Сколько RAM нужно для Qwen 2.5

MAATRIX

«Qwen 2.5 7B» звучит как четыре с половиной гигабайта, и на этом расчёт обычно заканчивается. Потом выясняется, что контекст 32k добавляет ещё почти два, 14B по памяти дороже 7B не вдвое, а втрое, а обещанные 128k из коробки вообще не включены. Ниже — требования Qwen 2.5 к RAM по всем семи размерам, точная арифметика KV-кэша и честные границы конфигураций.

Короткий ответ: сколько RAM требует Qwen 2.5

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

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

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

Ориентиры при квантовании Q4_K_M, контексте 8192 токенов и одном пользователе:

• 4 ГБ — qwen2.5:1.5b и qwen2.5:3b, задачи вроде классификации и автодополнения;
• 8 ГБ — qwen2.5:7b, рабочий минимум для осмысленного чата;
• 16 ГБ — qwen2.5:14b либо 7B с контекстом 32k;
• 32 ГБ — qwen2.5:32b с коротким контекстом;
• 64 ГБ — qwen2.5:72b, влезет, но скорость расстроит.

Речь про инференс на процессоре. С видеокартой лимитом становится VRAM, цифры те же.

Таблица RAM по всем размерам Qwen 2.5

Колонка «вес» — размер GGUF в Q4_K_M, то есть то, что скачивает ollama pull qwen2.5:14b без суффиксов. Минимум посчитан по формуле выше при контексте 8k, комфорт — при 32k.

Две нижние строки требуют оговорки. У qwen2.5:32b расчётный минимум — 25,5 ГБ, но тарифов на 26 ГБ не бывает, а 32 ГБ при контексте 32k заканчиваются впритык: 22 + 8 + 1,5 = 31,5 ГБ. У qwen2.5:72b — 55,7 ГБ, и на 64 ГБ модель живёт только с контекстом 8k.

Qwen2.5-Coder — те же цифры. Кодовая версия отличается обучением, а не архитектурой: qwen2.5-coder:7b весит те же 4,7 ГБ. Разница только в наборе размеров — у Coder нет 72B, максимум 32B.

Q8_0 удваивает вес относительно Q4_K_M, fp16 — учетверяет: 14B в fp16 (29,5 ГБ) просит сервер уровня 32B. Подробнее — в разборе про выбор квантования для Qwen 2.5.

Откуда берётся KV-кэш Qwen 2.5: GQA и точный расчёт

Все размеры Qwen 2.5 используют grouped-query attention, но с очень разным числом KV-голов — отсюда и непропорциональный рост памяти.

Формула, из которой они получены:

KV = 2 × слои × KV-головы × head_dim × токены × 2 байта

Для qwen2.5:14b: 2 × 48 × 8 × 128 × 8192 × 2 = 1 610 612 736 байт, ровно 1,5 ГиБ на 8k контекста.

Отсюда неочевидный вывод: переход с 7B на 14B удваивает веса, но утраивает кэш. У 7B четыре KV-головы на 28 слоёв, у 14B — восемь на 48, разница 3,4 раза. На 8k незаметно, на 32k — 4,25 лишних гигабайта, и 16 ГБ, взятые «под 14B, ведь веса всего девять», кончаются.

Брать на веру не надо — Ollama отдаёт их из GGUF-метаданных:

curl -s http://127.0.0.1:11434/api/show -d '{"model":"qwen2.5:14b"}' \
  | jq '.model_info | with_entries(select(.key | startswith("qwen2")))'

{
  "qwen2.block_count": 48,
  "qwen2.attention.head_count": 40,
  "qwen2.attention.head_count_kv": 8,
  "qwen2.context_length": 32768,
  "qwen2.embedding_length": 5120
}

head_dim в метаданных нет: считается как embedding_length / head_count, здесь 5120 / 40 = 128. Три числа в формулу — и у вас точный расход под свой контекст.

