DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation
Xin Cheng, Xingkai Yu, Chenze Shao, Jiashi Li, Yunfan Xiong, Yi Qian, Jiaqi Zhu, Shirong Ma, Xiaokang Zhang, Jiasheng Ye, Qinyu Chen, Chengqi Deng, Jiping Yu, Damai Dai, Zhengyan Zhang, Yixuan Wei, Yixuan Tan, Wenkai Yang, Runxin Xu, Yu Wu, Zhean Xu, Xuanyu Wang, Muyang Chen, Rui Tian, Xiao Bi, Zhewen Hao, Shaoyuan Chen, Huanqi Cao, Wentao Zhang, Anyi Xu, Huishuai Zhang, Dongyan Zhao, Wenfeng Liang
cs.AI, cs.CL
2026-07-06
DeepSeek 的 DSpark 用半自回归起草+按置信度调度验证,离线接受长度比 Eagle3 高约 30%,DeepSeek-V4 线上单用户提速 60–85%。
投机解码给大模型推理加速的思路是:用一个小「起草模型」先猜几个 token,再用大模型一次验证。并行起草器(一次前向吐一长串)有两个毛病:token 之间没有依赖,越往后接受率掉得越快;而且不分青红皂白地把整块拿去验证,把宝贵的 batch 算力浪费在大概率会被拒的 token 上,高并发时吞吐反而塌。DeepSeek 这篇 DSpark 同时治这两头,而且已经上了 DeepSeek-V4 的线上服务。
起草端是半自回归结构。一个重的并行主干(DFlash)一次前向产出所有隐状态,再接一个轻量的串行模块(Markov head 或 RNN head),给每个位置叠加基于已采样 token 的转移偏置。Markov head 用低秩分解(r=256)加一阶依赖,既压住了越往后越不准的 suffix decay,又把串行部分的耗时控得远小于并行主干。
验证端是置信度调度验证。一个置信度头给出每个 token 的条件接受概率 ck,监督信号是解析的 ck = 1 − ½‖pdraft − ptarget‖₁(草稿与目标分布的 L1 距离换算)。再上一层是硬件感知的前缀调度器:把候选 token 按存活概率 a = ∏ ci 全局排序,再根据引擎实时的吞吐曲线动态决定每个请求验多长,目标是把吞吐 Θ 拉满。
离线 benchmark 上,DSpark 的每轮接受长度 τ 全面领先:
| 目标模型/任务 | DSpark | DFlash | Eagle3 |
| Qwen3-4B 数学 | 5.57 | 4.80 | 4.56 |
| Qwen3-8B 代码 | 5.42 | 4.80 | 4.15 |
| Qwen3-14B 对话 | 3.47 | 2.99 | 2.52 |
相对自回归的 Eagle3 提升约 30%,相对并行的 DFlash 提升约 17%–18%。
线上更有说服力。在 DeepSeek-V4 服务系统、真实流量下:V4-Flash 单用户生成提速 60%–85%(等吞吐),V4-Pro 提速 57%–78%。在严格的交互 SLA 下(V4-Flash 80 tok/s/用户、V4-Pro 35 tok/s/用户),相对生产基线 MTP-1,聚合吞吐分别涨 51% 和 52%。作者强调它把服务系统的 Pareto 前沿推到了此前达不到的位置。
推理成本是大模型商业化的命门,DeepSeek 在这块一直是公开的工程标杆。DSpark 的价值在于把「起草质量」和「验证调度」一起优化,并在真实高并发流量上验证,而不是停在离线接受率。对做推理服务的团队,半自回归搭配负载感知验证是一套可借鉴的范式,工程上能直接对齐。
作者自己点出:起草端生成初始 γ-token 块的固定开销躲不掉,遇到接受率天然就低的复杂请求,这笔预付算力收不回来。他们留给后续工作的是「按难度提前退出」。另外线上收益是在 DeepSeek 自家系统(MTP 基线、特定硬件)上测的,换到别的推理引擎,置信度调度那套吞吐曲线得重新标定,迁移成本没展开。