DFlash + Spec V2 深度解析：扩散草稿 + KV 注入如何实现 4.3x LLM 推理加速

2026 年 6 月 15 日，Z Lab、Modal 和 SGLang 团队联合发布了 DFlash + Spec V2——推测解码（Speculative Decoding）的下一代方案。

如果说 EAGLE-3 在 2025 年用「直接 Token 预测」统一了推测解码的赛道，那么 DFlash 则在 2026 年用「块扩散 + KV 注入」打破了自回归草稿模型的天花板。

核心数据：

• Qwen 3.5 397B-A17B 上，DFlash 实现 4.3x 基线吞吐（HumanEval 数据集，并发 1）
• 对比原生 MTP（Multi-Token Prediction），DFlash 快 1.5x
• 对比 EAGLE-3（5 层），DFlash 在相同接受长度下快 1.5x

为什么 DFlash 能赢？

核心创新是两个：块扩散（Block Diffusion） 和 KV 注入（KV Injection）。

1. 块扩散：草稿模型不再逐 token 生成，而是一次性并行生成一整个 block（4/8/16 个 token）。这完美匹配 GPU 的并行计算能力。
2. KV 注入：将 target model 的隐藏状态直接注入草稿模型的 KV Cache，让草稿模型「站在巨人的肩膀上」预测下一个 block。

DFlash vs EAGLE-3 vs MTP 的本质区别：

本文目标：从零拆解 DFlash 的技术原理，并用 SGLang 完整部署，获得 4x+ 的推理加速。

DFlash 的论文（arXiv:2602.06036）提出了一个反直觉的洞察。 草稿模型不需要自己理解上下文，target model 已经理解得够好了。

2.1 传统方案的瓶颈

EAGLE-3 的做法是：从 target model 最后一层提取隐藏状态，输入到一个轻量 MLP 草稿模型中，逐 token 预测。问题是：

1. 草稿模型需要自己建模上下文——即使只有 5 层，它也需要理解「当前对话在说什么」
2. 逐 token 生成是串行的——生成 8 个 token 需要 8 次前向传播
3. 草稿模型越深，延迟越高——但浅了又影响接受率

2.2 DFlash 的解法：KV 注入

DFlash 的核心创新是把 target model 的隐藏状态直接注入到草稿模型每一层的 KV Cache 中。

具体来说：

1. Target model 正常执行前向传播，产生每一层的 K、V 张量
2. 这些 K、V 张量通过一个轻量线性投影（KV Projection），转换为草稿模型可用的格式
3. 注入到草稿模型对应层的 KV Cache 中
4. 草稿模型只需要「关注」这些已有的 KV，专注于预测下一个 block

这意味着草稿模型不需要自己建模上下文——它直接复用 target model 的理解。

2.3 块扩散：并行生成 block

草稿模型使用块扩散（Block Diffusion） 而非自回归来生成 token：

1. 初始化一个全为 [MASK] 的 block（长度 4/8/16）
2. 单次前向传播，预测所有位置的 token 概率
3. 迭代去噪（通常 2-3 轮），逐步确定每个位置的 token
4. 输出完整的 block

关键优势：无论 block 大小，扩散过程只需要 2-3 次前向传播。 生成 16 个 token 和生成 4 个 token 的延迟几乎相同。

2.4 性能对比

在 Qwen 3-4B 上，5 层 DFlash vs 5 层 EAGLE-3 的详细对比：

接受长度相近，但加速比大幅提升——这就是块扩散并行化的威力。

DFlash 的草稿模型已经够快了，但 SGLang 团队发现：Host 端的调度开销才是更大的瓶颈。

3.1 Host 开销问题

在推测解码中，调度器（Scheduler）运行在 Host（CPU）上，模型执行在 GPU 上。每个 batch 完成后，Host 需要：

1. 检测 stop token（判断生成是否结束）
2. 更新请求元数据
3. 分配下一个 batch 的 KV Cache
4. 发送执行指令给 GPU

这些操作看似很快，但在高并发（32+ 请求）下，Host 的串行处理成为瓶颈。GPU 在等待 Host 指令时处于空闲状态。

3.2 Spec V2 的 Overlap 调度

Spec V2 引擎的核心思想是让 Host 工作和 GPU 工作重叠执行：

1. Batch N-1 清理 ∥ Batch N 执行：GPU 开始执行 Batch N 时，Host 同时清理 Batch N-1 的结果（stop token 检测、元数据更新）
2. Batch N KV 分配 ∥ Batch N-1 执行：GPU 执行 Batch N-1 时，Host 同时为 Batch N 分配 KV Cache

