Jeff Dean万字访谈：我们正在杀死割裂AI应用，2026是大一统元年

谷歌最资深的传奇人物之一杰夫·迪恩（Jeff Dean）的开年访谈来了。自 1999 年加入谷歌至今，他堪称是谷歌稳若磐石般的存在，不仅是打下谷歌技术基石的奠基者，也是谷歌 AI 的核心推动者之一。

图 | 杰夫·迪恩（Jeff Dean）（来源：Google）

从早期的 MapReduce、BigTable 等谷歌基础设施，到引领深度学习的规模化革命，再到如今主导 Gemini 系列模型的研发，他的技术事业贯穿了谷歌的整个发展历史。

在 2026 年 2 月的这场开年访谈中，他谈到了人类未来可能会拥有自己的个人专属 Gemini，能在经允许后访问个人邮件和照片在内的你的所有网络内容。

他还提到了 AI 能力的演进：“最终肯定个不是 10,000 tokens 的代码，而是 1,000 tokens 的代码，背后带着 9,000 tokens 的推理过程。这实际上可能是更好读的代码。”这句话揭示了 AI 发展的新方向之一，那就是让模型在思考上花费更多时间，而非单纯地追求输出规模。

在这场横跨硬件、模型与未来预言的深度对话中，Jeff Dean 用他贯穿谷歌四分之一个世纪的技术视野，为我们勾勒出 AI 发展的清晰脉络。从蒸馏到稀疏，从 TPU 到万亿 tokens 的幻觉，最终指向那个朴素而深刻的真理，未来的代码或许更短，但藏在背后的思考将更长。

以下为 DeepTech 基于采访原文做的访谈整理。

访谈全文：

关于帕累托前沿

主持人：能请到你来演播室，感觉有点不太真实。我看过你太多的演讲，你的职业生涯堪称传奇。我想首先必须得说，恭喜你登上了帕累托前沿。（编者注：帕累托前沿指在资源有限的情况下，无法在不损害另一目标的前提下让某个目标变得更好。Jeff Dean 团队在模型性能和效率上都做到了极致，占据了这片前沿地带。）

Jeff Dean：谢谢。帕累托前沿是个好东西，能站在上面感觉很好。

主持人：我认为这是两方面的结合。你既要站在能力的前沿，也要兼顾效率，然后提供人们喜欢使用的那个模型系列。这其中的一部分始于你们的硬件工作，一部分是你们的模型工作。我相信你们累积研究了很多秘诀，但看到所有这些汇聚在一起，不断推动前沿向前发展，真的很令人印象深刻。

Jeff Dean：是的，这不仅仅是单一的一件事。而是整个技术栈从上到下的一整套东西。你知道，所有这些结合在一起，让我们能够训练出能力超强的大模型。同时，也通过软件技术，将那些大模型的能力提炼到更小、更轻量的模型中，这些模型成本效益更高、延迟更低，但就其规模而言，仍然相当有能力。

主持人：在保持帕累托前沿的底线方面，你们有多大压力？我认为初创公司总是试图冲击最高性能的前沿，因为他们需要筹集更多资金之类的。而你们拥有数十亿的用户。我想，最初你们在打造数据中心时，会考虑到如果每个使用谷歌的人，每天用我们的语音模型三分钟，那你们需要的算力数量就要翻倍。如今在谷歌内部，这种讨论是怎样的呢？比如，你们如何权衡追求前沿与“如果我们造出来了，就得实际部署它”这二者之间的关系？

Jeff Dean：我认为我们总是希望拥有处于前沿或能够推动前沿的模型，因为这样你才能看到，与去年、与六个月前能力稍逊的版本相比，现在出现了哪些以前不存在的新能力。这些前沿模型对很多应用场景会非常有用，但对于其他更广泛的应用场景来说，它们可能会有点慢，也有点贵。所以，我认为我们想做的，是始终拥有一种能力很强、价格又亲民的模型，它能够支持大量低延迟的应用场景。人们可以更自如地用它来做智能体编程，同时我们也有高端的、处于前沿的模型，它对于深度推理、解决极其复杂的数学问题这类事情非常有用。

并不是说这一个或那一个才有用，它们都有用。所以，我认为我们两者都要做。蒸馏是让小型模型能力更强的一个关键技术，你必须先有前沿模型，然后才能把它蒸馏到你的小型模型里。所以这不是一个二选一的问题。为了真正获得一个能力强大但规模适中的模型，你某种程度上需要那个前沿模型。

关于蒸馏

主持人：你和杰弗里·辛顿（Geoffrey Hinton）、还有 Oriol 在 2014 年就提出了这个方案。（编者注：奥里奥尔·维尼亚尔斯（Oriol Vinyals）是 Google DeepMind 的研究副总裁，也是 Gemini 项目的联合技术负责人。他于 2013 年加入 Google，是序列到序列学习（seq2seq）和知识蒸馏技术的开创者之一。）

Jeff Dean：还有 Andrew 也是。（编者注： Andrew Dai 是谷歌 DeepMind 的资深研究员，2012 年就已加入谷歌。他曾与 Jeff Dean 等人合著多篇论文，并担任过 Gemini 模型预训练数据工作的联合负责人。）

主持人：我很好奇，你怎么看待这些想法的循环周期？比如，稀疏模型也是。你怎么评估它们？在开发下一代模型时，你怎么考虑哪些东西值得重新审视？你研究过那么多想法，它们都很有影响力，但在当时，感觉可能并非如此。

Jeff Dean：我认为蒸馏最初的动机是因为当时我们有一个非常大的图像数据集，大概三亿张图像，我们可以用来训练，我记得大概有两万个类别，比 ImageNet 大多了。我们当时发现，如果你为这些图像类别的不同子集创建专家模型，比如这个模型特别擅长识别哺乳动物，那个模型特别擅长识别室内场景之类的，你可以将这些类别聚类，在更广泛的图像集上进行预训练后，再用增强的数据流进行训练。如果你把训练好的那几十个模型当作一个大的集成模型，性能会好很多。

但这对于服务部署来说，不太现实，对吧？所以，蒸馏的想法就来源于：如果我们真想部署这个东西，训练所有这些独立的专家模型，然后把它们压缩成一个实际能部署的形式，该怎么办？这和我们现在做的也没什么不同。如今，我们往往不是用 50 个模型的集成，而是有一个规模大得多的模型，然后把它蒸馏成一个规模小得多的模型。

主持人：我有时也在想，蒸馏是否也与强化学习革命有关联。让我试着阐述一下我的意思：你可以通过强化学习在分布的某个特定部分提升模型能力。你可以针对模型进行强化，但这通常可能会在其他领域造成损失。这是一种不太均衡的技术，但你也许可以再把它蒸馏回来。我认为，一个普遍的梦想是，能够在不导致其他任何方面退步的情况下提升能力。这种能力合并而不损失的过程。我感觉，某种程度上，这应该是一个蒸馏过程，但我没法完全说清楚。我没看到太多相关的论文。

Jeff Dean：我倾向于认为蒸馏的一个关键优势在于，你可以有一个小得多的模型，同时拥有一个非常大的训练数据集。你可以从多次遍历这个数据集中获得效用，因为你现在从大模型中获得了 logits，这有助于引导小模型表现出正确的行为，而仅仅使用硬标签是做不到这一点的。

所以我认为我们观察到的是，通过蒸馏方法你可以获得与大模型性能“非常接近”的结果。对很多人来说，这似乎是一个很好的平衡点，在 Gemini 的好几代模型中都是如此。我们已经能够让下一代模型的 Flash 版本，达到甚至远超上一代 Pro 版本的水平。我认为我们会继续努力这样做，因为这似乎是个值得遵循的好趋势。（编者注：“logits”是指模型在最终通过 softmax 层输出概率之前，那一层的原始输出向量包含了比“是/否”硬标签更丰富的软信息。）

主持人：原来你们的产品线是 Flash、Pro 和 Ultra。你们是直接把 Ultra 放在那里，作为教师模型去蒸馏出其他模型的吗？它就相当于旗舰或者说母舰一样的存在？

Jeff Dean：我们有很多不同类型的模型。有些是内部的，不一定发布或提供服务。有些是我们的 Pro 规模模型，我们也可以从它蒸馏出我们的 Flash 规模模型。所以我认为，这是一套很重要的能力。而且，推理时扩展也可以是一种提高模型能力的有用方法。

