单用户提速 60-85% ！DeepSeek 联手北大开源 DSpark ，突破推理加速工程问题

把算力花在刀刃上，梁文锋再次大幅降低推理优化门槛。

    作者丨樊天骄

    编辑丨马晓宁

2026年6月27日，AI圈迎来了一则重磅消息，DeepSeek联合北京大学正式发布了DSpark推理加速框架，并同步开源了支撑该版本的全栈推测性解码框架DeepSpec。

这是DeepSeek在完成500亿元融资后首次放出的开源新成果。在DeepSeek-V4-Pro-DSpark和DeepSeek-V4-Flash-DSpark两款模型上，DSpark将单用户生成速度提升了60%至85%。

梁文锋本人署名、联合北京大学完成的论文《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》同步上传。雷峰网(公众号：雷峰网)

论文、代码库、模型已经全部开源：

论文：

https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf

开源代码库：

https://github.com/deepseek-ai/DeepSpec

模型下载：https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark

01

DSpark 如何让草稿模型又快又准

先澄清一个容易误解的点：DeepSeek-V4-Pro-DSpark 不是全新架构的模型，而是在 DeepSeek-V4-Pro 基础上引入了推测性解码模块。这次更新的重点在于工程落地，不是模型能力本身的迭代。

说人话就是：模型还是那个模型，但让它跑起来的方法变聪明了，所以你用起来会感觉明显变快。

要理解 DSpark 的价值，得先搞清楚它在解决什么问题。

▎推测解码是什么？

大语言模型生成文本时采用自回归方式：每生成一个新 token 都需要一次完整的前向传播，推理延迟随输出长度线性增长。这是目前 AI 对话系统响应偏慢的核心原因之一。

推测解码（Speculative Decoding）提供了一条解决路径：

第一步，先用一个轻量级的小模型，快速生成若干候选token（草稿模型）

第二步，再由完整规模的大模型，通过单次并行前向传播进行批量验证这些token

第三步，接受其中符合目标分布的连续前缀

由于验证阶段可并行计算，且拒绝采样机制严格保证了输出分布与原始模型一致，推测解码能够在无损生成质量的前提下提升速度。

这个思路不是 DSpark 发明的，这两年一直有人在做。但是这次，Deepseek 精准解决了这个技术路线在实际落地中遇到的两个关键瓶颈。雷峰网

▎DSpark 的破局思路

早期的草稿模型是自回归的，也就是跟大模型一样一个字一个字猜。这样猜出来的质量确实高，但小模型自己猜也要时间，猜得多了草稿本身就变慢了，得不偿失。

举个例子：你让 AI 写一段 500 字的回复，它需要连续做 500 次完整计算，每次只能输出一个字。就算每次计算只要 10 毫秒，总共也要 5 秒。用户感知到的就是"转圈等待"。

后来有人想到了并行草稿，一次前向传播直接猜好几个字，草稿速度一下就上来了。但新的问题来了：因为每个位置是独立猜的，没有考虑字跟字之间的依赖关系。

"of course" 和 "no problem" 都是合理的回复开头，但并行草稿可能会猜出 "of problem" 这种四不像组合。越往后猜，这种错误累积越严重，接受率断崖式下跌。大家把这个现象叫"后缀衰减"。

过去通行做法是：草稿模型生成多少个 token，就原封不动地提交多少个 token 给大模型验证，这是一种“全量验证”模式。但因为越往后的字越不靠谱，验证这些低置信度的字是要占用算力的。

把低置信度的 token 送去验证，看似只是“浪费了一点算力”，但在真实的、高并发的生产系统中，这种浪费是灾难性的系统性损耗。

为了解决这两大问题，DSpark 作了两套核心设计：半自回归生成架构和置信度调度验证。

半自回归生成架构非常具有创新性，其主要针对的是并行草稿的后缀衰减问题。这种并行主干 + 轻量串行头的两阶段设计，可以在在几乎不牺牲生成速度的前提下补齐块内的 Token 依赖，直接拉高每轮验证的有效接受长度。

并行主干可单次前向输出全块基础 Logits 与隐藏态，草稿生成的核心延迟与纯并行方案持平，完整保留了并行架构块长大、生成快的速度优势。

轻量串行模块则是补齐短板的关键。DSpark 在并行输出的基础上，叠加了一个极简的串行单元（默认采用 Markov head），为每个位置的 Token 补充前缀依赖的转移偏置，修正并行独立生成导致的多模态语义冲突，大幅缓解了尾部 Token 接受率下滑的问题。

