Jeff Dean 专访：掌控帕累托前沿、模型蒸馏与 AI 系统的未来

导读

本期《Latent Space》播客邀请到了 Google 首席 AI 科学家、Gemini 项目的核心推手 Jeff Dean。从 2000 年代初重写 Google 的搜索底层架构，到复兴稀疏的万亿参数模型，再到将前沿机器学习研究与 TPU 硬件进行协同设计，Jeff Dean 几乎深刻影响了现代 AI 技术栈的每一个层级。他亲历了从 CPU 和索引分片，到如今跨越文本、视频和代码进行推理的多模态大模型的多次规模化革命。

在这次深度对话中，Jeff 详细剖析了“掌控帕累托前沿（Pareto frontier）”的真正含义，以及为什么模型蒸馏（Distillation）是每一次 Flash 级别模型性能突破的核心引擎。他提出，AI 规模化扩展的真正瓶颈正在从浮点运算次数（FLOPs）转变为以皮焦耳（picojoules）为单位的“能源消耗”。此外，他还分享了当初推动合并 Google 所有 AI 团队（Brain 与 DeepMind）背后的故事与内部备忘录。

展望未来，Jeff 认为 AI 的下一次飞跃将不仅仅来自于更大的上下文窗口，而是来自于能够产生“仿佛在处理万亿级 Token”错觉的混合检索与推理系统。无论你是对 TPU 的软硬件协同设计、多智能体（Agents）编程协同，还是对未来低延迟、个性化 AI 的发展方向感兴趣，这篇对谈都将为你带来顶级的行业洞察。

第一章：开场与帕累托前沿策略

主持人： 大家好，欢迎来到《Latent Space》播客。我是 Kernel Labs 的创始人 Alessio，和我在一起的是《Latent Space》的编辑 Swyx。你好。我们今天在演播室请到了 Google 的首席 AI 科学家 Jeff Dean。欢迎你。

Jeff Dean： 谢谢你们邀请我。

主持人： 能在演播室请到你感觉有点不真实。我看过你太多演讲了，显然你的职业生涯非常具有传奇色彩。所以，恭喜你。我想首先必须得说，恭喜你们掌控了“帕累托前沿（Pareto Frontier）”。

Jeff Dean： 谢谢，谢谢。帕累托前沿是个好东西，能置身于前沿感觉很棒。

主持人： 我觉得这是一种结合——你必须掌控帕累托前沿，你必须具备前沿的能力，但同时也要兼顾效率，并提供一系列人们喜欢使用的模型。这部分得益于你们的硬件工作，部分得益于你们的模型工作，我相信你们内部肯定积累了许多秘密武器。但看到这一切汇聚成这样一个稳步推进的前沿，真的令人印象深刻。

Jeff Dean： 是的，正如你所说，这不仅仅是一件事的功劳，而是整个技术栈上下许多创新的结合。所有这些因素结合在一起，不仅帮助你打造出能力极强的大型模型，还能通过软件技术将这些大模型的能力迁移到体积更小、更轻量级的模型中。这些小模型虽然成本效益更高、延迟更低，但相对于它们的体量而言，依然具备极强的能力。

主持人： 你们在保持帕累托前沿下限方面有多大的压力？我觉得那些新兴的 AI 实验室总是试图推动最高性能的前沿，因为他们需要筹集更多资金等等。而你们拥有数十亿用户，我想最初你在研究 CPU 时就考虑过，如果每个使用 Google 语音模型的人每天只用 3 分钟，你就需要将 CPU 数量翻倍。今天在 Google 内部的讨论是怎样的？你们是如何在追求前沿能力与“如果我们把它建出来，就必须得实际部署它”之间进行优先权衡的？

Jeff Dean： 我们始终希望拥有处于前沿或正在突破前沿的模型，因为我认为只有在那里，你才能看到现在存在着哪些在去年或六个月前能力稍弱的版本中不存在的新能力。但与此同时，我们也知道这些前沿模型在某些用例中会非常有用，但对于更广泛的其他用例来说，它们可能比人们期望的要慢一些、贵一些。

因此我们想要做的，是始终拥有一款能力极强且经济实惠的模型，能够赋能一大批低延迟（lower latency）用例。人们可以更轻松地将它们用于智能体编程（agentic coding）等任务。同时，我们也要拥有高端的前沿模型，用于深度推理、解决极其复杂的数学问题等。并不是说这两者只能选其一，它们都有各自的用武之地。所以我们两方面都想做。而且，通过模型蒸馏（distillation）——这是让小模型变得更强大的关键技术——你必须首先拥有前沿模型，才能将其蒸馏成体积更小、更轻量的模型。所以这不是非此即彼的选择。你必须拥有前者，才能获得能力极强但体量适中的后者。

第二章：模型蒸馏、强化学习与 Flash 模型的经济优势

主持人： 是的。你和吴恩达（Andrew Ng）在 2014 年就提出了这个方案。别忘了还有 Oriol Vinyals。这已经是挺久以前的事了。我很好奇，你是如何看待这些想法的循环周期的？甚至包括稀疏模型（sparse models）。你们是如何重新评估它们的？在下一代模型中，你们是如何判断什么东西值得重新审视的？你研究过太多最终产生深远影响的想法，但在当时那一刻，它们可能感觉并没有那么重要。

Jeff Dean： 模型蒸馏最初的动机是因为我们当时看到我们有一个非常庞大的图像数据集，有 3 亿张图像，我们可以用大概两万个类别进行训练，比 ImageNet 大得多。我们发现，如果你为这些图像类别的不同子集创建“专家模型（specialists）”，比如这个模型非常擅长识别哺乳动物，那个模型非常擅长室内场景，你可以对这些类别进行聚类，在对更广泛的图像集进行预训练之后，在丰富的数据流上进行训练。如果你将训练出的那 50 个模型作为一个庞大的集成模型（ensemble）来对待，你会获得好得多的性能。

