DFlash 2 发布：并行草稿继续压低大模型推理延迟

DFlash 2 于 2026 年 8 月 19 日发布，核心方向没有改变：让一个轻量级块扩散模型并行写出一段草稿，再交给目标大模型一次性验证，从而减少目标模型逐个生成 Token 的次数。

DFlash 是一种基于块扩散模型的推测解码技术，它用并行生成的草稿模型替代传统推测解码中的自回归草稿模型。 这句话基本概括了 DFlash 2 的定位：它不是新的通用聊天模型，也不是试图用一个小模型直接取代 Qwen、Llama 这类目标模型，而是部署在大模型推理链路中，专门负责“提前猜一段可能出现的内容”。

这条路线值得关注，是因为大模型推理的主要矛盾已经从“能不能生成”转向“生成一个 Token 要等多久”。在长回答、代码补全、Agent 工具调用和实时语音等场景里，模型每多花 100 毫秒，用户感受到的等待就会更明显。DFlash 2 的目标，就是把这段等待从串行过程改造成更多并行计算。

大模型为什么会慢

自回归生成是大语言模型逐步输出 Token 的机制，每一个新 Token 都依赖此前已经生成的内容。 模型先根据输入预测第一个 Token，再把输入和第一个 Token 合起来预测第二个 Token，依次循环。

这种机制并不意味着 GPU 每一步都没有并行计算能力。事实上，模型内部的矩阵乘法依然可以高度并行，但“下一步要看上一步结果”这个依赖关系，使得生成阶段无法像处理一整段文本那样一次性算完。对于已经存在的长上下文，模型可以通过 Prefill 阶段批量处理；但在输出阶段，每个 Token 都要等待前一个 Token 落地。

可以把它理解成两种不同的生产方式：普通自回归生成像一个人按照清单逐项填写，每填完一项才能知道下一项该填什么；推测解码则先让一名速度更快的助手把后面几项预填出来，再由专家一次检查多项内容。只要助手猜得足够准，专家就不需要重新逐项填写。

传统推测解码已经证明了这种思路有效。它通常使用一个较小的自回归模型生成草稿，再让大模型并行验证。如果草稿模型一次提出 5 个 Token，目标模型能够一次检查这 5 个位置，那么每轮推理有机会接受多个 Token，最终吞吐和首字后的生成速度都会提高。

问题在于，传统草稿模型本身仍然是自回归的。它虽然比目标模型小，但依旧要按照 Token 顺序一个个生成草稿。EAGLE-3 等先进方案在合适任务上通常可以带来约 2 到 3 倍的加速，但草稿生成的串行开销仍然限制了上限。草稿模型越大，预测通常越准，接受长度可能越高；但草稿模型越大，生成草稿又越慢，部署成本也越高。

DFlash 的判断是：草稿模型不需要独立完成一段高质量回答，它只要尽可能快地提出“足够接近目标模型”的候选片段即可。这个任务更适合块扩散模型，而不是一个缩小版的完整语言模型。

DFlash 2 的核心：一次写一块

块扩散语言模型是把一段待生成的 Token 作为一个块，通过多轮并行去噪或修正逐步确定内容的模型。 和自回归模型每次只决定一个下一个 Token 不同，块扩散模型可以同时处理一个区间内的多个位置。

在 DFlash 2 的推理流程里，草稿模型会根据当前上下文提出一段候选 Token。这段候选内容不必一次就完全正确，模型可以在块内并行预测和修正。随后，目标模型利用自己的完整能力，对这段候选序列进行并行验证，并保留从开头开始连续匹配的部分。

例如，草稿模型提出 8 个 Token，目标模型验证后发现前 6 个 Token 与自己的贪心预测一致，第 7 个位置出现分歧，那么前 6 个 Token 可以直接接受，后面的内容从第 7 个位置继续生成。传统流程可能需要目标模型完成 6 次串行解码；推测解码把它压缩成一次草稿加一次验证。

