DSpark_paper 代码 + 原文链接https://github.com/deepseek-ai/DeepSpec

一、前置说明：名称混淆澄清

DSpark 是DeepSeek 推出的大模型投机解码（Speculative Decoding）推理加速框架，与业界熟知的大数据分布式处理框架Apache Spark 没有任何技术关联：两者适用场景、技术栈、设计目标完全不同，仅名称存在局部重合，下文分析将完全围绕该 LLM 推理加速框架展开，不涉及任何大数据处理引擎相关内容。

二、论文核心概述

2.1 研究背景与解决的核心问题

自回归生成是当前大语言模型（LLM）的标准推理范式：每生成一个新 token，都需要将所有前文作为条件执行一次完整的模型前向计算，导致推理时延与输出长度呈线性增长，GPU 计算资源利用率极低 —— 这是生产级 LLM 服务的核心瓶颈，尤其在实时对话、多回合智能体 workflow 等时延敏感场景中，单用户体验和系统整体吞吐量难以兼顾。

投机解码是当前解决该瓶颈的主流技术路径：通过解耦草稿生成与目标验证两个环节，用一个轻量快速的 “草稿模型” 一次性生成多个候选 token，再由全量 “目标模型” 通过批量前向计算完成校验，接受匹配目标分布的最长有效 token 前缀，在完全不改变生成质量的前提下，将多次串行计算合并为一次并行计算，提升推理效率。

现有投机解码方案存在两大系统性痛点，严重限制其在高并发生产场景的落地：

1. 生成质量瓶颈：传统并行草稿器所有位置独立预测 token，无法建模块内 token 间的上下文依赖关系，导致多模态冲突、后续位置接受率快速衰减（Suffix Decay）；而传统自回归草稿器的生成时延随草稿块长度线性增长，无法通过扩大块长度提升吞吐量；
2. 系统效率瓶颈：现有方案均采用固定长度的验证策略，无差别校验所有草稿 token；但在高并发场景下，尾部低接受概率的 token 会挤占宝贵的 GPU 批处理资源，反而大幅降低系统有效吞吐量；同时，不同任务的 token 接受概率存在天然差异 —— 代码、数学等结构化任务的前缀存活概率显著高于开放式对话，静态验证长度必然造成资源浪费。

2.2 核心贡献

DSpark 从算法架构级设计与系统级调度优化两个维度切入，针对性解决上述瓶颈，核心贡献包含两点：

1. 半自回归生成架构：保留并行骨干网络的高生成效率，仅附加轻量级串行输出头建模局部 token 依赖，兼顾并行生成的低时延与自回归生成的高质量，缓解尾部接受率衰减问题；
2. 置信度调度验证机制：通过置信度头预估每个 token 的前缀存活概率，结合实时系统负载特征动态调整每笔请求的验证长度，将有限的 GPU 验证预算优先分配给高有效概率的 token，彻底消除无效验证带来的算力浪费。

该框架已在 DeepSeek-V4 生产级服务系统中落地，真实用户流量下实现显著双向增益：同等吞吐量条件下，单用户生成速度提升 60%~85%；严格时延约束下的吞吐量衰减问题被根本性缓解，将 LLM 推理服务的 Pareto 最优边界向前大幅推移。

2.3 开源配套

论文同步开源配套训练仓库DeepSpec，提供完整的草稿模型训练、性能评估、线上部署全链路工具链，公开 DSpark 官方预训练草稿权重，支持 Qwen3、Llama3、Gemma 等主流外部模型，覆盖从 10B 到万亿级参数规模的 LLM 加速适配需求，推动业界投机解码技术的工程化落地。。

三、DSpark 技术架构

DSpark 架构整体分为两大核心模块：半自回归草稿生成模块（负责快速产出高质量候选 token 块）与置信度调度自适应验证模块（负责结合数据特征与系统负载高效分配算力），两者端到端协同优化，同时兼顾单用户生成时延与集群有效吞吐量。

3.1 半自回归草稿生成架构

