Two Minute Papers · 5:44 · 发布 2026-07-07 · 3.7万次观看(截至抓取) · 观看原视频
主旨
DeepSeek 在新论文 DeepSpark 里给 speculative decoding(用 draft 模型猜一段、target 模型逐 token verify)加了三层工程化补丁:小记忆维持 draft 一致性 / 提前剔除注定被否的 token / 动态判断每步是否值得 verify,让 multi-token prediction 在他们自家 flash/pro 模型上跑出 60-85% 的实测加速(对照自家 MTP-1),论文中孤例报 661% 吞吐仅在旧基线”撞墙”的边角场景。
核心论点
- speculative decoding 的瓶颈是 draft 模型不够稳,而不是”算力不够” — 猜不准 → 大量 token 被否 → 速度起不来。(→ 详解1)
- DeepSpark 第一招:给 draft 加一点点 memory 让前一个 token 影响下一个 — 不需要大模型,只需要 draft 不会”前后自相矛盾”。(→ 详解2)
- 第二招:提前剔除”显然不行”的 token,省掉 target model 的 verify 时间 — 用低概率信号当剪枝信号,而不是事后 reject。(→ 详解3)
- 第三招:动态判断”这步 verify 值得花 GPU 时间吗” — 代码/数学等可预测任务几乎不 verify,开放式写作反而要更密集 verify。(→ 详解4)
- 实测加速 60-85% 是”日常范围”,661% 那个是 MTP-1 旧基线撞墙的边角数 — 看论文要分清”基线”和”日常”,661% 不能拿来当卖点。(→ 详解5)
- DeepSpark 是推理时优化,不是新模型 — 它免费但需要三件套:匹配的 draft model + target 概率 + 能高效并行 serve 的系统 — 不是 API 外的魔改。(→ 详解6)
知识点详解
1. 为什么 speculative decoding 本质是”drafter 准不准” 00:42
Two Minute Papers 用 senior editor + junior writer 这对比喻把 speculative decoding 讲清楚:大模型(senior)一次想一个 token 准确但贵,draft 模型(junior)一次猜几个 token 便宜但常错;junior 写完 senior 来 verify,yes yes yes no — 第一个 no 之后全部作废00:42。
这条机制的核心成本结构是:junior 猜得多 → senior 拒得多 → 速度起不来。换言之,整个 speculative decoding 加速的天花板被 drafter 自身的”内部一致性”卡住。junior 会”forget things, starts a phrase and finishes another” 正是这条结构性失败的具象——前一个 token 和后一个 token 之间没约束,导致整段作废。
DeepSpark 的全部三招都在打这个 drafter 内部一致性的问题,而不是去换更大的 model。
2. 第一招:drafter 加小 memory 让 token 之间互相关联 01:47
DeepSpark 的第一招是给 drafter 加一个”小记忆”——不是大改模型,只让”前一个 token 能影响下一个 token”01:47。这样 junior writer 在写”开始一个短语”和”结束一个短语”时不会自相矛盾。
这条工程选择很关键:不是把 drafter 升级到”更聪明”,而是把 drafter 从”无记忆采样”升级到”短程自一致采样”。模型容量不需要大幅增加,但单次 draft 的接受率显著上升,senior editor 的 verify 成本下降,整体加速提升。
Doesn’t need a huge brain. No, just enough for these few words not to fall apart.01:54
这一招的底层洞见是:drafter 的失败模式不是”猜不对”,而是”前后不一致”。当一个 drafter 写出”the ancient potato”时,前一个 token “the” 和后一个 “potato” 各自独立采样,senior 立刻 reject——但加了 memory 后,drafter 写第一个 token 时就考虑了第二个的合理范围,接受率明显上升。
3. 第二招:提前剔除”显然不对”的 token(doomed token pruning) 02:10
视频用”what planet do we live on”的例子说明第二种失败:drafter 写”lasagna”(千层面)开头的回答02:10显然不对。这种 token 不是”猜得不准”,是”一看就不行”——与其等 senior 读完整个 token 再 reject,不如 drafter 自己用低概率信号提前剪枝。
DeepSpark 给 drafter 加了一个 estimator:预测”哪些 token 几乎肯定会被 senior reject” → 这些 token 直接不进 draft 序列 → senior 不需要花 verify 时间。
这条优化把”senior editor 的工作量”从”验证全部 draft”降到”只验证看起来像样的 draft”,节省的 GPU 时间直接折算成加速。这条和第一招是叠加的:drafter 内部一致 + drafter 自剪枝 → senior verify 通过率上升 → 整体加速。
4. 第三招:动态判断 verify 是否值得花 GPU 02:48
第三招是更细的工程优化:不是每一步都让 senior verify,要看”这步是否值得 verify”。
判断逻辑:
- 代码/数学等可预测任务:drafter 写得准 → senior verify 通过率接近 100% → verify 是浪费 GPU,跳过或轻量 verify
- 开放式任务(写婚礼致辞、写作等):drafter 越往后越容易翻车(“the ancient potato”)02:53 → 越往后的 token 越要密集 verify
这条动态判断把”speculative decoding 的统一流程”改成”上下文敏感”——drafter 强的地方少 verify、弱的地方多 verify,GPU 时间精准分配。
Code and math, great. Open-ended chat, not so much. This is where that lasagna strikes back.04:15
这一招的工程价值是:不同 workload 的加速效果天差地别,不能拿代码任务的加速数据去承诺写作任务。
5. 60-85% 是日常加速,661% 是边角数 03:29
论文自报的数据:对照自家 MTP-1(原 multi-token prediction baseline),DeepSpark 给出 60% 到 85% 的 speedup03:29。这是”日常范围”——大部分 workload 跑出来都在这区间。
但论文里还有一个 661% 的吞吐数字03:47,Two Minute Papers 专门点出”that is not the normal everyday speed up. That only happens in corner cases where the old MTP-1 system is running out of room”03:53。
这是一个反”论文里随便挑大数当卖点”的提醒:做技术评估时,要把”边角数”和”典型数”分开;661% 在自家旧基线撞墙的场景下才出现,不能作为”DeepSpark 普遍提速 661%“来宣传。
6. DeepSpark 是推理时优化,不是新模型 04:41
最后一点很关键:DeepSpark 不是”新的更聪明模型”,而是让一个已有的”繁忙大脑”变得更快04:41。这条性质决定了两件事:
- 它免费——open science(视频用”open science and I think that is amazing”作为结尾04:50)
- 它不能从外部直接接入到闭源 API——需要三件套:① 一个匹配的 draft model,② target model 概率的访问,③ 能高效并行 serve 的系统。闭源 API 不会暴露 target model 的概率,所以这条技术对 Claude/GPT 这类闭源 API 无效
这条工程约束把 DeepSpark 定位为”自托管 / 开源部署”的优化技术,不是”所有用户都能用”的工具。
可执行步骤
- 如果你自托管开源 LLM,先评估 drafter 自身的”内部一致性”:给 drafter 加一格小 memory(让相邻 token 互相 attend),看 draft 接受率是否上升。
- 在 draft 输出阶段加 low-probability token 的剪枝:概率低于阈值(经验值 ~0.05)的 token 直接 drop,不让它进 senior verify 队列。
- 按 workload 类型分两路 serve 配置:代码/数学走”轻 verify 或跳过 verify”,开放式任务走”密集 verify”——给每条 query 动态选 serve 路径。
- 评估时不只看”边角数”:在自家常见 workload 上测一个 batch 的平均加速,看 60-85% 这个区间是否稳定。
- 闭源 API 用户跳过此条——DeepSpark 需要 target 概率访问,闭源 API 不会暴露。
关联
- 2026-04-25-在VPS上自托管Hermes Agent与Dashboard面板:互补——自托管场景下 DeepSpark 这类推理优化才有用,闭源 API 用户拿不到。
术语
- speculative decoding(用 draft 模型猜一段、target 模型逐 token verify 的加速方法,核心是”用便宜模型替贵模型多想几步”)
- MTP-1(DeepSeek 自家既有的 multi-token prediction baseline,DeepSpark 的对照基线)
- draft model(猜下一段 token 序列的小模型,要求”快 + 准 + 内部一致”)
- target model(被 draft 加速的”主”模型,逐 token 验 draft 提案)
- doomed token(几乎肯定会被 reject 的 token,DeepSpark 提前剪枝)
- Lambda Cloud(视频末尾赞助方,提供 GPU 用于复现论文实验,链接
lambda.ai/papers)
金句
So, what do you do instead? The solution is unexpectedly brilliant. Well, you hire a junior writer.00:42
用 senior editor / junior writer 比喻把 speculative decoding 的核心机制讲清楚,这一段是理解整支视频的钥匙。
Doesn’t need a huge brain. No, just enough for these few words not to fall apart.01:54
DeepSpark 第一招的工程哲学:不是把 drafter 变大,而是让它”前后不矛盾”。
Just trying to help you avoid some pitfalls. In practical cases, we get 60 to 85% and that is amazing.03:53
专门点出 661% 是边角数、60-85% 才是日常范围——这条对读者做技术评估比技术细节本身更重要。
立场与利益
- 与利益同向(待印证):视频开头”this is measured against MTP-1, their old production multi-token prediction baseline”——选自家旧产品作对照基线,可比但未必是”业内最强对照”。采信前应独立验证:在 Llama-3 70B / Qwen-2.5 等开源主流模型上,DeepSpark 的三招单独 / 叠加带来的加速是否仍在 60-85% 区间。
- 利益中性:DeepSpark 论文已 arxiv 公开(链接见视频 description),可独立下载复现;Lambda 赞助属”提供算力”而非”算力选择影响结论”——不构成方法论偏倚。
- 与利益反向(可信度最高):Two Minute Papers 在视频里主动指出”in the paper you also get a number that says 661% throughput” 然后警告”that is not the normal everyday speed up”——主动拆解作者宣称的数字,这种解构在 AI 论文报道里反而稀缺,提升全片可信度。
- 利益证据:视频末段”I use Lambda to reproduce AI research papers often in minutes … Lambda gives you powerful Nvidia GPUs to run your own experiments”——属明确赞助声明,折扣一档已点出。
价值定位
- 适合谁:自托管 / 开源 LLM 部署者,正在被推理成本/延迟卡住,想了解 “speculative decoding” 工程化方向的最新进展;或者在做 LLM serving 平台,关心 inference-time optimization 的研究边界。
- 解决什么:在”speculative decoding 已经能做到多少加速”这一问题上,给一个具体的最新数字(60-85%)+ 三个工程化优化方向(小记忆 / doomed token 剪枝 / 动态 verify)+ 工程约束(不是 API 外的魔改)。
- 认知 vs 实操:认知为主,实操细节略少(没有给具体 drafter 架构、memory 大小、剪枝阈值)。
- 与 2026-04-25-在VPS上自托管Hermes Agent与Dashboard面板 重叠,但本片独有:speculative decoding 在 DeepSpark 之后的具体加速数字 + 三个工程化 trick(topics 词表:模型与能力)。
自检问题
- 为什么 speculative decoding 的加速瓶颈是 drafter,而不是算力? 答案:drafter 猜得不准 → 大量 token 被 senior reject → 速度起不来;drafter 自身内部不一致(忘记前文、开始/结束短语不匹配)是失败主因。详见 详解1。附 00:42
- DeepSpark 的第一招为什么是”加小 memory”而不是”换大 drafter”? 答案:不是要 drafter 更聪明,而是要它”前后不矛盾”——容量增加对”内部一致性”帮助有限,小 memory 让相邻 token 互相约束,接受率直接上升。详见 详解2。附 01:54
- “doomed token”为什么比”事后 reject”更省 GPU? 答案:事后 reject 要等 senior 读完整个 token 才否决,doomed token 让 drafter 自己用低概率信号提前剪,senior 不需要花 verify 时间。详见 详解3。附 02:10
- DeepSpark 对代码/数学 vs 开放式写作的加速效果为什么差异巨大? 答案:代码/数学 drafter 写得准,verify 几乎全过,跳过 verify 反而省 GPU;开放式写作 drafter 越往后越容易翻车,需要更密集 verify。详见 详解4。附 02:48
- 论文里 661% 和 60-85% 两个数应该怎么解读? 答案:60-85% 是日常范围,661% 仅在 MTP-1 旧基线撞墙的边角场景出现;做技术评估时要把”边角数”和”典型数”分开,不能拿 661% 当普遍加速宣传。详见 详解5。附 03:29 和 03:47