Jeff Dean: The 1% Rule for Building in AI

编者按：本文是 Google 首席科学家杰夫·迪恩（Jeff Dean）在 AI Ascent 创业者峰会上的对谈实录。迪恩于 1999 年加入当时仅二十人的 Google，先后主导或参与了 MapReduce、Bigtable、TensorFlow、TPU 与 Gemini 等系统的构建。对谈由峰会主持人主持，面向台下数千名未来的创业者，话题围绕系统工程与创业选题展开。本文依据现场录音编译整理，仅删去口语枝节与寒暄，其余论述悉数保留。

回看预测：AI 已是初级工程师

主持人： 杰夫，欢迎。你做过 MapReduce、Bigtable、TensorFlow、TPU 和 Gemini，光是这些我们就能聊上一整个小时。但我最欣赏的是，你至今仍在公开做大胆的预测。去年，也就是 2025 年 5 月的 AI Ascent 峰会上，你说 AI 已经达到初级工程师的水平。一年过去了，这个预测离现实有多近？

迪恩： 我感觉模型在基于智能体（agent）的长时编码任务上进步很大，现在显然已经相当能干了。当然要看你对「初级工程师」的定义，但我认为这个预测基本命中。

主持人： 当时你低估了什么？

迪恩： 我觉得模型处理越来越复杂任务的能力，增长得比我预想的快。另外，在编码之外的领域，这些智能体系统也真正开始大放异彩。我认为这会是未来一个重要的趋势。

主持人： 那再给我们一个大胆的预测吧。2027 年版会是什么？

迪恩： 我认为你会看到机器学习系统本身被大量自动化。简单说，就是让机器学习系统通过大量运行实验来提升自身能力：把问题拆成子问题，在一个紧凑的自动化实验循环里跑这些子问题，再把结果拼起来，最终得到一个改进后的系统。这种完全自动化的问题分解和自动化实验，我觉得会非常令人兴奋。而且这不只适用于机器学习，也适用于其他科学与工程领域。基本上，只要目标是可度量的，如今都能取得很大进展。

历史重演：推理硬件的内存时刻

主持人： 我们回顾一下历史。早在 2001 年，Google 搜索还跑在硬盘上。你和桑杰（Sanjay Ghemawat）算了一笔账，发现到某个时点，整个搜索索引终于可以装进你们所有机器的内存里。你们做出了这个大胆的判断，然后在几天之内就把一个完全基于内存而非硬盘的新版搜索推上了生产环境，正是这一步让 Google 搜索变得那么快。历史总会以变奏的方式重演。在 2026 年的今天，「它能装进内存了」的时刻是什么？在座的每个人都应该在思考和设计什么？

迪恩： 情况有点不同，但我认为你会看到越来越多高性能、低能耗的推理硬件系统。因为大家现在都意识到，推理（inference）是让这些智能体系统惠及更多人的关键，延迟极其重要，而硬件的专用化是获得比通用计算设备（比如 GPU 甚至 TPU）更高能效、更低延迟的关键途径。

主持人： 在座的每个人都习惯了等模型回复。

迪恩： 等待可不好玩。

主持人： 所以你的意思是，如果我们不用再等了呢？

迪恩： 对。想象一下，如果延迟能好上五十倍，你能做出什么东西来。

主持人： 有意思。那么，这个房间里六千人可能都抱有、但其实已经不成立的一个 AI 认知是什么？

迪恩： 好问题。我想可能是这一点：人们还没有充分意识到，智能体系统不仅能在你关心的问题上跑一两个小时，在某些问题领域，只要底层模型足够强，它们可以连续跑几天甚至几周，完成非常复杂的任务。有些人已经开始看到端倪，但我认为大多数人还没有真正消化这一点。这将是一件大事。

主持人： 你自己跑过什么持续了数周的任务？你让智能体解决什么？

迪恩： 比如你可以让智能体用另一种编程语言把某个软件完整地重新实现一遍，新版本可能具有更好的安全属性或性能属性。它们真的能去做，而且做得相当扎实。

餐巾纸算出来的 TPU

主持人： 你出了名地擅长「餐巾纸算术」。关于你有个故事：2013 年，语音识别在 Google 开始真正好用，你算了一笔账，如果每个 Google 用户每天对着手机说话三分钟，仅仅三分钟，你们就得把整个服务器集群翻一倍，成本高得吓人。于是你们转而做了一款定制芯片，这就是 TPU 的起源。

