Квантизация моделей с открытыми весами: как честно мерить потери

Где начинается самообман

Самообман обычно начинается не на этапе квантизации, а на этапе отчета. Команда берет один средний балл, видит просадку на 1-2% и решает, что 4-bit "почти не отличается" от FP16. В таблице все выглядит спокойно. В продукте картина часто другая.

Средняя цифра хорошо прячет неприятные провалы. Модель может так же отвечать на простые вопросы, но чаще путаться в длинных инструкциях, терять числа в таблицах или ломать JSON. Общий балл почти не меняется, а рабочий сценарий уже разваливается.

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

Проблем добавляет и смешивание простых и сложных случаев в одну оценку. Модель может держать 95% на коротких FAQ-вопросах и резко проседать на многошаговых запросах с контекстом из нескольких сообщений. В среднем получится "все нормально". На деле самые дорогие ошибки останутся незаметны.

Это особенно видно после 4-bit. На легких примерах разница с 8-bit или FP16 бывает небольшой. На сложных запросах модель чаще теряет нить, обрезает объяснение, выбирает не тот инструмент или уверенно выдает неверный ответ. Если сложных примеров в тесте мало, средний балл их просто утопит.

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

Поэтому честная проверка начинается с простого вопроса: какие сбои для нас неприемлемы? Если 4-bit дает тот же средний скор, но вдвое чаще ломает structured output, этот режим уже проиграл. Даже если график в отчете выглядит почти идеально.

Если вы тестируете варианты через единый шлюз, например RU LLM, соблазн смотреть только на общие метрики становится еще сильнее. Прогонять модели через один OpenAI-совместимый эндпоинт удобно, но удобство запуска не заменяет честный срез по своим сценариям.

Что меняется после 8-bit и 4-bit

После квантизации моделей с открытыми весами вы почти сразу выигрываете в памяти. Модель, которая в FP16 едва помещалась в GPU, в 8-bit часто начинает работать заметно проще. В 4-bit запас по памяти становится еще больше, и в этот момент легко слишком рано сказать: "качество почти не изменилось".

Проблема в том, что качество падает не ровно. Средняя оценка может просесть слабо, а полезность в живой задаче - заметно. Модель все еще пишет гладкий текст, но хуже держит детали, путается в числах и теряет шаги в длинном рассуждении.

8-bit обычно ведет себя предсказуемо. Он чаще сохраняет стиль ответа, формат, тон и общую структуру. Если ассистент пишет короткие ответы, делает простую классификацию или возвращает шаблонный JSON, разница с FP16 иногда и правда невелика.

С 4-bit картина жестче. Модель может оставаться "умной" на общих вопросах, но чаще ошибается там, где нужен запас точности. Это хорошо видно на суммах, датах, артикулах, редких фактах и задачах, где ответ строится в несколько шагов. На коротком вопросе ошибка может не всплыть. На длинном диалоге она вылезает быстро.

Где потери видны сильнее

Если вы даете длинный контекст, 4-bit чаще теряет детали из начала сообщения. Если требуете строгий JSON, модель чаще пропускает поле, ломает тип или вставляет лишний текст. Если задача связана с извлечением точных данных, разрыв между FP16, 8-bit и 4-bit обычно больше, чем на обычном чат-бенчмарке.

Хороший пример - бот поддержки, который читает 20 сообщений клиента и должен вернуть JSON с категорией обращения, суммой возврата и сроком ответа. В 8-bit он нередко сохраняет структуру и ошибается редко. В 4-bit ответ выглядит таким же уверенным, но сумма уже может быть перепутана, одно поле пропущено, а факт взят из середины переписки вместо последнего сообщения.

Скорость тоже не стоит принимать на веру. Иногда 8-bit и 4-bit дают лучший throughput, но не на каждой конфигурации GPU. На одной карте вы упретесь в память и выиграете много. На другой FP16 и так работает нормально, и прирост окажется скромным. Бывает и хуже: неудачная реализация квантизации или неподходящие kernels съедают часть выигрыша. Поэтому смотрите не только на VRAM, но и на latency, tokens/sec и долю сломанных ответов.

Какие срезы данных смотреть отдельно

Средняя оценка почти всегда скрывает поломки. После 8-bit модель может почти не просесть на простых вопросах, но начать путаться в длинной переписке. После 4-bit это видно еще чаще. Поэтому квантизацию моделей с открытыми весами стоит проверять по отдельным типам запросов, а не одной общей цифрой.

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

