力 力达云
教程聚合APItoken成本国产模型资讯工具关于内测申请
← 返回资讯

模型量化怎么选：GGUF、AWQ、GPTQ 对比与选型指南

2026-07-08

量化是在有限显存上跑更大模型的核心手段。把一个 70B FP16 模型从 140GB 压缩到 35GB，就可以在两张 A100 而非四张上运行，成本直接减半。但量化方案不止一种——GGUF、AWQ、GPTQ 各有适用场景，选错方案会导致推理变慢、精度损失超预期，或者根本跑不起来。

我见过最常见的翻车场景是这样的：团队看别人博客说”INT4 量化省 70% 显存”，兴冲冲下了个 GPTQ 模型丢进 vLLM，结果启动报错 AssertionError: desc_act must be False for marlin kernel 或者干脆吞吐量比 FP16 还低。根子在于没搞清楚量化格式和推理框架、GPU 架构之间的匹配关系——量化不是”随便选一个压缩比最高的”，而是要按你的部署环境反推。这篇就把三种主流方案的底层差异、真实踩过的坑、怎么自查落地一次讲透。

三大量化方案速览

维度GGUF（llama.cpp）AWQGPTQ
格式来源llama.cpp 项目论文 AWQ（MIT）论文 GPTQ（微软）
主要推理框架Ollama、llama.cppvLLM、LMDeploy、TGIvLLM、TGI、AutoGPTQ
CPU 推理原生支持基本不支持基本不支持
精度损失（vs FP16）中（取决于量化级别）小中
量化速度快（本地转换）慢（需校准数据集）慢（需校准数据集）
推理速度CPU 快，GPU 中GPU 快GPU 中，略慢于 AWQ
HuggingFace Hub 支持有（TheBloke 等社区发布）有有

GGUF：CPU 友好的本地量化格式

GGUF 是 llama.cpp 使用的权重格式，最大优势是支持 CPU 推理，在没有 GPU 或 GPU 显存不足时可以自动把部分权重放到内存（RAM）里推理——速度慢但能跑。

量化级别对照（以 7B 模型为例）：

级别文件大小（约）精度推荐程度
Q2_K~2.5 GB损失明显不推荐，仅极限场景
Q4_K_M~4.1 GB损失轻微日常首选
Q5_K_M~4.8 GB损失极小显存稍宽裕时选
Q6_K~5.5 GB接近无损追求精度时选
Q8_0~7 GB基本无损显存充裕时选

Q4_K_M 是 GGUF 生态下的事实标准推荐，在显存节省和精度之间取得最好平衡。

这里顺便说清楚 GGUF 命名里那串字母到底是什么意思，很多人一直没搞明白就在瞎选。Q4_K_M 拆开看：Q4 是基础量化位宽（4 bit），K 表示用的是”K-quant”分块量化方案（不是老版本的线性量化，精度更好），M 表示 medium——同一个 K 位宽下还分 S（small，压得更狠精度更低）、M（medium，均衡）、L（large，精度更高文件更大）。所以你会看到 Q4_K_S、Q4_K_M、Q4_K_L 这种变体，选型时只要记住：“先定 Q4 还是 Q5，再在同位宽里选 M 档打底，显存吃紧降 S，精度要求高升 L”，不用去纠结每一档具体差多少个百分点的困惑度（perplexity），差异通常在 1% 以内，肉眼很难感知。

适合 GGUF 的场景：

  • 用 Ollama 或 llama.cpp 本地跑模型
  • 没有独立 GPU 或 GPU 显存不足
  • 开发者个人测试，对速度要求不高

AWQ：GPU 推理首选量化方案

AWQ（Activation-aware Weight Quantization）的核心思想是：不是所有权重对精度的贡献都相等——找到”激活值较大”的权重通道保持更高精度，其余部分积极压缩。

展开讲讲为什么这么设计有效。传统量化（比如朴素的 per-tensor INT4）把一层里所有权重按同一套 scale 压缩，问题是：模型里有一小撮通道（业内叫 salient channel）的激活值明显偏大，这些通道哪怕只有轻微量化误差，传播到下一层也会被放大成明显的输出偏差。AWQ 的做法不是去精细量化这些通道本身（那样反而增加复杂度），而是反过来：先统计激活值分布找出这一小撮关键通道（通常占比不到 1%），给它们的权重乘以一个更大的 scale 因子再量化，等效于给这部分权重”腾出”更大的数值表示范围，从而把量化误差压下去；对应地，激活值也要除以同样的 scale 保持数学等价。整个过程只需要一小批校准数据统计激活值分布，不需要像 GPTQ 那样做逐层的二阶误差补偿计算，这也是 AWQ 量化速度通常比 GPTQ 略快、且不依赖具体校准样本内容的原因——换句话说，AWQ 对校准数据集的敏感度比 GPTQ 低，用什么通用语料校准结果都比较稳定。

主要优势：

  • 精度损失是 INT4 方案中最小的，优于同等位宽的 GPTQ
  • 推理速度快，GPU kernel 优化成熟
  • vLLM、LMDeploy、TGI 均原生支持

