Квантизация — хранение весов модели с меньшей точностью. Вместо 16 бит на число — 8, 4 или меньше. Модель занимает меньше памяти и быстрее считается, но отвечает чуть хуже.
Что это даёт в цифрах
Модель на 7–8 миллиардов параметров в половинной точности занимает примерно 14–16 ГБ. В 8 битах — около 8, в 4 битах — порядка 4–5 ГБ. Это разница между «нужен серверный ускоритель» и «помещается на обычную видеокарту».
Скорость тоже растёт, но не пропорционально: узким местом часто оказывается пропускная способность памяти, а не вычисления. На процессоре без ускорителя сжатие — часто условие работы вообще: несжатая модель туда не помещается.
Оценка на глаз. Память под веса примерно равна числу параметров, умноженному на биты веса: 7 миллиардов параметров — порядка 14 ГБ в 16 битах, 7 ГБ в 8, 3,5–4 ГБ в 4. Плюс память под кэш и служебные нужды.
Кэш сам не сжимается. При обычной квантизации сжимаются веса, а кэш по умолчанию остаётся в исходной точности: на длинных контекстах память под кэш догоняет выигрыш от сжатия весов. Существуют отдельные режимы сжатия кэша — их включают осознанно, с той же проверкой качества.
Что теряется
Переход с 16 бит на 8 обычно проходит почти незаметно. На 4 битах потери становятся различимыми, и проявляются они неравномерно: простые задачи не страдают, а сложные рассуждения, следование формату и работа с редкими фактами деградируют заметнее.
Ниже 4 бит падение резкое, и такие варианты имеют смысл только при жёстком ограничении памяти.
Важно: потери не проверить по общим рейтингам. На вашей задаче они могут быть как незаметными, так и критичными. Нужен свой набор проверочных примеров и сравнение до и после.
Запас прочности снимается первым. Квантизация почти не вредит там, где модель работала с запасом, и бьёт по случаям на грани возможностей: задача, решавшаяся впритык, после сжатия перестаёт решаться. Поэтому проседание видно не в среднем, а в хвосте сложных примеров — и именно поэтому проверочный набор обязан содержать трудные случаи.
Карта риска. Относительно безопасно: классификация обращений, извлечение полей, оценка похожести, черновые ответы с последующей проверкой человеком. Рискованно: строгий выходной формат, длинные цепочки рассуждений, арифметика, точная работа с редкими терминами — там деградация проявляется первой.
Способы
Что происходит при сжатии. Веса — это дробные числа; квантизация переводит их на грубую сетку значений. Ошибки округления проходят через слои и накапливаются, поэтому решение «какие значения оставить поточнее» и определяет итоговое качество.
После обучения, без калибровки — самый простой путь, качество страдает больше.
С калибровкой на выборке данных — методы вроде GPTQ и AWQ подбирают масштабы сетки по реальным распределениям активаций. Качество заметно выше при том же размере.
Смешанная точность — чувствительные слои остаются в большей точности, остальные сжимаются сильнее.
Как выбирают способ. Без калибровки — для быстрой пробы и редко используемых задач. С калибровкой — для рабочей эксплуатации, причём метод калибровки остаётся тем же, что проверялся на примерах. Смешанная точность — когда 4 бита обязательны по памяти, а проверка показывает проседание на конкретных типах задач.
Формат и инструмент связаны. Для запуска на процессоре в llama.cpp сложилась экосистема файлов GGUF с готовыми степенями сжатия; серверные ускорители работают со своими форматами, и совместимость конкретной сборки проверяется до закупки.
Практическое правило
Начинать с 8 бит. Переходить на 4 только если памяти действительно не хватает, и обязательно сравнив качество на своих примерах. Выбор между «модель побольше в 4 битах» и «модель поменьше в 8» решается замером, а не рассуждением — исход зависит от задачи.
Квантизуй проверенное. Сжимать стоит модель, уже показавшую нужное качество на полной точности. Тогда проседание после сжатия объясняется квантизацией, а не свойствами незнакомой модели, и шаг назад принимается по данным. Одновременная смена модели и точности делает причину неразличимой.
Как проверять потери
Общие рейтинги здесь бесполезны: они измеряют средние способности, а вас интересует конкретная задача. Рабочая схема состоит из трёх шагов.
Набор примеров. 50–100 реальных запросов с известными правильными ответами, включая сложные случаи, а не только типовые.
Прогон в двух вариантах. Исходная точность и сжатая, при одинаковых настройках генерации. Температура должна быть нулевой или фиксированной, иначе разница будет объясняться случайностью.
Сравнение по типам задач. Смотреть не общий процент, а где именно просело. Обычно первыми страдают длинные рассуждения и строгое следование формату.
Проверка — не разовая. Сжатая модель сама не меняется, но меняются промпт, данные и их связка с моделью, поэтому прогон повторяют при существенных правках промпта и при смене версии исходных весов: прежний вывод «4 бита терпимы» нового промпта не гарантирует.
Где квантизация не поможет
Если модель не помещается даже в сжатом виде, дальнейшее сжатие не выход — качество упадёт быстрее, чем освободится память. Правильнее взять модель меньшего размера в мягком сжатии.
И квантизация не ускоряет обработку длинного входа: там узкое место в вычислениях, а не в перекачке весов.
Она не спасает и от нехватки памяти под кэш при длинных контекстах — для этого сжимают сам кэш или ограничивают длину, о чём подробнее в статье про контекстное окно.
Частые вопросы
Насколько падает качество?
На 8 битах обычно почти незаметно, на 4 битах различимо и неравномерно: простые задачи не страдают, сложные рассуждения и следование формату деградируют заметнее. Величину надо мерить на своих примерах — общие рейтинги её не предсказывают.
Что лучше: большая модель в 4 битах или меньшая в 8?
Зависит от задачи, и это решается замером. На задачах, где важны широкие знания, чаще выигрывает большая сжатая. На задачах со строгим форматом и рассуждениями — меньшая, но менее сжатая.
Влияет ли квантизация на скорость?
Да, но не пропорционально сжатию: узким местом часто оказывается пропускная способность памяти, а не вычисления. Основной выигрыш — в объёме занимаемой памяти, а не во времени ответа.
Нужна ли квантизация, если модель берётся по API?
Нет: точность весов — внутреннее дело провайдера, вы её не выбираете. Тема становится практичной при работе со своими весами на своём железе, когда память и стоимость обслуживания — ваши.
Стоит ли брать готовую квантованную версию из сообщества?
Можно — проверка на своих примерах обязательна в обоих случаях. Риск в другом: версии от разных авторов делаются разными методами и настройками калибровки, и «4 бита» у двух авторов дают разное качество. Сравнивайте конкретные файлы с известной родословной, а не ярлыки.
Что даёт сжатие KV-кэша?
Экономию памяти на длинных контекстах: кэш растёт с длиной контекста, и на объёмных запросах он занимает память, сопоставимую с весами. Плата — дополнительная деградация поверх сжатия весов, поэтому включают его после такого же прогона «до и после».