P-EAGLE：在 vLLM 中实现并行投机解码加速 LLM 推理

EAGLE 是当前主流的投机解码方法，但它的自回归草稿生成方式存在一个隐性瓶颈：投机的 token 越多，drafter 需要的串行前向推理次数就越多，额外开销最终会侵蚀原本的加速收益。P-EAGLE 通过在单次前向推理中生成全部 K 个草稿 token，消除了这一上限，在 NVIDIA B200 上的真实工作负载中，相比 vanilla EAGLE-3 实现了最高 1.69x 的加速。

你只需下载或训练一个支持并行草稿生成的 drafter head，并在 vLLM serving 配置里加上 "parallel_drafting": true 即可启用这项能力。HuggingFace 上已经提供了 GPT-OSS 120B、GPT-OSS 20B 和 Qwen3-Coder 30B 的预训练 P-EAGLE head，现在就可以直接开始使用。

本文将介绍 P-EAGLE 的工作原理、它如何自 v0.16.0 起集成进 vLLM（PR #32887），以及如何使用预训练 checkpoint 部署。相关资源如下：

• ArXiv 论文
• HuggingFace 模型：GPT-OSS 120B、GPT-OSS 20B、Qwen3-Coder-30B-A3B-Instruct
• vLLM 集成：Unified Parallel Drafting
• vLLM-Speculators：RFC、PR

图 1：P-EAGLE 与其他方法在 SPEED-BENCH 上的对比，Concurrency 为 1，单卡 NVIDIA B200。

快速上手 P-EAGLE

在 SpeculativeConfig 中通过一个配置项即可启用并行草稿生成：

# vllm/config/speculative.py
parallel_drafting: bool = True

下面是在 vLLM 中使用 P-EAGLE drafter 启用 parallel drafting 的示例命令：

vllm serve openai/gpt-oss-20b \
  --speculative-config '{"method": "eagle3", "model": "amazon/gpt-oss-20b-p-eagle", "num_speculative_tokens": 5, "parallel_drafting": true}'

EAGLE 的草稿生成瓶颈

EAGLE 相比标准自回归解码通常可以实现 2–3× 加速，并且已经广泛部署在 vLLM、SGLang 和 TensorRT-LLM 等生产推理框架中。EAGLE 以自回归方式生成草稿 token，要产生 K 个草稿 token，就需要对 draft model 执行 K 次前向推理。随着 drafter 越来越擅长生成长输出，这部分开销会越来越显著，drafter 延迟会随着投机深度线性增长，从而限制了我们能把投机做多深。

核心方法：Parallel-EAGLE（P-EAGLE）

P-EAGLE 将 EAGLE 从自回归草稿生成改造成并行草稿生成。在 B200 GPU 上，P-EAGLE 在 GPT-OSS 20B 上的 MT-Bench、HumanEval 和 SpeedBench 基准中，相比 vanilla EAGLE-3 实现了 1.05×–1.69× 加速。它现在已经集成进 vLLM，可用于生产环境中的并行投机解码加速。

P-EAGLE 在单次前向推理中生成 K 个草稿 token。其架构如图 2 所示，包含两个步骤。

步骤 1：Prefilling。 目标模型像正常推理那样处理 prompt 并生成一个新 token。与此同时，P-EAGLE 记录模型的内部 hidden states：每个 prompt 位置对应的 h_prompt，以及新生成 token 对应的 h_context。这些 hidden states 编码了目标模型在各位置“知道”的信息，并将用于指导 drafter 的预测。这一步与自回归 EAGLE 完全相同。

步骤 2：P-EAGLE Drafter。 Drafter 为每个位置并行构造输入。每个输入由一个 token embedding 和一个 hidden state 拼接而成。

对于 prompt 位置，输入会将每个 prompt token 的 embedding emb(p) 与目标模型对应的 h_prompt 配对。与自回归 EAGLE 相同，位置会整体右移一位：位置 i 接收位置 i-1 的 token 和 hidden state，从而预测位置 i 的 token。

对于位置 1，也就是 Next-Token-Prediction（NTP），输入将新生成 token 的 embedding emb(new) 与 h_context 配对。这个位置的行为与标准自回归 EAGLE 完全一致。

对于位置 2 到 K，也就是 Multi-Token-Prediction（MTP），所需的 token embedding 和 hidden state 此时都还不存在。P-EAGLE 用两个可学习参数来填充这些位置：共享的 mask token embedding emb(mask) 和共享的 hidden state h_shared。它们是在训练中学到的固定向量，作为中性占位符使用。

