DFlash：块扩散草稿模型实现最高15倍吞吐量提升

自回归大语言模型一次生成一个 token。每个 token 都要等待前一个 token。这种串行循环让现代 GPU 得不到充分利用，并使推理速度缓慢。对于长链式推理模型，代价更为严重。它们冗长的输出使延迟成为生成过程中的主导部分。

投机解码是标准的解决方案。一个小型草稿模型提出未来的 token。大型目标模型并行验证这些 token。被接受的 token 予以保留，因此输出保持无损。但大多数方法，包括最先进的 EAGLE-3，仍然以自回归方式起草。这种串行起草将实际加速限制在约 2–3×。

DFlash 由来自 UC San Diego 团队（z-lab）的研究团队提出，走了一条不同的路线。它是一个专为起草而构建的轻量级块扩散模型。它不是一次起草一个 token，而是在单次前向传播中提出一整个块。随后目标模型并行验证该块。

研究团队报告称，在一系列模型和任务上实现了超过 6× 的无损加速。其加速比 EAGLE-3 高出最多 2.5×。在 NVIDIA Blackwell 上，NVIDIA 工程团队报告 gpt-oss-120b 的吞吐量提升最高达 15×。该数字是在相同的用户交互性目标下取得的。

块扩散起草改变了什么

块扩散模型一次性对一整块被掩码的 token 进行去噪。它们将并行生成与自回归的块结构结合在一起。DFlash 仅将这一思路应用于草稿阶段。验证仍由可信的自回归目标模型完成。

这种分工对质量至关重要。独立的扩散 LLM 在准确率上往往落后于自回归模型。它们还需要大量去噪步骤，这拖慢了其原始推理速度。DFlash 同时规避了这两个问题。草稿只需足够好、能被接受即可。目标模型的并行验证保证了最终的输出分布。

第二个好处是草稿成本。自回归草稿模型的成本随投机 token 数量的增加而线性增长。而扩散草稿模型通过一次并行前向即可生成所有 token。因此，随着块的增长，草稿延迟基本保持平稳。这让 DFlash 能够使用更深、表达能力更强的草稿模型，而不增加延迟。

这使 DFlash 区别于早期的扩散草稿工作。DiffuSpec 和 SpecDiff-2 等方法使用了庞大的 7B 草稿模型，加速比被限制在 3–4× 左右。而 DFlash 改用一个小型五层草稿模型（Qwen3-Coder 为八层）。

“目标模型最懂”的洞见

DFlash 的核心思想很简单：目标模型最懂。大型自回归模型的隐藏特征编码了关于多个未来 token 的信息。DFlash 从目标模型的若干层中提取隐藏状态。它将它们融合为一个紧凑的目标上下文特征。该特征随后用于条件化草稿模型。

DFlash 注入这一特征的方式与 EAGLE-3 不同。EAGLE-3 仅将目标特征融合进草稿模型的输入嵌入向量中。随着草稿深度增加，该信号会被稀释。而 DFlash 则将特征注入到每一个草稿层的 Key 和 Value 投影中。投影后的特征驻留在草稿模型的 KV cache 中，并在多次草稿迭代中持续存在。

这种 KV 注入使得接受长度能够随草稿深度而扩展。一个五层 DFlash 草稿模型生成 16 个 token，胜过生成 8 个 token 的 EAGLE-3。在论文的测试中，它同时具有更低的延迟和更高的接受率。草稿模型实际上成为了目标模型之上的一个扩散适配器。

两个加速数字，测量方式不同

DFlash 研究中的 6× 是单流无损加速。在 Qwen3-8B 上使用贪心解码（Transformers 后端）时，DFlash 平均加速 4.86×。EAGLE-3 在树大小为 16 时平均加速 1.76×，在树大小为 60 时平均加速 2.02×。DFlash 在 MATH-500 上峰值达到 6.08×（τ = 7.87），跨任务平均 τ = 6.49。

