Квантование LLM ломает агентов там, где чат-боты не замечают

Одну и ту же модель можно запустить в разных «весовых категориях». В формате FP16 семейство на 70 млрд параметров требует порядка 140 ГБ видеопамяти, в 4-битном квантовании — около 40 ГБ, то есть влезает уже не в кластер, а в одну-две потребительские видеокарты. Экономия очевидна. Менее очевидно другое: то, что в обычном чате незаметно, в агентных сценариях всплывает как систематические сбои — сломанный JSON при вызове инструмента, забытый аргумент, зацикленная цепочка рассуждений.

Что такое квантование и почему оно почти бесплатно в чате

Веса модели хранятся как числа. По умолчанию — это 16-битные числа с плавающей точкой (FP16 или BF16). Квантование заменяет их на более компактное представление: 8 бит, 4 бита, иногда меньше. Модель становится в два-четыре раза легче по памяти и часто быстрее в инференсе, потому что упирается не в вычисления, а в пропускную способность памяти.

Плата за это — ошибка округления. Каждый вес хранится грубее, и предсказания модели немного «плывут». В диалоге человек этого не видит: если модель вместо идеального слова подставит близкое по смыслу, ответ всё равно читается нормально. Метрики вроде perplexity на 4-битных весах проседают на доли процента, и на этом основании квантование долго считали почти бесплатным.

Почему агент — другой случай

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

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

Квантование не делает модель «глупее» равномерно. Оно сначала отъедает самое хрупкое — точность формата и устойчивость длинных рассуждений. А это ровно то, на чём стоит агент.

Где именно всё ломается

Типовые сбои квантованной модели в агентном режиме — не абстрактная «потеря качества», а вполне конкретные вещи:

• Сломанный вызов инструмента. Лишняя запятая, кавычка не того типа, поле названо чуть иначе — и парсер на стороне агента падает. Модель в FP16 такие структуры держит стабильнее.
• Пропущенный или выдуманный аргумент. Функция ждёт user_id и date, модель передаёт только первый или подставляет несуществующий.
• Зацикливание. Агент повторяет один и тот же шаг, не замечая, что уже получил результат. Устойчивость к таким петлям падает вместе с точностью весов.
• Деградация на длинном контексте. Чем больше заполнено контекстное окно, тем заметнее ошибки квантованной модели — особенно когда нужный факт лежит в середине.

Форматы квантования и что они дают

«4 бита» — это не один метод, а семейство подходов с разным качеством. Ниже — ориентир по типам, а не гарантия для конкретной модели: результат сильно зависит от архитектуры и калибровки, поэтому проверять нужно на своей задаче.

GPTQ и AWQ — «умные» методы 4-битного квантования с калибровкой на данных, они обычно бьют наивное округление. Но и они не отменяют главного праводила: чем агрессивнее сжатие, тем внимательнее нужно тестировать именно агентные сценарии, а не только качество ответов в чате.

Кому это пригодится и кому нет

Квантование до 4 бит оправдано, если

• вы гоняете локальную модель на своей видеокарте и без квантования она просто не влезает в память;
• агент решает простые задачи: один-два вызова инструмента, короткие цепочки, прощаемые ошибки (черновик письма, поиск по базе с ручной проверкой);
• у вас есть валидация вывода на стороне кода — схема JSON, повторный запрос при ошибке парсинга, ограничение числа шагов.

Оставайтесь на 8 бит или FP16, если

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

Как проверить, а не гадать

Универсального ответа «столько бит безопасно» нет — он зависит от модели и задачи. Поэтому решайте измерением:

1. Соберите набор из 30–50 реальных агентных сценариев вашего продукта, с ожидаемыми вызовами инструментов и результатами.
2. Прогоните на нём базовую (FP16 или 8-битную) версию и зафиксируйте долю успешных завершений и долю валидных вызовов инструмента.
3. Прогоните ту же выборку на 4-битной версии и сравните те же две метрики, а не общее «ощущение качества».
4. Если просадка успешных завершений в пределах вашего допуска — квантование окупается. Если растёт доля битого JSON и незавершённых цепочек — поднимайтесь на уровень выше.

Экономия памяти считается легко. Стоимость ошибок агента — сложнее, но именно она решает, стоила ли экономия того.

¹ Агент — модель, которая не просто отвечает текстом, а в цикле выбирает и вызывает внешние инструменты (поиск, код, API), разбирает их ответы и решает следующий шаг сама.

² Контекстное окно — максимальный объём текста (в токенах), который модель удерживает за один проход: запрос, история, документы и результаты вызовов вместе.

³ RAG (retrieval-augmented generation) — подход, при котором в контекст модели подставляют найденные во внешней базе фрагменты, чтобы отвечать по актуальным данным, а не только по обучению.