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 GB	~4,5 GB
70B	~140 GB	~39 GB

Това е аритметика, а не бенчмарк на производител. Обхваща само теглата. Кешът KV и допълнителните разходи на средата за изпълнение добавят още.

1. Пълна точност: safetensors и PyTorch .bin

Неквантизираните модели обикновено се разпространяват с 16-битови тегла във формат pytorch_model.bin или model.safetensors.

По-старите файлове .bin / .pt използват Python pickle. Зареждането на pickle файл може да изпълни произволен код, което превръща ненадеждните контролни точки в риск за сигурността.

Safetensors, създаден от Hugging Face, премахва този риск. Файлът представлява малък JSON хедър плюс необработени буфери с тензори, без изпълнимо съдържание. Тензорите могат да се зареждат чрез memory mapping и един по един, без да се прочита целият файл. 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 GB
Q8_0	5,9584	+0,03%	7,0 GB
Q6_K	5,9642	+0,13%	5,5 GB
Q5_K_M	5,9796	+0,39%	4,8 GB
Q4_K_M	6,0565	+1,68%	4,1 GB

Само за илюстрация. Тези числа са от модел 7B от епохата около 2023 г.; по-новите модели може да реагират различно.

Матрица на важността (imatrix)

GGUF квантизацията може да използва калибрационни данни. llama-imatrix на llama.cpp изчислява матрица на важността от текстов файл. След това 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 A100 GPU часа.
• Много ниски битрейтове: Llama-3.1-70B запазва кохерентността си при 1,6 бита на тегло. С изходен слой с 3 бита и кеш от 4 096 токена той се побира в под 16 GB 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 GB, като се запазва производителността на 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	Метод + оформление	Необходима	Потребителски NVIDIA GPU	ExLlamaV2, TabbyAPI
EXL3	Метод + оформление	Вградена в конвертирането	Потребителски NVIDIA GPU	ExLlamaV3, TabbyAPI
bitsandbytes NF4	Метод в движение	Няма	NVIDIA (и Intel) GPU	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.
• Един потребител, потребителски NVIDIA GPU, максимален брой токени в секунда: 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: справочник за квантизацията — 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/