Jeff Dean：AI 时代构建者的 1% 法则Y Combinator

好，我们开始吧，Jeff？

好啊，听起来不错。

Jeff，欢迎你，也再次非常感谢你来。尤其是我刚好感冒了，还是谢谢你愿意来。

我恐怕也已经把嗓子弄哑了。我平常说话不是这个声音，不过我们尽量把它完成吧。

你做过 MapReduce、Bigtable、TensorFlow、TPU、Gemini。光讲这些我们就能聊一整个小时，但我很喜欢的一点是，你到现在还会公开做大胆预测。去年——对，2025 年 5 月，在 AI Ascent 上，你说 AI 已经到了“初级工程师”的水平。现在大约过了一年，这个判断实现到什么程度了？

我觉得模型在基于 agent、持续更长时间的编程任务上进步很大。现在看起来，它们确实已经相当有能力了。当然，这取决于你到底怎样定义“初级工程师”，但以我的判断，那句话现在看起来相当准确。

那个预测里，你低估了什么？

我低估了它们处理越来越复杂任务的能力增长速度。我原先没有想到会这么快。另外，不只是在编程领域，这些 agent-based 系统也开始在其他领域表现得非常亮眼。我觉得这会成为未来一个很重要的趋势。

那再给我们一个大胆预测吧。（轻哼）你觉得“2027 年版”的预测是什么？

我觉得我们会看到越来越多“机器学习系统本身的自动化”。也就是说，让 ML 系统通过大量实验来提高自己的能力：把问题拆成子问题，让这些子问题进入非常紧密的自动实验循环，收集结果，再把结果组合起来，得到一个改进后的系统。也就是把“问题分解 + 自动实验”这整套流程高度自动化。我觉得这会非常令人兴奋。

而且我认为这不只适用于机器学习，也适用于科学和工程的其他领域。基本上，只要某个问题有可度量的目标，现在就有机会通过这种方式取得很大进展。

我们往历史倒一点。很久以前，2001 年左右，Google 搜索还在硬盘上运行。

对。

你和 Sanjay 做了一遍计算，意识到某个时刻，整个搜索索引终于可以装进当时所有机器加起来的 RAM 里。你们由此做了一个很激进的改变：几天内就把一个新的、主要在内存而不是硬盘上工作的搜索版本推到了生产环境。这也是 Google 搜索后来变得那么快的重要原因。

历史经常换一种方式重演。到了 2026 年，今天有没有一个类似“它终于能装进内存了”的时刻，是现场所有人应该注意、应该围绕它重新设计系统的？

情况有点不同，但我觉得我们会看到越来越多高性能、低能耗的推理硬件。大家越来越意识到，推理才是让这些 agent-based 系统能够服务更多人的关键；延迟也非常重要。通过硬件专用化，你可以比更通用的计算设备——源字幕这里举的是 GPU 或 TPU 一类设备——获得更高能效、更低延迟。

因为现场所有人都习惯了等模型回复。（清嗓）

等待一点都不好玩。

所以你是在说：如果我们以后根本不用等呢？

对。想象一下，如果一个系统的延迟能改善大约 50 倍，你能用它做什么。

这个想法很有意思。那现场大约 6,000 人可能共同相信、但其实已经不成立的一条 AI 假设是什么？

这是个好问题。我觉得很多人还没有真正意识到：agent-based 系统可以运行多长时间。它们不只是对一个问题工作一两个小时；在某些问题域里，只要底层模型足够强，它们可以持续运行几天甚至几周，完成很复杂的任务。已经有人开始看到一点苗头了，但我不认为大家真的把这件事内化了。我觉得它会是一个非常大的变化。

你实际让 agent 连续跑过几周的任务，有什么具体例子？你到底让它们解决什么？

比如，你可以让 agent 去把一套软件完整地重新实现成另一种编程语言，希望新版本拥有更好的安全属性，或者更好的性能属性。然后它们可以真正离开一段很长的时间，把这类工作相当认真地做下去。

很酷。你还有一件特别出名的事：很会做“餐巾纸计算”，也就是快速做数量级估算。2013 年左右，Google 的语音识别开始真正有效。有个故事说，你算了一下：如果每个 Google 用户每天只对手机说话、使用语音识别 3 分钟，所需服务器量就会大到几乎要把 Google 的服务器 fleet 翻一倍；仅仅为了语音识别就会非常昂贵。

