Какое квантование выбрать для Qwen 2.5

MAATRIX

У qwen2.5:14b в библиотеке Ollama больше двадцати вариантов одного и того же файла — от q2_K на 5,8 ГБ до fp16 на 29,5 ГБ. Разница не только в занятом месте: на одних уровнях модель отвечает как оригинал, на других начинает путаться в числах и выдавать сломанный JSON. Ниже — что означают буквы в имени, сколько теряется на каждом шаге по замерам, как квантование влияет на скорость и какой файл брать под чат, код и вызовы функций.

Как читается имя кванта: Q4_K_M и все остальные

Формат имени — Q<биты>_<семейство>_<вариант>. Семейств три, и они не взаимозаменяемы.

Legacy (Q4_0, Q4_1, Q5_0, Q5_1, Q8_0) — старая схема: блок из 32 весов, один общий множитель. По качеству на бит проигрывает; смысл сохранил только Q8_0, на восьми битах терять уже нечего.

K-кванты (Q2_K, Q3_K_S/M/L, Q4_K_S/M, Q5_K_S/M, Q6_K) — дефолт последних лет: суперблоки по 256 весов, множители сами квантуются, ошибка на тех же четырёх битах заметно меньше. Суффикс — не про биты, а про то, сколько тензоров подняли на уровень выше: _S жмёт всё подряд, _M оставляет часть слоёв в Q6_K, _L добавляет к ним выходную матрицу.

I-кванты (IQ2_XS, IQ3_M, IQ4_XS, IQ4_NL) — кодовые книги плюс матрица важности (imatrix), собранная прогоном калибровочного текста. Качество на бит выше, но распаковка дороже, и на процессоре это стоит скорости. В библиотеке Ollama для qwen2.5 их нет, только на Hugging Face.

Что скачано сейчас, показывает ollama show:

ollama show qwen2.5:14b

  Model
    architecture        qwen2
    parameters          14.8B
    quantization        Q4_K_M

Короткий тег без суффикса всегда даёт Q4_K_M — и qwen2.5, и qwen2.5:32b, и qwen2.5-coder:7b. Дефолт разумный, но именно из-за него половина людей ничего другого не пробовала.

Сколько весит каждый уровень: таблица по размерам Qwen 2.5

Размеры GGUF для Instruct-версий. Последняя колонка — эффективные биты на вес для 14B, размер × 8 / 14,8 млрд: видно, что «Q4» на деле почти пять бит.

Два следствия. Первое: шаг между соседними уровнями — 10–15 %, а не «вдвое». Между Q4_K_S и Q4_K_M у 14B разница 420 МБ, экономить на ней бессмысленно. Второе: у 72B даже Q2_K — это 29,8 ГБ, то есть машина под 32 ГБ. Ни один квант не превращает 72B в модель для дешёвого VPS. Полный расчёт памяти с KV-кэшем — в разборе сколько RAM нужно для Qwen 2.5; здесь только сам файл весов.

Сколько качества теряется: перплексия и KL-дивергенция

Спорить про «на глаз лучше» бессмысленно, когда есть измеримые числа. Прогоняем один и тот же текст через оригинал и через квант:

./llama-perplexity -m Qwen2.5-7B-f16.gguf     -f wiki.test.raw --chunks 200 \
  --kl-divergence-base f16-logits.dat
./llama-perplexity -m Qwen2.5-7B-Q4_K_M.gguf  -f wiki.test.raw --chunks 200 \
  --kl-divergence-base f16-logits.dat --kl-divergence

Первая команда сохраняет логиты эталона, вторая сравнивает с ними квант. Перплексия показывает, насколько модель хуже предсказывает текст; KL-дивергенция честнее — она ловит случаи, когда средняя метрика в порядке, а отдельные токены уехали. Результат по 200 чанкам:

Проценты не универсальны — они зависят от размера модели. У qwen2.5:32b тот же Q3_K_M даёт около +2 %, а Q2_K — примерно +6 % вместо девятнадцати: чем больше параметров, тем больше избыточности и тем спокойнее модель переживает грубое округление. Обратная сторона — на qwen2.5:1.5b и :3b заметен уже Q4_K_M.

И оговорка про метод: wikitext — английский текст общего содержания, по нему квантование выглядит безобиднее, чем оно есть для русского, кода и структурированного вывода. Русский токенизируется длиннее и живёт на менее натоптанных путях, деградация приходит на полшага раньше. Работаете на русском — «рабочий баланс» в таблице для вас уже нижняя граница.

