#DeepSeek新发布的DSpark有多强#模型时代#
才来得及刷DeepSeek的DSpark，写一个通俗解释。DeepSeek团队在资源节约这个赛道上的创新，可能是独树一帜的。

---

DeepSeek 如何用一个“瞥一眼”的动作，让大模型说话快了85%

2026年6月27日，DeepSeek与北京大学联合发布了一篇技术报告，论文全称“DSpark： Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation”，作者团队超过30人，DeepSeek创始人梁文锋署名末位通讯。同步开源的还有DeepSpec，一个MIT许可的全栈训练框架。这项工作不是新模型，而是让模型生成回答时跑得更快的推理加速模块，装在DeepSeek-V4上，用户感知到的生成速度提升了60%到85%。

一、技术谱系

2022.11 Google Leviathan等人提出投机解码，用小模型打草稿、大模型批量验收，T5上实现2-3倍加速
↓
2024 EAGLE系列：自回归草稿模型，逐token生成，准确但草稿本身耗时
↓
2025.03 EAGLE-3（NeurIPS 2025）：三层特征融合，自回归草稿的当前最优
↓
2026 DFlash（DeepSeek）：并行草稿模型，一次生成整个token块，快但尾部衰减
↓
2026.06 DSpark：并行骨干+马尔可夫头+置信度调度 ← 本文

二、自回归生成：大模型为什么“嘴慢”

大语言模型生成文字的方式，本质上是一个字一个字往外蹦。模型把文字切成最小单位来处理，一个字或半个词算一个token。每生成一个token，都要把整个模型的参数从GPU的显存（可以理解为GPU专用的内存）里读一遍。一个几百亿参数的模型，生成100个token就要读100遍。GPU的计算能力其实大量闲置，瓶颈卡在显存的读取速度上，行话叫“显存带宽”。

这就像一位主编亲自写稿：每个字都经过深思熟虑，质量有保障，但速度实在太慢。

三、投机解码：找个快手先打草稿

2022年底，Google的Leviathan团队想到一个办法：让一个小而快的模型先写一段草稿，大模型一次性批量验收。验收通过的token直接用，没通过的由大模型自己补。数学上可以证明，这个过程不会改变每个位置上各个词被选中的概率，和大模型直接生成完全一致。加速不损失任何质量。

回到编辑部的比喻：主编不再亲自写，而是让实习记者先打草稿，主编只负责审。审一批草稿的时间和写一个字差不多，但一批里可能有好几个字直接过关。

关键指标是“接受长度”，即每轮验收平均能过几个token，这个数字越大，加速效果越好。

四、Eagle3和DFlash：两种打草稿的路线

打草稿有两条路线，各有各的天花板。

Eagle3是自回归路线的代表。实习记者逐句写草稿，每句都回看前一句，所以前后连贯。问题在于，草稿本身也是一个字一个字生成的，草稿写得越长，耗时越多，加速收益被草稿自身的延迟吃掉一部分。

DFlash走另一个方向：5个实习记者同时动笔，每人负责草稿的一个位置，数据在网络中跑一趟（术语叫“前向传播”）就生成整块草稿。速度极快，但5个人互相不知道对方写了什么。第1个位置写了“天气晴朗”，第3个位置可能接了“雨中漫步”。位置越靠后，和前文的一致性越差。论文里把这种现象叫“后缀衰减”（suffix decay），也叫“多模态碰撞”（multi-modal collision）。

这是一个工程上的两难：想让草稿前后连贯就得一个接一个地写，想要速度就得多路并行，但并行意味着放弃token之间的依赖关系。

五、DSpark的半自回归：瞥一眼，就够了

DSpark的核心思路是拒绝二选一。

第一步和DFlash一样：并行骨干网络一次前向传播，就生成整块草稿的基础分数，速度不是瓶颈。

第二步是DSpark的关键动作：在每个位置根据概率选出具体token（这个过程叫“采样”）之前，加上一个轻量级的“马尔可夫头”（Markov head）。这个头只做一件事：看一眼前一个位置实际采样出来的是什么token，然后给当前位置的概率分数加一个修正偏置。

用编辑部的比喻：5个实习记者还是同时动笔，但每人落笔前瞥一眼左边那位刚写完的最后一句话。就这一眼，足以避免“前面写晴天、后面写淋雨”的矛盾。

