来源： Latent Space | Jeff Dean（Google Chief AI Scientist）| 2025 原文发表： Feb 13, 2026 纪要生成： 2026-02-22
Jeff Dean 是 Google Chief AI Scientist，同时也是 Google 传奇级工程师之一。他在 2001 年主导了 Google 搜索索引的内存化改造，2006 年联合发表 MapReduce，2011 年加入 Google Brain 并推动了深度学习在 Google 的规模化落地，2014 年与 Geoffrey Hinton 共同提出模型蒸馏框架，此后还主导了 TPU 的研发以及 Google 内部 AI 团队（Brain + DeepMind）的整合，最终孕育了 Gemini 系列模型。本集由 Latent Space 主持人 Alessio Fanelli 和 Swyx（Shawn Wang）共同主持，围绕 AI 基础设施的系统性思维、模型架构演化、硬件协同设计和未来预测展开深度对话。
本节重点 - Jeff Dean 被介绍为 Google Chief AI Scientist，以 Gemini 系列"拥有 Pareto Frontier"开场 - Pareto Frontier 指在效率与能力两个维度同时领先 - 这一成就是硬件、模型研究、软件技术多层次协同的结果
详细精要
Swyx 开场直接向 Jeff 道贺——祝贺 Gemini 系列"拥有了 Pareto Frontier"。所谓 Pareto Frontier，在 AI 模型领域指的是：在相同成本/延迟约束下能力最强，或在相同能力约束下成本/延迟最低。真正占据 Pareto Frontier 的含义是：没有任何模型能在两个维度上同时超过你。
Jeff 回应，这一成绩并非单一技术突破的结果，而是"整个技术栈上下众多因素的叠加"。他特别提到，这包括：训练超大规模前沿模型的能力、通过软件技术将大模型能力压缩到轻量级模型的手段、以及让这些轻量模型在成本和延迟上保持竞争力的工程实践。这种对系统性思维的强调贯穿整集——Jeff 始终从全栈视角而非单一技术点来审视 AI 进展。
💬 精华片段
它不只是某一件事，而是整个技术栈上下众多因素的叠加，所有这些因素共同帮助我们训练出高度能干的大模型，同时也通过软件技术将这些能力注入更小、更轻量的模型之中。
"It's not just one thing. It's like a whole bunch of things up and down the stack. And all of those really combine to help make us able to make highly capable large models, as well as software techniques to get those large model capabilities into much smaller, lighter weight models."
本节重点 - 前沿模型（Pro/Ultra）与高效模型（Flash）定位不同，服务不同用例 - 蒸馏是将大模型能力注入小模型的核心技术路径 - Flash 已被部署到 Gmail、YouTube、Search 的 AI Mode 等大规模产品
详细精要
Alessio 提出一个核心张力问题：对于 Google 这种拥有数十亿用户的公司，如何在推进前沿能力与大规模可部署之间取得平衡？初创公司往往全力冲刺顶端性能（因为需要融资故事），而 Google 需要同时兼顾两端。
Jeff 的回答揭示了 Google 的双轨策略：
前沿模型的作用：前沿模型（比如 Ultra/Pro 级别）展示了当前存在但此前不存在的能力。对于深度推理、复杂数学、长链条任务，你需要最顶端的模型。
Flash 模型的作用：Flash 是"高度能干且经济实惠的模型"，专门服务于需要低延迟的大规模用例——代理式编程、实时 AI 功能等。重要的是，Flash 已经被部署到 Gmail、YouTube、Google Search 的 AI Mode 中，承载了海量真实用户流量。
蒸馏将两者联系起来：你必须先有前沿模型，才能蒸馏出好的小模型。这不是"要么要么"的选择——你需要前沿模型，不仅仅是为了展示能力，更是为了作为蒸馏的"教师模型"。Jeff 透露，Gemini 已经多代实现了"Flash 版本≈上一代 Pro 版本，甚至更好"的目标，这一趋势还将持续。
💬 精华片段
通过蒸馏技术，你必须先有前沿模型才能将其蒸馏进更小的模型。所以这不是非此即彼的选择，你需要前沿模型才能获得一个高能力的小型模型。
"Through distillation, you have to have the frontier model in order to then distill it into your smaller model. So it's not like an either-or choice. You sort of need that in order to actually get a highly capable, more modest size model."
本节重点 - 蒸馏最初来自大规模图像数据集的多专家集成压缩需求 - 核心机制：用大模型的 logits（软标签）替代硬标签来训练小模型 - 与 RL 革命的潜在协同：蒸馏可能是解决能力合并而不退化的关键
详细精要
Alessio 提到 Jeff 和 Geoffrey Hinton（以及 Oriol Vinyals）在 2014 年共同提出了蒸馏技术。Jeff 回溯了其原始动机：
起源背景：当时 Google 有一个约 3 亿张图片的大型图像数据集。研究人员发现，如果针对不同图像类别子集分别训练专门的"专家"模型（哺乳动物专家、室内场景专家等），每个专家在自己的子领域性能都更好。将约 50 个专家模型组合成集成体，效果很好——但集成体不实用，无法真正部署。
蒸馏的诞生：核心问题是：如何服务这个集成体？答案就是蒸馏——用集成体的输出（logits，即软概率分布）来训练一个单一的、可部署的小模型。软标签比"硬标签"（非此即彼的类别标签）包含更丰富的信息，因为它们保留了大模型对不确定性的理解。
现代映射：今天的蒸馏不再是"50 个专家模型"，而是"一个超大规模模型→蒸馏→一个小规模可部署模型"。机制相同，规模不同。
与 RL 的协同：Swyx 提出一个有趣猜想——RL 训练会让模型在分布的某个维度上"峰值化"，可能在其他维度退化；蒸馏可能是解决"能力提升而不退化"的关键路径。Jeff 认同蒸馏的一个核心优势：小模型可以用远大于自身规模的训练数据集进行训练，并且通过多次遍历数据（multi-pass）获益，因为大模型的 logits 提供了"软监督"而非仅仅硬标签。
💬 精华片段
蒸馏的关键优势之一是你可以有一个更小的模型，配合非常大的训练数据集，并且能从多次遍历数据中获益——因为你现在用的是更大模型的 logits 来引导小模型表现出正确行为，而不只是硬标签。
"One of the key advantages of distillation is that you can have a much smaller model and you can have a very large training data set and you can get utility out of making many passes over that data set because you're now getting the logits from the much larger model in order to sort of coax the right behavior out of the smaller model."
本节重点 - Google 同时维护多种规模的模型，包括不对外发布的内部训练模型 - Flash 的经济性使其成为 Gmail、YouTube、Search 等产品的主力 - 推测解码（speculative decoding）和推理时扩展（inference-time scaling）也是提升能力的工具
详细精要
Swyx 询问具体的模型层级——Flash、Pro、Ultra 三档模型中，是否有一个超大的"母舰"模型专门用于蒸馏？
Jeff 的回答透露了一些内部架构信息：Google 内部有多种不同规模的模型，其中有些是纯内部训练模型，不一定面向对外发布或直接服务；有些则是 Pro 规模模型，可以蒸馏到 Flash 规模。此外，推理时扩展（inference-time scaling，即给模型更多推理预算来提升回答质量）也是提升能力的重要手段。
Flash 的经济性带来了大规模部署的飞轮效应：
这种大规模部署不仅是商业成果，也是提供"真实世界反馈"的宝贵数据来源，推动下一代模型改进。
本节重点 - 低延迟不仅是用户体验问题，更是解锁"代理式任务"的前提 - 用户需求会随模型能力提升而升级，延迟感知随之放大 - 未来推理工作负载需要 10,000 token/s 级别的速度
详细精要
Jeff 特别强调延迟是一个被严重低估的关键属性。其核心逻辑是：
任务复杂度的升级：以前人们让模型"写一个 for 循环"，现在让模型"写一个完整的软件包"。任务复杂度上升意味着模型需要生成更多 token，延迟的累积效应被放大。一个速度慢 10 倍的模型，对于简单问题可能影响不大，但对于需要生成 10,000 个 token 的复杂任务，就变得完全不可接受。
代理式工作流的要求：在代理式编程场景中，模型需要在一个任务的多个子步骤之间连续生成内容；用户不会盯着屏幕等每一步，系统需要快速完成整个工作流。低延迟系统才能让代理任务变得实用。
TPU 硬件的贡献：Jeff 提到 TPU 的高性能芯片间互联对于长上下文注意力运算和稀疏专家（Mixture of Experts）模型的服务化起到了关键支撑作用。
万级 token/s 的未来：Jeff 在后段预测，10,000 token/s 的推理速度将成为现实，届时模型可以进行更多并行推演（rollout）、生成更多代码并自动验证。到那时，推理成本和延迟的约束被解除，DeepThink 类的深度推理模式将成为常态而非奢侈品。
本节重点 - 随着模型能力提升，用户会提出更复杂的需求，"饱和"并非终局 - 公开基准测试一旦达到 95% 以上就失去意义（数据泄露/能力已验证） - Google 维护严格隔离的内部基准，专门测试尚未解决的能力
详细精要
Alessio 提出一个战略层面的问题：如果 Flash 模型两代后就能处理大多数人的所有任务，还有什么驱动继续推进 Pro 前沿的动力？
Jeff 的回答很有洞见：需求是动态升级的，不是静态的。
他以自己的亲身体验举例：一年前他用模型做某些编程任务，简单任务"还行"，复杂任务"效果不好"。现在复杂任务大幅提升后，他开始问模型更复杂的问题——"帮我分析全球可再生能源部署情况，生成一份关于太阳能电池板部署的报告"。这种需求在一年前根本不会出现。所以模型越强大，人们提出的任务就越雄心勃勃，"饱和"只是相对于当前任务分布而言的。
基准测试的生命周期：Jeff 认为最好的基准测试应该在引入时初始分数在 10-30%，然后随着模型改进逐步提升到 80-90%。一旦达到 95% 以上，这个基准就失去价值——要么能力已被验证，要么存在训练数据泄露问题。以"长上下文-单针haystack基准"为例，已经完全饱和，需要更复杂的多针检索或真实场景基准。
内部保密基准：Google 维护着一套严格隔离的内部基准，这些测试明确不在训练数据中出现，针对的是模型当前尚不具备但希望获得的能力。通过分析在这些基准上的短板，团队决定是需要特定领域数据、架构改进，还是其他干预手段。
💬 精华片段
分布如果不是静止的，这个论断就不成立。随着模型越来越强大，人们要求它做的事情也越来越多——这和我自己的使用情况完全吻合。
"That's true, if your distribution of what people are asking the models to do is stationary. But what often happens is as the models become more capable, people ask them to do more."
本节重点 - 当前百万级上下文是有价值的，但距离"访问全部互联网"仍差几个量级 - 纯扩展注意力窗口（二次复杂度）无法到达万亿 token - 真正的解法是构建分层检索系统，"给出访问万亿 token 的幻觉" - 个人 AI 场景：访问用户的所有邮件、照片、文档将极其有价值
详细精要
这一节是全集最具战略视野的讨论之一。Jeff 表达了一个核心观点：长上下文是真实有用的，但现有技术路径无法扩展到理想规模。
问题的规模鸿沟：当前 Gemini 在 1M-2M token 的长上下文上已经是前沿，这很好。但如果你真正想要的是"回答问题时能够注意到整个互联网"，那你面对的是万亿 token——而标准注意力机制是二次复杂度（quadratic），1M token 已经是极限，扩展到 1T token 根本不可行。
Swyx 的有趣发现：即使你每天说话 8 小时，整个生命周期生成的 token 最多也就是几百万量级，完全在当前上下文窗口范围内。但互联网内容、视频内容、蛋白质序列等非语言信息密度极高的数据，体量就完全不同了。
Jeff 的解决方向：不应该寄希望于直接扩展上下文窗口，而应该通过算法改进+系统级改进，构建让人"感觉像在访问万亿 token"的系统。这意味着：
个人 AI 的愿景：Jeff 特别强调"个性化 Gemini"的概念——不训练在你的个人数据上，而是将访问个人数据作为一个工具，让模型能够检索你的邮件、照片，进行多轮交互推理。这将使 AI 助手真正变得"个人化"而非通用化。
💬 精华片段
如果你能给人以访问万亿 token 的幻觉，那将是惊人的。你会为此找到各种各样的用途——可以访问整个互联网，可以访问 YouTube 上的每一帧像素，在个人层面上可以访问你所有的个人状态……
"If you could give the illusion that you can attend to trillions of tokens, that would be amazing. You'd find all kinds of uses for that. You would have attend to the internet. You could attend to the pixels of YouTube... on a personal Gemini level, you could attend to all of your personal state."
本节重点 - 视觉和运动（视频）是最核心的模态，因为进化 23 次独立演化出了眼睛 - Gemini 是目前唯一的原生视频理解模型 - 非人类模态（LIDAR、MRI、基因组学）同样有价值，少量预训练数据即可"激活"
详细精要
Swyx 提问：是否存在"王者模态"——比如视觉是否可以编码文字和音频，从而统治其他一切？
Jeff 的回应引入了一个进化论视角：视觉和运动（视频）之所以重要，是因为进化独立演化出眼睛超过 23 次。这在生物进化中极为罕见，证明了视觉感知对于理解世界的根本重要性。我们希望这些模型能够解读它们"看到的"或"关注到的"东西，并利用这些信息来帮助人类。
Gemini 的多模态野心：Gemini 从设计之初就是多模态的，不仅限于文本+图像+视频（人类模态），还包括：
关键洞察：即使某个模态（如 LIDAR）的数据量不够多，不值得放入主要预训练数据组合，加入少量仍然有价值——因为它让模型知道"这个模态是真实存在的，在世界上有其含义"。
视频理解的实际用例：Jeff 分享了一个具体示例：给 Gemini 一个 18 个精彩运动时刻的 YouTube 集锦视频（跨越 20 年，包括乔丹跳投等），直接问"帮我列出这 18 个事件的时间、描述"，模型可以生成一个 18 行的结构化表格。这种"视频→结构化数据"的能力是大多数人没有想到的。
本节重点 - 现代 LLM 检索系统与 Google 搜索排名系统在架构上高度相似 - 都是从海量候选逐步漏斗式过滤到极少数最相关结果 - LLM 基于语义表示而非关键词匹配，但系统架构逻辑相通
详细精要
Alessio 提出一个思考：Google 搜索的核心价值是帮助人类处理"无法直接浏览整个互联网"的问题。对于 LLM 来说，这个检索模型是否需要重新设计？人类可能看前 5 个搜索结果，但 LLM 可能需要访问 20 个高度相关的文档？
Jeff 的回答揭示了一个深刻的架构相似性：
经典 Google 搜索的漏斗架构： 1. 从数十亿网页的完整索引开始 2. 用极轻量的方法识别"相关"子集，缩减到约 3 万个文档 3. 逐步应用更复杂的算法和信号，进一步过滤 4. 最终输出给用户的是约 10 个结果（加其他类型信息）
未来 LLM 检索的类比架构： 1. 同样从"万亿 token"的起点开始 2. 高度并行的轻量模型识别初步候选（约 3000 万 token → 3 万个文档） 3. 中间层模型进一步筛选到 117 个最相关文档 4. 最强的前沿模型处理这 117 个文档，生成最终答案
LLM 表示的革命性意义：相比关键词搜索，LLM 基于的语义表示使得检索摆脱了"页面上必须出现特定词汇"的限制，真正捕捉"这个段落与这个查询主题高度相关"的语义关系。Jeff 指出，BERT 在 Google 搜索中的应用早已带来了巨大的质量提升（尽管具体数字未公开）。
💬 精华片段
系统会像 Google 搜索给你"搜索整个互联网"的感觉一样，在某种程度上给你访问万亿 token 的幻觉——但只是找到其中极少数真正相关的内容。
"It has to be some system like that, that really enables you to give the illusion of attending to trillions of tokens. Sort of the way Google search gives you... you are searching the internet, but you're finding a very small subset of things that are relevant."
本节重点 - 2001 年，Google 将整个搜索索引从磁盘迁移到内存，是一次关键质量飞跃 - 内存索引使得查询扩展（同义词、形态变化）成为可能，实现"查询语义软化" - 索引更新频率从"每月一次"到"任何页面在一分钟内可更新"，提升超六个量级
详细精要
这一节是罕见的 Google 搜索技术内部史料。Jeff 在 2009 年 WSDM（Web Search and Data Mining）会议上做过相关演讲，将 1999-2004/2005 年的搜索系统演进梳理成了四到六代。
分片架构的诞生：随着互联网规模增长，Google 引入了分片（sharding）系统——将索引分割成多个分片（如 30 个分片），每个分片处理一部分查询。索引扩大一倍就增加一倍分片（60 个），以控制单个用户查询的延迟。随着流量增长，再为每个分片增加副本（replica）。
内存索引的革命：2001 年，团队做了一个关键计算：若数据中心有 60 个分片、每个分片 20 个副本，共 1200 台机器（有磁盘）。计算发现：整个索引的一份完整副本刚好可以放入这 1200 台机器的内存中。于是他们将整个索引迁移到内存，效果立竿见影：
更新频率的进化：索引更新频率是变化最大的参数。从每月一次更新，逐步提升到任何一个页面在不到一分钟内即可完成更新——提升了超过五个量级。这使得新闻类查询（如"breaking news"）不再返回过时信息，也使 Google News 从主搜索中分离成为独立产品成为可能。背后有整套系统决定每个页面的"更新优先级"——重要页面即使更新频率低也要频繁重新抓取，因为其更新价值极高。
💬 精华片段
一旦整个索引在内存中，就完全可以接受在查询中用到 50 个词——因为现在你可以添加同义词，比如"restaurant"和"restaurants"和"cafe"和"bistro"，从而真正捕捉用户输入词语背后的含义，而不只是用户精确输入的语义形式。
"Once you have the whole index in memory, it's totally fine to have 50 terms you throw into the query... because now you can add synonyms like restaurant and restaurants and cafe and bistro... really getting at the meaning of the word as opposed to the exact semantic form the user typed in."
本节重点 - 计算瓶颈不是 FLOP，而是数据搬运的能耗（皮焦耳/bit） - 一次跨芯片数据搬运比一次矩阵乘法贵约 1000 倍 - 批处理的根本原因是分摊数据搬运成本，而非计算利用率 - 推测解码等价于将有效 batch size 提升 5-8 倍
详细精要
这一节是全集最具工程深度的讨论，Jeff 以能耗（energy）而非 FLOP 为分析单位，给出了一套全新的思维框架。
"延迟数字"的经典传承：Jeff 曾经整理过"每个程序员都应该知道的延迟数字"——缓存未命中耗时多久、分支预测失败耗时多久、跨大洲网络往返耗时多久等。这些数字是做"信封背面计算"（back-of-the-envelope calculation）的基本原料。他建议，对于模型训练和推理，应该建立类似的直觉数字。
皮焦耳视角的颠覆性： - 一次矩阵乘法的能耗：约 1 皮焦耳以下（取决于精度） - 在同一芯片上搬运数据（从 SRAM 的一侧到乘法单元）：约 1000 皮焦耳 - 差距：1000 倍
这意味着：把一个模型参数从片上 SRAM 搬运到乘法单元，代价是 1000 皮焦耳。然后用这个参数做一次乘法是 1 皮焦耳。如果你只做一次乘法，效率只有 0.1%。
批处理的真正原因：这解释了为什么需要批处理（batching）——如果 batch size = 256，那么一次数据搬运的 1000 皮焦耳被 256 次乘法平摊，每次乘法分摊约 4 皮焦耳，效率大幅提升。如果 batch size = 1，效率极低。但 batch size 越大，延迟越高——这就是延迟与吞吐量之间的根本张力。
推测解码（Speculative Decoding）的能耗解读：推测解码通过小模型预测接下来 8 个 token，大模型并行验证并接受约 5-6 个。这等价于将有效 batch size 提升了 5-6 倍——同样的数据搬运成本，换来了 5-6 倍的有效计算利用率，从而降低了大模型的实际推理成本。
低精度的价值：Jeff 强调低精度（低 bit 量化）是降低能耗的绝佳方式，因为传输的是"皮焦耳/bit"——减少 bit 数就直接减少能耗。有一种有效技巧是极低精度权重（如 ternary）配合作用于权重组的缩放因子（scaling factors），在精度损失最小的情况下实现大幅压缩。
💬 精华片段
从芯片 SRAM 的另一侧搬运数据（甚至不是离开芯片，只是芯片内部的另一侧）可能需要 1000 皮焦耳。所以加速器需要批处理——如果你把一个模型参数搬运到乘法单元，那会花掉 1000 皮焦耳，你最好让这个东西被用很多很多次。这就是批处理维度存在的原因。
"Moving data from the SRAM on the other side of the chip... can be a thousand picojoules. So all of a sudden this is why your accelerators require batching... you better make use of that thing that you moved many, many times."
本节重点 - 硬件设计需要预测 2-6 年后的 ML 计算需求，这在快速变化的领域极具挑战 - ML 研究团队与 TPU 芯片架构团队深度协作，形成双向反馈循环 - 有时会在芯片中加入"投机性功能"——成本低但若成功可带来 10 倍加速
详细精要
Alessio 询问 TPU 设计决策的内部流程：如何决定哪些硬件优化值得做？
设计时间轴的挑战：一个芯片从设计开始到进入数据中心，通常需要约 2 年。加上芯片的使用寿命（3-5 年），意味着今天设计的芯片需要在 2-6 年后的 ML 工作负载下仍然高效。在变化如此之快的领域，这种预测极为困难。
双向协同设计机制：Google 建立了 ML 研究团队与 TPU 芯片架构团队之间的持续反馈循环。研究团队分享他们认为在未来 2-6 年内会开始奏效或变得更重要的 ML 研究方向，这些洞察被提前固化进 TPU N+2 版本的硬件设计中（N 是当前版本，N+1 可以加入小改动，N+2 需要提前规划）。
投机性硬件功能：有时团队会在芯片中加入成本极低（占用很少芯片面积）但潜力巨大的功能——如果这个功能对应的 ML 趋势成真，可以带来 10 倍加速；如果未成真，也只损失了一点点芯片面积，影响微乎其微。对于成本更高的大改动，则需要大量 ML 实验来验证，确保方向正确后才放入芯片。
反向约束：有时也会出现反方向的约束——因为芯片设计已经确定，模型架构需要适应已有芯片的特性。Jeff 提到，有时会提前按照下一代芯片将支持的低精度来训练模型，即使当前芯片不完全支持。
精度降低的趋势：对于精度下限的探索，Jeff 对极低精度（如 ternary，即三值）持开放态度，但认为配合组级别的缩放因子（scaling factors）是当前最有效的工程实践路径。
本节重点 - 如何让模型完成包含大量子任务的长链条复杂工作流，是最重要的开放问题之一 - 将 RL 扩展到非可验证（non-verifiable）领域是关键突破口 - 用"模型评估模型"的方法（critic 模型）作为非可验证 RL 的可行路径
详细精要
Alessio 问 Jeff 最感兴趣、希望研究者深入探索的方向。Jeff 给出了两个最核心的开放问题：
问题一：复杂多任务工作流的编排
如何让一个模型可靠地完成有大量子任务的长链条工作？这包括： - 一个"主控模型"将其他模型作为工具来调用 - 多个模型协同完成比任何单一模型能独立完成的更重要的工作 - 在中间步骤失败时有鲁棒的处理机制
问题二：将 RL 扩展到非可验证领域
在数学和编程领域，RL 之所以奏效，是因为答案可以被自动验证（代码能跑通/跑不通，数学答案对/错）。但大多数真实世界任务不具备这种可验证性。如果能将 RL 的强化机制应用到非可验证领域，模型能力将大幅扩展。
一个可行方向：模型评估模型
Alessio 提到 Noam Brown 曾表示 Deep Research 已经证明了这一点——用一个模型来评估另一个模型的输出质量，作为 RL 的奖励信号。Jeff 认可这个方向，并指出可以是同一个模型用不同提示词切换成"批评者"（critic）角色，对检索到的内容进行相关性评分，或从 2000 个检索结果中选出最相关的 50 个。
进展令人震撼：Jeff 回顾说，两年前模型还在挣扎于 GSM8K 问题（"Fred 有两只兔子，再得到三只，他有几只"），而现在模型已经能用纯自然语言攻克 IMO（国际数学奥林匹克）和 Erdős 问题。在一年半内完成这一飞跃是极其惊人的。他认为，在其他领域复制这一跃迁是接下来最令人期待的研究方向。
本节重点 - AlphaProof/AlphaGeometry 使用符号系统，而当年之后 Gemini 直接用通用模型超越 - Jeff 认为神经网络比"独立的符号系统"更接近人脑的真实运作方式 - 2013-2016 年的"统一模型淘汰任务专用模型"历史正在大规模重演
详细精要
Swyx 提出一个犀利问题：一年前，大家在用 AlphaProof（结合 Lean 验证器的符号系统）解决 IMO，而今年却是直接用 Gemini 单一通用模型解决同样问题，这意味着什么？
Jeff 从认知科学角度给出了他的解读：
神经网络是更自然的抽象：人类操作符号，但我们头脑中大概率没有"符号表示"——而是类似神经网络的分布式表示，不同神经元的激活模式对应不同概念，使得我们能够推理、规划和反思。在 Jeff 看来，"完全独立的离散符号系统 + 完全不同的处理方式"从来就不是合理的组合。
统一模型的历史先例：Jeff 指出这一转变并不新鲜——2013-2016 年已经发生过一次：那之前，人们为每个任务单独训练模型（街道标识识别模型、语音识别模型等）。如今"统一模型做一切"的时代已经到来，关键问题是这些通用模型能多快泛化到从未被要求做的新任务。
无需领域专家：Swyx 采访了参与 IMO 攻克的研究员，对方坦承自己"不知道 IMO 竞赛在哪里举办，也不懂比赛规则"——只是在训练模型。这正是"苦涩教训"（Bitter Lesson）的体现：足够的数据+足够的计算，可以解决几乎任何领域问题。Jeff 明确表示："通用模型在绝大多数情况下会战胜专业模型"。
本节重点 - 参数空间有限时，应优先存储"推理能力"而非"记忆冷僻事实" - 大模型 + 检索工具 = 个人化 AI 的最佳架构，无需将个人数据混入训练集 - 垂直模型有存在价值，但应以通用基础模型为起点，在特定领域数据上继续训练
详细精要
知识 vs 推理的权衡：Swyx 提出一个关于模型容量的问题：参数就是 bit，花参数记忆冷僻事实，不如花参数学习通用推理能力，然后让模型"检索+推理"来处理需要具体知识的场景。
Jeff 完全认同这个视角：模型应优先将参数空间用于"通用有用的推理能力"，而非记住"某个冷僻桥梁的长度"。但他也指出，完全脱离世界知识的模型也是不好的——模型需要对世界有基本认识（金门大桥大概多长），这有助于它在各种情境下做合理推断。
检索+推理的具体实现： - 不将 Jeff 的个人邮件混入 Gemini 训练 - 而是维护一个统一的 Gemini 模型 - 访问个人邮件、照片等作为"工具"（retrieval tool） - 模型在多轮交互中推理检索结果，达到"个性化"效果
垂直模型的定位：Jeff 认为垂直模型是"有意义的追求"，关键是要从强大的基础模型出发，然后在领域数据上继续训练。以机器人为例：Gemini 主模型会接触一些机器人数据，但不会穷尽所有机器人数据（因为要平衡整体能力）；如果你要构建最强的机器人模型，从 Gemini 出发再用更多机器人数据训练是正确路径——但可能会损失某些边缘语言能力（如 Perl 编程）。
模块化的未来：Jeff 描述了理想架构——有一个强大的基础模型，然后可以"安装"不同的知识模块（200 种语言模块 + 机器人模块 + 医疗健康模块），在不同情境下协同调用。部分"可安装知识"可以来自检索（实时），但部分应该来自在大量领域数据（如 1 万亿 token 的医疗数据）上预训练的模块。
💬 精华片段
用宝贵的参数空间去记住能被查找到的冷僻事实，实际上并不是这些参数空间的最佳用途。
"Having the model devote precious parameter space to remembering obscure facts that could be looked up is actually not the best use of that parameter space."
本节重点 - Kalamang 语：全球约 120 人使用，无书面文字，可以直接放入上下文让模型学习 - 索马里语、埃塞俄比亚语等语言通过增加训练数据可显著提升模型表现 - 跨模态融合（语言+视觉）使模型能够识别从未见过的新概念
详细精要
Swyx 提到他对语言学的兴趣，以及 Jeff 曾分享过的一个精彩案例。
Kalamang 语的极端案例：Kalamang 是一种真正的低资源语言，全世界约 120 人使用，且没有书面文字。Jeff 提到的神奇之处是：可以将这种语言的"整个数据集放入模型的上下文"中，让模型在上下文中学习，然后就能处理该语言的相关任务。这展示了大型语言模型的上下文学习（in-context learning）能力的极限：能从极少量样本中快速泛化。
语言多样性的数据权衡：对于索马里语、埃塞俄比亚阿姆哈拉语等有一定书面文字但训练数据不足的语言，增加训练数据可以显著提升模型在这些语言上的表现。但这是一个"此消彼长"的权衡——包含更多某种语言的数据，会排挤其他内容（如 Perl 编程数据）。
语言与视觉的融合实验：Jeff 提到他早期做过的一个工作（DeViSE，Device），将语言模型的词向量与图像模型的表示融合。训练完成后，给模型一张从未见过类别的图像（如显微镜——训练集有望远镜和双筒望远镜，但没有显微镜），模型能够推断出"microscope"作为标签，即使它从未看过标记为显微镜的训练图像。这展示了跨模态语义迁移的惊人潜力。
本节重点 - Jeff 在 1990 年本科论文中就研究了并行神经网络训练，坚信"扩展是正确方向" - 2011 年加入 Google Brain，正式将神经网络规模化带入 Google - 写了一页备忘录，指出碎片化算力的愚蠢，推动了 Google Brain+DeepMind 统一为 Gemini 项目
详细精要
1990 年的先见之明：Jeff 在 1990 年本科毕业论文中研究的就是并行神经网络训练——在那个时代，这是极度超前的选择。他当时就相信神经网络是正确的抽象，只是缺乏计算资源。系里的并行计算机只有 32 个处理器，能训练比当时主流更有趣一点的模型，但还远不够解决真实问题。
Moore 定律与规模的融合：从 2008-2009 年起，计算资源终于开始足够大，真正的大规模神经网络开始可行。Jeff 在 2011 年底加入 Google Brain，核心信念就是"应该用大量并行计算来扩大可训练的神经网络规模"。他重新应用了本科论文中就有的模型并行和数据并行技术。
碎片化与统一：到了某个时间点，Google 的 AI 能力分散在多个团队： - Google Research/Brain 团队做大语言模型 - Brain 其他团队做多模态模型 - Legacy DeepMind 做 Chinchilla、Flamingo 等模型
Jeff 写了一页备忘录，核心论点是：这种资源碎片化是愚蠢的——我们不仅分散了算力，还分散了最优秀的人。为什么不整合起来，训练一个真正的多模态统一模型？这个备忘录直接推动了 Gemini 项目的诞生。
Gemini 名称的由来：Jeff 还给 Gemini 起了名字。他解释了两个层次的含义： 1. 双子星（Twins）：两个组织（Brain + DeepMind）走到一起，如同双子 2. NASA Gemini 项目：NASA 历史上的 Gemini 计划是通往 Apollo 登月的关键一步——Gemini 也被寄予同样的里程碑意义
💬 精华片段
我写了一份一页的备忘录说，我们将资源碎片化是愚蠢的……为什么我们不整合起来，做一个从一开始就是多模态的、能做好一切的单一统一模型呢？这就是 Gemini 努力的起源。
"I actually wrote a one-page memo saying we were being stupid by fragmenting our resources... Why don't we combine things and have one effort to train an awesome single unified model that is multimodal from the start, that's good at everything. And that was the origin of the Gemini effort."
本节重点 - 编程工具在过去两年进步显著，现在可以承担复杂任务 - 与编程模型的交互风格决定了输出质量 - 管理 50 个 AI "实习生"的类比：需要合理的团队结构与汇报机制 - 高带宽的人机通信（多模态提示）比纯文本规格说明更有效
详细精要
Alessio 提出一个颇具哲学意味的问题：Jeff 曾谈到与 Sanjay Ghemawat（Google 另一位传奇工程师）结对编程的深度协作——两人的互补思维方式使彼此成为更好的工程师。那么现在与 AI 编程工具协作时，如何找到这种"兼容性"？
与模型的交互风格塑造输出：Jeff 指出，你和编程模型的交互方式直接决定了它如何与你协作： - 让它"写一批好测试" - 让它"帮我头脑风暴性能优化方案" - 这些不同的提问方式，产生完全不同的模型行为和问题解决路径
交互频率的权衡：对于某些问题，你希望频繁与模型交互（确保方向正确）；对于其他问题，你直接说"把这个写完"，让它自主完成再报告结果。没有哪种风格是万能的，取决于任务的清晰程度和复杂性。
50 个 AI 实习生的管理挑战：Jeff 用了一个生动类比——如果你有 50 个 AI 实习生，你会如何管理？你不会直接与所有 50 人互动——你会让他们组成 5 个小组，你与 5 个小组长交互，小组长再协调各自团队。人机协作的 UI 和交互模式设计目前还在早期阶段，随着模型改进，最佳实践也会演化。
多模态提示的高带宽：Swyx 补充，多模态提示（包含视频、图片等）是与模型最高带宽的通信方式。Anti-Gravity 团队的做法——以强多模态内容开始提示——比纯文本规格说明更有效。
💬 精华片段
如果你有 50 个实习生，他们都是真人，你会如何管理？你可能会让他们形成小团队，这样你不必与 50 人都交互，而是与 5 个团队交互，他们在你的代理下行事。
"If you have a team of 50 interns, how would you manage that if they were people? You would probably want them to form small sub teams, so you don't have to interact with 50 of them."
本节重点 - "写好软件规格说明"曾是被忽视的能力，现在变成了决定 AI 输出质量的核心技能 - 规格说明的模糊性直接导致 AI 输出的不确定性（"10 个可能结果中只有 1 个是你想要的"） - 通用的工程最佳实践文档（如分布式系统技术指南）作为 context 注入编程代理，可大幅提升输出质量
详细精要
这是全集最具实践价值的讨论之一。Jeff 提出了一个洞见，可以改变很多人使用 AI 编程工具的方式。
规格说明的历史地位：在传统软件工程教育中，写清晰的需求规格（specification）被教导为重要技能，但在实践中从来没有被认真对待——工程师更愿意直接动手写代码，规格文档只是走流程的东西。
AI 时代的反转：现在，规格说明的质量直接决定了 AI 助手输出的质量。如果你没有说清楚"需要处理这种边界情况"、"这是关键的性能瓶颈"，AI 就不会处理。Jeff 用了一个清晰的表述：规格说明不够充分时，AI 面临的是一个欠定问题——"我可以生成 10 种不同的东西，只有其中一种是你真正想要的"，但它无法知道你想要哪一种。
精确规格说明的技能价值：Jeff 认为，能够精确表达自己想要什么是一个在任何领域都极有价值的技能，不仅仅是软件工程。这个技能在 AI 时代变得更加重要。Swyx 打趣说，这"与足够先进的高管沟通（Executive Communication）没有区别"——写内部备忘录时，每个字都要斟酌。
通用技术指南作为 Context：Jeff 提出一个实用建议：将写好的通用工程技术指南注入编程代理的 context，可以大幅提升输出质量。比如，一份包含"构建分布式系统的 20 个关键技术"的文档（Paxos 式复制、双写容错、失败处理模式等），注入后就能让编程代理自动考虑这些可靠性要素，而不必每次都在提示词中重复。
💬 精华片段
如果你指定了你希望 AI 写的软件，你最好非常非常仔细地表达清楚，因为这将决定输出的质量。如果你没有覆盖它需要处理某种情况，它可能就不会处理。
"If you specify what software you want the agent to write for you, you'd better be pretty darn careful of how you specify that because that's going to dictate the quality of the output."
本节重点 - 预测一：能访问用户所有个人数据的个性化 AI 将极其有价值 - 预测二：更专业的硬件将使模型在可承受价格下大幅降低延迟 - 10,000 token/s 的推理速度将从根本上改变人机协作范式
详细精要
Swyx 请 Jeff 分享两个核心预测，结束本次对话。
预测一：个性化 AI
Jeff 认为，一个能够访问你"所有曾经见过的事物"的个性化模型将带来巨大价值： - 所有邮件 - 所有照片 - 所有你看过的视频 - 所有你参与的文档
这与之前讨论的"检索+推理"架构完全吻合——不是将个人数据混入通用模型训练，而是在用户授权下，通过检索工具让模型访问个人数据。与当前没有这种访问权限的通用模型相比，能力差距将是巨大的。
预测二：专用硬件驱动的低延迟
随着更专业化的硬件到来，当前的推理延迟将大幅降低，成本也将显著下降，而能力不减甚至更强。这将改变整个经济模型。
10,000 token/s 的意义：Swyx 追问：从当前约 100 token/s，到 1000 token/s，到 10,000 token/s，每个量级意义是否真的不同？Jeff 给予肯定回答——10,000 token/s 时代意味着： - 可以做更多并行推演（parallel rollout） - 可以生成远更多代码，并用链式思维推理来自动验证代码是否正确 - 不是生成"一万 token 的代码"，而是"一千 token 的代码 + 九千 token 的推理过程"——这样的代码质量会更高，阅读性更好
延迟的永恒困境：Swyx 观察到一个有趣的"悖论"——即使硬件进步带来 20X 延迟降低，模型也会变得更大、更好，带来新的延迟。Jeff 承认这个循环是永恒的，但关键是Pareto 曲线一直在向外延伸——每次硬件进步之后，即使在新的更高能力水平上，相同成本的延迟也比之前更低。
"多写少读"的编程未来：Swyx 半开玩笑说，在 10,000 token/s 时代，你根本不会读代码了——因为你只会不停生成。Jeff 纠正说：不是生成一万 token 代码让你读，而是生成一千 token 好代码，背后有九千 token 的推理支撑。如果有足够时间，你会写一封更短的信——这是信息密度提升的本质。
💬 精华片段
以 10,000 token/s 生成代码时，结果可能不是一万 token 的代码，而是一千 token 的代码，背后是九千 token 的推理过程——这才是真正更好的阅读体验。
"It may not end up with 10,000 tokens of code. It may be a thousand tokens of code that with 9,000 tokens of reasoning behind it, which would actually be probably much better code to read."
| 术语 | 解释 |
|---|---|
| Pareto Frontier（帕累托前沿） | 在效率与能力两个维度同时领先的模型集合；在 AI 领域指不存在任何模型能在成本/延迟和能力两个指标上同时超过你 |
| Distillation（知识蒸馏） | 用大模型的输出（logits/软概率分布）作为训练信号，训练小模型学习大模型的"知识"；区别于只用硬标签（one-hot）训练 |
| Logits（对数概率） | 模型输出层的未归一化分值，经过 softmax 后变为概率分布；蒸馏中用 logits 而非 hard label 能传递更丰富的信息（如模型对不确定性的认知） |
| Flash Model | Google Gemini 系列中的轻量高效版本，优化延迟和成本，通过蒸馏自 Pro/Ultra 模型获得高能力 |
| Inference-time Scaling（推理时扩展） | 在推理阶段给模型更多计算预算（更多 token 思考）以提升回答质量，与训练时扩展相对 |
| Speculative Decoding（推测解码） | 用小模型快速预测接下来多个 token，再由大模型并行验证；可将大模型的有效 batch size 提升 5-8 倍，降低推理成本和延迟 |
| Picojoule（皮焦耳） | 能量单位，1 皮焦耳 = 10⁻¹² 焦耳；Jeff 用来衡量 AI 计算的基本单元——矩阵乘法约 1 皮焦耳，芯片内数据搬运约 1000 皮焦耳 |
| HBM（High Bandwidth Memory） | 高带宽内存，TPU/GPU 的外挂内存；从 HBM 读数据比从片上 SRAM 读数据慢且更耗能 |
| SRAM（Static RAM） | 芯片上的静态随机访问内存，速度最快但容量有限；TPU 计算的数据理想状态是全部在 SRAM 中 |
| TPU（Tensor Processing Unit） | Google 自研的 AI 专用芯片，2016 年首次用于生产；特点是 2D/3D 网格结构的多芯片互联，针对 AI 矩阵计算优化 |
| Sharding（分片） | 将大型数据集（如搜索索引）分割成多个分片，分布在不同机器上并行处理；Google 搜索 1999 年开始使用，扩大索引时增加分片数 |
| MoE（Mixture of Experts） | 稀疏专家模型架构；模型有大量"专家"（子网络），每次推理只激活少数几个专家（如 1-5%），从而在极大参数量下保持计算效率 |
| Ternary Precision（三值精度） | 将模型权重量化为三个值（-1, 0, +1）的极低精度方案；配合组级别缩放因子可大幅降低能耗 |
| RL（Reinforcement Learning） | 强化学习；通过奖励信号训练模型；在数学、编程领域因可自动验证而效果突出，在非可验证领域的应用是当前开放问题 |
| RLVR（RL with Verifiable Rewards） | 基于可验证奖励的强化学习，即奖励来自明确的验证机制（代码跑通/数学答案正确）；区别于依赖人工判断的 RLHF |
| In-context Learning（上下文学习） | 通过在提示词（context）中提供少量样例，让模型学会完成新任务，无需更新模型权重；Kalamang 案例展示其极端版本 |
| Back-of-the-envelope Calculation | 信封背面计算，指快速的数量级估算，用于在正式设计前判断方案可行性；Jeff 的"延迟数字"是此类计算的基本原料 |
| DeViSE | Jeff Dean 参与的早期工作，融合语言词向量与图像模型表示，使模型能识别训练集之外的新类别（如从未见过显微镜图像但能预测"microscope"标签） |
| Gemini | Google 的多模态大型语言模型系列；由 Jeff Dean 命名，取自"双子"（Brain+DeepMind 两团队合并）和 NASA Gemini 计划（Apollo 登月前的关键一步）两层含义 |
| CAP Theorem（CAP 定理） | 分布式系统理论：一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance）三者不可同时满足；Google Spanner 通过原子钟实现了接近 CAP 理论极限的系统 |
蒸馏的极限在哪里？ Flash 超越上一代 Pro 的趋势能持续多久？当前沿模型的参数规模增长放缓时，蒸馏还能带来多少能力提升空间？
能耗视角的行业影响：Jeff 以皮焦耳而非 FLOP 来衡量 AI 计算效率，这个视角是否应该成为行业标准？在碳排放和能源压力日益增大的背景下，AI 领域是否需要更多"能耗优先"的设计哲学？
"万亿 token 的幻觉"如何实现？ Jeff 描述的分层检索架构（数十亿→数万→数百→最终回答）与 Google 搜索有深层相似性，但中间层的"模型评估模型"如何避免级联错误？对于时效性内容如何处理？
个性化 AI 的隐私边界：Jeff 描述的"访问你所有邮件、照片、视频"的个性化模型极具价值，但也引出深刻的隐私问题——谁控制这些数据的访问权限？用户数据是否会影响通用模型的训练？如何防止数据被滥用？
规格说明作为新核心技能：如果"精确表达你想要什么"变成工程师最重要的技能，这将如何重塑软件工程教育？是否意味着"产品经理式思维"和"工程师技能"的边界正在模糊？