LLM Quantization Engineering：生产推理不能只看位宽

为什么 LLM 量化不能只看“几 bit”

很多团队第一次做 LLM 推理优化，会把量化理解成一个简单问题：把 FP16/BF16 模型压成 INT8、INT4 或 FP8，然后比较显存是否下降、速度是否变快。

这个理解只对了一半。量化确实能降低模型权重、activation 或 KV cache 的内存与带宽压力，但生产环境真正的问题是：压缩掉的精度是否刚好落在业务可以承受的范围内。

同样是 4-bit，不同方法、不同 kernel、不同硬件、不同 calibration dataset、不同任务类型，最终效果可能完全不同。一个在摘要任务上稳定的量化模型，可能在数学推理、代码生成、JSON 工具调用或长上下文检索上出现明显退化。

因此，生产级量化不是模型压缩技巧，而是一套推理工程流程。

一句话理解 LLM Quantization Engineering

LLM 量化工程可以理解为：在尽量保持任务质量的前提下，把模型推理中的高精度数值表示转换为更低精度表示，并通过硬件 kernel、校准数据、评测集和回滚机制控制风险。

Baseline FP16 / BF16 Model → Calibration → Quantization Format Selection → Serving Engine Export → Hardware Kernel Validation → Quality + Latency Benchmark → Canary Rollout → Monitoring and Rollback

它的目标不是最低 bit，而是找到满足业务 SLO 的最低总成本点。

核心知识结构

可以把 LLM 量化拆成 6 个模块。

1. Weight-only Quantization

Weight-only quantization 只量化模型权重，activation 通常仍保持 FP16/BF16。这类方法常见于 INT4、INT8、AWQ、GPTQ。

它的优点是落地相对容易，能明显减少模型权重显存占用。缺点是如果硬件 kernel 支持不好，实际速度收益可能不如预期。

2. Weight-Activation Quantization

Weight-activation quantization 同时量化权重和 activation，例如 W8A8、W4A8、FP8。它能进一步降低计算和带宽压力，但更依赖 calibration、硬件支持和推理框架实现。

3. KV Cache Quantization

KV cache 量化关注的是生成过程中保存的 key/value 缓存。长上下文、高 batch、高并发服务中，KV cache 可能成为显存瓶颈。降低 KV cache 精度可以扩大上下文或并发空间，但必须验证长上下文任务是否稳定。

4. Calibration Dataset

Post-training quantization 通常需要用代表性数据估计 activation 范围、权重缩放和量化参数。校准数据如果偏离真实业务流量，量化模型可能在上线后出现质量回归。

5. Hardware Kernel

量化格式只有被硬件和 serving engine 高效支持，才会转化为真实收益。INT4、FP8、FP4、KV cache quantization 都依赖具体 GPU 架构、kernel 和推理框架。

6. Regression Evaluation

量化评测不能只看 perplexity 或单个 benchmark。生产系统需要覆盖真实任务、结构化输出、RAG、代码、数学、长上下文、工具调用和安全样本。

AWQ、GPTQ、SmoothQuant 分别解决什么问题

AWQ：保护重要权重通道

AWQ 的核心观察是：不是所有权重对模型输出同等重要。它利用 activation 分布识别更关键的权重通道，并通过缩放降低这些通道的量化误差。

它适合需要低 bit weight-only 量化、希望保持 instruction-tuned 模型泛化能力的场景。典型形式是 W4A16：权重量化到 4-bit，activation 仍保持较高精度。

GPTQ：用二阶信息做 one-shot 压缩

GPTQ 是经典 post-training weight quantization 方法。它使用近似二阶信息，在不重新训练模型的情况下逐层量化权重，并尽量补偿量化误差。

它适合离线准备量化 checkpoint，再部署到支持 GPTQ kernel 的推理引擎中。

SmoothQuant：处理 activation outlier

