在大模型推理服务中，延迟直接影响用户体验与吞吐量。Speculative decoding 通过引入一个轻量级的 draft 模型先猜测多个 token，再由 target 模型验证，是目前降低端到端延迟的经典手段。然而，传统方案中的 draft 模型仍然是自回归的 —— 它必须逐个 token 生成，这种顺序依赖在 GPU 并行计算资源充足的今天反而成为了新的瓶颈。DFlash（Block Diffusion for Flash Speculative Decoding）正是为解决这一问题而生：它用 diffusion 技术一次性生成一整块 token，将并行度从「单 token」提升到「多 token 块」，在不损失输出质量的前提下实现显著加速。
传统 Speculative Decoding 的局限
理解 DFlash 的改进之前，有必要回顾自回归 draft 的核心痛点。假设我们配置了 16 个 speculative token，传统的做法是让 draft 模型执行 16 次前向传播，每次基于已生成的 token 预测下一个。这种串行结构意味着即使 GPU 能够同时处理上千个 token，draft 阶段也只能逐个等待，无法充分利用并行计算能力。更重要的是，draft 模型的每次前向传播都要完整运行注意力机制，计算复杂度随序列长度二次增长，当 batch size 增大时显存压力急剧上升。
另一个关键问题是 draft 与 target 模型之间的分布漂移。Draft 模型参数量远小于 target（如 4B vs 27B），其预测分布与 target 存在偏差。验证阶段若大量 token 被拒绝，不仅浪费了 draft 的计算，还需回退到 target 模型重新生成，整体收益被削弱。业界尝试过 tree-based speculation 等方案来增加候选多样性，但根本问题在于 draft 阶段的串行本质仍未打破。
Block Diffusion 的并行 drafting 原理
DFlash 的核心创新在于将 draft 阶段从自回归改为块级别的 diffusion 过程。具体而言，DFlash 不再逐个预测 token，而是以某个固定长度的块（通常为 16 个 token）为单位，一次性生成整块的 token 分布。这种做法的理论基础来源于 diffusion 模型在连续空间的美妙特性：它能够在单次前向传播中输出多个位置的预测结果，而不受自回归链的顺序约束。
实现上，DFlash 通过注入 target 模型的 KV（Key-Value）特征来实现条件生成。Draft 模型在训练阶段学习了如何根据已知的上下文和 target 模型的隐藏状态，预测出与 target 分布高度接近的 token 块。这种条件机制确保了即使 draft 模型参数规模较小，其输出仍能与 target 保持较好的一致性，从而提高验证阶段的接受率。官方开源的 DFlash 模型已经针对多个主流 target 模型进行了微调，包括 Qwen3.5-27B、Gemma-4-26B 等。
落地到生产环境：各后端配置参数
DFlash 目前支持 vLLM、SGLang、Transformers 和 MLX 四个主流推理后端。以下是生产环境中经过验证的关键配置参数。
vLLM 后端
vLLM 从 v0.20.1 版本开始支持 DFlash 核心功能。非 Gemma 系列模型的标准启动命令如下：
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
其中 num_speculative_tokens 控制每次 speculative 循环中 draft 的 token 数量，默认值 15 是经过实验验证的平衡点 —— 过大则增加验证开销，过小则无法充分发挥并行优势。--max-num-batched-tokens 32768 确保了较大的 batch 处理能力，避免因显存不足导致 batch 被截断。
Gemma4 系列模型需要使用官方提供的 Docker 镜像或自定义构建，这是由于 Gemma4 的注意力实现与标准版本存在差异。
SGLang 后端
SGLang 提供了更灵活的调度策略。推荐配置如下：
python -m sglang.launch_server \
--model-path Qwen/Qwen3.5-35B-A3B \
--speculative-algorithm DFLASH \
--speculative-draft-model-path z-lab/Qwen3.5-35B-A3B-DFlash \
--speculative-num-draft-tokens 16 \
--tp-size 1 \
--attention-backend trtllm_mha \
--speculative-draft-attention-backend fa4 \
--mem-fraction-static 0.75 \
--mamba-scheduler-strategy extra_buffer \
--trust-remote-code
--speculative-num-draft-tokens 16 与 vLLM 的 num_speculative_tokens 含义一致，SGLang 默认为 16。--mem-fraction-static 0.75 分配了 75% 的显存给模型权重和 KV cache，对于 dual-model 场景（draft + target 同时驻留显存）尤为重要。--speculative-draft-attention-backend fa4 指定 draft 模型使用 Flash Attention 4 优化版本，能显著降低显存占用。
SGLang 还提供了实验性的调度重叠特性，通过设置环境变量 SGLANG_ENABLE_SPEC_V2=1 和 SGLANG_ENABLE_DFLASH_SPEC_V2=1 可开启，但该功能在某些场景下可能不稳定，建议在预发布环境中充分测试。
Transformers 后端
对于本地开发或小规模部署，Transformers 后端提供了最直接的集成方式。目前仅支持 Qwen3 和 LLaMA-3.1 系列模型：
from transformers import 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": "Write a short story."}]
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])
这里 block_size 参数控制 diffusion 生成的块大小，在 Transformers 接口中默认为 16，与其他后端保持一致。
性能基准与落地建议
根据官方在 GSM8K、Math500、HumanEval、MBPP 等数据集上的评测，DFlash 能够在保持与纯 target 模型输出完全一致的前提下，实现约 6 倍的吞吐量提升。需要注意的是，这一数字高度依赖于具体模型组合、batch size 和硬件配置。在实际部署中，建议在目标硬件上运行官方提供的基准脚本进行验证：
python -m dflash.benchmark --backend vllm \
--base-url http://127.0.0.1:8000 --model Qwen/Qwen3.5-27B \
--dataset gsm8k --num-prompts 128 --concurrency 1 --enable-thinking
落地时需要关注的监控指标包括：speculative acceptance rate（接受率应高于 85% 为佳）、首 token 延迟、以及 GPU 利用率曲线。如果 acceptance rate 持续偏低，可适当降低 num_speculative_tokens 或检查 draft 模型是否与 target 模型版本匹配。
另一个工程细节是显存管理。由于 draft 和 target 模型需要同时驻留显存，建议确保 GPU 显存至少为单个模型权重的 2.2 倍。例如使用 Qwen3.5-27B（FP16 约 54GB）配合对应 DFlash draft 模型，总显存需求约在 80GB 以上，此时 A100 80GB 或 H100 80GB 是合适的硬件选择。
小结
DFlash 通过 block diffusion 技术将 speculative decoding 的 draft 阶段从自回归改为并行块生成，成功突破了传统方案的单 token 顺序瓶颈。配合 vLLM 或 SGLang 的完善支持，工程师只需调整几个关键参数即可在生产环境中部署。需要注意的是，block diffusion 的加速效果高度依赖于 draft 与 target 模型之间的分布匹配度，在选择模型组合时应优先使用官方已经微调好的配对。随着更多模型支持的出现，block diffusion 有望成为高吞吐量推理服务的标准配置。
参考资料
- DFlash 官方 GitHub 仓库：https://github.com/z-lab/dflash
- DFlash 论文：arXiv:2602.06036