DeepSeek联合北大开源DSpark：高并发场景推理速度提升60%-85%

DeepSeek再次出手：联合北大破解大模型推理难题

6月27日，DeepSeek联合北京大学正式发布DSpark推理加速框架。梁文峰本人担任通讯作者，框架已部署于DeepSeek-V4-Flash与DeepSeek-V4-Pro预览版的生产推理引擎。论文、训练代码和模型检查点同步在GitHub的DeepSpec项目中开源。

Fireworks AI的CTO、PyTorch核心维护者Dimitro在看到论文后自发撰写了技术解读博客，这在AI圈并不常见——通常只有真正解决了痛点的工作才会引发这类自发响应。

这次发布的核心数据是：相比此前的生产基线MTP-1，单用户token生成速度提升60%-85%，高并发场景下吞吐量提升最高超过600%。数字很大，但要理解为什么这很难做到，得先看清楚大模型推理到底卡在哪里。

为什么AI对话这么慢？推理效率的真正瓶颈

大模型生成文本的方式叫自回归：每次只生成一个token，生成完了才能生成下一个。输出100个token，就要做100次完整的前向传播。这意味着延迟随输出长度线性增长，没有捷径。

很多人以为是GPU算力不够，实际上瓶颈在显存带宽。每生成一个token，系统都要把整套模型权重从显存搬到计算单元，而当前GPU的算力增长远超显存带宽的增长速度。结果是：大部分时间不是在算，而是在等数据搬运。一张高端GPU，约90%的推理时间花在数据移动上。

推测解码（Speculative Decoding）就是为了绕开这个限制而生的。基本思路是：用一个小的草稿模型快速生成一批候选token，再让大模型一次性批量验证。批量验证能充分利用GPU的并行计算能力，等于把多次"一个token一次传播"压缩成"多个token一次传播"。如果草稿质量够高、大模型接受率够好，整体速度就能显著提升。

问题在于，如何让草稿模型又快又准。

快而不准 vs 准而慢：推测解码的经典两难

目前主流的草稿模型分两类，各有各的问题。

自回归式草稿模型（代表：Eagle3）：逐token串行生成候选序列，因为每个位置都能看到前面的token，语义连贯性好、接受率高。但生成速度随候选长度线性增长，速度瓶颈明显，只能维持较短的候选块。

并行式草稿模型（代表：DFlash）：一次性生成所有候选位置，速度快。但问题来了——生成第5个候选token时，模型还不知道前面4个位置会被采样成什么，只能独立预测。这会导致"后缀衰减"：越靠后的位置错误越多，接受率断崖式下降。

在高并发场景下，问题更复杂。固定验证长度的策略很难适应不同请求的实际需求：对简单请求分配太多验证长度是浪费，对复杂请求分配太少又拿不到速度收益。批处理能力就这样被低效策略白白耗掉了。

DSpark要解决的，就是在这两个维度上同时做好。

DSpark如何"鱼与熊掌兼得"？两大核心机制

半自回归生成架构：融合两派优势

DSpark的草稿模型不是纯并行也不是纯串行，而是两层叠加。

第一层是并行骨干网络（基于DFlash改进），一次性扫描输入，生成所有候选位置的隐藏状态和初始概率分布。速度优势在这里建立。

第二层是轻量级顺序模块，逐token顺序注入前缀依赖信息。具体实现是马尔可夫头或RNN头——每个位置在并行骨干的基础上，额外看一眼前一个位置被采样后的状态，据此微调当前位置的概率。

举个例子：假设候选序列第一个位置预测了"off"，第二个位置并行骨干给出的初始分布里"problem"概率最高。顺序模块看到"off"被采样之后，会把第二个位置的概率往"cost"方向调整，因为"off-cost"比"off-problem"更符合语言习惯。这个调整很轻量，但对接受率的影响显著。

实验数据验证了这个设计的效率：两层DSpark的平均接受长度，超过了五层DFlash。参数没有增加多少，准确率却上去了。与Eagle3相比，平均接受长度提升26%-31%；与DFlash相比，提升16%-18%。

置信度调度验证机制：动态资源分配

光生成得好还不够，还得聪明地决定每个请求验证多少个候选token。

DSpark为每个候选位置输出一个置信度分数，代表该位置被大模型接受的估计概率。通过逐位置温度缩放校准，置信度与真实接受率的误差被压缩到1%以内——也就是说，模型说"这个位置80%会被接受"，实际上就真的是80%左右。

有了可靠的置信度之后，调度器做的事情是：把所有并发请求的候选token按存活概率全局排序，再根据当前系统负载动态决定每个请求的验证长度。低并发时，给每个请求分配4-6个token的验证长度；高并发时，自动收窄。整个调度逻辑跑在GPU内部，不需要CPU参与，调度延迟基本为零。

