Jeff Dean · Google DeepMind

Jeff Dean:占领 AI 的帕累托前沿

2026-02-12 · Latent Space (swyx & Alessio Fanelli) · 1h24m · 原文链接

→ 在 AI 访谈库中阅读(可切换中英、记录进度)
Jeff Dean 谈前沿模型与 Flash 小模型的取舍、蒸馏的作用、Gemini 模型层级设计以及万亿 token 长上下文目标。

Latent Space:AI 工程师播客掌控 AI 帕累托前沿——Jeff Dean

从 2000 年代初重写 Google 搜索技术栈,到复兴稀疏万亿参数模型,再到与前沿 ML 研究协同设计 TPU,Jeff Dean 几乎在悄无声息中塑造了现代 AI 技术栈的每一层。作为 Google 首席 AI 科学家和 Gemini 背后的核心推动者,Jeff 亲历了多次规模扩展革命——从 CPU 和分片索引,到能够跨文本、视频和代码进行推理的多模态模型。

Jeff 来到我们的节目,深入解读“拥有帕累托前沿”究竟意味着什么;为什么 distillation 是每一个 Flash 模型突破背后的引擎;为什么能耗(以皮焦耳计)而非 FLOPs 正在成为真正的瓶颈;牵头统一 Google 所有 AI 团队是怎样一种体验;以及为什么下一步的飞跃不会仅仅来自更大的上下文窗口,而是来自那些能营造出“关注到数万亿 token”之假象的系统。

Jeff 1990 年的早期神经网络论文:在并行训练尚未流行前便已涉足;为何他在几十年前就相信规模扩展终将胜出;以及“模型越大、数据越多、结果越好”这一持续了 15 年的信条。

Google 搜索的演进:分片、2001 年将整个索引载入内存、在 LLM 出现之前软化查询语义,以及为什么检索流水线早已与现代 LLM 系统颇为相似。帕累托前沿战略:为什么你既需要前沿的“Pro”模型,也需要低延迟的“Flash”模型;以及 distillation 如何让更小的模型超越前代。

Jeff Dean@JeffDean 我们再次拓展了效率与智能的帕累托前沿。借助 Gemini 3 Flash ⚡️,我们看到了此前仅属于我们最大型模型的推理能力,如今却在 Flash 级别的延迟下运行。这为全新的近实时应用场景打开了大门。 2025年12月17日下午4:06 · 15.7万次查看 52 条回复 · 196 次转发 · 1780 次点赞

Distillation 深度解析:集成 → 压缩 → 将 logits 作为软监督,以及为什么你需要最大的模型来打造最好的小模型延迟作为一等目标:为什么降低 10–50 倍延迟会彻底改变用户体验,以及未来的推理工作负载为何需要每秒 10,000 个 token

基于能耗的思考:每比特皮焦耳;搬运数据的成本是一次乘法运算的 1000 倍;从能量视角看 batching;以及 speculative decoding 作为摊销手段

TPU 协同设计:提前 2–6 年预测 ML 工作负载;推测性硬件特性、精度缩减、稀疏性,以及模型架构与芯片之间持续的反馈循环稀疏模型与“大得离谱”的网络:万亿参数、1–5% 激活率,以及为什么稀疏性自始至终都是正确的抽象统一模型 vs 专用模型:放弃符号系统;为什么通用多模态模型往往能战胜垂直领域的孤岛;以及何时垂直 fine-tuning 仍然有意义长上下文与规模的幻觉:超越大海捞针式的基准测试,迈向能将数万亿 token 聚焦到 117 份相关文档的系统个性化 AI:关注你的邮件、照片和文档(经许可),以及为什么检索 + 推理将解锁深度个性化的助手编程智能体:50 个 AI 实习生,清晰的需求规格作为新的核心技能,以及超低延迟将如何重塑人与智能体的协作为什么创意仍然重要:transformer、稀疏性、RL、硬件、系统——规模扩展并非盲目;各个部分必须相乘叠加

Jeff Dean 的《来自构建大规模分布式系统的软件工程建议》演讲(含信封背面估算)

Jeff Dean 的《每个程序员都应该知道的延迟数字》

Jeff Dean 谈“重要的 AI 趋势”@斯坦福 AI 俱乐部

Jeff Dean 与 Noam Shazeer——在 Google 的 25 年(Dwarkesh)

LinkedIn: https://www.linkedin.com/in/jeff-dean-8b212555

时间戳 00:00:04 — 引言:Alessio 与 Swyx 欢迎 Google 首席 AI 科学家 Jeff Dean 来到 Latent Space 播客 00:00:30 — 拥有帕累托前沿与平衡前沿模型和低延迟模型 00:01:31 — 前沿模型 vs Flash 模型 + distillation 的作用 00:03:52 — distillation 的历史及其最初动机 00:05:09 — distillation 在现代模型扩展中的角色 00:07:02 — 模型层级(Flash、Pro、Ultra)与 distillation 来源 00:07:46 — Flash 模型的经济效益与广泛部署 00:08:10 — 延迟对复杂任务的重要性 00:09:19 — 部分任务的饱和与未来前沿任务 00:11:26 — 关于基准测试,公开 vs 内部 00:12:53 — 长上下文基准测试示例与局限性 00:15:01 — 长上下文目标:关注到数万亿 token 00:16:26 — 纯语言之外的实际用例 00:18:04 — 多模态推理与非文本模态 00:19:05 — 视觉与运动模态的重要性 00:20:11 — 视频理解示例(提取结构化信息) 00:20:47 — LLM 检索的搜索排序类比 00:23:08 — LLM 表征 vs 关键词搜索 00:24:06 — Google 搜索的早期演进与内存索引 00:26:47 — 可扩展系统的设计原则 00:28:55 — 实时索引更新与重新抓取策略 00:30:06 — 经典的《每个程序员都应该知道的延迟数字》 00:32:09 — 内存与计算的成本以及能耗强调 00:34:33 — TPU 与模型服务的硬件权衡 00:35:57 — TPU 设计决策与 ML 协同设计 00:38:06 — 使模型架构适应硬件 00:39:50 — 替代方案:基于能量的模型、speculative decoding 00:42:21 — 开放研究方向:复杂工作流、RL 00:44:56 — 非可验证 RL 领域与模型评估 00:46:13 — 从符号系统转向统一 LLM 00:47:59 — 统一模型 vs 专用模型 00:50:38 — 知识 vs 推理以及检索 + 推理 00:52:24 — 垂直模型专业化与模块 00:55:21 — 垂直领域的 token 数量考量 00:56:09 — 低资源语言与上下文学习 00:59:22 — 起源:Dean 的早期神经网络工作 01:10:07 — AI 编程与人类–模型交互风格 01:15:52 — 清晰需求规格对编程智能体的重要性 01:19:23 — 预测:个性化模型与状态检索 01:22:36 — 每秒 token 目标(10k+)与推理吞吐 01:23:20 — 节目结语与致谢

Alessio Fanelli [00:00:04]: 大家好,欢迎收听 Latent Space 播客。我是 Alessio,Kernel Labs 的创始人,与我一起的是 Latent Space 的编辑 Swyx。

Shawn Wang [00:00:11]: 大家好,大家好。我们在演播室与 Google 首席 AI 科学家 Jeff Dean 一起。欢迎。谢谢邀请我。能请您来演播室感觉有点 surreal。我看过您的很多演讲,而且显然您的职业生涯非常传奇。所以,首先必须要说,恭喜你们掌控了帕累托前沿。

Jeff Dean [00:00:30]: 谢谢,谢谢。帕累托前沿是好事。能处在那个位置很好。

Shawn Wang [00:00:34]: 是啊,我的意思是,我认为这是两者的结合。你必须拥有帕累托前沿。你既要有前沿能力,也要有效率,然后提供一系列人们喜欢使用的模型。而且你知道,这部分工作始于你们的硬件研究。一部分是你们的模型工作,而且我相信你们积累了很多 secret sauce。但是,看到这一切汇聚到如此先进的程度,实在令人印象深刻。

Jeff Dean [00:01:04]: 没错。我是说,我认为正如你所说,这并非单一因素决定,而是整个技术栈上上下下的诸多环节共同作用。所有这些结合在一起,才使我们能够打造出能力极强的大模型;同时也包括各类软件技术,把这些大模型的能力下放到体积小得多、轻量得多的模型中,这些模型性价比更高、延迟更低,但就其规模而言依然相当出色。

Alessio Fanelli [00:01:31]: 那么在守住 Pareto Frontier 下界方面,你们承受着多大压力?我觉得那些新实验室总在拼命推高性能前沿,因为他们需要融更多资等等。而你们有数十亿用户。我记得最初你们在做 CPU 相关工作时就在想,如果每个 Google 用户每天使用语音模型三分钟,那就得把 CPU 数量翻倍。今天在 Google 内部是怎么讨论这个问题的?你们如何在“追求前沿”和“我们必须做到、必须实际部署”之间取舍?造出来之后到底该怎么上线?

