Jeff Dean预言：未来工程师将管理50个智能体，写需求比写代码更重要

谷歌首席AI科学家、传奇工程师Jeff Dean在最新访谈中提出了一个引人注目的预言：未来每位工程师可能会管理多达50个智能体实习生，以并行处理大量任务，且沟通效率将超越人类协作。

他同时指出，未来最重要的技能将是“清晰地定义需求”，因为智能体的输出质量完全取决于人类如何描述和限定问题。

谷歌的双轨模型策略：帕累托前沿

Jeff Dean揭示了谷歌当前遵循的帕累托前沿策略。在新模型的开发上，谷歌主要沿着两条路径推进：

• 高端前沿模型：专注于深度推理、解决复杂数学问题等高难度任务。
• 高性价比模型：针对低延迟场景优化，旨在实现更流畅的智能体式编程体验。

模型蒸馏：小模型逼近大模型性能的关键

Jeff Dean在访谈中确认，蒸馏技术是Gemini模型实现高性能与高效率平衡的核心秘诀。通过这一技术，小模型可以非常接近大模型的性能。

具体而言，谷歌让小模型在大量训练数据上进行多轮迭代学习，同时利用大模型输出的中间信息（logits）进行引导，从而使小模型学习到更精细、更接近大模型的行为模式。这正是Gemini能够实现“下一代轻量版模型性能约等于上一代专业版，甚至更好”的原因。Jeff Dean表示，谷歌将持续推进这条技术路线。

此外，Jeff Dean高度强调低延迟的价值，他认为若能将延迟降低20-50倍，用户体验将发生根本性变革。

访谈核心要点摘要

在本期访谈中，Jeff Dean还分享了以下关键信息：

• 规模化信念：他几十年前就坚信“更大的模型、更多的数据、更好的结果”这一信条，并已坚持了15年。
• 能耗作为第一性原则：大型语言模型的训练与推理不仅关乎计算量，也涉及数据搬运成本。对硬件、批处理大小、延迟和吞吐量的优化设计，都可以用能量消耗作为核心衡量标准。
• 软硬件协同设计：TPU团队与机器学习研究团队必须紧密协作，硬件设计需要预测未来2-6年的模型发展趋势。
• 对Gemini早期开发的反思：Jeff Dean坦言Gemini项目早期资源过于分散，并称“这是愚蠢的”。
• 未来预测：他给出了两个重要预测：一是未来真正“个性化”的模型将极其重要；二是低延迟将彻底改变众多应用场景。

以下内容节选自本次访谈实录，围绕核心观点进行了整理与摘选。

蒸馏是轻量模型突破的关键

Shawn Wang: 首先要祝贺你们占据了帕累托前沿。

编者注：帕累托前沿描述了在多目标权衡中的最优解集合。此处指谷歌在模型性能与成本/延迟的权衡上已达到最优状态，既能推出高性能前沿模型，也能提供高性价比模型。

Jeff Dean: 谢谢。能站在帕累托前沿当然是好事。

Shawn Wang: 是的。我认为你们所做的不仅是追求顶尖能力，还同时兼顾了效率，真正“拥有”了帕累托前沿——既提供了顶级性能，也控制了成本与效率，并为用户提供了完整的模型梯度选择。这背后是硬件工作、模型设计以及长期积累的多种技术共同作用的结果，整合起来确实令人印象深刻。

Jeff Dean: 确实如此。这不是单一因素决定的，而是从硬件到软件、从系统到模型的全栈协同。所有这些环节结合在一起，使我们既能打造能力极强的大型模型，也能通过软件技术将这些能力“压缩”到更小、更轻量、成本更低、延迟更低的模型中，同时仍能保持相当强大的能力。

Alessio Fanelli: 在谷歌内部，你们是否也对帕累托前沿的“低端”（即高性价比模型）感到很大压力？新兴实验室往往全力冲刺性能前沿以获取融资，但谷歌拥有数十亿用户。早年进行CPU规划时，如果每个用户每天多使用三分钟语音模型，总计所需的算力就可能需要翻倍。如今在内部，你们是如何在“追求技术前沿”和“必须实现规模化部署”之间进行权衡和决策的？

Jeff Dean: 我们始终希望拥有并推动处于前沿的模型，因为只有在那里，才能发现“新能力”——即上一代模型所不具备的功能。但我们也清楚地认识到，这类模型通常速度更慢、成本更高。许多广泛的应用场景实际上更需要低延迟、低成本的模型。

因此，我们的策略是双轨并行：一方面开发高端前沿模型，用于深度推理、复杂数学问题等高难度任务；另一方面开发高性价比模型，用于低延迟场景，例如更流畅的智能体式编程。两者都至关重要。

并且，通过蒸馏技术，我们可以将前沿模型的能力迁移到小型模型上。所以这不是“二选一”，而是相辅相成——没有前沿模型，也很难获得高质量的小模型。

Alessio Fanelli: 蒸馏这个方法，你和Geoffrey Hinton早在2014年就提出了。