NVIDIA 的 15× 是在固定交互性目标下的吞吐量。它适用于在 DGX B300 系统中八块 NVIDIA Blackwell GPU 上运行的 gpt-oss-120b，使用 TensorRT-LLM。在每用户 500–600 tokens/sec 的范围内，DFlash 的吞吐量超过自回归解码的 15×。这大约比同一水平下的 EAGLE-3 高出 1.5×。

下表展示了论文中在 Qwen3-8B 上温度为 0（Transformers 后端）时各任务的加速比。

另一项独立的 NVIDIA Speed-Bench 对比在相同并发量下测量了交互速度提升。在 gpt-oss-120b 上，DFlash 平均达到 2.3×，而 EAGLE-3 为 1.7×。在 Llama 3.1 8B Instruct 上，DFlash 平均达到 2.8×，而 EAGLE-3 为 2.2×。

用例与示例

DFlash 面向对延迟敏感的推理服务场景，在这些场景中逐 token 生成会拖慢速度。有三种模式非常契合：

• 编程智能体：代码生成需要快速、交互式的响应。在搭配 vLLM 的 Gemma 4 31B 上，NVIDIA 报告在并发量为 1 时 Math500 上最高达到 5.8×。HumanEval 达到 5.6×。更快的草稿意味着智能体循环内的等待时间更短。
• 推理模型：长链式思维（Chain-of-Thought）轨迹占据了生成时间的大部分。在启用思考模式的情况下，DFlash 在 Qwen3-4B 和 Qwen3-8B 上于贪心解码下保持约 4.5×。在采样下，保持约 3.9×。这降低了长推理输出的成本。
• 服务与吞吐量：DFlash 还能提升服务吞吐量。在配备 B200 GPU 的 SGLang 上，它在 Qwen3-8B（Math500，并发数为 1）上最高可达 5.1×。随着并发数上升，增益会逐渐减弱，但仍保持为正，因此服务成本依然会下降。

运行 DFlash

DFlash 随附检查点和框架支持，因此采用它几乎不需要写代码。在 vLLM 上，你只需把 EAGLE-3 配置换成 DFlash 配置即可。无需对应用进行重构。

vllm serve Qwen/Qwen3.5-27B \
  --speculative-config '{"method": "dflash", "model": "z-lab/Qwen3.5-27B-DFlash", "num_speculative_tokens": 15}' \
  --attention-backend flash_attn \
  --max-num-batched-tokens 32768

Transformers 后端支持 Qwen3 和 LLaMA-3.1 模型。它暴露了一个 spec_generate 调用，可将草稿模型与目标模型配对。

from transformers import AutoModel, AutoModelForCausalLM, AutoTokenizer

draft = AutoModel.from_pretrained(
    "z-lab/Qwen3-8B-DFlash-b16", trust_remote_code=True,
    dtype="auto", device_map="cuda:0").eval()
target = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen3-8B", dtype="auto", device_map="cuda:0").eval()
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3-8B")

messages = [{"role": "user", "content": "How many positive whole-number divisors does 196 have?"}]
input_ids = tokenizer.apply_chat_template(
    messages, return_tensors="pt", add_generation_prompt=True,
    enable_thinking=False).to(draft.device)

output = draft.spec_generate(
    input_ids=input_ids, max_new_tokens=2048, temperature=0.0,
    target=target, stop_token_ids=[tokenizer.eos_token_id])
print(tokenizer.decode(output[0], skip_special_tokens=False))

关键要点

• DFlash 在一次前向传播中草拟出整个 token 块，而不是一次只草拟一个 token。
• 它将目标隐藏特征注入每个草稿层的 KV cache，使接受长度随深度而扩展。
• 论文指标：在 Qwen3-8B 上最高可达 6.08× 无损加速；NVIDIA 测试：在 Blackwell 上于固定交互性下最高可达 15× 吞吐量。
• 一个轻量级的五层草稿器取代了 7B 草稿器，后者曾使早期扩散方法的上限停留在约 3–4×。

交互式讲解