下一代投机解码：DFlash 与 Spec V2

通过将 Modal 和 Z Lab 的 DFlash 投机解码模型与 SGLang 新近默认启用的 Spec V2 引擎结合使用，你可以为 LLM 推理服务实现最先进的延迟表现。我们联合发布的新 DFlash 模型（面向 Qwen 3.5 397B-A17B）在我们基准测试的所有设置下，吞吐量均高于基线模型和原生 MTP 投机解码。在 HumanEval 编码数据集上、并发数为 1 时，它的吞吐量达到基线的 >4.3 倍，以及 MTP 的 1.5 倍。

工作负载：Qwen 3.5 397B-A17B（BF16），HumanEval。设置：贪心解码，启用思考，最大新生成 token 数 4096。硬件：Modal 上的 8xB200。接受长度按请求取平均。草稿 token/块数量按最大吞吐量选取（MTP：7 步；DFlash：块大小 16）。

为庆祝此次合作，我们将在我们的三个 Hugging Face 组织下同时发布该模型：

• z-lab/Qwen3.5-397B-A17B-DFlash
• modal-labs/Qwen3.5-397B-A17B-DFlash
• lmsys/Qwen3.5-397B-A17B-DFlash

你可以使用以下命令自行试用该模型：

export SGLANG_ENABLE_OVERLAP_PLAN_STREAM=1

python -m sglang.launch_server \
  --model-path Qwen/Qwen3.5-397B-A17B \
  --trust-remote-code \
  --speculative-algorithm DFLASH \
  --speculative-draft-model-path modal-labs/Qwen3.5-397B-A17B-DFlash \
  --speculative-dflash-block-size 8 \
  --speculative-draft-attention-backend fa4 \
  --attention-backend trtllm_mha \
  --linear-attn-prefill-backend triton \
  --linear-attn-decode-backend flashinfer \
  --mamba-scheduler-strategy extra_buffer \
  --tp-size 8 \
  --max-running-requests 32 \
  --cuda-graph-max-bs-decode 32 \
  --cuda-graph-backend-prefill tc_piecewise \
  --enable-flashinfer-allreduce-fusion \
  --mem-fraction-static 0.8 \
  --host 0.0.0.0 \

下面，我们将介绍 DFlash 用于投机解码的新型扩散 + KV 注入策略，说明它为何对实现大幅加速至关重要，以及 Z Lab、SGLang 和 Modal 的团队如何携手合作，让所有人都能用上这些加速成果。

DFlash：通过 KV 注入进行并行草拟

基于 Transformer 的大语言模型（LLM）能力强大，但其自回归解码过程使推理变得缓慢：token 必须逐个生成，算术强度低，使其难以适配现代硬件。

投机解码通过使用一个更小、更快的草拟模型来提出多个 token，再由目标 LLM 并行验证，从而解决这一瓶颈，且不影响模型质量。

然而，许多投机解码方法，例如 EAGLE 系列，以及近期模型如 Gemma 4 和 DeepSeek-V4 中原生的多 token 预测（MTP）模块，仍然依赖串行自回归——只不过是在草稿模型而非目标模型中进行。草稿模型逐个生成草稿 token，这与现代硬件并不契合，也限制了可实现的加速比。

正因如此，Z Lab 开发了 DFlash，它使用一个轻量级的块扩散草稿模型来并行生成整个草稿 token 块，正是 GPU 和 TPU 所喜欢的方式。小米新的 MiMo v2.5-Pro-UltraSpeed 使用 DFlash 实现了 超过 1k 的输出 tps。

使用块扩散进行投机起草并非易事。直接训练一个小型块扩散模型作为起草器会导致接受长度偏低，而使用像 SpecDiff-2 这样已有的大型扩散 LLM 作为起草器则会带来巨大的内存占用和高昂的起草成本。

