Core Automation Founders Abandon Transformers to Build Self-Improving AGI

Core Automation创始人放弃Transformer架构，转向构建自我改进的AGI 标准Transformer架构因缺乏测试时适应能力而已达扩展上限，因而需要一个专注于定制GPU内核的自动化研究实验室来探索自我改进的替代方案。 在本次讨论中，前OpenAI推理负责人Jerry Tworek与前Gemini预训练联合负责人Rohan Anil阐述了为何单纯扩展Transformer和强化学习无法带来真正的AGI。他们认为，Transformer缺乏原生的测试时适应能力，受制于低效的逐token计算深度，并在结构上受限于静态训练范式。为了打破这一壁垒，他们分析了各大主流实验室困于短期产品竞争的原因，并介绍了其新成立的实验室Core Automation如何计划首先通过自动化定制硬件内核生成与实验循环，来探索非Transformer架构。 Jerry Tworek 与 Rohan Anil 指出，Transformer 架构已触及长达六年的瓶颈，仅靠缩放注意力机制与专家混合（MoE）层已无法解锁根本性的新能力。 (1:46) 大模型在现实复杂任务中的核心缺陷在于缺乏测试时学习（test-time learning）能力：上下文学习受限于窗口长度且数据效率低下，而微调则伴随着灾难性遗忘。 (4:54) 自回归逐 token 生成机制限制了模型的计算深度，使得思维链（CoT）推理成为一种昂贵且低效的折中表征方案。 (19:11) 一线 AI 实验室正深陷于标准 Transformer 驱动的编码智能体与产品交付军备竞赛，导致行业在非 Transformer 架构研究上留下了巨大盲区。 (9:50) Core Automation 致力于构建全自动 AGI 实验室，并将底层 GPU Kernel 自动生成作为首要突破口，以解锁因硬件加速壁垒而受阻的全新模型架构与优化器。 (39:45)

Core Automation founders Jerry Tworek and Rohan Anil argue that scaling standard autoregressive transformers has hit fundamental structural limits in test-time adaptation and computational depth. They contend that discovering the next paradigm requires end-to-end hardware-kernel co-design inside an automated lab designed for continuous, human-independent self-improvement. Structural Bottlenecks of Current Transformer Architectures (1:46) Tworek and Anil point out that six years of stacking parameters onto identical attention and mixture-of-experts (MoE) operations has plateaued in unlocking fundamental new capabilities. Large language models remain computationally shallow—typically capping out around 100 layers—and rely on autoregressive token generation as a brute-force mechanism to simulate computational depth. While chain-of-thought prompting and reinforcement learning (RL) add processing pathways, they impose a severe latency and compute penalty by generating one token at a time rather than building deeper internal representations directly. Furthermore, existing systems cannot adapt dynamically once deployed. Models depend on in-context learning, which is data-inefficient and context-window bound (often degrading or requiring resets after roughly 20 minutes of dense interaction), or centralized fine-tuning, which suffers from severe catastrophic forgetting. Tworek notes that while scaling RL caused benchmark scores to surge, models still fail on dirty, out-of-distribution real-world tasks because standard architectures lack the capacity for continuous test-time learning. Rethinking Optimization Dynamics and Frontier Lab Incentives (9:50) The founders argue that the industry's standard training pipelines treat pre-training and RL as disjoint phases evaluated on flawed proxies. Pre-training relies on perplexity, but applying RL often breaks perplexity metrics while substantially boosting downstream task performance. Anil highlights his work on the Shampoo optimizer at Google, which yielded roughly 2x efficiency improvements over Adam and powered models like Gemini 1.5 Flash. Stronger second-order optimizers can unlock novel network topologies—such as architectures that bypass residual connections—which fail under standard first-order solvers. Despite these opportunities, incumbent frontier labs are constrained by short-term market competition. Because API tokens lack inherent stickiness, leading labs face intense pressure to ship incremental product updates, trapping them in standard transformer setups. Anil also notes that artificial neural networks remain computationally inefficient compared to biological systems because digital silicon strictly separates hardware from weight updates, requiring massive parallel rollouts to force minor updates into parameters, whereas biological brains integrate the learning algorithm directly into physical, analog circuits. Custom Kernel Synthesis as the Research Bottleneck A recurring thesis from Anil is that architectural breakthroughs fail unless paired with end-to-end hardware integration. Theoretical model advances frequently languish because standard vendor libraries do not support non-standard operations. For example, Anil's early work on Shampoo was delayed for nearly two years due to a lack of custom XLA compiler kernels, and a 2020 proposal to replace MoE layers with sparse N-gram memory stalled until DeepSeek later implemented a similar design alongside custom hardware support. To demonstrate this constraint, Core Automation hosted a competition with GPU Mode to optimize a QR matrix decomposition kernel on NVIDIA B200 hardware. A human expert using AI coding agents achieved a 60x speedup over standard cuSOLVER baselines after four weeks and $100,000 in spend. Anil emphasizes that current state-of-the-art frontier models from OpenAI, Anthropic, and Google cannot autonomously design or optimize these multi-operator GPU memory patterns, making automated kernel synthesis a prerequisite for testing alternative architectures. The Blueprint for an Automated AI Scientist Core Automation aims to bypass human engineering bottlenecks by constructing a native, agent-centric lab in San Francisco that automates the deep learning stack from kernel compilation to experiment execution. Rather than operating within conventional human feedback loops, the team plans to scale research throughput from several daily experiments to dozens or hundreds of autonomous runs searching the architectural design space. Tworek defines true AGI not merely as economic utility, but as a system capable of continuous, autonomous self-improvement without human intervention. The founders plan to validate their architecture by observing non-linear inflections on long-term adaptation benchmarks and assessing whether their system can improve its own research workflows internally while the team is away. Tworek and Anil identify test-time learning and automated kernel synthesis as the primary hurdles blocking post-transformer architectures. However, whether small automated labs can overcome the massive capital advantages of incumbent frontier labs—or solve the efficiency limits of digital silicon without biological-style analog hardware—remains an open industry question.

Core Automation 联合创始人 Jerry Tworek 与 Rohan Anil 指出，现有基于 Transformer 的预训练与强化学习范式已遭遇计算深度浅与无法在线持续适应的瓶颈；他们计划通过自动化内核开发与端到端硬件优化构建自动化实验室，探索替代 Transformer 的全新架构以实现无人工干预的 AGI 自我改进。 Transformer架构与强化学习的局限 (0:00) Jerry Tworek 回顾其在 OpenAI 领导推理研究的经历时指出，自己曾坚信强化学习（RL）是通往 AGI 的唯一阶梯，但实际研究表明 RL 并不能完全解决现实问题。基准测试与 RL 训练处于同一分布，导致模型在测试榜单上得分激增，面对真实世界嘈杂且未见过的复杂任务时依然频现失误。Tworek 认为强化学习类似练习足球这种试错循环，而人类掌握数学需要深度内化与顿悟，当前的计算范式未能复现此类机制。 当前主流 Transformer 架构在此类适应性上存在结构缺陷：上下文学习受限于窗口长度且数据效率低下，在 Codex 等工具密集交互约 20 分钟后便需压缩或重置；微调则面临灾难性遗忘与低数据效率。堆叠混合专家（MoE）与注意力机制长达六年，但模型在实验室外部署后参数即处于静态。当现实环境的代码库或工具变化时，系统无法进行测试时动态学习（test-time learning），只能依赖中心实验室重新收集数据训练。 计算深度瓶颈与端到端优化缺失 (14:24) Rohan Anil 分析认为，自回归 Transformer 在推理时受制于单 token 串行解码瓶颈，投机解码仅是治标手段。当前顶尖模型的网络深度通常上限仅在 100 层左右，单次前向传播的最大理论计算量严格受限于层数乘序列长度。思维链（CoT）与 RL 虽然通过增加中间 reasoning token 变相扩展了路径，但这种靠极长 token 序列换取计算深度的方法伴随着巨大的延迟和算力税，单纯为了获取微弱的环境奖励信号而解码海量上下文造成了极大浪费。 在优化算法层面，行业长期依赖困惑度（Perplexity）评估模型压缩，然而困惑度的微小改善不能代表下游智能提升。Anil 结合在 Google 共同开发 Shampoo 优化器的经历指出，强优化器（如在 Gemini 1.5 Flash 中实现 Adam 约 2 倍性能的二阶优化方法）能解锁去除残差连接的高非线性深层网络。他主张预训练与 RL 不应割裂为两个独立阶段，而应进行端到端联合优化，但在大实验室追求短发布周期的商业压力下，此类需要耗时数月的基础架构探索常被搁置。 硬件束缚与底层算子生成瓶颈 针对模型能否达到生物计算效率的疑问，Anil 引述 Jeff Hinton 的“模型计算”概念，指出人类在发育中将学习算法直接构建在生物物理神经回路中，而当前数字硬件与模型权重分离，通过极低效率的大规模并行计算强行注入更新。除非未来走向模拟硬件并解决模拟容错，否则受制于硬件限制，效率难以匹敌生物。 实现新架构的直接阻塞在于硬件算子（kernel）。新机制在标准 GPU/TPU 库中缺乏支持，例如 Shampoo 优化器曾耗费 Google 两位顶级专家近两年编写底层的 XLA/LLO 编译器算子；Anil 于 2020 年构思的 N-gram 记忆架构也因缺乏稀疏访存硬件支持而推迟，直至数年后 DeepSeek 实现类似结构。Core Automation 与 GPU Mode 在 NVIDIA B200 上针对 QR 矩阵分解举行的比赛显示，资深工程师花费数周与 10 万美元 Agent 算力写出的算子比默认 cuSOLVER 提速 60 倍，而现有顶尖模型完全不具备独立优化复杂 GPU 访存模式的能力，导致底层高性能算子自动生成成为探索新架构的核心先决条件。 自动化实验室愿景与AGI定义 与 OpenAI 倾向于将 AGI 定义为超越人类经济价值工作的系统不同，Tworek 将真正的 AGI 定义为无需人类介入即可持续自我改进的系统。当前人机协同模式虽然高效，但缺乏人类引导的 LLM 无法长期自主运行并进行测试时学习。头部实验室陷入产品交付与代币争夺战，次级团队盲目跟风，导致非 Transformer 架构探索出现生态空白。Core Automation 选择从头搭建原生实验室，目标是将研究者从体力执行中解放出来，将实验迭代频率从传统周期大幅提升到每日运行多次乃至数十、数百次深度学习架构搜索。 针对新架构的验证标准，Tworek 指出真正的突破会体现在长期适应性指标曲线发生前所未有的非线性拐折。他们将日常的 AI 研发工作流直接作为评估基准：当团队全员度假归来，发现自动化系统在无人工干预的情况下自主改进了实验室的研究与代码能力，才标志着摆脱 Transformer 静态局限的持续自我提升系统真正落地。 Tworek 与 Anil 认为替代 Transformer 的关键在于跨越硬件算子瓶颈、打破串行解码推演深度的低效模式，并解决测试时在线适应问题。然而，在现有数字芯片体系下自动化生成超越人类水准的高性能算子、以及彻底统一预训练与强化学习等挑战仍处于早期探索阶段，其自我改进体系能否在脱离人类监督的环境中稳定泛化仍有待实验验证。