量化需要校准数据集（通常用 Pile、WikiText 等），耗时数分钟到数十分钟不等。大量开发者已将量化好的模型发布到 HuggingFace Hub（搜索模型名 + AWQ 即可找到），不必每次自己量化。

适合 AWQ 的场景：

  • 用 vLLM / LMDeploy 部署生产推理服务
  • 显存不足以加载 FP16 权重，需要 INT4 节省
  • 追求精度损失最小的 INT4 方案

GPTQ：老牌 GPU 量化方案

GPTQ 是最早流行的开源 INT4 量化方案，社区积累了大量预量化模型（TheBloke 在 Hub 上发布了数千个 GPTQ 模型）。

与 AWQ 的主要差异：

  • 精度：AWQ 通常略好于 GPTQ，两者差距不大
  • 速度：GPTQ 推理速度略慢于 AWQ（kernel 实现成熟度的差距）
  • 历史资源：GPTQ 模型资源更多，部分模型只有 GPTQ 版本

适合 GPTQ 的场景：

  • Hub 上找不到 AWQ 版本，只有 GPTQ 版本
  • 已有 GPTQ 工作流不想迁移
  • 用 AutoGPTQ 做量化实验

三个真实踩过的坑

选型只是第一步，真落地部署时下面这几个坑几乎人人都会撞一次，提前知道能省你几个小时排查时间。

坑一：GPU 架构不支持某些 kernel，报错却和量化本身无关。
在 T4、V100 这类较老的 GPU 上跑 AWQ 或 GPTQ 模型，vLLM 有时会报 RuntimeError: FP16 A matmul is not supported on GPUs with compute capability < 8.0 或者启动时卡在 marlin kernel 编译阶段半天没反应。根因是新版 AWQ/GPTQ 的高性能 kernel（marlin、exllama v2）依赖 Ampere 及以上架构（compute capability ≥ 8.0，也就是 A10/A100/RTX 30 系及以上），T4/V100 只能退回到较慢的 fallback kernel，甚至部分组合直接不支持。买卡或租卡前先确认 GPU 代际，别等模型下载量化完了才发现跑不起来。

坑二：量化模型的 tokenizer 版本和推理框架不匹配，输出乱码或截断。
有些 Hub 上的量化模型只上传了权重文件，配套的 tokenizer_config.json、special_tokens_map.json 版本和原始 FP16 模型对不上，加载后输出会出现重复 token、提前截断，或者中文输出变成一堆问号。排查方法很简单：始终从原始 FP16 模型仓库里拷贝 tokenizer 相关文件覆盖量化模型目录里的同名文件，而不是信任量化上传者打包的版本——这个坑在早期 GPTQ 模型上尤其常见。

坑三：显存”看起来”够但实际 OOM，是没算上 KV Cache 和激活值开销。
很多人算完权重显存刚好等于显卡容量就直接部署，结果并发请求一上来就 CUDA out of memory。量化只压缩了权重本身，推理时的 KV Cache（跟上下文长度和并发数成正比）、中间激活值这些开销并不会跟着等比例缩小。经验值是：权重显存之外，至少预留 20%–30% 作为 KV Cache 和运行时缓冲，长上下文或高并发场景要留得更多。具体怎么估算 KV Cache 占用，可以参考显存估算那篇的详细公式，这里不重复。

如何选量化方案

你用什么推理框架？
  ├── Ollama / llama.cpp → 选 GGUF（Q4_K_M 起步）
  └── vLLM / LMDeploy / TGI（GPU）
        ├── 追求精度最优 → AWQ（首选）
        └── Hub 上只有 GPTQ 版本 → GPTQ

显存节省对比（7B 模型）：

精度显存需求相比 FP16
FP16~14 GB基准
INT8（LLM.int8()）~7 GB节省 50%
AWQ/GPTQ INT4~4 GB节省 70%+
GGUF Q4_K_M~4 GB节省 70%+

常见问题

量化后对话质量会明显变差吗？
对大多数日常场景（对话、摘要、翻译、代码生成），INT4 量化的影响用户几乎感知不到。数学推理、复杂逻辑链等精度敏感任务可能有轻微下降。建议在你的实际业务数据上做评测后再决定。

AWQ 和 GPTQ 哪个量化速度更快？
两者都需要校准数据集，耗时相近（7B 模型通常 10–30 分钟）。如果 Hub 上已有现成的量化模型，直接下载远比自己量化省时间。

可以混合精度吗？比如部分层 FP16 部分层 INT4？
可以。bitsandbytes 的 LLM.int8() 就是混合精度的实现——对激活值较大的层保留 FP16，其余用 INT8，精度损失极低。但这种方案推理速度不如纯 AWQ/GPTQ 优化的 kernel。

显存充裕时有必要量化吗？
没有。FP16/BF16 精度最高，吞吐量通常也更好（不需要反量化开销）。量化是显存受限时的工具，不是追求更高吞吐的手段。

延伸阅读：