Почему Q4_K_M — это не «четыре бита»: разбор по тензорам

4,86 бита в таблице выше — не ошибка округления. llama.cpp квантует разные тензоры по-разному: основная масса идёт в Q4_K, но выходная матрица output.weight поднимается до Q6_K, туда же уезжает часть тензоров attn_v и ffn_down в начале и конце сети. Именно это отличает _M от _S, и это видно в логе конвертации:

[   1/ 579] token_embd.weight - [ 3584, 152064,  1,  1], type = f16,
            converting to q4_K .. size =  1039.50 MiB ->  292.36 MiB
[ 579/ 579]   output.weight   - [ 3584, 152064,  1,  1], type = f16,
            converting to q6_K .. size =  1039.50 MiB ->  426.38 MiB

Здесь и вылезает специфика Qwen 2.5. Словарь огромный — 151 936 токенов, а у 7B и старше матрица дополнена до 152 064 строк ради делимости при тензорном параллелизме. Для 7B это 3584 × 152064 ≈ 545 млн параметров во входной матрице и столько же в выходной: 1,09 млрд из 7,62 млрд, то есть 14 % модели — это словарь, и в Q4_K_M на два этих тензора уходит 719 МиБ из 4,68 ГБ.

Отсюда три следствия, которых нет у моделей со словарём на 32–50 тысяч токенов:

• Агрессивное сжатие экономит меньше, чем ждёте. Переход Q4_K_M → Q3_K_M у 7B срезает всего 870 МБ: выходная матрица как была Q6_K, так и осталась.
• У 0.5B, 1.5B и 3B эмбеддинги привязаны и занимают до четверти параметров. Жать их ниже Q6_K — менять качество на сотни мегабайт: между qwen2.5:1.5b-instruct-q4_K_M и -q8_0 всего 650 МБ.
• Сторонние сборки с суффиксом _L (Q4_K_L, Q5_K_L) держат token_embd и output в Q8_0: для Qwen это почти гигабайт сверху на 14B, а выигрыш виден на редкой лексике и на русском.

Скорость: квантование ускоряет генерацию, но не всегда

Генерация на процессоре упирается в пропускную способность памяти: на каждый токен читаются все веса, то есть токенов/с ≈ полоса памяти ÷ размер файла. А обработка промпта считается батчем и упирается в арифметику, поэтому от кванта почти не зависит. Замер на 8 vCPU AMD EPYC, DDR4-3200 (~38 ГБ/с по mbw -n 5 1024), Ubuntu 24.04, контекст 8192, ollama run qwen2.5:7b --verbose:

Две строки ломают ожидания. IQ4_XS меньше Q4_K_M на 10 %, но генерирует на 20 % медленнее, а промпт жуёт в полтора раза дольше — распаковка через кодовые книги на процессоре съедает весь выигрыш от размера. Отсюда правило: IQ-кванты нужны на видеокарте, где важно влезть в VRAM, и почти бесполезны на CPU. Вторая строка — q8_0: вдвое медленнее q4_K_M при разнице в 1,3 % перплексии. Скачавший Q8_0 «чтобы получше» меняет полтора процента метрики на удвоение времени ответа.

Отдельный случай — процессоры ARM (Ampere, Graviton): llama.cpp на лету перепаковывает Q4_0 под инструкции i8mm и sdot, и там q4_0 жуёт промпт в 2–3 раза быстрее K-квантов при том же размере. На x86 с AVX2 выигрыша нет, и q4_0 просто хуже q4_K_M. Прочие причины низкой скорости — в разборе Ollama медленно генерирует токены.

Какой квант под какую задачу и как его скачать

Сначала по бюджету памяти: на фиксированном объёме всегда стоит вопрос «модель побольше пожатее или поменьше поточнее».

Общее правило: следующий размер в Q4_K_M почти всегда лучше предыдущего в Q8_0 — но только пока вы не опускаетесь ниже Q4_K_M. На Q3 и Q2 оно переворачивается: qwen2.5:7b-q4_K_M осмысленнее, чем qwen2.5:14b-q3_K_S.

Дальше — поправки по типу задачи:

