Форматы квантования LLM

Квантование сжимает веса модели из 16-битных чисел с плавающей точкой в числа более низкой точности - обычно 4-битные. Потребление памяти падает в 4 раза, а на поддерживающем оборудовании пропускная способность может вырасти пропорционально. Подвох в том, что метод сжатия важен не меньше разрядности, а формат с самой громкой рекламой далеко не всегда выигрывает по перплексии.

Три формата из тестов Вячеслава

Q4_K_M - устоявшийся базовый уровень

Стандартный формат GGUF. Веса группируются в блоки по 256 элементов, каждый блок хранит собственный масштаб и смещение. Критичные к точности тензоры (attention) остаются 6-битными, всё остальное ужимается до 4 бит. Калибровочные данные не требуются. Этот формат используют сборки GGUF от bartowski, и он предсказуемо работает на любых архитектурах.

UD-Q4_K_XL - Unsloth Dynamic 2.0

Более новый и якобы более умный подход. Перед квантованием Unsloth прогоняет через модель от 300 тысяч до 1.5 миллиона токенов реальных диалогов и измеряет чувствительность каждого слоя. Чувствительные слои остаются в 8 или 16 битах, а остальные более агрессивно ужимаются до 4 бит. Заявленное преимущество: "калиброванное, основанное на данных, более высокое качество при той же средней разрядности".

MXFP4 - нативный для Blackwell 4-битный формат с плавающей точкой

4-битный формат с плавающей точкой (знак + короткая экспонента + мантисса) вместо целочисленного. Веса группируются в блоки с общей экспонентой. Тензорные ядра Nvidia Blackwell поддерживают MXFP4 нативно - никакой эмуляции, прямое аппаратное сопоставление. Этот формат используется в GGUF для Gemma 4 и работает как задумывалось.

Где Dynamic 2.0 даёт сбой

Интуиция "новее - значит лучше" ломается на Qwen MoE. Замеры перплексии Вячеслава на WikiText-2:

Ради экономии всего 1 GB на диске Dynamic 2.0 даёт почти пятикратный рост потерь в качестве. Консенсус сообщества, на который ссылается Вячеслав, заключается в том, что кванты от Unsloth работают хуже именно на MoE-архитектурах с чувствительной динамикой роутера: агрессивные 4-битные слои искажают решения о маршрутизации, и на длинных последовательностях эта ошибка накапливается.

Позже сами Unsloth убрали слои MXFP4 из своих GGUF для Qwen (Q2_K_XL, Q3_K_XL, Q4_K_XL) после сообщений о вычислительных аномалиях. Так один из ключевых элементов Dynamic 2.0 оказался несовместим с главным семейством локальных MoE. А Q4_K_M продолжил нормально работать.

Практический вывод

Не стоит выбирать квант по списку возможностей или заявлениям разработчиков. Проверяйте показатели перплексии для конкретной архитектуры модели, которую запускаете. Их сочетание значит больше, чем формат сам по себе.

Другое измерение, другой ответ

Подробный разбор Вячеслава измеряет те же кванты Qwen 3.6 35B-A3B не по перплексии на WikiText-2, а по KLD относительно эталона BF16, и получает обратный результат:

• UD-Q4_K_XL превосходит Q4_K_M (UD-Q4_K_XL на 1.2 GB больше)
• Q4_K_M ≈ UD-Q3_K_XL (динамический Q3 на 4.4 GB меньше при том же KLD)
• UD-Q2_K_XL превосходит IQ2_M при том же объёме памяти

KLD относительно BF16 - более свежее и специфичное для архитектуры измерение; более ранняя цифра перплексии получена до появления базового уровня BF16, под который проектируются новые кванты. Вывод становится ещё чётче: важна метрика, важен автор квантования, важна архитектура, важна версия модели. Не выбирайте квант по названию. Найдите замеры, сравнивающие кандидатов с эталонной точностью именно на той модели, которую вы собираетесь запускать.

evaluating-quantized-models развивает эту тему дальше. Вывод ByteShape состоит в том, что как только все оставшиеся кандидаты оказываются близки к эталону, перплексия и KLD вообще перестают их ранжировать - они выявляют лишь грубые отклонения, но не тонкие различия. К тому же число бит на вес никак не предсказывает реальную скорость. Решающими факторами остаются прикладной бенчмарк на задачах, похожих на ваши, и замер пропускной способности на том железе и движке инференса, которые вы реально будете использовать.

За рамками стандартных квантов

Ещё две ветки квантования, о которых стоит знать:

Кванты IQK (ik_llama). Форк от ikawrakow предлагает SOTA-кванты, которых нет в основном репозитории llama.cpp. IQ4_KS на Qwen 3.5 показывает примерно в 3 раза лучший KLD, чем Q4_K_M, при том же размере на диске и сравнивается по качеству с UD-Q4_K_XL, занимая примерно на 1 GB меньше. См. ik-llama-cpp и сущность unsloth об альтернативных создателях динамических квантов.

TurboQuant (KV-кэш). Сжатие KV-кэша по схеме "поворот, затем квантование", позволяющее получить 2-4 бита на координату с точностью поиска NiaH уровня полной точности (четырёхкратное сжатие). Стандартный llama.cpp поставляется с KV-кэшем q4_0/q8_0/f16; TurboQuant превосходит их по качеству при том же расходе памяти. См. random-rotation-quantization и interactive-turboquant.

Почему I-кванты могут быть медленнее K-квантов. Когда квант Q3 собран с блоками I-квантов, а модель выгружена на процессор через -cmoe, деквантование блоков I-квантов требует примерно в 2 раза больше ресурсов CPU, чем у K-квантов. Более крупная модель Q4_K_M может работать быстрее компактной UD-Q3_K_XL, если узким местом становятся экспертные слои на CPU. Когда производительность упирается в процессор, тип кванта важнее его размера. Подробный пример разобран в habr-local-llm-quantization-deep-dive.

Ссылки

• mixture-of-experts - объясняет, почему MoE необычайно чувствительны к квантованию отдельных слоёв
• local-llm-16gb-vram-tests - контекст, в котором сравнивались эти кванты (по метрике перплексии)
• habr-local-llm-quantization-deep-dive - замеры Вячеслава на основе KLD и история вокруг BF16
• lucumr-local-models - тезис Ронахера о том, что выбор квантования - одно из нескольких неочевидных решений, незаметно ухудшающих локальные модели
• bf16-vs-fp16 - эталон точности, с которым сравниваются современные кванты
• random-rotation-quantization - конкретно про KV-кэш: семейство алгоритмов "поворот, затем квантование"
• ik-llama-cpp - форк от ikawrakow с SOTA-квантами IQK
• unsloth - самый известный создатель квантов UD-Q*-XL
• glm52-amd-mi355x - MXFP4, измеренный на AMD вместо Blackwell, с опубликованными дельтами GSM8K/GPQA/tau2 относительно эталона FP8; заявление о "сжатии без потерь" принадлежит вендору и не укладывается в его же планки погрешностей
• deltafin - квантование как решение в области ввода-вывода, а не арифметики; на DGX Spark остов в int8 дал выигрыш ~4× от начала до конца вместо ожидаемых ~2× от двукратного сокращения байтов, поскольку освободил место под кэш страниц экспертов
• neutrino-1-8b - другое направление: кодированный формат тернарного семейства с размером в одну восьмую от fp16, декодируемый прямо внутри матричных ядер и никогда не материализуемый целиком