Skip to main content

Claude Fable 5 回归、Google 视频开发引擎、DeepSeek 加速推测解码

原文地址:https://www.deeplearning.ai/the-batch/issue-361

本期要点:Claude Fable 5 在被美国商务部出口管制指令暂停三周后于 7 月 1 日恢复服务,这是美国政府首次强制叫停通用模型访问;Google 把 Nano Banana 2 LiteGemini Omni Flash 视频模型打包到同一条 API;DeepSeek 开源 DSpark 推测解码模块,让 DeepSeek-V4 推理提速 50% – 85%;Brain2Qwerty v2 用脑磁图把脑波转文字,多被试联合训练显著优于单人训练。Andrew 提议把 SPEC.md 作为人类决策的长期记忆载体。

编者按:AI tokens 便宜,人类 tokens 珍贵

作者:Andrew Ng

Restoration of Claude Fable 5, Gemini's Video Dev Engine, DeepSeek Speeds Up Speculative Decoding

代理型编码回路(agentic coding loops)的关键,是让 Agents 持续工作到满足某个条件——比如达到产品规格说明书的要求。规格、评估、测试集的设计往往是整套系统中最难、最需要人类知识注入的部分。一旦规格清晰,剩下的路径(例如让编码代理迭代)就顺理成章。本期 Ng 分享搭建 0 到 1 产品时驱动编码回路的实用做法,组织原则就一句话:AI tokens 很便宜,人类 tokens 是金子。(是的,我知道人类不会真的 tokenize,但我天天和 token 打交道,已经把自己当成给计算机输送 token 的人了。)

搭大型复杂系统值得花时间提前架构——选哪个数据库、怎么切分服务、锁定哪些第三方依赖、前后端 API 边界怎么划。这些问题想清楚能避免后期想改却被旧决策卡死。

但搭 0 到 1 原型或陌生领域应用时,Ng 倾向于更快、更不假思索:立刻指挥编码代理开始构建,看它做出来什么,再做下一轮决策。没必要花一小时人类时间反复推敲设计规格——AI 代理花 20 分钟搭出一个简单原型,不如花 10 分钟写一份粗糙规格,看看代理做出什么,检查它的假设,再迭代规格、再继续。这避免了"规格驱动开发"沦为新瀑布流(写规格成了卡进度的一道关卡)。

许多应用原型第一版都有令人困惑的 UI 设计,Ng 修了规格才改好;事先无论怎么打磨初始规格,他都没法未卜先知这些修改点。靠人类 tokens 独立想出这些点成本太高——看到错在哪里、再解释怎么对,更便宜。

软件项目成熟后,编码代理可能连续工作数小时去满足复杂规格;但在早期,扔掉整个代码库从零重来完全没问题。这些代码用人类时间和 token 成本都很便宜,从测试中学到的东西反而更有价值

而且,对着已有的实现(有时 Ng 会让代理给几版不同设计)提反馈,能高效产出新的人类 tokens 来迭代规格、驱动下一轮。如果你正在做 0 到 1 产品,尽早让编码代理开工——哪怕感觉太早。看它做出来什么,把它当起点,记录你的反应,然后继续迭代。

这里同样可以让代理做大部分工作。一个常见痛点:你告诉编码代理某件事,过一会(可能是上下文压缩之后)它忘了。Ng 期待未来的编程框架能缓解这个问题,但目前他会在做关键决策时让代理把这个决策写到某处持久化——比如写到 SPEC.md。一个项目跑下来,编码代理可能产出上百万 tokens,远多于人类开发者会输入的内容。所以代理如果自己发现某件事后又忘了,重新发现要再烧一批 tokens,这还可以接受。但如果是人类说过的话被忘,就得再说一遍——更多金子打水漂。

过去几个月编码代理因为模型进步健忘得少了,但偶尔还会忘。Ng 在原型里看到不满意的地方时,往往不仅让代理修问题,还让它更新规格和测试计划,让代理未来的停止条件里包含"再次确认这个问题不能发生"。这是把人类 tokens 当金子用的方式之一。

Keep building!

Andrew


Claude Fable 5 与 Mythos 5 暂停三周后回归

Anthropic 的 Claude Fable 5 与更强一些的 Claude Mythos 5 在被美国商务部出口管制指令暂停 三周后恢复服务。

发生了什么

