Квантування GGUF для Ollama: що означають Q4_K_M, Q8_0 та IQ4_XS яке вибрати під своє залізо

Якщо ви запускаєте моделі через Ollama або інші локальні рантайми, ви вже стикалися з назвами на кшталт Q4_K_M, Q8_0 або IQ4_XS. Що це означає? Яке обрати? Чому Q4 часто краще за Q8 — і коли це не так?

У цій статті я розбираю квантування без зайвого теоретизування — з таблицями, реальними числами та прикладами з власних проєктів на MacBook M1 16 ГБ.

Що таке квантування мовної моделі — пояснення простою мовою

Мовна модель — це набір числових ваг. Кожна вага визначає, як нейрон реагує на вхідні дані. У повній точності (FP16) кожна вага займає 16 біт — два байти. Модель на 7 мільярдів параметрів важить при цьому близько 14 ГБ.

Квантування — це зменшення кількості біт на одну вагу. Q8 — 8 біт, Q4 — 4 біти, Q2 — лише 2. Чим менше біт, тим менший файл і менше потрібно пам'яті для запуску.

Хороша аналогія — JPEG проти RAW-фото. RAW — максимальна деталізація, але займає 25 МБ. JPEG із якістю 85% — 3 МБ, і більшість людей не бачать різниці. Але якщо ви масштабуєте зображення або різко обрізаєте — артефакти стають помітними. Так само і з моделями: у звичайному чаті Q4 і Q8 практично однакові, але в математиці чи складному коді різниця вже відчутна.

Головна думка: квантування — це стиснення, а не погіршення. Правильно обране квантування зберігає 92–95% якості при 3–4-разовому зменшенні розміру.

Приклад з практики: у моєму проєкті AskYourDocs RAG-система обробляє корпоративні документи через локальний Ollama на M1. Модель Qwen3-14B у Q4_K_M займає ~8.5 ГБ і вкладається у 16 ГБ unified memory — залишається місце для контексту та embedding-моделі. У FP16 вона б зайняла ~28 ГБ і просто не запустилась би.

Навіщо квантування потрібне для локального AI

Без квантування локальний AI на споживчому залізі просто неможливий. Ось цифри:

• Llama 3.3 70B у FP16 — ~140 ГБ. Таке залізо коштує десятки тисяч доларів.
• Той самий Llama 3.3 70B у Q4_K_M — ~40 ГБ. Запускається на Mac Studio або двох RTX 4090.
• 7B модель у FP16 — 14 ГБ. У Q4_K_M — 4.1 ГБ. Запускається навіть на відеокарті з 6 ГБ VRAM — які моделі відкриваються на 8 і 16 ГБ RAM.

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

Головна думка: квантування — це не компроміс, а єдиний спосіб запустити сучасні LLM на домашньому ПК або ноутбуці.

Де це застосовується: локальні RAG-системи, персональні асистенти, автономні агенти без хмари, корпоративні інструменти на ізольованих серверах — скрізь, де модель має працювати без API-ключів і без передачі даних назовні.

Що таке формат GGUF і чому він переміг

GGUF (GPT-Generated Unified Format) — це файловий контейнер для квантованих моделей. Його створив Georgi Gerganov, автор llama.cpp, у 2023 році як заміну старому формату GGML.

Головна перевага GGUF — самодостатність: один файл містить усе необхідне для запуску:

• квантовані ваги моделі;
• токенайзер та його конфігурацію;
• метадані архітектури;
• гіперпараметри.

Зі старим GGML потрібно було тримати окремі файли для ваг і конфігурації, що ускладнювало дистрибуцію. GGUF вирішив цю проблему і швидко став стандартом: сьогодні його підтримують Ollama, LM Studio, Open WebUI, Jan, KoboldCpp та більшість інших локальних рантаймів.