所有位置一起通过 N 层 transformer，再经过 language model head，在一次前向推理中同时预测草稿 token t1、t2、t3 和 t4。

图 2：P-EAGLE 架构概览。

在长序列上训练 P-EAGLE

现代推理模型会生成很长的输出。如图 3 所示，GPT-OSS 120B 在 UltraChat 数据集上生成的序列（包含 prompt）中位长度为 3,891 token，P90 为 10,800 token。Draft model 必须在相同量级的上下文长度上训练，才能在推理阶段发挥作用。

图 3：GPT-OSS 120B 在 UltraChat 数据集上的序列长度（prompt + generation）分布。Reasoning level: Medium。

一个关键挑战在于，并行草稿生成会在训练时放大显存需求。在长度为 N 的序列上训练 K 个并行组，总共会形成 N × K 个位置。当 N = 8,192 且 K = 8 时，单个训练样本就包含 65,536 个位置。Attention 需要每个位置关注所有有效位置，65K × 65K 意味着超过 40 亿个元素，仅 bf16 下就会消耗约 8GB 显存。

Position sampling（An et al., 2025）可以通过随机跳过部分位置来减少显存占用，但跳过过多又会损害草稿质量。Gradient accumulation 是显存受限训练中的标准解法，但它是把不同训练样本拆开累积；如果单个序列本身就超出显存，那么就没有可拆的空间了。

P-EAGLE 为此引入了一种序列分区算法，用于在同一条序列内部进行拆分。该算法将 N × K 的位置序列切分为连续 chunk，在 chunk 边界上保持正确的 attention 依赖关系，并在同一条序列的多个 chunk 之间累积梯度。详细内容可参考 P-EAGLE 论文。

在 vLLM 中的实现

并行草稿生成的挑战

在很多投机解码实现里，草稿生成和验证阶段共享相同的 per-request token 布局。对 EAGLE 而言，这基本成立：drafter 消耗的窗口与 verifier 将要检查的内容大体一致，也就是 K 个草稿 token 再加一个额外采样 token。

并行草稿生成打破了这种一致性。为了在一次 drafter 前向推理中预测 K 个 token，我们需要追加 MASK 占位符，例如 [token, MASK, MASK, …]。这些额外位置只为草稿生成服务，因此 draft batch 的形状不再与 verification batch 一致。由于无法复用验证阶段的 metadata，就必须重建整套 batch metadata：扩展输入 token IDs、hidden states 和 positions 来插入 mask token 或 embedding 的 slot；按 request 增加 position；再根据新的 position 重新计算 slot mapping 和 per-request start indices。

Triton Kernel

为了抵消重建 batch metadata 的开销，实现里使用了一个融合的 Triton kernel，在 GPU 上通过复制和扩展 target-model batch 来填充 drafter 的输入 batch。这个 kernel 在一次 pass 中，会把旧的 token ID 和 position 从目标 batch 复制到新的目标 slot，并插入由目标模型为每个 request 采样出的 bonus token。随后，它会用特殊的 MASK token ID 填满额外的 parallel drafting slot。最后，它还会生成一组轻量 metadata：rejected-token mask、parallel drafting slot 对应的 masked-token mask、用于采样 draft token 的 new-token indices，以及 hidden-state mapping。

如果不做融合，这一逻辑会拆成很多 GPU 操作，例如 copy/scatter、insert、fill、mask 和 remap。把它们融合为一个 kernel 能减少 launch 开销和额外显存流量，使草稿准备阶段的成本保持很低。

Hidden State 管理

对于 EAGLE 这类将 hidden states 传给 draft model 的方法，并行草稿生成会单独处理这些字段的填充。由于 hidden states 比输入 batch 中其他字段大得多，因此实现将工作拆开：先由 Triton kernel 输出一个 mapping，再由专门的 copy kernel 把学到的 hidden state 占位符广播到 mask token 对应的 slot。

# 将目标 hidden states 复制到新位置
self.hidden_states[out_hidden_state_mapping] = target_hidden_states

# 用学到的 Parallel Drafting hidden state 填充 masked 位置
mask = self.is_masked_token_mask[:total_num_output_tokens]
torch.where(
    mask.unsqueeze(1),
    self.parallel_drafting_hidden_state_tensor,
    self.hidden_states[:total_num_output_tokens],
    out=self.hidden_states[:total_num_output_tokens],
)

parallel_drafting_hidden_state_tensor 从模型的 mask_hidden buffer 中加载，这是一个学到的表示，用来告诉模型这些位置应该预测未来 token。

在 KV cache slot mapping 方面，有效 token 会获得正常的 slot 分配，而 rejected token 会被映射到 PADDING_SLOT_ID (-1)，从而避免错误的 cache 写入。对于 CUDA graph，capture range 会扩展 K × max_num_seqs，以容纳 parallel drafting 带来的更大 draft batch。

vLLM 上的 P-EAGLE 基准测试

我们在 GPT-OSS-20B 上训练了 P-EAGLE，并在三个基准上进行了评估：用于多轮指令跟随的 MT-Bench、用于长代码生成的 SPEED-Bench Code，以及用于函数级代码合成的 HumanEval。相较于公开可用的 vanilla EAGLE-3 checkpoint，P-EAGLE 在低并发（c=1）下带来 55–69% 的吞吐提升，在高并发（c=64）下仍保持 5–25% 的收益。结果见图 4–6。

P-EAGLE drafter 是一个轻量的 4 层模型，训练目标是并行预测最多 10 个 token。为了评估性能，我们扫描了投机深度 K ∈ {3,5,7} 和并发级别 C ∈ {1,2,4,8,16,32,64}。目标是在给定部署条件下分别找出 P-EAGLE 和 vanilla EAGLE-3 的最佳配置。两者都使用 linear drafting。文中的 “best P-EAGLE” 和 “best EAGLE-3” 指的是在给定投机深度 K 下达到峰值 TPS 的配置。

一个很稳定的模式出现了：P-EAGLE 在所有并发级别下都在 K=7 达到峰值 TPS。而 vanilla EAGLE-3 通常在 K=3 达到最高 TPS，尽管在某些并发下它对更高 K 也会略有偏好。这一现象反映了并行草稿生成的核心优势：P-EAGLE 在单次前向推理中生成全部 K 个草稿 token，因此可以在不增加串行开销的前提下从更深的投机中获益；而自回归 drafter 必须逐 token 串行生成，难以有效扩展到更大的 K。

所有实验都在单卡 NVIDIA B200（Blackwell）GPU 上，使用以下 vLLM 配置完成：

VLLM_USE_FLASHINFER_MOE_MXFP4_MXFP8=1 \
vllm serve openai/gpt-oss-20b \
    --speculative-config '{
      "method": "eagle3",
      "model": "amazon/GPT-OSS-20B-P-EAGLE",
      "num_speculative_tokens": 7,
      "parallel_drafting": true}' \
    --port 8000 \
    --max-num-seqs 1024 \
    --max-model-len 100000 \
    --max-num-batched-tokens 100000 \
    --max-cudagraph-capture-size 4096 \
    --no-enable-prefix-caching \
    --no-enable-chunked-prefill \
    --kv-cache-dtype fp8 \
    --async-scheduling \
    --stream-interval 20

注意。 目前在 vLLM 上部署带 EAGLE drafter 的 GPT-OSS-20B 仍需要一个单行 patch（PR #36684）。请在启动前先应用。该修复预计会在后续 vLLM 版本中合入。

图 4：P-EAGLE 与 EAGLE-3 在 GPT-OSS-20B 上不同并发级别下的 MT-Bench 吞吐（TPS）对比。P/E 加速比分别为：1.55x（c=1）、1.29x（c=2）、1.35x（c=4）、1.28x（c=8）、1.27x（c=16）、1.09x（c=32）和 1.05x（c=64）。

图 5：P-EAGLE 与 EAGLE-3 在 GPT-OSS-20B 上不同并发级别下的 HumanEval 吞吐（TPS）对比。P/E 加速比分别为：1.55x（c=1）、1.53x（c=2）、1.45x（c=4）、1.35x（c=8）、1.31x（c=16）、1.37x（c=32）和 1.23x（c=64）。

图 6：P-EAGLE 与 EAGLE-3 在 GPT-OSS-20B 上不同并发级别下的 Speed-bench 吞吐（TPS）对比。P/E 加速比分别为：1.69x（c=1）、1.61x（c=2）、1.54x（c=4）、1.45x（c=8）、1.40x（c=16）、1.22x（c=32）和 1.25x（c=64）。

