DeepSeek 与北京大学把投机解码(Speculative Decoding)从一篇算法论文变成了一份「连训练脚手架一起送」的开源交付。6 月 27 日,他们发布框架 DSpark(论文《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》),并把全栈训练代码库 DeepSpec 以 MIT 协议开源;同日,V4-Flash 与 V4-Pro 的 DSpark 检查点双双上架 HuggingFace(模型卡时间戳分别为 06:59 / 05:12 UTC,均 MIT)。DSpark 已部署在 DeepSeek-V4 的真实线上流量中,在匹配吞吐、输出无损前提下,V4-Flash 单用户生成提速 60%–85%、V4-Pro 提速 57%–78%,全面超越此前生产的单 token 多分支预测基线 MTP-1。论文当天登上 Hacker News 首页,获 约 716 分、近 300 条评论(经 HN API 核实)。比起「提速 80%」这个营销口径,真正改变格局的是:DeepSeek 第一次把投机解码的训练侧做成了任何人都可复刻的工具链,而不只是放出一个检查点。
发生了什么
投机解码的老问题很清楚:用一个轻量草稿模型一次性提议一串候选 token,满血目标模型一次前向并行验证、接受最长合法前缀,从而在不损失任何生成质量的前提下提速。瓶颈在于草稿器架构的两难——自回归草稿器(Eagle 系列)接受率高但草稿延迟随块长线性增长;并行草稿器(DeepSeek 自家的 DFlash)一次前向出整块、延迟几乎与块长无关,但各位置独立预测、缺乏 token 间依赖,后段接受率快速衰减(论文称为 suffix decay / 多模碰撞)。更致命的是,在线上高并发环境里盲目验证长草稿,会让目标模型把宝贵的批次算力浪费在注定被拒绝的尾部 token 上,总吞吐反而崩溃——这正是业界线上长期退守单 token(MTP-1)的根因。
DSpark 用两个互补机制把这两道坎一起迈过去:
-
半自回归生成:保留一个重型并行骨干(论文里即 DFlash,由 3 层 MoE + mHC + 滑动窗口注意力 128 构成)负责大部分草稿计算,延迟基本与块长无关;再挂一个极轻量的串行输出头(默认是低秩分解的 Markov head,秩 r=256,本质是一次 embedding 查表加一次矩阵乘)给草稿 token 之间补上局部依赖,缓解后段衰减。论文的实证很直接:一个 2 层 DSpark 在所有领域都打过了 5 层 DFlash——「一点点自回归」就能把后段救回来。
-
置信度调度验证:训练一个置信度头,为每个草稿位置估计「前缀存活概率」(监督信号是草稿分布与目标分布的 TV 距离解析接受率),再配一个硬件感知前缀调度器,根据引擎实测的吞吐曲线 SPS(B) 动态决定每个请求验证多长,把目标算力只投给「期望回报为正」的 token。它把投机解码当成了系统级吞吐最大化调度问题(最大化 Θ = τ·SPS(B)),而不只是「草稿器够不够准」。
落到生产里还有一堆工程硬骨头:置信度估计天然过自信,论文用「序列温度缩放(STS)」做后校准,把期望校准误差(ECE)从 3%–8% 压到 约 1%;调度算法与 CUDA Graph 重放、零开销调度(ZOS)冲突,DSpark 改成异步调度——用「两步之前」的置信度预测来决定截断长度,既规避了流水线 stall,又因为只依赖历史预测而天然满足无损投机解码所需的「非预期性」约束;在 DeepSeek-V4 架构上只改了 index-attention 与 compress 两个 kernel 以支持变长验证。生产里,调度器在中等并发下把每请求验证预算从 MTP-1 的静态 2 token 扩到约 4–6 token,并发升高时再自动收紧——这就是它在高并发下不崩吞吐的关键。
关键数据 / 技术细节
最值得看的是线上真实流量对比。DSpark(配置为最大草稿长度 γ=5,记作 DSpark-5)对标 MTP-1 生产基线。MTP-1 之所以长期是线上天花板,是因为静态多 token 草稿器(MTP-3/5)在高并发下因验证浪费严格拖累总吞吐——DSpark 要证明的正是「能安全地把更大草稿块放到动态服务环境里」。
| 模型 | 对比基线 | 匹配吞吐下单用户提速 | 中等 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 下,此时单 token 的 MTP-1 基线已逼近运行边界、只能服务极小并发批次,比值被放大。论文自己就标注,这类高 SLA 点「主要应理解为 DSpark 把可行的交互性前沿往外推了,而非一个有代表性的乘性加速」。真正稳健、可对外引用的,是匹配吞吐下的 60%–85%(Flash)/ 57%–78%(Pro)——这也是官方「提速 80%」说法的来源,KOL @danielhanchen 推文里「51% to 400%」的口径,正是把中等 SLA 的 51% 与严格 SLA 的 ~400% 拼在了一起(该推文获 2744 赞、23.9 万次浏览,是本轮传播的主轴)。
离线 benchmark(关闭置信度调度、固定块长,只测草稿质量)用每轮接受长度 τ 衡量,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 | 跨族泛化(见下表) | 跨族泛化 |
这次开源的真正增量是 DeepSpec 全栈代码库。它不是只放检查点,而是把「为任意开源大模型定制草稿器」的整条流水线都公开了:
| 维度 | DeepSpec 实际内容(经仓库核实) |
|---|---|
| 许可证 | MIT(Copyright 2026 The DeepSpec Authors) |
| 支持草稿器 | DSpark、DFlash、Eagle3 三种,均有独立 modeling / trainer / config |
| 支持目标模型 | Qwen3-4B/8B/14B、Gemma4-12B(config 目录下三种草稿器 × 四个目标均有配置,如 config/dspark/dspark_qwen3_4b.py) |
| 流水线三阶段 | ① 数据准备(下载/切分→重建目标答案→构建目标缓存)→ ② 训练(train.py,单卡一 worker,默认 8 卡单机)→ ③ 评估(eval.py,跑 9 个 benchmark) |
| 评估数据集 | gsm8k、math500、aime24/25、humaneval、mbpp、livecodebench、lbpp、mt-bench、alpaca、arena-hard-v2、swe-bench |
| 关键源文件 | deepspec/modeling/dspark/{markov_head,loss,common}.py、deepspec/eval/dspark/{confidence_head,draft_ops,evaluator}.py、deepspec/trainer/dspark_trainer.py |
| 依赖 | torch 2.9.1、transformers 5.10.2、triton 3.5.1 |
| 工程血统 | 建立在 SpecForge(Apache-2.0,sgl-project 的 Eagle3 训练框架)+ DFlash(MIT,z-lab)+ Qwen3/Gemma 之上 |
| 复现成本警告 | 默认 Qwen3-4B 设置下目标缓存约 38 TB |
几个值得记住的技术细节:训练用开源的 Open-PerfectBlend(130 万样本,数学 39.4% / 代码 38.9% / 对话 17.6% / 指令 4.1%),损失由交叉熵、分布匹配(TV 距离)、置信度三项加权(α=0.1/0.9/1.0);串行头延迟开销极小——把草稿长度从 4 拉到 16,整轮引擎延迟(batch=128)只增加 0.2%–1.3%,却能换来最高 30% 的接受长度提升;置信度阈值扫描显示,剪掉低价值后缀后,对话场景整体接受率从 45.7% 拉到 95.7%,数学从 76.9% 到 92.5%,代码从 67.6% 到 92.0%——长尾噪声越大的领域,调度收益越明显。承载 DSpark 的 DeepSeek-V4 本体为 V4-Pro 1.6T 总参 / 49B 激活、V4-Flash 284B 总参 / 13B 激活的 MoE,支持 100 万 token 上下文(V4 论文 arXiv:2606.19348);HuggingFace 模型卡明确标注 DSpark 检查点为 MIT、挂载在同一份 V4 检查点之上。
完整离线 benchmark 表(接受长度 τ,越高越好;论文 Table 1)
| 目标模型 / 草稿器 | GSM8K | MATH | AIME25 | MBPP | HumanEval | LCB | MT-Bench | Alpaca | Arena-Hard |
|---|---|---|---|---|---|---|---|---|---|
| Qwen3-4B / Eagle3 | 5.14 | 4.62 | 3.92 | 3.69 | 4.16 | 3.77 | 2.39 | 2.26 | 2.55 |
| Qwen3-4B / DFlash | 5.40 | 4.85 | 4.15 | 4.40 | 4.74 | 4.18 | 3.07 | 2.96 | 2.83 |
| Qwen3-4B / DSpark | 6.11 | 5.70 | 4.89 | 5.13 | 5.38 | 4.86 | 3.64 | 3.54 | 3.29 |
| Gemma4-12B / Eagle3 | 5.87 | 5.46 | 4.83 | 4.72 | 5.37 | 4.16 | 3.19 | 3.06 | 2.72 |
| Gemma4-12B / DFlash | 5.45 | 5.04 | 4.22 | 4.39 | 4.95 | 3.70 | 2.98 | 2.84 | 2.59 |
| Gemma4-12B / DSpark | 6.05 | 5.78 | 5.12 | 5.11 | 5.64 | 4.51 | 3.49 | 3.35 | 2.92 |
结构化任务(数学 / 代码)的接受长度天然高于开放对话——这正是固定长度验证会在对话里浪费算力、从而需要置信度调度的根因。位置级分析进一步显示:并行 DFlash 在第 1 个 token 容量更高(数学 0.88 vs Eagle3 的 0.81),但后段衰减;DSpark 继承了高首 token 容量,又靠串行头维持住了全块稳定接受率。数据来源:DSpark 论文 Table 1 与 Figure 2/4/5。
为何重要
这件事的分量要从「开源了什么」和「没开源什么」两层看。DeepSpec 公开的是算法骨架与训练侧全栈:三种草稿器的建模、损失、训练器、置信度头、评估器,加上数据准备到基准评估的完整脚本,且明确支持 Qwen3 与 Gemma4——意味着任何人都能在本地为自己的开源大模型定制并部署专属加速模块。它在工程血统上整合了 SpecForge(sgl-project 的 Eagle3 框架)与 DFlash,等于把当前投机解码的两条主线(自回归 / 并行)统一进了一个可训练、可评估的仓库。这对开放生态是实打实的「抬地板」:复现 τ(离线接受长度)从「读论文自己实现」变成了「跑脚本」。
但必须诚实指出没开源的部分:生产里那 60%–85% 的真正魔法——硬件感知调度器、STS 校准、异步 ZOS 集成、为 V4 架构定制的 index-attention/compress kernel——是和 DeepSeek 自家 serving 栈(HAI-LLM 训练框架、V4 架构、ZOS)深度耦合的,并不在 DeepSpec 仓库里。换个推理框架、换套硬件成本曲线,调度逻辑要重新标定。所以这次「开源」开的是算法骨架,生产级收益仍是 stack-specific 的:能复刻 τ,不等于能复刻线上吞吐。KOL @0xLogicrw(思维怪怪)的中文技术拆解把这一点说得很到位——它强调 DeepSpec 提供「从下载提示词、重建大模型缓存、训练草稿模型到基准评估的完整 Python 工具链」,但线上那套「两步前预测防未来信息泄漏」的异步调度,本质是 DeepSeek 内部服务引擎的工程。
放进本周的大图景看更有意思:同一周 OpenAI 在预览 GPT-5.6(Terra 主打「便宜一半」、还公布了自研推理芯片)——头部闭源厂商在用资本(定制硅)买推理效率;DeepSeek 则在用算法 + 调度从软件层把成本榨出来,并且把算法侧以 MIT 公开。两条路通向同一个目标(更低的每 token 成本),但 DeepSeek 这条路对开放生态的可复制性、可施压性都更强。Hacker News 评论区几乎把这场博弈的话说尽了:高赞留言称「DeepSeek 不仅推进边界,还发表这些论文解释他们如何取得增益——美国实验室已经不这么做了」,另一条更直接——「DeepSeek 正在把美国实验室赖以为投资者赚钱的性能增益商品化」。当算法侧的推理优化被一篇 MIT 论文 + 一个 MIT 仓库公开,闭源厂商靠工程效率建立的成本优势,窗口期会被压缩。
我们的判断:这一轮的看点不是「提速 80%」这个已经被反复传播的数字,而是 DeepSeek 把投机解码的训练侧做成了first-class 的开源工具链。过去社区盯着「草稿器架构」这一个旋钮,DeepSpec 把 DSpark、DFlash、Eagle3 三条路线连同训练、校准、评估一起放进一个 MIT 仓库,等于把「为任意开源模型造草稿器」的门槛从论文级降到了脚本级。这才是对开放生态真正的增量——它抬的是地板,不是天花板。
但要给三个反面 caveat。其一,「51% to 400%」与 661%/406% 极易被误读。它们成立的前提是基线已接近崩溃的严格 SLA 工作点,论文自己都不敢拿它当代表性加速。能拿来认真比较的只有匹配吞吐下的 60%–85%,这一点反而体现了这篇论文少见的诚实——可对外传播时,峰值数字几乎注定被掐头去尾放大。读者自辨。
其二,「全栈开源」是训练侧的全栈,不是服务侧的全栈。检查点和 DeepSpec 确实放出来了,Gemma/Qwen 上也复现了离线增益;但线上 60%–85% 靠的是硬件感知调度器、STS、异步 ZOS、V4 专属 kernel,这些和 DeepSeek 自家 serving 栈深度绑定、不在仓库里。社区能在 vLLM/SGLang 上复刻 τ,但要把调度器对着自己的 SPS 曲线和引擎重新标定,才能接近生产级吞吐。「开源了算法」不等于「开源了那 80%」。
其三,战略上这是「抬地板」而非「抹平领先」。算法一旦公开,闭源厂商靠单点工程效率建立的成本优势窗口会被压缩——这是 DeepSeek 一贯的打法,也是 HN 评论区「商品化性能增益」论调的来源。但真正的护城河从来不是算法本身,而是草稿器、调度器、serving 引擎、底层 kernel 的协同设计能力。DeepSeek 把这一层做成了系统级调度问题并跑通到生产,这件事单点很难被抄走。所以更准确的判断是:DeepSpec 让整个开放生态的推理效率下限上抬,但 DeepSeek 自身的领先仍在「能不能把整条 stack 一起协同设计」上——这恰恰是最难复刻、也最不该被「开源了」三个字掩盖的部分。
接下来看什么
- 社区复现的是 τ 还是吞吐。第三方在 vLLM / SGLang 上接 DSpark 检查点后,能复刻的是离线接受长度,还是生产级的吞吐-交互性前沿?后者才是真考验。盯 DeepSpec 仓库的 issue、star 增长与社区 benchmark。
- 硬件感知调度器能否被移植到开源引擎。「把验证长度当系统负载函数来调度」这个思路理论上和具体草稿器解耦。看 vLLM/SGLang 会不会把这套调度搬过去——若会,60%–85% 的收益才会从 DeepSeek 内部扩散到整个开放生态,这才是真正的分水岭。
- DeepSpec 会不会成为草稿器的「标准训练台」。它已经把 Eagle3/DFlash/DSpark 三条线统一进一个框架并欢迎新算法贡献。看 JetSpec 式并行树草稿、Medusa 等其他路线是否被社区接进 DeepSpec,形成可横向对比的 baseline ladder。
- 异步「两步前预测」调度会不会成为通用范式。这个用历史预测决定截断、既兼容 ZOS 又保无损的工程技巧,理论上可被任何带连续批处理的投机解码系统复用。看是否被其他 serving 框架采纳。
- V4 生产侧的走向。DSpark 上线两周就替掉了 MTP-1,后续 V4 正式版会不会把 DSpark 设为默认、γ 会不会继续放大,是观察 DeepSeek 推理成本走向的风向标。