最近刷到梁文锋署名的 DeepSeek 新论文 DSpark，数据很猛：

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

但这篇论文真正厉害的地方，不是某一个“神奇算法”，而是把算法、模型、GPU 调度和在线校准做成了一整套工程闭环。

简单说，DSpark 是在解决一个问题：

大模型生成文字太慢，能不能先“猜几个字”，再让大模型一次性检查？

这就是推测解码。

传统大模型是一个 token 一个 token 往外吐，像逐字打字。但 GPU 的特点是：一次处理 10 个 token，并不会比处理 1 个 token 慢 10 倍。

所以思路来了：

先用一个很快的“草稿模型”猜后面几个 token，再让大模型批量验证。猜对的直接收下，猜错的从分歧点重新生成。

关键是：输出质量不变，只是速度变快。

但问题也很现实：

猜得多不一定赚。

如果草稿模型猜 16 个 token，最后只对 3 个，那后面 13 个就是浪费算力。

所以 DSpark 做了几件事：

1. 不是随便拿小模型乱猜

它复用目标大模型内部的隐藏状态，再加轻量草稿头来预测。相当于站在大模型“理解”的基础上猜，速度快，也更准。

2. 不完全串行猜

传统草稿模型要一个 token 一个 token 猜，还是慢。DSpark 借鉴 DFlash 思路，一次性并行产出多个候选位置。

3. 解决“越往后越不准”

纯并行会有问题：每个位置独立预测，后面的 token 容易拼歪。比如单看都合理，连起来却很别扭。DSpark 加了轻量顺序头，让后面的 token 能参考前面的结果。

4. 串行修正很便宜

它没有重新做复杂注意力计算，而是用很轻的马尔可夫头修正概率。草稿长度从 4 扩到 16，额外延迟只增加 0.2%–1.3%，但接受长度最高能提升 30%。

5. 动态决定猜几个

代码生成规律强，可以多猜；开放聊天不确定性高，就少猜。GPU 空闲时多猜没关系，高并发时就要省算力。DSpark 会根据请求类型和硬件负载动态调整验证长度。

6. 边跑边校准

模型通常会“过度自信”，觉得自己猜得都对。DSpark 会在线观察真实接受率，动态调整置信度阈值。代码任务多了，就对代码草稿更宽容；聊天任务来了，就自动收紧。

我觉得 DSpark 最值得关注的点是：

它不是单点创新，而是系统工程能力的体现。

很多基础思路以前就有，但 DeepSeek 把它们组合成了一套能落地、能自适应、能端到端提速的方案。

这也是为什么它能在已经优化过的 MTP-1 基线上继续做到 60%–85% 的速度提升。

一句话总结：

DSpark 的核心不是“让模型更聪明”，而是让模型推理过程更会省力。

对于大模型推理来说，未来拼的不只是参数量，也会越来越拼工程调度、硬件利用率和系统协同设计。