发布日期:2026-08-20|适用读者:大模型推理工程师、Agent 开发者与本地模型用户

DFlash 2 是 Inco AI 于 2026 年 8 月 18 日发布的块扩散推测解码方案,通过候选路径选择器与双抽头动态卷积,在一次并行前向中生成更连贯的草稿 token,再交给目标模型验证。官方数据显示,它在只增加约 1.3% 草稿—验证周期延迟的情况下,平均每轮可比 DFlash 多接受 21% 的 token;已发布的两个草稿器在单请求测试中分别达到自回归解码 2.7-3.4 倍与 3.1-4.6 倍吞吐,但实际收益会随模型、任务、量化方式和并发数变化。

DFlash 2 是什么?

DFlash 2 是面向自回归大模型的轻量级块扩散草稿器,不是可独立对话的语言模型。它一次预测一整块候选 token,目标模型再并行验证;被接受的 token 与目标模型原本会生成的结果一致。

这套方案由 Inco AI 在第一代 DFlash 基础上提出,当前开源仓库由 Z Lab 维护。与它直接相关的实体包括:

  • 推测解码(speculative decoding):小模型先猜,目标模型后验,减少目标模型逐 token 前向的次数。

  • 块扩散(block diffusion):同一轮并行预测多个位置,而非让草稿器逐 token 自回归生成。

  • SGLang、vLLM、llama.cpp 与 oMLX:DFlash 2 已给出接入路径的主流推理运行时。

  • MTP 与 DSpark:官方基准中的两类对照草稿方法。

截至 2026 年 8 月 20 日,官方发布了面向 Qwen3.8-27BMuse-Glimmer-30B 的两个 DFlash 2 草稿器。模型卡明确说明,草稿器必须与对应目标模型配套,不能把一个 checkpoint 任意挂到其他模型上。

DFlash 2 如何工作?

DFlash 2 的关键改进是“先保留每个位置的多个候选,再并行选出连贯路径”,同时用局部卷积缓解草稿块尾部准确率下降。

1. 候选路径选择器

第一代 DFlash 在每个位置直接取概率最高的 token,但相邻位置各自合理,不代表整段连贯。DFlash 2 为每个位置保留前 16 个候选,用约 200 万参数的轻量选择器为相邻候选打分,再沿预计算分数选出一条路径。

根据 Inco AI 2026 年技术文章,在五层、面向 Qwen3-4B 的实验草稿器上,路径选择将温度为 0 时的平均接受长度从 4.27 提高到 4.61,额外周期延迟仅 0.6%;温度为 1 时则从 3.78 提高到 4.25。

2. 双抽头动态卷积

草稿越靠近块尾,候选准确率越容易下降,这一现象被作者称为“suffix decay”。DFlash 2 在注意力与前馈子层前后加入双抽头动态深度卷积,让每个位置并行融合自身和前一位置的信息。

官方 2026 年实验显示,这部分增加约 1650 万参数,即五层草稿器参数量的 3%,周期延迟增加 0.7%;相比直接把草稿器从 5 层加深到 15 层,局部卷积更聚焦于块内短程依赖。

3. 目标模型无损验证

草稿器只负责提出候选,最终接受与否仍由目标模型决定。贪心解码时,输出与目标模型逐 token 解码完全一致;采样时通过拒绝采样保持目标分布,因此“无损”指输出规则不变,不代表每种硬件和负载都能获得相同倍数的加速。

DFlash 2 与 DFlash、MTP、DSpark 有什么区别?

DFlash 2 的优势不是扩大草稿模型,而是在保持单次并行草稿的前提下,提高候选之间的连贯性和块尾准确率。

方法

草稿方式

连贯性处理

官方结果中的特点

主要限制

MTP

多 token 预测头

依赖模型内置结构

无需额外外部草稿器

仅适用于原模型已提供的 MTP

DFlash

块扩散并行草稿

各位置独立取首选

草稿延迟低、部署生态成熟

候选路径不连贯,块尾有衰减

DSpark

并行草稿加顺序修正

顺序修正分布

接受长度通常高于 DFlash

修正步骤带来额外延迟

DFlash 2

块扩散并行草稿

路径选择 + 局部卷积

兼顾接受长度与低周期开销

checkpoint 与目标模型强绑定,仍属新发布方案

在官方匹配训练的 Qwen3.5-4B 实验中,DFlash 2 在 GSM8K、MATH-500、HumanEval、MBPP 和 MT-Bench 上的平均接受长度为 5.97,DFlash 为 4.92,DSpark 为 5.49;该结果来自相同训练设置,但目前发布给用户直接运行的 checkpoint 是另外两个目标模型,不能混为同一组部署数据。

DFlash 2 实际能快多少?

DFlash 2 在低并发下的加速最明显,高并发时收益会因 GPU 已被自回归批处理充分利用而收窄。

Qwen3.8-27B-DFlash2 官方模型卡给出的测试环境为单张 NVIDIA H200、SGLang、FlashAttention 3、最多生成 4096 个 token。以下均为 2026 年官方测量值:

并发数

GSM8K

MATH-500

HumanEval

MT-Bench

1

236.1 tok/s(3.43 倍)

230.7 tok/s(3.34 倍)

214.6 tok/s(3.11 倍)

184.0 tok/s(2.67 倍)

8

1328.7 tok/s(2.84 倍)

1368.3 tok/s(2.85 倍)

1291.5 tok/s(2.67 倍)

1090.2 tok/s(2.27 倍)

32

1922.5 tok/s(1.45 倍)

1951.8 tok/s(1.30 倍)