效果：Host 开销被完全隐藏，GPU 利用率从 ~70% 提升到 ~95%。

在 Qwen 3-8B 单 B200、并发 32 的测试中，Spec V2 将吞吐从 11.4 ktok/s 提升到 15.3 ktok/s，提升 33%。

3.3 DFlash + Spec V2 的叠加效果

DFlash 和 Spec V2 解决的是不同层面的问题：

• DFlash：加速草稿模型本身（GPU 层面）
• Spec V2：消除调度开销（Host-GPU 交互层面）

两者叠加后，在 Qwen 3.5 397B-A17B 上实现了 4.3x 基线吞吐和 1.5x MTP 吞吐。

# SGLang Spec V2 + DFlash 部署命令（Qwen 3.5 397B-A17B）
# 硬件：8xB200 GPU

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 草稿模型，但如果你需要在自己的模型或数据集上训练，以下是完整流程。

4.1 训练数据准备

DFlash 草稿模型的训练数据来自 target model 的执行轨迹：

1. 用 target model 处理一批提示（prompts）
2. 记录 target model 每一层的隐藏状态和最终输出的 token
3. 将 (隐藏状态, token block) 对作为训练样本

关键：训练数据的分布必须与推理时的分布一致。 如果 target model 主要用于代码生成，训练数据也应该以代码为主。

4.2 训练配置

DFlash 草稿模型非常轻量——只有 5 层，参数量约为 target model 的 1-2%。

训练超参数建议：

• 学习率：1e-4（AdamW）
• Batch size：256
• Block size：8（与推理时一致）
• 扩散步数：2（训练和推理保持一致）
• 训练轮数：3-5（过多会过拟合）

4.3 评估指标

训练完成后，需要评估：

1. 接受长度（Acceptance Length）：草稿 block 中被 target 接受的平均 token 数
2. 端到端加速比（Speedup）：对比无推测解码的基线
3. 不同并发下的表现：并发 1/8/32 的加速比可能差异很大

经验法则：接受长度 > 3.0 就算合格，> 4.0 算优秀。

# DFlash 草稿模型训练伪代码
import torch
from torch.optim import AdamW
from dflash import DFlashDraftModel, BlockDiffusionTrainer

# 1. 加载 target model（冻结参数）
target_model = load_target_model("Qwen/Qwen3-4B")
target_model.eval()
for param in target_model.parameters():
    param.requires_grad = False

# 2. 初始化草稿模型（5 层，轻量配置）
draft_model = DFlashDraftModel(
    hidden_size=target_model.config.hidden_size,
    num_layers=5,
    block_size=8,           # 每次生成 8 个 token
    diffusion_steps=2,      # 2 轮去噪
    kv_projection_dim=target_model.config.hidden_size,
)

# 3. 准备训练数据
training_data = collect_target_trajectories(
    model=target_model,
    prompts=load_prompts("data/code_prompts.jsonl"),
    max_samples=10000,
)

# 4. 训练
trainer = BlockDiffusionTrainer(
    draft_model=draft_model,
    target_model=target_model,
    optimizer=AdamW(draft_model.parameters(), lr=1e-4),
    block_size=8,
    diffusion_steps=2,
)

trainer.train(
    dataset=training_data,
    batch_size=256,
    num_epochs=5,
    eval_every=500,
)

# 5. 评估
metrics = trainer.evaluate(
    eval_dataset=load_prompts("data/eval_prompts.jsonl"),
)
print(f"Acceptance Length: {metrics['acceptance_length']:.2f}")
print(f"Speedup: {metrics['speedup']:.2f}x")

DFlash 不是要替代 EAGLE-3 或 MTP，而是在特定场景下提供更优选择。

5.1 详细对比

5.2 选型决策

选 DFlash 的场景：

• ✅ 追求极致加速比（4x+）
• ✅ 使用 SGLang 引擎
• ✅ 有 GPU 资源训练草稿模型（或官方已提供）
• ✅ 并发场景（高吞吐需求）

选 EAGLE-3 的场景：

• ✅ 使用 vLLM 引擎且不想迁移
• ✅ 需要最广泛的模型支持
• ✅ 不想训练草稿模型（用通用草稿）
• ✅ 显存受限（DFlash 略高）

选 MTP 的场景：