Jeff Dean: 别忘了Oriol Vinyals（也是贡献者）。

Alessio Fanelli: 这么多年过去，你如何看待这些技术理念的“周期性”？例如稀疏模型。很多想法在当时可能看起来不那么重要，但后来产生了巨大影响。你们如何判断哪些理念值得在下一代模型中重新审视？

Jeff Dean: 当年提出蒸馏，其动机源于图像任务。我们有一个包含3亿张图片的数据集。如果针对不同类别（如哺乳动物、室内场景）训练专门的“专家模型”，然后将50个这样的模型集成起来，效果会非常好。但显然不可能在线上部署50个模型。于是我们思考：能否将这些专家模型的“知识”压缩进一个更小、可部署的单一模型？这就是蒸馏的起源。今天的逻辑是类似的，只不过我们现在是从一个极大规模模型蒸馏到一个小模型，而不是从50个模型蒸馏。

Shawn Wang: 蒸馏和强化学习革命之间是否存在关联？例如，强化学习可能会在某些能力分布上形成“尖峰”，但可能牺牲其他区域的能力。如果能通过蒸馏重新平衡这些能力，实现“能力合并而不退化”，这是否是一种理想状态？

Jeff Dean: 蒸馏的一个关键优势在于，小模型可以在大量训练数据上进行多轮迭代学习，同时利用大模型输出的logits信息（而不仅仅是硬标签）。这能引导小模型学习到更细腻的行为模式。在实践中，我们确实发现小模型可以非常接近大模型的性能。

这也是为什么在Gemini的多个迭代版本中，我们能够实现 “下一代轻量版模型性能约等于上一代专业版，甚至更好” 。这是一条我们将持续推进的技术路径。

Shawn Wang: 那么Ultra模型呢？内部是否有一个持续进行蒸馏的“母体模型”？

Jeff Dean: 我们拥有许多不同规模和用途的模型，有些并未对外发布，有些是专业版级别。蒸馏可以来自不同的源头。此外，在推理阶段进行扩展也是提升模型能力的重要方式。

Shawn Wang: 轻量模型的经济性确实带来了规模优势。听说处理量已达50万亿tokens？

Jeff Dean: 在市场份额方面，希望还在增长。

Shawn Wang: 轻量模型现在几乎无处不在——Gmail、YouTube、搜索AI模式……

Jeff Dean: 是的。轻量模型的优势不仅在于成本低，还在于低延迟。而延迟非常关键。未来，模型将被要求完成更复杂的任务，例如编写整个软件包，而不仅仅是一段循环代码。这将生成大量token，因此低延迟系统至关重要。轻量模型是其中一个方向。在硬件层面，例如TPU芯片之间的高性能互联，对于部署长上下文注意力机制或稀疏专家模型也至关重要。

Alessio Fanelli: 那么，你们是否会担心某种“饱和”现象？例如，经过两代发展后，轻量模型就能覆盖大多数需求，这是否会削弱继续推进专业版前沿模型的动力？

Jeff Dean: 如果人类提问的分布是静态不变的，那或许有可能。但事实是，模型的能力越强，人们提出的问题就会越复杂。

一年前，我只会让模型执行简单的编码任务，现在我已经会让它进行复杂的系统分析。用户的需求本身就在不断进化。前沿模型在推动能力边界的同时，也让我们看清了瓶颈所在，从而指导下一代模型的改进。

Alessio Fanelli： 谷歌内部现在还依赖公开的基准测试吗？

Jeff Dean： 公开基准测试有价值，但其生命周期有限。一个理想的基准，初始得分应该在10%到30%之间，然后通过改进提升到80%到90%。

一旦超过95%，意义就不大了，要么意味着能力已经完全掌握，要么可能存在数据泄露的风险。我们内部有很多保留的测试集，专门用于评估那些未出现在训练数据中的能力。之后我们会分析，问题究竟是出在数据、架构上，还是模型本身就存在能力缺口。

Shawn Wang： 有没有哪个基准测试直接促成了架构上的创新？

Jeff Dean： 长上下文能力就是一个很好的例子。从Gemini 1.5开始，我们在长上下文方面取得了显著进展。像“大海捞针”这种单点检索测试现在基本已经饱和了。真正有意义的是更复杂的多点检索或真实任务，比如从数千页文档或数小时视频中提取信息。

Shawn Wang： 但会不会有“过拟合基准测试”的风险？就像Jason Wei说的，那可能是一种归纳偏置，短期有效，但长期未必可扩展。

Jeff Dean： 我们更关注的是“需要什么能力”，而不是针对某个具体基准的解法。长上下文显然非常有用，但目前的长度仍然不够。

理想状态是模型“能在回答问题时访问整个互联网”。但现有的、具有二次计算复杂度的注意力机制不可能扩展到万亿级别的token。我们需要算法和系统层面的双重突破，来创造一种“可访问万亿token的幻觉”。