主持人：我认为 Flash 的量大管饱让它占据了统治地位。我听到的最新数字是 50 万亿 tokens。我不知道，显然每天都在变。但你知道，按市场份额算。

Jeff Dean：希望是往上涨。

主持人：不，我的意思是，从经济学角度看，因为 Flash 非常经济，你可以把它用在所有地方。它现在就在 Gmail 里，在 YouTube 里，无处不在。

Jeff Dean：我们在搜索产品中也更多地使用它，比如 AI 模式、AI 摘要。

主持人：是的，Flash 驱动了 AI 模式。是的，我之前就该想到的。

Jeff Dean：我的意思是，我认为 Flash 模型一个非常好的地方，不仅是它更实惠，而且延迟也更低。我认为延迟实际上是这些模型一个非常重要的特性，因为我们希望模型能做更复杂的事情，这涉及到从你要求模型做事到它实际完成之间，需要生成更多的 tokens。因为你现在要求的，不只是“给我写个 for 循环”，而是“给我写一整个软件包来做某某事”。所以，拥有能够做到这一点的低延迟系统，看起来至关重要。Flash 是实现这一点的一个方向和一种方式。显然，我们的硬件平台也为我们服务栈的许多有趣方面提供了可能，比如 TPU 芯片间的互连性能非常高，非常有利于例如长上下文的注意力操作。拥有包含大量专家的稀疏模型，这些东西对于如何让模型在大规模下可服务真的、真的很重要。（编者注：“for 循环”是编程中的基础概念，指一段重复执行特定次数的代码结构。）

主持人：对于像 Flash 蒸馏这种差不多晚一代的模式，会不会感觉存在某个突破点？我经常在想，差不多就像某些任务上的能力渐近线。今天的 Pro 模型在某种任务上可能已经饱和了。那么下一代，同样的任务会在 Flash 的价格点上饱和。而且我认为，对于人们使用模型的大部分事情来说，到某个时候，两代之后的 Flash 模型基本上就能做所有事了。那么，当大部分用户都对 Flash 模型感到满意时，你如何让继续推动 Pro 前沿这件事在经济上划算呢？我很好奇你怎么看这个问题。

Jeff Dean：如果人们要求模型做的事情分布不变，那确实如此。但我认为，通常情况下，随着模型能力变得更强，人们会要求它们做更多的事情。所以，我认为这在我自己的使用中也发生了。一年前，我会用我们的模型来做一些编程任务。它在一些简单的事情上还行，但在更复杂的事情上就效果不佳。从那以后，我们在更复杂的编程任务上取得了巨大的进步。现在我会让它做复杂得多的事情。

而且我认为，这不仅限于编程。比如，现在你可以问：“你能分析一下全球所有的可再生能源部署情况，给我一份关于太阳能电池板部署的报告吗？” 这是一个非常复杂的任务，比一年前人们通常会问的任务要复杂得多。所以，在某种意义上，你会需要能力更强的模型，来拓展人们要求模型去完成的任务的边界。这也反过来给了我们灵感：模型在哪些地方会失效？我们如何在这些特定领域改进模型，以便让下一代变得更好。

（来源：Gemini 生成）

关于 benchmark

主持人：你们内部会用什么 benchmarks 或测试集吗？因为几乎每次报道的都是同样的 benchmarks。就像从 90 分变成了 97 分。你如何持续推动团队内部，告诉他们“这就是我们要努力的方向”？

Jeff Dean：我认为 benchmarks 尤其是那些公开的外部 benchmarks 有其用处，但它们往往有一个效用生命周期。它们被引入时，可能对当时的模型来说相当难。我喜欢这么想：最好的 benchmarks 是那些初始得分在 10% 到 20% 或 30% 左右的，而不是更高的。

然后你可以致力于提高该 benchmark 旨在评估的某种能力，把它提升到 80%、90% 或其他任何水平。我认为一旦它达到 95% 左右，如果真的一门心思扑在这个 benchmark 上，能得到的回报会越来越少。因为这要么意味着你已经具备了那种能力，要么就存在公开数据泄露或者非常相关的数据混入了训练数据的问题。

所以我们有一整套保密的内部 benchmarks 来真正评估模型。我们知道这些数据完全不在训练集中，它们代表了我们希望模型拥有但目前还不具备的能力。然后我们就可以着手评估：我们如何让模型在这些方面变得更好？是我们需要不同类型、更专门针对这类任务的数据来训练？还是我们需要一些架构上的改进，或者某种模型能力的提升？什么会帮助改进它？

主持人：有没有这样一个例子，某个 benchmark 激发了一个架构上的改进？

Jeff Dean：Gemini 模型的一些长上下文能力，其实最早大概是在 1.5 版本就开始布局了。

主持人：我当时就在想，大家怎么能在同一时间都练成这个的？

Jeff Dean：正如你所说，那个考察细颗粒度的 benchmark，至少在 128K 左右的上下文长度上，现在已经饱和了。我认为如今大多数人实际上并没有用到远超 128K 或 256K 的上下文。而我们正试图将前沿推进到 100 万或 200 万上下文。

主持人：我觉得谷歌仍然是这方面的领先者。

Jeff Dean：这很好，因为我认为有很多应用场景，比如把上千页的文本，或者多个长达一小时的视频放到上下文中，然后能够实际利用起来，这非常有用。但那个简单的考察细颗粒度的 benchmark 已经饱和了。所以你真正想要的是更复杂、更贴近现实的场景：读完所有内容，最后给出答案。这样才能更好地评估人们真正想用长上下文做什么，而不仅仅是“你能告诉我这个特定东西的产品编号吗？” 那样只是检索。

主持人：没错，是在机器学习中进行检索。我想探讨的更深一层的问题是：当你手握一个 benchmark ，发现了一个能搞定它的架构技巧，这时你会怎么做？因为有时候你知道那本质上是在引入一个归纳偏置。就像以前在谷歌工作的 Jason 会说的那样，差不多就是这个意思。短期内你会赢，但长期来看，我不知道这是否能扩展，你可能之后得推翻重来。（编者注：Jason 指曾在谷歌大脑工作的著名 AI 科学家 Jason Wei。他最为人所知的贡献是提出了思维链概念，是大模型推理领域的开创性人物，后来加入 OpenAI 成为 o1 模型的关键奠基人之一。）

Jeff Dean：我倾向于不拘泥于具体的解决方案，而是聚焦于我们到底想要什么能力。而且我深信长上下文非常有用，但今天它的长度还远远不够，对吧？我认为你真正想要的是，能不能在我回答问题的时候，关注整个互联网？但这无法通过单纯扩展现有的（复杂度是二次的）方案来解决。所以，100 万 tokens 已经接近现有方案的极限了。你不可能做到 1 万亿 tokens，更别说 10 亿 tokens 了，更别提一万亿。

但我认为，如果你能营造出可以关注万亿 tokens 的幻觉，那就太棒了。你会为它找到各种用途。你就能关注整个互联网。你可以关注 YouTube 的像素，以及我们可以为单个视频形成的更深层表示，并且是跨越许多视频的。在个人 Gemini 层面，在你许可的情况下，你可以关注你所有的个人状态。比如你的邮件、你的照片、你的文档、你的机票。我认为那真的、真的会非常有用。问题在于，你如何通过算法层面的改进和系统层面的改进来打造一些方法，让你能够真正以有意义的方式关注万亿级别的 tokens。

主持人：顺便提一下，我算过，如果你每天说八小时的话，每天不停地说，最多也只能产生大约 10 万 tokens。这应该能很舒服地放进上下文了。

Jeff Dean：对啊，那要是再加上一个要求：我想理解大家上传到视频里的每一帧画面呢？

（来源：Gemini 生成）

关于多模态

主持人：还有一个经典的例子是，当谷歌开始超越语言，进入蛋白质或者其他信息密度极高的领域。

Jeff Dean：我认为 Gemini 的多模态特性之一，就是我们从一开始就希望它是多模态的。所以，有时这对人们来说意味着文本、图像和视频，以及音频这些人类相关的模态。但我认为，让 Gemini 了解非人类模态也非常有用。比如来自 Waymo 车辆的激光雷达传感器数据，或者来自机器人的数据，或者各种健康模态的数据，比如 X 光片、核磁共振成像、基因组信息。

