如何准确且可解释地评估大模型量化效果？

Llama 3.1 发布之后，量化方法的优劣讨论一下就热了起来。模型量化质量怎么评估，历来是个让人头疼的问题。下面说说我们 Fireworks 是怎么处理量化、怎么权衡其中得失的。

摘要

• 量化没有一刀切的标准
  ——量化技术五花八门，模型里哪些部分可以量化也各不相同。Fireworks 与 Cursor、Superhuman 等客户紧密合作，针对具体使用场景定制量化方案。

• 用 KL 散度衡量量化质量
  ——为了评估量化质量，我们倾向于使用散度指标。这些指标准确、可解释性强，并且有相关文献支撑。

• 其他评估方法
  ——Fireworks 通过散度指标和任务指标细致评估模型，确保质量与参考模型匹配。不过，不建议用基于任务的方法来衡量量化质量，因为高噪声会限制精度。

• 开发者自己才是质量的最佳评判者
  ——不同的量化技术对不同使用场景影响不一，所以开发者自己判断最靠谱。

1. 引言

对于通用的 LLM 推理和量化，我们并不认为存在一个万能方案。推理和量化配置理想状态下应该根据具体使用场景量身定制。

很多人误会量化是非黑即白的：要么模型量化得好，要么没量化好。但实际情况要复杂得多，主要涉及两方面：

1. 有多种量化技术可选择
   ，激进程度各不相同。比如 SmoothQuant、GPTQ、异常值减少变换（Hadamard、SpinQuant 等）都能用来提升量化模型的质量。扩展因子的粒度可以从整个张量一直细到每个小值组。运行时还可能用到在线 Hadamard 来减少 KV 缓存的不一致性，或者在线扩展来做线性变换。

2. 模型的不同层/部分
   可以被量化，比如 QKV 投影、注意力或 KV 缓存。有些层可以跳过不量化。

通常，量化越激进，性能越好，但质量会下降。不过，也有可能只付出很小的质量代价就换来显著的速度提升。质量与性能的权衡取决于：

(a) 具体模型（包括微调方式）
(b) 使用场景——量化对代码生成的影响可能和对函数调用的影响完全不同，具体可参考下面的示意图。

简单说，量化的目标就是找到质量与速度之间帕累托曲线上的最佳点。我们会和企业客户单独协作去定位这个点。但对于我们的公共端点，因为平台上跑着各种使用场景，并不存在一个完美的统一配置。

2. KL 散度——评估量化质量

怎么衡量量化后的模型质量？因为质量取决于具体使用场景，所以开发者自己来评估他们应用的质量最合适。但从整体衡量模型质量的角度，我们更偏向用散度指标（也就是量化对模型输出改变的程度），而不是单纯看能力指标（比如量化模型在 MMLU 这类通用基准上的分数）。

这个思路在微软研究院最近的文章《准确性并不是唯一指标》（arxiv.org/abs/2407.09141）里讲得很清楚。简单说，量化引入的噪声可能导致一些正确答案变错，也可能让一些错误答案变对（尤其是模型“不确定”时），从而影响准确率。如果能更精细地观察量化前后模型输出概率分布的变化，就能更清晰地理解不同量化技术的效果。

具体到实际，我们关注两个散度指标：

• Kullback-Leibler 散度 (KLD)
  ——衡量词元概率分布的变化程度（即使每个位置选中的词元一样）。

• 词元拒绝率
  ——衡量有多少位置选了不同的最高概率词元（可以理解为把量化模型当草稿模型时的准确率 β）。

我们还会把这些指标进一步细分，以便区分预填充阶段和生成阶段的散度——因为推理的不同部分可能用了不同的量化技术：

• 预填充 KL 散度
• 生成 KL 散度
• 预填充拒绝率
• 生成拒绝率

具体做法如下：

1. 参考模型生成
   ：让参考的 16 位模型针对各种提示生成词元，直至完成。假设词元量足够，散度指标对初始提示的选择是相当稳定的。

