下一代投机解码：DFlash 与 Spec V2
阅读原文· lmsys.orgDFlash 用并行起草和 KV 注入实现了实测 4.3 倍吞吐，再加上 SGLang Spec V2 引擎优化，推理加速不再是纸上谈兵。做 LLM 部署和推理服务的人，可以直接用这个组合试试。
Z Lab、Modal 与 SGLang 团队联合发布 DFlash 投机解码模型和 SGLang 的默认 Spec V2 引擎。DFlash 采用块扩散+KV 注入并行生成整块 draft token，在 Qwen 3.5 397B-A17B（BF16）的 HumanEval 数据集上、并发 1 时吞吐量达到基线的 4.3
使用 Modal 和 Z Lab 的 DFlash 推测解码模型，配合 SGLang 新默认的 Spec V2 引擎，你可以实现大语言模型推理服务的最优延迟。我们联合发布的全新 Qwen 3.5 397B-A17B DFlash 模型，在我们测试的所有设置下，其吞吐量均高于基线模型和原生 MTP 推测。在 HumanEval 编码数据集上，并发数为 1 时，该模型的吞吐量达到基线的 4.3 倍以上，是 MTP 的 1.5 倍。
工作负载：Qwen 3.5 397B-A17B (BF16)，HumanEval。设置：贪婪解码，启用思考，最大新 token 数 4096。硬件：Modal 上的 8 块 B200。接受长度按请求取平均值。草稿 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 架构的大语言模型功能强大，但其自回归解码过程导致推理速度缓慢：token 必须逐个生成，算术强度低，不适合现代硬件。
推测解码通过使用更小、更快的草稿模型来提出多个 token，然后由目标大语言模型并行验证，从而解决了这一瓶颈，且不影响模型质量。
然而，许多推测解码方法，例如 EAGLE 系列以及 Gemma 4 和 DeepSeek-V4 等近期模型中的原生多 token 预测模块，仍然依赖于顺序自回归——只不过是在草稿模型而非目标模型中进行。草稿模型逐个生成草稿 token，这同样不适合现代硬件，并且限制了可实现的加速效果。
这正是 Z Lab 开发 DFlash 的原因。它采用轻量级块状扩散草稿模型，以 GPU 和 TPU 青睐的方式并行生成整个草稿 token 块。小米全新的 MiMo v2.5-Pro-UltraSpeed 利用 DFlash 实现了超过 1000 输出 tps。
使用块状扩散进行推测性草稿生成并非易事。直接训练一个小的块状扩散模型作为草稿模型会导致接受长度较低，而使用像 SpecDiff-2 这样现有的大型扩散大语言模型作为草稿模型则会引入巨大的内存占用和高昂的草稿生成成本。
DFlash 的核心洞察很简单：目标大语言模型最了解上下文。受 Medusa、EAGLE 和 MTP 等先前方法的启发（Gloeckle 等人，2024；Samragh 等人，2025），我们从目标模型中提取上下文 token 的隐藏表示。与先前工作不同，我们将其直接注入草稿模型的 KV 缓存中。这种方法随着草稿深度的增加而扩展性更好。KV 注入还允许草稿模型跳过从头开始建模完整上下文，专注于纯粹预测下一个 token 块——使用与目标模型后几层相同的张量！
通过这种设计，DFlash 在保持草稿模型极其小巧高效的同时，充分利用了目标大语言模型产生的丰富且高度相关的上下文特征。因此，DFlash 以较低的草稿生成延迟实现了较高的接受长度。
为什么 DFlash 如此之快？
推测性解码的加速主要取决于两个因素：每个周期有多少个草稿 token 被接受，以及草稿模型增加了多少额外成本。DFlash 在这两方面都有改进：扩散草稿降低了草稿成本，KV 注入提高了接受率。
具体来说，让我们比较一下针对 Qwen 3-4B 在相同数据集上训练的 5 层 EAGLE-3 草稿模型与几个 5 层 DFlash 变体草稿模型的端到端接受长度和速度。基线 DFlash 实现了与 5 层 EAGLE-3 草稿模型相似的接受长度，但凭借其超快速的并行草稿生成，它提供了更高的端到端加速。结果以 acc_len / speedup 形式报告。
| 任务 | EAGLE-3（5 层） | DFlash |
|---|---|---|
| GSM8K | 4.2 / 2.1x | 4.2 / 3.3x |
| HumanEval | 4.3 / 2.2x | 4.0 / 3.2x |
| MT-Bench | 3.1 / 1.4x | 3.0 / 2.2x |
DFlash 草稿生成速度更快
自回归式草稿模型（如 EAGLE-3）逐个生成草稿 token。随着草稿长度增加，草稿生成成本大致呈线性增长。为了保持低延迟，这些方法通常依赖非常浅层的草稿模型，这限制了草稿质量。
DFlash 通过块扩散草稿模型避免了这一瓶颈。它只需一次前向传播就能并行生成整个 token 块，使草稿生成过程对硬件更加友好。一个 5 层 DFlash 草稿模型生成 4、8 甚至 16 个 token 的草稿延迟，远低于单层 EAGLE-3 草稿模型生成 4 个 token 的延迟。
我们可以通过消融 DFlash 的其他架构特性来观察这项技术的独立影响。即使接受长度较低，得益于更快的草稿生成速度，DFlash 仍能提供比 EAGLE-3 更高的端到端加速比。
| 任务 | EAGLE-3（5 层） | DFlash（仅扩散） |
|---|---|---|
| GSM8K | 4.2 / 2.1x | 3.5 / 2.9x |
| HumanEval | 4.3 / 2.2x | 3.5 / 2.9x |
| MT-Bench | 3.1 / 1.4x | 2.6 / 2.0x |
KV 注入提高了接受长度
快速草稿生成只有在草稿 token 被接受时才有帮助。EAGLE-3 仅在草稿模型的输入层使用目标模型的特征，这一信号在更深的草稿模型中会逐渐减弱。
相比之下，DFlash 将目标特征注入到每一层草稿模型的 KV 缓存中。这使得草稿模型在整个生成过程中始终受到目标模型上下文的强条件约束，从而让更深的草稿模型能够生成更高质量的草稿。
我们还可以通过消融扩散草稿生成来观察 KV 注入的独立影响。在端到端基准测试中，即使采用自回归模式，DFlash 由于更高的接受长度，仍能产生更高的加速比。
| 任务 | EAGLE-3（5 层） | DFlash（仅注入） |
|---|---|---|
| GSM8K | 4.2 / 2.1x | 4.8 / 2.4x |
| HumanEval | 4.3 / 2.2x | 4.6 / 2.3x |
| MT-Bench | 3.1 / 1.4x | 3.4 / 1.5x |
在 SGLang 中实现 DFlash
上述章节中的基准测试数据来自 Z Lab 作为研发项目对 DFlash 的初始实现。基于这些令人印象深刻的结果，Modal 和 SGLang 团队与 Z Lab 合作，在 SGLang 推理引擎中优化了端到端性能。
将 DFlash 这类性能优化技术从研究阶段推向生产环境，需要两个基本要素：首先在高性能引擎中实现该技术，然后优化从主机调度器到 GPU 执行这一端到端系统的整体性能。
按照这一思路，DFlash 与 SGLang 的集成可分为两部分。首先，DFlash 被添加到原有的（现已弃用的）V1 推测解码引擎中。除了实现新的草稿模型架构外，还需要集成草稿模型与目标模型之间的 KV 缓存以支持注入。其次，DFlash 被添加到新的 V2 推测解码引擎中，该引擎通过减少与主机的同步操作实现了更优的性能。
在 DFlash 的初始实现中，我们为现有的推测解码引擎添加了对这种新模型架构的支持。这包括新增一个 DFlashWorker 来控制草稿模型的执行，以及由其驱动的实际 DFlashDraftModel。
需要提醒的是，SGLang 使用调度器进程（主要在主机上）来驱动模型工作进程（主要在加速器上）的执行。SGLang 中推测解码运作方式有一个反直觉之处：草稿模型工作进程负责与调度器通信（通过 .forward_batch_generation 等方法）。它封装了目标模型的工作进程用于验证阶段，并在草稿准备就绪时调用该进程。如果你查看代码或追踪信息，请牢记这一点！
这在 DFlash 中并非新特性。其主要创新在于 KV 注入，它将草稿模型与目标模型之间的状态关联起来。对于 EAGLE 这类方法，草稿 KV 缓存完全属于草稿模型私有，基于草稿自身潜在表示的 KV 投影计算得出。而在 DFlash 中，目标模型的潜在表示会由草稿模型通过 KV 投影进行处理。
我们不想存储那些潜在表示，以免挤占宝贵的 KV 缓存空间，并且我们希望所有具有相同前缀的请求都能共享基数缓存。因此，我们在草稿模型前向传播的其余部分之前，先运行草稿 KV 投影——即即时物化。这需要很快的速度，所以我们添加了一个按层批处理的线性投影，以及一个用于归一化加 RoPE 后处理的融合 Triton 内核。
通过 Spec V2 和重叠调度消除 DFlash 的主机开销
这个方法有效且速度快，但我们知道还能更快。我们当时正在同步开发 V2 版推测解码引擎，因此下一步就是将 DFlash 与 V2 引擎结合起来，也就是现在 SGLang 中可用的功能。
V2 引擎的整体关键目标是减少主机与设备之间的同步点，这些同步点会严重损害推理性能，无论 GPU 有多快或内核有多好。解决方案被称为重叠调度器。
具体来说，有两个关键的重叠机会：
- 在 GPU 完成批次 N-1 之后，主机端的 pop_and_process 清理工作（例如，停止 token 检测、请求元数据更新）可以与批次 N 的 GPU 工作重叠；
- 批次 N 的主机端 KV 分配（在 prepare_for_decode 中）可以与批次 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 注入方法可以应用于大多数目标大语言模型。如果你感兴趣，请联系 Z Lab 或 Modal！
更广泛地说：得益于开放权重模型构建者、系统研究人员以及开源社区的努力，你可以在最优的智能水平、速度和成本下运行推理。无论是 Z Lab 在 DFlash 等技术上的研究工作，还是像 Modal 这样的开源贡献者带来的功能和性能提升，全球最优秀的大语言模型推理工作正在落地到 SGLang 开源引擎中，供你在此基础上进行构建和协作。
致谢
感谢所有为将 Spec V2 和 DFlash 引入 SGLang 做出贡献的人。
Z Lab：陈健、梁业盛和刘志坚。
Modal：David Wang 和 Charles Frye。
SGLang：余巧林、尹良升和 Khoa Pham。