DSpark：DeepSeek 如何让大模型推理提速 85%

你大概有过这样的体验：跟 AI 聊天时，它一个字一个字往外蹦，像在"挤牙膏"。对于一个 700 亿参数的模型来说，生成一段 200 字的回复可能需要等上十几秒。

这背后的技术瓶颈叫自回归解码（Autoregressive Decoding）——大模型每生成一个 token（可以粗略理解为一个词或词片段），都要把前面所有 token 重新"读"一遍。生成 N 个 token，就要做 N 次完整的神经网络前向传播。模型越大，这个过程越慢。

就在两天前（6 月 27 日），DeepSeek 联合北京大学正式开源了一套名为 DSpark 的推理解码加速框架。它不改变模型本身，而是在推理引擎层面做优化，让 DeepSeek V4-Flash 的单用户生成速度提升了 60% 到 85%，V4-Pro 提升了 57% 到 78%。更关键的是，DeepSeek 创始人梁文锋亲自署名在论文作者名单中——这在融资后的 AI 公司里相当罕见。

这不是又一个"跑分新闻"。DSpark 解决的是一个所有大模型厂商都在头疼的工程问题：模型能力已经够强了，怎么让它跑得更快？

推测解码：让大模型"边猜边验证"

要理解 DSpark，先要理解它优化的是什么——推测解码（Speculative Decoding）。

传统的自回归解码是一个字一个字串行生成，慢但准确。推测解码的思路是：既然一个字一个字生成太慢，那能不能先"猜"出一串 token，然后一次性验证这批猜测对不对？

具体做法是引入一个小模型（叫 Draft Model，草稿模型），让它先快速生成一串候选 token（比如 5-8 个），然后大模型一次性并行验证这批 token。如果前 4 个猜对了，就接受这 4 个，从第 5 个开始重新猜。这样，一次大模型前向传播可以接受多个 token，相当于把串行的"逐字生成"变成了"批量确认"。

这个思路听起来很美好，但实践中有两个核心难题：

第一，草稿模型本身也不快。如果用一个小号的自回归模型做草稿，它本身也要一个 token 一个 token 地生成，抵消了并行验证的优势。如果用并行方式生成草稿（比如用 EAGLE、Medusa 这类并行草稿头），又会出现"后缀衰减"——越靠后的 token 质量越差，浪费算力在注定被拒绝的猜测上。

第二，验证长度不好定。猜太少了提速不明显，猜太多了后面的大概率被拒绝，白白浪费验证算力。而且在真实服务环境中，服务器负载随时变化，固定长度的猜测策略无法适应动态场景。

DSpark 就是针对这两个难题给出的解法。

两个互补机制：一个管"怎么猜"，一个管"怎么验"

DSpark 的核心设计由两个机制组成，分别解决上述两个问题。

机制一：半自回归生成（Semi-Autoregressive Generation）

这个机制试图同时拿到"并行生成"和"串行一致性"两个好处。它采用两阶段设计：

第一阶段是并行主干——用一个并行网络（类似 Medusa 或 EAGLE 的草稿头）快速生成整个草稿块的隐状态。这一步快，因为所有位置是同时计算的。

第二阶段是轻量顺序头——在并行主干的输出上叠加一个轻量级的串行模块（默认使用 Markov Head，马尔科夫头），逐个 token 注入前缀依赖信息，修正每个位置的概率分布。这一步的计算量很小，但它让草稿 token 之间的连贯性大幅提升，解决了并行草稿的"后缀衰减"问题。

打个比方：并行主干就像一个团队同时写出草稿的各个段落，速度快但段落之间可能不连贯；马尔科夫头就像一个编辑快速通读一遍，把段落间的逻辑衔接理顺。两步合在一起，既有速度又有质量。

机制二：置信度调度验证（Confidence-Scheduled Verification）

这个机制解决"验证长度怎么定"的问题。