但这并不是一个非常实用的服务方案。因此，模型蒸馏的出现，实际上是出于这样一个想法：如果我们想把这 50 个独立的专家模型投入实际服务中，我们能否把它们压缩（squish）成一个符合你能实际部署尺寸的单一模型？这与我们今天所做的其实并没有太大区别。今天，我们通常不再集成 50 个模型，而是拥有一个规模大得多的单一模型，然后我们将其蒸馏成一个小得多的模型。

主持人： 是的，我有时也在想，模型蒸馏是否也与强化学习（RL）革命有着某种故事联系。让我试着表达一下我的意思。强化学习基本上会让模型在数据分布的某个特定部分出现能力尖峰（spikes），但这有时可能会在其他领域造成损失（lossy），它像是一种不均匀的技术。但你或许可以把它蒸馏回去。我认为普遍的梦想是能够在不让任何其他能力倒退的情况下推进新能力。我觉得这种“能力无损融合”的过程，有一部分应该就是一种蒸馏过程，但我还没有看到太多关于这方面的论文。

Jeff Dean： 我倾向于认为模型蒸馏的一个核心优势在于，你可以拥有一个小得多的模型，同时拥有一个非常庞大的训练数据集，并且你可以通过在数据集上进行多次迭代来获取效用。因为你现在不仅获得了硬标签（hard labels），还获得了来自大得多的模型的逻辑值（logits），以此来诱导小模型产生正确的行为，这是单纯依靠硬标签无法获得的。这就是我们的观察结果：通过蒸馏方法，你的小模型可以达到非常接近最大模型性能的水平。

这似乎是许多人眼中的最佳平衡点。因为通过这种方法，在过去的几个 Gemini 迭代中，我们已经能够让下一代的 Flash 版本达到与上一代 Pro 版本相当、甚至大幅超越的水平。我认为我们将继续努力这样做，因为这似乎是一个值得遵循的良好趋势。

主持人： 冒昧问一下，最初的路线图是 Flash、Pro 和 Ultra。Ultra 呢？你们是把 Ultra 藏起来，把它当成大金矿来向外蒸馏吗？（笑）

Jeff Dean： 我们有很多不同类型的模型。有些是内部模型，不一定是为了发布或提供服务而设计的。有些是我们的 Pro 规模模型，我们也可以从中蒸馏出我们的 Flash 规模模型。我认为拥有这样一套能力体系是很重要的。同样，推理时扩展（inference time scaling）也是提升模型能力的一种有效方法。

主持人： 是的。显然，我认为 Flash 极佳的经济效益导致了它的绝对主导地位。我认为最新的数据是 50 万亿个 Token 的处理量，市场份额极高。

Jeff Dean： 就经济效益而言，因为 Flash 如此经济，你可以将它用于任何地方。它现在被集成在了 Gmail 中，集成在了 YouTube 中，它无处不在。我们在各种 AI Overviews（AI 概览）搜索产品中也越来越多地使用它。

主持人： 我的天，AI 概览也是由 Flash 驱动的。我都没想到这一点。

Jeff Dean： 我认为 Flash 模型非常棒的一点是，它不仅更实惠，而且延迟更低（lower latency）。我认为延迟对于这些模型来说实际上是一个非常重要的特征。因为我们将要求模型执行复杂得多的任务，这将涉及生成多得多的 Token。你不再只是要求它“帮我写个 for 循环”，而是“帮我写一个完整的软件包来完成 X、Y 或 Z”。因此，拥有能够做到这一点的低延迟系统似乎非常重要。而 Flash 正是实现这一目标的途径之一。

显然，我们的硬件平台（如 TPU）也为我们的服务栈提供了许多有趣的特性。TPU 芯片之间的互连具有极高的性能，非常适合用于长上下文（long context）的注意力操作。此外，拥有大量专家的稀疏模型（sparse models）——所有这些在决定如何大规模提供服务时都至关重要。

第三章：基准测试、长上下文与真实用例

主持人： 对于早期的一代延迟（比如慢一代的蒸馏），是否感觉存在某种突破点？我甚至觉得某些任务在能力上已经达到了渐近线（asymptote）。比如今天的 Pro 模型已经在某种任务上饱和了。所以在下一代中，同样的任务在 Flash 的价位上也会饱和。对于人们使用模型的大多数任务来说，再过两代，Flash 模型基本上就能搞定一切了。当很大一部分人对 Flash 模型已经感到满意时，你们如何使其在经济上合理地继续推动 Pro 的前沿？

Jeff Dean： 我认为，只有当“人们要求模型做什么”的分布是稳定不变（stationary）的情况下，你说的才是对的。但实际情况往往是，随着模型变得更有能力，人们会要求它们做更多的事情。这在我的个人使用中就发生过：一年前我尝试用我们的模型完成一些编码任务，它在处理一些简单的任务时还行，但在处理更复杂的任务时就不太好用。从那以后，我们在更复杂的编码任务上取得了巨大的进步，现在我会要求它做复杂得多的事情。

我认为这不仅适用于编程，你现在会问：“你能否分析世界上所有的可再生能源部署情况，并给我一份关于太阳能电池板部署的报告？”这是一个比一年前人们会要求模型做的复杂得多的任务。因此，在某种意义上，你将需要更有能力的模型来推动“人们要求模型做什么”的前沿。这反过来也让我们洞察到：目前的系统在哪里崩溃了？我们如何在这些特定领域改进模型，使下一代模型变得更好？

主持人： 你们内部是否使用任何基准测试（benchmarks）或测试集？因为感觉现在每次报告的都是相同的基准测试，就像是“好吧，准确率从 97% 变成了 99%”。你们如何在内部不断推动团队朝着目标努力？