如果能做到这一点，模型就能访问整个互联网、YouTube视频的像素、个人邮件、照片和文档（在用户授权下）。这将极具价值。关键在于：如何在算法和系统层面实现这种规模的跃迁。

Gemini从设计之初就强调多模态

Shawn Wang： 顺便说一句，我之前算过一笔账——如果一个人每天连续讲八个小时、天天讲，最多也就生成大概10万个token，这其实完全在现有模型的承受范围内。

Jeff Dean： 对，不过如果你再进一步说——好，我想要理解人们上传到视频里的所有内容，那情况就不一样了。

Shawn Wang： 而且经典的例子是，当你从语言扩展到其他模态，比如蛋白质结构之类的信息，那信息密度就高得多了。

Jeff Dean： 没错。我认为像Gemini这样的模型之所以强调多模态，是因为我们从一开始就希望它是多模态的。

很多人理解的多模态是文本、图像、视频、音频这些“人类感知”的模态。但我认为，让模型理解“非人类”的模态同样非常有用。

比如来自Waymo自动驾驶车辆的激光雷达传感器数据，或者机器人数据、医疗影像数据（如X光、MRI），以及基因组信息。

世界上可能有数百种不同的数据模态，我们希望模型至少能接触到这些模态，并知道它们是有意义的信号。

即使你没有在所有激光雷达或MRI数据上进行大规模训练，仅仅少量纳入，也会非常有价值，因为这会给模型一个“暗示”：这些都是现实世界中的重要信号。

Shawn Wang： 那你是否认为存在某种“王者模态”？比如视觉可以在像素层面编码文本；有篇DeepSeq CR的论文就是这么做的。

视觉还能通过频谱图来表示音频。所以会不会视觉才是那个“统治一切”的模态？

Jeff Dean： 视觉和动态信息_（比如视频而非静态图像）_确实至关重要。

进化过程曾23次独立演化出“眼睛”，这本身就说明了视觉对于理解世界是多么关键。

而我们希望这些模型也是在“感知世界”。所以关键在于：它们是否能解释所看到或关注到的内容，并利用这些信息来帮助我们完成任务。

Shawn Wang： 说到视频，我得夸一句，Gemini目前可能还是唯一一个原生支持视频理解的模型。我经常用它来分析YouTube视频。

Jeff Dean： 是的，其实很多人并不完全了解Gemini到底能做什么。

我有个例子：一个包含过去20年18个经典体育瞬间的YouTube视频合集，比如迈克尔·乔丹在总决赛的最后一投、一些精彩的足球进球等等。

你可以直接把视频给模型，然后说“请帮我制作一个表格，列出每个事件是什么、发生日期以及简要描述。”

结果你会得到一个18行的结构化表格——这实际上是把视频信息转换成了类似SQL表的结构。很多人并不会把“视频理解”联想到这种具体的能力上。

谷歌搜索的演变：从分片索引到AI搜索

Alessio Fanelli： 谷歌内部有没有讨论过“照料整个互联网”这个问题？谷歌本身就是因为人类无法浏览整个互联网而存在的，通过排序系统帮助人们筛选信息。

对于大语言模型来说，排序逻辑是不是不同？人类可能只看前5个链接，但LLM是否应该关注20个高度相关的链接？你们内部是如何思考这种“更广泛的搜索模式”的？

Jeff Dean： 其实在大语言模型出现之前，我们的排序系统就已经是分层处理的了。

首先从一个巨大的索引中筛选出相关子集，可能从数十亿网页缩小到3万份候选文档，然后逐层使用更复杂的算法和信号进行精炼，最终展示前10个结果。LLM系统在本质上也是类似的。

你可以“关注”万亿级别的token，但你需要先筛选出3万份候选文档_（也许对应3000万token）_，然后进一步缩减到117份真正关键的文档，最后由最强的模型来处理这117份。

这样你就实现了一种“仿佛浏览了万亿token”的效果，就像谷歌搜索给人的感觉一样——虽然你在搜索整个互联网，但实际上系统只处理了一小部分最相关的内容。

Shawn Wang： 很多人不了解LLM在高流量系统里的渗透程度。比如BERT很早就被整合进谷歌搜索系统，提升了搜索质量。

Jeff Dean： 是的，引入LLM的表示方式之后，我们可以跳出“必须精确匹配用户输入词语”的限制，而更关注页面的主题是否与查询相关。

Shawn Wang： 其实在LLM之前，你们就已经在“软化查询词”了吧？

Jeff Dean： 没错。我在2009年的一次会议上做过回顾演讲，讲了1999到2004年间搜索系统经历的五六次架构重构。

2001年是一个关键点。当时为了扩展规模，我们把索引分片，比如分成60个分片，每个分片有多个副本。

当副本数量足够多时，我们意识到——整个索引其实可以全部放进内存！一旦索引在内存中，你就可以对用户原本只有三四个词的查询，扩展出50个相关词，比如restaurant、restaurants、cafe、bistro等等。

这是2001年的事情，远早于LLM，但本质是一样的——从“精确词匹配”走向“语义理解”。

