并行草稿解码：从 DFlash 到 DSpark 的推测解码范式转移

2024-2025 年的推测解码选型很简单：从 Medusa 到 EAGLE 再到 EAGLE-3，核心改进是草稿模型的架构效率，但草稿生成本质上仍是自回归——一个 token 接一个 token 地猜。EAGLE 3.1 修复了长草稿链中的注意力漂移问题，把接受率推到 88%，但自回归草稿的延迟瓶颈始终存在：草稿越长，草稿模型自身的推理时间也越长，最终抵消掉并行验证的收益。实测中，EAGLE-3 的整体加速上限被锁在 2-3×（据 EAGLE-3 论文，NeurIPS 2025）。

2026 年 2-6 月，两个独立研究打破了这个上限：

• DFlash（ICML 2026）：据 DFlash 论文（Chen et al., arXiv:2602.06036，2026-02），用块扩散（Block Diffusion）替代自回归草稿，在单次前向传播中并行生成整个草稿块。在 Qwen3-8B 上实现 6.08× 无损加速，比 EAGLE-3 快 2.5 倍以上。
• DSpark（DeepSeek-AI + 北京大学）：据 DSpark 论文（Cheng et al., arXiv:2607.05147，2026-06-27），用半自回归（Semi-Autoregressive）架构——并行骨干加轻量马尔可夫头——在 DeepSeek-V4 生产系统中实现 60-85% 的用户生成速度提升，同时通过 DeepSpec 开源仓库 发布了训练代码和预训练检查点。

这两个方案不是 EAGLE 系列的渐进改进，而是草稿生成范式的根本转变：从"串行猜、并行验"到"并行猜、并行验"。对部署团队而言，这意味着推测解码的加速上限从 2-3× 被推到 5-6×，同时生产部署模式也发生了变化。

边界说明：本文聚焦并行草稿解码的机制、工程权衡和生产部署。自回归草稿的四代架构演进（Medusa → EAGLE → EAGLE-3 → EAGLE 3.1）已在 kb-speculative-decoding-001 中详细覆盖，本文不重复。扩散语言模型（如 Mercury 2，Inception AI）作为更激进的范式替代，本文仅在最后一节讨论其与传统推测解码的关系。

在理解并行草稿之前，必须先看清自回归草稿为什么撞墙。

自回归草稿的延迟方程：设草稿块长度为 γ（推测步数），草稿模型每生成一个 token 需要一次前向传播。草稿块的总延迟 = γ × 单次草稿前向传播时间。验证阶段，目标模型一次前向传播验证 γ 个 token，验证延迟基本固定。

关键矛盾：γ 越大，理论上每次验证赚的 token 越多，但草稿延迟也线性增长。当 γ 超过某个拐点后，草稿延迟的增长速度超过验证收益，整体加速反而下降。EAGLE-3 的实测最优 γ 通常在 5-8 之间，对应 2-3× 加速。

EAGLE 3.1 的注意力漂移修复提升了接受率（γ=8 下从 75% 到 88%），但没有改变延迟方程本身——草稿模型仍然需要 γ 次串行前向传播。接受率提升让实际赚到的 token 更多，但草稿生成的时间成本没有减少。

并行草稿的核心洞察：如果草稿模型能在单次前向传播中生成整个 γ 长度的 token 块，草稿延迟就不再随 γ 线性增长，而是近似恒定。这意味着可以使用更大的 γ（比如 γ=15-20），在验证阶段一次赚到更多 token，而草稿阶段的时间成本几乎不增加。

并行草稿的两个工程挑战：

1. 草稿质量：并行生成的 token 之间没有串行依赖，后部 token 的质量通常显著低于前部。如果草稿质量太差，验证阶段全部拒绝，并行草稿反而浪费验证计算。
2. 验证浪费：即使草稿质量整体不错，少数低质量 token 也会导致整个块被拒绝。如何只验证高置信度的 token、跳过低置信度的 token，是生产部署的关键。

DFlash 和 DSpark 分别解决了这两个挑战。

DFlash 的核心创新：用轻量级块扩散模型（Block Diffusion Model）替代自回归草稿模型，在单次前向传播中并行生成 γ 个 token。

