DeepSeek+北大的DSpark：换了一套"变速箱"，生成速度直接提升85%

6月27日，DeepSeek联合北京大学甩了一篇论文出来。

不是新模型。

是一套让现有模型跑得飞快的工程方案。论文署名里有个名字——梁文锋。DeepSeek创始人。

距离DeepSeek完成500亿人民币首轮融资，只过了一周。

融资后第一枪，不是发新模型吹参数多大、评测多高。是开源了一套叫DSpark的推理加速框架。论文全称很长——"DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation"。翻译成人话：让大模型生成token的速度提升60%到85%，高并发下吞吐量翻4倍。

我反复看了两遍论文。把里面最核心的东西拆出来，说清楚它到底做了什么、为什么厉害。

一、先算一笔账：DSpark到底做了什么

DSpark没有改模型架构。没有增加参数量。没有训练新模型。

它只做了一件事：改变了大模型"生成token"的方式。

打个比方。你有一台打印机的引擎没换，但换了一套更聪明的送纸机构——纸还是那张纸，墨还是那个墨，但走纸速度快了85%。

DSpark就是这样。它挂在DeepSeek-V4-Pro和V4-Flash上，不替换模型本身，只是在推理阶段换了一套更高效的调度策略。你用的还是那个V4，但回复速度肉眼可见地变快了。

论文、代码、训练工具、模型checkpoint——全部MIT协议开源。不是放了篇论文说"你照着实现吧"，是真的把整条生产线打包给了开发者。

二、要理解DSpark，先搞清楚大模型为什么"慢"

大模型生成文本的方式叫自回归生成。说人话：一个字一个字往外蹦。

比如让它回一句"今天天气不错，适合出门散步"。实际过程是：生"今"→把"今"喂回去→生"天"→把"今天"喂回去→生"天"→就这么16个字蹦完，跑了16次完整的前向传播。

每次前向传播都要把整个模型的参数从显存里读出来、算一遍。你512个字的回复 = 跑了512次完整计算。哪怕GPU每次只要10毫秒，也要等5秒。

而且这里有个更扎心的细节：显卡算力不是瓶颈，显存带宽才是。

GPU的计算单元很快，但从显存往计算单元搬数据很慢——这叫"带宽受限"（bandwidth-bound）。深度求索团队发现一个关键事实：解码10个token的显存搬移耗时，只比解码1个token多了那么一丁点。也就是说，每次只搬1个token，显存带宽被大量浪费了。

这就催生了一个想法：能不能一次多搬几个token？一次多预测几个？

三、老路子走不通：推测解码的两个致命问题

这个想法不是DeepSeek首创的。学界早就有个思路叫推测解码（Speculative Decoding）。

思路很朴素：用一个小模型（草稿模型）先猜一串token，然后把这一整串扔给大模型一次性验证。大模型说"前面5个对，第6个开始胡扯"——那就收下前5个，从第6个重新猜。一次验证多个token，比一个一个蹦快得多。

逻辑没问题。但落地时，两个现有方案各自摔在了一个坑里。

方案一：自回归草稿（Eagle3为代表）——串行生成，太慢

草稿模型也一个字一个字蹦。虽然每个字比大模型快，但串行本质没变。就像雇了个跑得快的人帮你领号排队——快了，但没解决问题本质。

方案二：并行草稿（DFlash为代表）——全部并行生成，但"后缀衰减"严重

一次前向传播输出一整块token。速度快到飞起。但因为没有前后依赖关系，后半截token质量塌方——"of course"能被猜成"of problem"。越到后面，草稿越离谱，大模型验完前面三四个就得扔掉重新猜。速度有了，效率没了。

这两个方案代表了推测解码的经典困境：要么生成得慢但准（自回归），要么生成得快但烂（并行）。过去就是二选一，没有第三条路。

DSpark说：谁说只能二选一？

四、第一张王牌：半自回归架构——并行主干 + 轻量串行修正

DSpark的核心创新，我拆成三层来讲。

第一层：并行主干保速度。

DSpark继承了DFlash的并行生成思路——一次前向传播输出一整块候选token。这是速度的根本保障。不串行，一次搞定。

第二层：轻量马尔可夫头补依赖。

这是整个架构最巧妙的地方。

DFlash的问题在于——并行生成的每个token位置是独立计算的，位置之间没有信息流动。"of course"被猜成"of problem"，就是因为预测第4个位置时完全不知道第3个位置输出的是"course"。

DSpark加了一个极轻量的马尔可夫序列头（Markov sequential head）——成本极小——只根据前一个token的状态，微调后续每一个位置的输出概率。这个头不是重新生成，是修正。把"of problem"修正回"of course"，把"temperature high"修正回"temperature of"。修正的代价很小，但效果明显。

第三层：两阶段设计让效率碾压堆叠。

论文里有个数据我反复确认：2层深度的DSpark草稿器，有效接受长度超过5层深度的纯并行DFlash。不是靠堆层数，是靠架构设计。更少的参数，更高的接受率。

接受长度直接决定了加速效果。接受长度越长，大模型一次验证能收下的token越多，加速效果越好。实测DSpark的接受长度比DFlash提升了16%-30%，而且块长越大优势越明显——长时间生成场景（写代码、写长文）的收益最大。

