DeepSeek又变强了：发布DSpark框架 推理速度提升超60%

6月27日，DeepSeek团队联合北京大学发布了一篇名为《DSpark》的研究论文。这项研究聚焦于推测解码（speculative decoding）方向，目标很明确——加速大模型推理。从实测数据来看，效果相当突出：在保持生成文本分布完全无损（Lossless）的前提下，单用户生成速度较现有主流方案最高提升85%。

目前，这个框架已经被部署在DeepSeek-V4-Flash和DeepSeek-V4-Pro的真实线上流量中，直接服务于大语言模型（LLM）的推理加速。另外值得注意的是，DeepSeek的创始人梁文锋也出现在了论文作者名单里。

大模型推理的“速度焦虑”

想要理解DSpark的价值，得先明白大模型推理为什么慢。主流语言模型生成文本时，采用的基本是autoregressive（自回归）方式——每生成一个新token，都需要一次完整的前向传播。推理延迟会随着输出长度线性增长。这也是为什么大模型回复总让人感觉“卡顿”或“慢半拍”。

在实时对话、多轮智能体工作流这类高交互场景下，生成速度直接影响用户体验，同样也决定着GPU利用率。那有没有办法破局？当然有，推测解码（Speculative Decoding）就是一条不错的路径。

大致的思路是：用一个轻量级的草稿模型快速生成若干候选token，然后再由大模型做批量验证。但现有方案各有各的短板。自回归草稿模型是逐token串行生成，质量虽然高，但生成延迟同样随候选长度线性增长；而并行草稿模型虽然能一次产出全部候选，但因为token之间缺少依赖关系，后续候选很容易被大量拒绝，白白浪费计算资源。

DSpark的两把“手术刀”

针对这两个核心瓶颈，DSpark提出了两项互补机制。

第一个是“半自回归生成”架构（Semi-Autoregressive Generation）。

具体来说，DSpark在并行生成主干的基础上，引入了一个轻量级的顺序模块，用来逐token注入前缀依赖信息。可以这么理解：前面用并行方式快速铺开候选，后面再用一个很轻的顺序模块检查相邻token之间的衔接关系。

这个模块提供了两种实现方式——一种是仅依赖前一个token的马尔可夫头，另一种是通过循环状态累积完整前缀信息的RNN头。实验结果表明，只需要两层Transformer深度的DSpark，就能在所有测试领域上超过五层DFlash的接受长度。

第二个是置信度调度验证机制。传统方案的做法是对整段候选无差别校验，结果在高负载时大量算力都被浪费在了那些极有可能被拒绝的尾部token上。

而置信度调度验证机制则可以根据不同请求的成功概率与系统负载，自适应地调整验证长度，从而减少无效计算开销。在离线测试中，这个方法显著提升了可接受生成长度；而在DeepSeek-V4线上系统中，相比基线模型，推理速度提升了约60%–85%，并且有效降低了高并发下的吞吐损耗。

具体到实现，DSpark会在每个候选位置输出一个置信度分数，用来预测该token的存活概率。一个硬件感知的前缀调度器会根据实时引擎吞吐量，为每个请求动态决定最优验证长度，优先把算力分配给预期回报最高的token。

另外，这篇论文还同时开源了模型检查点与训练框架DeepSpec，以便推动社区进一步研究。DeepSpec是一个面向speculative decoding训练的代码库，里面包含了Eagle3、DFlash和DSpark的实现。