文章摘要
近期推出的投机解码草稿模型Qwen3.8 - 27B - DFlash2，基于Qwen3.8 - 27B打造，参数量仅1.92B。它通过轻量路径选择器与双抽头动态卷积，实现2.7至3.4倍吞吐提升且保留原精度。在测试中多指标领先，适配主流推理框架。此外，文中还给出开源资源、部署及下载指南。

近期，大模型推理优化领域推出了一款全新的投机解码草稿模型Qwen3.8-27B-DFlash2，该模型由开发团队基于Qwen3.8-27B打造，通过轻量路径选择器与双抽头动态卷积的设计，实现了2.7至3.4倍的吞吐提升且完全保留了原模型的生成精度。

这款草稿模型的参数量仅为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系列的初代模型于今年年初发布，目前已经适配了SGLang、vLLM、TensorRT-LLM和llama.cpp等主流推理框架。根据公开测试数据，NVIDIA在Blackwell GPU上测得该系列最高实现15倍的吞吐提升，Google在TPU平台上报告每秒Token生成量提升3倍，截至目前系列草稿模型的累计下载量已经超过350万次。

开源资源

核心技术优化思路

投机解码的核心逻辑是通过小体积的草稿模型提前生成一段Token序列，再由目标大模型通过一次前向传播完成整块序列的验证，保留预测正确的部分，丢弃错误的内容。传统的草稿生成采用自回归的方式，每次仅生成一个Token，而DFlash系列打破了这一限制，实现了整块Token的并行预测，进一步提升了草稿生成的效率。DFlash2则在初代设计的基础上，解决了并行草稿生成中最突出的两个问题：如何从候选Token中选出最合理的连贯序列，以及如何将草稿的准确率维持到整块序列的末尾。

在初代DFlash的设计中，每个位置的Token预测是独立进行的，单看每个位置的选择都具备合理性，但无法保证相邻Token之间的连贯性，这种不连贯的序列在验证阶段会被大量截断。此前的Domino、DSpark等方案，通过串行的Head重写每个位置的全词表分布来换取序列的连贯性，但这种方式需要付出不小的计算代价。而DFlash的候选列表数据显示，这种高成本的自回归修正并非必需：初代模型在第一个位置的Top-1命中率达到85.4%，而正确Token落在Top16候选中的概率高达99.5%，也就是说即使Top-1选择错误，正确的Token通常也存在于候选列表之中。如果存在一个理想的选择器能够从Top16候选中挑出正确的序列，那么接受长度可以从4.27提升到6.79，这一差距完全来自于选择策略的优化空间。

轻量路径选择器

基于序列连贯性主要依赖局部关联的观察——一个Token是否合理，主要取决于它前一个相邻的Token，DFlash2在每个位置保留Top16的候选Token，并对所有相邻的候选对进行打分。打分过程完全并行完成，所有位置的相邻候选对可以一次性计算完成，不需要额外的骨干网络或LM Head的前向传播，仅有的串行操作是在预计算的分数上进行一次遍历，从最后一个已验证的Token出发，逐步选择最优的后继Token。基于这组分数的采样和拒绝采样，可以精确还原目标分布。测试数据显示，该选择器在T=0时带来了0.34个Token的接受长度提升，在T=1时提升了0.47个，两种设置下都优于DSpark的修正方案，同时参数量仅为DSpark的1/40，延迟开销仅为其1/16。

后缀衰减的本地化解决方案

在测试中团队发现，各位置的召回率会随着位置向后推移逐渐降低，即使是理想的选择器也会从第一个位置的99.5%下降到最后一个位置的87.8%，这说明候选Token本身的质量在变差，团队将这一现象称为后缀衰减（suffix decay）。团队分析认为，这一问题的根源在于骨干网络的容量不足：五层的骨干网络可能无法在整块序列的范围内维持足够的依赖关系。如果这一判断成立，那么增加网络深度应该会在靠后的位置带来最大的性能提升，实际测试也验证了这一点：3层、5层和15层的DFlash模型在第一个位置的表现几乎一致，但随着位置向后推移，性能差异逐渐显现。不过，无差别地增加网络深度存在明显的短板：额外的十个注意力块会在所有位置都增加容量，包括本来就没有太多提升空间的早期位置，同时也会抹去DFlash大部分的效率优势。

通过分析注意力分布，团队找到了更具针对性的优化方案：DFlash的注意力模块同时承担了两项任务——读取序列之前的上下文信息，以及建立块内部的Token依赖关系。但随着网络层数加深，注意力在建立块内依赖上的投入越来越少：块内注意力占比从第一层的30%下降到第五层的8%，且剩余的注意力集中在越来越少的几个Head上。因此，团队将两项任务进行拆分，由专门的模块负责块内的依赖建立，而注意力模块则继续专注于读取上下文信息。

双抽头动态卷积优化

块内的Token依赖通常是短程的，一个块仅跨越4到16个Token，最紧密的依赖关系存在于相邻的位置之间，而短卷积是处理这类依赖的天然算子。DFlash2参考了Canon Layers、Dynamic Short Convolutions等相关工作，在每个注意力子层和前馈子层的前后各插入了一个双抽头动态深度卷积。该卷积模块仅作用于块内的局部范围，且无状态，因此可以无缝嵌入DFlash的架构中，不需要改动注意力、LM Head或验证流程。仅新增1650万参数（约占总参数量的3%），带卷积的五层DFlash模型就已经接近15层DFlash的性能表现，显著缓解了后缀衰减的问题。该卷积模块仅为draft-verify周期带来了0.7%的延迟增加，而增加十个Transformer层则会带来15.2%的延迟提升。同时，第四、五层的平均块内注意力占比从9.4%下降到了0.5%，验证了“卷积吸收了局部工作、注意力回归读取上下文”的设计思路。这一结果说明，后缀衰减本质上是一个局部问题，仅通过回看一个位置的卷积核，就能获得十个额外Transformer层的大部分性能收益。

性能测试结果

投机解码的核心性能指标是接受长度，即每个请求生成的Token总数除以验证步数，该数值越高，代表每次验证前传所产出的有效Token越多。在Qwen3.5-4B模型的测试中，DFlash2在所有基准测试中都取得了领先的表现。跨基准平均来看，相比初代DFlash，其接受长度提升了1.05个Token（提升幅度达21%），相比DSpark模型提升了0.48个Token。本次升级的成本极低，路径选择器和卷积模块合计仅为五层DFlash的draft-verify周期带来了1.3%的延迟增加。

团队还对比了两款正式发布的草稿模型：在Qwen3.8-27B上，使用块大小为8的配置，DFlash2相比其原生MTP方案和社区的DSpark草稿模型都实现了领先；在Muse Glimmer模型上，DFlash2同样领先于同类方案。整体来看，DFlash2在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。DFlash2已可在SGLang、vLLM、llama.cpp等主流推理引擎中运行。

模型下载

modelscope download --model Qwen/Qwen3.8-27B --local_dir ./Qwen3.8-27B
modelscope 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"

启动服务，通过环境变量从开源平台拉取权重：

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.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

Apple Silicon 用户可使用带 DFlash 2 支持的 oMLX 预编译包，在模型管理工具中为目标模型开启 DFlash、指定草稿模型并将验证模式设为 dflash 即可。

以上内容不代表本平台立场，仅供读者参考