量化方法与评测:从 PTQ/QAT 到可复现实验
按控制点理解 GPTQ、AWQ、SmoothQuant、Rotation 与 QAT,并用执行真实性、质量、容量、性能四道门验收量化方案
摘要
量化方法不能只按名字背诵。真正有区分度的是它在控制什么误差:
- 改变权重舍入顺序与误差补偿;
- 保护重要权重通道;
- 把 activation outlier 迁移到权重;
- 用等价旋转重新分布 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 改变的是长期状态,不是模型权重。当前 vLLM 的 FP8 KV 路径已区分:
- per-tensor 与 per-attention-head Scale;
- 默认 Scale、运行时随机 token 校准、数据集校准;
- 对滑动窗口等敏感层做 skip;
- 部分 backend 可以让 Attention 直接在 FP8 domain 计算。
因此 kv_cache_dtype=fp8 只是入口配置,Scale 来源和 Attention backend 同样属于实验身份。
2. 方法名不能直接排序
“AWQ 一定优于 GPTQ”或“FP8 一定无损”都不是稳定结论。量化质量是多变量函数:
至少要固定:
- 模型、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 路径无法证明,结果只能标记为“模型可加载”,不能标记为“低精度执行已验证”。
3.1 从 perf/IBS 迁移到 GPU 证据
CPU 和 GPU 的工具不同,但问题结构相同:
| 证据问题 | CPU 侧 | GPU 侧 |
|---|---|---|
| 是否执行目标低精度路径 | disassembly、library verbose、PMU | Kernel 名、operand dtype、engine log |
| 是否受存储墙限制 | LLC miss、DRAM BW、IBS load latency | HBM throughput、L2、memory/SOL |
| 是否有 layout 转换 | reorder、unaligned/split load | cast、Q/DQ、repack、短转换 Kernel |
| 是否发生 fallback | scalar tail、generic primitive | 高精度替代 Kernel、pre-expand |
| 是否端到端受益 | cycles/request、QPS、P95 | TTFT、TPOT、TPS/TPM |
因此“模型配置里写了量化”类似“源码里用了 int8_t”:两者都不能替代实际指令和运行数据。完整迁移路径见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:容量收益
容量结果至少拆成:
建议同时报告:
- 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 和不同硬件的兼容矩阵会随版本变化;正式部署应锁定版本并保存配置回读,不在文章里固化成永久能力表。
9. 结论
- 方法名只是入口,真正要比较的是误差控制点和运行时合同。
- Weight-only、W+A、KV quant 与 QAT 解决的是不同问题。
- 质量评测必须包含 PPL 之外的任务、长上下文和业务样本。
- 容量、性能和质量是独立结果,不能用理论位宽互相推导。
- 只有完全固定 Case 身份并证明 Kernel 路径,速度比较才可信。
相关页面
- CPU 工程师理解量化 — perf/IBS 与 GPU trace 的证据映射
- 量化基础 — 对象、格式、Scale 与性能边界
- FP4/FP8 量化 — Current/Delayed/MXFP8/NVFP4 的 Scale 合同
- GLM-5.2 量化执行图 — 单模型算子级混合精度案例
- Compute-bound vs Memory-bound — 用 Roofline 解释不同阶段的收益
- Profiling 到 Simulation — 从运行证据到性能模型
参考资料
← 被以下页面引用(6)
- FP4/FP8 量化:值域、Scale 与运行时合同ai-systems · synthesis
- LLM 推理系统全栈综合分析ai-systems · synthesis
- 从 AVX/AMX 到 Tensor Core:CPU 工程师理解 LLM 量化ai-systems · comparison
- 量化:从 Scale 到 W4A8 的完整坐标ai-systems · concept
- GLM-5.2 量化执行图:W4A8、BMM 与 KV8ai-systems · concept
- KV Cache:推理性能的命根子ai-systems · concept
修改历史2 次提交
- docs(wiki): bridge CPU and GPU quantizationxiaocheng··
e737e5b - docs(wiki): deepen quantization researchxiaocheng··
b5e5fcc