Контекст 128k у Qwen 2.5: чего стоит длинное окно

В карточке модели написано «128K context», и это половина правды. Родной контекст Qwen 2.5 — 32 768 токенов, что видно в поле qwen2.context_length выше. Расширение до 131 072 работает через YaRN и требует ручной правки: в config.json добавляется блок rope_scaling с "factor": 4.0 и "original_max_position_embeddings": 32768. В GGUF из библиотеки Ollama этого нет — num_ctx больше 32768 даст либо обрезку, либо бессвязный текст после 32 тысяч токенов.

Второй аргумент против длинного окна — цена в гигабайтах:

Для 14B стотысячный контекст стоит 24 ГБ — почти втрое дороже самих весов. Вдобавок YaRN у Qwen 2.5 включается статически и слегка портит качество на коротких запросах: авторы прямо советуют не включать его, пока вы не работаете с длинными документами.

Три вещи, которые режут кэш почти без потерь:

• Реальный контекст вместо максимального. Environment="OLLAMA_CONTEXT_LENGTH=8192" через systemctl edit ollama. По умолчанию Ollama берёт 4096, но клиенты присылают своё значение в options.num_ctx: Open WebUI подставляет настройку из профиля модели и перебивает переменную окружения.
• Квантование самого кэша. OLLAMA_FLASH_ATTENTION=1 вместе с OLLAMA_KV_CACHE_TYPE=q8_0 уменьшает кэш вдвое: для 14B на 32k это 3 ГБ вместо 6. Без флеш-аттеншена вторая переменная молча игнорируется.
• Один слот параллелизма. OLLAMA_NUM_PARALLEL=1 — иначе кэш умножается на число слотов, и заявленные 1,5 ГБ превращаются в 6.

Что специфично именно для Qwen 2.5: словарь, мелкие модели и лицензии

Словарь на 151 936 токенов — заметно больше, чем у ровесников, и это даёт два эффекта. Первый — вычислительный буфер: слой логитов при батче 512 занимает 512 × 151936 × 4 байта, и в логе llama.cpp появляется CPU compute buffer size = 304.00 MiB там, где вы ожидали десятки мегабайт. Для 7B это 6 % от весов, ерунда; для qwen2.5:0.5b — почти столько же, сколько сама модель.

Второй эффект интереснее. У размеров 0.5B, 1.5B и 3B матрица эмбеддингов привязана (tied embeddings) и занимает непропорционально большую долю параметров: у 0.5B это 151 936 × 896 ≈ 136 млн из 494 млн, то есть 27 % модели. Квантование сжимает её хуже остальных тензоров, поэтому qwen2.5:0.5b в Q4_K_M весит 398 МБ, а не «четверть от 0,5B». Вывод: на мелких Qwen выгода от агрессивного квантования почти нулевая, а качество проседает резко — берите их в Q8_0, разница всего 200–400 МБ.

Честно про мелкие размеры. qwen2.5:0.5b и qwen2.5:1.5b запустятся на любом VPS с 2 ГБ, но осмысленного диалога не дадут. Их ниша — классификация тикетов, извлечение полей, роутинг, автодополнение. Для чата на русском нижняя планка — 7B; 3B путается в согласованиях уже на втором-третьем ходу.

Лицензии различаются по размерам. Qwen2.5-0.5B, 1.5B, 7B, 14B и 32B выпущены под Apache 2.0. А вот 3B живёт под Qwen Research License и коммерческое использование не разрешает, 72B — под отдельной Qwen License. Самый выгодный по памяти размер оказывается непригоден для продукта: брали 3B ради экономии — для коммерческого проекта придётся взять 7B и 8 ГБ вместо 4.

Как проверить свои цифры и что делать при нехватке

Скорость на CPU упирается не в частоту ядер, а в пропускную способность памяти: на каждый токен процессор читает все веса модели. Отсюда потолок:

токенов/с ≈ пропускная способность памяти ÷ размер весов