Alessio Fanelli： 在系统设计上，你有什么原则？当规模以倍数级增长时，你是怎么思考的？

Jeff Dean： 首先要弄清楚最重要的设计参数：每秒查询数、索引规模、每个文档的数据量等等。

一个好的系统应该能承受5到10倍的增长，但如果增长到100倍，可能就需要完全不同的架构。比如从磁盘索引转为内存索引——这只有在流量足够大时才合理。

在设计之前，我喜欢在脑子里推演各种可能性，而不是一开始就写代码。

Shawn Wang： 更新频率是不是变化最大的参数？

Jeff Dean： 对。最早我们一个月更新一次索引，后来可以做到单页亚分钟级别的更新。

因为新闻类查询需要实时性。即便某个页面更新的概率很低，但如果它很重要，也值得被频繁抓取。这背后有一整套系统在判断抓取频率与页面的重要性。

用能量来衡量数据搬运成本

Shawn Wang： 说到延迟，我必须提一下你的经典文章《每个程序员都应该知道的延迟数字》。

（编者注：这是Jeff Dean在谷歌早期撰写的一篇经典内部文章，后来被公开分享。文章主要目的是帮助程序员理解计算机系统中各种操作的延迟成本，从而在设计软件和系统时能做出合理的权衡。）

Jeff Dean： 清单里大概列了八到十种关键指标，比如一次缓存未命中、一次分支预测失败、一次主存访问、从美国向荷兰发一个数据包各需要多长时间。

Shawn Wang： 顺便问一句，为什么是荷兰？是因为Chrome吗？

Jeff Dean： 不是，是因为我们当时在荷兰有数据中心。关键在于，你要能做“信封背面的估算”。这些延迟数字就是估算的原材料。

例如，设计一个图片搜索系统，结果页需要生成缩略图——你可以选择预计算，也可以实时从大图生成。那么需要多少带宽？多少次磁盘寻址？利用这些基础数字，你完全可以在30秒到1分钟内完成一次脑内推演。

随着你使用更高层的库编写软件，也应该培养类似的直觉——比如对某种数据结构的查找耗时有个大致概念。

Shawn Wang： 如果现在更新这份“延迟数字”清单，你会加入什么？

Jeff Dean： 我认为现在特别值得思考的是，在进行模型训练或推理时，你所执行的计算究竟意味着什么。

一个很好的切入视角是：你需要从内存中搬运多少“状态”？是片上SRAM？是加速器上的HBM？是DRAM？还是需要通过网络传输？

然后问一个问题：这些数据搬运的成本，相对于一次矩阵乘法中的乘法操作，要昂贵多少？实际上，乘法操作本身的能耗非常低，根据精度不同，通常小于1皮焦耳 (picojoule)。

Shawn Wang： 哦，你是用能量来衡量的？

Jeff Dean： 对，最终一切都归结为能量效率。

例如，从芯片另一侧的SRAM搬运数据，甚至都没有离开芯片——可能就需要1000皮焦耳。于是你就能明白，为什么加速器需要“批处理 (batch)”。

如果你花费1000皮焦耳将一个模型参数从SRAM搬运到乘法单元，那么你最好能多次使用它。假设批处理大小为256，这笔成本就能被摊薄；但如果批处理大小是1，那就太不划算了。

Shawn Wang： 对，因为你花了1000皮焦耳，只做了价值1皮焦耳的乘法运算。

Jeff Dean： 没错。所以从能量角度看，批处理是非常自然的选择。理想情况下我们当然希望批处理大小为1，因为延迟最低。但这会带来极差的能量效率和计算效率。

Shawn Wang： 我还是第一次听到从能量角度分析批处理的解释。

Jeff Dean： 这其实就是大家普遍采用批处理的原因。

TPU与机器学习必须协同设计

Shawn Wang： 在硬件上，有没有类似当年“把索引全部放进内存”那样的转折点？比如NVIDIA在SRAM上的激进投入。你们在设计TPU时是否也预见到了这种趋势？

Jeff Dean： TPU采用规则的2D或3D网状 (mesh) 结构，每个芯片都配有HBM。对于某些模型推理任务，从HBM读取数据的延迟和成本远高于从片上SRAM读取。

因此，如果模型足够小，你可以进行模型并行，将其分布在16或64个芯片上。只要全部参数都能放入SRAM，就能同时提升吞吐量和降低延迟。这其实是一个很自然的技术选择。

Alessio Fanelli： 在TPU设计中，你们如何决定优化方向？比如，是否可能将那1000皮焦耳的成本降到50？为此设计一颗新芯片是否值得？但机器学习领域变化如此之快，做硬件会不会风险太大？

Jeff Dean： 我们在TPU架构团队和机器学习研究团队之间保持着紧密互动，因为必须进行 “协同设计”。

问题在于：你今天开始设计一颗芯片，可能两年后才能部署到数据中心，之后还要使用三到五年。这意味着，你需要预测 两到六年后 人们会运行什么样的机器学习计算，而这个领域的变化速度极快。