Особисто я для щоденної роботи з GGUF-моделями використовую LM Studio — на моєму MacBook M1 генерація помітно швидша, ніж в Ollama, плюс зручний інтерфейс для швидкого перемикання між моделями і квантизаціями. Якщо ви ще не пробували — рекомендую як відправну точку.

Коротко: GGUF — це не тип квантування, а контейнер. Квантування (Q4, Q8 тощо) — це те, що знаходиться всередині файлу GGUF.

Приклад: коли ви виконуєте ollama pull qwen3:14b, Ollama завантажує GGUF-файл із квантизацією Q4_K_M за замовчуванням. Але ви можете явно вказати іншу: ollama run hf.co/bartowski/Qwen3-14B-GGUF:Q8_0.

Від FP16 до Q2: рівні квантування у таблиці

Кожен рівень квантування — це компроміс між якістю та розміром. Ось як виглядає 7B модель на різних рівнях:

Дані про розміри файлів взяті з реальних GGUF-замірів llama.cpp. Відсотки якості — приблизні значення перплексії відносно FP16.

Головне тут: різниця в якості між Q4_K_M і Q8_0 — близько 4%. Різниця в розмірі — майже вдвічі. Саме тому Q4_K_M виграє у більшості сценаріїв.

Приклад: дослідження початку 2026 року підтверджують, що логічні міркування дуже стійкі до квантування, тоді як арифметика починає деградувати нижче Q4. Для звичайного чату і перекладу — Q4 абсолютно достатньо.

Що означають Q4_K_M, Q5_K_M, Q8_0 — розшифровка суфіксів

Це один із найпопулярніших запитів серед новачків, і майже жодна стаття не пояснює його нормально. Розберімо детально.

Структура назви: Q[біти]_[метод]_[варіант]

Q4 — кількість біт на вагу (приблизно). Не завжди ціле число: Q4_K_M реально використовує ~4.5 біт через змішану точність.

_K — K-Quants. Це більш розумна схема квантування, яка розподіляє біти нерівномірно: шари, що найбільше впливають на якість (attention, output projection), отримують більше біт, решта — менше. Це дозволяє при тому ж середньому розмірі зберегти вищу якість, ніж старий рівномірний підхід.

_M / _S / _L — розмір варіанту в межах одного рівня:

• _S (Small) — мінімальний розмір у своєму класі, трохи нижча якість.
• _M (Medium) — баланс між розміром і якістю. Це стандартна рекомендація.
• _L (Large) — максимальна якість у класі, трохи більший файл.

_0 — стара рівномірна схема (наприклад, Q4_0, Q8_0). Усі ваги квантуються однаково, без пріоритетів. Q8_0 широко використовується через простоту, але Q4_0 вже практично витіснений Q4_K_M при тому ж розмірі.

Порівняльна таблиця популярних квантизацій

Запам'ятайте: суфікс _M у назві — найважливіша буква. Саме вона означає, що модель використовує змішану точність і зберігає найважливіші шари з вищою деталізацією.

Приклад: якщо ви бачите на Hugging Face два файли — model-Q4_0.gguf і model-Q4_K_M.gguf приблизно однакового розміру — беріть Q4_K_M. Стара схема Q4_0 при тому ж обсязі дає помітно гіршу якість.

IQ-квантизації: що таке IQ4_XS і чому це важливо у 2026

Це тема, якої майже немає в жодній статті . А між тим IQ-кванти вже з'явились у стандартних завантаженнях bartowski і активно обговорюються в спільноті llama.cpp.

Що таке imatrix (importance matrix)

Стандартне квантування обробляє всі ваги однаково. Importance matrix (imatrix) — це попередній аналіз: через модель пропускають калібрувальні дані та вимірюють, які ваги найбільше впливають на якість виводу. Ці ваги квантуються обережніше, решта — агресивніше.

Результат: менший файл при схожій або навіть кращій якості, ніж у K-квантів того ж рівня.

IQ4_XS vs Q4_K_M: практичне порівняння

