推测性解码简介：更快的 LLM 作弊代码

动手实践在人工智能推理方面，生成响应的速度越快越好，在过去的几周里，我们看到芯片新贵发布了许多声明，声称数字高得令人难以置信。

最近，大脑声称它实现了推理里程碑，在 Meta 的 4050 亿参数庞然大物中每秒生成 969 个令牌，在模型的完整 128K 上下文窗口中每秒生成 539 个令牌。

在小型 Llama 3.1 70B 型号中，Cerebras报道性能更高，每秒可达 2,100 个令牌。不甘落后于1,665tokens/sec 是人工智能芯片初创公司 Groq。

这些数字远远超过了仅使用 GPU 所能实现的任何数字。Artificial Analysis 的 Llama 3.1 70B API 排行榜显示，即使是最快的基于 GPU 的产品也能以每秒约 120 个令牌的速度达到顶峰，而传统 IaaS 提供商则接近 30 个。

部分原因在于 Cerebras 和 Groq 的芯片都不是 GPU。它们是专门构建的 AI 加速器，利用大量 SRAM 来克服通常与推理相关的带宽瓶颈。

然而，这并不能解释如此大的跳跃。Cerebras 和 Groq 之前曾展示过 Llama 3.1 70B 的性能分别约为 450 和 250 个令牌/秒。

相反，由于一种称为推测解码的技术，性能的飞跃是可能的。

性能作弊代码

如果您不熟悉推测解码的概念，请不要担心。该技术实际上非常简单，涉及使用较小的草稿模型（例如 Llama 3.1 8B）生成初始输出，而较大的模型（例如 Llama 3.1 70B 或 405B）充当事实检查器以保持准确性。

成功后，研究建议该技术可以将代币生成速度提高 2 倍到 3 倍，而现实世界的应用程序已经显示提高了 6 倍以上。 

您可以将这个草稿模型想象成一位私人助理，同时也是一名专业打字员。他们可以更快地回复电子邮件，只要他们的预测准确，您（在这个类比中的大模型中）所要做的就是单击“发送”。如果他们对奇怪的电子邮件没有正确理解，您可以介入并更正。

使用推测性解码的结果是，至少平均来说，具有更高的吞吐量，因为草稿模型需要更少的资源——无论是在 TOPS 或 FLOPS 还是内存带宽方面。更重要的是，由于大模型仍在检查结果，Artificial Analysis 的基准测试者宣称与仅运行完整模型相比，实际上没有精度损失。

亲自尝试一下

完成所有这些后，我们可以继续自己测试推测解码。许多流行的模型运行程序都支持推测解码，但出于本次实践的目的，我们将使用 Llama.cpp。

这并不是安装和配置 Llama.cpp 的指南。好消息是让它运行起来相对简单，甚至还有一些适用于 macOS、Windows 和 Linux 的预构建软件包 - 您可以找到它们这里。也就是说，为了使您的特定硬件获得最佳性能，我们始终建议手动编译最新版本。您可以找到有关编译 Llama.cpp 的更多信息

这里。一旦部署了 Llama.cpp，我们就可以使用推测解码来启动一个新服务器。首先找到

骆驼服务器在您首选的终端模拟器中可执行。接下来我们将拉下我们的模型。

为了简单起见，我们将使用 Hugging Face 中的一对 8 位量化 GGUF 模型。对于我们的草稿模型，我们将使用羊驼3.2 1B对于我们的主要模型，我们将使用羊驼3.1 8B– 需要略低于 12GB 的 vRAM 或系统内存才能运行。

如果您使用的是 macOS 或 Linux，则可以使用获取拉下模型。

wget https://huggingface.co/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF/resolve/main/Meta-Llama-3.1-8B-Instruct-Q8_0.ggufwget https://huggingface.co/bartowski/Llama-3.2-1B-Instruct-GGUF/resolve/main/Llama-3.2-1B-Instruct-Q8_0.gguf

接下来，我们可以通过运行以下命令来测试推测解码。别担心，我们将在一分钟内详细讨论每个参数。

./llama-推测-m Meta-Llama-3.1-8B-Instruct-Q8_0.gguf -md Llama-3.2-1B-Instruct-Q8_0.gguf -c 4096 -cd 4096 -ngl 99 -ngld 99 --draft-max16 --draft-min 4 -n 128 -p “谁是第一任总理英国？”

笔记：Windows 用户会想要更换./美洲驼推测和骆驼推测.exe。如果您不使用 GPU 加速，您还需要删除-ngl 99和-ngld 99。

输入提示几秒钟后，我们的答案就会出现，同时还会显示生成率以及小模型起草了多少代币以及大模型接受了多少代币的读数。 

在 0.033 秒内编码 9 个令牌，速度：269.574 t/s在 0.762 秒内解码 139 个令牌，速度：182.501 t/s...n_草稿 = 16n_预测 = 139n_起草 = 208n_接受= 125接受=60.096%

接受率越高，生成率就越高。在这种情况下，我们使用相当低的参数计数模型（尤其是草稿模型），这可以解释为什么接受率如此之低。