对。

所以你们没有继续按原方案堆服务器，而是做了一块定制芯片，这就是 TPU 的起点。

是。我们当时已经看到基于深度学习的语音模型带来很好的质量提升。它们相较旧语音系统计算成本更高，但错误率大约减半——几个月里，靠调整模型、扩大一点规模、拿到更好的数据，效果相当于过去大约 20 年语音识别的进步。

然后我们开始担心：如果语音识别真的好用很多，人们就会用得更多。那次 back-of-the-envelope calculation 本质上就是在问：如果大家开始更多地用语音识别写邮件、对手机说话，会发生什么？最后我们意识到，继续跑在当时的 CPU 上不是一个好答案，需要更好的办法。

所以我们做了 TPU。它本质上高度专门化于低精度的稠密线性代数，而这恰好处在几乎所有现代机器学习算法的核心。你可以做一块芯片，它擅长低精度稠密线性代数，除此之外几乎什么都不会——它跑不了 Chrome，也跑不了 Word——但对机器学习推理极其有用。几年后，那一代芯片相对于当时的 CPU 和 GPU，能效大约高 30 到 80 倍，延迟也低很多，大约改善 20 到 30 倍。

这很惊人。现在 TPU 已经成了如此基础的设施。当初你不可能预见到后来会出现 Transformer，而 Transformer 是在 TPU 之后才被发明的。

这正是为什么我们当时做的是一个相对通用的线性代数系统——TPU 本质上就是这个。我们知道 ML 算法还在演进，所以不应该过度专用化；但又要专门化到足以得到巨大的性能收益。我们可以做非常大的乘法单元，可以有高速内存，可以做高速互连。后来的 TPU 还可以让很多很多芯片高效地共同处理同一个问题。这些年我们已经做了很多代，并不断把规模和性能往上推。

这个餐巾纸计算太厉害了。

餐巾纸很好用。（笑）

那么，现场每个想成为未来创始人的人，今晚应该做什么样的“餐巾纸计算”，才有可能发现像 TPU 一样重要的东西？

这总是很难直接回答。不过我会先想：你现在看到的问题是什么？瓶颈是什么？有没有一种完全不同的解法，可以让性能、能力或者你关心的指标提高一个数量级，甚至两个数量级？

有时候，你需要眯起眼重新看问题，不要被“今天大家就是这样解决的”锚定。试着从第一性原理问：如果从头开始，我会怎样解决它？这样往往会冒出一些很好的想法，而且它们未必是别人正在想的方向。

这是个很好的建议。（清嗓）很多年前，你写过一份非常著名的“Latency Numbers Every Programmer Should Know”，里面是各种系统工程数字，比如 cache miss 要多久、磁盘 seek 要多久、一个网络包从加州到荷兰要多久。它几乎成了很多分布式系统工程师贴在墙上的“圣经”。如果今天把它更新成 2026 年 AI 版，应该包含哪些数字？

如果看今天 AI 系统真正重要的东西，我会想知道：加速器的主存到片上内存的带宽是多少；片上内存到乘法单元之类计算单元的带宽是多少；一次乘法到底耗多少能量；芯片之间的互连带宽是多少；在这个带宽下可以连多少芯片。

再往更大规模走，你还应该知道：当你不再和 500 块芯片通信，而是要和 10,000 块芯片通信时，网络带宽会怎样掉下来。这些都是非常重要的数字。它们会直接改变你思考某一类问题应该怎样解。

我还听你提过一个很有意思的转变：现在几乎所有东西最后都可以用“能量”来衡量。

对。

你举过一个数量级：做一次计算，大约是 1 pico 这个量级；但搬运数据、做数据 I/O，代价可以高大约 1,000 倍。

对。仅仅是把数据从加速器上的 HBM 搬进处理器，让它真的可以被计算，就要付出这个代价。

这个差距其实悄悄决定了哪些产品可行、AI 算法怎样构造。创始人经常把哪些问题叫做“模型问题”，但其实它们更像能源问题或数据 I/O 问题？

你刚才说的那个“搬数据比真正做计算大约贵 1,000 倍”的能耗差距，就是一个非常重要的例子，它塑造了机器学习系统的很多方面。如果没有这个 1,000 倍差距，很多时候你根本不需要 batching。