我认为可能有上百种数据模态，你会希望模型能够至少接触到这样一个事实：这是一个有趣的模态，在世界上有特定的含义。这样，即使你没有在所有激光雷达数据或核磁共振成像数据上训练过，因为也许从你在主要预训练数据混合中的权衡来看，包含这些数据不合理，但至少包含一点点实际上是非常有用的，因为它能提示模型，世界上有这个东西存在。

主持人：既然我们聊到这个话题了。有些问题我正好可以问问你，是否存在某些王炸模态，凌驾于所有其他模态之上？举个简单的例子，视觉可以在像素层面编码文本，DeepMind 有篇论文就是这么做的。视觉也被证明可能可以融合音频，因为你可以做音频的语谱图，这也可以被视为一种视觉能力。所以也许视觉就是那个关键模态？

Jeff Dean：我的意思是，视觉和运动是相当重要的东西。我们选择视频，而非静态图像。生命进化之所以把眼睛这个器官独立发明了 23 次，不是没有原因的。因为感知你周围的世界是如此有用的能力。这正是我们希望这些模型能够做到的：解读我们看到或关注的事物，然后利用这些信息帮助我们做事。

主持人：我认为 Gemini 仍然是目前唯一原生具备视频理解能力的模型，所以我一直在 YouTube 上用它。

Jeff Dean：实际上，我觉得人们不一定意识到 Gemini 模型在处理视频方面能做什么。我在一次演讲中用过一个例子。那是一个 YouTube 精彩集锦视频，汇集了过去 20 年里 18 个难忘的体育时刻之类的。里面有迈克尔·乔丹（Michael Jordan）在总决赛最后时刻的跳投，还有一些足球进球等等。你可以直接把视频给它，然后说：“你能帮我做个表格吗？列出所有这些不同的事件，发生的时间，以及简短描述。”然后你就会得到一个 18 行的表格，里面是从视频中提取出来的信息。你知道吗，这种把视频直接变成表格的能力，一般人根本想不到。

（来源：Gemini 生成）

关于 AI 搜索

主持人：谷歌内部有没有讨论过，就像你提到的，要关注整个互联网？谷歌的存在，很大程度上就是因为人类无法关注整个互联网，需要某种排序来找到需要的东西。这种排序对于大模型来说会大不相同，因为你可以期望用户查看谷歌搜索结果中排名前五六的链接。而对于大模型，你是否应该期望它有 20 个高度相关的链接？你们内部是如何思考，如何构建 AI 模式的？那种模式，可能需要比面向人类的搜索更广泛、跨度更大。

Jeff Dean：我认为即使在语言模型出现之前，我们的排序系统也是从一个巨大的网页索引库开始的。其中很多网页是不相关的。所以你会用非常轻量级的方法，先识别出一个相关的子集，比如筛选到 3 万个文档左右。然后你逐步细化，应用越来越复杂的算法和各种信号，最终得到你展示给用户的东西，也就是最终的 10 条结果，或者 10 条结果加上其他信息。我认为一个基于大模型的系统也不会有什么不同，你会去关注万亿级别的 tokens，但你会想先识别出，大概哪 3 万个左右的文档（或许有 3,000 万感兴趣的 tokens）是相关的？然后你如何从这 3 万缩小到那 117 个我应该真正关注的文档，以便完成用户要求我做的任务？

我认为，你可以想象这样一个系统：你有大量高度并行的处理，可能用非常轻量级的模型来识别最初的 3 万个候选。然后你有一些系统，可能用稍微复杂一点的模型或模型集，帮你从 3 万缩小到 117 个。最后，最终的模型可能是你能力最强的模型，它来审视这 117 个东西。所以我认为会是这样的系统。这种系统让你能够营造出关注万亿 tokens 的“幻觉”，就像你用谷歌搜索，并不是产生了什么幻觉，而是你真的在检索整个互联网，只不过最终看到的只是一个极小的相关子集。

主持人：我经常告诉很多不熟悉谷歌搜索历史的人，你看，BERT 几乎立刻就被用到了谷歌搜索里，它极大地提升了搜索结果的质量。我手头没有具体数字，但我敢肯定，这对谷歌来说显然是最重要的数字。

Jeff Dean：是的，我认为采用基于大模型的文本和词汇表示，能够让你摆脱“特定词汇必须出现”这种显式硬性要求，真正深入到“这个页面或这段落的主题与这个查询高度相关”的层面。

主持人：我认为人们没有意识到大模型已经占据了所有高流量系统。所有这些非常高流量的系统，比如谷歌搜索，比如 YouTube。YouTube 有个语义 ID 系统，它用一个码本（codebook）来预测视频，词汇表中的每个条目对应一个 YouTube 视频。这对于 YouTube 的规模来说简直是不可思议的。最近，xAI 的 Grok 也用了类似的东西。

Jeff Dean：我想指出的是，甚至在语言模型被广泛用于搜索之前，我们就已经非常重视软化用户实际输入查询的概念。我实际上在 2009 年的网络搜索与数据挖掘会议上做过一个演讲。我们从未真正发表过关于谷歌搜索起源的论文，但我们回顾了从 1999 年到 2004 或 2005 年，大约四到五代、五六代搜索检索系统的重新设计。

那个演讲讲的就是这段演变，其中一件真正发生在 2001 年的事情是，我们正努力在多个维度上扩展系统。一个是我们想扩大索引，这样就能从更大的索引库中检索，这通常总能提升质量，因为如果你的索引里没有这个页面，你肯定没法处理得好。然后我们也需要扩展我们的容量，因为我们的流量增长得非常快。

所以我们有了一个分片系统：随着索引增长，你需要更多的分片。比如你有 30 个分片，如果你想将索引大小翻倍，就做成 60 个分片，这样就能限制任何用户查询的响应延迟。然后随着流量增长，你为每个分片添加更多的副本。

我们最终做了一个计算，发现如果我们有一个数据中心，里面有比如 60 个分片，每个分片 20 个副本，那我们现在就有了 12,200 台带硬盘的机器。我们一算，心想：这个索引的一份副本，其实可以放在这 12,200 台机器的内存里。所以在 2001 年，我们把整个索引放到了内存里。从质量角度来看，这带来的好处是惊人的。因为在此之前，你必须非常小心地控制对一个查询要考察多少个不同的词项，因为每一个词项都意味着要在 60 个分片中的每一个上进行一次磁盘寻道。

所以，当你扩大索引时，这变得更加低效。但一旦你把整个索引都放进了内存，即使对用户原始的三四个词的查询，你抛出 50 个词项也完全没问题。因为你现在可以添加同义词，比如 restaurant 和 restaurants 和 cafe 和 bistro 等等。突然间，你可以真正开始理解词的含义，而不仅仅是用户输入的精确语义形式。那是 2001 年，远在大模型出现之前。但这确实是在软化用户输入的严格定义，以便触及意义本身。

主持人：你在设计系统时，尤其是考虑到在 2001 年互联网的规模每年翻两三倍，使用什么原则？不是像现在这样。而且我认为今天在大模型领域也是如此，每年规模都在跳跃，能力增长如此之快。你在思考这些问题时，有什么原则吗？

Jeff Dean：首先，任何时候设计系统，你都要理解哪些设计参数对于设计来说最重要。所以你要知道，你需要处理每秒多少查询？你需要处理多大的索引？你需要为索引中的每个文档保留多少数据？当你检索时，如何查看它们？如果流量翻倍或翻三倍，系统还能正常工作吗？我认为一个好的设计原则是，你希望设计一个系统，使得最重要的特性能够扩展 5 到 10 倍，但可能不超过这个范围。

因为经常发生的情况是，如果你为一个规模 x 设计系统，而某些东西突然变成了 100x，那就会开启一个完全不同的设计空间点。这个点在 x 规模下没有意义，但突然到了 100x 就完全合理了。比如，从基于磁盘的索引转向内存索引，一旦你有足够的流量，就非常有意义了。因为现在，你在磁盘上有足够多的状态副本，这些机器现在实际上可以把一份完整的索引放到内存里了。是的，这突然间开启了一个以前不切实际的完全不同的设计。

所以，我的意思是，我非常喜欢在脑子里过一遍设计，在实际写大量代码之前，稍微在设计空间里探索一下。但是，正如你所说，在谷歌早期，我们大幅扩展索引，我们也大幅扩展索引的更新率。令人惊讶的是，更新率实际上变成了变化最大的参数。过去是每月更新一次。是的，后来我们变成了一个系统，可以在不到一分钟内更新任何一个特定的页面。