Свою полосу измерьте так: apt install mbw, затем mbw -n 5 1024 и строка AVG Method: MEMCPY. Замер на 16 vCPU / 64 ГБ, DDR4-3200, Ubuntu 24.04, контекст 8k:

Практический смысл: ядра сверх 8–16 почти ничего не дадут, а полосу вы получаете вместе с объёмом памяти. Подробнее про упирающуюся генерацию — в разборе медленной работы Ollama.

Три типичных отказа. Первый — llama.cpp не смог выделить буфер под веса:

ggml_backend_cpu_buffer_type_alloc_buffer: failed to allocate buffer of size 20401483776
llama_model_load: error loading model: unable to allocate backend buffer
Error: llama runner process has terminated: error loading model

Второй — ядро убило процесс при загрузке, и systemd крутит его по кругу:

systemctl status ollama
   Active: activating (auto-restart) (Result: signal)
  Process: 41207 ExecStart=/usr/local/bin/ollama serve (code=killed, signal=KILL)

Подтвердить: dmesg -T | grep -i oom_reaper. Третий — у тех, кто запускает Qwen 2.5 через vLLM на видеокарте: там кэш выделяется заранее.

ValueError: The model's max seq len (32768) is larger than the maximum number
of tokens that can be stored in KV cache (13872). Try increasing
`gpu_memory_utilization` or decreasing `max_model_len`.

Лечится флагом --max-model-len 8192, а не покупкой карты. Остальные симптомы разобраны в частых ошибках Qwen 2.5 на сервере.

Порядок действий, от дешёвого к дорогому: снизить num_ctx до нужного; включить OLLAMA_FLASH_ATTENTION=1 с OLLAMA_KV_CACHE_TYPE=q8_0; выставить OLLAMA_MAX_LOADED_MODELS=1; взять размер поменьше — qwen2.5:7b в Q4_K_M почти всегда полезнее, чем qwen2.5:14b в Q3_K_S. И только потом добавлять память. Своп не спасёт: он страхует от падения при загрузке, но в работе превращает 7 tok/s в доли токена.

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

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

Минимум — 4 vCPU / 8 ГБ RAM / 80 ГБ NVMe. Это qwen2.5:7b в Q4_K_M с контекстом 8k и 5–7 токенами в секунду. Нормально для фоновых задач: разбор писем, суммаризация, классификация. Для живого чата медленно — человек читает быстрее, чем такая связка печатает, и делать вид, что это не так, бессмысленно. Диск берите с запасом: 7B и 14B рядом — уже 14 ГБ.

Комфорт — 8 vCPU / 16 ГБ RAM / 160 ГБ NVMe. Помещается qwen2.5:14b с контекстом 8k либо qwen2.5:7b с контекстом 32k и Open WebUI рядом. На этой конфигурации Qwen 2.5 перестаёт быть демонстрацией: запас снимает нужду считать KV-кэш и бояться второго пользователя.

Под qwen2.5:32b — 16 vCPU / 48 ГБ RAM. Формально хватит и 32 ГБ, но только с контекстом 8k. Скорость 1,5–2 tok/s означает пакетную обработку ночью, а не интерактив. qwen2.5:72b на CPU возможна при 96 ГБ и выдаёт около 0,6 tok/s: это проверка гипотезы, а не рабочий инструмент. Задача решается видеокартой — что брать, разобрано в подборе GPU-сервера под инференс LLM.

Ollama из каталога apps.maatrix.io ставится на сервер автоматически при заказе — вставлять команды не нужно, автоустановка работает на Ubuntu и Debian. Доступы появляются в личном кабинете, раздел «Доступ»; дальше остаётся ollama pull qwen2.5:14b и правка переменных под ваш контекст. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT; зарубежная карта для Лондона не нужна. Не уверены в размере — напишите задачу, контекст и число пользователей, посчитаем без переплаты. Требования по остальным моделям — в таблице RAM для Ollama.

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