每秒一万个 Token 是为了给 AI 预留足够的思考空间

2 月 13 日，Google 首席 AI 科学家 Jeff Dean 接受了 Latent Space 播客的深度专访。本次对话全面回顾了 Google 如何在激烈的 AI 竞赛中通过 Gemini 占据前沿，深入拆解了模型蒸馏、长上下文处理向万亿 Token 的跨越、TPU 硬件协同设计、分层搜索逻辑，以及 AI Agent 对未来软件工程的重塑。Jeff Dean 还在对话中复盘了 Google 内部资源整合的决策内幕，并对“万倍速推理”时代做出了预测。

Jeff Dean 指出，Google 的领先源于贯穿整个技术栈的综合优势。通过将前沿大模型（Pro/Ultra）的能力蒸馏至更小、更轻量的模型中，Google 实现了性能与成本的最佳平衡。他强调，Flash 系列模型的成功并非偶然，低延迟是复杂任务的核心指标，因为复杂任务意味着需要生成海量 Token。对于长上下文技术，Jeff 认为行业已从简单的“大海捞针”测试转向对数百万甚至数万亿 Token 的深度理解，目标是让 AI 系统能够实时处理整个互联的信息或个人全部数字化足迹。

Jeff Dean 认为，与其让小模型死记硬背随处可查的冷门事实，不如将参数空间释放给推理能力，通过在强基座模型上进行模块化配比或插件式调用，其进化效率远超独立的医疗或法律模型。此外，他指出高性能中小型模型（如 Flash）的领先前提，是必须持续推动顶级前沿模型（Pro/Ultra）的突破，以作为蒸馏的“能力源泉”。

Jeff Dean 提出，数据搬运的成本远超计算本身。他指出，相对于 1 皮焦耳的乘法运算，从内存搬运数据可能消耗 1000 皮焦耳，这也决定了“批处理（Batching）”在 AI 计算中并非仅为了吞吐量，其本质是为了平摊昂贵数据搬运成本而进行的能效妥协。

针对 AI Agent 带来的行业变革，Jeff Dean 预计，未来 5 个管理者带领 250 个虚拟 AI Agent 的协作效率，将远高于传统的层级化人力团队。在这种模式下，编写严谨的“规格说明书”将取代模糊的指令，成为驱动生产的核心。他认为，未来的核心竞争力不在于编写代码，而在于能否像管理高级行政团队一样，清晰、准确地定义任务目标，并利用模型在思维链中消耗的大量推理 Token 来换取最终输出的高可靠性。

关于未来，Jeff Dean 有 2 个预测，首先个性化模型将变得异常强大。一个了解你、掌握你所有授权状态（邮件、照片、视频）并能检索信息的模型，会比通用模型有用得多。其次越来越多的专用硬件将以更低廉的价格实现更低延迟、更强大的模型。

Jeff Dean： 非常感谢，能保持在帕累托前沿的位置确实令人振奋。正如你所说，这并非单一因素的结果，而是贯穿整个技术栈的综合优势。这些因素共同作用，使我们能够打造出性能极强的大语言模型，并利用软件技术将这些能力迁移到更小、更轻量的模型中。这些小模型虽然成本更低、延迟更小，但在同等尺寸下依然保持了极强的竞争力。

我们始终致力于研发处于甚至推动技术前沿的模型，因为这能让我们发现一年前或半年前还不具备的新能力。与此同时，我们也意识到这些前沿模型在某些广泛应用场景下，速度和成本可能不尽如人意。因此，我们的目标是始终提供一种能力强且价格亲民的模型，以支持低延迟应用。例如，用户可以更顺畅地将这些模型用于 AI Agent 编码。同时，我们也需要高端前沿模型来处理深度推理、解决复杂的数学难题等任务。这两者并非互斥，而是相辅相成。通过蒸馏技术，我们可以将前沿模型的能力注入到小模型中。因此，这并非二选一的抉择，要获得高性能的中小型模型，首先必须拥有顶尖的前沿模型。别忘了 Oriol Vinyals 也是（蒸馏论文的）作者之一。

