谷歌首席AI科学家、传奇工程师Jeff Dean，在最新访谈中放出了一个炸裂预言：
未来每个工程师可能会各自管理50个智能体实习生，完成大量并行任务，而且沟通效率会比人更高效。
未来最重要的技能将会是"写清楚需求"，因为Agent的输出质量完全取决于你如何定义问题。
好家伙，那以后岂不是……写需求比写代码还重要？
一方面是高端前沿模型，用于深度推理、复杂数学问题等高难任务；
另一方面是高性价比模型，用于低延迟场景，比如更流畅的Agent式编程。
Jeff Dean在这期访谈中亲口认证：通过蒸馏，小模型可以非常接近大模型性能。
他们让小模型在大量训练数据上多次迭代学习，同时利用大模型输出的logits信息，让小模型学到更细腻的行为。
这就是为什么Gemini能够做到"下一代Flash ≈ 上一代Pro，甚至更好"。并且他也透露，谷歌内部会持续推进这条路线。
另外，Jeff Dean非常相信"低延迟"的价值：他认为如果延迟降低20-50倍，用户体验会彻底改变。
他还指出，内部一开始就希望Gemini是个多模态模型，但多模态不只是文本、图像、视频、音频这些，让模型理解"非人类"的模态同样非常有用。
比如Waymo车辆的LIDAR传感器数据，或者机器人数据、医疗影像数据等等。未来可能有数百种模态。
△AI生成
在这期访谈中，你还可以了解到：
Jeff Dean早在几十年前就坚信规模化终将取胜，以及"更大的模型、更多的数据、更好的结果"这一信条，这一信条持续了15年；
LLM训练与推理不仅关心计算量，也关心数据搬运成本；对硬件优化、batch size、延迟、吞吐量的设计，都可以用能量消耗作为第一性原则衡量；
TPU和ML研究团队必须紧密互动、协同设计，硬件设计需预测未来2–6年的模型趋势；
Gemini早期资源太分散，Jeff Dean称"这是愚蠢的"；
Jeff Dean给出两个预测：未来真正"个性化"的模型会极其重要，以及低延迟会改变很多应用场景。
以下为本场访谈重点内容实录，围绕核心观点做了摘选整理，部分文字在不改变原意的基础上做了适度删改，enjoy！
蒸馏是Flash模型突破的关键
Shawn Wang：首先得说一句，恭喜你们占据了帕累托前沿。
（编者注：帕累托前沿描述的是多个目标之间权衡时的最优解集合。此处指谷歌既能推出高性能的前沿模型，又能推出低成本、低延迟的高性价比模型，在性能 vs 成本/延迟这两个维度上已经达到了最优权衡状态）
Jeff Dean：谢谢。能站在帕累托前沿当然是好事。
Shawn Wang：是的。我觉得你们做的不只是追求最强能力，还同时兼顾效率，真正"拥有"了帕累托前沿——既有顶级性能，也有成本与效率控制，还提供了完整的模型梯度供用户选择。
这里面有一部分来自你们的硬件工作，一部分来自模型设计，还有很多长期积累的"秘密武器"。看到这一切整合起来，确实令人印象深刻。
所有这些结合在一起，才能既做出能力极强的大模型，也能通过软件技术把这些能力"压缩"到更小、更轻量、更低成本、更低延迟的模型里，同时仍然保持相当强的能力。
Alessio Fanelli：你们内部，会不会对帕累托前沿的"低端"也有很大压力？
新实验室往往拼命往性能最前沿冲，因为需要融资。但你们有数十亿用户。早年做CPU规划时，如果每个用户每天多用三分钟语音模型，算下来都需要翻倍的算力。
现在在谷歌内部是怎么权衡的？如何在"追求前沿"和"必须规模化部署"之间做决策？
Jeff Dean：我们始终希望拥有站在前沿、甚至推动前沿的模型，因为只有在那里，你才能看到"新能力"的诞生——那些上一代模型不具备的能力。
但我们也清楚，这类模型通常更慢、更贵。很多广泛场景其实更需要低延迟、低成本的模型。
所以我们的策略是同时做两件事：一方面有高端前沿模型，用于深度推理、复杂数学问题等高难任务；
另一方面有高性价比模型，用于低延迟场景，比如更流畅的 Agent 式编程。两者都重要。
而且通过蒸馏技术，我们可以把前沿模型的能力迁移到小模型上。因此这不是"二选一"，反而是相辅相成——没有前沿模型，也很难得到高质量的小模型。
Jeff Dean：别忘了Oriol Vinyals。
Alessio Fanelli：这么多年过去，你怎么看待这些技术理念的"周期性"？比如稀疏模型。很多想法在当时未必看起来重要，但后来影响巨大。你们如何判断哪些值得在下一代模型中重新审视？
Jeff Dean：当年做蒸馏，动机其实来自图像任务。
我们有一个 3 亿张图片的数据集。如果针对不同类别训练"专家模型"——比如一个专门识别哺乳动物，一个专门识别室内场景——然后做成 50 个模型的集成，效果会很好。但显然不可能线上部署50个模型。
于是我们想：能否把这些专家模型"压缩"进一个更小、可部署的模型里？这就是蒸馏的由来。今天其实逻辑类似，只不过我们不是蒸馏50个模型，而是从一个极大规模模型蒸馏到小模型。
Shawn Wang：蒸馏和强化学习革命之间是不是也有关联？比如RL会在某些能力分布上"打尖"，但可能牺牲其他区域。
如果能通过蒸馏把能力重新平衡回来，实现"能力合并而不退化"，那是不是理想状态？
Jeff Dean：蒸馏的关键优势之一，是小模型可以在大量训练数据上多次迭代学习，同时利用大模型输出的 logits 信息，而不仅是硬标签。这能引导小模型学到更细腻的行为。
实践中我们确实发现，小模型可以非常接近大模型性能。
Shawn Wang：那Ultra呢？是不是内部有一个"母体模型"一直在蒸馏？
Jeff Dean：我们有很多不同规模和用途的模型，有些不对外发布，有些是Pro级别。蒸馏可以来自不同来源。另外，推理阶段扩展也是提升能力的重要方式。
Shawn Wang：Flash的经济性确实带来了规模优势。听说已经50万亿tokens？
Jeff Dean：市场份额方面，希望还在增长。
Shawn Wang：Flash现在几乎无处不在——Gmail、YouTube、搜索AI模式。
Jeff Dean：是的。Flash的优势不仅是便宜，还有低延迟。而延迟非常关键。
未来模型会被要求完成更复杂任务，比如写整个软件包，而不仅是一段循环代码。这会生成大量token，因此低延迟系统至关重要。
Flash 是一个方向。硬件层面，比TPU芯片之间的高性能互联，也对长上下文attention或稀疏专家模型的可部署性至关重要。
Alessio Fanelli：那你们会不会担心某种"饱和"？比如两代之后Flash就能覆盖大多数需求，那还有动力继续推Pro前沿吗？
Jeff Dean：如果人类提问的分布是静态的，那可能会。但事实是，模型能力越强，人们问的问题越复杂。
一年前我只会让模型做简单coding，现在我会让它做复杂系统分析。用户需求本身在进化。前沿模型推动能力边界，同时也让我们看到瓶颈在哪里，从而改进下一代。
Alessio Fanelli：内部还依赖公开benchmark吗？
超过95%就意义不大了，要么能力已掌握，要么可能出现数据泄露。我们有很多内部保留测试集，专门评估未出现在训练数据中的能力。然后分析是数据问题、架构问题还是能力缺口。
Shawn Wang：有没有某个benchmark直接促成了架构创新？
Jeff Dean：长上下文能力就是一个例子。Gemini 1.5开始我们明显推进了长上下文。像"needle in a haystack"这种单针测试现在基本饱和了。真正有意义的是更复杂的多针检索或真实任务，比如从数千页文本或数小时视频中提取信息。
Shawn Wang：但会不会有"过拟合 benchmark"的风险？像Jason Wei说的，那是一种inductive bias，可能短期有效，长期未必可扩展。
Jeff Dean：我们更关注的是"需要什么能力"，而不是某个具体解法。长上下文显然有用，但当前仍然太短。
理想状态是"能在回答问题时访问整个互联网"。但现有二次复杂度attention不可能扩展到万亿token。我们需要算法与系统层面的突破，创造"可访问万亿 token 的幻觉"。
如果能做到，就可以访问整个互联网、YouTube视频像素、个人邮件、照片、文档（在用户授权下）。那将极具价值。关键在于：如何在算法和系统层面实现这种规模跃迁。
Gemini一开始就强调多模态
Shawn Wang：顺便说一句，我之前算过一笔账——如果一个人每天连续讲八个小时、天天讲，最多也就生成大概10万个token，这其实完全在可承受范围内。
Jeff Dean：对，不过如果你再进一步说——好，我想要理解人们上传到视频里的所有内容，那情况就不一样了。
Shawn Wang：而且经典的例子是，当你从语言扩展到其他模态，比如蛋白质之类的信息，那信息密度就高得多了。
Jeff Dean：没错。我觉得像Gemini这样的模型之所以强调多模态，是因为我们从一开始就希望它是多模态的。
比如来自Waymo车辆的LIDAR传感器数据，或者机器人数据、医疗影像数据，比如X光、MRI，以及基因组信息。
世界上可能有数百种不同的数据模态，我们希望模型至少能接触到这些模态，知道它们是有意义的。
即使你没有在所有LIDAR或MRI数据上大规模训练，仅仅少量纳入，也会非常有价值，因为这会"暗示"模型：这些都是现实世界中的重要信号。
Shawn Wang：那你是否认为存在某种"王者模态"？比如视觉可以在像素层面编码文本；有篇DeepSeq CR的论文就是这么做的。
视觉还能通过频谱图来表示音频。所以会不会视觉才是"统治一切"的模态？
进化在 23 次独立的过程中演化出了"眼睛"，这本身就说明视觉对理解世界是多么关键。
而我们希望这些模型也是在"感知世界"。所以关键在于：它们是否能解释所看到或关注到的内容，并利用这些信息帮助我们完成任务。
Shawn Wang：说到视频，我得夸一句，Gemini目前可能还是唯一一个原生支持视频理解的模型。我经常用它分析YouTube。
Jeff Dean：是的，其实很多人并不了解Gemini到底能做什么。
我有个例子：一个YouTube视频合集，包含过去20年18个经典体育瞬间，比如Michael Jordan在总决赛最后时刻的跳投、一些足球进球等等。
你可以直接把视频给模型，说"请帮我做一个表格，列出每个事件是什么、发生日期以及简要描述。"
结果你会得到一个18行的结构化表格——这其实是把视频转成类似SQL表结构的信息。很多人并不会把"视频理解"联想到这种能力。
谷歌搜索的演变：从分片到AI搜索
Alessio Fanelli：在谷歌内部有没有讨论过"照料整个互联网"这个问题？谷歌本身就是因为人类无法浏览整个互联网而存在的，通过排序系统帮人筛选。
对于LLM来说，排序逻辑是不是不同？人类可能只看前5个链接，但LLM是否应该关注20个高度相关的链接？你们内部是怎么思考这种"更广泛搜索模式"的？
Jeff Dean：其实在大语言模型出现之前，我们的排序系统就是这样分层处理的。
首先从一个巨大的索引中筛出相关子集，可能从数十亿网页缩小到3万份候选文档，然后逐层使用更复杂的算法和信号精炼，最终展示前10个结果。LLM系统本质上也类似。
这样你就实现了一种"仿佛浏览了万亿token"的效果，就像谷歌搜索给人的感觉一样——虽然你在搜索整个互联网，但实际上只处理了一小部分最相关的内容。
Shawn Wang：很多人不了解LLM在高流量系统里的渗透程度。比如 BERT 很早就进入谷歌搜索系统，提升了质量。
Jeff Dean：是的，引入LLM表示方式之后，我们可以跳出"必须精确匹配用户输入词语"的限制，而更关注页面的主题是否与查询相关。
Shawn Wang：其实在LLM之前，你们就已经在"软化查询词"了吧？
Jeff Dean：没错。我在2009年的一个会议上做过一次回顾演讲，讲1999到2004年搜索系统经历的五六次架构重构。
2001年是一个关键点。当时我们为了扩展规模，把索引分片，比如60个shard，每个shard多个副本。
当副本数量足够多时，我们意识到——整个索引其实可以全部放进内存！一旦索引在内存中，你就可以对用户原本三四个词的查询，扩展出50个相关词，比如restaurant、restaurants、cafe、bistro等等。
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：哦，你是用能量来衡量的？
比如，从芯片另一侧的SRAM搬数据，甚至都没出芯片——可能就要1000皮焦耳。于是你就明白了，为什么加速器需要"batch"。
如果你把一个模型参数从SRAM搬到乘法单元，花了1000皮焦耳，那你最好多次使用它。假设batch size是 256，那这笔成本还能摊薄；但如果batch是 1，那就太亏了。
Shawn Wang：对，因为你花了1000皮焦耳，只做了1皮焦耳的乘法。
Jeff Dean：没错。所以从能量角度看，batching 是非常自然的选择。理想情况下我们当然希望batch size是1，因为延迟最低。但能量效率和计算效率会非常糟糕。
Shawn Wang：我还是第一次听到用能量分析batching的解释。
Jeff Dean：这其实就是大家做batching的原因。
TPU和ML必须做协同设计
Shawn Wang：那在硬件上有没有类似当年"把索引全部放进内存"那样的转折？比如NVIDIA在SRAM上的激进下注。你们在TPU设计时是否也早就预见到这种趋势？
Jeff Dean：TPU采用的是规则的2D或3D mesh 结构，每个芯片都有HBM。对于某些模型推理任务，从HBM读数据的延迟和成本比从片上SRAM高得多。
所以如果模型够小，你可以做模型并行，把它分布在16或64个芯片上，只要全部参数都能放进SRAM，就能同时提升吞吐和延迟。这其实是一个很自然的技术选择。
Jeff Dean：我们在TPU架构团队和ML研究团队之间有很多互动，因为必须做"协同设计"。
问题是——你今天开始设计一颗芯片，可能两年后才部署到数据中心，然后还要用三到五年。也就是说，你要预测两到六年后人们会运行什么样的ML计算，而这个领域变化极快。
但有些改动代价很大，就必须通过大量ML实验来验证方向。
Alessio Fanelli：有没有反过来的情况？因为芯片设计已经定了，所以模型架构不得不调整？
Jeff Dean：当然会。模型架构有时会为了适配现有硬件而调整。比如未来一代支持更低精度，你可能提前为那个精度训练模型，即便当前代还不支持。
Shawn Wang：那精度还能降多低？有人说三值化（ternary）都可以。
Jeff Dean：我个人很喜欢低精度，因为每减少一位比特，就减少搬运时的能量消耗。很多成功做法是：权重本身用极低比特表示，但给一组权重共享一个缩放因子。
Shawn Wang：低精度加缩放因子？挺有意思的。说到精度，我们最终是采样生成的，还会加随机数——那这么精细的计算是不是有点讽刺？
Jeff Dean：确实有很多趋势值得关注。比如能量驱动模型、扩散模型（不再顺序解码 token）、投机解码。
比如一次预测8个token，然后接受其中5或6个，相当于把有效batch提升了5倍，大幅摊薄参数搬运成本。从能量、延迟、吞吐的角度看问题，会自然引导你找到更优解。
Shawn Wang：还有模拟计算这种更激进的方向呢？
Jeff Dean：模拟计算很有意思，理论上功耗低。但现实中你往往要和数字系统接口，做数模、模数转换，这会损耗掉不少能效优势。
不过我认为，在现有数字架构下，我们在能效上还有巨大的提升空间。
几个新的研究角度
Alessio Fanelli：从研究角度看，还有哪些方向你觉得特别值得探索？
Jeff Dean：一个大问题是如何让模型更可靠，能完成更长、更复杂、包含大量子任务的工作。也许一个模型调用其他模型作为工具，协作完成更大规模任务。
还有一个开放问题是：如何把强化学习扩展到"不可验证"的领域。现在数学和编程的进步，很大程度上来自可验证奖励。如果我们能在不可验证领域也实现类似突破，模型能力会有很大提升。
Jeff Dean：可以用另一个模型来评估第一个模型的结果，比如判断检索结果是否相关，或者从2000条结果中打分选出最相关的50条。有时甚至可以用同一个模型，只是通过不同提示词，让它充当"批评者"。
Shawn Wang：感觉我们好像做完了"简单的部分"，接下来全是硬骨头。但每年都这么觉得。
Jeff Dean：这个领域的好处是，有很多聪明人都在想办法解决这些问题。
两年前，我们还在为GSM8K这种"小明有两只兔子又买三只"的题目发愁。现在模型已经能做IMO和Erds水平的数学推理了，而且是纯语言形式完成。这在一年半内是惊人的跃迁。
Shawn Wang：比如说，自动生成YouTube缩略图，这就非常有用了。那就是AGI了，我们真的需要它。
Shawn Wang：对内容创作者来说，那绝对是。
Jeff Dean：我不是YouTube创作者，所以我个人没那么在意这个问题，不过我知道很多人确实很在意。
统一模型时代已经到来
Shawn Wang：说回IMO，我到现在都还没消化一件事：一年前我们还有AlphaProof、AlphaGeometry这些专用系统，结果今年直接说"算了，全丢给 Gemini"。
你怎么看这种从"符号系统 + 专用模型"到"全LLM一统天下"的转变？
Jeff Dean：这对我来说其实挺自然的。人类确实在操作符号，但我们的大脑里未必真的是离散的符号系统。更可能是某种分布式的神经表示——大量神经元的激活模式。
当我们看到某些东西时，激活特定模式，从而进行推理、规划、链式思考，甚至回滚再尝试其他路径。
从这个角度看，用神经网络来模拟这种过程是合理的。我一直觉得，把完全独立的离散符号系统和神经模型硬性分开，其实不太有道理。
Shawn Wang：也许对你来说很明显，但对我一年前来说并不明显。
Jeff Dean：我觉得，从"把问题翻译成Lean再用专用几何模型求解"，到第二年直接用一个统一的大模型（基本就是生产版模型，只是给了更多推理预算），这其实说明通用模型能力的巨大提升。你已经不再需要那些专用系统了。
这和2013到2016年机器学习的发展很像——那时每个任务都要训练一个独立模型：街道标志识别一个模型，语音识别一个模型。
现在，统一模型时代已经到来。问题变成：它们对从未见过的新任务的泛化能力如何？而答案是——越来越好。
Shawn Wang：而且甚至不需要领域专家。我采访过Ete，他说自己甚至不知道IMO在哪举行、规则是什么，只是训练模型。这种"通用ML技能 + 数据 + 算力"就能解决各种任务，某种程度上像是"苦涩的教训"。
（编者注：Ete是指爱德华·格列芬斯特，一位Google DeepMind的研究科学家，他参与过多项与推理、语言模型相关的研究；
"苦涩教训"是"强化学习之父"理查德·萨顿提出的理念：研究者总想把人类知识编入AI，短期有效但长期看，依靠大规模算力和通用算法的方法最终会胜出）
Shawn Wang：但这里有个疑问：模型容量是有限的，参数本质上只能容纳有限的比特。比如 Gemma 这种小模型，很多人希望本地开源模型，但它们会记住一些其实没必要记住的知识。
大模型可以包罗万象，但小模型容量有限。我们能否把"知识"和"推理能力"分离？
Jeff Dean：理想情况下，模型应该把宝贵的参数空间更多用于推理能力，而不是记住那些可以检索到的冷门事实。比如某个偏僻小桥的长度，没必要死记硬背。但模型也不能完全脱离世界知识。
比如知道Golden Gate Bridge大概多长，有助于建立尺度感。所以需要一定的常识。模型越大，能容纳的知识越多。但我认为，把检索和推理结合起来——尤其是多阶段检索 + 推理——会让模型显得更强大。
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年，随着摩尔定律和更大的数据集，神经网络才真正开始解决语音、视觉、语言等问题。
我还复活了本科论文里的模型并行和数据并行思想——那时候我用的名字不一样，但本质就是这两种并行方式。历史有时候会兜个圈再回来。
Shawn Wang：这个是公开的吗？我们能去网上查到吗？
Jeff Dean：可以，在网上都能找到。
不过说到更宏观一点的事情，我觉得过去十五年真正重要的一点，是把各种技术结合起来，并且持续推动Scaling。
这不仅仅是算法问题，还包括硬件的进步，比如构建像TPU这样的专用硬件；也包括软件层面的抽象能力，让研究者和工程师能够更好地向计算机表达自己的想法。
Shawn Wang：关于后来对算力资源分配的反思——有人提到所谓的"算力配额市场"。
David在OpenAI做过VP of Engineering，后来又去了Google。他的观点是，OpenAI 当时愿意"押上全部筹码"去做一件事，而 Google 更民主化，每个人都有自己的算力配额。
（编者注：此处指David Luan，是 AI 领域知名的技术专家，曾任职于Google Brain和OpenAI，后来创办了 AI 初创公司Adept）
如果你真的相信 Scaling 是关键，那这其实是一个全组织层面的战略选择。你当时会认同这种说法吗？还是有不同的复盘结论？
Jeff Dean：我在一定程度上是同意的。事实上，我当时还写过一页memo，说我们把资源拆分得太零散是"愚蠢"的。
问题在于，我们不仅把算力分散在多个方向上，还把最优秀的人才分散开了。我当时的观点是：这没有必要。为什么不整合起来，做一个统一的、从一开始就是多模态的、在各方面都很强的单一模型？
这就是Gemini项目的起点。
Shawn Wang：所以那份一页纸的memo成功了？另外，Gemini这个名字也是你起的吗？
Jeff Dean：是的，是我起的。
当时也有别的备选名字，但我觉得"Gemini"挺好。因为这两个组织像是"双胞胎"一样的存在，现在合并在一起。另外，NASA 早期的Gemini项目也是通往Apollo计划的重要一步。这个隐喻也很贴切——双子合一。
未来人均50个智能体实习生
Alessio Fanelli：我很好奇你现在是怎么用AI来写代码的。你一直是工程能力极强的人。我看到你说过，结对编程时要找到思维方式互补的人。
那现在有了coding agents，你会如何"塑造"一个与自己思维方式匹配的智能体？你如何评价现在这些工具？未来应该往哪个方向发展？
Jeff Dean：首先，编程工具相比一两年前已经有了巨大进步。现在你可以把更复杂的任务交给它们。
一个很有意思的点是：你和模型互动的方式，会反过来决定它如何与你合作。你可以让它写测试、帮你做性能优化brainstorming，也可以让它完全独立去完成一个模块。
不同任务适合不同交互模式。有些任务需要频繁互动；有些你可以清晰定义需求，然后让它独立完成。
我认为未来会有越来越多独立运行的软件智能体替你做事。关键问题是：人机交互模型该怎么设计？什么时候它应该打断你？什么时候独立推进？
这个问题还没有最终答案。而且随着模型能力提升，这些交互决策也会改变。如果你有50个实习生，你会怎么管理？也许你真的会想要50个——前提是他们足够优秀。
Shawn Wang：那管理成本也很高。
Jeff Dean：是的。但你可能会把他们分成小组，而不是直接管理 50 个人。
同样的，如果一个人管理50个虚拟智能体，而不是50个真人工程师，也许组织结构和沟通带宽会更高效。
五个工程师各自管理50个智能体，彼此之间可能反而有更高带宽的交流，而不是每人都要协调一个50人团队。
Jeff Dean：也许。但传统的软件组织其实也是高度分工的。50个人在不同模块上工作，本来也不会高频互动。
如果是5个人各自管理50个智能体，反而可能在这5人之间形成更高效的协作结构。具体会怎么演化，我也不确定。
"写好需求"将会是核心技能
Alessio Fanelli：那你的工作节奏会怎么改变？是不是要花更多时间在设计和specification上？
Jeff Dean：我觉得这是个非常关键的变化。过去大家都被教导要写清晰的specification，但说实话，没有多少人真正重视"英文规格说明"这个产物。
但如果你是让一个agent为你写代码，你必须把specification写得非常清楚。因为输出质量完全取决于你如何定义问题。如果你没写清楚某个corner case，没强调性能要求，模型就很可能忽略这些。
因此，我认为未来一个重要能力是：用非常精确、无歧义的方式表达你想要什么。这不仅对软件工程重要，对任何复杂任务都是重要能力。
能够"清晰表达需求"，会成为一种核心技能。
而且我认为"多模态"非常重要。比如Google当年推出的一些模型，一开始就强调强多模态能力，包括视频。这其实是给模型最高带宽的一种输入方式，是一种极其强大的沟通手段。
Alessio Fanelli：那你怎么处理自己脑子里那些经验性的知识？比如你对性能优化有很强的"直觉感"，知道哪些地方可能有提升空间。
现在是不是更有价值把这些通用经验系统性写下来，作为可以检索的资料喂给模型？
比如边界情况就是个好例子——以前你脑子里自然会想到某些特定场景，现在是不是每次都得明确写出来？你会建议大家花更多时间写这些"通用指南"吗？
Jeff Dean：我确实认为，高质量的软件工程指南会变得更重要。因为它们既可以作为模型的输入上下文，也可以被其他工程师阅读，从而帮助他们写出更清晰的prompt。
未必需要为每个具体问题都写一份专门文档，但如果你有一些通用指南，然后把它们放进 coding agent 的上下文中，那会非常有帮助。
举个例子，在分布式系统里，你可以列出常见故障类型，以及对应的处理技术。比如Paxos这样的复制协议，或者向两个节点发送请求、只需一个返回即可容错的策略。
如果你写一份包含 20 种类似技术的简明说明，那大概率能帮助coding agent构建出更可靠、更健壮的分布式系统。
模型的"个性化"和低延迟会极其重要
Shawn Wang：回到prompt和迭代这个话题。我一直想做一个A/B实验：
是三次"快速但能力一般"的模型调用、每次都有人类校准效果更好？还是一次写一个非常长、非常详尽的prompt，然后让一个很强的模型一次完成更好？
很多时候性能不佳，是因为你没写清楚需求，而不是模型不行。模型其实可以生成10种合理结果，只是你想要其中1种。
Jeff Dean：对，本质上是"欠规格化"。如果问题没被清晰定义，模型只能猜。而多轮快速交互，往往足够逼近你真正想要的结果。
我个人非常相信"低延迟"的价值。低延迟交互会让系统使用体验变得愉悦得多。如果响应慢10倍或20倍，体验完全不同。
未来我们会看到模型和底层软硬件系统带来20倍甚至50倍的延迟下降。这对那些需要在每次交互之间完成大量内部计算的系统至关重要。
Shawn Wang：但另一方面，也有像DeepThink这种强调深度推理、但延迟较高的模型。
Jeff Dean：如果成本和延迟不是问题，你当然会一直用DeepThink。
假设硬件提升20倍延迟降低，那你自然希望模型具备更强推理能力。但有趣的是，当硬件变快后，你往往又会设计出更复杂的模型，再次把时间用满。
Shawn Wang：帕累托前沿总是在往上爬。最后问个预测问题。有没有你觉得现在还不满意、但很快会实现的能力？
Jeff Dean：我给两个预测。
第一，真正"个性化"的模型会极其重要。一个了解你、掌握你所有状态、并且可以在你授权范围内检索你全部历史信息的模型——你看过的邮件、照片、视频——会比通用模型强大得多。
Shawn Wang：大家常用"每秒tokens数"来衡量速度。比如现在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
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
—完—
今天，你养虾了吗？
欢迎加入【龙虾养成讨论组】，一起交流养虾经验！扫码添加小助手加入社群，记得备注【OPENCLAW】哦～
一键关注 点亮星标
科技前沿进展每日见
