6.2 量化：AWQ、GPTQ 与 FP8 把字节砍下来

6.2 量化：AWQ、GPTQ 与 FP8 把字节砍下来

本节摘要：量化把权重与 KV Cache 的精度字节数从 FP16 的 2 字节压到 1 字节甚至 0.5 字节以内：AWQ 与 GPTQ 是训练后量化的两条成熟路线（INT4 为主），FP8 则是面向新一代硬件的在线格式。收益是三重的——权重显存减半以上、KV Cache 同步瘦身、decode 因搬运量下降而提速；代价是可控但真实存在的质量风险。本节讲清三条路线的原理差异、选型依据与验证方法。

深度学习历史上，低位宽的探索几乎与 GPU 推理本身一样古老：从 FP32 到 FP16 再到 INT8，每一次位宽下调都伴随着"精度会不会崩"的疑问与"实测没那么糟"的结论。大模型时代这条曲线继续下探，只是主角换成了三套各有哲学的方案：AWQ 靠"看激活选权重"，GPTQ 靠"逐层误差补偿"，FP8 靠"硬件原生支持"。它们共同回答一个问题：用更少的字节，保住几乎相同的能力。

为什么量化在推理侧格外划算

第 1 章讲过 decode 是访存受限的：每步耗时主要由权重搬运决定。权重的字节数砍半，搬运时间随之砍半——这意味着量化不只是省显存，还直接提速 decode。把收益完整列出来是三重的：

一省权重显存：8B 模型 FP16 约 16 GB → INT4 约 5 GB 上下，单卡可容纳的模型规模直接升档。
二省 KV Cache：缓存精度同步可调（比如降到 FP8），第 2 章公式里的"字节数"一项减半。
三提 decode 速度：访存受限意味着省下的搬运时间几乎等比例兑现为吞吐与 TBT 改善。
​

代价集中在质量维度：对 perplexity 类指标影响通常很小，但对数学推理、代码生成、少样本学习等"精度敏感"任务，粗糙的量化方案可能出现可感知的退化。量化不是免费的，它是一笔"字节换质量风险"的交易——而下面三条路线的差别，正是"怎么把风险压到最低"的三种答案。

三条路线：各有各的哲学

AWQ（激活感知的权重量化）：观察到一个事实——权重里少数关键通道承载了大部分信息，而哪些通道关键，由训练数据流过时产生的激活幅度决定。AWQ 先用一小批校准数据统计激活分布，据此对重要权重做缩放保护，再把整体压到 INT4。它的优势是校准便宜（不需要重训练）、对模型类型宽容，社区里大量模型直接发布 AWQ 版本，是"开箱即用"程度最高的一条路线。

GPTQ（逐层的近似二阶量化）：把量化当成一个逐层求解的优化问题——每量化一层，就估计这次量化引入的误差，并调整该层尚未量化的权重去补偿已产生的误差。它对校准集的依赖略高于 AWQ，但压缩率与质量平衡同样成熟，是 INT4 时代的另一大主流。两者在 4 比特档位的实测差距通常不大，选型更多看"你要用的模型有没有现成的对应版本"。

FP8（8 位浮点）：与前两者不同，FP8 不是整数格式而是浮点格式，指数位的存在让它对数值范围的宽容度远好于 INT8，通常无需复杂的校准流程即可对权重与激活同时量化（W8A8）。它的落地高度依赖硬件——新一代数据中心卡的原生 FP8 支持让它既有速度又有精度；老卡上要么没有加速，要么只能模拟。KV Cache 降到 FP8 也是同一条思路的延伸：缓存的字节数减半，长上下文的显存压力直接松绑。

图：量化方案的显存与质量对比

在 vLLM 里怎么用

vLLM 对这三条路线都有原生支持，多数场景下只是一两个启动参数的事：

# 路线一：直接使用社区发布的 AWQ 量化版模型
vllm serve 某模型的 AWQ 版本 --quantization awq

# 路线二：使用 GPTQ 量化版
vllm serve 某模型的 GPTQ 版本 --quantization gptq

# 路线三：新硬件上开启 FP8（权重与激活），同时把 KV Cache 降到 FP8
vllm serve 某模型 --quantization fp8 --kv-cache-dtype fp8
​

三个实践要点：其一，优先用现成量化版模型——社区发布的 AWQ/GPTQ 版本经过验证，比自己动手量化踩坑少；确需自行量化时，校准集尽量贴近你的业务文本分布。其二，KV Cache 量化是独立的旋钮，--kv-cache-dtype fp8 可以与权重量化解耦使用，长上下文场景单独开启它就有可观收益。其三，量化与并行联动：上一节说过，能靠量化装进更少卡就别加并行度——一个 70B 模型，INT4 后单卡可容，比"FP16 + 四卡张量并行"少了全部通信开销，吞吐往往反而更高。

量化前后怎么验证：一套固定动作

质量验证不要依赖感觉，固定的四步走：

第一步：选评测集。通用能力用公开基准，业务能力必须自建（从真实请求里抽样标注）。
第二步：定对比口径。同一套采样参数、同一批请求，FP16 与量化版各跑一遍。
第三步：看两类指标。自动指标（准确率、BLEU 类）之外，人工抽检长链推理样本。
第四步：看线上灰度。小流量灰度对比负反馈率，没有异常再全量。
​

⚠️ 一个容易被忽略的坑：部分任务对量化敏感的表现不是"答错"，而是"格式错乱"——比如 JSON 输出开始带出多余字符、工具调用参数解析失败。这类退化在自动指标里可能看不见，却直接打断下游流程。涉及结构化输出的服务，量化验证清单里务必加一条：结构化输出成功率。

量化与长上下文的联动：一个常被低估的组合

单独看，KV Cache 降 FP8 已经很划算；与长上下文叠加时收益会再放大。回顾第 2 章的公式：序列长度是缓存开销里增长最快的一项，长上下文请求的缓存占用动辄数 GB，把它降到 8 位等于把"最贵的那些请求"的成本直接砍半。对以长文档、长会话为主的服务，这条旋钮的优先级应排在权重量化之前——它不涉及任何模型质量争议（缓存精度的影响远小于权重精度），是量化家族里风险最低的一步。

本节要点回顾

• 量化收益三重：权重显存、KV Cache 字节数、decode 搬运时间，三本账一起减。
• AWQ 靠激活分布保护关键权重，现成版本多，是通用部署的默认首选；GPTQ 逐层误差补偿，能力相当，作为备选路线。
• FP8 是新硬件的原生路线，权重激活可同时量化，KV Cache 降 FP8 是独立可开的旋钮。
• 质量风险集中在精度敏感任务，验证必须用自建评测集与线上灰度，别只看通用基准。
• 量化优先于并行：先把字节瘦下来，再考虑加卡；两者叠加时按"量化为主、tp 为辅"配置。

显存与算力的账都能算平了。第 7 章把所有配置落成服务：安装、启动、OpenAI 兼容接口与核心参数清单。