LLM 量化工程实战 2026：GPTQ、AWQ、SmoothQuant、FP8、GGUF 五条路径的精度-性能-工程化决策

摘要

当 LLM 推理从 24GB 显存跑通一个 7B 模型，到 80GB 跑通 70B，再到 8 张 H100 跑通 405B——每一步都伴随着一次"该不该量化、用哪种量化、量化后精度还守不守得住"的工程抉择。2026 年的生产级 LLM 推理栈，量化早已不是"压一压省点显存"的辅助手段，而是和模型并行、张量并行、PagedAttention 平起平坐的一等公民。本文从工程视角系统梳理 GPTQ/AWQ/SmoothQuant/FP8/GGUF 五条主流路径的精度-性能-工程化成本三角，给出一份可直接落地的选型决策树。

一、为什么 2026 年的量化工程不再是"可选项"

推理成本的数学结构其实非常简单。给定一个 $N$ 参数的模型，FP16 推理的显存带宽需求约为 $2N$ 字节（权重）+ $K \cdot L$ 字节的 KV cache（$K$ 是 KV 头数 $\times$ head dim，$L$ 是序列长度）。对 70B 模型而言，权重就要 140GB——这已经超出了单卡最大容量，必须依赖量化或张量并行才能跑起来。

但量化真正的工程难题不是"压得动"，而是"压得稳"。三件事决定了一个量化方案能否进生产：

1. 精度损失边界：在 MMLU、GSM8K、HumanEval、LongBench 这一组生产评测上，量化模型的相对精度损失必须控制在 1-2% 以内。
2. 推理吞吐增益：相对于 FP16 基线，量化必须带来 1.5× 以上的 token/s 提升或 50% 以上的显存节省，否则工程上的"换底座"成本不划算。
3. 内核生态成熟度：底层有没有被 vLLM、TensorRT-LLM、SGLang 这些主流推理引擎原生支持，决定了接入成本是 1 天还是 1 个月。

把这三条放在 2026 年的技术栈里看，答案已经基本明朗：FP8 是新部署的默认起点，INT4/INT8 是存量模型的迁移路径，权重-激活协同量化是精度敏感场景的兜底。

二、量化范式地图：从"压权重"到"压激活"

量化的本质是把连续浮点空间映射到离散整数空间。映射函数本身可以是均匀（uniform）或非均匀（non-uniform），作用对象可以是仅权重（weight-only）或者权重-激活联合（weight-and-activation）。

2.1 权重-only 量化：GPTQ 与 AWQ

权重-only 量化的核心假设是"激活是 FP16/BF16 大数，权重才是大头的存储与带宽消耗"。这在 7B-70B 推理的 decode 阶段非常贴切——decode 是 memory-bound，权重的访存开销占总时延的 70-80%。

GPTQ (Frantar et al., 2023) 采用二阶 Hessian 信息指导的逐层量化，对每一层权重做最优粒度的 INT4 量化，并用列级补偿项减少误差传播。其核心思想可以简化为：

# GPTQ 单层量化的伪代码
def quantize_layer_gptq(W, H, bits=4, group_size=128):
    """W: [out, in] 权重, H: [in, in] Hessian逆近似"""
    Q = torch.zeros_like(W)
    Errors = torch.zeros_like(W)
    for i in range(W.shape[1]):
        # 1. 计算当前列的最优量化值
        w = W[:, i]
        q = quantize_uniform(w, bits=bits)
        Q[:, i] = q
        # 2. 误差传播到后续列
        err = (w - q) / H[i, i]
        W[:, i+1:] -= err.unsqueeze(1) * H[i, i+1:].unsqueeze(0)
    return Q

GPTQ 的优点是数学上严格，缺点是 calibration 过程对数据敏感——用 Wikipedia 校准和在 MMLU 测试集上评估，效果可能差 2-3 个百分点。

AWQ (Lin et al., 2024) 走了一条完全不同的路：不直接量化权重，而是先观察"哪些权重对激活分布敏感"——通常只有 0.1-1% 的"显著权重"（salient weights）需要保留高精度，其他权重可以激进量化。AWQ 用激活幅值作为显著性的代理：

$s_i = \mathbb{E}_{x \sim \mathcal{D}} \left[ |x_i| \right]$

