GGUF проти GPTQ проти AWQ проти EXL2: пояснення форматів моделей LLM (2026)

Спочатку розділіть 2 поняття: контейнери та методи квантування

Більшість плутанини виникає через змішування 2 рівнів.

Контейнер визначає, як тензори зберігаються на диску. Метод квантування визначає, як ваги стискаються до меншої кількості бітів.

• Контейнери: safetensors, GGUF, PyTorch pickle (.bin / .pt).
• Методи: GPTQ, AWQ, bitsandbytes NF4, K-кванти та I-кванти llama.cpp.
• Обидва одночасно: EXL2 і EXL3 — це метод плюс структура зберігання, прив’язана до однієї бібліотеки інференсу.

Швидке емпіричне правило для запам’ятовування

Пам’ять для ваг ≈ кількість параметрів × кількість бітів на вагу ÷ 8.

Модель	16 біт	~4,5 біта на вагу
8B	~16 ГБ	~4,5 ГБ
70B	~140 ГБ	~39 ГБ

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

1. Повна точність: safetensors і PyTorch .bin

Неквантовані моделі зазвичай постачаються з 16-бітними вагами у файлах pytorch_model.bin або model.safetensors.

Старіші файли .bin / .pt використовують Python pickle. Завантаження pickle-файлу може виконати довільний код, що створює ризик для безпеки під час роботи з ненадійними контрольними точками.

Safetensors, створений на Hugging Face, усуває цей ризик. Файл складається з невеликого JSON-заголовка та необроблених буферів тензорів, без будь-чого виконуваного всередині. Тензори можна відображати в пам’ять і завантажувати по одному, не читаючи весь файл. Safetensors тепер зазначений як проєкт PyTorch Foundation.

Важливий нюанс: більшість моделей GPTQ, AWQ, EXL2, EXL3 і MLX також зберігаються у файлах .safetensors. Квантування міститься у вмісті тензорів і конфігураційному файлі, а не в новому контейнері.

2. GGUF (llama.cpp)

Що це таке

GGUF — це бінарний формат для запуску моделей із GGML і виконавцями на основі GGML, такими як llama.cpp. Його створив Georgi Gerganov, який також очолює llama.cpp (документація Hugging Face). Його представили 21 серпня 2023 року як заміну старішому формату GGML.

Чому він замінив GGML

Старіші файли GGML, GGMF і GGJT не могли вказати, до якої архітектури належить модель. Додавання нового гіперпараметра ламало кожен наявний файл. GGUF перейшов на типізовані метадані у форматі ключ-значення, тому нові поля можна додавати без порушення роботи старих файлів.

Цілі дизайну

Специфікація визначає 5 цілей: розгортання в одному файлі, розширюваність, сумісність із mmap, просте завантаження та повнота інформації всередині файлу. На відміну від форматів, що містять лише тензори, GGUF може зберігати токенізатор, спеціальні токени та шаблон чату Jinja разом із вагами.

Як читати назви квантувань GGUF

Суфікс у назві на кшталт Q4_K_M.gguf повідомляє про схему. Наведені нижче цифри взято з документації Hugging Face щодо GGUF.

Тип	Принцип роботи	Бітів на вагу
Q4_0 / Q4_1 (застарілі)	Округлення до найближчого значення з точністю 4 біти в блоках по 32 ваги; Q4_1 додає мінімум блоку	4,5 / 5,0*
Q8_0 (застаріле позначення)	Округлення до найближчого значення з точністю 8 біт у блоках по 32 ваги	8,5*
Q2_K	16 блоків × 16 ваг на суперблок, 4-бітні масштаби та мінімуми	2,625
Q3_K	16 блоків × 16 ваг, 6-бітні масштаби	3,4375
Q4_K	8 блоків × 32 ваги, 6-бітні масштаби та мінімуми	4,5
Q5_K	8 блоків × 32 ваги, 6-бітні масштаби та мінімуми	5,5
Q6_K	16 блоків × 16 ваг, 8-бітні масштаби	6,5625
IQ4_XS	Суперблоки по 256 ваг, використовується матриця важливості	4,25
IQ3_XXS	Та сама родина I-квантів	3,06
IQ2_XXS	Та сама родина I-квантів	2,06
IQ1_S	Та сама родина I-квантів	1,56

