谷歌首席科学家Jeff Dean：数据搬运比计算贵 1000 倍，大模型推理该换芯片了

Google首席科学家Jeff Dean近日在YC Startup School 2026上，分享了他对AI现状与未来机会的核心判断。

作为Google早期核心成员，Jeff Dean参与创建了MapReduce、Bigtable、TensorFlow，主导了TPU的研发，并领导了Gemini等大模型的开发。他的每一次公开讲话，几乎都值得AI从业者和创始人反复咀嚼。

这次也不例外。

他给出了几个值得深思的判断：AI模型已真正达到初级工程师水平；AI代理将从运行几小时扩展到运行数周；AI效率的本质是能耗问题——数据搬运的能耗是计算本身的1000倍；推理硬件专用化是下一波效率提升的关键；创始人应寻找大模型完全失效（0%-1%成功率）的领域，而非部分胜任的领域；而未来最稀缺的能力，将是“品味”——判断什么问题值得解决。

本文编译自YC最新一期博客内容，原文链接：https://www.youtube.com/watch?v=CxXgV54KzpQ，以下是完整编译。

1

AI的自进化时代

主持人： Jeff，欢迎你，也再次感谢你来到这里。你做过MapReduce、Bigtable、TensorFlow、TPU、Gemini。光讲你做过的这些事，我们就能聊一个小时。但我特别喜欢的一点是，你到现在还会公开做大胆预测。去年，也就是2025年5月，在AI Ascent上，你说AI已经到了“初级工程师”的水平。那已经是一年前了。现在回头看，你觉得这个判断离现实还有多远？

Jeff Dean： 我觉得模型在那种基于agent、运行时间更长的编程任务上，能力提升得非常快。现在看起来很明显，它们已经相当能干了。具体要看你怎么定义“初级工程师”，但如果按一般意义来讲，我会说这个判断基本是说中了。

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

Jeff Dean： 我觉得我低估了它们处理越来越复杂任务的速度，这个增长比我想得更快。另外我也觉得，不只是写代码，agent型系统在其他领域也开始真正发光了。我认为这会是未来一个很重要的趋势。

主持人： 那你再来一个大胆预测吧。你觉得2027版的判断会是什么？

Jeff Dean： 我觉得你会看到更多机器学习系统本身的自动化。也就是让ML系统通过自己跑大量实验、把问题拆成子问题、让这些子问题进入紧密的自动实验循环，再把结果拼起来，从而提升自己的能力。我觉得这种“全自动问题分解+自动实验”的方式会非常令人兴奋。而且我认为，这不只适用于机器学习，也适用于其他科学和工程领域。基本上，凡是你能定义一个可衡量目标的地方，我觉得如今都可能取得非常大的进展。

主持人： 我们回到历史里看一眼。早在2001年，Google搜索还是跑在硬盘上的。你和Sanjay算了一笔账，意识到总有一天，整个搜索索引会装进你们所有机器的RAM里。然后你们就在几天内上线了一个全新的、跑在内存而不是硬盘上的搜索版本，那基本就是Google搜索变快的关键转折点。历史总是会押韵。那如果放到2026年，现在这个“终于能全放进内存里”的时刻是什么？现场这6000个人，今天应该盯着什么来设计？

Jeff Dean： 情况不完全一样，但我觉得你会看到越来越多高性能、低能耗的推理硬件系统。因为现在大家都在意识到，推理才是让这些agent型系统能服务更多人的关键，而且延迟非常重要。还有一点，硬件的专用化，是让系统变得比通用计算设备——比如GPU或TPU——更节能、更低延迟的关键路径。我觉得在座所有人都已经习惯了等模型回结果，但等待并不好玩，速度才是王道。

主持人： 你的意思是说，如果我们根本不用等了呢？

Jeff Dean： 对。你可以想象一下，如果延迟能好50倍，会发生什么。

主持人： 很有意思。那现在这个房间里可能有6000个人都还默认相信、但其实已经错了的一个AI假设是什么？

Jeff Dean： 这是个好问题。我觉得有一件事是，大家还没有真正意识到，让agent型系统不是只跑一小时、两小时，而是针对某些问题，借助能力足够强的底层模型，让它连续跑几天甚至几周，其实已经是可能的了，而且还能处理非常非常复杂的任务。有些人已经看见一点苗头了，但我觉得还不是所有人都真正把这件事内化进去。而这会是一件非常大的事。

主持人： 你们真的有那种能跑几周的任务吗？具体是什么？你让agent去解什么题？