该架构精准平衡生成时延与草稿质量，核心设计思路是 “重并行骨干、轻串行校正”，既保留并行生成的低时延优势，又通过极小的串行成本弥补 token 依赖缺失的短板，三大核心组件协同完成草稿生成：

3.1.1 Parallel Backbone（并行骨干网络）

基于 DFlash 并行块生成架构优化设计，作为草稿模型的核心算力承载层，所有候选 token 位置的预测过程完全独立并行，仅执行一次模型前向计算，整体生成时延几乎不受草稿块长度影响，为生成长候选 token 块提供基础支撑。

3.1.2 Markov 顺序校正头

极轻量级的串行输出模块，可在并行骨干的输出结果上叠加局部 token 转移依赖，把原本独立预测的 token 序列校正为符合语言逻辑的连贯序列；由于仅对骨干输出做局部顺序校正、不参与深层特征计算，额外引入的串行时延极低，仅占整体草稿生成时延的 0.2%~1.3%，几乎可以忽略不计。

3.1.3 Confidence Head（置信度头）

独立的轻量级预测层，结合并行骨干的隐藏状态输出，预估每个草稿 token 位置的前缀存活概率—— 即该位置之前的所有前缀 token 均被目标模型接受的前提下，自身被通过的条件概率，为后续动态调度提供量化、可比较的决策依据。

3.2 置信度调度验证机制

该机制是 DSpark 区别于传统方案的核心系统级优化，本质是在数据侧的预测性特征与系统侧的实时负载特征之间做权衡，动态控制验证预算的分配，从根本上解决高并发场景下的算力浪费问题。

3.2.1 设计逻辑

传统投机解码采用固定验证长度策略：低负载场景下，多验证几个尾部 token 几乎没有额外成本；但在高并发场景下，GPU 批处理资源是核心瓶颈，验证低概率 token 会挤占其他高优先级请求的资源，反而大幅降低整体吞吐量。DSpark 放弃静态验证长度，转而由调度器基于两类实时数据做动态决策：

• 数据侧：置信度头输出的每个 token 前缀存活概率；

• 系统侧：引擎实时吞吐量 profile、GPU 批处理资源利用率、当前并发请求总量。

3.2.2 调度执行流程

• 概率过滤：调度器预先设置一个可动态调整的置信度阈值，所有低于该阈值的尾部草稿 token 会被直接截断，不送入目标模型参与验证；
• 负载适配：低负载时，系统自动降低置信度阈值，保留更长的草稿块，充分利用空闲算力提升单轮生成效率；高负载时，系统自动抬高置信度阈值，仅保留高概率的前缀 token，优先节省算力支撑更多并发请求；
• 协同验证：最终确定的有效草稿块被送入目标模型做批量验证，验证完成后将接受结果反馈至置信度头，辅助后续请求的概率预估校准，形成闭环优化。

四、DSpark 创新点深度分析

4.1 半自回归生成：融合两类范式的优势

完全突破传统草稿器的设计两难：要么采用自回归生成保证质量、但时延随块长度线性增长，要么采用并行生成保证速度、但草稿质量快速衰减，通过分层架构设计实现两者优势的叠加：

• 并行骨干负责大部分特征计算，保障生成速度；

• 轻量级串行头仅补充建模局部 token 依赖，几乎不增加额外时延；

实测显示，该架构的草稿生成速度与纯并行方案完全持平，同时将平均接受率衰减幅度降低了 70% 以上。

4.2 置信度调度：从静态验证到动态感知

第一次把单纯的算法级验证，升级为算法 + 系统协同的验证调度策略，实现算力资源的精准分配：

• 传统方案仅关注 “能生成多少草稿 token”，DSpark 关注 “验证多少草稿 token 性价比最高”；

• 通过实时感知负载和 token 质量，在低并发场景下最大化单轮生成效率，在高并发场景下将无效验证占比从传统方案的 40% 压缩至 5% 以内，从根本上避免算力浪费。

4.3 端到端系统级协同优化

并非孤立优化草稿生成或验证环节，而是从草稿生成逻辑到验证调度策略做全链路协同：

• 半自回归架构提升草稿质量上限，为调度策略提供高质量的候选 token 基础；