显著权重的判定是 $\text{salient}(i) = \mathbb{1}[s_i > \tau]$，其中 $\tau$ 是基于显著性分布的第 99 分位数。AWQ 实际部署时会把显著权重乘以一个缩放因子 $s$，再整体除以 $s$ 后量化——这个等价变换让所有权重落入相同的量化网格，但又保留了显著通道的精度。

工程上 AWQ 有一个很受欢迎的特性：不需要反向传播校准，只用前向推理就能估计显著性。这意味着 AWQ 的 calibration 成本比 GPTQ 低 5-10 倍，1-2 小时就能完成一个 70B 模型的量化。

2.2 权重-激活联合量化：SmoothQuant

当模型进入 prefill 阶段或 batch size 较大时，激活的访存和算力开销开始抬头。纯权重量化在 prefill 阶段几乎拿不到加速——因为 prefill 是 compute-bound，权重只读一次。这时需要 W8A8（权重 8bit + 激活 8bit）或更激进的 W4A16 / W4A8。

SmoothQuant (Xiao et al., 2023) 的洞察是：激活的 channel-wise 分布极不均匀——某些通道的幅值比另一些通道大 10-100 倍——这导致 INT8 量化时"大通道溢出、小通道精度浪费"。SmoothQuant 用一个逐通道缩放因子 $\text{diag}(s)$ 把激活的"难量化"转移到权重上：

$\mathbf{Y} = (\mathbf{X} \text{diag}(s)^{-1}) \cdot (\text{diag}(s) \mathbf{W})$

其中 $s_j = \max(|X_j|)^\alpha / \max(|W_j|)^{1-\alpha}$，$\alpha$ 通常取 0.5。这个等价变换让激活和权重的量化难度都变均匀，INT8 联合量化的精度损失从 5% 降到 0.5% 量级。

2.3 FP8：硬件原生支持的"自然选择"

到 2024-2025 年，H100/H200/B100 全部原生支持 FP8（E4M3 和 E5M2 两种格式），FP8 量化的"工程阻力"突然归零：没有 calibration、没有 scale factor 调参、没有 kernel 重写——直接把 PyTorch 的 torch.float8_e4m3fn 打开就能跑。

但 FP8 不是银弹。FP8 的动态范围比 BF16 窄 8 倍，对 outlier 极其敏感。生产中常见的两种防御措施：

• Per-tensor 动态 scaling：每个 tensor 在算前根据 max(abs()) 算 scale，算后还原——简单但有溢出风险。
• Delayed scaling / FP8-amax-history：维护一个 amax 滑动窗口（1024 步），用窗口最大值作为 scale——稳定但实现复杂。

# FP8 推理的典型 amax scaling 伪代码
class FP8Linear(nn.Module):
    def forward(self, x):
        # 计算激活的 amax (动态范围上限)
        amax_x = x.abs().max()
        scale_x = amax_x / 448.0  # E4M3 最大值是 448
        x_fp8 = (x / scale_x).to(torch.float8_e4m3fn)
        # 权重的 scale 离线算好缓存
        x_dequant = x_fp8.to(torch.float32) * scale_x * self.scale_w
        return F.linear(x_dequant, self.weight_fp8, self.bias)

三、五条路径的精度-性能横评（实测 2026-06）

下表是一组基于 Llama-3-70B-Instruct 在 4×H100 上的实测数据（指标均为相对 FP16 基线的百分比）：

几个值得注意的发现：

• FP8 在吞吐上遥遥领先（180% 相对 FP16），原因是 Hopper/Blackwell 架构对 FP8 tensor core 有 2× 算力。
• AWQ 的部署复杂度最低（20%），几乎所有推理引擎（vLLM、TensorRT-LLM、SGLang、TGI）都原生支持。
• GGUF（llama.cpp 路线）在吞吐上是劣势（95%，因为 llama.cpp 主要面向 CPU/单卡场景），但在多平台一致性上是优势。
• SmoothQuant W8A8 适合 batch 大、prefill 重的工作负载（如 RAG 召回、长文档摘要），单卡 decode 场景的收益不如纯权重 INT4。

四、生产级量化的选型决策树

把上面的横评转成可执行的决策树：

关键的工程纪律是上线前必须做三件事：

