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

MAATRIX

На 4-8 ГБ RAM выбор модели — это компромисс: либо мелкая модель, либо крупная, но обрезанная агрессивным квантованием до потери связности. На 16 ГБ логика меняется: сюда уже помещаются модели 13-14 млрд параметров в нормальном Q4 или даже Q5-квантовании, без экстремального сжатия. Ниже — какие модели реально стоят на 16 ГБ с запасом, когда выгоднее взять 7B в высоком качестве вместо урезанной 13B, как держать две модели загруженными одновременно и в какой момент даже 16 ГБ перестаёт хватать.

Что открывает переход на 16 ГБ: модели 13B–14B без урезанного квантования

Формула прикидки размера файла та же, что и для младших объёмов RAM: множитель на квантование, умноженный на число параметров в миллиардах. Для Q4_K_M это примерно 0,6 ГБ на миллиард параметров, для Q5_K_M — около 0,7 ГБ/млрд. Поверх файла модели закладывайте коэффициент 1,2 на служебную память процесса и ещё 1-1,5 ГБ на контекст и систему — эта же логика расчёта разобрана подробнее в статье сколько RAM нужно для Ollama.

Модель на 14 млрд параметров в Q4_K_M даёт файл около 8,4 ГБ. С учётом накладных расходов это примерно 11,5 ГБ занятой памяти — комфортно помещается в 16 ГБ, оставляя 4-4,5 ГБ на систему и контекст. Та же модель в Q5_K_M весит уже около 9,8 ГБ файлом и потребует порядка 13,3 ГБ суммарно — всё ещё влезает, но запас на длинный контекст или второй процесс становится тонким.

На конец августа 2026 года в каталоге Ollama в диапазоне 13-14B актуальны:

• Qwen2.5 14B — сильная универсальная модель, приличный русский, держит инструкции лучше, чем 7B того же семейства;
• Qwen2.5-Coder 14B — та же линейка с уклоном в код: рефакторинг, объяснение чужого кода, генерация функций по описанию;
• CodeLlama 13B — специализация на коде, преимущественно англоязычные промпты;
• Llama 2 13B — более старая модель, но всё ещё в каталоге; по качеству инструкций уступает Qwen2.5 14B, для новых проектов почти всегда есть более удачный выбор того же веса.

Разница с 4 ГБ, где предел — модели около 3-4 млрд параметров, ощущается не просто в размере: 13-14B модели заметно лучше держат многошаговые инструкции, реже теряют контекст диалога и меньше «галлюцинируют» на фактических вопросах. Это не абсолютная гарантия качества — конкретные результаты зависят от задачи и промпта — но статистически разница между 3B и 14B в связности ответа заметна почти всегда.

Качественные 7B без агрессивного сжатия — когда Q6/Q8 лучше, чем 13B в Q4

Не всегда есть смысл сразу брать максимальный размер модели, который влезает. У 16 ГБ RAM есть альтернативный путь: взять модель поменьше — 7-8 млрд параметров — но в куда более высоком квантовании, Q6_K или Q8_0, вместо стандартного Q4_K_M. Расход памяти на эти кванты выше — примерно 0,8 ГБ/млрд для Q6_K и 1,05-1,1 ГБ/млрд для Q8_0, — но и потери от квантования минимальны: Q8_0 практически неотличим от исходных весов FP16 по качеству ответа.

Qwen2.5 7B в Q8_0 — это файл около 7,4 ГБ, суммарно с накладными расходами около 10,3 ГБ. Llama 3.1 8B в том же кванте — около 8,4 ГБ файлом, порядка 11,6 ГБ суммарно. Оба варианта заметно легче, чем 14B в Q4_K_M, и при этом не теряют в точности из-за сжатия — теряют только в объёме «знаний», которые физически зависят от числа параметров.

Когда это выгоднее, чем 13-14B в Q4:

• задача требует точного следования инструкциям и работы с контекстом (RAG, извлечение данных из документов), а не широкой эрудиции — здесь точность квантования важнее объёма параметров;
• на сервере параллельно крутится что-то ещё, и лишний гигабайт-два запаса не помешает;
• нужна более высокая скорость генерации — меньшая модель при прочих равных отвечает быстрее, даже в тяжёлом кванте.

Обратная сторона: 7B — это всё ещё 7B, и по широте «фоновых знаний» и способности удерживать сложную многошаговую логику модель на 14 млрд параметров в среднем сильнее, даже в Q4. Однозначного правильного ответа нет — если задача узкая и предсказуемая, качественный 7B часто предпочтительнее; если нужна более гибкая модель общего назначения — есть смысл брать 13-14B.

Таблица моделей для 16 ГБ RAM

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

Верхние строчки — 14B в Q4 и 7-8B в Q8 — комфортно работают в одиночку с запасом под контекст на несколько тысяч токенов. Модель в Q5_K_M на 14B и связка «чат + embeddings» уже плотнее используют доступную память, но всё ещё укладываются без риска OOM при аккуратной настройке.