这里的“并行”并不是说目标模型可以无条件一次生成任意长度的文本。目标模型仍然负责最终决定输出，DFlash 只是提前准备候选答案。也正因为有验证环节，DFlash 的目标是无损推理：在采用确定性解码和相同采样设置的情况下，输出应当与目标模型直接生成保持一致，或者至少由验证规则保证不会接受目标模型不认可的 Token。

DFlash 2 延续了这种架构，并把重点放在草稿质量、草稿延迟和生产部署开销之间的平衡。它不是单纯把草稿块做得更长。块越长，理论上一次能接受的 Token 越多，但错误也更容易在后续位置累积；草稿模型太小，单轮运行确实更快，却可能导致接受率下降，最终目标模型仍要频繁接管。真正决定收益的是“草稿生成成本”和“平均接受长度”的乘积。

KV 注入解决了小模型看不懂上下文的问题

KV 注入是把目标模型在当前上下文中计算出的 Key-Value 特征，经过适配后注入草稿模型的 KV Cache，使草稿模型获得目标模型的上下文提示。 这是 DFlash 与普通小型草稿模型最关键的区别之一。

一个独立运行的小模型，面对复杂代码、长篇推理或多轮对话时，很难准确判断目标模型下一步会说什么。它可能知道问题的大方向，却无法跟上目标模型在当前上下文里的细节。DFlash 的草稿模型虽然轻量，但并不是完全“闭着眼睛”猜测。

在目标模型处理上下文之后，系统会从目标模型的若干层提取特征，并将这些信息融合、投影，再注入草稿模型的 KV Cache。这样一来，草稿模型可以利用目标模型已经算好的上下文表示。更直观地说，小模型负责快速组织候选片段，目标模型则提前把“当前语境、推理状态和表达方向”告诉它。

这不是简单复制目标模型的隐藏状态，也不是让两个模型共享所有参数。KV 注入更像是给草稿模型一张经过目标模型整理过的地图：草稿模型仍然需要自己走路，但少了重新辨认道路和方向的成本。

这项设计直接影响接受率。推测解码的加速效果并不只取决于草稿模型的速度，还取决于目标模型愿意接受多少候选 Token。如果每轮草稿只能被接受 1 到 2 个 Token，那么即使草稿模型非常轻，也很难超过常规解码；如果平均接受长度稳定在 5、6 个甚至更多 Token，目标模型的并行验证能力才会真正转化成用户可感知的速度提升。

DFlash 2 与其他推测解码路线怎么比

推测解码的核心指标是每轮平均接受 Token 数与草稿生成延迟，而不是单独比较草稿模型参数量。 因此，DFlash 2 不应该只和普通小模型比较大小，而要放到完整的解码链路里评估。

| 方案 | 草稿生成方式 | 草稿阶段是否串行 | 主要优势 | 主要限制 | |---|---|---:|---|---| | 普通自回归解码 | 目标模型逐 Token 生成 | 是 | 实现简单，输出稳定 | 每个 Token 都要等待前一步 | | 小型自回归推测模型 | 小模型逐 Token 生成草稿 | 是 | 生态成熟，适配成本相对低 | 草稿阶段仍有串行瓶颈 | | EAGLE-3 | 基于目标模型特征的自回归草稿 | 是 | 接受率较高，适配多个目标模型 | 草稿生成速度受串行计算限制，常见加速约 2 到 3 倍 | | DFlash | 轻量块扩散模型 | 否，块内并行 | 草稿延迟低，可一次提出多个候选 Token | 需要专用草稿模型和推理框架支持 | | DFlash 2 | 改进的块扩散草稿与上下文注入流程 | 否，块内并行 | 继续优化接受率、端到端延迟和部署效率 | 收益依赖目标模型、硬件、批量和上下文长度 |

从已有公开结果看，DFlash 路线在 Qwen3-8B 等模型上曾报告最高约 6 倍的无损加速；社区测试还出现过从 48.5 Token/秒提升到 415.7 Token/秒的案例。不过，这两个数字不能简单理解为所有模型和所有请求都能达到的固定速度。它们通常依赖特定硬件、目标模型、输入长度、输出类型、批量大小以及接受率。