因此，如果研究团队对未来两三年内可能成功的方法有深刻洞察，我们就能在“TPU N+2”版本中加入相应的硬件特性。有时可以加入一些“投机性功能”，它们只占用很小的芯片面积，但如果成功可能带来10倍的提升；即使失败，损失也不大。

但有些改动代价高昂，就必须通过大量的机器学习实验来验证方向。

Alessio Fanelli： 有没有反过来的情况？因为芯片设计已经确定，所以模型架构不得不做出调整？

Jeff Dean： 当然会有。模型架构有时会为了适配现有硬件而调整。例如，如果未来一代硬件支持更低精度，你可能会提前为那个精度训练模型，即使当前代硬件还不支持。

Shawn Wang： 那精度还能降到多低？有人说三值化 (ternary) 都可以。

Jeff Dean： 我个人很看好低精度，因为每减少一个比特，就减少了数据搬运时的能量消耗。许多成功的做法是：权重本身用极低的比特数表示，但为一组权重共享一个缩放因子。

Shawn Wang： 低精度加缩放因子？这很有意思。说到精度，我们最终是采样生成的，还会加入随机性——那进行如此精细的计算是不是有点讽刺？

Jeff Dean： 确实有很多趋势值得关注。比如能量驱动模型、扩散模型 (不再顺序解码token)、投机解码 (speculative decoding)。

例如，一次预测8个token，然后接受其中的5或6个，这相当于将有效批处理大小提升了5倍，大幅摊薄了参数搬运的成本。从能量、延迟、吞吐量的角度思考问题，会自然地引导你找到更优的解决方案。

Shawn Wang： 还有像模拟计算这样更激进的方向呢？

Jeff Dean： 模拟计算很有意思，理论上功耗极低。但在现实中，你往往需要与数字系统接口，进行数模和模数转换，这会损耗掉不少能效优势。

不过我认为，在现有的数字架构下，我们在能效方面仍有巨大的提升空间。

几个新的研究视角

Alessio Fanelli： 从研究角度看，还有哪些方向你觉得特别值得探索？

Jeff Dean： 一个大问题是 如何让模型更可靠，能够完成更长、更复杂、包含大量子任务的工作。也许一个模型可以调用其他模型作为工具，协作完成更大规模的任务。

另一个开放问题是：如何将强化学习扩展到“不可验证”的领域。当前在数学和编程方面取得的进步，很大程度上得益于可验证的奖励信号。如果我们能在不可验证的领域也实现类似的突破，模型能力将获得巨大提升。

Alessio Fanelli： 比如Deep Research或AI Mode，本质上也是一种信息检索。是不是“检索”本身就是可验证的部分？

Jeff Dean： 可以用另一个模型来评估第一个模型的结果，例如判断检索结果是否相关，或者从2000条结果中打分并选出最相关的50条。有时甚至可以使用同一个模型，只是通过不同的提示词，让它充当“批评者”角色。

Shawn Wang： 感觉我们好像已经做完了“简单的部分”，接下来全是难啃的硬骨头。但我们每年似乎都这么觉得。

Jeff Dean： 这个领域的好处在于，有很多聪明人都在努力解决这些问题。

两年前，我们还在为GSM8K这类“小明有两只兔子又买了三只”的题目发愁。现在模型已经能够处理国际数学奥林匹克 (IMO) 和埃尔德什 (Erdős) 水平的数学推理问题，并且是以纯语言形式完成的。这在一年半内是惊人的飞跃。

对于其他领域，我们也希望实现类似的飞跃。虽然有些方向的前进路径尚不清晰，但研究本身就是一个不断尝试、验证和推进的过程，这正是它迷人的地方。

Shawn Wang： 比如说，能自动生成YouTube视频缩略图，这就非常有用了。那简直就是通用人工智能 (AGI) 了，我们真的需要它。

Shawn Wang： 对内容创作者来说，那绝对是革命性的。

Jeff Dean： 我不是YouTube创作者，所以我个人对这个问题的感受没那么强烈，不过我知道很多人确实非常在意这一点。

统一模型时代已经到来

Shawn Wang： 说回IMO，我到现在都还没完全消化一件事：一年前我们还有AlphaProof、AlphaGeometry这些专用系统，结果今年直接说“算了，全交给 Gemini 来处理”。

你怎么看待这种从“符号系统 + 专用模型”到“大型语言模型一统天下”的转变？

Jeff Dean： 这对我来说其实挺自然的。人类确实在操作符号，但我们的大脑内部未必真的是离散的符号系统。更可能是一种分布式的神经表示——由大量神经元的激活模式构成。

当我们看到某些事物时，会激活特定的思维模式，从而进行推理、规划、链式思考，甚至回退并尝试其他路径。

从这个角度看，用神经网络来模拟这一过程是合理的。我一直认为，将完全独立的离散符号系统与神经模型截然分开，并没有太多道理。