Как держать две модели одновременно и не упереться в OOM

16 ГБ — это тот объём, где имеет смысл не одна модель, а связка из двух: например, основная чат-модель плюс отдельная embedding-модель для RAG (nomic-embed-text или mxbai-embed-large — обе весят несколько сотен мегабайт и почти не влияют на общий бюджет памяти), либо две модели под разные роли — чат и код.

По умолчанию поведение Ollama по выгрузке предыдущей модели при запросе к новой зависит от версии и настроек — надёжнее не полагаться на умолчания, а явно задать лимит через переменную окружения:

export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=1
sudo systemctl restart ollama

OLLAMA_MAX_LOADED_MODELS=2 разрешает держать в памяти сразу две модели вместо одной, OLLAMA_NUM_PARALLEL ограничивает число параллельных запросов на модель — каждый параллельный слот добавляет свой KV-кэш, так что на 16 ГБ с двумя резидентными моделями разумно держать это значение небольшим.

Прежде чем комбинировать модели, стоит прикинуть бюджет вручную: сумма занятой памяти обеих моделей (файл × 1,2) плюс 1-1,5 ГБ на систему не должна подходить вплотную к 16 ГБ. Связка «7B в Q4 (~5,6 ГБ с накладными расходами) + embedding-модель (~0,5 ГБ)» укладывается с большим запасом. Связка «две модели по 7-8B в Q6-Q8» — уже 20+ ГБ суммарно и на 16 ГБ не поместится одновременно; здесь придётся либо снижать квант, либо ограничиваться одной резидентной моделью, а вторую подгружать по требованию.

Проверить, что реально загружено в память в моменте:

ollama ps
free -h

Выгрузить модель вручную, не дожидаясь тайм-аута:

ollama stop qwen2.5:14b

Настройка Ollama под 16 ГБ: контекст, keep_alive, параллельные запросы

Три параметра прямо влияют на то, сколько памяти реально израсходует запущенная модель, помимо веса самого файла.

num_ctx — размер окна контекста. KV-кэш растёт линейно с этим значением и с числом слоёв модели; у 14B он весит заметно больше, чем у 3B на том же контексте. Задать явно можно через API-запрос:

curl http://127.0.0.1:11434/api/generate -d '{
  "model": "qwen2.5:14b",
  "prompt": "Объясни разницу между Q4 и Q8 квантованием",
  "options": { "num_ctx": 8192 },
  "stream": false
}'

Не стоит без нужды ставить num_ctx на максимум, который поддерживает модель — если реальные диалоги короткие, лишние гигабайты KV-кэша просто съедают запас, который пригодился бы под вторую модель.

OLLAMA_KEEP_ALIVE — сколько времени модель остаётся в памяти после последнего запроса, прежде чем выгрузится сама. Значение по умолчанию — несколько минут; если приложение обращается к модели редко, но нужен мгновенный ответ без повторной загрузки файла с диска, время стоит увеличить:

export OLLAMA_KEEP_ALIVE=30m

Обратная сторона — модель дольше занимает память впустую между запросами, что критично именно при двух резидентных моделях на 16 ГБ.

OLLAMA_NUM_PARALLEL — уже упомянутый лимит параллельных запросов к одной модели. Для одиночного диалогового сценария достаточно значения 1; поднимать его стоит только если приложение реально обслуживает нескольких пользователей одновременно, и в бюджете памяти заранее заложен запас под дополнительные KV-кэши.

Когда 16 ГБ уже мало: модели 30B+ и пора думать про GPU

Модели от 30 млрд параметров и выше на 16 ГБ RAM не помещаются даже в Q4. Qwen2.5 32B в Q4_K_M — это файл около 19 ГБ, что уже больше всей доступной памяти сервера без учёта контекста и системы. Mixtral 8x7B, несмотря на архитектуру MoE с активными не всеми параметрами при инференсе, всё равно держит в памяти все веса модели целиком — суммарно порядка 47 млрд параметров, что также выводит её далеко за пределы 16 ГБ в любом разумном кванте.

Технически можно попытаться впихнуть такую модель через своп, но это плохая идея на практике: генерация токенов при постоянном вытеснении в своп замедляется в разы, и диалоговый сценарий превращается в ожидание, а не в работу. Разница между Ollama на CPU и на GPU при таких объёмах модели разобрана подробнее в статье CPU или GPU для локальной LLM — если коротко, для моделей 30B+ система с достаточной видеопамятью перестаёт быть роскошью и становится единственным практичным вариантом, потому что вычисления идут в VRAM, а не в оперативной памяти сервера, и математика ограничений совсем другая.

Если проект дорос до этой точки, разумный следующий шаг — не апгрейд RAM на том же сервере, а переход на конфигурацию с GPU: варианты для инференса LLM разобраны в статье GPU-сервер в США для инференса LLM.

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