DeepSeek两天前开源了DSpark推理加速框架，梁文锋署名。
DSpark已经在V4预览版的在线服务上跑了真实流量，把每个用户感受到的生成速度拉高了60%到85%。
DSpark用半自回归结构和置信度调度两套机制，化解了推测解码长久以来的尾部衰减与算力浪费问题，在Qwen3和Gemma4多个目标模型上稳定超过Eagle3和DFlash。
而刚刚，DeepSeek-V4正式版官宣定档7月中旬，也将受益于DSpark，推理速度大幅提升。
老问题，新瓶颈
大语言模型生成文本是逐字吐的，每个新词都要走一遍完整的前向传播。输出越长，等待越久，GPU利用率也低。在实时对话、多轮Agent等延迟敏感场景里，瓶颈格外明显。
而推测解码(speculative decoding)的思路是，一个轻量级的draft模型先抛出一批候选词，大模型一次性校验整批，按拒绝采样保留最长合法前缀，再补一个bonus token。校验是并行的，接受规则又能精确还原大模型原本的分布，加速不带质量损失。
draft模型怎么设计，决定了快和准的平衡。早期的自回归drafter比如Eagle3，每个位置都依赖前面的采样结果，建模能力强，延迟随块长线性增长，被迫用短块浅网。并行drafter比如DFlash，所有位置一次前向搞定，块长拉到16也不拖慢多少。
问题出在块内依赖上，各位置预测彼此独立。上下文有多种合理续写时，并行drafter可能拼出 “of problem” 或 “no course” 之类的混搭词（“of course” 和 “no problem” 混合），接受率沿块快速衰减，draft和verify的算力都浪费了。
固定块长的校验方式也不聪明。Code类结构化文本接受率高，开放聊天低。系统负载轻时多验几个词几乎免费，负载重时多验一个词就抢占别人的批处理容量。固定阈值在两种极端之间反复吃亏。
DSpark同时瞄准上述两个问题，生成质量补上并行drafter的尾部短板，系统效率让校验长度跟着负载和数据走。
DSpark的两把刀
DSpark架构见下图，整体由两块构成。
目标模型先产出锚点token D，DSpark用重型并行骨干加轻量序列头生成候选EFGH及置信度c1到c4，硬件感知调度器保留EFG并丢弃低置信度的H，目标模型并行校验保留的前缀，E和F接受，G被拒绝触发模型产出修正token G*，进入下一轮。
半自回归生成解决draft质量问题。并行骨干沿用DFlash，单次前向产出所有位置的base logits，块长γ再大也不影响延迟。再接一个轻量序列头注入块内token依赖。
置信度调度校验解决系统效率问题。硬件感知前缀调度器把校验长度选择形式化成全局吞吐最大化问题。
在Qwen3-4B、8B、14B上，DSpark相对Eagle3的宏平均接受长度分别提升30.9%、26.7%、30.0%，相对DFlash提升16.3%、18.4%、18.3%。Gemma4-12B上也保持稳定优势，增益跨模型族通用。
Table 1 主推测解码结果。报告每解码轮的接受长度τ，越大越好。DSpark行在每个benchmark上均为最佳。
表里还有个反直觉现象。并行drafter和半自回归drafter的接受长度往往比纯自回归drafter还高，跟“逐步自回归应该质量更好”的直觉相反。
Figure 2 位置条件接受率结果表明，Qwen3-4B目标模型，按领域平均。自回归drafter(Eagle3)保持稳定或上升，并行drafter(DFlash)出现尾部衰减，DSpark全程稳定高位。
真实流量里跑起来
团队将DSpark和DeepSeek-V4-Flash(preview)以及DeepSeek-V4-Pro(preview)一起co-deployed。
在维持相同总体吞吐量的情况下，相比前一代部署，DSpark 将用户的生成速度分别提升了 60%-85%（Flash）和 57%-78%（Pro）。
Figure 7 横轴是每请求生成速度tok/s/user，纵轴是单GPU总token吞吐。散点是真实用户流量采样，实线是拟合前沿。DSpark相对MTP-1把吞吐与交互性前沿整体外推。
V4-Flash引擎在80 tok/s/user的SLA下，DSpark把聚合吞吐拉高51%。在120 tok/s/user的更严SLA下，MTP-1已经接近运行边界，只能维持很小并发批，DSpark名义上拿到661%的吞吐优势。论文特别说明，那个点主要当作DSpark把可服务交互前沿外推的证据，不当成代表性的乘法加速。在可比的实用吞吐水平下，DSpark把每用户生成速度提升60%到85%。V4-Pro也是同样模式，35 tok/s/user SLA下吞吐提升52%，50 tok/s/user下MTP-1进入低并发区，DSpark拿到406%名义优势，等量系统容量下每用户生成速度提升57%到78%。
把背后的机制拆开看。
负载上升时，动态调度器自动收紧每请求校验长度防止资源争抢。
在V4-Flash并发低于200、V4-Pro并发低于150的常规区间，硬件感知调度器把每请求校验预算从MTP-1的静态2个token扩到约4到6个，每步接受更多token，前沿上的吞吐增益由此而来。
并发继续上升、target算力饱和后，调度器动态收紧预算，平均校验长度随负载平滑下降，低置信度draft token在吃掉关键batch容量前就被剪掉。轻载时把空闲算力榨干，重载时保住关键批容量，部署稳定。
团队也坦承局限。前缀调度器把target侧校验浪费压到最低，draft侧生成初始γ-token块的固定开销无法回收。对天生接受率低的复杂query，draft算力是沉没成本。未来方向是在draft模型里做难度感知的提前退出，让此类请求绕过整块生成。
与DSpark一并开源的，还有用于训练和评估推测解码算法的全栈代码库DeepSpec。DeepSpec训练仓库包含Eagle3、DFlash和DSpark三套drafter的训练代码。社区拿到以上资源，就可以复现和扩展。
V4要来了
官方宣布，DeepSeek V4正式版7月中旬上线，伴随全新的API定价策略。
DeepSeek V4预览版迈入百万上下文普惠时代，V4正式版7月中旬接棒，引入峰谷定价机制，高峰时段（北京时间每日 9：00~12：00，14：00~18：00）价格翻倍。
DSpark把GPU算力利用率顶上去之后，瓶颈从算力总量转向算力调度。
定价调整，可能是因为模型更强、速度更快，将带来访问高峰吗？
参考资料：
https://github.com/deepseek-ai/DeepSpec
https://huggingface.co/collections/deepseek-ai/deepspec
