Квантування GGUF: який рівень обрати?

Беріть Q4_K_M за замовчуванням; переходьте на Q6_K чи Q8_0, коли VRAM із запасом і потрібні останні відсотки якості. Квантування GGUF стискає ваги моделі з 16 біт до менших — Q4_K_M зберігає приблизно 4.85 біт на вагу, тож модель 7B падає з ~14 ГБ до ~4.1 ГБ з перплексією гіршою за оригінал менш ніж на 1% зазвичай. Питання «яке gguf-квантування обрати» має стабільно нудну відповідь, яку більшість інтернет-драми затуляє. Нижче: що квантування справді робить з вагами, скільки якості коштує кожен рівень, як порахувати розмір самому, і одна команда виміряти шкоду на власному залізі замість віри в чужий бенчмарк.

Що квантування GGUF справді робить?

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

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

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

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

Q4 проти Q8: чи вище квантування краще?

Технічно так; перцептивно ні. За референс беремо власні перплексійні прогони llama.cpp на моделях Llama: Q8_0 приземляється в межах ~0.02% від FP16 — для будь-якої практичної цілі без втрат. Q6_K розрізнити майже неможливо. Q4_K_M набирає близько 1–2% перплексії, Q4_0 трохи більше, а на Q2_K у малих моделей зв’язні відповіді починають розсипатися.

Два правила, які з чисел випливають:

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

Рівень	Біт/вагу	Розмір проти 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-quants

Скільки 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-кеш (росте з довжиною контексту — від кількох сотень МБ до кількох ГБ), активації та обчислювальні буфери. Практичний запас: моделі «4.9 ГБ» хочеться карту 6 ГБ на контексті 4k, плюс flash-attention і квантування KV-кеша, щоб лишитися там на 16k. Ваги — це заголовок, а не всякий рахунок.

Яке квантування 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 один раз, скачайте два рівні однієї моделі і міряйте обидві перплексію (менше — краще) і tokens/секунду:

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-text (менше = ближче до оригінальної моделі)
./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. Про файловий бік — у як запустити GGUF-моделі локально.

Тож який рівень обрати?

Q4_K_M, і перестаньте читати форуми про це. Апгрейдьтеся до Q6_K для роботи, голодної до точності, якщо VRAM дозволяє, тримайте одну Q8_0 про запас для A/B, а все нижче Q4 — надзвичайний пайок лише для великих моделей. Єдина помилка, варта уникнення, симетрична: хвилюватися про Q4-проти-Q5, ігноруючи довжину контексту, яка ламає більше локальних налаштувань, ніж будь-яке квантування.