Jeff Dean： 我认为基准测试，特别是公开可用的基准测试有其效用，但它们往往有一个效用生命周期。刚推出时，它们对当前模型来说可能非常难。我倾向于认为最好的基准测试是初始得分只有 10% 到 20% 或 30% 的那种。然后你可以致力于提升该基准测试试图评估的能力，把分数提升到 80%、90%。一旦它达到 95% 左右，你再在这个基准测试上投入精力，收益就会急剧递减。因为要么你实际上已经具备了那种能力，要么就是公共数据或非常相关的数据泄露到了你的训练数据中。

因此，我们有许多内部保留的（held out）基准测试，我们确信这些数据绝对没有出现在训练数据中。它们代表了我们希望模型具备但目前还不具备的能力，然后我们可以致力于评估：“我们如何让模型在这些方面变得更好？是我们缺少专门针对这类任务的训练数据？还是我们需要进行架构上的改进或某种模型能力的提升？”

主持人： 有没有这样一个例子，一个基准测试启发了架构上的改进？

Jeff Dean： 我觉得 Gemini 模型中一些长上下文（long context）的能力（最早是在 1.5 版本中推出）就是围绕这个展开的。我们希望拥有……

主持人： 突然之间，每个人的图表都变成了全绿的。我就在想，大家是怎么在同一时间攻克这个难题的？（笑）

Jeff Dean： 就像你说的，“大海捞针（needle in a haystack）”式的单一基准测试，在至少 128K 或 256K 的上下文长度下已经饱和了。现在大多数人实际上也用不到比这大得多的上下文。我们正试图突破 100 万或 200 万上下文的极限。

主持人： 我认为 Google 在 200 万上下文方面依然是领导者。

Jeff Dean： 是的，这很好。因为我认为有很多用例，把上千页的文本或者好几个小时的视频放进上下文并实际利用它是非常有用的。但单一的大海捞针基准测试已经饱和了。所以你真正需要的是更复杂的、多重捞针（multi-needle）的测试，或者是更现实的测试：拿所有这些内容，从长上下文中生成这类答案。这能更好地评估人们真正想用长上下文做什么，而不仅仅是“你能告诉我这个特定东西的产品编号吗”。

主持人： 这就变成了机器学习系统内部的信息检索（retrieval）。我试图提升到更高层面的认知是：你有一个基准测试，然后你说“我看到了我需要做出的架构改变来解决这个问题”，但你真的应该这么做吗？因为有时候那就是一种归纳偏置（inductive bias）。曾在 Google 工作的 Jason 就说过类似的话：“是的，你这么做短期内会赢，但从长远来看我不知道它能否规模化扩展，你可能以后还得把它撤销掉。”

Jeff Dean： 我倾向于不关注具体的解决方案应该驱动什么，而是关注我们想要实现什么能力。我们非常确信长上下文是有用的，但今天的长度还远远不够。你真正想要的是：“我能在回答问题时关注整个互联网（attend to the internet）吗？”但这不可能通过单纯扩展现有的二次方复杂度（quadratic）解决方案来实现。100 万个 Token 差不多推到了极限，你不可能用它处理 1 万亿个 Token，更不用说 10 亿、1 万亿了。

但是，如果你能提供一种“能够关注万亿级 Token”的错觉（illusion），那将是非常惊人的。你会发现各种各样的用途。你可以关注互联网，你可以关注 YouTube 上的像素，并在大量视频中形成深层表征；在个人 Gemini 层面上，在得到你许可的情况下，它可以关注你所有的个人状态数据——你的电子邮件、照片、文档、机票等。我认为那将极其有用。问题是，你如何获得算法和系统层面的改进，从而构建出一个能以某种有意义的方式实际关注万亿级 Token 的系统？

主持人： 顺便说一下，我算过一笔账。如果你每天 8 小时不停地说话，你最多也只能产生 10 万个 Token 左右，这非常轻松就能放进上下文里了。（笑）但是如果你说“我想理解人们放在视频里的一切”，或者进入蛋白质等信息密度极高的领域，那就是另一回事了。

Jeff Dean： 关于 Gemini 的多模态（multimodal）特性，我们一直希望它从一开始就是原生多模态的。人们有时认为多模态就是文本、图像、视频和音频，这些人类感知的模态。但我认为，让 Gemini 了解非人类的模态也极其有用。比如来自 Waymo 自动驾驶汽车或机器人的激光雷达（LiDAR）传感器数据，或者各种医疗模态数据（X 光、MRI、医学影像、基因组信息）。

世界上可能存在数百种模态数据，你希望模型至少能接触到：这是一种有趣的模态，并且在这个世界上具有某种含义。即使你没有对所有可用的激光雷达或 MRI 数据进行训练（因为考虑到预训练数据混合的权衡），至少包含一点点也是非常有用的，因为这能启发模型意识到这是一个有价值的信息维度。

主持人： 有没有所谓的“王者模态（king modalities）”？那些超越所有其他模态的模态。一个简单的例子是视觉（vision）——它能在像素级别编码文本，DeepMind 曾有一篇关于这方面的论文。视觉也被证明可以包含音频，因为你可以将音频转化为频谱图，这本质上也是视觉能处理的事情。视觉是否就是这个王者模态？

Jeff Dean： 视觉和运动（motion）是非常重要的事情。由于对运动/视频的感知极其有用，生物演化在自然界中已经独立演化出眼睛多达 23 次。这种感知周围世界的能力正是我们希望这些模型具备的：解释我们所看到的、我们正在关注的事物，然后利用这些信息帮助我们采取行动。

第四章：多模态与 Google 搜索的演进

主持人： 顺便向 Gemini 致敬一下，我认为它依然是目前市面上唯一的原生视频理解模型。我经常用它来看 YouTube 视频。

