梁文锋署名的DSpark，看懂这10个点就够了量子位

梁文锋署名的DeepSeek新论文DSpark你可能刷到过了——

单用户速度提升85%、高并发场景有效吞吐翻4倍。

但你真的看懂了吗？

别急，有人替你拆解了一遍。

Fireworks AI的联合创始人兼CTO、PyTorch核心维护者Dmytro Dzhulgakov将整篇论文梳理成了10个概念，从最底层的GPU访存特性讲到最上层的在线自适应调度。

DeepSeek这套方案真正的精髓在于系统工程和模型协同设计。

相关基础思路前人已有提出，难能可贵的是其将各类技术融合为一套自适应完整系统，实现了端到端的显著性能优化。

下面我们就顺着这10个概念过一遍DSpark。

10个概念理解DSpark

批处理解码（Batching in LLM Decoding）

想要搞懂大模型各类推理加速技术，首先要理解GPU一个非常特殊的运行特性：

让GPU同时解码10个token，其实只比解码1个token慢一点点。

卡帕西曾经讲过，原因在于大模型推理的瓶颈不是浮点运算，而是显存带宽，GPU大部分时间花在把模型权重从显存搬到计算核心上。

搬一次也是搬，搬十次也是搬，既然权重已经加载到了缓存里，不如一次搬运、干十件事。

这就是连续批处理：把多个请求的token塞进同一个batch，让每一次显存读取都物尽其用。

理解了这一点，就明白为什么推测解码能奏效，它的本质就是把“猜出来的多个候选token”打包成一个batch送给大模型验证，而验证batch的成本，远低于逐个生成的成本。

推测解码（Speculative Decoding）

大模型生成是自回归的，第N+1个token依赖第N个token的结果，没法直接并行。

但有一种绕路的办法，如果你能「猜」出接下来几个token是什么，就可以把猜出来的候选序列一次性喂给大模型做批量验证。

验证是通过拒绝采样，系统逐个检查候选token，接受最长的正确前缀，在第一个分歧点重新采样一个token。

这套规则在数学上保证输出分布与原模型完全一致，没有任何质量损失。

所以推测解码的本质是用“猜+验”替代“逐字生成”。

猜的环节用小模型可以很快，验的环节进行批量验证可以很高效，所以最终每一步都能往前跳好几个token。

DSpark就是这个方向上的最新进展。

草稿模型（Draft Model）

那怎么猜呢？

最直接的方案是拿一个小模型当“草稿器”。

比如用Qwen 0.8B给Qwen 397B探路，小模型跑得快，把候选序列生成好，大模型只需要做一次前向传播来验证。

通过了就全收，没通过就从分歧点重新来。

这个设计把推理过程分成了两个角色，速度型选手草稿器负责猜，力量型选手目标模型负责判。

二者配合得好，整体速度就能大幅提升。

但要想配合得好，背后需要权衡大量工程取舍，接下来几个概念就是在讲这些取舍。

推测并不免费（Speculation is Not Free）

草稿模型引入了额外开销。

如果草稿器自己跑得太慢，或者一次猜了16个token但只有前3个被接受，那这笔帐就不划算了。

论文给出了一个核心公式来描述实际延迟：

每个token的耗时= （草稿耗时+验证耗时） /被接受的token数τ。

在这个理论下，加速只有三条路可以走，降低草稿耗时（猜得更快）、提高τ（猜得更准）、减少验证浪费（验得更聪明）。

猜得越多不一定越好，因为如果多猜的token大概率被拒绝，它们只会白白占用验证batch的宝贵算力。

所以DSpark的整篇论文，可以理解为同时拉动这三个杠杆的一次系统性尝试。

Eagle与MTP，复用目标模型的内部理解

第一根杠杆，就是优化草稿模型本身的构造。

草稿模型不用从零训一个完整的小模型，有一种更聪明的做法是直接把目标模型最后一层的隐藏状态拿过来，在上面加1–2层Transformer头当草稿器。

这就是Eagle系列和MTP（Multi-Token Prediction）的思路。

△图源：DeepSeek-V3 Technical Report

好处有两个，一个是快，草稿器只有1–2层，计算量极低；

二是准，因为它直接吃的是目标模型的内部理解，也就是最后一层激活值，等于站在巨人肩膀上猜下一步，比从头用小模型独立推理要靠谱得多。

DeepSeek-V3就已经在用MTP做单token推测（MTP-1）。

DSpark论文中所有的加速数字都是跟MTP-1这个基线对比的，也就是说，60%–85%的速度提升是在已经优化过的基础上再叠加的。