Сколько RAM нужно для Ollama: таблица моделей

MAATRIX

Ollama ставится одной командой и создаёт ощущение, что железо не важно. Ощущение живёт до строчки Error: model requires more system memory (14.9 GiB) than is available (13.4 GiB) — или до момента, когда модель запустилась, но печатает по слову в пять секунд. Ниже — таблица RAM по моделям, формула с KV-кэшем и честные границы конфигураций.

Короткий ответ: сколько оперативной памяти нужно Ollama

Вопрос «Ollama сколько оперативной памяти требует» не имеет одного ответа: памяти требует не Ollama, а модель, которую вы в неё загружаете. Сам сервис — Go-бинарник, в покое он занимает 90–150 МБ. Всё остальное съедают веса и кэш внимания. Рабочая формула:

RAM ≈ вес файла модели × 1,1 + KV-кэш под ваш контекст + 1,5 ГБ на систему

Коэффициент 1,1 — буферы вычислительного графа поверх весов. Полтора гигабайта — минимум для Ubuntu 24.04 с SSH и systemd; если рядом Docker с Open WebUI и Postgres, закладывайте 2,5–3 ГБ.

Быстрые ориентиры по классам, при контексте 8k и одном пользователе: 8 ГБ — модели до 8B в Q4_K_M, впритык, но работает; 16 ГБ — 12–14B комфортно или 8B с контекстом 32k; 32 ГБ — 24–32B либо две средние модели сразу; 64 ГБ — 70B на CPU, влезет, но скорость расстроит; 96–128 ГБ — 120B и крупные MoE вроде qwen3:235b-a22b.

Речь про инференс на процессоре: если в сервере есть видеокарта, лимитом становится VRAM — про это отдельная секция.

Таблица: вес модели и минимальная RAM

Колонка «вес» — размер GGUF-файла в Q4_K_M, то есть то, что даёт обычный ollama pull llama3.1:8b без суффиксов. «Минимум» посчитан по формуле выше при контексте 8192 токенов.

Две строки требуют пояснения. gpt-oss идёт не в Q4_K_M, а в родном MXFP4 — вес задан релизом, а не вашим выбором. qwen3:30b-a3b — MoE: в памяти лежат все 30 миллиардов параметров, а считаются на токен только 3 миллиарда. RAM требует как крупная модель, а работает как средняя — для CPU-инференса лучший размен, который сегодня доступен.

Вторая таблица — как квантование меняет требования на примере одной 8B. Люди тянут :8b-instruct-q8_0 «чтобы получше» и упираются в память там, где Q4 работал бы спокойно:

Переход с Q4_K_M на Q8_0 стоит четырёх лишних гигабайт и половины скорости, а разницу в ответах вы в большинстве задач не заметите. Как квантование влияет на скорость — в разборе про медленную генерацию.

Из чего складывается память: веса, KV-кэш и слоты

Веса. Ollama открывает GGUF через mmap, и после первого прохода в памяти оказывается весь файл — каждому токену нужны все веса. Побочный эффект важен для диагностики: в free -h эти гигабайты попадают в buff/cache, а не в used, и неопытный глаз видит «память свободна» при занятой машине.

KV-кэш. О нём забывают чаще всего. Он хранит ключи и значения внимания для каждого токена контекста и растёт линейно по его длине:

KV = 2 × слои × KV-головы × размер_головы × токены × байт_на_число

Для llama3.1:8b это 32 слоя, 8 KV-голов, размер головы 128, f16 по 2 байта: 2 × 32 × 8 × 128 × 8192 × 2 = 1 073 741 824 байт — ровно 1 ГиБ на 8k контекста. Дальше арифметика:

Отсюда самая дорогая ошибка новичка: выставить num_ctx в 131072, потому что «модель же поддерживает». Вы добавляете 16 ГБ к 5 ГБ весов и получаете отказ запуска там, где модель прекрасно жила.

Слоты параллелизма. Ollama резервирует несколько слотов одновременных запросов и умножает KV-кэш на их число — по умолчанию до четырёх, если считает, что памяти хватает. Для одного пользователя это чистая потеря: Environment="OLLAMA_NUM_PARALLEL=1" через systemctl edit ollama экономит три четверти кэша.