2. 参考分布创建
   ：在每个位置，记录前 N 个对数概率值，归一化为一个分布。经验上我们会取 N 使得前 N 个词元覆盖分布的 0.99，N=16 通常够用。

3. “强制”量化模型生成与分布创建
   ：用同样的提示运行量化模型，构建类似的分布。关键一步：就算量化模型更倾向选其他词元，我们也坚持使用参考模型输出的词元——这能防止量化模型生成一条完全不同的路径，那条路径可能质量差但困惑度指标（比如重复性）却好看。

4. 散度分析
   ：然后就可以分析所有样本的期望散度、相对于位置的期望散度等。重要的是，可以同时看预填充和生成阶段的指标，因为不同技术对两个部分的影响可能截然不同。

我们在 Llama 3.1 8B Instruct 模型上测试了 4 个不同的“量化级别”（对模型不同部分进行量化），并用 KL 散度做评估，同时还和 MMLU 做了对比。Fireworks 平台提供了 logprobs，所以欢迎大家自己算散度。也鼓励其他提供商公开 logprobs，这样整个社区都能一起分析量化的权衡。结果如下：

• 级别 1：量化 MLP 矩阵乘法，除去第一层和最后一层（最不激进）
• 级别 2：级别 1 + 量化省略的层和 QKV
• 级别 3：级别 2 + 量化 KV 缓存
• 级别 4：级别 3 + 量化预填充中的注意力（最激进）

（由于模板差异，可能与 Meta 报告的数字不完全一样。加粗数字是高噪声 MMLU 指标的一个例子）

几个值得注意的点：

• 量化引入的散度比例在增加
  ——如预期，散度指标随着量化级别递增而单调上升。而基于任务的指标（比如 MMLU）则噪点很大，量化模型（级别2）的 MMLU 性能居然比 FP16 参考模型还高。

• 可解释性强
  ——不同模型需要不同的量化策略，因为瓶颈（包括信息和性能）各不相同。通过分段分析和消融测试，我们能看清不同类型的量化如何影响推理的不同方面。比如我们发现：
• 量化 MLP 层对模型影响相对较小，而量化 QKV 影响较大。
• 量化注意力预填充操作对长预填充的场景提速效果比对长生成的场景更明显。

• 质量退化很小
  ——虽然很难定义一条可接受的散度标准线，但通常 KL 散度小于 0.007 意味着高质量的部署。

3. 确保质量

在 Fireworks，我们会把部署的模型与参考模型进行细致对比，曾借此发现 HuggingFace 实现中的 bug（详见 x.com/dzhulgakov/status/1806561582627045669）。像 MMLU 这样的任务准确率指标，对区分量化类型不够敏感，不过仍可作为一种一致性检查手段。

我们用 Helm-Lite 评估套件（crfm.stanford.edu/helm/lite/latest/）和其他测试对 Fireworks 和 TogetherAI 端点上的 Llama 3.1 70B 做了对比。Llama 3.1 发布时，Meta 给出了包含完整格式提示的官方参考评估（huggingface.co/datasets/meta-llama/Meta-Llama-3.1-405B-Instruct-evals），我们重新跑了一遍，发现模型在各维度上几乎没差异。如果想用 Meta 的官方评估，可以参考我们的重现脚本（github.com/fw-ai/llm_eval_meta）。

4. 其他量化质量评估方法的问题

尽管我们在 MMLU 和其他任务基准上拿到了不错的结果，但还是建议大家不要只根据这些基准里的小差异就下结论说量化质量如何。任务指标在分析基础模型质量时很管用，但用来对比不同量化技术时灵敏度不足——因为评分方法噪点大，而且是全有或全无的性质。

任务评估把正确性当成阶跃函数来用。想象一下这种情况：参考模型对一个正确答案和一个错误答案的概率分布是 0.51/0.49，量化模型可能变成 0.49/0.51，但任务评估会给这两个模型分别打 0 分和 1 分。