Shawn Wang： 也许这对你来说显而易见，但一年前的我并不这么认为。

Jeff Dean： 我认为，从“将问题翻译成 Lean 语言再用专用几何模型求解”，到第二年直接使用一个统一的大模型（本质上就是生产版模型，但分配了更多推理预算），这恰恰展示了通用模型能力的巨大飞跃。你不再需要那些专用系统了。

这很像 2013 到 2016 年机器学习的发展历程——那时每个任务都需要训练一个独立模型：识别街道标志用一个模型，语音识别用另一个模型。

如今，统一模型的时代已经到来。问题变成了：它们对从未见过的新任务泛化能力如何？答案是——越来越好。

Shawn Wang： 甚至不需要领域专家。我曾采访过 Ete，他说自己甚至不知道国际数学奥林匹克（IMO）在哪里举行、规则是什么，只是负责训练模型。这种“通用 ML 技能 + 数据 + 算力”就能解决各类任务的方式，在某种程度上印证了“苦涩的教训”。

Jeff Dean： 在大多数情况下，通用模型会胜出。

Shawn Wang： 但这里存在一个疑问：模型容量是有限的，参数本质上只能容纳有限的信息。例如 Gemma 这类小模型，很多人希望将其作为本地开源模型使用，但它们会记住一些并非必需的知识。

大模型可以包罗万象，但小模型容量有限。我们能否将“知识”与“推理能力”分离开？

Jeff Dean： 理想情况下，模型应将宝贵的参数空间更多地用于提升推理能力，而非记忆那些可以通过检索获取的冷门事实。比如某座偏僻小桥的长度，没必要死记硬背。但模型也不能完全脱离世界知识。

例如，知道金门大桥的大致长度有助于建立尺度感。因此，一定的常识是必要的。模型越大，能容纳的知识越多。但我认为，将检索与推理相结合——尤其是多阶段检索与推理——会让模型显得更强大。

Shawn Wang： 就像是“个人版 Gemini”。

Jeff Dean： 是的。我们不太可能将我的私人邮件数据直接训练进 Gemini 的通用模型中。更合理的做法是，使用统一模型，并通过工具让它检索我的邮件、照片等，然后对这些结果进行推理，并支持多轮交互。

垂直模型仍有意义

Alessio Fanelli： 那你如何看待垂直模型？比如“医疗 LLM”或“法律 LLM”。

Jeff Dean： 垂直模型是有意义的。它们应该基于一个强大的基础模型，然后在特定领域的数据上进行进一步强化训练。

以机器人领域为例，我们不会将所有机器人数据都塞进基础 Gemini 中，因为需要平衡其各项能力。但如果你想打造一个顶级的机器人模型，就应该在基础模型之上，使用大量机器人数据进行额外训练。

代价可能是模型的多语言能力有所下降，但机器人相关能力会更强。我们始终在进行数据分布的权衡。

理想情况是模块化：一个拥有 200 种语言能力的模块、一个顶级机器人模块、一个顶级医疗模块，可以根据需要组合调用。例如，遇到医疗问题时，就调用医疗模块来增强基础模型。

Shawn Wang： 就像“可安装的知识包”。

Jeff Dean： 没错。有些能力可以通过检索实现，有些则可能需要通过预训练来获得，例如使用上千亿 token 的医疗数据进行训练。

Shawn Wang： 谈到语言，你之前提到过一个例子：将低资源语言直接放入上下文，模型就能学习。

Jeff Dean： 是的。例如 Kalaman 语，全球大约只有 120 人使用，且没有书面文本。而对于像索马里语或阿姆哈拉语这样的语言，世界上其实存在不少文本资料。

我们在训练 Gemini 时可能只使用了其中一部分。如果增加更多数据，这些语言的能力就会得到提升。

Shawn Wang： 我对语言学也很感兴趣。如果我是语言学家，拿到这些模型，我会探究一些根本性问题。比如萨丕尔-沃尔夫假说：语言是否塑造思维？

还有所谓的“柏拉图式表示”——图像中的“杯子”和文本中的“cup”最终在模型中被映射到同一个向量空间。理论上这应该跨语言成立，但有些语言拥有独特概念，而英语没有，这些差异其实非常有意思。

Jeff Dean： 我之前参与过一个叫 DeViSE 的模型项目，它将语言模型的词向量与图像模型（类似用 ImageNet 训练的模型）的表示融合在一起。

结果发现，即使给模型一张训练集中从未出现过的类别的图像，它也常常能给出正确的标签。

例如，图像模型在训练时见过“telescope”（望远镜）和“binoculars”（双筒望远镜），但没见过“microscope”（显微镜）。然而，当给它一张显微镜的图片时，它却能正确生成“microscope”这个标签，尽管从未见过带有此标签的图像。

Shawn Wang： 这很酷。

Jeff Dean： 确实挺有意思的。

Gemini 早期资源太分散是“愚蠢”的

Shawn Wang： 最后一个问题，你希望别人多问你些什么？我们已经聊了硬件、模型和研究。