（关于技术构想的周期）蒸馏技术最初的动力源于我们当时拥有一个包含 3 亿张图像的超大数据集。我们发现，如果为不同的图像子集创建专家模型，例如专门处理哺乳动物的模型，或专门处理室内场景的模型，在进行广泛预训练后，再通过聚类并在丰富的数据流上训练，可以获得更好的性能。但如果将这 50 个模型组成的集成模型直接用于在线服务，显然不切实际。于是我们产生了一个想法，既然训练了这些独立的专家模型，能不能把它们压缩成一个适合在线服务部署的单体模型。这与我们今天的做法大同小异，只是现在我们通常是将一个超大规模模型的能力蒸馏到一个小规模模型中。

（关于强化学习的结合）我认为蒸馏的核心优势之一在于，利用一个小模型和超大规模的训练数据集，可以通过对数据集的多次迭代获得巨大效益。由于你可以从大模型中获取 Logits (对数几率) 来引导小模型的行为，这种效果是仅靠硬标签无法实现的。观察结果显示，通过蒸馏方法可以获得非常接近顶尖模型性能的小模型。这是一个非常理想的平衡点也是为什么连续几代 Gemini Flash 模型都能达到甚至超越前一代 Pro 模型水平的原因。我们会坚持这一技术趋势。我们内部拥有多种模型，其中一些模型并非为了公开发布或提供服务。我们可以从 Pro 级别的模型中蒸馏出 Flash 级别的模型。此外，推理侧扩展 也是提升模型能力的重要手段。

Jeff Dean： Flash 模型最吸引人的地方不仅在于价格实惠，更在于它的低延迟。延迟是模型性能的关键指标，因为我们希望模型处理更复杂的任务，而复杂任务意味着需要生成更多的 Token。比如用户不再只是要求模型写一个循环，而是编写整个软件包。在这种场景下，具备低延迟特性的 AI 至关重要。我们的硬件平台也为推理栈提供了有力支撑，例如 TPU 芯片间的高速互联对于长上下文的注意力机制操作，以及支持大量专家的稀疏模型运行，都起到了决定性的作用。

（关于 Pro 模型的持续动力）如果用户需求是静止不变的，这种观点可能成立。但实际情况是，随着模型能力的提升，人们的需求也在水涨船高。以我个人的经验为例，一年前我用模型处理简单的编程任务，效果尚可，但处理复杂任务就很吃力。随着我们在复杂编程任务上的突破，我现在会要求模型处理更高级的开发任务。这不仅限于编程，比如要求模型分析全球可再生能源部署情况并生成太阳能报告，这类任务的深度远超一年前的需求。因此，我们必须持续研发前沿模型以探索技术边界，并从中洞察模型在哪些特定领域会遇到瓶颈，从而指引下一代模型的优化方向。

（关于内部基准测试）公开的外部基准测试确实有其价值，但通常都有生命周期。我比较推崇那些初始得分仅在 10% 到 30% 之间的测试，因为这代表了真正的挑战。一旦得分达到 95% 左右，由于边际收益递减以及训练数据中可能存在的泄露问题，继续专注于该指标的意义就不大了。所以我们建立了一系列内部测试集，确保它们在训练数据中从未出现过。这些测试代表了我们希望模型具备但尚未掌握的能力，它会指引我们是需要更专业的训练数据，还是需要架构层面的改进。

Gemini 1.5 系列的长上下文能力就是一个很好的例子。当单针的大海捞针测试在 128K 长度饱和后，我们开始尝试推动 100 万甚至 200 万上下文的前沿。这具有极大的应用价值，比如将上千页文本或数小时的视频放入上下文并让 AI 提取有用信息。单针测试已经过于简单，我们需要更复杂的多针测试或更接近真实需求的任务，例如让模型基于超长上下文生成深度回答，这才能真实衡量 long context 技术的实际价值，而不仅仅是识别一个简单的产品编号。

Jeff Dean： 我倾向于不纠结于具体的解决方案，而是思考究竟需要实现什么样的能力。我们坚信长上下文极具价值，但目前的处理能力还是太局限了。理想情况下，你肯定希望 AI 系统在回答问题时能够实时处理整个互联网的信息。但这在目前很难通过纯粹扩展现有的二次方复杂度方案来实现。处理 100 万个 Token 几乎已经达到了目前的技术极限，更不用说处理 10 亿甚至 1 万亿个 Token 了。但如果你能构建出一种能够处理数万亿 Token 的能力，哪怕只是实现这种效果，那也将是非常惊人的。你会发现它的用途极其广泛，比如让 AI 系统关注整个互联网，或者理解 YouTube 视频中的像素信息及其背后的深层表示。