LLM 中 activation outlier 是 INT8 weight-activation 量化的主要难点。SmoothQuant 的思路是把 activation 的量化难度迁移到 weight 上，通过等价变换让 activation 更容易量化，从而支持 W8A8 推理。

它更适合希望同时降低计算和内存压力，并且硬件对 INT8 / W8A8 有良好支持的场景。

为什么硬件决定量化收益上限

同样一个量化模型，在不同硬件和 serving engine 上可能表现差异很大。原因是量化收益不只来自模型更小，还来自低精度计算是否被硬件原生支持、kernel 是否高效、batch 形状是否适配。

常见误区包括：

误区	现实
模型文件变小 = 推理一定更快	需要硬件 kernel 才能真正加速
INT4 = 一定比 INT8 更好	取决于任务质量损失和 kernel 支持
FP8 = 所有 GPU 都能高效跑	仅较新架构有原生 FP8 支持
量化后显存下降 = 吞吐一定提升	需考虑 batch 形状和调度策略
benchmark 变好 = 业务质量一定不下降	业务样本分布可能与 benchmark 不同

更准确的判断方式是：

量化格式 × GPU 架构 × kernel 实现 × workload shape × 质量阈值

例如，weight-only INT4 可能显著降低显存，但如果 decode 阶段 kernel 没有很好利用 INT4 计算，速度收益可能主要来自更低内存带宽压力，而不是完整计算加速。FP8 在较新 GPU 上通常更有潜力，但也需要推理框架支持对应 kernel。

典型量化上线流程

生产量化流程建议按下面步骤执行：

1. 建立 FP16 / BF16 baseline
2. 收集真实业务 calibration dataset
3. 选择候选量化格式：AWQ、GPTQ、SmoothQuant、FP8、INT4、KV cache quantization
4. 导出量化 checkpoint 或 serving engine artifact
5. 验证硬件与 kernel 兼容性
6. 跑离线质量评测和性能 benchmark
7. 做小流量 canary rollout
8. 监控质量、延迟、成本和错误分布
9. 若出现关键指标回退，自动切回 baseline

这里最容易被跳过的是第 2、6、8、9 步。很多量化失败不是方法本身不行，而是没有用真实业务样本校准和回归。

评测指标：不要只看显存和 tokens/s

量化模型至少要评估 8 类指标。

1. Memory Footprint

包括模型权重显存、KV cache 显存、activation 峰值、batch 扩大后的显存压力。

2. TTFT

Time To First Token 受 prefill、模型加载、cache、kernel 和 batch 调度影响。量化模型如果需要额外 dequantize，TTFT 不一定总是下降。

3. TPOT / ITL

Time Per Output Token 或 Inter-Token Latency 更能反映流式生成体验。权重量化和 KV cache 量化都会影响 decode 阶段表现。

4. Throughput

吞吐要按真实 batch、真实 prompt length、真实 output length 测试，而不是只用固定 synthetic benchmark。

5. Task Quality

至少覆盖问答、摘要、RAG、代码、数学、工具调用、结构化输出等任务。

6. Long Context Stability

如果启用 KV cache quantization，必须单独测试长上下文检索、needle-in-a-haystack、长文档问答和多轮对话。

7. Format Reliability

很多业务依赖 JSON、YAML、SQL、代码 diff、函数调用参数。量化可能让格式稳定性下降，必须单独统计 schema pass rate。

8. Regression Delta

不要只看量化模型的绝对分数，而要看它相对 FP16/BF16 baseline 的下降是否在阈值内。

一个简化监控结构如下：

metrics:
  baseline_model: llama-3.1-70b-bf16
  quantized_model: llama-3.1-70b-awq-int4
  gpu_memory_reduction: 0.48
  ttft_ms_p95_delta: -0.18
  tpot_ms_p95_delta: -0.22
  throughput_delta: 0.36
  rag_accuracy_delta: -0.01
  json_schema_pass_rate_delta: -0.004
  math_accuracy_delta: -0.035
  rollback_required: false

Calibration Dataset：量化质量的隐形决定因素

