Ex-OpenAI, DeepMind Researchers Target Post-Transformer AI Architecture

前 OpenAI 与 DeepMind 研究员瞄准后 Transformer 架构 Core Automation 联合创始人认为，当前的 Transformer 模型无法实现持续学习或真正的自我改进，需要结合定制硬件内核协同设计新架构，以打破 AI 扩展瓶颈。 AI 领域专家 Jerry Tworek（前 OpenAI）与 Rohan Anil（前 Google DeepMind）指出，单纯靠参数扩展的 Transformer 模型已碰壁，上下文学习和持续微调均无法解决实际应用中的测试时自适应问题。他们分析了现有主流实验室因受困于短期产品竞争而难以推进高风险架构变革的原因，并指出了计算深度的结构性限制、困惑度与强化学习（RL）之间的权衡，以及优化瓶颈。为突破这些制约，Core Automation 正在构建一个高度自动化的实验室，专注于预训练、RL 以及定制硬件内核的端到端协同设计，以实现真正具备自我改进能力的 AGI。 Jerry Tworek 与 Rohan Anil 认为 Transformer 架构已成为通往下一代智能的核心瓶颈，单纯依靠参数与算力扩展已难以继续带来质的飞跃。 (0:00) 现有模型普遍缺乏测试时自适应（test-time adaptation）能力：In-context 学习在编码等任务中持续约 20 分钟便会触碰上下文上限，而持续微调则会引发严重的灾难性遗忘。 (5:00) 主流 AI 实验室被卷入短期的 API 与产品发布竞赛，在体制上缺乏动力去承担高风险、周期长达数年的底层架构探索。 (10:00) Transformer 模型的计算深度严重受限（通常不足 100 层），不得不低效依赖自回归生成思维链来模拟复杂推理；同时以压缩为主的预训练与 RL 优化目标存在割裂，需要进行端到端的统一重构。 (15:00) Core Automation 致力于构建高度自驱的自动化研究实验室，将自动化底层 Kernel 生成作为战术切入点，以释放新架构在现代硬件上的极致计算潜力。 (40:00)

Core Automation founders Jerry Tworek and Rohan Anil argue that the transformer architecture and parameter scaling have hit fundamental limits in computational depth, continual learning, and test-time adaptation. They contend that reaching true artificial general intelligence requires replacing the transformer through an automated research lab that co-designs architectures, optimizers, and low-level hardware kernels. Structural Limits of Transformers and Continual Learning Jerry Tworek argues that while scaling pre-training and reinforcement learning (RL) drove past industry breakthroughs, the transformer itself is now the primary bottleneck to automated intelligence. Frontier dense transformers remain computationally shallow, rarely exceeding roughly 100 layers. To compensate during reasoning tasks, models rely on autoregressive chain-of-thought token generation, which creates severe inference latency and compute inefficiencies. Furthermore, existing models depend on the assumption that training sets contain all relevant information; without ongoing retraining, static models rapidly degrade as real-world codebases, tools, and conditions change. Tworek highlights that current test-time adaptation mechanisms remain inadequate. In-context learning avoids catastrophic forgetting but hits mechanical limits, such as context bloating and degradation after approximately 20 minutes in coding workflows. Conversely, continuous fine-tuning on user data suffers from low data efficiency and triggers catastrophic forgetting. While benchmark performance improved rapidly through 2024, Tworek notes that high benchmark scores mirror clean training distributions rather than messy real-world complexity, demonstrating the need for architectures that adapt natively over extended horizons. Unifying Optimization, Pre-Training, and RL (28:00) Rohan Anil contends that the industry's approach to pre-training—optimizing power-law data compression to reduce perplexity—is merely a bootstrap process for priors rather than a complete learning solution. In current workflows, applying downstream RL disrupts the carefully minimized perplexity metrics. Anil and Tworek argue that pre-training and RL must instead be optimized end-to-end within a unified framework, though bridging pre-training's large-batch static data compression with RL's dynamic, high-variance rollouts presents substantial mathematical and systems hurdles. Anil emphasizes that advanced optimizers expand the frontier of viable neural architectures. Historically, architectural components like residual connections were introduced partly to compensate for first-order optimizers like Adam. Second-order optimizers like Shampoo—used in Gemini 1.5 Flash to achieve roughly 2x pre-training efficiency gains—can optimize deeper or more complex architectures that Adam cannot train. However, Anil questions whether digital AI hardware can ever match biological computational efficiency, citing Geoffrey Hinton's concept of mortal computation: biological learning links software directly to analog physical substrates, whereas digital GPUs incur massive energy and communication overhead to pass small gradient updates across parallel arrays. The Kernel Bottleneck and Architectural Exploration (40:00) Implementing non-transformer architectures requires mapping abstract mathematics directly to peak TFLOPs on hardware like NVIDIA Blackwell architectures. Anil points to custom kernel development as an immediate operational bottleneck. In a QR matrix decomposition challenge with GPU Mode, default libraries like cuSOLVER provided baseline performance, and simple search loops yielded a 7x speedup, but reaching a 60x speedup required three expert CUDA engineers working alongside frontier coding agents for four weeks. Frontier language models cannot currently solve these low-level kernel problems autonomously. Anil notes that missing hardware-accelerated kernels has historically stalled algorithmic development. In 2020, his team conceptualized replacing transformer parameters with N-gram memory embeddings, but internal Google deployments stalled because custom TPU gather-and-scatter acceleration could not be delivered in time. Five years later, DeepSeek published scaling laws showing that N-gram embeddings could replace Mixture-of-Experts (MoE) layers, validating the concept once kernel and hardware tooling matured. Lab Incentives and Autonomous Research Systems (32:30) Tworek and Anil observe that incumbent frontier labs are ill-positioned to explore post-transformer architectures. Locked in intense competition and offering API tokens that lack user stickiness, major labs face pressure to prioritize immediate, quarterly releases—such as coding agents—over speculative, multi-year architectural research. Because novel architectures require significant baseline compute to demonstrate signal, small-scale toy evaluations are insufficient, making it difficult for researchers in product-focused labs to secure six-month exploratory mandates. Core Automation addresses this barrier by constructing an automated research facility where agentic tooling automates experimental deep learning workflows across model designs, training dynamics, and kernel compilation. Tworek defines true AGI not merely as economic utility, but strictly as a system capable of recursively improving its own capabilities without human intervention. By accelerating internal research iterations, the founders aim to discover self-adapting architectures that perform the daily workloads of AI research scientists. The founders acknowledge that discovering a post-transformer architecture requires simultaneously aligning multiple complex components—including architectures, optimizers, and low-level kernels—before scaling curves visibly diverge. Whether Core Automation's automated research loop can validate a viable alternative architecture at scale without the immense operational infrastructure of incumbent labs remains an open empirical test.