更值得关注的是加速结构，而不是某个最高峰值。公开材料显示，DFlash 把扩散模型限制在草稿阶段，避免了让一个大规模扩散语言模型承担完整生成任务。此前一些扩散式推测方案需要 7B 级别的草稿模型，这会削弱推测解码的经济性。DFlash 的思路是训练更轻量的扩散适配器，把容量集中用在“快速提出与目标模型相近的候选块”上。

如果把目标模型每轮验证看成一次固定成本，那么平均接受长度越高，单位 Token 分摊到的验证成本越低；如果把草稿模型看成额外成本，那么草稿模型越小、并行度越高，端到端收益越明显。DFlash 2 的工程价值，正是在这两个成本之间寻找更好的工作点。

速度之外，DFlash 2 对部署意味着什么

DFlash 2 是推理运行时的加速组件，而不是一个拿来直接聊天的独立基础模型。 用户最终接触到的仍然是目标模型，DFlash 2 只是改变了目标模型生成 Token 的方式。

对在线服务来说，最直接的收益是降低每个请求的生成延迟。在客服、代码补全和 Agent 任务中，用户通常不只关心总吞吐，也关心首字之后的连续输出是否顺畅。DFlash 2 如果能让每次目标模型前向计算承载更多已验证 Token，就有机会同时改善单请求延迟和单位 GPU 的有效吞吐。

对长文本生成来说，收益可能更明显。回答越长，逐 Token 解码的串行等待越容易累积。代码生成、结构化 JSON、SQL 和多段解释文本往往具有较强的局部规律，草稿模型更容易预测连续片段，因此适合尝试推测解码。但在强随机采样、创意写作或输出经常改变方向的场景里，草稿接受率可能下降，收益会明显收窄。

对资源调度来说，DFlash 2 也带来新的复杂度。系统需要同时管理目标模型和草稿模型，还要处理目标模型 KV Cache、草稿 KV Cache、特征注入以及验证结果回收。目标模型本身如果已经受到显存带宽限制，额外的草稿计算不一定能带来线性收益；在高并发场景下，批处理策略也可能改变最优块长度。

因此，DFlash 2 不是“装上就自动九倍加速”的开关。部署团队至少需要观察以下指标：

• 草稿模型每轮生成候选块的耗时；
• 平均接受 Token 数和接受率；
• 目标模型每秒输出 Token 数；
• 单请求端到端延迟，而不是只看某一个 kernel 的耗时；
• 不同上下文长度、批量大小和采样参数下的收益；
• 草稿模型额外占用的显存和调度开销。

如果草稿耗时为 3 毫秒、目标模型验证耗时为 20 毫秒、每轮平均接受 6 个 Token，那么单位 Token 的主要成本就从约 20 毫秒下降到约 3.8 毫秒，理论上接近 5 倍改善；如果平均只接受 2 个 Token，同样的链路成本则约为 11.5 毫秒，收益会大幅降低。这也是为什么“平均接受长度”比“草稿模型有多少参数”更值得看。

现阶段最适合谁

DFlash 2 最适合已经部署大模型推理服务、并且愿意为目标模型配套草稿模型和运行时的团队。 它的价值主要体现在规模化推理，而不是个人用户换一个模型文件就能获得同样收益。

第一类适用场景是代码补全。代码具有语法结构、缩进规律和较强的局部重复性，草稿模型容易提出连续候选，目标模型也更容易批量验证。第二类是结构化输出，例如 JSON、SQL 和工具参数，这些输出的格式约束可以提高草稿预测的稳定性。第三类是长答案生成，尤其是目标模型已经完成较充分上下文处理、后续输出方向相对明确的任务。

相对不适合的场景包括高随机性的采样、频繁改变推理路线的复杂 Agent，以及每次输出只有几个 Token 的短响应。后者的总延迟可能主要花在请求排队、上下文 Prefill 和网络传输上，DFlash 2 能优化的只是解码环节。

还需要注意模型匹配问题。DFlash 草稿模型通常需要针对目标模型或模型家族进行适配。一个为 Qwen 系列训练的草稿器，不应被默认视为适用于任意 Llama、GLM 或其他架构。词表、层结构、隐藏维度、特征接口和 KV Cache 组织方式都可能影响兼容性。

不要只看峰值加速

推测解码的真实收益取决于端到端工作负载，单次基准测试中的峰值 Token/秒不能代表生产环境表现。 这是评估 DFlash 2 时最需要保持清醒的地方。

公开材料中，DFlash 初代已经出现超过 6 倍的无损加速描述，Qwen3-8B 上也有最高约 6 倍的结果。社区转述的 48.5 Token/秒到 415.7 Token/秒案例，约为 8.6 倍提升，但这类数字必须结合硬件、输入输出长度和测试方式理解。不同实现是否计入草稿模型开销、是否包含框架调度、是否使用连续批处理，都会直接影响结果。

更合理的测试方式是建立同一目标模型的对照组：关闭推测解码、使用普通小型自回归草稿、使用 DFlash 2 草稿，并在短上下文、中等上下文、长上下文和不同输出长度下重复测试。除了吞吐，还要记录 P50、P95 延迟、显存峰值、平均接受 Token 数以及输出一致性。

对于开发者而言，DFlash 2 的重要性不只是多了一个加速选项。它说明推测解码正在从“用一个更小的语言模型猜答案”转向“用更适合并行计算的模型快速提出候选”。这是一种架构层面的变化：目标模型继续负责质量和最终决策，草稿模型则不再追求完整语言能力，而是追求低延迟、低显存和高接受率。

OpenAI Hub 判断

DFlash 2 的发布，延续了今年推理优化领域一个清晰趋势：模型参数规模仍在增长，但服务端不会只靠堆 GPU 来解决延迟问题。Prefill 优化、KV Cache 管理、MTP、Speculative Decoding 和块扩散草稿正在共同争夺生成阶段的每一毫秒。

DFlash 2 最有价值的地方，是把扩散模型放到了一个更现实的位置。它不需要证明扩散语言模型可以全面击败自回归模型，也不需要承担长链路生成中的全部质量风险。它只需要在目标模型前面快速写出一份“足够像正确答案”的草稿，再让目标模型批量盖章。

这也决定了它的上限和边界。DFlash 2 能否在生产环境兑现收益，取决于草稿接受率、目标模型支持情况、推理框架调度和硬件利用率，而不是发布页上的单一峰值。对于拥有自建推理栈的团队，DFlash 2 值得进入基准测试清单；对于只调用现成模型服务的开发者，它暂时更像一项值得关注的底层技术，而不是立刻可配置的通用功能。

截至 2026 年 8 月 19 日，DFlash 2 给出的信号已经足够明确：大模型生成速度的竞争，正在从“让目标模型算得更快”扩展到“让目标模型少算几次”。如果块扩散草稿模型能够持续提高接受率，并进一步降低 KV 注入和运行时调度开销，推测解码可能会从高级部署优化，逐渐变成主流大模型服务的默认组成部分。

参考来源

1. DFlash 相关模型与权重搜索：用于查看公开发布的 DFlash 系列模型、适配目标模型与权重信息。
2. SGLang GitHub 仓库：DFlash 相关推理框架集成和生产部署能力的主要开源项目之一。
3. Hugging Face 模型社区：用于交叉核对模型名称、架构标签、权重版本和公开评测信息。

本文主要依据 Inco AI 于 2026 年 8 月 19 日发布的《DFlash 2: Keep Drafting Parallel》官方说明，并结合 DFlash 相关公开论文、推理框架资料和社区测试结果整理。峰值加速数据受模型、硬件、上下文长度、批量和采样设置影响，不应直接视为所有部署环境的固定表现。