主持人：这是竞争优势。

Jeff Dean：因为对新闻搜索来说，索引上个月的老新闻，对新问题根本没用。

主持人：有没有想过，你可以把它拆分到另一个独立系统上？

Jeff Dean：嗯，我们确实推出了谷歌新闻产品，但你也希望人们输入主搜索框的新闻相关查询也能及时更新。

主持人：然后你还得判断页面的重要性，决定哪些页面值得被优先更新。

Jeff Dean：是的，幕后有一套完整的系统，试图决定页面的更新速率和重要性。所以即使某个页面的更新速率看起来很低，你可能仍然希望经常重新抓取重要的页面，因为它们改变的可能性可能很低，但拥有更新版本的价值很高。

（来源：Gemini 生成）

关于延迟

主持人：你提到了延迟，这让我想起你的一个经典之作，我不得不提，那就是“每个程序员都应该知道的延迟数字”，当时有什么背景故事吗？（编者注：“每个程序员都应该知道的延迟数字”是 Jeff Dean 在系统设计演讲中列出的一张经典表格，用于帮助工程师在设计系统时进行粗略估算。这些数字展示了计算机各类操作的典型耗时，核心在于理解不同操作之间的数量级差距，而不是纠结于绝对数值。）

Jeff Dean：“每个程序员都应该知道的延迟数字”表格里面列出了大概 8 到 10 种不同的指标，比如一次缓存未命中需要多长时间？一次分支预测错误需要多长时间？一次主内存访问需要多长时间？把一个数据包从美国发送到荷兰（或者荷兰的某个地方）需要多长时间？

主持人：顺便问一下，是因为 Chrome 吗？

Jeff Dean：我们在那边有数据中心。所以，我的意思是，我认为这归根结底是为了能够进行粗略的心算。这些就是心算的基本素材。你可以用它们来推算：好吧，如果我需要设计一个做图片搜索和结果页缩略图生成的系统，我该怎么做？我可以预计算图片缩略图，也可以尝试从大图上实时生成缩略图。那样做会有什么后果？需要多少磁盘带宽？会产生多少次磁盘 I/O？你可以用这些基本数字，在 30 秒或一分钟内，在心里做做思想实验。然后，当你使用更高级的库构建软件时，你也想培养类似的直觉。比如，在我用的这种特定哈希表里查找一个东西需要多长时间？或者，对一百万个数字进行排序需要多长时间之类的。

主持人：我提起这个其实是因为大概两年来我一直在尝试总结出“每个 AI 程序员都应该知道的数字”。好吧，我还没有一个很好的版本，因为这不是物理常数，像你这里列出的都是物理常数，但我觉得确实应该有。举个简单的例子，参数数量到磁盘大小的换算，不过是简单的字节转换，没什么意思。我想知道的是，如果要更新你的那份延迟数字列表，你会怎么做？

Jeff Dean：我认为，要好好思考一下你在模型中进行的计算，无论是训练还是推理，都非常有用。通常一个很好的思考角度是：你需要从内存中加载多少状态？是从芯片上的 SRAM、加速器附带的 HBM、DRAM，还是通过网络加载？这些数据移动的成本，与比如在矩阵乘法单元中进行一次实际乘法运算的成本相比，有多高？而乘法运算的成本实际上非常、非常低，对吧？因为，根据你的精度，大概是亚皮焦、1 皮焦耳左右。

主持人：你用能量来衡量？

Jeff Dean：这最终都会归结为能量。以及你如何让一个系统的能效最高。然后，将数据从芯片另一端的 SRAM 移过来，甚至不是片外，只是同一芯片的另一端，可能就需要，一千皮焦耳？所以这就解释了为什么加速器需要批处理，因为如果你把一个模型的参数比如说从芯片上的 SRAM 移到乘法器单元里，这要花掉你一千皮焦耳。

所以你最好能多次利用你移动过来的那个东西。这就是 batch 维度发挥作用的地方。因为突然间，如果你有一个 250 的 batch 之类的那还好，但如果 batch size 是 1 那就真的很糟糕了。因为你花了一千皮焦耳，却只做了一次一皮焦耳的乘法。

主持人：我从未听过基于能量的批处理分析。

Jeff Dean：这就是人们做批处理的原因。理想情况下，你会希望使用 batch size 1，因为延迟会很棒，但能量成本和计算成本的低效会非常大。

（来源：Gemini 生成）

关于 TPU

主持人：就像你当年把所有东西放进内存一样，现在也有很多类似的计算。我认为，显然英伟达通过大力押注 SRAM（比如他们的 H200 芯片）取得了很大成功。我想知道，这是否是你在 TPU 上已经看到的东西？因为你们必须在自己规模上提供服务。你可能某种程度上预见到了这一点。有哪些硬件创新或见解，是因为你们看到的这些需求而形成的？

Jeff Dean：TPU 采用规整的 2D 或 3D 网格拓扑结构，将大量芯片互联在一起，每个芯片都配备了 HBM。对于服务某些类型的模型，从 HBM 加载东西的成本和时间延迟，远比从芯片上的 SRAM 加载要高。所以，如果你的模型足够小，你实际上可以对其进行模型并行，分布到许多芯片上，你会从中获得相当好的吞吐量提升和延迟改善。你现在相当于把你的小型模型条带化到比如 16 或 64 个芯片上。但如果你这样做，并且模型全部能放进 SRAM，那可能是个巨大的胜利。所以这不是意外，但确实是个好技术。

主持人：再谈到 TPU 的设计，你们如何确定架构改进的优先级？比如，将一次数据移动的能耗从 1,000 皮焦耳降至 50 皮焦耳，这样的优化目标是否足以驱动一款新芯片的研发？极端情况下，当人们说“你应该把模型烧录到 ASIC 上”，那差不多是最极端的思路。当事物变化如此之快时，在硬件上投入多少是值得的？谷歌内部的讨论是怎样的？

Jeff Dean：我们内部有非常紧密的协作，比如 TPU 芯片架构团队与高级建模专家之间就保持着高频互动。因为我们真的想利用协同设计的能力，根据我们对机器学习研究未来发展方向的预判，来决定未来的 TPU 应该是什么样子。因为，作为一名特别是专注于机器学习的硬件设计师，你试图从今天开始设计一款芯片。这个设计可能需要两年时间才能最终部署到数据中心。然后它还需要有一个合理的生命周期，可能再用三、四、五年。所以，我们需要预测未来两到六年，在这个瞬息万变的领域里，人们会想用机器学习做什么。而拥有那些具备前瞻性研究想法的人才，能帮助我们判断哪些技术趋势将在未来变得重要，从而把这些有趣的硬件特性提前布局到，比如说，我们的下一代产品 TPU n+2 中。

主持人：周期是 n+2。

Jeff Dean：大致如此。我的意思是，有时你可以把一些改动塞进 n+1，但更大的改动就需要芯片设计处于其生命周期设计的更早期阶段。所以只要有可能，我们就会这样做。有时你也可以加入一些探索性的特性，这些特性可能不会占用太多芯片面积，但如果成功了，它能让某些事情快上 10 倍。如果没成功，你也就浪费了一点点微不足道的芯片面积在那上面，不是什么大事。但有时候这会是一个非常大的改动，我们需要非常确信这会成功。所以我们会做大量仔细的机器学习实验来证明，这确实是我们想走的路。

主持人：有没有反向的情况？比如，“芯片设计方案已经定稿，因此模型架构无法再向那个方向演进，因为兼容性存在问题。”

Jeff Dean：肯定会有这样的情况：你需要调整模型架构，使其能高效适配未来一代芯片的训练和推理，所以我认为这是双向的。有时你可以利用未来一代芯片中即将出现的低精度特性。所以你可能会用那种低精度来训练，即使当前一代芯片还不太支持。

主持人：精度能降到多低？因为有人提到三值网络之类的。

Jeff Dean：我非常喜欢极低精度，因为我认为这能节省大量的能量。因为数据传输是按皮焦耳每 bit 来算的，减少 bit 数是降低这个成本的好方法。极低比特精度带来了显著的收益，但代价是需要在整组权重上施加缩放因子。