但现实里你必须把很多样本、或者很多 token 一起组成 batch，用更多计算去摊薄那次数据搬运的成本。这样你付的就不是完整的 1,000 倍，而更像是“1,000 除以 batch size”的能耗代价。可问题是，如果你追求极低延迟，batching 又不理想。因此，硬件里这些能量相关的约束，会一路影响到我们构建更高层系统时的决定。

一个很具体的例子就是模型训练。大家习惯了把数据集分 batch、跑 epoch。很多人可能以为这是模型本身的设计问题，但本质上它其实是系统和数据 I/O 问题，对吧？

对。你要组成 batch，才能让硬件运行得更高效。理想状态下，也许你会想做 batch size = 1 的训练，但从效率上看并不好，所以现在大家会使用相当大的 batch。

你不是很有名的一件事，就是可能出去度个长周末或者一周，然后回来给出一个很漂亮的系统解法吗？有没有可能某次 Jeff 消失两周，回来就把 batch size = 1 的训练解决了？

我最近想得更多的是推理。推理很有意思，因为你确实想要极低延迟；训练则不一定需要那么低的延迟。我觉得相较今天，我们还有很多空间去做更专门的推理硬件。

具体有哪些推理方向让你特别感兴趣？

一是尽量减少数据搬运；二是考虑极低精度运算；三是如果你已经非常确定需要什么精度，也许根本不必支持很多很多不同精度，而是只把你真正需要的精度做进硬件，其他都不做。

这让我想到一个类比：有位著名计算机科学家说，整个 AI 的过程其实像一个巨大的压缩问题。因为要把数据有损压缩、之后又能够恢复出有用的信息，你其实必须理解它。

对。如果你真的理解数据，你应该能把它压得非常好。

而 Transformer 架构就是目前证明相当有效的一种方式。

对，目前看起来确实相当有效。

我的同事们干得不错。（笑）

我们把镜头拉远一点。过去说 AI 进步，往往等于“模型变好了”：更多数据、更大的参数。但过去一年左右，越来越多进步来自模型周围的一整套东西——retrieval、tools、memory、agent tools——这些现在常被合称为 context engineering，对吧？

我觉得模型只是整个系统里的一部分。真正的目标是构建一个可以解决非常有意思问题的总体系统。这个系统里的模型要会使用工具，可能会检索相关信息，可能保留过去解决问题时检索过的信息历史，再把这些内容放进当前模型的 context。

这有一个很大的好处：context 里的信息对模型非常清楚。相比之下，训练数据是数万亿 token 被搅在一起，最后进入数千亿、甚至数万亿参数的一锅“汤”里。那种信息没有“这个问题此刻直接放进上下文里的信息”那么清楚。

接下来，模型还需要理解有哪些工具可用；下一阶段应该用什么工具；怎样把一个问题分解成一串 tool calls；是否应该同时尝试多条路径，然后评估哪条有效。这就是复杂 agent 系统、多 agent 系统的 orchestration。我觉得它会越来越重要，而且现在正是非常令人兴奋的时候。

这个方向有趣的一点是，现场几乎每个人都能做。以前训练模型需要惊人的资源、GPU 和数据；但 context engineering 不一样，你有 Gemini 之类模型的 API，就能自己做 retrieval、tool calls 等等。那大家怎样才能真正变得擅长 context engineering？

一个很好的办法就是直接拿这些模型、harness 和工具去解决真实问题，然后观察它在哪里失败。很多时候，你无法从外部直接改模型参数，但你可以给模型更好的指导原则，可以给它写 skills，让它知道某类问题应该怎样使用不同工具。

这样做下去，你会进入一种“让整个解题 setup 自我改进”的循环。你会越来越清楚：为了让模型更有能力，它真正还需要什么额外信息。

你能不能举一个自己做过的 context engineering 例子？比如你写过什么 skill、什么工具，真的显著改变了工作流？

几周前，我和 Sanjay 在做一些很底层 library 的性能改进。Google 内部有一套我们写的 microbenchmark library，可以测不同操作要多久，比如填充某个数据结构要多久。有些数据结构会在 Google 数百万个进程上使用，所以把它们做得高性能其实很重要。

没有 agent 系统的时候，典型流程是：先跑你关心的 benchmark，测当前性能；然后改代码，希望性能提高；再跑 benchmark，看哪里变快；也许再跑一套更广的 benchmark；再看看 cache footprint 等等。

