Transformer 之后，下一步是让模型在部署中继续学习 (2026)

单集信息

播客：Training Data
主持人：Sonya Huang、Pat Grady，Sequoia Capital
嘉宾：Jerry Tworek，Core Automation 联合创始人、前 OpenAI VP；Rohan Anil，Core Automation 联合创始人，曾参与 Gemini pre-training 并参与 Shampoo optimizer 的研发。1
集标题：Building the Automated AGI Lab: Core Automation's Jerry Tworek and Rohan Anil
发布日期：2026 年 7 月 29 日。2
原集链接：YouTube 官方视频

Transformer 还没有被淘汰，但 Jerry Tworek 和 Rohan Anil 已经不愿把下一轮进展押在「更大的 Transformer」上。他们在这集里反复强调，过去 6 年的主线已经把 pre-training 和 reinforcement learning 做到了很高的规模，下一处瓶颈更可能是架构本身，而不是继续给同一套 MoE 和 attention 加参数。1

先把 Transformer 说清楚

Jerry 的开场判断很容易被误读成「Transformer 已死」：

「The first step to replacing transformers is appreciating deeply how far they were able to carry us.」1

他的意思恰好相反。Transformer 已经解决了大规模预训练和大规模 RL，很多今天看起来像产品能力的东西，都建立在这条路线之上。问题在于，行业现在更习惯做两件事：让 Transformer 更便宜，或者让它更高效。Jerry 认为，少有人认真追问怎样让它变得更强、更有表达力。

这一区分很重要。压缩成本和提高上限不是同一个问题。一个架构可以在现有任务上越来越省钱，却仍然不适合需要持续适应、长期记忆和更深计算的任务。Core Automation 的出发点，就是把注意力从「怎样继续扩大规模」移到「规模之外还缺什么」。

模型为什么需要在测试时学习

两位嘉宾给出的现实背景是：模型在实验室数据上训练，部署后却要面对不断变化的用户、任务和真实分布。训练集和 benchmark 很难覆盖这些变化，模型如果只能在部署前完成学习，就会把大量适应工作推给用户或外部工具。

他们提出的方向是 test-time learning，让模型在测试阶段继续从用户、用户自己的数据和真实任务中学习。现有方案各有硬伤。in-context learning 数据效率高，但上下文规模很快触顶；fine-tuning 可以写入新信息，却容易遇到灾难性遗忘，而且每次更新的数据效率并不理想。节目简介把这个问题落到了一个熟悉的例子上：Codex 使用大约 20 分钟后就需要 compact。1

这不是在否定 context window 或 memory 产品，而是在问一个更底层的问题：如果模型每次都靠堆更多 token、反复读取外部数据来弥补结构缺陷，系统的学习过程会不会一直停留在临时记忆层？他们想做的是让模型把部署经验变成能力变化，而不是每次从头回忆。

Transformer 的另一块短板：计算深度

Rohan 把架构问题说得更具体：Transformer 的 computational depth 不够。很多实际训练的 Transformer 最多大约 100 层，在他看来仍然相当浅。模型当然可以通过 chain of thought 和 RL 生成更多 token，借此增加推理路径和计算量，但自回归解码一次只生成一个 token，效率会跟着下降。1

这解释了为什么 test-time compute 会同时带来能力和成本。多想一会儿，模型可能得到更好的答案；但如果「想」的物理实现是不断生成 token，系统就会以延迟、显存和推理费用为代价。speculative decoding 等方法能缓解一部分问题，却没有改变计算结构本身。

Rohan 还把 pre-training 和 RL 放在同一个优化问题里看。他不满足于只看 perplexity，因为 RL 可能让传统训练指标变差，却让端到端任务效果变好。Shampoo optimizer 被他举作过去改进优化方法的例子，约有 2 倍提升，但他仍认为现有训练流程没有用尽可获得的信息。1

为什么要从 kernel 自动化开始

Core Automation 的目标听起来很大：做「the most automated lab in the world」。但他们没有从一句泛泛的 AGI 宣言开始，而是把第一批工程问题落在 kernel generation 上。原因很现实：一个新架构如果只能停留在论文或慢速原型里，理论优势无法变成可用系统。

节目里提到一次在 B200 node 上进行的 QR kernel competition。人类加搜索循环先拿到约 7 倍提升；之后用 coding agents 持续 4 周、花费约 10 万美元，得到约 60 倍更快的 kernel。这个案例的重点不在「agent 已经能独立写出高性能 kernel」，而在于它暴露了当前系统的边界：即使有大量自动生成的代码，模型仍离稳定地产出这种级别的底层优化很远。1

所以他们的自动化实验室并不是把研究员从流程里删掉。更准确的说法是，把研究者从重复执行、编译、测试和调参中解放出来，让同一个人可以更快提出假设、筛选结果，再把有效想法推进到更大规模。两人谈到的节奏目标也带有明显的愿景性质：先做到每天至少一个实验，再尝试把频率推到每天 10 个，甚至 200 个。1

这集真正留下的问题

Jerry 对 AGI 的定义很窄：

「For me AGI is a model that can improve itself without human in the loop in any way.」1

按这个标准，今天的「LLM + human」已经很有用，但「LLM without humans」还差得很远。这个判断让整集节目没有滑向「下一代架构马上取代 Transformer」的宣传口吻。它更像一份研究议程：持续学习、计算深度、端到端训练，以及把想法变成高性能 kernel 的自动化，必须一起推进。

这也是这集最值得带走的地方。架构替代不是一次模型发布，而是一条从学习机制到硬件实现的长链条。只改变其中一环，系统可能得到更好的 benchmark，却不一定得到能在真实环境中持续变强的模型。

这集值得谁听

做模型架构、训练系统和 inference infrastructure 的人值得完整听：重点不是「Transformer 过时了吗」，而是 test-time learning、computational depth 和训练目标怎样彼此牵制。
做 coding agent 或 AI research tooling 的人值得听 kernel automation 部分：QR kernel 的 7 倍、60 倍和 10 万美元案例，比「agent 会自动做研究」更能说明现在的技术边界。
只想听最新模型发布消息的人可以跳过：这集没有 benchmark 榜单，也没有产品发布；核心增量是对下一代学习架构和自动化研究组织的判断。

Transformer 之后，下一步是让模型在部署中继续学习