---
title: 'DeepSeek 的 DeepSpark 把 speculative decoding 提速到 85%'
video_id: 1yBU41auQhw
url: https://youtu.be/1yBU41auQhw
title_en: "DeepSeek's New AI Speed Hack Is Amazing"
channel: Two Minute Papers
published: 2026-07-07
duration: "5:44"
topics: [模型与能力]
noted: 2026-07-08
value: A
views: '3.7万'
---


[![封面](https://i.ytimg.com/vi/1yBU41auQhw/maxresdefault.jpg)](https://youtu.be/1yBU41auQhw)

> Two Minute Papers · 5:44 · 发布 2026-07-07 · 3.7万次观看(截至抓取) · [观看原视频](https://youtu.be/1yBU41auQhw)

## 主旨

DeepSeek 在新论文 DeepSpark 里给 speculative decoding(用 draft 模型猜一段、target 模型逐 token verify)加了三层工程化补丁:小记忆维持 draft 一致性 / 提前剔除注定被否的 token / 动态判断每步是否值得 verify,让 multi-token prediction 在他们自家 flash/pro 模型上跑出 60-85% 的实测加速(对照自家 MTP-1),论文中孤例报 661% 吞吐仅在旧基线"撞墙"的边角场景。

## 核心论点

1. **speculative decoding 的瓶颈是 draft 模型不够稳,而不是"算力不够"** — 猜不准 → 大量 token 被否 → 速度起不来。([[#1-为什么-speculative-decoding-本质是drafter-准不准-0042|→ 详解1]])
2. **DeepSpark 第一招:给 draft 加一点点 memory 让前一个 token 影响下一个** — 不需要大模型,只需要 draft 不会"前后自相矛盾"。([[#2-第一招drafter-加小-memory-让-token-之间互相关联-0147|→ 详解2]])
3. **第二招:提前剔除"显然不行"的 token,省掉 target model 的 verify 时间** — 用低概率信号当剪枝信号,而不是事后 reject。([[#3-第二招提前剔除显然不对的-tokendoomed-token-pruning-0210|→ 详解3]])
4. **第三招:动态判断"这步 verify 值得花 GPU 时间吗"** — 代码/数学等可预测任务几乎不 verify,开放式写作反而要更密集 verify。([[#4-第三招动态判断-verify-是否值得花-gpu-0248|→ 详解4]])
5. **实测加速 60-85% 是"日常范围",661% 那个是 MTP-1 旧基线撞墙的边角数** — 看论文要分清"基线"和"日常",661% 不能拿来当卖点。([[#5-60-85-是日常加速661-是边角数-0329|→ 详解5]])
6. **DeepSpark 是推理时优化,不是新模型 — 它免费但需要三件套:匹配的 draft model + target 概率 + 能高效并行 serve 的系统** — 不是 API 外的魔改。([[#6-deepspark-是推理时优化不是新模型-0441|→ 详解6]])

## 知识点详解

### 1. 为什么 speculative decoding 本质是"drafter 准不准" [00:42](https://youtu.be/1yBU41auQhw?t=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](https://youtu.be/1yBU41auQhw?t=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](https://youtu.be/1yBU41auQhw?t=107)

DeepSpark 的第一招是给 drafter 加一个"小记忆"——不是大改模型,只让"前一个 token 能影响下一个 token"[01:47](https://youtu.be/1yBU41auQhw?t=107)。这样 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](https://youtu.be/1yBU41auQhw?t=114)

这一招的底层洞见是:**drafter 的失败模式不是"猜不对",而是"前后不一致"**。当一个 drafter 写出"the ancient potato"时,前一个 token "the" 和后一个 "potato" 各自独立采样,senior 立刻 reject——但加了 memory 后,drafter 写第一个 token 时就考虑了第二个的合理范围,接受率明显上升。

### 3. 第二招:提前剔除"显然不对"的 token(doomed token pruning) [02:10](https://youtu.be/1yBU41auQhw?t=130)

视频用"what planet do we live on"的例子说明第二种失败:drafter 写"lasagna"(千层面)开头的回答[02:10](https://youtu.be/1yBU41auQhw?t=130)显然不对。这种 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](https://youtu.be/1yBU41auQhw?t=168)

第三招是更细的工程优化:不是每一步都让 senior verify,要看"这步是否值得 verify"。

判断逻辑:
- **代码/数学等可预测任务**:drafter 写得准 → senior verify 通过率接近 100% → verify 是浪费 GPU,跳过或轻量 verify
- **开放式任务(写婚礼致辞、写作等)**:drafter 越往后越容易翻车("the ancient potato")[02:53](https://youtu.be/1yBU41auQhw?t=173) → 越往后的 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](https://youtu.be/1yBU41auQhw?t=255)

这一招的工程价值是:不同 workload 的加速效果天差地别,**不能拿代码任务的加速数据去承诺写作任务**。

### 5. 60-85% 是日常加速,661% 是边角数 [03:29](https://youtu.be/1yBU41auQhw?t=209)

论文自报的数据:对照自家 MTP-1(原 multi-token prediction baseline),DeepSpark 给出 **60% 到 85% 的 speedup**[03:29](https://youtu.be/1yBU41auQhw?t=209)。这是"日常范围"——大部分 workload 跑出来都在这区间。

但论文里还有一个 661% 的吞吐数字[03:47](https://youtu.be/1yBU41auQhw?t=227),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](https://youtu.be/1yBU41auQhw?t=233)。

这是一个**反"论文里随便挑大数当卖点"的提醒**:做技术评估时,要把"边角数"和"典型数"分开;661% 在自家旧基线撞墙的场景下才出现,不能作为"DeepSpark 普遍提速 661%"来宣传。

### 6. DeepSpark 是推理时优化,不是新模型 [04:41](https://youtu.be/1yBU41auQhw?t=281)

最后一点很关键:DeepSpark 不是"新的更聪明模型",而是让一个已有的"繁忙大脑"变得更快[04:41](https://youtu.be/1yBU41auQhw?t=281)。这条性质决定了两件事:

- **它免费**——open science(视频用"open science and I think that is amazing"作为结尾[04:50](https://youtu.be/1yBU41auQhw?t=290))
- **它不能从外部直接接入到闭源 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](https://youtu.be/1yBU41auQhw?t=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](https://youtu.be/1yBU41auQhw?t=114)

DeepSpark 第一招的工程哲学:不是把 drafter 变大,而是让它"前后不矛盾"。

> Just trying to help you avoid some pitfalls. In practical cases, we get 60 to 85% and that is amazing.[03:53](https://youtu.be/1yBU41auQhw?t=233)

专门点出 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 词表:模型与能力)。

## 自检问题

1. 为什么 speculative decoding 的加速瓶颈是 drafter,而不是算力?
   **答案**:drafter 猜得不准 → 大量 token 被 senior reject → 速度起不来;drafter 自身内部不一致(忘记前文、开始/结束短语不匹配)是失败主因。详见 详解1。附 [00:42](https://youtu.be/1yBU41auQhw?t=42)
2. DeepSpark 的第一招为什么是"加小 memory"而不是"换大 drafter"?
   **答案**:不是要 drafter 更聪明,而是要它"前后不矛盾"——容量增加对"内部一致性"帮助有限,小 memory 让相邻 token 互相约束,接受率直接上升。详见 详解2。附 [01:54](https://youtu.be/1yBU41auQhw?t=114)
3. "doomed token"为什么比"事后 reject"更省 GPU?
   **答案**:事后 reject 要等 senior 读完整个 token 才否决,doomed token 让 drafter 自己用低概率信号提前剪,senior 不需要花 verify 时间。详见 详解3。附 [02:10](https://youtu.be/1yBU41auQhw?t=130)
4. DeepSpark 对代码/数学 vs 开放式写作的加速效果为什么差异巨大?
   **答案**:代码/数学 drafter 写得准,verify 几乎全过,跳过 verify 反而省 GPU;开放式写作 drafter 越往后越容易翻车,需要更密集 verify。详见 详解4。附 [02:48](https://youtu.be/1yBU41auQhw?t=168)
5. 论文里 661% 和 60-85% 两个数应该怎么解读?
   **答案**:60-85% 是日常范围,661% 仅在 MTP-1 旧基线撞墙的边角场景出现;做技术评估时要把"边角数"和"典型数"分开,不能拿 661% 当普遍加速宣传。详见 详解5。附 [03:29](https://youtu.be/1yBU41auQhw?t=209) 和 [03:47](https://youtu.be/1yBU41auQhw?t=227)