vLLM 与 Speculators 开源支持 P-EAGLE、DFlash、DSpark 三种并行草稿算法

1. 引言

推测解码已成为缓解大语言模型（LLM）服务中内存带宽瓶颈的核心优化技术。通过在单次验证器模型前向传播中验证多个候选 token，它使生产系统能够实现显著的推理加速。

然而，随着服务基础设施的演进，传统推测框架面临着一个结构性上限，其根源在于草稿 token 的生成方式。今天，我们很高兴展示 Speculators 和 vLLM 如何通过为三种最先进的并行草稿算法——P-EAGLE、DFlash 和 DSpark——提供完整的开源支持，从而突破这些限制。

Figure 1. Parallel drafting algorithms, such as P-EAGLE, DFlash and DSpark, provide significant performance gains when compared to autoregressive drafting algorithms such as EAGLE-3. Speculator models mentioned above can be found in the Speculators Collection at the RedHatAI HuggingFace Hub. — 图 1. 与 EAGLE-3 等自回归草稿算法相比，P-EAGLE、DFlash 和 DSpark 等并行草稿算法可带来显著的性能提升。上述推测器模型可在 RedHatAI HuggingFace Hub 的 Speculators Collection 中找到。

2. 递归草稿的局限

EAGLE 和 MTP 等框架的引入标志着推测解码领域的重大范式转变。EAGLE 没有强迫推测器模型从表层文本盲目猜测，而是证明推测器架构可以直接利用验证器模型丰富的内部隐藏状态，从而大幅提高 token 接受率。

尽管取得了这一突破，EAGLE-3 等高级迭代版本仍然受制于一个根本性约束：自回归草稿。为了提出一系列候选 token，推测器架构必须按顺序生成它们，为每个 token 执行单独的前向传播。

这种自回归设计在生产中引入了两大权衡：

模型规模限制：由于草稿成本随推测长度线性增长，推测器模型被迫保持极小且轻量，以避免消耗验证器模型验证过程中节省的执行时间。
复杂的运维调优：线性扩展在实际中严重限制了草稿 token 的数量。选择最优推测长度（K）成为一个敏感变量，工程团队必须根据具体用例和实时服务器负载不断调整。

Figure 2. Parallel drafting generates multiple draft tokens in a single step, whereas auto-regressive drafting generates one draft token per step. — 图 2. 并行草稿在单步中生成多个草稿 token，而自回归草稿每步生成一个草稿 token。

3. 向并行草稿的转变

并行草稿通过完全消除草稿阶段的顺序执行，从根本上重新设计了这一权衡。并行草稿算法不再循环执行单 token 生成步骤，而是同时预测整个候选 token 块。

通过将起草阶段压缩为单次前向传播，生成候选 token 的延迟与推测的 token 数量解耦。这一架构转变从两个不同方面简化了生产服务：

表达能力容量：由于推测模型每个块只运行一次，开发者可以使用更大、更稳健、表达能力更强的起草架构。这些更深的推测模型能够捕捉更复杂的上下文，并在不引入顺序延迟代价的情况下获得更高的接受率。
简化的参数调优：将起草成本与块长度解耦，消除了根据波动的服务器负载对推测参数进行超参调优的运维负担。

并行起草这一概念此前已被探索过——Medusa 和 PARD 是较早的著名例子。P-EAGLE、DFlash 和 DSpark 在此基础上，将并行执行与深度验证器状态条件化相结合，正是这一洞见让 EAGLE 如此成功。

4. 深入底层：推理与训练架构

P-EAGLE、DFlash 和 DSpark 都基于验证器模型的隐藏状态来并行生成候选 token，但各自采用了不同的实现路径。图 3 并排展示了它们的架构。

三者共同面临的一个挑战是训练。任何并行推测器都必须在训练序列的每个 token 位置上执行 next-K 预测。对于长度为 N 的序列和 K 的预看窗口，朴素地计算整个矩阵上的损失会导致内存和计算成本高得难以承受。每种算法以不同方式解决这一问题。