Jeff Dean： 有件事挺有趣的。我 1990 年本科毕业时，毕业论文做的就是并行神经网络训练。那时我就认为神经网络是正确的抽象方向，只是算力远远不够。

系里那台 32 处理器的并行机只能训练一些稍微有点意思的模型，远不足以解决现实问题。直到 2008、2009 年，随着摩尔定律的推进和更大数据集的出现，神经网络才开始真正解决语音、视觉、语言等问题。

我在 2011 年底于谷歌重新投入神经网络研究时，核心想法就是：我们应该利用大规模并行计算，将神经网络的规模推上去。

我甚至复活了本科论文中的模型并行和数据并行的思想——虽然当时用的名称不同，但本质就是这两种并行方式。历史有时会绕个圈再回来。

Shawn Wang： 这些资料是公开的吗？我们能在网上查到吗？

Jeff Dean： 可以，在网上都能找到。
不过，从更宏观的层面看，我认为过去十五年真正重要的一点，在于将各种技术结合起来，并且持续推动 Scaling（规模化）。

这不仅仅是算法问题，还包括硬件的进步，例如构建像 TPU 这样的专用硬件；同时也包括软件层面的抽象能力，让研究者和工程师能更好地向计算机表达他们的想法。

Shawn Wang： 关于后来对算力资源分配的反思——有人提到所谓的“算力配额市场”。

David 曾在 OpenAI 担任工程副总裁，后来又去了 Google。他的观点是，OpenAI 当时愿意“押上全部筹码”专注于一件事，而 Google 的资源分配方式更民主化，每个人都有自己的算力配额。

如果你真的相信 Scaling 是关键，那么这实际上是一个组织层面的战略选择。你当时认同这种说法吗？还是有不同的复盘结论？

Jeff Dean： 我在一定程度上同意。事实上，我当时还写过一份一页纸的备忘录，指出我们将资源拆分得太零散是“愚蠢”的。

当时的情况是：Google Research 里有团队在做大语言模型，Google Brain 团队里也有团队在做；同时，其他团队在做多模态模型；而 DeepMind 也在开发像 Chinchilla、Flamingo 这样的模型。

问题在于，我们不仅将算力分散在多个方向上，还把最优秀的人才也分散了。我当时的观点是：这没有必要。为什么不整合起来，打造一个统一的、从一开始就是多模态的、在各方面都足够强大的单一模型？

这就是 Gemini 项目的起点。

Shawn Wang： 所以那份一页纸的备忘录奏效了？另外，Gemini 这个名字也是你起的吗？

Jeff Dean： 是的，这个名字是我起的。
当时也有其他备选，但我认为“Gemini”很合适。因为这两个组织如同“双胞胎”，如今合二为一。同时，NASA早期的“双子座”（Gemini）计划也是通往“阿波罗”登月的重要一步。这个隐喻非常贴切——双子合一。

未来人均管理50个智能体实习生

Alessio Fanelli： 我很好奇你现在如何使用AI辅助编程。你一直是工程能力极强的人。你曾提到，结对编程时要找思维方式互补的伙伴。
那么，面对编码智能体，你会如何“塑造”一个与自己思维方式匹配的智能体？你如何评价当前的工具？它们未来应向什么方向发展？

Jeff Dean： 首先，编程工具相比一两年前已经有了巨大进步。现在你可以将更复杂的任务交给它们。
一个关键点是：你与模型的互动方式，会反过来塑造它的协作模式。你可以让它编写测试、进行性能优化的头脑风暴，也可以让它完全独立完成一个模块。
不同任务适合不同的交互模式。有些需要频繁互动；有些则在你清晰定义需求后，它可以独立完成。
我认为未来会有越来越多独立运行的软件智能体为你工作。核心问题在于：人机交互模型应如何设计？它何时应该打断你？何时应该独立推进？
这个问题尚无最终答案。而且，随着模型能力提升，这些交互决策也会变化。如果你有50个实习生，你会如何管理？或许你真的会想要50个——前提是他们足够优秀。

Shawn Wang： 但管理成本也会很高。

Jeff Dean： 是的。但你可能会将他们分成小组，而非直接管理50个人。
同理，如果一个人管理50个虚拟智能体，而不是50位真人工程师，组织结构和沟通带宽或许会更高效。
设想五位工程师各自管理50个智能体，他们彼此之间可能反而能进行更高带宽的交流，而不必每个人都去协调一个50人的团队。

Alessio Fanelli： 你觉得这种模式是否会导致人变得更孤立？例如，你想找人进行“结对编程”，但现在已经有50个智能体并行完成了大量工作，向他人讲清楚上下文反而可能更困难。

Jeff Dean： 有可能。但传统的软件组织本就高度分工。50个人在不同模块上工作，原本也不会高频互动。
如果是5个人各自管理50个智能体，反而可能在这5人之间形成更高效的协作结构。具体会如何演化，目前还不确定。

“写好需求”将成为核心技能