在个人化的 Gemini 层面，如果得到授权，它可以处理你所有的个人状态，包括电子邮件、照片、文档以及机票信息。这会非常实用。现在的核心问题是，如何通过算法和系统层面的改进，让你真正以有意义的方式去处理数万亿规模的 Token。

（关于多模态与核心模态）关于 Gemini 的多模态能力，我们从立项之初就致力于此。对大多数人来说，多模态意味着文本、图像、视频和音频等人类感知模态。但我觉得让 Gemini 理解非人类模态同样意义重大，比如来自 Waymo 自动驾驶汽车的激光雷达（LIDAR） 传感器数据，或者是机器人感知数据，以及医疗领域的 X 光、核磁共振成像（MRI） 和基因组学信息。世界上存在成百上千种数据模态，我们希望模型至少能意识到这些模态的存在及其背后的现实意义。即使主预训练数据集中没有包含全部的激光雷达或核磁共振数据，只要包含一小部分，对模型来说就非常有帮助，因为这能引导模型感知到这种模态的存在。

视觉和运动确实至关重要，尤其是动态视频相对于静态图像而言。自然界中的生物进化曾独立演化出眼睛多达 23 次，这足以说明感知周围世界的能力是多么关键，这正是我们对 AI 系统的期望，解释所见所感并协助我们利用这些信息去完成任务。实际上，很多人还没意识到 Gemini 模型真正的实力。我在一次演讲中举过一个例子，一段包含过去 20 年间 18 个经典体育瞬间的 YouTube 锦集，比如迈克尔·乔丹在总决赛的绝杀球以及一些经典的足球进球。你直接把视频交给它，让它整理一份表格，列出每个事件、发生日期和简短描述。它能直接从视频中提取信息并生成一个 18 行的表格，这种将视频直接转化为类似 SQL 结构化数据的能力，是很多人之前不敢想象的。

Jeff Dean： 首先，设计一个 AI 系统时，你必须明确最核心的设计参数，比如每秒查询量、互联网规模、索引大小以及每个文档需要保留的数据量。你必须预判，如果流量翻倍，系统是否还能扛得住。我的原则是，系统设计应该能应对 5 到 10 倍的扩展，但不必追求更高，因为当规模增长 100 倍时，整个设计空间会发生质变。正如当年从磁盘索引转向内存索引，只有当流量达到一定规模、副本数足够多时，这种设计才变得可行。我非常推崇在实际编写代码之前，先在脑子里反复推演设计空间。

（关于搜索架构的演进）其实在 1999 到 2005 年间，我们的检索系统经历了五六代的彻底重构。2001 年是一个关键节点，当时我们正尝试从多维度扩展系统。一方面要扩充索引规模以提升搜索质量，另一方面要应对激增的流量。当时我们采用分片系统，随着索引增长，分片数从 30 个增加到 60 个。最后我们算了一笔账，在拥有 1200 台带磁盘机器的数据中心里，整个索引的一个完整副本其实完全可以塞进 these 机器的内存总和里。于是 2001 年，我们率先实现了全内存索引，这对搜索质量的提升是革命性的。在此之前，由于每次关键词查询都要在 60 个分片上进行磁盘寻道，我们必须非常克制查询词的数量。而有了内存索引后，即使用户只输入三四个词，我们也可以自动扩展出 50 个同义词，比如餐厅、餐馆、咖啡馆、小酒馆等。这让我们在 2001 年就实现了从精确匹配到语义理解的跨越。

（关于实时更新的逻辑）在 Google 早期，索引更新率是变化最剧烈的参数，从以前的每月更新一次，进化到能在不到一分钟内更新页面。对于新闻类查询，如果你给用户看的是上个月的索引，那基本就没用了。虽然我们推出了 Google 新闻产品，但同时也希望当用户在主索引中输入新闻相关的查询时，结果也能保持某种程度的实时更新。幕后有一套完整的系统在决定更新频率和页面的重要性。即使有些页面的更新率看起来很低，你可能仍希望频繁地重新爬取重要页面，因为尽管它们发生变化的概率不高，但保持更新的价值却极大。

