梁文锋亲自署名！DeepSeek发布DSpark，大模型推理一口气提速85%

DSpark 深度技术解读

一、引言：不拼参数，拼速度

2026年6月27日，DeepSeek联合北京大学发布了一篇题为《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》的论文。紧随其后，DeepSeek开源了DSpark推理加速框架及配套的全栈工具DeepSpec。

这不是一个新模型。DeepSeek-V4-Pro-DSpark和DeepSeek-V4-Flash-DSpark并非全新架构，而是在原有模型基础上引入了推测解码模块。此次更新的重点在于工程落地，而非模型能力本身的迭代。

然而，正是这种“工程落地”的思路，让DSpark在上个周末引爆了AI圈：

• • 在DeepSeek-V4-Flash上，单用户生成速度提升 60% - 85%
• • 在DeepSeek-V4-Pro上，单用户生成速度提升 57% - 78%
• • 在高并发场景下，有效吞吐量提升达4倍

值得注意的是，DeepSeek创始人梁文锋位列论文作者名单。在完成首轮约500亿元融资后，创始人依然亲自参与技术论文撰写，这在AI行业并不多见。

本文将从底层原理到工程实现，尝试拆解DSpark的技术架构。

二、背景：大模型为什么“慢”？

2.1 自回归生成的根本瓶颈

大语言模型生成文本时采用自回归（Autoregressive） 方式：每生成一个新token，都需要一次完整的前向传播。这意味着：

生成N个token = N次完整模型前向计算

推理延迟随输出长度线性增长。这就是AI回答“挤牙膏”的根本原因。

2.2 GPU的“搬砖”特性

要理解DSpark为什么有效，首先得理解GPU的一个特殊运行特性：

让GPU同时解码10个token，其实只比解码1个token慢一点点。

原因在于，大模型推理的瓶颈不是浮点运算，而是显存带宽。GPU大部分时间花在把模型权重从显存搬到计算核心上。搬一次是搬，搬十次也是搬——既然权重已经加载到了缓存里，不如一次搬运、干十件事。

这就是连续批处理（Continuous Batching） 的核心思想：把多个请求的token塞进同一个batch，让每一次显存读取都物尽其用。

2.3 推测解码：一个优雅的“作弊”方案

既然验证多个token的成本接近验证一个token，那能不能让模型一次性验证多个token？

这就是推测解码（Speculative Decoding） 的核心思路：

1. 1. 打草稿：用一个轻量级的“草稿模型”（Draft Model）快速生成一串候选token
2. 2. 批量验证：把整串候选token一次性喂给目标模型（Target Model）做并行验证
3. 3. 接受与修正：通过拒绝采样，逐个检查候选token，接受最长的正确前缀，在第一个分歧点重新采样

这套规则在数学上保证输出分布与原模型完全一致，没有任何质量损失。

推测解码的本质是用“猜+验”替代“逐字生成” 。猜的环节用小模型可以很快，验的环节用批量验证可以很高效——所以每一步都能往前跳好几个token。

三、现有方案的困境

推测解码并非DSpark首创。但现有主流方案各有各的短板。

3.1 自回归草稿模型（如Eagle3）：“老实人”打法

草稿模型也一个字一个字地猜，猜完一个、看一眼前文、再猜下一个。

• • 优点：依赖关系建模能力强，候选质量高，接受率高
• • 缺点：草稿耗时随候选长度线性增长，只能使用短候选块和浅层网络

草稿模型自己写草稿时也要一步一步来，候选token越多，草稿阶段越慢。速度跟大模型自己写都差不多了。

3.2 并行草稿模型（如DFlash）：“一口气”打法

不管三七二十一，一次性把后面所有字全猜出来。

• • 优点：单次前向传播即可生成全部候选，生成延迟几乎与候选长度无关
• • 缺点：并行生成每个位置时无法依赖块内先前已采样的token，导致后缀接受率迅速衰减

论文里举了一个很直观的例子：模型面对某个上下文时，可能同时存在“of course”和“no problem”两种合理续写。并行草稿模型因为没有真正按顺序生成，很容易把两条续写路径混在一起，生成“of problem”这种前后不一致的组合。

开头几个token往往还不错，但越往后，被接受的概率下降越快——论文把这种现象称为 “后缀衰减”（Suffix Decay） 。

3.3 更现实的问题：盲目验证

在高并发生产环境中，固定长度的验证策略会迫使目标模型将宝贵的批量处理能力消耗在高拒绝风险的尾部token上。

猜得越多不一定越好——如果多猜的token大概率被拒绝，它们只会白白占用验证batch的宝贵算力。