传统做法是固定一个验证长度——比如每次都猜 6 个 token 然后全部验证。但不同情况下，最优验证长度是不同的：服务器空闲时可以多验证几个，服务器繁忙时应该少验证几个把算力留给其他请求。

DSpark 的做法是引入一个置信度头（Confidence Head），为每个草稿 token 评估一个"存活概率"——给定当前前缀，这个 token 被大模型接受的概率有多大。然后，一个硬件感知的前缀调度器（Hardware-Aware Prefix Scheduler）根据这些置信度分数、当前系统负载和实时吞吐量曲线，动态决定这次验证多少个 token。

这相当于把"固定预算"变成了"弹性预算"——系统忙的时候少猜几个，系统闲的时候多猜几个，始终在全局吞吐量最优的点上运行。

真实生产环境的数据

DSpark 不是停留在论文里的实验。它已经在 DeepSeek V4 的生产环境中上线部署，覆盖了 V4-Flash 和 V4-Pro 两个模型。

在真实流量验证下，数据相当亮眼：

特别值得注意的是"严格 SLA"（Service Level Agreement，服务等级协议）场景下的数据。当旧基线在高并发下接近崩溃时，DSpark 依然能维持有效吞吐，V4-Flash 的 TPS（Tokens Per Second）比旧方案高出 661%。这意味着在大规模线上服务中，DSpark 不仅让单个用户感觉更快，还让系统在高并发时更稳定。

为什么这件事重要？

大模型推理速度不只是一个"体验优化"问题，它直接关系到 AI 应用的商业可行性。

对于实时聊天场景，生成速度每提升 10%，用户等待焦虑就减少一分，留存率就上升一点。对于多轮 Agent 工作流（比如 AI 编程助手、自动化数据分析），一次任务可能涉及几十轮模型调用，推理加速直接缩短了端到端完成时间。对于企业级 API 服务，更高的吞吐意味着同一组 GPU 可以服务更多用户，直接降低单位推理成本。

DSpark 的价值在于，它不需要重新训练模型、不需要增加硬件——它是在现有模型和现有硬件之间"挤出了"大量性能空间。这是一种工程层面的效率优化，而不是资源层面的堆砌。

与其他推测解码方案的对比

推测解码并非 DSpark 首创。在它之前，学术界和工业界已经提出了多种方案，但各有短板。

EAGLE 系列采用并行草稿头，在目标模型最后一层隐状态上训练多个轻量预测头，并行生成候选 token。速度快，但并行生成的 token 之间缺乏依赖关系，越靠后的 token 质量下降越明显。

Medusa 的思路类似，在模型顶部添加多个"分支头"同时预测未来多个位置的 token。优点是无需额外模型，缺点同样是后缀位置预测精度不足。

SpecInfer 等方案使用独立的小型自回归模型作为草稿模型。草稿质量高（因为是串行生成），但草稿模型本身也需要多次前向传播，速度受限。

DSpark 的半自回归设计本质上是在这两条路线之间找到了平衡点：并行主干保证了生成速度，轻量顺序头弥补了并行带来的质量损失。而置信度调度验证则是 DSpark 独有的创新——此前没有方案将验证长度与实时系统负载动态绑定。

写在最后

大模型的竞争正在从"谁更聪明"转向"谁更快更便宜"。模型能力趋同之后，推理效率成为下一个核心战场。

DSpark 用两个精巧的机制——半自回归生成解决"草稿质量"，置信度调度验证解决"验证效率"——在不改动模型权重的前提下实现了最高 85% 的推理提速。它证明了一件事：在大模型时代，不只是做更大模型的公司有护城河，把推理工程做到极致的公司同样能建立技术壁垒。

对于开发者来说，DSpark 的论文和代码刚刚在 GitHub 上开源（deepseek-ai/DeepSpec），值得趁热深入研究其推测解码的工程实现。对于普通用户来说，你下次用 DeepSeek 聊天时感觉"怎么变快了"，背后大概就是这套框架在默默加速。