量化方法与评测：从 PTQ/QAT 到可复现实验

量化方法不该按名字背诵，而应按它控制的误差点来理解：权重舍入与补偿、重要通道保护、activation outlier 迁移或重排、训练中适应低精度噪声，以及 KV Cache 状态压缩。

选定方法只是开始。一个方案还必须分别通过执行真实性、模型质量、容量收益和性能收益四道门；任何一道门都不能替代另外三道。

1. 先按控制点分类

1.1 Weight-only PTQ

Weight-only 方案保留较高精度激活，典型写法是 W4A16。

方法	核心控制点	需要校准数据	典型特点
RTN	直接 round-to-nearest	否	最简单基线，能暴露算法本身带来的增益
GPTQ	近似二阶信息与逐列误差补偿	是	逐层重构，常用于 3/4 bit 权重
AWQ	根据激活统计保护重要权重通道	是	不做反向传播，强调硬件友好的 weight-only
AQLM 等 codebook 方法	多码本重构权重	是	更低 bit/weight，但 runtime 和 Kernel 更专用

Weight-only 的主要收益是：

• Checkpoint 和常驻权重变小；
• Decode 读取权重的流量下降；
• 能容纳更大 Batch 或把模型放到更少 GPU。

它不自动意味着 Prefill 低精度计算。某些 Kernel 会读取 INT4/FP4 权重后在片上解包，与高精度激活完成矩阵乘；具体收益取决于 Kernel。

1.2 Weight + Activation PTQ

激活是动态张量，并且更容易出现 outlier，因此 W8A8/W4A8 比 weight-only 更依赖分布处理。

方法	核心控制点	目标
SmoothQuant	等价缩放，把 activation outlier 难度迁移到权重	让 INT8 W8A8 更容易量化
QQQ 类 W4A8	smoothing + 权重误差补偿	同时降低权重和激活位宽
FP8 recipe	E4M3/E5M2 + current/delayed/block scaling	使用 FP8 Tensor Core
NVFP4 recipe	E2M1 + block/global hierarchical scaling	在 Blackwell 上实现更低位混合精度

这里的重点不是“位宽更低一定更快”，而是两个 operand 是否能直接进入目标低精度矩阵乘。

1.3 Rotation 与 Outlier 重排

QuaRot 等方法利用等价旋转改变 hidden state 和权重的数值分布，在不改变高精度函数的前提下减少 outlier，使权重、激活和 KV 更容易量化。

这类方法的验收不能只看 PPL：

• Rotation 是否被离线吸收到权重？
• 运行时是否增加额外 Hadamard/rotation Kernel？
• 新增 Kernel 是否抵消低精度收益？
• 长上下文和 Attention 敏感路径是否仍然合格？

1.4 QAT

QAT 在训练或微调时模拟低精度前向，让模型参数适应量化误差。它适合 PTQ 难以维持质量的极低位场景，但成本包括：

• 训练数据和训练算力；
• 稳定的 fake-quant / STE 或低精度训练配方；
• 与目标 Kernel 一致的 Scale、block 和累加假设；
• 重新完成模型质量与安全评测。

QAT 的优势是模型可以适应噪声，不代表任意 QAT Checkpoint 都能被目标引擎高效执行。

1.5 KV Cache 量化

KV quant 改变的是长期状态，不是模型权重。它的实验身份至少包括值格式、Scale 粒度与来源、敏感层例外，以及 Attention backend 是否直接消费低精度状态。kv_cache_dtype=fp8 只是入口配置，不能独自定义可比较 Case。

2. 方法名不能直接排序

“AWQ 一定优于 GPTQ”或“FP8 一定无损”都不是稳定结论。量化质量是多变量函数：

$$Q_{\mathrm{loss}} = f( \text{model}, \text{task}, \text{bitwidth}, \text{granularity}, \text{calibration}, \text{excluded layers}, \text{runtime} )$$

至少要固定：

• 模型、revision、tokenizer 与 chat template；
• 量化对象、格式、group/block size、zero-point；
• 校准数据的来源、数量、长度和随机种子；
• 不量化的层；
• 推理引擎、Kernel backend 和硬件；
• 解码参数和评测数据。

论文中的某个速度或质量数字只对论文的 Case 成立，不能直接成为另一个模型或引擎的预期收益。

3. G1：执行真实性

第一道门不是“能启动”，而是证明运行时执行了预期路径。

需要保留的证据

证据	回答什么问题
Checkpoint config	声明了什么 quantization recipe
Engine config readback	引擎实际接受了哪些配置
Load log	是否重打包、展开、跳过层或 fallback
Kernel trace	operand dtype、Q/DQ、cast 与实际 Kernel
HBM readback	常驻权重是否仍是压缩格式

建议为每个实验输出一条规范化身份：

model@revision
+ quant_recipe@revision
+ engine@version
+ kernel_backend
+ gpu_arch
+ TP/PP/EP

若 Kernel 路径无法证明，结果只能标记为“模型可加载”，不能标记为“低精度执行已验证”。

CPU 与 GPU 的工具不同，但都要从配置声明走到实际指令、数据移动和端到端结果；完整的 perf/IBS → GPU trace 映射由CPU 工程师理解量化统一维护。

4. G2：模型质量

4.1 不要只看一个 PPL

PPL 是快速回归信号，但不能代表完整能力。建议至少覆盖：