Jeff Dean： 人们其实不一定清楚 Gemini 模型实际上能用视频做什么。我在一次演讲中用过一个例子：一段 YouTube 的体育集锦视频，包含了过去 20 年的 18 个难忘的体育瞬间，比如迈克尔·乔丹在总决赛最后的跳投、一些足球进球等等。你完全可以直接把视频丢给它，然后说：“请帮我制作一个表格，列出所有这些不同的事件、发生的日期以及简短的描述。”然后你就会得到一个 18 行的表格，这些信息都是从视频中提取出来的。大多数人不会想到模型能直接把视频转化为类似 SQL 表格的数据。

主持人： Google 内部是否有过关于“关注整个互联网”的讨论？这是人类无法做到的，你需要某种排名机制来找到你需要的东西。对于大型语言模型（LLM）来说，这种排名是非常不同的。你期望一个人最多看 Google 搜索的前五六个链接，但对于 LLM，你是否期望有 20 个高度相关的链接？你们在内部如何弄清楚，如何构建出比人类搜得更广的 AI 概览模型？

Jeff Dean： 即使在基于语言模型的工作出现之前，我们的排名系统也是建立在海量的网页索引之上的。其中大部分是不相关的。所以你会用非常轻量级的方法识别出一个相关的子集。现在你把它缩小到了比如 3 万份文档。然后你逐渐细化，应用越来越复杂的算法和各种复杂的信号，最终将其缩小到你所展示的内容——也就是最终的 10 个搜索结果。

我认为一个基于 LLM 的系统并不会与之有太大差异。你将尝试关注数万亿个 Token，但你会想确定：包含这 3000 万个有趣 Token 的、最初的 3 万份文档是什么？然后你如何从这 3 万份文档中，提炼出为了完成用户请求的任务而真正应该关注的 117 份文档？

你可以想象这样的系统：你拥有大量的高并发处理，也许使用非常轻量级的模型来识别那最初的 3 万个候选者；然后你有一个系统（也许是一个或一组稍微复杂的模型）帮助你从 3 万缩小到 117；最后的模型才是真正审查那 117 份文档的核心。这可能是你能力最强的模型。我认为它必须是一个类似于这样的系统，才能为你提供“关注了万亿级 Token”的错觉。这就好比 Google 搜索并不是真的把全网读了一遍再给你结果，但它给了你正在搜索整个互联网的错觉，实际上你只是找到了一小部分非常相关的东西。

主持人： 我经常告诉那些不熟悉 Google 搜索历史的人：当年 BERT 几乎是立刻就被应用在了 Google 搜索内部，并且极大地改善了结果。

Jeff Dean： 转向基于 LLM 的文本、词汇表征，使你能够摆脱那些特定的词必须精确出现在页面上的僵化概念，而是真正理解：这个页面的这个主题或段落，与用户的查询高度相关。

主持人： 我觉得人们可能没有意识到 LLM 在多大程度上接管了所有这些超高流量的系统。这是 Google，这是 YouTube。YouTube 有个语义 ID 的东西，词汇表中的每个项都是一个 YouTube 视频，它使用代码本来预测视频，这对于 YouTube 的体量来说简直不可思议。

Jeff Dean： 甚至在 LLM 被广泛用于搜索之前，我们就非常重视弱化（softening）用户实际输入的查询的语义刚性。

主持人： 你们有一段关于这个的历史记录吗？

Jeff Dean： 2009 年我在 Web 搜索和数据挖掘会议上做过一次演讲。我们从未正式发表过关于 Google 搜索起源的论文，但那次演讲梳理了从 1999 年到 2004/2005 年左右，我们重写搜索和检索系统的四、五、六代历程。2001 年真正发生的一件事是，我们试图在多个维度上扩展系统。一方面，我们想把索引变大，因为索引越大，检索质量通常越好。另一方面，我们需要扩大容量，因为流量增长得非常快。

所以我们拥有一个分片（sharded）系统，随着索引变大，分片数量也增加。比如你有 30 个分片，如果要将索引翻倍，你就做成 60 个分片，这样可以保证响应查询的延迟是有上限的。随着流量增长，你再不断添加每个分片的副本。最终我们算了一笔账，发现在一个数据中心里，如果有 60 个分片，每个分片有 20 个副本，我们现在有了 1200 台带硬盘的机器。我们意识到：我们完全可以把一份完整的索引放进这 1200 台机器的内存里！

于是在 2001 年，我们将整个索引放入了内存。从质量的角度来看，这带来的提升是惊人的。因为在此之前，你必须非常谨慎地决定为查询查看多少个不同的关键词，因为每一个词都会涉及对 60 个分片上硬盘的寻道操作（disk seek）。随着索引变大，这就变得极其低效。

但一旦整个索引都在内存中，你完全可以在用户最初的 3 到 4 个词的查询中，再额外扔进 50 个扩展词。因为你现在可以添加同义词，比如 restaurant、restaurants、cafe、bistro。你突然可以开始真正理解词语的含义，而不是局限于用户输入的精确语义形式。那是在 2001 年，虽然远在 LLM 出现之前，但本质上都是为了软化用户输入的严格定义，从而触及真正的含义。

第五章：系统设计原则与延迟数字

主持人： 当你们面临像 2001 年互联网每年翻倍甚至翻三倍的增长时，你设计系统时采用了哪些原则？今天在 LLM 领域我们看到了类似的情况，每年模型规模和能力的跳跃都如此之大。

Jeff Dean： 在设计系统时，你首先要了解在决定系统架构时，哪些设计参数是最重要的。比如，你需要处理每秒多少次查询？你需要处理的索引有多大？每个文档你需要保留多少数据？当流量翻倍或翻三倍时，这个系统还能运转良好吗？