7 月 1 日 Anthropic 恢复了 Claude Fable 5 在 Claude API、Claude Code 以及其他 Anthropic 自有平台上的客户访问。作为与美国政府的协议一部分,Anthropic 给模型加上了额外护栏,阻止一部分网络安全相关查询并把它们路由到能力较弱的 Claude Opus 4.8

事件时间线

  • 4 月:Anthropic 向部分政府和科技合作伙伴 预览 Claude Mythos,仅限运营关键基础设施的公司,用于识别和修补安全漏洞
  • 6 月 9 日:Anthropic 向全球客户发布 Claude Fable 5,护栏阻止了部分网络安全和生物研究类查询,模型还 有意降级对"如何构建强 AI 模型"类问题的回答
  • 6 月 12 日:美国商务部对 Anthropic 发布出口管制指令,暂停所有外籍人士访问Claude Fable 5 与 Mythos 5——无论他们身处何地,理由是国家安全。同一天 Anthropic 禁用全球用户对这两个模型的访问
  • 6 月 26 日:美国政府告知 Anthropic 可以重新部署 Claude Mythos 5 给部分政府机构。商务部长 Howard Lutnick 在给公司的信中说,数周的谈判取得了"显著进展",Anthropic 承诺与政府合作制定 AI 模型安全评估的协议与标准
  • 6 月 30 日:在 Anthropic 实施新安全护栏以应对前述 Amazon 研究员识别的网络安全风险后,Fable 5 和 Mythos 5 的出口管制解除。Anthropic 宣布 Claude Fable 5 自 7 月 1 日起对全球用户可用,AWS、Google Cloud、Microsoft Foundry 的客户访问紧随其后

回归后的问题

Claude Fable 5 回归数日后,部分用户报告模型表现相较早期版本有所下降,基础生物科学问题被审查、编码任务受到更多限制。Anthropic 在 X 上发文说部分例行编码任务会回退到 Opus 4.8,但公司将在接下来几周"更好地区分真正的滥用与合法请求"。

另一些用户抱怨 Fable 5 即将只覆盖订阅用户 50% 使用额度的访问,超出部分需要按额度付费。Anthropic 最终把付费订阅者的完整 Fable 5 访问延至 7 月 12 日。

背景

今年 2 月已经发生过高风险冲突:五角大楼在 Anthropic 拒绝提供去掉护栏(防止用于大规模监控或自主武器)的版本后,将 Anthropic 列为"供应链风险"。这一后果性的认定意味着国防部及其合作伙伴不能再使用 Anthropic 产品。但 6 月的出口管制令是政府干预首次导致通用模型访问被暂停。OpenAI 近期发布的 GPT-5.6 家族三个新强模型发布前,也有政府强制的能力预览。

为什么重要

美国政府对 Anthropic 与 OpenAI 顶级模型的审查标志着 AI 行业的转折点,将影响未来模型发布节奏。出口禁令意味着各国政府越来越愿意在最强 AI 系统大规模部署前审查其能力,由此带来模型应如何发布、谁能访问的问题,还可能影响各国维持技术领导力的能力。看到美国政府限制顶级模型访问的国家有强烈动机去发展自己的前沿模型,或转向限制较少的合作伙伴,以保护其 AI 主权。

未来展望

如果政府决定介入 AI 模型发布——我们怀疑这种做法的明智性,因为有监管俘获导致少数模型过审的风险——至少应该走可预期的流程。企业需要知道把产品推向市场需要达到什么标准。任何模型发布治理框架都需要公平、稳定、透明、足够宽松,以降低不确定性、鼓励投资、避免临时拍板导致创新延迟和公众信任流失。


Google 把 Nano Banana 2 Lite 与视频模型打包出售

Google 为媒体类开发者搭建了低成本、高吞吐的流水线:把 Gemini 最快的图像模型与速度相近的多模态视频模型配在一起,后者能把图像转成带同步声音的视频。

两款新模型

  • Nano Banana 2 Lite(正式名称 Gemini 3.1 Flash Lite Image):Google 最快、最低成本的图像模型,定位为初代 Nano Banana 的替代品
  • Gemini Omni Flash:Google 最新视频模型,消费者侧已在 Google 应用中用到了 6 周,此次通过 API 开放给开发者。Google 在发布稿中把这两款模型称为"双拼套餐"——用图像模型廉价生成一张(或一百张)静态图,再通过同一对话界面把最好的一张做成视频

输入输出

模型输入输出
Nano Banana 2 Lite文本 + 图像图像(最高 1K 分辨率)+ 文本
Gemini Omni Flash文本 + 图像 + 视频720p 视频 + 同步音频,单段最长 10 秒

