Какую модель Ollama поставить на 4 ГБ RAM

MAATRIX

Ollama ставится одной командой, а дальше начинается лотерея: ollama run llama3.1 либо намертво вешает сервер, либо генерирует по одному токену раз в несколько секунд, либо процесс просто убивает OOM-killer. Причина почти всегда одна — модель по умолчанию весит больше, чем есть свободной памяти. На 4 ГБ RAM работать можно, но не с любой моделью из каталога Ollama, а с конкретным и довольно коротким списком. Ниже — какие модели туда реально помещаются с запасом на систему, по какой логике это считается и что делать, если выбранная модель всё равно не лезет.

Почему размер модели и объём RAM связаны напрямую

Модель в Ollama — это файл в формате GGUF, который целиком (или почти целиком, если нет GPU) загружается в оперативную память перед первым ответом. Не читается по частям с диска на лету, как видео, а держится в RAM всё время работы процесса ollama serve. Отсюда прямая зависимость: сколько весит файл модели — примерно столько же плюс контекст и накладные расходы процесса нужно свободной памяти.

Вес файла определяется двумя числами: количеством параметров модели и квантованием — то есть тем, сколько бит отводится на хранение каждого параметра. Оригинальные веса от разработчика обычно в FP16 — по 16 бит (2 байта) на параметр. Квантование сжимает это до 8, 5 или 4 бит, жертвуя точностью ради размера и скорости. В каталоге Ollama по умолчанию почти для всех моделей стоит квантование Q4_K_M — по историческим и практическим причинам это разумный баланс, и именно его увидит новичок, если не укажет тег явно.

Грубая формула для прикидки размера файла GGUF:

Размер (ГБ) ≈ Параметры (млрд) × Биты на параметр / 8

Для Q4_K_M реальный расход из-за неоднородного квантования слоёв — около 4,5–5 бит на параметр, то есть множитель примерно 0,6 ГБ на каждый миллиард параметров. Для Q5_K_M — около 0,7 ГБ/млрд, для Q8_0 — около 1,05–1,1 ГБ/млрд. Пример: модель на 3 млрд параметров в Q4_K_M даст файл около 2 ГБ, та же модель в Q8_0 — около 3,2 ГБ.

Но RAM нужна не только под сами веса. Поверх файла модели добавляются:

• KV-кэш контекста — растёт с длиной диалога и размером окна контекста (num_ctx); у мелких моделей на коротком контексте это десятки–сотни мегабайт, но при увеличении окна легко вырастает на гигабайт;
• служебная память процесса Ollama — раннер, буферы, обвязка вокруг llama.cpp;
• операционная система и всё остальное на сервере — SSH, панель управления, возможно nginx или Docker.

Практический ориентир: минимальная RAM под модель — это размер GGUF-файла, умноженный примерно на 1,2, плюс 1–1,5 ГБ на контекст и систему. На VPS с 4 ГБ из них реально доступно под модель 2,5–3 ГБ, если система лёгкая (голый Ubuntu без графики), и меньше, если на сервере уже что-то работает.

Какие модели реально помещаются в 4 ГБ с запасом

С учётом формулы выше на 4 ГБ RAM без риска OOM-killer помещаются модели примерно до 3–4 млрд параметров в Q4, и с бо́льшим запасом — модели до 2 млрд. Вот конкретный список актуальных на конец августа 2026 года моделей, которые на практике ставят на бюджетные VPS:

• Llama 3.2 1B — самая лёгкая из линейки Meta, годится для простых задач: короткие ответы, классификация, суммаризация небольших текстов.
• Qwen2.5 1.5B и Qwen2.5-Coder 1.5B — заметно сильнее по качеству на своём весе, приличный русский язык, вторая — с уклоном в код.
• Gemma2 2B от Google — хорошо держит инструкции и диалог, разумный компромисс между размером и связностью ответов.
• Llama 3.2 3B — более развёрнутые и связные ответы, чем у 1B, но уже требует аккуратности с контекстом на 4 ГБ.
• Qwen2.5 3B — универсальный выбор, если нужен RU/EN-чат или база под простого агента.
• Phi-3-mini (3.8B) от Microsoft — сильна в логике и коротком коде, но на 4 ГБ ставится впритык, без запаса под длинный контекст.

Таблица для быстрой ориентировки (размер файла и RAM — расчётные значения по формуле квантования, у конкретной сборки они могут отличаться на десятые доли гигабайта):

Если сервер, кроме Ollama, ничего не держит и контекст короткий (пара тысяч токенов, не больше), верхние строчки таблицы — Llama 3.2 1B, Qwen2.5 1.5B и Gemma2 2B — работают с комфортным запасом. Модели в 3–3,8 млрд параметров на 4 ГБ уже балансируют на грани: любой скачок контекста или параллельный запрос может утопить процесс в своп или в OOM. Сводную таблицу под разные объёмы RAM, не только 4 ГБ, мы разбирали отдельно в статье сколько RAM нужно для Ollama.

Чего категорически не хватит на 4 ГБ