Как измерить свой расход, а не гадать по таблице

Три команды дают точную картину за минуту. Первая — что загружено сейчас:

ollama ps
NAME                ID              SIZE      PROCESSOR    UNTIL
qwen2.5-coder:14b   9ec8897f747e    11 GB     100% CPU     4 minutes from now

SIZE — не вес файла, а веса плюс KV-кэш плюс буферы, то есть ровно то, что модель занимает в памяти; разница с 9,3 ГБ из таблицы — как раз кэш.

Вторая — реальное состояние памяти:

free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       2,1Gi       298Mi       1,0Mi        13Gi       1,4Gi
Swap:          2,0Gi       412Mi       1,6Gi

Смотрите не на used и тем более не на free, а на available. Здесь used всего 2,1 ГБ, но 13 ГБ в buff/cache — это отображённые веса, и свободно на самом деле 1,4 ГБ. Именно по available Ollama решает, влезет модель или нет.

Третья — самая полезная. Журнал сервиса прямо пишет, сколько памяти он насчитал и что решил:

journalctl -u ollama --no-pager -n 200 | grep -i "memory\|offload"
msg="offload to cpu" layers.requested=-1 layers.model=49 layers.offload=0
  memory.available="[13.4 GiB]" memory.required.full="14.9 GiB"
  memory.weights.total="9.1 GiB" memory.kv.cache="4.0 GiB"

Эта строка отвечает лучше любой таблицы: движок сам разложил требования на веса и кэш и сравнил с доступным. Виноваты не веса, а контекст 32k, раздувший KV до 4 ГБ. Параметры своей модели — в ollama show qwen2.5-coder:14b.

Что происходит при нехватке: точные ошибки

Сценариев три, и лечатся они по-разному.

Отказ на старте. Ollama посчитала требования заранее и не стала пытаться — самый удобный случай, вам назвали обе цифры и разницу:

Error: model requires more system memory (14.9 GiB) than is available (13.4 GiB)

Убил OOM-killer. Модель начала грузиться, оценка не сошлась с реальностью, вмешалось ядро:

Error: llama runner process has terminated: signal: killed

dmesg -T | grep -i "out of memory"
[Fri Aug 21 11:04:38 2026] Out of memory: Killed process 8817 (ollama runner)
total-vm:19427840kB, anon-rss:12904512kB, oom_score_adj:0

Так гибнут машины без swap при попытке загрузить вторую модель, не выгрузив первую. Про соседние симптомы — 403, model not found, обрывы pull — есть разбор частых ошибок Ollama.

Худший сценарий — всё «работает». Ответы идут, но невыносимо медленно. Проверяйте своп: vmstat 1 5, колонки si/so. Ненулевые значения в десятках тысяч — это модель, которую перекачивают между диском и памятью на каждом токене. Замер на стенде: qwen3:8b с контекстом 32k на машине с 8 ГБ RAM и 4 ГБ swap выдавала 0,4 токена в секунду против 7,1 tok/s на той же модели с контекстом 8k без свопа. Разница в семнадцать раз — и ни одного сообщения об ошибке.

Порядок действий, от дешёвого к дорогому:

1. Снизьте контекст: Environment="OLLAMA_CONTEXT_LENGTH=8192". Переменная работает начиная с версии 0.6, свою проверьте через ollama -v.
2. Поставьте один слот: OLLAMA_NUM_PARALLEL=1, и OLLAMA_MAX_LOADED_MODELS=1, чтобы вторая модель не вытесняла первую.
3. Сожмите KV-кэш: OLLAMA_FLASH_ATTENTION=1 вместе с OLLAMA_KV_CACHE_TYPE=q8_0 — минус половина кэша почти без потерь качества. Без флеш-аттеншена вторая переменная игнорируется.
4. Возьмите модель поменьше в Q4, а не ту же в Q3. 8B в Q4_K_M почти всегда осмысленнее, чем 14B в Q3_K_S.
5. Добавьте RAM. Swap — страховка от падения при загрузке весов, а не решение: постоянная работа из свопа делает инференс бессмысленным.