这种全有或全无的方式会带来大量不确定性。比如我们发现，某些基准中量化模型的质量居然比参考模型还高。下面这张来自 TogetherAI 的图就是一个例子：量化模型（Turbo）在 GSM8K 和 MMLU EM 上的结果比非量化模型高出几个百分点。

实际上，量化并不能奇迹般地提升模型质量，是基准测试本身的噪点在作怪。这么高的噪声水平意味着，从小于1%的差异中得出的结论很可能具有误导性。

困惑度

困惑度衡量的是 LLM 在给定文本分布上的预测效果。它的一个缺点是：如果模型对自己生成的输出过于自信，那么在自己生成的文本上评估困惑度会产生偏差。此外，还有平均偏差的问题。引用《准确性并不是唯一指标》里的话：

“我们观察到，两个模型输出的词元值之间的差异会相互抵消，从而使平均指标结果保持不变，这也适用于困惑度。特别是，由于困惑度可以解释为词元概率几何平均值的倒数，测试数据集中某些词元的较低概率可能会被其他词元的较高概率所抵消。”

前面提到的 KL 散度指标与困惑度密切相关，但正好解决了这两个缺点。

AlpacaEval 和用 LLM 自身当评估者的方法

让人对两个 LLM 生成的答案做盲选投票，这是 LLM 评估的黄金标准——LMsys Chatbot Arena 领头推广，目前已经积累了超过 150 万票。但人工评估成本太高，所以像 AlpacaEval 这样的指标改用强大的 LLM（比如 GPT-4）来挑选优选答案，这种方法也流行起来了。不过它也有局限：

• 样本量小（805 个样本），置信区间偏宽。
• 用 LLM 当评估者，倾向于喜欢更长的回答。AlpacaEval 2.0 通过拟合人类偏好的回归模型并做长度修正来缓解，但这种修正并没有专门针对量化这种小变化做过校验。
• 由于采样设置不同，结果可能很难复现。
• 默认设置优化了评估成本，但牺牲了准确性——给 LLM 的提示只是一个简单的偏好问题，没有用思维链。

实际观测中，这个基准测试的结果相当嘈杂，经常没来由地大幅波动。比如我们就看到过量化模型被评估得比参考模型还好的情况。

Arena-Hard-Auto 是 LMsys Chatbot Arena 团队新出的基准，试图解决部分局限：

• 精心策划并定期更新提示集，尽量减少污染。
• 用思维链提示让 LLM 评估更精准。
• 技术报告（arxiv.org/pdf/2406.11939）指出，相比 AlpacaEval 2.0，它的分离能力更强，与人类偏好的对齐差距缩小了近一半。

我们对 Llama 3.1 405b Instruct 的多个量化配置做了 Arena-Hard-Auto v0.1 测试，结果没有明显差异，差距都在置信区间之内。

5. 结论

量化对不同的使用场景影响各异，所以量化质量最终要由开发者自己来评判。我们鼓励大家在自己的场景上试试量化模型和未量化模型（标记为 “-hf”）。Fireworks 为多家企业客户做模型量化，这些客户的应用覆盖了数百万用户，我们在速度、质量和成本之间找到了平衡。

Superhuman 的 AI 负责人 Roland Ga vrilescu 说：“Fireworks 的 FP8 模型让我们很满意，Superhuman 因此能为用户提供更低的延迟和更高质量的响应，Ask AI 体验大幅提升。部署的服务效率也让我们能提供卓越的客户体验。”

我们的量化方法让 Fireworks 能做到行业领先的速度和成本。比如我们帮助 Cursor 的 Fast Apply 功能达到了每秒 1000 个词元。Anysphere 联合创始人 Sualeh Asif 说：“Fireworks 让我们的 Fast Apply 和 Copilot++ 模型高效运行，合作非常愉快。产品性能远超我们测试过的其他竞品。我们广泛测试了他们的量化模型，质量下降非常小。而且 Fireworks 在帮助我们实现任务特化加速和新架构方面也发挥了关键作用，让我们的模型达到了前沿水平！”

正是这种速度与质量的平衡，让我们能以其他提供商 10 倍的成本效率发布 Llama 3.1 405B。