*IQ4_XS дає перевагу лише якщо використано якісний imatrix-файл. Погано калібрований IQ-квант може поступатися Q4_K_M.

Для 70B моделі різниця між IQ4_XS і Q4_K_M — 3–4 ГБ, що може бути критичним для того, чи влізе модель у пам'ять взагалі.

Де брати перевірені IQ-кванти

Не всі GGUF-файли на Hugging Face однакові. Три перевірені джерела:

• bartowski — найактивніший та найнадійніший завантажувач, включає imatrix.
• mradermacher — широке покриття моделей.
• TheBloke — класичний архів, менш активний у 2026, але ще надійний.

Головна думка: IQ4_XS — не завжди краще за Q4_K_M. Але якщо вам потрібно вмістити більшу модель у ту саму пам'ять — IQ4_XS дає 3–4 ГБ виграшу при схожій якості.

Практичний сценарій: у мене MacBook M1 з 16 ГБ. Qwen3-14B у Q4_K_M займає ~8.5 ГБ — влізає. Але якщо додати nomic-embed-text (~280 МБ) і контекст 8K — починається свопінг. IQ4_XS того ж Qwen3-14B займає ~7.9 ГБ, і система дихає вільніше.

У своїй роботі я використовую двоетапну стратегію: для тестування, написання статей і звичайних задач — легша модель у Q4_K_M, яка запускається швидко і не навантажує систему. Але коли агент переходить до виклику зовнішніх інструментів або складної логіки з tool calling — перемикаюсь на сильнішу модель у Q5_K_M або Q6_K, де критично важлива точність JSON-схеми і послідовність кроків. Q4 тут іноді «губить» логіку в середині ланцюжка.

Скільки RAM та VRAM потрібно: таблиця та формула

Ось практична таблиця з розмірами популярних моделей у різних квантизаціях. Дані на основі замірів willitrunai.com та офіційних GGUF-файлів:

Формула для власних розрахунків

RAM (ГБ) = Параметри (млрд) × Байти_на_вагу × 1.2

Байти на вагу:
  FP16   → 2.0
  Q8_0   → 1.0
  Q5_K_M → 0.69
  Q4_K_M → 0.55
  Q3_K_M → 0.41

Додатково:
  + 1–2 ГБ на KV-кеш (при контексті 4K)
  + 2 ГБ на ОС та інші процеси

Джерело формули: localaimaster.com.

Приклад розрахунку: Qwen3-14B у Q4_K_M → 14 × 0.55 × 1.2 = 9.24 ГБ для ваг + ~1.5 ГБ KV-кеш при 4K контексті = потрібно мінімум 11–12 ГБ VRAM.

Коротко: розмір файлу — це тільки ваги. Додайте KV-кеш (залежить від контексту) і 2 ГБ на систему — і отримаєте реальну потребу в пам'яті.

Важливо для MacBook Apple Silicon: unified memory ділиться між CPU та GPU, тому реально доступно ~75–80% від загального обсягу. На M1 16 ГБ — приблизно 12–13 ГБ ефективно для моделі.

Яке квантування вибрати під своє залізо

Коротка практична шпаргалка:

Що робити, якщо модель не влізає у VRAM повністю

Якщо модель більша за VRAM — llama.cpp і Ollama автоматично переносять частину шарів на CPU. Це називається частковим offloading (layer offloading).

Коли вибирати Q4_K_S замість Q4_K_M

При частковому offloading кожен шар, що іде на CPU, проходить через PCIe-шину. Менший файл = менше трафіку. Тому при частковому offloading рекомендується Q4_K_S — він на ~8% менший за Q4_K_M при незначній різниці в якості.

Квантизація KV-кешу: прихований виграш у пам'яті

Мало хто знає, що окрім квантування ваг моделі — можна також квантувати KV-кеш. Це пам'ять, яку модель використовує для збереження контексту при генерації.

В Ollama це керується змінною середовища:

OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

Результати реальних замірів на основі llama.cpp Discussion #20969:

Висновок з таблиці: q8_0 KV-кеш — майже безплатний виграш: вдвічі менше пам'яті без помітної втрати якості. q4_0 KV-кеш небезпечний при довгому контексті — на 110K токенів швидкість генерації падає на 37%, і деградує якість структурованого виводу та коду.

Головна думка: якщо вам тісно в пам'яті — спочатку спробуйте OLLAMA_KV_CACHE_TYPE=q8_0. Це дає ~47% економії KV-пам'яті практично без втрат. Тільки потім розглядайте менше квантування ваг.

Де це особливо важливо: у RAG-системах на кшталт AskYourDocs, де в контекст завантажуються великі фрагменти документів — KV-кеш може займати стільки ж пам'яті, скільки сама модель.

Чому Q4_K_M рекомендують частіше за Q8

На перший погляд логіка проста: Q8 — краща якість. Але є три аргументи на користь Q4_K_M, про які зазвичай не говорять.

1. Q8_0 повільніший за Q4_K_M

LLM-генерація обмежена пропускною здатністю пам'яті, а не обчисленнями. GPU більше часу витрачає на зчитування ваг з VRAM, ніж на множення матриць. Більший файл = більше байт читати на кожен токен.

За даними офіційного README llama.cpp для Llama-3.1-8B: Q8_0 генерує токени на 29% повільніше за Q4_K_M.

2. Більша модель у Q4 > менша модель у Q8

Це найважливіше правило для вибору квантування, яке більшість ігнорує:

70B у Q4 значно перевершує 7B у FP16 при схожому розмірі файлу.

Стратегія правильна: спочатку беріть максимально велику модель, яка влізає у пам'ять, і тільки потім знижуйте точність. Не навпаки.

3. Q4_K_M зберігає 92–95% якості FP16

Для побутового чату, перекладу, підсумовування та більшості текстових задач — 5% різниці в якості практично невідчутні. Саме тому Q4_K_M — це стандартна квантизація Ollama за замовчуванням: за замовчуванням Ollama вже вибирає цей варіант. Вам не потрібно думати про це — просто запустіть модель.

Головне тут: Q4_K_M виграє не тому що Q8 поганий — а тому що звільнена пам'ять дозволяє запустити модель вдвічі більшого розміру, що дає більший приріст якості.

Приклад із цифрами: на RTX 4070 12 ГБ — вибір між Qwen3-7B Q8_0 (~7.7 ГБ) і Qwen3-14B Q4_K_M (~8.5 ГБ). Другий варіант у реальних тестах дає помітно кращі результати на складних задачах попри нижче квантування.

Коли варто платити за Q5, Q6 або Q8

Є сценарії, де вищий рівень квантування справді виправданий:

Код та structured output → Q5_K_M або Q6_K

Генерація коду вимагає точного дотримання синтаксису. Пропущена дужка або неправильний відступ — і код не компілюється. Q5_K_M помітно знижує частоту синтаксичних помилок у порівнянні з Q4.

Математика та reasoning → Q5_K_M мінімум

Дослідження 2026 року підтверджують: арифметичне міркування деградує різко нижче Q4. Для задач із покроковими обчисленнями, особливо із довгими ланцюжками логіки — Q5_K_M або Q6_K.

RAG-системи з довгим контекстом → Q5_K_M

При завантаженні великих документів у контекст модель має «утримувати» факти з початку тексту до кінця відповіді. Q4 справляється, але Q5_K_M надійніший при контексті 16K+.

Агенти з tool calling → Q5_K_M+

Агенти мають точно дотримуватися JSON-схеми для виклику інструментів. Q4 іноді генерує невалідний JSON під навантаженням. У своїй системі агентів я вже перейшов на Q5_K_M саме через це.

Малі моделі (3B–7B) з великим VRAM → Q8_0

Якщо у вас 16+ ГБ VRAM і ви запускаєте невелику 7B модель — Q8_0 виправданий: модель повністю влізає, а виграш у якості відчутний.

