DSpark 的 661% 提速，是真突破还是数字游戏？

DSpark 的 661% 提速，是真突破还是数字游戏？ 2026 年 6 月 27 日，DeepSeek 和北大联合放出论文《DSpark》，梁文锋亲自署名。隔天，爱范儿、量子位接连拆解，标题里都写着两个数字：单用户生成速度提升 85%，高并发场景系统吞吐名义优势 661%。 85% 看起来还行。661% 这个数字太像营销话术了——你买股票一年能涨 661% 吗？一家公司能让推理速度凭空翻 6 ...

DSpark 的 661% 提速，是真突破还是数字游戏？

2026 年 6 月 27 日，DeepSeek 和北大联合放出论文《DSpark》，梁文锋亲自署名。隔天，爱范儿、量子位接连拆解，标题里都写着两个数字：单用户生成速度提升 85%，高并发场景系统吞吐名义优势 661%。

85% 看起来还行。661% 这个数字太像营销话术了——你买股票一年能涨 661% 吗？一家公司能让推理速度凭空翻 6 倍？

这篇论文到底在说什么？这 661% 是怎么算出来的？以及更重要的：DeepSeek 把这套东西开源，意味着大模型竞争进入了什么新阶段？

答案分三层：这是一次正经的工程突破，「661%」不是骗术但确实有特定前提，它指向的是「大模型竞赛换赛道」。

DSpark 在大模型推理加速谱系中的位置

一、为什么你的 AI 一直在「挤牙膏」

要理解 DSpark 在解决什么，先得理解一件事：大模型生成慢，不是「算力不够」，是「必须串行」。

主流语言模型是自回归的。第 N+1 个 token，必须等第 N 个算完才能开始。GPU 算一个 token 是几十毫秒量级，要写一段 1000 token 的回复，就是 1000 次串行计算。每多等一个 token，用户都要等几十毫秒。

但这里有个反直觉的物理事实：GPU 解码的瓶颈不是浮点运算，而是显存带宽。

卡帕西讲过一句话：让 GPU 同时解码 10 个 token，其实只比解码 1 个 token 慢一点点。原因在于，模型权重一旦从显存搬到计算核心，搬一次和搬十次的开销差别不大（数据来源：量子位转引卡帕西公开演讲）。既然权重已经在缓存里了，不如一次搬运、干十件事。

这就是推测解码（speculative decoding）的全部物理学基础。

自回归 vs 推测解码：猜 + 验代替逐字生成

它的思路是：用一个轻量级的「草稿模型」（draft model）先猜出接下来 N 个候选 token，然后让真正负责质量的「目标模型」（target model）一次性批量验证这 N 个 token。验证通过的留下，第一个分歧点之后重新采样。

这样做的好处是：target model 那次贵的前向计算，可以一次性确认多个 token，把多次串行变成一次并行批处理。质量上无任何损失——数学上能证明输出分布和原模型完全一致。

用餐厅类比：自回归是主厨「一道菜做完再做下一道」；推测解码是「让帮厨先把 5 道菜的半成品备好，主厨一次性验收」。

听起来很美。但帮厨备的菜可能不对路。这是 DSpark 要解决的事。

二、老路线的两难：草稿要么慢、要么糊

过去几年推测解码大致走两条路线，两条都有硬伤。

第一条是自回归草稿（Eagle3、MTP）。

草稿模型自己也是一个语言模型，按顺序一个 token 接一个 token 生成候选。好处是前后连贯，候选质量高。但代价是：draft 阶段本身是串行的——你想生成 N 个候选 token，draft 阶段就得跑 N 步。step 数越多，draft 越慢，前面攒下来的批处理优势就被吃光了。

第二条是并行草稿（DFlash）。

借鉴扩散模型的思想，一次前向传播把全部 N 个候选位置同时产出。速度确实快。问题在于各位置之间没有依赖关系。

论文里给了一个直白的例子：模型面对某个上下文，可能同时存在「of course」和「no problem」两种合理续写。位置 1 采出「of」，位置 2 独立采出「problem」，各自看概率都合理，拼在一起就成了「of problem」。论文管这叫多模态碰撞（multimodal collision），更广义的术语是后缀衰减（suffix decay）——位置越靠后，接受率急剧下滑。

