vLLM 在 AMD GPU 上探索推测解码：从 MTP 到 EAGLE-3

导语

大语言模型服务的一个核心瓶颈，是解码阶段必须按顺序逐个生成 token。即使模型已经完成提示词处理，长文本生成仍需要反复执行解码步骤，延迟和吞吐因此受到限制。vLLM 近期发布的实践文章，围绕 AMD Instinct MI300X、MI355X 和 ROCm 环境，梳理了推测解码在 AMD GPU 上的工作方式、可选方案及调优思路。

推测解码如何工作

推测解码并不取代原始大模型，而是为目标模型增加一个更快的候选生成环节。每轮过程中，草稿组件先提出多个未来 token，目标模型随后在一次验证过程中按位置检查这些候选。连续通过验证的 token 可以被一并提交；一旦某个位置被拒绝，后续候选会被丢弃，并由目标模型决定替代 token。这样，系统有机会用一次目标模型计算推进多个输出位置，同时保持目标模型负责最终结果。

vLLM 支持的主要路径

素材将相关方案归纳为三类：

• 原生 MTP：直接集成在目标模型架构中，通过模型自身的辅助预测路径逐步生成候选。
• 独立 MTP 草稿器：使用与目标模型匹配的独立检查点，并结合目标模型激活值和共享 KV cache 进行连续预测。
• 专用目标条件草稿网络：包括 EAGLE-3、DFlash 和 DSpark。EAGLE-3 基于目标模型隐藏状态进行自回归草拟；DFlash 面向候选块进行并行草拟；DSpark 则加入轻量级因果修正与基于置信度的前缀选择。

这些类别描述的是草稿组件，而不是目标模型家族。同一目标模型可能同时支持原生 MTP 和其他专用草稿模型。草稿器也并非完全独立运行：它可能接收目标模型隐藏表示、多个层的状态、KV cache，或由多种目标侧特征组合而成的信息。

性能不能只看提议长度

推测解码的收益取决于候选被目标模型接受的比例，以及草稿阶段带来的额外成本。提议 token 越多，并不意味着吞吐一定越高：如果后续候选频繁被拒绝，验证成本和草稿开销可能抵消并行推进的好处。vLLM 的实验观察显示，输出 token 吞吐会随草稿方法、提议长度、模型家族、草稿检查点和具体工作负载而变化。因此，部署时应围绕实际请求评估接受行为，而不是照搬某个固定配置。

意义与影响

这项实践的价值在于把推测解码从单一算法概念，落实为一组与模型和硬件协同的服务选项。对 AMD GPU 用户而言，ROCm 环境下的 MTP、EAGLE-3、DFlash 和 DSpark 提供了不同的速度—开销折中；对平台维护者而言，则需要同时观察输出 token 吞吐、候选接受情况、提议长度及草稿成本。更稳妥的路径是先以普通自回归解码建立基线，再逐项启用草稿方法，按模型和业务负载进行对照测试。推测解码的真正收益，不在于“多猜几个 token”，而在于候选质量足够高，使一次目标模型验证能够稳定推进更多有效输出。

来源：vLLM Blog