维度	指标或数据	目的
Language modeling	WikiText/C4 PPL	检查整体分布拟合漂移
知识与理解	MMLU 类任务	检查知识和选择题能力
数学/推理	GSM8K、数学集或内部 reasoning 集	极低位通常更容易暴露链式误差
代码	HumanEval/MBPP 或内部代码集	检查精确 token 序列能力
指令遵循	IFEval 或业务指令集	检查格式和约束执行
长上下文	Needle、长文 QA、真实长请求	检查 KV/Attention 误差随长度累积
业务样本	固定黄金集	决定是否满足真实上线标准

4.2 比较合同

• 高精度与量化模型使用相同 tokenizer、prompt template 和 decoding config。
• 对确定性任务固定随机种子或使用 greedy decode。
• 同时报告绝对分数和相对高精度基线的变化。
• 预先定义 acceptance budget，不能看完结果后再改阈值。
• 把“未运行”“运行失败”“不支持”和“质量不达标”分开记录。

5. G3：容量收益

容量结果至少拆成：

$$M_{\mathrm{peak}} = M_{\mathrm{weights}} + M_{\mathrm{scales}} + M_{\mathrm{KV}} + M_{\mathrm{activations}} + M_{\mathrm{workspace}} + M_{\mathrm{communication}}$$

建议同时报告：

• Checkpoint 大小；
• 加载后常驻权重 HBM；
• Scale/zero-point/padding；
• KV bytes/token/rank；
• 给定 Context 下可容纳的最大 Batch；
• 峰值 HBM，而不是只看 steady-state；
• TP/EP 下 per-rank 与 global 的区别。

如果权重下降但 workspace 或 runtime expansion 抵消了收益，应分别展示，而不是只给一个“节省百分比”。

6. G4：性能收益

6.1 Case 身份

性能比较必须固定以下字段：

model: exact checkpoint and revision
quantization: exact recipe and excluded layers
engine: name, version, commit, kernel backend
hardware: GPU SKU, count, topology, power mode
parallelism: TP, PP, EP, DP
workload: ISL, OSL, batch/concurrency, KV hit ratio
serving: scheduler, prefix cache, chunked prefill, speculative decoding
slo: TTFT and TPOT constraints

6.2 指标分层

层级	指标	用途
Capacity	峰值 HBM、最大 Batch	量化是否释放了可用容量
End-to-end	TTFT、TPOT、TPS/TPM、请求吞吐	产品是否真正受益
Phase	Prefill/decode time、queue wait	收益发生在哪个阶段
Kernel	GEMM/BMM/Attention/Q/DQ/cast 时间	解释为何达到或没达到理论值
Cost	GPU 数、功耗、tokens/成本	决定生产价值

6.3 Sweep 而不是单点

至少进行：

• ISL/OSL 分桶；
• Batch 或并发 sweep；
• 冷/热 KV Cache；
• Prefill 与 Decode 分阶段；
• 一个高精度基线和一个简单 RTN 基线；
• 多次重复并报告分位数。

单个 batch=1 TPS 不能代表吞吐，单个大 Batch 点也不能代表低延迟。

7. 推荐实验矩阵

变量	最小集合
Precision	BF16、FP8/W8A8、W4A16、目标 W4A8/FP4
Method	RTN、一个 weight-only PTQ、一个 activation-aware/W+A 方案
Workload	短 Prefill、长 Prefill、小 Batch Decode、大 Batch Decode
Context	2K、8K、32K 或业务 P50/P95
Quality	PPL + 2 个关键公开任务 + 业务黄金集
Runtime	至少记录 engine/kernel 版本与 trace 证据

最终结果表不应只写一个 speedup：

Case	Runtime verified	Quality	Peak HBM	TTFT	TPOT	TPS	Result state
BF16 baseline	yes	baseline	—	—	—	—	comparable
Quant recipe A	yes/no	Δ	—	—	—	—	comparable / fallback
Quant recipe B	yes/no	Δ	—	—	—	—	unsupported / failed

unsupported、failed、missing 和 not_comparable 都不能填成 0。

8. 选型边界

目标	优先研究	首要风险
小 Batch Decode / 显存不足	W4A16、W4A8、KV8	Kernel 解包、fallback、质量
Prefill 吞吐	FP8/W8A8/W4A8	激活 outlier、Tensor Core 命中
极低位端到端	Rotation、QAT、FP4 recipe	训练成本、Attention/KV 稳定性
CPU/边缘	GGUF/CPU 专用格式	GPU 结论不可迁移
长上下文	KV FP8、敏感层保留高精度	Scale 校准与误差累积
生产 serving	引擎原生 recipe + 可追溯 Kernel	版本兼容矩阵快速变化

框架支持是动态事实。以 vLLM 为例，AWQ、GPTQ、Marlin、FP8、bitsandbytes、GGUF 和不同硬件的兼容矩阵会随版本变化；正式部署应锁定版本并保存配置回读，不在文章里固化成永久能力表。

相关页面

• CPU 工程师理解量化 — perf/IBS 与 GPU trace 的证据映射
• 量化基础 — 对象、格式、Scale 与性能边界
• FP4/FP8 量化 — Current/Delayed/MXFP8/NVFP4 的 Scale 合同
• GLM-5.2 量化执行图 — 单模型算子级混合精度案例
• Compute-bound vs Memory-bound — 用 Roofline 解释不同阶段的收益
• Profiling 到 Simulation — 从运行证据到性能模型

参考资料

• GPTQ
• AWQ
• SmoothQuant
• QuaRot
• vLLM Quantization
• vLLM Quantized KV Cache