详细解析 GGUF、GPTQ、AWQ、EXL2、EXL3 等格式的区别,涵盖每权位数、量化校准和硬件适配,并给出 Mac、消费级 GPU 和生产环境的格式选择建议。
先把两个概念分开:容器与量化方法
大多数混淆来自于把两个层次混为一谈。
容器定义了张量在磁盘上如何存储。量化方法定义了权重如何被压缩到更少的位数。
容器:safetensors、GGUF、PyTorch pickle(.bin / .pt)。
量化方法:GPTQ、AWQ、bitsandbytes NF4、llama.cpp K-quants 和 I-quants。
两者兼而有之:EXL2 和 EXL3 既是一种方法,也是一种绑定到特定推理库存储布局的格式。
一条简单的内存经验法则
权重内存 ≈ 参数数 × 每权重位数 ÷ 8。
| Model | 16-bit | ~4.5 bits per weight |
|---|---|---|
| 8B | ~16 GB | ~4.5 GB |
| 70B | ~140 GB | ~39 GB |
这是算术运算,不是厂商的基准测试。只涵盖权重。KV cache 和运行时开销会在这基础上增加更多。
未量化模型通常以 16 位权重发布,格式为 pytorch_model.bin 或 model.safetensors。
较早的 .bin / .pt 文件使用 Python pickle。加载 pickle 文件可以执行任意代码,这使得不可信的 checkpoint 成为一个安全风险。
Safetensors 由 Hugging Face 创建,消除了这种风险。一个文件由一个小的 JSON 头加上原始张量缓冲区组成,内部没有任何可执行内容。张量可以通过内存映射加载,一次加载一个,而无需读取整个文件。Safetensors 现在已被列为 PyTorch Foundation 项目。
一个重要的细节:大多数 GPTQ、AWQ、EXL2、EXL3 和 MLX 模型也存储在 .safetensors 文件中。量化内容在张量内容和一个配置文件中,而不是在一个新的容器中。
GGUF 是一个用于通过 GGML 和基于 GGML 的执行器(如 llama.cpp)运行模型的二进制格式。它由 Georgi Gerganov 创建,后者也是 llama.cpp 的主导者(Hugging Face 文档)。它于 2023 年 8 月 21 日推出,作为旧版 GGML 格式的替代品。
较旧的 GGML、GGMF 和 GGJT 文件无法说明一个模型属于哪种架构。添加新的超参数会破坏每个现有文件。GGUF 切换到类型化键值元数据,因此可以添加新字段而不会破坏旧文件。
该规范列出了 5 个目标:单文件部署、可扩展性、mmap 兼容性、易于加载以及文件内的完整信息。与仅张量格式不同,GGUF 可以携带分词器、特殊 token 和 Jinja 聊天模板以及权重。
像 Q4_K_M.gguf 这样的名称中的后缀告诉了你方案类型。以下数据来自 Hugging Face GGUF 文档。
| Type | How it works | Bits per weight |
|---|---|---|
| Q4_0 / Q4_1 (legacy) | 4-bit round-to-nearest in 32-weight blocks; Q4_1 adds a block minimum | 4.5 / 5.0* |
| Q8_0 (legacy label) | 8-bit round-to-nearest in 32-weight blocks | 8.5* |
| Q2_K | 16 blocks × 16 weights per super-block, 4-bit scales and mins | 2.625 |
| Q3_K | 16 blocks × 16 weights, 6-bit scales | 3.4375 |
| Q4_K | 8 blocks × 32 weights, 6-bit scales and mins | 4.5 |
| Q5_K | 8 blocks × 32 weights, 6-bit scales and mins | 5.5 |
| Q6_K | 16 blocks × 16 weights, 8-bit scales | 6.5625 |
| IQ4_XS | 256-weight super-blocks, uses an importance matrix | 4.25 |
| IQ3_XXS | Same I-quant family | 3.06 |
| IQ2_XXS | Same I-quant family | 2.06 |
| IQ1_S | Same I-quant family | 1.56 |
*通过手工推导,未列入 HF 表格:32 个权重加一个 16 位 scale(Q4_1 还有一个 16 位 minimum)。
验证 Q4_K 的计算:一个 super-block 持有 256 个权重。256 × 4 位 = 1,024 位。加上 8 个块 × 12 位的 scales 和 minimums(96 位)。加上一个 16 位 super-scale 和 16 位 super-minimum(32 位)。总计:1,152 ÷ 256 = 4.5 位每权重。
_S、_M、_L 是什么意思:这些是混合,不是新类型。例如,llama.cpp 描述 Q4_K_M 对一半的 attention.wv 和 feed_forward.w2 张量使用 Q6_K,其余使用 Q4_K(Unsloth 文档)。这就是为什么 Q4_K_M 文件平均超过 4.5 位每权重。
较新的类型:HF 表格还列出了用于三值权重的 TQ1_0 和 TQ2_0,以及 MXFP4,一种 4 位微缩浮点类型。
一个标签特点:Hugging Face 将 Q8_0 标记为"legacy"类型。实际上,Q8_0 仍然是标准的近无损 GGUF 选择。
Hugging Face 的 Llama-2-7B 类模型参考表格显示了权衡:
| Quant | Perplexity | Change vs FP16 | Size |
|---|---|---|---|
| FP16 | 5.9565 | baseline | 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 |
仅供参考。这些数字来自 2023 年代的 7B 模型;较新的模型可能有不同的反应。
GGUF 量化可以使用校准数据。llama.cpp 的 llama-imatrix 从一个文本文件计算重要性矩阵。然后 llama-quantize --imatrix 使用它来提高质量。对于 1 位和 2 位混合,如果未提供 imatrix,llama-quantize 会发出警告。
规范定义文件名为:基础名称、大小标签、微调版本、版本、编码、类型和分片。分片使用 5 位计数器,如 00003-of-00009。可选的 mmproj- 和 mtp- 前缀标记视觉投影器和多 token 预测草稿模块。
GGUF 是 llama.cpp 及其生态系统 native 的格式。Hugging Face 文档将其与 llama.cpp、LM Studio、GPT4All 和 Ollama 一起使用。
vLLM 支持存在但有限。vLLM 称其高度实验性且未优化,GGUF 现在需要 out-of-tree 的 vllm-gguf-plugin。
GPTQ 由 Elias Frantar(IST Austria)、Saleh Ashkboos 和 Torsten Hoefler(ETH Zurich)以及 Dan Alistarh(IST Austria & Neural Magic)编写。它于 2022 年 10 月 31 日首次出现在 arXiv 上。它在 ICLR 2023 上发表。
GPTQ 是一种一次性训练后权重量化方法。它使用近似的二阶(Hessian)信息来决定如何对权重进行舍入。一列中的舍入误差通过调整尚未量化的权重来补偿。它需要一个小的校准数据集但不需要重新训练。
在约 4 个 GPU 小时内将 175B 参数模型量化到每权重 3 或 4 位(arXiv)。
报告称在这些位宽下准确率损失可以忽略不计。
在 NVIDIA A100 上比 FP16 快约 3.25 倍,在 A6000 上快约 4.5 倍(HF 论文第页)。
GPTQ 仓库的名称中通常包含 GPTQ 或 4bit-128g 等标签。
Group size(128g):每 128 个权重一个 scale。较小的组提高准确率但略微增加大小。
Act-order(desc_act):按重要性顺序对列进行量化,通常会提高准确率。
原始 AutoGPTQ 库不再维护。
GPTQModel 声称已完全取代 Transformers、Optimum 和 PEFT 的 AutoGPTQ 和 AutoAWQ。其输出可在 Transformers、vLLM 和 SGLang 中运行。
llm-compressor 也实现了 GPTQ,但以 compressed-tensors 格式保存结果。
Hugging Face 估计在 1 张 A100 上对 8B 模型进行 GPTQ 校准大约需要 20 分钟。
AWQ(Activation-aware Weight Quantization)来自 MIT 的 Song Han 团队。它于 2023 年 6 月 1 日首次出现在 arXiv 上。它获得了 MLSys 2024 最佳论文奖。
并非所有权重都同等重要。保护大约 1% 的"显著"权重会大幅降低量化误差。
巧妙之处:AWQ 通过查看激活幅度(而非权重本身)来找到那些显著通道。
它不以更高精度存储这些通道。相反,它通过数学上等价的变换将它们放大,保持统一、对硬件友好的格式。AWQ 不使用反向传播或重构,因此不太可能过拟合其校准集。
论文的 TinyChat 运行时在桌面和移动 GPU 上比 Hugging Face FP16 实现快 3 倍以上。
Hugging Face 估计在 1 张 A100 上对 8B 模型进行 AWQ 校准大约需要 10 分钟,大约是 GPTQ 估计的一半。
AutoAWQ 已被正式废弃。其最后测试的配置是 Torch 2.6.0 和 Transformers 4.51.3。
vLLM 将功能合并到 llm-compressor 中,现在是推荐的 AWQ 工作流程。
MLX-LM 也在 Apple Silicon 上支持 AWQ。
EXL2 是 ExLlamaV2 的 native 格式,ExLlamaV2 是 turboderp 为消费级 GPU 开发的推理库。它使用与 GPTQ 相同的优化方法,支持 2、3、4、5、6 和 8 位量化。
任意平均位速率从 2 到 8 位每权重:量化级别可以在层之间和层内混合。
列级混合:层内更重要的列可以获得更多位数。
自动分配:转换器以多种方式量化每个矩阵,并测量与校准数据的误差。然后它选择能够最小化最坏情况误差同时达到目标位速率的设置。
这就是为什么 EXL2 文件带有像 4.65bpw 这样的名称而不是 4 位。
TabbyAPI 是官方推荐的服务器,提供 OpenAI 兼容的 API。EXL2 重命名了一些张量,使每个模型在内部看起来像一个 Llama 变体。这使得 EXL2 难以在其他框架中重用。
EXL3 是后继格式,建立在 Cornell RelaxML 的 QTIP 之上。QTIP 使用栅格编码量化和不相干处理,并在 NeurIPS 2024 上发表。
EXL3 保留 QTIP 的程序化码本和栅格编码。它改变了张量的正则化方式和打包方式。
简单转换:你提供一个 Hugging Face 模型和目标位速率。Hessian 在转换期间动态计算(README)。
合理的成本:小型模型的转换需要几分钟,70B+ 在 1 张 RTX 4090 级 GPU 上需要几个小时。相比之下,README 说 AQLM 在 70B 模型上大约需要 720 张 A100 GPU 小时。
非常低的位速率:Llama-3.1-70B 在每权重 1.6 位时保持连贯。通过 3 位输出层和 4,096 token 的缓存,它可以装在 16 GB 以下的 VRAM 中。
可移植布局:EXL3 大部分保持原始张量结构,与 EXL2 不同。
ExLlamaV3 添加了 2–8 位 KV-cache 量化、张量并行和专家并行推理、投机解码、多模态支持以及 Transformers 插件。最新版本为大型 MoE 模型添加了 CPU 卸载。
硬件注意:ExLlamaV3 需要 CUDA 12.4 或更高版本。其 README 将 ROCm 支持列为待办事项。
bitsandbytes 通常不是你下载预量化的东西。你加载一个 16 位模型并即时量化它。
其 4 位模式来自 QLoRA:
NF4(4 位 NormalFloat):一种为正态分布权重设计的数据类型。
双重量化:量化常量本身被量化以节省更多内存。
结果:在单张 48 GB GPU 上微调 65B 模型,同时匹配 16 位微调性能。
Hugging Face 的指导:
不需要校准数据集。
不保证推理加速。
它仍然是通过 PEFT 进行 QLoRA 微调的标准路径。
MLX-LM 是一个用于在 Apple Silicon 上运行和微调 LLM 的 Python 包,使用 MLX。MLX 来自 Apple Machine Learning Research。
MLX 模型是带有 MLX 特定量化权重的 safetensors。mlx_lm.convert 带 -q 量化一个 Hugging Face 模型并可以将其上传到 mlx-community 组织。
在 Mac 上,GGUF(通过 llama.cpp)和 MLX 都是强选项。
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 位的研究方法。
| Format | What it is | Calibration | Best hardware | Main runtimes |
|---|---|---|---|---|
| Safetensors (16-bit) | Container | None | GPUs with enough VRAM | Transformers, vLLM, SGLang |
| GGUF | Container + quant types | Optional (imatrix) | CPU, Apple Silicon, CPU+GPU split | llama.cpp, Ollama, LM Studio |
| GPTQ | Method (in safetensors) | Required | GPUs | vLLM, SGLang, Transformers |
| AWQ | Method (in safetensors) | Required | GPUs | vLLM, SGLang, Transformers |
| EXL2 | Method + layout | Required | Consumer NVIDIA GPUs | ExLlamaV2, TabbyAPI |
| EXL3 | Method + layout | Built into conversion | Consumer NVIDIA GPUs | ExLlamaV3, TabbyAPI |
| bitsandbytes NF4 | On-the-fly method | None | NVIDIA (and Intel) GPUs | Transformers, PEFT |
| MLX | Method (in safetensors) | None by default | Apple Silicon | MLX-LM |
Mac、仅 CPU 或大于 VRAM 的模型:GGUF。从 Q4_K_M 开始;如果内存允许,移至 Q5_K_M 或 Q6_K。
在数据中心 GPU 上为许多用户服务:vLLM/SGLang 中的 AWQ 或 GPTQ,或在 Hopper/Blackwell 级卡上使用 FP8。
一个用户、消费级 NVIDIA GPU、最大化每秒 token 数:通过 TabbyAPI 使用 EXL3(较旧设置使用 EXL2)。
预算有限的微调:bitsandbytes NF4 配合 QLoRA。
Apple Silicon 配合 Python 工作流或微调:MLX。
文件格式(GGUF、safetensors)与量化方法(GPTQ、AWQ)不是同一回事。
GGUF 是 CPU、Apple Silicon 和混合 CPU+GPU 本地推理的默认格式。
GPTQ 和 AWQ 是 vLLM、SGLang 和 Transformers 中 GPU 服务的事实标准 4 位方法。
EXL2 和 EXL3 针对消费级 GPU 上的快速单用户推理和细粒度位速率。
AutoGPTQ 和 AutoAWQ 已不再维护;改用 GPTQModel 或 llm-compressor。
GGUF specification — https://github.com/ggml-org/ggml/blob/master/docs/gguf.md
Hugging Face Hub: GGUF — https://huggingface.co/docs/hub/gguf
llama.cpp imatrix README — https://github.com/ggml-org/llama.cpp/blob/master/tools/imatrix/README.md
llama.cpp quantize README — https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md
Qwen docs: llama.cpp quantization — https://qwen.readthedocs.io/en/latest/quantization/llama.cpp.html
Unsloth docs: saving to GGUF — https://unsloth.ai/docs/basics/inference-and-deployment/saving-to-gguf
Hugging Face skills: quantization reference — 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 (legacy quantization formats) — https://github.com/vllm-project/vllm/issues/30136
llm-compressor — https://github.com/vllm-project/llm-compressor
llm-compressor: saving a model — https://docs.vllm.ai/projects/llm-compressor/en/latest/guides/saving_a_model/
Transformers: selecting a quantization method — https://huggingface.co/docs/transformers/quantization/selecting
Transformers: quantization concepts — 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 official code (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 format notes — https://github.com/turboderp-org/exllamav3/blob/master/doc/exl3.md
GPTQModel — https://github.com/ModelCloud/GPTQModel
AutoAWQ (deprecated) — https://pypi.org/project/autoawq/
MLX-LM — https://github.com/ml-explore/mlx-lm
r/LocalLLaMA thread on model formats — https://www.reddit.com/r/LocalLLaMA/comments/1ayd4xr/for_those_who_dont_know_what_different_model/