Головна думка: підвищуйте квантування не «заради якості взагалі», а під конкретну задачу. Для коду і агентів — Q5_K_M мінімум. Для чату і перекладу — Q4_K_M достатньо.

Чи псує квантування якість відповідей — реальні приклади

Я порівнював Q4_K_M і Q8_0 на Qwen3-14B через Ollama на M1. Ось що я отримав на різних типах задач:

Запам'ятайте: 80% задач не потребують Q8. Але якщо ваша задача — це код, агенти або математика — Q5_K_M стане помітним покращенням навіть без переходу на Q8.

Важливий нюанс: різниця між Q4_K_M і Q8_0 на 14B моделі менша, ніж різниця між 7B Q8_0 і 14B Q4_K_M. Розмір моделі важливіший за рівень квантування — завжди беріть більшу модель у нижчому кванті, якщо маєте вибір.

GGUF vs GPTQ vs AWQ vs EXL2: що обрати у 2026

GGUF — не єдиний формат квантування. Ось повна картина:

Детальніше про GPTQ та AWQ: LLM Quantization Guide 2026 — tensorrigs.com.

Якщо ви — домашній користувач або розробник на MacBook/ПК — GGUF Q4_K_M через Ollama є єдиним форматом, про який вам потрібно думати. GPTQ і AWQ — для GPU-серверів і production-інфраструктури.

Де що застосовується: GGUF — локальний dev, RAG-прототипи, особистий асистент. AWQ — production API, vLLM-сервер з десятками паралельних запитів. EXL2 — ентузіасти, що витискають максимум з одного RTX 4090.

Як завантажити правильний GGUF-файл з Hugging Face

Покажу на власному прикладі — я регулярно завантажую моделі саме звідси. Детально можете ознайомитись на сторінці bartowski/Qwen_Qwen3-14B-GGUF — там є всі квантизації з описом розміру і рекомендаціями:

Крок 1. Відкрийте сторінку моделі на Hugging Face. Шукайте репозиторії від bartowski, mradermacher або TheBloke — у них є imatrix і перевірена якість.

Крок 2. У вкладці "Files and versions" відфільтруйте файли за розширенням .gguf.

Крок 3. Визначте потрібне квантування за таблицею вище. Для більшості — Qwen3-14B-Q4_K_M.gguf.

Крок 4. Завантажте через Ollama напряму:

ollama run hf.co/bartowski/Qwen3-14B-GGUF:Q4_K_M

Або через CLI Hugging Face:

pip install huggingface_hub
huggingface-cli download bartowski/Qwen3-14B-GGUF --include "Qwen3-14B-Q4_K_M.gguf"

Перевірити квантизацію вже завантаженої моделі в Ollama:

ollama show qwen3:14b

У виводі шукайте рядок quantization — там буде вказано тип (наприклад, Q4_K_M).

Запам'ятайте: не завантажуйте GGUF від невідомих авторів без перевірки картки моделі. Поганий imatrix робить IQ-кванти гіршими за звичайні K-кванти. Три надійних джерела — bartowski, mradermacher, TheBloke.

Типові помилки при виборі квантизації

• Брати Q2 або Q3 заради маленького розміру. Нижче Q4 якість руйнується нерівномірно: модель може зв'язно говорити, але «втрачати логіку» в середині відповіді. Краще взяти меншу модель у Q4, ніж більшу в Q2.
• Завантажувати Q8 на залізо без запасу VRAM. Q8 не просто займає більше пам'яті — він ще й повільніший. Якщо модель ледве влізає, Q8 дасть суопінг і фактично менше токенів/с, ніж Q4_K_M.
• Плутати параметри моделі та квантування. «14B Q4» і «7B Q8» — це дуже різні речі. Параметри (7B/14B/70B) впливають на якість набагато більше, ніж рівень квантування.
• Ігнорувати KV-кеш при розрахунку пам'яті. Модель 8.5 ГБ на 12 ГБ VRAM здається нормою. Але при контексті 32K KV-кеш може додати ще 4–6 ГБ — і система зависне.
• Брати IQ-кванти без перевірки imatrix-джерела. IQ4_XS від невідомого автора без калібрувального датасету може поступатися Q4_K_M. Перевіряйте картку моделі на наявність imatrix.
• Повторне квантування вже квантованої моделі. Якщо ви берете Q8_0 файл і квантуєте його в Q4 — похибки накопичуються. Завжди квантуйте з оригінального FP16.