我们后来写了一个 skill，基本上把人会采取的这些步骤、以及不同情况下该以什么顺序采取这些步骤，教给模型。这样模型就能自己做一个循环：测 benchmark → 修改代码 → 再测性能改进 → 继续迭代。对一些问题来说，这个方法效果相当好。它本质上没有什么神秘的，就是把“我们作为人会怎么做”用模型可以使用的形式交给模型。

这太夸张了。所以如果别人拿到这个 skill，他就能像 Jeff Dean 一样做性能优化？这听起来值无限的钱。

其实我们几个月前已经公开了一份文档，叫 *Performance Hints*。那是一份我和 Sanjay 写的、大概 30 页的文档，讲各种性能优化技巧。已经有人把它整理成摘要交给不同模型，发现模型确实会因此更擅长推理代码里的性能问题。

所以大家听到了：拿这份 *Performance Hints*，就能让自己的模型更像 Jeff Dean 一样优化代码。

对，而且它完全免费、公开可用，大家都应该试试。

很酷。

说到 agent，现场应该几乎每个人都造过一个。大家也都看过 agent 到第 30、40 步突然跑偏：前 10 步可能很好，到第 50 步就开始摇摇欲坠。今天真正的约束是什么？context？evaluator？还是因为这是一个近似 open-loop 的系统，错误会不断累积？

我们当然希望 agent 能运行非常长的时间，因为只有这样它们才能解决越来越复杂的问题。但你说得对，今天它们有时在和工具交互 10 次左右之后就会停止正常工作。

一个原因是，模型可能正在尝试自己并没有太多经验的事情。它在一批分布上训练过，但只要稍微偏离它熟悉的数据分布，就和多数机器学习模型一样，性能会开始下降。你离它的“舒适区”越远，越容易出问题。

有几种办法。第一，给模型 skills 和 hints，让它尽量留在自己知道怎么走的“灯光更亮的路径”上。第二，构建 multi-agent 系统，让多个 agent 尝试不同解法，再用另一个模型或另一个 agent 去评估哪些路线看起来最有希望。

这相当于在可能解法的空间里做搜索：保留更有希望的路线，丢掉那些不工作、或者已经跑偏的路线。更一般地说，就是在 inference time 花额外 compute 去搜索可能的解法。这样可以显著提高长时 agent flow 的性能和可靠性。

你们内部具体怎样实现这种工作流？

我们有 harness，也有一整套 skills，尤其是在 Google 内部开发环境里。我们会让 agent 学会使用内部的编码工具、code review 工具、性能测量工具、日志抓取工具等等。

即使基础模型并没有在“Google 工程师究竟怎样从某个专有系统拉日志”这件事上受过训练，只要 skill definition 写得对，它也能学会正确地做。这样就能提高 agent 的实用性。

接下来聊聊创业公司还能赢在哪里。Google 从处理器到产品都在做 co-design。像 Google 这样的公司会继续在哪些层面投入、持续复利？反过来，一个两三人的团队还可以在哪些地方赢？

Google、Gemini 模型以及我们的硬件基础设施，目标当然是构建非常通用、几乎什么都能做的模型。但恰恰因为目标这么通用，我们不一定会把大量注意力放到每一个具体垂直领域。

某个小团队如果能为特定领域做出设计非常好的产品界面，再配上一组 skills、一个模型，甚至一个专门模型，而这个领域又不在通用模型最擅长的能力组合里，就可能拥有明显优势。你可以在自己真正热爱的垂直领域里，把东西做得非常好用、准确率很高、质量很高。两三个人在一个房间里，就可能靠这种专注获得优势。

不过我也要提醒大家：通用模型正在越来越多的事情上变好。所以你得问，这个优势是否持久？前沿模型会不会在未来 6 个月或 12 个月里就把它吃掉？还是说这是它们两三年都做不到的事？选择问题时，你必须把这个时间尺度算进去。

那创始人怎样判断应该选什么问题？

第一，也是最重要的一条：选一个你自己非常兴奋、真的想构建、而且你认为对世界有用的东西。只要满足这一点，你就已经远远好过每天醒来都觉得“我其实不太想做这个”，或者造出来的东西对世界、对大多数人都没什么用。

