29 октября 2026 г. · Анатолий Крылов, редактор Тераферма

Квантование LLM: GGUF, AWQ и FP8 — сколько памяти экономит и что теряем

Квантование LLM сжимает веса модели в 2–4 раза: Llama 70B в 16 битах весит около 141 ГБ и требует двух H100, в FP8 — около 70 ГБ и помещается на одну H100, а в 4 битах (AWQ или GGUF Q4_K_M) — 40–43 ГБ и работает на одной карте с 48 ГБ, например RTX A6000 за 66 ₽ в час. Потеря качества при 8 битах почти нулевая, при 4 битах — небольшая и заметна в основном на коде и математике.

Что такое квантование и зачем оно нужно

Каждый параметр модели записан числом. В исходных весах оно хранится в 16 битах (bf16 или fp16), то есть 2 байта на параметр. Модель на 70 млрд параметров занимает 140 ГБ только на веса.

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

Квантование даёт две выгоды:

Меньше памяти. Модель помещается на карту дешевле или на меньшее число карт.

Выше скорость генерации. На каждый токен карта читает все веса модели. Чем меньше весов в гигабайтах, тем быстрее генерация упирается не в память, а в вычисления. Модель в 4 битах генерирует текст заметно быстрее той же модели в 16 битах на одной и той же карте.

Подробная формула расхода памяти с учётом контекста есть в статье сколько видеопамяти нужно для LLM. Здесь сосредоточимся на самих форматах.

Основные форматы: GGUF, AWQ, GPTQ, FP8

Формат	Бит на вес	Где работает	Для чего
GGUF Q8_0	≈ 8,5	llama.cpp, Ollama, LM Studio	Почти без потерь, когда хватает памяти
GGUF Q6_K	≈ 6,6	llama.cpp, Ollama	Баланс для моделей до 14B
GGUF Q5_K_M	≈ 5,7	llama.cpp, Ollama	Чуть лучше Q4 при небольшом росте размера
GGUF Q4_K_M	≈ 4,8	llama.cpp, Ollama	Самый популярный вариант для одной карты
GGUF IQ3, IQ2	2,3–3,5	llama.cpp	Когда иначе модель вообще не помещается
AWQ, GPTQ	≈ 4,25	vLLM, SGLang, TGI	Серверный инференс с батчингом
FP8	8	vLLM, SGLang, TensorRT-LLM	Почти без потерь, быстро на Ada, Hopper, Blackwell
NVFP4, MXFP4	≈ 4,25	vLLM, TensorRT-LLM	Аппаратный 4-бит на Blackwell

GGUF. Формат llama.cpp, на нём работают Ollama и LM Studio. Главное достоинство в гибкости: модель можно частично разместить в видеопамяти, а остаток — в оперативной. Буквы в названии (K, M, S) обозначают схему квантования: Q4_K_M сжимает важные слои чуть мягче, чем остальные. Для одного пользователя и экспериментов это самый простой путь.

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

FP8. 8-битные числа с плавающей точкой. Тензорные ядра Ada Lovelace (RTX 4090, L4, L40S), Hopper (H100, H200) и Blackwell умеют считать в FP8 аппаратно, поэтому модель не только меньше, но и быстрее. На Ampere (RTX 3090, A100, RTX A6000) vLLM тоже загрузит FP8-веса, но без аппаратного ускорения вычислений.

NVFP4 и MXFP4. 4-битные форматы с плавающей точкой, которые аппаратно ускоряет Blackwell: RTX 5090, RTX PRO 6000, B200. В MXFP4 сразу выпущены gpt-oss-20b и gpt-oss-120b.

Сколько памяти экономит каждый формат

Возьмём три популярных размера моделей. Цифры показывают размер весов без контекста; на KV-кеш и служебные данные добавляйте 10–30% в зависимости от длины контекста и числа пользователей.

Модель	BF16	FP8 / Q8_0	Q5_K_M	Q4_K_M / AWQ	Q3
8B (Llama 3.1 8B, Qwen 8B)	16 ГБ	8–8,5 ГБ	5,7 ГБ	4,5–4,9 ГБ	3,7–4 ГБ
32B (Qwen 32B)	64 ГБ	32–34 ГБ	23 ГБ	18–20 ГБ	15–16 ГБ
70B (Llama 3.3 70B)	141 ГБ	70–75 ГБ	50 ГБ	40–43 ГБ	33–34 ГБ

Формула для своей модели: размер весов в ГБ ≈ число параметров в млрд × бит на вес ÷ 8. Например, Qwen 32B в Q4_K_M: 32 × 4,8 ÷ 8 ≈ 19 ГБ. С контекстом на 8–16 тысяч токенов это уже 21–23 ГБ, на грани для карты на 24 ГБ.

Быстро проверить, на какую карту ляжет ваша модель с нужным контекстом, можно в калькуляторе видеопамяти.

Что теряем: качество и скорость

Квантование сжимает с потерями. Вопрос в том, насколько они заметны на вашей задаче.

8 бит (FP8, Q8_0). Практически без потерь: разница с оригиналом в бенчмарках обычно в пределах погрешности. Если модель помещается в память в 8 битах, сжимать сильнее нет смысла ради качества — только ради экономии.

5–6 бит (Q5_K_M, Q6_K). Потери едва заметны. Хороший выбор для моделей 7–14B, у которых каждая потеря чувствуется сильнее, чем у больших.

4 бита (Q4_K_M, AWQ, GPTQ). Небольшая, но измеримая потеря. В чате и пересказе текста её почти не видно. Сильнее всего страдают задачи, где важна точность каждого шага: код, математика, длинные цепочки рассуждений, строгий JSON на выходе.