Core Automation 联合创始人 Jerry Tworek 与 Rohan Anil 指出，现有 Transformer 架构及单纯的参数扩展已遭遇计算深度不足与无法持续学习的根本瓶颈；他们正通过构建高度自动化的研发实验室，探索端到端联合优化预训练、强化学习及底层硬件算子，以寻求替代架构并实现真正的通用人工智能（AGI）。 Transformer 的计算深度瓶颈与测试期适应缺陷 Jerry Tworek 与 Rohan Anil 认为，Transformer 架构虽在过去几年凭借混合专家（MoE）与注意力机制的扩展带来了巨大商业回报，但如今已成为通往更高智能的主要障碍。当前稠密 Transformer 的结构普遍较浅，深度很少超过约 100 层，导致内部表征能力受限。现有范式试图通过强化学习强制模型自回归生成思维链（Chain-of-Thought）Token 来换取推理深度，但逐 Token 生成的方式不仅算力效率极其低下，还迫使业界依赖投机解码等权宜方案。此外，如果主流实验室停止模型训练，缺乏动态更新机制的静态模型在面对真实世界新事件、代码库演进与新工具时，效用会迅速退化。 面对未出现在训练集中的真实复杂任务，现有 Transformer 的动态适应手段陷入两难困境。上下文学习（In-Context Learning）虽无灾难性遗忘且数据利用效率高，却受制于上下文窗口限制；在实际编程工作流中，往往持续使用约 20 分钟后上下文就会膨胀，不得不进行压缩或重置。若直接在用户数据上进行连续微调（Continuous Fine-Tuning），则会导致灾难性遗忘且数据利用效率极低。Jerry 指出，模型在贴近训练数据分布的基准评测中屡创新高，却在混乱的真实应用场景中频频受挫，必须依靠在架构层深度嵌入元学习机制，才能在测试期实现原生、长周期的动态适应。 现有实验室的组织束缚与统一优化的数学分歧 两位创始人分析，主流大模型实验室难以投入精力探索替代架构，首要原因在于组织激励与商业节奏的错位。由于模型 API 缺乏天然的用户粘性，主流厂商深陷白热化的市场发布周期，不得不将全部计算资源调配给能带来即时商业回报的增量优化（如季度发布编程 Agent）。在激烈的短期竞争中，管理层通常不会批准耗时六个月以上的底层架构探索。同时，复杂学习机制与新型元学习架构在微小算力尺度下几乎无法显现信号，必须跨过极高的基础算力门槛才能展现能力，这进一步放大了大机构承担试错风险的成本。 从技术机制上看，将预训练与强化学习打通为端到端统一流程在数学上并非易事。预训练依赖在静态语料上通过超大批次（Batch Size）和高并行度来压缩数据以降低困惑度（Perplexity），遵循对数增加算力仅获得微小边际收益的幂律定律；而强化学习则依赖高方差的动态路径采样（Rollout）。Rohan 观察到，业界在预训练模型上微调强化学习时，实际上彻底破坏了预训练阶段精心优化的困惑度指标。两套数学范式的分裂，不仅导致业界普遍将强化学习误当成从经验中学习的唯一数学形式，也构成了架构整合的技术壁垒。 二阶优化器演进与生物计算效率的现实壁垒 (28:00) 在优化算法研究方面，Rohan Anil 回顾了第二代优化器 Shampoo 的起源与演进。他在 Google 工作期间与 Vineet Gupta 合作开发 Shampoo，旨在打破 Adam 算法独占的格局。随后该算法被应用于 Gemini 1.5 Flash 的预训练，相比传统方法实现了约 2 倍的效率提升，并带动了包括 SOAP 在内的一系列优化算法研究。Rohan 提出，优化器与模型架构之间存在深度的协同设计关系：历史上残差连接等架构特性的出现，部分是为了迁就 Adam 等较弱优化器的训练局限，而更强大的优化器理论上能够直接训练以往无法收敛的深层或无残差复杂网络。 然而，对于人工智能能否匹配人类大脑的计算效率，Rohan 持明确的否定态度，认为在现有数字硬件限制下短期内几乎不可能实现。他引述 Geoffrey Hinton 提出的“终有一死的计算”（Mortal Computation）概念指出，生物神经系统在生长过程中将算法与物理基质不可分割地融为一体；而数字人工智能则严格拆分了软件与硅基硬件。为了在静态硬件上传递微小梯度，数字 GPU 必须依赖极端的数据并行计算，能量损耗极其巨大。在硬件能够原生地容忍噪声并直接进行模拟误差校正之前，生物大脑的能效优势依然难以逾越。 算子工程瓶颈与高度自主化科研实验室的构建 (40:00) 构建全新非 Transformer 架构的战术瓶颈落在了底层硬件加速算子（Kernel）的开发上。若无法将数学构想转化为能在 NVIDIA Blackwell 或 B200 等现代 GPU 上以峰值浮点性能执行的高性能算子，新型架构便无法在真实算力预算中落地。Rohan 举例说明，在线性代数与 Shampoo 优化中通用的 QR 矩阵分解任务中，使用 NVIDIA cuSOLVER 仅能获得基准性能；普通工程师搜索可获得约 7 倍加速，而要实现 60 倍提速，则需要顶尖 CUDA 专家驱动前沿编程 Agent 苦战四周才能达成。当前 OpenAI、Anthropic 或 Google Gemini 的主流模型均无法独立解决这类极度精密的算子生成难题。 为此，Core Automation 将核心使命定位于打造高度自主化的 AI 实验室。与其追求完全将人类排除在外，其实验室模式旨在通过自动化研发工作流将研究员从繁重的日常调试中解放出来，使小规模团队每天能够自动化运行数十次甚至上百次全栈深度学习实验。Jerry 对通用人工智能（AGI）给出了严格的操作型定义：即系统无需人类介入即可实现自我迭代与自我改进。他指出，2024 至 2025 年间“人类加大语言模型”的混合协作模式虽然卓有成效，但真正的自主演进系统依然缺位，唯有突破测试期适应性难题，才能真正逼近 AGI。 Jerry Tworek 与 Rohan Anil 坚信替代 Transformer 需要多项复杂子系统在算法与底层硬件层面同时协同就绪，其终极验证标准不仅在于测试集曲率的改变，更在于模型能否承担起实验室内部全流程科研代码的自主迭代。目前，如何让自动化 Agent 稳定独立攻克深层算子生成，以及新型架构能否在大算力验证下稳定重现自适应能力，仍是 Core Automation 有待在实践中验证的核心挑战。