DFlash 在第一个 token 上表现强，因为上下文信息充足；但越往后越糊。「开头精彩、后面崩坏」是并行草稿的真实写照。

自回归 vs 并行草稿：后缀衰减的对比

更现实的问题发生在线上。数学、代码这些结构化任务，答案路径明确，候选 token 容易被接受；开放式聊天不确定性高，后面的 token 大概率被拒绝。系统空闲时多验证几个 token 没事；系统繁忙时，把那些大概率被拒绝的 token 送给 target model 验证，只会占用批处理容量，拖累其他用户。

换句话说，推测解码的问题已经不只是「能不能一次生成更多 token」，还在于「哪些 token 值得验证」。

三、DSpark 的解法：草稿要像样，审稿要聪明

DSpark 的思路可以概括成两件事——草稿要写得更像样，审稿要更会挑重点。

3.1 生成侧：半自回归架构

在草稿这一端，DSpark 采用半自回归（semi-autoregressive）架构。它保留并行草稿的主干，让大部分计算一次完成；同时在输出端加入一个轻量级顺序模块，让后面的 token 能参考前面已经采样出来的 token。

论文默认用 Markov head，只建模相邻 token 之间的转移关系，计算成本低、部署方便；也测试了 RNN head，能保留更长块内历史，但收益有限、复杂度更高。Markov head 是默认方案。

类比一下：帮厨还是并行铺开所有候选（快），但每铺一段，就回头检查相邻两段的衔接（连贯）。

架构实验结果能说明问题：2 层 DSpark 已经超过 5 层 DFlash。意思是，与其把并行层堆得更深，不如加一层轻量级的顺序建模。这对那些已经为 DFlash 堆资源的人是个不小的耳光。

3.2 验证侧：置信度调度的动态决策

这一招才是 DSpark 的杀手锏。

系统会给每个候选位置预测一个 confidence score（置信度分数）。这个分数回答的问题是：在前面的 token 都已经被 target model 接受的情况下，当前位置继续被接受的概率有多高。

然后，hardware-aware prefix scheduler（硬件感知前缀调度器）根据三个因素动态决定每个请求该验证多少 token：

当前系统负载
每个候选位置的置信度
引擎在不同 batch size 下的吞吐曲线

系统资源宽松时，DSpark 可以验证更长的前缀，让一次前向计算尽量产出更多有效 token。系统负载升高时，它会缩短低置信度请求的验证长度，减少对 batch capacity 的占用。

这是和老方案最本质的区别。传统推测解码是「机械地验证固定长度的候选块」。DSpark 不机械——它会根据系统当下的情况，决定这次验证是「多走一步」还是「到此为止」。

DSpark 全流程：草稿 → 置信度打分 → 动态验证

3.3 数字：661% 到底怎么来的

论文的离线 benchmark 在 Qwen3-4B/8B/14B 和 Gemma4-12B 上跑，DSpark 相比 Eagle3 的 accepted length（宏平均接受长度）提升 26.7%~30.9%，相比 DFlash 提升 16.3%~18.4%（数据来源：DSpark 论文）。

accepted length 是关键指标，意思是每一轮推测解码中，平均有多少 token 能被 target model 接受。这个数字越高，草稿模型写得越准，加速空间越大。

更有意思的是不同任务的差异。以 Qwen3-4B 为例，数学任务 accepted length 5.57，代码任务 5.12，聊天任务 3.49。结构化任务天然吃这套——答案路径明确，模型容易猜对；开放式聊天不确定性强，模型猜错率高。

所以 DSpark 的置信度调度特别聪明：让系统在结构化任务上「敢验」，在聊天任务上「保守验」。这就是置信度扫表实验的结果——聊天任务 acceptance rate 从 45.7% 提升到 95.7%，数学从 76.9% 到 92.5%，代码从 67.6% 到 92.0%。

然后是线上数据。DeepSeek 在 DeepSeek-V4-Flash preview 和 V4-Pro preview 的生产服务中部署 DSpark，最大 draft 长度设为 5，对比基线是此前的 MTP-1。

V4-Flash 在 80 token/s/user 服务目标下，DSpark 让系统总吞吐提升 51%。
在更严格的 120 token/s/user 目标下，MTP-1 已经接近能力上限，DSpark 给出的名义吞吐优势达到 661%。

