DeepSeek 推理提速 85%，DSpark 做对了哪两件事

如果你最近用过 DeepSeek 的在线对话，有没有感觉它"反应"变快了？

这不是错觉。

就在近日，DeepSeek 上线了一个名为 DSpark 的推理加速系统。官方数据很直接：在真实线上流量下，每位用户的生成速度提升了 60% 到 85%。

不是实验室里的 benchmark 游戏，是实打实能感知到的变化。

这背后是一个困扰整个行业已久的问题——大模型生成文字，本质上是一个字一个字往外"蹦"的过程。每蹦一个字，模型就要完整跑一遍前向计算。输出越长，等待越久。这个瓶颈卡了业界很久，而 DSpark 用了两把手术刀，精准切开了它。

大模型"说话"为什么那么慢

要理解 DSpark 的价值，得先理解大模型为什么慢。

LLM 生成文本的方式，可以想象成一个人在台上逐字念稿子。每念一个字，都要停下来把整篇稿子重新理解一遍，才能决定下一个字念什么。这种"一个接一个"的模式叫自回归生成，天然就是串行的。

业界早就有一个解法叫推测解码：找一个"助手"先快速猜出一串可能的字，然后让大模型一次性验证。猜对的部分直接通过，猜错的扔掉重来。助手猜得越准，加速效果越好。

但这个方案有两个长期解决不了的硬伤。

第一，助手猜字的质量不稳定。并行生成速度很快，但每个位置彼此独立，前面猜什么后面完全不知道。于是经常出现"我喜欢吃苹果手机"这种前后矛盾——单个词都对，连起来就崩。而且猜得越长，后半段质量越差，这个现象叫后缀衰减。

第二，验证环节的盲目消耗。助手一口气猜出 16 个字，但其中可能有一大半都会被拒绝。把这些字打包送去大模型验证，在高并发场景下，大模型宝贵的算力就被这些"大概率被否"的候选字白白占满。结果不是加速，而是拖慢整体吞吐。

DSpark 要解决的，正是这两个核心瓶颈。

第一刀：半自回归——给并行加上"记忆"

DSpark 的第一个设计非常巧妙：它不抛弃并行的速度优势，但给并行加了一个轻量级的"记忆模块"。

具体来说，DSpark 保持一个并行主干（叫 DFlash）作为主力，一次性跑完前向计算，生成所有位置的候选 logits。然后在后面增加一个极轻的顺序头——可以是马尔可夫头或 RNN 头——在最终采样的时候，把"前一个字是什么"这个信息注入进来。

这个改动很小，但效果惊人。

实验数据显示，在 Chat 任务上，传统并行方案从第 1 个位置到第 7 个位置，候选字的存活率从 0.72 一路跌到 0.63；而加了顺序头的 DSpark，全程维持在高位，几乎没有衰减。仅仅 2 层的 DSpark，性能已经超过了 5 层的纯并行方案。

一点点"顺序信息"，换来的是草稿质量的大幅提升。

第二刀：置信度调度——给系统装上"红绿灯"

草稿质量的问题解决了，但还有一个系统层面的问题：怎么决定验证多少个候选字？

传统方案是固定长度，比如每次验证 2 个。弊端很明显——系统空闲时验证太少浪费机会，系统繁忙时验证太多反而堵塞。

DSpark 的做法是：额外训练一个置信度估计头，对每个候选字预测一个"前缀存活概率"——就是如果前面的字都通过了验证，这个位置的字有多大可能也能通过。

但神经网络天然会过度自信，预测的概率往往偏高。DSpark 引入了一个叫顺序温度缩放的校准方法，把预测概率和真实接受率对齐，校准误差从百分之几压到了约 1%。

然后登场的是一个硬件感知调度器。它实时监测系统负载，结合每个字的生存概率，动态决定每个请求该验证多少个字。负载低时多验证几个，高并发时果断剪掉低置信的尾巴。

这样一来，验证预算从以前的固定 2 个，变成了动态的 4 到 6 个。关键是不需要"偷看"未来的信息——调度器用的是两步前的历史数据来做决策，严格保证了推理结果和原始模型完全一致。

线上效果：不只是更快，是更稳

DSpark 已经部署在 DeepSeek-V4-Flash 和 V4-Pro 的生产服务中，上线两周就完全替换了上一代系统。

几个硬数据：在中等服务标准下，V4-Flash 的总吞吐提升了 51%；在高标准下，上一代系统已接近崩溃，而 DSpark 的吞吐高出 661%——这个数字的意义不在于倍数本身，而在于它把一个"不可能完成"的服务档位变成了现实。

对每个用户来说，最直观的感受就是同样的模型能力下，每秒钟能看到的字数多了 60% 到 85%。

这正是 DSpark 的价值：不是让单个用户更快一点，而是把整个服务的速度-吞吐边界往外推了一圈，让过去无法兼顾的性能组合成为了可能。

开源了，但不止于代码

DeepSeek 同步开源了 DSpark 的检查点和 DeepSpec 训练仓库，包含 Eagle3、DFlash 和 DSpark 三套实现。如果你在做推理加速相关的工作，这些代码值得花时间研究。

从工程角度看，DSpark 的设计思路有一种难得的克制——不追求大而全，而是精准定位两个核心瓶颈，用最小的架构改动解决最大的问题。半自回归头的额外延迟微乎其微，但有效接受长度提升了 30%。

这种"四两拨千斤"的感觉，是工程上最让人舒服的状态。

当然，它也有局限。对于那些本身接受率就很低的复杂请求，并行草稿阶段的计算是注定浪费的，目前没有办法跳过。论文也承认，未来如果能做到"难度感知的提前退出"，还有优化空间。

但就现阶段而言，DSpark 已经是推测解码领域相当完整的工程实践——算法、系统、校准、部署，每一层都做得扎实。

对于关心大模型落地的人来说，这是一个值得关注的信号：模型能力军备竞赛之外，推理效率的优化正在成为新的主战场。

如果你觉得有收获，欢迎评论、推荐给需要的朋友，还没关注的话点个关注，每周分享 AI 前沿技术解读。