В первую очередь разделяйте короткие вопросы и длинные диалоги. В одном случае модель выбирает факт из памяти, в другом должна удержать контекст на много реплик. Простые FAQ и запросы с несколькими условиями тоже лучше проверять отдельно. Вопрос "Как сменить тариф?" и запрос "Подберите тариф без роуминга, с eSIM и лимитом до 1500 рублей" ломаются по-разному.

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

Отдельный срез почти всегда нужен для задач с числами, кодами и названиями брендов, тарифов, артикулов или ID. Именно здесь даже небольшая деградация после 4-bit быстро становится заметной.

Простой пример. Допустим, вы тестируете ассистента поддержки. На 200 обычных FAQ версия в 4-bit почти догоняет FP16. Но на диалогах, где клиент дает номер заказа, дату, сумму и просит вернуть статус в JSON, ошибки уже неприятные: модель меняет одну цифру, пропускает поле или путает язык ответа. Если смотреть только на средний балл, это легко пропустить.

Полезно делить срезы и по длине входа, и по длине выхода. Иногда модель нормально понимает длинный запрос, но сыпется на длинном ответе: повторяется, забывает ограничения, теряет формат. Для команд, которые гоняют трафик через один OpenAI-совместимый слой, такие различия хорошо видны при сравнении FP16, 8-bit и 4-bit на одной и той же задаче.

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

Какие метрики брать под задачу

Средний балл успокаивает сильнее, чем должен. Для квантизации моделей с открытыми весами полезнее считать не абстрактное качество, а долю ответов, которые можно использовать без ручной правки.

Если у задачи есть один правильный ответ, берите точное совпадение. Это подходит для классификации, выбора категории, извлечения кода, номера договора, статуса заявки или ответа из закрытого списка. В таких случаях "почти правильно" обычно равно ошибке.

Похожесть по словам тут часто только мешает. Модель может написать гладкую фразу, но вернуть не тот код причины отказа. Для сравнения FP16, 8-bit и 4-bit это особенно важно: средняя метрика почти не меняется, а точное совпадение проседает заметно.

Когда ответ забирает другая система, сначала проверяйте формат. Считайте долю валидного JSON, долю ответов, которые проходят вашу схему, и долю случаев, где заполнены все обязательные поля. Если после 4-bit модель чаще теряет скобку, меняет тип поля или добавляет лишний текст, такой ответ уже нельзя считать успешным.

Отдельно отмечайте грубые ошибки. Это не просто слабый ответ, а ответ, который нельзя пустить дальше без вмешательства человека. Сюда входят выдуманные факты, перепутанные даты и суммы, опасные советы, потерянное отрицание, неверный адресат и сломанный формат. Один флаг "непригодно" часто полезнее, чем несколько мелких оценок.

Среднее значение снова скроет больные места, поэтому худший срез лучше смотреть отдельно: длинные диалоги, редкие классы, шумный OCR, смешанный русский и английский, запросы с таблицами, сообщения с опечатками. Именно на таких данных 4-bit часто проседает сильнее, чем кажется по общей сводке.

Добавьте и прикладную метрику: цену одного удачного ответа. Считайте ее просто - общая стоимость прогона, деленная на число ответов, которые прошли по качеству и формату. Если 4-bit на бумаге дешевле, но чаще ломает JSON или дает больше непригодных ответов, итоговая цена полезного результата может оказаться выше, чем у 8-bit.

Нормальный набор метрик отвечает на один вопрос: можно ли после квантизации оставить тот же сценарий без лишней ручной проверки.

Как собрать честный тест

Честный тест начинается не с квантизованной версии, а с эталона. Сначала зафиксируйте базовую модель в FP16 или BF16 и больше ничего не меняйте: тот же системный промпт, те же шаблоны, тот же retrieval, те же инструменты, тот же лимит токенов. Иначе вы сравните сразу несколько переменных и потом не поймете, что именно испортило ответ.

Набор запросов лучше брать не из публичных бенчмарков, а из живых сценариев. Для первого прогона обычно хватает 200-500 запросов, если они действительно отражают прод. Хороший набор включает частые простые кейсы, длинные запросы, редкие неприятные случаи и промпты, где модель должна строго держать формат ответа. Если вы тестируете ассистента поддержки, берите обращения клиентов, а не демо-вопросы, которые команда придумала за час.