Jeff Dean： 你可以让agent去实现某个软件的全新版本，比如换一种编程语言去重写，而且那种新版本可能有更好的安全性，或者更好的性能。然后它们真的可以比较认真地把这件事做下去。

1

TPU的起点，其实只是Jeff Dean算了一笔“餐巾纸数学”

主持人： 说到这个，你特别出名的一件事，就是你很擅长“餐巾纸数学”。有个很经典的故事：2013年左右，当Google的语音识别开始真正变得可用时，你算了一笔账——如果每个Google用户每天只是在手机上用3分钟语音识别，Google整个服务器集群都得翻倍，这会贵得离谱。于是你们最后造了一颗定制芯片，这也成了TPU的起源故事。

Jeff Dean： 是的。那时候我们开始看到基于深度学习的语音系统确实能做出非常好的质量。跟旧的语音系统比，它们算力成本高很多，但错误率却减半了。那几乎相当于在短短几个月里，就拿到了过去20年语音识别进步的总和：调一调模型、稍微扩一下规模、喂更好的数据，效果就出来了。

所以我们开始担心，如果语音真的变好，人们就会用得更多。那笔粗略的计算，本质上就是在问：如果大家开始更多地用语音来写邮件、跟手机讲话之类的，会怎样？结果我们发现，继续跑在CPU上不行了，于是就做了TPU。TPU本质上是一种非常专门为低精度、密集线性代数而设计的芯片，而这恰恰是几乎所有现代机器学习算法的核心。如果你专门为低精度密集线性代数造一颗芯片，而它别的什么都不会——比如它跑不了Chrome，也跑不了Word——那它在机器学习推理上会特别有用。最终我们做出来的那一代芯片，在当时相较CPU和GPU，能效高了30到80倍，延迟也低了20到30倍。这是一个非常惊人的基础，后来TPU才演化成今天这个样子。

主持人： 但在你发明TPU的时候，Transformer甚至都还没出来。你肯定也没法预料，TPU后来会变得这么基础。

Jeff Dean： 是的，所以我们当时造的是一个通用线性代数系统，这其实才是TPU的本质。因为我们知道，机器学习算法还会继续演化。你不能把硬件做得过度专用，但又得专用到足以拿到巨大的性能提升。比如我们可以做非常大的乘法单元，可以做高速内存，可以做高速互连。后来几代TPU还能让很多很多芯片高效协同处理同一个问题。我们已经持续很多代去扩展它们、提升它们的性能。

主持人： 所以，什么样的“餐巾纸数学”，是今天所有想创业的人今晚都该去算一算的？有没有可能算出下一个像TPU这么重要的东西？

Jeff Dean： 这个很难一概而论。但我觉得，你应该先去看你所在领域的问题是什么、瓶颈是什么。然后问自己：有没有一种跟今天完全不同的解法，能让这个问题在性能、能力或者别的关键指标上，提升一个数量级，甚至两个数量级？因为很多时候，如果你能“换个角度”重新看这个问题，不要被当下主流解法锁死，而是从第一性原理想：如果让我从头解决它，我会怎么做？这时候你往往能想到很好的点子，而这些点子，可能根本不是别人正在想的方向。

主持人： 很多人可能不知道，多年前你写过一份非常著名的清单，叫《每个工程师都该知道的延迟数字》。比如cache miss要多久、磁盘seek要多久、一个网络包从加州跑到荷兰要多久。这份东西后来几乎成了很多分布式系统工程师的“圣经”。现在快进到2026年，如果这份清单要更新成AI版，它该包括什么？

Jeff Dean： 如果你看今天AI系统里什么最重要，那你就会想知道：主存到加速器片上内存之间的带宽是多少，到乘法单元的带宽是多少；做一次乘法运算要多少能量；芯片之间互连带宽是多少；在这个带宽条件下你能连多少颗芯片。再往外推一步，如果你从500颗芯片扩展到10000颗芯片，网络带宽会怎样衰减？这些数字都非常重要，而且会真正影响你怎么思考某类问题的解法。

主持人： 我还听你讲过一件事挺有意思：现在很多东西最后都用“能量”来度量。

Jeff Dean： 对。

主持人： 你提过，做一次计算，大概只要1 pico级别的能量；但搬一次数据、做一次数据IO，成本是它的1000倍。

Jeff Dean： 没错。哪怕只是把数据从加速器上的高带宽内存搬进处理器，让它真正参与计算，能量代价也要高得多。

主持人： 这个差距其实悄悄决定了什么产品能成立，也决定了AI算法怎么设计。那你觉得，创业者经常误以为是“模型问题”，但其实实际上是“能耗问题”或者“数据IO问题”的典型场景有哪些？

