Квантование моделей Q4, Q5, Q8: что выбрать

MAATRIX

Модель на 7 млрд параметров в исходной точности (FP16) весит около 15 ГБ и не влезает ни в бытовую видеокарту, ни в дешёвый VPS. Квантование моделей ужимает вес в несколько раз, но одинаковая на вид метка «Q4» у разных файлов на Hugging Face означает разный размер и разное качество. Разберём, что на самом деле стоит за Q4, Q5 и Q8 в именах GGUF-файлов, как посчитать нужную память и какой уровень брать для чата, кода и агентов — с командами Ollama и нашими собственными замерами на CPU.

Что означают Q4, Q5 и Q8 в имени GGUF-файла

Веса модели после обучения — десятки миллиардов чисел, обычно 16-битных (FP16 или BF16); квантование хранит их меньшим числом бит. Формат для локального запуска — GGUF, его понимает llama.cpp и, соответственно, Ollama. Буква и цифра после Q — конкретная схема упаковки со своей арифметикой, а не ярлык.

Первое поколение — «legacy»: Q4_0, Q4_1, Q5_0, Q5_1, Q8_0. Блок из 32 весов ужимается до N бит плюс общий масштаб (scale) на блок в FP16 — реальный размер честнее заявленного числа: Q4_0 — (32 × 4 + 16) / 32 = 4,5 бита на вес, Q8_0 — (32 × 8 + 16) / 32 = 8,5 бита.

Второе поколение — K-кванты: Q3_K, Q4_K, Q5_K, Q6_K, у младших ещё суффикс _S, _M или _L. Часть тензоров — обычно матрицы внимания и feed-forward — хранится точнее заявленной цифры, остальное грубее. Суффикс — не про битность, а про то, сколько тензоров подняли выше: _S жмёт почти всё подряд, _M оставляет часть слоёв точнее, _L добавляет выходную матрицу. По документации проекта эффективная точность: Q3_K_M — около 3,9 бита на вес, Q4_K_S — около 4,6, Q4_K_M — около 4,8, Q5_K_M — около 5,7, Q6_K — около 6,6.

Третье поколение — IQ-кванты (IQ2_XXS, IQ3_S, IQ4_XS): кодовые книги плюс матрица важности (imatrix) вместо простого масштаба. Меньший размер при сопоставимом качестве, но дороже распаковка на CPU — см. раздел про нюансы.

Разница между Q4_0 и Q4_K_M в названии незаметна, а в размере и качестве — есть. Дальше по тексту цифра после Q без буквы K — почти всегда устаревшая схема; берут её редко, кроме отдельных случаев с процессорами ARM, о которых ниже.

Почему «бери максимум, что влезет» — плохой критерий

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

Первая причина уже разобрана: Q4_0 и Q4_K_M называются одинаково, но это разные схемы с разной эффективной битностью. Сравнивать «Q4 против Q4» без буквы K — сравнивать не то с не тем.

Вторая причина — не вся модель одинаково чувствительна к урезанию: в _M/_L часть тензоров сознательно хранится точнее остальных, поэтому грубая упаковка всего на восьми битах иногда проигрывает продуманной смеси на четырёх-пяти при меньшем файле.

Третья причина — убывающая отдача: шаг от Q4_K_M к Q8_0 почти удваивает объём, а прирост точности для диалога и суммаризации на глаз почти не заметен. Для агентов и кода та же малая доля ошибок концентрируется там, где цена высока — лишняя скобка, а не стиль ответа. Дело не в «побольше», а в уровне под задачу — разберём в разделе сравнения.

Четвёртая причина — доверие к метке без проверки источника: imatrix (см. следующий раздел) считается на калибровочном тексте, и один и тот же Q4_K_M от двух авторов может вести себя не одинаково.

И банальная опечатка в теге — Ollama на несуществующий тег отвечает сухо:

Error: pull model manifest: file does not exist

Это не значит, что квант не поддерживается — чаще опечатка или квант, которого автор не выложил. Смотрите список тегов на странице модели, а не подбирайте вслепую.

Как выбрать и переключить квант в Ollama: команды

Если Ollama на сервере ещё нет — базовая установка и первый запуск разобраны отдельно, здесь только про выбор и проверку кванта.

