DeepSeek DSpark 上线：推理速度涨 85%，但厉害的不是这个

DeepSeek DSpark 上线：推理速度涨 85%，但厉害的不是这个

DeepSeek 6 月 27 日放了一个新东西。

梁文锋署名，联合北大，论文标题《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》，同步开源推测解码框架 DSpark 和训练工具链 DeepSpec。落地到 V4-Pro / V4-Flash 的线上服务，替换了上一代 MTP-1 方案。

三家媒体实测数据对齐：DeepSeek-V4-Flash 单用户生成速度提升 60%-85%，V4-Pro 提升 57%-78%。在系统总吞吐不变、严守交互延迟的前提下达成（来源：智东西、爱范儿、Datawhale 三方交叉验证，2026-06-27）。

但数字不是重点。

重点是 DSpark 的两件套——半自回归草稿 + 置信度调度验证——把推测解码从"草稿写得准不准"这件事，推到了"哪些 token 值得验证"这件事上。

这事改变的不是 DeepSeek 一家的速度曲线，是整个大模型下半场的竞争维度。

---

一、先把「挤牙膏」这件事说清楚

主流大模型是自回归的。

每生成一个 token，都要以前面所有 token 为条件跑一次前向计算。输出越长，延迟越高，GPU 越空。

这就是你打字给大模型，它「一个字一个字蹦出来」的根源。不是它故意装高冷，是计算结构决定了它只能这么干。

推测解码（Speculative Decoding）的思路，是找捷径：

让一个小模型先写一串候选 token，再让目标大模型一次性验证。验证是并行的。通过的 token 全收，第一个被拒的位置后面整串作废，目标模型自己补一个。整个过程数学上严格保证与目标模型逐字生成的结果一致——无损加速，质量不打折。

听着像秘书先拟稿，老板过一遍，对的留下，错的地方老板自己改。

这条路在 2024 年开始被各家盯上。Eagle3（自回归草稿器）和 DFlash（并行草稿器）是两个主流派别。

但 DeepSeek 在论文里点出了一句同行不爱听的话：现有的推测解码方案，已经撞到了天花板。

天花板在两个方向：

第一，自回归草稿器为了压延迟只能做浅网络。 浅了以后第一个 token 的接受率就低，而推测解码是前缀验证，第一个 token 一旦被拒，后面整串作废。论文实测数字：数学任务 0.81，对话任务 0.53。

第二，并行草稿器为了快能做深网络，但 token 之间缺少依赖关系。 上下文同时支持 "of course" 和 "no problem" 两种续写，并行独立预测就可能拼出 "of problem" 或 "no course"——论文里把它叫做 multi-modal collision（多模态碰撞），结果是越靠后的 token 接受率衰减越快，论文叫 suffix decay。

这就是过去两年推测解码卡住的地方：快和准二选一。 要么自回归草稿写得准但写得慢，要么并行草稿写得快但后段崩。

DSpark 说，我要两个都要。

---

二、DSpark 的两件外套

半自回归：给并行草稿补一个"前一个 token"的眼睛

DSpark 的草稿器结构是「并行骨干 + 轻量串行模块」。

并行骨干负责一次前向计算铺开整串候选，这部分和传统并行草稿一样快。

但 DSpark 在输出端加了一个 Markov head——默认只参考紧邻前一个 token，用低秩分解（r=256）把转移关系压得很小。

回到 "of / no" 的例子：第一个位置选 "of" 之后，Markov head 会在下一个位置抬升 "course" 的概率、压低 "problem"，前后就接上了。

代价几乎为零。 论文实测，Markov head 给整轮延迟只增加 0.2%-1.3%。

论文也试过更长的 RNN head，准确率略好，但实现复杂、部署不划算，最终默认还是 Markov head。这是一个工程权衡的胜利，不是论文的胜利。

置信度调度：哪些 token 值得交给大模型验证？

这件事才是 DSpark 的杀招。

过去所有推测解码方案，对一串候选 token 都是「一视同仁全验证」。但在真实的高并发服务里，这事很蠢。

「数学、代码这类结构化任务，答案路径相对明确，候选 token 更容易被接受。开放式聊天不确定性更高，后面的 token 更容易被拒绝。」（Datawhale 拆解 DSpark 论文）

更现实的问题：系统空闲时多验证几个 token 没事，系统繁忙时验证那些大概率会被拒的 token，会占用批处理容量，影响其他用户请求。

DSpark 的做法是置信度调度校验：

根据预估的前缀通过概率 + 引擎当前吞吐特征，为每条请求动态调整校验长度。

容易过的请求多验几个，反正 GPU 闲着也是闲着；难过的请求少验几个，把批处理容量让出来给后面的请求。

这不是算法上的创新，是系统调度上的创新。