Jeff Dean： 你刚才说的这个例子——搬数据比实际计算贵1000倍——就非常关键，它塑造了机器学习里很多事情的做法。因为如果没有这个1000倍差距，你其实不需要把数据打包处理；但正因为有，所以你必须把很多样本、或者很多token一次性攒成一批再处理，去摊薄数据搬运的成本。这样你付出的就不再是1000倍的能耗惩罚，而是“1000除以这一批的数据量”。但如果你想做极低延迟，打包处理其实并不是好办法。所以我觉得，底层硬件里的这些能量约束，会非常深地影响我们在更高层系统上的很多选择。

主持人： 一个特别具体的例子就是模型训练。今天大家说训练，会说要把数据分批打包、要跑多轮迭代，这些听起来像是模型层面的概念，但其实本质上是系统和数据IO问题，对吗？

Jeff Dean： 对。你必须把数据攒成一批来处理，才能让硬件利用率更高。理想情况下你也许想一次只处理一条数据就做更新，但在效率上并不好，所以今天大家会用很大的批次。

主持人： 那有没有可能，Jeff找个周末，闭关想几周，把“一次处理一条数据”的训练搞定？

Jeff Dean： 我最近其实更多在想推理问题。因为推理很有意思，它确实需要非常低延迟；训练倒不一定非得极低延迟。我觉得，在推理硬件上，我们现在还远远没有做到足够专用化。

主持人： 那你最近在推理硬件上具体在想什么？

Jeff Dean： 核心就是尽量减少数据搬运；再就是思考极低精度的运算；也许不用支持那么多不同的精度。如果你已经比较清楚，哪些精度才是真的需要的，那你完全可以把它们直接硬编码进硬件里，别的就不要了。

主持人： 这让我想到一个很核心的类比：有位著名计算机科学家说，整个AI过程本质上就是一个大的压缩问题。因为想把数据高度有损压缩之后再恢复出来，你本质上得理解它。

Jeff Dean： 是的，如果你真的理解数据，你就应该能把它压得很好。而Transformer架构，其实就是目前被证明效果很好的方法之一。

主持人： 现在看来，这条路确实跑得不错。

Jeff Dean： 至少目前看，是挺不错的。要感谢我同事们做的好工作。

1

别只盯着模型了，下一步该卷“上下文”

主持人： 我们把视角再拉高一点。以前大家说AI进步，意思基本就是模型更好了：更多数据、更大参数、训练更久。但最近这些年，越来越重要的其实是模型周围的一切——不只是参数规模或者训练数据，还有检索工具、memory、agent工具等等。某种程度上，这些都可以被统称为“上下文工程”，对吧？

Jeff Dean： 对。我觉得模型只是你要构建的整个系统中的一部分。真正的目标，是构建一个能解决有意思问题的完整系统。这意味着：模型要会使用各种工具，可能还要会检索相关信息，可能还要有过去为别的问题拿到过的信息历史，并且能把这些信息放进当前模型的上下文里。这里有个好处是，这类信息对模型来说是很清晰的。因为训练数据其实像是一锅“大杂烩”——几万亿token被搅在一起，最后揉进几千亿甚至上万亿参数里。相比之下，模型在当前问题里直接看到的上下文，要清晰得多。

此外，模型还得理解有哪些工具可用，哪些工具对解决当前这一步有帮助，怎么把一个问题拆成一连串工具调用，甚至尝试多种不同方法去解同一个问题，并评估哪种方法有效。这其实就是复杂agent系统、多agent系统的编排能力。我觉得这会变得越来越重要，也会非常令人兴奋。

主持人： 这个领域好玩的地方在于，房间里所有人其实都能做。以前你要训练一个模型，需要巨量资源、GPU和数据；但做上下文工程，大家只需要一个像Gemini这样的API，再加上自己的检索、工具调用和工作流搭建，就能开始做。

主持人： 那对于大家来说，怎么才能把上下文工程做得更好、做到特别强？

Jeff Dean： 一个非常好的方法，就是实际用这些模型、这些工具链、这些harness去解问题。然后你往往会看见模型在哪里出错。很多时候，让模型表现更好的办法，不是从外部去调模型参数——那很难——而是去给它更好的指导，比如写出更好的guideline，写出更好的skill，让它知道某一类问题该怎么调工具。随着你不断这么做，你会进入一种“自我改进setup”的状态。你会越来越理解：模型到底还需要什么额外信息，才能变得更强。

主持人： 你能不能举个你自己实际做过的上下文工程例子？比如你写过什么skill、什么工具，真的显著改变了你的工作流？