Jeff Dean [00:02:03]: 是的,我是说,我认为我们始终希望拥有处于前沿甚至推动前沿的模型,因为正是在那里,你才能发现那些去年或半年前稍逊一筹的版本所不具备的新能力。与此同时,我们知道这些前沿模型对很多用例会非常有用,但对其他更广泛的场景来说,它们可能比人们期望的更慢、更贵。所以我觉得我们的目标是,始终保有一款能力很强且价格可承受的模型,以支撑大量低延迟用例。人们能更顺畅地拿它们来做 agentic coding;同时再配上一款高端的前沿模型,专门用于深度推理、解决非常复杂的数学问题之类的事情。并不是说只能二选一,两者都有用。所以我们希望两条线同时推进。另外,通过 distillation——这是让小模型变得更强的关键技术——你必须先有前沿模型,才能把它 distill 到更小的模型里。所以这并非二选一,你其实需要前者,才能真正得到一个能力很强但规模更适中的模型。

Alessio Fanelli [00:03:24]: 毕竟你和 Jeffrey 在 2014 年就提出了这套方法。

Jeff Dean [00:03:28]: 也别忘了 Oriol Vinyals。

Alessio Fanelli [00:03:30]: 那是很久以前的事了。但我好奇的是,你如何看待这些想法的周期,比如稀疏模型,你会如何重新评估它们?在下一代模型中,你觉得哪些东西值得再回头看?你研究过那么多后来极具影响力的想法,但在当时,它们未必给人那种感觉。

Jeff Dean [00:03:52]: 我是说,distillation 最初的动机是因为当时我们有一个非常大的图像数据集,大约 3 亿张图像可以用来训练。我们发现,如果你针对不同图像类别的子集训练专门的模型,比如这个专门识别哺乳动物,那个专门识别室内场景之类的,你可以对这些类别做聚类,先在更广泛的大规模图像集上做预训练,然后再用富集的数据流继续训练,这样性能会好得多。接着,如果你把这大约 50 个独立训练的专家模型当作一个大型 ensemble 来使用,虽然效果不错,但部署上线并不现实,对吧?所以 distillation 的想法应运而生:既然我们想真正把它部署上线,训练了这么多独立的专家模型,能不能把它们压缩成一个适合实际部署的形态?这其实和我们今天做的事并没有本质不同。只不过今天,我们不再是 ensemble 50 个模型,而是先训练一个规模更大的模型,再通过 distillation 把它压缩到一个规模小得多的模型里。

Shawn Wang [00:05:09]: 对。我还有点好奇,distillation 和 RL 革命之间是不是也存在某种关联。我试着解释一下我的意思:RL 本质上会让模型在某个分布区间上表现特别突出(spike),你可以通过 RL 让模型在某些方面很强,但有时候……它在其他领域可能会有损,这是一种不太均匀的技术。但你可以把它 distill 回来,我觉得大家普遍的梦想是,能够在提升某些能力的同时,不在其他任何方面退化。这种无损的能力融合,我觉得某种程度上应该是一个 distillation 过程,但我还说不清楚,也没看到太多相关论文。

Jeff Dean [00:06:01]: 是的,我倾向于认为 distillation 的一大关键优势在于,你可以用一个很小的模型,配合一个非常庞大的训练数据集,通过多轮迭代来获得收益,因为这时你拿到的是大模型输出的 logits,用来引导小模型表现出正确的行为,而仅靠 hard labels 是无法达到这种效果的。所以我觉得我们观察到的现象是,通过 distillation,你可以非常接近最大模型的性能。这对很多人来说似乎是一个不错的平衡点,因为它让我们能够——在 Gemini 的多代模型中——做到下一代的 Flash 版本和上一代 Pro 版本相当,甚至明显更好。我觉得我们会继续保持这个方向,因为这是一个很好的趋势。

Shawn Wang [00:07:02]: 对了,Dara 问过,最初的路线图是不是 Flash、Pro 和 Ultra。你们是拿着 Ultra 来做 distillation 吗?那才是核心富矿?

Jeff Dean [00:07:12]: 我的意思是,我们有很多种不同的模型。有些是内部模型,不一定会对外发布或上线。有些是我们 Pro 级别的模型,我们也可以从 Pro 级别 distill 到 Flash 级别。所以我认为这是一套非常重要的能力。另外,inference time scaling 也是提升模型能力的有效手段。

Shawn Wang [00:07:35]: 嗯,太酷了。显然,我觉得 Flash 的经济性带来了绝对的主导地位。最新数字好像是 50 万亿 token?我也不确定,反正每天都在变。

Jeff Dean [00:07:46]: 是的,是的。不过就市场份额而言,希望还在涨。

Shawn Wang [00:07:50]: 不,我是说,从经济角度上看,因为 Flash 太经济了,你可以把它用在所有地方。现在 Gmail 里有它,YouTube 里有它,对,无处不在。

Jeff Dean [00:08:02]: 我们也在更多搜索产品中使用它,包括各类 AI mode reviews。

Shawn Wang [00:08:05]: 天哪,Flash 已经应用到 AI mode 了。天哪,对,我甚至都没意识到。

Jeff Dean [00:08:10]: 我认为 Flash 模型的一个很好的地方在于,它不仅更便宜,而且延迟更低。我觉得延迟对这些模型来说其实是一个相当重要的特性,因为我们希望模型做更复杂的事情,这意味着当你要求模型执行时,它需要生成更多的 token。所以,如果你要让模型做某件事,直到它真正完成你交代的任务——因为现在你要求的不再是“给我写个 for 循环”,而是“给我写一整个软件包来做 X、Y 或 Z”。因此,拥有能做到这一点的低延迟系统显得非常重要。而 Flash 就是实现这一目标的一个方向、一种方式。显然,我们的硬件平台也为我们的 serving stack 带来了很多有趣的方面,比如 TPU,TPU 上芯片之间的 interconnect 其实性能非常高,而且很适用于例如长上下文场景的 attention 操作,或者拥有大量专家的 sparse models。这些方面对于如何在大规模场景下实现可 serving 至关重要。

Alessio Fanelli [00:09:19]: 对。你有没有觉得,这种类似 Flash 原型的蒸馏技术会有一个临界点,大概延迟一代左右?我有时会想,在某些任务上,capabilities 就好像今天的 pro 模型已经能把某类任务做到饱和了。那么下一代,同样的任务就能在 Flash 的价格点上做到饱和。我觉得对于大多数人们使用模型的场景而言,再过两代,Flash 模型基本上就能胜任所有事情了。当大部分用户都觉得 Flash 模型够用时,你们怎么在经济上保持继续推进 pro 模型前沿的动力?我很好奇你对此怎么看。

Jeff Dean [00:09:59]: 我认为是这样的——如果人们要求模型做的事情的分布是静态不变的话,对吧?但实际情况往往是,随着模型能力变强,人们会要求它们做更多的事情,对吧?就我自己而言,我确实如此。比如一年前我会用我们的模型做一些编码任务,当时它在一些简单的事情上表现还行,但更复杂的事情就做得不太好。而后来我们在更复杂的编码任务上取得了巨大进步。现在我会让它去做复杂得多的东西。而且我认为这不仅限于编码,还包括比如现在你可以问:能不能分析全球所有的可再生能源部署情况,然后给我一份关于太阳能电池板部署的报告之类的。这比一年前人们会问的任务要复杂得多。因此你总是需要能力更强的模型去推动前沿。这也让我们获得 insight:到底哪些地方会出现瓶颈?我们如何在那些特定领域改进模型,从而让下一代变得更好?

Alessio Fanelli [00:11:11]: 嗯。你们内部有没有使用什么 benchmark 或者测试集?因为看起来每次都是报同一批 benchmark,然后就只是从 97 分变成了 99 分。你们是怎么在内部持续推动团队的?或者说,你们到底在朝着什么目标建设?

Jeff Dean [00:11:26]: 我认为,benchmark 尤其是那些公开可获取的外部 benchmark,是有其用处的,但它们往往有一个效用生命周期。刚推出的时候,可能对当时的模型来说还挺难的。我觉得最好的 benchmark 是那种初始得分大概在 10% 到 20% 或 30%,而不是更高的那种。然后你可以针对该 benchmark 所评估的能力进行提升,把它做到 80%、90% 左右。我认为一旦达到 95% 左右,你再死磕这个 benchmark 的收益就很小了,因为要么你已经具备了这项能力,要么就存在公共数据 leakage 的问题,或者非常相似的数据已经出现在你的训练数据里了。所以我们有一套内部 held out 的 benchmark,是我们真正关注的,我们确信这些数据完全没有出现在训练集中。有些能力是我们希望模型具备但它目前还没有的,然后我们就可以去评估:怎么让模型在这些事情上做得更好?是需要不同类型的、针对这类任务更专门的数据来训练?还是需要一系列架构上的改进,或者某种模型能力上的提升?哪些东西能帮助它变得更好?