一个很好的设计原则是：你应该设计一个让最重要的特征能够扩展 5 到 10 倍的系统，但可能不需要超过这个范围。因为通常会发生的情况是，如果你为 X 规模设计系统，而需求突然变成了 100 倍的 X，这通常会开启设计空间中一个完全不同的点——在 X 规模下没有意义的设计，在 100X 规模下可能变得非常合理。比如从基于磁盘的索引转向内存索引，只有当你拥有足够的流量，以至于在磁盘上存放了足够多状态副本时，这些机器才凑够了将一份完整索引装入内存的容量。这突然解锁了一种以前不切实际的全新设计。

所以我非常喜欢在写大量代码之前，先在脑海中推演系统设计。在 Google 早期，我们正在大力扩展索引。索引的更新频率实际上是变化最大的一个参数。过去是每个月更新一次。后来我们转变成了一个可以在不到一分钟内更新任何特定页面的系统。

主持人： 因为这构成了竞争优势，对吧？突然之间，对于新闻相关的查询，如果你的索引还是上个月的，那就没什么用了。你们原本可以把新闻放在一个单独的系统上的。

Jeff Dean： 我们确实推出了 Google News 产品，但你也希望人们在主索引中输入的新闻相关查询也能得到及时更新。然后你需要有一套后台系统来判断哪些页面应该以什么频率更新。即使整体更新率看似很低，你可能依然需要非常频繁地重新抓取某些重要的页面。因为虽然它们改变的概率很低，但拥有最新版本的价值却非常高。

主持人： 关于延迟和存入磁盘的问题，让我想起了你的经典之作——《每个程序员都应该知道的延迟数字（Latency Numbers Every Programmer Should Know）》。写这个有什么背后的故事吗？

Jeff Dean： 这个表格列出了 8 到 10 种不同的指标，比如缓存未命中需要多长时间，分支预测失败需要多长时间，引用主存需要多长时间，发送一个数据包从美国到荷兰需要多长时间等。这实际上是为了具备进行粗略估算（back of the envelope calculations）的能力。这些是基础的原材料。你可以用它们来进行推演：“如果我需要设计一个用于图像搜索并为结果页面生成缩略图的系统，我该怎么做？我可以预先计算缩略图，我也可以尝试实时生成缩略图。这会有什么后果？我需要多少磁盘带宽？我会进行多少次磁盘寻道？”利用手头这些基础数字，你实际上可以在 30 秒或一分钟内进行思想实验。当你使用更高层次的库构建软件时，你也想培养同样的直觉：“在这个特定类型的哈希表中查找需要多长时间？对一百万个数字进行排序需要多长时间？”

主持人： 我提出这个是因为这几年来我一直试图编制一份“每个 AI 程序员都应该知道的数字”。但我没搞出什么好版本，因为现在的数字不像物理常数那么固定。最简单的可能是将参数数量转换为磁盘大小，但这只是简单的字节转换，没什么有趣的。如果你要更新这个表格，针对 AI 你会写什么？

第六章：能源消耗、批处理与 TPU 硬件协同设计

Jeff Dean： 思考模型中的计算（无论是训练还是推理）的一个好方法是：你需要从内存中（无论是片上的 SRAM，还是加速器附加的 HBM，或是 DRAM，亦或是通过网络）引入多少状态数据？这些数据移动的成本，相较于在矩阵乘法单元中进行一次实际乘法运算的成本有多大？实际的乘法成本极低，根据精度的不同，不到一个皮焦耳（picojoule）。

主持人： 你是用能源消耗（energy）来衡量的。

Jeff Dean： 是的，一切最终都归结于能源，以及你如何以最节能的方式进行计算。从同一芯片另一端的 SRAM 中移动数据，可能就需要一千个皮焦耳。

主持人： 哇。

Jeff Dean： 这就是为什么你的加速器需要使用批处理（batching）的原因。因为如果你把模型的参数从芯片上的 SRAM 移动到乘法单元中需要花费 1000 皮焦耳，你最好把这个搬运过来的数据多用几次。这就是批次维度的用武之地。如果你的批次大小是 256，那平摊下来成本就不算太糟。但如果你批次大小只有 1，那情况就非常糟糕了。你花费了 1000 皮焦耳，只为了执行那 1 皮焦耳的乘法运算。

主持人： 我从没听过用“能源”视角来分析批处理的。（笑）

Jeff Dean： 这就是人们为什么要使用批处理的根本原因啊，对吧？理想情况下，你当然希望批次大小为 1，因为延迟会极低。但能源成本和计算成本的低效将会极其巨大。

主持人： 有没有类似的硬件创新技巧？比如 Nvidia 和 Groq 都在 SRAM 上押注很大。我想你们在面对规模化服务需求时，在 TPU 的设计上早就预见到了这些。

Jeff Dean： TPU 有一个非常好的规则结构，即由众多芯片通过 2D 或 3D 网格连接而成，每块芯片上都附加了 HBM 内存。在服务某些模型时，从 HBM 引入数据的成本和延迟要远高于从片上 SRAM 引入。所以，如果你的模型足够小，你实际上可以进行模型并行（model parallelism），将其分布在比如 16 或 64 块芯片上，这在吞吐量和延迟上会带来极大的改善。如果能做到这一点且全都能放进 SRAM，那将是一个巨大的胜利。这不是什么惊喜，但确实是一项好技术。

主持人： 在 TPU 的设计中，你们是如何决定在哪里进行改进的？是设计一种新芯片把那 1000 皮焦耳降到 50 值得，还是像极端做法那样直接把模型烧录进 ASIC 芯片里？当事情变化得如此之快时，在硬件上投入多少是值得的？

Jeff Dean： 我们的 TPU 芯片架构设计团队与高层的模型专家之间有大量的互动。因为作为 ML 的硬件设计师，你从今天开始设计一块芯片，可能需要两年时间才能真正在数据中心落地，然后它还要有三到五年的生命周期。在一个快速变化的领域里，你实际上是在预测未来 2 到 6 年内，人们想要运行什么样的 ML 计算。

