RunPod разобрал 4 метода квантизации: от FP16 до INT4 память падает в 4 раза

RunPod, облачный провайдер GPU, выпустил обзор четырёх способов сжимать модели перед развёртыванием: post-training квантизация (PTQ), quantization-aware training (QAT), смешанная точность и динамическая квантизация. В материале нет собственных бенчмарков, это справочное сравнение компромиссов. Но тема из тех, что напрямую определяют счёт за инференс. Веса модели на 70 млрд параметров занимают около 140 ГБ в FP16, около 70 ГБ в INT8 и около 35 ГБ в INT4. Разница между «нужны два 80-гигабайтных ускорителя» и «хватит одного» складывается из этих цифр.

Четыре способа потерять немного точности

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

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

Смешанная точность держит большинство операций в FP16 или BF16, а чувствительные места, вроде аккумуляторов, нормализации и softmax, оставляет в более высокой разрядности. Динамическая квантизация хранит веса в целых числах, а диапазоны активаций вычисляет на лету во время работы. Она проще всех подключается к готовой модели и хорошо ложится на CPU-инференс, зато накладные расходы на расчёт диапазонов съедают часть выигрыша.

Ориентиры по разрядности

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

• FP16/BF16: 2 байта на параметр, базовая точность, 70B-модель требует около 140 ГБ только под веса.
• INT8: 1 байт на параметр, память вдвое меньше, потери качества на большинстве задач обычно невелики.
• INT4: 0,5 байта на параметр, около 35 ГБ для 70B, заметный риск деградации на рассуждениях и коде.
• Накладные расходы: KV-кэш и активации в эти цифры не входят и растут с длиной контекста и числом параллельных запросов.
• Поддержка железа: ускорение даёт только то, что умеют нативно считать тензорные ядра. На H100 это FP8 и INT8, а для INT4 часто нужны специальные ядра.

Где подвох

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

Из этого следует практический порядок действий. Для первой попытки берите PTQ в INT8 или в 8-битном формате, который поддерживает ваше железо, и сравнивайте с FP16 на собственных данных, а не на публичных тестах. Если качество держится, пробуйте INT4 и смотрите на худшие случаи, а не на среднее. Если просадка критична, а бюджет на дообучение есть, переходите к QAT. Динамическая квантизация подойдёт там, где GPU нет вовсе или нужно быстро проверить гипотезу. Отдельно считайте KV-кэш: 70-гигабайтная INT8-модель на 80-гигабайтной карте оставляет лишь около 10 ГБ под контекст и параллельные запросы, и в этот момент INT4 выигрывает не скоростью, а свободной памятью.