推理速度暴涨85%
DeepSeek-V4线上实测，全栈代码MIT协议开源
DeepSeek联合北大开源DSpark：推理速度暴涨85%，AI基础设施再被加速
500亿融资后的第一个开源成果，不拼参数拼速度。梁文锋亲自署名的DSpark框架，用两套互补机制解决了推测解码的工程落地难题。
一、为什么大模型推理这么慢？
二、DSpark的两大核心创新
三、实测数据：全面碾压Eagle3和DFlash
四、线上生产环境表现
五、开源详情与使用指南
六、行业影响与展望
一、为什么大模型推理这么慢？
2026年6月27日，DeepSeek联合北京大学正式发布推理加速框架DSpark，并同步开源了全栈推测解码训练框架DeepSpec。这是DeepSeek完成500亿元融资后首次放出的开源新成果，论文由创始人梁文锋亲自署名。
先说清楚问题出在哪
大语言模型采用自回归方式生成文本——每生成一个新token，都需要基于全部前置token完成一次完整的前向传播。简单来说，让AI写500字回复，它需要连续做500次完整计算，每次只输出一个字。输出越长，等待越久，GPU利用率也越低。
这就是为什么你在用AI聊天时经常遇到”转圈等待”——尤其是在长文本生成和多轮对话场景下，延迟问题尤为突出。
行业标准的提速方案：用一个轻量级”草稿模型”快速生成若干候选token，再由完整规模的大模型通过单次并行前向传播批量验证。接受其中正确的连续前缀，遇到第一个错误就丢弃后面全部。
打个比方：秘书先拟好一段话，老板快速过一遍，对的留下，错的地方自己改。关键在于验证是并行的，而且数学上保证结果和逐字生成完全一致——无损加速，质量不打折。
但现有方案各有短板
目前推测解码的主流方案分为两派，都不完美：
- 自回归草稿模型（代表：Eagle3）：逐token串行生成，依赖关系建模强、接受率高，但草稿耗时随长度线性增长，只能用短块、浅层网络。
- 并行草稿模型（代表：DFlash）：一次前向传播直接预测整串token，速度极快。但各位置独立预测、彼此不知道对方结果，越往后越容易前后不一致，接受率断崖式下跌。
举个形象的例子：上下文同时支持”of course”和”no problem”两种续写，并行草稿可能会猜出”of problem”这种四不像组合。论文把这个现象称为”多模态冲突”（multi-modal collision），越靠后的token越容易被拒绝。
二、DSpark的两大核心创新
DSpark精准解决了上述两大瓶颈，提出了两套互补机制——一个改草稿，一个改验证。
创新一：半自回归生成架构
并行快但尾部不连贯，自回归连贯但慢——过去只能二选一。DSpark的做法是：两个都要。
繁重的计算仍由并行骨干网络（基于DFlash改进）一次性完成，产出全部候选位置的隐藏状态和基础logits。随后接一个轻量级串行模块，逐token注入前缀依赖信息，把连贯性补回来。
这个串行模块默认采用马尔可夫头（Markov Head）：只参考紧邻的前一个token，用低秩分解（r=256）把转移关系压得很小，几乎不增加计算量。回到刚才的例子：一旦第一个位置确定是”of”，它就会在下一个位置提高”course”的概率、压低”problem”，前后就接上了。
实验表明，仅两层Transformer深度的DSpark，即可在所有测试领域上超过五层DFlash的接受长度。少量自回归依赖的引入，在参数效率上远优于单纯堆叠并行层。
这种优势还会随块长放大：当草稿块长从7增加到15时，DSpark相对DFlash的接受长度优势从15%-18%扩大至22%-30%。
论文也试过记忆更长的RNN Head，效果略好，但实现复杂、部署不划算，最终默认还是Markov Head。代价很小——这个串行模块给整轮延迟只增加0.2%–1.3%。
创新二：置信度调度验证机制
草稿能写得很长，是不是就该整串都验证？答案是否定的。
在高并发的线上环境中，验证并不免费。多验证一个大概率会被拒绝的token，就会占用目标模型这一批的算力，而这部分算力本可以用来服务其他正在等待的请求。负载低时影响不大，负载一高就是明显的系统性浪费。
DSpark的解决方案分两层：
这意味着系统能根据实时并发量自动调整策略——闲时全力加速，忙时保住整体吞吐量。
三、实测数据：全面碾压Eagle3和DFlash
研究团队选取了Qwen3系列（4B/8B/14B）和Gemma4-12B作为目标模型，在三大类任务上进行了离线基准测试：
- 数学推理：GSM8K、MATH500、AIME25
- 代码生成：MBPP、HumanEval、LiveCodeBench
- 日常对话：MT-Bench、Alpaca、Arena-Hard
核心结论：DSpark在全部目标模型、全部评测领域下，稳定超越两类基线。
| 目标模型 | vs Eagle3 提升 | vs DFlash 提升 |
|---|---|---|
| Qwen3-4B | +30.9% | +16.3% |
| Qwen3-8B | +26.7% | +18.4% |
| Qwen3-14B | +30.0% | +18.3% |
| Gemma4-12B | 一致增益 | 一致增益 |
数据还揭示了一个有趣的领域差异：结构化任务（数学、代码）的可接受长度天然更高。以Qwen3-4B为例，数学任务平均接受长度5.57，代码任务5.12，而开放对话场景仅3.49。这印证了固定验证长度的局限——不同类型请求的最优验证块长本就不同，动态调度策略能让每类请求都拿到最优加速收益。
按直觉，逐字往后写的自回归应该比独立预测的并行更连贯。但数据显示：在第一个token位置上，并行草稿DFlash的接受率反而高于自回归Eagle3（数学0.88 vs 0.81，对话0.72 vs 0.53）。原因是并行架构可以做得更深，而自回归为了控制延迟只能做浅。
投机解码是前缀验证，第一个token一旦被拒、后面整串作废，所以起点的权重最高。DSpark继承了并行架构的首位容量优势，同时用顺序依赖补平了尾部的衰减——两全其美。
四、线上生产环境表现
DSpark不是停留在实验室的算法优化。它已经全面部署于DeepSeek-V4-Flash和DeepSeek-V4-Pro的预览版线上服务，替换了此前的MTP-1单token生产基线。真实用户流量验证结果如下：
| 引擎 | SLA标准 | 吞吐量提升 | 单用户速度提升 |
|---|---|---|---|
| V4-Flash | 80 token/s | +51% | 60% – 85% |
| V4-Flash | 120 token/s | +661% | |
| V4-Pro | 35 token/s | +52% | 57% – 78% |
| V4-Pro | 50 token/s | +406% |
值得注意的是，当SLA收紧至120 token/s时，单token基线已接近运行边界，而DSpark在维持可用并发批处理的前提下实现了标称661%的吞吐量优势。
调度器在系统并发数较低时会分配4-6个token的验证长度以充分利用空闲计算资源，随着并发数上升则平滑缩减验证长度以避免资源争用——表现出优秀的负载自适应能力。
五、开源详情与使用指南
开源内容
DeepSeek已在GitHub的DeepSpec项目中完整开源：
- DSpark、DFlash、Eagle3 三种草稿模型的训练代码
- 评估脚本与基准数据集
- 模型权重（HuggingFace可下载）
- 论文PDF
- MIT许可证——随便下、随便改、随便用
GitHub仓库: https://github.com/deepseek-ai/DeepSpec 论文PDF: https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf 模型下载: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark
DeepSpec工作流
DeepSpec是一个用于训练和评估推测解码草稿模型的全栈代码库，包含数据准备工具、草稿模型实现、训练代码和评估脚本。工作流程分为三个阶段：
bash scripts/train/train.sh，每个可见GPU启动一个worker。默认配置假设单节点8 GPU环境。bash scripts/eval/eval.sh，在GSM8K、MATH500、HumanEval等9个基准上测量推测解码的接受率。目前DeepSpec内置三种算法实现：DSpark、DFlash和Eagle3，支持Qwen3和Gemma4系列目标模型。项目欢迎社区贡献新算法。
六、行业影响与展望
DeepSeek在推理效率优化上一直投入颇多：V2的MLA压缩了KV cache，V3引入了MTP（多token预测），V3.2换用稀疏注意力。DSpark是这条线上的最新一步，也是第一次直接用在主力产品上。
这次开源的核心价值在于：对于缺乏底层算法团队的中小企业和ToB服务商，无需投入巨额研发即可复用成熟推理优化方案，大幅降低大模型私有化部署和线上服务的落地门槛。智能体、工业代码、金融舆情等场景的规模化落地速度有望加快。
已知局限
DSpark并非完美无缺。论文坦诚指出：即使后缀token最终被调度器截断，并行主干仍需为所有请求生成完整的初始候选块。对于接受率本身较低的复杂查询，这部分草稿计算开销无法回收。
未来的优化方向：在草稿模型内部引入难度感知的早退出机制，使低适配请求能够跳过完整块生成流程。
在生成式AI从实验室走向商业化的周期里，”更快、更省算力”正在取代单纯的模型跑分，成为厂商竞争力的关键指标。DeepSeek在完成大额融资后并未单纯追求参数扩容，而是关注落地效率——这或许才是真正的长期主义。
发表回复