Shawn Wang [00:12:53]: 你有没有遇到过这样的例子,就是某个 benchmark 启发了一项架构上的改进?我就是顺着你的话想了解一下,因为你刚才提到——

Jeff Dean [00:13:02]: 我认为 Gemini 模型的一些长上下文能力,我觉得最早是在 1.5 版本上出现的,其实就是源于这样的思考:我们希望拥有……

Shawn Wang [00:13:15]: 然后所有人立刻都跳出了全绿的图表,所有人都有。我当时就想,怎么大家同时攻克了这个?对吧。

Jeff Dean [00:13:23]: 我认为,而且正如你所说,single needle in a haystack 这类 benchmark 至少在 128K 左右的上下文长度上已经饱和了。实际上现在大家的上下文都已经远远超过 128K 了。我们在尝试推动 100 万甚至 200 万上下文的边界,这很有价值,因为我觉得有很多 use case 需要你把一千页文本或者几小时的视频放进上下文,然后真正有效地利用这些信息,可供探索和利用的信息规模其实很大。不过 single needle in a haystack benchmark 基本已经饱和了。所以你其实需要更复杂的、multi-needle 的,或者更贴近现实的 benchmark:给你所有这些内容,然后让模型从长上下文中产出某种答案,这样才能更好地评估人们真正想用长上下文来做什么。那不仅仅是“你能告诉我这个特定东西的产品编号吗?”

Shawn Wang [00:14:31]: 对,这本质上就是检索,是机器学习里的检索。我觉得有意思的是,我想在更 meta 的层面上探讨的是:你看到一个 benchmark,然后觉得“好,我知道需要在架构上做什么来搞定它”。但问题是,你真的应该去做吗?因为有时候这其实就是一种 inductive bias。就像 Jason Wei——他以前在 Google 工作——会说的话,完全就是这个意思。对,短期来看你会赢,但长期来看,我不确定它是否能 scale。你可能之后还得把它推翻重来。

Jeff Dean [00:15:01]: 我的意思是,我不太喜欢聚焦于我们最终要得出什么具体方案,而是更关注你想要什么能力。我认为我们非常确信,长上下文是有用的,但现在的长度远远不够,对吧?我觉得你真正想要的是,我能在回答问题时关注到整个互联网,对吗?但这不可能通过单纯扩大现有方案来实现,因为现有方案是二次方的复杂度。所以一百万 token 差不多已经是极限了。你不可能把它扩展到一万亿 token,更不用说十亿 token,更不用说一万亿了。但我认为,如果你能营造出一种可以关注到数万亿 token 的假象,那就太棒了。你会为此找到各种各样的用途。你可以关注整个互联网。你可以关注 YouTube 的像素,以及我们能从中提取的更深层的表征。你可以关注单个视频的内容形式,也可以跨多个视频去关注。在个人的 Gemini 层面,你可以在获得许可的情况下关注你的全部个人状态,比如你的邮件、照片、文档、机票信息。我觉得那会非常有用。问题在于,如何通过算法层面和系统层面的改进,让你真正能以有意义的方式关注到数万亿 token?对吧。

Shawn Wang [00:16:26]: 顺便说一句,我算了一下,如果你每天不停地说八个小时,最多也就产生大约十万 token,这很轻松就能装下。

Jeff Dean [00:16:38]: 没错。但如果你说,我想能够理解人们上传到视频里的所有内容。

Shawn Wang [00:16:46]: 另外,我觉得经典的例子是你开始超越语言,进入到蛋白质之类信息密度极高的领域。是的。

Jeff Dean [00:16:55]: 我是说,我认为 Gemini 在多模态(multimodal)方面的一个特点是我们从一开始就希望它是多模态的。所以有时候对人们来说这意味着文本、图像、视频这类类似人类的模态,以及音频这类类似人类的模态。但我认为让 Gemini 了解非人类模态也非常有用。比如来自 Waymo 车辆或机器人的 LIDAR 传感器数据,或者各种健康模态,比如 X 光、MRI、医学影像和基因组学信息。我觉得可能有数百种数据模态,你希望模型至少能接触到——即认识到这是一种有趣的模态,在世界上有特定意义。即使你并没有用所有的 LIDAR 数据或 MRI 数据进行训练,也可以这样做,因为也许在主要预训练数据混合的权衡中加入全部这些数据并不合理,但至少加入一点点其实非常有用。因为这会启发模型意识到这是真实存在的东西。

Shawn Wang [00:18:04]: 嗯。你相信吗,我是说,既然我们聊到这个话题,而且我终于能问你所有我一直想问的问题了,这太棒了。就是,是否存在某种“王者模态”,一种凌驾于其他所有模态之上的模态?一个简单的例子是,视觉(Vision)可以在像素层面编码文本。DeepSeq 有一篇 DeepSeq CR 的论文就是这么做的。视觉。而且视觉也被证明或许可以整合音频,因为你可以把音频做成频谱图,这也是视觉能处理的东西。所以,也许视觉就是王者模态,然后……

Jeff Dean [00:18:36]: 我是说,视觉和运动是相当重要的东西,对吧?运动。嗯,比如视频相对于静态图像,因为进化以大约 23 种独立的方式演化出了眼睛,这是有原因的——它是一种感知周围世界的极其有用的能力,而这正是我们希望这些模型具备的。所以我认为,我们能做到的就是解读我们看到的东西或我们关注的东西,然后帮助我们利用这些信息去做事情。

Shawn Wang [00:19:05]: 我觉得运动,你知道,我还是想提一下,我认为 Gemini 仍然是市面上唯一的原生视频理解模型。所以我经常用它来看 YouTube。很好。

Jeff Dean [00:19:15]: 是的。其实,我觉得人们未必真正了解 Gemini 模型到底能做什么。比如我在一次演讲中用过一个例子。那是一个 YouTube 精彩集锦视频,收录了过去大概 20 年里的 18 个难忘体育瞬间。里面有迈克尔·乔丹在总决赛最后时刻的跳投,还有一些足球进球之类的。你可以直接把视频丢给它,说:你能不能帮我做个表格,列出这些不同的事件是什么、发生日期是什么时候,再加一段简短描述。然后你就能得到一个 18 行的表格,这些信息都是从视频里提取出来的。大多数人可能不会想到能把视频转成类似 SQL 表格这样的东西。

Alessio Fanelli [00:20:11]: Google 内部有没有讨论过,你提到关注整个互联网,对吧?Google 的建立初衷几乎就是因为人类无法关注整个互联网,你需要某种排序来找到所需信息。对 LLM 来说,这种排序很不一样,因为你可以预期一个人只会看 Google 搜索的前五六个链接,但对 LLM 来说,你是不是应该期望它有 20 个高度相关的链接?你们内部是怎么考虑的,如何构建一种 AI 模式,让它可能比人类模式拥有更广泛的搜索范围和跨度?

Jeff Dean [00:20:47]: 我是说,我认为即使在基于语言模型的工作之前,我们的排序系统就是这样构建的。从索引中大量的网页开始,其中很多并不相关。所以你用非常轻量级的方法找出相关的一个子集。这样你就缩小到大概 3 万份文档之类的。然后你逐步细化,应用越来越复杂的算法和越来越复杂的各种信号,最终得到你展示的结果,也就是最后的 10 个结果,或者 10 个结果再加上其他类型的信息。我认为基于 LLM 的系统也不会太不一样,对吧?你会关注到数万亿 token,但你会想找出大约 3 万份文档,也就是大概 3000 万个有趣的 token。然后怎么从这 3 万份进一步缩小到真正应该关注的 117 份文档,以便完成用户提出的任务?我觉得你可以设想这样的系统:你用大量高度并行的处理,借助非常轻量级的模型,先找出最初那 3 万个候选;然后某个系统用稍微复杂一点的模型或一组模型,帮你从 3 万缩小到 117;最后可能让最强的模型来处理这 117 份文档。所以我认为最终一定会是这样的系统,才能真正让你营造出可以关注数万亿 token 的假象。就像 Google 搜索一样——不是假象,而是你确实在搜索整个互联网,但你找到的只是一小部分真正相关的东西。

Shawn Wang [00:22:47]: 我经常跟很多不太熟悉 Google 搜索历史的人说,Bert 基本上很快就被应用到了 Google 搜索里,而且大幅提升了搜索结果的质量,对吧?我手头没有具体数字,但我很确定这对 Google 来说显然是最重要的指标。

Jeff Dean [00:23:08]: 我的意思是,我认为转向基于 LLM 的文本和词汇表示,能让你摆脱那种严格的、必须出现特定词汇的硬性要求,而是真正理解到这个页面或这个段落的主题与查询高度相关。

Shawn Wang [00:23:28]: 我觉得大家没意识到 LLM 已经渗透到了所有这些超高流量的系统里。比如 Google,比如 YouTube。YouTube 有一种语义 ID 机制,基本上 vocab 里的每个 token 或者说每个条目都是一个 YouTube 视频,或者说是用 code book 来预测视频,以 YouTube 的规模来说,这在我看来太不可思议了。

