你让本地 AI 写一大段代码，它通常像一个谨慎的打字员：算出一个词，再算下一个词。显卡明明很忙，输出仍要逐字等待。DFlash 2 想改掉这套节奏。它先并行猜出一段草稿，再交给主模型一次核验，并通过一个轻量的“选路器”让这些猜测前后更连贯。如今，Qwen3.8-27B 和 Muse-Glimmer-30B 的草稿模型已经发布，Qwen3.8-27B 也出现了 llama.cpp 与双 RTX 3090 的实测，算法、引擎接入和用户验证由此连成了一条线。
这里的数字需要先划清口径：性能倍数主要来自 Inco AI 官方博客，两份社区测试则使用了不同硬件、量化方式、推理引擎和任务，不能直接横向比较。
从“逐字打草稿”改成“一次铺开”
DFlash 2 属于 speculative decoding（推测解码）路线。做法是让一个较小的草稿模型——负责快速提出候选、但不决定最终答案的辅助模型——先猜若干 token。token 可以粗略理解为模型生成文字时处理的基本片段。随后，主模型一次检查整段候选；猜中的留下，猜错的丢掉。最终输出仍由主模型决定。
传统草稿模型往往也按自回归方式工作，也就是一个 token 接一个 token 地猜。DFlash 把整段草稿改为单次前向、各位置并行预测。问题也随之出现：每个位置单看都像正确答案，连起来却未必是一句话。好比几个人分别补写一句话里的不同空格，每个人都填得合理，合起来可能不通顺。
Inco AI 给出的数据展示了这个缺口。在草稿块第一个位置，DFlash 排名第一的候选有 85.4% 的概率正确；但如果看前 16 个候选，正确 token 在其中的概率达到 99.5%。也就是说，答案经常已经在候选名单里，只是系统没有挑中它。官方计算的理想上限显示，如果每次都能从前 16 名里选对，平均可接受长度能从 4.27 个 token 提高到 6.79 个。
不重写答案，只挑一条顺路的路径
DFlash 2 的关键不是增加一次完整生成，而是替候选“选路”。它保留每个位置排名前 16 的 token，并为相邻位置的候选两两打分。分数一部分来自草稿模型原本的偏好，另一部分判断当前候选接在前一个候选后面是否合适。每个 token 会被压缩为 256 维表示，再由上下文决定哪些匹配信息更重要。
这些相邻配对仍可一次并行计算，不需要额外运行主干模型或语言模型输出层。最后，系统才沿着已经算好的分数向前走，选出一条连贯路径。官方称，拒绝采样会让最终结果保持目标模型原有的输出分布；不过现有材料没有附上相关论文或证明细节。
Inco AI 的对比中，这个选路器只增加约 200 万参数和 0.6% 延迟开销。在两种测试设置下，平均接受长度分别从 4.27 提高到 4.61、从 3.78 提高到 4.25。官方还称，它比 DSpark 的顺序修正方案少用约 40 倍参数，延迟开销低约 16 倍。直观地说，DFlash 2 发现“从已有答案里挑对”可能比“重新预测一遍”更便宜。
它仍没有解决全部问题。越靠近草稿块末尾，候选本身越容易缺少正确答案。官方把这叫作 suffix decay（后缀衰减）：即使假设每次都能从前 16 名中挑中正确项，命中率也会从第一个位置的 99.5% 降到最后一个位置的 87.8%。选路器只能挑现有候选，不能补回名单中没有的答案。
218 tok/s 是怎样测出来的
官方称，DFlash 2 让每次 verification pass（主模型的一轮核验）多产出超过 20%，而每个生成周期的延迟只增加约 1%；各项基准收益为 16%—25%。在 batch size 1，也就是一次只处理一个请求时，Qwen3.8-27B 搭配 DFlash 2，由 SGLang 推理引擎运行的吞吐量据称达到普通自回归解码的 2.7—3.4 倍。这些结果目前都只有官方信源。
社区测试给出了更贴近日常本地部署的观察。一名 RTX 5090 用户重新编译带有相关 PR 的 llama.cpp 后，长代码生成可短时达到约 200 tok/s；完整单次代码请求平均约 120 tok/s，thinking（模型展开推理过程）则约为 80—90 tok/s。
另一名用户用两张 RTX 3090、定制版 vLLM 和 INT4 量化测试 Qwen3.8-27B。结果是叙事文本解码 120.1 tok/s，代码解码 218.3 tok/s；平均接受长度为 3.35，候选接受率为 47.8%。这正好说明加速效果取决于内容是否容易预测：格式和重复模式较强的代码获益更大，thinking 和叙事文本较低。
这组 218.3 tok/s 并非开箱即用成绩。测试使用 vLLM v0.26.1rc1、定制补丁和自定义修复，也采用特定采样参数。它证明这条路线已经能在消费级旧显卡上跑出很高速度，但不能代表所有双 3090 配置。
为什么值得现在看
我们在 8 月 16 日报道 Qwen3.8-27B 时，已经介绍过 MTP 和推测解码。本次进展的意义，是并行草稿不再只停留在方法发布：Qwen3.8-27B 草稿模型已有多个信源确认，并提供适合本地推理生态的 GGUF 版本；Muse-Glimmer-30B 也发布了草稿模型和 GGUF，不过目前只有单一信源。llama.cpp 和 vLLM 用户则开始交出实际配置与数据。
更重要的是，DFlash 2 把优化重点从“再预测一次”转向“把已经猜到的候选组织好”。如果后续引擎能稳定接入，这类方法可能让本地模型在不改变最终决定者的前提下，更充分地利用显卡的并行能力。
局限与未知
- 加速需要额外显存。RTX 5090 用户的可用上下文长度从约 220k 降到 160k；双 3090 用户称草稿模型占约 13.5 GB，上下文上限约 131k。
- 官方的 16%—25%、2.7—3.4 倍及“输出可证明不变”等主张，尚缺材料中的独立复现实验或证明细节。
- 模型仓库分别出现
z-lab/Qwen3.8-27B-DFlash2与incoai/Qwen3.8-27B-DFlash2命名，现有材料无法确认它们是迁移、镜像还是不同版本。