Форматы квантизации LLM: INT8, INT4, GPTQ, AWQ, GGUF — что выбрать?

Почему квантизация LLM ломает качество ответов

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

Средняя метрика при этом почти не двигается: разница в десятые доли процента выглядит безопасной на отчётном графике. Деградация качества ответов оседает не в среднем, а на редких токенах — числах, датах, артикулах, именах, единицах измерения — и на длинных цепочках рассуждений, где ошибка раннего шага дальше только перемножается.

Первыми страдают предсказуемые классы запросов: извлечение полей из договоров, арифметика по таблицам, генерация кода с опорой на редкие вызовы, многошаговые инструкции и работа с длинным контекстом ближе к его концу. Формат ответа при низкой разрядности соблюдается — модель уверенно возвращает нужную структуру, но факты внутри неё подменяются правдоподобными.

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

Что даёт сжатие весов: скорость ответа и объём памяти

Вес модели занимает основную часть памяти при её работе на выдаче — и сжимается первым. Переход с полной точности на INT8 уменьшает его примерно вдвое, на INT4 — втрое-вчетверо. Освободившийся объём уходит под кэш контекста и увеличенный размер пакета запросов: экономия памяти превращается в тот запас, которого обычно не хватало на пиковой нагрузке.

Время отклика падает не потому, что вычисления стали «быстрее», а потому что на каждый шаг генерации из памяти читается меньше данных. Пока узким местом оставалась пропускная способность подсистемы памяти, добавление ускорителей почти не помогало; после сжатия тот же парк обслуживает больше одновременных запросов, а хвостовые задержки перестают расти при всплесках.

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

Стабильность под нагрузкой — следствие того же запаса. Когда памяти хватает с коэффициентом, планировщик не вытесняет контексты и не перезапускает инстансы, очереди не растут лавинообразно. При агрессивном сжатии без калибровки на своём домене качество ответов может проседать, поэтому формат — GPTQ, AWQ, GGUF — выбирают под задачу и профиль трафика, а не по принципу «чем меньше бит, тем лучше».

Сравнение форматов сжатия весов: точность и ограничения

Квантование снижает разрядность весов, чтобы модель уместилась в память ускорителя и выдавала больше токенов в секунду. Но выбор формата — это не только число бит: методы по-разному восстанавливают веса и потому по-разному переносят потерю на качество ответов. Ошибка проявляется не при загрузке, а позже — на длинных рассуждениях и генерации кода.

Ниже — реальные альтернативы, между которыми выбирают на стенде.

На практике держат две-три сборки: одну с запасом по точности для сложных задач, вторую — сжатее, для массовых запросов. Критерий выбора — не усреднённая метрика, а расхождение ответов с полной моделью на вашем наборе задач. Наборы для калибровки и описания методов удобно брать в Hugging Face — там же видно, на каких данных формат проверяли.

Как проходит внедрение: аудит, схема, проверка, передача

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

1. Аудит модели. Снимаем базовые метрики на полной точности: доля верных ответов на вашем наборе запросов, время отклика, потребление памяти. Отдельно помечаем сценарии, где ошибка стоит дороже всего — они станут контрольными.
2. Подбор режима сжатия. Сопоставляем требования к качеству и к доступным ресурсам: INT8 — осторожный вариант, INT4 с групповой квантизацией (GPTQ, AWQ) — когда важнее память, GGUF — для локального запуска.
3. Настройка сжатия. Собираем калибровочный набор из реальных запросов, задаём размер группы и оставляем чувствительные слои в повышенной точности — это дешевле, чем терять качество на всём диапазоне.
4. Тестирование качества. Прогоняем сжатый вариант по контрольным сценариям и сравниваем с базой: доля совпадений, связность ответов, поведение на длинном контексте. Расхождение выше порога — возвращаемся к настройке, а не списываем на особенности сжатия.
5. Защита и откат. Храним полновесную копию и версионируем веса, чтобы возврат к предыдущей сборке занимал минуты.
6. Передача решения. Отдаём веса, конфигурации, скрипты сборки и регламент: как обновлять модель, чем мерить качество, при каких метриках откатываться. Ваши инженеры воспроизводят сборку без нас.

Все замеры и выбранные параметры фиксируем в отчёте — видно, почему подошёл именно этот режим сжатия и что изменится при переходе на другой.

Перечень артефактов: конфигурации, схемы, регламенты

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

• Конфигурации сборки и сжатия — разрядность, калибровочный набор, закреплённые версии зависимостей: повторная сборка даёт тот же артефакт.
• Схемы развёртывания — раскладка модели по ускорителям, требования к памяти, точки балансировки и запас на пиковую нагрузку.
• Политики доступа — роли на чтение и на изменение параметров, порядок выдачи ключей к сервису вывода ответов, журнал обращений.
• Регламенты эксплуатации — что делать при просадке качества, как откатить предыдущую сборку, когда нужна пересборка.
• Инструкции для команды — как поднять стенд, воспроизвести замеры качества, добавить новый формат сжатия в обвязку.
• Документация — паспорт модели, замеры точности до и после сжатия, журнал изменений с ответственным за каждую правку.
• Эталонные наборы проверок — вопросы, на которых видна деградация после перехода на INT4: форматы сравниваются на ваших данных, а не по общим отзывам.

