DFlash 2：让投机解码真正并行起来

2026年8月18日，Inco AI发布了DFlash 2。这是继年初DFlash之后的重大更新——在不改变输出结果的前提下，每一轮验证多产出20%以上的token，延迟仅增加约1%。

这意味着什么？在Qwen3.8-27B上，DFlash 2实现了2.7到3.4倍的吞吐量提升；在Meta的Muse Glimmer上，更是达到了3.1到4.6倍。每生成一个token，节省了约三分之一的算力。

这不仅仅是数字游戏——它直接影响Agent时代的成本结构。

一、为什么投机解码如此重要

Agent时代，推理成为瓶颈

大模型应用正在从"对话"走向"Agent"。一个Agent可能连续运行数小时甚至数天，持续消耗token。这个量级是传统Chat场景根本无法相比的。

每一个token都需要模型的一次完整前向传播。当你的Agent每天生成上百万token时，推理成本就是生命线。

投机解码的原理

投机解码（Speculative Decoding）的思路很聪明：

1. 用一个小模型（称为"Drafter"）快速猜出一串token
2. 用大模型（称为"Target"）一次性验证这串token
3. 猜对的token直接保留，猜错的丢弃重来

关键在于：大模型一次验证一整串token，效率远高于一个一个猜。

DFlash做了什么

传统投机解码里，小模型本身还是自回归的——也是一个token一个token地猜。DFlash的核心创新是：让小模型的猜测也变成并行的，整串token在一个前向传播中同时生成。

这在工程上需要用到块扩散（Block Diffusion）技术。具体原理这里不展开，但效果很直接——NVIDIA在Blackwell GPU上测出了最高15倍的吞吐量提升，Google在TPU上测出了3倍的token生成速度提升。

DFlash目前已经集成进了SGLang、vLLM、TensorRT-LLM和llama.cpp。NVIDIA、Red Hat、Meta、Poolside、小米都发布了配套的DFlash Draft模型。Hugging Face下载量已超过350万次（截至2026年8月）。

二、DFlash 2做了什么改进

DFlash的核心机制是独立预测每个位置——每个位置根据自己的上下文，从候选列表中选最优token。候选列表里通常有正确答案，但问题是：各个位置的最优选择放在一起，可能形成一个不连贯的句子。

在验证阶段，这种不连贯会导致整块被截断，前功尽弃。

DFlash 2有两个核心改进来解决这个问题：

改进一：轻量级路径选择器

观察：正确答案其实一直在候选列表里。以Qwen3-4B在GSM8K上的测试为例：

关键数据：Top-1准确率85.4%，但Top-16召回率高达99.5%。正确答案几乎总在列表里，问题只是怎么把它选出来。

DFlash 2的方案是相邻候选配对评分。不需要重新调用大模型，而是在候选列表内部做局部匹配：

S(a,b) = U(b) + <A(a) ⊙ H(h_t), B(b)>

简单说：看相邻两个token搭不搭配。如果搭配就加分，不搭配就扣分。然后从验证点出发，贪心地走一条总分最高的路径。

效果对比：

路径选择器用40分之一的参数量和16分之一的延迟，超越了DSpark修正方案。选择比预测更便宜。

改进二：轻量级局部卷积

观察：越到block末尾，准确率衰减越严重。即使有完美的路径选择器，到第6个位置时准确率仍会下降到87.8%左右。这是**后缀衰减（Suffix Decay）**问题，是模型本身容量不足导致的。

传统解法是增加模型层数。但这样会在所有位置都增加计算量——包括那些本来就不需要额外容量的前几个位置。

DFlash 2的洞察是：后缀衰减主要是一个局部问题。block只有4-16个token，最强的依赖关系都发生在相邻位置之间。增加10层Transformer来改善最后几个位置，是用大炮打蚊子。

解决方案：两个抽头的动态深度可分离卷积：

Conv(x)_t = k_t,0 ⊙ x_t + k_t,1 ⊙ x_{t-1}

在每个DFlash层的每个注意力头和MLP子层前后，都插入这个卷积操作。每个位置的表示只和自己的前驱做一次混合，信息就这样一步步向右传播。

这个卷积只增加了16.5M参数（3%）， cycle延迟只增加0.7%——而10层Transformer会增加15.2%。

效果：五层DFlash加上卷积，几乎追平了15层DFlash的性能。后缀衰减被大幅缓解，而计算量几乎没有增加。

综合效果

把两个改进合在一起：

Qwen3.5-4B（平均接受长度，越高越好）：

DFlash 2在所有基准测试上都领先，平均比DFlash高出21%，比DSpark高出9%。

三、快速上手教程

支持的推理引擎

DFlash 2目前已支持四大主流推理引擎：SGLang、vLLM、llama.cpp和oMLX。

SGLang

pip install "sglang[all] @ git+https://github.com/sgl-project/sglang.git#subdirectory=python"