*Розраховано вручну, у таблиці HF не зазначено: 32 ваги плюс 16-бітний масштаб (і 16-бітний мінімум для Q4_1).

Перевірка математики Q4_K: суперблок містить 256 ваг. 256 × 4 біти = 1 024 біти. Додаємо 8 блоків × 12 бітів масштабів і мінімумів (96 бітів). Додаємо 16-бітний супер-масштаб і 16-бітний супер-мінімум (32 біти). Разом: 1 152 ÷ 256 = 4,5 біта на вагу.

Що означають _S, _M, _L: це комбінації, а не нові типи. Наприклад, llama.cpp описує Q4_K_M як такий, що використовує Q6_K для половини тензорів attention.wv і feed_forward.w2, а Q4_K — для решти (документація Unsloth). Саме тому файл Q4_K_M у середньому має понад 4,5 біта на вагу.

Новіші типи: таблиця HF також містить TQ1_0 і TQ2_0 для тернарних ваг, а також MXFP4 — 4-бітний тип чисел із мікромасштабуванням.

Особливість маркування: Hugging Face відносить файли Q8_0 до «застарілих» типів. На практиці Q8_0 залишається стандартним варіантом GGUF із майже безвтратною якістю.

Якість проти розміру

Еталонна таблиця Hugging Face для моделі класу Llama-2-7B демонструє цей компроміс:

Квант	Перплексія	Зміна порівняно з FP16	Розмір
FP16	5,9565	базовий рівень	13,0 ГБ
Q8_0	5,9584	+0,03%	7,0 ГБ
Q6_K	5,9642	+0,13%	5,5 ГБ
Q5_K_M	5,9796	+0,39%	4,8 ГБ
Q4_K_M	6,0565	+1,68%	4,1 ГБ

Лише для ілюстрації. Ці числа отримано для моделі епохи 2023 року з 7B параметрів; новіші моделі можуть реагувати інакше.

Матриця важливості (imatrix)

Квантування GGUF може використовувати калібрувальні дані. llama-imatrix обчислює матрицю важливості з текстового файлу. Потім llama-quantize --imatrix використовує її для покращення якості. Для 1- і 2-бітних комбінацій llama-quantize попереджає, якщо imatrix не надано.

Правила найменування

Специфікація визначає імена файлів як базову назву, позначення розміру, тонке налаштування, версію, кодування, тип і сегмент. Сегменти використовують 5-значний лічильник, наприклад 00003-of-00009. Необов’язкові префікси mmproj- і mtp- позначають проєктори зору та чернеткові модулі багатотокенного передбачення.

Де працює GGUF

GGUF є нативним для llama.cpp та її екосистеми. Hugging Face документує використання з llama.cpp, LM Studio, GPT4All і Ollama.

Підтримка vLLM існує, але обмежена. vLLM називає її надзвичайно експериментальною та неоптимізованою, а для GGUF тепер потрібен сторонній vllm-gguf-plugin.

3. GPTQ

GPTQ створили Elias Frantar (IST Austria), Saleh Ashkboos і Torsten Hoefler (ETH Zurich), а також Dan Alistarh (IST Austria & Neural Magic). Уперше метод з’явився на arXiv 31 жовтня 2022 року. Його опублікували на ICLR 2023.

Як це працює

GPTQ — це одноетапний метод квантування ваг після навчання. Він використовує наближену інформацію другого порядку (Гессіана), щоб визначити, як округлювати ваги. Помилка округлення в одному стовпці компенсується коригуванням ваг, які ще не квантувалися. Метод потребує невеликого калібрувального набору даних, але не потребує повторного навчання.

Основні результати

• Квантування моделей зі 175B параметрів приблизно за 4 години на GPU до 3 або 4 бітів на вагу (arXiv).
• Повідомлялося про незначну втрату точності за такої розрядності.
• Прискорення наскрізного виконання порівняно з FP16 приблизно у 3,25 раза на NVIDIA A100 і в 4,5 раза на A6000 (сторінка статті на HF).

Як читати назви GPTQ

Репозиторії GPTQ часто містять у назві GPTQ або позначення на кшталт 4bit-128g.

• Розмір групи (128g): один масштаб на кожні 128 ваг. Менші групи покращують точність, але трохи збільшують розмір.
• Порядок активацій (desc_act): стовпці квантуються в порядку важливості, що зазвичай покращує точність.