Shawn Wang： 提到延迟和存储，这让我想起你的经典作之一，即每个程序员都该知道的延迟数字。这背后有什么故事吗，你是直接记录下来的吗？

Jeff Dean： 那份清单涵盖了大约 8 到 10 种不同的指标，例如缓存未命中耗时、分支预测错误耗时、引用主内存耗时，以及从美国向荷兰发送一个数据包需要多长时间。之所以选择荷兰，只是因为我们在荷兰有一个数据中心。这触及了进行快速估算的重点，这些指标是计算的原始素材。你可以利用它们来评估方案，比如在设计图像搜索系统时，是预先计算缩略图还是从大图实时生成。掌握了这些基本数字，你就能在几十秒内完成思想实验。

Jeff Dean： 我认为思考模型在训练或推理过程中的计算量非常有益。一个很好的视角是观察你需要从内存中带入多少状态，无论是片上的 SRAM，还是来自加速器连接内存的 HBM，或者是 DRAM 以及通过网络传输。相对于矩阵乘法单元中实际乘法的成本，这种数据搬运的成本是极其昂贵的。计算本身的成本其实非常低，根据精度不同，通常低于 1 pJ（皮焦耳）。核心在于能效以及如何制造最节能的系统。将数据从芯片一侧的 SRAM 移动到同一芯片的另一侧，即使不离开芯片，也可能消耗能量。

（关于批处理的能量代价）这就是 Batch 维度发挥作用的地方。如果 Batch Size 为 256，情况还不算太糟，但如果 Batch Size 为 1，效率会非常低下。如果你为了进行乘法而花费能量去搬运模型参数，那将非常不划算。这正是人们进行批处理的物理意义。理想情况下，你希望 Batch Size 为 1 以获得最佳延迟，但由此带来的能量成本和计算效率损失是巨大的。TPU 采用了规则的 2D 或 3D 网格结构，连接了大量芯片，每一个都配备了 HBM。在模型推理服务中，如果模型能完全装进 SRAM，那将是一个巨大的胜利。

（关于 TPU 设计周期）TPU 芯片架构团队与高层建模专家之间有很多互动。我们非常看重协同设计的优势，根据我们对机器学习研究未来趋势的判断来规划未来的 TPU 应该是什么样。作为 AI 硬件设计师，从今天开始设计一款芯片，可能需要两年时间才能在数据中心落地，然后它必须拥有 3 到 5 年的合理生命周期。这意味着你试图在一个变化极快的领域中预测 2 到 6 年后的计算需求。通过研究那些我们认为会在那个时间框架内生效或变得更重要的科研想法，我们能够将有趣的硬件特性放入 TPU N+2 代中，重大的架构改动需要芯片在设计周期的早期就介入。有时我们会加入一些投机性的功能，虽然会占用一点芯片面积，但如果成功了，可能会让某些操作快 10 倍。

（关于精度与解码技术）我是极低精度的坚定支持者，数据传输的能耗是按每比特皮焦耳计算的，减少比特数是降低能耗的绝佳方法。目前大家通过引入适用于大量权重的缩放因子，在极低精度领域（如三元权重）取得了很多进展。此外，投机解码是另一种可以获得等效小批量因子的方法，例如你可以预报 8 个 Token，这能让你将有效 Batch Size 增加 8 倍。即使最后只接受其中的 5 或 6 个 Token，你在权重搬运成本的摊销上也能获得 5 倍的效率提升。从真实的能量、延迟和吞吐量视角来看待这些技术是非常有益的。

Alessio Fanelli： 是否存在反向限制的情况，比如因为已经致力于某种芯片设计，所以无法采用某种模型架构？

Jeff Dean： 肯定会有需要调整模型架构以适应芯片的情况，从而确保在特定代际的芯片上实现高效的训练和推理。这是一个双向的过程。有时你可以利用未来代际中出现的低精度特性，即使当前代际还无法完全支持，你也可以提前使用这种低精度进行训练。

