Квантование GGUF: Q4_K_M vs Q8_0, размер и VRAM

По умолчанию берите Q4_K_M; поднимайтесь до Q6_K или Q8_0, когда VRAM в избытке и нужны последние проценты качества. Квантование GGUF сжимает веса модели с 16 бит до меньшего — Q4_K_M хранит примерно 4.85 бита на вес, так что модель 7B худеет с ~14 GB до ~4.1 GB, а перплексия обычно хуже исходной меньше чем на 1%. У вопроса «какой квант GGUF использовать» ответ скучно стабилен — и именно его закрывает большая часть драмы в интернете. Ниже: полная таблица уровней — от Q2_K до Q8_0, размер, VRAM и измеренная потеря качества — расчёт размера самому, и одна команда, чтобы измерить ущерб на своём железе, а не верить чужому бенчмарку. Если квант отправляется в vLLM, а не в llama.cpp, can vLLM run GGUF описывает плагин и правило «только GPU».

Что квантование GGUF делает с весами?

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

1. Блочное масштабирование. Веса группируются в блоки (обычно по 32), и каждый блок получает свой масштабный коэффициент. 4-битные значения — смещения внутри блока, так что широкий диапазон величин выживает.
2. K-кванты с учётом важности. «K» в Q4_K_M означает супер-блоки масштабов плюс различное обращение с attention- и feed-forward-слоями — они переносят сжатие неравномерно.

Семейство «I» (IQ4_XS и компания) идёт дальше с информационно-теоретическими кодовыми книгами, позаимствованными из сжатия изображений. Та же идея, более хитрое кодирование: меньше бит на вес при похожем качестве ценой чуть более медленного инференса на некоторых бэкендах.

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

Q4 vs Q8: выше квантизация — лучше?

Технически да; по ощущениям нет. Взяв за ориентир собственные прогоны перплексии llama.cpp на моделях Llama: Q8_0 отстаёт от FP16 на ~0.02% — для любой практической цели это lossless. Q6_K практически неотличим. Q4_K_M теряет примерно 1–2% перплексии, Q4_0 чуть больше, а на Q2_K у маленьких моделей связные ответы начинают разваливаться.

Два правила из этих цифр:

• Размер модели даёт запас по квантованию. Модель 70B переживает Q2/Q3 куда лучше, чем 7B: большие модели более избыточны. Квантизация 7B до Q2 — ампутация; 70B до Q3 — портновская подгонка.
• Пол качества движется вместе с задачей. Чат терпит Q4. Точная генерация кода, математика и RAG по точным документам выкапывают шум квантования раньше. Если Q4-модель стабильно пишет слегка неправильный код, проверьте ту же модель на Q6_K, прежде чем винить модель.

Уровень	Бит/вес	Размер vs FP16	Потеря качества	Когда брать
Q2_K	~3.4	~21%	Тяжёлая ниже 13B	Когда больше ничего не влезает; только крупные модели
Q3_K_M	~3.9	~25%	Заметная	Тесно по VRAM, модели ≥14B
Q4_K_S	~4.6	~29%	Небольшая	Q4_K_M не влезает, а разница невелика
Q4_K_M	~4.85	~30%	~1% перплексии	Дефолт. Лучший баланс качество/размер
Q5_K_M	~5.7	~35%	~0.5%	VRAM есть, задачи критичны к качеству
Q6_K	~6.6	~41%	Почти нулевая	Код/математика, ещё влезает свободно
Q8_0	~8.5	~53%	Практически нет	Референс-прогоны, базы для файнтюнов
IQ4_XS	~4.3	~27%	≈Q4_K_M	Q4_K_M чуть великоват, бэкенд умеет i-кванты

Сколько VRAM нужно каждому уровню?

Считайте размер сами, а не заучивайте таблицы — это одна строка:

size_GB ≈ (bits_per_weight × params) / 8
# модель 8B @ Q4_K_M: 4.85 × 8 / 8 ≈ 4.9 GB
# модель 8B @ Q8_0:   8.50 × 8 / 8 ≈ 8.5 GB

Затем добавьте то, чего формула не учитывает: KV-кэш (растёт с длиной контекста — от пары сотен MB до нескольких GB), активации и compute-буферы. Практический запас: модели «на 4.9 GB» нужна карта на 6 GB при контексте 4k, а чтобы удержаться на 16k — flash attention и квантование KV-кэша. Веса — заголовок счёта, а не весь счёт.

Какой квант GGUF вам подойдёт?

Порядок решений, запоминать исключения не стоит:

1. Сначала посчитайте бюджет контекста + KV, потом весов. Контекст, который не влезает, хуже качества, которое вы не можете измерить.
2. Дефолт — Q4_K_M. Он дефолт сообщества не просто так: примерно 1% перплексии за 70% размера. Каждый реестр, включая Ollama, возит его как базовую линию.
3. Шагайте на Q6_K, когда задача наказывает за шум: код, математика, извлечение данных, всё, что вы скармливаете пайплайну без присмотра.
4. Q8_0 — только для референса: A/B-тесты, измерение ущерба от квантизации, база для файнтюна. Как ежедневная машина он в основном греет сенсоры вашей VRAM.
5. Ниже Q4 — только под давлением, и только на крупных моделях. Прежде чем доверять, проверьте известной сложной подсказкой.

Если выбираете, какой файл качать на Hugging Face, берите одиночный Q4_K_M.gguf вместо шардированных кусков — разве что автор выложил только их: меньше движущихся частей. А если выбираете, где его запускать, выбор движка — отдельная ось: см. llama.cpp vs Ollama.

Как измерить ущерб от квантизации самостоятельно?

Бенчмарки различаются; ваш промпт постоянен. Соберите llama.cpp один раз, скачайте два уровня одной модели и измерьте и перплексию (ниже — лучше), и токены/сек:

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build && cmake --build build --config Release -j

huggingface-cli download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF \
  Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf Meta-Llama-3.1-8B-Instruct-Q8_0.gguf \
  --local-dir models

# перплексия на куске wiki-текста (ниже = ближе к исходной модели)
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99
./build/bin/llama-perplexity -m models/Meta-Llama-3.1-8B-Instruct-Q8_0.gguf  -ngl 99

# и скорость на том же железе
./build/bin/llama-bench -m models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -ngl 99

Цифра Q4_K_M будет на несколько сотых пункта хуже Q8_0, а файл — на ~40% меньше. Если ваша нижележащая задача разницы не видит — а для большинства это так, — ответ у вас уже есть, без чтения чужих лидербордов.

Вредит ли квантизация приватности и локальности?

Нет — это арифметика над весами, полностью офлайн, и квантованный файл — просто меньший контейнер тех же параметров. Локальный запуск Q4_K_M утекает ровно столько же (то есть ничего), сколько и локальный запуск модели полной точности: с машины не уходит ничего. Приватно значимая переменная — где выполняется инференс, а не разрядность. Обычные оговорки о происхождении модели применимы одинаково к каждому уровню квантования: «uncensored»-файнтюн на украденной базе в Q8 не безопаснее тех же весов в Q4. Про сторону формата файла — см. how to run GGUF models locally.

Какой уровень в итоге выбрать?

Q4_K_M — и перестаньте читать об этом форумы. Поднимайтесь до Q6_K для задач, требующих точности, если позволяет VRAM; держите один Q8_0 под рукой для A/B-сравнений; всё, что ниже Q4, считайте аварийным пайком только для больших моделей. Единственная ошибка, которой стоит избегать, симметрична: переживать из-за Q4-против-Q5 и игнорировать длину контекста — она ломает больше локальных установок, чем любой квант за всю историю.