De câtă RAM are nevoie un VPS? Cifre reale după sarcină

Majoritatea oamenilor își ghicesc RAM-ul. Fie cumpără mult prea mult, „pentru orice eventualitate”, fie descoperă OOM killerul la 3 dimineața. Memoria e de fapt unul dintre cele mai ușor de dimensionat lucruri, pentru că sarcinile sunt previzibile odată ce știi cifrele aproximative. Iată-le, de la o mașină de 1 GB pentru un bot până la serverele de 64 GB pe care le caută oamenii când vor să ruleze local un model mare.

Cifre aproximative după sarcină

Sunt cifre reale, în regim stabil, pentru o configurare obișnuită, nu minimurile furnizorilor.

Două lucruri de observat. Întâi, saltul dintre sarcinile „normale” și LLM-uri e uriaș — un bot și un model de 70B diferă de două sute de ori. Apoi, majoritatea serviciilor merg bine pe 1–4 GB; oamenii cumpără prea mult pentru că dimensionează pentru un viitor care rareori vine.

Formula pentru LLM

Pentru modelele de limbaj există o estimare simplă: parametri × biți per greutate ÷ 8, plus overhead. Un model de 8B la aproximativ 4,5 biți (o cuantizare Q4 obișnuită) înseamnă 8 × 4,5 ÷ 8 ≈ 4,5 GB de greutăți. Adaugă 1–2 GB pentru fereastra de context (cache-ul KV crește odată cu lungimea contextului) și pentru runtime și ajungi la 5–6 GB.

Partea cinstită: pe serverele doar cu CPU, memoria e doar jumătate din poveste. Așteaptă-te la tokeni pe secundă de o singură cifră pentru modelele de 7–8B pe câteva vCPU și la aproximativ un token pe secundă pentru 70B. E în regulă pentru loturi, agenți de fundal și experimente private; nu e o experiență de chat pentru mulți utilizatori simultani. Dacă apelezi mai ales API-uri de modele găzduite, agentul tău are nevoie de mult mai puțin — vezi dimensionarea VPS pentru agenți AI.

Măsoară în loc să ghicești

Dacă ai deja un server, cifrele sunt chiar acolo:

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 folosește RAM-ul neocupat drept cache de disc, deci „free” e mereu mic, și asta e sănătos. Available e cifra care contează — memoria pe care kernelul o poate da programelor chiar acum. Dacă available rămâne peste ~25% în ora cea mai aglomerată, ești dimensionat corect. Dacă ajunge regulat la zero și swap-ul crește, treci mai sus.

Verifică și opririle OOM din trecut:

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

Swap: centură de siguranță, nu motor

Un fișier swap de 1–2 GB pe un server mic e o asigurare ieftină: o actualizare de pachete sau un build Docker care are nevoie pentru scurt timp de mai multă memorie supraviețuiește, în loc să fie oprit. Dar dacă un serviciu trăiește în swap, fiecare cerere așteaptă după disc. Swap-ul e pentru vârfuri. Swap constant înseamnă că ai nevoie de planul următor.

Deci cât să cumperi?

• 1 GB — un bot, un API mic, un site static.
• 2 GB — alegerea implicită rezonabilă pentru orice are o bază de date sau Docker.
• 4–6 GB — mai multe servicii pe o mașină, builduri pe server, un model local mic.
• 32–64 GB — doar când un lucru mare trebuie să stea în memorie: un model local peste 14B, un index RAG mare, o flotă de agenți. Pentru asta sunt planurile cu multă memorie.

Pornește cu o mărime sub ce-ți spune instinctul, urmărește free -h o săptămână și treci mai sus dacă așa spun cifrele. Pe EQVPS, un upgrade de plan îți păstrează datele și taxează doar diferența proporțională (cum funcționează schimbările de plan).