迪恩： 是的。当时我们训练的基于深度学习的语音模型，已经开始呈现出非常好的质量。它们比旧的语音系统计算开销大得多，但把错误率砍掉了一半。这相当于语音识别领域二十年的进步，被压缩进了几个月，靠的只是调调模型、把规模放大一点、拿到更好的数据。于是我们开始担心：如果语音识别好用了很多，人们就会用得更多。那个粗略估算正是关于这一点：如果人们开始更多地用语音识别来口述邮件、跟手机说话，会怎么样？结果我们意识到，需要一个比当时在 CPU 上跑更好的方案。所以我们做出了 TPU。

TPU 高度专门化于低精度稠密线性代数，而这正是我们今天所用的几乎所有现代机器学习算法的核心。如果你造一颗专门做低精度稠密线性代数、别的什么都干不了的芯片，它对机器学习推理会极其有用，尽管它跑不了 Chrome 或 Word。那个项目几年后产出的芯片，能效比当时的 CPU 和 GPU 高出三十到八十倍，延迟也低得多，低了二十到三十倍。

主持人： 难以置信的是 TPU 今天成了怎样的基石。你当年绝不可能预见 TPU 会对 Transformer 架构如此重要，毕竟 Transformer 是在 TPU 发明之后很久才出现的。

迪恩： 这正是我们把它做成通用线性代数系统的原因，TPU 本质上就是这个。我们知道机器学习算法还在演进，所以不能过度专用化，但又要专用到足以获得巨大的性能收益：可以有非常大的乘法单元，可以有高速内存，可以有高速互连（后来几代 TPU 靠它让成千上万颗芯片高效协同处理同一个问题）。我们持续扩大规模、提升性能，如今已经迭代了很多代。

主持人： 了不起的餐巾纸算术。

迪恩： 餐巾纸是个好东西。

主持人： 那么，在座想成为创业者的人，今晚该在餐巾纸上算一笔什么样的账，才可能做出像 TPU 一样影响深远的东西？

迪恩： 这很难一概而论。我想，看看你所关注的领域里有哪些问题、哪些瓶颈，然后问问是否存在截然不同的解法，能带来一个甚至两个数量级的性能或能力提升。因为有时候，你眯起眼睛看一个问题，不锚定在今天的解决方式上，而是从第一性原理出发想该怎么解，就能想出别人没在想的好主意。

AI 时代的延迟与能耗数字

主持人： 给在座不了解的人补充一下：多年前，杰夫写过一份很著名的清单，叫「每个工程师都该知道的延迟数字」。里面是诸如一次缓存未命中要多久、一次磁盘寻道要多久、一个网络包从加州传到荷兰要多久之类的数字，全是关于分布式系统和系统工程的。它被贴在墙上，成了许多分布式系统工程师的圣经。现在这份清单该更新了。给我们一个 2026 年的 AI 版。

迪恩： 如果看看今天 AI 系统里什么最重要，你会想知道这些：加速器上主内存到片上内存、再到乘法单元的带宽；做一次乘法运算要消耗多少能量；芯片之间的互连带宽是多少，以这样的带宽能连接多少颗芯片；再往外走出这个域，当你需要和一万颗芯片而非五百颗通信时，网络带宽会衰减多少。我认为这些数字都非常值得学，它们直接影响你思考特定问题的方式。

主持人： 我听你讲过一件有意思的事：如今衡量一切的单位是能量。你指出，做一次计算大约要一皮焦，但搬运数据、做数据 IO 的代价是它的一千倍。

迪恩： 对。仅仅是把数据从加速器的 HBM 搬进处理器让它能算，就是这个代价。

主持人： 这个差距悄悄决定了什么产品是可能的，以及 AI 算法是怎么构建的。有哪些问题，创业者们一直管它叫「模型问题」，实际上却是能耗或数据 IO 问题？

迪恩： 你提到的搬数据与算数据之间一千倍的能耗差，确实很显著，它塑造了我们在机器学习里做的很多事。如果没有这一千倍的差距，你就不需要批处理（batching）。但现在你必须把许多样本或许多 token 打成一批，来分摊数据搬运的开销，这样付出的就不是一千倍的代价，而是一千除以批大小的能耗代价。而对于追求极低延迟的场景，批处理其实并不好用。所以我认为，这类事情，以及我们所用硬件背后各种决策的能耗账，深深影响着我们构建上层系统时的很多决定。