主持人：说到这个，我觉得有个话题很有意思。当我们在做采样时，精度的概念本身就有点奇怪。最终我们会有所有这些能做非常精确数学运算的芯片，然后我们在开头扔进去一个随机数生成器。感觉现在大家都在往基于能量的模型和处理器那个方向走，你肯定也琢磨过这事儿吧？想听听你的看法。

Jeff Dean：是的，我认为有一些有趣的趋势。比如基于能量的模型、扩散模型，它们不是那种顺序解码 token 的方式还有一种投机性解码技术，可以在不降低生成质量的前提下，获得等效的加速效果。

主持人：非常小的 draft batch。（编者注：draft batch 指的是投机性解码中，由小模型一次性生成的、等待大模型验证的候选词元组。）

Jeff Dean：例如，你可以一次预测出八个 tokens。这让你能把正在做的事情的有效 batch size 增加八倍。然后你可能接受其中的五六个 tokens。所以你通过摊销将权重移入乘法器进行 tokens 预测的成本，获得了五倍的改进。

这些都是非常好的技术，我认为从能量（不是指基于能量的模型）、延迟和吞吐量的角度来看它们真的很好。如果你从这个角度看问题，它会引导你找到更好的解决方案，比如能够更便宜、更低延迟地服务更大的模型，或者同等规模的模型。

主持人：这很有吸引力，但还没看到它在主流中真正流行起来。我确实觉得有种诗意在里面，如果我们从根本上把它设计进硬件里，就不用搞那么多花样了。

Jeff Dean：我认为还有更奇特的东西，比如基于模拟的计算基板，而不是数字的。我对那些非常感兴趣，因为它们的功耗有望做到很低。但我认为，你最终往往需要将其与数字系统接口，而你在系统边界和外围进行的数模、模数转换可能会损失很多功耗优势。我仍然认为，从我们今天所处的位置，通过为我们在意的模型制造更好、更专用的硬件，在能效方面还有巨大的提升空间。

（来源：Gemini 生成）

关于新想法

主持人：除了这些，还有哪些你觉得有趣的研究方向？或者有什么想法，是谷歌内部不方便做，但你希望看到学界去探索的？

Jeff Dean：我认为我们最近的研究组合相当广泛。从研究方向来看，有一大堆开放问题。如何让这些模型更可靠，能够完成更长的、更复杂的、包含许多子任务的任务？如何编排？可能是一个模型使用其他模型作为工具，来构建能够共同完成比单个模型所能做的更重大的工作。如何让模型更可验证？如何让强化学习在不可验证的领域工作？

我认为这是一个非常有趣的开放问题，因为我认为这会拓宽模型的能力范围，你会看到数学和编程方面都在进步。如果我们能通过开发出真正有效的强化学习技术，将其应用到其他不那么可验证的领域，那将真正让模型提升很多。

主持人：我很好奇。当诺姆·布朗（Noam Brown）上我们播客时，他说他们已经证明你可以通过深度研究做到这一点。你在 AI 模式中某种程度上也做到了，虽然它本身并不可验证。我很好奇，有没有你认为有趣的线索？两者都是在做信息检索追踪。

所以我在想，是否检索本身就是那个可验证的部分，可以用来作为评分依据？或者说，你会如何为这个问题建模？（编者注：诺姆·布朗（Noam Brown）是 OpenAI 的研究员，专注于 AI 推理和多智能体系统。他因开发在德州扑克中击败人类专家的 Libratus 和 Pluribus 而闻名，后加入 OpenAI 参与 o1 推理模型的研发。）

Jeff Dean：是的，我认为有些方法可以让其他模型来评估第一个模型所做的结果，也许甚至可以检索。你可以让另一个模型问：“你检索到的这些东西相关吗？” 或者你能对你检索到的这 2,000 样东西进行评分，以评估哪 50 个最相关吗？我认为这类技术实际上非常有效。有时甚至可以是同一个模型，只是通过不同的提示词，让它扮演评论家的角色，而不是实际的检索系统。

主持人：确实，我总觉得我们好像永远在跨越一个又一个悬崖：每次都觉得简单的事做完了，然后集体卡在下一个难题面前，年年如此。“哦，这个我们搞定了，接下来那个肯定难到没人能解。”为什么偏偏强化学习验证就成了那个坎儿？所有人都在问同一个问题：“没有明确判断标准的下一个阶段，到底要怎么走？”

Jeff Dean：我觉得这个领域的好处是，有许许多多聪明的人在想创造性的解决方案来解决我们都能看到的难题。因为我认为大家都看到了，这些模型在某些方面很棒，但在这些方面的边缘地带会失效，能力达不到我们的期望。然后想出好的技术和尝试它们，看看哪些真正能带来改变，这正是这个领域整个研究方面向前推进的方式。我认为这就是为什么它超级有趣。

想想两年前，我们还在为 GSM8K 的问题挣扎，对吧？弗雷德有两只兔子，他又得到了三只兔子，他总共有多少只兔子？这与现在模型能做的数学题相比差远了。现在已经是纯语言的天下。短短一年半时间，模型能力就实现了惊人的飞跃。如果在其他领域也能复制这种成功，那就太棒了。虽然有些领域我们还没找到门路，但既然在其他领域已经看到了可行的方法，我们就会全力以赴，让它变得更好。

主持人：没错，比如 YouTube 缩略图生成，我们就需要这个能力。如果能实现，那将是触及 YouTube 核心业务的一次突破。

Jeff Dean：是的，我不是 YouTube 创作者，所以我不太关心那个问题，但我想很多人关心。

（来源：Gemini 生成）

关于模型大一统

主持人：扯回 IMO，我还是挺唏嘘的。去年还是 AlphaProof、AlphaGeometry 各显神通，今年就直接扔给 Gemini 了。我在想，以前大家不都觉得符号系统和大模型融合是条正路吗？怎么突然就变成“别折腾了，全让大模型自己来”了？

Jeff Dean：我觉得这对我来说很有意义，因为你知道人类操纵符号，但我们脑子里可能没有一个符号化的表征，对吧？我们有某种分布式表征，从某种意义上说，是神经网络式的，由许多不同的神经元和激活模式组成，当我们看到某些东西时会触发。这使我们能够推理、规划、进行思维链以及回溯，“这个方法看来行不通，我试试那个”。

在许多的方面，我们正在神经网络模型里模拟我们直觉上认为真实大脑内部发生的事情。所以，对我来说，拥有完全分离的、离散的符号化事物，以及一套完全不同的方式来思考这些东西，从来就没有意义。

主持人：我的意思是，对你来说可能显而易见，但一年前对我来说并不明显。

Jeff Dean：我确实认为，去年 IMO 竞赛用到了翻译成 Lean 语言并使用 Lean，以及使用了一个专门的几何模型。然后今年，切换到一个单一的统一模型，这基本上是生产级模型，只是多给了点推理预算，这实际上非常棒。因为它表明那个通用模型的能力已经大大提高了。现在你不再需要这些专门的模型了。这实际上与 2013 到 2016 年时期的机器学习非常相似，对吧？

过去，人们会针对许多不同的问题训练不同的模型，对吧？我想识别街道标志，所以我训练一个街道标志识别模型。或者我想做语音识别解码，我就去训练一个语音模型。我认为现在，做所有事情的统一模型时代真的来临了。问题在于，这些模型在面对它们从未被要求做的事情时，泛化能力有多好？它们正变得越来越好。

主持人：你都不需要领域专家了。我采访过 Ete，他就是那个团队的成员。他说：“我真的不知道它们是怎么工作的，不知道 IMO 在哪里办，也不知道比赛规则。我只是在训练模型，我做的就是训练模型。”

这很有意思，拥有这种通用技能的人，只需要机器学习能力，拿到数据和算力，就能处理任何任务。这大概就是所谓的“苦涩的教训”吧。（编者注：1、Ete 是指爱德华·格列芬斯特（Edward Grefenstette），一位 Google DeepMind 的研究科学家，他参与过多项与推理、语言模型相关的研究。2、“苦涩的教训”是“强化学习之父”理查德·萨顿（Richard Sutton）提出的AI核心理念：研究者总想把人类知识编入 AI，短期有效但长期看，依靠大规模算力和通用算法的方法最终会胜出。它之所以“苦涩”，是因为 AI 的成功往往不是因为它模仿了人类，而是靠大力出奇迹走出自己的路。）

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