块扩散的工作原理：扩散模型在图像生成中已经成熟——从噪声开始，通过多次去噪迭代逐步生成图像。DFlash 把这个思路应用到文本草稿生成：草稿模型从一组随机 token 开始，通过 3-5 次去噪迭代，逐步收敛到一个 γ 长度的 token 块。每次去噪迭代更新所有 γ 个位置，而不是从左到右逐个生成。

关键工程细节——KV 注入（KV Injection）：DFlash 的草稿模型不是独立运行的。目标模型在 prefill 阶段（处理输入 prompt）时，每一层都会产生隐藏状态（hidden states）。DFlash 把这些多层隐藏状态作为 KV（Key-Value）直接注入到草稿模型的每一层 Transformer 中。这意味着草稿模型在生成每个 token 时，都能"看到"目标模型对整个输入的深度理解，而不是仅靠最后一层的输出。

为什么 KV 注入如此重要：自回归草稿模型（如 EAGLE）也使用目标模型的隐藏状态，但通常只用最后一层。DFlash 的论文发现，目标模型的中间层隐藏状态已经"隐式"编码了多个未来 token 的信息——草稿模型不需要从零开始推理，只需要充当一个轻量级的"扩散适配器"，把目标模型已经计算好的特征翻译成未来 token 块。

DFlash 的架构参数：

• 草稿模型：5 层 Transformer，约 200-400M 参数（取决于目标模型规模）
• 去噪迭代次数：3-5 次（不是扩散模型通常的 50-100 次，因为草稿不需要完美，只需要足够好让目标模型验证）
• 额外显存：约 1-2% 目标模型大小（比 EAGLE-3 的 1-3% 略低）
• 训练数据：与 EAGLE 风格类似，需要目标模型的隐藏状态 + token 配对数据

DFlash 的基准测试结果（Qwen3-8B，Transformers 后端，据 DFlash 论文 Figure 1）：

关键观察：DFlash 在数学和代码任务上的加速比最高（5-6×），在开放式对话（MT-Bench）上加速比较低（2.75×）。这是因为数学和代码的下一个 token 分布更集中、更可预测，扩散草稿更容易猜对；开放式对话的下一个 token 分布更分散，并行草稿的后部 token 质量下降更严重（DFlash 论文 Section 4.2 详细分析了这一现象）。

DFlash 的局限：

1. 块内独立性假设：并行生成的 γ 个 token 之间没有显式依赖。"of" 和 "problem" 各自是合理的 token，但组合成 "of problem" 就不合理。这种块内不连贯导致后部 token 的接受率显著低于前部。
2. MT-Bench 加速有限：开放式任务中，DFlash 的加速比只有 2.75×，接近 EAGLE-3 的水平。这说明并行草稿在低熵任务（数学、代码）上收益最大，在高熵任务（对话、创意写作）上收益有限。
3. 训练复杂度：块扩散草稿模型的训练比自回归草稿更复杂，需要精心设计去噪目标和迭代次数。

DSpark 解决了 DFlash 的核心局限：块内 token 独立性导致的质量问题。它的思路是——不完全放弃串行依赖，而是用极轻量的串行修正层（马尔可夫头）来补充并行骨干。

DSpark 的架构：

1. 并行骨干（Parallel Backbone）：3 层 MoE（Mixture of Experts）Transformer，负责快速生成 γ 个 token 的初始预测。这一层与 DFlash 类似，在单次前向传播中并行生成。
2. 马尔可夫头（Markov Head）：一个极轻量的串行修正层。对于并行骨干生成的第 i 个 token，马尔可夫头只依赖第 i-1 个 token 和一个低秩矩阵，计算量几乎可以忽略。它的作用是修正块内的局部不连贯——比如把 "of problem" 修正为 "no problem"。
3. 置信调度验证（Confidence-Scheduled Verification）：不是所有 γ 个 token 都送给目标模型验证。DSpark 根据草稿模型的置信度动态决定验证哪些 token。高置信度的 token 直接验证，低置信度的 token 跳过（回退到自回归生成）。这避免了"验证浪费"——验证低质量 token 不仅浪费时间，还可能因为拒绝率过高导致整个块被丢弃。

马尔可夫头 vs RNN 头：DSpark 论文对比了两种串行修正结构。RNN 头在块内维护一个循环状态，理论上能捕获更长的依赖，但计算开销更高。马尔可夫头只用前一个 token，开销几乎为零。DeepSeek 的实测发现，马尔可夫头已经能捕获绝大部分收益，RNN 头的额外收益微乎其微。因此 DeepSeek-V4 生产部署使用的是马尔可夫头。