Ниже 4 бит. Качество падает быстрее. Модель 70B в 3 битах обычно всё ещё лучше модели 32B в 8 битах, но маленькие модели 7–8B в 2–3 битах часто начинают путаться.

Правило: большая модель в 4 битах обычно лучше маленькой в 16 битах при том же объёме памяти. Qwen 32B в Q4_K_M на 24 ГБ почти всегда умнее Qwen 14B в BF16 на тех же 24 ГБ.

Отдельно про модели Mixture of Experts вроде gpt-oss, Qwen3-30B-A3B или DeepSeek. Квантование уменьшает их размер так же, как у обычных моделей, но в память всё равно нужно загрузить всех экспертов, а не только активных. Зато генерация у них быстрая: на каждый токен читается лишь малая часть весов, и даже в 4 битах MoE-модель выдаёт токены быстрее плотной модели того же размера.

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

Как квантование меняет счёт за аренду

Самое заметное следствие квантования: модель переезжает на карту дешевле или на меньшее число карт. Посчитаем для Llama 70B и рабочего месяца: 22 дня по 8 часов, 176 часов.

Формат	Веса	Конфигурация	Потолок скорости, ток/с	176 часов
BF16	141 ГБ	2 × H100	≈ 47	119 328–146 784 ₽
FP8	70 ГБ	1 × H100	≈ 48	59 664–73 392 ₽
FP8	70 ГБ	1 × A100 80 ГБ	≈ 29	17 072 ₽
AWQ 4 бита	40 ГБ	1 × RTX A6000 48 ГБ	≈ 19	11 616 ₽
AWQ 4 бита	40 ГБ	1 × L40S 48 ГБ	≈ 22	17 072 ₽

Потолок скорости для одного пользователя считается так: токенов в секунду ≈ пропускная способность памяти (ГБ/с) ÷ размер весов (ГБ). Для A6000: 768 ÷ 40 ≈ 19. Реальная скорость составляет 60–80% от потолка. Подробнее о формуле читайте в разборе скорости генерации токенов.

Выводы из таблицы:

• Переход с BF16 на FP8 на H100 вдвое снижает счёт без потери скорости и почти без потери качества.
• 4 бита на карте с 48 ГБ — самый дешёвый способ держать 70B для внутреннего ассистента на нескольких пользователей.
• FP8 на A100 работает, но без аппаратного ускорения: выигрыш здесь только в памяти.

Для моделей поменьше логика та же. Qwen 32B в Q4_K_M помещается на RTX 3090 или RTX 4090 с 24 ГБ (карты на 24 ГБ собраны на странице видеокарты с 24 ГБ). В BF16 той же модели нужна A100 80 ГБ.

Какой формат выбрать под задачу

Задача	Движок	Формат
Попробовать модель, один пользователь	Ollama, llama.cpp	GGUF Q4_K_M или Q5_K_M
Модель чуть больше видеопамяти	llama.cpp	GGUF с частичной выгрузкой в ОЗУ
API на несколько пользователей	vLLM	AWQ или GPTQ, на Ada и Hopper — FP8
Максимум качества на H100, L40S, RTX 4090	vLLM	FP8
Карты Blackwell	vLLM, TensorRT-LLM	NVFP4 или FP8
Дообучение	Transformers + PEFT	QLoRA на 4-битной базе

Готовые квантованные версии популярных моделей обычно уже лежат на Hugging Face: ищите в названии GGUF, AWQ или FP8. Квантовать самому имеет смысл, если нужной версии нет или вы дообучили свою модель. AWQ для модели 70B готовится за несколько часов на одной A100, GGUF через llama.cpp — быстрее.

Как проверить качество после квантования

Общие бенчмарки показывают среднюю картину, а важна ваша задача. Проверка занимает час-два на арендованной карте и почти ничего не стоит.

1. Соберите 30–50 своих примеров. Реальные запросы пользователей, документы для пересказа, задачи на код: то, что модель будет делать в работе. Для каждого запишите эталонный ответ или критерий правильности.
2. Запустите две версии. Например, 8-битную как эталон и 4-битную как кандидата. На карте с 80 ГБ обе версии 32B помещаются по очереди, а сравнение занимает минуты.
3. Сравните ответы. Для задач с однозначным ответом — долю правильных. Для текстов — вслепую: перемешайте ответы двух версий и отметьте, какой лучше. Можно попросить оценить пары более сильную модель, но финальное решение лучше принимать по нескольким десяткам примеров, просмотренных глазами.
4. Замерьте скорость и память. Запишите токены в секунду и пиковое потребление видеопамяти с вашим контекстом. Это даст и выбор карты, и цену миллиона токенов.

Если 4-битная версия отвечает так же хорошо в 90–95% случаев, а ошибки не критичны, берите её: экономия на аренде будет двукратной. Если проваливаются именно важные запросы, оставайтесь на 8 битах или возьмите модель меньше, но в более высокой точности.

Квантование KV-кеша

Веса — не единственное, что занимает память. При длинном контексте и многих пользователях KV-кеш может весить столько же, сколько сама модель.

vLLM и llama.cpp умеют хранить KV-кеш в FP8 или 8-битном целочисленном формате. Это вдвое сокращает его объём и позволяет обслуживать вдвое больше параллельных запросов или удвоить контекст. Потеря качества обычно меньше, чем от квантования весов, но на задачах с очень длинным контекстом её стоит проверить.

Квантование остаётся самым дешёвым способом уменьшить счёт за инференс. FP8 почти не теряет качество и вдвое сокращает память, 4 бита уменьшают её вчетверо ценой небольшой потери на коде и математике. Большая модель в 4 битах обычно лучше маленькой в полной точности.

Подберите формат и карту под свою модель в калькуляторе видеопамяти и запустите тест на арендованной GPU с поминутной оплатой.