北大与DeepSeek联合开源DSpark框架，高并发下生成速度提升超60%

IT之家 6 月 27 日消息，今日，DeepSeek 联合北京大学正式发布 DSpark 推理加速框架，旨在解决大语言模型在高并发生产环境中的推理效率瓶颈。

该框架已部署于 DeepSeek-V4-Flash 与 DeepSeek-V4-Pro 的预览版服务引擎中，相比此前生产环境采用的单 token 推测解码基线 MTP-1，在同等吞吐量水平下可将单用户生成速度提升 60% 至 85%。相关论文、训练代码等已在 GitHub 上开源。

大语言模型生成文本时采用自回归方式，每生成一个新 token 都需要一次完整的前向传播，推理延迟随输出长度线性增长，这是目前 AI 对话系统响应偏慢的核心原因之一。推测解码技术提供了一条解决路径：用一个轻量级的小模型快速生成若干候选 token，再由完整规模的大模型通过单次并行前向传播进行批量验证，接受其中符合目标分布的连续前缀。由于验证阶段可并行计算，且拒绝采样机制严格保证了输出分布与原始模型一致，推测解码能够在无损生成质量的前提下提升速度。

但推测解码的实际加速效果受制于两个因素：一是候选生成的质量，二是验证阶段对目标模型计算资源的占用。当前主流方案分为两派。自回归式草稿模型（如 Eagle3）逐 token 串行生成候选序列，依赖关系建模能力强、接受率高，但生成延迟随候选长度线性增长，迫使实际部署中只能使用短候选块和浅层网络。并行式草稿模型（如 DFlash）则在一个前向传播内一次性产出全部候选 token，生成延迟几乎与候选长度无关，理论上支持更长的候选块。

然而并行生成每个位置时无法依赖块内先前已采样的 token，导致随着候选位置后移，不同语义路径相互冲突、接受率迅速衰减，长候选块的后缀 token 往往在验证阶段被大量拒绝，造成目标模型计算资源的浪费。此外，在并发请求较多的生产环境中，固定长度的验证策略会迫使目标模型将宝贵的批量处理能力消耗在高拒绝风险的尾部 token 上，导致整体吞吐量下降。

DSpark 的设计围绕上述两个瓶颈展开，提出了两项互补机制。在候选生成阶段，DSpark 采用半自回归架构：计算量较大的并行主干网络（基于 DFlash 改进）一次性产出全部候选位置的隐藏状态和基础 logits，随后由一个轻量级顺序模块逐 token 注入前缀依赖信息。该顺序模块提供两种实现 —— 仅依赖前一个 token 的马尔可夫头，以及通过循环状态累积完整前缀信息的 RNN 头。

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

在验证调度阶段，DSpark 引入置信度调度验证机制。模型在每个候选位置输出一个置信度分数，预测该 token 在给定此前所有 token 均被接受的条件下的存活概率。受训阶段完成后，团队在验证集上通过逐位置温度缩放对置信度进行校准，使其与经验接受率对齐。

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

在离线基准测试中，研究团队选取了 Qwen3 系列（4B/8B/14B）和 Gemma4-12B 作为目标模型，对比自回归草稿模型 Eagle3 与并行草稿模型 DFlash。

在数学推理（GSM8K、MATH500、AIME25）、代码生成（MBPP、HumanEval、LiveCodeBench）和日常对话（MT-Bench、Alpaca、Arena-Hard）三类任务上，DSpark 的平均每轮接受长度均优于两类基线。

以 Qwen3-4B 为例，DSpark 相比 Eagle3 提升约 30.9%，相比 DFlash 提升约 16.3%。进一步的位置级条件接受率分析显示，DFlash 在首位的较高接受率源于并行架构可支撑更深网络带来的容量优势，但从第 2 位开始接受率迅速下降；Eagle3 虽然后续位置保持稳定甚至上升，但首位接受率受限于浅层网络。DSpark 继承了并行架构的首位容量优势，同时通过顺序依赖缓解了后续位置的衰减。

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

训练阶段，研究团队在内部框架中实现了两项系统优化：其一，并行训练时仅传递目标模型的隐藏状态而非完整词表 logits，将通信复杂度从 O (V) 降至 O (d)；其二，采用锚点定长序列打包策略，将训练序列中随机采样的多个预测块压缩为密集批次，避免传统填充带来的计算和内存开销。

在实际系统集成中，DSpark 的调度器面临两个工程约束：

• 其一是 CUDA 图重放和零开销调度要求下一轮批处理大小在当前轮完成前即已确定，同步调度会导致 GPU 流水线停滞。团队将调度器改造为异步模式：以当前轮置信度排序候选 token，但截断长度（即批次容量上限）依据两轮前的历史置信度预测来确定，从而隐藏调度延迟并兼容现有系统框架。
• 其二是动态变长验证前缀会导致标准解码内核因填充和负载不均而利用率下降。团队将物理执行与逻辑序列跟踪解耦，将所有 token 展平为独立元素处理，通过稀疏注意力中的标记张量传递序列内依赖关系，仅需修改索引注意力与压缩内核即可支持动态调度。

在线生产环境实测中，DSpark-5 与原有的单 token 基线 MTP-1 在真实用户流量下进行了对比。IT之家注意到，在 V4-Flash 引擎上，当系统保证单用户生成速度不低于 80 token/s 时，DSpark 的聚合吞吐量相比基线提升 51%；当 SLA 收紧至 120 token/s 时，单 token 基线已接近运行边界，DSpark 在维持可用并发批处理的前提下实现了标称 661% 的吞吐量优势。

在 V4-Pro 引擎上，35 token/s 的 SLA 下 DSpark 吞吐量提升 52%，50 token/s 的 SLA 下提升 406%。在匹配的实际吞吐量水平下，DSpark 将单用户生成速度提升了 57% 至 85%。

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

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

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

参考资料：

• GitHub：https://github.com/deepseek-ai/DeepSpec
• Hugging Face：https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark