投机解码不是新概念，但真正能在大模型上跑出 4.3 倍吞吐的方案凤毛麟角。Z Lab、Modal 和 SGLang 团队联合放出的 DFlash 模型配合全新的 Spec V2 引擎，把这件事从论文里拽了出来——基于 Qwen 3.5 397B-A17B（BF16）的实测数据显示，DFlash 在 HumanEval 数据集、并发 1 的条件下，吞吐量直接打到了基线的 4.3 倍。这不是某个研究机构关起门来的 toy demo，而是已经写进 SGLang 默认推理管线的工程级方案。
DFlash 到底快在哪
块扩散：把 draft token 一次性吐出来
传统投机解码走的是「自回归」路线——草稿模型老老实实一个 token 一个 token 地猜，再让目标模型并行验证。问题显而易见：草稿阶段本身就是串行的，模型小也救不回来。DFlash 换了一个完全不同的思路，用块扩散（block diffusion）来生成 draft token。所谓块扩散，就是一次性把整块候选 token 全部生成出来，块内的 token 之间相互依赖但并行解码。配合 KV 注入技术，前一块生成时缓存的 Key-Value 状态直接喂给下一块，省去了重复的前向计算。对推理引擎来说，这相当于把「猜一个、验一个」的循环变成了「猜一整块、验一整块」，草稿阶段的延迟被压到了接近单步前向的水平。
KV 注入：被低估的杠杆
很多人低估了 KV 注入在块扩散里的作用。直觉上，块内 token 互相 attention 时，每个位置都要看到块内其他 token 的信息——如果从头算，这部分开销会吃掉并行带来的所有收益。DFlash 的处理方式很聪明：在生成当前块时，把已经生成的前缀 KV 直接注入注意力上下文，块内只用算增量部分。这样一来，块大小可以拉到 8、16 甚至 32，吞吐量随块大小近似线性增长，而不会因为注意力计算量爆炸而崩盘。Modal 团队在工程化这块下了不少功夫，最终让 DFlash 在 397B-A17B 这种规模下依然能稳定跑出 4.3 倍的数字。
和传统方案的代差
把 DFlash 摆到 Medusa、EAGLE、Lookahead 这一票投机解码方案旁边看，差别非常明显。Medusa 依赖多个并行的解码头，本质还是逐 token 生成；EAGLE 用轻量级自回归模型做草稿，训练成本高、泛化差；Lookahead 的 Jacobi 迭代在长序列上不稳定。DFlash 的块扩散加 KV 注入组合，训练目标是直接优化块级似然，草稿阶段完全并行，验证阶段复用目标模型的完整注意力——这意味着同一个 DFlash 模型可以服务不同的目标模型，工程复用度高出不止一个量级。
SGLang Spec V2 引擎：把 4.3 倍变成默认体验
为什么需要专用引擎
块扩散生成长度不固定，draft 阶段的输出长度依赖置信度阈值和块大小——这跟传统投机解码的「固定 draft length」完全不同。SGLang 的 Spec V2 引擎专门为这种动态性重新设计了调度器：草稿模型和目标模型之间的握手协议从「等够 N 个 token 再验证」改成「块就绪即验证」，CUDA graph 重捕获的频率也跟着块大小自适应调整。换句话说，引擎不再假设草稿阶段的延迟是常数，整个推理图被重新画了一遍。
实测数据的含金量
4.3 倍这个数字看起来简单，背后有几个细节值得展开。第一，测试用的是 BF16 精度的 Qwen 3.5 397B-A17B，不是量化后的轻量模型，硬件门槛对得起真实生产环境。第二，HumanEval 是代码生成任务，token 分布偏长且结构化，对草稿质量要求极高——DFlash 能在这个数据集上跑出 4.3 倍，说明块扩散的草稿命中率没有被长序列拖垮。第三，并发 1 意味着单请求场景，这是推理服务里最敏感、也最难优化的工况，批处理优势在这里几乎用不上。
从默认引擎看工程信号
DFlash 已经被设为 SGLang 的默认 Spec V2 引擎，这件事的分量比吞吐量数字本身更重。开源推理框架的「默认」二字意味着维护团队认为它在通用性、稳定性和性能之间找到了平衡点——不是实验室里跑分漂亮、放到生产就崩的玩具。对部署工程师来说，这意味着不需要手动调参、不需要自己写验证逻辑，直接升级 SGLang 就能拿到加速。这种「开箱即用」在推理优化领域是稀缺品。
谁该立刻关注这个组合
自托管大模型的团队
如果你正在用 vLLM、TGI 或者 SGLang 自托管 Qwen 3.5 或者同架构 MoE 模型，DFlash + Spec V2 是一个几乎零成本的升级路径。推理成本直接砍到原来的四分之一左右，意味着同样的 GPU 预算可以多服务四倍的用户，或者把单请求延迟压到原来的四分之一。对于 To C 聊天产品、代码助手 API 以及企业内部知识库这类对延迟敏感的场景，这个数字足以改变商业模型。
推理服务供应商
对于 Modal、Anyscale、Fireworks 这类做推理服务的厂商，DFlash 的工程复用度才是真正的杀手锏。一个训练好的 DFlash 草稿模型可以服务多个不同规模的目标模型，不需要为每个目标模型单独训练草稿头。在过去，自研投机解码方案往往是头部云厂商的护城河，现在开源社区拿出了可比的方案，护城河正在被填平。
还在用 Medusa 的项目
如果你之前的项目基于 Medusa 或者 EAGLE 做投机解码加速，现在是认真评估迁移成本的时候了。块扩散的优势在长序列和结构化输出上尤其明显——代码生成、JSON 输出、工具调用这些场景正是当前 LLM 应用的主战场。4.3 倍的基线差距不是靠调参能追平的，更可能是架构层面的代差。
几个需要冷静看待的点
4.3 倍不是万能数字
DFlash 在 HumanEval、并发 1、BF16 精度下跑出 4.3 倍，但这个数字不能直接外推到所有场景。短文本对话、数学推理、纯英文闲聊——这些任务的 token 分布和结构化程度差异巨大，草稿命中率会有波动。在高并发批处理场景下，目标模型的计算会被摊薄，投机解码的边际收益也会下降。真实部署前，最好在自有业务数据上做一轮 benchmark。
草稿模型的训练门槛
DFlash 的训练目标是块级似然，需要在目标模型的语料上做大规模蒸馏。对于没有充足算力和数据的小团队来说，自己训练一个适配特定目标模型的 DFlash 并不轻松。好消息是 Z Lab 和 Modal 已经在 Hugging Face 上放出了 Qwen 3.5 397B-A17B 的预训练版本，直接下载就能用。如果未来能覆盖更多主流模型（Llama、Mistral、DeepSeek 系列），这个生态才算真正完整。
Spec V2 引擎的兼容性窗口
SGLang Spec V2 是为 DFlash 量身定制的，对其他投机解码方案的兼容性需要时间验证。社区里仍然有大量项目跑在 vLLM 或者 TGI 上，DFlash 要真正铺开，还需要这些框架的原生支持。目前看来，SGLang 的工程社区响应速度足够快，但跨框架适配仍需至少几个月的时间窗口。
把视角拉远一点
DFlash + Spec V2 的组合，本质上是把推理优化从「模型压缩」和「硬件加速」之外的第三条路——算法层面的并行化——推到了一个新的高度。块扩散不是 DFlash 独创，但把它和投机解码结合并工程化到生产可用的程度，是这次发布真正的价值所在。当推理成本从「卡脖子」变成「可优化」，整个 LLM 应用的经济模型都会被重新写一遍。部署工程师们，是时候把这个组合放进你的工具箱了。
