北大与DeepSeek联合开源DSpark：破解AI大模型高并发推理瓶颈，速度提升60%至85%
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 继承了并行架构的首位容量优势，同时通过顺序依赖缓解了后续位置的衰减。