置信调度的工程细节：草稿模型对每个 token 输出一个置信度分数。DSpark 使用一个学习的阈值函数，根据 token 位置和置信度决定是否验证。直觉上：块的前部 token 置信度高、接受率高，几乎全部验证；块的后部 token 置信度低、接受率低，大部分跳过。这种动态调度让 DSpark 在高 γ（10-15）下仍然保持高效的验证利用率。

DSpark 的生产部署成果（据 DSpark 论文 Section 5 和 DeepSeek-V4 技术报告，DeepSeek-V4，2026-06）：

关键洞察：DSpark 的价值不仅是"更快"，而是"在严格 SLA 下不退化"。传统的 MTP-1 基线在严格交互约束（如 120 TPS for Flash、50 TPS for Pro）下，吞吐量会严重退化。DSpark 通过置信调度避免了验证浪费，在相同 SLA 下维持了稳健的吞吐量，实际上扩展了系统的可操作边界（DSpark 论文 Section 5.3 详细讨论了 SLA 约束下的性能表现）。

DeepSpec 开源仓库：DeepSeek 开源了 DeepSpec，包含 DFlash、DSpark 和 EAGLE-3 的训练和评估代码。alphaxiv 的 DSpark 论文解读 提供了对半自回归草稿机制的深入分析。这意味着团队可以直接复现论文结果，并在自己的模型上训练并行草稿模型。

并行草稿不是要替代 EAGLE-3，而是在特定场景下提供更高的加速上限。选型决策取决于三个因素：任务类型、延迟 SLA 和工程投入意愿。

任务类型：

• 低熵任务（数学、代码、结构化输出）：并行草稿收益最大。DFlash 在数学和代码上达到 5-6× 加速，远超 EAGLE-3 的 2-3×。如果你的推理服务主要处理代码补全、数学推理或 JSON 生成，并行草稿是明确的升级路径。
• 高熵任务（开放式对话、创意写作）：并行草稿收益有限。DFlash 在 MT-Bench 上只有 2.75×，接近 EAGLE-3。如果你的服务以对话为主，EAGLE 3.1 仍然是更稳妥的选择。
• 混合负载：DSpark 的置信调度在混合负载下表现更稳健，因为它能动态跳过低置信度的 token。如果你的服务同时处理代码和对话，DSpark 是更好的折中。

延迟 SLA：

• 严格 SLA（<100ms TTFT，高并发）：DSpark 的生产部署经验表明，置信调度在严格 SLA 下能避免验证浪费，维持稳健吞吐量。如果你的服务有严格的延迟约束，DSpark 的调度策略是关键优势。
• 宽松 SLA（<500ms TTFT，批处理）：DFlash 的纯并行方案在宽松 SLA 下可以最大化加速比，不需要置信调度的额外复杂度。

工程投入：

• 快速部署：EAGLE-3 仍然是 vLLM 的默认方案，开箱即用。如果你需要在一周内完成部署，EAGLE-3 是最安全的选择。
• 中期优化：DSpark 的 DeepSpec 仓库已经包含训练脚本和预训练检查点（DeepSeek-V4-Flash 和 V4-Pro）。如果你的团队有 2-4 周的工程预算，可以训练自己的 DSpark 草稿模型。
• 长期研究：DFlash 的块扩散架构在基准测试中表现最好，但生产部署经验较少。如果你的团队有研究能力，DFlash 提供了最高的加速上限。

决策树：

1. 你的主要负载是低熵任务（代码、数学、结构化输出）吗？

   • 是 → 评估 DFlash 或 DSpark
   • 否 → 继续使用 EAGLE 3.1

2. 你有严格的延迟 SLA（<100ms TTFT）吗？

   • 是 → 选择 DSpark（置信调度）
   • 否 → 选择 DFlash（最大加速）

3. 你的团队有 2-4 周的工程预算训练草稿模型吗？

   • 是 → 使用 DeepSpec 训练 DSpark 或 DFlash
   • 否 → 继续使用 EAGLE-3，等待 vLLM 集成并行草稿

并行草稿的生产部署与自回归草稿有几个关键差异，需要在部署前解决。

训练数据准备：DFlash 和 DSpark 都需要目标模型的隐藏状态 + token 配对数据。与 EAGLE 类似，需要从目标模型导出每一层（DFlash）或最后几层（DSpark）的隐藏状态。DeepSpec 仓库提供了数据导出脚本，但需要注意：

