DeepSeek联合北大发布DSpark推理框架 推动大模型推理效率提升

6月27日，DeepSeek联合北京大学正式推出DSpark推理加速框架。该框架聚焦大语言模型在高并发生产环境中的推理效率瓶颈，已部署于DeepSeek-V4-Flash与DeepSeek-V4-Pro的预览版服务引擎中。

推理性能实现显著提升

根据DeepSeek披露的信息，DSpark框架在同等吞吐量水平下，相比此前生产环境采用的单token推测解码基线MTP-1，可将单用户生成速度提升60%至85%。这一对比数据表明，该框架在优化用户端响应速度方面具有直接成效。

“该框架已部署于DeepSeek-V4-Flash与DeepSeek-V4-Pro的预览版服务引擎中。”

技术背景与框架定位

DSpark推理加速框架的核心目标在于解决大语言模型在生产环境中面临的推理效率问题。所谓“推理效率”，指的是模型在接收到用户输入后，生成输出结果的速度和质量。DSpark通过优化这一流程，试图在高并发场景下维持快速响应能力。

具体而言，DSpark使用的推测解码技术允许模型在生成当前token（即文本的基元单位）的同时，并行预测多个后续token，从而减少计算等待时间。MTP-1作为单token推测解码基线，每次仅预测一个token；而DSpark通过多token并行预测机制，实现了输出速度的提升。

行业影响与部署进展

此次框架发布，直接将技术成果嵌入到DeepSeek的现有产品线中。DeepSeek-V4-Flash与DeepSeek-V4-Pro预览版的用户，将在实际使用中感知到生成速度的变化。

业内分析人士指出，推理加速框架的推出，对于大模型从研发走向规模化商业落地具有直接推动作用。在高并发环境下，用户等待时间每缩短一秒，都可能影响系统的部署成本和用户体验。

DSpark半自回归推测解码发布：DeepSeek-V4系列在线吞吐量最高提升661%

大语言模型生成文本时的自回归方式导致推理延迟随输出长度线性增长，成为AI对话系统响应偏慢的核心原因之一。针对这一瓶颈，DeepSeek研究团队近日在GitHub开源了DSpark半自回归推测解码技术，并在其V4-Flash与V4-Pro预览版引擎上完成在线部署实测。

技术背景：推测解码的两条路径与各自瓶颈

推测解码通过轻量级小模型快速生成候选token，再由完整大模型并行验证，可无损加速生成。但当前主流方案均存在制约：自回归式草稿模型（如Eagle3）逐token串行生成，接受率高但生成延迟随候选长度线性增长；并行式草稿模型（如DFlash）一次性产出全部候选token，生成延迟几乎与候选长度无关，但候选位置后移时接受率迅速衰减，导致目标模型计算资源浪费。

实验表明，两层Transformer深度的DSpark即可在所有测试领域上超过五层DFlash的接受长度。

DSpark的两项互补机制

半自回归架构：并行主干+轻量顺序模块

在候选生成阶段，DSpark采用基于DFlash改进的并行主干网络一次性产出所有候选位置的隐藏状态和基础logits，随后通过轻量级顺序模块逐token注入前缀依赖信息。该模块提供两种实现：马尔可夫头（仅依赖前一个token）和RNN头（通过循环状态累积完整前缀信息）。这种设计在参数效率上优于单纯堆叠并行层。

置信度调度验证：动态分配计算资源

模型在每个候选位置输出置信度分数，预测该token在后续被接受的存活概率。团队在验证集上通过逐位置温度缩放进行校准，使置信度与经验接受率对齐。硬件感知前缀调度器将验证长度选择建模为全局吞吐量最大化问题，为每个请求动态决定验证多长的候选前缀，优先将目标模型资源分配给全局存活概率最高的token。

调度器采用异步模式：以当前轮置信度排序候选token，但截断长度依据两轮前的历史置信度预测来确定，从而隐藏调度延迟并兼容CUDA图重放等系统框架。同时，物理执行与逻辑序列跟踪解耦，所有token展平为独立元素处理，通过稀疏注意力中的标记张量传递序列内依赖关系。

离线基准测试：三大任务中优于两派基线

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

位置级条件接受率分析显示：DFlash首位接受率较高，但从第2位开始迅速下降；Eagle3后续位置稳定但首位受限。DSpark继承了并行架构的首位容量优势，同时通过顺序依赖缓解了后续位置衰减。

生产部署与在线实测：DeepSeek-V4引擎实测数据

DSpark草稿模型与DeepSeek-V4-Flash及DeepSeek-V4-Pro预览版共同部署，并行主干含三个MoE层与滑动窗口注意力，最大候选块长度设为5，采用马尔可夫头作为顺序模块。训练阶段实施两项系统优化：并行训练时仅传递目标模型隐藏状态，将通信复杂度从O(V)降至O(d)；采用锚点定长序列打包策略，避免传统填充开销。

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

调度器在系统并发数较低时分配4至6个token的验证长度以利用空闲计算资源，随并发数上升平滑缩减验证长度，表现出负载自适应的验证预算分配能力。

局限与开源

DSpark的局限在于：即使后缀token被调度器截断，并行主干仍需为所有请求生成完整初始候选块，对于接受率较低的复杂查询，这部分草稿计算开销无法回收。目前DeepSeek已在GitHub的DeepSpec项目中开源DSpark、DFlash和Eagle3三种草稿模型的训练代码、评估脚本及模型检查点。