DeepSeek DSpark 详解：V4 实测提速 60%～85%，它做对了什么？-尧图网络科技

〔更多精彩AI内容，尽在「魔方AI空间」，引领AIGC科技时代〕
本文作者：猫先生

经典文章回顾：

万字综述 | 一文带你入门「具身智能」：从基础概念到大模型赋能
万字长文｜一文详解具身智能：视觉-语言-动作模型（VLA）系统性综述
一文梳理主流大模型推理部署框架：vLLM、SGLang、TensorRT-LLM、ollama、XInference
一文梳理主流热门智能体框架：Dify、Coze、n8n、AutoGen、LangChain、CrewAI
一文详解AI大模型14个核心基础概念：Transformer、Token、MoE、RAG、对齐、预训练、微调、Agent

写在前面
【从零走向AGI】旨在深入了解通用人工智能（AGI）的发展路径，从最基础的概念起，逐步构建完整的知识体系。
项目地址🔗：https://ai-mzq.github.io/From-Zero-to-AGI/

一句话总结：DSpark 把推测解码从“固定多猜几个 token”，改造成了“更连贯地猜，并根据置信度和机器负载决定猜到哪里”。

这项工作的亮点不只是一种新的草稿模型结构。它把算法层面的接受率、系统层面的验证成本和线上服务负载放进了同一个优化闭环，并已经在 DeepSeek-V4 的真实流量中部署。

论文标题：DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation
发布时间：2026 年 6 月
论文 PDF：https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf
代码与模型：https://github.com/deepseek-ai/DeepSpec

01 推测解码快在哪里，又浪费在哪里

大模型通常一次只生成一个 token。推测解码的思路很像“让小模型先打草稿”：轻量的draft model一次提出多个候选 token，昂贵的target model再并行验收。只要使用严格的拒绝采样，最终输出分布仍与 target model 一致，因此这类加速原则上不牺牲生成质量。

问题在于，草稿既要快，又要准。

自回归草稿模型逐 token 生成，前后依赖清楚，但草稿越长，生成时间也线性增长。
并行草稿模型一次生成整段，速度很快，却看不到块内前面实际采样了什么，后半段容易“串台”。

举个直观例子。上下文可能接 “of course”，也可能接 “no problem”。并行预测每个位置时，各自看到的是多种可能性的混合，于是可能拼出 “of problem” 这种单词都认识、组合却不对的结果。

而推测解码只接受从头开始的连续前缀。前面一处被拒，后面的 token 即使碰巧正确也全部作废。因此，长草稿后半段质量快速衰减，不只是模型问题，还会变成实打实的算力浪费。

推测解码的关键不是“草稿越长越好”，而是每多验证一个 token，预期收益能不能覆盖它占用的服务容量。

02 DSpark 的核心：半并行生成，按负载验证

DSpark 用两个互补模块解决上述矛盾：

半自回归生成（Semi-Autoregressive Generation）：重计算并行完成，轻量的顺序模块负责补上块内依赖。
置信度调度验证（Confidence-Scheduled Verification）：估计每个前缀能通过验证的概率，再结合当前引擎负载，为每个请求动态分配验证长度。

图 1：DSpark 先用并行骨干生成整块 logits，再由轻量顺序模块逐步修正；调度器保留高价值前缀 EFG，丢弃低置信度的 H，最后交给目标模型并行验证。

图中这一轮的过程很清楚：目标模型先产生锚点 tokenD；DSpark 草拟E、F、G、H，同时输出置信度；调度器判断H不值得验证，只把EFG送入 target model；E、F被接受，G被拒绝并由目标模型修正为G*。

这里的“聪明”不是单点技巧，而是三件事同时成立：草稿生成足够便宜、长前缀足够连贯、验证预算随服务状态变化。

03 半自回归：重活并行做，轻活顺序做

DSpark 的主体沿用 DFlash 式并行骨干，一次前向计算得到整块位置的隐藏状态和基础 logits。随后，一个很小的顺序模块从左到右注入前缀信息：

Markov Head只读取前一个已采样 token，通过低秩转移矩阵修正当前 logits；
RNN Head维护块内历史状态，能利用更长的前缀信息，但计算也略重。

论文默认采用 Markov Head，低秩维度为 256。它不负责“从头再生成一遍”，只给并行骨干的结果加一个局部转移偏置。可以把它理解成：并行骨干先把整段的大方向写出来，顺序头再快速检查相邻词是否接得上。

这个设计的分寸感很重要。顺序模块太强，系统就退回自回归生成；太弱，又无法修复并行预测的模式碰撞。实验中，Markov Head 已经拿到大部分收益，而额外的串行开销只占完整解码轮次延迟的约0.2%～1.3%。

训练时，目标模型保持冻结，DSpark 联合优化三类目标：真实 token 的交叉熵、草稿分布与目标分布的总变差距离，以及置信度预测误差。越靠前的位置权重越高，因为前缀验证中，早期 token 决定了后面整段能否存活。

04 调度器：不是设一个阈值，而是算这笔账值不值

DSpark 的置信度头预测的不是“这个 token 看起来像不像对”，而是一个更严格的量：

在前面 token 都已被接受的条件下，当前位置通过目标模型验证的概率。