因此，让拥有超前 ML 研究想法（我们认为将在那个时间段开始奏效或变得更重要）的人参与进来，能够帮助我们在 TPU 的下一代（TPU N+2）中加入有趣的硬件特性。有时候你可以加入一些前瞻性（speculative）的特性，也许不会占用太多芯片面积，但如果它行得通，就能让某项计算快 10 倍。如果行不通，你也只是浪费了一点点芯片面积，没什么大不了的。但如果是非常大的改变，我们需要相当确定它能成功，所以我们会进行大量严谨的 ML 实验来验证。

主持人： 有没有反过来的情况：你们已经在这个芯片设计上投入了资源，所以不能让模型架构朝那个方向发展，因为它不适配硬件？

Jeff Dean： 当然。你肯定需要调整模型架构的形态，使它们能够在这一代芯片上高效地进行训练和推理。有时你可以利用未来一代芯片上即将推出的低精度（lower precision）特性。因此，即使当前这一代芯片还不能完全支持，你也可以开始用较低的精度来训练它。

主持人： 精度能降到多低？有人说三值（ternary）网络。

Jeff Dean： 我非常支持采用极低的精度，因为那能为你节省海量的能源。减少传输的位数是降低每比特皮焦耳数的极好方法。我认为人们在极低位精度上取得了很大的进展，只要他们引入缩放向量（scaling vectors）应用于一整批较低精度的权重上。

主持人： 这很有趣，极低精度搭配放大的权重缩放。当我们在对模型输出进行随机采样时（比如生成文本时的随机温度机制），讨论精度本身也是挺奇怪的一件事——因为在最后一步，无论这些芯片的数学运算做得多好，我们终究只是扔进去一个随机数生成器来进行采样而已。（笑）

Jeff Dean： 我认为有几个有趣的趋势。基于能量的模型（Energy-based models）是一个。不遵循词元顺序解码的扩散模型（Diffusion based models）是另一个。投机解码（Speculative decoding）则可以让你获得极高的摊销收益。比如你预测出接下来的 8 个词元，实际上将你的批次大小增加了 8 倍，然后你可能接受了其中 5 或 6 个词元，这就在将权重搬入乘法器时的摊销成本上获得了 5 倍的提升。所有这些都是非常棒的技术。通过能源、延迟和吞吐量的视角来看待它们，将指引你找到更优的解决方案。

第七章：研究前沿：可靠性与强化学习挑战

主持人： 你在 Google 看到过哪些有趣的研究思路？或者有什么你希望研究人员去攻克的难题？

Jeff Dean： 我们在研究方向上有一系列未解决的难题：如何使这些模型变得可靠（reliable）？如何让它们执行复杂得多、包含许多子任务的长序列任务？如何编排（orchestrate）一个模型去使用其他模型作为工具，从而协同完成仅凭单一模型无法完成的重大工作？

此外，如何让强化学习（RL）在非可验证域（non-verifiable domains）中发挥作用？我认为这是一个极其有趣的开放性问题。因为如果能够做到这点，就能将我们在数学和编程中看到的模型能力提升，扩展到其他不太容易进行严格验证的领域。

主持人： 对于非可验证领域，现在有某种有希望的思路吗？比如信息检索，这种很难验证的过程，应该如何建模？

Jeff Dean： 可以使用其他模型来评估第一个模型的执行结果。比如在检索任务中，你能否让另一个模型来评估检索出的 2000 个文档的相关性，选出最相关的 50 个？我认为这种技术实际上非常有效。有时候甚至可以使用同一个模型，只需通过不同的提示词，让它扮演“批评家（critic）”而不是检索系统的角色。

主持人： 我觉得在这个领域，大家总是感觉“容易的我们已经做完了，接下来的超级难，没人知道怎么搞”。

Jeff Dean： 这个领域的美妙之处在于，有许多聪明人都在寻找创造性的解决方案。两年前，我们还在与 GSM8K 级别的数学题作斗争（比如“Fred 有两只兔子，又得到三只，一共有几只？”）。而现在，模型已经能解决类似 IMO（国际数学奥林匹克竞赛）级别的数学题了。这在一年半的时间里是能力上的惊人飞跃。如果我们能在其他领域实现这种跨越，那将是非常棒的。

第八章：统一模型与符号系统（关于 IMO 的突破）

主持人： 去年我们还有 AlphaProof、AlphaGeometry 这样结合了证明器的系统。但今年，你们直接把 IMO 的题目扔给了 Gemini 这个统一的大模型。为什么放弃了原本的思路，决定全部在 LLM 中完成？这种结合符号系统和 LLM 的执念为什么被打破了？

Jeff Dean： 在我看来这很有道理。人类能够操作符号，但我们的头脑中可能并没有某种显式的、硬编码的符号表征机制。我们在头脑中拥有的是某种分布式的表征，类似神经网络。我们在看到特定事物时，神经元的激活模式使我们能够进行推理、计划和展开思维链。如果我们发现当前的解题思路行不通，我们会退回来尝试另一种。在很大程度上，我们在基于神经网络的模型中，正是在模拟我们直觉上认为真实大脑内部发生的事情。

所以，去维护一套完全独立、离散的符号系统，然后再搞一套完全不同的思考机制，这对我来说从来都说不通。

今年的 IMO 突破在于，我们将其转换为使用单一的统一模型（大致就是那个添加了更多推理计算预算的生产级模型），这展示了该通用模型（general model）的能力已经得到了极大的提升，你不再需要那些专业化的模型了。

主持人： 这是机器学习经典套路的重演。2013-2016 年间，大家还会为街景标志、语音识别训练单独的模型。现在统一模型的时代已经全面到来。只要提供足够的数据和算力，这些掌握“通用机器学习技能”的研究员就能解决任何任务。这或许就是某种“苦涩的教训（bitter lesson）”。