python -m sglang.launch_server \
 --model-path Qwen/Qwen3.8-27B \
 --speculative-algorithm DFLASH \
 --speculative-draft-model-path incoai/Qwen3.8-27B-DFlash2 \
 --speculative-num-draft-tokens 8

vLLM

pip install -U "vllm @ git+https://github.com/vllm-project/vllm.git@refs/pull/52816/head"

vllm serve Qwen/Qwen3.8-27B \
 --speculative-config '{
  "method": "dflash",
  "model": "incoai/Qwen3.8-27B-DFlash2",
  "num_speculative_tokens": 7
}'

llama.cpp

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git fetch origin pull/27342/head:pr-27342
git switch pr-27342

# NVIDIA CUDA
cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON
cmake --build build -j

# Apple Silicon
cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_METAL=ON
cmake --build build -j

./build/bin/llama-server \
 -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \
 -hfd incoai/Qwen3.8-27B-DFlash2-GGUF:Q4_K_M \
 --spec-type draft-dflash \
 --spec-draft-n-max 7

oMLX（Apple Silicon）

下载预构建版本：

• oMLX 0.6.2 with DFlash 2

1. 打开Model Downloader，下载：

   • mlx-community/Qwen3.8-27B-4bit
   • incoai/Qwen3.8-27B-DFlash2

2. 在Model Manager中编辑mlx-community/Qwen3.8-27B-4bit，配置DFlash：

   • DFlash: enabled
   • Draft model: incoai/Qwen3.8-27B-DFlash2
   • Draft quantization: enabled
   • Runtime block size: 5
   • Verify mode: dflash

模型下载

四、生态与行业采用

DFlash系列的采用速度非常快。七个月内从论文变成了行业标准。

已发布官方Draft模型的厂商：

• NVIDIA：Kimi-K2.6-DFlash
• Red Hat：Gemma-4-31B-IT DFlash
• Meta：Muse Glimmer（内置DFlash）
• Poolside：Laguna-S-2.1-DFlash
• 小米：MiMo-V2.5-Pro-FP4-DFlash
• Modal：Kimi-K3-DFlash

生产环境案例：

• CoreWeave的Kimi K2.7 Code端点（Artificial Analysis上该模型最快）默认运行DFlash
• NVIDIA在Blackwell GPU上测得最高15倍吞吐量提升
• Google在TPU上测得3倍token生成速度提升

五、设计哲学与核心观点

1. 并行是终态

DFlash从第一天起就坚持一个原则：从Draft到Verify，每个环节都应该是并行的。自回归是序列生成的本能敌人，引入任何形式的自回归链都会成为瓶颈。DFlash 2延续了这个思路。

2. 选择比预测更便宜

DFlash 2最重要的insight不是某个模型架构的改进，而是这个认知：与其花力气预测得更准，不如花更小的代价从候选里选得更对。路径选择器只用了2M参数，0.6%的延迟，就超越了77.8M参数、9.6%延迟的DSpark方案。这个思路本身值得深思。

3. 问题诊断先于方案设计

在动手优化之前，DFlash团队先做了详尽的分析：Suffix Decay的根源是什么？容量问题还是架构问题？为什么增加层数不是最优解？这些问题的答案直接决定了最终的方案。先诊断，再开药。

4. 局部性是高效算法的线索

Suffix Decay主要是一个局部问题——增加10层Transformer来改善最后几个位置的准确率，是用牛刀杀鸡。两抽头卷积就够了，因为它直接利用了问题的数学结构：token之间的依赖随距离指数衰减。知道这一点，就不需要用通用的大模型容量去硬扛。

5. 生态大于一切

DFlash系列没有选择做一个封闭的优化方案，而是从一开始就兼容E2B风格的API，最终选择兼容现有的推理引擎生态。这让它能够快速被SGLang、vLLM、llama.cpp采纳。没有生态的技术再先进也只是论文。

六、总结

DFlash 2的核心成就是：在保持输出完全一致（数学证明保证）的前提下，将投机解码的效率又向前推进了一大步。

关键数据：

• Qwen3.8-27B：2.7到3.4倍吞吐量提升
• Muse Glimmer：3.1到4.6倍吞吐量提升
• 相比DSpark：+9%平均接受长度，仅1.3%延迟开销
• 相比DFlash：+21%平均接受长度，仅1%延迟开销

在Agent时代，每个token的成本乘以Agent运行的总token数，就是系统的成本结构。DFlash 2让这个成本降低了三分之二。

Inco AI在博客中写道："推理还没有触底。"这句话值得记住。在这个方向上，显然还有很大的空间。

项目地址：https://github.com/z-lab/dflash
官方博客：https://inco.ai/blog/dflash2/
模型下载：https://huggingface.co/collections/incoai/dflash-2

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个星标，谢谢你看我的文章，我们，下次再见。

首发于微信公众号「瑞哥观势」。