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

2024-09-05 AIGC 0

作者｜Fireworks Team

OneFlow编译
翻译｜张雪聃
题图由SiliconCloud平台生成

随着Llama 3.1的发布，关于不同量化方法的优缺点的讨论变得相当热烈。模型量化质量的评估一向是个难题，本文将分享Fireworks如何处理量化以及评估其中的权衡。

以下是本文内容摘要：

量化没有通用的标准——量化技术多种多样，模型中可以量化的部分也各不相同。Fireworks与Cursor和Superhuman等客户有密切合作，根据个别使用场景量身定制量化方案。
使用KL散度衡量量化质量——为了衡量量化质量，作者倾向于使用散度指标。这些指标的准确性和可解释性很强，并且得到了相关文献的支持。
其他评估方法——Fireworks通过散度指标和任务指标来细致地评估模型，以确保质量与参考模型（reference model）匹配。然而，作者并不建议使用基于任务的方法来衡量量化质量，因为高噪声会限制精度。
你就是质量的最佳评判者——不同的量化技术对不同的使用场景有不同的影响。因此，开发者是量化质量的最佳评判者。

（本文经授权后由OneFlow编译发布，转载请联系授权。来源：https://fireworks.ai/blog/fireworks-quantization）

引言

对于通用的LLM推理和量化，我们认为没有一种通用的解决方案能适用于所有LLM推理。推理和量化设置在理想情况下应该是针对特定的使用场景进行特别定制。

一个关于量化的常见误解是：量化是非黑即白的，要么模型被很好地量化了，要么就没有被量化。然而，实际上却存在以下两种情况：

多种可能的量化技术，其激进程度各不相同。例如，我们可能会使用SmoothQuant、GPTQ以及异常值减少变换（如Hadamard、SpinQuant）等技术来将量化模型的质量最大化。扩展因子的粒度可以从每个整个张量一个到每个小值组一个不等。在运行时，量化模型可能会使用在线Hadamard技术来减少KV缓存的不一致性，或使用在线扩展来进行线性变换。
模型的各种层/部分可以被量化，例如QKV投影、注意力或KV缓存。一些层可能会被跳过或不进行量化。

通常，随着量化激进程度的增加，性能会提高，但质量会下降。然而，在只对质量产生微小影响的情况下，获得显著的性能提升，也是有可能的。质量与性能之间的权衡取决于以下因素：

(a) 特定模型（甚至是模型的微调）

(b) 使用场景——量化对代码生成等使用场景的影响可能与函数调用不同，请参见下面的假设图示。

一般来说，量化的目标是找到质量与速度之间的帕累托曲线（一种用于表示资源分配优化的曲线，常用于描述两者之间的权衡关系）上的最佳点。我们会与企业客户单独合作，找到这一最佳点。然而，对于我们的公共端点来说，由于平台上存在各种使用场景，并没有一个完美的配置。

KL散度——评估量化质量

如何衡量量化后的模型质量？由于质量取决于具体的使用场景，所以开发者还是评估其应用程序质量的最佳人选。然而，为了衡量模型的综合质量，我们更倾向于关注散度指标（量化对特定模型输出的改变程度），而不是单纯的能力指标（例如量化模型在通用基准测试如MMLU上的分数）。

这一理念在微软研究院最近的论文《准确性并不是唯一指标（https://arxiv.org/abs/2407.09141）》中得到了很好的表述。简单来说，量化引入的噪声可能会导致一些正确答案变为错误答案，但也可能会使一些错误答案变为正确答案（特别是在模型“不确定”的情况下）。这会影响准确性。对量化前后模型输出的概率分布的变化进行更精准地观察，可以帮助我们更清晰地理解不同量化技术的效果。

具体来说，我们专注于两个散度指标：

Kullback-Leibler散度 (KLD)——衡量词元概率分布的变化程度（即使每个位置上选择的词元相同）
词元拒绝率——衡量不同选择的最高概率词元的数量（可以将其视为使用量化模型作为草稿模型的准确性（β））

我们对这些指标进一步细分，以便在预填充和生成阶段（推理的不同部分可能使用不同的量化技术）理解散度：

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

我们的方法如下：

参考模型生成：为了计算散度，我们让参考的16位模型根据各种提示生成词元直到完成。假设词元数量足够，散度指标对初始提示的选择具有很强的稳定性。
参考分布创建：在每个位置，我们记录前N个对数概率值并将其归一化为一个分布。作为经验法则，我们选择N使得前N个词元覆盖分布的0.99，我们发现N=16是一个不错的值。
“强制”量化模型生成和分布创建：然后，我们在相同的提示上运行量化模型并构建一个类似的分布。重要的是，即使量化模型倾向于选择其他词元，我们仍然坚持使用参考模型所生成的输出。这可以防止量化模型生成一个完全不同的结果，这个结果可能质量较差但困惑度指标（例如，重复性）很好。
散度分析：随后我们可以分析所有样本的预期散度、相对于位置的预期散度等。重要的是，我们可以同时查看这些指标在预填充和生成阶段的情况，因为不同的技术对每个部分的影响不同。

