DFlash与Spec V2解码（14分钟阅读）

# 下一代推测解码：DFlash 和 Spec V2 - LMSYS 博客 来源：https://www.lmsys.org/blog/2026-06-15-next-generation-speculative-decoding-dflash-v2/ 通过将 Modal 和 Z Lab 的 DFlash 推测解码模型与 SGLang 新默认的 Spec V2 引擎结合使用，您可以在 LLM 推理服务中实现最先进的延迟。我们新联合发布的 Qwen 3.5 397B-A17B 的 DFlash 模型，在我们基准测试的所有设置中，其吞吐量均高于基线模型和原生 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` (https://huggingface.co/z-lab/Qwen3.5-397B-A17B-DFlash) - `modal-labs/Qwen3.5-397B-A17B-DFlash` (https://huggingface.co/modal-labs/Qwen3.5-397B-A17B-DFlash) - `lmsys/Qwen3.5-397B-A17B-DFlash` (https://huggingface.co/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 (https://z-lab.ai/)、SGLang 和 Modal (https://modal.com/) 团队如何协作，使这些加速效果惠及所有人。 ## DFlash：通过 KV 注入进行并行草稿生成 基于 Transformer 的大型语言模型 (LLM) 功能强大，但其自回归解码过程使得推理缓慢：token 必须逐一生成，算术强度 (https://modal.com/gpu-glossary/perf/arithmetic-intensity) 很低，难以适应现代硬件。 推测解码 (https://arxiv.org/abs/2211.17192) 通过使用一个更小、更快的草稿模型来提出多个 token，然后由目标 LLM 并行验证，从而解决了这一瓶颈，且不影响模型质量。 然而，许多推测解码方法，如 EAGLE 系列 (https://arxiv.org/abs/2503.01840) 以及近期模型（如 Gemma 4 (https://blog.google/innovation-and-ai/technology/developers-tools/multi-token-prediction-gemma-4/) 和 DeepSeek-V4 (https://www.lmsys.org/blog/2026-04-25-deepseek-v4/)）中的原生多 token 预测 (MTP) 模块，仍然依赖顺序自回归——只不过是在草稿模型而非目标模型中。草稿模型逐个生成草稿 token，这并不适合现代硬件，并且限制了可实现的加速效果。 因此，Z Lab 开发了 DFlash (https://arxiv.org/abs/2602.06036)，它使用轻量级块扩散草稿模型并行生成整个草稿 token 块，这种方式正是 GPU 和 TPU 所擅长的。小米的新款 MiMo v2.5-Pro-UltraSpeed 使用 DFlash 实现了超过 1k 输出 tps (https://mimo.xiaomi.com/blog/mimo-tilert-1000tps)。 将块扩散用于推测草稿并非易事。直接训练一个小型块扩散模型作为草稿器会导致接受长度较低，而使用现有的大型扩散 LLM（如 SpecDiff-2 (https://arxiv.org/abs/2511.00606)）作为草稿器则引入大量内存占用和高昂的草稿生成成本。 DFlash 的关键洞察很简单：目标 LLM 最了解上下文。受早期方法如 Medusa (https://arxiv.org/abs/2401.10774)、EAGLE (https://arxiv.org/html/2503.01840v1) 和 MTP（Gloeckle et al., 2024 (https://arxiv.org/abs/2404.19737); Samragh et al., 2025 (https://arxiv.org/abs/2507.11851)）的启发，我们从目标模型中提取上下文 token 的隐层表示。与之前的工作不同，我们将其直接注入到草稿模型的 KV 缓存中。这使得扩展性在增加草稿深度时更好。KV 注入还允许草稿模型跳过从头建模完整上下文，而专注于预测下一个 token 块——使用与目标模型后续层相同的张量！ 通过这种设计，DFlash 在保持草稿模型极其小巧高效的同时，充分利用了目标 LLM 产生的丰富且高度相关的上下文特征。因此，DFlash 实现了高接受长度和低草稿延迟。 ### 为什么 DFlash 如此之快？ 推测解码加速主要取决于两个因素：每个周期接受多少草稿 token，以及草稿模型增加的额外成本。DFlash 在这两方面都有改进：扩散草稿降低了草稿成本，KV 注入提高了接受率。 具体来说，让我们比较一个 5 层 EAGLE-3 草稿器与多个为 Qwen 3-4B 在相同数据集上训练的 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 的草稿延迟远低于生成 4 个 token 的单层 EAGLE-3 草稿器。 通过消融 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 被添加到了原始的（现已弃用 (https://github.com/sgl-project/sglang/pull/25464)）V1 推测解码引擎中。除了实现新的草稿模型架构，这还需要在草稿模型和目标模型之间集成 KV 缓存以支持注入。其次，DFlash 被添加到了新的 V2 推测解码引擎中，该引擎通过减少与主机 (https://modal.com/blog/host-overhead-inference-efficiency) 的同步来提供更优的性能。 在 DFlash (https://github.com/sgl-project/sglang/pull/22077) 的初始实现中，我们将这种新模型架构支持添加到了现有的推测解码引擎。这包括添加一个 `DFlashWorker` 来控制草稿模型的执行，以及它驱动的实际 `DFlashDraftModel`。 提醒一下，SGLang 使用一个调度器进程（主要在主机上）来驱动模型工作进程（主要在加速器上）的执行。SGLang 中推测解码工作的一个反直觉方面是，草稿模型工作进程负责与调度器通信（通过诸如 `.forward_batch_generation` 之类的方法）。它包装了一个目标模型的工作进程用于验证阶段，并在草稿准备好时调用它。如果您查看代码或跟踪信息，请记住这一点。 这对 DFlash 来说并不新鲜。主要的新颖之处在于 KV 注入，它将草稿模型和目标模型之间的状态联系起来。对于 EAGLE 等方法，草稿 KV 缓存完全属于草稿模型私有，基于草稿自身隐层的 KV 投影计算得出。而在 DFlash 中，目标模型的隐层则通过草稿模型的 KV 投影传递。 我们不想存储这些隐层从而占用宝贵的 KV 缓存空间，同时希望所有具有相同前缀的请求能够共享基数缓存。因此，我们在草稿前向传播的其余部分之前运行草稿 KV 投影——即“即时物化”。这需要快速执行，因此我们添加了一个层批处理线性投影，以及一个用于 norm+RoPE 后处理的融合 Triton 内核。 ## 通过 Spec V2 和重叠调度消除 DFlash 的主机开销 上述方法有效且快速，但我们知道可以更快。我们当时正在并行开发 V2 推测解码引擎，因此下一步是将 DFlash 与 V2 引擎 (https://github.com/sgl-project/sglang/pull/23000) 结合，这现在已在 SGLang 中可用。 V2 引擎的整体关键目标是减少主机-设备同步点，这些同步点会严重损害推理性能 (https://modal.com/blog/host-overhead-inference-efficiency)，无论 GPU 有多快或内核有多好。解决方案称为“重叠调度器”。 具体来说，有两个关键的重叠机会： 1. 主机端 `pop_and_process` 清理（例如，停止 token 检测、请求元数据更新）在 GPU 完成批次 N-1 后，可以与 GPU 在批次 N 上的工作重叠； 2. 批次 N 的主机 KV 分配（在 `prepare_for_decode` 中）可以与 GPU 在批次 N-1 上的工作重叠。 在采用这些优化的 V2 引擎下，当在单个 B200 上运行 Qwen 3-8B 且并发数为 32 时，性能提升了超过 33%，从约 11.4 ktok/s 提升至约 15.3 ktok/s（详情 (https://github.com/sgl-project/sglang/pull/23000)）。 ## 高性能 DFlash 草稿模型现已支持多种模型 今天，我们为 Qwen 3.5 397B-A17B 发布了一款新的 DFlash 草稿模型。在我们测试的所有设置中（从 GSM8K 到 HumanEval 再到 MT-Bench，请求并发数从 1 到 32），其吞吐量均高于该模型的原生 MTP 推测。 有关基准测试的详细信息以及自行复现结果，请参阅 Hugging Face 仓库 (https://huggingface.co/modal-labs/Qwen3.5-397B-A17B-DFlash/tree/main/benchmark)。 您可以在 Z Lab 在 Hugging Face 上的 DFlash 合集 (https://huggingface.co/collections/z-lab/dflash) 中找到更多高质量的草稿器。敬请期待更多模型即将发布！ ## 立即在 SGLang 中尝试 DFlash 您不必仅仅阅读这篇博客而感觉错失良机。您可以阅读代码 (https://github.com/sgl-project/sglang/pull/23000)。您可以使用本文开头显示的命令部署一个由 DFlash 加速的 SGLang 服务器——或者在 Modal (https://modal.com/docs/examples/sglang_low_latency) 上快速启动一个。 您还可以为您的自有数据或目标模型训练一个 DFlash 推测器模型。相同的块扩散加 KV 注入方法可以应用于大多数目标 LLM。如果您感兴趣，请联系 Z Lab (https://z-lab.ai/) 或 Modal (https://modal.com/)。 更广泛地说：由于开放权重模型构建者、系统研究人员和开源社区的工作，您可以以最优的智能水平、速度和成本运行推理。无论是 Z Lab (https://z-lab.ai/) 在 DFlash 等技术上的研究工作，还是像 Modal (https://modal.com/) 这样的开源贡献者提供的功能和性能增强，世界上最好的 LLM 推理工作都正在汇入 SGLang 开源引擎，供您在此基础上构建和使用。 ## 致谢 感谢所有为将 Spec V2 和 DFlash 带到 SGLang 做出贡献的人。 Z Lab：Jian Chen, Yesheng Liang, and Zhijian Liu。 Modal：David Wang and Charles Frye。 SGLang：Qiaolin Yu, Liangsheng Yin, and Khoa Pham。