Сколько RAM нужно VPS? Реальные цифры по задачам

Большинство выбирают память наугад. Либо покупают с огромным запасом «на всякий случай», либо знакомятся с OOM killer в три часа ночи. Хотя память — одна из самых простых вещей в подборе сервера: нагрузки предсказуемы, если знать примерные цифры. Вот они — от сервера на 1 ГБ для бота до тех самых 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 смена тарифа сохраняет данные, а списывается только пропорциональная разница (как работает смена тарифа).