将这些条件概率连乘，就得到某个前缀完整存活的概率。论文还使用Sequential Temperature Scaling（STS）做逐位置校准，把原本偏自信的估计拉回真实接受率附近：在 Alpaca 数据上的平均 ECE 从约 3%～8% 降至约 1%。

但有置信度还不够。固定阈值没有考虑一个现实问题：同一个低置信度 token，在空闲 GPU 上几乎是“顺手一验”，在高并发时却可能挤掉另一个用户的请求。

因此，DSpark 预先测量引擎在不同 batch token 数下的每秒步数曲线SPS(B)，运行时最大化：

预期接受 token 数 × 当前 batch 大小对应的引擎步速

调度器把所有请求可继续扩展的前缀按存活概率排序，逐个加入验证批次；只要预计系统吞吐不再上升，就停止增加。这样一来，验证长度不再是固定超参数，而成了每轮、每个请求、随负载变化的资源决策。

为了保持无损推测解码，作者还加入了严格的提前停止机制，避免调度决策偷看未来候选 token。这个细节很技术，但很关键：否则“按置信度筛选”可能悄悄改变目标分布，速度上去了，生成结果却不再等价。

05 离线实验：确实猜得更长，但要看清指标

离线实验覆盖 Qwen3-4B、8B、14B 和 Gemma4-12B 四个目标模型，任务包含数学、代码与开放聊天。为了单独评估草稿质量，这部分关闭了动态置信度调度，所有方法都使用固定草稿长度。

图 2：DSpark 在四个目标模型和九组任务上均取得最高的单轮平均接受长度；结构化任务的可接受草稿通常明显长于开放聊天。

在 Qwen3-4B、8B、14B 上，DSpark 的宏平均接受长度相比：

对比方法	Qwen3-4B	Qwen3-8B	Qwen3-14B
自回归 Eagle3	+30.9%	+26.7%	+30.0%
并行 DFlash	+16.3%	+18.4%	+18.3%

逐位置分析解释了收益来源：并行模型在第一个位置通常很强，因为它能用更深的网络专注预测一个位置；但越往后，独立预测的缺陷越明显。DSpark 保留了并行模型的强起步，又用轻量顺序依赖减缓后缀接受率下滑。

还要注意明显的领域差异。以 Qwen3-4B 为例，DSpark 在数学和代码任务上的平均接受长度约为 5.57 和 5.12，而开放聊天约为 3.49。代码、数学的延续更受结构约束，开放对话则往往存在很多同样合理的表达路径。

离线 accepted length 证明 DSpark“草稿更好”，但它本身不等于线上更快；真正的系统收益还取决于草稿成本、验证成本和并发负载。

06 线上部署：它真正拉开差距的地方

作者将最大草稿长度为 5 的 DSpark-5 部署到 DeepSeek-V4-Flash 与 DeepSeek-V4-Pro 的预览版服务中，并与原生产基线 MTP-1 比较。图中的散点来自真实用户流量，实线是拟合出的性能边界。

图 3：相同聚合吞吐下，DSpark 能提供更高的单用户生成速度；相同交互性要求下，它也能承载更高吞吐，整体把服务系统的 Pareto 前沿向外推。

在较温和的交互性 SLA 下：

V4-Flash 在 80 tok/s/user 时，聚合吞吐提升51%；
V4-Pro 在 35 tok/s/user 时，聚合吞吐提升52%。

在匹配聚合吞吐的更稳定比较下，DSpark 将单用户生成速度提高：

V4-Flash：60%～85%；
V4-Pro：57%～78%。

论文还报告了严格 SLA 下661%和406%的名义吞吐提升，但作者明确提醒：此时 MTP-1 已逼近运行边界，只能维持很小的并发批次。它更适合被理解为“DSpark 打开了原先不可用的服务区间”，而不是日常负载下稳定获得六倍吞吐。

图 4：负载较轻时，DSpark 把空闲算力用于验证约 4～6 个 token；并发升高后，验证预算平滑收缩，避免低置信度后缀占满目标模型的 batch 容量。

这张图可能比单一加速数字更能说明 DSpark 的价值：它没有寻找一个“永远正确”的草稿长度，而是在系统还有余力时多验证、接近饱和时主动少验证。过去静态 MTP-3/5 在高并发下会因验证浪费而降低总吞吐，DSpark 的调度正是为了安全地释放长草稿的潜力。

07 贡献、边界，以及我怎么看

DSpark 的贡献可以分成三层：

模型层：用“重并行 + 轻顺序”折中草稿速度与块内依赖；
估计层：预测并校准连续前缀的真实存活概率；
系统层：把置信度、请求差异和硬件吞吐曲线联合起来，动态分配验证预算。

它的边界也很明确。

草稿骨干仍要先生成完整候选块。对天然接受率很低的复杂请求，这笔固定成本无法靠后续剪枝收回。
线上数字来自 DeepSeek 自有 V4-Flash/Pro 预览版、特定引擎与真实流量分布，不能直接外推到所有模型、GPU 和部署框架。
开源仓库当前公开了 Qwen3 与 Gemma4 的训练、评估配置和检查点，但论文中的 V4 线上系统包含异步调度、稀疏注意力内核等生产级改造，复现端到端收益并不只是加载一个权重。
论文主要比较 Eagle3、DFlash 与 MTP-1；这足以验证设计，但还不能代表对所有推测解码方案的全面胜出。