第二，看当前更通用的模型在这个问题域到底能做什么。你可以直接测试：它做得好吗？如果它完全失败，那通常是个好信号。如果它已经能做一部分，只是做得还不够好，反而未必是好信号——那可能意味着能力已经开始出现在模型里，只要再加训练数据、扩大模型规模，或者做其他改进，它很可能很快就会变强。

如果通用模型在一个任务上已经能做到 20%，那可能不是好信号；我会找它只成功 0% 或 1% 的问题。

这种问题怎么找？它们本质上是训练集之外的 out-of-distribution 问题吗？具体什么样的问题形态最合适？

有一种情况是，你做的产品能够访问通用模型本身拿不到的特殊数据。比如你帮助用户整理他们自己的全部个人信息，通用模型天然不一定能看到这些数据。那你的产品一下子就对重要数据拥有了可见性，这会带来很大的优势。

另一种情况是某个问题本身极其困难，但你能拿到正确的训练数据，于是可以训练一个比通用模型更专门的模型。这个 niche model 未必需要很多 compute，训练成本也可能负担得起，但它在特定问题上可以做到很高的准确率。这种东西可以成为解决“通用模型目前做不好”的重要问题的一个非常好的 building block。

这听起来基本有两条路。第一条有点好笑：Google 已经在“组织全世界的信息”。

对，这部分大概覆盖得挺好了。（笑）

但“组织你自己的个人信息”仍然是开放的，这就很有意思。

对。

第二条就是你说的某些领域的专门模型。能不能举几个具体领域？

看我同事们做的 AlphaFold 就是一个很好的例子。它是非常特定的蛋白质折叠模型，而且非常成功。突然之间，你有了一个惊人的工具，可以非常有效地回答关于蛋白质及其结构的问题。但它不是通用模型，而是高度专门的模型。

还有其他领域也可能适合这种方式，比如材料科学、芯片设计等等。你可以利用一个准确率非常高但很 niche 的模型，去做今天仍然很难的事。

假设大家已经找到了类似 AlphaFold 这种形态的问题。下一步，怎样成为真正的 AI-native founder？你以前说过，管理一支 50 个、甚至 100 个 agent 的 fleet，关键在于写出非常好、非常清晰的 design doc 或 spec。大家怎样才能学会？

当你和“虚拟 agent”协作时，如果能非常清楚地说明自己究竟想要什么，你会成功得多。你越清楚，agent 就越有明确的指导原则、规则和目标轮廓。反过来，如果你几乎没有写清楚，它只能自己猜你的意思，而它猜出来的东西经常和你脑子里想的不同。

我们从计算机科学一开始就告诉学生：真正写软件之前，先明确你写的软件到底要完成什么。今天 agent-based 系统已经可以帮你把代码写出来，但“明确说明你要什么”反而变得更重要了。过去你把任务交给一个非常聪明的人类，对方可能有很多背景信息，也可以追问；agent 有时也能追问，但清晰的 specification 仍然非常重要。

一个今天 coding agent 做得特别好的例子，是把软件从一种语言翻译到另一种语言。原因是这个任务天然有一份极其详细的 specification——原软件本身就完整描述了系统应该做什么。

比如你有一个 Python 实现，想得到一个 Go 实现。模型可以把 Python 里的测试也拿过去，确保 Go 版本通过；把测试翻译成 Go；比较两个实现的行为差异，直到差异消失。它之所以能做得这么好，很大程度上就是因为 spec 太清楚了。

假设以后每个创始人都能同时运行几百个 agent，代码也全部由 agent 写。那什么会变成真正稀缺的能力？

是“品味”——你究竟让 agent 去做什么。对我这种研究背景的人来说，这一直是研究的核心。研究者可以掌握所有工具、所有技术，但很多时候真正的战斗是：你要把时间花在哪一个问题上？

如果你选对问题并把它解决了，这远胜过把一个很无聊的问题研究得无比漂亮。那种“应该做什么”的高层判断非常重要，而且我并不确定模型会特别擅长这一点。未来会是人来掌舵，让大量 AI-assisted computation 更快完成伟大的事情；但“你到底想让模型做什么”仍然是最需要你自己关注的核心。

现在大家都在谈 agent coding 时代的 taste。可“品味”听起来很玄，它到底怎样变得具体？

