DFlash：块级扩散模型驱动的大模型推理加速器

一、引子：当 AI 开始"预判"你的话

你有没有遇到过这种体验：对着 AI 说话，它突然变得异常流畅，仿佛能"读心"一样秒回每一个字？这背后很可能藏着一项叫**投机解码（Speculative Decoding）**的技术——让一个小模型"预写"，大模型来"审稿"。传统投机解码的瓶颈在于"预写"环节本身还是串行的，像一个打字员逐字敲击。

DFlash 带来了一个完全不同的思路：不是逐字猜测，而是一次性"写出一整段"。

图1：DFlash 系统架构图 — Draft Model 使用块级扩散模型在单次前向传播中并行生成 K 个 token，Target Model 随后并行验证

二、背景：从 EAGLE-3 的局限到扩散模型的突破

大语言模型（LLM）推理有天然的"速度瓶颈"：生成每个 token 都必须等待前一个 token 完成——这是序列处理的本质限制。以 GPT-4、Qwen3、DeepSeek 为代表的超大模型，生成一段长回答可能需要数十秒。

投机解码试图打破这个循环：用一个小型"起草模型"（Draft Model）快速生成候选 token，再让大模型（Target Model）并行验证。EAGLE-3 是此前的 SOTA 方法，它将推理加速 3-4 倍，但起草阶段仍然是逐 token 串行的，本质上只是把"打字员换成了手速快的"，而非真正并行。

DFlash 的核心洞察是：既然目标模型的深层语义信息已经可用，为什么不让起草模型直接"借用"这些信息，一次性生成一整块 token？ 这就是"块级扩散"（Block Diffusion）的精髓。

三、核心技术：块级扩散如何工作？

3.1 条件生成：借用目标模型的"智慧"

DFlash 的核心创新在于条件扩散机制（Conditional Diffusion Drafting）。传统扩散模型需要从随机噪声开始，逐步去噪生成内容，这很难保证与目标模型语义对齐。DFlash 则巧妙地提取目标模型的中间层特征（context features），将其作为条件信息注入扩散过程——相当于给扩散模型一张"参考答案"，让它在正确的方向上生成。

这样，扩散模型不再需要"从零推理"，而是在目标模型深层次语义的引导下，并行地一次性生成 16 个 token 的 draft block。

3.2 单次前向传播 vs. 串行自回归

传统自回归草案（EAGLE-3）：

token1 → token2 → token3 → token4 → ... (串行，延迟累积)

DFlash 块级扩散草案：

[noise + context_features] → [token1, token2, ..., tokenK] (一次并行生成)

实验数据显示，DFlash 在 Qwen3-8B 上实现 6 倍无损加速，比 EAGLE-3 快了约 2.5 倍。

3.3 多后端支持

DFlash 不是"玩具项目"，它深度集成到了业界主流推理框架：

后端	特点	适用场景
vLLM	工业级推理引擎，H100 优化	高吞吐生产环境
SGLang	支持自定义调度策略	复杂推理管线
Transformers	原生 HuggingFace 生态	快速实验
MLX	Apple Silicon 优化	Mac 本地推理

四、功能体验：支持哪些模型？

DFlash 官方提供了大量预训练好的 Draft Model，覆盖了当前主流的中英文大模型：

• 国内主流：Qwen3.5 全系列（4B 到 122B）、DeepSeek-V4 系列（即将）、GLM-5.1（即将）、Kimi-K2 系列
• 国际主流：Gemma-4 系列、Llama-3.1、LLaMA 系列
• 编程专用：Qwen3-Coder-Next、Qwen3-Coder-30B-A3B

用户也可以根据官方即将开源的训练配方，自定义训练自己的 Draft Model 来加速任意 LLM。

五、上手体验

安装（Python >= 3.10）

推荐使用 uv 作为包管理器。不同后端有独立的可选依赖：

# vLLM 后端（推荐生产环境）
uv pip install -e ".[vllm]"

# SGLang 后端
uv pip install -e ".[sglang]"

# Transformers 后端（仅支持 Qwen3 和 LLaMA）
uv pip install -e ".[transformers]"

# Apple Silicon
pip install -e ".[mlx]"

Gemma-4 Docker 一键运行

Gemma-4 模型目前需要定制 vLLM 镜像，官方提供了开箱即用的 Docker 方案：

docker run --rm -it   --gpus all   --ipc=host   --shm-size=16g   -p 8000:8000   -v ~/.cache/huggingface:/root/.cache/huggingface   ghcr.io/z-lab/vllm-openai:gemma4-dflash-cu130   google/gemma-4-26B-A4B-it   --host 0.0.0.0   --port 8000   --speculative-config '{"method": "dflash", "model": "z-lab/gemma-4-26B-A4B-it-DFlash", "num_speculative_tokens": 15, "attention_backend": "flash_attn"}'   --attention-backend triton_attn   --max-num-batched-tokens 32768   --trust-remote-code

Python 代码调用（Transformers）

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 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 并非银弹，以下问题值得关注：

1. Gemma-4 特殊依赖：Gemma-4 需要定制 vLLM 构建版本，主流 pip install vllm 暂不支持，Docker 镜像是目前最稳定的方案。
2. 非所有模型均支持 Transformers 后端：目前只有 Qwen3 和 LLaMA-3.1 能用原生 Transformers；其他模型需通过 vLLM 或 SGLang 调用。
3. 硬件门槛较高：16GB+ VRAM 的 GPU 是基本要求，部分大模型（Qwen3.5-122B）需要多卡并行。
4. 安装复杂度：多后端依赖容易产生冲突，官方建议使用独立的虚拟环境。

七、行业意义与未来展望

DFlash 证明了扩散模型在文本生成领域的巨大潜力。块级扩散不仅能加速推理，其并行生成特性在理论上可以无限扩展——理论上可以用更大的 block size 换取更高的加速比，但需要解决 acceptance rate 的下降问题。

从更大的视角看，DFlash 代表了 LLM 推理优化的新范式：从"优化单点"（如 Flash Attention、量化）转向"系统性流水线重构"。随着 vLLM 和 SGLang 相继集成，DFlash 有望在 2026 年成为大模型推理的标准加速方案之一。

图2：DFlash 在 LocalLLaMA 社区引发广泛讨论