主持人： 一个很具体的例子就是模型训练的方式。整套关于把数据集分批、跑多轮 epoch 的概念，人们可能误以为是模型问题，其实是系统和数据 IO 问题，对吧？

迪恩： 是的。你必须组装批次来提高硬件效率。理想情况下你或许想做批大小为一的训练，但那样效率不高。所以如今人们都用相当大的批。

主持人： 你出了名地会抽出一个长周末或一周时间，然后带回一个绝妙的方案。会不会有那么一天，杰夫去闭关两周，把批大小为一的训练搞定？

迪恩： 其实我最近想得更多的是推理。我觉得推理是个很有意思的问题，因为你确实需要极低的延迟，而训练并不一定需要。我认为在硬件面向推理的专用化上，还有很大空间，远比我们今天做的多。

主持人： 在推理上，你正在认真思考的有趣方向有哪些？

迪恩： 尽量减少数据搬运；考虑极低精度的运算，而且或许不必支持那么多种精度。如果你对需要哪些精度已经有了明确答案，那就把它们做进硬件，别的基本不做。

主持人： 这让我想起一位著名计算机科学家的类比：整个 AI 的过程本质上是一个大的压缩问题，因为要把数据有损压缩再还原，你基本上得先理解它。

迪恩： 对，如果你真正理解了数据，就应该能把它压缩得很好。

主持人： 而 Transformer 架构正是被证明行之有效的方式之一。

迪恩： 目前看来相当管用。我的同事们干得不错。

上下文工程与 skills 实践

主持人： 我们把视角拉远一点。过去所谓 AI 的进步就是更好的模型：更多数据、更多参数。但近一两年，进步越来越多地来自模型周边的一切：检索、工具、记忆、智能体工具等等，这些可能正在被归拢成人们所说的「上下文工程」（context engineering）。

迪恩： 模型其实只是你要做的事情的一部分，你真正要构建的是一个能解决有趣问题的完整系统。这包括一个懂得使用各种工具的模型，它或许知道如何检索相关信息，或许存有过去解决其他问题时检索到的信息记录，并能把信息放进模型的上下文里。这样做的好处是，这些信息对模型来说非常清晰。模型的训练数据则不然，那是数万亿 token 搅在一起、熬成了几千亿乃至上万亿参数的一锅汤，远不如模型针对当前这个问题直接看到的上下文来得清晰。再往下，是理解有哪些工具可用、哪些能帮模型解决问题的下一阶段、如何把问题分解成一连串工具调用，或许还要尝试多种解法、看哪种奏效并加以评估。这就是复杂智能体和多智能体系统的整套编排，我认为它会越来越重要，眼下正是激动人心的时候。

主持人： 这个问题域的有趣之处在于，在座每个人都能上手。过去要训练模型，需要海量资源、海量 GPU 和数据；而做上下文工程，你只需要一个像 Gemini 这样的 API，然后自己搭检索、搭工具调用就行。给在座的人一些建议吧，怎样才能在上下文工程上做得出色？

迪恩： 一个很好的办法是，用这些模型以及各种「脚手架」（harness）和工具去真正解决问题，这样你就能看到模型在哪里失败。而且往往你不必调整模型参数（从外部很难做到），而是通过为模型写出更好的指引、为它编写 skills 让它知道如何使用对某类问题特别有用的工具，就能让模型在那类问题上做得更好、成功解决。当你这么做时，你的整套设置会进入一种自我改进的循环。这是理解「模型还需要哪些额外信息才能变得更强」的极好途径。

主持人： 能举个你亲自做过的上下文工程的例子吗？比如你写过的某个 skill 或工具，对你的工作流产生了巨大影响。

迪恩： 几周前我和桑杰在做一件事。我们经常给非常底层的库做性能优化。Google 内部有一个我们写的微基准测试库，可以用它写微基准，测各种操作耗时多久、填充某个数据结构要多久等等。有些数据结构跑在 Google 数以百万计的进程上，所以确保它们高性能相当重要。你可以写微基准，但在没有智能体系统的情况下，通常的流程是：先在你关心的基准上测出当前性能，做一些你希望能提升性能的修改，然后重跑基准看哪里变好了，再跑一组更广的基准，量一下缓存占用。于是我们写了一个 skill，把这些步骤及各种组合顺序教给模型，让它能自主完成「测基准、改代码、量提升、再迭代」这个自我改进的循环。对某些类型的问题，效果相当不错。说到底，这只是把我们作为人会采用的方法，以模型能用的形式交给它。