Jeff Dean： 可以。几周前我和Sanjay还在一起做一些非常底层库的性能优化。我们在Google内部有一个自己写的microbenchmark库，可以测很多不同操作到底要多久，比如填充某个数据结构要多长时间之类。有些数据结构会被Google里几百万个进程使用，所以保证它们足够高性能是非常重要的。

以前如果没有agent系统，你的做法一般是：先测当前性能；然后改代码，希望它更快；再重跑benchmark，看哪里改善了；然后可能还要跑更广的一组benchmark，测cache footprint等等。所以我们写了一个skill，本质上就是教模型怎么在不同步骤顺序里完成这些事情：测benchmark、改代码、重新测性能、看是否变好、继续迭代。这个方法对某些问题表现得相当不错。说白了，我们只是把人类自己会用那套方法，转写成模型能用的形式而已。

主持人： 这听上去很厉害。也就是说，你们其实有一个skill，可以让别人像Jeff Dean一样做性能优化？如果有人拿到它，感觉都值无限多的钱了。

Jeff Dean： 其实我们几个月前公开发过一个文档，叫《Performance Hints》，是我和Sanjay写的，大概30页，讲了很多性能优化技巧。已经有人把这份文档总结之后喂给不同模型，结果发现模型在推理代码性能问题这件事上，确实变强了。

主持人： 所以大家都听到了：如果你拿到Jeff和Sanjay发的这份《Performance Hints》，你就有机会让模型像Jeff Dean那样帮你优化代码。

Jeff Dean： 对，都是公开免费的，大家都可以试试。

主持人： 既然你在谈agent，在座所有人应该都做过或者至少试过做agent。大家肯定都见过一种情况：agent在前10步挺好，到了第30步、第40步，甚至第50步就开始跑偏。你觉得现在的主要约束是什么？是上下文、评估器，还是因为错误在开环系统里会不断累积？

Jeff Dean： 我们当然希望agent能连续运行很长时间，因为这是它们解决越来越复杂问题的前提。但像你说的，今天它们确实常常在10次左右工具交互后就不太行了。有时候这是因为，模型正在尝试一件它没有太多经验的事。它训练时见过一大堆分布内任务，但只要你稍微走出它熟悉的分布，像大多数机器学习模型一样，它的表现就会开始下降。离它“舒适区”越远，它越容易失效。所以可以做几件事。第一，给模型skill和hint，把它尽量留在那条它更熟悉、更有把握的路径上。第二，可以用多agent系统，让多个agent试不同方法，再让另一个模型或另一个agent去评估，哪些路径看起来更靠谱。这本质上是在搜索可能解法空间，然后保留更有希望的路径，丢掉那些跑偏或无效的路径。这是一种非常非常有用的通用技术：用推理时计算去搜索可行解法，从而让长链路agent流程更可靠、性能更高。

主持人： 那你们内部具体是怎么实现这套东西的？

Jeff Dean： 我们有各种harness，也有一整套skill，特别是在Google内部开发环境里。比如，agent会知道怎么调用内部编码工具、怎么做code review、怎么测性能、怎么抓日志文件等等。这些都只是一些skill。加上之后，底层模型就会变得更强，哪怕它原本并没有被训练过“Google内部工程师是如何从专有系统里抓日志”的精确做法。但只要skill定义得对，它就能工作，而且会显著提升agent的实用性。

主持人： 接下来聊聊创业公司还能赢在哪里。这个话题我自己也特别在意，因为在场所有人都要决定未来做什么。Google的特点是，你们几乎把整个系统每一层都共同设计了，从处理器一直到产品。那么，哪些层会持续被Google这种公司越做越强？而两三个人的小团队，还能在哪些地方赢？

Jeff Dean： 很显然，Google、Gemini模型和我们的硬件基础设施，都是在努力构建尽可能通用、几乎什么都能做的模型。但恰恰因为它们要做得很通用，很多时候我们不会对某个特别具体的领域投入足够多的注意力。所以，如果你能围绕某个特定领域，设计出一个非常好的产品界面，再配上一套模型和skill，甚至是一个更专门的模型——而不是通用模型里“顺手兼顾”的能力——你完全可能获得明显优势。因为你可以在自己真正热爱的领域里，做出一个让人愉悦、准确率又很高、质量也很高的产品。我觉得，这正是两三个人在一个房间里，做他们真正兴奋的东西时，可能拥有优势的地方。但我也要提醒一句：通用模型确实在变得越来越强，而且覆盖越来越广的任务。所以你得判断：你正在做的这个东西，到底是不是一个“耐打”的方向？前沿模型会不会在未来6个月、12个月里就把它做掉？还是说这件事它们两三年内都还做不到？这必须放进你的判断里。

