DeepSeek发布DSpark推理加速框架，显著提升大

模型智能水平的比拼，确实是当下最热闹的赛道。但有一件事，没那么光鲜，却可能更关键——怎么让大模型跑得更快。

2026年6月28日，DeepSeek在开源平台放出了一个新框架，名叫DSpark，相关论文也同步公开。这玩意儿瞄准的不是又刷了多少分，而是高并发场景下大模型推理效率那块最难啃的骨头。

这项工作是DeepSeek和北京大学一起做的，创始人梁文锋也列名作者。开源做得相当彻底——DSpark的模型权重全量放出，还配套发布了一个叫DeepSpec的训练代码库，专攻推测解码方向。

先简单说一下瓶颈在哪。问题其实很经典：大模型的自回归生成机制，本质上是一个词一个词往外蹦。每一步都要把所有已经生成的词元再算一遍，输出越长，延迟就非线性飙升。GPU资源利用率上不去，用户那边等得心焦。实时对话助手、多轮智能体协作这类对延迟极度敏感的场景，尤其吃痛。

目前主流的优化路数主要有两条：一条靠自回归结构的草稿模型，另一条靠并行架构的草稿模型。各有各的尝试，但始终在生成质量和系统效率之间左右为难，更别提动态适应负载变化了——这个能力，基本是空白。

DeepSeek给出的答案，是DSpark这个推测解码框架。它的核心思路是半自回归生成架构。怎么理解呢？就是保留了并行主干的高吞吐特性，同时额外引入一个轻量级的串行模块，逐词元地把前缀依赖信息注入进去。这个模块有两种实现方式：一种叫马尔可夫头，只依赖前一个词元；另一种叫RNN头，通过循环状态持续累积完整前缀信息。两种方案，各有侧重。

实验数据挺能说明问题。在同等模型深度下，只用两层Transformer的DSpark，在所有测试任务上都超过了五层结构的DFlash模型——后者可是多了整整三层的深度。这意味着什么？架构设计上的代差，比单纯堆层数更管用。

目前DSpark已经集成到DeepSeek-V4的在线服务系统里，基于真实用户请求流量完整跑了一遍实测。结果很直接：在保持吞吐量不变的前提下，相比现有生产环境用的基线系统MTP-1，用户端文本生成速度提升了60%到85%。不是一个小数。

更值得注意的是，DSpark已经在多个第三方模型上完成了适配验证。拿Qwen3系列模型来说事，在4亿、8亿、14亿三种参数规格下，单轮平均可接受词元长度——这个是推测解码场景下评估效率的核心指标——相比自回归草稿方案分别提升了30.9%、26.7%和30%；相比并行草稿方案，也分别提升了16.3%、18.4%和18.3%。跨模型的泛化能力，基本算是验证扎实了。

总的来说，DSpark这个工作，方向选得很实际——不追求理论上的最优，而是扎扎实实解决线上部署最头疼的效率问题。开源加实测，这套打法确实让人期待后续的落地效果。