• 置信度调度将草稿质量的增益转化为实际系统吞吐量的提升，两者配合同时覆盖 “用户体验优化” 和 “运维成本降低” 两大生产侧核心需求，推动推理服务的 Pareto 边界前移。

4.4 生产级场景的针对性适配

设计过程中充分贴合真实流量的特征差异，适配不同任务的天然算力效率差异：

• 结构化任务（代码、数学推理）的前缀存活概率整体偏高，调度器自动保留更长的草稿块，充分挖掘并行生成潜力；

• 开放式对话任务的前缀存活概率偏低，调度器主动截断低置信度尾部 token，避免无意义的算力消耗，将任务级特征转化为实际的性能增益。

五、与同类技术对比分析

当前主流投机解码方案分为两类：以 Eagle3 为代表的自回归草稿器、以 DFlash 为代表的并行草稿器，DSpark 半自回归架构 + 置信度调度的组合，完美覆盖两类方案的优势区间，不存在明显短板。

5.1 核心基线方案差异对比

维度	DSpark	Eagle3（自回归基线）	DFlash（并行基线）	MTP-1（原生产基线）
草稿生成范式	半自回归：并行骨干 + 轻量级串行校正头	全自回归：逐 token 串行生成	全并行：所有 token 位置独立预测	受限并行：短块长度并行生成
核心优势	兼顾高生成速度与低接受率衰减	草稿质量高，尾部接受率稳定	草稿生成速度极快	架构简单，部署成本低
核心短板	草稿器需适配目标模型分布	生成时延随块长度线性增长，吞吐量瓶颈明显	缺乏 token 依赖建模，尾部接受率快速衰减	无动态调度，高并发下算力浪费严重
验证策略	动态：基于置信度 + 实时负载调整	静态：固定短块长度	静态：固定长块长度	静态：固定中长块长度
资源开销	额外增加轻量级置信度头，训练成本低	串行生成成本随块长度放大	无额外串行成本	无额外组件成本

5.2 量化性能对比

5.2.1 离线 Benchmark 对比

测试覆盖三大典型 LLM 任务域，采用平均接受长度（每轮解码中，目标模型最终接受的有效 token 数量，包含额外生成的 bonus token，越高越好）作为核心评价指标，该指标直接反映草稿的实际有效质量：

• 相对自回归基线：在 Qwen3-4B/8B/14B 模型上，DSpark 的平均接受长度比 Eagle3 高出 26.7%~30.9%；在 Gemma4-12B 模型上提升幅度持平，优势覆盖全任务场景；

• 相对并行基线：在 Qwen3 系列模型上，DSpark 的平均接受长度比 DFlash 高出 16.3%~18.4%；在 Gemma4-12B 模型上提升约 15%，直接验证了半自回归架构的质量增益；

• 衰减特征对比：从单 token 条件接受率的变化曲线看，DFlash 的接受率在草稿块后半段快速跳水，Eagle3 的接受率缓慢上升，DSpark 的接受率在尾部几乎无明显衰减，稳定性逼近自回归方案，同时保留并行生成的速度优势。

5.2.2 生产级流量对比

在 DeepSeek-V4 真实生产集群中，以原生产基线 MTP-1 为参照，DSpark 实现双向性能增益，数据来自 GPUStack 官方实测结果：

• 用户侧时延优化：相同集群吞吐量下，单用户生成速度提升 60%~85%；首 token 时延（TTFT）降低为原基线的 1/2；

• 系统侧吞吐量优化：低并发场景下，系统吞吐量较原版提升约 1 倍；10 并发、64K 上下文长度的高负载场景下，TPS 从 198 提升到 338，提升幅度约 70%；极端高并发场景下的吞吐量衰减幅度被控制在 10% 以内；

• 资源利用率优化：相同 GPU 资源下，可支撑的在线用户规模较原基线提升 51%~52%，有效降低了服务运维成本。

5.2.3 质量一致性验证

所有投机解码方案必须保证生成质量无损失：DSpark 严格遵循标准投机解码的拒绝采样规则，完全保留目标模型的原生输出分布；实测显示，在所有任务域、所有并发场景下，DSpark 的输出结果与原目标模型直接生成的结果无统计差异，完全不存在速度与质量的权衡问题。