主持人： 那我们把这个问题再往深里挖一点。你们当然会继续把通用模型越做越强。那创业者到底该怎么判断，什么方向值得做？

Jeff Dean： 最重要的，是挑一个你自己超级兴奋、非常想做，而且你觉得对世界有用的东西。如果做到这一点，你已经领先很多了。因为如果你每天醒来就觉得“我其实不太想做这个”，或者你要做的东西本身对世界帮助不大，那就不对。第二步，是你要去看今天的通用模型在这个问题上已经能做到什么程度。你可以自己测：它们是不是已经做得很好？如果它们完全失败，那通常是个好信号；如果它们已经能做一点，但还不太好，那反而未必是个好信号。因为这通常意味着能力已经开始出现了，只要再多一点训练数据、再大一点模型、再多一点规模，它就会继续变好。所以，你要找的是那种模型现在成功率只有0%或1%的事，而不是20%。

主持人： 那这类问题要怎么找？是不是本质上要找那些超出训练分布、类型不一样的问题？

Jeff Dean： 有时候是。有时也可能是你要做的产品，拥有某类底层通用模型没有的数据。比如你在做一个帮用户整理个人信息的产品，通用模型本身其实没有这些个人数据。那你的产品或你的模型就突然拥有了一个很大的优势，因为它能看见很重要的信息。还有一种情况，是某个非常难的问题。如果你能拿到正确的训练数据，训练一个更专门的模型，而不是通用模型，可能其实成本也没那么高，但精度会特别高。这有时会成为解决某个重要问题的非常好的一块积木，而通用模型在那个点上恰恰做得不够好。

主持人： 这挺有意思。基本上是两条路：第一条有点好笑，就是Google在“组织全世界的信息”，但“组织你自己的个人信息”这件事还没被彻底做完。

Jeff Dean： 对，这块大概还远没有被完全覆盖。

主持人： 第二条则是你刚才说的，在某些领域做更专门的模型。那你能不能多讲一点，哪些领域可能属于这种类型？

Jeff Dean： 比如你看我同事们做的AlphaFold，那就是一个高度专门、面向蛋白质折叠的模型，而且它极其成功。突然之间，你就拥有了一个非常惊人的工具和模型，能高效回答关于蛋白质及其结构的问题。但它不是通用模型，它是非常专门的。还有其他一些领域也可能适合类似路径，比如材料科学、芯片设计等等。在这些地方，一个非常准确、但很小众的专用模型，可以帮你做到今天很难做到的事情。

主持人： 假设大家真的找到了一个值得做的问题。接下来就来到另一个问题：一个人怎么成为AI Native的创始人？怎么真正擅长这件事？你以前说过，管理50个、100个agent，本质上很像写非常清晰、非常利落的设计文档和规格说明。那大家到底该怎么把这件事练好？好的规格到底长什么样？

Jeff Dean： 我觉得，和虚拟agent协作时，如果你能把你想要的东西说清楚，你会成功得多。你越清楚，agent就越有边界、越有规则、越知道自己到底要完成什么。反过来，如果你什么都不说明白，那agent就只能自己猜你的意图。很多时候，它猜出来的东西可能跟你脑子里想的不是一回事。其实从计算机科学很早开始，我们就一直在告诉程序员：在写软件之前，先把软件到底要完成什么说清楚，非常重要。现在只是换成了“agent帮你写”，但规格说明的重要性反而更高了。因为以前你是把任务交给一个非常聪明的人，他可能天然有上下文，也可能会反问你；而agent虽然有时也会追问，但总体上讲，清楚的规格仍然是非常好的做法。我举个现在特别有效的coding agent用法：把软件从一种编程语言翻译成另一种。今天的模型在这件事上做得非常好。原因不是神秘，而是因为这里的specification特别清楚——原始软件本身就是规格说明。比如你有一个Python实现，想要一个Go实现，这时模型很强，因为它可以拿Python里的所有测试，确保在Go版本里也能通过；还能把测试本身翻译成Go；还能不断比较两边的行为差异，直到不再有差异。正因为规格足够清晰，所以它在这类任务上表现得极其有效。

1

当Agent成为标配，最稀缺的能力反而变成了“品味”

主持人： 假设未来每个创始人都很会同时调度几百个agent，代码也都是agent写的。那最稀缺的能力会变成什么？