四、DSpark的核心创新

DSpark针对上述两个瓶颈，提出了两项互补机制。

4.1 创新一：半自回归生成（Semi-Autoregressive Generation）

4.1.1 设计思想

DSpark的思路非常聪明：不抛弃并行，但加上一个轻量的“依赖注入”模块。

具体架构分为两层：

1. 1. 并行主干网络（基于DFlash改进）：一次性产出全部候选位置的隐藏状态和基础logits
2. 2. 轻量级顺序模块：逐token注入前缀依赖信息

这个顺序模块提供两种实现：

• • 马尔可夫头（Markov Head） ：仅依赖前一个token
• • RNN头：通过循环状态累积完整前缀信息

4.1.2 架构图

4.1.3 效果数据

实验数据非常直观：

• • 在Chat任务上，DFlash的条件接受率从位置1的0.72衰减到位置7的0.63
• • DSpark全程维持在高位且几乎不掉

更令人惊喜的是：仅2层的DSpark，性能已经超过了5层的DFlash。少量自回归依赖的引入在参数效率上远优于单纯堆叠并行层。

草稿长度从4扩展到16，端到端延迟只增加了0.6%-1.3%，但接受长度提升了30%。

4.2 创新二：置信度调度验证（Confidence-Scheduled Verification）

如果说半自回归生成解决的是 “猜得准” 的问题，那么置信度调度验证解决的是 “验得聪明” 的问题。

4.2.1 置信度估计头

DSpark额外训练了一个置信度估计头（Confidence Head） ，对每个草稿token预测一个 “前缀存活概率” ——即如果前面的token都通过了验证，这个位置的token还能活下来的概率是多少。

4.2.2 顺序温度缩放（STS）校准

光有概率还不够，因为神经网络天生会过度自信。DeepSeek引入了一个叫 “顺序温度缩放（Sequential Temperature Scaling，STS）” 的校准方法，把预测概率和真实接受率对齐。

校准效果：平均校准误差从 3%-8% 压到了约 1% 。

4.2.3 硬件感知前缀调度器

这是整个系统最精妙的部分。

传统的推测解码会盲目地把生成的草稿token全部送去验证。在高负载时，那些极大概率会被拒绝的尾部token会严重浪费宝贵的批处理算力。

DSpark的调度器将验证长度选择建模为全局吞吐量最大化问题：

输出

硬件感知前缀调度器

输入

并发请求队列

各位置置信度分数

引擎吞吐量曲线预先实测

全局吞吐量最大化

动态决定每个请求的验证长度

轻载: 验证4-6个token

高并发: 自动收缩

调度器的核心逻辑：

将算力只分配给预期回报最高的token

具体来说，给定一批并发请求及其各位置置信度，结合预先实测的引擎吞吐量曲线，调度器为每个请求动态决定验证多长的候选前缀。

实际效果：

• • 轻负载时大胆多验证（从MTP-1固定的2个token动态扩展到4-6个）
• • 高并发时果断剪掉低置信后缀

4.2.4 一个重要的数学约束

这套机制有一个必须解决的难题：不能提前偷看未来token，否则会破坏无损推测解码的理论保证。

论文附录专门给出了反例证明——一旦放开这个约束，输出分布就会漂移，不再等价于大模型的真实分布。DSpark的调度器利用前两步的历史预测来决定当前的动态截断长度，从而在保证理论正确性的前提下实现自适应调度。

五、核心公式与理论分析

5.1 推测解码的加速公式

推测解码加速的核心公式为：

其中：

• • ：每个token的平均耗时
• • ：草稿生成耗时
• • ：目标模型验证耗时
• • ：平均被接受的token数

在这个理论框架下，加速只有三条路可以走：

1. 1. 降低 （猜得更快）
2. 2. 提高 （猜得更准）
3. 3. 减少验证浪费（验得更聪明）

DSpark在三条路上都有突破：

• • 降低 ：并行主干网络单次前向生成全部候选
• • 提高 ：半自回归架构抑制后缀衰减
• • 减少验证浪费：置信度调度动态裁剪低置信后缀

5.2 半自回归的数学表达

设并行主干网络生成的基础logits为 ，顺序模块注入的依赖信息为 ，其中 。

最终草稿token的采样概率为：

其中 是控制依赖强度的超参数。

马尔可夫头（）和RNN头（）是两种不同的 实现。

5.3 置信度调度的优化目标

设第 个位置的置信度为 （校准后与经验接受率对齐），引擎在批大小 下的验证延迟为 。

调度器的优化目标是：