我们在Llama 3.1 8B Instruct模型上对4种不同的“量化级别（levels of quantization）”进行了KL散度评估，在这些量化级别中，我们对模型的不同部分进行量化。为了进行对比，我们还与MMLU进行了比较。Fireworks平台提供了对数概率值（logprobs），因此我们鼓励大家自行评估散度结果。我们也鼓励其他提供商公开对数概率值，以帮助分析量化的权衡。结果如下所示。

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

量化级别的指标（由于模板差异，可能与Meta报告的结果不完全匹配。粗体数字是高噪声MMLU指标的一个例子）

一些值得注意的要点

量化引起的散度比例增加：正如预期的那样，我们发现散度指标在相互之间以及与量化级别的关系中是单调增长（Increase monotonically）的。相比之下，基于任务的指标（如MMLU）噪声较大，我们看到量化模型（级别2）的MMLU性能实际上比FP16参考模型更高。
可解释性：不同的模型需要不同的量化选择，因为瓶颈（包括信息和性能）可能不同。通过对我们的指标进行分段和进行消融测试，我们可以看到不同类型的量化是如何影响推理的不同方面，从而为选择最佳量化方法提供依据。例如，我们发现：
- 量化模型的MLP层对模型的影响相对较小，而量化QKV值的影响较大。
- 量化注意力预填充操作对长预填充模型的速度提升比对长生成模型的速度提升更明显。
质量降级很小——虽然难以定义单一的可接受散度值，但通常KL散度小于0.007会带来高质量的部署。

确保质量

在Fireworks，我们对部署的模型与参考模型进行了细致的比较，发现了HuggingFace实现中的错误（https://x.com/dzhulgakov/status/1806561582627045669）。像MMLU这样的基于任务的准确性指标对区分量化类型不够敏感。然而，这些指标仍然可以作为一致性检查的有用工具。

我们使用Helm-Lite评估套件（https://crfm.stanford.edu/helm/lite/latest/）和其他测试对Fireworks和TogetherAI端点上的Llama 3.1 70B进行了测试。随着Llama 3.1的发布，Meta发布了包含完整格式提示的官方参考评估（https://huggingface.co/datasets/meta-llama/Meta-Llama-3.1-405B-Instruct-evals），我们对此进行了重现。我们发现模型在各个维度上几乎没有差异。要使用Meta的官方评估，请查看我们下方的重现脚本（https://github.com/fw-ai/llm_eval_meta）。

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

即使我们在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做评估者的方法倾向于生成更冗长的内容。Alpaca Eval 2.0旨在通过拟合人类偏好的回归模型并应用基于长度的调整来纠正这一点。然而，这种修正并未针对量化等较小的变化进行专门评估。
由于采样设置的不同，结果可能难以重现。
默认设置优化了评估成本，但以牺牲准确性为代价。即，给LLM的提示是一个简单的偏好问题，而不是思维链。

我们在实际操作中观察到，这个基准测试的结果相当嘈杂，波动很大且没有明确的原因。例如，我们观察到在一些情况下，量化模型被评估为优于参考模型。

Arena-Hard-Auto是由LMsys Chatbot Arena团队创建的一个较新的基准测试，旨在解决一些局限性：

精心策划并更新提示集，尽量减少污染
使用思维链提示对LLM进行更精确的评估
技术报告（https://arxiv.org/pdf/2406.11939）指出，与AlpacaEval 2.0相比，其分离能力更强，与人类偏好的对齐差距几乎减小了一半

我们对Llama 3.1 405b Instruct进行了多个量化模型配置的Arena-Hard-Auto v0.1测试。结果没有明显差异，差距都被置信区间掩盖了。

5 结论

由于量化对不同使用案例的影响各不相同，量化质量的评判者最终是开发者自己。我们鼓励你在使用案例上尝试量化模型和未量化模型（标记为“-hf”）。我们为多家企业客户进行模型量化，以最大化应用程序的速度、质量和成本，这些应用程序覆盖了数百万用户。

Superhuman的AI负责人Roland Gavrilescu写道：

“我们对Fireworks的FP8模型很满意，这系列的模型使Superhuman能够提供更好的用户体验，使Ask AI实现低延迟和高响应质量。部署的服务效率也使我们能够提供卓越的客户体验。”

我们的量化方法使Fireworks能够提供行业领先的速度和成本。例如，我们帮助Cursor的Fast Apply功能达到了每秒1000个词元。

正如Anysphere的联合创始人Sualeh Asif所说：

“Fireworks使我们的Fast Apply和Copilot++模型高效运行，是一个了不起的合作伙伴。他们的产品在性能上远超我们测试过的其他竞争对手的产品。我们对其量化模型的质量进行了广泛测试，并发现质量下降非常小。此外，Fireworks还在帮助我们实现任务特定的加速和新架构方面发挥了关键作用，使我们的模型达到了前沿性能水平！”

我们在速度和质量之间实现了平衡，这使得我们能够以其他提供商的10倍成本效率发布Llama 3.1 405B。

其他人都在看