Jeff Dean： 我觉得会变成：你到底有没有非常好的“品味”，知道该让你的agent去解决什么问题。从我自己的研究背景看，这其实就是研究问题选择的核心。一个研究者可以拥有所有工具和技术，但大部分胜负其实发生在一开始：你选了什么问题来投入时间。如果你问题选得好，而且真的解决了它，那远远胜过你把一个无聊问题研究得特别精致。所以，我认为那种高层次的判断——到底该做什么——会非常重要。而模型未必会特别擅长这一点。未来会是很多人驾驶着大量AI辅助计算去完成伟大的事，但你真正该聚焦的，是你到底想让这些模型做什么。

主持人： 现在大家都在讲“品味”，尤其在agent coding这个时代。那品味到底怎么练？怎么把这件听起来很玄的事讲具体一点？

Jeff Dean： 这确实不容易，也不像某个指标那样有明确可测目标。它有一部分来自经验。你过去做过很多不同的问题，这些经历会教你：未来什么问题可能值得做，哪些看似分散的方法拼在一起，可能刚好能造出一个很神奇、很有用的东西。还有一种办法，是你自己写下很多条：未来12个月里，哪些事情你觉得可能会很重要。你也许只会选其中一个去做，但12个月之后，你应该回来看，其他那些预测里，哪些真的重要了，哪些被别人做出来了，哪些并没有发生。这样你其实是在给自己制造更多样本，帮助自己训练“品味生成能力”。这是个很重要的能力。

主持人： 我记得我们之前还聊到第三种方法：做一些特别疯狂的思想实验。

Jeff Dean： 对，这也是一种很好的方法。有时候，不要把所有人都默认成立的事，也当成理所当然。前几天我就和同事做了一个很疯狂的思想实验。过去60年，整个硅芯片设计和制造行业，一直在努力把晶体管做得越来越小，而且错误率越来越低。因为大家默认的目标是：同一种设计造出来的每一颗芯片，都应该跟别的芯片完全一样，不能有bit flip。内存里有各种安全裕量，有ECC等等。但在宏观层面，我们并不是这样建系统的。比如大规模分布式系统，就是用不可靠组件搭可靠系统。单块磁盘会坏，但数据不能丢，所以我们会做三副本，分别放在不同机器、不同机架上，还会用Reed-Solomon编码。可是在晶体管这么底层的尺度上，我们似乎并没有把这种思路走到很极端。所以我们就在想：如果你去造一个系统，里面的晶体管可能每天出20次错，而不是几百万年才出一次错，会怎样？

主持人： 天哪。

Jeff Dean： 那会是一个完全不同的设计点，也许会让制造端出现非常有意思的新可能。比如你要把一个信号从这里送到那里，在这种超级不可靠的晶体管上，你可能会采用完全不同的信号传输方式，也许会走多条冗余路径，确保至少有一路能到。我不是说我们现在就该去这么做，但这类思想实验很重要。很多时候这些实验最后不会成功，因为过去50年大家之所以这么做，是有充分理由的。但你还是应该每隔一段时间，重新审视这些前提。

主持人： 这听起来已经有点像神经形态计算了，或者像人脑、像自然系统。

Jeff Dean： 的确很像。比如大脑里的信号传输，本来也不是那种极端可靠的方式。所以当大脑真的有重要信息必须从一个地方传到另一个地方时，它往往会走多条通路。

主持人： 在你这么长的职业生涯里，有没有哪一个被你扔出窗外的“默认假设”，最后真的变成了一个很有影响力的系统？

Jeff Dean： 有。比如TPU就是一个很好的例子：在那个问题领域还没有像今天这么重要的时候，就去思考“是不是可以为一个非常小众的问题专门设计硬件”。这本身就是一种思想实验。

另一个例子是那个大规模分布式计算框架。那时候我、Sanjay和其他一些同事，已经为Google的抓取和索引系统写过很多代实现。我们写过很多手工并行化代码，也写了很多容错机制，确保系统跑在100台、1000台机器上时，就算其中一些机器死掉，也还能稳住。但问题在于，这些代码会和你真正想做的那个简单逻辑缠在一起。比如你本来只是想“看一遍所有网页内容，再算一个从URL到网页语言的映射”，结果代码会被大量并行化和可靠性逻辑淹没。后来我们想起自己在函数式语言上的训练，于是开始换个角度看这类问题，最后提出了一个抽象的计算框架——上层只写简单的数据处理逻辑，下层统一处理所有并行调度和容错机制。这样所有人都能站在这个底层库上做事。结果它后来成为Google处理超大规模计算时一种极其成功的方法：既健壮、又可靠。而这一切，最初就来自那个思想实验——如果我们换个角度看，能不能发现很多问题其实都能装进这个抽象里？