Jeff Dean [00:23:50]: 然后最近 xAI 的 GROK 也是这样。我想说,即使在 LLM 被大规模用于搜索之前,我们就已经非常重视弱化用户实际输入查询时的严格字面匹配。

Shawn Wang [00:24:06]: 那你能不能讲讲这个演进过程?是什么样的发展脉络?

Jeff Dean [00:24:09]: 其实我曾在 2009 年的 Web Search and Data Mining 会议上做过一次演讲,虽然我们从未真正发表过关于 Google 搜索起源的论文,但我们大致经历了四到五代搜索与检索系统的重新设计,时间跨度大约是从 1999 年到 2004 或 2005 年。那次演讲讲的就是这段演进历程。其中一件很关键的事发生在 2001 年,当时我们正努力从多个维度扩展系统。首先,我们想让索引更大,这样就能从更大的索引中检索,这通常总能提升质量,因为如果你索引里没有这个页面,效果肯定不好。其次,我们还需要扩展处理能力,因为流量增长非常迅猛。所以我们做了一个分片系统,随着索引增长不断增加分片数,比如一开始有 30 个分片。如果想把索引扩大一倍,就做成 60 个分片,这样就能控制响应每个用户查询的延迟。然后随着流量增长,你再不断增加每个分片的副本。最后我们算了笔账:在一个数据中心里,假设我们有 60 个分片,每个分片 20 个副本,那就是 1200 台带磁盘的机器。然后我们一算,发现其实一份完整的索引完全可以放进这 1200 台机器的内存里。所以在 2001 年,我们把整个索引放进了内存,这在质量层面带来的提升非常惊人。在此之前,你必须非常小心地控制查询中要查多少不同的词,因为每个词都需要在 60 个分片上各自做一次磁盘寻道。索引越大,效率就越低。但一旦整个索引都在内存里,就完全没问题了。用户原本只输入了三四个词,你现在可以往查询里加 50 个词,因为现在你可以加入同义词,比如 restaurant、restaurants、cafe、bistro 等等。突然间,你就能真正触及词汇的含义,而不是用户输入的字面形式。那是 2001 年,远早于 LLM 时代,但本质上就是在弱化用户输入的严格定义,以便理解其真正含义。

Alessio Fanelli [00:26:47]: 你在设计系统时遵循哪些原则?特别是在 2001 年,互联网规模每年都在翻倍、翻三倍,而且我觉得今天你在 LLM 领域也能看到类似情况,每年的规模和能力跃升都非常巨大。你思考这些问题时有没有什么原则?

Jeff Dean [00:27:08]: 我认为,首先,每当你设计一个系统时,都要先弄清楚哪些设计参数最为关键。比如,你需要处理多少 QPS?互联网有多大?索引需要覆盖多大规模?索引中每个文档需要保留多少数据?检索时如何访问这些数据?如果流量翻倍或翻三倍,系统还能不能很好地工作?我觉得一个好的设计原则是,你要让系统在最重要的特性上能够扩展 5 到 10 倍,但可能不需要设计得超过这个范围,因为经常出现的情况是:如果你为一个量级 X 设计系统,而某个指标突然变成了 100X,这会让你进入一个完全不同的设计空间,这个设计在 X 时并不合理,但在 100X 时却完全说得通。比如从磁盘索引转向内存索引,一旦你有了足够的流量,因为你有足够多的磁盘状态副本,这些机器现在其实有能力在内存中容纳一份完整的索引。这突然间就实现了一种之前完全不切实际的全新设计。所以我很喜欢在动手写大量代码之前,先在脑子里把设计方案过一遍,在设计空间里稍微探索一下。不过正如你所说,在 Google 早期,我们的索引规模扩展得非常快,索引的更新频率也在不断提升。实际上,更新频率才是变化最大的参数,这有点出人意料。以前是一个月更新一次。

Jeff Dean [00:28:56]: 后来我们做到了一个能在不到一分钟内更新任意特定页面的系统。

Shawn Wang [00:29:02]: 是的,因为这是一种竞争优势,对吧?

Jeff Dean [00:29:04]: 因为突然间,对于新闻类查询来说,如果你的新闻索引还是上个月的,那就没什么用了。

Shawn Wang [00:29:11]: 新闻确实是个特殊的存在。你们有没有考虑过把它拆到一个单独的系统上?

Jeff Dean [00:29:15]: 我们确实做了。我们推出了 Google News 这款产品,但你也希望用户在主搜索框里输入的新闻相关查询能得到及时更新。

Shawn Wang [00:29:23]: 所以,是的,这很有意思。然后你还得判断页面属性,决定哪些页面应该更新、以什么频率更新。

Jeff Dean [00:29:30]: 背后有一整套系统在决定更新频率和页面的重要程度。所以即使某个页面的更新频率看起来很低,你可能仍然希望频繁地重新抓取重要页面,因为它变更的概率可能很低,但一旦更新了,价值却很高。

Shawn Wang [00:29:50]: 对对对对。嗯,提到延迟和存储,让我想起了你的一个经典之作,我必须提一下,就是「每个程序员都应该知道的延迟数字」。这背后有什么故事吗?你是不是随手就写下来了?

Jeff Dean [00:30:06]: 我的意思是,这里面大概有八到十种不同的指标,比如缓存未命中(cache miss)需要多长时间?分支预测失败(branch mispredict)需要多长时间?访问主存(main memory)需要多长时间?从美国发一个数据包到荷兰需要多长时间?等等。

Shawn Wang [00:30:21]: 顺便问一下,为什么是荷兰?是因为 Chrome 吗?

Jeff Dean [00:30:25]: 呃,我们在荷兰有一个数据中心,所以,我的意思是,我认为这涉及到了能否进行粗略估算(back of the envelope calculations)的能力。这些都是估算的基本素材,你可以用它们来思考:如果我需要设计一个系统来做图片搜索和结果页的缩略图处理(thumbnailing),我该怎么做?我可以预先算好缩略图,也可以试着从大图实时生成缩略图。那样做会怎样?我需要多少磁盘带宽?会产生多少次磁盘寻道?等等。实际上,有了这些基本数字,你可以在30秒或一分钟之内做思想实验。然后,当你用更高层的库来构建软件时,你也希望能培养出类似的直觉,比如在这种特定类型中查找某个东西需要多长时间。

Shawn Wang [00:31:21]: 下次见。

Shawn Wang [00:31:51]: 就是一个简单的字节转换。那没什么意思。我想知道你有没有,如果你要更新你的……

Jeff Dean [00:31:58]: 我的意思是,我认为很有必要去仔细思考你在模型中进行的计算,无论是训练还是推理。

Jeff Dean [00:32:09]: 通常一个很好的视角是:你需要从内存中调入多少状态,无论是芯片上的 SRAM,还是加速器上的 HBM、外挂内存、DRAM,或者是通过网络传输。然后,这种数据搬运的成本,与在矩阵乘法单元中做一次实际乘法的成本相比,有多昂贵?而那个成本其实非常非常低的,对吧?因为它的量级,取决于你的精度,我认为是低于一皮焦耳(picojoule)的。

Shawn Wang [00:32:50]: 哦,好的。你用能量来衡量。对,对。

Jeff Dean [00:32:52]: 是的。我的意思是,最终一切都是关于能量的,以及如何打造能效最高的系统。然后,把数据从芯片另一端的 SRAM 搬过来,甚至还没出片,只是在同一块芯片的另一端,可能就要花费一千皮焦耳。哦,是的。所以突然之间,这就是你的加速器需要批处理(batching)的原因。因为如果你把模型的某个参数从芯片上的 SRAM 搬进乘法单元,那将花费你一千皮焦耳。所以你最好把你搬过来的这个东西反复利用很多次。这就是 batch 维度存在的原因。因为突然之间,如果你的 batch 是 256 之类的,那还不错。但如果你的 batch 是 1,那就真的很不划算了。

Shawn Wang [00:33:40]: 对,对,没错。

Jeff Dean [00:33:41]: 因为这样一来,你为了做一次一皮焦耳的乘法,却要先支付一千皮焦耳的代价。

Shawn Wang [00:33:46]: 我从未听过基于能量的批处理分析。

Jeff Dean [00:33:50]: 是的。我的意思是,这就是人们要做批处理的原因。理想情况下,你会想用 batch size 为 1,因为延迟(latency)会很低。

Jeff Dean [00:33:56]: 但由此带来的能量开销和计算效率损失是相当大的。所以,是的。

Shawn Wang [00:34:04]: 有没有类似你之前那种把所有东西放进内存的技巧?你知道,我觉得 NVIDIA 在 Grok 上大力押注 SRAM,显然引起了很大轰动。我想知道,这是不是你们用 TPU 时就已经看到的东西,对吧?就是,为了支撑你们那样的规模,你可能早就预见到这一点了。那么,基于你们在那边观察到的情况,形成了哪些硬件上的创新或洞见?

