AMD GPU 上 vLLM 的推测解码

TL;DR：推测性解码允许 vLLM 在单个目标模型传递中验证多个起草的标记。在我们的实验中，它对输出令牌吞吐量的影响因起草方法和提案长度而异，并且还取决于模型系列、草案检查点、工作负载和接受行为。简介 大型语言模型支持广泛的应用程序，但大规模服务它们需要仔细优化。标准自回归解码是大多数 LLM 服务系统使用的基线：模型生成一个标记，将其附加到序列中，然后使用更新的序列生成下一个标记。这一过程简单可靠，但服务循环仍然一次推进一个已提交的令牌，因为输出令牌必须按照严格的从左到右的顺序生成。推测性解码 [1] 通过草稿和验证机制建立在该基线之上。轻量级草稿组件提出候选未来代币，目标模型在提交这些候选代币之前对其进行验证。当多个草稿令牌被接受时，系统可以从单个目标模型验证步骤提交多个输出令牌，同时保留目标模型的输出行为。这篇文章探讨了推测解码在 vLLM 中的工作原理，并分享了我们测试环境中的测量结果。我们首先回顾自回归解码基线以及起草和验证过程。然后，我们研究了五种推测性起草方法：原生 MTP、Gemma 4 MTP、EAGLE-3、DFlash 和 DSpark。这些方法的不同之处在于草稿组件如何从目标模型接收信息以及候选标记是顺序生成、自回归生成、并行生成还是通过混合方法生成。最后，我们展示了如何启用在我们的环境中测试的方法，报告使用 ROCm™ 开放软件平台在 AMD Instinct™ MI300X 和 MI355X GPU 上进行的实验的测量结果，并讨论实际的调整和可观察性注意事项。自回归解码基线 在标准自回归解码中，每个解码步骤都会生成并提交一个新令牌。例如，生成四个输出标记需要四个连续的解码步骤： 步骤 1：上下文 → 模型 → T1 步骤 2：上下文 + T1 → 模型 → T2 步骤 3：上下文 + T1 T2 → 模型 → T3 步骤 4：上下文 + T1 T2 T3 → 模型 → T4 在每个步骤之后，生成的标记将附加到序列中，并成为下一步输入的一部分。这使得解码循环变得简单，但对于每个输出标记也需要一个模型解码步骤。在长时间的生成过程中，这种逐个令牌的循环可能会主导延迟并限制服务吞吐量。因此，推测性解码背后的关键问题是：我们能否保留原始模型的输出行为，同时减少生成一次仅推进一个令牌的频率？推测性解码通过将提议与验证分开来解决这个问题。草案组件首先提出几个候选未来代币。原始模型充当目标模型，然后在提交这些候选模型之前对其进行验证。推测解码的核心思想 推测解码并不会取代原始模型。相反，它将原始模型保留为目标模型，该模型仍然负责最终输出，并在其前面添加了更快的提案阶段。该过程分为两个部分： 草案：提出几个候选未来代币。验证：使用目标模型来检查这些候选者。在每一轮推测解码期间，如图 1 所示，轻量级草案组件会提出一个或多个未来令牌。这些代币只是候选代币，不会立即提交。然后，目标模型在一次验证过程中评估候选标记序列。验证从左到右进行。使用目标模型在相应位置的结果来检查每个草稿标记。接受的令牌被提交到输出序列。当草稿令牌被拒绝时，同一提案中的后续候选者将不再被接受。如果草稿令牌被拒绝，目标模型将提供下一个令牌。剩余的草稿令牌将被丢弃，并从更新的序列继续生成。从概念上讲，标准自回归解码的进展如下：目标模型 → T1 目标模型 → T2 目标模型 → T3 目标模型 → T4 推测性解码允许一起评估多个候选位置：草案建议 T1 T2 T3 T4 模型验证 ✓ ✓ ✗ 停止提交 T1 T2 替换令牌 - 当接受多个候选时，这可以减少目标模型解码轮数。当草稿组件生成目标模型接受的令牌时，可以从一个目标模型验证步骤提交多个输出令牌。当提案被拒绝时，目标端的结果决定生成如何继续。简单的接受/拒绝示例 图 2 给出了一轮推测解码的示例。绿框是草稿代币