DeepSeek 这一次给 V4 推了一个看上去不起眼、实则分量很重的更新:投机解码(Speculative Decoding)框架 DSpark,论文题为《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》,由北京大学与 DeepSeek-AI 联合署名。官方口径是「推理速度提升 80%」,但比这个数字更重要的是它的落地方式——DSpark 不是停留在离线 benchmark 的算法论文,而是已经部署到 DeepSeek-V4 Flash 与 Pro 的真实线上流量中,在 V4 预览版发布约两周后,直接替换掉了上一代的 MTP-1 生产基线。论文 PDF 当天登上 Hacker News 首页,拿到逾 600 分、230 余条评论(截至核查时为 616 分 / 230 评论)。DeepSeek 同时开源了 V4-Flash/Pro 的 DSpark 检查点(MIT 许可)以及训练仓库 DeepSpec。
发生了什么
投机解码的基本盘很简单:用一个轻量「草稿模型」一次性提议一串候选 token,再让满血的「目标模型」在一次前向里并行验证、接受最长的合法前缀。因为验证是并行的、且接受规则严格保持目标分布,它能在不损失任何生成质量的前提下提速。过去两年的主线是优化草稿模型本身:自回归草稿器(如 Eagle 系列)接受率高但草稿延迟随块长线性增长;并行草稿器(如 DeepSeek 自己的 DFlash)一次前向出整块、草稿延迟几乎与块长无关,但因为各位置独立预测、缺乏 token 间依赖,后段接受率会快速衰减(论文称之为 suffix decay / 多模碰撞)。
DSpark 的贡献是把这两条路缝合起来,并且把「验证多长」从固定值变成一个随系统负载动态调度的决策。它由两个互补机制构成:
-
半自回归生成(Semi-Autoregressive Generation):保留一个重型并行骨干(论文里就是 DFlash,由三层 MoE + 滑动窗口注意力 128 构成)负责大部分草稿计算,延迟基本与块长无关;再挂一个极轻量的串行输出头(默认是低秩分解的 Markov head,秩 r=256),给草稿 token 之间补上局部依赖,缓解后段接受率衰减。论文的判断很直接:并行骨干的首 token 容量本就高,只要「一点点自回归」就能把后段救回来——一个 2 层的 DSpark 在所有领域都打过了 5 层的 DFlash。
-
置信度调度验证(Confidence-Scheduled Verification):这是真正的新意所在。DSpark 训了一个置信度头,为每个草稿位置估计「前缀存活概率」,再配一个硬件感知前缀调度器,根据当前引擎吞吐曲线(SPS,steps-per-second 成本表)动态决定每个请求验证多长,把目标模型的算力只投给「期望回报为正」的 token。换句话说,它把投机解码当成一个系统级的吞吐最大化调度问题来解,而不只是「草稿器够不够准」的模型问题。
落到生产里,DSpark 还啃下了一堆工程硬骨头:置信度估计天然过自信,论文用「序列温度缩放(STS)」做后校准,把期望校准误差(ECE)从 3%–8% 压到 约 1%;调度算法本身是同步的、会和 CUDA Graph 重放与零开销调度(ZOS)冲突,DSpark 改成异步调度——用「两步之前」的置信度预测来决定截断长度,既规避了流水线 stall,又因为只看历史预测而天然满足无损投机解码所需的「非预期性」约束;在 DeepSeek-V4 架构上还专门改了 index-attention 与 compress 两个 kernel 以支持变长验证。
关键数据 / 技术细节
最值得看的是线上真实流量的对比。DSpark(配置为最大草稿长度 γ=5,记作 DSpark-5)对标的是 MTP-1 单 token 生产基线——之所以一直用单 token,是因为静态多 token 草稿器在高并发下会因验证浪费而拖垮总吞吐。在匹配吞吐(matched throughput)这一更稳健的工作点上:
| 模型 | 对比基线 | 匹配吞吐下单用户提速 | 中等 SLA 吞吐提升 | 严格 SLA 吞吐提升 |
|---|---|---|---|---|
| DeepSeek-V4-Flash | MTP-1 | +60% ~ +85% | +51%(80 tok/s/user) | +661%(120 tok/s/user) |
| DeepSeek-V4-Pro | MTP-1 | +57% ~ +78% | +52%(35 tok/s/user) | +406%(50 tok/s/user) |
这里要特别拆解一下那两个夸张的「+661% / +406%」:它们出现在严格交互性 SLA(每用户 120 / 50 tok/s)下,此时单 token 的 MTP-1 基线已逼近运行边界、只能服务极小并发批次,所以比值被放大。论文自己就很坦诚地标注,这类高 SLA 点「主要应理解为 DSpark 把可行的交互性前沿往外推了,而非一个有代表性的乘性加速」。真正稳健、可对外引用的数字,是匹配吞吐下的 60%–85%(Flash)/ 57%–78%(Pro)——这也正是官方「提速 80%」说法的来源。机器之心等媒体复述的同样是这组区间。
离线 benchmark 上(关闭置信度调度、固定块长,只测草稿质量),DSpark 用「每轮接受长度 τ」衡量,稳定优于两条基线:
| 目标模型 | vs Eagle3(自回归草稿) | vs DFlash(并行草稿) |
|---|---|---|
| Qwen3-4B | +30.9% | +16.3% |
| Qwen3-8B | +26.7% | +18.4% |
| Qwen3-14B | +30.0% | +18.3% |
几个值得记住的技术细节:训练用的是开源的 Open-PerfectBlend(130 万样本,含数学 39.4% / 代码 38.9% / 对话 17.6%),损失由交叉熵、分布匹配(TV 距离)与置信度三项加权组成(α=0.1/0.9/1.0);串行头带来的延迟开销极小——把草稿长度从 4 拉到 16,整轮引擎延迟只增加 0.2%–1.3%,却能换来最高 30% 的接受长度提升;置信度阈值扫描显示,剪掉低价值后缀后,对话场景的整体接受率能从 45.7% 拉到 95.7%,数学从 76.9% 到 92.5%,代码从 67.6% 到 92.0%——长尾噪声越大的领域,调度收益越明显。承载 DSpark 的 DeepSeek-V4-Pro 本体为 1.6T 总参 / 49B 激活的 MoE,HuggingFace 模型卡明确写道「DSpark 不是新模型,只是在同一份检查点上挂了个投机解码模块」。
完整离线 benchmark 表(Qwen3-4B,接受长度 τ,越高越好)
| 草稿器 | GSM8K | MATH | AIME25 | MBPP | HumanEval | LCB | MT-Bench | Alpaca | Arena-Hard |
|---|---|---|---|---|---|---|---|---|---|
| Eagle3 | 5.14 | 4.62 | 3.92 | 3.69 | 4.16 | 3.77 | 2.39 | 2.26 | 2.55 |
| DFlash | 5.40 | 4.85 | 4.15 | 4.40 | 4.74 | 4.18 | 3.07 | 2.96 | 2.83 |
| DSpark | 6.11 | 5.70 | 4.89 | 5.13 | 5.38 | 4.86 | 3.64 | 3.54 | 3.29 |
可见结构化任务(数学 / 代码)的接受长度天然高于开放对话——这正是固定长度验证会在对话里浪费算力、从而需要置信度调度的根因。位置级分析进一步显示:并行的 DFlash 在第 1 个 token 容量更高(0.88 vs Eagle3 的 0.81),但后段衰减;DSpark 继承了高首 token 容量,又靠串行头维持住了全块的稳定接受率。
数据来源:DSpark 论文 Table 1 与 Figure 2/4/5。
为何重要
这件事放在 DeepSeek 一贯的路线里看会更清楚:从 V2 的 MLA、V3 的 FP8 训练与 MTP,到 V3.2 的稀疏注意力,DeepSeek 的护城河从来不是「最聪明的模型」,而是「把每 token 推理成本往下打」的工程系统能力。DSpark 是这条线的最新一环,而且第一次把投机解码从「草稿器架构竞赛」明确拔高到了「算法 + 调度器 + 服务引擎 + 硬件 kernel 协同设计」的系统层面。论文里专门有一节《Verify Smarter, Not Longer》,这个口号几乎可以当作整个方向的注脚:接下来比的不是草稿提得多长,而是验证调度得多聪明。
与同期工作对照能看出领域的两条路径。本周 HuggingFace 上同样高热的 JetSpec(《并行树草稿打破投机解码扩展上限》)走的是纯算法极限路线——它用「树因果注意力」让一次前向并行生成多个树节点又保留自回归依赖,在 MATH-500 上拿到了 最高 9.64×(H100) 的离线加速,开放对话也有 4.58×,在 vLLM 上 batch=1 时 6.75×。两者放一起恰好构成一组镜像:
| 维度 | DSpark(DeepSeek) | JetSpec |
|---|---|---|
| 核心思路 | 半自回归草稿 + 置信度调度验证 | 并行树草稿 + 树因果注意力 |
| 主战场 | 上线 V4 真实线上流量 | 离线 benchmark 极限加速 |
| 峰值数字 | 线上单用户 +60%~85%(匹配吞吐) | 最高 9.64×(MATH-500,H100) |
| 关键判断 | 把投机解码当系统调度问题 | 解决并行草稿的「因果-效率两难」 |
JetSpec 那种 9×+ 的数字看着比 DSpark 的「80%」漂亮得多,但两者根本不在一个语境:离线、batch=1、高 token 预算下的理论加速,和高并发生产流量里受 KV-cache 容量、SLA、批次调度层层约束后的真实收益,差着一个数量级的「水分」。DSpark 真正稀缺的地方,正是它把数字落在了有真实用户、有并发争抢、有交互性 SLA的生产环境里——这也是为什么它的论文有大半篇幅在讲 ZOS 兼容、异步调度、kernel 改造这类「脏活」。
我们的判断:DSpark 真正的看点不是「80%」这个营销数字,而是 DeepSeek 把投机解码彻底重新定义成了一个系统级调度问题,并且把它跑通到了生产。过去大家盯着「草稿器架构」这一个旋钮,DSpark 加上了第二个、可能更重要的旋钮——在什么负载下、给哪个请求、验证多长。一旦验证长度变成随系统负载实时调度的变量,投机解码就从「模型的小聪明」升级成了「服务引擎的一等公民」。谁能把草稿器、调度器、serving 引擎、底层 kernel 一起协同设计,谁就能在每 token 成本上拉开身位。这正是 DeepSeek 最擅长、也最难被单点抄走的东西。
但要给三个反面 caveat。其一,那两个 400%–660% 的数字极易被误读。它们成立的前提是基线已经接近崩溃的严格 SLA 工作点,论文自己都不敢拿它当代表性加速——可对外传播时,这种「峰值数字」几乎注定被掐头去尾地放大。能拿来认真比较的,只有匹配吞吐下的 60%–85%,这一点反而体现了这篇论文少见的诚实。
其二,这次「开源」是部分开源。检查点和 DeepSpec 训练仓库确实放出来了(MIT),Gemma/Qwen 上也复现了离线增益;但生产里那 80% 的真正魔法——硬件感知调度器、STS 校准、异步 ZOS 集成、为 V4 架构定制的 index-attention/compress kernel——是和 DeepSeek 自家 serving 栈(HAI-LLM、V4 架构)深度耦合的。换个推理框架、换套硬件成本曲线,这套调度逻辑要重新标定。所以「开源」开的是算法骨架,生产级收益仍是 stack-specific 的。能复刻 τ,不等于能复刻线上吞吐。
其三,把它放进本周的大图景里看更有意思:同一周 OpenAI 在预览 GPT-5.6(Terra 主打「便宜一半」)、还公布了自研推理芯片 Jalapeño——头部闭源厂商在用资本(定制硅)买推理效率;DeepSeek 则在用算法 + 调度从软件层把成本榨出来。两条路通向同一个目标(更低的每 token 成本),但 DeepSeek 这条路对开放生态的可复制性、可施压性都更强。当算法侧的推理优化被一篇 MIT 论文公开,闭源厂商靠工程效率建立的成本优势,窗口期会被压缩。
接下来看什么
- 社区复现的是 τ 还是吞吐。第三方在 vLLM / SGLang 上接 DSpark 检查点后,能复刻的是离线接受长度,还是生产级的吞吐-交互性前沿?后者才是真考验。关注 DeepSpec 仓库的 issue 与社区 benchmark。
- 置信度调度会不会被通用化。「把验证长度当系统负载的函数来调度」这个思路,理论上和具体草稿器解耦。看 EAGLE、Medusa、JetSpec 等其它路线会不会把硬件感知调度器搬过去——如果会,这会成为投机解码的新标配组件。
- DSpark 与 JetSpec 式树草稿能否叠加。半自回归 + 置信度调度,和并行树草稿,理论上正交。两者结合能否在生产里把加速从 80% 再往上推,是下一个值得等的点。
- MTP 路线的退场。DSpark 上线两周就替掉了 MTP-1,意味着 DeepSeek 内部已认定「单 token + 静态多 token」这套旧生产范式不再最优。后续 V4 正式版会不会把 DSpark 设为默认、γ 会不会继续放大,是观察其推理成本走向的风向标。
- 官方更正式的发布。目前一手信息主要来自论文 PDF、HuggingFace 模型卡与 KOL 转述,DeepSeek 尚未出独立的技术博客或正式 release note。等官方发布以确认线上数字与部署范围。