1799.0 tok/s(1.16 倍)

1525.3 tok/s(1.01 倍)

这组数据给出三个实用结论:

  1. 交互式 Agent 和代码生成更容易受益。 单请求或低并发时,逐 token 延迟更接近主要瓶颈。

  2. 高并发不能照搬“3 倍”结论。 在并发 32 的官方测试中,不同任务只有 1.01-1.45 倍。

  3. 接受长度不是最终吞吐。 草稿器越大、显存带宽越紧或量化内核越不适配,接受更多 token 也未必等比例加速。

官方模型仓库在 2026 年 8 月 19 日记录的参数量为:Qwen3.8-27B 草稿器约 19.24 亿参数,Muse-Glimmer-30B 草稿器约 27.72 亿参数。这意味着 DFlash 2 虽比目标模型小,但仍需要额外显存与加载时间。

哪些场景适合部署 DFlash 2?

DFlash 2 最适合“单次输出长、交互延迟敏感、目标模型固定”的推理工作负载。

  • 长链路 Agent:规划、工具调用与反复读取会持续产生大量 token,单 token 延迟累积明显。

  • 代码生成与数学推理:官方 HumanEval、MBPP、GSM8K 和 MATH-500 均有公开测量数据。

  • 固定模型的在线服务:团队能为同一目标模型长期维护匹配草稿器和运行时。

  • Apple Silicon 本地推理:官方仓库提供 MLX/oMLX 路径,但量化矩阵乘内核会影响最佳块大小。

以下情况不应优先部署:目标模型没有匹配 checkpoint、服务经常热切换模型、GPU 已长期处于高并发饱和状态,或团队无法接受使用最新推理引擎分支。

DFlash 2 位于自建推理服务底层,不替代应用层的统一模型接口。例如七牛云AI提供多款主流大模型的标准化接入,两者解决的是不同层级的问题:前者优化特定模型的解码周期,后者处理应用接入与模型调用。

如何用 SGLang 运行 DFlash 2?

截至 2026 年 8 月 20 日,最直接的服务端路径是按官方模型卡安装 SGLang 最新源码版,并同时指定目标模型和配套草稿器。

第一步:准备环境

生产部署前应确认 CUDA、驱动与显存满足目标模型要求,并在隔离环境中安装。官方当前命令为:

python -m venv .venv
source .venv/bin/activate
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

这里的 8 是推测块相关配置;官方基准口径为每轮提出 7 个草稿 token,并由验证步骤产出额外 token。不要在没有重新评测的情况下把块大小设得越大越好。

第三步:做同条件 A/B 测试

部署验收至少记录以下指标,并确保基线与 DFlash 2 使用相同提示词、采样参数、最大输出长度和并发数:

  1. 输出吞吐量(output tok/s)与端到端请求吞吐量。

  2. 首 token 延迟、每输出 token 延迟,以及 P50/P95 延迟。

  3. 平均接受长度和每轮草稿接受率。

  4. 目标模型、草稿器的显存占用与 GPU 利用率。

  5. 贪心输出一致性,或采样分布的统计一致性。

vLLM、llama.cpp 与 Ollama 的 DFlash 2 支持在发布时仍引用特定 Pull Request 或实验分支,生产环境应锁定提交版本,不要直接依赖会移动的分支头。

常见问题

Q:DFlash 2 会降低模型回答质量吗?

不会改变目标模型的解码规则。贪心模式下,目标模型会拒绝错误草稿,因此结果与原始自回归输出一致;采样模式通过拒绝采样保持目标分布。不过,运行时实现、采样参数或量化配置错误仍可能造成结果差异,需要 A/B 验证。

Q:DFlash 2 能用于任意大模型吗?

不能直接通用。草稿器需要针对目标模型训练,并与其词表、架构和隐藏特征对齐。截至 2026 年 8 月 20 日,官方 DFlash 2 集合公开的是 Qwen3.8-27B 与 Muse-Glimmer-30B 两组目标模型及其 GGUF 变体。

Q:DFlash 2 和量化可以同时使用吗?

可以,但量化内核会改变最优配置。官方 MLX 说明建议量化目标模型或草稿器时使用不大于 5 的块大小,因为当前量化矩阵乘内核在更宽验证块上的效率会下降;实际值仍应以设备基准为准。

Q:为什么并发越高,加速倍数往往越低?

高并发批处理已能提高目标模型的 GPU 利用率,推测解码增加的草稿计算和验证宽度就更难被隐藏。官方 Qwen3.8-27B 数据中,GSM8K 的加速从并发 1 时的 3.43 倍降至并发 32 时的 1.45 倍。

Q:现在适合直接上生产吗?

适合先在固定模型、低到中并发、长输出服务中灰度验证。DFlash 生态已进入多个推理引擎,但 DFlash 2 发布仅两天,部分接入仍依赖最新源码或 Pull Request;应锁定依赖、保留自回归回退路径并持续监控收益。

结论

DFlash 2 用候选路径选择与局部卷积,把第一代 DFlash 的并行草稿从“各位置独立猜测”推进到“整块连贯选择”,官方 2026 年数据表明它以约 1.3% 周期开销换来平均 21% 的接受长度增益。Inco AI 技术文章与 Z Lab 模型卡同时说明,2.7-4.6 倍属于特定单请求基准,而不是所有生产负载的固定收益。

本文内容基于 2026 年 8 月 20 日可用的官方仓库、模型卡和发布文章;DFlash 2 仍在快速接入推理引擎,建议部署前复核最新兼容矩阵与固定版本。

参考资料