Inco AI 团队开源面向 Qwen3.8-27B 的投机解码草稿模型 Qwen3.8-27B-DFlash2。该草稿模型参数量 1.92B、约 3.85GB，与目标模型 Qwen3.8-27B 配合使用，沿用 DFlash 系列一次前向传播并行预测整块 token 的草稿设计，并在此基础上新增轻量路径选择器和双抽头动态卷积，把草稿准确率保持到整块末尾。

在单张 NVIDIA H200、SGLang、并发 1 的条件下，Qwen3.8-27B 配合该草稿模型的输出吞吐达到自回归解码的 2.7–3.4 倍。在五个基准上测试，平均接受长度 4.80，高于 Qwen3.8 原生 MTP 的 4.28 和社区 DSpark 草稿模型的 3.62，解码结果无损。

DFlash 2 在配备 oMLX 的 Apple M5 Max 上为 Qwen3.8-27B 生成草稿，与自回归解码并排对比：

 

DFlash 系列前代模型于今年 1 月发布，目前已进入 SGLang、vLLM、TensorRT-LLM 和 llama.cpp，NVIDIA 在 Blackwell GPU 上测得最高 15× 吞吐提升，Google 在 TPU 上报告每秒 token 数提升 3×，系列草稿模型累计下载量超过 350 万次。

开源地址

• 模型链接：https://modelscope.cn/models/z-lab/Qwen3.8-27B-DFlash2
• 代码仓库：https://github.com/z-lab/dflash
• 技术博客：https://inco.ai/blog/dflash2/

 

投机解码

投机解码的基本流程是：一个小的草稿模型先猜出一块 token，目标模型用一次前向传播验证整块内容，猜对的部分保留，猜错的丢弃。长期以来草稿生成本身是自回归的：一次一个 token；DFlash 把草稿也变成一次前传，整块的每个位置并行预测。DFlash 2 在这一设计内部解决了并行草稿留下的两个问题：选出正确的 token，以及把准确率保持到块的末尾。

 

正确的 token 已经在候选里

DFlash 并行且独立地预测每个位置，每个选择单看都是合理的。但没有任何机制保证它们彼此契合，而不连贯的块会在验证阶段被截断。近期的 Domino、DSpark 等方法，用串行的 head 重写每个位置的全词表分布来换取连贯性，但这种代价不小的自回归式修正真的必要吗？DFlash 自己的候选列表说明这种代价不小的自回归修正并非必需：第一个位置上 top-1 命中率为 85.4%，而正确 token 落在 top 16 候选中的概率是 99.5%。即使 top-1 选错，正确 token 通常仍在候选列表里。

 

如果有一个 oracle 总能从 top 16 中挑出正确候选，接受长度将从 4.27 提升到 6.79。这一差距完全是选择带来的提升空间。

如下图，仅用 DFlash 时，每个位置保留各自的 top-1 选择；图中两个相邻位置选中了同一个词，这种重复在验证时被淘汰。

 

 

DFlash 2 保留每个位置的 top 候选，选择器在其中追踪出一条连贯路径；此时整个块都得以保留。

 

轻量路径选择器

连贯性主要是局部的：一个候选是否契合，主要取决于它前面那一个 token。DFlash 2 因此在每个位置保留 top 16 候选，并对所有相邻候选对打分，对前驱 a 与当前候选 b：

 

 

打分过程完全并行，所有位置的所有相邻对一次算完，不需要额外的骨干网络或 LM head 前传；唯一的串行工作是在预计算分数上做一次遍历，从最后一个已验证 token 出发逐步跟随最佳后继，采样基于同一组分数进行，拒绝采样可精确还原目标分布。

选择器在 T=0 时带来 0.34 个 token 的提升，T=1 时为 0.47，两种设置下都优于 DSpark 的修正方案，同时参数量少约 40 倍、延迟开销低约 16 倍。

 

 

后缀衰减是一个局部问题

上面表中，各位置的 recall 都随位置向后走低，即使是 oracle 也从第一个位置的 99.5% 降到最后一个位置的 87.8%，即候选本身在变差，这是骨干网络的问题，Inco AI 团队称之为后缀衰减（suffix decay）。

一个可能的原因是容量：五层的骨干网络也许太小，不足以在整块范围内保持依赖关系。如果这个判断成立，那么增加深度应当在靠后的位置带来最大收益。事实确实如此。

