导读
我第一次看到 DSpark“单用户生成速度提升 60%—85%”时，下意识以为 DeepSeek 又做了一个更小、更快的模型。读完论文才发现，方向恰好相反：主模型没有少算答案，也没有拿精度换速度。它只是找了一个草稿员先往前猜几步，再让大模型一次批改。真正刁钻的地方是，草稿写多长，居然还得看 GPU 此刻忙不忙。
推测解码不是让大模型少想，而是把逐字批改变成整段批改
先把 推测解码（Speculative Decoding） 说人话。
普通大模型像一个特别谨慎的作者：写完一个 token，重新读一遍上下文，再写下一个。输出 100 个 token，就要沿着这条串行链走很多轮。不是它故意磨蹭，自回归生成本来就这么干。
推测解码塞进来一个“草稿员”。它先猜出后面几枚 token，再交给目标模型一次验证。猜对的前缀留下；碰到第一处错误，后面的草稿一起作废，目标模型从分歧处接管。
听着像拿小模型糊弄大模型？
不是。Leviathan 等人的原始论文给出了一套拒绝采样规则，在相应条件下，最终采样仍服从目标模型的分布。它省掉的是串行等待，不是质量标准。
这里最容易产生一个误解：一次验证 8 个 token，并不等于成本和验证 1 个完全相同。更准确地说，Transformer 能并行计算这些位置；当推理受显存带宽、批处理和硬件利用率限制时，批量验证的边际成本可能远低于逐枚生成。
所以速度账本可以压成一句：
每个 token 的耗时 ≈（草稿耗时 + 验证耗时）÷ 每轮接受数量。
草稿写得太慢，不划算。猜 16 个只对 2 个，也不划算。高并发时还把大概率会错的尾部 token 塞进 batch，我看着都烦：它们会挤掉其他用户的位置。
这不是“猜得越多越快”的游戏。
如果候选接受率不高，推测解码甚至可能比老老实实逐 token 生成更慢，这个反例比所有漂亮加速数字都重要。
并行草稿跑得快，却可能把“of course”猜成“of problem”
草稿模型有两种脾气。
Eagle3 一类自回归草稿器按顺序猜。前一个 token 出来后，后一个再跟上，句子比较连贯；代价是草稿越长，串行步骤越多。像一个认真但手慢的助理。
DFlash 一类并行草稿器则把多个位置一次产出。它可以用更深的网络，第一枚 token 往往猜得不错，草稿长度拉长也不用等比例增加前向次数。
麻烦藏在后半句。
假设上下文后面可能接 “of course”，也可能接 “no problem”。几个位置各猜各的，就可能拼出 “of problem”。每个词单看都像那么回事，合起来却很邪门。论文把这类现象叫作多模态碰撞；越往草稿尾部，接受率越容易衰减。
并行解决了等待，却切断了词与词之间的商量。
DSpark 的做法有点像给快手助理配一个轻量编辑。重活交给并行骨干，一次生成整块基础 logits；随后由顺序头从左到右补入前缀依赖。
默认的 Markov head 甚至只看前一个 token。它用 rank 256 的低秩分解做转移修正：前面抽到 “of”，后面就抬高 “course”、压低 “problem”。论文也试了能记住更长前缀的 RNN head，但增益有限，部署更麻烦，于是没把复杂当勋章。
在 Qwen3-4B、8B、14B 的离线实验中，DSpark 的宏平均接受长度相对 Eagle3 分别提高 **30.9%、26.7%、30.0%**，相对 DFlash 提高 **16.3%、18.4%、18.3%**。草稿长度从 4 拉到 16 时，顺序模块给整轮延迟增加的开销约 **0.2%—1.3%**，接受长度最高多出 30%。
这些数字挺漂亮，但先别急着欢呼。离线实验关闭了置信度调度，为的是单独比较草稿质量；而且评测使用 Qwen3 与 Gemma 4 目标模型、统一训练数据和非思考模式。换模型、换工作负载，数字不会自动复制粘贴。
我更喜欢这个设计的地方，是它没有执着于纯并行或纯串行，而是把昂贵计算并行化，只留下便宜的依赖修正。
DSpark 真正难的一步，是让 GPU 决定今天该批改几题
草稿更连贯，只解决了一半。
代码有固定语法，往后猜 8 枚 token 可能还挺稳；开放聊天的分叉多，猜到第 4 枚就开始发虚。同一份草稿，在 GPU 空闲时多验几枚没大碍，高并发时却可能占掉宝贵的 batch 容量。
固定草稿长度很省事，也很笨。
DSpark 给每个位置加了置信度头，估计“前面的 token 都通过后，这一枚还能存活”的概率。神经网络又有个老毛病：自信得有点冒犯人。论文在 Alpaca 上观察到校准前 ECE 约为 3%—8%，经过顺序温度缩放后，平均降到约 **1%**。
调度器再把这些存活概率和 GPU 的实测吞吐曲线放到一起算。低负载时，验证长一点；负载上来，就砍掉回报低的后缀。每条请求拿到的验证长度可以不同。
这才是 DSpark 最有生产味的部分：模型负责判断草稿靠不靠谱，系统负责判断此刻值不值得验证。
在 DeepSeek-V4 预览版真实流量中，DSpark 相对生产基线 MTP-1，在匹配总体吞吐能力时，让 V4-Flash 的单用户生成速度提高 **60%—85%**，V4-Pro 提高 **57%—78%**。
注意限定词：匹配吞吐、生产基线、特定预览版系统。
论文图里还有 661% 和 406% 的吞吐优势，但作者自己泼了冷水：那出现在严格 SLA 下，MTP-1 已接近运行边界、并发批次很小。拿它包装成“日常吞吐翻六倍”，挺糟糕，也容易把读者带沟里。
看到作者亲自拆自家爆款标题，我反而放心一点。
代码开源了，但 38TB 会让很多人先冷静下来
DeepSpec 仓库已经放出数据准备、训练、评估代码，以及 Qwen3 4B/8B/14B、Gemma 4 12B 对应的 Eagle3、DFlash、DSpark checkpoint。许可证是 MIT。
然后，现实账单来了。
官方 README 提醒：默认 Qwen3-4B 配置构建 target cache，存储量大约 38TB；默认脚本面向单节点 8 卡。少卡可以调整 CUDA_VISIBLE_DEVICES，但成本不会凭空消失。
所以，普通开发者可以先做三件事：
-
想理解算法：直接读论文 Figure 1，再看仓库里的 DSpark 配置，不必先训练。 -
想跑评估：使用官方公开 checkpoint，对照 GSM8K、HumanEval、MT-Bench 等脚本验证接受长度。 -
想训自己的草稿器：先估算目标缓存、GPU 数量和目标模型服务成本，别下载完仓库才发现硬盘已经举白旗。
还有一条容易漏掉：官方 README 明确建议，领域任务最好重新微调草稿模型；若目标模型主要运行在 thinking mode，也尤其要重新适配。草稿器学的是目标模型的出牌习惯，不是随便拎一个就能通吃。
DSpark 没有让大模型跳过思考。
它只是把等待切碎，把能并行的先并行，把容易猜错的及时扔掉。以前我们问“下一次多猜几个 token 会不会更快”，现在问题变成了：
⬆️AI生成
GPU 正忙着，这枚 token 还值得占一个座位吗？
参考资料
-
DSpark 官方技术报告： https://github.com/deepseek-ai/DeepSpec/blob/main/DSpark_paper.pdf -
DeepSpec 官方代码仓库： https://github.com/deepseek-ai/DeepSpec -
推测解码原始论文： https://arxiv.org/abs/2211.17192 -
DeepSeek-V3 官方仓库： https://github.com/deepseek-ai/DeepSeek-V3 -
DFlash 原始论文： https://arxiv.org/abs/2602.06036 -
EAGLE-3 原始论文： https://arxiv.org/abs/2503.01840 -
量子位参考文章： https://mp.weixin.qq.com/s/BVlgO1e6StBGIaxGPTQIXQ -
机器之心参考文章： https://mp.weixin.qq.com/s/xFzo8SBzqcxtAL3mYnYV-A
文章仅做学术分享，如有侵权请联系删除，非常感谢！