Llama 3.1 发布后，关于量化方法优劣的讨论迅速升温。如何评估模型量化质量，一直是业界难题。下面分享 Fireworks 在量化处理与权衡取舍方面的实践经验。

摘要

• 量化没有统一标准——量化技术种类繁多，模型各部分的量化方式也各不相同。Fireworks 与 Cursor、Superhuman 等客户紧密合作，针对具体应用场景定制量化方案。
• 用 KL 散度衡量量化质量——为评估量化效果，我们倾向于采用散度指标。这些指标准确、可解释性强，且有相关学术文献支撑。
• 其他评估方法——Fireworks 通过散度指标和任务指标细致评估模型，确保其质量与参考模型匹配。但基于任务的方法不宜单独用于衡量量化质量，因为高噪声会限制精度。
• 开发者自身才是最佳评判者——不同量化技术对不同使用场景影响各异，因此开发者应自行判断量化效果。

1. 引言

对于通用的大语言模型推理与量化，我们并不认为存在放之四海而皆准的方案。理想情况下，推理和量化配置应根据具体使用场景量身定制。

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

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。