从速率角度看，这套设计收益极高：串行模块开销极小，却让 Qwen3 系列模型的平均接受长度相对 DFlash 提升 16.3 % - 18.4 %，相对自回归的 Eagle3 提升 26.7 % - 30.9%。

2 层深度的 DSpark，有效接受长度甚至超过 5 层深度的纯并行 DFlash。这说明局部自回归的速度 - 参数效率，远高于单纯堆叠并行层。

这种优势还会随着块长放大：当草稿块长从 7 增加到 15 时，DSpark 相对 DFlash 的接受长度优势从 15% - 18% 扩大至 22% - 30%。换言之，并行架构的长块速度潜力，此前一直被后缀衰减封印，而半自回归设计将其彻底释放了出来。

如果说半自回归解决了 “生成得更有效”，那么置信度调度解决的就是 “验证得更聪明”。从源头杜绝无效 Token 占用宝贵的验证算力，让大模型的每一次前向计算都产出最大价值，尤其能稳住高并发场景下的生成速度。

▎这套机制分为两层设计：

第一层是置信度预判。 DSpark 在草稿模型上加了一个轻便的打分模块（置信度头 Confidence Head ），草稿每生成一个候选 Token，它就实时预测该 Token 的条件接受概率（Conditional Acceptance Probability）。

不过 AI 打分天生容易 “自我感觉良好”，估出来的通过率往往偏乐观。所以 DSpark 还搭配了 “顺序温度缩放（STS）” 校准方法，把对草稿的打分的误差从原来的 3%-8% 下降到约 1% ，让概率预估变得足够精准，给后续的调度调整提供了可靠的判断依据。

第二层，是硬件感知动态调度。基于预测试的引擎吞吐曲线，将验证长度选择转化为全局吞吐量最大化问题，用贪心算法为每个请求动态分配验证预算：低负载时自动拉长验证块，把空闲算力用满，拉满单用户生成速度；高负载时主动裁剪低价值 Token，避免资源争抢，稳住系统整体吞吐量与用户体感速度。

02

验证！推理速度全场景飙升

加速技术的真实分量要靠实测来印证。

首先是离线基准评测。团队选取数学推理、代码生成、日常对话三大领域共 9 个通用数据集，在 Qwen3-4B/8B/14B、Gemma4-12B 四款目标模型上进行横向对比。结果显示，DSpark 的平均接受长度全面超越当前业界 SOTA 方案，对应的单 Token 理论延迟显著低于 Eagle3 与 DFlash。

测试数据同时呈现出清晰的领域差异：数学、代码这类结构化较强的任务，接受长度明显更高，开放对话场景的接受长度则相对更低。这一差异印证了固定验证长度的先天局限 —— 不同类型的请求，最优验证块长本就不同，而动态调度的策略能让每一类请求都拿到最优的加速收益。

线上真实流量的表现最能体现用户的实际体感。目前 DSpark 已全量部署于 DeepSeek-V4 线上服务，对比前代 MTP-1 单 Token 生产基线，在速度、服务容量和稳定性上都有实质提升：

同吞吐下绝对提速：在系统总吞吐量持平的配置下，V4-Flash 单用户生成速度提升 60% - 85%，V4-Pro 提升 57% - 78%，用户可直接感知到输出跟手度提升、长文本生成等待时间大幅缩短。

高 SLA 下容量扩容：在严格的交互性要求下（如 Flash 要求 120 token/s、Pro 要求 50 token/s），传统单 Token 基线已接近性能极限，仅能支撑极低并发；而 DSpark 仍能维持可观的服务容量，解锁了此前无法实现的高速响应档位，向外推移了推理服务的性能帕累托边界。

全负载下速度稳定：动态调度器会随并发压力自动调整验证预算：低并发时用满算力、拉满速度；高并发时平滑收缩、避免跳水。全程不会出现传统静态方案的速度骤降，用户体验一致性显著提升。

总而言之，DSpark 跳出了过往推测解码非此即彼的技术局限，依靠半自回归架构补齐并行草稿尾部准确率短板，再通过置信度动态调度解决传统全量验证的算力浪费问题，完成了草稿生成与在线验证的全链同优化。雷峰网

值得一提的是，团队还配套开源的 DeepSpec 全栈训练工具链，将这套无损推理加速方案对外开放。过去，中小开发者和轻量化应用很难低成本实现高速大模型推理，而DSpark以高性价比大幅降低了推理优化的门槛，让“每个小app都能用上大模型”不再是一句口号，而是正在落地的行业现实。

上车，带你看遍全球 AI 顶会精华

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

扫描上方二维码

或点击「阅读原文」关注专区。

雷峰网原创文章，未经授权禁止转载。详情见转载须知。