• 隐藏状态的数据量显著大于 token 数据。每条样本的隐藏状态大小 ≈ 模型参数量 × 序列长度 × 层数（DFlash）或最后 3 层（DSpark）。对于 70B 模型，单条样本的隐藏状态可能达到数 GB。
• 训练数据需要覆盖目标任务的分布。如果目标服务主要处理代码，训练数据应该以代码为主，而不是通用语料。

草稿模型训练：

• DFlash 的块扩散训练目标与标准扩散模型不同。它使用 order-agnostic cross entropy（顺序无关交叉熵），允许模型在任意去噪迭代次数后输出合理的 token 块。训练迭代次数通常设为 3-5 次（推理时也使用相同次数）。
• DSpark 的训练分两阶段：先训练并行骨干（3 层 MoE），再训练马尔可夫头。马尔可夫头的训练数据是并行骨干的输出 + 目标 token，训练目标是预测下一个 token。

推理配置：

• vLLM 目前（2026-08）尚未原生集成 DFlash 或 DSpark。团队需要使用 DeepSpec 仓库的推理脚本，或等待 vLLM 集成。
• γ 的初始设置：DFlash 建议 γ=15-20，DSpark 建议 γ=10-15。从保守值开始，逐步增大直到接受率下降到 60% 以下。
• 置信调度阈值（仅 DSpark）：DeepSpec 提供了预训练的阈值函数，但需要根据目标任务的置信度分布微调。

监控指标：

• 块接受率（Block Acceptance Rate）：整个 γ 长度块被完全接受的比例。健康范围 40-60%（低于自回归草稿的 70-90%，因为并行草稿的块更长）。
• token 接受率（Token Acceptance Rate）：γ 个 token 中被接受的比例。健康范围 60-80%。
• 验证利用率（Verification Utilization，仅 DSpark）：实际验证的 token 数 / γ。健康范围 70-90%。如果低于 60%，说明置信调度过于激进，跳过了太多 token。
• 端到端 TPOT（Time Per Output Token）：对比开启/关闭并行草稿的 TPOT，确认实际加速。

常见陷阱：

1. 训练数据分布不匹配：如果训练数据以通用语料为主，但目标服务处理代码，草稿模型在代码任务上的接受率会显著下降。必须用目标任务的数据训练。
2. 去噪迭代次数不匹配：DFlash 训练时的迭代次数必须与推理时相同。如果训练用 5 次，推理用 3 次，接受率会大幅下降。
3. γ 设置过大：虽然并行草稿的延迟不随 γ 线性增长，但 γ 过大会导致块内 token 质量下降，接受率降低。实测 γ=15-20 是 DFlash 的拐点，γ=10-15 是 DSpark 的拐点。
4. 忽略马尔可夫头（DSpark）：马尔可夫头的计算开销几乎为零，但能显著提升块内连贯性。跳过马尔可夫头会导致后部 token 接受率下降 10-15%。

DFlash 和 DSpark 仍然属于推测解码框架——它们用扩散或半自回归方法加速草稿生成，但最终仍需要目标模型的自回归验证。扩散语言模型（Diffusion LLM） 走得更远：完全放弃自回归解码，用扩散过程直接生成完整输出。

Mercury 2（Inception，2026-02） 是目前最成熟的商业扩散语言模型。据 Mercury 技术报告（arXiv:2506.17298），它的工作原理：

• 从一组随机噪声 token 开始
• 通过 5-10 次去噪迭代，逐步收敛到完整输出
• 每次去噪迭代更新所有位置的 token，而不是从左到右逐个生成
• 在 NVIDIA Blackwell GPU 上达到 1,009 tok/s，而自回归模型通常只有 100 tok/s（据 Inception 2026-02 发布数据）

Mercury 2 与推测解码的关键区别：

• 推测解码（包括 DFlash/DSpark）：草稿模型并行生成，目标模型自回归验证。输出质量由目标模型保证，与标准自回归解码完全一致。
• 扩散语言模型：没有目标模型验证。输出质量完全由扩散模型自身保证。这意味着质量可能低于同规模的自回归模型，但速度快 10 倍。

Mercury 2 的质量定位：