可用渠道:两款模型均在 Gemini API、Google AI Studio、Gemini Enterprise Agent Platform、Gemini app、Google Flow 上提供。Nano Banana 2 Lite 还接入 AI Mode in Search、NotebookLM、Google Photos、Stitch、Google Ads;Gemini Omni Flash 还接入 YouTube Shorts。

价格

模型价格
Nano Banana 2 Lite$0.034/张 1K 分辨率图像
Gemini Omni Flash$0.10/秒 720p 视频

性能

模型Arena.ai 排名
Nano Banana 2 LiteImage Arena 第 5 名(1,250 Elo),比更贵的 Nano Banana Pro(1,245 Elo)略胜,但价格低 10 美分/千图;榜首是 OpenAI GPT-Image-2(1,386 Elo)
Gemini Omni Flash视频生成 第 1(1,527 Elo);视频编辑榜第 2(1,347 Elo),仅次于字节 Seedance 2.0(1,377 Elo)

速度:Nano Banana 2 Lite 出图约 4 秒;Gemini Omni Flash 生成时长未披露。

未披露内容:两款模型的参数量和训练数据均未公开。

工作原理

Google 为每个模型发布了 model card,给出基础架构和已知限制,但保留参数量与训练数据细节

Nano Banana 2 Lite 是基于 Gemini 3.1 Flash-Lite(Google 的轻量多模态基础模型)的多模态 Transformer,在文本与图像上训练。Gemini Omni Flash 是文本、图像、音频、视频上训练的多模态 Transformer。

Gemini Omni Flash 能从文本提示、起始图像或参考图像中返回一段 720p + 原生音频的短片。它的编辑是对话式的:在 Google 的 Interactions API 内,模型保留会话历史,每一条指令都修订上一段片段而不是重新生成,最多支持三步顺序编辑。

图生视频模式是两模型协作的关键——通过同一个 Gemini API(或在 Google AI Studio 网页里对话式操作),Nano Banana 2 Lite 的图像可以作为起始帧传给 Gemini Omni Flash。

背景

Google 的"Nano Banana"绰号最初是 Gemini 2.5 Flash Image 在 2025 年 8 月上线时使用的占位代号。Google 此后为家族加了后缀——2025 年 11 月的 Nano Banana Pro、2026 年 2 月的 Nano Banana 2,再加这次的 Nano Banana 2 Lite。Gemini Omni Flash 最早出现在 5 月 19 日的 Google I/O 上,仅向 Gemini app 订户、Google Flow 和 YouTube Shorts 提供。

为什么重要

媒体生成已经廉价、快速到可以在 app 内运行时调用,而不是作为慢速、经过精心策划的制作步骤——这标志着它的单位经济性发生了变化。10 秒的短片可以拼接成更长的作品,开发者可以在自己 app 内自动化生成。其中一种典型用例是高量级数字广告和社交媒体内容,例如据报道 Meta 正在搭建一套系统,从一张产品图和一个预算出发自动生成广告素材——包括视频。

我们怎么看

把图像与视频生成当成同一个市场是个错误。Nano Banana 2 Lite 和 Gemini Omni Flash 的分辨率不够好莱坞用,速度与成本改进对爱好者用户的价值也有限。但就像我们在文本和音频上看到的,给多媒体加上自动化、交互、个性化与代理型工作流,能释放更多价值。这是放开想象力的好时候


DeepSeek 的 DSpark 把推测解码再推一步

DeepSeek 搭出了一个推测解码模块,让自家生产模型的文本生成速度提升 50% 以上又不牺牲准确率,然后把技术开源

做了什么

北京大学与 DeepSeek 的 Xin Cheng 等人提出了 DSpark——一种推测解码方法,由小模型(叫 draft module)生成 token,再由大模型单次验证。团队把 DSpark 接到 DeepSeek-V4 模型上,之后发布了 checkpoint DeepSeek-V4-Pro-DSparkDeepSeek-V4-Flash-DSpark——把 draft module 加到未改动的 DeepSeek-V4-Pro / V4-Flash 预览权重上。修改后的 DeepSeek 模型以 MIT 许可证放在 Hugging Face 上免费下载,可商用。

核心洞见

推测解码里,小 draft module 提议一批 token,被服务的大模型单次验证整批。这次计算在每一个被提议位置上同时算出大模型自己的下一 token 选择,所以最终保留下来的就是和这些选择一致的最长 draft 段。生成速度被加快,同时验证环节保证文本质量。

