Короткий вывод

Квантизация уменьшает точность представления весов модели и обычно сокращает их объём в памяти. Это может позволить перенести модель на более доступное оборудование, увеличить запас под параллельные запросы или отказаться от второй видеокарты. Но «16 бит → 4 бита» не означает автоматическое четырехкратное снижение ежемесячных расходов.

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

Для бизнеса правильная единица сравнения — не гигабайт модели и не токен в секунду, а стоимость принятого результата при заданном SLA.

Что квантизация меняет на самом деле

В исходной модели веса часто хранятся в FP16 или BF16. При weight-only квантизации их переводят в представление с меньшим числом битов, а вычисления могут выполняться в более высокой точности. Документация llama.cpp прямо описывает переход из F32/BF16 в низкобитные варианты: файл уменьшается, инференс иногда ускоряется, но возможна потеря качества. Для её снижения проект поддерживает importance matrix — статистику значимости весов на калибровочных данных.

В Transformers документация bitsandbytes отдельно указывает, что 8-битная загрузка примерно вдвое уменьшает память для весов по сравнению с 16-битной. Там же заметно важное ограничение: не все модули обязательно переводятся в тот же формат. Нормализации и другие части графа могут оставаться в исходном dtype.

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

Почему размер файла не равен полной памяти

Грубую нижнюю границу веса модели можно оценить так:

`параметры × битность / 8`.

Для модели на 8 млрд параметров это около 16 ГБ при 16 битах, 8 ГБ при 8 битах и 4 ГБ при 4 битах — до метаданных, масштабов, части неквантизованных тензоров и выравнивания. Это оценка весов, а не готовой службы.

Во время работы память также занимают:

  • KV-кэш для активных последовательностей;
  • временные активации и рабочие буферы;
  • CUDA-графы, ядра и служебные структуры движка;
  • контекст нескольких одновременных пользователей;
  • визуальный или аудиокодер у мультимодальной модели;
  • адаптеры LoRA и другие подключаемые компоненты.

В документации vLLM нехватка KV-кэша связана с вытеснением и повторным вычислением запросов, что ухудшает сквозную задержку. Уменьшение весов может освободить место под кэш и повысить параллелизм, но эффект зависит от длины контекста и числа одновременных запросов. Если нагрузка одиночная и короткая, свободная память сама по себе денег не экономит.

Совместимость с железом важнее названия формата

Одинаковая надпись «4-bit» скрывает разные схемы: GGUF/K-quants, GPTQ, AWQ, bitsandbytes, INT4 W4A16 и другие. Они используют разные упаковки весов, масштабы, калибровку и вычислительные ядра.

Таблица совместимости vLLM показывает, что поддержка форматов различается между поколениями NVIDIA, AMD, Intel и CPU. Поэтому выбирать квант до выбора среды запуска опасно. Формат может загружаться, но использовать менее эффективный путь, требовать конвертации или не поддерживать нужную архитектуру модели.

Минимальная техническая проверка должна фиксировать:

  • точную модель, ревизию весов, токенизатор и chat template;
  • формат и параметры квантизации, источник кванта и контрольную сумму;
  • сервер вывода и его версию;
  • процессор или GPU, объём памяти и драйвер;
  • длину входа и ответа, размер батча и параллелизм;
  • TTFT, межтокенную задержку, пропускную способность, p95 и ошибки;
  • фактическую занятую память после прогрева.

Сравнивать результаты разных серверов, разных шаблонов или разных наборов запросов бессмысленно: меняется сразу несколько переменных.

Качество надо измерять на рабочем результате

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

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

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

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

Модельный расчёт: почему 8 бит могут оказаться дешевле 4

Рассмотрим условный поток из 30 000 документов в месяц. Сотрудник исправляет непринятый результат в среднем 2,5 минуты, его полная стоимость — 600 рублей в час. Для простоты одинаковые расходы на интеграцию и обычную проверку исключены: нас интересует разница между вариантами.

Допущения пилота:

  • BF16: инфраструктура 120 000 рублей в месяц, принято без исправления 96%;
  • 8 бит: инфраструктура 100 000 рублей, принято 95%;
  • 4 бита: инфраструктура 80 000 рублей, принято 90%.

Дополнительный труд считается как `объём × доля исправлений × минуты / 60 × ставка`.

  • BF16: 30 000 рублей труда, итог 150 000 рублей;
  • 8 бит: 37 500 рублей труда, итог 137 500 рублей;
  • 4 бита: 75 000 рублей труда, итог 155 000 рублей.

Это не рыночный прайс и не прогноз для конкретной модели, а демонстрация чувствительности. В примере самый маленький квант экономит 40 000 рублей инфраструктуры относительно BF16, но добавляет 45 000 рублей исправлений. Лучшим оказывается 8-битный вариант.

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

Как провести пилот без дорогой перестройки

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

1. Зафиксируйте 200–500 обезличенных рабочих примеров и критерий приёмки.
2. Подготовьте кванты из одной исходной ревизии или возьмите проверенные артефакты с понятным происхождением.
3. Запустите их на одном целевом сервере с одинаковыми настройками генерации.
4. Снимите память после прогрева, TTFT, p95, пропускную способность и энергопотребление при типичной нагрузке.
5. Проведите слепую проверку результатов и посчитайте минуты исправлений.
6. Рассчитайте стоимость принятого результата и проверьте запас по SLA.
7. Оставьте победителя в теневом режиме на неделю, затем зафиксируйте версию и план отката.

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

Что решить руководителю

Попросите команду принести не скриншот размера GGUF, а таблицу из трёх строк: инфраструктура, доля принятия без исправлений и полная стоимость принятого результата для BF16/8-bit/4-bit. Если в таблице нет времени людей и p95 на вашем железе, решение ещё не посчитано.