DeepSeek 联合北大开源 DSpark：半自回归推测解码，推理速度提升 57% 至 85%

DeepSeek 联合北大开源 DSpark：半自回归推测解码，推理速度提升 60% 至 85%

大语言模型生成文本时逐 token 串行计算，推理延迟随输出长度线性增长，这是 AI 对话系统响应偏慢的根本原因之一。推测解码是一条已知的加速路径：用轻量草稿模型快速生成若干候选 token，再由完整规模的大模型通过单次并行前向传播批量验证，接受符合目标分布的连续前缀。验证阶段可并行计算，拒绝采样机制严格保证输出分布与原始模型一致，从而在无损生成质量的前提下提升速度。

但推测解码的实际效果受制于两个瓶颈：候选生成质量和验证阶段的算力占用。现有方案分两派。自回归草稿模型（如 Eagle3）逐 token 串行生成候选，依赖关系建模能力强、接受率高，但生成延迟随候选长度线性增长，迫使实际部署中只能使用短候选块和浅层网络。并行草稿模型（如 DFlash）一个前向传播产出全部候选 token，生成延迟几乎与候选长度无关，但随着位置后移，无法依赖块内先前 token 导致接受率迅速衰减，长候选块的后缀 token 往往在验证阶段被大量拒绝。

半自回归候选生成

DSpark 采用半自回归架构应对第一项瓶颈。并行主干网络一次性产出全部候选位置的隐藏状态和基础 logits，随后由一个轻量顺序模块逐 token 注入前缀依赖信息。该顺序模块提供两种实现：仅依赖前一个 token 的马尔可夫头，以及通过循环状态累积完整前缀信息的 RNN 头。

实验结果表明，两层 Transformer 深度的 DSpark 在所有测试领域上均超过五层 DFlash 的接受长度，表明少量自回归依赖的引入在参数效率上优于单纯堆叠并行层。

置信度调度验证

第二项瓶颈由置信度调度验证机制解决。模型在每个候选位置输出一个置信度分数，预测该 token 在此前所有 token 均被接受条件下的存活概率。受训阶段完成后，团队在验证集上通过逐位置温度缩放对置信度进行校准。

硬件感知前缀调度器将验证长度选择建模为全局吞吐量最大化问题：给定一批并发请求及其各位置置信度，结合预先实测的引擎吞吐量曲线，为每个请求动态决定验证多长的候选前缀，优先将目标模型算力分配给全局存活概率最高的 token。

离线基准与生产部署

离线基准测试选取 Qwen3 系列（4B/8B/14B）和 Gemma4-12B 作为目标模型。在数学推理（GSM8K、MATH500、AIME25）、代码生成（MBPP、HumanEval、LiveCodeBench）和日常对话（MT-Bench、Alpaca、Arena-Hard）三类任务上，DSpark 的平均每轮接受长度均优于 Eagle3 和 DFlash 两类基线。以 Qwen3-4B 为例，DSpark 相比 Eagle3 提升约 30.9%，相比 DFlash 提升约 16.3%。

DSpark 已部署于 DeepSeek-V4-Flash 和 V4-Pro 预览版。并行主干包含三个 MoE 层与滑动窗口注意力，最大候选块长度设为 5，采用马尔可夫头作为顺序模块。

在线生产环境实测中，V4-Flash 引擎上，当 SLA 保证单用户不低于 80 token/s 时，DSpark 聚合吞吐量相比基线提升 51%；SLA 收紧至 120 token/s 时，基线已接近运行边界，DSpark 实现标称 661% 的吞吐量优势。V4-Pro 引擎上，35 token/s SLA 下吞吐量提升 52%，50 token/s SLA 下提升 406%。匹配实际吞吐量水平下，单用户生成速度提升 57% 至 85%。

DSpark 的局限在于，即使后缀 token 被调度器截断，并行主干仍需为所有请求生成完整的初始候选块，对接受率本身较低的复杂查询，这部分草稿计算开销无法回收。

DSpark、DFlash、Eagle3 三种草稿模型的训练代码、评估脚本及模型检查点已在 GitHub 的 DeepSpec 项目中开源。

来源：IT之家 · GitHub DeepSpec · HuggingFace