这个 661% 怎么理解？不是所有场景都能拿 6 倍提速。更准确的说法是：在高交互、强 SLA 约束下，MTP-1 很难继续维持服务能力，而 DSpark 把原本难以达到的性能区间打开了。

类比一下：你原来开的车最快能到 100 km/h，现在换了发动机，不仅能到 100，还能稳定到 160。在「跑到 120 公里/小时」这个目标下，老发动机的有效功率比是 0，新发动机的有效功率比可以算成无穷大——但这不代表你日常通勤就能跑到 160。661% 是「解锁」的数字，不是「普适提速」的数字。

V4-Pro 的趋势类似。35 token/s/user 目标下总吞吐 +52%，50 token/s/user 严格目标下名义优势 +406%。在相同系统容量下，DSpark 让 V4-Pro 单用户生成速度提升 57%~78%。

到这里，661% 这个数字的真面目就清楚了：它不是吹牛，但有特定前提；它是「高 SLA 场景下的性能解锁」，不是「日常都提速 6 倍」。论文诚实地把基线、目标、batch size 全部列出来，没有回避 MTP-1 已经接近饱和的事实。

四、梁文锋亲自署名，DeepSeek 在押什么

DSpark 这件事最值得关注的不是 661%，是 DeepSeek 的几个动作叠在一起。

第一，梁文锋亲自署名。一篇工程优化论文，老板亲自下场，说明这不是「下面人随便发的成果」，而是公司层面的战略动作。

第二，同步开源 DSpark 模型权重——包括 V4-Flash 和 V4-Pro preview 对应的 DSpark checkpoints。同时开源训练库 DeepSpec，里面包含 Eagle3、DFlash 和 DSpark 三套方案。

第三，Fireworks AI 的 CTO、PyTorch 核心维护者 Dmytro Dzhulgakov 专门撰文拆解 10 个概念，把这篇论文定性为「DeepSeek 这套方案真正的精髓在于系统工程和模型协同设计」（来源：量子位）。

把这三件事拼起来看，信号很明确：

训练更强的模型是牌桌上的硬实力，但能否把模型以更快、更便宜、更稳定的方式送到真实用户面前，同样会决定一款 AI 产品的上限。

OpenAI 把推测解码当「生产细节」藏着，Anthropic 在这方面也相对保守。DeepSeek 选择把这套生产环境里的加速经验开源，等于把一部分真正能提高推理效率、降低服务成本的核心方法，无私分享给全行业。

这背后是一个判断：下一代大模型竞争的牌桌，已经从「谁参数多」换到了「谁推理快」。

中国团队的差异化路径也在浮现——不卷参数上限（这块被 H100/H200 集群规模和 CUDA 生态卡死），卷「同等参数下用户能多快拿到结果」。Kimi 之前用 KVCache 跨地域调度让延迟降 64%，DeepSeek 现在用 DSpark 在单卡层面把单用户速度再提 85%。两条路线指向同一个结论：模型层之上，工程层能榨出的油水比想象中大得多。

大模型竞争的尽头，越来越不是「更大」，而是「更快送到」。

结尾

DSpark 让我重新看 DeepSeek——他们不再只是「开源价格屠夫」，而是中国大模型里第一个把「系统工程」打到战略高度的团队。

论文里那张置信度调度曲线，比任何发布会都更能说明问题：真正的壁垒不在参数表里，在调度器的代码里。

那么问题就剩一个了：OpenAI 什么时候会跟进这套思路？是「技术领先被追平」的不甘，还是「方向根本看不上」的傲慢？

答案可能会在 GPT-5.1 或 Claude 5 的某次更新里揭晓。在那之前，DSpark 至少证明了一件事——大模型竞争的下半场，开源比闭源跑得更快。

参考来源：

论文：DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation（DeepSeek × 北大，2026-06-27）。GitHub: https://github.com/deepseek-ai/DeepSpec
爱范儿《DeepSeeK 突然发布 DSpark，让 AI 的回答不再「挤牙膏」》：https://www.ifanr.com/1670249
量子位《梁文锋署名的 DSpark，看懂这 10 个点就够了！》：https://www.qbitai.com/2026/06/439548.html