主持人：我想在这里稍微深入探讨一下。我觉得这里有一个漏洞，就是关于模型容量的概念。抽象地说，一个模型能容纳的比特数是有限的。所以，谁会知道 Gemini Pro 可能有一万亿到十万亿参数？我们不知道。

但以 Gemma 模型为例。很多人想要开源、能在本地运行的模型，它们拥有一些并不必要的知识，对吧？它们不可能知道所有事。你们有优势，你们有大模型，大模型应该什么都能做。但是，当你进行蒸馏，把它缩小到小模型时，你实际上是在记忆一些没用的东西。所以，我们能否将知识与推理分离开？

Jeff Dean：我认为你确实希望模型在能够检索东西时最有效地进行推理，对吧？因为让模型把宝贵的参数空间用来记忆那些可以查到的、晦涩的事实，实际上并不是对该参数空间的最佳利用，对吧？你可能会更喜欢那些在更多场景下更有用的东西，而不是它记住的某个晦涩事实。

所以我认为这个权衡一直存在。同时，你也不希望你的模型完全脱离对世界的了解。比如，知道金门大桥有多长可能很有用，能对“桥一般有多长”有个大致概念。它应该有那种知识，它可能不需要知道世界上某个更偏远角落的一座小桥有多长，但是拥有相当多的世界知识确实有帮助。你的模型越大，你能容纳的知识就越多。

但我确实认为，将检索与推理结合起来，让模型真正擅长进行多轮检索并通过中间检索结果进行推理，这将是让模型看起来能力更强的一个非常有效的方法。我们不会在 Gemini 上训练我的电子邮件，我们可能更希望有一个单一的模型，然后我们可以使用它，并能够使用从我的电子邮件中检索作为工具，让模型推理它，从我的照片中检索，然后利用这些信息进行多轮交互。

主持人：你怎么看垂直领域模型这个方向？比如有人说“我们在打造最好的医疗大模型”“我们在做最牛的法律大模型”。这些是短期的过渡方案，还是真的有长远价值？

Jeff Dean：我认为垂直领域模型很有趣。你想让它们从一个相当好的基础模型开始，然后你可以，我有点把它们看作是丰富那个特定垂直领域的数据分布。比如医疗保健。比如，对于机器人技术，我们可能不会在所有可能的机器人数据上训练 Gemini。你可以用它训练，因为我们希望它拥有一套平衡的能力。

所以我们会让它接触一些机器人数据。但如果你想构建一个真正、真正好的机器人模型，你会希望从那个基础开始，然后在更多的机器人数据上训练它。这可能会损害它的多语言翻译能力，但会提高它的机器人能力。

我们在训练基础 Gemini 模型时，总是在数据混合中做这种权衡。我们很乐意包含另外 200 种语言的数据，并且有和这些语言一样多的数据。但这会挤占模型的其他一些能力。它在 Perl 编程上可能没那么好了。它在 Python 编程上仍然会很好，因为我们会包含足够多的 Python 数据。但在其他长尾计算机语言或编程能力上，它可能会受影响。或者多模态推理能力可能会受影响，因为我们没有机会让它接触那么多相关数据，但它在多语言方面会非常出色。

所以我认为，某种组合是合适的：专门的模型，也许更多是模块化的模型。如果能有能力将这 200 种语言，加上这个超棒的机器人模型，加上这个超棒的医疗保健模块，所有这些可以组合在一起协同工作，在不同情况下被调用那将非常棒。比如，如果我有一个与健康相关的问题，那么它应该能够启用这个健康模块，与主基础模型一起，在这些事情上做得更好。

主持人：可安装的知识？

Jeff Dean：是的，只需要下载就行。部分可安装的东西可以来自检索。但有些可能应该来自预先加载的训练，比如在 1,000 亿或一万亿 tokens 的健康数据上训练。

主持人：你需要多少亿的 tokens 才能超过前沿模型的改进速度？如果我想让这个模型在医疗保健方面更好，而主 Gemini 模型仍在改进，那么需要 500 亿 tokens 吗？如果我需要一万亿，我能用 1,000 亿做到吗？医疗保健的 tokens，你可能手头没有那么多。

Jeff Dean：我认为医疗保健是一个特别有挑战性的领域。所以有很多医疗保健数据，我们无法适当地获取。但也有许多医疗保健组织希望在自己的数据上训练模型，这些数据不是公共医疗数据，是私有的医疗数据。所以我认为有机会与大型医疗保健组织合作，为他们训练更定制化的模型，这些模型可能比在公共数据上训练的通用模型更好。

主持人：这有点类似于语言方面的讨论。我记得你最喜欢的一个例子是，你可以把一种低资源语言放在上下文中，它就能在上下文中学习。

Jeff Dean：我记得我们用的例子是卡尔梅克-卫拉特语，那是真正的低资源语言，因为世界上只有大约 120 人使用，而且没有书面文本。所以你可以直接把它放在上下文里。

主持人：但我觉得你整个数据集都在上下文里。

Jeff Dean：如果你拿一种语言，比如索马里语之类的，世界上确实有相当数量的索马里语文本，或者埃塞俄比亚的阿姆哈拉语之类的。我们可能不会把所有那些语言的数据都放进 Gemini 的基础训练里。我们会放一部分进去，但如果你放更多进去，你会提高模型在这些语言上的能力。

主持人：我对语言学有点兴趣。大学时上过几节课。我有时想，如果我是一名语言学家，并且可以使用所有这些模型，我会问一些关于语言本身的非常基本的问题。比如，一个非常明显的问题是“沃尔夫假说”：你说的语言在多大程度上影响你的思维？还有一些语言中有些概念在其他语言中没有体现，但很多其他概念则是重复的。

还有一篇人们很喜欢的论文叫《柏拉图式表征》，讲的是比如一张杯子的图片，如果你在上面训练一个模型，并且有大量带有“杯子”这个词的文本，它们最终会映射到潜在空间中大致相同的位置。所以，这应该适用于语言，除了那些不适用的地方。而这正是人类发现的一些有趣的概念差异，可能英语里没有。

Jeff Dean：是的，我做过一个早期模型的工作，它将一个基于语言的模型（有很好的基于词的表示）和一个在 ImageNet 之类东西上训练的图像模型融合在一起。是的，然后你把它们的顶层融合起来。再做一点额外的训练来融合这些表征。

我们发现如果你给模型一张全新的、不在图像模型训练类别中的图像，它常常能给那张图像分配出正确的标签。例如，我认为望远镜和双筒望远镜都在图像模型的训练类别中，但显微镜不在。所以如果你给它一张显微镜的图像，它实际上能想出带有“显微镜”这个词的标签，即使它从未见过标记为“显微镜”的图像。

（来源：Gemini 生成）

关于神经网络

主持人：聊了这么多，从硬件到模型研究，你觉得还有什么是人们应该多问问你的？

Jeff Dean：有一件挺有意思的事是，我在 1990 年做本科毕业论文时，做的就是并行神经网络训练。那时我第一次接触到神经网络，我一直觉得它们是正确的抽象，只是我们需要比当时多得多的算力。学校计算机系里那台有 32 个处理器的并行计算机，能帮你做出稍微有趣一点的模型，但不足以解决真正的问题。

所以从 2008、2009 年开始，人们通过摩尔定律拥有了足够的算力。以及更大、更有趣的数据集可以用于训练，实际上开始训练能够解决人们关心的实际问题的神经网络，比如语音识别、视觉，最终是语言。所以当我在 2011 年底开始在谷歌做神经网络时，我真的觉得我们应该利用大量的并行计算来扩大神经网络的规模。所以我实际上重拾了我本科论文中的一些想法，我当时既做了模型并行，也做了数据并行训练，并对它们进行了比较。我当时给它们取了不同的名字，比如模式划分和模型划分之类的。

主持人：那个论文是公开的吗？

Jeff Dean：好像网上能找到。但是，我认为结合这些技术，并且在过去十五年里真正致力于推动规模化，一直非常重要。这意味着硬件上的改进。因此，我们一方面推动专用硬件的研发，比如 TPU；另一方面也着力于软件抽象层的建设，让人们能够更高效地表达机器学习想法。与此同时，像稀疏模型这样的前沿方向也在持续推进中。

长期以来我一直觉得，稀疏激活的模型是一件非常重要的事情，因为你希望模型有很大的容量，就像我们之前讨论的记忆很多东西那样。但你也希望模型的激活极其高效，所以你希望有数万亿的参数，但只激活其中的 1%、5% 或 10%。我们在 2017 年的一篇早期论文中做了这方面的工作，真正实现了超大规模神经网络的规模化扩展。那篇论文的标题里有个很吸引眼球的词。我记得标题里有“outrageously large”。