Дефолтный ollama pull qwen2.5:7b тянет квант по умолчанию — обычно Q4_K_M, но не всегда, и без проверки вы не знаете наверняка, что запустили. Явный выбор — через суффикс тега:

ollama pull qwen2.5:7b-instruct-q5_K_M

Проверить, что реально скачалось, — ollama show:

ollama show qwen2.5:7b-instruct-q5_K_M

В выводе блок с архитектурой, где явно указан уровень:

  Model
    architecture        qwen2
    parameters           7.6B
    context length       32768
    quantization          Q5_K_M

Сравнить размеры уже скачанных вариантов — ollama list со столбцом SIZE; если число сильно расходится с расчётом из раздела про память, стоит перепроверить, что скачали именно то, что думаете.

Собственный или скачанный напрямую с Hugging Face GGUF заводится через Modelfile:

FROM ./qwen2.5-7b-instruct-q5_k_m.gguf
PARAMETER num_ctx 8192

ollama create qwen-q5-custom -f Modelfile

Проверить, куда физически легла модель и сколько памяти занимает работающий процесс, — ollama ps:

NAME                          ID              SIZE      PROCESSOR    UNTIL
qwen2.5:7b-instruct-q5_K_M    a1b2c3d4e5f6    5.3 GB    100% CPU     4 minutes from now

Столбец PROCESSOR показывает, влезла ли модель целиком в видеопамять или часть слоёв ушла на CPU — например, «46%/54% CPU/GPU» при частичном оффлоаде.

Где физически лежат блобы моделей: сервис на Linux работает от пользователя ollama, путь по умолчанию — /usr/share/ollama/.ollama/models. Перенести на отдельный NVMe-раздел — переменной окружения через drop-in юнита:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_MODELS=/data/ollama-models"

sudo systemctl daemon-reload && sudo systemctl restart ollama

Нюансы: imatrix, KV-кэш и где квантование ломается

Матрица важности (imatrix) — отдельный слой качества, не связанный со схемой сжатия: калибровочный проход по тексту перед квантованием. llama-imatrix считает, какие веса сильнее влияют на выход, а llama-quantize с флагом --imatrix распределяет биты с оглядкой на эту статистику. Для средних K-квантов разница на глаз небольшая, а для самых мелких (Q2_K, весь ряд IQ) imatrix — уже не бонус, а необходимость: без калибровки такие файлы иногда съезжают в повторы на нетипичных промптах.

Второй частый пробел — KV-кэш контекста, который живёт отдельно от весов и в сравнение квантов обычно не попадает. Для длинного диалога кэш способен сравняться по объёму с весами модели. Ollama умеет квантовать и его: OLLAMA_KV_CACHE_TYPE=q8_0 (или q4_0) при включённом OLLAMA_FLASH_ATTENTION=1 сокращает память под кэш в разы — возможность экспериментальная, проверяйте ollama --version.

Честно про предел агрессивного сжатия: Q2_K и нижняя часть IQ-ряда держат связную речь, но ненадёжны там, где нужна точность в каждом токене — валидный JSON, имена параметров функции, арифметика в несколько шагов. Ошибка не выглядит как явный сбой — модель просто путает деталь, и в пайплайне молча ломает парсер. Для чата агрессивное сжатие обычно допустимо, для кода и агентов — нет.

Отдельная оговорка про CPU без ускорителя: на процессорах без специфичных инструкций (не ARM с i8mm/sdot) выигрыш IQ-серии в размере иногда съедается более медленной распаковкой — меньшая цифра не гарантирует более быстрый ответ.

Сколько памяти нужно и как это связано со скоростью

Порядок размера файла весов считается напрямую: параметры (млрд) × эффективные биты / 8 = гигабайты, плюс 3–8% на тензоры, которые в лёгких квантах держат точнее остальных (эмбеддинги, выходной слой, нормализация). Точный расчёт по моделям и размерам — в таблице RAM для Ollama, здесь — механика и наши измерения.