## Background 该视频由红杉资本（Sequoia Capital）于 2026 年 8 月 18 日在 YouTube 平台发布，由合伙人 Sonya Huang 与 Pat Grady 主持。访谈围绕 Core Automation 两位联合创始人 Jerry Tworek（前 OpenAI 推理团队负责人）与 Rohan Anil（前 Gemini 预训练负责人兼 Shampoo 发明者）展开，深入探讨了为何 Transformer 架构已触及天花板、测试期持续学习的紧迫性，以及为何必须从自动化内核生成切入来打造全自动 AGI 实验室。 ## TL;DR Jerry Tworek 与 Rohan Anil 指出，迈向更高智能的核心瓶颈已由算力规模转向架构本身——Transformer 缺乏测试期持续适应能力，且自回归逐词生成暴露了严重的计算深度与效率缺陷。当前各大头部实验室被季度商业竞争与同质化的编程 Agent 内卷所束缚，难以承担探索全新架构的风险，导致预训练与强化学习长期割裂。为此，Core Automation 确立了打造“全球最自动化实验室”的路线图，选择从现有前沿模型难以攻克的底层算子内核自动化生成（如 QR 分解）作为突破口，旨在以极高频的实验迭代速度在宏大的算法空间中探寻彻底颠覆 Transformer 的下一代架构。 ## Atmosphere & style 整场对话散发着顶尖架构师跳出大厂体制后的清醒与叛逆，既有对亲历技术突破的深刻复盘，又有对行业盲目堆砌算力与内卷现象的犀利剖析。两位嘉宾对答沉稳、默契十足，在硬核的技术推演与风趣幽默的行业洞察（如“沐浴用品”优化器系列与检验终极自动化的“全员度假测试”）之间自如切换。红杉主持人的提问兼具战略格局与技术敏锐度，使得整场对话如同暴风雨前夕的深度沙盘推演，兼具前沿底层的极客思辨与宏大的创业使命感。 ## Bulletin - [02:44](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=164s) 前 OpenAI 推理负责人 Jerry Tworek 与前 Gemini 预训练负责人 Rohan Anil 联合创立 Core Automation，提出下一代 AI 核心瓶颈已非算力规模而是 Transformer 架构本身，其物理结构天然缺乏测试期持续学习能力。 - [19:11](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1151s) Transformer 存在严重的计算深度不足问题，前向传播被限定为层数与序列长度的乘积，当前的思维链（CoT）与 RL 扩展本质上是以低效的逐 Token 串行自回归解码在后天代偿架构深度缺陷。 - [39:33](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2373s) Core Automation 将突破口定在自动化内核生成（Kernel Automation），在 GPU MODE 联合竞赛中，顶级专家结合 10 万美元 Agent 算力将 QR 分解加速 60 倍，解锁了原本因算力开销过大而无法实际落地的二阶优化算法与高阶特征值分解。 - [12:47](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=767s) 大厂实验室因受制于按月发布模型的商业竞争与同质化 Coding Agent 内卷，缺乏动力冒险探索 6 个月以上的替代架构，为初创团队在后 Transformer 范式上留出了关键生态位。 ## Key takeaways - [00:00](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=0s) 经验学习存在两种形态：类似反复试错微调的“踢足球式强化学习”，以及在大脑内部进行逻辑拓扑重构的“学数学式深度思考”，当前 RL 远非从经验中学习的终极形态。 - [02:44](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=164s) AI 行业过去六年深谙大规模预训练与大规模 RL，但底层运算仍局限于注意力机制与 MoE，下一代更聪明系统的核心瓶颈已经由算力规模转向架构本身。 - [04:54](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=294s) 强化学习在基准测试上的屠榜存在“评估与训练任务同构”的假象，离线预训练再部署的范式无法应对现实世界的环境漂移，模型必须具备在测试期自主进化的能力。 - [07:32](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=452s) Transformer 架构在测试期学习上遭遇物理墙：上下文学习受限于窗口长度与高昂推理成本（如 Codex 约 20 分钟即需压缩），而测试期微调则极易引发灾难性遗忘并面临低数据效率。 - [09:41](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=581s) Transformer 胜出的根本逻辑在于扩展经济学，其训练成本远低于商业回报；新型架构研究同样存在“算力门槛”，仅在小型 Toy Dataset 上实验往往无法验证架构的涌现潜力。 - [12:47](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=767s) 头部实验室被困在同质化的 Coding Agent 竞争与短期交付压力中，无暇抽身探索后 Transformer 范式，为敏捷的初创公司创造了破局窗口。 - [14:24](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=864s) 预训练架构与强化学习长期处于割裂状态：预训练构建固定上下文，RL 则通过逐词吐字拉长思考来笨拙代偿单步计算能力，推理系统效率极低。 - [19:13](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1153s) 前沿 Transformer 深度通常局限在百层左右，模型缺乏深层抽象能力；当前推断期扩展强行通过自回归序列长度弥补深度，算力利用效率极其低下。 - [20:32](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1232s) 静态权重与离线微调导致模型一旦面临真实世界的数据漂移便迅速失效，任何环境自适应都必须绕回中心实验室重新训练一轮的模式绝非通用智能的终局。 - [26:41](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1601s) 预训练过度聚焦降低困惑度（Perplexity）已出现严重的收益递减，且其目标与下游 RL 相互冲突，唯有打通两者构建端到端优化才能带来数量级的效率跃升。 - [28:39](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1719s) 神经网络架构与优化算法互为因果：许多现有架构设计纯粹是向弱优化器妥协的产物，引入 Shampoo、Soap 等高阶二阶优化器有望打破对残差连接等固定结构的依赖。 - [31:56](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1916s) 受制于软硬件割裂与数字芯片限制，机器在短期内无法达到人类大脑的生物计算效率；而主流大厂因发布周期绑架，无力投入数月以上的端到端统合深水区研究。 - [34:24](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2064s) Core Automation 对“自动化实验室”的定义不是剥离人类，而是通过 Coding Agent 为单兵提供极致杠杆，将深度学习基础算子的实验迭代速度提升至每日数十甚至数百次。 - [38:13](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2293s) 真正的 AGI 质变标志在于彻底剔除“人类在环”，即模型能在无人类干预的情况下完成长期的自我提升与深层次环境自适应。 - [42:06](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2526s) 底层算子内核决定了新架构落地的生死：无论是 Shampoo 的 XLA 适配还是 N-gram 显存记忆架构，缺乏硬件与算子协同就会让理论最优的算法沦为纸上谈兵。 - [45:09](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2709s) 检验自动化实验室与新架构成功的终极标准是“全员度假测试”：当研发团队集体离开数周，系统若能在测试期自适应运转并自主输出更优的研究成果，才真正证明了架构的突破。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=0s) 经验学习的两种形态：踢足球与学数学 Jerry Tworek 用一个生动的类比开启了关于模型学习本质的讨论。在人类的学习过程中，存在两种截然不同的模式： - **踢足球式的强化学习**：一次次尝试、射门、跌倒，每次稍微调整发力与姿态，观察结果是否符合预期，其核心是高度具身化且反复迭代的自我强化（self-reinforcement）。 - **学数学式的深度思考**：面对艰深的抽象概念，不需要立刻做出外部动作，而是在大脑内部进行极其深度的推演与内省，直到思绪在某一瞬间“豁然贯通”（click），各个知识点形成牢固的拓扑连接。 这两种截然不同的形态，归根结底都是“从经验中学习”（learning from experience）。当前整个人工智能行业投入了前所未有的海量算力来让模型从经验中学习，但现有的强化学习（RL）远非经验学习的终极形态。Jerry 坚信，在未来几年内，研究人员必将探索出远比当下 RL 更先进、更高效的经验与数据利用方式。 --- ### [01:00](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=60s) 告别 Transformer 时代的前提：深刻理解它的伟大 红杉资本（Sequoia Capital）的 Sonya Huang 与 Pat Grady 邀请到了 Core Automation（录音中误读为 Core Animation）的两位联合创始人 Jerry Tworek 和 Rohan Anil。两人在创立公司前均主导过 AI 领域的关键研究： - **Jerry Tworek**：前 OpenAI 副总裁，主导了包括 Strawberry（o1）项目在内的推理（Reasoning）团队研发。 - **Rohan Anil**：Google 资深研究员，Gemini 预训练的核心四位负责人之一，曾在 Google Brain 领导多项底层基础研究，并在 Google 和 Anthropic 扮演“疑难杂症攻坚专家”（fix-it guy），同时也是知名二阶优化器 Shampoo 的发明者。 ```mermaid flowchart LR accTitle: Core Automation 创始人背景 accDescr: 简要展示 Jerry Tworek 与 Rohan Anil 的前任职背景及在 Core Automation 的聚焦点。 subgraph S1["Jerry Tworek"] J1["OpenAI VP"] --> J2["Strawberry / 推理团队负责人"] end subgraph S2["Rohan Anil"] R1["Gemini 预训练负责人"] --> R2["Shampoo 优化器发明者"] end subgraph S3["Core Automation"] C1["后 Transformer 架构探索"] C2["测试期持续学习 (Continual Learning)"] C3["自动化 AGI 实验室"] end J2 --> C1 R2 --> C2 C1 --> C3 ``` 针对 Jerry 在社交媒体上发表的一条广受关注的“辛辣”观点——“替代 Transformer 的第一步，是深刻体会它曾带领我们走得有多远”，Sonya 询问这是否意味着对 Transformer 的悼词。Jerry 笑着回应道，如今他在各类访谈中最常做的事就是解释自己的推文。他指出，所谓“理解”并不仅仅是赞美，而是清晰地绘制出 Transformer 的能力边界： 1. **看清长处与短板**：只有明确它擅长解决什么，才能聚焦于它无法攻克的弱点。 2. **拒绝平庸的优化**：当前学术界与工业界对架构的研究，绝大多数只是在想方设法让 Transformer 变得更便宜、更高效（如剪枝、稀疏化、蒸馏），却极少有人去探索如何让架构本身在表达能力和通用智力上变得更强大。 --- ### [02:44](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=164s) 算力扩展的尽头与架构瓶颈的显现 Jerry 梳理了过去六年的技术发展轨迹。整个 AI 行业在过去数年里精通了两大核心算法范式：大规模无监督预训练（Pre-training at scale）以及大规模强化学习（Reinforcement Learning at scale）。然而，整个行业几乎一直坐在同一列火车上——不断堆叠参数，其底层本质上依然局限于两种固定运算：专家混合（MoE, Mixture of Experts）与注意力机制（Attention）。 Jerry 认为，**下一代更聪明系统的核心瓶颈已经不再是算力规模，而是架构本身（The architecture itself is the bottleneck）**。 虽然他对像 OpenAI Codex 和 Claude Code 这类编程系统以及工作流自动化产品充满敬意，并在日常工作中深度依赖它们，但这种依赖也伴随着一种强烈的反思： - 为什么即使使用了最顶尖的代码模型，开发者依然必须亲自“来上班”？ - 为什么模型只能处理局部片段，而无法端到端地接管整个任务？ - 为什么核心自动化无法彻底闭环？ 当大模型在基准测试中捷报频传，却在现实工作流中依旧需要人类不断“擦屁股”时，研究的根本方向就必须重新校准：必须去追寻那些当前 Transformer 根本不具备的物理特质与系统能力。 --- ### [04:54](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=294s) 强化学习的现实检验：实验室基准与现实世界的断层 被问及为什么认定问题出在架构层面，Jerry 讲述了他个人在 OpenAI 的认知演变。 长久以来，Jerry 都是一名坚定的“强化学习最大化主义者”（RL maximalist）。从 GPT-3 到 GPT-4，当整个行业目睹模型参数不断膨胀但 RL 占比仍相对有限时，Jerry 内心一直抱有坚定的信仰：只要全面启动并放大大规模强化学习，一切难题都将迎刃而解，通往 AGI 的康庄大道将被彻底打通。 > “如果你在 2024 年问我什么时候能实现 AGI，我会斩钉截铁地告诉你：2025 年就是那一年，我们将在那一年解决所有问题。” 然而，当他身处中心、亲手推动模型一遍遍经过强化学习 Scaling 训练并见证了这一过程后，残酷的现实带来了巨大的心理落差： - **评估指标与训练任务同构**：强化学习模型在一套又一套高难度 Benchmark 上分数飙升、屠榜封神，但那些 Eval 本质上就是训练任务的一体两面（two sides of the same coin）。 - **现实任务的极度混沌**：真实世界的现实分布远比合成环境或固定规则测试更加混乱、肮脏、多变。现有的训练分布根本无法覆盖真实世界用例。 - **“任务荒”假象**：模型训练者们普遍抱怨“我们没有足够难的任务来训练模型”，但转头面对真实工业场景时，系统却依然频繁掉链子。 这让 Jerry 得出了一个颠覆性的结论：**模型在受控实验室中离线预训练、再部署到现实世界的传统范式存在根本张力**。必须彻底转变思路——模型必须具备“在测试期学习”（Test-time Learning）的能力，能够在用户的使用现场，直接利用真实数据与真实任务分布进行实时自适应演进。 --- ### [07:32](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=452s) 测试期学习的困境：上下文上限与灾难性遗忘 当下让模型在测试期实时进化的路径只有两条，但都遭遇了 Transformer 架构底层的坚硬物理墙壁： | 学习范式 | 核心优势 | 致命缺陷 | 实际落地现实 | |:--- |:--- |:--- |:--- | | **上下文学习** (In-context Learning) | 数据效率高；天然避免灾难性遗忘 | 容量不可扩展；上下文窗口受限；推理计算成本激增 | 使用 Codex 编写代码约 20 分钟后，就必须手动压缩并清理上下文，系统记忆严重“短视”。 | | **测试期微调** (Continual Fine-tuning) | 理论上可永久更新权重 | 极易发生**灾难性遗忘** (Catastrophic Forgetting)；单样本数据效率极低 | 无法兼顾泛化与记忆，微调新领域往往导致原有常识与通识能力崩溃。 | Jerry 强调，如果在 Transformer 现有框架下能解决这两个问题，行业早就解决了。上下文长度无法承担真正的终身学习，而权重微调又无法克服遗忘与低效。因此，唯一的出路不在于继续给现有模型打补丁，而是**在架构层面上找到一种全新的元学习（Meta-learning）算法**，从物理结构上原生支持跨越更长时域、具有深度适应能力的经验沉淀。 ### [09:41](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=581s) 缩放定律的经济账：为何 LSTM 输给了 Transformer 在探讨如何给大规模强化学习（RL）奠定前置认知时，Jerry 指出，Transformer 之所以能够胜出，核心并不单纯是纯粹的技术可行性，而在于背后的经济学逻辑。理论上人们完全可以把 LSTM 堆叠扩展到非常庞大的规模，但当年没有人敢冒这个险。缩放定律（Scaling Laws）的经典论文中明确对比了 LSTM 与 Transformer，结果证实 Transformer 的扩展规律在本质上更为优秀。假若历史没有诞生 Transformer，人们固然也会继续缩放 LSTM 并做出一些模型，但其训练成本将高得惊人，作为产品的惊艳程度也会大打折扣。如此一来，根本无法带来合理的商业回报，也就没有人能说服投资人投入数亿美元去训练超巨型的 LSTM。 Transformer 真正令人惊叹的魔力在于其经济价值：训练它所耗费的成本远低于它最终产生的商业营收。这种商业闭环在机器学习领域绝非理所当然。Jerry 回顾道，在 OpenAI 之前，大多数科研人员对“单纯堆算力做 Scaling”抱有极强的抵触心理，甚至视其为“不讲科学”。当时的学术研究普遍致力于提升算法效率——如何在既定计算预算下抠出更好效果。而 OpenAI 当时的豪赌则是反其道而行之：“我们不在乎算法是否越来越精妙，我们在乎的是这个算法是否足够简单、足够具备可扩展性，能让我们无休止地灌入算力并换取更强的性能。”尽管 OpenAI 为此长期遭受学界非议，但正是这种豪赌塑造了如今的 AI 格局。 架构研究在极小规模上停滞了太长时间，许多人总想着先在小数据集、微小算力上验证某个新架构，等证明有效后再去尝试扩展。然而 Jerry 强调，正如在强化学习领域必须跨过一定的算力门槛才能展现出智能跃迁一样，许多潜在的全新神经网络架构也存在一个能力基准线：如果不投入足够的计算量，它们根本无法展现出任何有趣的潜力和实际价值。 - **LSTM 与 Transformer 的缩放差异**：在相同或更高成本下，LSTM 扩展效率极差，产品体验弱，无法实现商业自洽（训练成本无法被产品收入覆盖）。 - **科研理念的范式转移**：从过去追求“固定算力下的极致算法效率”，转向 OpenAI 确立的“追求简单、可直接受益于海量算力灌注的高扩展性架构”。 - **架构研究的“算力门槛假说”**：许多新型架构不能仅靠小型 Toy Dataset 实验来判定死活，它们必须在突破一定的最低算力基准后才能真正涌现出有用能力。 --- ### [12:47](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=767s) 巨头的困局与初创公司的生态位 针对“既然需要高门槛算力，为什么不在拥有海量算力的大厂实验室内部做，而要成立 Core Automation 出来创业”这一尖锐问题，Jerry 直言这完全是一个“市场时机”问题。眼下，全球规模最大、资金最雄厚的顶尖 AI 实验室正陷入历史上最惨烈的同质化市场厮杀中。 当 Transformer 已经在商业上被验证能稳定赚钱，且实验室为了在下一个季度赢下竞品必须把全部精力和卡力都押注在 Transformer 的缩放上时，大厂几乎不可能腾出足够的组织注意力与计算资源，去冒着极大风险研发一到两年后才可能见效、甚至颠覆现有格局的全新架构。Jerry 透露，他与几乎所有头部实验室都深聊过，大厂对于探索 Transformer 替代路径的兴趣极其有限；而二线实验室则陷入了亦步亦趋的怪圈，竭尽全力模仿头部玩家。市场上所有人都在争先恐后地推出一模一样的编程 Agent（Coding Agent）。正是因为现有巨头全部被锁死在既有路线的内卷中，才为 Core Automation 留出了探索非 Transformer 新范式的独特生态位。 ```mermaid flowchart TD accTitle: Big Labs vs Core Automation Strategic Focus accDescr: Comparison between big frontier labs trapped in short term competition and Core Automation exploring post transformer architectures. subgraph BigLabs["头部主流实验室 (Frontier Labs)"] A["季度商业竞争压力"] --> B["全量资源押注 Transformer Scaling"] B --> C["同质化产品内卷 (扎堆发布 Coding Agents)"] C --> D["缺乏动力/资源探索替代架构"] end subgraph CoreAuto["Core Automation 的战略破局"] E["跳出季度指标压力"] --> F["探索后 Transformer 时代新架构"] F --> G["联合端到端优化 (预训练 + RL + 算子)"] G --> H["填补前沿探索生态位"] end ``` --- ### [14:24](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=864s) 逐词吐字与深层瓶颈：Rohan 剖析 Transformer 的效率顽疾 曾任职于 Google Brain 并见证 Transformer 诞生的 Rohan Anil，对 Jerry 的论断深表赞同。他回忆道，当年 Ashish Vaswani 和 Noam Shazeer 等人提出 Transformer 时，内部反响其实很平淡。Rohan 自己当时在同一个内部研讨会上展示在线知识蒸馏（Online Distillation）工作，绝大多数研究员并没觉得 Transformer 有多惊天动地，因为初代论文的切入点非常垂直——仅仅是为了在机器翻译任务上击败 LSTM。直到后来 Noam 等人推动语言模型扩展，并在看到 GPT-2 和 GPT-3 的震撼表现后，业界才真正意识到 Transformer 的可扩展性威力。 Rohan 强调，架构设计的本质是“如何有效消费计算资源（Spend Computation）”。当前整个行业的巨大痛点在于，海量算力都被耗费在推理阶段以自回归方式逐个生成 Token（Chain of Thought）上： 1. **预训练与强化学习的割裂**：预训练构建了一个具有固定上下文长度的 Transformer，而当 RL 发现原有的单步计算能力不足以解决复杂问题时，采取的补丁方案竟是通过 Chain of Thought 一个词一个词地往后吐 Token 来延长思考。从推理系统的角度来看，这种自回归解码机制极端低效，逼得全行业只能用投机解码（Speculative Decoding）这类创可贴式的手段修修补补。 2. **计算深度（Computational Depth）严重不足**：过去两三年里，整个行业才慢慢搞懂如何从庞大的稠密模型走向 MoE（混合专家模型）并兼顾训练效率。但 Transformer 本身的计算深度依然非常薄弱。Rohan 提出，如果把“如何从根本上提高模型的计算深度”作为一个核心命题，立刻就能衍生出 20 多个重新设计底层机制的全新研究方向。 3. **软硬件端到端闭环的缺失**：基础科研往往需要五到六年才能落地到工业界。一个在理论上最优的架构，若无法在硬件上高效运行，就毫无实际价值。研究团队必须具备从研究原型、底层自定义算子（Kernels）编写到最终生产化部署的全栈闭环能力。目前业内绝大多数机构的算法、系统与硬件工程都是割裂的，而 Core Automation 正在打破这种壁垒，让全栈专家协同作战。 针对市场对 Token 成本和生成延迟的抱怨，Rohan 结合自己在 Google 负责服务数十亿用户的背景指出，当前这种仅靠粗暴扩大规模的 Transformer 技术，由于成本与延迟居高不下，注定只能服务全球极少数的人群。如果不彻底从底层重构计算架构，这种局限性还将持续多年。Core Automation 正是带着这种紧迫感，下注寻找能够取代 Transformer 的根本性解法。 ### [19:13](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1153s) Transformer 的计算深度瓶颈与测试期扩展 谈及 Transformer 最根本的技术短板时，Rohan 指出其核心痛点在于“计算深度（computational depth）严重不足”。尽管整个领域被称为“深度学习”，但业界现今训练的大多数前沿 Transformer 实际上相当“浅”，模型深度顶多在 100 层左右。深度学习的初衷是学习逐层抽象的深层表征，但现有预训练架构为模型设下了计算硬顶：整个前向传播的计算预算被严格限定为“层数 × 序列长度（number of layers × sequence length）”。为了突破这一瓶颈，近年来兴起的思维链（Chain of Thought, CoT）推理以及通过强化学习（RL）诱导思维链，本质上是在后天强行弥补计算深度——模型每吐出一个思考 token，就相当于在计算图上增加了一条新的通路。 这种方式虽然带来了推断期扩展（inference-time scaling）的红利，让模型在数学或代码等难题上表现出更强性能，但其内在机制极其低效。模型为了获得更优的推理结果，不得不像打字机一样“一个 token 接着一个 token”线性生成大量冗长文本，导致推理成本激增。Rohan 透露，Core Automation 目前正在攻克的核心方向之一，正是针对这一结构性缺陷进行彻底重构，让深层计算和测试期自适应变得更加高效。 ```mermaid flowchart TD accTitle: Computational Depth in Transformers accDescr: Comparison between shallow pre-trained transformers and test-time reasoning expansion. subgraph Pretrained["经典预训练架构瓶颈"] A["浅层结构<br/>（最多约 100 层）"] --> B["硬性计算预算<br/>（层数 × 序列长度）"] end subgraph InferenceScaling["推断期扩展（思维链与 RL）"] B -.-> C["引入推理 Token"] C --> D["逐个 Token 串行生成<br/>（增加等效计算路径）"] D --> E["计算深度提升，但吞吐与算力极低效"] end ``` - **浅层表征上限**：前沿 Transformer 堆叠至多约 100 层，缺乏更高维度的深层抽象结构。 - **扩展机制代偿**：通过强化学习激发 CoT 是一种通过增加序列长度来代偿固定网络层数的方法。 - **单 Token 瓶颈**：当前测试期扩展完全依赖串行自回归解码，算力利用率和执行效率极差。 --- ### [20:32](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1232s) Transformer 的能力天花板与实验室回训死循环 在被问及 Transformer 架构究竟何时见顶时，Jerry 展开了一个引人深思的思想实验：“如果 OpenAI 和 Anthropic 今天突然停止训练新模型，大家手里只剩下现有的这代 Transformer，接下来会发生什么？”在 Jerry 看来，Transformer 的本质是一个极度擅长从互联网静态数据中提炼知识的“压缩包”，再辅以 RL 将人类预期的工作流固化其中。哪怕实验室派人记录下地球上每一个人的工作场景、环境状态和具体操作，并全部灌入训练集，现实世界只要一发生漂移，这套体系就会迅速瓦解。 随着时间推移，新的社会事件不断涌现，概念间产生全新的关联，新的代码库、软件工具和工作形态层出不穷。由于 Transformer 无法在测试时自我演进，它的实用价值只能依托于训练时见过的分布，一旦脱离训练分布便表现得极为脆弱。当下行业维持模型“聪明”的唯一手段，就是让人类专家写出精准的 Prompt、捕捉模型失败的长尾样本、塞回数据池重新训练，然后依赖中央实验室重新发版。Jerry 直言，这种“任何环境适应都必须绕回中心实验室重训一轮”的模式并非终局，真正的通用智能系统必须摆脱对中心化重训的依赖。 - **静态知识蒸馏**：预训练将人类现有互联网知识压缩至权重，RL 则负责将流程模板硬编码。 - **环境漂移困境**：世界动态变化（新工具、新代码库、新语义关联）导致冻结的模型迅速老化贬值。 - **重训回合限制**：当前的适应能力极弱且缺乏灵活性，修正缺陷必须经历“收集失败样本 $\to$ 回到实验室重训 $\to$ 重新部署”的冗长链路。 --- ### [23:22](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1402s) 走出强化学习的迷信：经验学习的多样性 针对 Rich Sutton 与 David Silver 提出的《经验时代》（The Age of Experience）论文，Jerry 提出了自己的独到见解。他指出，强化学习（RL）绝不是什么新鲜事物——从早期攻克西洋双陆棋（Backgammon），到后来横扫围棋（Go）、《星际争霸》（StarCraft）、《Dota》，再到如今解决编程问题，其核心都是让模型通过自我生成的经验来学习。Jerry 甚至坦言自己的一个激进观点：当下的互联网预训练在很大程度上已经是把其他 AI 生成的数据蒸馏到新模型中，本质上也是一种对网络数据的模仿与行为克隆（behavioral cloning）。 然而，Jerry 明确反对将“从经验中学习”狭隘地等同于强化学习。现有的 RL 算法在数学表达上高度依赖大规模并行模拟展开（parallel rollouts），依靠海量并行世界来降低方差，但这完全不是人类利用经验的方式。Jerry 以人类大脑的学习机制为例进行对比： - **运动技能学习**（如踢足球）：这与 RL 的试错机制极其相似，通过反复踢球、微调肌肉动作，观察落点是否符合预期并进行自我强化。 - **抽象思维学习**（如学习高等数学）：这完全是另一种机制。学习者通过阅读艰深的抽象概念，在脑海内部进行长时间的深度反思与逻辑重构，直到思维“咔哒”一声接通顿悟。 两者都属于“从经验中汲取能力”，但背后的认知算法截然不同。Jerry 强调，尽管业界正在经验学习上投入前所未有的海量算力，但经典的 RL 绝不是终点，未来几年算法研究的重心必然是如何在更丰富、更少依赖暴力并行的场景下高效消化经验。 --- ### [26:41](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1601s) 端到端视角与优化器进阶：打破困惑度教条 当话题转向如何将学习算法的算力与数据效率提升数个数量级时，长期深耕优化算法的 Rohan 一针见血地指出：行业的度量体系从一开始就走偏了。现在的预训练研究将重心完全放在“压缩”上，工程师们死盯着困惑度（Perplexity）指标，坚信参数规模和算力每呈对数级增加，困惑度就能换来微弱的 $\epsilon$ 提升。然而这种看似科学的评估与真实任务往往脱节。Rohan 打趣道：“我辛辛苦苦把预训练模型交到 Jerry 手里，结果 Jerry 跑一轮 RL，就把我费尽心血刷下来的困惑度指标全毁了。” 这种割裂表明，预训练加后训练的分离不过是早期为了冷启动（bootstrap）而采取的妥协方案。要实现效率的跨越式突破，必须将预训练与强化学习打通，构建端到端的学习算法与优化目标。Rohan 回忆了自己在 Google 的优化器演进生涯：2016 年他刚加入 Google 时，负责的是大规模线性求解系统 Sibyl（在深度学习全面接管 Google 之前用于支撑海量逻辑回归的主力求解器）。在亲历神经网络彻底取代传统线性系统后，他明确了自己终身的研究目标——钻研深度学习底层训练算法，打造能从根本上重塑计算效率的新一代优化器。 - **压缩度量的局限**：单纯追求降低困惑度的预训练虽然构建了先验，但算力收益递减极其严重。 - **训练流程断裂**：预训练优化目标与下游 RL 目标相互冲突，亟需融合为端到端的统一训练范式。 - **底层算法渊源**：Rohan 早年在 Google 从优化 Sibyl 大规模线性求解器起步，随后转型深耕神经网络优化器（如后来的 Shampoo），致力于从数学底层重构训练效率。 ### [28:39](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1719s) 优化算法的诞生：Shampoo、Soap 与架构的“共生关系” Rohan Anil 回忆了他在 Google 研发 Shampoo 优化器的起源：当时同事 Vineet Gupta 走到他的工位前说：“听说你非常擅长写优化方法。我们白板上推导出了一个想法，能帮我们实现并把它扩展到神经网络的大规模训练上吗？”在经理 Yonghui Wu 的坚定支持下，Rohan 从那时起一直深耕该方向直至 2024 年离职。然而，在很长一段时间里，整个学术与工业界对优化算法的研究极为冷淡。大多数人抱着一种固执的偏见：“上限在哪里？继续用 Adam 不就挺好吗？为什么不把所有精力花在模型和数据上，非要去碰优化器？” 但 Rohan 坚信优化正是模型训练的核心所在。他指出，深度学习架构与优化算法本质上是同一枚硬币的两面： - **互为妥协与支撑**：过去很多网络架构的设计，纯粹是为了迁就弱优化器，让网络“能够跑通”；如果拥有更强悍的优化器，就能训练那些结构更复杂、更难优化但上限更高的模型。 - **代表性突破**：团队后来在 Gemini 1.5 Flash 中成功应用了 Shampoo，随后学术界逐渐跟进，甚至发表了 Soap 论文，衍生出一整套幽默的“沐浴用品系列（Shampoo、Soap 等）”优化器文献。 - **未被挖掘的潜力**：哪怕 Shampoo 带来了约 2 倍的效率提升，在 Rohan 眼中它依然算不上终极形态，因为它根本没有充分利用训练过程中产生的海量信息。更高级的优化器甚至能帮我们摆脱残差连接（Residual Connections）——业内极少数先锋学者已经证明，在不使用残差连接的情况下可以学到更深层的特征表示，但前提是必须匹配极其强大的优化算法。 ```mermaid flowchart TD accTitle: 优化算法与模型架构的协同关系 accDescr: 展示强弱优化算法分别对应何种架构，以及协同演进带来的计算效率提升。 subgraph WeakOpt["常规路径（弱优化算法）"] W1["标准优化器 (如 Adam)"] --> W2["妥协的架构设计 (如过度依赖残差连接)"] W2 --> W3["易于收敛但特征深度受限"] end subgraph StrongOpt["先锋路径（强优化算法）"] S1["高级二阶优化 (如 Shampoo / Soap)"] --> S2["摆脱架构妥协 (更难优化的深层网络)"] S2 --> S3["端到端高计算效率与更强表征"] end ``` - **强化学习的计算浪费**：Rohan 尖锐地批评了当前的 RL（强化学习）机制，认为它在计算利用率上极其低下。模型为了把仅仅 1 bit 的有效信息反向传递进网络权重，必须完整解码出一整条漫长的思维链（Chain of Thought），这种极低的信息密度让 RL 成为优化算法降本增效的首要靶标。 --- ### [31:56](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1916s) 生物学习效率与端到端统合的现实阻碍 当被问及 AI 是否有可能接近或超越人类生物学的学习效率时，Rohan 坦言“在目前的硬件条件下基本不可能”。他引用了 Geoffrey Hinton 提出的“模型计算（Mortal Computation）”概念：人类的大脑在成长过程中自主构建硬件神经回路与学习算法，个体消亡时回路也随之终止；而目前的深度学习是软硬件割裂的，硬件保持不变，网络依靠庞大的规模和暴力并行来传递极其微量的信息。除非硬件设计彻底颠覆——例如采用类脑模拟电路（Analog Circuits）并攻克模拟误差校正问题，否则机器很难达到生物级的学习效率。对此，Rohan 打趣道：“从这个角度看，人类暂时还是安全的。” 关于“将预训练（Pre-training）与强化学习（RL）进行端到端联合优化”这一看似必然的发展方向，各大主流实验室之所以迟迟没有推进，原因并不只是技术认知差距： 1. **数学本质的冲突**：预训练是典型的大 Batch、高并行、高吞吐的高确定性优化问题；而 RL 涉及先验分布采样、多步 Rollout 和极高的方差，两者的优化目标和训练动态截然不同，简单的拼凑根本行不通。 2. **发布周期的绑架**：顶尖研究员虽然认同这一方向的前景，但根本无法将其排入优先级列表。因为底层 Token API 没有用户黏性，各家大厂陷入了激烈的按月模型发布竞赛（Release Cycles），在动辄要求短期见效的高压环境下，耗时 6 个月以上的深水区探索性研究几乎没有生存空间。 --- ### [34:24](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2064s) 打造世界上最自动化的实验室：Core Automation 的范式重构 面对大模型研究自身进入“AI Scientist”时代的剧变，Core Automation 的目标是成为“世界上最自动化的实验室（Most Automated Lab in the World）”。Jerry Tworek 明确阐述了他们对“自动化”的独特定义： - **最大化人类掌控力与杠杆（Agency）**：他们的自动化不是为了把人类完全排除在闭环之外（Human-out-of-the-loop），而是给单兵赋予无与伦比的杠杆。“徒步只能走一小段距离，骑上自行车走得更远，开上汽车则能走得极其遥远；原始人类只能手工开垦巴掌大的田地，有了农业机械就能耕作一整片平原。” - **单兵迭代速度的质变**：Jerry Tworek 曾在 OpenAI 长期主持代码大模型与内部“AI 科学家”项目的研发。他深刻体会到，旧体制下的组织架构、团队分工和数据流正在拖慢科研速度。初创团队从第一天起就原生基于 Coding Agent 与自动化工作流构建，每一个研究员能够以前所未有的速度测试假设。 - **重构深度学习底层堆栈**：Core Automation 正在从头审视深度学习栈中的几乎每一个基础算子。如果一个小型研究团队每天能自动化完成一次甚至多次底层的完整探索实验，其迭代效率将彻底碾压过去的传统范式。随着自动化能力从“每天 1 次实验”推进到“每天 10 次”甚至“每天 200 次”，在巨大的参数与算法搜索空间中，他们必将凭借敏捷优势发现更优秀的全新深度学习设定。 ### [38:13](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2293s) 重新定义 AGI：剔除“人类在环”才是真正的质变 Jerry Tworek 深入阐述了他对通用人工智能（AGI）的根本定义：一个能够在没有任何人类干预（human in the loop）的情况下实现自我提升的模型。他指出，这一标准其实是“在经济上有价值的人类工作”这一宽泛定义的子集，因为改进 AI 模型本身就是高价值的人类智力工作。然而，迄今为止行业在将人类彻底从循环中剥离方面遭遇了巨大的阻碍，甚至未曾接近这一目标。 当前虽然“人类 + LLM”的混合协作模式取得了巨大成功，但脱离人类监管的纯 LLM 系统几乎无法独立完成复杂的闭环任务。回顾 2024 年至 2025 年初的技术走向，Jerry 认为现有的路径根本无法带我们抵达真正的 AGI。整个领域亟需严肃的底层研究，去攻克模型在推理/测试期（test-time）深层次自主学习与自适应的核心机制。 --- ### [39:33](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2373s) Core Automation 的六个月路线图：为什么从自动化内核生成开始 面对主持人 Sonya Huang 关于 Core Automation 宏伟蓝图的提问，Rohan Anil 公布了公司未来半年的关键里程碑：自动化内核生成（Kernel Automation）。在硬件上（如 NVIDIA GPU 及 Blackwell 架构），算法创新的核心痛点在于“概念落地速度”——即如何把一个消除架构瓶颈的绝妙点子，在最短时间内转化为在 GPU 上跑出极致 TFLOPS 吞吐的底层计算内核。 当前前沿的大模型（无论是 OpenAI、Anthropic 还是 Google Gemini 的最新编码 Agent）在面对高度复杂的算子优化时完全无能为力。为了验证这一点，Core Automation 联合 GPU MODE 举办了一场针对经典线性代数 QR 分解（QR Factorization）的底层算子竞赛。QR 分解在二阶优化算法（如 Rohan 之前主导的 Shampoo 优化器）中处于核心地位： - **基线表现**：使用标准的 cuSOLVER 库，针对特定矩阵形状只能获得基础的算力吞吐。 - **普通 Agent 结合人类搜索**：大约能实现 7 倍的加速。 - **极致人类专家与算力投入**：全世界仅有大约两三位顶尖专家，在 4 周内消耗了价值约 10 万美元的编码 Agent 算力进行深度协同调优，最终实现了惊人的 **60 倍（60x）加速**。 QR 分解涉及到在面板（panel）上执行运算、矩阵相乘、回折累加并不断迭代这一内循环。如果直接把这种问题抛给现有最强的前沿模型，它们连边都摸不到。因此，解决这一极致复杂的问题，是 Core Automation 打造更高效架构的底层内循环。 ```mermaid flowchart TD accTitle: QR Kernel Optimization Performance Comparison accDescr: A comparison between standard cuSOLVER, Coding Agents with humans, and Top Human taste with massive agent compute, illustrating the 60x throughput jump. subgraph Baseline ["标准基线"] A["cuSOLVER 标准实现<br/>(基础吞吐性能)"] end subgraph CurrentAgent ["普通辅助"] B["人类工程师 + 搜索循环<br/>(约 7x 加速)"] end subgraph Frontier ["极致品味与投入"] C["顶尖人类专家 (全球仅2-3人)<br/>+ 4周内 10 万美元 Coding Agent<br/>(达到 60x 加速)"] end Baseline -->|"基础优化"| CurrentAgent CurrentAgent -->|"现有前沿模型断层瓶颈"| Frontier ``` --- ### [42:06](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2526s) 硬件利用率的沉痛教训：从 Shampoo 到 N-gram 架构 Rohan 结合自己在行业内的三段核心研发经历，解释了为何算子内核是绕不开的命脉。在像 Google 这样的巨型机构中，算力经济学极其严苛：绝不可能允许工程师消耗 10 倍的算力去换取区区 2 倍的性能提升；唯一的生存法则是在增加不超过 20% 计算预算的前提下稳拿 2 倍收益。 1. **二阶优化方法（Shampoo）**：其瓶颈全在底层算子。因为算子极其新颖，整个 Google 内部最初仅有 Rasmus 和 Peter Hawkins 两位专家能够编写深度 XLA LLO（Low-Level Optimizer）代码，整整耗时两年才得以彻底跑通。 2. **N-gram 记忆架构（2020 年）**：Rohan 曾与同事探索用外置显存替换 Transformer 的部分参数，提出 N-gram 记忆网络以通过稀疏读写（sparse gathers/scatters）替代部分计算。然而，这需要专属硬件支持与底层算子配合。尽管 Rohan 在疫情期间不断与 TPU 团队开会沟通，所需的硬件加速支持却迟迟未能就绪；直到后来转战 Anthropic，底层支持也才刚刚触及皮毛。令人唏嘘的是，DeepSeek 在大约六个月前发布了其改进版 N-gram 架构，证明了利用 N-gram 嵌入替代部分 MoE 参数的可行性并给出了优异的扩展定律（Scaling Law）。 3. **性能天花板的算法红利**：60 倍加速的 QR 内核意味着全新的算法空间被解锁——原本由于过于沉重而无法在线上运行的高阶特征值分解（Eigen Decomposition）和高级优化器，如今完全能够被纳入实际训练流程中。但能够手写出此类极致代码的专家如同凤毛麟角，散落各处，因此让 AI 模型自主掌握这一高难度能力是破局的关键。 --- ### [45:09](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2709s) 自动化实验室终极使命：寻找替代 Transformer 的新架构与“度假测试” Jerry Tworek 站在系统全局高度总结了 Core Automation 的核心使命：建立世界上最自动化的实验室，去寻找能够**彻底替代 Transformer** 的下一代架构。Transformer 结构先天缺乏持续学习能力，团队的目标是通过超高吞吐的内核生成工具、大规模并行训练基础设施以及精准的先验假设，以远超任何机构的迭代速度在巨大的架构空间中高效搜索。 当被问及“如何确信自己真正找到了全新架构”时，Jerry 坦言在科研经历中，每一个突破性成果最终都会凝聚成一张“关键曲线走势与以往截然不同”的图表（Plot）： - **科研的顿悟时刻**：真正卓越的图表往往早已在科学家的脑海与直觉中成型。深度学习系统极为精巧脆弱，往往需要连续做对 5 件极其微妙的事情，系统的齿轮才会真正咬合，最终在屏幕上跑出那条梦寐以求的曲线。 - **验证标准与“全员度假测试”**：真正的衡量尺度是系统的测试期持续适应能力——即模型能否每天在 Core Automation 内部研发工作中变得更加聪明。Jerry 与 Rohan 甚至打趣提出了一个极具野心的评估法：“整个团队集体去度一周假，看看留守运转的自动化实验室能否在这一周内自主产出更好的研究结果。如果能，那就把假期延长两倍、三倍甚至四倍，直到我们彻底不需要回来。” ### [48:11](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2891s) 结语与展望：自动化 AGI 实验室的全新探索 访谈在关于技术终局与“永久度假”（permanent vacation）的轻松畅想中迎来尾声。主持人 Sonya Huang 与 Pat Grady 感慨这是一个极其美妙的收尾契机，并对 Rohan Anil 与 Jerry Tworek 的到访致以由衷的感谢。两位嘉宾在过往的科研生涯中，分别在 OpenAI 的推理与强化学习扩展、以及 Google 的 Gemini 预训练与 Shampoo 优化器等前沿领域做出了具有划时代意义的突破（"transformative work"），为当今 AI 技术的发展奠定了坚实基石。 主持人由衷表示，非常期待看到他们两位联合创办 Core Automation，开启建立自动化实验室、探索超越现有 Transformer 架构瓶颈与实现测试时持续学习的全新征程，并密切关注他们未来将要创造出的颠覆性成果。Rohan 与 Jerry 亦向主持人的邀请与深度交流表达了感谢，在愉快融洽的气氛与片尾音乐中圆满结束了本次对话。 - **奠基性的过往成果**：Rohan Anil 与 Jerry Tworek 曾分别主导了推动当前 AI 格局演进的重大核心技术突破，其学术与工程深度得到了主持人的极高评价。 - **Core Automation 的新篇章**：两位技术领袖联合启程创办自动化 AGI 实验室，致力于从内核自动化生成入手，打破 Transformer 范式桎梏并开辟端到端学习的新路径。 ## Notable quotes > [01:00](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=60s) 替代 Transformer 的第一步，是深刻体会它曾带领我们走得有多远 — Jerry Tworek > [02:44](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=164s) 下一代更聪明系统的核心瓶颈已经不再是算力规模，而是架构本身（The architecture itself is the bottleneck） — Jerry Tworek > [04:54](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=294s) 如果你在 2024 年问我什么时候能实现 AGI，我会斩钉截铁地告诉你：2025 年就是那一年，我们将在那一年解决所有问题。 — Jerry Tworek > [04:54](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=294s) 评估指标与训练任务本就是一体两面（two sides of the same coin） — Jerry Tworek > [09:41](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=581s) 我们不在乎算法是否越来越精妙，我们在乎的是这个算法是否足够简单、足够具备可扩展性，能让我们无休止地灌入算力并换取更强的性能。 — Jerry Tworek > [26:41](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1601s) 我辛辛苦苦把预训练模型交到 Jerry 手里，结果 Jerry 跑一轮 RL，就把我费尽心血刷下来的困惑度指标全毁了。 — Rohan Anil > [28:39](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1719s) 听说你非常擅长写优化方法。我们白板上推导出了一个想法，能帮我们实现并把它扩展到神经网络的大规模训练上吗？ — Vineet Gupta > [28:39](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=1719s) 上限在哪里？继续用 Adam 不就挺好吗？为什么不把所有精力花在模型和数据上，非要去碰优化器？ — Rohan Anil > [34:24](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2064s) 徒步只能走一小段距离，骑上自行车走得更远，开上汽车则能走得极其遥远；原始人类只能手工开垦巴掌大的田地，有了农业机械就能耕作一整片平原。 — Jerry Tworek > [45:09](https://www.youtube.com/watch?v=2RJiaf0SY8s&t=2709s) 整个团队集体去度一周假，看看留守运转的自动化实验室能否在这一周内自主产出更好的研究结果。如果能，那就把假期延长两倍、三倍甚至四倍，直到我们彻底不需要回来。 — Jerry Tworek ## Mentioned Jerry Tworek, Rohan Anil, Sonya Huang, Pat Grady, Core Automation, Sequoia Capital, OpenAI, Google, Google Brain, Anthropic, Strawberry (o1), Gemini, Shampoo, Soap, Codex, Claude Code, Transformer, LSTM, MoE (Mixture of Experts), Adam, Sibyl, Rich Sutton, David Silver, Ashish Vaswani, Noam Shazeer, Geoffrey Hinton, Vineet Gupta, Yonghui Wu, Rasmus, Peter Hawkins, DeepSeek, NVIDIA, GPU MODE, cuSOLVER, XLA ## Video description Jerry Tworek led reasoning at OpenAI, convinced that scaling reinforcement learning was the path to AGI. Rohan Anil co-led Gemini pre-training and built the Shampoo optimizer. Now they've teamed up at Core Automation on a contrarian premise: the transformer has carried us as far as it can, and the bottleneck to smarter systems is no longer scale — it's the architecture itself. The missing capability is continual learning, models that adapt at test time, which transformers can't do. In-context learning taps out fast (Codex needs compacting after ~20 minutes) and fine-tuning invites catastrophic forgetting. Rohan argues pre-training and RL should be optimized end-to-end, and that transformers spend computation inefficiently. They lay out why the largest labs won't chase alternatives while locked in the coding-agent race, and why building the world's most automated lab starts with automating kernel generation—the one place frontier models still lose to a high-taste human. Hosted by Sonya Huang and Pat Grady, Sequoia Capital 00:00 Introduction 01:46 Appreciating Transformers 02:44 Scaling Hits Limits 04:54 Why Architecture Matters 05:32 RL Reality Check 07:32 Test Time Learning 09:52 Economics Of Scaling 12:47 Why Start A Company 14:24 Rohan On Transformers 19:11 Computational Depth Problem 20:32 When Transformers Top Out 23:22 Beyond Reinforcement Learning 26:41 Optimization And Efficiency 34:24 Building An Automated Lab 39:45 Kernel Automation Roadmap [Source](https://www.youtube.com/watch?v=2RJiaf0SY8s)