主持人：你那时就在谈论万亿参数的模型。

Jeff Dean：是的，因为与非稀疏模型相比，它在达到给定质量水平所需的时间或计算成本上，带来了 10 倍的改进。同样，相比当年的 LSTM，Transformer 在达到同等质量水平时，计算成本降低了 10 到 100 倍。所有这些因素乘在一起让我认为这些事情都很重要，需要去研究。

从硬件到系统基础设施，从模型架构的算法优化，到数据质量的提升，再到强化学习方法的改进，所有这些因素叠加在一起，产生了乘数效应。这才让 2026 年的模型，不仅远超 2025 年，更将 2023、2022 年的版本远远甩在身后。

主持人：这是一个巨大的组织挑战，这涉及上千人，也许更多。我知道，当 Gemini 的论文出来时，我看到有上千位合著者。

Jeff Dean：那篇论文有 10 页的合著者名单。我认为有这么多合著者是完全合理的。而且我确实认为，组织这么多人，让他们有效地朝着共同的方向努力，让他们所有的工作最终在最终的产出（也就是下一代模型）上形成乘数效应，实际上相当棘手。我们在整个 Gemini 团队中拥有出色的人来帮助协调这一切。所以，你知道，我自己、Noam 和 Oriol 在帮忙指引方向。

然后我们有团队在思考，预训练设置是什么样的？基础设施是什么样的？后训练方案是什么样的？数据准备是什么样的？还有多模态能力、长上下文能力？有很多不同的领域，编程能力。所有这些领域都超级重要，有专人密切关注这些事情是很好的。同时也要密切关注所有其他事情。

主持人：是的，我听说谢尔盖非常积极地回来了。（编者注：“谢尔盖”指的是谢尔盖·布林（Sergey Brin），他是谷歌的联合创始人之一。）

Jeff Dean：是的，非常积极。

主持人：参与编程方面的工作。

Jeff Dean：是的，我们都用同一个微型厨房。（编者注：“用同一个微型厨房”，是指大家共用一个小型茶水间/休息区，暗示了谢尔盖深入一线、和团队打成一片的状态。）

主持人：你可能讲过几次，显然 Google Brain 也是在一个微型厨房里起步的。

Jeff Dean：是的。

主持人：看来你们的微型厨房非常重要。

Jeff Dean：是的，我偶然碰到了当时在美国斯坦福大学任教的吴恩达。我之前因为去斯坦福做过几次演讲而认识他，所以算是认识。我问他，你在这里做什么？他说：“哦，我还不确定，我几周前刚开始在这里兼职，每周来一天做顾问。我还不确定做什么，但我的斯坦福学生们在用神经网络做语音识别，开始取得一些好结果。”我心想，哦，神经网络，我喜欢神经网络，这让我想起了我 90 年代的本科论文。我对他说：“哦，听起来很有趣。我们应该训练真正、真正大的神经网络。当时就是这么开始的。”

主持人：你的第一反应很有意思，就是“我们应该把它大规模扩展”。

Jeff Dean：嗯，我的意思是，我觉得谷歌有大量的计算能力。所以如果他们在单 GPU 模型上看到了好结果，你知道，如果当时我们的数据中心里没有 GPU，没有任何加速器。我们有很多 CPU，但我们可以构建一个软件系统，让你能够通过模型并行和数据并行，分布到大量计算机上。

我们最终训练了一个相当大的模型，据我们所知，比之前的任何神经网络都大 50 倍。那是一个有 20 亿参数的视觉模型，在 16,000 个数据中心算力核心上训练了数周。这让我们得到了很好的结果。它在 ImageNet 22K（那个 22,000 类别的数据集）上带来了 70% 的相对错误率改进。

这也让我们真正看到了规模化的重要性。我们没有写一个复杂的规模化分析，但我们看到了：更大的模型、更多的数据，带来更好的结果。这成了接下来六七年里我们不断扩展的信条。每次当我们这样做，都在语音、语言和视觉上看到了更好的结果。

（来源：Gemini 生成）

关于 Gemini 命名来源

主持人：我们之前的嘉宾 David Juan，他曾经为你工作。他有点把谷歌在语言模型上投入不足归咎于 Google Brain 的内部计算资源市场。我想知道，你是否同意当时的这种看法？（编者注：戴维·栾（David Luan），是 AI 领域知名的技术专家，曾任职于 Google Brain 和 OpenAI，后来创办了 AI 初创公司 Adept。）

Jeff Dean：是那个给计算配额定价的内部市场吗？

主持人：是的，计算配额市场。基本上他说的是，David 在 OpenAI 的 VP 引擎团队工作过，也在谷歌工作过。他说，从根本上讲，OpenAI 愿意全情投入，把全部赌注押在一件事上，而谷歌则更民主，每个人都有自己的一亩三分地。我当时想，如果你相信规模化是一件重要的事，那这其实是一个需要在整个组织层面做出的重要决策。

Jeff Dean：我认为我某种程度上同意这个说法。我记得我实际上写过一份一页纸的备忘录，说我们分散资源是很愚蠢的。具体来说，当时在谷歌研究院内部，尤其是在 Brain 团队，我们有多个大模型的工作。在 Brain 和谷歌研究院的其他部分，我们也有多模态模型的工作。

然后原来的 DeepMind 也有像 Chinchilla 和 Flamingo 这样的模型。所以我们不仅把计算资源分散到了这些不同的工作中，也分散了我们最优秀的人才和最好的想法。所以我说，这太蠢了。我们为什么不联合起来，集中力量做一件事？

主持人：这就是合并的起源。

Jeff Dean：去训练一个从一开始就是多模态的、厉害的、统一的、在所有方面都很出色的模型，这就是 Gemini 努力的起源。我那页纸的备忘录奏效了，这很好。

主持人：名字也是你取的吗？

Jeff Dean：是的，当时我还提议了另一个名字。我说，这两个组织走到一起，某种程度上就像双胞胎（twins）。所以我有点喜欢这个名字。而且，NASA 早期的双子座计划（Gemini project）也是通往阿波罗计划的重要一步。所以这看起来是个好名字。双胞胎走到一起。

（来源：Gemini）

关于 AI 编程

主持人：我很好奇，你现在是怎么用 AI 来编程的？你可能是计算机科学史上最多产的工程师之一。我在读一篇文章时，看到关于你和 Sanjay 的友谊，以及你们如何一起工作。有一句话提到，你需要找到一个能和你一起结对编程的人，他的思维方式与你兼容，这样你们俩合在一起就能形成互补的力量。

我在想，你怎么看待编程智能体？你如何塑造一个编程智能体，使其与你的思维方式兼容？你觉得今天的工具怎么样？有什么看法？（编者注： Sanjay 指的是桑杰·格玛沃特（Sanjay Ghemawat），他是谷歌系统基础设施部门的高级研究员，也是 Jeff Dean 长达二十多年的黄金搭档。）

Jeff Dean：我认为编程工具与一两年前相比，正在变得非常、非常强大。所以现在，你可以真正依赖它们来完成更复杂的任务，那些你作为软件工程师想要完成的任务。你可以把相当复杂的事情委托给这些工具。我认为，人类软件工程师和他们正在使用的编程模型之间互动的一个非常好的方面是，你与那个编程模型对话的方式，实际上决定了它如何与你互动，对吧？

你可以让它“请为这个写一堆好的测试”。你可以让它“请帮我 brainstorm 一些性能方面的想法”。你的提问方式会塑造模型的回应方式，它会处理什么样的问题。你希望模型多大程度上去独立完成更大的事情，还是更多地与你互动，以确保你在塑造正确的方向？

我认为，并不是某一种风格适合所有情况。对于某些问题，你可能实际上希望与模型有更频繁的互动。而对于另一些问题，你可能就直接说，“好的，请去把这个写了，因为我知道我需要这个东西。我能够清晰地说明它，你就去做吧，做完回来。”所以我确实认为，未来会有更多独立的软件智能体代表你行事，我们需要找出合适的人机交互模型和用户界面来决定它什么时候应该打断你。