Комплект рассчитан на самостоятельную работу: пересобрать модель в другой разрядности или вернуть предыдущую версию можно без нашего участия.

Кейс: сократили парк оборудования без потери качества

Как мерили и что стало

Модель с открытыми весами Llama в полной точности занимала четыре карты, а пиковый трафик вынуждал масштабироваться горизонтально. Нагрузочное тестирование собрали на записи реального трафика с двумя профилями — короткие типовые вопросы и длинные обращения с вложениями: расход памяти и время ответа ведут себя на них по-разному. Метрики снимали до квантизации и после каждого формата, от INT8 до групповой квантизации с калибровкой, на одном железе и одном наборе запросов.

Смешанная схема — INT4 на линейных слоях, INT8 на слоях внимания и эмбеддингах — сократила время ответа почти втрое и подняла пропускную способность в 2,6 раза на тех же картах. Пик, который раньше разъезжался на два узла, стал держаться на одном, а модель уложилась в две карты вместо четырёх: парк под этот сценарий сократился вдвое без замены оборудования.

Что не сработало с первого раза

Первый прогон был равномерным INT4 по всей сети: на коротких вопросах разницы не увидели, а на длинных контекстах модель теряла условия из середины диалога и путала пункты регламента. Оценка ответов разметкой операторов упала с 91% до 82% — заметнее и быстрее, чем просадка по скорости.

Вернулись к смешанной схеме: калибровку для групповой квантизации собрали из реальных обращений за месяц, критичные слои оставили в INT8 и завели регрессионный набор, который прогоняется перед каждым обновлением весов. На выходе — 90% совпадений с ответами полной модели при пропускной способности в 2,6 раза выше исходной.

Чем отличается квантизация LLM для сервиса и для устройства?

Разница не в том, какой формат точнее, а в том, какой ресурс упирается первым. Серверный запуск держит веса в памяти ускорителя постоянно и обслуживает десятки параллельных запросов — критичны пропускная способность и память на одну сессию. Локальный запуск отвечает одному пользователю в общем пуле памяти устройства, поэтому решает не скорость, а сама возможность уложить модель.

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

На устройстве логика обратная: сначала укладываются в память, потом смотрят на качество. GGUF допускает частичную выгрузку слоёв на процессор — модель запускается там, где целиком не размещается, ценой задержки. Решение принимают по замерам на своём наборе вопросов, а не по таблицам из сети: готовые сборки в каталоге Hugging Face экономят время, но потери качества у каждого сценария свои.

Частые технические сомнения перед стартом

Перед стартом всплывают одни и те же вопросы: не просядет ли качество ответов, что делать при обновлении модели, выдержит ли сжатая версия пиковую нагрузку. Формат весов — INT8, INT4, GPTQ, AWQ или GGUF — меняет способ сжатия, но сами сомнения остаются общими.

Ответы ниже мы проверяем на ваших данных, а не на усреднённых метриках.

Что происходит при обновлении модели?

Сжатие не переносится между версиями: калибровочные коэффициенты под новые веса не подходят. Обновление — это повторная квантизация и прогон регресс-набора, который ловит просадку до выкладки в рабочую среду. Артефакты версионируются, поэтому предыдущая сборка остаётся доступной для отката.

Как сжатая модель ведёт себя под пиковой нагрузкой?

Выигрыш в памяти даёт запас на кэш контекста и размер одновременной обработки, поэтому пропускная способность на одном сервере растёт. Но предел есть: при переполнении очереди растёт время ответа. Мы снимаем нагрузочный профиль и показываем точку, после которой добавляется вторая копия модели.

Уже развёрнута полная версия — придётся всё переделывать?

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

Обсудим задачу и вернёмся с оценкой и планом

Чтобы оценка была предметной, а не «на глаз», для старта достаточно трёх вещей: профиля запросов (тип задач, средняя и пиковая длина контекста, соотношение генерации и коротких ответов), требований к качеству (какие ответы считаются недопустимыми и есть ли эталонный набор вопросов для сравнения) и ограничений по оборудованию — на чём модель должна работать в итоге. Если уже есть замеры времени ответа и объёма модели, приложите: они снимают целый этап согласований.

В ответ мы возвращаем:

• разбор задачи: где узкое место — память, скорость ответа или требования к точности, и какие схемы сжатия под это подходят;
• план работ по этапам: подготовка калибровочных данных, выбор разрядности, замер качества до и после, внедрение;
• оценку сроков и состав команды под ваш объём;
• критерии приёмки — метрики качества и времени ответа, по которым сравниваем варианты между собой;
• список исходных данных и доступов, которые нужны с вашей стороны;
• риски и точки отката: как вернуться к исходной точности, не пересобирая окружение заново.

Опишите задачу в свободной форме — пришлём оценку сроков, план работ и предложение по старту проекта. Достаточно короткого описания и одного-двух примеров реальных запросов.