六、性能测试与实验结果分析

DSpark 的实验设计分为两层：离线实验单独验证半自回归架构的草稿质量增益，在线生产实验验证置信度调度的系统级协同增益。

6.1 离线实验设计与结果

6.1.1 实验设置

• 任务域：覆盖三类典型 LLM 生产场景，数学推理（GSM8K、MATH500、AIME25）、代码生成（MBPP、HumanEval、Live-CodeBench）、日常对话（MT-Bench、Alpaca、Arena-Hard）；

• 目标模型：采用 Qwen3-4B/8B/14B、Gemma4-12B 四款主流开源 LLM，覆盖不同参数规模、不同模型架构；

• 评估协议：关闭置信度调度，强制所有方案使用相同的固定草稿块长度，隔离系统调度的干扰，单纯验证草稿生成架构的质量差异；采用标准投机解码流程，采样温度系数固定为 1.0，核心评估指标为每轮解码的平均接受长度。

6.1.2 核心实验结论

1. 架构优势验证：半自回归架构的草稿质量显著优于纯并行和自回归方案：在所有目标模型、所有任务域下，DSpark 的平均接受长度均稳居第一，不存在任何短板；
2. 任务特征验证：结构化任务的天然接受率显著高于开放式对话：以 Qwen3-4B 为例，数学任务的平均接受率为 5.57，代码任务为 5.12，对话任务仅为 3.49；这一差异直接验证了静态验证长度的不合理性，也解释了置信度调度策略的必要性；
3. 增益稳定性验证：半自回归架构的增益不依赖特定目标模型架构：无论是 Qwen3 系列还是 Gemma4 系列模型，DSpark 的相对提升幅度都保持在稳定区间，没有明显的模型适配波动。

6.2 在线生产实验设计与结果

6.2.1 部署环境

DeepSeek-V4 生产级推理集群，采用 2x DGX Spark 节点，张量并行度（TP）=2，官方 FP8 量化，配置 200K 上下文长度，基于 GPUStack 实现集群资源编排与推理服务调度，完全还原真实线上场景。

6.2.2 实测核心结果

1. 调度增益验证：开启置信度调度后，高并发场景下的系统吞吐量较关闭调度时额外提升 30%~40%；尾部低概率 token 的实际验证占比从传统方案的 40% 降至不足 5%，无效算力被大幅压缩；
2. 并发适配验证：随着并发请求规模提升，传统方案的吞吐量呈现断崖式衰减，而 DSpark 的吞吐量衰减曲线极度平缓；在严格的用户交互时时延约束下，DSpark 可以支撑的有效并发规模是原基线方案的 2.5 倍，突破了原有的服务性能上限；
3. 叠加适配验证：DSpark 的加速增益可与其他主流推理加速技术叠加：与 FP8 量化、分页注意力、KV Cache 压缩等技术组合后，综合加速幅度可再提升 30%，适配不同的生产级优化需求。

6.3 分解实验分析

为进一步验证各组件的贡献，论文开展了分解对比实验：

• 半自回归架构单独增益：关闭置信度调度，仅使用 Parallel Backbone+Markov 校正头，平均接受长度比纯并行方案提升 20%~25%，贡献了大部分的草稿质量增益；

• 置信度调度单独增益：固定草稿块质量，开启动态调度后，高并发场景下的有效吞吐量提升幅度超过 30%，贡献了大部分的系统效率增益；

• 协同增益：两个组件同时启用时，整体增益高于两者单独增益的乘积，验证了架构协同的有效性：高质量草稿块为调度提供了更多优化空间，调度策略则将草稿质量增益精准转化为实际系统性能提升。

七、实际应用案例

7.1 DeepSeek-V4 全量生产部署

这是 DSpark 最核心的落地案例：DeepSeek 将 DSpark 作为默认推理加速框架，全量覆盖 V4 系列的 Flash 和 Pro 两个线上版本，支撑百万级真实用户的多回合对话、代码生成、数学推理等线上业务，在不降低服务吞吐量的前提下，将用户感知的生成速度直接提升了 60%~85%。