Jeff Dean [00:34:33]: 是的。我的意思是,你知道,TPU 有一种很好的、规则的结构,就是二维或三维的网格(mesh),把一堆芯片连接起来。而且每块芯片都带有 HBM。我认为,在 serving 某些模型时,从 HBM 调数据进来,比从芯片上的 SRAM 调数据,成本要高得多,延迟也大得多。所以如果你的模型足够小,你其实可以做模型并行(model parallelism),把它分布到很多芯片上,这样做能显著提升吞吐量(throughput)并降低延迟。于是你就把你的小规模模型条带化(striping)地分布到比如说 16 块或 64 块芯片上。但如果你这样做,而且整个模型都能装进 SRAM,那就会是很大的优势。所以,这并不令人意外,但确实是个好技巧。

Alessio Fanelli [00:35:27]: TPU 的设计呢?比如,改进方向有多少是由你决定的?这是个很好的例子:有没有办法把那一千皮焦耳降到五十?值得为此设计一款新芯片吗?极端情况是,人们说,你应该把模型烧录进 ASIC,那差不多是最极端的做法了。在变化如此之快的情况下,投入硬件设计值得吗?内部讨论是怎样的?

Jeff Dean [00:35:57]: 我的意思是,我们,比如说 TPU 芯片设计架构团队与更高层次的建模专家之间有很多互动,因为你真的很想利用协同设计(co-design)的能力,基于我们认为 ML 研究方向会走向何方,来决定未来的 TPU 应该长什么样。某种意义上,因为作为 ML 硬件设计师,特别是你从今天就开始设计一款芯片,而这个设计可能需要两年时间才能部署到数据中心。然后这款芯片还需要有合理的生命周期,大概三、四或五年。所以你试图预测未来两到六年,在这个快速变化的领域里,人们会想要运行什么样的 ML 计算。因此,如果有一些有趣的 ML 研究想法,一些我们认为会在那个时间段内开始奏效或变得更加重要的东西,真的能让我们把有趣的硬件特性放进 TPU N+2 里,而 TPU N 是我们现在拥有的。

Shawn Wang [00:37:10]: 哦,周期是加两代。

Jeff Dean [00:37:12]: 大致如此。哇。因为,呃,我的意思是,有时候你可以把一些改动挤进 N+1,但你知道,更大的改动需要芯片……对,在设计周期的更早阶段就确定下来。所以只要我们能做到这一点,通常都是好事。而且有时候你可以加入一些投机性的特性(speculative features),可能只占很少的芯片面积,但如果奏效了,它能让某件事快上十倍。如果没奏效,好吧,你只不过在那上面烧掉了一点点极小的芯片面积,没什么大不了的。有时候改动非常大,那我们就得相当确定这能成。所以我们会非常谨慎地做大量 ML 实验,来向我们证明,这确实是我们想走的路。

Alessio Fanelli [00:37:58]: 那有没有反过来的情况,比如我们已经敲定了这款芯片设计,所以就没法采用某种模型架构,因为它不太适配?

Jeff Dean [00:38:06]: 你需要根据芯片特性调整模型架构,使其在用于训练和推理某一代模型的芯片上都能高效运行。所以我认为这是双向的。有时你可以利用未来一代芯片带来的更低精度特性,因此即使当前这一代芯片还不太支持,你也可以用那种更低精度来训练模型。

Shawn Wang [00:38:40]: 精度到底能降到多低?

Jeff Dean [00:38:43]: 因为有人在说 ternary 之类的。对,我是超低精度的忠实拥趸,因为我觉得这能节省大量时间。毕竟每传输一比特都要消耗皮焦耳,减少比特数是降低能耗的绝佳方式。我认为人们从超低比特精度中获益良多,但同时要为整组权重配上 scaling factors。缩放。这是怎么运作的……

Shawn Wang [00:39:15]: 有意思。所以是低精度,但权重被放大。对。哈。对。从来没考虑过这点。对。有意思。我们既然聊到这个话题,我觉得,当我们做采样时,精度的概念本身就挺奇怪的。我们最终会有所有这些数学运算能力极强的芯片,然后一开始我们却要往里扔一个随机数生成器。所以,现在有一种趋势是转向 energy based 的模型和处理器。我很好奇你对此有何评论,显然你已经思考过这个问题了。

Jeff Dean [00:39:50]: 是的。我认为有很多有趣的趋势。energy based models 是其中之一,你知道,diffusion based models,也就是不按顺序逐个解码 token 的模型,是另一个方向。speculative decoding 也是一种方法,它能让你获得一种等效的、非常小的……

Jeff Dean [00:40:07]: batch factor,比如你一次性预测八个 token,这能让你把实际处理的 effective batch size 提升八倍,然后你可能接受其中五到六个 token。这样一来,在将权重载入乘法器进行 token 预测时,amortization 效果就提升了五倍。所以这些都是很好的技术。我认为从能量——真正的能量,不是 energy based models——以及延迟和吞吐量的视角来审视它们,是非常有价值的。对吧?如果你从这个角度出发,就会引导你找到更好的解决方案,从而能够更便宜、更低延迟地部署更大的模型,或者同等规模的模型。

Shawn Wang [00:41:03]: 对。我觉得这在智力上很吸引人,但还没看到它真正进入主流。不过,我确实觉得这里面有一种诗意:如果我们在硬件底层就做好设计,就不必搞那么多花招了。对,对。

Jeff Dean [00:41:23]: 我的意思是,还有一些更奇特的方向,比如 analog based 的计算基底,而非数字的。我觉得这些非常有趣,因为它们可能做到超低功耗。但我认为你往往最终还是要让它与数字系统对接,而在数模和模数转换过程中,你会损失掉很多功耗优势——这些转换发生在系统的边界和外缘。不过,我认为就能效而言,从我们今天所处的位置出发,还有巨大的提升空间,只要为我们关心的模型打造更优质、更专用的硬件。

Alessio Fanelli [00:42:06]: 你还有其他觉得有趣的研究想法吗?或者有些在 Google 无法推进、但希望看到外部研究者去尝试的东西?我猜你们的研究人员已经够多了。对,我猜你们人手是充足的,不过我们的研究……

Jeff Dean [00:42:21]: 我们的研究版图相当广。我想说,就研究方向而言,有一大堆开放性问题:如何让这些模型更可靠,如何执行包含大量子任务的更长期、更复杂的任务;如何编排模型,让一个模型把其他模型当作工具来调用,从而构建出能够完成远比单一模型所能处理的更重大工作的系统。这非常有趣。还有,如何让结果更可验证,如何让 RL 在非可验证领域发挥作用?我认为这是一个相当有趣的开放问题,因为这会大大拓展模型的能力。我们现在在数学和编程上看到的进步,如果能应用到其他更难验证的领域——只要我们设计出了真正有效的 RL 技术来实现这一点——那就会让模型得到相当大的提升。我是这么认为的。

Alessio Fanelli [00:43:26]: 我很好奇,之前 Noam Brown 来做客时说过,他们已经用 deep research 证明了这是可行的。AI mode 某种程度上也有这种特性,但它不是可验证的。我好奇你觉得这里面有什么有趣的线索。到底是什么?两者都像是对 JSON 做信息检索。所以我在想,检索本身是不是就是可验证的部分?就是你可以打分的那个部分,还是说……对,对。你会如何建模这个问题?

Jeff Dean [00:43:55]: 是的。我认为可以让其他模型来评估第一个模型的结果,甚至包括评估检索到的内容。能不能有另一个模型来判断:你检索到的这些东西是否相关?或者对你检索到的 2000 个结果进行打分,评估哪些是最相关的 50 个?我觉得这类技术其实相当有效。有时甚至可以用同一个模型,只是换种 prompt,让它充当一个 critic,而不是实际的检索系统。

Shawn Wang [00:44:28]: 我觉得确实存在这样一个奇怪的断层,感觉容易的部分我们已经做完了,现在到了……但每年都会这样,就是“哦,我们已经懂了”,然后下一部分超级难,谁都没搞定。尤其是现在 RLVR 这个方向,所有人都在讨论:好吧,非可验证部分的下一阶段怎么办?每个人都是:我不知道,你知道的,LLM judge。

Jeff Dean [00:44:56]: 我觉得这个领域的好处在于,有很多非常聪明的人都在为我们共同看到的那些问题构思创造性的解决方案。因为我想每个人都看到了,模型在某些方面很厉害,但在这些能力的边界上又会出问题,而且在我们希望它擅长的那些领域还做不到那么好。然后想出好的技术方法并付诸尝试,看看哪些真的能带来改变,这正是推动这个领域研究向前发展的核心。我觉得这也是为什么它特别有意思。你想,两年前我们还在为 GSM8K 的题目头疼,对吧?比如 Fred 有两只兔子,又得到了三只,他一共有多少只兔子?这和现在模型能处理的数学问题相差太远了,现在你用纯语言就能做 IMO 和 Erdos 问题。对,纯语言。所以在大概一年半的时间里,能力上有了非常非常惊人的飞跃。我觉得,如果在其他领域也能实现这样的跨越就太好了。虽然对某些领域我们还不清楚具体该怎么做,但对另一些领域我们已经看到了路径,我们会努力把这些方面做得更好。