五、第二张王牌：置信度动态调度——让每一次验证都"花在刀刃上"

半自回归架构解决了"生成快且准"。但还有一个问题没解决：什么时候验证多少？

现有方案的做法很粗暴：草稿生成10个token，大模型就验证10个。哪怕后5个明显不靠谱——照样送进去浪费算力。这在单用户场景下影响不大，但在高并发场景（几十上百个用户同时请求）下，就是灾难性的算力浪费。

DSpark的解法，分三步，层层递进。

第一步：置信度头——草稿每出一个token就打一个分。

在草稿模型的输出层上，DSpark加了一个极轻量的置信度预测头。每生成一个候选token，这个头就预测它被大模型接收的概率。打一个0到1的分。

分数高的留在前面，分数低的排在后面。

第二步：顺序温度缩放校准——打掉AI的"自我感觉良好"。

这一步容易被忽略，但极其关键。

神经网络有个臭毛病：过度自信。它打分0.95的token，实际被大模型接收的概率可能只有0.87。这个偏差如果不校准，依赖置信度做调度决策就会系统性犯错——以为靠谱的其实不靠谱。

DSpark的解法叫顺序温度缩放（Sequential Temperature Scaling）。不是静态校准——是随着推理进行动态调整，边跑边学。论文实测，校准前误差3%-8%，校准后降到约1%。近乎完美的校准精度。

第三步：硬件感知动态调度——看菜下饭。

有了每个token的置信度分数，DSpark就能做"智能裁剪"：

• 低负载时：把验证块拉到最长，全力加速。反正GPU闲着也是闲着。

• 高并发时：自动裁剪掉低置信的候选token，只验证高分的部分。用少量速度换全局吞吐量。

而且这个调度完全在GPU上执行——不需要等CPU发指令。避免了CPU-GPU通信的延迟瓶颈。

对不同类型的任务，调度策略也不同。代码生成等确定性强的任务可以给更长的验证块（因为模型对token的置信度天然更高）；开放式闲聊则采用更保守的策略。不是一刀切，是看任务下菜。

六、实测数据：不是PPT加速

论文里有两组数据值得认真看。

单用户速度提升

• V4-Flash-DSpark: 60%-85% 加速

• V4-Pro-DSpark: 57%-78% 加速

在你一个人用的时候，回复速度接近翻倍。

高并发有效吞吐量

• 4倍提升。

当几百上千个请求同时涌入时，DSpark的动态调度把算力利用率推到了新高度。

还有一个细节值得一提：代码类任务的加速效果最明显。因为代码的语法结构确定性强，草稿模型的接受长度更长——一次能猜对更多token，加速效果更突出。

论文还验证了一个关键指标：全负载下速度稳定。不是低负载飞快、高并发就崩——DSpark的动态调度让速度曲线平滑过渡。这对线上服务来说比峰值加速更重要。

七、开源：不止论文，连训练工具都给了

DSpark不只是发了一篇论文。

它随论文一起开源的，是一个叫DeepSpec的训练库。里面包含三种草稿模型的完整训练代码：Eagle3、DFlash、DSpark。

而且不止支持DeepSeek自家的模型。DeepSpec支持Qwen3、Gemma4等主流开源架构。意味着你用Qwen搭的服务，也能训练一个DSpark草稿器挂上去，白嫖60%-85%的加速。

全栈MIT协议开源。

这个动作的信号很清楚：DeepSeek不只希望自己的服务快。它希望整个开源生态的推理效率都上一个台阶。不是把核心技术攥在手里当护城河，是放出去让大家一起用、一起改。

GitHub上线后迅速获得开发者关注，已经出现多个社区优化变种。DSpark正在从一个论文算法变成社区标准。

八、500亿融资后第一枪，为什么是推理加速？

回到那个问题。

刚拿了500亿人民币——创下中国AI创业公司单轮融资纪录——DeepSeek第一件事不是发"参数多十倍、评测全面碾压"的新模型，而是开源了一套推理加速框架。

这个选择传递了一个信号。

大模型竞争的下半场，不是在参数规模上继续堆料。是在单位算力能产出的token数量上卷。

你有一个700B参数的模型，我用一个400B的模型 + DSpark，在用户感知层面比你快85%。对用户来说，快就是好。

更重要的是，推理效率直接决定部署成本。推理快85%，意味着同一块GPU能服务85%更多用户。这是一笔实打实的账——不是技术炫技，是成本账。

再看梁文锋亲自署名。DeepSeek创始人一般不署名具体论文。这次破例——说明DSpark在DeepSeek战略版图里的位置，不只是"一篇好论文"，是一个技术路线级表态。

美国在卡高端GPU。DeepSeek在告诉你：没有最先进的卡，我可以把现有卡榨出多一倍的效率。

DSpark不是革命性算法。它没有发明新理论。它做的是把推测解码这条技术路线推到工程极致——半自回归架构、置信度调度、在线校准、硬件感知优化——每一个环节都抠到像素级。

这就是工程的魅力。

—— END ——

关注「亮虾哥」，一个连锁零售IT老炮的实话

👇 评论区聊聊

#DeepSeek #DSpark #大模型推理加速 #推测解码 #开源AI #AI基础设施