然而，即使接受率为 60%，我们仍然看到性能有相当大的提升，速度为 182 个令牌/秒。使用未启用推测解码的 Llama 3.1 8B，我们看到性能接近 90-100 个令牌/秒。

那么这个命令发生了什么？ 

• ./美洲驼推测指定我们要使用推测解码。
• -m和-md分别设置主（大）模型和草图（小）模型的路径
• -c和-光盘分别为主模型和草图模型设置上下文窗口
• -ngl 99和-ngld 99告诉 Llama.cpp 将我们的主模型和草稿模型的所有层卸载到 GPU。
• --最大吃水深度和--草稿分钟设置草稿模型一次应生成的最大和最小令牌数。
• --草稿-p-分钟设置推测解码发生的最小概率。
• -n设置要输出的最大令牌数。
• -p是我们用引号输入提示的地方。

您可以通过运行以下命令找到可用参数的完整细分：

./llama-speculative--help

如果您想在项目中使用推测解码，您还可以使用以下命令启动兼容 OpenAI 的 API 服务器：

./llama-server -m Meta-Llama-3.1-8B-Instruct-Q8_0.gguf -md Llama-3.2-1B-Instruct-Q8_0.gguf -c 4096 -cd 4096 -ngl 99 -ngld 99 --draft-max8 --draft-min 4 --draft-p-min 0.9 --host 0.0.0.0--端口8087

当您可以像任何其他 OpenAI 兼容的 API 服务器一样与它交互时，这将在端口 8087 上公开您的 API 服务器。此示例是作为概念证明提供的。在生产环境中，您可能需要设置 API 密钥并限制通过防火墙的访问。

作为旁注，我们还看到，当包括--采样-seq k优先考虑 Top-K 采样，但您的情况可能会有所不同。

完整列表骆驼服务器可以通过运行找到参数：

./llama-server --help

服务器启动并运行后，您现在可以将应用程序或前端（例如 Open WebUI）指向与服务器交互。有关设置后者的更多信息，请查看我们的检索增强生成指南这里。

为什么要猜测？

推测性解码绝不是新鲜事。该技术是讨论过至少早在 2022 年 11 月——ChatGPT 引发人工智能军备竞赛不久之后。

然而，随着单片模型变得越来越大，推测性解码提供了一种在不影响准确性的情况下更有效地运行 Llama 3.1 405B 等大型单片模型的方法。

虽然 Meta 的 405B 基础模型与 OpenAI 的 GPT4 相比可能很小（据说其参数大小约为 1.7 万亿个），但它仍然是一个难以以高吞吐量运行的模型。

在全分辨率下，实现每秒 25 个令牌的生成速率需要超过 810GB 的 vRAM 和超过 20 TB/秒的内存带宽。实现更高的性能需要更高级别的并行性，这意味着更多的 GPU 或加速器。

使用像 Llama 3.1 70B 这样的推测性解码作为草稿模型，在 810 之上还需要 140GB 内存，但是理论上可以实现远超过 100 个令牌/秒的生成率 — 直到发生错误预测，此时你的吞吐量将会急剧下降。

这是与推测性解码相关的挑战之一：它在提高吞吐量方面非常有效，但在我们的测试中，延迟可能是零星的且不一致的。

我们实际上可以在 Cerebra 之前的文章中看到这一点发表使用推测解码时 Llama 3.1 70B 的结果。我们不知道草案模型是什么，但根据之前的基准测试，我们相当确定它是 8B 变体。正如您所看到的，当实现推测解码时，性能会出现巨大的峰值，但延迟的变化仍然很大 - 上下跳跃 400 个或更多令牌。

需要明确的是，70B 的速度为 1,665 到 2,100 个令牌/秒，405B 的速度高达 969 个令牌/秒，很有可能在您注意到问题之前输出就已完成生成。

至于为什么需要一个能够在眨眼间生成数百或数千个令牌的推理引擎，Cerebras 实际上很好地说明了这个问题。

如果您尝试过 OpenAI 的 o1，您可能会注意到它比以前的模型慢很多。这是因为该模型采用思想链 (CoT) 树将任务分解为单独的步骤，评估响应，识别逻辑中的错误或差距，并在向用户提供答案之前纠正它们。

使用 CoT 作为生成人工智能过程的一部分被认为可以提高答案的准确性和可靠性，并减少错误行为或幻觉。然而，这种方法的结果是速度要慢得多。

下一步的发展是将 CoT 方法与代理工作流程中的多个特定领域模型相结合。根据 Cerebras 的说法，此类方法需要大约 100 倍的步骤和计算能力。因此，你生产代币的速度越快，你就越能隐藏增加的延迟——或者无论如何，这就是这个想法。®

编者注：为支持此类报道，The Register 提供了 Nvidia 的 RTX 6000 Ada Generation 显卡、Intel 的 Arc A770 GPU 和 AMD 的 Radeon Pro W7900 DS。这些供应商均未对本文或其他文章的内容提供任何意见。