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

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

但你真的看懂了吗？

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

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

他认为：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

那怎么猜呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

但 Eagle/MTP 的问题在于，要生成 N 个候选 token，就得跑 N 步，第 2 个 token 依赖第 1 个的输出，第 3 个依赖第 2 个……串行的链条没法打破。

DFlash 的思路是借鉴扩散模型的做法，一次前向传播就把全部 N 个候选位置同时产出。

速度确实快，但代价是各位置之间没有依赖关系。开头几个 token 可能很准，因为上下文信息充足，但越往后越拉胯。

论文管这个问题叫多模态碰撞。

举个例子，位置 1 采样出 "of"，位置 2 独立采样出 "problem"，各自看概率都合理，拼在一起就变成了 "of problem" 这种不通顺的组合。

位置越靠后，这种跑偏的概率越大，接受率急剧下滑。

这就是所谓的后缀衰减（suffix decay），也是纯并行方案在实际部署中加速效果打折的主因。

DSpark 的核心创新，用一句话说清就是把并行和串行拼在一起，各取所长。

具体做法分两步。第一步，用 DFlash 的并行骨干网络一口气生成所有位置的基础 logits，这一步负责速度。

第二步，用一个轻量级的顺序头从前往后逐个位置注入前缀依赖偏置，这一步负责修正后缀衰减。

用上面的例子来看，效果是：

位置 1 采样出 "of" 之后，顺序头会把位置 2 的概率分布往 "course" 方向推，同时压低 "problem" 的概率。

并行骨干保证了整体速度不拖后腿，顺序头保证了后半段的接受率不崩盘。

在论文的离线测试中，DSpark 的平均接受长度比 Eagle3 高 26% – 31%，比 DFlash 高 16% – 18%。

两层 DSpark 甚至打得过五层 DFlash。

既然第二步要加一个顺序头，那它的成本不就把第一步省下来的时间又吃回去了吗？

DSpark 的回答是：不会，因为并行骨干已经把上下文信息编码好了，串行步骤不需要再做完整的注意力计算，只需要做极轻量的修正。

默认方案是一个马尔可夫头，它只看前一个 token 就决定当前位置的修正方向，通过低秩分解（rank 256），即使词表有十几万个 token，计算成本也几乎可以忽略。

实测数据就很能说明问题，草稿长度从 4 扩展到 16，每轮额外增加的延迟只有 0.2% – 1.3%，但接受长度最高提升了 30%。

论文里还提供了一个 RNN 头的可选方案，可以追踪整个草稿块的前缀信息，但实际增益有限，所以默认没有开启。

这也体现了 DSpark 的工程审美，不是越复杂越好，而是找到成本和收益的最优折中。

那每次应该猜几个 token 呢？这个问题没有固定答案。

首先，不同类型的请求天然不同。

代码生成的可预测性高（语法模式强），草稿器猜 8 – 16 个 token 可能都能过审；开放式闲聊不确定性大，猜 4 个就可能翻车。

其次，服务器的实时负载也在变化。

GPU 空闲时，多猜几个 token 没什么额外成本，反正算力闲着也是闲着；高并发时，每一块验证 batch 的算力都很金贵，不该浪费在大概率被拒绝的尾部 token 上。

于是 DSpark用一个置信度头给每个草稿位置打分，预估它在验证中存活的概率。

这套方案会预先测算 GPU 在各类批次尺寸下的硬件吞吐数据，生成吞吐量参考曲线，再依据曲线结果为每条请求动态匹配最优验证长度。

整套调度逻辑完全在 GPU 内部执行，无需 CPU 参与，虽然实现门槛极高，但该方案已经落地了。

接下来，就是最后一块拼图，在线草稿置信度校准。

置信度头的思路很好，但有一个实际问题是" 神经网络天生过度自信 "。

它觉得自己猜的每个 token 都对，这就会导致原始置信度评分不可靠，该停的时候不停，该放手的时候死撑。

如果直接用模型输出的概率设阈值，系统表现会跑偏。

DSpark 的做法是在运行时持续观察草稿器的实际表现。

论文中使用顺序温度缩放做后处理校准，把预期校准误差从 3% – 8% 压到了约 1%。

更关键的是，这个校准过程是在线的，系统边跑边调，根据当前工作负载的实际接受率动态修正阈值。

代码任务跑多了，它就学会对代码草稿更宽容；聊天任务来了，它自动收紧阈值。

越跑越准，真正做到了自适应。

这 10 个概念单独拎出来，大部分确实算不上全新，但整套方案完成了算法、调度、硬件适配三位一体的端到端工程闭环。

而且 DeepSpec 全栈训练库一并开源，Eagle3、DFlash、DSpark 三种草稿模型的训练代码全部放出，支持 Qwen3 和 Gemma 等外部模型——

你想给自己的模型训一个草稿器，直接拿过去改就行。

DSpark 配套的 DeepSpec 库目前在 GitHub 已经拿下 1.4k Star，各路开发者都开始实操内卷。

海外大佬看完论文火速掏出两块 RTX PRO 6000 在家折腾 DSpark。