Оценка квантованных моделей для развёртывания

Обзорная страница ByteShape для серии из трёх статей о выборе квантованной модели. Начинается она с претензии: модели часто сравнивают по одной удобной цифре - размеру модели, bits per weight, perplexity, дивергенции Кульбака - Лейблера или токенам в секунду. Каждая из этих метрик отвечает на конкретный вопрос, но ни одна не даёт ответа на главный практический вопрос: какую именно модель запускать на вашем железе. Здесь приведён обзор всей серии; сами три части отдельно не обрабатывались, а изложенные аргументы принадлежат ByteShape.

Авторы делят измерения на три категории, которые часто путают между собой. Метрики применимости (fit) - это размер модели, bits per weight и требования к памяти под контекст. Оценки качества (quality) - это бенчмарки на прикладных задачах. Метрики развёртывания (deployment) - реальная скорость генерации токенов на конкретном железе. Метрики применимости отсекают заведомо неподходящие модели, а качество и замеренная пропускная способность определяют, какие из оставшихся имеет смысл использовать на практике.

В первой части вводится различие, на котором строится вся остальная серия: качество на прикладных задачах - не то же самое, что близость к эталонной модели (fidelity). Perplexity и дивергенция Кульбака - Лейблера (KLD) замеряют лишь то, насколько квантованная модель отклонилась от базовой версии в BF16. Ни одна из этих метрик не показывает, правильно ли модель отвечает, следует ли инструкциям и пишет ли рабочий код.

Метрики близости ранжируют не то

Во второй части авторы проверяют это различие на практике. На всей выборке моделей perplexity и KLD действительно кажутся способными предсказать результаты бенчмарков, но ByteShape утверждает, что эту корреляцию обеспечивают исключительно сильно деградировавшие варианты на краю спектра. Среди моделей, близких к исходной (а именно из них и приходится выбирать), полезный сигнал ранжирования исчезает.

Они заявляют, что протестировали 14 вариантов метрик близости, меняя датасет, длину контекста, метод агрегации и ограничение оценки только ответом модели. Результат подтвердился во всех случаях: метрики близости улавливают лишь грубые отклонения от BF16, но не могут надёжно упорядочить модели, близкие к эталону.

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

Bits per weight тоже ранжирует не то

В третьей части аналогичный аргумент приводится для скорости. Размер модели и BPW показывают, поместится ли модель в память, и задают общий тренд, но среди вариантов близкого размера они не позволяют предсказать реальную скорость генерации токенов. Итоговая пропускная способность зависит от формата квантования, формы тензоров и размера групп, поддержки на уровне ядер (kernels), характера обращений к памяти, архитектуры CPU и GPU, нагрузки, длины контекста и реализации движка инференса. Меньшая по размеру модель может работать медленнее более крупной, а формат, выигравший на одном GPU, может уступить на другом устройстве. BPW измеряет лишь затраты на хранение весов.

Серия сводит обе половины воедино графиком рассеяния для RTX 6000, где каждая квантованная модель представлена дважды: незакрашенным кружком на позиции по косвенным метрикам (где меньший KLD предполагает лучшее качество, а меньший BPW - большую скорость) и остриём стрелки на позиции реальных замеров (где оценка в прикладном бенчмарке задаёт ранг качества, а измеренная пропускная способность - ранг скорости). Если бы косвенные метрики отражали реальность развёртывания, точки совпали бы. Вместо этого стрелки оказываются длинными и направлены в разные стороны: вертикальное смещение показывает расхождение KLD с качеством на бенчмарках, горизонтальное - расхождение BPW с реальной пропускной способностью, а некоторые модели сильно сдвигаются по обеим осям. Точный порядок моделей привязан к конкретной видеокарте, но общий вывод неизменен: модель, лидирующая по косвенным метрикам, при развёртывании часто уступает другим.

Практический алгоритм выбора

Сначала отфильтровать по применимости, отсеяв всё, что превышает доступный объём памяти при нужной длине контекста. Протестировать оставшиеся модели на бенчмарках, похожих на целевую задачу. Затем замерить пропускную способность на конкретном движке инференса, целевом железе, нужной длине контекста и реальных параметрах генерации. Итоговый выбор - модель, которая влезает в память, обеспечивает достаточное качество и работает достаточно быстро для вашей задачи.

Связь с остальными заметками о квантовании

В llm-quantization собран каталог форматов и уже зафиксирован вывод о том, что способ сжатия важен не меньше битности: Q4_K_M против UD-Q4_K_XL против MXFP4, где самый свежий и разрекламированный формат вовсе не обязательно выигрывает по perplexity. Вклад ByteShape делает следующий шаг: даже perplexity оказывается плохим критерием для выбора, когда все кандидаты близки к базовой модели. habr-local-llm-quantization-deep-dive показывает ту же реальность глазами практика: флаги выгрузки (offload), прунинг экспертов и выбор сборки движка инференса меняют реальную скорость так, как не предскажет ни одно значение bits per weight. random-rotation-quantization - один из форматов, чьи накладные расходы на метаданные для каждого блока проявились бы на горизонтальной оси того самого графика.

Этот паттерн применим не только к квантованию. В local-ai-is-not-opus описывается та же ошибка, но с лидербордом вместо косвенной метрики: единственная оценка SWE-Bench подменяет собой вопрос развёртывания, не отражая ни нужного языка программирования, ни модели конкурентности. scaffold-model-fit - третий пример: оценка ассистента для написания кода измеряет связку модели и скаффолда, а не саму модель, поэтому результат нельзя перенести на другой harness. Все три случая сводятся к одной ошибке: метрику первичного отсева принимают за основу для ранжирования. Что касается MoE-моделей, в mixture-of-experts объясняется, почему ось применимости вообще перестаёт быть одним числом, ведь общее число параметров и число активных параметров тянут память и вычисления в разные стороны.

Оглавление серии: byteshape.com/blogs/Evaluating-Quantized-Models, опубликовано 2026-07-15.