Jeff Dean： 是的，通用模型在绝大多数情况下都将胜过专用模型。

第九章：知识与推理的剥离，以及垂直模块化模型

主持人： 我想在这深入探讨一点。模型的能力容量受限于其参数量。对于小尺寸模型，在模型蒸馏的过程中，它不可避免地会记住了很多其实并不实用的死知识。我们能否把“知识”和“推理”分离开来？

Jeff Dean： 如果模型能够利用检索（retrieval）功能，你确实希望它在推理能力上最为高效。让模型把宝贵的参数空间用来记忆那些随时可以查到的晦涩事实，实际上并不是这些参数空间的最佳用途。你更希望这些参数被用来赋予模型在更广泛的场景中普遍有用的能力。

但同时，你也不希望你的模型完全脱离对世界的常识认知。比如，模型脑子里得大概有个概念，知道金门大桥有多长，以建立对“桥”的长度尺度感。它不需要知道世界上某个偏僻角落的无名小桥有多长，但拥有相当的世界知识（world knowledge）还是有帮助的。模型越大，能包含的世界知识就越多。

我认为，将检索与推理结合起来，让模型在执行多阶段检索时变得极为出色，并且能够对中间检索结果进行推理，这将是让模型看起来能力暴增的一种非常有效的方法。回想一下之前提到的个人版 Gemini 助手。我们不可能用我的个人邮件去训练整个 Gemini 大模型，但我们希望拥有一个单一的强大模型，将检索我的个人邮件或照片作为一种工具，然后让模型对其进行多轮交互推理。

主持人： 那些专注于垂直领域的模型（比如医疗 LLM、法律 LLM）是长期的解决方案，还只是短期的权宜之计？

Jeff Dean： 我认为垂直领域模型很有意思。你希望它们从一个非常优秀的基座模型（base model）开始，然后用特定垂直领域的数据去丰富它的训练分布。比如在机器人领域，我们为了保持基座模型各项能力的平衡，不会把世界上所有的机器人数据都喂给通用 Gemini，只会让它接触到一部分。但如果你想构建一个顶级的机器人模型，你就会在它的基础上用更多的机器人数据去训练。这可能会损害它的多语言翻译能力，但会极大地提升它的机器人控制能力。

我们一直在预训练的数据混合中进行这些权衡。我们非常希望包含另外 200 种语言的数据。但这必然会挤占模型在其他方面的能力——比如它在 Perl 编程上可能就不那么擅长了（Python 肯定还是很好，因为我们会放足够多的数据）。

因此，一种可行的方向是混合专业模型（specialized models）和更具模块化（modular）的模型。比如，如果你能拥有支持 200 种小语种的基础能力，加上一个绝佳的机器人控制模块，再加上一个顶级的医疗模块。所有这些模块都能协调运作，并在不同的特定环境下被按需调用，那将是非常理想的。

第十章：多语言能力与极低资源语言的洞察

主持人： 我记得你曾举过一个非常有意思的例子：你们把一种名为卡拉芒语（Kalamang，全世界只有 120 个人使用且没有书面文字的极低资源语言）的整本词典或全部数据放进了上下文窗口中，模型就在上下文中直接学会了这门语言。（笑）

Jeff Dean： 是的，因为你直接把整个数据集塞进了上下文里！对于其他语言，比如索马里语，我们可能没有把所有的索马里语语料都放进 Gemini 的预训练里，只放了一部分。但如果你在上下文中放入更多，它在处理该语言时的能力就会极大提升。

我还做过一项早期研究，将具备优良词表征的语言模型与在类似 ImageNet 上训练的图像模型融合在一起，并对顶部层进行联合训练。我们发现，如果你给出一个模型在图像训练集中从未见过的类别的全新图像，比如“显微镜（microscope）”（当时图像模型的类别里只有望远镜和双筒望远镜），模型依然能够为其分配“显微镜”这个标签。尽管它从未见过一张被标注为显微镜的图像，但它通过多模态的映射关系推理出了这个概念。

第十一章：模型规模化的历程与 Gemini 的起源

主持人： 纵观你的职业生涯，你觉得大家问得不够多、但你认为很重要的问题是什么？

Jeff Dean： 回想 1990 年我做本科毕业论文时，主题就是神经网络的并行训练。我当时就觉得神经网络是正确的抽象方向，只是我们需要比当时多得多的算力。从 2008 年或 2009 年开始，借由摩尔定律和大数据集，世界上终于拥有了足够的算力去训练能解决语音和视觉等实际问题的神经网络。

2011 年底我在 Google 开始研究神经网络时，我强烈感觉到我们应该利用大规模并行计算，把我们能训练的神经网络规模极大地扩展上去。于是我复活了我在本科论文中的一些想法（模型并行和数据并行）。我们用 16000 个 CPU 核心训练出了一个拥有 20 亿参数的视觉模型，它的规模是当时任何其他神经网络的 50 倍以上。它在 ImageNet 22K 上取得了 70% 的相对误差改善。那让我们真正看到了规模化的巨大力量。

我们当时的口头禅就是：“更大的模型，更多的数据，更好的结果（bigger model, more data, better results）。”这成了我们在此后六七年里不断规模化扩展的信条。

主持人： 问一个可能有点敏感的问题。之前曾在你手下工作的 David Luan 曾在我们播客中提到，Google Brain 内部早年存在一种算力配额的“自由市场（marketplace）”机制，每个人都有配额去追求自己的研究，这导致 Google 未能在语言模型上“押注全部身家（bet the farm）”，而 OpenAI 却愿意孤注一掷。你是如何看待这段历史的？

Jeff Dean： 我在一定程度上同意他的看法。这也是为什么后来我写了一份单页备忘录，指出我们把资源碎片化（fragmenting）是非常愚蠢的。当时 Google Research 的 Brain 团队有研究大型语言模型的项目，也有研究多模态模型的项目；而（曾经独立的）DeepMind 也在搞 Chinchilla 模型和 Flamingo 模型。