除了草稿生成开销下降之外，P-EAGLE 的吞吐提升还来自更高的 Acceptance Length（AL），即 verifier 每轮投机中平均接受的草稿 token 数。更高的 AL 意味着更多草稿工作真正变成了输出，从而直接提升有效 OTPS/TPS。

下面的表格对比了 P-EAGLE 与 vanilla EAGLE-3 在 GPT-OSS-20B 上三个基准的 AL：

P-EAGLE（AL）

Config	HumanEval	SPEED-Bench	MT-Bench
K=3	3.02	2.87	2.87
K=7	3.94	3.38	3.70

EAGLE-3（AL）

Config	HumanEval	SPEED-Bench	MT-Bench
K=3	2.65	2.24	2.70
K=7	3.03	2.59	3.27

在相同投机深度 K 下，P-EAGLE 始终获得比 EAGLE-3 更高的 AL。以 K=7 为例，P-EAGLE 在 HumanEval 上比 EAGLE-3 高 30%（3.94 vs 3.03），在 SPEED-Bench 上高 31%（3.38 vs 2.59），在 MT-Bench 上高 13%（3.70 vs 3.27）。值得注意的是，P-EAGLE 从更深投机中获益也更明显：从 K=3 提升到 K=7 时，P-EAGLE 在 HumanEval 上的 AL 增加了 0.92（3.02 → 3.94），而 EAGLE-3 只增加了 0.38（2.65 → 3.03）。这一随着更高 K 持续拉大的差距，与 P-EAGLE 单次并行草稿生成的特性完全一致，因为更深投机不会引入额外串行成本。

复现结果

启动服务后，可以使用 vllm bench serve 运行基准测试：

# MT-Bench
export MODEL="openai/gpt-oss-20b"
export BASE_URL="http://localhost:8000"
vllm bench serve \
    --dataset-name hf \
    --dataset-path philschmid/mt-bench \
    --num-prompts 80 \
    --max-concurrency 1 \
    --model $MODEL \
    --base-url $BASE_URL \
    --temperature 0.0 \
    --hf-output-len 2048

# HumanEval
# Download HumanEval dataset openai/openai_humaneval
vllm bench serve \
    --dataset-name custom \
    --dataset-path <dataset path> \
    --num-prompts 164 \
    --max-concurrency 1 \
    --model $MODEL \
    --base-url $BASE_URL \
    --temperature 0.0 \
    --custom-output-len 2048

结论

P-EAGLE 消除了投机解码中的串行瓶颈，在真实工作负载中实现了相比 vanilla EAGLE-3 最高 1.69× 的加速。通过将草稿数量与前向推理次数解耦，我们现在可以探索更大的 drafting 架构，甚至能够获得比单层 baseline 更高的接受率。该实现通过手写融合 kernel，细致处理了输入准备、attention metadata 管理和 KV cache slot mapping 的复杂性。虽然它需要专门训练的模型，但其性能收益使它成为 vLLM 投机解码能力中的一个重要补充。

随着更多并行训练模型的出现，我们预计这种方法会成为生产级 LLM 部署中的优选方案。P-EAGLE 的架构效率与 vLLM 扎实的基础设施结合，为追求极致推理性能和更低延迟的部署场景提供了一条清晰路径。

现在就试试：从 HuggingFace 下载一个预训练 P-EAGLE head，在 vLLM 配置里设置 "parallel_drafting": true，然后直接体验加速效果。

致谢

AWS： Xin Huang, Florian Saupe, Jaime Campos Salas, Ashish Khetan, George Karypis

NVIDIA： Benjamin Chislett, Max Xu, Zeyuan (Faradawn) Yang, Kaihang Jiang, Xin Li, Omri Almog

同时也特别感谢 vLLM 社区维护者提供的 review、指导和优秀基础设施，让这项特性的实现成为可能。

本文也同步发布在 AWS Blogs。

参考链接

• EAGLE
• GPT-OSS 120B P-EAGLE
• GPT-OSS 20B P-EAGLE
• Qwen3-Coder 30B P-EAGLE
• vLLM v0.16.0
• P-EAGLE Paper
• Unified Parallel Drafting PR
• vLLM-Speculators RFC
• vLLM-Speculators PR
• Position Sampling
• MT-Bench
• HumanEval
• EAGLE-3 Checkpoint
• GPT-OSS Patch
• AWS Blogs
• 英文原文：vllm.ai/blog/p-eagle