TL; DR: speculative decoding 允许 vLLM 在单个目标模型通过中验证多个起草的 token。在我们的实验中，其对输出 token 吞吐量的影响因起草方法和建议长度而异，也取决于模型家族、草稿检查点、工作负载和接受行为。

引言：大型语言模型支持各种应用，但大规模服务它们需要仔细优化。标准自回归解码是大多数 LLM 服务系统使用的基线：模型生成一个 token，将其追加到序列中，然后使用更新的序列生成下一个 token。这个过程很简单可靠，但服务循环仍然每次只推进一个已提交的 token，因为输出 token 必须按严格的左到右顺序生成。

decoding [1] 建立在该基线之起草-验证机制。一个轻量级的起草组件提出候选未来 token，目标模型在它们被提交前验证这些候选。当多个 draft token 被接受时，系统可以从单个目标模型验证步骤中提交多个输出 token，同时保留目标模型的输出行为。

本文探讨了 vLLM 中 speculative decoding 的工作原理，并分享了我们测试环境中的测量结果。我们首先回顾自回归解码基线和起草-验证过程。然后，我们检查五种 speculative-drafting 方法：原生 MTP、Gemma 4 MTP、EAGLE-3、DFlash 和 DSpark。这些方法在起草组件如何从目标模型接收信息以及候选 token 是按顺序、自回归、并行还是混合方式生成方面有所不同。最后，我们展示如何在我们的环境中启用这些方法，报告我们在 AMD Instinct↓ MI300X 和 MI355X GPU 上使用 ROCm↓ 开放软件平台进行的实验测量，并讨论实际调优和可观测性考量。

自回归解码基线：在标准自回归解码中，每个解码步骤产生并提交一个新的 token。例如，生成四个输出 token 需要四个顺序解码步骤：步骤 1：context→model→T1 步骤 2：context + T1→model→T2 步骤 3：context + T1 T2→model→T3 步骤 4：context + T1 T2 T3→model→T4 每个步骤后，生成的 token 追加到序列中，并成为下一步的输入。这使得解码循环很简单，但它也要求每个输出 token 进行一次模型解码步骤。在长代际生成期间，此 token-by-token 循环可能主导延迟并限制服务吞吐量。

起草-验证的关键问题在于：我们能否在保留原始模型输出行为的同时，减少生成仅每次推进一个 token 的频率？ speculative decoding 通过将提议与验证分离来解决这个问题。一个起草组件首先提出若干候选未来 token。原始模型充当目标模型，随后在候选被提交前对其进行验证。

speculative decoding 的核心思想：speculative decoding 不替换原始模型。相反，它保留原始模型作为目标模型，该模型仍然负责最终输出，并在其前面添加一个更快的提议阶段。该过程有两部分：起草：提出若干候选未来 token。验证：使用目标模型检查这些候选。

在每一次 speculative decoding 回合中，如图 1 所示，一个轻量级的起草组件提出一个或多个未来 token。这些 token 仅为候选，且不立即提交。目标模型随后使用一次验证评估候选 token 序列。验证从左到右进行。每个 draft token 使用目标模型在对应位置的结果进行检查。接受的 token 被提交到输出序列。当一个 draft token 被拒绝时，后续的候选...