Перед запуском почистите выборку. Уберите персональные данные, склейте почти одинаковые дубликаты и проверьте, не перекосило ли набор в одну тему. Если половина запросов про возврат товара, а сложные кейсы занимают 5%, средний балл успокоит вас слишком рано.

Дальше нужна дисциплина запуска. Один и тот же набор надо прогонять с одинаковыми параметрами для FP16, 8-bit и 4-bit. Температура, top_p, seed, system prompt, порядок сообщений, подключенные инструменты - все это лучше не трогать. Если тест идет через шлюз вроде RU LLM, полезно еще зафиксировать маршрут до одной и той же модели и провайдера. Иначе в сравнение попадет не только квантизация, но и разница между бэкендами.

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

После этого возьмите небольшой спорный срез и проверьте его руками. Обычно хватает 30-50 ответов, если выбрать пограничные случаи, где автоматическая метрика сомневается или ставит близкие оценки. Именно там часто видно главное: 8-bit почти не трогает смысл, а 4-bit ломает точность на длинных инструкциях, таблицах или извлечении фактов из шума.

Если после прогона у вас есть только средний score, тест еще сырой. Если есть эталон, чистая выборка, одинаковые параметры и карта ошибок по типам, цифрам уже можно верить.

Пример: ассистент поддержки на модели с открытыми весами

Возьмем обычного ассистента для интернет-сервиса. Он отвечает на FAQ, объясняет тарифы, оформляет возвраты и пишет JSON для CRM. На такой задаче квантизация моделей с открытыми весами быстро снимает розовые очки: средний балл может почти не сдвинуться, а сбои пойдут в самых дорогих местах.

На коротких FAQ разница между FP16 и 8-bit часто почти незаметна. Пользователь спрашивает: "Как сменить email?" или "Где скачать счет?" Модель в 8-bit обычно держит стиль, не путает шаги и отвечает почти так же. Если смотреть только на такие запросы, легко решить, что можно безболезненно ужимать все.

Проблемы начинаются там, где ответ зависит от условий. В кейсах про возврат денег, перенос тарифа или скидку по договору 4-bit чаще теряет точность. Она может перепутать срок отказа, не заметить исключение для промо-тарифа или уверенно выдать правило, которого нет. Для поддержки это уже не "чуть хуже текст". Ошибка сразу бьет по деньгам и жалобам.

Длинный диалог ломает картину еще сильнее. Клиент в первом сообщении пишет, что он юрлицо, платит по безналу и уже получил частичный возврат. Через шесть реплик 4-bit нередко забывает одну из этих деталей и советует сценарий для обычного физлица. Ответ выглядит гладко, но он неверный.

Отдельная боль - структурированный вывод. Обычный текст модель еще тянет, а JSON для CRM сыпется раньше: пропадает обязательное поле, меняется тип значения, ломается кавычка, теряется один флаг из схемы. Если команда мерит только "похоже ли на хороший ответ", она увидит проблему слишком поздно, уже после выката.

В живом контуре почти всегда лучше работает разделение, а не один режим для всего. Дешевые и короткие запросы можно держать в 4-bit или 8-bit. Сложные диалоги, тарифные споры, возвраты и все, что пишет JSON в CRM, лучше оставлять в полной точности. Если у команды уже есть единый шлюз к моделям, такую развилку проще ввести без переписывания клиентского кода.

Где команды чаще ошибаются при замерах

Самая частая ошибка скучная, но фатальная: команда меняет промпт между прогонами. Чуть сократили инструкцию, переставили системное сообщение, добавили пример - и сравнение FP16, 8-bit и 4-bit уже нельзя считать честным. Если вы меряете только влияние квантизации, все остальное должно быть одинаковым: промпт, шаблон чата, stop tokens, max_tokens и даже порядок few-shot примеров.

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

Синтетические тесты тоже часто обманывают. На сгенерированных задачах 4-bit нередко выглядит почти так же, как FP16, потому что примеры слишком ровные. А потом модель сыпется на живых диалогах, кривых формулировках, длинных хвостах контекста и редких терминах. Если у вас ассистент поддержки, берите реальные тикеты: короткие, злые, с опечатками, с обрывками переписки. Именно там обычно и видны потери качества после 4-bit.

