Datawhale干货
最新发布： DeepSeek、北京大学
这次接入的是一套投机解码（Speculative Decoding）框架 DSpark，同时开源了配套的训练框架 DeepSpec，论文由 DeepSeek 和北京大学合作完成。
最近用 V4 的人应该能感觉到，出字速度比之前快了，尤其在并发不高的时候，这就是 DSpark 带来的变化。它已经部署在 V4 的 Flash 和 Pro 两个版本的线上流量中，替换了上一代的 MTP-1 方案。
需要说明的是，DSpark 不是一个全新架构的模型，而是在 V4 的基础上加了一个推测性解码模块。这次更新的重点在工程落地，而不是模型能力本身的迭代。
DeepSeek 在推理效率上一直投入较多：V2 的 MLA 压缩了 KV cache，V3 引入了 MTP（多 token 预测），V3.2 换用稀疏注意力。DSpark 是这条线上的最新一步，也是第一次直接用在主力产品上。
报告链接：https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf
这篇新成果换了个角度去看推理速度这个问题：
投机解码卷了两年「草稿写得多不多、准不准」DSpark 把矛头指向了被忽略的另一件事情：验证。
先说清楚：投机解码在做什么
大模型生成文字是逐字进行的：每生成一个 token，都要把前面的内容完整计算一遍。输出越长越慢，GPU 利用率也低。
投机解码（Speculative Decoding）是解决这件事的标准思路：用一个又小又快的「草稿模型」一次预测出后面若干个 token，再由完整的「目标模型」并行验证这一批，接受其中正确的前缀，遇到第一个错误就丢弃后面全部。
打个比方，就像秘书先拟好一段话，老板快速过一遍，对的留下，错的地方自己改。关键在于，验证是并行的，而且能在数学上保证结果和目标模型逐字生成完全一致。所以它是无损加速，质量不打折。
草稿模型怎么造，是性能的关键。过去主要有两条路线：
自回归草稿（代表 Eagle3）：逐个 token 往后预测，每个都基于前一个。准确率高，但起草耗时随长度线性增长，只能写短、网络也只能浅。
并行草稿（代表 DFlash）：一次前向就预测出整串 token，耗时几乎与长度无关，可以写得很长。缺点是各位置独立预测、彼此不知道对方的结果，越往后越容易前后不一致。
并行草稿的这个缺点有个形象的例子：上下文同时支持 "of course" 和 "no problem" 两种续写，独立预测就可能拼出 "of problem" 或 "no course"。论文把它称为 multi-modal collision，结果是越靠后的 token 越容易被拒，接受率快速衰减。
DSpark 做的两件事，正好一件针对草稿，一件针对验证。
创新一：半自回归，给并行草稿补上「顺序」
前面说过：并行快但尾部不连贯，自回归连贯但慢，过去只能二选一；而 DSpark 想两个都要。
DSpark 的做法是：繁重的计算仍由并行骨干一次完成，再在后面接一个轻量的串行模块，专门补上「前一个 token」的信息，把连贯性补回来。
这个串行模块默认采用 Markov head：只参考紧邻的前一个 token，用低秩分解（r=256）把转移关系压得很小，几乎不增加计算量。回到刚才的例子：一旦第一个位置确定是 "of"，它就会在下一个位置提高 "course" 的概率、压低 "problem"，前后就接上了。
论文也试过记忆更长的 RNN head，效果略好，但实现复杂、部署不划算，最终默认还是 Markov head。
代价很小。后面会看到，这个串行模块给整轮延迟只增加 0.2%–1.3%。
一个反直觉的发现，并行比自回归更准
按直觉，逐字往后写的自回归，应该比各自独立预测的并行更连贯、接受率更高。
但论文的实测结果相反：并行草稿反而更准。
原因有两层。
第一个 token，并行天然占优。并行草稿的起草耗时与长度无关，因此网络可以做得更深；自回归为了控制延迟只能做浅。结果在第一个位置上，DFlash 的接受率反而高于 Eagle3（数学 0.88 对 0.81，对话 0.72 对 0.53）。而投机解码是前缀验证，第一个 token 一旦被拒、后面整串作废，所以起点的权重最高。
越往后，独立预测的短板才显现。位置 2 到 7，DFlash 持续衰减（代码从 0.87 降到 0.78，对话从 0.72 降到 0.63）；自回归则能保持甚至回升（对话从 0.53 升到 0.74）。
DSpark 要的就是两者之长：用深并行骨干拿下高起点（数学第一位达到 0.93），再用轻量串行模块补平尾部的衰减。
这套组合还很省参数。
草稿写得越长，优势越明显。
创新二：让验证也能动态调度
前面都在改进草稿，论文的另一个核心创新在验证。
草稿能写得很长，是不是就该整串都验证？答案是否定的。
在高并发的线上环境里，验证并不免费。多验证一个大概率会被拒的 token，就会占用目标模型这一批的算力，而这部分算力本可以用来服务其他正在等待的请求。负载低时影响不大，负载一高就是明显的浪费。
DSpark 的第一步，是为每个草稿位置配一个置信度头（Confidence Head），预测该 token 通过验证的概率。
仅仅是判断该不该验证尾部 token，这一步的作用就已经很明显。
不过要让置信度真正用于调度，还差一步。
调度需要的不是「哪个 token 更有把握」的排序，而是存活概率的绝对值：数值准确，才能算出该验证多长。神经网络给出的置信度通常偏乐观，所以论文又加了一道称为 STS 的事后校准，把预测概率拉回真实接受率，同时不改变原有排序。
有了可靠的存活概率，最后一步才是核心：一个硬件感知调度器（Hardware-Aware Prefix Scheduler），根据当前负载动态决定每个请求验证多长。
在真实环境里，到底快了多少
先看离线评测。在 Qwen3 的 4B/8B/14B 和 Gemma4-12B 四个目标模型上，DSpark 全面超过自回归的 Eagle3 和并行的 DFlash。
具体来说，平均接受长度相比 Eagle3 提升 26.7%–30.9%，相比更强的 DFlash 也有 16.3%–18.4%。
数据里还有一条规律：结构化任务（数学、代码）的接受长度天然高于开放对话。以 Qwen3-4B 为例，数学三项平均 5.57、代码 5.12，对话只有 3.49。这正好解释了固定长度验证为什么是浪费：对话里那些大概率被拒的尾部 token，本就不该花算力去验。这也是上一节动态调度的意义所在。
论文更重要的部分，是真实的生产环境数据。
结论是：在吞吐量持平的前提下，V4-Flash 上每个用户的生成速度提升 60%–85%，V4-Pro 上提升 57%–78%。
另一个场景更关键。当对单用户速度要求非常严格时（例如 120 tok/s/user），上一代 MTP-1 已接近极限、只能服务很少的并发，DSpark 仍能维持。
此时两者的相对吞吐差距可达 +661%。论文也强调，这个数字更多是说明 DSpark 把可用的交互档位往外扩展了，而不是真有六倍提升。
它是怎么做到的？看负载自适应这张图。
简单说，就是闲时多验证、多接受，忙时收紧，把算力优先留给真正在排队的请求。
写在最后
论文也讲了短板：DSpark 再省，起草的成本仍然省不掉。并行骨干生成第一块草稿是固定开销，遇到本身就难、接受率很低的复杂请求，这部分前期投入收不回来。团队给出的后续方向，是让草稿模型也能按难度提前停下。
总体看，这是 DeepSeek 在推理加速上的又一步，而且第一次直接落到了 V4 主力产品上。
祝各位「源神」们用得快乐！