这确实很难。很多时候，“品味”根本没有一个可直接度量的 objective。我觉得一部分来自经验：你过去解决过很多不同问题，就会逐渐知道什么样的问题未来可能有意思；也会知道哪些东西只差一点点就能靠已有方法拼起来实现，以及为了达到某种近乎“魔法”、或者真正非常有用的效果，还缺哪些开放问题。

还有一个办法，是给自己制造更多训练样本。你可以把自己认为“未来 12 个月会变重要”的很多东西都写下来。你也许只会选其中一个真正去做，但 12 个月之后再回来检查：哪些判断真的重要了？哪些东西已经被世界上的其他人做出来了？哪些仍然没人做？

这种回看会给你自己的“品味生成器”更多样本。我觉得这是一项很重要的能力。

我们之前还聊过第三种方法：做非常疯狂的 thought experiment。

对，这也是一种很好的方式。有时候，不要把“几乎所有人都认为理所当然的东西”真的当成理所当然。

前几天我和同事就在做一个很疯狂的思想实验。过去大约 60 年，整个硅芯片设计与制造行业都在努力把晶体管做得越来越小、错误率越来越低。一个隐含假设是：同一种设计制造出来的每一块芯片，都应该和其他芯片行为一致。

也就是说，你不想看到任何 bit flip。

对，不希望任何 bit 翻转。所以系统里有很多 error margin，今天内存也会用 ECC。但有意思的是，在宏观的大规模分布式系统里，我们并不要求每个部件永远可靠。我们会用“不可靠的部件”构建“可靠的分布式文件系统”：单个磁盘可以坏，但数据不能丢。

所以我们在更高一层做机制。比如把同一份数据放三份，分散在三台不同机器、三个不同机架里。这样某个 rack switch、机器或者磁盘坏掉，你仍然有数据。我们也会用 Reed-Solomon 一类编码技术。

但在晶体管这一极端微观尺度上，我们似乎没有把这种思维推到同样激进的程度。一个有意思的 thought experiment 是：如果你故意用那种一天可能发生 20 次错误的晶体管来造系统，会发生什么？

天啊。

对，不是“每一百万年才错一次”，而是“一天错 20 次”。那会是一个完全不同的 design point，也许会让制造方法发生非常有意思的变化。比如如果你要把信号从这里送到那里，而晶体管非常不可靠，你可能会采用完全不同的信号传输方式；你也许会沿多条冗余路径同时发送，确保至少有一条能到达。

我觉得这是一组很有意思的思想实验。我不是说我们现在就应该真的去这样造芯片；我的意思是，你应该偶尔主动质疑这些假设。当然，这类思想实验经常最后不成立，因为过去 50 年我们用某种方法而不是另一种方法，往往确实有很好的理由。但每隔一段时间重新检查它们，仍然很有价值。

这太疯狂了，而且听起来越来越像 neuromorphic computing、像人脑、像自然本身工作的方式。

没错。人脑里的信号从一个地方传到另一个地方，其实并没有特别可靠。所以当某个信息真的很重要，大脑里往往有多条路径，让它能够到达目标。

你职业生涯里有没有一个类似例子：你真的把某个大家默认的疯狂假设扔掉，结果造出了一个重要系统？

TPU 就是一个例子：在那个问题域还没有像今天这么重要之前，我们就相信“可以针对一个相对 niche 的问题域做专门硬件”。另外，MapReduce 的起源也是一个很好的例子。

我和 Sanjay 以及其他一些同事，做过 Google 爬虫与索引系统的很多代实现。我们写了大量手工并行化的代码，也放了很多 checkpointing，确保程序跑在 100 台、甚至 1,000 台机器上时，即便其中有机器死掉，系统仍然可靠。

问题是，这些并行化、容错代码会和你真正想完成的那件简单事情混在一起。比如你其实只是想扫描所有网页内容，然后得到一个“URL → 这个网页是什么语言、页面文本是什么”的映射；结果真正的业务逻辑反而被大量并行化与可靠性代码淹没。

我们想起了自己在函数式语言方面受过的训练，于是换一个角度看这些问题，发展出了 MapReduce 这个抽象。上层只暴露问题本身的 map/reduce 形式；下层 library 则负责 checkpointing、可靠性等所有机制。这样所有系统都可以在这个底层之上构建。

最后，它成了 Google 处理超大规模计算的一种非常成功、稳健而可靠的方式。这个 thought experiment 的核心就是：如果我们换个角度看，能不能发现很多问题其实都能塞进同一个抽象里？