Alessio Fanelli [00:46:14]: 比如生成 YouTube 缩略图。那会非常有用。我们需要这个。那就算是 AGI 了。我们需要这个。

Shawn Wang [00:46:20]: 那就算是了。对内容创作者来说。

Jeff Dean [00:46:22]: 大概因为我不是 YouTube 创作者,所以我对这个问题没那么在意,不过我想很多人确实在乎。

Shawn Wang [00:46:27]: 确实。是啊,这不重要。事实证明,人们确实会以貌取人。嗯,回到 IMO 这个目标上。我还是没法释怀,就在一年前我们还有 AlphaProof、AlphaGeometry 那些东西,结果今年我们却说,去他的,直接把它丢进 Gemini 里就得了。对。你怎么看?我觉得关于符号系统和 LLM 融合的问题,曾经是一个非常核心的信念。然后到了某个节点,人们就说,不,我们直接用 LLM 做就行了。

Jeff Dean [00:47:02]: 是啊,我觉得这很合理,因为人类虽然会操作符号,但我们脑子里可能并没有一种符号化的表征,对吧?我们有的是某种分布式表征,以某种方式类似于神经网络,由大量不同的神经元组成。看到特定事物时,激活模式就会触发,这让我们能够推理、规划、进行思维链,并在发现某种解题思路行不通时回溯,换另一种试试。在很大程度上,我们正在模仿我们凭直觉认为真实大脑内部正在发生的过程,把它放在基于神经网络的模型里。所以我一直觉得,把完全独立的、离散的符号系统,和另一种完全不同的思考方式放在一起,是讲不通的。

Shawn Wang [00:47:59]: 有意思。是啊,可能这对你来说是显而易见的,但一年前对我来说并不是。

Jeff Dean [00:48:06]: 我是说,我确实觉得,IMO 这件事——先是翻译到 Lean 里并用 Lean 证明,第二年又做了一个专门的几何模型——然后今年转成了单一统一的模型,基本上就是生产模型,只不过多给了一点推理预算,这其实是非常好的,因为它说明通用模型的能力已经大幅提升了,现在你已经不需要专门的模型了。这其实非常类似于 2013 到 2016 年那段时间的机器学习,对吧?过去人们会为很多不同的问题分别训练不同的模型,比如我想识别路牌,就专门训练一个路牌识别模型;或者我想做语音识别,就专门有一个语音模型。我觉得现在,能够做所有事情的统一模型的时代真的已经到来了。问题在于这些模型对从未见过的新任务的泛化能力如何,而它们正在变得越来越好。

Shawn Wang [00:49:10]: 而且你不需要领域专家。我采访过 ETA,他就是那个团队的。他当时说,是啊,我不懂那些题目怎么解,我不知道 IMO 比赛在哪里举行,也不知道规则,我只是训练模型。对。对。这挺有意思的,就是有些人具备这种通用技能,只会机器学习,你给他们数据、给他们足够的算力,他们就能解决任何任务,我想这就是“苦涩的教训”吧。大概。对。

Jeff Dean [00:49:39]: 我觉得,通用模型在大多数情况下都会胜过专用模型。

Shawn Wang [00:49:45]: 我想在这一点上追问一下。我觉得这里有一个漏洞,就是模型的容量问题。抽象地说,一个模型只能容纳与其参数量相当的比特数。天知道 Gemini Pro 是不是有 1 万亿到 10 万亿参数,我们不清楚,但比如 Gemma 模型,很多人想要那种开源的本地模型,它们掌握了一些并不必要的知识,对吧?它们不可能知道所有事情。你们有大模型的奢侈,大模型应该有能力做到所有事。但当你做蒸馏、把它压缩成小模型时,你实际上在记忆一些没用的东西。对。所以我想,我们要不要把这些东西抽出来?我们能不能把知识和推理分离开?

Jeff Dean [00:50:38]: 是的。我觉得,如果模型能够检索信息,你肯定希望它把最有效的能力用在推理上,对吧?因为让模型把宝贵的参数空间用来记忆那些可以查到的冷门事实,其实并不是对参数空间的最佳利用,对吧?你可能更希望它掌握的是在更多场景下都普遍有用的东西,而不是某个冷门事实。所以我认为这始终是一种权衡。同时,你也不想让你的模型完全脱离对世界的认知,对吧?比如知道金门大桥有多长可能是有用的,这能让它建立一种对桥梁长度的普遍认知,对吧?它应该具备这类知识。它也许不需要知道世界某个偏僻角落某座小桥有多长,但拥有相当多的世界知识确实对它有帮助,模型越大,能容纳的知识就越多。不过我的确认为,把检索和推理结合起来,让模型非常擅长进行多阶段的检索,是的。

Shawn Wang [00:51:49]: 并对中间检索结果进行推理,这将是让模型显得能力强得多的一个非常有效的方式,因为比如想象一个个人化的 Gemini,对吧?

Jeff Dean [00:52:01]: 比如我们不会用我自己的邮件去训练 Gemini。我们更可能希望有一个统一的模型,然后把它作为工具,让它能够从我的邮件中检索信息并进行推理,或者从我的照片里检索,然后加以利用,进行多阶段的交互。这样是合理的。

Alessio Fanelli [00:52:24]: 你认为垂直模型是值得追求的有趣方向吗?就像人们说,我们要构建最好的医疗 LLM,最好的法律 LLM,这些算是短期权宜之计吗?

Jeff Dean [00:52:37]: 不,我是说,我认为垂直模型很有意思。你希望它们从一个相当不错的 base model 出发,然后可以将其视为丰富了特定垂直领域的数据分布。比如在医疗领域,或者机器人领域,我们可能不会用所有可能的机器人数据来训练 Gemini。我们本可以这么做,但我们希望它具备一套平衡的能力。所以我们会让它接触一些机器人数据,但如果你想构建一个非常非常好的机器人模型,你会希望以它为起点,然后用更多机器人数据来训练。这样一来,也许它的多语言翻译能力会有所下降,但机器人能力会提升。我们在训练 Gemini base model 时,总是在数据配比上做这种权衡。我们很乐意纳入另外 200 种语言的数据,以及我们手头有的所有这些语言的数据,但这会挤占模型的其他能力。它在 Pearl 编程方面就不会那么强了,不过 Python 编程仍然会不错,因为我们会纳入足够多的这类数据。但其他长尾的计算机语言或编程能力可能会受损,或者多模态推理能力也可能受影响,因为我们没能让它接触到那么多这方面的数据,但它在多语言方面会表现很好。所以我认为某种专业模型、也许更偏模块化的模型的组合会是不错的方向。理想情况是,既能支持那 200 种语言,又有一个很棒的机器人模型,还有一个很棒的医疗模块,这些都能整合在一起协同工作,在不同场景下被调用。对吧?如果我有一个健康问题,那它就应该能调用这个医疗模块,配合主 base model 来把这类任务做得更好。

Shawn Wang [00:54:36]: 可安装的知识。对。

Shawn Wang [00:54:38]: 就像一个包一样下载安装。

Jeff Dean [00:54:39]: 有些这种可安装的内容可以通过检索获得,但有些可能应该来自预加载的训练,比如用数千亿甚至一万亿 token 的医疗数据做过预训练。

Shawn Wang [00:54:51]: 顺便告诉听众,我想提一下 Gemma 3 的论文,我觉得他们在里面也涉及了一点这个思路。

Alessio Fanelli [00:54:56]: 对。我想问题是,你需要多少 billions 的 token 才能跑赢 frontier model 本身的进步?就是说,如果我要让这个模型在医疗方面更出色,而主 Gemini 模型还在不断改进。我需要 500 亿 token?1000 亿能不能做到?如果需要一万亿医疗 token,那这些数据可能根本不存在,也没有被收录。我觉得这才是关键所在。

Jeff Dean [00:55:21]: 嗯,我认为医疗是一个特别有挑战性的领域,有很多医疗数据我们目前无法合法获取,但有很多医疗机构希望用自己的数据来训练模型。这些数据不是公开的医疗数据,呃,不是公共卫生数据,而是公开的医疗数据。所以我觉得有机会与大型医疗机构合作,为它们训练定制模型,这些模型可能会比在公开数据上训练出来的通用模型效果更好。

Shawn Wang [00:55:58]: 对。顺便说一句,我觉得这也和之前聊语言的话题有点关系。我记得你举过一个特别喜欢的例子:你可以在 context 里放入一种低资源语言,模型就能学会。对。