DFlash 的核心洞见很简单：目标 LLM 最了解上下文。受 Medusa、EAGLE 和 MTP（Gloeckle 等，2024；Samragh 等，2025）等先前方法的启发，我们从目标模型中提取上下文 token 的隐藏表示。与先前工作不同，我们将它们直接注入起草模型的 KV cache。这种方式在起草深度增加时扩展性更好。KV 注入还允许起草模型跳过从头建模完整上下文的过程，纯粹专注于预测下一个 token 块——使用与目标模型后层相同的张量！

通过这一设计，DFlash 利用了目标 LLM 生成的丰富且高度相关的上下文特征，同时保持起草模型极其小巧高效。因此，DFlash 在低起草延迟下实现了高接受长度。

DFlash 为什么如此之快？

投机解码的加速主要取决于两个因素：每个周期接受多少起草的 token，以及起草模型增加多少额外成本。DFlash 同时改善了两者：扩散起草降低了起草成本，KV 注入提高了接受率。

具体来说，让我们比较一个 5 层 EAGLE-3 drafter 与几个 5 层 DFlash 变体 drafter 的端到端接受长度和速度，这些 drafter 都是在同一数据集上为 Qwen 3-4B 训练的。基线 DFlash 的接受长度与 5 层 EAGLE-3 drafter 相近，但得益于其超快的并行起草，它带来了更高的端到端加速。结果报告为 acc_len / speedup。

DFlash 起草更快

像 EAGLE-3 这样的自回归草稿模型会逐个生成草稿 token。随着草稿长度增加，草稿成本大致呈线性增长。为了保持低延迟，这些方法通常依赖非常浅的草稿模型，这限制了草稿质量。

DFlash 通过块扩散草稿模型避开了这一瓶颈。它通过单次前向传播并行生成一整块 token，使草稿生成对硬件更加友好。一个 5 层的 DFlash 草稿模型生成 4、8 甚至 16 个 token，其草稿延迟远低于单层 EAGLE-3 草稿模型生成 4 个 token 的延迟。

通过消融 DFlash 的其他架构特性，我们可以观察到这项技术的独立影响。得益于更快的草稿生成，即使在较低的接受长度下，DFlash 仍能提供比 EAGLE-3 更高的端到端加速。

KV 注入提升了接受长度

快速草稿只有在草稿 token 被接受时才有帮助。EAGLE-3 仅在草稿模型的输入端使用目标模型特征，而这一信号在更深的草稿模型中会逐渐衰减。

DFlash 则改为将目标特征注入到每一层草稿层的 KV cache 中。这使得草稿模型在整个生成过程中都强烈地以目标模型的上下文为条件，从而让更深的草稿模型能够生成更高质量的草稿。

我们还可以通过消融扩散草稿来观察 KV 注入的独立影响。在我们的端到端基准测试中，自回归模式下的 DFlash 由于接受长度更高，仍然能带来更高的加速。

在 SGLang 中实现 DFlash

上一节中的基准测试数据来自 Z Lab 在研发过程中对 DFlash 的初步实现。基于这些令人瞩目的结果，Modal 和 SGLang 团队与 Z Lab 合作，在 SGLang 推理引擎中优化端到端性能。

将 DFlash 这样的性能优化技术从研究推向生产，需要两个基本组成部分：在高性能引擎中实现该技术，然后优化从主机调度器到 GPU 执行的端到端系统性能。

按照这一思路，DFlash 集成到 SGLang 的工作可以分为两部分。首先，DFlash 被加入到原有的（现已弃用）V1 投机解码引擎中。除了实现新的草稿模型架构外，这还需要跨草稿模型和目标模型的 KV cache 集成以支持注入。其次，DFlash 被加入到新的 V2 投机解码引擎中，该引擎通过减少与主机的同步来提供更优的性能。

在 DFlash 的初始实现中，我们为现有的投机解码引擎添加了对这一新模型架构的支持。这包括新增一个 DFlashWorker 来控制草稿模型的执行，以及它所驱动的实际 DFlashDraftModel。