## Background 本期节目由红杉资本（Sequoia Capital）于 2026 年 7 月 29 日在播客及网络平台发布，由合伙人 Sonya Huang 与 Pat Grady 共同主持。节目介绍了两位亲历前沿模型突破的顶尖专家——曾任 OpenAI 推理团队负责人的 Jerry Tworek 与曾共同领导 Gemini 预训练的 Rohan Anil，重点探讨他们联手创立 Core Automation 背后的核心命题：为何 Transformer 架构已达极限、持续学习能力为何缺失，以及如何打造全自动化的 AGI 实验室来寻找下一代全新架构。 ## TL;DR Jerry Tworek 与 Rohan Anil 认为单纯依靠堆砌算力扩展 Transformer 已经触及天花板，其核心瓶颈在于无法在测试期实现长程的持续学习与动态自适应。现存主流范式将预训练与强化学习严重割裂，逐 Token 推理效率极低，而顶尖巨头受困于季度发布周期的内卷，无法投身于可能颠覆现有架构的长线探索。Core Automation 致力于打通从最底层 GPU 算子生成（如极限 QR 分解内核优化）到新型架构设计的全栈闭环，通过高密度的自动化实验探索非 Transformer 路径，最终打造一套不依赖人类干预、具备自我持续改良能力的完全自动化研发体系。 ## Atmosphere & style 整场对话洋溢着顶尖系统工程师与一线科研领袖特有的清醒、严谨与务实幽默。Jerry Tworek 带着从强化学习极大主义者幻灭后的深刻反思，以生动的比喻拆解认知机制与 Scaling 的商业现实；Rohan Anil 则展现出硬核的底层工程直觉与全栈技术积淀，言辞犀利直击痛点。主持人的追问层层剥离技术光环，四人在畅快而高密度的思想碰撞中勾勒出迈向深水区的新范式，既有对现实技术瓶颈的冷峻剖析，又充满探索未知无人区的从容与浪漫情怀。 ## Bulletin - `00:00` 前 OpenAI 推理负责人 Jerry Tworek 与前 Gemini 预训练负责人 Rohan Anil 联合创立 Core Automation，主张 Transformer 架构已达瓶颈，必须研发支持测试时持续学习的全新架构以实现 AGI。 - `05:00` 现有 Transformer 在测试期自适应面临两难：上下文学习容量极窄（Codex 约 20 分钟即需压缩），而持续微调则会遭遇严重的灾难性遗忘与极低数据效率。 - `40:00` 大模型在底层高性能算子生成上仍落后于人类专家：以 B200 上的 QR 分解内核为例，顶级人类专家配合 Agent 可实现 60 倍提速，而主流大模型完全无法端到端独立解决。 - `35:00` Core Automation 将预训练与强化学习的端到端融合以及算子内核自动生成作为突破口，旨在构建全自动闭环运转的 AGI 研发实验室。 ## Key takeaways - `00:00` 踢足球式的运动试错与高阶数学概念的顿悟机制迥异，当前强化学习只是经验学习的一种狭义数学表述，绝非经验学习的终极形态。 - `02:18` 行业在 Attention 与 MoE 的参数堆叠上已行驶六年，当前学术界多局限于推理降本与加速，缺乏对架构表达力与智能上限的深层探索。 - `05:00` Scaling RL 无法掩盖基准测试与真实世界数据分布的脱节，唯有具备“测试时学习（Test-time Learning）”能力的架构才能突破中心化实验室的更新死循环。 - `10:00` Transformer 具备商业回报大于训练成本的独特经济学奇迹，而小规模算力环境往往因未达能力涌现门槛而扼杀了有潜力的新架构。 - `12:30` 顶级实验室因受制于季度发布周期与同质化 Coding Agent 竞速，难以抽身下注可能颠覆自身架构的长线研究，为新实验室留出了生态位。 - `14:48` 逐 Token 自回归生成本质上是在用序列时间强行换取计算深度，是弥补物理网络层数过浅（普遍百层以内）的低效妥协方案。 - `25:52` 端到端整合预训练与强化学习是突破计算效率的关键，传统预训练过分追求困惑度指标，其收益往往在随后的 RL 阶段被彻底打破。 - `30:00` 模型架构与优化算法互为表里，更强悍的高阶优化器（如 Shampoo 等）能够解锁原本难以收敛但表达能力更强的深层无残差网络范式。 - `30:00` 受限于“有限计算（Mortal Computation）”的软硬件分离架构，人工神经网络在样本与能效利用率上暂时无法匹敌生物大脑。 - `37:32` AGI 的核心判定基准在于系统能否在没有任何人类参与的闭环下实现持续的自我迭代与改良。 - `42:47` 底层 Kernel 编写能力长期制约算法创新，过去因硬件算子开销过大而被放弃的算法（如二阶优化与 N-gram 记忆网络）需要靠极限优化重新激活。 - `45:00` Core Automation 的终极目标是通过高度自动化将人类研究员从执行细节中解放，通过极高频的假设验证探索出彻底取代 Transformer 的新架构。 ## Detailed walkthrough ### `00:00` 经验学习的本质与两位前沿技术负责人的联手 在探讨人工智能学习机制的开篇，Jerry Tworek 拿踢足球与学数学做了一个极具画面感的对比。踢足球的过程高度类似于强化学习（Reinforcement Learning）：一个人一次又一次地起脚射门，每一次尝试后根据皮球轨迹进行微调，观察结果是否大致符合预期，大脑中发生着自我强化；然而学习数学则是截然不同的认知机制，它需要阅读极其晦涩抽象的命题概念，在大脑内部进行深度的沉思与推演，直到某一瞬间所有逻辑链条豁然贯通。这两种方式在广义上都属于“从经验中学习”，但底层机制完全不同。当前整个 AI 工业界在经验学习上耗费的算力比以往任何时候都要多，但强化学习绝不是经验学习的终局，未来几年研究者们必然会探索出利用经验数据的更优范式。 红杉资本（Sequoia Capital）合伙人 Sonya Huang 由此引出了本期对话的两位重磅嘉宾——硅谷炙手可热的“新实验室”（Neolab）Core Automation 的联合创始人 Jerry Tworek 与 Rohan Anil。两人在创立 Core Automation 之前曾执掌过 AI 时代最具代表性的前沿项目：Jerry 曾任 OpenAI 副总裁，主导了备受瞩目的 Strawberry 项目以及推理（Reasoning）团队；Rohan 则是 Gemini 预训练阶段的四位核心负责人之一，在此之前曾长期领导 Google Brain 的基础 AI 研究，并在 Google 及后来的 Anthropic 内部担任关键技术攻坚的“救火队长”（Fix-it guy），同时也是知名优化器 Shampoo 的缔造者。两位亲历前沿模型突破的顶尖研究者联手创业，正是为了正面挑战当今 AI 架构的最深层瓶颈。 ### `02:18` 对 Transformer 的“悼文”与后架构时代的瓶颈 Sonya 抛出了 Jerry 近期在社交媒体上引发轩然大波的一条推文：“取代 Transformer 的第一步，是深刻领会它究竟把我们带出了多远。” Jerry 半开玩笑地感慨，自己最近几乎每次接受采访都要专门解释自己的推文究竟是什么意思。他解释道，这绝不是单纯写一篇悼文，而是强调如果不能真正看清 Transformer 擅长解决什么，就不可能认清它的弱点所在。如今学术界和工业界绝大多数针对架构的研究，都在想方设法让 Transformer 变得更便宜、更高效，却极少有人真正思考如何让架构具备更强的表达能力（Expressive）与解决复杂问题的力量。 在 Jerry 看来，AI 领域目前已经把两套核心算法磨练到了极致：大规模预训练与大规模强化学习。然而，我们在这列“依靠 MoE（混合专家模型）和注意力机制（Attention）不断堆叠参数”的技术列车上已经行驶了整整六年。如今限制系统变得更聪明的真正瓶颈，正是架构本身。Jerry 每天都在高频使用 Codex 与 Claude Code 这类编程自动化工具，他一方面由衷赞叹这六年来规模化扩展（Scaling）所带来的工作流红利，但另一方面又始终被一个根本性问题所困扰：既然自己已经能够用这些工具完成大量工作，为什么每天依然需要亲自来上班？为什么 Codex 不能替自己搞定一切？这正是创立 Core Automation 的核心动因——如果人类要在研发端彻底实现自动化，就必须审视当前系统缺失了哪些至关重要的特质。 - **六年的扩展路径**：过去六年整个行业本质上一直在对 Attention 和 MoE 这两种基本运算施加更多参数，依赖超大规模预训练和超大规模 RL 的组合拳。 - **效率 vs. 表达力**：大部分架构创新局限在降本与推理加速，缺乏对架构“表达能力与智能上限”的探索。 - **自动化的未竟之业**：日常开发虽然充斥着 Codex 和 Claude Code 的身影，但人类依然是工作流中无法被替代的黏合剂，表明现有系统缺乏根本性的认知能力。 ### `05:00` 实验室与现实世界的割裂：强化学习神话的破灭与测试时学习的困境 Jerry 坦承自己技术视角的转向源自一段刻骨铭心的幻灭过程。在 OpenAI 启动强化学习规模化（Scaling RL）之初，他是一个彻头彻尾的“强化学习极大主义者”（Reinforcement Learning Maximalist），坚信 Scaling RL 就是通往通用人工智能（AGI）必不可少的关键台阶。当行业从 GPT-3 一路迈向 GPT-4 时，模型内部实际包含的 RL 成分依然很低；Jerry 当时坚信，只要真正把 RL 规模化做起来，所有问题都将迎刃而解。“如果你在 2024 年问我什么时候能实现 AGI，我会斩钉截铁地告诉你：2025 年就是那一年，届时我们将解决一切。” 然而，当他身处漩涡中心，亲眼见证一个又一个模型被训练出来、基准测试分数节节攀升之后，残酷的现实却摆在眼前：现实世界中的各类复杂任务并没有被顺理成章地解决。Jerry 意识到，所有的 Benchmark 与评估集本质上与训练任务是“同一枚硬币的两面”，而真实世界的分布要肮脏、混沌得多。前沿实验室的训练者常常抱怨“已经没有足够难的任务来供模型训练”，可模型却依然无法覆盖真实任务的分布。这种实验室与现实世界的剧烈张力得出了一个必然结论：模型必须具备“测试时学习”（Test-time Learning）的能力，能够在用户真实的场景中、伴随用户的数据即时自适应。 在现有的 Transformer 体系下，测试时学习面临着无法逾越的机械限制。模型在测试时自适应仅有两种既有途径，却各自存在致命短板： ```mermaid flowchart TD accTitle: Transformer在测试时学习上的双重困境与未来方向 accDescr: 展示上下文学习与持续微调各自的局限性，并推导出需要架构层元学习的结论。 subgraph Bottleneck["现有 Transformer 测试时学习途径"] A["上下文学习 (In-Context Learning)"] -->|优点| B["无灾难性遗忘 / 高数据效率"] A -->|瓶颈| C["容量极度受限<br>Codex 使用约 20 分钟必须压缩"] D["持续微调 (Continual Fine-Tuning)"] -->|缺陷| E["灾难性遗忘 (Catastrophic Forgetting)"] D -->|缺陷| F["极低的数据利用效率"] end subgraph Solution["Core Automation 探索路径"] G["架构层元学习 (Meta-Learning on Architecture)"] G --> H["跨越超长时域 (Longer Horizons) 的自适应学习"] end C -.->|无法支撑复杂现实任务| G E -.->|参数更新失控| G F -.->|样本需求过大| G ``` 第一种途径是上下文学习（In-context Learning），它的优势在于没有灾难性遗忘，且具备较高的数据效率，但容量上限极其脆弱。Jerry 以自身体验举例，使用 Codex 大约 20 分钟左右，上下文窗口就会不堪重负，必须对历史记录进行压缩（Compact）和迁移，无法承载更长时间跨度的连续认知；第二种途径是持续微调（Fine-tuning），但这会立刻遭遇灾难性遗忘与极度低下数据效率的折磨。如果这些问题在现有架构内容易解决，业界早就攻克了。因此，Jerry 坚信出路不在于修补，而在于在全新的架构层去实现能够长程运作的“元学习”（Meta-learn）机制。 ### `10:00` Transformer 的经济学奇迹与小规模架构研究的局限 Jerry Tworek 深入剖析了架构扩展背后的深层经济学逻辑。理论上人们完全可以把 LSTM 扩展得非常庞大，只是当年没人敢真正往这个方向孤注一掷。在经典的缩放定律（Scaling Laws）论文中，研究人员将 LSTM 与 Transformer 进行了直接对比，结果显示 Transformer 的缩放表现从底层机制上就显著胜出。Jerry 设想，如果人类从未发明 Transformer，行业或许至今仍在不断扩充 LSTM 的规模：我们虽然也能得到某些可用的模型，但由于训练成本高昂得多、产品体验却逊色不少，根本无法换来足够的商业回报，也就不会有人愿意投入数以亿计的资金去训练那些庞然大物。Transformer 最宏伟的地方正在于它具备天然的经济价值——训练它的成本低于它所能创造的商业收入，这是机器学习历史上极罕见的“奇迹”，绝非任何架构与生俱来的权利。 回溯历史，在 OpenAI 之前，绝大部分学术界与产业界研究者对模型缩放持强烈抵触态度，甚至视其为“不讲究科学规范”的做法。当时主流算法研究的核心追求是“如何在相同算力预算下榨取更高的效率与更好的指标”；而 OpenAI 当年做出了一个极其叛逆的反向下注：不再执着于追求局部微调的高效算法，而是专注于寻找“具备超强可扩展性”的算法，坚信通过持续注入海量算力能够解锁更强的智能。尽管这一路线长期遭受整个 AI 社区的抨击，但正是这种偏执造就了如今的前沿模型格局。 Jerry 指出，学术界长期以来存在一个严重的盲区：绝大部分针对新架构的研究都发生在极小的数据集与极低的算力范畴内。很多人总想在微型算力环境下先证明某个架构有效，再去考虑规模扩展。但以强化学习（RL）为例，如果不达到一定的算力基线，模型根本无法展现出基本的通用能力——RL 必须建立在一定的 baseline 能力之上才能开始起效。同样的道理，世界上必然存在许多被低估的创新架构，它们必须在足够的算力基准之上，才能显现出真正的威力和惊艳特性。 ```mermaid flowchart TD accTitle: Transformer的经济可行性循环与架构研究的陷阱 accDescr: 对比了Transformer带来商业正循环的过程，以及传统学术研究在低算力下验证架构所面临的困境。 subgraph CommercialLoop ["Transformer 的经济学正循环"] T1["高扩展性架构 Transformer"] --> T2["大规模算力投入"] T2 --> T3["产出超越训练成本的商业收益"] T3 --> T4["持续吸引资金投入下一代 Scaling"] end subgraph AcademiaTrap ["小规模架构研究的困境"] A1["在微型数据与低算力下实验"] --> A2["未达能力涌现的算力基准线"] A2 --> A3["无法展现真正潜力而被过早放弃"] end ``` --- ### `12:30` 巨头实验室的季度内卷与初创公司的破局机会 面对“既然突破需要高算力基线，为什么不留在资源充沛的大型实验室，而是选择创立 Core Automation”这一尖锐问题，Jerry 坦言这完全是一个“时机问题（Timing issue）”。当今 AI 市场的竞争格局极为残酷，那些最顶尖、最成功的实验室正身陷有史以来最白热化的阵地战之中。当 Transformer 已经被证明具有丰厚商业利润，且通过持续堆砌资源扩充现有 Transformer 架构就能确保下一季度的财报与胜率时，实验室内部很难挪出巨大的算力与精力，去探索那些可能在两三年后颠覆整个领域的新架构方向。 在走访了几乎所有顶尖实验室后，Jerry 发现巨头们对寻找 Transformer 的替代方案兴致寥寥；而二线实验室则陷入了亦步亦趋的怪圈，全在模仿龙头企业的动作。“只要看看上周行业发布的成果，就会发现所有人都在同一时间抢着发布同质化的编程智能体（Coding Agent）。”这种全行业的同质化竞争给 Core Automation 留出了关键的生态位：与其在拥挤的赛道上重复造轮子，不如开辟全新的非 Transformer 路径。 - 顶尖巨头受困于短期季度业绩和极度白热化的市场竞争，无法下注可能颠覆自身架构的长远探索。 - 绝大多数追赶型实验室缺乏独立思考，陷入全员复制前沿实验室、扎堆抢发编程智能体的内卷。 - 探索下一代全新架构必须跨过高算力门槛，这一空缺恰好是 Core Automation 专注攻克的方向。 --- ### `14:48` Transformer 诞生的冷清现场与推理端算力浪费的本质 Rohan Anil 回忆起自己在 Google Brain 见证 Transformer 诞生的时刻。当时 Ashish Vaswani、Noam Shazeer 等人提出该架构时，Rohan 正在推进自己的在线蒸馏（Online Distillation）工作，双方在同一场 Google 内部学术会议上汇报成果。令人意外的是，Transformer 在 Google 内部最初并未引起轰动，多数人只当它是另一篇普通的研究论文而已，只有极少数人真正理解了它的价值。最初的论文目标非常具体聚焦——解决机器翻译问题，打败当时的虚拟端到端 LSTM（Tree-LSTM/GNMT）。直到 OpenAI 相继推出 GPT-2 和 GPT-3，整个行业才真正意识到 Transformer 结合语言模型缩放的巨大威力。 从底层算力分配的角度来看，Rohan 认为 Transformer 确实是一种高效消耗算力的方式，但当下的行业重心已全面转向推理期（Inference-time）算力，即持续消耗算力生成 Token。他认为目前必须将预训练与 RL 作为一个端到端（End-to-end）的整体来审视：目前的范式中，预训练构建了固定上下文窗口的 Transformer，而当强化学习介入并发现算力不足时，便粗暴地通过“一次只生成一个 Token”的思维链（Chain of Thought）来增加算力消耗。 从推理角度来看，逐个 Token 自回归生成的机制极其低效。行业为此发明的诸如推测解码（Speculative Decoding）等方案，本质上只是在给自回归缺陷缝补“创可贴”。正如当年整个行业花了整整两到三年才从超大稠密模型（Dense Models）痛苦摸索到混合专家模型（MoE）与稀疏激活，如今 Transformer 暴露出更根本的弊端：计算深度（Computational Depth）严重不足。一旦抛出“如何有效提升计算深度”这一命题，立刻就能在机制层面衍生出 20 种不同的全新改良路径。 --- ### `17:21` 全栈工程落地能力与打破“浅层计算”瓶颈 在 Rohan 看来，探索前沿架构往往需要五到六年的漫长周期才能在产业界开花结果。推动这一跃迁需要两个不可或缺的核心要素：第一是坚定的内心信念（正如 Jerry 坚信 RL 必不可少，而 Rohan 在 Google 时曾是一个极端的“预训练最大化主义者”，如今两人恰好互补）；第二是软硬件结合的工程落地能力。一个理论上看似最优的架构如果无法在真实硬件上极致高效地运转，对任何人都没有价值。从提出科研假设到编写高性能算子（Kernel），再到打通全流程生产化闭环，全行业目前只有极少数团队具备这种全栈集成能力。Core Automation 组建了一支打破学科孤岛的集成团队，让算法架构专家与底层算子工程师紧密配合、端到端地系统性解决问题。 ```mermaid flowchart LR accTitle: 理论架构落地的全栈闭环 accDescr: 展示了从科研假设到硬件算子编写、再到规模化生产的端到端软硬件闭环流程。 subgraph CoreLoop ["Core Automation 全栈研发闭环"] R1["算法与数学构想"] --> R2["底层高性能 Kernel 编写"] R2 --> R3["硬件算力极致优化"] R3 --> R4["大规模生产级部署验证"] R4 -. 反馈迭代.-> R1 end ``` Rohan 直言，如果任由行业自然演进，替代 Transformer 将会经历一个极其漫长且低效的过程。很多用户已经在抱怨日益高昂的 Token 成本。Rohan 带着在 Google 时必须服务数十亿全球用户的工程思维——必须在极其苛刻的延迟与吞吐预算内交付结果。当前的前沿技术即便继续单纯缩放，也依然昂贵到只能触及人类群体中的极小一部分；要打破这一限制，唯有彻底重构架构底层。 针对 Transformer “计算深度不足”这一核心问题，Rohan 给出了极其直观的剖析：尽管这门学科被称为“深度学习（Deep Learning）”，但实际上目前训练的绝大多数 Transformer 都极其“浅层”（Shallow），其物理层数至多只有 100 层左右。学术界虽曾尝试在物理上继续堆叠层数，却从未真正成功学习到极深层次的高维表征。目前行业所依赖的“思维链推理”与 RL 自主展开思考，本质上只是在模型推理路径中用序列时间换深度——每额外生成一个 Token，就相当于为网络追加了一条推理路径。然而，这种用长序列自回归强行模拟深度推理的妥协做法，正面临着越来越严重的算力瓶颈与表达上限。 - 物理网络深度瓶颈：主流前沿模型物理结构极浅，网络层数普遍停留在 100 层以内。 - 思维链的本质：一种通过逐个输出 Token 在时间轴上折叠、迂回增加计算深度的低效补丁。 - 普惠 AI 的鸿沟：现有架构的单位 Token 计算成本注定只能服务极少数高价值场景，必须依靠底层架构革新才能普及到数十亿普通用户。 ### `20:00` Transformer 的极限与“实验室闭环”的困境 当前预训练架构的计算量受到层数乘以序列长度（$Layers \times Sequence\ Length$）的刚性限制。虽然通过拉长序列长度进行推理期扩展（Inference-time Scaling）能够显著提升模型能力，但这种做法付出的代价十分高昂：模型必须逐个 Token 输出冗长内容来换取更好的结果。这种“逐 Token 推进”的方式在计算上极其低效，而这也正是他们目前正在专注解决的核心方向之一——让这一过程变得远比现在更高效。 针对 Transformer 架构究竟还能走多远、何时见顶的追问，Jerry Tworek 剖析了其能力边界。目前的范式是：通过预训练从全网数据中蒸馏人类已有知识，再通过强化学习（RL）将期望的工作流与推理模式注入模型。在理想的极限状态下，Transformer 可以是一个耗尽全球数据与天量算力训练出来的超级模型，掌握了人类所有知识及其组合关联，能够胜任所有具备训练数据的任务。然而，Jerry 提出了一个直击痛点的思想实验：“如果 OpenAI 和 Anthropic 今天起彻底停止训练新模型，数月或数年后会发生什么？” 答案是这个模型会变得越来越无用。即便实验室把全球人类的所有工作、任务与环境全都录制下来喂给模型，一旦现实世界发生改变——出现新事件、新因果关联、新任务类型、新代码库或新工具，Transformer 就会立刻受挫。Transformer 的全部价值依赖于其训练数据中必须包含这些高价值内容；它虽然具备极其微弱的适应力，但既不宽泛也不灵活。 ```mermaid flowchart TD accTitle: 当前 Transformer 模型的演进与局限闭环 accDescr: 展示了从海量数据蒸馏到遭遇新世界数据后必须重新依赖中心化实验室的死循环过程 subgraph LabTraining ["中心化实验室训练流程"] A["全网数据与任务流程"] --> B["预训练蒸馏 + 强化学习 (RL)"] B --> C["高能力 Transformer 模型"] end subgraph RealWorld ["现实动态环境"] C --> D["部署至真实世界"] D --> E{"世界发生变化？\n(新代码库/新工具/新事件)"} E -- "否" --> F["高效率完成已知任务"] E -- "是" --> G["模型表现急剧退化\n无法在测试期灵活适应"] G --> H["收集失败案例与新数据"] H --> A end ``` 这种模式的根本软肋在于，用户每一次遇到模型无法解决的新任务，虽然可以通过人工编写 Prompt 或提供精准调度来绕过，但真正要解决问题，必须把新失败案例加回到数据集中，依赖中心化实验室重新为你重训模型。“如果模型从根本上必须在实验室里更新，你究竟是想要这种模式，还是希望模型能够摆脱实验室、自主且灵活地完成在线更新？”这正是当前架构与终极通用智能之间最深的一道鸿沟。 - 推理期扩展（Inference-time Scaling）虽然有效，但受制于单 Token 串行生成的效率瓶颈。 - Transformer 的适应能力极弱，对动态世界（新事件、新逻辑、新软件生态）缺乏弹性泛化能力。 - 依赖实验室不断收集失败样例重新训练的“更新闭环”，阻碍了模型演化为真正自主的智能体。 --- ### `22:58` 经验学习的本质：超越强化学习（RL）的数学框架 谈及 Rich Sutton 与 David Silver 共同发表的著名论文《经验时代》（*The Age of Experience*），Jerry 明确指出：强化学习从来都不是新事物。它从早期攻克西洋双陆棋（Backgammon）、围棋（Go）、《星际争霸》（StarCraft）、《Dota》，一路演进到如今攻坚编程任务，本质上一直是模型生成自身经验并从经验中学习。相比之下，当今人们对预训练的批评不无道理——预训练只是行为克隆（Behavioral Cloning）、人类模仿与互联网数据压缩，甚至如今大部分互联网文本早已由 AI 生成，预训练更像是在用新模型蒸馏旧模型。 然而，Jerry 提出了一个发人深省的观点：**从经验中学习（Learning from Experience），绝对不等于强化学习**。强化学习只是一种特定的数学公式化表述。当前的强化学习极其依赖于通过海量并行 Rollout（轨迹展开）来进行方差缩减（Variance Reduction），并在多个平行的世界版本中进行横向对比，而这根本不是人类从经验中学习的方式。人类从单次经验中学习的效率比机器高出数个数量级。 Jerry 以人类大脑为例解释了两种截然不同的学习机制： 1. **踢足球式的运动学习**：踢很多次球，每次根据偏差进行细微调整，观察是否大致符合预期，伴随着自发性的强化信号——这非常接近强化学习； 2. **学习高阶数学概念**：阅读艰涩难懂的概念，在脑海中进行深层抽象思考，直到所有神经连接突然被“打通”（Click）并形成网络——这种经验学习与当下的大规模并行试错完全是两码事。 因此，虽然当前 AI 领域在经验学习（RL）上投入的算力创下了历史新高，但这绝非经验学习的终态，未来几年学术界与工业界必将孕育出更具突破性、能在更丰富语境下利用经验数据的全新算法。 --- ### `25:52` 优化算法与架构的共生：端到端整合预训练与 RL 被问及如何将学习算法的算力与数据效率提升数个数量级时，Rohan Anil 认为破局必须从**评估测量体系（Measurement）**重新做起。当前行业将预训练等同于数据压缩，盲目将困惑度（Perplexity）奉为圭臬，通过在对数尺度上堆砌参数与算力来换取极微小的指标改善（$\epsilon$ improvement）。但这只是建立先验概率的辅助手段，甚至是完全看反了问题的终极目标：“我辛辛苦苦训练出一个困惑度极佳的模型交给 Jerry，Jerry 做完 RL 后就会彻底摧毁我辛苦优化出来的困惑度指标。”当前的阶段只是一个起步（Bootstrap）过程，真正实现数量级飞跃的关键，在于把**预训练与强化学习进行端到端的深度融合**，将其重构为统一的学习算法。 ```mermaid flowchart LR accTitle: 预训练与强化学习割裂流程对比端到端联合流程 accDescr: 展示了传统脱节的流水线与端到端统一学习算法之间的效率差异对比 subgraph TraditionalPipeline ["传统割裂范式 (效率极低)"] direction TB T1["预训练阶段\n(以困惑度/压缩率为唯一指标)"] -->|算力指数级消耗| T2["强化学习阶段 (RL)\n(任务目标彻底破坏困惑度)"] end subgraph ProposedPipeline ["未来统一演进目标"] direction TB P1["预训练先验 + 目标导向强化学习"] --> P2["端到端联合学习算法\n(带来数量级的效率提升)"] end ``` Rohan 回顾了自己在优化领域的职业轨迹。2016 年他在 Google 针对逻辑回归进行优化研究，为大规模线性求解器 SIBL（在神经网络兴起前统治 Google 内部的基础求解器）编写算法，自此深陷优化理论的魅力中（"nerd sniped"）。当深度神经网络全面爆发时，他坚定地选择深耕网络训练算法。随后，Vineet Gupta 来到他的工位前，拿着在白板上推导出的 Shampoo 算法矩阵原型，邀请精通优化器编写的 Rohan 合作将其在超大规模神经网络上落地。 在 Google 任职直至 2024 年期间，这项工作得到了其主管 Yonghui Wu 的鼎力支持。然而在当时，业界对新型优化器充满冷漠与质疑，普遍认为“优化器用 Adam 就足够了，为什么不把时间花在优化器之外的事情上”。但 Rohan 坚持认为优化器正是模型优化的命脉所在。更深层的洞见在于：**模型架构（Architecture）与优化算法（Optimization）本质上是一枚硬币的两面**。过去十年深度学习架构上取得的大量演进，其真实目的都是为了让网络更容易被训练优化；一旦拥有了足够强悍的优化器，就必然能够解锁更加强大且完全不同的新型模型架构。 - 传统的预训练困惑度与 RL 对齐目标彼此割裂，导致了极高的计算资源浪费；端到端融合两者是突破计算效率瓶颈的必然途径。 - Rohan 早期主导 Google 内部大规模线性求解器 SIBL 的优化，后与 Vineet Gupta 合作将二阶优化器 Shampoo 扩展至超大规模深度模型训练。 - 深度学习社区长期依赖 Adam 并对优化器改进持保守态度，忽视了架构设计本质上是“为了迁就现有优化算法的可训练性”这一核心事实。 ### `30:00` 优化器与模型架构的共生关系、端到端学习与生物学习效率 Rohan Anil 深入拆解了优化器与模型架构之间密不可分的共生关系。在他看来，业界存在一种天然的权衡取舍：你可以用一个更强大、更先进的优化算法去训练那些原本极其难以收敛但表达能力极强的模型，从而取得更出色的上限性能；或者使用较弱的常规优化器去训练那些容易优化的模型，换取尚可的基线效果。Rohan 指出，他们在 Gemini 1.5 Flash 中成功运用了相关优化技术，随后社区也跟进推出了类似 Soap 优化器的论文，甚至衍生出了一整套以“洗浴用品”（Shampoo、Soap 等）命名的二阶/高阶优化器文献体系。然而 Rohan 坦言，哪怕像 Shampoo 这样的工具带来过约 2 倍的效率飞跃，它本身依然算是相当简陋的，根本没有充分利用训练过程中能够获取到的所有动态信息。 优化算法的革新不仅关乎训练收敛的速度，更在底层决定了人类究竟能探索出何种新型架构。Rohan 举例提到，残差连接（Residual Connections）固然是历史上训练深度神经网络的利器，但现在世界上有极少数（“可能全世界只有四个人真正在乎”）先锋研究者已经成功抛弃了残差连接，借助更优质的优化手段学到了更深层、更强大的表征。这也直接延伸到强化学习（RL）的高昂计算代价上：当前通过长链思维（Chain of Thought）解码数十或上百个 Token 来反向反刍仅仅“1 个比特”的信息反馈，算力利用效率极低。如果能将预训练与 RL 架构完全进行端到端优化，模型训练效率将迎来几个数量级的跃升。 面对主持人 Sonya Huang 关于“AI 能否达到或超越生物大脑的学习效率”的提问，Rohan 给出了极其明确的否定回答。他引用了深度学习先驱 Geoffrey Hinton 提出的“有限计算”（Mortal Computation）概念解释道：人类生物大脑在成长过程中是硬件与算法一体化演化建立回路的，肉体死亡，这些独特的回路便消亡殆尽；而人工神经网络则是硬件长期固定、权重强行复用，模型只能依靠极低效的大规模并行试错来吸收极其微量的信息。除非硬件底层发生颠覆性革命——比如走向极其先进的模拟计算（Analog Circuits）、彻底解决模拟电路中的误差校正与信息传递问题，否则人类在生物效率维度上“暂时是完全安全的”。 ```mermaid flowchart TD accTitle: Optimization and Architecture Co-design Flow accDescr: 优化器与模型架构的相互驱动关系，对比传统训练与端到端联合优化的计算效率。 subgraph S1["优化器与模型架构的选择权衡"] A["弱优化器 (如标准 Adam)"] --> B["限制于易训练的常规架构 (如经典残差结构)"] C["强优化器 (如二阶 Shampoo / Soap)"] --> D["解锁难以优化的高阶架构 (如去残差的深层表征)"] end subgraph S2["当前计算瓶颈 vs 理想范式"] E["当前 RL 机制: 长思维链仅换取微量反馈 (算力效率低)"] F["端到端联合优化: 预训练与 RL 融合 (释放数个数量级效率)"] E -.->|亟待进化为| F end ``` ### `33:04` 为何顶级大厂无法统一“预训练”与“强化学习” Sonya Huang 抛出一个直击行业痛点的问题：将预训练（Pre-training）和强化学习（RL）整合进行端到端优化，听起来逻辑上无比清晰自洽，为何全球顶尖的 AI 实验室至今没有这么做？究竟是被僵化的组织架构与团队流程所阻碍，还是另有隐情？ Rohan 剖析了两个核心根因。其一是数学与工程性质的截然不同：预训练面对的是庞大的数据批次（Large Batch）、高度确定性的环境以及吞吐极高的大规模计算并行；而 RL 则是从强先验出发，高度依赖环境采样探索（Rollouts），伴随着极大的随机方差。把这两种完全不同的优化范式天真地捏合在一起几乎必然导致崩溃，必须从全新视角重新推导数学基础。 其二则是严酷的商业现实与竞争环境。即使去询问顶尖实验室里的核心科学家，他们大多也会点头承认探索端到端联合优化大有可为，但在实际的排期优先级中它绝不可能排在最顶层。正如 Jerry Tworek 指出的那样，由于当前大模型推理生成的 Token 没有任何用户粘性，全球 AI 巨头陷入了高频发布周期的生死竞速，必须在每个发布窗口（Release Cycle）前拿出一代新模型以防被市场淘汰。在这样的高压生存环境下，团队根本不可能腾出哪怕半年的时间去沉下心做深度的前沿探索。 - **优化范式的割裂**：预训练侧重高吞吐、大 Batch 与稳定性；强化学习依赖高方差采样与探索，难以通过简单拼接实现融合。 - **发布周期的绑架**：模型产品缺乏原生护城河（“Tokens are not sticky”），实验室被迫疲于应对数月一次的发布考核，导致长线底层探索被长期边缘化。 ### `34:52` Core Automation 的哲学：用 AI 代理武装人类，重塑全栈深度学习研发 当行业领袖们（如 Sam Altman、Dario Amodei）不断鼓吹“AI 科学家”（AI Scientist）将彻底取代人类研究员时，Jerry Tworek 明确阐述了 Core Automation 独树一帜的建队哲学。他们成立最自动化实验室的初衷并不是要把人类完全踢出研发循环（Human-out-of-the-loop），而是要给予个体研究员“最大限度的主观能动性与赋能（Agency）”。Jerry 用人类工具的发展历程打了个生动的比方：徒步时人只能走微小的距离；骑上自行车就能大幅延伸脚步；开上汽车则能日行千里；农耕文明初期人类只能靠双手打理一小块田地，但有了现代农机之后，一个人就能经营广袤的农场。 曾在 OpenAI 领导 Coding 与早期 AI Scientist 探索多年的 Jerry 认为，当下基于大模型的编程代理（Coding Agents）彻底改变了科研生产力的基本面。与其在传统巨头尾大不掉的层级架构与陈旧工作流中修修补补，不如从零组建一家从第一天起就原生为自动化代理打造的精炼研究组织。Core Automation 的目标是重构整套深度学习技术栈，反思并重写底层每个算子与训练步骤。在全新自动化工作流下，研究员若能每天无摩擦地验证一个底层创新假设，就已经超越了过往传统大厂的迭代速率；未来随着自动化推进到每天 10 次甚至上百次实验验证，系统就能以极高的搜索速度自动筛选出真正管用的下一代网络范式。 - **工具杠杆论**：自动化不是消灭研究者，而是将研究者从执行繁琐细节中解放出来，类似于农夫掌握了重型机械，大幅扩充单位时间内的探索边界。 - **全栈原生重写**：从矩阵算子到底层优化机制全面重构，打破已有深度学习基础设施的条框限制。 - **极小团队的高密度输出**：通过深度集成 Coding Agent，团队以极具紧凑的人员编制，追求百倍于传统模式的假设探索与验证速度。 ### `37:32` AGI 的严谨定义：不依赖人类反馈的自我改良能力 当被问及“何时才能断定人类真正实现了 AGI”时，Jerry Tworek 深入剖析了他对这一定义的演进过程。他打趣道，过去人们常说“AGI 存在于每个人的心中”，不同人有不同的标准。OpenAI 官方给出的通用定义是“在最具经济价值的工作中超越人类的系统”，但 Jerry 提出了一个尖锐的反思：假设 OpenAI 现在立刻停止给模型喂新数据、停止人工训练模型，这套系统还能不能自我维系现有的自动化水平？还是会就此停滞？ 因此，Jerry 给出了自己的 AGI 判定硬核基准：“只有当模型能够在没有任何人类干预（Without human in the loop in any way）的情况下实现自我持续改良时，我们才能有意义地谈论 AGI 的到来。”自我改良 AI 模型本身就是一项极具经济价值的工作，因此这一定义在逻辑上天然属于通用人工智能定义的内核子集。 Jerry 坦言，现阶段人类距离这一目标还差得很远。回顾 2024 年乃至进入 2025 年以来的行业现实，几乎找不到任何现实生产任务能够把人类彻底剔除出闭环；大模型加上人类专家的“人机协作混合体”（Human-LLM Hybrid）取得了前所未有的惊人成功，但纯粹由 LLM 独立主导的闭环系统表现极其糟糕。这一残酷现实证明当前的主流范式（堆砌参数、加大上下文窗口、传统微调）根本通往不了终点，必须寻求颠覆性的新路径，核心就在于让模型具备在**测试期（Test Time）**能够进行更深层次持续自适应与动态学习的能力。 ```mermaid flowchart TD accTitle: Pathway to Genuine AGI accDescr: 展现从当前人机协同现状演进到具备自主持续学习改良能力的真 AGI 路径。 subgraph S1["当前行业瓶颈 (2024-2025 现状)"] A["传统 LLM 堆叠规模 / 上下文"] --> B["人类+LLM 混合架构大获成功"] A -. 难以实现.-> C["纯自治模型闭环: 极易崩溃/无法自适应"] end subgraph S2["真 AGI 的核心判定基准"] D["测试期动态深度自适应 (Test-time Learning)"] --> E["彻底移出闭环中的人类干预"] E --> F["AI 系统实现自主闭环持续自我迭代 (Self-Improvement)"] end B -. 核心能力缺失.-> D ``` ### `39:35` Core Automation 的破局切口与六个月路线图 对于 Core Automation 这个团队究竟在密谋何种宏伟蓝图，Rohan Anil 破除了外界诸如“盲人摸象”般的揣测，大方公开了公司未来半年的切入策略。 Rohan 强调，重新发明一种新模型架构绝不仅仅是坐在白板前证明它理论表现有多好，最核心的工程红线在于：它能否在物理硬件上高效、极其稳定地运转起来？更重要的是，它能否立刻派上用场，让 Core Automation 实验室内部的研究人员以及早期用户直接在日常研发中无缝使用？把新架构落实为生产级工具、并在内部研发迭代中实现自我驱动与闭环赋能，正是他们接下来半年的核心目标。 ### `40:00` 算力瓶颈与算子内核：打破硬件极限的 QR 分解竞赛 Core Automation 目前可以涉足许多技术方向，但团队清醒地意识到，最艰难却也最需要被彻底自动化的一环正是底层算子内核生成（Kernel Generation）。面对现存的 GPU 以及英伟达最新的 Blackwell 硬件集群，团队必须在上面完成大规模训练与推理。为了让全新的架构设想不再被底层算力所掣肘，必须打造出顶尖的模型，大幅缩短“产生突破性架构构想”到“让其以最高 TFLOPs 在 GPU 上满血运行”之间的开发周期。虽然现有的编程智能体配合资深工程师能够推进一部分工作，但现状依然极其严峻。 Rohan Anil 以 Core Automation 与社区 GPU MODE 联合举办的 QR 内核优化竞赛为例。QR 分解作为一项经典的线性代数算子，在 Shampoo 等二阶优化算法及众多科学计算场景中被广泛使用，其目标是在单个 B200 节点上实现极致性能。面对特定的矩阵尺寸，若直接调用官方的 cuSOLVER 库，虽然能获得一定的基准性能，但空间极其受限；即便普通人类工程师结合自动化搜索闭环，最多也只能实现大约 7 倍的加速。要想获得高达 60 倍（60x）的惊人提速，需要全世界最顶尖、仅有屈指可数两三位拥有极高审美与工程直觉的底层专家，带领编程智能体深耕整整四周时间。这意味着当前的前沿模型在应对底层高性能内核生成时，依然远远落后于顶级专家。 从算法本身来看，QR 分解甚至谈不上极其繁复：它本质上是由大约三个底层算子构成的流水线——操作特定面板（panel）、执行矩阵乘法、将其折叠回矩阵中，并周而复始。然而，如果将这样一道看似结构清晰的高性能优化难题抛给 Anthropic、OpenAI 或是 Gemini 的顶尖大模型，它们根本无法给出合格的解决方案，甚至可以说离解决该问题差了十万八千里。自动化生成这类极限内核，正是 Core Automation 打通新架构研发“内循环”（Inner Loop）的关键钥匙。 - **QR 内核性能提升阶梯**： - 基准表现：使用官方 cuSOLVER 处理特定矩阵形状。 - 人工基线 + 搜索闭环：获得约 7 倍性能提升。 - 顶级人类专家（全球约 3 人）+ 编程智能体协作 4 周：达到 60 倍（60x）极限性能。 - **前沿大模型的现状**：无论是 Anthropic、OpenAI 还是 Gemini，在面对 QR 分解等底层复杂 GPU 算子生成任务时，均完全不具备端到端攻克的能力。 ```mermaid flowchart TD accTitle: GPU Kernel Optimization Spectrum accDescr: Comparison of QR kernel performance showing the gap between current automated methods and elite human optimization. subgraph Baseline["基准与通用方案"] A["官方 cuSOLVER 库<br/>(基础运行效率)"] B["大语言模型直接生成<br/>(OpenAI / Anthropic / Gemini)<br/>无法独立解决"] end subgraph Intermediate["中阶搜索优化"] C["人类工程师 + 搜索循环<br/>获得约 7x 提速"] end subgraph Frontier["前沿极限突破"] D["全球顶级专家 (约3人)<br/>+ 编程 Agent 深度协作 4 周"] E["实现 60x 速度提升<br/>解锁全新算法空间与新架构"] end A --> C B -.->|当前断层| D C --> D D --> E ``` ### `42:47` 历史教训：算子束缚如何扼杀算法创新 被问及为何如此执着于底层内核（是否仅是为了追求单 FLOP 算力产出的最高智能水平）时，Rohan 回顾了自己过往深度参与的几项行业级重大项目，指出“算子编写能力不足”曾经无数次掐断了极具潜力的架构突破路线。第一个切肤之痛来自于二阶优化方法（Second-Order Methods，如其在 Google 研发的 Shampoo 优化器）。在 Google 这种量级的超大算力体系下，研发必须遵从严格的投资回报率：“如果你花费了 10 倍的算力，换来的仅仅是 2 倍的收益，这在工程上是绝对不可接受的”；相反，唯有把计算开销压到仅增加 20%，同时换取 2 倍的巨大收益，业务和基础设施团队才会全面买单。然而，二阶优化涉及诸多前所未见的数学算子，当时整个 Google 内部精通底层 XLA LLO（Low-Level Optimizer）底层代码、有能力把这些算子写到极致效率的仅有两个人——Rasmus 和 Peter Hawkins，而彻底跑通这些算子前前后后耗费了整整两年时间。 第二个案例则是 Rohan Anil 在 2020 年与同事共同提出的架构构想——用超大规模外部记忆替换 Transformer 的部分参数，即内部代号为 Ngrammer（N-gram 记忆网络）的研究。当时虽然在小尺寸模型上实现了内部落地，但在大模型训练中，该架构极度依赖对超稀疏数据的高速 Gather（聚集）与 Scatter（分散）硬件级加速。Rohan 当年甚至在疫情期间多次召集 TPU 硬件团队展开跨部门研讨，全力推动底层硬件改动以支持这一操作，然而预期的硬件加速支持最终石沉大海，未能落地。 最具戏剧性的是，就在类似探索因工程瓶颈搁置多年后，DeepSeek 在六个月前发布了他们基于 N-gram 嵌入的架构论文。DeepSeek 凭借出色的工程实现，用 Scaling Laws 证明了借助此类 N-gram 记忆可以有效替代 MoE（专家混合模型）。面对这个自己五年前就探索过的方向终于被友商完全验证并大放异彩，Rohan 感慨万千，但同时也由衷地为他们感到高兴。这段经历更加坚定了他的信念：如果无法自动化搞定最底层内核，机器学习的大片广阔状态空间根本无从探索。高悬的硬件性能天花板（Roofline）不仅决定了运行速度，更直接定义了新架构算法的生与死。当像 QR 分解这样的算子被提速 60 倍时，特征值分解（Eigendecomposition）等大量过去因过于昂贵而被放弃的算法空间将瞬间被重新激活。 - **Google 二阶优化器（Shampoo）落地挑战**：算力增幅必须严格受限（用 20% 开销换取 2 倍提升）；受制于当时全公司仅 Rasmus 和 Peter Hawkins 两人能编写对应 XLA LLO 底层内核，整体攻关历时整整两年。 - **Ngrammer 记忆网络构想（2020 年）**：尝试用外部 N-gram 存储替代模型参数，受制于 TPU 硬件对稀疏 Gather/Scatter 加速的缺失而难以在大规模模型上施展。 - **DeepSeek 的后续验证**：DeepSeek 最终成功发布了更精进的 N-gram 外部记忆方案，证明其能够作为 MoE 的有力替代方案并符合尺度定律。 ### `45:00` 终极目标：构建完全自运转实验室，寻找替代 Transformer 的新架构 在对话的尾声，Jerry Tworek 对 Core Automation 的长远使命进行了高屋建瓴的总结：Core Automation 的创立并非为了在现有范式下修修补补，而是要彻底打造能够“在部署中实时持续学习”（Continually learn and learn from deployment）的新一代智能体。Jerry 明确重申，Transformer 在本质架构上完全不具备持续学习能力，在现有框架上打补丁无法解决这一基因缺陷；因此，实验室唯一的根本任务就是寻找全新的架构，彻底完成对 Transformer 的范式替代。为了达成这一目标，他们必须打造世界上自动化程度最高的实验室，以远超任何竞争对手的速度在大规模上快速试验、验证并筛选新架构。 当被问及“如何在一片未知的汪洋中识别出那个真正超越 Transformer 的架构、何时才会迎来属于他们的尤里卡时刻”时，Jerry 坦率而富有诗意地分享了他的科研心法。在传统的科研流程中，成功通常体现为某张评估图表上出现了一条与其他方案截然不同、以奇异斜率翘起的曲线。但 Jerry 指出，当数据曲线真正被绘制出来时，往往已经是探索旅途的尾声了；在极具颠覆性的科研中，研究者早在数据浮出水面之前，就已经在直觉中明确了方向。Jerry 半开玩笑却又无比认真地说道：“我这辈子最棒的几张关键图表，早在它们变成真实数据之前，就已经清晰地出现在我的梦境中了。” Jerry 解释道，深度学习系统极其复杂精密，想要让新范式跑通，通常必须连续把五个极其微妙的关键环节全部做对，系统才会发生质的跃迁并最终拟合出预想中的完美曲线。对他们而言，检验这一突破的核心金标准极其纯粹：观察系统是否能在测试时展现出真实而有意义的长期环境适应能力。甚至在 Core Automation 内部，研究员们最核心的评估指标就是大模型能否接管他们每天的日常研发工作，让模型每一天都变得比前一天更擅长做一名 AI 科学家。 伴随着轻松欢快的笑声，Jerry 和 Rohan 描绘了一个极具科幻感的终极目标：如果哪天全体团队成员一起去放假一周，回来后惊喜地发现由自运转系统驱动的实验室居然独立产生出了更好的研究成果，那他们的应对策略就是“把假期延长两倍，再延长四倍，直到我们进入永久休假（Permanent Vacation）”。在一片欢笑中，主持人 Sonya Huang 和 Pat Grady 为两位开启新征程的顶级研究者送上了由衷的赞叹与祝福，盛赞他们过往对 AI 格局塑造的非凡贡献，并期待 Core Automation 在无人区中开辟出通向真正 AGI 的自动化研究新范式。 ## Notable quotes > `02:18` 取代 Transformer 的第一步，是深刻领会它究竟把我们带出了多远。 — Jerry Tworek > `05:00` 如果你在 2024 年问我什么时候能实现 AGI，我会斩钉截铁地告诉你：2025 年就是那一年，届时我们将解决一切。 — Jerry Tworek > `12:30` 只要看看上周行业发布的成果，就会发现所有人都在同一时间抢着发布同质化的编程智能体（Coding Agent）。 — Jerry Tworek > `20:00` 如果 OpenAI 和 Anthropic 今天起彻底停止训练新模型，数月或数年后会发生什么？ — Jerry Tworek > `20:00` 如果模型从根本上必须在实验室里更新，你究竟是想要这种模式，还是希望模型能够摆脱实验室、自主且灵活地完成在线更新？ — Jerry Tworek > `22:58` 从经验中学习（Learning from Experience），绝对不等于强化学习。 — Jerry Tworek > `25:52` 我辛辛苦苦训练出一个困惑度极佳的模型交给 Jerry，Jerry 做完 RL 后就会彻底摧毁我辛苦优化出来的困惑度指标。 — Rohan Anil > `25:52` 模型架构（Architecture）与优化算法（Optimization）本质上是一枚硬币的两面。 — Rohan Anil > `37:32` 只有当模型能够在没有任何人类干预（Without human in the loop in any way）的情况下实现自我持续改良时，我们才能有意义地谈论 AGI 的到来。 — Jerry Tworek > `42:47` 如果你花费了 10 倍的算力，换来的仅仅是 2 倍的收益，这在工程上是绝对不可接受的 — Rohan Anil > `45:00` 我这辈子最棒的几张关键图表，早在它们变成真实数据之前，就已经清晰地出现在我的梦境中了。 — Jerry Tworek > `45:00` 把假期延长两倍，再延长四倍，直到我们进入永久休假（Permanent Vacation）。 — Jerry Tworek ## Mentioned Jerry Tworek, Rohan Anil, Sonya Huang, Pat Grady, Sequoia Capital, Core Automation, OpenAI, Google Brain, Google, Anthropic, Strawberry 项目, Gemini, Shampoo, Codex, Claude Code, Transformer, MoE (Mixture of Experts), LSTM, Ashish Vaswani, Noam Shazeer, GPT-2, GPT-3, GPT-4, Rich Sutton, David Silver, 《经验时代》(The Age of Experience), SIBL, Vineet Gupta, Yonghui Wu, Adam, Gemini 1.5 Flash, Soap 优化器, Geoffrey Hinton, 有限计算 (Mortal Computation), Sam Altman, Dario Amodei, Blackwell, B200, GPU MODE, QR 分解, cuSOLVER, Rasmus, Peter Hawkins, XLA LLO, Ngrammer, TPU, DeepSeek ## 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 [Source](https://pscrb.fm/rss/p/traffic.megaphone.fm/CPUAI4789823358.mp3)