主持人： 这太厉害了。你的意思是，有这么一个 skill，谁拿到它就能像杰夫·迪恩一样做性能优化。全世界都会想要，对某些人来说值无限多的钱。

迪恩： 其实几个月前我们发布了一份文档，叫《性能提示》（Performance Hints），是我和桑杰写的，大概三十页，讲各种性能技巧。已经有人把它提炼后喂给各种模型，发现模型在推理代码性能问题上确实变强了。

主持人： 大家都听到了：拿这份《性能提示》，你就能像杰夫·迪恩一样优化自己的代码。

迪恩： 是的，全部免费公开，你们都该试试。

长时 agent 为何脱轨与对策

主持人： 说到智能体，在座的人大概都在做或者做过一个。而且我相信大家都见过自己的智能体在第三十或四十步脱轨。智能体跑到第十步左右还很好，到第五十步就摇摇欲坠。你认为今天的约束是什么？是上下文、评估器，还是因为它本质上是开环系统，错误在不断累积？

迪恩： 我们显然希望智能体能跑很长时间，因为这是它们解决越来越复杂问题的方式。但正如你观察到的，它们有时和工具交互十次之后就不行了。有时是因为模型在试图做它没多少经验的事。它在一整套东西上训练过，一旦稍微偏离它熟悉的分布，就像大多数机器学习模型一样，性能会开始下滑；离舒适区越远，就越可能表现不佳。

对此可以做几件事。一是给模型提供 skills 和提示，把它留在那条「灯火通明」的路上，也就是它确实会做的事情上。二是多智能体系统：让多个智能体尝试不同路径，再用另一个模型或智能体来评估哪些看起来有希望。这在某种意义上是在搜索可能解的空间，保留最有希望的，丢弃行不通或者脱轨的。这是一种非常通用、非常有用的技术：用推理时算力对合理的解题路径做搜索，能在长时智能体流程中获得高得多的性能和可靠性。

主持人： 你们内部是怎么为智能体实现这套工作流的？

迪恩： 我们有脚手架，还有一整套 skills，尤其是针对 Google 内部开发环境的。有了这些 skills，智能体就知道如何使用我们大量的内部工具，比如编码、代码评审、性能测量、拉取日志文件。这些 skills 加上去就能让基础模型更能干，即便它从未在「Google 内部工程师如何从我们的专有系统里拉日志」这种事上受过训练。只要 skill 定义得当，就能让它跑起来，智能体的实用性也随之提升。

1% 法则：创业公司在哪能赢

主持人： 我们来谈谈创业公司能在哪里赢。这一节我个人特别关心，因为在座的每个人作为未来的创业者，都要决定做什么。Google 的特点是从处理器到产品，整个系统都是协同设计的。哪些层是 Google 这样的公司会持续构建、不断累积优势的？两三个人的团队在哪里仍然能赢？

迪恩： Google、我们的 Gemini 模型和硬件基础设施，显然是在努力构建几乎什么都能做的通用模型。但这在很多情况下意味着，我们对特定领域的关注是不够的。在这些领域，一个精心设计的产品界面，配上一个模型和一组 skills，或者一个不在我们通用模型擅长范围之内的专用模型，就能拥有显著优势，因为你可以为你真正热爱的领域做出令人愉悦、准确率极高、质量极高的东西。我认为这正是房间里两三个人做他们真正兴奋的事时的优势所在。

但我也要提醒：通用模型在越来越广的领域里确实在变强。所以你得判断，你在做的这件事是否经得起时间，前沿模型会不会在未来六个月或十二个月内就做好它，还是说这是它们两三年内都做不到的事。做选题时要把这个权衡进去。

主持人： 我们再深入一点。通用模型你们当然会持续改进。听众该如何判断哪些领域不会被覆盖？创业者该怎么思考选题？

迪恩： 最重要的是选一件你非常兴奋、想去做、而且你认为对世界有用的事。做到这一点，你就已经远远领先于那些早上醒来想「我其实并不想做这个」，或者正在做一件对世界、对很多人其实没多大用处的事的人。这是我给自己「下一个做什么问题」定的头号筛选标准。

