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的具体实现。