[1:00] Jerry Tworek: 替代 Transformer 的第一步，是深刻体会它曾带领我们走得有多远 [2:44] Jerry Tworek: 下一代更聪明系统的核心瓶颈已经不再是算力规模，而是架构本身（The architecture itself is the bottleneck） [4:54] Jerry Tworek: 如果你在 2024 年问我什么时候能实现 AGI，我会斩钉截铁地告诉你：2025 年就是那一年，我们将在那一年解决所有问题。 [4:54] Jerry Tworek: 评估指标与训练任务本就是一体两面（two sides of the same coin） [9:41] Jerry Tworek: 我们不在乎算法是否越来越精妙，我们在乎的是这个算法是否足够简单、足够具备可扩展性，能让我们无休止地灌入算力并换取更强的性能。 [26:41] Rohan Anil: 我辛辛苦苦把预训练模型交到 Jerry 手里，结果 Jerry 跑一轮 RL，就把我费尽心血刷下来的困惑度指标全毁了。 [28:39] Vineet Gupta: 听说你非常擅长写优化方法。我们白板上推导出了一个想法，能帮我们实现并把它扩展到神经网络的大规模训练上吗？ [28:39] Rohan Anil: 上限在哪里？继续用 Adam 不就挺好吗？为什么不把所有精力花在模型和数据上，非要去碰优化器？ [34:24] Jerry Tworek: 徒步只能走一小段距离，骑上自行车走得更远，开上汽车则能走得极其遥远；原始人类只能手工开垦巴掌大的田地，有了农业机械就能耕作一整片平原。 [45:09] Jerry Tworek: 整个团队集体去度一周假，看看留守运转的自动化实验室能否在这一周内自主产出更好的研究结果。如果能，那就把假期延长两倍、三倍甚至四倍，直到我们彻底不需要回来。

