跳转到主要内容

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

按控制点理解 GPTQ、AWQ、SmoothQuant、Rotation 与 QAT,并用执行真实性、质量、容量、性能四道门验收量化方案

· 约 9 分钟阅读

摘要

量化方法不能只按名字背诵。真正有区分度的是它在控制什么误差:

  • 改变权重舍入顺序与误差补偿;
  • 保护重要权重通道;
  • 把 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 类 W4A8smoothing + 权重误差补偿同时降低权重和激活位宽
FP8 recipeE4M3/E5M2 + current/delayed/block scaling使用 FP8 Tensor Core
NVFP4 recipeE2M1 + 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 一定无损”都不是稳定结论。量化质量是多变量函数:

Qloss=f(model,task,bitwidth,granularity,calibration,excluded layers,runtime)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 traceoperand 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、PMUKernel 名、operand dtype、engine log
是否受存储墙限制LLC miss、DRAM BW、IBS load latencyHBM throughput、L2、memory/SOL
是否有 layout 转换reorder、unaligned/split loadcast、Q/DQ、repack、短转换 Kernel
是否发生 fallbackscalar tail、generic primitive高精度替代 Kernel、pre-expand
是否端到端受益cycles/request、QPS、P95TTFT、TPOT、TPS/TPM

因此“模型配置里写了量化”类似“源码里用了 int8_t”:两者都不能替代实际指令和运行数据。完整迁移路径见CPU 工程师理解量化

4. G2:模型质量

4.1 不要只看一个 PPL

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

维度指标或数据目的
Language modelingWikiText/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:容量收益

容量结果至少拆成:

Mpeak=Mweights+Mscales+MKV+Mactivations+Mworkspace+McommunicationM_{\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-endTTFT、TPOT、TPS/TPM、请求吞吐产品是否真正受益
PhasePrefill/decode time、queue wait收益发生在哪个阶段
KernelGEMM/BMM/Attention/Q/DQ/cast 时间解释为何达到或没达到理论值
CostGPU 数、功耗、tokens/成本决定生产价值

6.3 Sweep 而不是单点

至少进行:

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

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

7. 推荐实验矩阵

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

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

CaseRuntime verifiedQualityPeak HBMTTFTTPOTTPSResult state
BF16 baselineyesbaselinecomparable
Quant recipe Ayes/noΔcomparable / fallback
Quant recipe Byes/noΔunsupported / failed

unsupportedfailedmissingnot_comparable 都不能填成 0。

8. 选型边界

目标优先研究首要风险
小 Batch Decode / 显存不足W4A16、W4A8、KV8Kernel 解包、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 路径,速度比较才可信。

相关页面

参考资料

修改历史2 次提交