这个机制的价值在于：系统不再需要人工设置验证长度的超参数，也不需要在不同负载场景下手动调整。边跑边校准，自动适应。

数据说话：实验室测试和真实部署的表现

离线基准测试

测试覆盖了Qwen3系列（4B/8B/14B）和Gemma4-12B四个模型，任务包括数学推理（GSM8K、MATH500、AIME25）、代码生成（MBPP、HumanEval、LiveCodeBench）和日常对话（MT-Bench、Alpaca、Arena-Hard）。

以Qwen3-14B为例，DSpark相比Eagle3平均接受长度提升约30%，相比DFlash提升18.3%。在代码生成和数学推理任务上提升幅度更大，因为这类任务输出序列长、局部语义依赖强，正好是半自回归架构的优势区间。

生产环境实测

生产数据是最有说服力的部分。DeepSeek在V4-Flash和V4-Pro两个引擎上都给出了对比MTP-1基线的结果：

高SLA场景下的提升幅度远高于低SLA，这是因为高速响应要求下批处理空间更紧张，动态调度的优化效果被放大了。

在匹配相同吞吐量水平的前提下，单用户token生成速度提升57%-85%。这两个数字不是取其一，而是同时成立——系统既能服务更多并发用户，单个用户等待的时间也更短。帕累托改进：吞吐量和延迟同时改善，没有取舍。

魔鬼在细节：DSpark的工程打磨

算法设计是一回事，能不能在生产环境跑通是另一回事。DSpark在工程实现上做了几个关键处理。

训练阶段的通信优化：草稿模型训练时，主模型和草稿模型之间需要传递中间状态。如果传递完整词表的logits，通信量是O(V)，V是词表大小（通常十几万）。DSpark改为只传递隐藏状态，通信复杂度降至O(d)，d是隐藏层维度（通常几千）。这一个改动让分布式训练的通信开销大幅下降。训练时还采用了锚点定长序列打包策略，避免因序列长度不一致带来的填充浪费。

调度器的异步设计：用当前轮的置信度排序，但截断长度的决策依据历史预测——两件事错开执行。这样调度计算不会出现在关键路径上，延迟被完全隐藏。

动态变长支持：推测解码的一个麻烦是每轮验证后序列长度都会变化，不同请求的序列长度还各不相同。DSpark通过将物理执行与逻辑序列跟踪解耦，配合稀疏注意力传递块内依赖关系，让系统能正确处理变长输入，不需要对齐填充。

在线校准：部署后系统会持续统计真实接受率，与置信度预测值对比，动态修正校准参数。这保证了长期运行中置信度估计不会漂移。

这些工程细节单独拿出来都不算新技术，但把它们组合成一个稳定运行的生产系统，需要对整条链路有深入理解。

全链路开源：DSpark给行业送了什么

DeepSeek在GitHub的DeepSpec项目中开源了完整内容：DSpark、DFlash、Eagle3三种草稿模型的训练代码、评估脚本和模型检查点。不是只开源推理代码，而是从头训练到评估全链路都给了出来。

支持的外部模型包括Qwen3、Gemma等，不限于DeepSeek自家模型。对其他团队来说，这等于直接拿到了生产级推理加速工具链，不用从零开始复现。

当然也有局限。并行主干的设计决定了，无论某个请求的查询有多难，系统都要先生成完整的初始候选块。对那些草稿质量本来就很差的复杂查询，这部分计算开销无法回收。目前没有机制在生成候选之前提前判断"这个查询值不值得做推测解码"。

从算法到系统：DSpark说明了什么问题

DSpark用到的每一个技术组件——半自回归生成、置信度打分、动态调度——都不是全新发明。推测解码本身是老概念，马尔可夫头和RNN头也有先例，温度缩放校准是标准操作。

DSpark的贡献在于把这些东西整合成一个端到端可部署的生产系统，并且在已经高度优化的生产基线MTP-1之上再叠加出60%-85%的速度提升。后者尤其困难——在基线已经很强的情况下继续做增量优化，比从头做一个系统要难得多，因为容易摘的果子都已经摘完了。

梁文峰亲自挂名通讯作者这件事本身也值得关注。这不是常规的工程优化报告，而是在说：这类系统级工程工作在DeepSeek内部被当作核心研究方向对待，而不只是产品团队的技术债。

大模型推理加速这个方向，单点算法突破的红利正在收窄。DSpark的路径——把半自回归架构、置信度估计、硬件感知调度、在线校准整合成一个互相咬合的系统——大概率是接下来这个领域真正有效的做法。