Стан інструментів у 2026 році

Оригінальна бібліотека AutoGPTQ більше не підтримується.

• GPTQModel зазначає, що повністю замінила AutoGPTQ і AutoAWQ для Transformers, Optimum і PEFT. Її результат працює в Transformers, vLLM і SGLang.
• llm-compressor також реалізує GPTQ, але зберігає результати у форматі compressed-tensors.
• Hugging Face оцінює калібрування GPTQ для моделі 8B приблизно у 20 хвилин на 1 A100.

4. AWQ

AWQ (Activation-aware Weight Quantization, квантування ваг з урахуванням активацій) походить від групи Song Han у MIT. Уперше метод з’явився на arXiv 1 червня 2023 року. Він отримав нагороду MLSys 2024 за найкращу статтю.

Основна ідея

Не всі ваги однаково важливі. Захист приблизно 1% «значущих» ваг різко зменшує помилку квантування.

Особливість: AWQ знаходить ці значущі канали, аналізуючи величини активацій, а не самі ваги.

Метод не зберігає ці канали з вищою точністю. Натомість він масштабує їх за допомогою математично еквівалентного перетворення, зберігаючи однорідний формат, зручний для апаратного забезпечення. AWQ не використовує зворотне поширення чи реконструкцію, тому має меншу ймовірність перенавчитися на своєму калібрувальному наборі.

Швидкість і вартість

• Середовище виконання TinyChat зі статті працювало більш ніж у 3 рази швидше за реалізацію Hugging Face у FP16 на настільних і мобільних GPU.
• Hugging Face оцінює калібрування AWQ для моделі 8B у приблизно 10 хвилин на 1 A100 — близько половини оцінки для GPTQ.

Стан інструментів у 2026 році

• AutoAWQ офіційно визнано застарілим. Останньою протестованою конфігурацією були Torch 2.6.0 і Transformers 4.51.3.
• vLLM інтегрував цю функціональність у llm-compressor, який тепер є рекомендованим робочим процесом для AWQ.
• MLX-LM також підтримує AWQ на Apple Silicon.

5. EXL2 (ExLlamaV2)

Що це таке

EXL2 — це нативний формат ExLlamaV2, бібліотеки інференсу від turboderp для споживчих GPU. Він використовує той самий метод оптимізації, що й GPTQ, і підтримує квантування на 2, 3, 4, 5, 6 та 8 біт.

Чим він відрізняється

• Будь-яка середня бітова швидкість від 2 до 8 бітів на вагу: рівні квантування можна комбінувати між шарами та всередині них.
• Комбінування на рівні стовпців: важливішим стовпцям усередині шару можна призначити більше бітів.
• Автоматичний розподіл: конвертер квантує кожну матрицю кількома способами та вимірює помилку щодо калібрувальних даних. Потім він обирає налаштування, які мінімізують найгіршу помилку, дотримуючись цільової бітової швидкості.

Саме тому файли EXL2 мають назви на кшталт 4.65bpw, а не 4-bit.

Середовище виконання

TabbyAPI є офіційно рекомендованим сервером і надає API, сумісний з OpenAI. EXL2 перейменовує деякі тензори, щоб кожна модель внутрішньо виглядала як варіант Llama. Через це EXL2 складно повторно використовувати в інших фреймворках.

6. EXL3 (ExLlamaV3)

Що це таке

EXL3 — це формат-наступник, створений на основі QTIP від Cornell RelaxML. QTIP використовує квантування з кодуванням за ґраткою та обробкою некогерентності й був представлений на NeurIPS 2024.

EXL3 зберігає процедурну кодову книгу QTIP і ґратчасте кодування. Він змінює спосіб регуляризації та пакування тензорів.

Чому це важливо

• Просте перетворення: ви вказуєте модель Hugging Face і цільову бітову швидкість. Гессіани обчислюються на льоту під час перетворення (README).
• Помірна вартість: перетворення займає хвилини для малих моделей і кілька годин для моделей 70B+ на 1 GPU класу RTX 4090. Для порівняння, у README зазначено, що AQLM для моделі 70B потребує близько 720 годин роботи GPU A100.
• Дуже низька бітова швидкість: Llama-3.1-70B зберігає зв’язність за 1,6 біта на вагу. З вихідним шаром на 3 біти та кешем на 4 096 токенів вона вміщується менш ніж у 16 ГБ VRAM.
• Портативна структура: EXL3 значною мірою зберігає оригінальну структуру тензорів, на відміну від EXL2.

Функції

ExLlamaV3 додає 2–8-бітне квантування кешу KV, тензорний і експертний паралельний інференс, спекулятивне декодування, мультимодальну підтримку та плагін Transformers. Останні випуски додають вивантаження на CPU для великих MoE-моделей.

Примітка щодо апаратного забезпечення: ExLlamaV3 потребує CUDA 12.4 або новішої версії. У README підтримку ROCm зазначено як завдання на майбутнє.

7. bitsandbytes (NF4 / INT8): квантування під час завантаження

bitsandbytes зазвичай не завантажують у вигляді попередньо квантованої моделі. Ви завантажуєте 16-бітну модель і квантуєте її на льоту.

Його 4-бітний режим походить від QLoRA:

• NF4 (4-бітний NormalFloat): тип даних, розроблений для нормально розподілених ваг.
• Подвійне квантування: самі константи квантування квантуються, щоб заощадити більше пам’яті.
• Результат: тонке налаштування моделі 65B на одному GPU обсягом 48 ГБ із показниками, що відповідають тонкому налаштуванню у 16-бітному режимі.

Рекомендації Hugging Face:

• Калібрувальний набір даних не потрібен.
• Прискорення інференсу не гарантоване.
• Це залишається стандартним шляхом для тонкого налаштування QLoRA через PEFT.

8. MLX (Apple Silicon)

MLX-LM — це пакет Python для запуску й тонкого налаштування LLM на Apple Silicon за допомогою MLX. MLX походить від Apple Machine Learning Research.

Моделі MLX є файлами safetensors зі специфічними для MLX квантованими вагами. mlx_lm.convert з параметром -q квантує модель Hugging Face і може завантажити її до організації mlx-community.

На Mac і GGUF (через llama.cpp), і MLX є сильними варіантами.

9. Інші назви, які вам траплятимуться

• compressed-tensors / FP8: Формат на диску, який записує llm-compressor. Він охоплює FP8, схеми INT4/INT8 лише для ваг, NVFP4 і розрідженість. Для повної реалізації переваг FP8 потрібне новіше обладнання, наприклад NVIDIA H100/H200/B100 або AMD MI300 (довідник понять).
• HQQ: швидке квантування без калібрування від 8 до 1 біта. Нижче 4 бітів точність може різко падати.
• SINQ: ще один метод без калібрування, що працює на льоту і тепер представлений у Transformers.
• AQLM, SpQR, VPTQ, HIGGS: дослідницькі методи, що просувають квантування нижче 2 бітів на вагу.

Порівняльна таблиця

Формат	Що це таке	Калібрування	Найкраще апаратне забезпечення	Основні середовища виконання
Safetensors (16-біт)	Контейнер	Немає	GPU з достатнім обсягом VRAM	Transformers, vLLM, SGLang
GGUF	Контейнер + типи квантування	Необов’язкове (imatrix)	CPU, Apple Silicon, розподіл CPU+GPU	llama.cpp, Ollama, LM Studio
GPTQ	Метод (у safetensors)	Потрібне	GPU	vLLM, SGLang, Transformers
AWQ	Метод (у safetensors)	Потрібне	GPU	vLLM, SGLang, Transformers
EXL2	Метод + структура	Потрібне	Споживчі GPU NVIDIA	ExLlamaV2, TabbyAPI
EXL3	Метод + структура	Вбудоване в перетворення	Споживчі GPU NVIDIA	ExLlamaV3, TabbyAPI
bitsandbytes NF4	Метод на льоту	Немає	GPU NVIDIA (та Intel)	Transformers, PEFT
MLX	Метод (у safetensors)	За замовчуванням немає	Apple Silicon	MLX-LM

---

Що обрати?