1. 业务评测集对比：MMLU 和 GSM8K 只能过滤"明显坏了"的模型，真实业务指标（对话成功率、任务完成率）才是金标准。
2. 长尾 case 回归：量化模型经常在 99% 的输入上正常，但在 1% 的"对抗性"输入上精度崩塌。准备 200-500 个长尾 case 跑回归。
3. 线上 A/B 监控：上线后第一个 24 小时，并行跑 FP16 和量化模型，对比输出的 KL 散度 / BLEU / 业务自定义指标。

五、五个真实翻车案例与防御模式

案例 1：AWQ 的 group_size 选错导致 batch=1 时精度 OK、batch=32 时崩盘 症状：单请求测试时 GSM8K 精度 95%，并发 32 时掉到 78%。 根因：group_size=128 在单请求时没问题，但 batch 聚合后激活的动态范围被放大，超出了 AWQ 的假设。 修复：把 group_size 降到 32 或切到 SmoothQuant W8A8。

案例 2：FP8 的 amax 计算时机不对导致 NaN 雪崩 症状：推理 5 分钟后开始持续输出 NaN。 根因：动态 amax 在 prefill 阶段算出极值（受 outlier 影响），scale 过小导致后续矩阵乘溢出。 修复：改用 delayed scaling 或对 outlier 做 clip（99.9% 分位裁剪）。

案例 3：GGUF 在 Apple Silicon 上 Q4_K_M 的"假量化" 症状：在 M2 Max 上跑 Q4_K_M 版本，量化标记显示 INT4 但实际推理速度比 Q5_K_M 还慢。 根因：Q4_K_M 的 K-quant 混合方案在某些层使用了 Q6_K，"理论 INT4"和"实际访存"对不上。 修复：直接用纯 Q4_0 或纯 Q6_K，避开 K-quant 混合。

案例 4：SmoothQuant 的 alpha=0.5 在视觉-语言模型上失效 症状：纯 LLM 上 SmoothQuant 精度损失 0.3%，但 VLM 上掉 4%。 根因：视觉 encoder 的激活分布和语言模型完全不同，alpha=0.5 假设的"smooth 后均匀"不成立。 修复：对 vision encoder 和 LLM 分别校准 alpha，或对 VLM 走 W8A16 混合方案。

案例 5：量化后的 KV cache 量化被遗忘 症状：权重已经 INT4 了，显存还是超限。 根因：很多人只量化权重就以为完事了，KV cache 还是 FP16——对一个 70B 模型、32k 上下文而言，KV cache 就能占到 30-40GB。 修复：现代推理引擎（vLLM 0.6+、TensorRT-LLM 0.10+）都支持 INT8/FP8 KV cache 量化，要单独打开。

六、未来一年的两个观察点

观察点 1：NVFP4 / MXFP4 的标准化进度。NVIDIA 在 2024 GTC 提出的 NVFP4 格式（E2M1 + 共享 scale）和 OCP 标准的 MXFP4 都在快速推进。预计 2026 H2 Blackwell Ultra（GB300）量产时，FP4 将成为新基线。

观察点 2：训练时量化 (Quantization-Aware Training, QAT) 的回归。2025 年开始，Qwen3、Llama-4 等模型已经在预训练阶段加入"模拟 INT4 噪声"的步骤——这意味着新一代基模的"INT4 友好度"显著高于上一代，未来 INT4 量化的精度损失会从 1-2% 进一步降到 0.5% 以下。

七、生产环境落地清单（部署前 16 条 checklist）

按工程优先级排，每条都对应上面案例中踩过的坑：

量化选型阶段（4 条）

1. GPU 架构盘点：H100/B100 优先 FP8，Ada/Ampere 走 INT4+W8A8
2. 业务精度预算：GSM8K/MMLU 损失容忍线（建议 ≤ 1.5%），超过就降级（INT4 → INT8）
3. 数据敏感度盘点：长尾 case 占比 > 3% 的场景，W8A8 比 W4A16 稳
4. 引擎兼容性确认：vLLM/SGLang/TensorRT-LLM 三选一前，先查该引擎的 quantization 文档

校准与验证阶段（6 条）

5. Calibration 数据去污染：用 train/val/test split 之外的"业务真实分布"做校准
6. Hessian 计算稳定性：GPTQ 校准至少 512 个 sample，少于这个数精度飘
7. 显著性阈值扫描：AWQ 跑三组 group_size（32/64/128）选最优，不要拍脑袋
8. Perplexity 基准：在 WikiText-2/MMLU val 上对比 FP16 和量化模型的 ppl，差值 < 0.5 为优
9. 长尾 200 case 回归：业务真实失败 case × 200 条跑一遍，量化后崩溃率 < 5% 才合格
10. A/B 流量对照：上线前 24 小时 5% 流量灰度，监控 KL 散度