作者识别出影响速度的三个因素:生成 draft token 的成本、draft token 通过验证的存活数量、大模型验证量。以往的 draft 设计通常在前两个之间权衡,第三个则不论服务器负载都保持不变。DSpark 同时作用于三者,主要贡献在动态调节第三个——轻负载时验证更多 draft token,重负载时少验证以腾出容量服务其他用户

工作原理

DSpark 的 draft module 挂在更大的目标模型上,目标模型权重冻结。DeepSeek 只训练 module 的三个部分:drafting backbone、一个小型顺序组件、一个 confidence head——module 直接借用目标的 embedding 层与输出头。

离线实验里,团队用 Open-PerfectBlend 开源数据集的 prompt 喂目标模型,再用目标模型的回复训练 drafter。训练让 drafter 拟合目标模型的 token 概率分布,让 confidence head 估计每个 token 通过验证的概率。

DSpark 的 backbone 借自另一个团队的早期 drafter DFlash。像 DFlash 一样,DSpark 单次并行提议一个块里的所有位置 token。一次并行的代价与块长度无关,所以并行 drafter 能比逐 token drafter 多堆几层,初始猜测更强。但因为 drafter 独立预测每个位置,它会跨合法延续"拼接"——作者举例,当上下文既可接"of course"也可接"no problem"时,它可能拼出"of problem"。块末准确率急剧下降,浪费了算力

为应对这点,作者加了一个紧凑的顺序组件——他们叫它 Markov head,根据刚刚生成的 token 调整每个位置的概率。例如 drafter 挑了"of"之后,下一 token 的概率倒向"course"远离"problem"。这一步逐 token 跑,但因为太小,把 draft 从 4 token 增长到 16 token 只让每轮延迟比未改的 DFlash backbone 多 0.2 – 1.3 个百分点

confidence head 估计每个 draft token 在"前面全部存活"条件下通过验证的概率。这些估计偏乐观,需要真实量级而不是排序。作者加了校准步骤,逐位置重新缩放估计值,使一连串预测与保留数据上的实际通过率匹配。

服务时,调度器把每 token 的 confidence 估计连乘——draft 要活到某一长度需要前面全部存活,得到每个可能 draft 长度的存活概率。调度器据此为每个请求设定验证长度,目标是在所有用户间最大化期望总输出,参照系统启动时测量的各负载档位速度曲线。

结果

DSpark 在开源权重模型上和之前的 draft 设计对比,离线评估全面胜出,在生产环境里也击败 DeepSeek 之前的部署设置:

对比维度表现
平均每轮通过 token 数 vs EAGLE-3Qwen3-4B/8B/14B 上分别提升 30.9% / 26.7% / 30.0%
平均每轮通过 token 数 vs DFlash同样三个尺寸上分别提升 16.3% / 18.4% / 18.3%
在 Gemma4-12B(非 Qwen3 系列)增益保持,说明优势不是血统特异

生产环境加速

模型速度提升
DeepSeek-V4-Flash每用户生成速度较前 drafter MTP-1 快 60% – 85%
DeepSeek-V4-Pro每用户生成速度较 MTP-1 快 57% – 78%

DeepSeek 把 DSpark 和旧 draft module 在不同硬件速度下做了对比。在每用户 80 tokens/秒(V4-Flash)35 tokens/秒(V4-Pro) 条件下,DSpark 让系统每秒总生成 token 数分别提升 51% 和 52%。在每用户保底 120 tokens/秒(V4-Flash)与 50 tokens/秒(V4-Pro)条件下,提升达到 661% 与 406%。实际上相当于每用户生成速度 60 – 85% 的加速。DeepSeek 旧 drafter 在更高速度下几乎失效,所以作者把这些数字解读为"开辟了新的可行运行点"而不仅仅是单纯的提速。

背景

推测解码由 Google Research 的作者 2022 年首次描述。该技术此后成为生产部署的标配,token draft module 设计也越来越多。早期 drafter 是顺序的,逐 token 生成;DSpark 拿来对比的 EAGLE-3 就是这种,用目标模型多层特征预测下一个 token。并行 drafter 之后突破顺序瓶颈——单次并行提议整块 token;DSpark 借来 backbone 的 DFlash 用一个小扩散模型做到这一点。作者报告对 EAGLE-3 高达 2.5 倍加速,Nvidia 称在其 Blackwell GPU 上把推理速度提升到 15 倍。DSpark 同时保留并行 drafter 的速度与顺序 drafter 的连贯性。DeepSeek 从 DeepSeek-V3 开始一直用简单的顺序 drafter,直到 DSpark 这种"并行 + 顺序"混合设计在 DeepSeek-V4 预览上线两周后替换了它。