主持人：太厉害了。也就是说，那个思想实验最后变成了你们做的那个大规模分布式计算框架。

Jeff Dean： 对。

主持人： 回到你刚才提到的硬件和自动化。现在有AlphaChip帮你做芯片布局，也有AlphaEvolve这种会提出方案、评估方案、保留有效方案的系统。感觉你们正在构建一整套“AI去造更好的AI”的系统。

Jeff Dean： 更一般地说，这其实是在把科学方法自动化。你提出一个实验，搭好需要执行实验的东西，跑它，评估结果，再从结果中继续前进。现在越来越多的问题，已经可以把这个回路自动化了，而且不仅是跑少量实验，而是能跑非常非常多实验。一旦你能把这个循环的延迟压得极低，它就会非常非常重要。它会让我们能去处理机器学习模型设计本身、芯片设计、科学问题、工程问题等很多领域的问题。如果你真能自动化做到这些，再加上一个编排框架，把很高层的目标拆成子问题，每个子问题又都进入这种自动实验循环，去探索最优解法；然后再由另一个编排层把这些子问题的解法拼成整个高层问题的解决方案——这会非常有影响力。它会加速机器学习进步，会加速科学，会加速工程。我觉得那会很惊人。

主持人： 听起来，很多领域只要有好的evaluator，或者至少接近可形式化验证的场景，就特别适合这种能自我改进的AI系统。

Jeff Dean： 是的。而且很多时候，问题在于你得先把evaluator做得足够快。举个例子，十年前左右，我有些同事研究过量子化学问题。你要理解某个分子的性质，通常得先生成一个分子构型，然后跑一个非常昂贵的密度泛函理论模拟器。这个模拟器可能要算整整一夜，才能给你一个答案。但我同事们的做法是，先收集很多这类模拟的输入输出：输入是分子构型，输出是昂贵模拟器算出来的结果。然后他们用这些数据去训练一个神经网络版的近似模拟器。这样它就成了一个新的验证设备。以前跑一次要一整夜，现在他们把它做成了一个快30万倍、而且精度几乎不输完整模拟器的版本。

主持人： 太夸张了。

Jeff Dean： 这会彻底改变你做科学的方式。因为如果你有1000万个候选要筛，以前这可能是一个要花6个月攒计算资源去做的工程；现在你可能午饭前就筛完了。我觉得，在很多领域，都还有很大空间去做更快的验证模型，甚至是学习型验证模型。它们能更快地给出一个足够接近真实答案的结果。而一旦做到这一点，你就能重新定义整个实验循环，以及你跑一轮循环要多久。

主持人： 那在这种被大幅加速的“科学方法”里，你最兴奋的具体问题是什么？你最想看到它先解决哪些空间里的问题？

Jeff Dean： 很显然，机器学习本身就是一个。也就是：我们能不能造出一个模型，让它通过跑大量实验，递归式地改进自己？你看今天大模型是怎么被研究团队做出来的：大家先想一些点子，跑很多小规模实验，看看哪些小实验有效；如果有效，再把最有希望的那些放大规模；再评估；再把结果整合成一个新的模型recipe。但其实没有什么根本障碍，非得让这个循环由人来主导。完全可以把它做成更自动化的loop：模型自己决定要探索什么，或者由人类在高层稍微给一点指引，比如“你去试试某种新架构”，然后模型自己跑大量实验，筛出有效方案，并以更快的节奏把成果纳入下一轮改进里。本质上，你想优化的是“每单位算力输入能得到多少新发现”。

1

Jeff Dean给AI创业者的建议

主持人： 再回到职业成长这件事上。今天在座很多人未来都会被拒绝很多次。你也有这样的经历。比如2014年，你和Jeff Hinton、Oriol Vinyals写过一篇关于蒸馏的论文：大模型当老师，小模型当学生，从而得到更便宜、更小、但依然有效的模型。现在整个行业都在用这套东西。但那篇论文当年却被NIPS拒了。

Jeff Dean： 对。我其实也不怪程序委员会。很多时候一篇论文就是拿到三份评审。那次有一位评审说，这项工作“不太可能产生显著影响”。但我们写那篇论文时，其实很清楚这是个特别重要的问题。因为我们知道，如何从更大的模型里做出更便宜但依然很强的模型，是我们非常迫切想解决的事。因为我们想把模型服务给更多的人，覆盖更多场景，比如语音、视觉等等。但评审未必有这样的经验。他可能没有在思考大规模AI服务系统，而是更偏学术地在想“这是不是一个根本性理论突破”。所以有时候会被拒，这没关系。我们把它放到arXiv上，大家看了、用了，一切都很好。而且今天我们也确实在这么做。比如Gemini里的Flash模型，就是部分从更大的Pro模型蒸馏出来的。这也是为什么Gemini的Flash模型在体量和速度都更小的情况下，依然那么有能力。在同等模型尺寸级别里，它们是benchmark上表现最好的之一。