RAM или VRAM: когда память системная, а когда видеокарты

Если в сервере есть NVIDIA-карта и она видна через nvidia-smi, Ollama выгружает слои в VRAM, и лимитом становится она. Формула та же, только применяется к видеопамяти: 8 ГБ VRAM — до 8B, 12 ГБ — 12B или 8B с контекстом 32k, 16 ГБ — 14B, 24 ГБ — 24–32B, 48 ГБ — 70B в Q4 с коротким контекстом, 80 ГБ — 70B с большим контекстом или 120B в MXFP4.

Системная RAM при этом нужна всё равно: веса читаются с диска в память и оттуда копируются в VRAM, так что на время загрузки требуется примерно столько же RAM, сколько весит модель. Правило: системной памяти не меньше, чем видеопамяти. Сервер с картой на 24 ГБ и 8 ГБ RAM будет спотыкаться на каждой загрузке.

Когда модель не влезает в VRAM, Ollama не отказывает, а делит слои между картой и процессором — в ollama ps это видно как 62%/38% CPU/GPU. По скорости такой режим близок к чистому CPU: узкое звено обесценивает быструю часть. Увидели гибрид — уменьшайте контекст или берите модель на класс меньше. Что брать под постоянный инференс, разобрано в подборе GPU-сервера под LLM.

И про соседей по машине. Open WebUI в контейнере — ещё 700 МБ–1,5 ГБ сверх модели, а с RAG и реранкером все 2–3 ГБ; замеры — в разборе RAM для Open WebUI. Модель эмбеддингов nomic-embed-text (274 МБ) почти бесплатна, но занимает отдельный слот загрузки: при OLLAMA_MAX_LOADED_MODELS=1 каждый запрос к RAG выгружает основную модель и грузит обратно. Для связки «чат + эмбеддинги» ставьте 2.

Какой сервер взять под Ollama в MAATRIX

Сначала про локацию, потому что для локальной модели логика непривычная. Ollama никуда не ходит по сети: веса лежат у вас, запросы не покидают сервер. Локацию выбирают не по доступности зарубежных API, а по тому, где ваши пользователи и под чью юрисдикцию попадают данные. Лондон (UK) — базовый выбор для большинства: пинг до пользователей в ЕС 15–30 мс, из Москвы 45–60 мс, что для чата с локальной моделью незаметно — генерация занимает секунды, и сетевая задержка теряется на этом фоне. Плюс европейская юрисдикция, если вы обрабатываете данные клиентов из ЕС. Россия нужна в одном случае — персональные данные россиян и 152-ФЗ.

Теперь честно про конфигурации.

Минимум — 8 vCPU / 16 ГБ RAM / 100 ГБ NVMe. Живут модели до 14B в Q4_K_M с контекстом 8k, скорость на 8B — 6–9 токенов в секунду. Для фоновых задач нормально: суммаризация писем, классификация тикетов, локальный RAG. Для живого чата медленно, и притворяться иначе смысла нет — человек читает быстрее, чем такая связка печатает. Диск берите с запасом: три-четыре средние модели — уже 30–40 ГБ.

Комфорт — 16 vCPU / 32 ГБ RAM / 200 ГБ NVMe. Помещается 24–32B, либо 14B с контекстом 32k, либо две модели сразу — чат и кодовая. Запас снимает целый класс проблем: не надо считать KV-кэш и бояться второго пользователя. Конфигурация по умолчанию для команды до десяти человек.

Брать 8 ГБ ради экономии не советуем прямо: формально llama3.1:8b там запускается, но любой шаг в сторону — контекст побольше, второй параллельный запрос, Open WebUI рядом — упирается в потолок. 70B на CPU возможна при 64–96 ГБ, но выдаёт 1,5–2 токена в секунду: это демонстрация, а не рабочий инструмент, и вопрос решается видеокартой, а не оперативной памятью.

Если Ollama вы ещё не ставили, начните с пошагового развёртывания на сервере. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; зарубежная карта для лондонской площадки не нужна. Не уверены в конфигурации — напишите, какая модель, какой контекст и сколько человек, посчитаем требования и подберём без переплаты.

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