提醒一下，SGLang 使用一个调度器进程（主要运行在主机上）来驱动模型工作进程（主要运行在加速器上）的执行。SGLang 中投机解码的工作方式有一个反直觉之处：是草稿模型工作进程与调度器通信（通过 .forward_batch_generation 之类的方法）。它包装了目标模型的工作进程以用于验证阶段，并在草稿准备就绪时调用它。如果你查看代码或 trace，请记住这一点！

这在 DFlash 中并非新事物。主要的新颖之处在于 KV 注入，它将草稿模型与目标模型之间的状态绑定起来。对于 EAGLE 之类的方法，草稿 KV cache 完全为草稿模型私有，基于草稿自身 latent 的 KV 投影计算得出。而在 DFlash 中，目标模型的 latent 则改为由草稿模型经过 KV 投影传递。

我们不想存储这些 latent 从而侵占宝贵的 KV cache 空间，并且我们希望所有具有相同前缀的请求都能共享基数树缓存。因此我们在草稿前向传播的其余部分之前先运行草稿 KV 投影——即时物化。这需要足够快，所以我们添加了一个按层批处理的线性投影，以及一个用于 norm+RoPE 后处理的融合 Triton kernel。

通过 Spec V2 和重叠调度消除 DFlash 的主机开销

这确实有效，而且速度很快，但我们知道它还能更快。我们当时正在并行开发 V2 投机解码引擎，所以下一步就是将 DFlash 与 V2 引擎结合，这就是如今在 SGLang 中可用的方案。

V2 引擎的整体关键目标是减少主机与设备之间的同步点，因为无论 GPU 有多快、kernel 有多好，这些同步点都会扼杀推理性能。解决方案被称为重叠调度器。

特别是，存在两个关键的重叠机会：

1. 主机侧的 pop_and_process 清理工作（在 GPU 完成第 N-1 批之后进行，例如停止 token 检测、请求元数据更新）可以与 GPU 在第 N 批上的工作重叠；
2. 主机端 KV 分配（位于 prepare_for_decode）针对批次 N 可以与批次 N-1 的 GPU 工作重叠进行。

在这些优化下的 V2 中，当在单张 B200 上以并发度 32 运行 Qwen 3-8B 时，性能提升了超过 33%，从约 11.4 ktok/s 提升至约 15.3 ktok/s（详情见此）。

高性能 DFlash 草稿模型现已可用于多种模型

今天，我们发布了面向 Qwen 3.5 397B-A17B 的新 DFlash 草稿模型。在我们测试的所有设置中——从 GSM8K 到 HumanEval 再到 MT-Bench，以及从 1 到 32 的请求并发度——它都实现了比该模型原生 MTP 推测更高的吞吐量。

关于基准测试的详细信息以及自行复现这些数字的方法，请参见

Hugging Face 仓库

你可以在 Z Lab 的 Hugging Face 上的 DFlash 合集 中找到更多高质量的草稿模型。敬请期待更多模型即将发布！

立即在 SGLang 中试用 DFlash

你不必只是读这篇博客而感到错失恐惧。你可以 阅读代码。你可以使用本文开头展示的命令部署一个 DFlash 加速的 SGLang 服务器——或者在 Modal 上启动一个。

你还可以针对自己的数据或目标模型训练一个 DFlash 推测模型。同样的块扩散加 KV 注入方法可以应用于大多数目标 LLM。如果你感兴趣，请联系 Z Lab 或 Modal！

更广泛地说：得益于开放权重模型构建者、系统研究人员和开源社区的工作，你可以以最优的智能、速度和成本运行推理。无论是 Z Lab 在 DFlash 等技术上的研究工作，还是像 Modal 这样的开源贡献者带来的功能和性能增强，全球最顶尖的 LLM 推理工作正在落地到 SGLang 开源引擎中，供你在此基础上进行构建和使用。

致谢

感谢所有为将 Spec V2 和 DFlash 引入 SGLang 做出贡献的人。

Z Lab：Jian Chen、Yesheng Liang 和 Zhijian Liu。

Modal：David Wang 和 Charles Frye。

SGLang：Qiaolin Yu、Liangsheng Yin 和 Khoa Pham。