即在给定验证长度 下，最大化期望有效接受长度与验证延迟的比值。

这是一个在线优化问题——调度器根据实时系统负载动态调整 。

六、性能数据

6.1 离线基准测试

研究团队选取了Qwen3系列（4B/8B/14B）和Gemma4-12B作为目标模型，在数学推理（GSM8K、MATH500、AIME25）、代码生成（MBPP、HumanEval、LiveCodeBench）和日常对话（MT-Bench、Alpaca、Arena-Hard）三个领域进行测试。

核心结果：

DSpark在全部目标模型、全部评测领域下稳定超越两大基线。

6.2 线上生产实测

在DeepSeek-V4的真实线上流量中，相比此前的生产基线MTP-1：

更关键的是，在严格交互时延约束下，DSpark避免了吞吐率大幅滑坡，推高了整套服务系统的帕累托最优边界。

6.3 领域差异

论文实验数据还揭示了一个显著的领域差异效应：

结构化任务（数学、代码）的可接受长度天然更高，而开放式对话场景明显偏低。这也意味着DSpark在代码助手、数学解题等场景下的加速效果最为显著。

七、DeepSpec：全栈开源工具链

随DSpark一同开源的还有 DeepSpec，这是一个用于训练和评估推测解码草稿模型的全栈代码库。

7.1 核心功能

DeepSpec包含：

• • 数据准备工具：下载提示词数据，使用推理引擎对目标模型重新生成答案，构建目标缓存
• • 草稿模型实现：内置DSpark、DFlash、Eagle3三种实现
• • 训练代码：针对缓存的目标输出训练草稿模型
• • 评估脚本：在基准任务上衡量推测解码的接受程度

7.2 工作流程

DeepSpec的工作流程分为三个阶段：

数据准备下载提示词+构建目标缓存

训练训练草稿模型

评估衡量接受程度

三个阶段需要按顺序运行，前一阶段的输出作为后一阶段的输入。

7.3 开源生态

DeepSpec采用MIT许可，支持Qwen、Gemma等国内外主流基座。目前已在GitHub上开源了DSpark、DFlash、Eagle3全套训练代码、评估工具与模型权重。

这意味着，对于缺乏底层算法团队的中小企业，无需投入巨额研发即可复用成熟推理优化方案，大幅降低大模型私有化部署的门槛。

八、局限与展望

论文也坦诚指出了当前方案的局限：

对于本身可预测性极低、接受率偏低的复杂查询，这部分前置草稿算力无法回收。

未来的优化方向是：在草稿模型内部引入难度感知的早退出机制，使此类请求能够跳过完整块生成流程。

九、总结

DSpark的贡献不在于发明了推测解码——这个方向已有大量研究。它的真正价值在于：

将各类技术融合为一套自适应完整系统，实现了端到端的显著性能优化。

从技术架构上看，DSpark做了三件对的事：

1. 1. 半自回归生成：用并行保速度，用轻量顺序模块保质量——2层胜过5层
2. 2. 置信度调度验证：把算力只分配给预期回报最高的token——从固定2个到动态4-6个
3. 3. 系统工程落地：让算法在真实流量中跑起来

Fireworks AI的联合创始人兼CTO、PyTorch核心维护者Dmytro Dzhulgakov在拆解DSpark论文后给出了一个精辟的评价：

DeepSeek这套方案真正的精髓在于系统工程和模型协同设计。

而这，或许正是DSpark给整个AI行业最重要的启示：在模型参数竞赛进入瓶颈期后，推理效率的工程优化将成为下一阶段的核心竞争力。

参考文献

[1] DeepSeek, Peking University. DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation [R]. Technical Report, 2026.

[2] 36氪. 梁文锋署名论文，DeepSeek首轮融资后大动作：生成速度大涨85%[N]. 2026-06-27.

[3] 钛媒体. 北大与DeepSeek联合开源DSpark框架，高并发下生成速度提升超60%[N]. 2026-06-27.

[4] 凤凰网科技. 北大与DeepSeek联合开源DSpark框架，高并发下生成速度提升超60%[N]. 2026-06-27.

[5] 凤凰网科技. DeepSeek推理提速80%，DSpark到底做对了什么？[N]. 2026-06-28.

[6] 财联社. 大模型推理最高提速85%！DeepSeek发表重磅论文 提出两项互补机制[N]. 2026-06-28.

[7] 极客公园. DeepSeek V4更新DSpark，推理速度提升80%[N]. 2026-06-28.

[8] DeepSpec GitHub Repository. https://github.com/deepseek-ai/DeepSpec