[2:18] Jerry Tworek: 取代 Transformer 的第一步，是深刻领会它究竟把我们带出了多远。 [5:00] Jerry Tworek: 如果你在 2024 年问我什么时候能实现 AGI，我会斩钉截铁地告诉你：2025 年就是那一年，届时我们将解决一切。 [12:30] Jerry Tworek: 只要看看上周行业发布的成果，就会发现所有人都在同一时间抢着发布同质化的编程智能体（Coding Agent）。 [20:00] Jerry Tworek: 如果 OpenAI 和 Anthropic 今天起彻底停止训练新模型，数月或数年后会发生什么？ [20:00] Jerry Tworek: 如果模型从根本上必须在实验室里更新，你究竟是想要这种模式，还是希望模型能够摆脱实验室、自主且灵活地完成在线更新？ [22:58] Jerry Tworek: 从经验中学习（Learning from Experience），绝对不等于强化学习。 [25:52] Rohan Anil: 我辛辛苦苦训练出一个困惑度极佳的模型交给 Jerry，Jerry 做完 RL 后就会彻底摧毁我辛苦优化出来的困惑度指标。 [25:52] Rohan Anil: 模型架构（Architecture）与优化算法（Optimization）本质上是一枚硬币的两面。 [37:32] Jerry Tworek: 只有当模型能够在没有任何人类干预（Without human in the loop in any way）的情况下实现自我持续改良时，我们才能有意义地谈论 AGI 的到来。 [42:47] Rohan Anil: 如果你花费了 10 倍的算力，换来的仅仅是 2 倍的收益，这在工程上是绝对不可接受的 [45:00] Jerry Tworek: 我这辈子最棒的几张关键图表，早在它们变成真实数据之前，就已经清晰地出现在我的梦境中了。 [45:00] Jerry Tworek: 把假期延长两倍，再延长四倍，直到我们进入永久休假（Permanent Vacation）。

[0:00] Jerry Tworek: The first step to replacing Transformers is appreciating deeply how far they were able to carry us. [5:00] Jerry Tworek: If you ask Jerry in 2024, when do we get AGI? I would say 2025 will be that year... Benchmark scores were going up, and did we also solve all the real-world tasks at that moment? Unfortunately not. [10:00] Jerry Tworek: Market is right now in a very specific place where the biggest and the most successful labs... are probably in the most competitive market fight ever right now, which makes them not very keen on trying different paths. [15:00] Rohan Anil: If the computational depth is poor, how do we increase computational depth? Just posing that question opens up like 20 new directions on how we can modify the mechanism. [32:30] Jerry Tworek: There are companies now competing for release cycles because tokens are not sticky, so it's much harder to do long-term research of six months in many of these labs in the environment they're in. [30:00] Rohan Anil: I do not think so... at least with the hardware we have, it seems pretty unlikely.

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