Quanta RAM serve a un VPS di base?

Per un singolo bot, una piccola API o un sito statico basta 1 GB, spesso con margine. 2 GB sono la scelta comoda appena aggiungi un database o fai girare servizi in Docker. Sotto 1 GB, i gestori di pacchetti e i runtime dei linguaggi moderni iniziano a soffrire.

Quanta RAM serve per far girare un LLM su un VPS?

Più o meno la dimensione del modello alla sua quantizzazione, più un gigabyte o due per il contesto. Un modello da 7–8B a 4 bit vuole circa 5–6 GB, un 14B circa 10 GB, un 32B intorno ai 20 GB e un 70B intorno ai 40–45 GB. Per questo esistono i server da 64 GB: ci sta un modello da 70B con spazio per il resto dello stack.

Lo swap sostituisce la RAM?

No. Lo swap è una rete di sicurezza per i picchi brevi: evita che una build o un backup vengano terminati. Se un carico vive nello swap tutto il giorno, tutto diventa lento; è il segnale per passare a un piano superiore.

Come vedo quanta RAM usa davvero il mio server?

Esegui 'free -h' e guarda la colonna 'available', non 'free': Linux usa la memoria libera come cache del disco e la restituisce quando serve. 'ps aux --sort=-rss | head' mostra i processi più grandi, e 'docker stats --no-stream' mostra l'uso per container.

Quando ha senso un VPS da 64 GB?

Quando una singola cosa deve stare in memoria: un modello locale da 32–70B, un grande indice vettoriale per RAG o una flotta di agenti con i loro runtime. Per siti, bot e la maggior parte delle API sono soldi sprecati.

Quanta RAM serve a un VPS? Numeri reali per carico

La maggior parte delle persone la RAM la tira a indovinare. O compra troppo «per sicurezza», o scopre l'OOM killer alle 3 di notte. La memoria in realtà è una delle cose più facili da dimensionare, perché i carichi sono prevedibili una volta noti i numeri indicativi. Eccoli, da una macchina da 1 GB per un bot fino ai server da 64 GB che si cercano quando si vuole far girare un grande modello in locale.

Numeri indicativi per carico

Sono valori reali a regime per un setup tipico, non i minimi dichiarati dai produttori.

Carico	RAM usata davvero	Piano adatto
Bot Telegram/Discord (Python, Node.js)	100–300 MB	Nano 1 GB
Sito statico + Caddy/Nginx	50–150 MB	Nano 1 GB
WordPress + MariaDB, traffico normale	0,8–1,5 GB	Micro-IP 2 GB
PostgreSQL per una piccola app	0,5–2 GB (lo decidi tu con `shared_buffers`)	Micro / Small
n8n con qualche workflow	0,5–1,5 GB	Micro 2 GB
Host Docker con 5–10 piccoli servizi	2–4 GB	Small 4 GB
Coolify + build + un database	3–4 GB	Small-IP 4 GB
LLM da 7–8B, 4 bit, inferenza su CPU	5–6 GB	Medium 6 GB
LLM da 14B, 4 bit	~10 GB	Pro-32
LLM da 32B, 4 bit	~20 GB	Pro-32
LLM da 70B, 4 bit	~40–45 GB	Pro-48 / Pro-64

Due cose da notare. Primo, il salto tra i carichi «normali» e gli LLM è enorme: un bot e un modello da 70B differiscono di un fattore duecento. Secondo, la maggior parte dei servizi sta bene con 1–4 GB; si compra troppo perché si dimensiona per un futuro che raramente arriva.

La formula per gli LLM

Per i modelli linguistici c'è una stima semplice: parametri × bit per peso ÷ 8, più l'overhead. Un modello da 8B a circa 4,5 bit (una tipica quantizzazione Q4) fa 8 × 4,5 ÷ 8 ≈ 4,5 GB di pesi. Aggiungi 1–2 GB per la finestra di contesto (la KV cache cresce con la lunghezza del contesto) e per il runtime, e arrivi a 5–6 GB.

La parte onesta: sui server solo CPU la memoria è metà della storia. Aspettati una manciata di token al secondo per i modelli da 7–8B su pochi vCPU e circa un token al secondo per un 70B. Va bene per lavori batch, agenti in background ed esperimenti privati; non è un'esperienza di chat per molti utenti contemporanei. Se chiami soprattutto API di modelli in hosting, al tuo agente serve molto meno: vedi dimensionare un VPS per agenti AI.

Misura invece di indovinare

Se hai già un server, i numeri sono lì:

free -h                              # look at "available", not "free"
ps aux --sort=-rss | head -n 8       # the biggest processes, by resident memory
docker stats --no-stream             # per-container usage

Linux usa la RAM inattiva come cache del disco, quindi «free» è sempre piccolo, ed è sano così. Available è il numero che conta: la memoria che il kernel può dare ai programmi in questo momento. Se nell'ora di punta available resta sopra il 25% circa, sei dimensionato bene. Se scende spesso a zero e lo swap cresce, sali di piano.

Controlla anche se ci sono stati OOM kill in passato:

journalctl -k | grep -i "out of memory"

Lo swap: una cintura di sicurezza, non un motore

Un file di swap da 1–2 GB su un piccolo server è un'assicurazione economica: un aggiornamento dei pacchetti o una build Docker che per un attimo chiede più memoria sopravvive invece di essere terminata. Ma se un servizio vive nello swap, ogni richiesta aspetta il disco. Lo swap serve per i picchi. Uno swapping costante vuol dire che ti serve il piano successivo.

Quindi quanta comprarne?

1 GB: un bot, una piccola API, un sito statico.
2 GB: la scelta sensata per qualsiasi cosa con un database o Docker.
4–6 GB: diversi servizi sulla stessa macchina, build sul server, un piccolo modello locale.
32–64 GB: solo quando una cosa grande deve vivere in memoria: un modello locale sopra i 14B, un grande indice RAG, una flotta di agenti. È a questo che servono i piani ad alta memoria.

Parti da una taglia sotto rispetto a quello che ti dice l'istinto, osserva free -h per una settimana e sali se i numeri lo dicono. Su EQVPS il passaggio a un piano superiore mantiene i tuoi dati e addebita solo la differenza proporzionale (come funzionano i cambi di piano).