3 层、5 层和 15 层的 DFlash 模型在第一个位置几乎完全一致，随着位置向后推移则逐渐分化。但增加深度是无差别的：额外十个注意力块在所有位置都增加了容量，包括本来就没多少提升余量的早期位置，同时也抹掉了 DFlash 大部分的效率优势。

 

注意力分布指出了更有针对性的修法。DFlash 的注意力同时承担两件事：读取块之前的上下文，以及建模块内部的依赖。但它在第二项上的投入越来越少：块内注意力占比从第 1 层的 30% 降到第 5 层的 8%，且残余部分集中在越来越少的几个 head 上。于是 Inco AI 团队把两项工作拆开：由一个专门的模块承担块内工作，注意力则继续负责读取上下文。

下图是五层 Qwen3-4B DFlash 中按 head 统计的块内注意力，颜色越亮表示该 head 投入草稿块的注意力越多。

 

 

双抽头动态卷积

块内工作本身就是短程的：一个块只跨 4 到 16 个 token，而最紧密的依赖存在于相邻位置之间。天然的算子是一个短卷积：两个抽头，一个在当前位置，一个回看前一个位置，权重随内容自适应。DFlash 2 因此参考 Canon Layers、Dynamic Short Convolutions 等工作，在每个注意力子层和前馈子层的前后各插入一个双抽头动态深度卷积。

 

该卷积是块内局部的、无状态的，因此可以直接嵌入 DFlash，不需要改动注意力、LM head 或验证流程。仅新增 1650 万参数（3%），带卷积的五层 DFlash 就已接近 15 层 DFlash 的表现，显著减轻了后缀衰减。这些卷积给 draft–verify 周期延迟带来 0.7% 的增加，而多加十个 Transformer 层带来的是 15.2%。第 4、5 层的平均块内注意力也从 9.4% 降到 0.5%，与“卷积吸收了局部工作、注意力回归读取上下文”的判断一致。一个只回看一个位置的 kernel 就能取得十个额外层大部分的收益：后缀衰减主要是一个局部问题。

 

效果

投机解码的核心指标是接受长度（acceptance length），即每个请求生成的 token 总数除以验证步数，数值越高说明每次验证前传产出的 token 越多。

Qwen3.5-4B 的单请求平均接受长度：

 

DFlash 2 在每一项基准上都领先。跨基准平均来看，它相对 DFlash 提升 1.05 个 token（21%），相对 DSpark 提升 0.48 个。这次升级依然廉价：选择器和卷积合计只给五层 DFlash 的 draft–verify 周期延迟增加 1.3%。

两个正式发布的草稿模型

分别对比各自模型的官方方案。Qwen3.8-27B 使用块大小 8，对比其原生 MTP 路径和社区 DSpark 草稿模型。

Qwen3.8-27B 的单请求平均接受长度：

 

 

Muse Glimmer 的单请求平均接受长度：

 

 

在两个模型上，DFlash 2 平均都比 DSpark 领先一个以上完整 token。它同样超过了各模型的官方 drafter：Qwen3.8-27B 上的 MTP 和 Muse Glimmer 上的 DFlash。换算下来，在 Qwen3.8-27B 上是自回归解码吞吐的 2.7–3.4 倍，在 Muse Glimmer 上是 3.1–4.6 倍。

本地部署

Qwen3.8-27B-DFlash2 草稿模型参数量 1.92B、约 3.85GB，与目标模型 Qwen3.8-27B 配合使用，官方评测环境为单张 NVIDIA H200。DFlash 2 已可在 SGLang、vLLM、llama.cpp 等主流推理引擎中运行。

模型下载

modelscope download --model Qwen/Qwen3.8-27B --local_dir ./Qwen3.8-27Bmodelscope download --model z-lab/Qwen3.8-27B-DFlash2 --local_dir ./Qwen3.8-27B-DFlash2

SGLang 部署

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

启动服务，通过 SGLANG_USE_MODELSCOPE 从魔搭拉取权重：

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 部署

llama.cpp 的支持位于 PR 27342，编译后按 draft-dflash 模式加载 GGUF 量化版草稿模型：

git clone https://github.com/ggml-org/llama.cpp.gitcd llama.cppgit fetch origin pull/27342/head:pr-27342git switch pr-27342
# NVIDIA CUDAcmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ONcmake --build build -j
# Apple Siliconcmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_METAL=ONcmake --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

Apple Silicon 用户可使用带 DFlash 2 支持的 oMLX 预编译包，在 Model Manager 中为目标模型开启 DFlash、指定草稿模型并将 Verify mode 设为 dflash 即可。