Часті запитання

Що означає Q4 у назві моделі?

Q4 означає, що кожна вага моделі стиснута приблизно до 4 біт (замість 16 у FP16). Це скорочує розмір файлу приблизно в 3–4 рази при збереженні ~92–95% якості.

Що краще: Q4 чи Q8?

Залежить від задачі. Для чату, перекладу та написання текстів — Q4_K_M достатньо. Для коду, математики та агентів — Q5_K_M або Q8_0 помітно кращі. Але пам'ятайте: більша модель у Q4 зазвичай краща за меншу модель у Q8.

Чи варто використовувати Q2 або Q3?

Ні, якщо є альтернатива. Q2 і Q3 дають суттєву деградацію логіки. Краще взяти меншу модель (3B або 7B) у Q4_K_M — вона буде і якіснішою, і швидшою.

Яка квантизація найкраща для Ollama?

Q4_K_M — стандарт за замовчуванням для Ollama і правильний вибір для більшості користувачів. Якщо є запас пам'яті та задачі пов'язані з кодом — Q5_K_M.

Чи впливає квантування на швидкість генерації?

Так. Q8_0 генерує токени на ~29% повільніше за Q4_K_M через більший обсяг зчитуваних даних. LLM-генерація обмежена пропускною здатністю пам'яті, а не обчисленнями.

Чому 70B у Q4 краща за 7B у Q8?

Тому що кількість параметрів моделі впливає на якість набагато більше, ніж рівень квантування. 70B модель із 40 ГБ у Q4 і 7B модель із 7.7 ГБ у Q8 — перша переможе на переважній більшості задач.

Що таке IQ4_XS і чим відрізняється від Q4_K_M?

IQ4_XS використовує importance matrix — попередній аналіз, які ваги найважливіші. Результат: файл на ~5% менший при схожій якості. Але вимагає якісного imatrix-файлу від перевіреного автора. Без нього IQ4_XS може поступатися Q4_K_M.

Як квантування впливає на довгий контекст?

Безпосередньо — ні. Але при довгому контексті KV-кеш займає багато пам'яті. Встановіть OLLAMA_KV_CACHE_TYPE=q8_0 — це скоротить KV-буфер на 47% без помітної втрати якості.

Де брати перевірені GGUF-файли?

Особисто я завжди починаю з двох джерел: bartowski — найактивніший завантажувач у 2026, публікує imatrix-кванти з детальною документацією одразу після виходу нових моделей, і mradermacher — команда з широким покриттям моделей, також включає imatrix. TheBloke — класичний архів, але вже практично не оновлюється: для нових моделей краще одразу шукати у bartowski або mradermacher.

Чи можна змінити квантування вже завантаженої моделі?

Ні — без перекомпіляції. Можна тільки завантажити інший GGUF-файл з потрібним квантуванням. Важливо: не квантуйте з вже квантованого файлу (наприклад, Q8 → Q4) — похибки накопичуються. Завжди квантуйте з FP16.

Читайте також

• Топ-10 моделей Ollama 2026 — яку модель вибрати після того як визначились з квантизацією
• Як запустити GGUF з Hugging Face в Ollama — покроковий гайд із командами
• Ollama 0.30: GGUF, Vulkan і прискорення NVIDIA — що нового у зв'язці з llama.cpp
• Ollama REST API: Java, Python, JavaScript — як підключити локальну модель до проєкту