DeepSeek V4 推出 DSpark，推理速度飙升 80%

2026 年 6 月 27 日，DeepSeek 联合北京大学正式发布 DSpark 推理加速框架，在生产环境中将单用户生成速度提升了 60% 至 85%。相关模型权重和全栈开源框架 DeepSpec 已在 GitHub 和 HuggingFace 上公开发布。

背景：大模型推理的瓶颈

大语言模型在生成文本时采用 自回归（Autoregressive） 方式——每生成一个 token（词元）都需要一次完整的前向传播计算。这意味着输出越长，推理延迟就线性增长。这也是为什么我们在使用 AI 对话时，有时会看着它一个字一个字地往外蹦，心里着急。

推测解码（Speculative Decoding） 提供了一条巧妙的解决路径：用一个轻量级的「草稿模型」快速生成若干候选 token，再由完整的大模型通过一次并行前向传播进行批量验证。由于验证阶段可以并行计算，且拒绝采样机制严格保证了输出分布与原始模型完全一致，推测解码能够在无损生成质量的前提下大幅提升速度。

DSpark 的架构创新

DSpark 并非一个全新的模型，而是在 DeepSeek-V4-Pro 和 DeepSeek-V4-Flash 基础上引入的推测解码模块。它的核心创新包含两大机制：

1. 半自回归生成架构（Semi-Autoregressive Generation）

在此之前，推测解码的草稿模型主要有两种流派：

  • 自回归草稿模型（如 Eagle3）：逐 token 串行生成，依赖关系建模能力强、接受率高，但生成延迟随候选长度线性增长，实际部署只能用短候选块和浅层网络。
  • 并行草稿模型（如 DFlash）：一次前向传播产出全部候选 token，生成速度极快，但每个位置独立生成，无法建模 token 间的依赖关系。这导致越往后接受率越低，出现所谓的 「后缀衰减」（Suffix Decay） 现象。

DSpark 的设计很巧妙：它保留了并行骨干网络的高吞吐优势，计算量大的部分全部一次搞定；然后在高性能的并行输出之上，加了一个 极轻量的顺序模块（支持马尔可夫头和 RNN 头两种实现），快速为并行猜测注入局部的顺序依赖信息。就像写完文章快速通读一遍改几个连接词一样，花费极少的时间却换来了连贯性的大幅提升。

2. 置信度调度验证（Confidence-Scheduled Verification）

这是 DSpark 论文中最具工程价值的部分。DSpark 给每个草稿位置加了一个 置信度头（Confidence Head），预测该 token 最终被接受的概率。然后有一个硬件感知的调度器，根据实时的系统负载和每个位置的置信度，动态决定这次到底送几个 token 给大模型验证。

简单来说就是：

  • 闲的时候：多验证几个，反正算力闲着也是闲着
  • 忙的时候：只验证那些高置信度的 token，不做无用功

这个调度是在生成草稿的过程中就完成的，保证不会引入选择偏差。

基准测试数据

离线基准测试

在 Qwen3 系列（4B、8B、14B）和 Gemma4-12B 作为目标模型的离线测试中，DSpark 的表现如下：

对比对象 平均接受长度提升
对比 Eagle3（自回归草稿） 26.7% ~ 30.9%
对比 DFlash（并行草稿） 16.3% ~ 18.4%

生产环境实测

DSpark 已经在 DeepSeek-V4-Flash 和 DeepSeek-V4-Pro 的真实线上流量中部署运行。相比此前生产环境采用的单 token 推测解码基线 MTP-1，在维持相同总体吞吐量的情况下：

V4-Flash 引擎：

  • SLA 80 token/s 时：吞吐量提升 51%
  • SLA 120 token/s 时：MTP-1 基线已接近崩溃，DSpark 实现了 661% 的吞吐量优势
  • 单用户生成速度提升：60% ~ 85%

V4-Pro 引擎：

  • SLA 35 token/s 时：吞吐量提升 52%
  • SLA 50 token/s 时：吞吐量提升 406%
  • 单用户生成速度提升：57% ~ 78%

核心结论：DSpark 不仅在日常情况下提升了推理速度，在高并发场景下的表现尤为突出——高峰期大家一起用的时候，不会再感觉到明显的卡顿和等待。

开源：DeepSpec 全栈框架

随 DSpark 一同开源的还有 DeepSpec，一个用于训练和评估推测解码草稿模型的全栈代码库，已采用 MIT 许可证开源。

项目地址

DeepSpec 功能

DeepSpec 包含三大流程：

  1. 数据准备：下载提示词数据、使用推理引擎对目标模型重新生成答案、构建目标缓存
  2. 训练：支持 DSpark、DFlash、Eagle3 三种草稿模型算法，默认配置面向单节点 8 卡 GPU 环境
  3. 评估：涵盖 GSM8K、MATH500、AIME25、HumanEval、MBPP、LiveCodeBench、MT-Bench、Alpaca、Arena-Hard-v2 等多个基准

⚠️ 注意：以默认的 Qwen/Qwen3-4B 配置为例，目标缓存体积可达约 38 TB，使用前请充分评估存储资源。

支持的草稿模型

当前 DeepSpec 内置三种草稿模型实现：

  • DSpark（本方案，半自回归 + 置信度调度）
  • DFlash（纯并行生成）
  • Eagle3（自回归生成）

支持的目标模型系列：Qwen3（4B/8B/14B）和 Gemma（4-12B）。

局限性

论文中也坦诚指出了 DSpark 的局限性：

对于本身就特别复杂、接受率天然低的查询，草稿阶段的固定计算开销可能无法收回。未来可能会引入难度感知的早停机制，让这类查询直接绕过完整的草稿生成，以进一步优化效率。

小结

DSpark 的发布标志着大模型推理优化进入了一个新的阶段——不再只是「谁的模型更聪明」的竞争，推理效率、服务成本和用户体验这些工程层面的因素权重越来越大。

用户可能感知不到 DSpark 的存在，但每次用 DeepSeek 感觉回复变快了、高峰期不转圈了，背后就是这些工程改进在默默起作用。

而 DeepSeek 选择将生产环境验证过的技术细节和模型权重开源出来，对整个 AI 社区都是一件好事。不是每家公司都愿意这么做的。

参考资料：DSpark 技术报告、DeepSpec GitHub 仓库、DeepSeek-V4 HuggingFace Model Card