Більшість обирає пам'ять навмання. Або купують із величезним запасом «про всяк випадок», або знайомляться з OOM killer о третій ночі. Хоча пам'ять — одна з найпростіших речей у підборі сервера: навантаження передбачувані, якщо знати приблизні цифри. Ось вони — від сервера на 1 ГБ для бота до тих самих 64 ГБ, які шукають, щоб запустити велику модель у себе.
Приблизні цифри за задачами
Це реальне споживання в усталеному режимі для типового встановлення, а не мінімальні вимоги з документації.
| Задача | Реально займає RAM | Відповідний тариф |
|---|---|---|
| Бот для Telegram/Discord (Python, Node.js) | 100–300 МБ | Nano 1 ГБ |
| Статичний сайт + Caddy/Nginx | 50–150 МБ | Nano 1 ГБ |
| WordPress + MariaDB, звичайний трафік | 0,8–1,5 ГБ | Micro-IP 2 ГБ |
| PostgreSQL для невеликого застосунку | 0,5–2 ГБ (вирішуєте самі через shared_buffers) | Micro / Small |
| n8n із кількома сценаріями | 0,5–1,5 ГБ | Micro 2 ГБ |
| Docker-хост із 5–10 невеликими сервісами | 2–4 ГБ | Small 4 ГБ |
| Coolify + збірки + база даних | 3–4 ГБ | Small-IP 4 ГБ |
| LLM 7–8B, 4 біти, інференс на CPU | 5–6 ГБ | Medium 6 ГБ |
| LLM 14B, 4 біти | ~10 ГБ | Pro-32 |
| LLM 32B, 4 біти | ~20 ГБ | Pro-32 |
| LLM 70B, 4 біти | ~40–45 ГБ | Pro-48 / Pro-64 |
Зверніть увагу на дві речі. По-перше, розрив між «звичайними» задачами й LLM величезний — бот і модель 70B відрізняються у двісті разів. По-друге, більшості сервісів вистачає 1–4 ГБ; переплачують, бо беруть пам'ять під майбутнє, яке рідко настає.
Формула для LLM
Для мовних моделей є проста оцінка: параметри × біт на вагу ÷ 8, плюс накладні витрати. Модель 8B приблизно в 4,5 біта (типова квантизація Q4) — це 8 × 4,5 ÷ 8 ≈ 4,5 ГБ ваг. Додайте 1–2 ГБ на контекстне вікно (KV-кеш росте з довжиною контексту) і рантайм — виходить 5–6 ГБ.
Чесна частина: на серверах лише з CPU пам'ять — тільки половина історії. Чекайте однозначної кількості токенів на секунду для моделей 7–8B на кількох vCPU і приблизно одного токена на секунду для 70B. Для пакетних задач, фонових агентів і приватних експериментів це нормально; для чату з багатьма одночасними користувачами — ні. Якщо ви здебільшого кличете хмарні API моделей, агенту потрібно набагато менше — див. підбір 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%, розмір обрано правильно. Якщо регулярно падає до нуля й росте своп — час вище.
Перевірте й минулі OOM-вбивства:
journalctl -k | grep -i "out of memory"
Своп — пасок безпеки, а не двигун
Своп-файл на 1–2 ГБ на маленькому сервері — дешева страховка: оновлення пакетів чи збірка Docker, якій ненадовго потрібно більше пам'яті, переживе пік замість того, щоб бути вбитою. Але якщо сервіс живе у свопі, кожен запит чекає на диск. Своп — для піків. Постійний свопінг означає, що потрібен наступний тариф.
То скільки брати?
- 1 ГБ — один бот, одне невелике API, статичний сайт.
- 2 ГБ — розумний стандарт для всього, де є база чи Docker.
- 4–6 ГБ — кілька сервісів на одній машині, збірки на сервері, невелика локальна модель.
- 32–64 ГБ — лише коли в пам'яті має жити одна велика річ: локальна модель більша за 14B, великий RAG-індекс, парк агентів. Для цього й існують тарифи з великою пам'яттю.
Беріть на розмір менше, ніж підказує інтуїція, тиждень дивіться на free -h і розширюйтеся, якщо цифри так кажуть. В EQVPS зміна тарифу зберігає дані, а списується лише пропорційна різниця (як працює зміна тарифу).
Коментарі
Поки немає коментарів. Будьте першим.