Jeff Dean： 我们的研究范畴其实非常广泛。在研究方向上，目前存在很多开放性问题，比如如何让模型变得可靠，如何处理包含许多子任务的长流程复杂任务。此外，如何让强化学习在不可验证的领域发挥作用也是一个非常有趣的课题。目前我们在数学和编码等可验证领域看到了显著进步，如果我们能开发出有效的强化学习技术并应用到非验证领域，将极大扩展模型的能力。可以通过其他模型来评估第一个模型的结果，甚至包括检索过程你可以让另一个模型判断检索到的内容是否相关，或者对检索到的 2000 条结果进行评分。评价者甚至可以是同一个模型，只是扮演批判者的角色。

（关于符号系统与统一模型）关于 AlphaProof 和 AlphaGeometry，我从来不认为将独立的离散符号系统与神经网络强行结合是有意义的。人类虽然操纵符号，但大脑内部可能并没有符号化的表示。我们拥有的是某种神经网络式的分布式表示。今年转向单一的统一模型（不再需要专门的几何模型），这证明了通用模型的能力已经大幅提升。我认为在大多数情况下，通用模型最终都会战胜专用模型。现在的统一模型处理一切，关键在于它们对未知任务的泛化能力正变得越来越强。

（关于知识与推理的剥离）如果模型具备检索能力，你肯定希望它能把参数空间更多地用于推理。让模型消耗宝贵的参数空间去死记硬背那些随处可查的冷门事实，效率并不高。你也不希望模型对世界一无所知，比如了解金门大桥的长度能让它有常识性的感知，但它不需要知道偏远地区的小桥。将检索与推理结合，并让模型擅长执行多级检索，是提升模型能力的有效途径。以个人版 Gemini 为例，我们倾向于使用一个通用模型，将访问电子邮件、照片等作为一种工具，让 AI 通过检索来进行推理。

（关于垂直领域的前景）垂直模型很有趣。你可以在一个优秀的基座模型上，针对特定垂直领域丰富其数据分布。以机器人领域为例，如果你想做顶尖的机器人模型，你就需要在基座上针对机器人数据进行强化训练。这可能会稍微牺牲多语言翻译能力，但会换取更强的机器人操控能力。未来的趋势可能是专业化模型与模块化模型的结合。如果能把语言能力、机器人模块、医疗模块像插件一样编织在一起协同工作，那就太理想了。医疗领域确实很特殊，很多优质数据无法公开获取，因此与大型机构合作开发定制化模型是一个机会。

Shawn Wang： 你以前提到过一个有趣的例子，只需将一种低资源语言放入上下文中，模型就能学会。

Jeff Dean： 是的，比如 Kalamang 语。这种语言全球只有约 120 人使用，而且没有书面文字。对于像索马里语或阿姆哈拉语这种有一定文本存量的语言，如果你在上下文中提供更多数据，模型的能力就会显著增强。我早期做过一个 DeViSE 模型，它发现即使给模型一张它从未见过的类别（如显微镜图片），只要它在训练中接触过望远镜和双筒望远镜它就能通过语义关联，准确地分配标签。

Jeff Dean： 在某种程度上我同意这个看法。事实上，我当时写过一份单页备忘录，直言不讳地指出我们分散资源的策略非常愚蠢。具体来说，当时 Google Research 内部有多个并行的项目：Brain 团队在研发大语言模型，同时 Brain 的其他小组以及 Google Research 的其他部门也在尝试多模态模型。此外，原 DeepMind 团队还有 Chinchilla 和 Flamingo 等模型项目。我们不仅在算力资源上表现得极其碎片化，甚至在顶尖人才和核心资源的分配上也是分散的。

我当时主张，我们应该整合所有力量，集中精力训练一个从底层设计开始就是多模态、全能且极其强大的统一模型。这就是 Gemini 项目的起源。我的那份备忘录最终起到了作用，这很令人欣慰。

Shawn Wang： Gemini 这个名字也是你起的？

Jeff Dean： 是的。当时还有另一个候选名称，但我认为这两个组织合并在一起，在某种意义上就像双胞胎合体，我非常喜欢这个寓意。此外，Gemini 也是 NASA 早期的一个重要航天计划，是通往阿波罗计划的关键一步，所以这看起来是一个非常合适的名称。