• AIME 2025：~91.1%（与 GPT-4o 同级）
• GPQA：~73.6%
• LiveCodeBench：~67.3%
• 输出价格：$0.75 / 1M token

这些数据来自 Inception 官方报告，尚未经过完全独立的第三方验证。Copilot Arena 的早期数据显示，Mercury Coder Mini 在质量上排名第二、延迟上排名第一（~0.25 秒），但这是 Mini 版本，不是完整的 Mercury 2。

对部署团队的启示：

• 如果你的任务对延迟极度敏感（如实时交互、代码补全），且质量要求可以接受 5-10% 的下降，Mercury 2 值得评估。
• 如果你的任务需要与 frontier 自回归模型完全一致的质量（如医疗、法律、金融），扩散语言模型目前还不适合。
• DFlash 和 DSpark 的优势在于：它们保留了目标模型的自回归验证，输出质量与标准推测解码完全一致，同时获得了 5-6× 的加速。这是质量与速度的更优折中。

更长线的趋势：扩散语言模型的训练方法和推理架构正在快速演进。Mercury Edit 2（2026-03）专门针对代码编辑任务优化，使用 KTO（Kahneman-Tversky Optimization）对齐，在接受率上提升 48%。如果扩散语言模型的质量在 2026 下半年继续提升，它们可能从"第二档"变成某些任务的首选。

2026 年的推测解码不再是"EAGLE-3 还是 EAGLE 3.1"的简单选择。并行草稿（DFlash）和半自回归草稿（DSpark）把加速上限从 2-3× 推到 5-6×，同时 DeepSeek 的生产部署证明了这些方案在大规模服务中的可行性。

核心原则：

1. 自回归草稿（EAGLE-3/3.1）仍然是默认起点：它在 vLLM 中原生集成，部署最简单，适合大多数通用场景。如果你的团队没有明确的加速需求或工程预算，继续使用 EAGLE-3。

2. 低熵任务升级到并行草稿：代码、数学、结构化输出任务的下一个 token 分布集中，并行草稿的加速收益最大。DFlash 在这些任务上达到 5-6× 加速。

3. 严格 SLA 选择 DSpark：置信调度在严格延迟约束下避免验证浪费，维持稳健吞吐量。DeepSeek-V4 的生产数据证明了这一点。

4. 扩散语言模型是更长线的选项：Mercury 2 的 10× 速度提升很有吸引力，但质量验证尚不充分。DFlash/DSpark 保留了目标模型验证，是更稳妥的加速路径。

5. 监控接受率和验证利用率：并行草稿的块接受率（40-60%）低于自回归草稿（70-90%），但 token 接受率（60-80%）和端到端加速更高。必须同时监控这两个指标，以及 DSpark 的验证利用率。

推测解码的范式转移已经开始。2026 年底，并行草稿很可能成为 vLLM 等主流框架的默认选项。现在评估和实验，能为未来的升级做好准备。

1. J. Chen, Y. Liang, Z. Liu. "DFlash: Block Diffusion for Flash Speculative Decoding." arXiv:2602.06036, February 2026. Accepted at ICML 2026. — DFlash 原始论文，提出块扩散并行草稿架构，在 Qwen3-8B 上实现 6.08× 无损加速。

2. X. Cheng, X. Yu, C. Shao, et al. (DeepSeek-AI + Peking University). "DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation." arXiv:2607.05147, June 27, 2026. — DSpark 论文，提出半自回归草稿 + 置信调度，在 DeepSeek-V4 生产系统实现 60-85% 用户生成速度提升。

3. DeepSeek-AI. "DeepSpec: Training and Evaluation Repository for Speculative Decoding." GitHub: deepseek-ai/DeepSpec, 2026. — 开源仓库，包含 DFlash、DSpark、EAGLE-3 的训练和评估代码，以及 DeepSeek-V4-Flash 和 V4-Pro 的预训练草稿模型检查点。

4. Inception AI. "Mercury: Ultra-Fast Language Models Based on Diffusion." arXiv:2506.17298, June 2025. — Mercury 扩散语言模型的技术报告。

5. Inception AI. "Mercury 2 Launch Announcement." February 24, 2026. — Mercury 2 发布公告，报告 1,009 tok/s 吞吐量和 AIME 2025 91.1% 成绩。

6. DeepSeek-AI. "DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence." arXiv:2606.19437, 2026. — DeepSeek-V4 技术报告，包含 DSpark 的生产部署细节。