主持人： 这真的很厉害。这里面的一个启示就是：即使被拒了，也继续干下去。

Jeff Dean： 对，这就是我从中“蒸馏”出来的教训。

主持人： 现在假设一下：把1999年加入Google那个20人创业公司时的年轻Jeff Dean，直接传送到今天。带着你现在的能力和视野，你会怎么选？去前沿实验室，还是自己创业？

Jeff Dean： 这个永远都很难一概而论，也非常个人。对我来说，最重要的问题是：你是不是在做一件你真正关心的事？如果你和一群你喜欢合作的同事，一起在这件事上取得进展，或者把它真的做出来，它会不会以某种正面方式改变世界？比如，它会不会突然让生物化学家能做以前做不到的事？或者帮助程序员？或者帮助所有互联网消费者？你该努力追求的，是在世界上产生正向影响，和你喜欢的人一起工作，然后尽全力把事做好。

至于你刚才说的那个具体二选一：去前沿实验室，还是跟一两个朋友小规模创业——它们是完全不同的体验。大机构里，你有现成结构，有非常多厉害的同事，他们知道很多你不知道的事；也有很多重要问题等着你做；而且你的工作天然就有现成的平台去产生影响。小创业公司则完全不一样。你必须对那个问题有强烈热情，而且要承担很高风险：你到底能不能把它做成、把它长成一项事业？但那也可能是非常有回报的经历。所以最终还是看个人偏好。但不管你选哪条路，至少都要问自己一句：如果这件事走到最好的结局，世界会不会因此在某个方面明显变得更好？如果答案只是“哦，这还挺酷，但也就那样”，那这就不是你应该投入时间的事。

主持人： 那我们再多聊一点第二条路，也就是和你真正喜欢的人组成一个小团队。你做过很出色的导师和管理者，也带人做出过很大的系统。那对今天在场的人来说，怎么和聪明人一起工作、怎么找到聪明人，有什么经验？

Jeff Dean： 你当然总是想找那些在某个关键领域里很强的人，无论你是在公司内部组团队，还是自己创业。你需要那些技能互补的人。但你也得找那种你和他们待在一起会很开心的人。因为你们会花大量时间，一起啃很难的问题。所以你想找的是那种低ego、能合作、并且技能和你互补的人。我一直觉得，小团队特别有意思的一点是，别人懂你不懂的东西，而你也有他们没那么强的能力。这样你们合在一起，就能共同做出一个单独谁都未必做得出来的东西。而且在一起做这件事的过程中，你自己会长很多新知识、新技能，他们也会。你要把自己的工程或研究生涯看成一个“工具腰带”：你总得不断往里面加新工具，因为你永远不知道未来会碰到什么问题。也许将来你遇到一个问题时，需要的不是你现在有的3个专用工具，而是4个。你的工具越多，未来你能解的问题就越多。

主持人： 最后一个问题。我相信今天在场的人里，将来一定会有人做出像MapReduce、TPU、蒸馏那样有影响力的东西。你最希望他们去做什么问题？

Jeff Dean： 世界上有太多有意思的问题了，我随便列几个，这肯定不完整。首先，我个人特别兴奋的是新的硬件路径。刚才那个思想实验其实就是个信号。还有，更高效的推理硬件，我觉得也非常重要。另外，我觉得机器学习算法本身也许还可以完全不同——比如比今天方法数据效率高得多。你想想今天的大模型，它们可能在18岁之前看到的数据量，比一个人类到18岁时接触的数据多1000倍。但人类到了18岁，在很多事情上反而做得更好，或者至少能和前沿模型打平。所以，能不能做出数据效率高得多、还能持续从自己行动中学习的系统？持续学习本身就是一个非常有意思的问题。我还觉得，多agent交互也很有意思。再往外一点，怎样让世界上的人进行更好的对话，也很有意思。有没有办法让人们进行更文明的交流？有没有办法帮助人们基于兴趣认识世界上他们本该认识的其他人？这些都是挺有意思的方向。世界很大，问题很多，我们应该努力让更多更酷的事情发生。

主持人： 听起来很棒。非常感谢你，Jeff Dean。今天就到这里。也谢谢大家。

Jeff Dean： 谢谢大家。

点个“爱心”，再走 吧