第二，看看当前更通用的模型在那个问题域里能做到什么程度。你可以测试它们：能把这件事做好吗？如果它们完全失败，那可能是个好兆头。如果它们能做一部分但做得不太好，那可能不是好兆头，因为这说明这种能力已经开始在模型里出现，随着更多训练数据或更大规模的模型，它很可能变好。所以，要找模型成功率是 0% 或 1% 的事，而不是 20% 的。

主持人： 怎么找到这些？它们本质上是训练集之外的东西吗？符合这个条件的问题究竟长什么样？

迪恩： 有时候是你构建的产品能接触到某种特定数据，而底层的通用模型接触不到。比如你做一个帮用户整理个人信息的东西，模型未必能看到这些信息。在这里你就有很大优势，因为你的模型或产品突然拥有了对重要数据的可见性。也可能是某个极难的问题，如果你拿到合适的训练数据，训练出一个比通用模型更专门的模型，成本其实可以很低：为这个特定问题训练一个小众模型，未必需要多少算力，却能得到高准确率的东西。这有时能成为解决重要问题的极好基石，而这类问题通用模型往往处理得不好。

主持人： 有意思，基本上是两条路。第一条有点好笑：你们在整理全世界的信息，这块大概已经覆盖得差不多了；但整理个人的信息，还是开放的。

迪恩： 没错。

主持人： 第二条路是特定领域的专用模型。能多讲讲有哪些这样的领域吗？

迪恩： 比如我同事做的 AlphaFold，那是一个专门做蛋白质折叠的模型，非常成功，把那个领域处理得相当好。于是你突然有了一个惊人的工具和模型，能极其高效地回答关于蛋白质及其结构的问题。但它不是通用模型，而是非常专门的模型。还有其他领域适合这种路径，比如材料科学、芯片设计之类，你可以借助一个非常准确但小众的模型，去做今天很难做到的事。

主持人： 好例子。所以如果你们找到一个和 AlphaFold 形状相似的问题，那可能就值得做。

规格说明与选题品味

主持人： 假设你已经找到了要做的问题，接下来聊聊怎么成为「AI 原生」的创业者，怎么真正做好。你过去说过，管理一支五十或一百个智能体的队伍，关键在于写出真正好、真正清晰的设计文档或规格说明（spec）。人们怎么练好这一点？好的规格长什么样？

迪恩： 和你的虚拟智能体协作时，如果你能清楚地说明你要什么，成功的机会就大得多。你说得越清楚，智能体就越有指引和规则可循，越清楚它要达成的轮廓。反之，如果你说得很少，智能体就得去推断你的意思，很多时候它推断出的东西和你想的并不一样。我们从一开始就告诉计算机科学家：在动手写软件之前，先说清楚这个软件要达成什么，这非常重要。现在我们有了能代笔的智能体系统，但说清楚你要什么的重要性反而上升了。因为以前你是把任务交给一个聪明的人，他或许有背景知识，或许会向你追问；智能体有时也能追问，但清晰的规格说明无论如何都是好主意。

举一个编码智能体用得极好的例子：今天的模型可以非常有效地把软件从一种语言翻译到另一种语言，因为在这种情况下，你手里有一份无比详尽的规格说明，就是整个软件本身，它说明了系统应该做什么。所以如果你有一个 Python 实现，想要一个 Go 实现，如今的模型在这方面显得极为能干：它可以把 Python 里的所有测试翻译成 Go，确保在 Go 版本里通过，比较两个实现之间的行为差异，直到没有差异为止。它之所以高效，正是因为规格如此清晰。

主持人： 现在假设每个创业者都学会了同时运行数百个智能体，所有代码都由智能体写。稀缺的技能变成了什么？

迪恩： 我认为是对「让智能体做什么」拥有极好的品味。以我的研究背景来看，这正是研究问题的症结所在。一个研究者可以拥有所有工具和技术，但大部分的战斗其实在于：你要把时间花在什么问题上？如果你选对了问题并成功解决，那远胜于对一个相当无聊的问题做一次漂亮的研究。这种「做什么」的高层智慧，我认为极其重要，而模型在这方面未必会很擅长。所以未来会是人在掌舵大量 AI 辅助的计算，以更快地成就伟大的事情。但「你究竟想让模型做什么」这个核心，才是你该聚焦的关键。

主持人： 再多聊聊品味吧。在智能体编码的时代，这个词被谈论得很多。品味究竟怎么培养？听起来太玄了，怎么把它落实？