Jeff Dean [00:56:09]: 哦,对,我想我们举的例子是 Calamon,这确实是真正的低资源语言,因为全世界大概只有 120 人会说,而且完全没有书面文本。

Shawn Wang [00:56:20]: 所以,对,你就可以这么做。直接把它放进 context 里就行。对。但你应该是把整个数据集都放进 context 里了,对吧。

Jeff Dean [00:56:27]: 如果你拿一种语言,比如索马里语之类的,世界上其实有相当数量的索马里语文本,或者埃塞俄比亚的阿姆哈拉语之类的,呃,我们很可能——对——并没有把这些语言的所有数据都放进 Gemini 的基础训练中。我们放了一部分,但如果你放入更多,就能提升模型在这些语言上的能力。

Jeff Dean [00:56:49]: 或者说,提升模型在这些语言上的表现。

Shawn Wang [00:56:52]: 嗯,对,挺酷的。我对语言学有一点副业兴趣。我大学的时候上过几门课,有时候我想,如果我是一个语言学家,而且能接触到所有这些模型,我就会去问一些关于语言本身的非常根本的问题。对。比如有一个特别明显的,就是 Sapir-Whorf,你说的话在多大程度上影响你的思维?但还有一些语言里有其他语言完全没有的概念,而另一些语言里很多概念只是重复,对吧。还有另一篇大家很喜欢的论文,叫做 platonic representation,就是说,比如一个杯子的图像,如果你用这个词的大量文本来训练模型,它最终会把图像和文本映射到大致相同的地方。所以这种规律应该也适用于语言,除了不适用的那些情况。而这些例外其实非常有趣,它们代表了人类发现的一些概念,可能是英语里根本没有的。

Shawn Wang [00:57:54]: 不知道,这就是我对语言的一点碎碎念。对。

Jeff Dean [00:57:58]: 我是说,我早年做过一个模型,把语言模型——里面有很好的基于词的表征——和一个图像模型融合在一起,那个图像模型是用类似 ImageNet 的数据训练的。对。然后你把它们的顶层融合起来,不,这是 DeViSE,呃,你再多做一点训练,把这些表征融合起来。你会发现,如果你给出一个全新的图像,它不在图像模型训练时的任何类别里,模型往往还是能给这个图像分配一个大致正确的类别或标签。比如,我记得望远镜和双筒望远镜都在图像模型的训练类别里,但显微镜不在。嗯。所以如果你给它一张显微镜的图片,它实际上能给出类似 microscope 这个词作为它分配的标签,即使它从未见过标注为显微镜的图像。

Shawn Wang [00:59:01]: 哦,这很好。挺酷的。对。

Shawn Wang [00:59:07]: 很有用。呃,酷。我觉得还有一些更宏观、更宽泛的问题,不过我想问,你总体上更希望别人多问你什么?因为你的涉猎太广了,我们已经聊了硬件,聊了模型研究。

Jeff Dean [00:59:22]: 我觉得有一点挺有意思的。我在1990年写本科论文时研究的是神经网络训练,具体是并行神经网络训练。那时我第一次接触神经网络,一直觉得它们是正确的抽象,但当时我们拥有的算力远远不够。系里那台并行计算机上的32个处理器,确实能让你做出稍微有趣一点的模型,但还不足以解决真正的问题。所以从2008或2009年开始,得益于摩尔定律,世界上总算有了足够的算力,加上更大、更有趣的数据集可以用来训练,我们才真正开始训练能够解决人们关心的实际问题的神经网络。对,比如语音识别、视觉,最后还有语言。因此,当我在2011年底开始在 Google 做神经网络相关工作时,我真的觉得我们应该利用大规模并行计算来扩大神经网络的训练规模。于是我重新启用了本科论文里的一些想法,那时我同时做了 model parallel 和 data parallel 训练,并且比较了它们。我管它们叫……我从八岁起就在做这些了,不过名字不一样,像是 pattern partitioned 和 model partitioned 之类的。

Shawn Wang [01:00:43]: 那篇论文是公开的吗?我们能去挖出来看看?

Jeff Dean [01:00:45]: 对,在网上能搜到。嗯,我想说,结合很多这类技术,在过去15年左右真正致力于把规模做大,这一点非常重要。这意味着硬件上的改进,也就是推动像 TPU 这样的专用硬件的研发;同时也意味着要在软件抽象层上发力,让人们能够向计算机表达自己的想法。谢谢你邀请我。

Jeff Dean [01:01:40]: 谢谢你邀请我。

Shawn Wang [01:07:10]: 你是否同意他当时那个观点?还是说你的事后复盘不一样?

Jeff Dean [01:07:15]: Brain 内部针对计算配额的市场机制。

Shawn Wang [01:07:18]: 计算配额,基本上他的意思是,David 曾在 OpenAI 担任工程副总裁,后来又去了 Google。他说,从根本上讲,OpenAI 愿意孤注一掷,把所有筹码押在一件事上;而 Google 则更民主化,每个人都有配额。我当时就想,如果你相信 scaling 是一件重要的事,那么全公司层面的这种决策就至关重要。

Jeff Dean [01:07:41]: 对,对。我想我在一定程度上同意这个说法。其实我还写过一页纸的备忘录,说我们把资源分得这么散,太蠢了。具体来说,当时 Google Research 内部,尤其是 Brain 团队,在大语言模型上有投入;Brain 和 Google Research 的其他部门也在做多模态模型;然后原来的 DeepMind 那边有 Chinchilla 模型和 Flamingo 模型等项目。所以我们不仅把算力分散到了这些彼此独立的项目上,还分散了我们最好的人才,还有我们最好的……因此我说,这太蠢了。为什么不把这些整合起来,集中力量训练一个出色的统一模型,从一开始就具备多模态能力,什么都擅长。这就是 Gemini 项目的起源。

Shawn Wang [01:08:52]: 然后我那页备忘录起作用了,这很好。名字也是你取的吗?因为可能还有人不知道,Gemini 这个名字是你起的。

Jeff Dean [01:08:58]: 是我起的。当时还提了另一个名字。我说,你看,这两个组织在某种程度上就像一对双胞胎走到一起,所以我很喜欢这层含义。另外 NASA 早期也有一个 Gemini 计划,是通往 Apollo 计划的重要一步。所以这个名字感觉挺合适的。双胞胎合二为一。对吧。

Alessio Fanelli [01:09:27]: 对,不错。我知道时间快不够了,但我很好奇你现在怎么用 AI 写代码。你大概是计算机科学史上最高产的工程师之一了。我之前读到一篇关于你和 Sanjay 的友谊以及你们如何合作的文章。你有一句话大意是,你需要找到一个思维方式与你兼容、可以一起 pair program 的人,这样你们两个在一起才能形成互补的力量。我就在想,你怎么看 coding agents,你如何塑造一个 coding agent 让它兼容你的思维方式?你怎么评价今天的工具?它们应该往哪里发展?

Jeff Dean [01:10:07]: 首先,我觉得 coding 工具比一两年前的水平好了太多。现在你真的可以依赖它们去完成更复杂的任务,这些是作为软件工程师的你想要实现的。你可以把相当复杂的事情委托给这些工具。我认为人类软件工程师与所使用的 coding model 之间互动的一个很好的地方在于,你跟这个 coding model 说话的方式,实际上决定了它如何与你互动,对吧?比如你可以请它“给这段代码写一批好的测试”,也可以请它“帮我头脑风暴一下性能优化的思路”。你提问的方式会塑造模型的回应方式、它处理的问题类型,以及你希望它在多大程度上独立去做更大更自主的任务,还是更多地与你互动,以确保你在引导正确的方向。我认为并不是只有一种风格适合所有情况,对吧?有些问题你其实希望与模型保持更频繁的互动;另一些时候你只想说“行了,你去写这个吧,因为我知道我需要这个东西,我能把它描述得足够清楚,你去写,写完回来找我”。所以我确实认为,未来会有更多这样的风格:大量独立的软件 agent 代表你去执行任务,而我们需要找到合适的人机交互模型和 UI,来决定它应该在什么时候打断你,说“嘿,我需要一点指引”,或者“我做完了这件事,接下来该做什么”。我觉得我们还没有找到这个问题的终极答案。而且随着模型变得更好,你对交互方式所做的那一整套决策也可能会改变,对吧?想象一下,如果你有一支50人的实习生团队,你会怎么管理他们?而且问题在于,你愿不愿意带50个实习生?如果他们都特别优秀,你可能愿意,对吧?

Shawn Wang [01:12:23]: 那管理起来工作量很大。不过也很……

Jeff Dean [01:12:25]: 对,我觉得这很有可能成为现实,很多人未来可能会拥有50个实习生。所以作为一个人,你实际上会怎么处理呢?你可能会让他们组成几个小型的子团队,这样你就不用跟50个人分别互动,你只需要跟五个团队打交道,他们会代表你去执行各种任务。但我也不确定这最终会怎么发展。