• Mac, лише CPU або модель, більша за обсяг VRAM: GGUF. Почніть із Q4_K_M; переходьте на Q5_K_M або Q6_K, якщо пам’ять дозволяє.
• Обслуговування багатьох користувачів на серверних GPU: AWQ або GPTQ у vLLM/SGLang чи FP8 на картах класу Hopper/Blackwell.
• Один користувач, споживчі GPU NVIDIA, максимальна кількість токенів за секунду: EXL3 через TabbyAPI (EXL2 для старіших конфігурацій).
• Тонке налаштування з обмеженим бюджетом: bitsandbytes NF4 із QLoRA.
• Apple Silicon із робочим процесом Python або для тонкого налаштування: MLX.

Основні висновки

• Формат файлу (GGUF, safetensors) — це не те саме, що метод квантування (GPTQ, AWQ).
• GGUF є стандартним варіантом для CPU, Apple Silicon і локального інференсу зі змішаним використанням CPU+GPU.
• GPTQ і AWQ — основні 4-бітні методи для обслуговування GPU-моделей у vLLM, SGLang і Transformers.
• EXL2 і EXL3 орієнтовані на швидкий інференс для одного користувача та гнучкі бітові швидкості на споживчих GPU.
• AutoGPTQ і AutoAWQ більше не підтримуються; натомість використовуйте GPTQModel або llm-compressor.

---

Джерела:

Специфікації та офіційна документація

• Специфікація GGUF — https://github.com/ggml-org/ggml/blob/master/docs/gguf.md
• Hugging Face Hub: GGUF — https://huggingface.co/docs/hub/gguf
• README imatrix llama.cpp — https://github.com/ggml-org/llama.cpp/blob/master/tools/imatrix/README.md
• README quantize llama.cpp — https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md
• Документація Qwen: квантування llama.cpp — https://qwen.readthedocs.io/en/latest/quantization/llama.cpp.html
• Документація Unsloth: збереження у GGUF — https://unsloth.ai/docs/basics/inference-and-deployment/saving-to-gguf
• Hugging Face skills: довідник із квантування — https://github.com/huggingface/skills/blob/main/skills/huggingface-local-models/references/quantization.md
• vLLM: GGUF — https://docs.vllm.ai/en/latest/features/quantization/gguf/
• vLLM: AutoAWQ — https://docs.vllm.ai/en/stable/features/quantization/auto_awq/
• vLLM RFC #30136 (застарілі формати квантування) — https://github.com/vllm-project/vllm/issues/30136
• llm-compressor — https://github.com/vllm-project/llm-compressor
• llm-compressor: збереження моделі — https://docs.vllm.ai/projects/llm-compressor/en/latest/guides/saving_a_model/
• Transformers: вибір методу квантування — https://huggingface.co/docs/transformers/quantization/selecting
• Transformers: поняття квантування — https://huggingface.co/docs/transformers/quantization/concept_guide
• Safetensors — https://github.com/safetensors/safetensors
• PyTorch Foundation: Safetensors — https://pytorch.org/projects/safetensors/
• Hugging Face Hub: MLX — https://huggingface.co/docs/hub/en/mlx

Статті

• GPTQ (arXiv 2210.17323) — https://arxiv.org/abs/2210.17323
• Офіційний код GPTQ (ICLR 2023) — https://github.com/ist-daslab/gptq
• AWQ (arXiv 2306.00978) — https://arxiv.org/abs/2306.00978
• AWQ (MLSys 2024) — https://proceedings.mlsys.org/paper_files/paper/2024/hash/42a452cbafa9dd64e9ba4aa95cc1ef21-Abstract-Conference.html
• QLoRA (arXiv 2305.14314) — https://arxiv.org/abs/2305.14314
• QTIP (arXiv 2406.11235) — https://arxiv.org/abs/2406.11235

Бібліотеки

• ExLlamaV2 — https://github.com/turboderp-org/exllamav2
• ExLlamaV3 — https://github.com/turboderp-org/exllamav3
• Нотатки щодо формату EXL3 — https://github.com/turboderp-org/exllamav3/blob/master/doc/exl3.md
• GPTQModel — https://github.com/ModelCloud/GPTQModel
• AutoAWQ (застаріла) — https://pypi.org/project/autoawq/
• MLX-LM — https://github.com/ml-explore/mlx-lm

Обговорення спільноти

• Обговорення форматів моделей на r/LocalLLaMA — https://www.reddit.com/r/LocalLLaMA/comments/1ayd4xr/for_those_who_dont_know_what_different_model/