迪恩： 这确实很难，很多时候品味没有可度量的目标。我想一部分来自经验：过去做过很多不同的问题，会教你哪些问题未来可能有趣，哪些事情把已有方法拼凑起来就刚好能实现，以及为了做出有点魔力或者非常有用的东西，还需要攻克哪些开放问题。

另一个让自己积累经验的办法是：把你认为未来十二个月里可能重要的事情列一份清单。你或许只挑其中一件去做，但十二个月后回头评估：其他那些事，哪些真的变得重要了？哪些被世界上别的人做出来了？哪些看起来还没人做？这能为你的品味养成提供多得多的样本。这是一项重要的技能。

主持人： 我们之前聊到的第三种方式，是做非常疯狂的思想实验。

思想实验：不可靠晶体管与 MapReduce

迪恩： 对，那也是个好办法。有时候，别把大多数人视为理所当然的事当成理所当然。前几天我和几位同事就做了一个疯狂的思想实验。六十年来，整个硅芯片设计与制造行业做了大量工作，把晶体管做得越来越小，同时错误率极低。因为大家的假设是：同一设计制造出的每一颗芯片，都应该和其他每一颗一模一样。

主持人： 你不希望有任何一个比特翻转。

迪恩： 一个比特都不能翻。为此内置了各种容错余量，比如如今内存都有 ECC 校验。但在宏观尺度上，我们构建大规模分布式系统时并不做这种假设。我们用不可靠的部件构建可靠的大规模分布式文件系统：单块磁盘可以坏，但你的数据必须安全。所以我们在更高层设计了机制，比如把数据存三份、放在三台不同机器、三个不同机架上，任何一个机架交换机、单台机器或磁盘坏了，数据都还在。我们还有里德所罗门编码（Reed-Solomon）之类的技术。但在晶体管这个层级，我们似乎从未把这种思路推到极致。

于是一个有意思的思想实验就是：如果你用每天可能出二十次错的晶体管去构建一个系统，会怎样？

主持人： 天哪。

迪恩： 而不是一百万年出一次错。那会是一个截然不同的设计点，可能在制造环节带来非常有趣的可能性。你会有完全不同的设计方法论：如果要把信号从这里传到那里，而晶体管极不可靠，你的信号传递方式可能会完全不同，比如沿多条冗余路径发送，确保至少有一条能送达。我觉得这是一组相当有意思的思想实验。我不是说我们应该去做这件事，但你确实需要偶尔质疑一下前提。当然，这类思想实验常常不成立，因为过去五十年之所以这样做而不那样做，往往有很充分的理由。但隔一段时间重新审视一下，是有好处的。

主持人： 太疯狂了。这听起来和神经形态计算、和人脑与自然的运作方式很有共鸣。

迪恩： 正是如此。我们大脑里的信号从一处传到另一处并不特别可靠。所以我想，大脑里真正重要的信息需要从一处传到另一处时，是有多条通路来保证的。

主持人： 你的职业生涯如此令人瞩目。过去有哪一个被你扔出窗外的疯狂假设，真的催生了一个影响深远的系统？

迪恩： 一个能说得上「成了」的例子是 TPU：在某个问题域显得远不如今天重要之前，就为它专门定制硬件，这就是一个思想实验。另一个好例子是 MapReduce 的起源。我和桑杰以及一些同事，做过 Google 抓取与索引系统的好几代迭代。我们写了大量手工并行化的代码，加了大量检查点，以确保它跑在一百台或一千台机器上、其中一些宕机时依然稳健可靠。但这些代码往往和你真正想做的、其实相当简单的事纠缠在一起，比如「我只想看一遍所有网页的内容，顺便算出一个从 URL 到该页面语言的映射」。这样简单的意图，被大量并行化和可靠性代码淹没了。

于是我们想起了当年在函数式语言上受的训练，意识到可以眯起眼睛看这些问题，发展出 MapReduce 这层抽象，放在实现之上；而在实现之下，把所有检查点和可靠性机制都放进一个底层库，让一切都建立在它之上。这成了 Google 稳健可靠地处理超大规模计算的一种极为成功的方式。它的起点正是那个思想实验：如果眯起眼睛看，能不能找到大量问题都能装进这个抽象里？

主持人： 令人赞叹。一个思想实验催生了 MapReduce。

自动化科学方法与快速评估器