Еще одна ошибка - смотреть только на качество ответа и игнорировать задержку под нагрузкой. На одном запросе все может выглядеть приемлемо. Под 20 или 50 параллельных запросов картина меняется: растет tail latency, очередь становится длиннее, часть ответов обрывается по таймауту. Для продакшена это не мелочь, а часть результата. Бенчмарк LLM после квантизации должен включать и качество, и поведение сервиса в очереди.

Полезный минимум такой:

• держать один и тот же набор промптов и параметров;
• убирать случайность или прогонять каждый пример несколько раз;
• смешивать синтетику с реальными данными;
• мерить p50 и p95 задержки при разной нагрузке.

И еще одно. Не останавливайтесь после первого красивого отчета. Иногда 8-bit проходит первый набор, а на следующей неделе проваливает длинные диалоги или ответы с точными числами. Хороший замер - это серия прогонов на нескольких срезах, а не один удачный скриншот.

Короткий список перед релизом

Перед релизом квантизованной модели стоит пройти пять простых проверок. Они занимают немного времени, но быстро показывают, можно ли выпускать 8-bit или 4-bit в прод, или вы просто смотрите на приятную среднюю цифру.

• Зафиксируйте базовую линию в полной точности: FP16 или BF16, один и тот же промпт-шаблон, те же параметры декодирования и тот же набор тестов.
• Разделите тесты на срезы, а не только на общий скор. Длинные диалоги, JSON-ответы, извлечение полей, сложные инструкции и редкие доменные запросы ведут себя по-разному.
• Заранее решите, где проходит граница поломки. Например, если точность извлечения реквизитов падает больше чем на 1,5%, если доля битого JSON растет выше 3% или если модель чаще уходит в отказ там, где раньше отвечала.
• Отдельно проверьте самые дорогие ошибки вручную. Для поддержки опаснее не стилистическая неровность, а неверный тариф, пропущенное ограничение по возврату или уверенно выдуманный ответ.
• Подготовьте откат до более точной версии. Если 4-bit ведет себя нестабильно, маршрут на 8-bit или FP16 должен быть готов заранее.

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

Хороший релиз выглядит скучно: есть честное сравнение FP16, 8-bit и 4-bit, есть понятный порог отказа, есть ручная проверка плохих кейсов и есть быстрый откат. Этого уже хватает, чтобы не обманывать себя красивой средней метрикой.

Что делать с результатами

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

4-bit имеет смысл оставлять там, где ошибка стоит дешево. Это черновые ответы, короткие суммаризации, извлечение простых полей, классификация с ручной проверкой, внутренние подсказки оператору. Если ответ короткий, а человек все равно смотрит результат перед отправкой, разница в цене и задержке часто важнее, чем небольшая просадка по качеству.

8-bit для общей нагрузки обычно спокойнее. Такой режим часто дает хороший баланс: память и стоимость ниже, чем у FP16, а просадка по качеству заметно меньше, чем у 4-bit. Если нужен один рабочий вариант на большую часть запросов, разумнее начать именно с 8-bit, а не пытаться посадить весь трафик на 4-bit ради красивой экономии в таблице.

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

Практичнее думать не форматами, а маршрутами. Обычно хватает трех правил: 4-bit для дешевых и коротких задач, 8-bit для основного потока, FP16 или другой модели для тяжелых случаев. В проде побеждает не средняя оценка, а предсказуемое поведение на разных типах запросов.

Тест нужно повторять каждый раз, когда вы меняете промпт, токенизатор или версию модели. Даже небольшой сдвиг в шаблоне ответа может резко увеличить разницу между FP16 и 4-bit на ваших данных. Старые замеры после такого изменения быстро теряют смысл.

Если вы гоняете несколько моделей в российском контуре, удобно держать такую проверку в одном месте. В RU LLM можно переключать маршруты через единый OpenAI-совместимый эндпоинт и не менять SDK, код и промпты при сравнении моделей и режимов. Это упрощает сам прогон, но выводы по качеству все равно должен делать ваш тест, а не удобная таблица.

Итог простой: не выбирайте одну квантизацию "навсегда". Зафиксируйте пороги качества, разложите трафик по типам задач и повторяйте замер после каждого заметного изменения стека.