Jeff Dean： 首先，目前的编码工具比一两年前有了质的飞跃。作为软件工程师，你现在可以放心地把更复杂的任务委派给这些工具，让它们协助你实现目标。人类工程师与模型之间的互动有一个美妙的特性：你与模型对话的方式直接决定了它与你互动的方式。你可以要求它编写高质量测试用例，或进行性能优化的头脑风暴。你的沟通方式会塑造模型的响应。你需要决定让模型在多大程度上独立执行任务，或者通过更频繁的互动来确保方向正确。我认为没有哪种风格是绝对完美的，某些问题需要频繁交互，而另一些只需要清晰的需求定义。

（关于 AI Agent 的管理模式）未来会演变成一种拥有大量独立 AI Agent 代表你处理事务的模式。我们需要找到最合适的人机交互模型和 UI，例如 AI 何时该中断请示，何时该询问下一步。想象一下，如果你管理一个 50 人的实习生团队，你会如何管理？如果你管理得好，这会带来巨大的生产力。你可能会让他们组成小的子团队，这样你只需要对接 5 个团队负责人。在一个没有任何 AI 辅助的传统组织里，50 个人协同工作往往是等级森严且沟通不畅的。但如果你有 5 个人，每人管理 50 个虚拟 Agent，那么这 5 个人之间可以进行极高带宽的沟通。这种效率远高于 5 个需要各自协调 50 名真实员工的主管。

（关于规格说明与指南的价值）过去老师总是强调编写规格说明极其重要，但很少有人践行。现在，编写英文规格说明书成了驱动创作的核心。当你指定 AI Agent 编写代码时，你必须严谨定义需求，因为这决定了输出质量。如果你忽略了边缘情况或性能需求，输出就无法达到预期。高质量的软件开发指南非常有用，你可以将其放入编码 Agent 的上下文中。例如在分布式系统领域，通过指南告诉 AI 如何考虑各种故障模式，以及处理这些故障的技术，比如类 Paxos 复制或者双向请求容错技术。给 AI 提供几十种此类技术的描述，能极大地帮助它构建出更可靠的系统。

Shawn Wang： 我常开玩笑说，优秀的 Prompt 沟通其实与高级行政沟通没有区别，就像撰写内部备忘录一样需要字斟句酌。

Jeff Dean： 没错。此外，多模态非常重要，Google 推出的包括视频输入在内的多模态能力，是与模型进行高带宽沟通的最佳方式。

Jeff Dean： 关于 Spanner 和 CAP 定理，在某些局部假设和精准时钟同步的前提下，确实可以这么说。但模型通常会非常固守你告诉它的规则。关于 Prompt 迭代，我一直想做一个实验，对比两种模式：一种是三次快速的模型调用配合人类在中间进行对齐校正；另一种是你花很长时间写一个非常复杂的长 Prompt。很多时候，AI 表现不佳是因为需求定义不清晰。在需求模糊时，AI 产出的 10 种结果中可能只有一种是你想要的。因此，与快速模型进行多轮交互通常就足够了。

（关于延迟的预测）我坚信必须不断降低延迟，极低延迟的互动体验远比慢上 10 倍的系统更愉悦。未来，底层系统的延迟会比现在低 20 到 50 倍。帕累托曲线一直在不断攀升。如果不考虑成本，你肯定希望一直拥有 DeepThink 这种深度推理能力。如果底层硬件能将延迟降低 20 倍，你没有理由不使用它。但到那时你可能会研发出一个更先进的模型，它可能又要多跑 20 倍的时间。

（关于未来预测）我有两个预测。首先，个性化模型将变得异常强大。一个了解你、掌握你所有授权状态（邮件、照片、视频）并能检索信息的模型，会比通用模型有用得多。其次，越来越多的专用硬件将以更低廉的价格实现更低延迟、强大的模型。

（关于 10,000 TPS 的意义）每秒 10,000 个 Token 将是极其惊人的。这意味着你可以让模型产生更多的并行尝试、生成更多代码并进行自我检查。在那个速度下，人类可能来不及阅读代码，但模型最终输出的 1,000 个 Token 代码背后，可能包含了 9,000 个 Token 的逻辑推理过程。事实上，这种带有详细推理支撑的代码反而更易于人类阅读和理解。