很厉害。所以正是这种思想实验，最终带你们做出了 MapReduce。

对。

回到你最近很感兴趣的定制硬件。现在 AlphaChip 可以做芯片布局，AlphaEvolve 会提出候选解、评估它们，并保留有效的解。听起来，你们正在把这些系统组合起来，开始构建“会构建 AI 的 AI”。

更一般地说，这就是科学方法的基本循环：提出一个实验，准备运行实验所需的东西，执行并评估实验，然后拿到结果。现在越来越多问题可以把这整套循环自动化，而且不是只跑几个实验，而是跑很多很多实验；最关键的是把这个循环的 latency 压得非常低。

这会让我们能更快推进很多科学、工程和机器学习问题，包括模型设计本身，也包括芯片设计这类工程任务。

如果你有一个 orchestration framework，可以接收很高层的目标，把它拆成很多子问题；每个子问题又交给一个自动实验循环去搜索最佳解；最后 orchestration framework 再把这些子问题的解组合成更高层问题的整体解，那会非常有影响力。我觉得它会加速机器学习、科学和工程的进展。

这听起来尤其适合那些 evaluator 很好、甚至接近 formal verification 的领域，因为系统可以不断自我改进。

对。不过很多时候，你还需要把 evaluator 本身做得快很多。

举个例子。大概十年前，我的同事做过量子化学问题：给定某种分子构型，你想知道它的性质。你可以运行计算量非常大的 density functional theory simulator，但一次模拟可能要整整一个晚上，才告诉你一个候选的答案。

他们把大量这种昂贵模拟的输入分子构型和输出结果收集起来，用它们训练了一个对模拟器的神经网络近似。于是你得到一个新的 validation device：不再需要跑一整晚，而且速度大约快了 300,000 倍。

哇。

而且它和完整模拟器几乎一样准确。这会完全改变你做科学的方式。假设你有 1,000 万个候选要筛选，以前这可能是一个耗时 6 个月、还要到处凑 compute 的项目；现在也许你去吃个午饭，它就筛完了。

我觉得很多领域都还有空间去做更快的 validation model，可能是 learned validation model，用非常快的方式给你接近真实答案的近似。这会改变你怎样设计实验循环，也会改变你能以多快速度跑完一轮循环。

这种“被极度加速的科学方法”，你最希望它先解决哪些问题？

机器学习本身显然就是一个。我们能不能让模型通过大量实验递归地自我改进？今天大型研究团队改进模型，通常是人先想出一些点子，跑一批小规模实验；如果小实验表现好，就挑最有希望的扩大规模；再评估结果，最后把不同结果整合进一份新的模型 recipe。

我看不出有什么根本障碍，阻止我们把这个过程做成更自动的循环。模型自己可以决定探索什么；人也许只在最高层轻轻推一把，比如说“为什么不试试包含某个机制的新架构”。然后模型就去跑大量实验，看看哪些有效，再以更快速度把成功的东西纳入下一版。最终，你真正想优化的是“每单位 compute 投入能产生多少 discovery”。

很酷。回到现场。你们以后无论创业还是开始职业生涯，都会收集很多拒绝。Jeff，你也被拒过。2014 年，你和 Geoffrey Hinton、Oriol Vinyals 做了关于 distillation 的工作：用一个大 teacher model 去训练一个更小、更高效、参数更少、推理更便宜的模型；现在这已经是整个行业都在用的技巧。

但那篇工作当时被一个会议拒了。

对。我其实并不怪 program committee。论文往往会拿到三份 review，其中一位 reviewer 可能看完后说——这次对方就说了——“不太可能产生重大影响”。

“不太可能产生重大影响。”

但我们写那篇工作的时候，认为它解决的是一个非常重要的问题。因为我们迫切需要把大型模型的能力变成更便宜、仍然很有能力的小模型，这样才能把模型服务给更多人，覆盖语音、视觉等很多不同领域。

reviewer 当时可能没有这类经验，也许没有在思考大规模 AI service，而更关心它是不是某种“基础性推进”。所以论文偶尔被拒就被拒了，没什么。我们把它放到 arXiv 上，大家去读、去用，一切都挺好。

而且今天我们确实会用类似方法，从更大规模的 Pro 模型得到 Flash 模型。这也是为什么 Gemini 的 Flash 模型相对于自己的体量和速度，可以这么有能力。