主持人： 回到你现在对定制硬件的兴趣。如今 AlphaChip 在做芯片布局，AlphaEvolve 会提出方案、评估它们、留下有效的。看起来你们正在构建这些能不断累积、「用 AI 造 AI」的系统。

迪恩： 更一般地说，科学方法的根基是：提出一个实验，实现运行它所需的东西，评估实验，得到结果。我认为现在越来越多的问题可以把整个循环实现出来，不是跑几个实验，而是跑非常多的实验，因为你能把这个循环自动化，并把循环的延迟压到极低。这将非常重要，它能让我们攻克科学、工程、机器学习模型设计本身，以及芯片设计等工程任务中的众多问题域。

如果你能以自动化的方式做这些事，再有一个编排框架，能接受非常高层的目标，把它拆成子问题，每个子问题都是一个这样的自动化循环，去探索解决它的最佳方式；然后编排框架再把子问题的解拼成上层问题的整体解。这会极具影响力，也极其重要。我认为它会加速机器学习的进步，加速科学，加速工程。这会很了不起。

主持人： 听起来很多领域都适用：只要有很好的评估器，或者邻近于可以形式化验证的东西，就是自我改进 AI 系统的沃土。

迪恩： 是的。不过很多时候，你的评估器需要变得快得多。举个例子，大约十年前我的同事做过一些量子化学方面的工作，目标是理解特定分子的性质。你可以生成某种分子构型，然后想知道它有什么性质。你可以跑一个计算量极大的密度泛函理论（DFT）模拟器，算一个构型可能要花一整晚。我的同事们做的是：把那些模拟运行的输入（分子构型）和昂贵模拟器的输出收集起来，用它们训练一个模拟器的神经网络近似。这就成了一个验证装置，但它不需要一整晚，而是快了三十万倍。

主持人： 哇。

迪恩： 而且准确度几乎和跑完整模拟器一样。这彻底改变了做科学的方式：现在你有一千万个东西要筛选，可以趁午饭的工夫跑完，而不是花六个月到处凑算力去跑所有这些模拟。我认为在很多领域，快得多的验证模型（可能是学习得到的验证模型）都有很大空间，它们能以快得多的速度给出对真实答案的近似。这改变了实验循环的思考方式，以及你转动这些循环的速度。

主持人： 你特别期待这种大幅提速的科学方法去解决或实现什么？具体是哪些问题、哪些领域？

迪恩： 显然，机器学习本身是其中之一：能不能有一个模型，通过运行大量实验递归地自我改进？想想今天大型研究团队是怎么改进模型的：通常是人想出一些点子，跑一批小规模实验，看效果如何；如果不错，就挑最有希望的那些在更大规模上尝试，再评估，然后把结果整合进模型的新配方。我认为没有什么真正的障碍阻止这个循环变得高度自动化：模型自己决定要探索什么，或许在最高层接受一点来自人的推动，比如「你去试试把这个思路纳入模型架构的新点子」，然后它去跑大量实验，看哪些有效，再以快得多的速度把它们整合进来。说到底，你要优化的是每单位算力投入所产出的发现数量。

蒸馏被拒与职业路径选择

主持人： 回到这个房间。在座各位将来创业或开始职业生涯时，大概率会收获大量拒绝。你也遇到过。有个故事是，2014 年你和杰弗里·辛顿（Geoffrey Hinton）、奥里奥尔·温亚尔斯（Oriol Vinyals）写了一篇关于蒸馏（distillation）的论文，讲的是用一个大的教师模型去训练一个小得多、效率高得多、参数更少、计算更便宜的模型。这已经成了全行业人人都在用的技巧。可这篇论文当年被 NeurIPS 拒了。

迪恩： 是的。我不怪程序委员会。很多时候一篇论文会有三位审稿人，其中一位看了之后，在这个案例里说的是「不太可能产生显著影响」。

主持人： 「不太可能产生显著影响」。

迪恩： 但我们写这篇论文时，确实看到了这是个极其重要的问题，因为我们知道，用大规模模型做出更便宜、又高度能干的模型，是我们迫切想做的事。我们想把模型服务提供给越来越多的人，覆盖语音、视觉等各种领域。可审稿人或许没有这样的经历，或许没在考虑大规模 AI 服务，而是在想「这算不算根本性的进步」。所以，论文时不时被拒，没关系。我们把它放到 arXiv 上，人们读了，人们用了，一切都好。我们自己也在用它，比如从更大的 Pro 模型蒸馏出 Flash 模型。Gemini 的 Flash 模型相对其体量和速度之所以如此能干，部分原因就在于此。