7.2 GPUStack 官方企业级部署案例

GPUStack 社区发布完整的落地教程，在 2x DGX Spark 节点上部署 DeepSeek-V4-Flash+DSpark 组合方案，实现高吞吐、低时延的企业级 LLM 推理能力：单并发下的 token 生成速率达到 195TPS，是原版的 2.1 倍；10 并发高负载场景下的吞吐量达到 338TPS，较原版提升 70%，作为中小企业落地大模型服务的标准参考架构。

7.3 开源生态适配

配套开源的 DeepSpec 仓库，支持业界主流 LLM 的 DSpark 草稿模型训练，包括 Qwen3、Llama3、Gemma 等主流开源模型，企业用户可以基于自有业务数据训练定制化的草稿模型，在不修改目标模型代码的前提下，快速为自有 LLM 服务接入 DSpark 的加速能力。

7.4 典型适配场景

DSpark 的增益在不同场景下存在差异，但均保持稳定收益：

• 代码生成、数学推理：加速幅度最高可达 85%，这类任务逻辑约束强、草稿接受概率高，半自回归架构和调度策略的增益可以充分释放；

• 多回合开放式对话：加速幅度稳定在 60%~70%，置信度调度有效控制了低概率 token 的算力浪费；

• 长上下文生成场景：上下文长度超过 32K 时，DSpark 的相对增益进一步放大，有效缓解了长上下文下的 KV Cache 带宽瓶颈。

八、技术前景分析

8.1 成为生产级 LLM 推理的标准加速方案

当前 LLM 推理的核心瓶颈集中在 KV Cache 显存带宽、计算资源利用率两个维度，而现有推理加速技术多聚焦于模型侧的单维度优化；DSpark 从系统级调度和草稿生成两个维度切入，不依赖特定模型架构、不需要修改目标模型核心逻辑，可与量化、KV Cache 压缩、分页注意力、 speculative decoding 等主流加速技术无缝叠加，组合后实现更大幅度的综合增益，成为生产级推理栈中的标准组件。

8.2 推动投机解码技术的工程化普及

在 DSpark 之前，投机解码技术存在明显的落地门槛：自回归方案无法支撑高并发，并行方案的质量衰减问题难以解决；DSpark 的半自回归架构和置信度调度策略，把该技术的落地复杂度直接降低了一个量级；配套的 DeepSpec 开源仓库提供从训练、评估到部署的全链路支持，无需深入掌握 speculative decoding 的底层算法细节，即可快速完成适配，推动业界大规模落地该技术。

8.3 适配更复杂的下一代 LLM 生产场景

DSpark 的架构具备极强的扩展适配能力，可覆盖下一代 LLM 生产场景的核心需求：

• 多模态生成场景：半自回归架构可适配图文、视频多模态 token 的生成特征，置信度调度可感知不同模态的 token 接受概率，实现多模态推理加速；

• 超大规模长上下文场景：结合前缀缓存技术，调度器可以快速识别高置信度的前缀 token，有效验证更长的草稿块，支撑 1M + 上下文长度的高并发推理服务；

• 分布式集群场景：调度器可以扩展为全局负载感知模式，跨节点分配验证算力，适配超大规模 GPU 集群的高并发推理需求。

8.4 优化云原生 LLM 服务的资源性价比

云原生场景下，GPU 计算资源是核心成本项，DSpark 的动态调度逻辑可以最大化资源利用率：

• 集群低负载时，调度器自动延长验证块长度，充分利用空闲算力提升单用户体验；

• 集群高负载时，调度器自动截断低概率 token，将算力优先分配给核心用户请求，显著降低云环境下的综合运维成本。

九、面临的挑战与未来研究方向

9.1 面临的技术挑战