Модели от 7 млрд параметров и выше на 4 ГБ RAM не помещаются даже в агрессивном квантовании — и дело не только в арифметике. Llama 3.1 8B, Qwen2.5 7B, Mistral 7B в Q4_K_M весят 4,5–4,7 ГБ уже одним файлом — это больше, чем вся доступная память сервера, ещё до учёта контекста и системы. Опуститься ниже Q4 в поисках места — плохая идея: квантования Q2 и Q3 драматически теряют в качестве, модель начинает путаться, повторяться и терять инструкции, и итоговый выигрыш в паре сотен мегабайт того не стоит.

Отдельная ловушка — теги без суффикса квантования. Команда ollama pull llama3.1 по умолчанию тянет 8B в Q4_K_M — файл под 4,7 ГБ, который гарантированно не встанет на 4-гигабайтный сервер. Новички часто ставят её просто по названию, не глядя в карточку модели на ollama.com, где указан размер конкретного тега. Если запуск модели молча убивает процесс без внятной ошибки в логах — это почти всегда OOM-killer, и первое, что стоит проверить, это dmesg | grep -i oom.

Про причины медленной или нестабильной генерации токенов — не только нехватку памяти, но и упор в CPU, диск или неудачный num_ctx — отдельный разбор в статье Ollama медленно генерирует токены.

Практическая установка и запуск модели

Сама Ollama ставится одной командой на любом современном Linux-дистрибутиве:

curl -fsSL https://ollama.com/install.sh | sh

После установки сервис ollama поднимается автоматически и слушает 127.0.0.1:11434. Дальше — выбор модели под 4 ГБ из списка выше. Для универсального лёгкого ассистента разумный старт — Qwen2.5 3B:

ollama run qwen2.5:3b

Первый запуск скачивает GGUF-файл и сразу открывает интерактивный чат в терминале. Если модель предполагается использовать не в терминале, а через API — из своего скрипта или бэкенда — модель достаточно скачать один раз, без немедленного запуска:

ollama pull qwen2.5:3b

и затем обращаться к ней через HTTP:

curl http://127.0.0.1:11434/api/generate -d '{
  "model": "qwen2.5:3b",
  "prompt": "Кратко объясни, что такое квантование модели",
  "stream": false
}'

Для более лёгкого варианта, если 3B на конкретном сервере ощутимо тормозит из-за постоянно занятого свопа, есть смысл сразу пробовать вариант меньше:

ollama run qwen2.5:1.5b

Сразу после первого ответа полезно посмотреть, сколько памяти реально занял процесс:

ollama ps
free -h

Колонка SIZE в выводе ollama ps показывает объём, который модель заняла в памяти (или видеопамяти, если есть GPU) — сверьте это число с available из free -h, чтобы понять, сколько запаса осталось на контекст и остальные процессы.

Своп как подстраховка, а не как основа

Своп-раздел (swap) на VPS с 4 ГБ RAM — это не способ запустить модель, которая не помещается в память, а страховка от падения процесса в момент кратковременного пика: чуть более длинный запрос, пара параллельных обращений к API, фоновая задача от системы. Без свопа такой пик почти всегда заканчивается тем, что ядро линукса убивает процесс ollama через OOM-killer.

Создать файл подкачки на 2 ГБ, если его ещё нет:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Важная оговорка: своп на диске на порядки медленнее оперативной памяти, и если модель начинает регулярно туда вытесняться, генерация ответа замедляется в разы — это признак того, что модель просто выбрана слишком крупная для сервера, а не повод мириться со свопом как постоянным режимом. Здоровый сценарий — своп почти никогда не используется и остаётся резервом на редкий пиковый момент; если free -h стабильно показывает ненулевой Swap used, стоит либо взять модель меньше, либо перейти на сервер с бóльшим объёмом RAM.

Когда пора апгрейднуться до 8 ГБ

4 ГБ RAM — рабочий объём для одной лёгкой модели и несложных сценариев, но у него есть чёткий потолок. Апгрейд до 8 ГБ стоит планировать, если наблюдается любое из следующего:

• нужна модель класса 7B (Llama 3.1 8B, Qwen2.5 7B, Mistral 7B) — на 8 ГБ она встаёт в Q4_K_M с разумным запасом под контекст;
• контекст диалога регулярно превышает 4–8 тысяч токенов — KV-кэш начинает откусывать заметную долю памяти сверх веса самой модели;
• Ollama делит сервер с другими сервисами — базой данных, панелью управления, обратным прокси — и им тоже нужна память постоянно, а не только в момент запроса к модели;
• планируются параллельные запросы к API от нескольких клиентов одновременно, а не последовательный чат в один поток.

Если хотя бы два пункта из списка про вашу задачу — переезд на VPS с 8 ГБ RAM обойдётся дешевле, чем часы, потраченные на подбор компромиссного квантования и борьбу со свопом. На 8 ГБ доступна не только более крупная модель, но и запас под второй процесс — например, embedding-модель для RAG рядом с основной чат-моделью.

Частые вопросы