主持人： 在同等规模的模型里，它们是各项基准上最强的之一，令人印象深刻。我想这里的教训之一是：即便被拒，也要继续走下去。

迪恩： 对，这就是我从中「蒸馏」出来的教训。

主持人： 有趣的是，你 1999 年加入 Google 时，它还是一家二十人的创业公司。如果把当年那个年轻的杰夫·迪恩传送到今天，带着你的技能，你会怎么做？加入前沿实验室，还是创业？二十五岁的杰夫·迪恩会怎么选？

迪恩： 这很难说，把时间花在什么上是非常个人的选择。对我来说，最重要的几个问题是：你要做的是不是你真正在乎的事？如果你和一群你喜欢共事的同事一起在这件事上取得进展，或者集体把它解决了，这会不会以某种正面的方式给世界带来改变？比如你突然能做到某件事，把它作为服务提供出去，帮到生物化学家；或者范围更广一些，帮到程序员，帮到互联网上的所有消费者。你应当追求的是对世界产生正面影响，和你喜欢的人共事，努力工作，尽力而为。

至于你说的具体权衡，加入前沿实验室还是和一两个、两三个亲密朋友创业，这是两种不同的体验。在一个大型成熟组织里，你有结构，有大量出色的同事，他们懂很多你不懂的东西，有大量有趣的问题可以做，而且你已经拥有一个产生影响的平台，你的工作已经在影响世界上很多很多人。而作为一个很小的创业公司，你必须有自己热爱的东西，并且要承担很大的风险：你能不能在这个问题上成功，能不能把一项事业做大。但我想那也会有极大的回报。所以这真的取决于个人偏好。但无论走哪条路，至少要问自己：如果我做这个问题，并且出现了最好的结果，世界会不会因此在某方面好很多？还是世界只会说「呃，挺酷的，不过也就那样」？后者不值得你投入时间。

组队原则与留给后来者的问题

主持人： 再多聊聊第二条路，和你真正喜欢的人在小团队里工作。你是许多工程师杰出的导师和管理者，也构建过庞大的系统。关于如何与聪明人共事、如何找到聪明人并发挥他们的最大价值，有什么经验可以分享给在座的人？

迪恩： 你总是希望找到在团队所需的某个领域里技能真正过硬的人，无论是在公司内部组建团队还是创业。但你也要找那些让你乐于与之相处的人，因为你会花大量时间和他们一起攻克非常难的问题。你想要低自我、有团队精神、并且技能与你互补的人。我一直觉得，在一个小团队里，别人懂我不懂的东西，而我也有些别人不那么擅长的技能，这非常有趣。因为你们在共同构建一样也许谁都无法单独完成的东西，而在这个过程中，你会获得很多新知识和新技能，他们也一样。

你可以把自己的工程或研究生涯看作一条装满技术的工具腰带，你要不断往里添新工具。因为你永远不知道什么时候会碰上一个需要这四件专用工具而不是那三件的问题。工具越多，你未来遇到的问题就越可能被你解决。

主持人： 最后一个问题。我很确定这个房间里会有一个或几个人，最终做出像 MapReduce、TPU、蒸馏那样影响深远的东西。你希望他们去解决什么问题？

迪恩： 世界上有很多有意思的问题，我随便列几个，绝不穷尽，因为世界很大，问题很多。我特别期待硬件上的新路径，刚才那个思想实验就是一种指向，还有效率高得多的推理硬件。我认为机器学习可能存在截然不同的算法，数据效率远高于我们今天的方法。想想我们今天的大规模模型，它们看过的数据大概是一个人到十八岁为止所见的一千倍。然而十八岁的人在很多事情上表现更好，在其他方面也与那些看过多得多数据的前沿模型不相上下。所以，能不能做出数据效率高得多、能从自身行为中持续学习的系统？持续学习（continual learning）是个非常有意思的方向。多智能体交互也很有意思。另外，创造让世界上的人更好地对话的方式也可能很有意思：有没有办法让交流文明得多？帮人们基于兴趣结识世界各地本该认识的人？这些都是有趣的事。世界上有很多很酷的东西，我们都应该努力让更酷的事情发生。

主持人： 太好了。非常感谢你，杰夫·迪恩。今天就到这里。

迪恩： 谢谢大家。