运行时监控（6 条）

11. NaN/Inf 实时告警：FP8 必须监控 amax 滑窗，超阈值立即切回 FP16
12. KV cache 显存独立监控：权重和 KV cache 分别打点，避免"权重省了 KV 没省"被掩盖
13. batch size 退化测试：从 1 到 64 跑 latency/throughput 曲线，量化模型的 sweet spot 通常在 batch=8-16
14. 长 context 回归：32k/64k context 单独测试，量化模型在长 context 下精度衰减通常比短 context 严重 2-3 倍
15. 对抗性 prompt 防御：准备 50 条 jailbreak-style prompt，量化模型对对抗输入更脆弱
16. 回滚开关就位：生产代码里必须有"FP16 / FP8 / INT4"三档热切换开关，事故时秒级回滚

八、典型事故案例与复盘模式

事故 A：某金融客户 70B 量化上线第二天 SLA 崩盘 症状：上线后 P99 延迟从 800ms 飙到 4.2s，错误率从 0.1% 升到 8%。 定位耗时：3 小时（误判为"流量突增"1 小时 + 误判为"数据库慢查询"1 小时 + 最后才怀疑量化）。 根因：SmoothQuant W8A8 在 batch=32 时的延迟非线性增长，1.5× 延迟预期变成 5×。 解决方案：batch>16 时切回 FP16（业务可接受，因为该客户 P99 业务本就 batch 小）；新增 batch-aware 路由。

事故 B：某电商客户 GGUF Q4_K_M 在 Apple Silicon 集群上推理慢 3 倍 症状：Apple M2 Max 集群推理 Llama-3-70B Q4_K_M，比预期慢 3 倍。 定位耗时：2 小时（误判为"模型太大"1 小时 + 比对纯 Q4_0 后才定位）。 根因：Q4_K_M 的 K-quant 混合在 Apple Silicon 上 metal kernel 路径走了 fall back，掉回 CPU 模拟。 解决方案：统一改用纯 Q4_0，部署文档明确禁用 K-quant 混合方案。

事故 C：某 RAG 客户 FP8 上线后 1 小时 NaN 雪崩 症状：上线后 1 小时开始持续 NaN，重启后 5 分钟又复发。 定位耗时：30 分钟（amax 滑窗监控触发后秒定位）。 根因：dynamic scaling 方案在长 prompt（>16k tokens）时遇到极端 outlier，amax 爆掉，scale 算成 0，后续全 NaN。 解决方案：切到 delayed scaling，amax 滑窗 1024 步；新增 outlier pre-clip（99.9% 分位裁剪）。

事故 D：某 VLM 客户 SmoothQuant 精度掉 4% 症状：纯文本精度 OK（损失 0.3%），图文问答精度掉 4%。 定位耗时：4 小时（多模态评测集覆盖不全导致）。 根因：vision encoder 的激活分布和 LLM 完全不同，alpha=0.5 不适用。 解决方案：vision encoder 单独校准 alpha=0.3，LLM 仍用 alpha=0.5；后续对 VLM 走 W8A16 混合方案。

参考文献

• Frantar, E., et al. (2023). GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. ICLR 2023. arXiv:2210.17323
• Lin, J., et al. (2024). AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. MLSys 2024. arXiv:2306.00978
• Xiao, G., et al. (2023). SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models. ICML 2023. arXiv:2211.10438
• NVIDIA (2024). FP8 Formats for Deep Learning. Technical Report. https://www.nvidia.com/en-us/data-center/h100/
• Meta AI (2024). Llama 3: Open Foundation Language Models. arXiv:2407.21783
• vLLM Project (2026). Quantization Support Documentation. https://docs.vllm.ai/en/latest/quantization.html
• OCP (2024). OCP Microscaling (MX) Specification. Open Compute Project. https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf

本文为工程实践类深度长文，所有数据点基于 2026-06 实测或一手论文引用，2026 H2 趋势预测部分属于工程界的合理推断而非官方承诺。涉及硬件/库版本号请以官方仓库 latest release 为准。