为什么只看前一个位置就够了？论文尝试过用RNN头（一种能记住更长上文的循环网络结构）来看完整的前文历史，但发现接受率只有微小提升，而计算开销明显增加。马尔可夫头的实现方式是把一个大矩阵拆成两个小矩阵相乘（线性代数里叫“低秩分解”，这里用的秩是256），这样参数量和计算量都压得很低，额外延迟不到总草稿时间的1.5%。论文的实验数据显示，2层的DSpark在接受长度上超过了5层的DFlash。更浅的网络，因为解决了位置间的依赖问题，反而比更深但互不通气的网络准确。

类比有局限：真实模型不是5个独立的人，马尔可夫头的“瞥一眼”是矩阵偏置校正，比人类“瞥一眼”精确得多。这里只是借用来说明“并行为主、轻量串行修正”的架构思路。

六、置信度调度：忙的时候少审，闲的时候多审

DSpark的第二个创新在系统调度层。

草稿里每个token被大模型接受的概率不同。DSpark训练了一个“置信度头”，为每个草稿位置打一个0到1的分数，估计这个token有多大把握能通过验收（统计学里把“有多大把握”叫“置信度”）。为了让这个分数可信，论文用了一种叫“序列温度缩放”（Sequential Temperature Scaling）的校准方法，把校准误差从3%–8%压缩到1%左右。

有了可靠的置信度分数，一个“硬件感知调度器”就可以根据GPU实时负载动态决定每个请求验证多长的草稿。GPU空闲时，多验几个位置，最大化单用户速度；GPU繁忙时，砍掉低置信度的尾部token，把算力留给其他请求。

回到编辑部的比喻，逻辑一样，但DSpark用一个贪心算法在所有并发请求之间全局分配验证资源，目标是系统整体吞吐量最大化。

七、效果和代价

离线基准测试（2026年6月论文数据）：DSpark在Qwen3-4B/8B/14B和Gemma4-12B上，在数学、代码、对话等任务上的平均接受长度（统计学里叫“宏平均”，即各任务先分别算平均再汇总）比Eagle3提升26.7%–30.9%，比DFlash提升16.3%–18.4%。

生产环境数据（DeepSeek自有集群，V4实时流量）：V4-Flash单用户生成速度比之前的MTP-1基线（DeepSeek此前已在用的一种单token预测加速方案）提升60%–85%，V4-Pro提升57%–78%。在服务协议要求每个用户至少达到80 tok/s（即每秒生成80个token，行业术语叫SLA）的条件下，V4-Flash整体吞吐量提升51%。

需要注意几点。第一，MTP-1本身已经是一个加速过的基线，不是未经加速的裸模型，所以60%–85%的提速是在已有优化基础上的增量。第二，论文中出现的661%和406%吞吐量数字，出现在非常严格的SLA阈值下，此时旧基线已接近服务极限，DSpark扩展的是可服务的边界，不是所有部署环境的通用乘数。第三，截至2026年6月底，所有性能数据均为DeepSeek自报，尚无独立第三方验证。

代价方面，论文没有详细披露额外的显存开销和训练成本。DeepSpec框架需要约38TB存储用于训练数据准备，但这是训练阶段的要求，不影响推理部署。

八、论文定位：生产级的系统工程

论文标题用了两个限定词：“Confidence-Scheduled”和“Semi-Autoregressive”。没有用“novel”（新颖）或“breakthrough”（突破），没有宣称理论创新。两个核心贡献，半自回归草稿和置信度调度，都是把已有技术要素重新组合并优化到可以上线的程度。论文花了大量篇幅描述生产环境的部署细节（异步调度、CUDA图兼容性、零开销调度），这进一步说明团队的重心在工程落地。

同步开源的DeepSpec框架包含DSpark、DFlash和Eagle3三种草稿模型的训练代码，兼容Qwen3和Gemma等开源模型。对于没有能力自建推理加速栈的团队来说，这可能比DSpark本身更有价值。它提供的不是一个成品，而是一套可复现的蓝图。

参考文献：Xin Cheng， Xingkai Yu， Chenze Shao et al。， “DSpark： Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation，” arXiv：2606.19348， June 27, 2026. 代码与权重：github.com/deepseek-ai/DeepSpec （MIT License）