Alessio Fanelli [01:12:52]: 你怎么看引入其他人的问题?结对编程对引入新思路、在组织内部分发知识总是很有帮助的。但感觉现在我们有了越来越多的 coding agents 来编写代码,就很难把其他人拉进一个问题里了。比如说,你有 50 个实习生,对吧?然后你想去找 Noam Shazier 说,嘿,我想跟你结对做这件事。但现在已经有大量工作并行完成了,你得让他全部跟上进度。我好奇的是,人们会不会在团队中变得更加孤立,因为这里有 50 个实习生产生的海量上下文,我很难把一切都转述给你。

Jeff Dean [01:13:33]: 也许吧。但另一方面,想象一下没有任何 AI 辅助工具的传统软件组织。你有 50 个人在干活,他们的互动方式自然会非常层级化,因为这 50 个人负责系统的这一部分,不会和那边的其他人有太多交互。但如果你有五个人,每人管理 50 个虚拟 agent,这五个人之间或许反而能实现更高带宽的沟通,相比之下,五个人同时还要各自协调一个 50 人的软件团队,沟通效率可能更低。

Alessio Fanelli [01:14:15]: 那我好奇,你的工作节奏是怎么变化的?是不是会花更多时间和人一起提前过设计文档和设计目标?

Jeff Dean [01:14:26]: 我觉得有一点很有意思:以前人们学习写软件时,都被教导要把规格说明写得非常清楚,但没人真正当回事。就像是"随便吧,我不需要那个"。用自然语言写规格说明从来都不是一个被真正重视的产出物。它确实重要,但它在很大程度上并不驱动实际的创造性过程。而现在,如果你要指定让 agent 为你写什么软件,那你最好非常仔细地斟酌表达方式,因为这将决定输出质量。如果你没涵盖它需要处理这类情况,或者没说明这是一个超级重要的边界情况,或者你非常在意这部分的性能,它可能就不会按你期望的去做。你越擅长与这些模型交互,就越会明白这一点。我认为人们提升能力的方式之一,就是学会非常清晰地定义需求,而不是留下歧义。这其实不是坏事。无论你是软件工程师还是从事其他任务,能够清晰明确地表达自己想要什么,都是一项非常重要的技能。

Shawn Wang [01:15:52]: 我经常开玩笑讲,这实际上跟足够高级的管理层沟通无法区分,就像写内部备忘录一样,必须字斟句酌。而且我认为 multimodal 也非常重要。Google 的 anti-gravity 有一点做得很好,就是一开始就具备非常强大的 multimodal 能力,包括视频,这是你能给模型的最高带宽沟通 prompt,这非常棒。

Alessio Fanelli [01:16:20]: 你怎么收集那些通常只存在于你脑中的东西?比如你对如何寻找性能优化有一种很强的直觉。现在让人们把这些通用的东西写下来,是不是变得更有价值了?这样之后可以把它们作为 retrieval artifacts 输入给模型。还是说边界条件就是个好例子?如果你在构建系统,你脑中已经有特定的边界条件了,但现在每次都得重复说明。你们会让大家花更多时间去写这些吗?还是说你们发现了更多可以沉淀下来的通用经验?

Jeff Dean [01:16:56]: 我认为,撰写精良的软件工程指南会很有用,因为它们既可以作为模型的输入,也可以供其他开发者阅读,从而让他们的 prompts 更清晰地表达底层软件系统应该做什么。不一定需要为每种情况都定制一份指南;如果你有一些通用指南,把它们放进 coding agent 的上下文里,就会很有帮助。比如在分布式系统中,你可以说:要考虑这类故障,这里有一些处理故障的技术。你可以采用类似 Paxos 的复制机制,或者把请求发到两个地方并容忍故障,因为只要有一个返回就够了。对分布式系统构建中的 20 种类似技术做一点描述,可能就能让 coding agent 拼凑出更可靠、更健壮的分布式系统。

Shawn Wang [01:18:07]: 是啊。我好奇 Gemini 什么时候能构建出 Spanner?

Alessio Fanelli [01:18:12]: 它里面可能已经有代码了,对吧?

Alessio Fanelli [01:18:16]: 是啊,这其实就是个好例子,对吧?你有 CAP 定理,这就像真理一样不可违背。然后你做出了一个打破它的东西。

Shawn Wang [01:18:26]: 我好奇的是,某种程度上模型就像……他会说自己打破了吗?你会说你打破了 CAP 定理吗?真的吗?好吧,我是说,在局部假设下。对,在某些假设下。而且你还得有好的时钟。对对。

Alessio Fanelli [01:18:41]: 有时候你不必总是遵循那些已知为真的东西,对吧?而且我觉得模型在某种程度上,如果你告诉它们什么,它们真的会深信不疑。所以是的,只是更多思考,而不是给出任何关于如何修复它的答案。

Jeff Dean [01:18:57]: 是的,关于这种大 prompt 和迭代,回到你说的 latency 问题,我一直想做的一个 AB 测试、实验、基准或研究是:性能差异到底是什么?比如说,三次快速但较弱的模型调用,加上人工对齐——因为人类会修正,人类看了第一次输出后生成一个新 prompt。

Shawn Wang [01:19:23]: 给第二次调用。对。与之相对的是,你花时间写了一个超级大、超级详尽的 prompt,然后用一个非常聪明的模型一次性做对。因为说到底,性能不足是不是因为你根本没有指定清楚?如果你没告诉我,我根本就不可能产出你想要的东西。

Jeff Dean [01:19:44]: 这是 underspecified。所以我可能产出 10 个不同的结果,其中只有一个才是你想要的。

Shawn Wang [01:19:49]: 而用一个 flash model 进行多轮交互就足够了。

Jeff Dean [01:19:54]: 我非常推崇压低延迟,因为我认为能够与所用系统进行极低延迟的交互,远比那些慢上 10 倍、20 倍的体验要愉悦得多。而且我认为,未来我们会看到模型本身,以及底层的软硬件系统,其延迟比今天低 20 倍、甚至 50 倍。对于那些需要在交互间隙处理大量任务的系统来说,这将极为重要。

Shawn Wang [01:20:27]: 对,对。这有两个极端,对吧?与此同时,你还有 DeepThink,它完全处在另一端。

Jeff Dean [01:20:33]: 但如果不是因为成本和延迟,你会一直使用 DeepThink,对吧?如果底层硬件和系统的延迟降低了 20 倍,成本也随之下降,让你能在模型中拥有那种能力,那没理由不这么做。

Jeff Dean [01:20:52]: 但与此同时,到时你可能又会有一个更厉害的模型。即便在那套新硬件上,它也要多花 20 倍的时间。是的。

Shawn Wang [01:21:00]: 要知道,Pareto curve 一直在向上攀升。嗯,不断向前,不断向外扩展。对了,我们是不是该请他做些预测?我不知道你有没有什么特别想坚持的预测,比如说,每当新模型发布时你会跑的那套测试——有没有什么是你现在还不太满意、但觉得很快能解决的?

Jeff Dean [01:21:29]: 嗯,我做两个不太一样的预测吧。首先,我认为个性化模型会非常非常有用——它了解你,掌握你所有的状态,能够在你主动授权的前提下检索你有权访问的一切信息;相比那些无法获取这些信息的通用模型,它的优势巨大。也就是说,有没有可能让模型关注到我见过的所有东西?对,每一封邮件、每一张照片、每一个……对,我看过的每一支视频,这将会非常有用。其次,我认为越来越多的专用硬件将带来延迟更低的模型,以及价格可负担且能力更强的模型,相比现在的现状而言。这也同样非常重要。是的。

Shawn Wang [01:22:16]: 你说的延迟大幅降低,大家通常用 tokens per second 来衡量。这么说可以吗?好的。要知道,我们现在大概是一百,接下来可以到一千。那有没有意义冲到一万?有。真的吗?当然。绝对有意义。对吧,因为 chain of thought 和 chain of thought reasoning。

Jeff Dean [01:22:36]: 我是说,你可以思考更多的 token,可以做更多并行的 rollouts。你可以生成多得多的代码,并通过 chain of thought reasoning 来检查代码是否正确。所以我认为,如果能以每秒 10,000 token 的速度做到这些,那就太棒了。是的。

Shawn Wang [01:22:52]: 到了每秒 10,000 token,你就不再是在读代码了。对,就像你只是生成它,你……我不会去读它。

Jeff Dean [01:22:58]: 嗯,记住,最终输出的可能并不是 10,000 个 token 的代码。对,它可能是 1,000 个 token 的代码,背后有 9,000 个 token 的推理过程,而这样的代码读起来可能反而要好得多。是的。

Alessio Fanelli [01:23:11]: 是啊。“如果我有更多时间,我会写一封更短的信。”是的,是的,是的。嗯,太棒了。Jeff,这次访谈非常精彩。谢谢你抽出时间。谢谢。

Jeff Dean [01:23:20]: 聊得很开心。谢谢邀请。