为什么重要

部署模型每输出一个 token 都让提供商花钱、让用户等时,这两点共同限制了开发者能构建的东西。常见的应对——更小的模型或量化——会牺牲准确率。DSpark 不动模型权重、不降输出质量,只砍成本与时间,整体上等于更便宜的 token 与更快的响应。

我们怎么看

DeepSeek 的名号是廉价训练强模型、把基于强化学习的推理模型这类技术放到公开论文里很高兴看到它也在优化模型部署,并把成果与代码开放给所有人用


不动手打字:用脑磁图把脑波变文字

想象你在打一句话。但不是键盘、操纵杆或眼动仪——而是环绕你头部的设备读取你的意图,把这句话打到屏幕上。

做了什么

研究者公布了 Brain2Qwerty v2——前代系统把脑波转文字的升级版。作者团队来自 Meta、法国国家科学研究中心、Adolphe de Rothschild 医院基金会、巴斯克认知-脑-语言中心、巴黎西岱大学、法国信息与自动化研究院。

工作原理

  1. 编码器:把脑活动切成字符。用一个编码器——先 CNN、再 CNN+Transformer 混合(conformer)——生成字符 embedding 并把脑活动分类到字符。编码器靠最小化生成序列与真实字符序列的差异来学习
  2. Aligner:把字符 embedding 转成词 embedding。用一个普通神经网络把字符 embedding 重新嵌入;按预测词(由生成的字符序列中的空格决定)分组并对组内 embedding 取平均,得到词 embedding。Aligner 的训练目标是把生成对的词的 embedding 与 Qwen3 真实词的 embedding 拉近、把与错误词的 embedding 推远
  3. 语言模型后处理:用微调过的 Qwen3-4B 修正词序列。作者给每个被试单独用 LoRA 适配器微调 Qwen3-4B,再把所有被试的 LoRA 适配器取平均

训练数据:9 名被试打英文句子的脑活动,总计 90 小时、2.2 万条样本。记录设备是脑磁图(MEG)——一种非侵入式记录脑磁活动的设备。

结果

Brain2Qwerty v2 全面超过前代:

指标v2v1
词错率(猜错的词占比)39%43%

随训练数据增加,编码器的字符错率(猜错的字符占比)持续下降:

训练数据量字符错率
20 小时~50%
90 小时~25%

在耗尽数据之前未观察到性能平台期

多被试 vs 单被试

训练方式中位词错率
只用单个被试的数据训练66.5%
多被试联合训练47.8%

联合训练显著优于单被试训练。

背景

Brain2Qwerty 第一期项目把 MEG 记录与 EEG(脑电图)做了对比,发现 MEG 读数能更准确地预测文本。Brain2Qwerty v2 只用 MEG,更新了架构并使用了比 v1 更多的训练数据研究者把两版的训练代码开源,并公布了 v1 的数据

为什么重要

数据越多表现越好并不意外。真正令人意外的是,跨多名被试的脑活动训练能改善表现——哪怕是相对只训练单个个体而言。毕竟历史上脑机假体的模型通常是为单个用户训练的。能读懂任何个体的独特脑活动、学习共同模式、并随着数据继续提升,意味着从脑波识别文本的模型可以靠更多被试更多数据来提升,就像过去几年 LLM 靠更多数据提升一样。

我们怎么看

像外科手术植入电极这类侵入式手段,已经让过往患者以个位数百分比的错误率沟通。Brain2Qwerty v2 报告的数字还没有追上侵入式方案但每降低一个百分点,都在逼近未来一个不需要冒着手术风险也能用的脑机接口


本期要点回顾:Claude Fable 5 在被美国商务部出口管制指令暂停后于 7 月 1 日恢复服务,这是政府首次强制叫停通用模型访问;Google 把 Nano Banana 2 LiteGemini Omni Flash 视频模型打包到同一条 API;DeepSeek 开源 DSpark 推测解码模块,让 DeepSeek-V4 推理提速 50% – 85%;Brain2Qwerty v2 用脑磁图把脑波转文字,多被试联合训练显著优于单人训练。Andrew 提议把 SPEC.md 作为人类决策的长期记忆载体,让编程代理不再忘记你说过的关键判断。