Повечето хора гадаят RAM-а. Или купуват много повече «за всеки случай», или се запознават с OOM killer в 3 през нощта. Паметта всъщност е от най-лесните неща за оразмеряване, защото натоварванията са предвидими, щом знаеш грубите числа. Ето ги, от сървър с 1 GB за бот до сървърите с 64 GB, които хората търсят, когато искат да пуснат голям модел локално.
Груби числа по натоварване
Това са реални стойности в стабилно състояние за типична настройка, не минимумите на производителите.
| Натоварване | Реално ползвана RAM | Подходящ план |
|---|---|---|
| Бот за Telegram/Discord (Python, Node.js) | 100–300 MB | Nano 1 GB |
| Статичен сайт + Caddy/Nginx | 50–150 MB | Nano 1 GB |
| WordPress + MariaDB, нормален трафик | 0.8–1.5 GB | Micro-IP 2 GB |
| PostgreSQL за малко приложение | 0.5–2 GB (решаваш чрез shared_buffers) | Micro / Small |
| n8n с няколко workflow-а | 0.5–1.5 GB | Micro 2 GB |
| Docker хост с 5–10 малки услуги | 2–4 GB | Small 4 GB |
| Coolify + билдове + база данни | 3–4 GB | Small-IP 4 GB |
| LLM 7–8B, 4-bit, inference на CPU | 5–6 GB | Medium 6 GB |
| LLM 14B, 4-bit | ~10 GB | Pro-32 |
| LLM 32B, 4-bit | ~20 GB | Pro-32 |
| LLM 70B, 4-bit | ~40–45 GB | Pro-48 / Pro-64 |
Две неща да забележиш. Първо, скокът между «нормалните» натоварвания и LLM е огромен: бот и модел 70B се различават двеста пъти. Второ, повечето услуги се чувстват добре на 1–4 GB; хората купуват повече, защото оразмеряват за бъдеще, което рядко идва.
Формулата за LLM
За езиковите модели има проста оценка: параметри × битове на тегло ÷ 8, плюс допълнителни разходи. Модел 8B при около 4.5 бита (типична Q4 квантизация) е 8 × 4.5 ÷ 8 ≈ 4.5 GB тегла. Добави 1–2 GB за прозореца на контекста (KV cache расте с дължината на контекста) и runtime-а и стигаш до 5–6 GB.
Честната част: на сървъри само с CPU паметта е само половината история. Очаквай едноцифрен брой токени в секунда за модели 7–8B на няколко vCPU и около токен в секунда за 70B. Това е добре за пакетни задачи, фонови агенти и лични експерименти; не е чат изживяване за много едновременни потребители. Ако основно викаш APIs на хоствани модели, агентът ти иска много по-малко; виж размер на VPS за AI агенти.
Измервай вместо да гадаеш
Ако вече имаш сървър, числата са там:
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 ползва неизползваната RAM като кеш за диска, така че «free» винаги е малко и това е здравословно. Available е числото, което има значение: паметта, която ядрото може да даде на програмите в момента. Ако available остава над ~25% в най-натоварения ти час, размерът е правилен. Ако редовно стига нула и swap-ът расте, мини по-нагоре.
Провери и за минали OOM убийства:
journalctl -k | grep -i "out of memory"
Swap: предпазен колан, не двигател
Swap файл от 1–2 GB на малък сървър е евтина застраховка: обновяване на пакет или Docker билд, на който за миг трябва повече памет, оцелява вместо да бъде убит. Но ако услуга живее в swap, всяка заявка чака диска. Swap-ът е за пикове. Постоянното swap-ване значи, че ти трябва следващият план.
Та колко да купиш?
- 1 GB: един бот, едно малко API, статичен сайт.
- 2 GB: разумният стандарт за всичко с база данни или Docker.
- 4–6 GB: няколко услуги на една машина, билдове на сървъра, малък локален модел.
- 32–64 GB: само когато едно голямо нещо трябва да живее в паметта: локален модел над 14B, голям RAG индекс, флот от агенти. За това са плановете с много памет.
Започни с един размер по-малко, отколкото ти казва инстинктът, гледай free -h една седмица и надгради, ако числата го кажат. В EQVPS надграждането на плана пази данните ти и таксува само пропорционалната разлика (как работят смените на план).
Коментари
Още няма коментари. Бъди първият.