它们在自己这个模型尺寸级别的 benchmark 上，确实是最好的模型之一。所以一个教训就是：哪怕被拒了，也继续做。

对，这就是我会从这个故事里“蒸馏（distill）”出来的教训。（笑）

你 1999 年加入 Google 时，它大概还是一家 20 人的 startup。假设把当年那个年轻的 Jeff Dean 传送到今天——拥有你现在这些技能，但又回到 25 岁——你会去 frontier lab，还是自己创业？

（笑）我突然觉得自己很有活力、很年轻了。

很难说。这是一个非常个人化的选择，取决于你究竟想把时间花在哪里。对我来说，几个最重要的问题是：你要做的是不是自己真的在乎的事？你和一群自己喜欢共事的人一起推进它，最后如果真的把它解决了，会不会以某种积极方式改变世界？

也许你做出的服务能帮助生物化学家；也许影响更广，能帮助程序员，或者帮助互联网上的所有消费者。你应该努力让自己的工作对世界产生正面影响，和你喜欢的人一起工作，同时认真投入、尽自己最大努力。

至于你提的 frontier lab 和“一两个、两三个好朋友一起创业”的取舍，它们是很不同的体验。在成熟的大组织里，你有结构，有很多懂得你不知道的东西的出色同事，也有很多有趣问题；而且已经有一个巨大的平台，让你的工作可以影响世界上很多人。

在很小的 startup 里，你必须对某个问题真正有热情，而且风险会更高。你得赌自己能把那个问题做成，还要把整个事业一点点长起来。但如果成功，它也可能带来极大的回报和满足感。

所以最后还是个人选择。但无论走哪条路，我至少会问自己：如果我做这个问题，而且最好的可能结果真的发生了，世界会不会因此明显变好？如果世界最后只会说“嗯，挺酷的，不过也就那样”，那就不太值得你把时间花在上面。

那我们再谈谈另一条路：和自己真的喜欢的人组成小团队。你带过很多工程师，也造过非常大的系统。怎样找到聪明的人、怎样和他们一起工作，才能把团队的潜力发挥出来？

你当然要找在团队所需领域拥有真正好技能的人，无论是在公司内部组队，还是一起创业。但你也应该找那些“你真的很喜欢和他待在一起”的人，因为大家会一起花很多时间解决非常困难的问题。

我喜欢低 ego、真正是 team player、并且技能和我互补的人。我一直觉得，小团队最好玩的状态就是：别人知道我不知道的东西，而我也有他们没那么擅长的技能。这样大家可以共同造出任何一个人单独都未必能完成的东西。

更重要的是，在合作过程中，每个人都会学到新知识、新技能。你可以把自己的工程或研究职业生涯想象成一条装满技术的 tool belt；你应该一直往里面加新工具。因为你永远不知道未来某个问题恰好需要“这四个专门工具”，而不是你原来手里的那三个。工具越多，你未来遇到的问题就越可能在自己的可解范围内。

最后一个问题。现场也许有一个人、或者几个人，未来会做出像 MapReduce、TPU、distillation 一样重要的东西。你希望他们去解决什么问题？

世界上有很多有意思的问题，我随便列几个，这绝对不是完整清单。首先，我对新的硬件方法很兴奋——刚才那个关于不可靠晶体管的 thought experiment 就是一个提示；更高效的推理硬件也很重要。

我也觉得，机器学习可能还存在和今天完全不同、数据效率高得多的算法。今天的大规模模型，可能看到的训练数据量是一个人到 18 岁为止所接触数据的 1,000 倍左右；但一个 18 岁的人类在很多事情上仍然更好，在另一些事情上也至少能和这些看过远多得多数据的前沿模型相当。

所以，能不能做出数据效率高得多的系统？能不能持续学习，并且从自己的行动里继续学习？continual learning 很有意思；multi-agent interaction 也很有意思。

还有一些看起来不那么“纯技术”的问题也很值得做。比如，能不能让世界上的人有更好的公共讨论、更文明的对话？能不能根据人的兴趣，帮助他们遇到世界上那些“其实彼此应该认识”的人？我觉得这些也都非常有意思。

世界上还有很多很酷的事情。我们都应该努力，让更酷的事情发生。

太好了。非常感谢你，Jeff Dean。今天就到这里。

谢谢，也感谢大家。