这不仅分散了我们的算力，更重要的是分散了我们最优秀的人才和最好的点子。所以我说，这简直太蠢了。我们为什么不把力量结合起来，集中精力去训练一个无敌的、单一的统一大模型，它从一开始就是多模态的，并且在所有方面都很出色？这就是 Gemini 项目的起源。我的那页备忘录奏效了。

主持人： “Gemini（双子座）”这个名字也是你起的对吧？

Jeff Dean： 是的。当时大家提议了另一个名字。我说，这两个组织（Brain 和 DeepMind）真的就像双胞胎（twins）一样融合在了一起。而且，NASA 历史上的“双子座计划（Gemini Project）”也是通往最终登月的“阿波罗计划”极其重要的一块基石。这听起来是个很好的名字。双胞胎走到了一起，对吧？

第十二章：AI 辅助编程、智能体协作与规范设计

主持人： 作为一个传奇工程师，你现在是如何用 AI 编程的？你曾说过需要找到一个思维方式与你互补的人进行结对编程（pair programming）。随着编码智能体的发展，你如何塑造一个符合你思维习惯的 AI 助手？

Jeff Dean： 现在的编程工具比一两年前有了质的飞跃，你可以放心地把更复杂的任务委托给它们。一个非常有意思的现象是，你与这个编码模型对话的方式，其实决定了它与你互动的方式。

你可以要求它：“请帮我写一堆测试用例。”你也可以要求它：“请帮我头脑风暴一下性能优化的思路。”你的提问方式会塑造模型的反应、它要处理的问题类型。你是希望模型独立去完成大型任务，还是希望与它进行更频繁的互动以确保它处于正确的方向？

如果你手下有 50 个实习生（如果是人类的话），你会如何管理他们？你可能会让他们分成几个小组，这样你就不用与 50 个人一一对接，而只需与 5 个小组进行交流，由他们去代你执行任务。未来，人们很可能每个人都管理着 50 个虚拟智能体，这也同样需要寻找合适的交互与管理模式。

主持人： 当这些智能体代写了大量代码后，项目内部的上下文变得极其庞大，这是否会让程序员变得越来越孤立，因为很难把所有进展同步给一个新加入的人类同事？

Jeff Dean： 想象一个没有 AI 辅助的传统 50 人软件团队，他们的互动方式天然就是高度层级化（hierarchical）的。但这 5 个人如果每人管理着 50 个虚拟智能体，这 5 个人之间反而能进行带宽极高的通信。

主持人： 这是否意味着你需要花更多的时间在前期的需求文档（specs）和设计目标上？

Jeff Dean： 当人们刚学写软件时，老师总告诉我们“清晰地编写需求规格说明书极其重要”。但实际上没几个人当真，大家想的都是“管他呢，我要直接开撸代码了”。编写规范从未成为主导创作过程的核心产物。

但是，如果你要指示 AI 智能体为你编写软件，你最好非常非常谨慎地指定你的需求，因为这将直接决定输出的质量。如果你没有说明需要处理的边缘情况、性能要求，它可能就无法达到你的期望。未来，人们必须变得非常擅长清晰地指定需求，这不仅仅是软件工程师必备的技能，对任何使用 AI 执行任务的人来说，都是一项极其重要的核心技能。

主持人： 我常开玩笑说：“好的提示词（prompting），与极其高级的管理层内部备忘录是无法区分的。”你必须非常谨慎地斟酌你的用词。

第十三章：延迟预测、Tokens/sec愿景与硬件预测

主持人： 关于优化性能提示词和编写规范，你如何看待“让一个速度极快的傻瓜模型在人类指导下进行三次快速迭代修改”，与“花很长时间写一个巨长无比的提示词，让一个极聪明的慢速模型一次性生成”之间的性能差异？有时候模型表现不好，只是因为我们的需求没有明确（underspecified）。

Jeff Dean： 我是极力主张降低延迟的。与系统的低延迟互动，比等待一个慢 10 倍或 20 倍的系统要令人愉悦得多。我认为在未来，我们会看到模型底层的软件和硬件系统能够实现比今天低 20 倍、甚至 50 倍的延迟。这对于那些需要在你的两次交互之间执行大量操作的系统来说极其重要。

理想情况下，你当然想一直使用能力最强（类似 Deep Think 模式）的模型，阻止你这么做的唯一原因就是成本和延迟。

主持人： 当你提到更低的延迟时，我们现在大约在每秒 100 个 Token（tokens/sec）的水平。我们能达到几千吗？走到每秒 10,000 个 Token 有意义吗？

Jeff Dean： 绝对有意义。因为你需要进行思维链（chain of thought）推理。你可以做大量的并行推演，你可以生成海量的代码，并通过思维链推理检查代码的正确性。在 10,000 Tokens/sec 的速度下，你不再是“读取”代码，你只是直接让系统生成和迭代。最终输出给你的，可能是 9000 个 Token 的思维链推理过程，支撑着最终那 1000 个 Token 的精简代码。那样的代码，读起来体验大概也会好得多。

第十四章：对未来的预测与结语

主持人： 最后，你对未来有什么重大的预测吗？有什么你认为很快就能实现的？

Jeff Dean： 我做两个预测。第一，一个极度个性化、认识你、了解你所有状态，并且能够在你的许可下检索你拥有权限的所有信息（电子邮件、照片、观看过的视频等）的模型，其实用性将远远超过那些无法获取这些个人状态的通用模型。

第二，越来越专业化的硬件将催生出延迟极低、能力极强的模型，且价格将远低于目前的现状。这将非常重要。

主持人： 感谢你，Jeff。这次对话非常精彩，感谢你抽出时间。

Jeff Dean： 谢谢。非常愉快。谢谢你们的邀请。

术语表