You want to put an AI assistant online and VPS plans start at a few euros. Is that enough? The first question is not how many gigabytes you need. It is what the server will actually run.
An app that sends requests to Grok or OpenAI does not compute the model’s answers itself. It manages users, requests, files and possibly a database. Running a local model adds a very different workload.
Map the path of a request
If you use an API, a modest VPS can be a starting point for a small workload. That is not a capacity guarantee. Connections, attachments, the database and background jobs can overwhelm the server long before the remote model becomes the bottleneck.
For a local model, start with the exact model, quantization and inference engine. Weights are only part of memory usage. Context, concurrent requests and the engine add their own requirements. Do not infer RAM needs from the download size alone.
With an API
Browser → your server → provider API
↓
database
With a local model
Browser → your server → inference engine
↓
local RAM / GPU
In both cases
Authentication → quotas → bounded job queue
Measure before upgrading
In a test environment, replay a flow with fictional data and gradually increase concurrency. Watch available memory, disk usage, errors and response time. These Linux commands give a snapshot of the machine, not a capacity test on their own.
# Available memory and swap
free -h
# Disk space
df -h
# Load and processes
uptime
ps -eo pid,comm,%mem,%cpu --sort=-%mem | head -n 12
# If the app runs in Docker
docker stats --no-stream
Leave room for the busier days
A server that handles ten consecutive requests may not handle ten concurrent ones. Limit in-flight work and reject what you cannot process cleanly. If latency comes from the API, doubling the VPS RAM will not fix that delay.
I would choose a size from those measurements, leaving room for backups and updates. A small server you understand is more useful than a large machine whose errors nobody watches.