P-EAGLE

P-EAGLE 直接建立在 EAGLE 使用验证器模型隐藏状态作为输入特征的基础之上。P-EAGLE 不是用这些特征来顺序预测 token，而是将它们同时映射到多个未来位置，在单个并行步骤中输出整个候选 token 序列。

为保持训练可行，P-EAGLE 实现了起草块稀疏化：它按照衰减速率沿预看维度（K）丢弃 token，将优化集中在最关键的近期 token 上，同时从损失计算中剪除较远的未来位置。

DFlash

DFlash 以不同方式路由验证器特征。DFlash 不是将隐藏状态作为标准输入馈入，而是将其投影并直接注入推测器模型的 KV-cache。这在不扩展输入序列长度的情况下，将推测器的注意力机制紧密地条件化于验证器的精确状态，使其能够通过块扩散生成高度准确的候选 token 块。

在训练方面，DFlash 实现了序列长度稀疏化。它不是在长度为 N 的序列中的每个 token 位置计算块损失，而是沿时间线选择随机锚点，仅在这些交叉点计算块预测——在保持 GPU 内存的同时维持具有代表性的覆盖。

DSpark

DSpark 采用 DFlash 的并行主干，并在其上叠加了两项额外创新。首先，它通过一个轻量级自回归校正头来增强架构，使未来 token 能更强地以过去 token 为条件。这将并行生成的吞吐量优势与自回归细化的序列连贯性结合在一起。

其次，DSpark 解决了一个下游瓶颈：验证成本。并行草稿可以低成本地生成大量草稿 token，但验证器仍必须处理所有这些 token。DSpark 引入了一个置信度头，在草稿 token 到达验证器之前对其进行评分，只选择性地转发那些可能被接受的 token。这减少了浪费的验证计算，并提高了端到端吞吐量。

5. 推理性能

图 1 展示了并行草稿算法与 EAGLE-3 相比所带来的性能提升。图中展示了三种不同的模型和并行草稿算法：

模型	算法	用例	硬件
Qwen3-8B	P-EAGLE	数学推理（GSM8k）	1xA100
Qwen3-30B-A3B	DFlash	编码（HumanEval）	2xA100
gemma-4-31B-it	DSpark	编码（HumanEval）	2xA100

在所有情况下，并行草稿都显示出相较 EAGLE-3 的显著改进。性能会因模型、任务和硬件配置而异——我们鼓励社区在自己的工作负载上进行基准测试。

6. 使用 vLLM 和 Speculators 进行生产服务

将最先进的并行草稿算法集成到生产中需要稳定、优化的基础设施栈。Speculators 仓库提供了一个统一的生态系统来训练和评估这些下一代模型，并与 vLLM 完全集成。

启动一个由并行草稿支持的推测引擎，就像在初始化时传入适当的配置标志一样简单：

vllm serve Qwen/Qwen3-30B-A3B \
  --tensor-parallel-size 2 \
  --reasoning-parser qwen3 \
  --speculative-config '{
    "model": "RedHatAI/Qwen3-30B-A3B-speculator.dflash",
    "num_speculative_tokens": 7,
    "method": "dflash"
  }'

通过从单 token 生成转向块级并行草稿，你的推理流水线自下而上都变为并行——最大化硬件利用率，并提供持续的无损加速。（推测解码通过拒绝采样精确保留验证器模型的输出分布，因此质量在数学上与标准解码完全相同。）

7. 开始使用

并行草稿现已完全支持、开源且可用于生产。我们邀请社区探索该仓库，利用我们文档化的训练路径构建自己的并行推测器，并在 vLLM 中对其进行原生基准测试。

仓库：Speculators
预训练推测器：HuggingFace 上的 Speculators Collection
训练指南：Speculator 教程

勘误

图 1 中的图表已于 26 年 7 月 29 日更新。由于环境设置错误，原图表中的数字被证明与所报告的基准测试条件不一致。然而，模型之间的相对表现是一致的，博客中的结论没有改变。