• Чат и суммаризация на русском — Q4_K_M рабочий минимум, Q5_K_M ровнее в согласованиях и терминах.
• Qwen2.5-Coder — не ниже Q5_K_M: пропущенная скобка ломает файл целиком, тогда как проза ошибку в одном токене переживает. Мелкие Coder-модели для автодополнения в IDE (qwen2.5-coder:1.5b, :3b) берите сразу в Q8_0 — они и так быстрые, а FIM-разметка с токенами <|fim_prefix|>, <|fim_suffix|>, <|fim_middle|> страдает от сжатия первой.
• Вызовы функций и строгий JSON — Q5_K_M. Шаблон tool-calls требует ровных тегов <tool_call> и валидного JSON внутри; на Q3 модель теряет закрывающий тег и путает типы полей, и парсер падает вместо ответа.
• Классификация, роутинг, извлечение полей — тут можно идти вниз смело: короткий выход и жёсткий набор вариантов переживают даже Q3_K_M на 14B.

Качается уровень полным тегом, и регистр в нём имеет значение — Ollama имена не нормализует:

$ ollama pull qwen2.5:14b-instruct-q4_k_m
Error: pull model manifest: file does not exist

Правильно q5_K_M: q и цифры строчные, буквы семейства и варианта заглавные. I-квантов и _L-сборок в библиотеке Ollama нет, за ними идут на Hugging Face: ollama run hf.co/bartowski/Qwen2.5-14B-Instruct-GGUF:IQ4_XS. Переквантовать скачанный файл не выйдет — Ollama сжимает только из fp16/fp32 и отвечает Error: quantization is only supported for F16 and F32 models, так что «скачал Q8_0, сожму сам» требует сперва выкачать 29,5 ГБ fp16.

На видеокарте формат другой: у Qwen есть официальные сборки -AWQ и -GPTQ-Int4/Int8 под vLLM, GGUF там не нужен. Известная грабля — Qwen2.5-72B-Instruct-GPTQ-Int4 не стартует с --tensor-parallel-size 8: размер 29568 не делится на 8 групп по 128, и vLLM падает с ValueError: The input size is not aligned with the quantized weight shape. Ставьте 4 или 2. Про железо — в выборе GPU-сервера под инференс LLM.

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

Выбор кванта и выбор тарифа — одна задача с двух сторон. Есть сервер — квант берётся из таблицы выше. Есть требование к качеству — считаем обратно: файл нужного уровня плюс 10 % на буферы, плюс KV-кэш под контекст, плюс 1,5 ГБ системе.

Минимум — 4 vCPU / 8 ГБ RAM / 80 ГБ NVMe. Это qwen2.5:7b-instruct-q4_K_M, контекст 8k, около 7 токенов в секунду. Честное ограничение: подняться до Q5_K_M здесь уже нельзя — 5,44 ГБ весов плюс кэш плюс система упрутся в потолок, и первый длинный диалог закончится убитым по OOM процессом. Восемь гигабайт — ровно один квант, без права на эксперимент.

Комфортный вариант — 8 vCPU / 16 ГБ RAM / 160 ГБ NVMe. Здесь появляется собственно выбор: 14b-q4_K_M для связного русского текста, 7b-q6_K для кода и вызовов функций, 7b-q5_K_M с контекстом 32k под RAG. Два-три кванта лежат рядом, и сравнивать можно на своих задачах, а не на чужих таблицах. Про диск не забудьте: 7B в пяти квантах — это 27 ГБ в /usr/share/ollama/.ollama/models, а под 32B в Q6_K с парой запасных вариантов разумный минимум — 320 ГБ.

Локация — Лондон (UK). Сетевая задержка локальной модели безразлична: веса лежат у вас, наружу ничего не ходит. Важно, откуда вы качаете. Hugging Face из России отвечает нестабильно, и попытка вытащить IQ-квант или _L-сборку регулярно заканчивается так:

Error: pull model manifest: Get "https://huggingface.co/v2/bartowski/...":
dial tcp: i/o timeout

С европейской площадки этого нет, а 9-гигабайтный файл по гигабитному каналу приезжает за полторы минуты. Лондон даёт заодно 15–30 мс до пользователей в ЕС и европейскую юрисдикцию, если через модель проходят клиентские данные. Российская площадка нужна в одном случае — персональные данные россиян и 152-ФЗ.

Ollama из каталога apps.maatrix.io ставится автоматически при заказе — вставлять команды не нужно, автоустановка работает на Ubuntu и Debian. Доступы появляются в личном кабинете, в разделе «Доступ»; дальше остаётся один ollama pull с нужным тегом. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT. Не уверены в уровне — напишите задачу, язык и контекст: подберём связку «размер + квант + тариф» без переплаты. Установка по шагам — в статье как запустить Qwen 2.5 на VPS.

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