• 草稿模型的适配依赖性强：并行骨干网络的生成质量，与目标模型的层特征分布、生成风格高度相关；不同架构、不同训练数据的目标模型，需要单独适配草稿模型的骨干结构和校正头参数，不存在通用的草稿模型，跨模型适配的训练成本较高；
• 置信度预估准确率存在天花板：极端开放式生成场景（如创意写作、自由闲聊）的 token 间依赖极弱，前缀存活概率的预估精度会显著下降，动态调度的优化幅度会有所衰减；同时，置信度头的训练依赖大量目标模型的真实验证样本，标注成本较高；
• 超大规模集群的调度协同难度高：在跨多节点的分布式集群中，调度器需要实时同步所有计算节点的 GPU 利用率、批处理资源负载、排队请求规模，决策时延会随着集群规模扩大而轻微上升；如果调度时延超过单轮验证时延，反而会降低系统性能；
• 叠加优化的适配工作量大：与 KV Cache 压缩、量化、分页注意力等技术叠加时，需要重新验证草稿模型的生成质量和调度器的决策逻辑；部分加速技术会修改模型的输出分布，需要同步调整草稿模型的校正头和置信度头，适配和调优的工作量较大；
• 长上下文场景的草稿收益受限：上下文长度超过 100K 后，KV Cache 的访问时延占比显著上升，草稿生成的并行增益会被部分稀释；同时，长前缀的 cache 特征会降低校验的并行度，衰减 DSpark 的实际加速效果。

9.2 未来研究方向

• 跨模型通用草稿模型设计：通过元学习、模型蒸馏、共享骨干特征等技术，打造跨架构、跨任务、不同参数规模 LLM 的通用草稿模型家族；将草稿模型的适配过程标准化为 few-shot 微调，降低适配训练成本；
• 上下文感知的精准置信度预估模型：引入前缀 cache 历史接受数据、任务类型特征、上下文长度特征作为预估参考变量，结合轻量级在线学习机制，将验证结果反馈到置信度头的实时校准过程中，提升开放场景的预估精度；
• 分布式全局感知的调度算法：研究集群级负载、跨节点通信成本、请求优先级、实时带宽等多维度特征的调度决策模型，引入预测性负载预判能力，提前调整各节点的验证预算分配，适配超大规模 GPU 集群的高并发推理场景；
• 端到端的协同优化链路：将草稿模型训练、置信度调度、目标模型 KV Cache 优化三者联合建模，设计统一的优化训练链路，让草稿模型的生成特征和目标模型的加速特征实现最优匹配，最大化叠加后的综合增益；
• 细粒度任务级调度策略优化：基于大模型的任务分类识别结果，固化不同任务的最优调度模板，包括草稿块长度、置信度阈值、验证算力分配比例等参数，实现任务级的调度策略自动适配；
• 长上下文场景的专属架构优化：将草稿生成与前缀缓存技术深度融合，用轻量级串行头建模长距离 token 依赖，优化验证过程中的 KV Cache 访问逻辑，降低长上下文场景下的验证时延；
• 完善开源生态的工具链支持：补充更多主流模型的官方草稿 checkpoint，增加对 vLLM、TensorRT-LLM 等主流推理引擎的适配支持，提供量化、性能调优、集群部署的官方完整教程，降低业界落地门槛。

十、总结

DSpark 是 DeepSeek 在投机解码工程化落地方向的系统性创新，核心逻辑是通过半自回归架构解决草稿的质量问题，通过置信度调度解决验证的效率问题，把原本割裂的算法级优化和系统级调度优化合并成完整的技术栈，首次在生产级环境下，同时满足了低用户时延、高系统吞吐量的双重需求。

其核心技术价值并非单点算法突破，而是系统级的协同优化设计：

• 算法层用半自回归架构，平衡了并行生成的速度与自回归生成的质量；

• 系统层用置信度调度，第一次将数据侧的预测性和系统侧的负载特征精准结合，真正实现了 “算力用在刀刃上”；

• 工程层完全贴合真实生产场景的特征，在落地过程中兼顾了技术增益与运维成本。

从行业角度看，DSpark 的出现标志着投机解码技术从实验室的算法 benchmark 验证，正式进入了生产级系统优化阶段；随着该技术的进一步普及和叠加优化完善，将突破长期限制 LLM 落地的推理性能瓶颈，为大模型支撑更复杂的实时业务场景提供关键基础支撑。