Наши цифры с одного стенда: AMD EPYC 9554, 16 vCPU (8 физических ядер + HT), DDR5, Ollama 0.33.1, короткий контекст. Резидентная память по ollama ps в Q4_K_M: qwen2.5:3b — 2,2 ГБ, mistral:7b — 5,0 ГБ, qwen2.5:7b — 5,1 ГБ, llama3.1:8b — 5,6 ГБ. Mistral:7b и qwen2.5:7b одного класса по параметрам, а разница в памяти всё равно есть — это не про квант, а про архитектуру. При 16 потоках генерация: llama3.1:8b — 12,8 ток/с, mistral:7b — 12,1, gemma2:9b — 8,8, qwen2.5:3b — 34,1. Разрыв между 7–9B моделями не пропорционален разнице в параметрах.

Механика связи размера и скорости простая: генерация на CPU почти всегда упирается не в арифметику, а в пропускную способность памяти — каждый токен требует заново прочитать все веса. Чем меньше файл, тем меньше данных гонять через память на токен, поэтому более лёгкий квант почти всегда даёт более быструю генерацию на одном железе. Добавление потоков сверх нескольких физических ядер не помогает, а на избытке даже вредит — подробности в статье про ядра CPU у Ollama.

Q4 против Q5 против Q8: сравнение и честный вывод

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

Для ориентира: qwen2.5:7b в Q4_K_M у нас резидентно занимает 5,1 ГБ (раздел выше) — от этой цифры считайте пропорции для своей модели.

Честный вывод, кому что подходит:

• Общий ассистент, чат, суммаризация — Q4_K_M. Разумный дефолт: более чем втрое легче F16 при разнице, незаметной в диалоге.
• Код, агенты, строгий JSON — не ниже Q5_K_M, лучше Q6_K. Редкие ошибки квантования дорого стоят: лишняя скобка ломает парсер.
• Сравнение моделей друг с другом, эффект дообучения — F16 или Q8_0 как эталон, иначе непонятно, где источник расхождения.
• Совсем тесная память — Q3_K_M с оговоркой: прогоните 5–10 промптов из вашей задачи, прежде чем полагаться на такой квант в проде. Разбор по семействам моделей — например, для Qwen 2.5.

Правило важнее любой строки таблицы: не переносите чужой опыт на свою модель и задачу — 10 минут на своих тестовых промптах скажут больше любого готового сравнения.

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

Ollama есть в каталоге приложений MAATRIX и ставится автоматически при заказе — на Ubuntu и Debian доступ к API на порту 11434 появляется в кабинете сразу после разворачивания. Дальше — только ollama pull с нужным тегом кванта.

Честный минимум: 4 vCPU, 8 ГБ RAM, 60 ГБ NVMe. Модель уровня 7B в Q4_K_M занимает в памяти около 5 ГБ, плюс система — укладывается с небольшим запасом для одной модели. Ограничение прямо: сравнивать кванты здесь тесно — переход на Q5_K_M заберёт большую часть запаса, а держать рядом ещё Q8_0 не выйдет. Контекст 16–32 тысячи токенов без запаса под KV-кэш — либо явная ошибка заранее, либо процесс, завершённый ядром по нехватке памяти.

Комфортный вариант: 8 vCPU, 16–32 ГБ RAM, 120–160 ГБ NVMe. Помещается то, ради чего написана статья, — два-три кванта одной модели одновременно, чтобы сравнивать на своих промптах, а не по чужим таблицам. Диск с запасом: 7B в трёх-четырёх квантах — уже 15–20 ГБ, с парой запасных моделей разумный минимум — 120 ГБ.

Локация — Великобритания (Лондон). Модели с Hugging Face — файлы по несколько гигабайт на каждый квант, и маршрут до европейских CDN из Лондона короче большинства альтернатив. Для сервиса с клиентами в ЕС лондонский узел ближе по сети и привычнее по юрисдикции, чем американский или российский. Если Ollama — внутренний инструмент команды с аудиторией в России, разница в задержке некритична: это фоновая генерация, а не потоковый инференс с жёстким лимитом по времени первого токена.

Оплата — картой российского банка, по СБП, криптовалютой или токеном MAAT; загранкарта не нужна, хотя сервер физически в Лондоне. Если нужен полноценный llama.cpp для своих IQ-квантов с imatrix — это уже не из каталога: сервер приходит чистым, llama-quantize и llama-imatrix собираются из исходников самостоятельно.

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