Jeff Dean：AI已达初级工程师水平，推理硬件是下一个关键战场

AI智能体正从"工具"演变为能够连续运行数周、独立完成复杂任务的系统，而制约其大规模普及的核心瓶颈，正在从模型能力转向推理硬件效率。Google首席科学家、深度学习先驱Jeff Dean在Y Combinator的访谈中，对AI现状与未来走向作出了一系列研判，并点明了他眼中下一个技术突破口所在。 Dean表示，他去年对"AI已达初级工程师水平"的预测基本得到了验证，且模型在完成更复杂任务方面的进展速度超出了他的预期。他尤其强调，AI智能体在编程之外的领域同样开始展现能力，这将是未来的重要趋势。 在预判下一阶段突破口时，Dean将目光指向推理硬件。他提出，若推理延迟能降低50倍，将从根本上改变AI系统的产品边界，催生出目前难以实现的全新应用形态。与此同时，他对创业者发出明确信号：上下文工程、专用领域模型，以及能够整合推理时计算的多智能体系统，将是小团队实现差异化的主要窗口。 AI智能体能力已超预期，可连续运行数周 Dean在对话中证实，其2025年5月作出的"AI达到初级工程师水平"判断基本准确，并指出实际进展在某些维度上超出了他的预期。"模型完成更复杂任务的能力增长速度比我预想的要快，"他说，"而且在编程之外的领域，这些基于智能体的系统也开始崭露头角。" 他认为，目前市场对AI智能体能力存在一个被普遍低估的认知盲点：基于智能体的系统已经可以不止运行一两个小时，在某些问题领域、配合足够强大的模型，可以连续运行数天甚至数周，完成极为复杂的任务。"有些人已经开始隐约察觉到这一点，但我认为还没有被普遍接受，这将是一件影响很大的事。" 在实际应用层面，Dean举例称，他和同事Sanjay近期在做底层库性能优化时，通过为智能体编写"技能"（skill），教会模型按顺序完成"测量基准—改进代码—测量性能提升—迭代"的完整流程，实现了相当高效的自动化循环。他还提到，目前的模型在将软件从一种编程语言翻译成另一种语言方面已相当高效，因为原始代码本身构成了一份极其清晰的规格说明。 推理硬件：下一个关键战场 Dean将推理硬件效率定义为AI系统下一步大规模普及的核心约束，并类比了他2001年主导的一项历史性决策——将Google搜索索引从硬盘迁移至内存，以此说明硬件架构的跃迁对产品能力的决定性影响。 "大家会看到越来越多高性能、低能耗的推理硬件系统，"他表示，"推理是让基于智能体的系统能够普及给更多人的关键，延迟非常重要，而硬件的专用化正是提升能效、降低延迟的关键途径，比GPU或TPU这类通用计算设备更有效。" Dean进一步指出，当前AI系统设计中存在一个被多数创业者忽视的底层约束：将数据从加速器的HBM取到处理器进行计算，所消耗的能量是实际执行一次乘法运算的上千倍。这一差距深刻影响了批处理的必要性、系统架构设计乃至产品的延迟表现。"如果没有这上千倍的差距，就不需要做批处理；但正因为有，你必须一次性处理很多样本或很多token，才能把这次数据搬运的开销摊薄。" 在推理硬件的优化方向上，他着重提到两点：尽量减少数据搬运，以及尝试极低精度运算，将所需精度直接内建到硬件中，而非支持冗余的精度选项。 上下文工程崛起，小团队迎来差异化窗口 Dean指出，AI进步的驱动力正在发生结构性转变——从"更大的模型、更多的数据"，逐步转向模型之外的系统工程能力，包括检索、工具调用、记忆管理和智能体编排，即业界所称的"上下文工程"（context engineering）。 "模型只是你要构建的整体系统中的一部分，"他说，"这涉及模型如何使用各种工具，如何检索相关信息，可能还要保留过去解决其他问题时检索到的信息，并把这些信息放进模型的上下文中。" 他将上下文工程视为小团队的重要机会入口，原因在于门槛结构的改变："以前训练一个模型需要海量的资源、GPU和数据，但做上下文工程，你只需要一个类似Gemini的API接口，然后自己搭建检索系统、工具调用之类的东西就行了。" 对于智能体在执行超过三四十步后容易"脱轨"的普遍问题，Dean给出了两类应对策略：一是为模型提供技能和提示，使其尽量停留在熟悉的操作路径上；二是采用多智能体架构，通过推理时计算（inference-time compute）搜索可行解题路径，由另一个模型或智能体对多条路径进行评估和筛选，保留有效方案，剔除偏离轨道的路径。 对创业者的判断框架：找模型成功率接近零的问题 在与创业者直接相关的议题上，Dean提供了一套较为具体的机会识别框架。 他指出，通用模型正在越来越多的领域持续变强，这意味着创业者必须审慎评估自己选择的方向是否具备足够的持续性："你正在做的事情是不是够'持久'——未来六个月或十二个月，前沿模型会不会就能做到这件事了？" 在识别有效切入点时，他给出了较为清晰的信号：应当寻找当前通用模型成功率接近0%或1%的问题，而非20%。后者往往意味着相关能力正处于萌芽阶段，随训练数据增加或模型规模扩大，通用模型可能很快追平。 他认为两类场景具有较强的结构性优势：其一，产品能够接触到通用模型无法获取的特殊数据，例如用户个人信息；其二，针对极其困难的特定问题，通过训练专用小模型，可以以较低成本获得高精度解法。他以AlphaFold为例——这是一个专用于蛋白质折叠的模型，并非通用系统，在特定领域取得了显著成效。他认为材料科学、芯片设计等领域同样存在类似机会。 自动化科学方法：AI加速AI自身演进 Dean对2027年的大胆预测指向一个更深层的演进方向：机器学习系统本身的自动化程度将大幅提高，形成"用AI优化AI"的闭环。 他描述的路径是：将问题拆解成子问题，在紧密的自动化实验循环中运行，再将结果整合，从而持续迭代出改进后的系统。"这不只适用于机器学习，也适用于其他科学和工程领域——基本上任何有可衡量目标的领域，现在都能取得很大进展。" Dean还提到，加快这一循环的关键之一，是构建速度更快的验证模型。他以量子化学领域的案例说明：原本需要运行一整夜的密度泛函理论模拟，在用神经网络近似后速度提升了30万倍，使原本需要六个月才能完成的千万种分子构型筛选，在午饭时间内即可完成，从根本上改变了科学研究的节奏。 他同时提出了一个颇具挑战性的思想实验：过去60年，半导体行业默认晶体管必须极度可靠；但若在更高系统层面引入冗余容错机制，是否可以使用每天出错20次的晶体管来构建系统？这类对基础假设的重新审视，正是他认为能够催生下一代突破性系统的思维方式。 未来稀缺能力：判断力，而非执行力 面对"当智能体能完成所有代码编写后，什么才是真正稀缺的"这一问题，Dean给出了明确的答案：判断力（taste）——即知道该让智能体去解决什么问题。 "模型未必擅长做这种判断，"他说，"未来会是人来引导大量的AI辅助计算，从而更快地实现伟大的成果——但那个'你想要模型做什么'的核心，才是你应该专注的关键。" 他提出了一种量化训练判断力的方式：定期写下未来12个月内可能重要的事情清单，一年后回头核验哪些真的变得重要，哪些已被他人完成，哪些尚属空白。此外，他还强调了"第一性原理"思考的价值——不纠结于问题今天是怎么解决的，而是眯着眼睛审视问题的本质，寻找能带来一到两个数量级提升的截然不同的解决思路。 以下为访谈实录： 主持人： Jeff，欢迎你，非常感谢你能来。尤其是我刚感冒了，还是要谢谢你能来。 Jeff Dean： 我这几天嗓子哑了，平时说话不是这个样子，但我们尽量。 主持人： 你主导开发了MapReduce、Bigtable、TensorFlow、TPU、Gemini，光是这些成果就能聊上一整个小时。但我最欣赏的一点是，你现在依然愿意公开做出大胆的预测。去年，也就是2025年5月的AI Ascent大会上，你说AI已经达到了初级工程师的水平。这已经是一年前的事了，现在这个预测兑现得怎么样？ Jeff Dean： 我感觉模型在基于智能体的长程编程任务上进步很快，现在它们已经相当能干了。具体要看你怎么定义"初级工程师"，但我觉得这个预测基本说中了。 主持人： 这个预测里，你低估了什么？ Jeff Dean： 我觉得模型完成更复杂任务的能力增长速度比我预想的要快。而且我发现，在编程之外的领域，这些基于智能体的系统也开始崭露头角，我认为这会是未来的一个重要趋势。 主持人： 那再给我们一个大胆的预测吧，你觉得2027版的预测会是什么？ Jeff Dean： 我认为机器学习系统本身的自动化程度会大幅提高——让机器学习系统通过运行大量实验来自我提升能力，把问题拆解成子问题，在一个紧密的自动化实验循环里运行这些子问题，再把结果整合起来，从而得到一个改进后的系统。这种完全自动化的问题分解和自动化实验，我觉得会非常令人兴奋。而且这不只适用于机器学习，也适用于其他科学和工程领域——基本上任何有可衡量目标的领域，现在都能取得很大进展。 主持人： 我们回顾一下历史。早在2001年，Google搜索还跑在硬盘上，你和Sanjay算了一笔账，发现总有一天整个搜索索引能装进所有服务器的内存里。你们意识到这一点后，几天之内就把搜索从跑在硬盘上换成了跑在内存里，这也是Google搜索变快的关键。放到2026年的今天，"能装进内存"这样的时刻是什么？在座的每个人现在应该在思考、设计什么？ Jeff Dean： 情况不太一样了，但我认为大家会看到越来越多高性能、低能耗的推理硬件系统。因为大家现在都意识到，推理是让这些基于智能体的系统能够普及给更多人的关键，延迟非常重要，而硬件的专用化正是提升能效、降低延迟的关键途径，比GPU或TPU这类通用计算设备更有效。毕竟现在每个人都已经习惯了等待模型的响应。 主持人： 所以你是说，如果我们不用再等待了会怎样？ Jeff Dean： 对，设想一下，如果延迟能降低50倍，你能用它做什么。 主持人： 有意思的想法。现在，在座这6000人当中，有什么关于AI的普遍假设其实已经不成立了？ Jeff Dean： 我觉得可能有一点大家没有充分意识到，那就是基于智能体的系统其实已经可以不止运行一两个小时，在某些问题领域，配合足够强大的模型，它们可以连续运行数天甚至数周，去完成非常复杂的任务。有些人已经开始隐约察觉到这一点，但我认为还没有被普遍接受，这将会是一件影响很大的事。 主持人： 具体来说，有没有哪个任务是你让智能体跑了好几周的？你让它去解决什么问题了？ Jeff Dean： 比如说，你可以让智能体去用不同的编程语言，从头实现全新版本的软件，可能是安全性更好，或者性能更好的版本，然后让它们真正认真地去完成这件事。 主持人： 很酷。现在说说你特别擅长的一件事——用餐巾纸做估算。听起来有点好笑，但关于你的一个故事是：2013年Google的语音识别刚开始起作用时，你在餐巾纸上算了一笔账——如果每个Google用户每天用手机做三分钟的语音识别，你发现这需要把整个Google服务器机队翻一倍，成本会非常高昂。而你没有这么做，你们自己造了一款定制芯片，这就是TPU的起源。 Jeff Dean： 对。当时我们开始在基于深度学习的语音系统上看到非常好的质量结果，但相比旧的语音系统，这些模型的计算开销要大得多，不过错误率也降低了很多，相当于几个月内就实现了语音识别20年的进步——只是稍微调了调模型、扩大了规模、用了更好的数据。于是我们开始担心，如果语音识别效果变得好很多，人们会更多地使用它，比如用语音口述邮件或者跟手机对话。我们意识到需要比当时用CPU运行更好的解决方案，于是就有了TPU——它专门针对低精度密集线性代数运算做了优化，而这正是当今几乎所有现代机器学习算法的核心。如果你为低精度密集线性代数专门造一块芯片，别的什么都不做，它对机器学习推理会非常有用，尽管它跑不了Chrome或Word之类的程序。几年后，这套系统做出的芯片，能效比当时的CPU和GPU高出30到80倍，延迟也低了20到30倍——这也是今天TPU能成为基础设施的关键原因。 主持人： 你当初肯定没预料到，TPU后来会成为Transformer架构的基础——毕竟Transformer架构比TPU出现得晚得多。 Jeff Dean： 对，这也是为什么我们造的是一个通用的线性代数系统，也就是TPU真正的本质。因为我们知道机器学习算法还在不断演变，你不想过度专用化，但又要专用到足以获得显著的性能提升——比如可以有非常大的乘法器阵列、高速内存、高速互连，后来的TPU还能让许多芯片高效地协同处理同一个问题。这么多代下来，我们一直在持续扩展和提升它们的性能。 主持人： 这餐巾纸算账真是厉害。那对于在座想成为未来创业者的人来说，今晚回去应该做哪种餐巾纸测算，才有可能做出像TPU这样有分量的东西？ Jeff Dean： 这个不好一概而论。我觉得应该去想想，你关注的领域里有哪些问题，有哪些瓶颈，是否存在截然不同的解决思路，能带来一到两个数量级的性能或能力提升。有时候，如果你眯着眼睛看一个问题，不去纠结这个问题今天是怎么解决的，而是从第一性原理出发去思考该怎么解决，你就可能想出一些真正好的点子——很可能是别人还没想到的。 主持人： 是个不错的建议。多年前，你写过一份很出名的清单，叫"每个工程师都应该知道的延迟数字"，里面列了缓存未命中要多久、磁盘寻道要多久、一个网络包从加州传到荷兰要多久，诸如此类关于分布式系统和系统工程的数字。这份清单后来被很多分布式系统工程师奉为圭臬。现在这份清单也该更新了，能不能给我们一个2026年的AI版本？ Jeff Dean： 如果放在今天的AI系统里看什么是重要的，你会想知道加速器主存到片上内存、再到乘法器单元之间的带宽是多少；做一次乘法运算需要消耗多少能量；芯片之间的互连带宽是多少，这个带宽能连接多少块芯片；再往外扩展，比如要和一万块芯片通信而不是五百块时，网络带宽会怎样下降。我觉得这些都是非常重要、值得了解的数字，会实实在在地影响你思考和解决具体问题的方式。 主持人： 你说过一个很有意思的观点，现在衡量一切的单位是能量。你提到做一次运算大约消耗1皮焦耳，但搬运数据、做数据I/O要消耗上千倍的能量。 Jeff Dean： 对，光是把数据从加速器的HBM取到处理器里以便计算，就是这个量级的开销。 主持人： 这个差距其实悄悄决定了什么产品能做出来、AI算法该怎么设计。那么，创业者常常以为是"模型问题"，但其实是能量或数据I/O问题的，都有哪些？ Jeff Dean： 你提到的搬运数据和实际计算之间上千倍的能量差距是个很关键的例子，它塑造了我们做机器学习时的很多方面。如果没有这上千倍的差距，就不需要做批处理（batching）；但正因为有，你必须一次性处理很多样本或很多token，才能把这次数据搬运的开销摊薄，这样才不用承受上千倍的减速，而是承受"上千倍除以批大小"的能量开销。但对于真正的低延迟场景，批处理效果并不好。这类围绕计算机硬件能量消耗的决策，实际上深深影响着我们构建上层系统的许多选择。 主持人： 一个很具体的例子就是模型训练本身——把数据集分批、跑epoch这套流程，大家可能以为这是"模型问题"，但其实是系统层面的数据I/O问题，对吧？ Jeff Dean： 对，你必须把数据组装成批次才能提高硬件效率。理想情况下你可能想做批大小为1的训练，但这样效率不够高，所以现在大家用的批次都相当大。 主持人： 你以擅长利用一个长周末，独自钻研出一个精妙方案而闻名。有没有可能Jeff你花上几周时间，去实现批大小为1的训练？ Jeff Dean： 我最近其实在更多地思考推理。推理是个挺有意思的问题，因为你确实需要非常低的延迟——训练则未必需要那么低的延迟。我觉得针对推理去做更专用的硬件，还有很大的空间，目前这方面做得还不够。 主持人： 在推理方面，有哪些你正在深入思考的有意思的事情？ Jeff Dean： 主要是尽量减少数据搬运；尝试极低精度的运算，可能不需要支持那么多种精度——如果你已经明确知道自己需要什么精度，那就直接把它内建到硬件里，别的都不要支持太多。 主持人： 这让我想起一位知名计算机科学家的类比：AI本质上是一个巨大的压缩问题——因为要把数据做有损压缩再还原，你首先得真正理解这些数据。 Jeff Dean： 对，如果你真正理解数据，就应该能把它压缩得很好，而Transformer架构正是目前证明行之有效的方法之一。 主持人： 效果确实不错——这也是我同事们的功劳。现在我们把视野放宽一点。过去AI的进步主要是"模型变得更好"——更多数据、更大参数量。但最近这一两年，进步越来越体现在模型之外的东西上：检索、工具、记忆、智能体工具，这些可能正在汇聚成大家所说的"上下文工程"（context engineering），对吧？ Jeff Dean： 对，模型只是你要构建的整体系统中的一部分，这个系统要能解决非常复杂的问题——这涉及模型如何使用各种工具，如何检索相关信息，可能还要保留过去解决其他问题时检索到的信息，并把这些信息放进模型的上下文中。这样做的好处是，这些信息对模型来说是非常清晰的，不像训练数据那样——训练数据是数万亿个token混合搅拌进数千亿甚至数万亿参数里，相对模糊；而当下这个具体问题或用例的上下文，模型能直接、清晰地看到。接下来，模型需要理解有哪些工具可用，哪些工具能帮它解决下一步的问题，如何把一个问题拆解成一连串的工具调用，也许还要尝试多种方案并评估哪种有效——这整套复杂智能体乃至多智能体系统的编排，我认为会变得越来越重要，也是一个非常令人兴奋的领域。 而且我觉得这个问题领域有意思的地方在于，在座的每个人其实都能参与其中——因为以前训练一个模型需要海量的资源、GPU和数据，但做上下文工程，你只需要一个类似Gemini的API接口，然后自己搭建检索系统、工具调用之类的东西就行了。 主持人： 那大家应该怎么做，才能在上下文工程上做得更出色？ Jeff Dean： 一个很好的办法是，实际用这些模型、脚手架（harness）和工具去解决问题，有时你能亲眼看到模型在哪些地方失败了。往往你不需要去调整模型参数（这从外部很难做到），而是可以通过给模型制定更好的指导规范、写"技能"（skill）让模型知道如何使用不同的工具，就能显著提升模型解决某一类问题的表现。做这件事的过程中，你所使用的整套系统会不断自我改进。这也是一个很好的方式，能让你更清楚模型还需要哪些额外信息才能变得更强。 主持人： 能举个你自己亲手做的上下文工程的例子吗？比如你写过的某个技能或工具，对你的工作流程带来了很大改变？ Jeff Dean： 几周前，我和Sanjay在做一些底层库的性能优化工作。我们在Google写了一个微基准测试库，可以测量各种操作要花多长时间，或者填充某个数据结构要多久——这些数据结构可能在Google的数百万个进程中被使用，所以确保它们高性能非常重要。你可以写微基准测试，但如果没有智能体系统，通常的流程是：先测量当前基准的性能，做一些你希望能提升性能的修改，然后重新运行基准测试看哪里有改善，再运行更大范围的基准测试，测量缓存占用情况等等。于是我们写了一个"技能"，教模型如何按顺序完成这一整套流程，让它能自主完成"测量基准—改进代码—测量性能提升—迭代"这个循环，这对某些类型的问题效果相当不错。这其实就是把我们自己作为工程师会用的方法，以模型能使用的形式教给它。 主持人： 这听起

原文超出正文长度上限，此处截断——上游还有内容，完整版见上方「原文 ↗」。