Суть
Все три распространённых алгоритма решают одну задачу — уложить веса в меньшее число бит с наименьшей потерей качества, — но расходятся в том, что именно они защищают от огрубления, и в том, где потом запускаются.
Общий контекст: квантование применяется после обучения (post-training), то есть не требует ни данных, ни переобучения, только небольшую калибровочную выборку.
Три алгоритма
| Алгоритм | Принцип | Особенности | Среда исполнения |
|---|---|---|---|
| AWQ | Защита примерно 1% «весов-выбросов», отобранных по магнитуде активаций | Минимальная деградация перплексии | vLLM, SGLang, TensorRT-LLM |
| GPTQ | Послойная оптимизация через матрицу Гессиана | Точная минимизация квадратичной ошибки, дольше калибровка | vLLM, AutoGPTQ, ExLlamaV2 |
| GGUF (k-quants) | Блочное квантование с индивидуальными шкалами | Поддержка выгрузки части слоёв в оперативную память CPU | Локальный инференс: llama.cpp, Ollama |
Идея AWQ разворачивается в одно наблюдение: не все веса одинаково важны, и небольшая доля, влияющая на активации сильнее прочих, сохраняется в высокой точности. Остальные огрубляются агрессивно. Отсюда же его практическое преимущество: метод не использует ни обратное распространение, ни реконструкцию выхода, поэтому не подстраивается под калибровочную выборку и переносится на другие домены без потери качества. GPTQ идёт другим путём — не выделяет привилегированные веса, а послойно подбирает квантованные значения так, чтобы минимизировать ошибку выхода слоя.
GGUF стоит особняком: он оптимизирован не под максимум качества, а под запуск там, где видеопамяти не хватает вовсе, и умеет держать часть слоёв в оперативной памяти.
Что это даёт в цифрах
Байт на параметр по точностям (LLM Sizing):
| Точность | Байт на параметр |
|---|---|
| FP32 | 4 |
| FP16 / BF16 | 2 |
| FP8 / INT8 | 1 |
| INT4 (AWQ/GPTQ) | ≈ 0,55 |
Значение 0,55 вместо 0,5 — плата за служебные данные: масштабные коэффициенты и точки нуля хранятся рядом с самими четырёхбитными весами.
Переход на INT4/FP8 снижает бюджет видеопамяти на 50–70% относительно FP16 — с учётом того, что уменьшаются только веса, а KV-кэш остаётся прежним (KV Cache).
Когда квантование становится проектным решением, а не оптимизацией
В контуре с ограниченным доступом к топовым ускорителям агрессивное квантование закладывается уже на этапе MVP: часто именно оно определяет, реализуем ли проект на доступном оборудовании (RU AI Regulatory). Это меняет статус решения — из «докрутим потом, если будет дорого» оно превращается в исходное ограничение, влияющее на выбор самой модели.
Второе следствие: смена модели требует пересчёта, а не переноса настроек. Модели со смешанной архитектурой экспертов считаются иначе, чем плотные, поэтому чек-лист миграции включает пересчёт видеопамяти и повторный прогон метрик на эталонном наборе (Agent Evals).
Квантизация как точка атаки, а не только экономия памяти
Всё выше — про то, что квантизация делает с качеством. Отдельно она делает кое-что с доверием: веса можно подобрать так, чтобы полноточная модель проходила проверки безобидно, а квантованный артефакт демонстрировал выбранное атакующим поведение (Egashira et al., 2025).
Следствие прикладное и неприятное: проверки, пройденные на полной точности, на развёрнутый квантованный артефакт не переносятся. Если модель квантуют после приёмки — а так обычно и происходит, потому что квантизация это шаг развёртывания, — приёмку проходил не тот артефакт, который поедет в прод. Проверять надо то, что развёртывается, включая результат конвертации (Supply Chain AI).
Связано с
Supply Chain AI — преобразование артефакта как звено цепочки поставки
LLM Sizing — куда подставляются байты на параметр
Local LLM Deployment — где GGUF-модели реально запускаются
Inference Optimization — рычаги, действующие на кэш, а не на веса
KV Cache — слагаемое, которое квантование весов не уменьшает
Model Selection — квантованная модель как отдельный вариант выбора
Agent Evals — как проверять, что качество не просело
RU AI Stack Map — движки, поддерживающие каждый формат