Alessio Fanelli： 那么你的工作节奏会如何改变？是否需要在设计和规格说明上投入更多时间？

Jeff Dean： 我认为这是一个非常关键的变化。过去我们都被教导要撰写清晰的规格说明，但说实话，并非所有人都真正重视这份“书面文档”。
但如果你让一个智能体为你编写代码，你就必须把规格说明写得极其清晰。因为输出质量完全取决于你如何定义问题。如果你没有写清楚某个边界情况，或未强调性能要求，模型很可能就会忽略它们。
因此，我认为未来一项重要的能力是：以非常精确、无歧义的方式表达你的需求。这不仅对软件工程至关重要，对任何复杂任务都是核心能力。
能够“清晰表达需求”，将成为一项核心技能。

Shawn Wang： 我常开的一个玩笑是：高级别的执行沟通（executive communication）在某种程度上已接近“魔法”——就像撰写内部备忘录，你必须极其谨慎地权衡措辞。我认为现在的提示工程也越来越像这种沟通艺术。
同时，“多模态”至关重要。例如，Google早期推出的一些模型就强调强大的多模态能力，包括视频理解。这实际上是为模型提供了最高带宽的输入方式，是一种极其强大的沟通手段。

Alessio Fanelli： 你如何处理自己脑中那些经验性的知识？比如你对性能优化有很强的“直觉”，知道哪些地方可能有提升空间。
现在，是否更有价值将这些通用经验系统地记录下来，作为可检索的资料提供给模型？
以边界情况为例——过去你脑中自然会想到某些特定场景，现在是否每次都需要明确写出来？你会建议人们花更多时间撰写这类“通用指南”吗？

Jeff Dean： 我确实认为，高质量的软件工程指南将变得更重要。因为它们既可作为模型的输入上下文，也可供其他工程师阅读，从而帮助他们写出更清晰的提示。
未必需要为每个具体问题都撰写专门文档，但如果你有一些通用指南，并将其置入编码智能体的上下文中，那将非常有帮助。
例如，在分布式系统中，你可以列出常见故障类型及对应的处理技术。比如Paxos这类复制协议，或是“向两个节点发送请求，只需一个返回即可实现容错”的策略。
如果你撰写一份包含20种此类技术的简明说明，很可能帮助编码智能体构建出更可靠、更健壮的分布式系统。

模型的“个性化”与低延迟将极其重要

Shawn Wang： 回到提示与迭代的话题。我一直想做一个A/B测试：
是进行三次“快速但能力一般”的模型调用，每次都由人类校准效果更好？还是撰写一个非常长、非常详尽的提示，然后让一个强大的模型一次性完成更好？
很多时候效果不佳，是因为你没有写清需求，而非模型能力不足。模型其实可以生成10种合理结果，而你只想要其中1种。

Jeff Dean： 对，本质上是“需求定义不足”。如果问题未被清晰界定，模型只能猜测。而多轮快速交互，往往足以逼近你真正想要的结果。
我个人非常相信“低延迟”的价值。 低延迟交互会让系统使用体验变得愉悦得多。如果响应慢上10倍或20倍，体验将完全不同。
未来我们将看到模型及底层软硬件系统带来20倍甚至50倍的延迟下降。这对于那些需要在每次交互间完成大量内部计算的系统至关重要。

Shawn Wang： 但另一方面，也有像DeepThink这样强调深度推理、但延迟较高的模型。

Jeff Dean： 如果成本和延迟不是问题，你当然会一直使用DeepThink。
假设硬件提升带来20倍的延迟降低，你自然希望模型具备更强的推理能力。但有趣的是，当硬件变快后，人们往往又会设计出更复杂的模型，再次将时间资源用满。

Shawn Wang： 帕累托前沿总是在向上移动。最后问一个预测性问题：有没有哪些你现在还不满意、但认为很快会实现的能力？

Jeff Dean： 我给出两个预测。
第一，真正“个性化”的模型将变得极其重要。 一个了解你、掌握你所有状态、并能在你授权范围内检索你全部历史信息（如看过的邮件、照片、视频）的模型，将比通用模型强大得多。

第二，更专用化的硬件将推动模型延迟大幅下降，同时能力提升、成本下降。这将改变许多应用场景。

Shawn Wang： 人们常用“每秒生成token数”来衡量速度。例如，现在若是100 tokens/s，提升到1000有意义吗？10000呢？

Jeff Dean： 当然有意义。
更高的tokens/s意味着你可以进行更多并行展开（rollout），生成更多代码，或在生成背后进行大量思维链推理与验证。10,000 tokens/s 将非常强大。

Shawn Wang： 达到那种速度，你可能都不会去读生成的代码了。

Jeff Dean： 未必。也许最终代码只有1000 tokens，但背后却用了9000 tokens进行推理。这样生成的代码，反而更值得阅读。

参考链接：
https://www.youtube.com/watch?v=F_1oDPWxpFQ

关注“鲸栖”小程序，掌握最新AI资讯