这才是值得盯的事。

大模型下半场，从「拼参数」到「拼系统调度」的拐点，DSpark 踩中了第一脚。

---

三、反直觉的发现：并行比自回归更准

论文里有一段很有意思的对比数据。

按直觉，逐字往后写的自回归草稿，应该比各自独立预测的并行草稿更连贯、接受率更高。

实测结果相反。

DFlash（并行草稿）在第一个 token 上的接受率反超 Eagle3（自回归草稿）：

• 数学任务：0.88 vs 0.81
• 对话任务：0.72 vs 0.53

原因有两层。

第一，并行草稿的起草耗时与长度无关，因此网络可以做得更深；自回归草稿为控制延迟只能做浅。

第二，推测解码是前缀验证，第一个 token 一旦被拒、后面整串作废——起点的权重压过一切。

这个反直觉的结论，对所有还在「自回归 vs 并行」之间摇摆的团队是一个响亮的提醒：起点的接受率比全程的连贯性更值钱。

DeepSeek 的选择是：先并行铺开，再用 Markov head 补连贯性，最后用置信度调度控制验证成本。

三层叠加，才有「60%-85%」这个数字。

---

四、为什么 DeepSpec 比 DSpark 本身更重要

DSpark 模型开源是意料之中的事。

但 DeepSeek 同时把训练工具链 DeepSpec 也开源了，MIT 许可——这才是让人多想一步的事。

DeepSpec 是「训练和评估推测性解码草稿模型的全栈代码库」，包含数据准备、草稿模型实现、训练代码、评估脚本。目前支持 DSpark、DFlash、Eagle3 三种草稿模型。

DeepSeek 在仓库里向 SpecForge、DFlash、Qwen3、Gemma 致谢。

这句话信息量很大。

它意味着 DeepSeek 在告诉所有开源社区：你可以用我的工具，给你的 Qwen3、Gemma、甚至任何基座模型，训练一个推测解码草稿器。

这事的战略意义是——

DeepSeek 把「推理加速」这件事，从「我家的独家能力」变成了「全行业的公共能力」。

为什么敢这么做？

两个可能。第一，DeepSeek 已经在训练-推理并重的赛道上领先太多，开源工具链反而能巩固它的「生态枢纽」地位——以后大家做推理优化都按 DeepSpec 的范式来，DeepSeek 就是标准制定者。第二，也是更深一层——独家能力不是工具，是基座模型本身和工程团队的迭代速度。 工具你拿走，我也已经走到下一站了。

无论哪种判断，对开发者来说都是好事：手里突然多了一套生产可用的推测解码训练工具链，可以直接拿来给自己手里的开源模型提速度。

---

五、速度涨 85% 不重要，工程范式变了才重要

回到标题那个判断。

DSpark 让 V4 推理快 60%-85%，这是结果。结果不是重点。

重点是三件事：

1. 大模型竞争从「参数 + 显卡」转向「推理优化 + 系统调度」。 DeepSeek 自己走过的路：V2 的 MLA（压缩 KV Cache）→ V3 的 MTP（多 token 预测）→ V3.2 的稀疏注意力 → V4 的 DSpark（推测解码）。每一步都在「让现有模型跑得更快」而不是「造更大的模型」。这条路线会和「拼参数」路线长期共存，但权重会越来越大——因为算力价格不可能无限下降。

2. 开源推理工具链成为新战场。 DeepSpec 把推测解码的训练门槛打到了 MIT 协议下，下一波受益的是 Qwen3、Gemma、LLaMA 系生态。赢家未必是模型最强的，而是工具链最完整的。

3. 「快」不再是免费午餐。 DSpark 的设计哲学——置信度调度——承认一个事实：算力是有限的。 真正高效的推理系统，要让每一个 GPU 周期都花在「最有可能被接受」的 token 上。这和云计算时代的资源调度逻辑一模一样。

6 月 27 日，DeepSeek 放的不是一次小更新，是一整套关于「未来三年大模型竞争怎么打」的方法论。

至于 85% 这个数字本身——

数字会过期，方法论不会。

---

参考来源

1. 智东西：梁文锋署名论文！DeepSeek 首轮融资后大动作：生成速度大涨 85%（2026-06-27）
2. 爱范儿：DeepSeek 突然发布 DSpark，让 AI 的回答不再「挤牙膏」（2026-06-28）
3. Datawhale：刚刚，DeepSeek V4 新成果发布，推理速度更快了！（2026-06-27）
4. 量子位：DeepSeek V4 更新 DSpark，推理速度提升 80%（2026-06-28）
5. DSpark 论文：https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf
6. Hugging Face：https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark
7. DeepSpec GitHub：https://github.com/deepseek-ai/DeepSpec