比如，它会说：“嘿，我需要一点指导”，或者“我已经完成了这件事，下一步做什么？” 我认为我们还没有这个问题的最终答案。随着模型变得更好，你在决定互动应该如何进行时所做的决策也可能会改变。就像如果你有一个由 50 名实习生组成的团队，如果他们是人类，你会如何管理？我想，如果他们是真正优秀的 50 名实习生，情况可能不同。

主持人：管理量很大。

Jeff Dean：管理量确实很大。我认为很有可能，很多人将来都会拥有 50 名实习生。那么作为一个人，你实际上会如何应对呢？你可能希望他们组成小型的子团队，这样你就不用和 50 个人都直接互动。你可以和其中五个团队互动，他们都在代表你做事。但我不完全确定这会如何展开。

主持人：你如何看待引入他人，比如结对编程？结对编程总是有助于带来新的想法。感觉随着我们有更多的编程引擎来编写代码，将其他人引入问题就变得困难了。比如说，你有了 50 个实习生，对吧？然后你想去找 Noam 或 Sanjay，说，“嘿，我想跟你结对做这个事”。但是现在有大量的并行工作已经完成了，你需要让他们先跟上这些，对吧？我很好奇，人们在团队中会不会变得更加孤立？因为会有太多这 50 个实习生带来的上下文，很难全部同步给你。

Jeff Dean：也许吧。但另一方面，想象一个没有任何 AI 辅助工具的经典软件组织，你会有 50 个人在做事情。他们的互动方式自然会是高度层级化的，因为这 50 个人会在系统的这一部分工作，不会和那边的那些人互动那么多。但如果你有五个人，每个人管理着 50 个虚拟智能体，他们之间可能会有高得多的沟通带宽。然后这五个人再相互沟通协调，这比五个人同时还要协调各自管理的 50 人团队要高效。

主持人：我很好奇你是如何改变自己的工作节奏的？比如，你花了更多时间在脑子里和人们一起 review 代码和设计目标吗？

Jeff Dean：我觉得有意思的是，每当人们被教导如何写软件时，他们都被教导清晰地编写规格说明非常重要，但没人真正相信这一点。人们只会觉得：“嗯，知道了，没必要那么较真。”然后继续我行我素。

主持人：真的吗？

Jeff Dean：我的意思是，用英语写的规格说明，从来都不是一个真正被高度重视的产物。它很重要，但它不像现在这样，如果这是你要求智能体为你编写软件的依据，那你最好在如何说明上非常、非常小心，因为那将决定输出的质量，对吧？就像如果你没有涵盖到它需要处理这类情况，或者这是一个超级重要的边界情况，或者你特别关心这一部分的性能，它可能就不会按你想要的方式工作。我觉得人进步的一个方法，就是学会把事儿说明白，别模棱两可的。这真不是坏事。不管你是写程序的，还是干别的，能把需求讲清楚，这个本事到哪儿都吃香。

主持人：是的，好的提示词工程与足够高级的管理层沟通没什么区别。就像写内部备忘录一样，非常仔细地斟酌你的用词。而且，我认为，能够做到多模态非常重要。我觉得，谷歌的 NotebookLM 做得很好的一点就是，直接涌现出了非常、非常强大的多模态能力，包括视频。那是你能给模型提供的最高带宽的沟通提示。

那么，你如何收集那些你脑海中经常有的东西？比如你写过那些关于如何寻找性能改进的惊人技巧。人们把这些通用的东西写下来，以便以后可以把它作为检索的素材给模型，这样是不是更有价值？拿边界情况来说吧，你心里门儿清，但每次都得跟人掰扯一遍。那你会不会让大家多花点功夫，把这些东西写成通用的，以后直接甩出来就能用？

Jeff Dean：我认为那些写得好的软件工程指南会很有用，因为它们可以作为模型的输入，或者被其他开发者阅读，这样它们就能像提示词一样，让底层软件系统应该做什么更清晰。我认为可能不需要为每种情况都创建定制化的指南。如果你有通用的指南，把它们放到编程智能体的上下文里，那会很有帮助。

你可以想象一份针对分布式系统的指南。你可以告诉它：“这类故障可以这么处理。”比如 Paxos 协议，或者双路发送、单路返回的容错机制。把 20 种类似的技巧写成一个“分布式系统避坑指南”，编程智能体就能借鉴这些经验，搭出更靠谱的系统。

主持人：Gemini 能写出 Spanner 吗？也许已经可以了，毕竟代码就摆在那儿。CAP 定理是个好例子，人人都当它是铁律，结果你们硬是把它打破了。我好奇的是，模型会不会也这样？在某些前提下，你会说它“推翻了 CAP 定理”吗？（编者注：1、Spanner 是谷歌开发的全球分布式数据库，被誉为数据库领域的“登月计划”。2、CAP 定理是分布式系统设计的核心基石，由计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年提出。）

Jeff Dean：是的，在某些假设下。

主持人：你给模型灌输什么，它就容易信什么。所以我就老在想一个问题，就是关于你刚才说的延迟。我一直特别想做这么个实验：一边是快速跑几轮、人随时纠正，另一边是憋一个大招、写个巨详细的提示词让模型一次搞定。这两种方式，到底谁更牛？性能问题到底是因为你没说明白，还是因为你根本没法说明白？

Jeff Dean：它说明不足，所以我可以产生 10 种不同的东西，但只有一个是你要的。

主持人：那么，用 Flash 模型进行多轮交互就足够了。

Jeff Dean：我非常信奉推动低延迟，因为我认为能够与你使用的系统进行真正低延迟的互动，比慢 10 倍或 20 倍的东西要令人愉悦得多。而且我认为，未来我们会看到模型，以及底层的软件和硬件系统，其延迟比我们今天拥有的低 20 倍、低 50 倍。这对于需要在你的交互之间做大量事情的系统来说，将非常、非常重要。

主持人：有两个极端，你还有 DeepThink，它一直在另一端，对吧？

Jeff Dean：但如果不是因为成本和延迟，你会一直使用 DeepThink。如果你能在模型中拥有那种能力，同时底层硬件系统的延迟改善了 20 倍，成本也降下来了，你没有任何理由不想要那个。但与此同时，你可能会有更好的模型，即使在新硬件上，也需要花 20 倍的时间。

主持人：你知道，帕累托曲线一直在上升。

Jeff Dean：是的，向前，向上。

关于个性化模型

主持人：有没有一些你现在就可以做、未来也能验证的预测？比如说，每次新模型发布，你都会用一些测试来衡量，那么眼下还有哪些让你不太满意、但你预感很快就会被攻克的难题？

Jeff Dean：让我做两个预测，可能不完全是你说的那种。首先，我认为一个了解你、了解你所有状态、并且能够在你选择加入的情况下检索你能访问的所有状态的个性化模型，将比一个无法访问这些的通用模型有用得多。比如，可以关注我见过的所有东西的模型。每一封邮件，每一张照片，我看过的每一个视频。我认为，越来越多专用硬件将能够以比现状更实惠的价格，实现延迟低得多的模型和性能更强的模型。

主持人：你提到低得多的延迟，业内常用每秒 tokens 数来衡量。现在如果是 100，未来能到几千甚至 10,000，这有意义吗？

Jeff Dean：太有意义了，思维链推理就指着这个呢。你可以想象多得多的 tokens，你可以做多得多的并行推演，你可以生成更多的代码，并用思维链推理检查代码是否正确。所以我认为，能够以每秒 10,000 tokens 的速度做到这些，那就太棒了。

主持人：每秒 10,000 tokens 时，你就不再是阅读代码了。

Jeff Dean：最终可能不是 10,000 tokens 的代码，而是 1,000 tokens 的代码，背后带着 9,000 tokens 的推理过程。这实际上可能会是更好读的代码。

主持人：就像那句名言：给我更多时间，我能写出更短的句子。（编者注：这句话通常被归功于法国数学家、哲学家布莱兹·帕斯卡（Blaise Pascal），他在 1657 年出版的《致外省人信札》中写过一句类似的话：“我没有时间写得短些，所以只好写得长些。”）

Jeff Dean：是的。

主持人：太棒了，Jeff，这次访谈太精彩了。

Jeff Dean：谢谢你们，非常有趣，感谢邀请。

参考资料：

原视频

https://www.youtube.com/watch?v=F_1oDPWxpFQ

排版：胡巍巍Jeff Dean万字访谈：我们正在杀死割裂AI应用，2026年是大一统元年