• ✅ 使用 Gemma 4 或 DeepSeek-V4
• ✅ 不想额外训练/加载草稿模型
• ✅ 需要最简单的部署（零额外组件）

5.3 混合策略

在实际生产中，可以根据场景动态选择：

• 代码生成（高接受率）→ DFlash（block=16）
• 对话生成（中等接受率）→ EAGLE-3（block=4）
• 通用任务（低延迟需求）→ MTP（零额外开销）

SGLang 支持在同一服务中配置多种推测策略，按请求类型路由。

Z Lab、Modal 和 LMSYS 联合发布了多个模型的 DFlash 草稿模型，可以直接下载使用。

6.1 已发布的草稿模型

所有模型都在 HuggingFace 上公开，可以免费下载使用。

6.2 部署硬件建议

6.3 性能调优参数

启动命令中的关键参数：

• --speculative-dflash-block-size：block 大小（4/8/16）。越大接受长度越高，但草稿延迟也越高。建议从 8 开始调。
• --speculative-draft-attention-backend：草稿模型的注意力后端。fa4（FlashAttention 4）最快，但需要 Ampere+ GPU。
• --max-running-requests：最大并发请求数。影响 Spec V2 的 overlap 效果。建议设为 GPU SM 数量。
• --mem-fraction-static：静态 KV Cache 占比。0.8 是安全值，可以试 0.85。

# 使用 OpenAI 兼容 API 测试 DFlash 加速效果
import openai
import time

client = openai.OpenAI(
    base_url="http://localhost:30000/v1",
    api_key="dummy"
)

# 测试 HumanEval 中的一个代码生成任务
prompt = """
Write a Python function that finds all prime numbers up to n using the Sieve of Eratosthenes.
"""

start = time.time()
response = client.chat.completions.create(
    model="Qwen/Qwen3-4B",
    messages=[{"role": "user", "content": prompt}],
    max_tokens=512,
    temperature=0,
)
elapsed = time.time() - start

print(f"Generated {response.usage.completion_tokens} tokens in {elapsed:.2f}s")
print(f"Throughput: {response.usage.completion_tokens / elapsed:.1f} tok/s")
# 预期输出: Throughput: ~120 tok/s (DFlash) vs ~35 tok/s (baseline)

DFlash 代表了推测解码 2.0 时代，但终点远未到达。

7.1 推测解码的三代演进

7.2 下一步：完全并行生成

DFlash 仍然需要 target model 验证草稿，这意味着它没有完全摆脱自回归的束缚。真正的终极方案是完全并行生成（Fully Parallel Generation）——target model 一次性输出所有 token，无需验证。

这可能需要的架构突破：

1. 非自回归 LLM：如 Diffusion Transformer（DiT）用于语言
2. 一致性解码：确保并行生成的 token 之间语义一致
3. 硬件协同：GPU 架构需要适配大规模并行输出

7.3 短期趋势（2026 H2）

在完全并行生成到来之前，2026 下半年的趋势是：

1. DFlash 生态扩展：更多模型的草稿模型被训练和发布
2. Spec V2 成为标配：所有推测解码方案都将受益于 overlap 调度
3. 自适应 block size：根据输入复杂度动态调整 block 大小
4. 多草稿模型路由：不同场景使用不同的草稿模型

DFlash + Spec V2 是当前（2026 年 6 月）推测解码的最优解，但不是终局。

DFlash + Spec V2 是 2026 年推测解码领域的最大突破。 它将 LLM 推理加速从 2x 时代推入 4x 时代，为实时 AI 应用铺平了道路。

核心要点回顾

1. DFlash 的两个创新：块扩散（并行生成 block）+ KV 注入（复用 target 特征）
2. Spec V2 的贡献：overlap 调度消除 Host 开销，GPU 利用率从 70% → 95%
3. 实际效果：Qwen 3.5 397B 上 4.3x 基线吞吐，1.5x MTP 吞吐
4. 部署门槛：需要 SGLang 引擎 + 兼容 GPU + 草稿模型（已开源）

实践建议

1. 立即可做：如果你在用 SGLang，升级到 Spec V2 引擎，获得 20-30% 免费加速
2. 短期尝试：下载官方 DFlash 草稿模型，在你的场景测试加速效果
3. 中期规划：如果 DFlash 效果不理想，考虑在自己的数据上训练草稿模型
4. 长期关注：跟踪完全并行生成的研究进展，为下一代架构做准备

推测解码的故事还远未结束。DFlash 是当前的最优解，但每一周都有新的突破在发生。