[4:54] Jerry Tworek: If you ask Jerry in 2024, when do we get AGI? I would say 2025 will be that year. This is where we solve everything. [9:50] Jerry Tworek: The biggest and the most successful labs, by coincidence or by fate, are probably in the most competitive market fight ever right now, which makes them not very keen on trying different paths, trying alternatives. [15:57] Rohan Anil: a band-aid to a problem that we've picked something that can only generate one token at a time. [19:11] Rohan Anil: Depth is like—it's called deep learning because you want deeper representations... Chain of thought reasoning and RL to do chain of thought by the model itself is one way to increase computational depth because every token you add, you add like one more pathway. [31:44] Rohan Anil: I think we're safe.

[0:00] If I play football, for example, it [0:02] looks very very closely to reinforcement [0:04] learning. I get all a lot of times and [0:06] every time I adjusted a little bit and I [0:08] see if it roughly matches what I what I [0:10] wanted and there are there are there are [0:11] some self-reinforcement happening. When [0:13] I learn mathematics, it's a very [0:15] different type of thing. It's it's like [0:17] reading [0:18] about hard concepts and thinking about [0:20] them very deeply inside my head until [0:23] things click and I until until I have [0:24] them connected. And both of those in [0:26] some way are learning from experience. [0:29] They are just very different. We [0:31] probably are spending the most compute [0:32] than ever on learning from experience, [0:34] but there reinforcement learning is is [0:36] not the end of learning from experience [0:37] and there will be better approaches that [0:39] researchers will be coming up in the [0:41] coming [music] years on how to how to [0:42] use that data. [0:55] >> [music] [1:00] >> Jerry Rohan, thank you so much for [1:01] joining us today. The two of you are the [1:03] founders of Core Animation, one of the [1:06] hottest new labs in San Francisco right [1:07] now. And before starting Core Animation, [1:10] you led some of the most important [1:12] research projects of the AI era. Jerry, [1:15] you were VP at OpenAI, where you worked [1:18] among amongst other things on running [1:20] the strawberry and reasoning teams. And [1:23] Rohan, you were one of two of the four [1:26] pre-training leads at Gemini. And before [1:28] that, led a lot of the fundamental AI [1:30] research at Google Brain and were the [1:32] fix-it guy across Google and then at [1:34] Anthropic. And so, between the two of [1:36] you, you've seen more than a fair your [1:38] fair share of [1:40] what the world looks like in terms of [1:41] doing frontier research. And so, I'm [1:43] very very excited to dig in. Um, let's [1:45] start with you, Jerry. You tweeted a [1:47] very spicy take recently. The first step [1:50] to replacing transformers is [1:52] appreciating deeply how far they were [1:54] able to carry us. Is that a eulogy for [1:56] the transformer? What does that mean? [1:57] >> Thank you very much for inviting us [1:59] here, Sonia. I feel like a lot of my [2:02] interviews these days is explaining my [2:04] tweets. And what did I [2:06] >> [laughter] [2:06] >> What did I mean? [2:08] But appreciating Transformer means like [2:11] understanding what it does well. So, if [2:13] you're not solving the problems that it [2:15] is solving well, you have to focus on [2:16] its on its weaknesses. You have to You [2:18] have to understand good parts and bad [2:20] parts. And it's very easy in a lot of [2:22] the work what people are doing in [2:24] architectures is trying to make [2:26] Transformers cheaper. They are trying to [2:28] make Transformer more efficient. I I [2:30] very rarely see people thinking about [2:32] how do we make Transformers more [2:34] powerful, trying to do more express. But [2:36] But like seeing someone's weak parts and [2:38] seeing someone's strong parts are almost [2:40] almost almost the same thing. It's just [2:41] just understanding the shape of [2:43] Transformer a little bit more. [2:44] >> What I think right now we are in this [2:47] stage. We got to really really good at [2:49] training really really big models. We [2:51] mastered two algorithms. We mastered [2:54] pre-training at a large scale. And we [2:56] mastered reinforcement learning at a [2:57] large scale. [2:59] And I'm asking myself a lot what is next [3:02] in machine learning. I think at this [3:04] moment what the bottleneck is to better [3:07] models and to smarter systems is the [3:09] architecture itself. It is this moment [3:11] to revisit uh the train we've been [3:14] riding for the last 6 years of trying to [3:17] add more and more parameters to [3:19] essentially two of the same [3:21] operations, which is MoE and and [3:24] attention. And when I am when I'm [3:26] thinking about it, like what's what like [3:29] where we are today and what we are [3:31] doing, I am thinking a lot about about [3:34] like what Codex and what Cloud Code are [3:36] doing for us. And I'm really really [3:38] appreciative of those systems and of the [3:40] coding and of the workflow automation [3:42] and of the systems and of the products [3:45] that we have today that we essentially [3:46] have built over those those 6 years of [3:49] scaling. And I think I think this is [3:50] this is the first step of thinking. [3:52] Like, what is the [3:53] If we want to work on the replacement, [3:55] we need to like see where we are, what [3:57] problems we have solved to like start [3:59] seeing what the next stage is, what [4:01] problems we haven't solved yet, what [4:03] what kind of are we missing. And this is [4:05] this is kind of whenever whenever I use [4:07] Codex and I am successful at a task, I [4:11] also start thinking, why did I why [4:12] didn't I try to push that thing harder? [4:15] Whenever whenever I come to work, there [4:17] are a lot of things I do with Codex, but [4:19] I still come to work. I still ask it to [4:21] do certain things for me. And I'm always [4:24] asking myself, why am why am I even [4:25] needed there? Why is uh core automation [4:29] is name and its concept is we want to we [4:31] want to be automating tasks. And why why [4:34] why why are those things not yet [4:35] automated? Why why why is not Codex [4:37] doing everything for me? And this is [4:40] this is the question of like the [4:41] research, where we want to go. And with [4:44] that research, I'm trying to think, what [4:45] kind of models, what kind of what kind [4:47] of systems do we need, what kind of [4:49] qualities do we need what that that that [4:51] we don't we don't have today. And that's [4:52] that's what I'm thinking a lot these [4:54] days. [4:54] >> And you have the starting premise of the [4:57] architecture is the issue, which I think [4:59] is a contrarian point of view. So, [5:00] what's what led you to that point of [5:02] view? What did you see that made you [5:04] think the architecture was the issue? [5:05] >> It's fundamentally what is the issue. [5:08] It's it's it's like comes back from that [5:10] from from the previous implication. What [5:11] I I think is the issue is that the [5:14] models are being trained in the lab and [5:17] are being deployed in the in the real [5:19] world. That is that that is the [5:20] fundamental fundamental tension that is [5:23] that is there. [5:25] And mm [5:27] like [5:28] a bit of a bit of my disappointment came [5:30] comes from my my my personal story. [5:32] Whenever we were starting uh the [5:34] research and progress on scaling up [5:36] reinforcement learning at OpenAI, I [5:38] basically believed that scaling up [5:41] reinforcement learning is a necessary [5:43] stepping stone on a path to AGI [5:46] uh since since since I started like uh [5:48] working working at Open AI. And I was [5:50] always reinforcement learning [5:52] maximalist. I was always believe this is [5:54] what we need to focus on. This is what [5:55] we need to do. I've seen LLMs being [5:57] scaled up to [5:59] to to higher and higher levels through [6:01] GPT-3 to GPT-4. And we're still doing [6:04] very little RL. And I had this this [6:06] internal belief that the moment we start [6:08] scaling up RL we'll we'll we'll solve [6:10] everything. We'll we'll we'll be able to [6:12] solve solve all the problems. And we [6:15] eventually started [6:17] scaling up RL. I was I was just in [6:19] there. I was I was in the center of it. [6:20] I was thinking here we are. If you ask [6:22] Jerry in 2024, when do we get AGI? I [6:26] would say 2025 will be will be that [6:28] year. This is [6:29] this is where we solve everything. And I [6:31] saw us training model after model. This [6:35] model was getting better and better. All [6:36] the benchmark scores were going up. And [6:40] did we also solve all the real-world [6:44] tasks at that moment? Unfortunately, [6:46] unfortunately not. We we we we still [6:48] have work. And I realized there was this [6:51] bit of [6:53] distinction as all the benchmarks that [6:56] we are evaluating our models, they were [6:58] essentially the same thing as we were [6:59] training the models on. Like all the [7:01] evals and training side tasks are the [7:03] same sides of the coin. But the [7:05] real-world distribution and real-world [7:07] task is much messier, much murkier, much [7:09] more much more different. Our our [7:10] training data didn't really replicate [7:13] the real-world use cases. And despite us [7:16] basically maximizing all the task, if [7:18] you see ask anyone training models, [7:21] "Hey, what is one of your main issues?" [7:23] "I don't have hard enough tasks. I don't [7:25] I don't have what to what to train our [7:26] model on." Yet we are still not covering [7:29] the the entirety of the of the [7:30] real-world distribution. From that, my [7:33] conclusion is we need to have models [7:35] that learn at test time. We need to have [7:37] models that learn with users on their [7:39] data, on their real-world task, on the [7:41] real world distribution. And [7:44] there when you ask why why why why why [7:46] why don't we have that today? Why why [7:48] why why are transformers not not [7:49] learning any anywhere? And there are [7:52] essentially two types of learning that [7:55] we could be doing at test time. We could [7:57] be doing in-context learning essentially [8:00] of transformers, which is [8:02] it it it doesn't have [8:04] fundamental problems of catastrophic [8:07] forgetting. It doesn't have that issue. [8:08] It is pretty data efficient. So that [8:10] that is great, but it's not very [8:11] scalable. We only can have so much of [8:14] it. It is limited and it has some more [8:17] even more of mechanical limitations of [8:21] what actually are you doing when you [8:23] when you build context? But maybe maybe [8:25] we can we can come back to it later. But [8:28] we have we have in-context learning, [8:29] which is very limited and very very [8:31] small amount of data. Whenever I'm using [8:32] Codex roughly after around 20 minutes of [8:35] usage, I need to I need to compact it [8:37] and move and move it afterwards, which [8:39] is not that much not that much data. If [8:41] we have all all we can learn is for for [8:43] 20 minutes, it's not that much. And the [8:44] second thing is [8:46] fine-tuning. We could try to [8:48] continuously fine-tune our models, but [8:50] then those have the issues of [8:51] catastrophic forgetting. We have issues [8:53] of very low data efficiency. And neither [8:57] those are very solvable. Neither of [8:59] those are very easy to [9:01] uh to find ways. People have been [9:03] trying. If they was were easy to solve, [9:05] someone already solved it. So [9:08] my personal belief is we need to find an [9:12] algorithm that we can we can meta learn, [9:14] that we can express on the architectural [9:16] layer, that can represent how does how [9:19] does learning look like. How does [9:21] learning look like that can work on much [9:22] much longer horizons. [9:24] >> Mhm. Do you expect the architecture will [9:26] look transformer-like? Cuz my my my [9:29] understanding from the from the chief [9:31] seats is that you know, OpenAI have been [9:33] trying to scale up reinforcement [9:34] learning for a long time, and it wasn't [9:36] until the transformer came about that it [9:38] seemed like there was an even kind of [9:41] scalable prior on the world upon which [9:43] to even scale RL. And so, how do you [9:46] even go about trying to think about [9:48] scaling up this this new resume? [9:50] >> Yeah, it's a it's a it's a great [9:51] question. I think those two things [9:53] happened at the same time, but [9:57] if anything that that happened there was [9:58] was mostly about about economics, [10:00] because technically you can scale up [10:02] LSTMs. Just no one no no one really [10:05] really dared to go in that direction. [10:07] And they did scale much much more [10:11] poorly. They are they are they are [10:12] scaling in a scaling loss paper there is [10:15] presented a comparison of LSTMs and [10:17] Transformers. And fundamentally scaling [10:19] law of Transformers was better. There is [10:21] a world where we never invented [10:23] Transformers and we would be scaling [10:24] LSTMs and we would be having some [10:26] models. But because they would be much [10:28] more expensive to train and much less [10:32] impressive as a product, we would have [10:34] we would have just this worse experience [10:36] and maybe no one would be able to [10:37] convince people to spend as many dollars [10:39] training that those gigantic LSTMs [10:41] because we wouldn't get a market return. [10:43] The the the majestic thing about [10:45] Transformer, which goes back to like why [10:47] why why why do we have to appreciate [10:48] Transformers so deeply, is that [10:50] Transformers are economically valuable. [10:53] The training them the cost of training [10:55] them is lower than the revenue that they [10:57] that they generate, which is which is [10:59] magic of machine learning and it's not [11:01] guaranteed by itself. But for for LSTMs [11:03] it probably wouldn't be that way, which [11:05] which which may have happened. But you [11:06] can in many ways you can scale most of [11:09] the architectures. [11:11] I think I think a lot of reasons why [11:12] people didn't scale things before was [11:14] because researchers before OpenAI had a [11:17] lot of reluctance to scaling. It was [11:20] often seen as unscientific and [11:23] research in algorithm was was providing [11:25] how do we become more and more [11:27] efficient? How do we for the same [11:28] compute budget get better better [11:29] results? And it was it was a bit of a [11:31] bet by OpenAI at that moment. Try to [11:35] say, "Hey, we don't care about better [11:37] and better algorithms. We care about [11:38] smaller and more scalable algorithms." [11:41] And how do we how do we pour more and [11:42] more compute and get better and get [11:44] better results, which OpenAI was [11:45] criticized repeatedly by many people in [11:48] the community for for a long time. But [11:49] thanks to that, we have we have the [11:51] models that we that we have today. [11:53] Uh and I think there are tons of [11:54] architectures that can be scaled up. And [11:58] I am part of [12:00] the core automations mission, and our [12:02] our belief is that a lot of [12:04] architectural research happened at too [12:06] small scale for [12:07] too long time. A lot of people are [12:10] trying to say, "Hey, let's let's try to [12:12] first try our architecture on a on a on [12:15] a small data set on a small in a small [12:17] computer regime, and then and then and [12:19] then see where where where where where [12:20] where it scales only after after you [12:22] prove itself." But for example, when you [12:25] do work on reinforcement learning, you [12:27] know that to get to any interesting [12:29] results, you only you need certain level [12:30] of compute to even see the capabilities [12:33] in a model. Reinforcement learning needs [12:35] a baseline of of of ability to only to [12:37] only start working. So so where I am [12:39] coming from, probably there are many [12:40] architectures that need a baseline of [12:43] compute to even start doing anything [12:45] anything interesting and anything [12:46] useful. [12:47] >> Can I ask you then maybe a touchy [12:48] question? [12:49] >> Please do. [12:49] >> If you need a baseline of compute, that [12:51] sounds like a job that would be well [12:53] served inside of a big research lab. Why [12:55] start a company to go do this? [12:57] >> [laughter] [12:58] >> It's a it's a it's a great question, and [13:00] it's I think in in in many ways it's [13:03] likely a timing thing, timing issue. [13:06] Market is right now in a in a very [13:08] specific place where [13:11] the biggest and the most successful [13:13] labs, by coincidence or by fate, are [13:16] probably in the most competitive market [13:20] fight ever right now, which makes them [13:23] not very keen on trying different paths, [13:27] trying alternatives. If Transformer is [13:29] profitable and if you can spend more [13:31] efforts and more resources scaling [13:33] Transformer to win in the next quarter, [13:36] it's very hard to put at least a lot of [13:38] attention and a lot of energy to work on [13:40] something that will that will maybe [13:42] better or maybe or maybe will will [13:45] redefine the field in a year or two. So [13:47] so I think the big biggest labs and I [13:50] talked to basically all of them don't [13:53] don't have that much interest in trying [13:55] the alternatives to to Transformer. And [13:58] the labs that are not the biggest are [13:59] doing whatever they can to do what they [14:02] what the what the what the most [14:03] successful labs are doing. And everyone [14:04] is trying to trying the same the same [14:06] coding agent. If you look at the [14:08] last week's releases, everyone everyone [14:10] is is trying to release a coding agent [14:12] right now. And and I think [14:15] we need different paths and different [14:18] and different approaches here. So so [14:19] that's what that's the niche in the [14:21] ecosystem we are trying to trying to [14:23] fill in. [14:24] >> Mhm. And you were you were at [14:25] you were at Brain when the Transformer [14:26] was invented. Do you Do you agree with [14:28] Jerry's eulogy for the Transformer? [14:30] >> Yes. Um in some sense like um once the [14:34] first when the Transformers Ashish Noam [14:36] and others came up with it I I had like [14:38] work I worked on my work on online [14:41] distillation around the same time. We [14:42] presented it at the same internal [14:44] research conference. It wasn't a big [14:46] deal internally. There was only few [14:47] people who actually got it. [14:49] >> Mhm. [14:49] >> A lot of few people were like, oh, it's [14:51] it's like, yeah, it's another work. And [14:54] people were finding [14:55] ways to And it was also very focused on [14:58] at least the original work was very [15:00] focused on a real problem, which was [15:01] translation. So they solved like they [15:03] beat LSTM on translation. And it took [15:05] opening up I mean, internally at Google [15:08] there was definitely like Noam and a few [15:09] others were definitely interested in [15:11] scaling language models. I think it is [15:13] until GPT-2 and GPT-3 that we saw the [15:16] benefit of Transformers working quite [15:18] well. At least the way I think about [15:20] architecture is how do we spend [15:21] computation and transformer is one way [15:24] very efficient way to spend computation. [15:27] But now that I look at the industry, [15:28] it's it's a lot of our computation is [15:31] inference time and spending it on [15:32] tokens. Let me ask the question like if [15:35] I want to optimize for a better [15:36] architecture, I want to look at both [15:38] pre-training and RL together and I would [15:40] like to find architectures that spend [15:42] computation much better than current [15:45] chain of thought token generation. Uh in [15:48] at a like to give a much better [15:51] overview, it's I think of like [15:52] pre-training is built the transformer [15:54] with certain context length and RL comes [15:57] in and it's like, well, that's not [15:58] sufficient. I need more computation. Let [16:00] me do it via adding one token at a time. [16:03] This is quite inefficient from uh like [16:06] inference perspective. You're doing one [16:07] token at a time, so most of the [16:09] solutions have been finding to do better [16:12] ways of speculative decoding. So it's [16:14] like a band-aid to a problem that we've [16:15] picked something that's can only [16:17] generate one token at a time. So [16:19] autoregressive decoding. Uh there is [16:21] problems with the transformer in terms [16:23] of how do we spend the computation? Uh [16:26] for all the longest time, I think uh [16:28] most of the world was training very [16:30] large dense models and it took uh like [16:33] the industry like roughly two to three [16:35] years to get to refine the architecture [16:38] to what we now take for granted was not [16:40] obvious to a lot of people. Sparsity and [16:42] the mixtures of experts and getting good [16:45] training efficiencies with them, right? [16:47] So then you can ask like what's wrong [16:49] with the transformer? Well, it's it the [16:51] computational depth is poor. You how do [16:54] we increase computational depth? And [16:55] just posing that question opens up like [16:58] 20 new directions on how we can modify [17:00] the mechanism to incorporate it. So um [17:04] I see like to do work like this, it [17:07] takes time and usually like fundamental [17:10] research in the past have taken like [17:13] five, six years to land into industry [17:16] and it's largely from organizational [17:19] knowing that it is important. This is [17:21] the bet. Like just like Jerry had the [17:23] inner belief that RL is needed. [17:26] Absolutely do not have that belief at [17:27] Google. I was a pre-training maximalist. [17:30] Pre-train a bigger smaller [17:31] >> are a good fit. [17:32] >> Right? Like [17:33] all right. And then so that inner belief [17:35] and second is you need your architecture [17:38] to run efficiently on hardware. A [17:40] theoretically optimal architecture is [17:41] not useful to anyone. It is something [17:44] when it comes into practice. So you need [17:46] the research inception to getting it [17:49] productionized and getting kernels and [17:51] everything written. The end-to-end loop. [17:53] And there's only few places right now [17:55] which have integrated teams doing that [17:58] and I think we have built a team in a [18:01] way that puts every like the experts [18:03] together not in different silos that [18:06] like we are accelerating on having [18:08] everybody look at the problem [18:09] holistically from end to end. So that's [18:11] like where I'm quite bullish. That's why [18:13] I'm here. Um the current mechanisms are [18:17] quite poor and it will if if you leave [18:20] it to the world, I am afraid that it'll [18:22] take us like a much longer time horizon [18:24] before we replace the transformer and I [18:27] think a lot of folks are already [18:28] complaining on [18:29] a lot on token costs. And that seems [18:32] like as someone [18:33] >> complaining. [18:34] >> Uh [18:35] I mean [18:36] in terms of like yeah, exactly. [18:39] I come from the Google mindset where we [18:40] had to like serve billions of people. So [18:42] like finding more efficient [18:43] architectures that fit have a like a [18:45] deadline on latency and the number of [18:47] tokens that you can serve. So like when [18:50] I look at that like the amount of like [18:51] the world that can use like frontier [18:53] tech is very little and we someone or [18:57] some group has to [18:58] like accelerate and make this better and [19:01] we are taking that shot at doing that. [19:03] The current technology just scaled up is [19:05] still only relevant to like a subset of [19:08] humans. [19:09] >> Yeah. [19:09] >> And this is the bet we're making. [19:11] >> So one of the things I heard you say was [19:13] the problem with transformers is the [19:15] computational depth is poor. [19:17] >> Yeah. [19:17] >> If that's the crux of the issue, tell us [19:19] what does that mean? [19:21] Why is that the case? How do you fix it? [19:23] >> I can [19:25] give you like one insight like most [19:27] transformers that we train are quite [19:29] shallow. It's at most like 100 layers [19:32] deep. [19:33] Depth is like it's called deep learning [19:35] cuz you want a deeper representations. [19:38] There has been experiments on going with [19:40] no one has actually shown [19:43] us learning extremely deep [19:44] representations. Chain of thought [19:46] reasoning and RL to do chain of thought [19:48] on by model itself is one way to [19:51] increase computational depth because [19:52] every token you add you add like one [19:54] more pathway. And there has been [19:57] So, then you can get out of like this [19:59] bottleneck that the pre-trained [20:00] architecture has set you up on. You can [20:03] only do layer number of layers times [20:06] sequence length. Now, you can increase [20:08] the sequence length and you get much [20:10] stronger results. You can do inference [20:12] time scaling. Now, the issue with [20:14] inference time scaling is that models [20:16] now have to produce more tokens to get [20:19] better results and that's very one token [20:21] at a time. And from this you can see [20:24] like you can directly address many of [20:26] these things and this is like a subset [20:28] of work that we're looking at, right? [20:30] Making this much more efficient. [20:32] >> What's your forecast for the [20:33] transformer-based architecture? [20:35] If it's not the end state, how far can [20:37] it get us? When do we start to see it [20:40] topping out? [20:41] >> I I I [20:41] think it all it all comes back to what [20:44] we are what we are training transformers [20:46] for and what we can what we can do with [20:48] them. We're doing pre-training which is [20:51] very good at distilling all the [20:52] knowledge from the internet into [20:54] transformers and then we can RL them [20:56] through which is we basically can bake [20:58] all the workflows that we want into a [21:00] transformer. So, what what what where [21:03] transformer has like capped out is we [21:05] have all the knowledge of of of humanity [21:07] in the model together with the [21:09] relationships and how do they how do [21:11] they work together, how we how they can [21:13] be combined. And basically any task that [21:16] we have training data for, we can we can [21:19] put into the model and we this can be [21:21] gigantic model trained with a lot of [21:23] compute on all the on all the all the [21:24] data in the world. And then if we ever [21:27] stop training that model, what would [21:29] what would happen? Like the the question [21:31] worth asking often and thinking about [21:32] transformer, what would happen if OpenAI [21:35] and Anthropic stopped training new [21:36] models and we got we got the transformer [21:38] we have today and say this is this is [21:40] it. This is this is this is the best the [21:41] best model we have. Uh months pass, [21:45] uh year year year years pass and the [21:47] model is getting less and less useful. [21:50] Maybe the lab really like [21:52] recorded of every human on earth what [21:54] they were doing and what their what [21:55] their tasks were and their environments [21:57] and put them put them in the model, put [21:59] them in the in the in the learning [22:00] environment. But then that that then [22:02] then then what happens if the if [22:04] anything of that stuff changes? If there [22:07] are new events in the world, if those [22:09] new events have new relationships [22:11] between them, [22:12] if there are there are new types of [22:14] tasks, if there are new code bases, new [22:16] tools to use, transformers are getting a [22:19] lot of their usefulness and all value [22:21] through the things that are that are [22:23] valuable have to be present in in in in [22:25] in in training. And when when when when [22:27] when they are not, they they they they [22:29] suffer. There's there's some ability to [22:31] adapt, but it's not very not very big [22:33] and not very not very flexible. So in my [22:35] mind this is this is kind of the level [22:37] where the where the transformers uh top, [22:40] which in many ways what I think is a is [22:42] a tool to use for us. If we if if we [22:46] kind of know if there ever there's human [22:47] who knows the limitations of a [22:49] transformer, they can they can schedule [22:51] that model, they can they can write a [22:52] prompt of what is what is it the task [22:54] that you want. And by doing the training [22:56] we are doing, you can you can like get [22:59] very successful in that and any task the [23:01] model fails, you get added to training [23:02] data and the model and the model can can [23:04] succeed. But that that loop is has to go [23:07] for the lab training training the model [23:09] for you. And if the model that that [23:11] fundamentally needs to be trained in the [23:12] lab, like how much do you think of it [23:14] that this is this is the goal or or or [23:17] you would want to be able to update the [23:19] model somehow not having to to go back [23:21] there. [23:22] >> Have you read the Rich Sutton and David [23:24] Silver have this paper the the age of [23:26] experience? Have you read it? I'm [23:27] curious how much you agree or if you [23:29] have any different opinions where your [23:31] opinions diverge. [23:32] >> Reinforcement learning is not a [23:33] particularly new [23:35] approach particularly particularly new [23:38] thing to do. So, [23:40] uh and some some way age of experience I [23:42] think I think always has been there and [23:45] people have been criticizing a bit [23:49] pre-training because pre-training work [23:50] clearly is this is the other way of of [23:53] looking at the models which is like we [23:54] have static data that data is mostly [23:56] generated by others. Although I I have [23:59] this personal view that pre-training [24:00] today is largely distilling other models [24:03] other models into the new model because [24:04] most of the tokens in the internet are [24:06] are coming from from AI. But there [24:09] there's clearly pre-training which is [24:10] which is behavioral cloning which is [24:12] mimicry which is which is compression of [24:15] of of of of internet data. But [24:17] reinforcement learning is not something [24:18] that that people haven't been thinking [24:20] and people haven't been haven't been [24:22] doing. Reinforcement learning was used [24:24] to solve backgammon back in the day. [24:25] They used to solve go, Starcraft, Dota [24:28] and to solving programming right now and [24:32] every time it comes down to model [24:35] writing its own experience and learning [24:37] learning from that experience. But this [24:39] is very clear and what I think is [24:41] interesting and what I think is still is [24:43] still perplexing to people that [24:45] reinforcement learning is not really the [24:47] only way to learn from experience and [24:50] there there will be [24:53] more and there will be there will be a [24:54] little bit more of [24:56] I think [24:58] you can call it algorithmic, but [24:59] essentially innovation of how we learn [25:01] from experience. Just because just [25:04] because reinforcement learning is only [25:06] one way to do it. It's a mathematical [25:08] formulation. And [25:11] especially right now how we are using [25:13] it. It really likes those parallel [25:14] rollouts for variance reduction and for [25:17] for comparing how the model does in in [25:19] in parallel versions of the world, which [25:20] is not how not how we do not how we [25:22] learn from experience. We learn from our [25:24] experience much more efficiently and [25:25] much more [25:27] Um we use we use those in many in many [25:30] many ways. At some moment I've been [25:31] trying to explain to people that what [25:33] what brain does how how we learn. So uh [25:35] there's one learning algorithm in a [25:37] brain. I think I think there are there [25:39] are multiple actually and they and they [25:41] they work together. But if I play [25:44] football for example, it looks very very [25:47] closely to reinforcement learning. I [25:48] kick ball a lot of times and every time [25:50] I adjusted a little bit and I see if it [25:52] roughly matches what I what I wanted and [25:54] I learn or or some self-reinforcement [25:56] had money. When I when I when I learn [25:58] mathematics, it's very different type of [26:01] thing. It's it's like reading about hard [26:04] concepts and thinking about them very [26:06] deeply inside my head until until things [26:09] click and I until until I have them [26:10] connected. And both of those in some way [26:13] are learning from experience. They are [26:15] just very different. So so summarizing [26:17] my thinking of the learning from [26:19] experience is that we've been doing it [26:20] for a while. We probably are spending [26:22] the most compute than ever on learning [26:25] from experience, but the reinforcement [26:26] learning is is not the end of learning [26:28] from experience and there will be [26:30] there will there will be better [26:31] approaches that will [26:33] researchers will be coming up in the [26:35] coming years on how to how to use that [26:36] data in in a richer new chart settings. [26:39] >> Thank you. Same. [26:41] >> I'm Rohan. I'm curious since a lot of [26:42] your work has been around optimization [26:45] and and efficiency, how do we get to a [26:48] orders of magnitude [26:50] more efficient, I guess more compute [26:52] efficient and more data efficient [26:54] learning algorithm. [26:55] >> You know, I would start with [26:56] measurement. I think pre-training as we [26:58] define it right now is about [27:00] compression. We look at perplexity and [27:02] then measure [27:03] how do we decrease the perplexity and [27:05] then we find that scaling and increasing [27:08] parameter count and putting more compute [27:10] is the way and every time we increase [27:13] compute in log scale, we get this [27:16] epsilon more improvement in these [27:18] metrics. [27:19] This is I think this is fine for [27:21] building the prior. [27:23] But I think this is the wrong way to [27:24] look at the problem. We should be [27:26] looking at the end-to-end. What are we [27:28] training these models for? Look at the [27:30] outcome. Like for example, I train this [27:32] model and give it to Jerry. Jerry will [27:34] do RL and destroy all the perplexity [27:37] metrics that I have created, right? Like [27:39] so then it's sort of like it was the [27:41] best way we had so far to attempt to [27:46] solve the problem and I think the labs [27:47] and everyone else have done a great job [27:49] in producing intelligence that's super [27:52] valuable and makes my work so much fun. [27:55] But it was the bootstrap process to get [27:57] there. We have to combine pre-training [27:59] and RL together and that's like [28:02] where one order of magnitude improvement [28:04] would come from and that's like a [28:06] training procedure. You can say it's a [28:08] learning algorithm. Um in terms of [28:11] optimization, [28:12] my story is I started optimization at [28:15] Google for logistic regression back in [28:18] 2016. Got nerds like me and I worked on [28:21] some solvers for what we used to call [28:23] Sybil, which was the large-scale linear [28:25] solver that was used at Google before [28:27] neural network took off and then [28:30] replaced this. Then I asked myself like [28:33] what do I want to work on with neural [28:34] network and it was quite clear like I [28:36] want to understand the training [28:37] algorithm and make it better. And then [28:39] someone Vinit Gupta just showed up one [28:41] day at my desk. It's like I heard you're [28:43] really good at writing optimization [28:45] methods. We have this idea that you [28:47] know, uh like we worked out on a [28:49] whiteboard [28:50] uh and what turned out to be the Shampoo [28:52] algorithm. Can you help us implement [28:54] scale, make sure it works at large scale [28:56] for neural network training? So, as [28:59] working on this, I I thank my manager, [29:01] Yanghui Wu, who has like supported it [29:03] throughout then to like till my end of [29:05] my tenure 2024. But largely like the [29:08] community and most of the other people [29:09] were not as excited by this idea. And [29:12] for me, this is the most exciting thing [29:14] cuz I was like I'm putting in [29:15] computation and making training better. [29:17] This is the thing I have to figure out. [29:19] I will spend as much time I would would [29:22] take to do it. And then people were um [29:25] making this assumption, "Oh, why like [29:27] what's the upper bound? You could still [29:29] use Adam. That's fine. Like why are we [29:31] You could spend all the time on [29:33] everything else, not optimization." But [29:35] in some sense, optimization is like like [29:37] you have a model, you're optimizing it, [29:40] you want to optimize it better. Now, [29:41] I'll connect it to some of the stuff [29:42] that we talked about architecture. What [29:45] has happened is that a lot of the work [29:48] that we've done in architecture is to [29:50] make these networks train. And in some [29:53] sense, it's like two sides of the [29:55] coin and optimization and architecture [29:57] go together. You could have a stronger [29:59] optimizer train a much more harder [30:02] harder to optimize model and get better [30:04] performance. Or you can use a weaker [30:06] optimizer on easier to optimize models [30:09] and get decent performance. So, there [30:11] are these tradeoffs that appear all [30:13] over. And for me, it's a lot of time [30:15] working on it. I think we used it for [30:17] Gemini 1.5 Flash. And then like the [30:19] community started getting like more [30:21] interested in it. There was the Soap [30:22] paper published. We have like an entire [30:25] literature of like shampoo, soap, all [30:27] like bath time the things that you would [30:30] use. And then it was quite clear like so [30:32] that was like maybe a 2x improvement [30:34] over what was happening. But even then, [30:36] if you look at Shampoo, it's quite weak [30:38] in what it's doing. It's not using all [30:40] the information that's available to you [30:43] when you train. And as you use more and [30:45] more information as part of training, [30:47] you can get better improvement. And in [30:51] some sense, like your optimization [30:52] algorithm defines what architectures you [30:55] will discover. Like I have colleagues, [30:57] it's not very popular in the literature. [31:00] It's only like maybe sub like four [31:02] people in the world care about it. Kind [31:04] of ideas that are extremely interesting [31:06] like residual connections have been [31:08] extremely useful for training neural [31:10] networks. There are folks who have like [31:12] gotten rid of them and learned deeper [31:14] representations. But they needed a [31:16] better optimization method. So like for [31:18] me, optimization methods and the [31:20] question you asked is just like how do [31:22] we get there? It's It's combined with [31:24] architecture and thinking about the [31:26] problem end to end is where a lot of the [31:28] computational efficiency is in it. [31:29] >> Yeah. [31:30] >> And I also see RL as spending a lot of [31:32] compute not as efficiently. And so like [31:35] if you could spend it because you don't [31:37] get much feedback and you're [31:39] spending a lot more compute because you [31:41] have to decode all this long chain of [31:42] thought to get this one bit of [31:44] information into the network. Seems [31:46] quite inefficient and an easy target to [31:48] get orders of magnitude on top of. I can [31:51] go on talking about optimization all [31:53] day, but I [31:54] >> it. [31:55] >> Rohan really has [31:56] >> Do you think we'll ever approach or [31:57] surpass biological learning efficiency? [32:01] >> I do not think so because I think [32:04] we would need to change [32:05] I maybe like that was a strong [32:07] statement. At least with the hardware we [32:08] have, it seems pretty unlikely. Um it [32:12] our biological like we have something as [32:15] Jeff Hinton says, model computation. So [32:18] we build our own circuit as we grow up [32:20] and we build our own learning algorithm [32:21] with the hardware. And then we die and [32:23] then we're gone. Uh neural networks are [32:26] quite different. Our hard The hardware [32:27] stays, the neural network stays, but [32:29] it's learning very inefficiently and you [32:31] need a lot more of them and a lot of [32:33] parallelism to get small amounts of [32:35] information through. So until I think we [32:38] design hardware to be much more like how [32:41] humans operate, maybe more analog, [32:44] figure out how to deal with analog [32:45] circuits, and to figure out how to do [32:47] with error correction, figure out how to [32:49] get information through it will be much [32:51] harder. [32:52] Uh we [32:53] I think we're safe. [32:55] >> Safe. That's an interesting way to put [32:56] it. [32:57] Um the idea that pre-training and RL [33:00] should be optimized end-to-end [33:03] seems like such a, you know, clear [33:05] maybe obvious statement. Do do you think [33:08] Do you think the labs realize this? And [33:09] then is it just hard for them to, you [33:12] know, get rid of org charts and process [33:14] to be able to make that come together? [33:16] Or what stops the labs from from being [33:18] able to, you know, unify the the two? [33:20] >> Uh I don't think it's that obvious cuz [33:23] uh it's a completely, again, different [33:25] optimization problem. You have a prior, [33:28] you're doing rollouts, you have higher [33:30] variance, you're [33:32] and then [33:33] pre-training is much large batch, like [33:36] more parallelism or compute for the unit [33:38] of time that you can spend. So, it is [33:41] not an obvious thing for folks to [33:42] combine these two training procedures [33:44] until [33:45] uh you think a bit more like, "Why is it [33:48] that the naive combination doesn't [33:49] work?" So, that's one. [33:52] Uh the second one is if I pull like some [33:54] of the best researchers in these labs, [33:56] they would say, "Oh, this makes sense. [33:57] We should probably explore it, but it [33:59] would be probably not in the top bucket [34:02] because they have to train a model for [34:03] the next cycle before It's like as as [34:06] Jerry said, like there are companies now [34:09] competing for release cycles because [34:11] tokens are not sticky. So, it's much [34:14] harder to do long sight, like even [34:17] long-term research of 6 months in many [34:20] of these labs in the environment they [34:22] are in. [34:24] >> So, it seems like one of the core [34:25] premises for Coral Lemonade is, you [34:27] know, you're starting you're starting a [34:28] lab at a time when you know, Sam's been [34:30] talking about the AI scientists. I think [34:32] Dario's been talking about the AI [34:33] scientist. It seems like your job as [34:35] researchers has actually fundamentally [34:36] changed. [34:38] Um and you're get you get to start the [34:39] company native to that era. And as a [34:41] result, you're maybe able to run a lot [34:43] more experiments than otherwise might be [34:46] possible. How automatable do you think [34:49] the research job is? [34:51] Um and how are you guys approaching [34:54] building your lab to be as I believe [34:55] your mission one of your missions is to [34:57] be the most autonomous lab there is? [34:59] >> Most most automated lab in the world and [35:03] to to start with I think that automation [35:05] the version of automation [35:07] by core automation is about giving each [35:10] human maximum level of agency in some [35:13] way. It is we we're not trying to really [35:17] get humans out of the loop which is like [35:18] one version to automate, but it is about [35:21] give humans ability to do the most with [35:23] with their their amount of time. [35:25] Whenever whenever you are walking you [35:27] can get some distance. Whenever you get [35:28] a bike you can go go work a larger [35:30] distance. Whenever you are a car you can [35:32] you can go much much much much larger. [35:34] When whenever whenever [35:37] humans started farming they had to farm [35:38] by hand and will work on a small plot of [35:41] land. When you have a machine you work [35:42] on a much much larger plot of land. [35:45] Uh personally I am I'm both really great [35:48] fan of the of the current coding agents [35:50] and and and very happy it's in some way [35:52] it is what I've been working for many [35:54] years both doing coding research and [35:57] working on various versions of of AI [35:59] scientist inside inside of OpenAI and uh [36:03] in the end I realized starting a company [36:06] to realize that vision is is is is one [36:08] of the best one of the best ways to [36:10] realize it because the way you can do [36:12] research today is very very different [36:15] because a single researcher can do much [36:17] more. In the end the speed of iteration [36:20] the speed of research the speed of how [36:21] quickly you can you can move through [36:23] ideas and how quickly you can get data [36:25] on your ideas is something something [36:27] very very different and you can try to [36:31] move the old structures around it and [36:35] the teams workflows [36:38] how data is gathered or you can try to [36:40] build like like like you said you can [36:42] you can try to build build natively for [36:44] it for processes that that maximally [36:47] empower each researcher and allow them [36:49] to just to just iterate on their on [36:50] their idea much much quicker. We are we [36:53] are here and we are trying to to to [36:55] rebuild deep learning stack and try to [36:57] think how we can do almost each [37:01] operation differently. What are what are [37:02] various options and if we can execute at [37:06] least even one of those experiments a [37:08] day, that's already a pretty good [37:10] iteration speed versus anything that was [37:12] that was done before and there isn't [37:14] really like any any fundamental like [37:16] laws of physics reason why not and maybe [37:18] maybe one day we get to to 10 of those a [37:20] day. Maybe one day we get we get 200 [37:22] those a day and fundamentally for that [37:25] like search process optimization [37:27] process, we should be able to just just [37:29] find things that work in a better deep [37:31] learning setting and what what we are [37:33] what we are trying to do is like we've [37:35] been like almost all of us we are we are [37:38] we are a team that is very agent built [37:40] and automation built. We are we are we [37:42] are we are we are trying to do an [37:43] experiment like how far how far we can [37:44] we can push those thing and how far how [37:46] how much an organization that tries to [37:49] do as much as we can with a small team, [37:51] how far how far we can get with that. [37:53] >> When will we know that we've reached [37:55] AGI? [37:56] >> At some moment I used to say it's it's [37:58] very much in everyone's heart, whatever [38:00] whatever they consider AGI. Open AI says [38:02] the system that can [38:04] outperform all humans in economically [38:06] valuable work, but it goes to my my my [38:08] my previous statement. What if what if [38:10] Open AI stops training models? Would [38:12] that would that would that would that [38:13] still keep working and I still would [38:15] would that still keep the automation [38:17] level the same the same or would that [38:19] would that drive? [38:20] And for me AGI is a model that can [38:24] improve itself without human in the loop [38:28] in any in any in any way. That's That's [38:30] I think I think the moment where we can [38:32] meaningfully talk about about AGI [38:34] because that is in some way it is a sub [38:36] definition of the previous one because [38:38] improving air models is actually a job [38:40] that humans can do. It is economically [38:41] valuable work. And it definitely [38:44] definitely is the case, but removing [38:46] humans from from from loops with models [38:49] has been actually notoriously [38:51] notoriously difficult so far. We haven't [38:53] come anywhere close to it. It's very [38:55] very hard for me to find any task where [38:56] all of them were able to like get get [38:58] humans out in the loop. We are We are [39:00] the the the the human LLM hybrid is is [39:03] really really successful right now, but [39:05] LLMs without humans not so much, not at [39:07] all. And what I have seen there in 2024 [39:11] and in early 2025 is that the current [39:14] like path doesn't doesn't get us there. [39:17] And I think we need we need some pretty [39:19] pretty serious research on my this [39:21] company or some other to to try to [39:23] unlock how do we how do we make our [39:25] models learn and and adapt at a test on [39:30] a deeper level than we've been so far. [39:32] >> Mhm. [39:32] >> I feel like we've alluded to this [39:33] throughout the conversation, but it's [39:35] kind of been one of these, you know, [39:36] five blinded blindfolded people trying [39:38] to find the elephant things. Uh, what is [39:41] the grand master plan for for Core AI [39:43] that you're willing to share? [39:45] >> I can share our 6-month road map. In [39:47] some sense, like building architectures [39:49] as I said, like wouldn't it's not just [39:51] how good the architectures does it run [39:53] well and can we get users including [39:55] ourselves as part of the lab to use it? [39:58] Right? So, then [40:00] that's directly like we can do many [40:03] things now, but the thing that is going [40:04] to be difficult and thing that we want [40:06] to automate away is kernel generation. [40:09] So, we would we have a set of hardware [40:11] GPUs, black holes that we have to train [40:13] and run inference on. Uh, we will build [40:16] the best model that we can to [40:19] basically reduce the time from having a [40:22] very cool idea that can make [40:26] these bottlenecks go away in the [40:27] architecture to having them run at the [40:30] highest TFLOPS on GPUs. And in some [40:33] sense like current coding agents plus [40:35] humans can go a long way, but like an [40:38] example of this is our urgent QR kernel [40:41] competition that we hosted with GPU [40:44] mode. It's for running this fairly old [40:48] linear algebra operation QR. Um, it's [40:51] used for optimization like shampoo line [40:53] of work uses it. Many other places uses [40:55] it. And you want to run this efficiently [40:57] on a B200 node. Uh, if you use cool [41:01] solver for the shapes that we care [41:02] about, you get some efficiency. And then [41:05] a human plus some search loop can get [41:08] you like something like 7x. [41:10] But it requires the highest taste human [41:14] like there's maybe three people on the [41:15] world to and spend about $100,000 on [41:18] these coding agents over span of 4 weeks [41:21] to get to a solution that's 60x faster. [41:25] So these models today are no way close [41:27] to getting that 60x faster kernel. And [41:29] there's there is a real bottleneck now. [41:32] That was a single problem. It has like [41:35] perhaps three different operators. Work [41:38] on this panel, do this matrix multiply, [41:40] fold it back in, and do this repeatedly. [41:43] That's what the square factorization of [41:44] a matrix would look like. And if you [41:46] give this problem to entropic models of [41:48] an AI model Gemini, it just wouldn't [41:51] solve it. It just is not our models are [41:53] not even close to solving this problem. [41:55] So for us it's like something that we've [41:57] talked about, something that we're [41:58] getting close to as sort of like [42:01] getting to that point because that's our [42:03] inner loop to having more efficient [42:05] architectures. [42:06] >> Why kernels? Is it just cuz like [42:09] maximize intelligence per flop of [42:11] compute you need to generate your own [42:12] >> In some sense, um [42:14] I've had like three projects. [42:17] Two of them have [42:19] kind of landed in the industry. So, [42:21] first is [42:22] secondary methods. Kernels was a [42:24] bottleneck cuz you have to run it well. [42:26] If you were at a place like Google, you [42:28] cannot spend 10x uh amount of compute [42:30] and get a 2x win. [42:31] So, I could only spend maybe a budget of [42:33] 20% and get the 2x win. Everyone's [42:35] happy. [42:36] I don't like great. So, like I think [42:38] that's the market, right? You spend uh [42:40] less than [42:41] >> Yeah. [42:41] >> you uh get. So, kernels ended up being a [42:45] bottleneck there cuz most of the [42:47] operations were novel that we haven't [42:50] gotten a lot of people to look at it. [42:52] There's only like two humans at Google [42:54] who could write it, Rasmus and Peter [42:56] Hawkins. Cuz it was deep XLA LLO code [42:59] that you have to write to make this work [43:01] and then that took them 2 years to do. [43:04] The other idea I had with one of my [43:06] coworkers at that time was like [43:08] replacing some of the parameters in a [43:10] transformer with extra memory and we [43:13] called it N-gram and N-gram memory. [43:15] We worked on it in 2020. It's a we had [43:18] versions of it internally deployed, not [43:21] the big version, the smaller version. [43:23] But, there I needed like something that [43:26] can accelerate sparse uh gathers and [43:28] scatters as part of training. [43:29] >> Yeah. [43:30] >> Uh it required hardware change and a [43:31] hardware making use of the hardware. It [43:34] never arrived. I had uh conferences set [43:37] up with the TPU team, us and a bunch of [43:39] others. We were talking about it and [43:41] during COVID like oh, we're going to [43:42] have it happen and it never arrived. I [43:45] also was using uh TPUs at Anthropic. [43:48] While I was leaving, just barely started [43:50] the surface of being able to um do it. [43:53] But, at the same time, 6 months before [43:55] that, Deep Seek wrote uh their N-gram, [43:57] which is a improved version of adding [43:59] more memory. Short scaling loss that [44:02] yeah, you don't need MOEs. You could [44:04] actually replace it with these [44:06] >> Mhm. [44:06] >> N-gram embeddings. for me that was like [44:08] ah [44:09] >> Yeah. [44:10] >> I It was like a five-year thing and I [44:13] was very happy for them. [44:15] >> isn't even possible if you're not [44:17] writing kernels. [44:18] >> Kernels and you need to be assisted in [44:20] writing kernels or solve that kernel [44:23] to have the highest performance. Like [44:25] and the [44:26] the roof line is pretty high. So it's [44:29] like the QR. If I use CuSolver's QR, I [44:32] get some performance. If I we use our [44:34] the competition winners QR, you get 60x [44:36] faster. [44:37] And that is a completely different [44:39] playing field. Now it opens up an entire [44:41] new set of algorithms you can apply and [44:43] in terms of training transformers, [44:45] training optimizers. QR is so [44:47] fundamental in analyzing the eigen [44:48] decompose for eigen decomposition and [44:51] many other things. So it is a thing that [44:53] I think also if you think about it, only [44:57] few people have the skill set to and [44:59] they're very much not at the same place. [45:02] It's like one person here, one person [45:03] there. And [45:05] it would be ideal if models had those [45:07] abilities. [45:09] >> Maybe I'll I'll [45:10] summarize a little bit and talk from the [45:12] high level of what we want. Kernel [45:13] automation is a lab created to [45:17] build models that continuously learn and [45:19] then learn from deployment. We believe [45:21] as [45:23] I mentioned that transformers are [45:25] incapable of continual learning. There [45:27] there's no way how to put continual [45:28] learning on transformers. So we know we [45:31] have to find a different different [45:32] architecture. Some of anyway, our quest [45:34] is to find that that new architecture, [45:36] find that transformer replacement and we [45:39] want to build the most automated lab to [45:42] do it. We want to be able to build [45:45] experiments at scale the quickest we [45:47] can, iterate on them, try a lot of new [45:49] architectural ideas, have strong priors [45:51] of what we want to do to search the [45:54] space of architectures efficiently to [45:56] find to go to that go to that place [45:58] fastest than than anyone else. That's [46:00] what we what we want to do and all the [46:02] work we are doing on kernels, on large [46:04] scale training, on trying new [46:06] architectural ideas is is exploring that [46:10] space. [46:10] >> So you can experiment your way [46:13] into finding a superior architecture. [46:16] How will you know when you've found it? [46:18] What are you looking for to say, "Aha, [46:21] this is the one." [46:23] >> That's that's a great question. There [46:24] are there always two angles. In in in my [46:27] mind and my experience, every successful [46:30] research had a plot that shows something [46:33] that's that other other plots don't [46:34] show. There there is a one line that is [46:36] a little bit bending in a [46:37] different different way and you're [46:39] saying this is this is what you want. [46:41] But at least it is my experience with [46:43] research always has been that plot is [46:45] already quite late in a journey where [46:48] most of the time you already know what [46:49] you want and already know what you are [46:51] up to. I am a bit a bit joking, but it's [46:54] actually true that all the best plots in [46:56] my life I have done in a dream before [46:58] before actually they were they were [47:00] real. I kind of knew I was looking for. [47:03] Just just the question is is like when [47:04] when it actually clicks if you if you [47:06] know what I mean because most of the [47:08] time you kind of know what you are [47:09] looking for, but you are you are not [47:11] finding it. You you try one thing and it [47:13] doesn't work. Try second thing and it [47:15] doesn't it doesn't work. But eventually [47:17] there all the all the right pieces fall [47:19] into it and most of that deep learning [47:21] systems are very intricate. So usually [47:22] you have to get five things right in a [47:24] row for the for the thing to start [47:26] working and then eventually you get the [47:28] plot that looks like like like like you [47:30] want and then and then you know. So So I [47:32] think [47:34] what we are what we are looking for is [47:35] systems that learn and test time and if [47:39] we see meaningful [47:41] long-term adaptability of our of our [47:44] systems and like we are we are we are [47:46] joking, but it's it's it's a it's a real [47:48] we want to be evaluating our systems of [47:50] our of our [47:51] everyday work. Will they get better at [47:54] doing the work of core automation [47:56] scientists each day? [47:57] >> Yeah, we like go on a vacation as a team [48:00] and see if the lab produces something [48:01] better. [48:02] For the week, give the [48:04] >> Then what you do when you get back? [48:05] >> Um, we'll see what [48:07] >> Extend Extend the vacation two times, [48:09] three or four times, until we are on [48:11] permanent vacation. [48:14] >> Uh, that is a beautiful note to end on. [48:17] Um, Rohan, Jerry, thank you so much for [48:20] joining us. You've both worked on like [48:22] really, really [48:24] transformative work for where we are [48:26] today. And I'm so excited to see you [48:29] starting a lab on this is new journey. [48:32] Uh, and very excited to see what you're [48:34] able to come up with. Thank you for [48:36] joining us. [48:36] >> It's an It's a great to be here and to [48:38] chat with you. [48:39] >> Thank you. [48:43] >> [music] [48:57] [music] [49:05] [music]