Post-training quantization 通常不需要完整训练，但仍需要校准。校准数据的作用是让量化算法看到真实 activation 分布和典型输入形态。

一个差的校准集可能只有通用网页文本，而真实业务是：

• 长合同条款
• 代码仓库上下文
• 客服多轮对话
• 表格 + 文本混合文档
• JSON 工具调用轨迹
• 数学推理步骤

这种偏差会导致量化参数在真实任务上不稳定。

更合理的 calibration dataset 应该包含：

• 高频业务 prompt
• 长上下文样本
• 结构化输出样本
• 工具调用样本
• RAG 检索上下文样本
• 代码和数学样本
• 中英文混合样本
• 边界长度样本

校准集不一定要很大，但必须代表真实 workload。

什么时候优先选择哪类量化

场景	推荐量化策略	关键考量
显存装不下模型	Weight-only INT4 / INT8（AWQ、GPTQ）	先让模型能部署，扩大 batch 或降低实例数
高吞吐在线服务	FP8、W8A8、W4A8	确认 GPU 和引擎有高效 kernel 支持
长上下文或高并发	KV cache quantization	瓶颈可能在 KV cache 而非模型权重
高风险业务	保守策略，非关键链路先量化	金融、医疗、法律等保留高精度模型
边缘设备或本地推理	INT4、INT3、GGUF 等本地格式	评估设备 CPU/GPU/NPU 的 kernel 支持

常见失败模式

1. 只用通用 benchmark 验证：MMLU 或 perplexity 只能提供部分信号。业务系统还需要验证格式、引用、工具、拒答、长上下文和实际用户样本。

2. 没有保留 baseline：量化上线后如果没有 FP16/BF16 基线，就很难判断质量下降来自量化、模型版本、prompt 还是检索变更。

3. 忽略少数关键任务：整体平均分不变，不代表高风险任务稳定。数学、代码、合规判断、结构化输出可能更敏感。

4. 只看模型权重显存：真实推理还包括 KV cache、activation、batch 调度、LoRA adapter、prefix cache 等显存占用。

5. 没有灰度和回滚：量化模型应像新模型一样发布。直接全量替换会放大质量回归风险。

生产落地 Checklist

上线前建议检查：

• 是否建立 FP16/BF16 baseline
• 是否明确目标：省显存、降成本、降 TTFT、提升吞吐，还是扩大上下文
• 是否选择与硬件和 serving engine 匹配的量化格式
• 是否使用真实业务样本做 calibration
• 是否分别评估 AWQ、GPTQ、SmoothQuant、FP8、KV cache quantization 等候选
• 是否测试 TTFT、TPOT、吞吐、显存和成本
• 是否测试 RAG、代码、数学、工具调用和结构化输出
• 是否单独测试长上下文和 KV cache 压力
• 是否统计 schema pass rate 和 refusal accuracy
• 是否有 canary rollout、异常告警和快速回滚
• 是否记录量化版本、校准数据版本和推理引擎版本
• 是否在模型、prompt、retriever、kernel 或硬件变更后重新跑回归测试

结论

LLM 量化的本质，不是把模型尽可能压低 bit，而是在可接受质量损失内，降低推理系统的总成本。

• AWQ / GPTQ 解决权重显存和带宽问题
• SmoothQuant / FP8 解决 weight-activation 计算效率问题
• KV cache quantization 解决长上下文和高并发内存问题
• Calibration 决定量化参数是否贴近真实业务
• Hardware kernel 决定理论压缩是否变成真实加速
• Regression evaluation 决定量化模型是否可以上线

对工程团队来说，最实用的原则是：先用业务指标定义“能接受的质量损失”，再选择量化格式和硬件路径。不要让“4-bit”这样的标签替代完整的上线验证。

只有当量化格式、校准数据、硬件 kernel、评测集、灰度和回滚形成闭环时，LLM Quantization 才能从模型压缩技巧变成可靠的生产推理基础设施。