单用户提速60-85%！DeepSeek联手北大开源DSpark，突破推理加速工程问题
把算力花在刀刃上，梁文锋再次大幅降低推理优化门槛。
作者丨 樊天骄
编辑丨 马晓宁
2026年6月27日，AI圈迎来了一则重磅消息，DeepSeek联合北京大学正式发布了 DSpar k推 理 加速框 架 ， 并同步开源了支撑该版本的 全栈推测性解码框架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 依赖，直接拉高每轮验证的有效接受长度。