学术殿堂属于野心家 —— MIT 新星 Alex Zhang
AI Engineer NYC 普通票最后召集！作为 Latent Space 订阅者的专属福利，前 30 位可领取30% 优惠码（仅限新票，不可退款）。两周后见！
虽然我们通常主要在播客上聊行业，但偶尔也会捧一把那位正在浮出水面的学术新星。在2024年，我们推介了Shunyu Yao，他后来在 OpenAI 打造了 Operator，目前担任腾讯首席AI科学家。在2025年，我们推介了Jack Morris，他随后联合创立了估值达$600m的 Engram，如今是持续学习领域的重要声音。
今年，我们很荣幸推介来自 MIT 的 Alex Zhang。
从 GPU 内核到KernelBench，再到递归语言模型、被误管的精英以及大规模多智能体集群，Alex Zhang 正在探索：当我们用原始系统包裹越来越强大的模型时，究竟遗留了多少潜力未被挖掘。
RLM 今年早些时候席卷了时间线：
alex zhang@a1zhang就像 2025 年从语言模型转向推理模型一样，我们认为 2026 年的关键将是转向递归语言模型（RLM）。 事实证明，如果允许模型把*自己的提示词*当作外部环境中的一个对象来处理，它们可以强大得多……
9:14 PM · Jan 2, 2026 · 2.03M Views247 Replies · 1.07K Reposts · 7.29K Likes
而且一个基于 RLM 的框架率先~解决了 ARC-AGI-3，比 OpenAI 的 Astra 还早：
Prime Intellect@PrimeIntellect隆重推出 Prime Agent： 一个用于编码和长时间自主任务、可自我改进的 RLM 框架。 通过程序化工具调用、上下文作为变量、多智能体消息传递以及可自我修改的框架状态，在节省 token 的同时保持强大的表达能力。7:34 PM · Aug 5, 2026 · 3.22M Views400 Replies · 840 Reposts · 8.17K Likes
而且直到今天，它还在影响一些比 RLM 意义更为深远的新研究：
Rulin Shao @RulinShao ❗️上下文管理的“苦涩教训”：赋予语言模型对上下文的完全控制权，优于人类设计的 SOTA！ 隆重介绍 🩵上下文语言模型（CLM）🩵- 原生自主管理上下文
- 将上下文视为文件
- 策略内置于 CLM 权重中，无需外部 harness
2026年9月30日 下午1:03 · 38.9万次浏览
82条回复 · 251次转发 · 1.94K个赞
我们将深入探讨 GPU Mode 与 AI 编写的内核（kernels）、研究品味、以及学者为何应敢于下注行业实验室不愿尝试的方向；GEV 及标准自回归语言模型的替代方案；作为组合式泛化器的 harness 理念。Alex 解释了 RLMs、上下文卸载、程序化子智能体调用、Prime Agent、持久性子智能体，以及为何未来的“语言模型”可能实际是一个简单界面下隐藏的隐形智能体蜂群。我们还讨论了 OpenAI 的大规模智能体实验、Kimi 蜂群、Sakana AI 的开放式研究、推测性程序化工具调用、能力过冲（capability overhang）、Neuralese，以及 Alex 认为下一个重大研究机会可能在哪里。
我们讨论了：
为何AI 生成的 GPU 内核仍为人类专业知识留下巨大空间
一条专家洞察如何可能替代海量的蛮力 token 搜索
为何博士生应下注那些初看平淡、怪异或无意义的研究押注
SWE-bench、RLMs、ReAct 和 Quiet-STaR揭示了关于研究品味的哪些信息
GEV 以及为何语言模型不必是非自回归的 text-to-text 解码器
为何Claude Code、Codex 和 Pi在结构上比表面看起来更相似
Harness 设计如何改善跨任务和领域的组合式泛化
RLMs：上下文卸载、代码执行、递归子智能体、共享内存
Prime Agent、持续运行的 harness 以及持久的智能体间通信
为什么未来你查询的模型背后可能隐藏着一个完整的群体或脚手架（scaffold）
OpenAI 的万智能体实验、1300亿输出 token 以及约 4000万美元等值的问题解决能力
为什么智能体群体的大部分可能都是浪费的搜索——以及为什么收敛依然困难
Kimi 与 OpenAI在多智能体系统上的不同路径
开放性、Sakana AI，以及在海量生成工作中寻找隐藏 gems
为什么当前前沿模型可能已经存在巨大的能力冗余（capability overhang）
推测性程序化工具调用以及将工具执行与生成过程重叠
英语、代码还是全新的“Neuralese”，究竟哪个限制了模型的推理方式
AI for science、快速迭代的 benchmark，以及 Alex 如何选定值得下注的研究问题
Alex Zhang
网站：alexzhang13.github.io
X（推特）：@a1zhang
时间戳
00:00:00 介绍
00:00:49 GPU 模式、KernelBench 与 AI 编写的内核
00:07:38 人类专业知识 vs. AI 暴力搜索
00:13:20 研究品味与豪赌
00:19:28 GEV 与重构语言模型
00:29:03 游戏智能体与 Harness 难题
00:31:01 为什么 Claude Code、Codex 和 Pi 如此相似
00:36:42 作为组合式泛化器的 Harness
00:44:24 详解 RLMs
00:52:01 Prime Agent 与持久性子智能体
00:57:41 现实世界中的 RLMs
01:00:30 OpenAI 群体与语言模型的未来
01:07:26 开放性与 Sakana AI
01:15:52 Kimi vs. OpenAI 智能体群体
01:20:06 能力冗余与推测性工具调用
01:28:19 Neuralese、未来研究与 AI for Science
文字记录
引言：Alex Zhang、RLMs 与 GPU 模式
Swyx [00:00:00]: 好的，我们今天在演播室请到了 Alex Zhang，估计大家最熟悉的是 RLMs，当然他还有其他几个身份。欢迎来到节目。
Alex Zhang [00:00:12]: 谢谢邀请。
Swyx [00:00:13]: 对，还有 GPU Mode，对吧？
Alex Zhang [00:00:15]: 对，还有 GPU Mode。
Swyx [00:00:16]: 你是 Mark Saroufim 引荐来的，不是谁都有这种待遇。
Alex Zhang [00:00:19]: 是的，我跟 GPU Mode 里的人都特别熟。
Swyx [00:00:23]: 嗯。
Alex Zhang [00:00:23]: 我们经常以各种方式一起合作，不只是局限在 GPU Mode 里。
Swyx [00:00:29]: 对，能跟不太了解的听众解释一下吗？它其实就是一个 Discord 社区，最早聚焦 CUDA Mode，后来范围扩大了一些。创始人是 Mark。
Alex Zhang [00:00:41]: 对。
Swyx [00:00:42]: 在我看来，它简直就像 PyTorch 团队的招聘管道。
Swyx [00:00:45]: 然后你离开了 PyTorch。
Alex Zhang [00:00:47]: 是。
Alex Zhang [00:00:49]: 对。我记得它大约创立于 2023 年，我还在读大学的时候。发起人是 Mark、Andreas 和 Jeremy Howard。最初就是一个专门教大家写 GPU kernel 的 Discord 社区，有讲座课程，基本就这样。我当时正在写 GPU kernel，所以很感兴趣。其实纯属机缘巧合，那时我在 Snapchat 实习，
从 CUDA Mode 到 GPU Mode
Swyx [00:01:22]: Rexis。
Alex Zhang [00:01:23]: 对，我对 Rexis 的工作感到挺无聊的。当时他们有个项目，想实现一篇叫 Infinite Attention 的论文，是 Google 的。
Swyx [00:01:35]: 对，我们在 Paper Club 里聊过这篇。
Alex Zhang [00:01:36]: 对，是的。我当时很感兴趣的是，能不能为它在 Snapchat 上编写专用内核。后来发现不太行，没怎么搞出结果，于是我就加入了 GPU Mode。当时它还叫 CUDA Mode，估计是因为法律方面的原因改的名字。我在那里认识了 Mark、Matei 以及社区里很多其他核心成员。后来 Mark 提出了一个叫 Popcorn 的想法，那就是你们现在看到的排行榜的前身。核心的直觉是，我觉得大家都觉得 GPU 编程和竞赛编程很像。我不想说它们技能可以完全迁移。
Popcorn、KernelBench 与 GPU 内核自动化
Swyx [00:02:17]: 你有各种约束条件，还得稍微搞点代码高尔夫。
Alex Zhang [00:02:19]: 没错。
Swyx [00:02:19]: 是啊。
Alex Zhang [00:02:19]: 对。其实大家常用的优化手段其实少得惊人，而且人们真正想优化的内核种类也没那么多。所以我们当时有个想法：就像 Codeforces 有数百万道题一样，如果你有足够的数据，在 GPU 代码上也能做到类似的事，那就可以规模化地自动化 GPU 内核开发。这对研究人员来说意义重大。我认为一个较大的瓶颈是……你看 Mamba，比如，他们发论文时得附带内核代码，否则你根本没法有意义地使用它。而且不是每个团队里都有一个 Tri Dao。所以我们对此非常感兴趣。KernelBench 也是由此衍生出来的，探索能否让 LLM 自动化 GPU 内核代码。我觉得那是一段非常有趣的时光，正好在我本科和读博之间。我在 GPU Mode 度过了很愉快的日子。现在我只是偶尔帮忙做个讲座，参与度没那么高了。而且我们一般也不像以前那样搞那么多比赛了。不过，我依然和那里的人保持很多联系。
Swyx [00:03:27]: 有一种友好的竞争关系吗？我觉得之前做这个的社区是 MLSys、MLPerf 那类
Alex Zhang [00:03:32]: 对。
Swyx [00:03:32]: 差不多是这个意思。它们之间存在友好的竞争吗？这有点像新一代的 MLPerf，还是怎么回事？
Alex Zhang [00:03:38]: GPU Mode 的一个优点在于它具备社区属性。很多讲座内容对初学者来说都足够简单，大家完全可以跟上进度、提出疑问。而且，竞赛并不是次要环节，参与者可以借此学习。我认为 MLSys 和 MLPerf 这类基准测试往往主要由严肃的实验室和公司参与，至少是认真在参加。至少这是我的理解，我可能说得不对。但我还发现，除了 GPU Mode，另一件令人兴奋的事是现在有越来越多的网站和从业者在举办竞赛。我想，应该有……
Alex Zhang [00:04:21]: 我记得有个网站叫 LeetGPU 之类的，就像针对 GPU 问题的 LeetCode。
Swyx [00:04:26]: 哇。
Alex Zhang [00:04:26]: 还有其他一些类似的平台，我们在 GPU Mode 上也见过不少衍生项目，这非常令人振奋。因为我之前对 GPU 编程感兴趣时，它还极其小众。我之所以感兴趣，是因为 Tri Dao 在普林斯顿大学做了一场讲座——他当时正在申请教职，现在已经是那里的教授了。2023 年左右，我听了他关于 FlashAttention 的演讲，心里想：“哇，这简直太酷了。”
Alex Zhang [00:04:56]: 我当时就觉得，所有人都应该投入去做这件事。要知道，当时 vLLM 等工具也刚出来，大家开始意识到我们该写算子了。但现在写算子已经成为常态，几乎是人人都在做。从某种意义上说，这个领域已经趋于饱和。
AI 编写的算子与验证缺口
Vibhu [00:05:11]: 对于想要入行的人，你有什么有趣的看法？我认为其中最大的新闻是 GPT-5.6 写出了更高效的算子，这可能让 Terra 和 Luna 的成本降低 80%。
Alex Zhang [00:05:24]: 是的。
Vibhu [00:05:25]: 另外我们还看到一些比赛，有人刷新了纪录，说自己搞了个自动化研究循环，而这些人根本没写过 kernel
Alex Zhang [00:05:34]: 对
Vibhu [00:05:34]: 完全没有 GPU kernel 编写背景，对吧？
Alex Zhang [00:05:36]: 是的。就拿 GPU Mode 排行榜来说，最近很多题目的解法几乎全是 AI 生成的。但你在排行榜上会注意到，有个叫 Gauners 的人，他是 GPU Mode 社区的常客。我们早就知道他是超强的 GPU kernel 写手。有意思的是，我们在这个排行榜上发现，他其实也用 AI 来辅助解题，只不过主要由他来写提示词、引导方向。我们发现他的 kernel 基本上是前十名里唯一一个在真实端到端系统中保持稳定的。这就引出了一个问题：GPU kernel 存在验证难题，这个我们早就知道，从 KernelBench 发布以来就一直有这个问题，大量 reward hacking 现象存在。而且 AI 生成的代码行数往往少很多，但……
Vibhu [00:06:33]: 对，我正想问，这个差距很明显吗，还是说……
Alex Zhang [00:06:36]: 是的，很明显。
Vibhu [00:06:36]: 好
Alex Zhang [00:06:36]: 这个差距非常重要。而且我觉得很有意思的是，擅长写 GPU kernel 这件事至今仍然很有 alpha。
Vibhu [00:06:44]: 也就是说，从验证到实际可用，中间还有一道鸿沟
Alex Zhang [00:06:45]: 确实有。而且这一点也适用于很多 AI 系统。比如最近那些数学证明的进展，并不意味着数学家就过时了。这些公司还是会雇数学家，不管是做数据标注，还是引导模型去解决问题。在这些领域有深厚的知识储备，依然很有 alpha。
Swyx [00:07:12]： 这是纯粹的知识，还是说还有更多的规划？是否出现了一种更有效的规划风格？
Alex Zhang [00:07:22]： 我觉得是两者的混合。也许你指的是这种直觉——
Swyx [00:07:27]： 类似那种东西
Alex Zhang [00:07:28]： 如何去解决问题。
Swyx [00:07:29]： 比如，我总是在画代码图。
Alex Zhang [00:07:31]： 是的。
Swyx [00:07:31]： 对吧？
Alex Zhang [00:07:31]： 对。
Swyx [00:07:31]： 然后，如果图中有我不理解的部分，我会一直研究直到弄懂为止。否则，是不允许的。
Alex Zhang [00:07:37]： 是的。
Swyx [00:07:38]： 对。
Alex Zhang [00:07:38]： 所以我认为，这是一种混合特质。那些懂得如何审视和解决问题的人，也知道如何利用 AI 来做这些事。因为你实际上扮演着一个极强的验证者角色。就像如果你知道该做什么，并且……我认为我们在这些 agent swarms 等事物中发现的一个规律是：当你对一个问题投入足够的算力时，你可以充分探索该问题的解法。但很多时候，你也许能在一件事上烧掉 1000 亿甚至 1 万亿个 tokens，但如果你引入一个了解该问题的人，他们可能会发现能让模型节省那一万亿 tokens 支出的方法。这里的趋势并不完全清晰，但我认为野外仍有大量我们想要解决的问题，我们无法总是倾向于投入尽可能多的算力。所有这些事物中，效率方面依然至关重要。
光速限制、内存与 Megakernels
Swyx [00:08:41]： 是否存在基于物理学计算出的理论正确答案，然后你只是逐渐接近物理极限？
Alex Zhang [00:08:49]: 是的。对于 GPU 内核，你需要计算它的上限。其实有时候这并不容易，具体取决于问题的复杂程度。比如矩阵乘法，估算“光速上限”——即最快内核的理论极限——就非常直接。而且，这种估算通常假设所有数据都从 CPU 或 GPU 的 DRAM 开始传输，诸如此类。这会让数值产生一些细微变化，但
Swyx [00:09:18]: 包括数据传输等开销，对。
Alex Zhang [00:09:20]: 对。但我想说的是，在很多情况下，我们甚至不确定是否真的能达到这个理论数值。这假设了完美的计算与数据传输重叠，但实际中总存在一些无法绕过的瓶颈。而实际上，我们写出的内核往往离这个理论值差得很远，远到毫无意义。
Swyx [00:09:43]: 是的。关键是速度吗？你当然也会关心内存，因为
Alex Zhang [00:09:48]: 嗯
Swyx [00:09:48]: 内存影响速度。你关心功耗吗？我们年度最佳嘉宾之一是 Geoff Dean，他曾说：“我实际追踪的是微焦、纳焦，甚至皮焦。”
Alex Zhang [00:09:59]: 是的，现在经常讨论到皮焦级别。
Swyx [00:10:01]: 皮焦。
Alex Zhang [00:10:01]: 是的。
Swyx [00:10:01]: 你关心这个吗？
Alex Zhang [00:10:03]: 我不太关心。
Alex Zhang [00:10:04]: 是的。我猜也许是因为我并没有那么
Swyx [00:10:06]: 但你这里的一切都关于速度，对吧？
Alex Zhang [00:10:07]: 这里一切都关于速度
Swyx [00:10:08]: 没人去计算皮焦。
Alex Zhang [00:10:09]: 但我想补充一点，这里有个前提要说清楚：速度可以指单个 kernel 层面的速度，也可以指更大问题层面的速度，比如 N10 模型。需要考虑的一点是——这也是为什么搞清楚“光速极限”到底指什么很重要——在讨论 kernel 时，我们总是默认所有数据都在 HBM 里，对吧？但你可以想象，对于端到端的模型，你可能希望牺牲第一步操作的速度，把数据留在缓存里供第二步操作使用。这类问题没法靠单独优化某个 kernel 来解决。人们把它叫做 fusion，也就是
Swyx [00:11:01]: Megakernel
Alex Zhang [00:11:02]: kernel fusion 问题。对，或者说 megakernel。它通常只在你受内存瓶颈限制的情况下才适用。不过这里还有个问题：随着模型越来越强，我们是不是应该直接去生成 megakernel？这真的是我们想要的方向吗？
Vibhu [00:11:20]: 你怎么看？
Alex Zhang [00:11:21]: 我觉得这非常难，因为你需要数据来做这件事。我在现实中还没见过任何一个例子，能够在没有任何样本的情况下，凭空掌握解决某类极难问题的能力。另外我觉得这可能没那么有意思的另一个原因是：在单个 kernel 层面，一方面它本身不那么复杂，另一方面你比较有把握认为单个 kernel 里没有太多结构可挖。但对于 megakernel，我更倾向于相信编译器会做得更好。在更高层级的 op 之上做编译是合理的，因为实际上 megakernel 的各个组成部分就是由单个 kernel 非常自然地组合起来的。虽然有些场景下你可能需要做一些奇怪的融合，但总体上这类问题编译器应该能处理。据我所知，已经有一家公司在做这件事，他们也在 GPU mode 上做过几次分享。
Swyx [00:12:28]: 是的，我打算把关于 GPU 模式的所有讨论集中在这里，因为显然还有其他部分需要继续讨论。
Alex Zhang [00:12:32]: 没错。
Swyx [00:12:32]: 我们得继续往下聊。
Vibhu [00:12:33]: 我觉得有个内容值得推介。你们主讲了很多非常棒的课程，这些都在 YouTube 上，大家可以去关注。而且你们
Alex Zhang [00:12:39]: 是的
Vibhu [00:12:39]: 主导了其中很大一部分，你依然非常投入。
Alex Zhang [00:12:41]: 以前是的，有时现在也会参与。我觉得主要是 Mark 在做，他通常负责这些。Matei 偶尔也会讲，但不管怎样，我强烈推荐这些课程。它们是极好的资源。我觉得人们在那里分享的内容数量令人惊叹，确实如此。
Swyx [00:12:59]: 因为如果你在那里，你完全就是目标受众，对吗？
Alex Zhang [00:13:03]: 是的，完全正确。
Swyx [00:13:03]: 这类内容不会触达大众市场。
Alex Zhang [00:13:04]: 我们也发布了很多入门级材料，我觉得这对大家很有用。
Benchmarks, Princeton, and Research Taste
Swyx [00:13:10]: KernelBench 很有影响力。我只是想知道，那是去年的事。
Alex Zhang [00:13:13]: 是的。
Swyx [00:13:14]: 还有哪些正在进行的工作值得大家关注？因为显然你深耕这个
Alex Zhang [00:13:20]: 是的
Swyx [00:13:20]: 领域。
Alex Zhang [00:13:20]: 是的。我想分享一下背景故事，我实际上参与了很多 benchmark，或者说是以前参与。这始于我在普林斯顿的时候，我与那里的 SWE-bench 团队合作。
Swyx [00:13:33]: John, Carlos
Alex Zhang [00:13:33]: John, Carlos
Swyx [00:13:34]: Ofir
Alex Zhang [00:13:34]: 还有 Ofir。他们都很好。
Swyx [00:13:36]: Karthik
Alex Zhang [00:13:36]: 我很喜欢他们。是的。
Swyx [00:13:37]: 基本上，我觉得很多人没意识到，基准测试大多出自同一群人。
Alex Zhang [00:13:42]: 是的。
Swyx [00:13:42]: 也就是普林斯顿的那群。
Alex Zhang [00:13:44]: 太疯狂了。
Swyx [00:13:45]: 做 Xun Yu 的人是谁？
Alex Zhang [00:13:45]: 对，没错。
Swyx [00:13:46]: 我们之前还请他上过节目。现在他好像负责腾讯云了。
Alex Zhang [00:13:48]: 对，他现在是位明星人物。我认识他时，他正在指导我的朋友 Michael Tang，后者现在在 Anthropic 工作。两人当时合作很多。我们当时都是 Karthik 实验室里的本科生。我……后来也有其他人加入。总之，Xun Yu 很棒。我直到离开之后，才知道他这么有名。
Swyx [00:14:12]: 嗯。好吧，所以读博的人很少。像你这样的，下一个大概要隔一年。比如我们常提到的一些人，整个博士生涯都非常顺利。
Swyx [00:14:25]: 这样的人才不多。Xun Yu 显然是其中之一。Jack Morris 也是。节目开始前，我们还聊到了“研究品味”。
Swyx [00:14:33]: 对吧？有些博士生天生拥有一段顺风顺水的职业生涯，基本……对，确实如此，他们的方向会持续保持相关性，所有人都应该了解这些。
Alex Zhang [00:14:42]: 是的。
Swyx [00:14:42]: 而其他人，则什么都没做出来。
Alex Zhang [00:14:44]: 我觉得工业界实验室里的情况也是如此。只是博士生的可见度更高。所以你就能看到，有些人……
Swyx [00:14:56]: 是的，你可以发表论文Alex Zhang [00:14:57]: 有些人是运气好，或者说是运气和聪明兼而有之。我觉得研究品味也是这样，至少就我而言，它是在各种机会中慢慢培养出来的。我很幸运走了现在这条路：先在普林斯顿工作，后来在 MIT 遇到了 Omar，他是一位特别好的导师。不过我想说，研究生或者说学术界最成功的那些研究，往往出自那些关注工业界大多数人没在研究的问题的人。很多研究生的问题是，他们做的事情是为了让工业界实验室看得上眼，比如去刷某个当下很火的 benchmark。2023 年的 benchmark 和现在的 benchmark 已经完全是两回事了。现在很多人在做 harness、meta-harness，还有针对各种具体任务的 harness。但你认真想想，大家做这些的原因，无非是围绕现有的模型定了一个清晰的目标，想着“我就想看到这个结果”。我拿 RLM，也就是 recursive language model 那篇论文来举例吧，因为它的想法其实非常简单。刚发布的时候，很多人看到就问：“这东西到底有什么用？”
Swyx [00:16:27]: 或者觉得太玄乎了。
Alex Zhang [00:16:28]: 对。就是“这算什么？这不就是 subagent 之类的吗？”
Alex Zhang [00:16:32]: 我认为，当你看到这种反应时，这其实是个好兆头，因为它表明人们并未真正思考这项工作的核心价值所在。我再举一个 SWE-bench 的例子。Ofir 很喜欢讲这个故事：SWE-bench 刚发布时，根本没人理会。大家都觉得“这是个不可能完成的任务，为什么要把它当作基准呢？”直到 Devin 出现后，大家才意识到，“哇，这是值得我们投入资源去攻克的高地。”我认为这种现象在许多思想中都很常见。我印象最深的是 Eric Siegelman 关于 STaR 和 Quiet-STaR 的工作。读那篇论文时，至少是我第一次读的时候，会觉得：“这难道不是显而易见的想法吗？”或者也可能并非如此，我不确定，我当时只是觉得：“哦，这看起来很简单。” Chain of thought 也是如此，ReAct 也一样。大家都会说：“好吧，确实如此。”但如果你深入思考这篇论文的价值在哪里，会发现它其实在讲述一个关于该领域未来愿景的故事。在学术界，做到这一点非常困难。如果你看看 Quiet-STaR、ReAct、RLMs、SWE-bench 这些论文，它们并不像 GPT-6 那样的大型发布，不会让所有人惊呼：“天哪，我马上要用它，这是世界上最好的东西。”目前学术界还无法承受这种代价。虽然我认为有很多理由支持改变这一现状，但对于博士生来说，你处于一个非常独特的位置：你基本上可以研究任何你想研究的东西。如果你没有利用这一优势，而是去研究那些没人关心或被视为理所当然、甚至被认为“我虽然想过，但根本用不上”的事情，我认为最终的研究成果绝不会特别有趣。因为在学术界，你必须敢于下大注。否则，不如去工业界的实验室。那里拥有大量资源和人才。为什么要把自己局限在一个资源有限、周围也没多少人的领域呢？归根结底，就是关于下大注。你必须敢于下大注，其中很多会失败，这是自然的。但我认为
Alex Zhang [00:18:55]： 也就是说，作为博士生，你相比其他实验室的任何单个人最大的优势在于，你不需要应对官僚主义和其他种种杂务。
Swyx [00:19:07]： 也有道理。
Alex Zhang [00:19:07]： 对。
Swyx [00:19:08]： 我常问很多人这个问题，他们通常都敷衍了事。但我认为，我很欣赏你给出了一个深思熟虑的回答，指出这是你的不对称优势，因为其他因素基本上都对你不利。
Jev 与打破自回归解码器范式
Alex Zhang [00:19:20]： 是的，完全正确。说实话，我想以 Jev 为例，因为它并非一个学术
Swyx [00:19:26]： 哇，好的。
Alex Zhang [00:19:27]： 它不是一个学术项目。
Swyx [00:19:28]： 是的。
Alex Zhang [00:19:28]: 我想提这一点，因为 RLM 也遇到过同样的问题，很多其他工作也是。就是东西被过度炒作之后，人们又会说“这有什么好炒的？这不就是平平无奇的东西吗”。Jev 发布的时候我也看到了类似的情况。发布方虽然不是学术团队，但做研究总得做品牌、做宣传，这我能理解。不过当时确实有很多讨论说 Jev 不过是我们多年前就知道的东西。我觉得这种说法没抓住重点：为什么这样的系统这么有意思？它为什么不是一个我们在机器学习入门课上早就做烂了的普通 NLP 分类器？我觉得 Jev 真正有意思的地方在于，它打开了一个新问题：语言模型的形态一定是对的吗？除了文本到文本，我们能不能探索别的设计空间？因为它本质上是在说：“我要利用这个语言模型 backbone——我知道它捕获了大量语言信息——但我要改变模型的输出空间，换来的代价是极快的推理速度。”比如说你对问题已有先验知识，只需要做个二分类，那你会让语言模型去干这个活、付 400 倍的成本吗？不会，那就太傻了。而且长期以来，因为只有大实验室掌握着最好的模型，你永远只会用 GPT-4、GPT-6 或 Fable 这类最强模型。也正因为如此，大家已经习惯了一个观念：语言模型就是一个自回归 decoder。我们默认接受了这一点。RLM 出来的时候也是一样，我最常收到的批评就是“这不是语言模型”，或者“我以为是什么新架构，结果不是”。我的回应是：语言模型就是给语言建模，它不一定要是 Transformer decoder。Jev 特别有意思的一点就在于，我们现在有了一种新的……
Alex Zhang [00:21:49]: 需要调节的一个方面，即输出空间是什么样的，以及这对推理延迟有何影响？我认为我们甚至开始能针对语言模型本身的各个部分提出这个问题。在 Loop Transformer 上我们也看到了类似现象，当时很多人围绕它的关注度很高，但反应像是：“这想法太傻了吧”、“为什么？谁在乎这个？”。但这其实是个简单的想法，却开启了全新的一系列问题。我觉得，尤其是对于博士生来说，这些正是你们想要回答的问题。因为归根结底我们对此一无所知。以 Jev 为例，我们不知道能走多远；对于 Loop Transformer，我们也同样不知道上限在哪里。如果只循环模型的一部分会怎样？如果路由到模型的特定部分会怎样？比如设一个路由器将请求分发到模型的不同部分？你能否在模型内部模拟 Harness 的行为？Harness 的选择和模型架构的选择之间能打通什么联系？像这样的工作带来了这些问题，让我觉得非常兴奋。特别是 Jev，看到它的时候，我觉得“这对 RLM 真的很有用”。我觉得很有道理，因为 RLM、Swarm 或类似系统最大的瓶颈就是慢。当你总是进行多次语言模型调用时，你的算力分配并不合理，因为也许有些任务很简单，本来可以用简单的模型处理，但你的语言模型是个笨重的东西，你无法灵活应对。所以我非常期待。我认为除了标准的前沿模型，我们将开始看到新类型的模型出现，在这些模型上可以做很多事，例如探索新的权衡。
Swyx [0023:34]: 我还要特别提到 Thinky 及其交互式模型。
Alex Zhang [00:23:36]: 是的。是啊。另一个很好的例子。
Swyx [00:23:38]: 对。基本上就是试图打破“从序列到序列”、纯解码器的范式，尝试做任何其他事情。
Alex Zhang [00:23:46]: 是的。
Vibhu [00:23:46]: 我觉得，如果你试图竞争，你无法与做自回归生成（autoregressive）的前沿实验室竞争。
Alex Zhang [00:23:54]: 不。
Vibhu [00:23:54]：解码器开着。就...他们投入的计算资源规模...嗯，甚至 Thinky（一家新兴 AI 实验室）可能都达不到这个量级。好吧，可能 Thinky 是少数几个能做到的实验室之一，但即便如此，你也没法靠这点资源做出什么了不起的进展。
Alex Zhang [00:24:06]：我对 Thinky 了解不多，我也不想妄加评论。但问题是，如果他们的策略仅仅是复制 OpenAI 或 Anthropic，那这将是一个糟糕透顶的策略。
Alex Zhang [00:24:15]：因为...你看，你得去想，你手里到底有什么优势？如果你打算用同样的架构，我确定他们不会这么做，但假设你真的要照搬同样的方案，那本质上你就是在拼自己可控的要素：数据和算力。显然，在这些方面他们无法与前沿实验室（Frontier Labs）抗衡。所以，这也合乎逻辑——如果你是一个新兴实验室（Neo Lab），实际上，我也不确定是否该把 Thinky 归类为新兴实验室，但总之...
Vibhu [00:24:40]：是啊。这就是为什么他们在这个榜单里。
Alex Zhang [00:24:42]：我猜他们的情况确实有点特殊。
Vibhu [00:24:43]：他们在榜单上。而且他们已经发布了 Inkling。就像...他们没法...
Alex Zhang [00:24:46]：除了 OpenAI 或 Anthropic，也许还有 Meta 和 GDM，剩下的你就得做些别的了。现实确实有点残酷，但我认为这其实是件好事。我非常高兴看到规模化（Scale）策略行之有效，这些公司会继续这么做，因为这让一些新的玩家有可能入场——如果它们能发现什么真正有趣的东西。因为我其实怀疑前沿实验室是否会认真对待这种探索，因为为什么它们要冒这个险呢？为什么要将大量算力分配到新的赌注上，当旧的赌注已经在起作用时？因此...
Vibhu [00:25:24]：我认为这就是为什么很多新兴实验室会分裂出来，对吗？
Alex Zhang [00:25:27]：是的。
Vibhu [00:25:27]：你有一个侧面的假设，但没有算力支持，于是你就像...
Alex Zhang [00:25:30]：是的。
Vibhu [00:25:30]：“好吧，我这就去干这件事。”
Alex Zhang [00:25:31]：确切地说是这样。
Vibhu [00:25:31]: 你说的潜在上行空间，例子就是类似 Jev 这样的东西——便宜几百倍，一出来，可能就是新的语言模型。
校准、快速分类与新模型的取舍
Alex Zhang [00:25:41]: 是的。
Vibhu [00:25:41]: 这种情况下，情况就完全不同了。
Alex Zhang [00:25:42]: 对。
Swyx [00:25:43]: 是啊。
Swyx [00:25:44]: 那 Jev 到底是什么，就没有人猜一下吗？
Alex Zhang [00:25:46]: 我倒是有些猜测。看到有人说“哦，是个 diffusion 相关的东西”。
Swyx [00:25:56]: 就是并行解码那种，对吧？
Alex Zhang [00:25:58]: 对，并行解码。说实话，不管它到底是什么——我已经看到一些开源复现了——他们的工作真正让我兴奋的地方在于，我完全不清楚他们的优化目标是什么、是怎么训练出来的。这一点和我们在 RLM 上思考的问题很像：RLM 这个想法本身非常简单，论文一发出来谁都能用。但 RLM 的真正价值，取决于你能不能把它训练好，能不能围绕这个系统设计出合适的架构让它变得真正强大——这也是我现在正在做的方向。而对他们来说，他们找到了训练这套系统的方法，这绝对不是件容易的事。我真的不知道他们是怎么做到的。网上有些人声称他们用的是 Qwen，或者在 Qwen 的基础上做了 post-training，但你用任何开源的 Qwen 版本效果都会更差，因为他们的训练方法显然非常有效。所以这一点非常令人期待。
Swyx [00:27:04]: 关于校准，这是一个很少有人了解或真正理解的稀有话题。我们之前与 Hugging Face 的 Clementine Foley 交谈时曾讨论过这一点。她过去负责 Hugging Face 的评估工作，核心概念在于，模型旨在输出最可能的下一个 token。因此，当你问它们“你有多确定”时，它们实际上是在“撒谎”。因为它们给出的只是最可能的下一个答案，而不是真正的概率校准，比如“我百分之五十确定”或“我百分之二十确定”，并尝试对这些概率进行校准。我认为，围绕这一点生成合成数据其实相当容易，因为你可以通过查看真实答案，然后合成生成一批回答，让模型进行分类，最后再与地面真值（ground truth）进行比较。
Alex Zhang [00:27:52]: 哦，我明白了。
Swyx [00:27:52]: 这就是我对这件事的逆向工程思路。
Alex Zhang [00:27:54]: 是的。
Swyx [00:27:54]: 实际上，我认为校准被严重低估了。人们只是把它当作一个极快的分类器使用，但他们甚至没有利用其概率或校准估计值。
Alex Zhang [00:28:04]: 是的。
Vibhu [00:28:04]: 我想再次强调，人们对此仍有误解。当你问一个模型“你有多确定”时，它可能会吐出“百分之四十三”这样的数字。巨大的区别在于，这是否是一个基于事实依据的分类（grounded classification）？
Alex Zhang [00:28:16]: 是的。是的，我非常期待看到人们如何利用这个模型。它会解决所有问题吗？当然不会。但我想它解决了一类我们传统上难以处理的问题，即低延迟场景。所以我非常喜欢关于游戏的例子，那实际上……
Swyx [00:28:34]: 是的，毁灭战士（Doom）的例子
Alex Zhang [00:28:35]: 是的
Swyx [00:28:35]: 确实非常好。
Alex Zhang [00:28:35]: 我做了一个语言模型玩电子游戏的 benchmark。我一直很着迷的问题就是，能不能让智能系统去玩它没见过的游戏，类似这样的东西。所以我觉得他们那种独特的做法特别酷——用一个速度非常快的模型来捕捉语言和理解能力。
语言模型玩电子游戏
Vibhu [00:28:59]: 哦，正好聊到这个话题，关于电子游戏你有什么想分享的吗？
Alex Zhang [00:29:02]: 哦，有。
Vibhu [00:29:03]: 你是不是给某个项目做过 benchmark？
Alex Zhang [00:29:05]: 对，做过。不过那些数据已经很过时了。
Vibhu [00:29:08]: 嗯。
Alex Zhang [00:29:08]: 因为现在很多模型都大不一样了。而且我确实看到有人在用更新的模型跑这些游戏，挺有意思的。这个 benchmark 的大致思路是：想看看视觉语言模型在把延迟约束也算进去的情况下，能不能直接接入游戏并且玩得够好。因为这个其实——我是紧跟着 Claude Plays Pokémon 发布之后做出来的。
Alex Zhang [00:29:33]: 所以那大概是两年前的事了，现在来看算是远古时期了。不过我觉得这套任务有个很棒的地方：游戏种类非常多样。而且大部分游戏都是大家知道或者见过的。我看到了，对，Jeff 在玩 Doom。不过说实话，我觉得他们玩的应该只是些很简单的关卡。而且坦白讲，大部分模型到现在还是玩不了这些游戏——或者说，我认为没有任何模型能真正意义上通关这些游戏。当然有些游戏是可以的，我好像见过 Astra 能通关 Kirby 那个游戏。另外，我们做这个 benchmark 的时候，刻意设计了一个非常精简的 harness。关于 harness 这个话题我后面还会展开，因为这里面其实大有可谈：harness 的价值到底是什么？给模型配 harness 的目的又是什么？但总的来说，我希望能很快看到所有这些游戏都被新一代模型通关。
Vibhu [00:30:35]: 对，挺有意思的。比如那个老的 Cloud Place Pokemon，他们直接从 RAM 里读状态，判断哪些地块可以走之类的。我们很久以前和他们做过一期播客。
Alex Zhang [00:30:45]: 原来如此。
Vibhu [00:30:46]: 嗯，挺好玩的。
Swyx [00:30:46]: 对，类似。Jeff 没有视觉能力，
Alex Zhang [00:30:48]: 是的
Swyx [00:30:48]: 所以你得把信息喂进去，
Harness 是组合泛化器
Alex Zhang [00:30:50]: 对
Swyx [00:30:50]: 比如游戏状态之类的。那我们直接聊聊 harness 这个话题吧。
Alex Zhang [00:30:54]: 好啊
Swyx [00:30:54]: 反正是你提的。语言模型的 harness 就是组合泛化器。
Alex Zhang [00:30:59]: 没错。
Vibhu [00:31:00]: 你刚才读这个词还挺费劲的。
Alex Zhang [00:31:01]： 解释一下。是的，好吧。我对人们如何看待 harness（执行框架/驱动层）感到些许不满，因为大家总是把不同的 harness 拿来比较，比如：“哦，我更喜欢 Claude Code，或者 Codex，还有 Pi。” 又比如：“不，我喜欢 Oh My Pi 或 Prime Agent。” 老实说，我认为它们本质上都是一样的。这些 harness 背后的大多数设计决策或选择都如出一辙。也许 Prime Agent 有点不同，因为它本质上是一个 RLM。但总体而言，我认为我们在 harness 的设计上可以更具创造性。 这么说吧，如果我们从 harness 究竟为模型做了什么这个角度去思考，会发现一个核心问题：当你试图解决难题，并想利用语言模型来处理这些极其复杂的任务时，我们发现下一词预测（next token prediction）其实是一种非常笨拙的形式，难以应对此类任务。以 SWE-bench 为例，当你在浏览代码库时，你能指望通过单次语言模型调用就搞定所有事情吗？你只是说“解决代码”或“解决这个代码库中的查询”，肯定不行。所以我们依赖 harness 来辅助完成这类工作。 我认为有趣的一点在于，harness 其实是一个非常具有观点性的程序，它决定了如何让你将语言模型适配到特定问题上。我提出这点，是因为当我们思考 harness 的作用时，应该真正去审视：harness 中的哪些选择让语言模型得以解决这个任务？我是否可以直接使用一个仅执行此操作的模型？因为考虑到 harness，且既然循环 Transformer（loop transformers）已经成为现实，我觉得非常有趣的一点是，你实际上可以通过 harness 以某种方式模拟循环 Transformer。你只是在循环调用模型。虽然你现在可以说“哦，我不是在解码”，这略有不同，但总体而言，出于某种原因，我们长久以来一直固守着同一套模型架构选择。 关于为什么要这样做有很多争论，但很明显，我们现在正围绕着 harness 的 rollout 来训练模型。因此，在 harness 上进行训练存在一种非常别扭的方式：我们训练语言模型在 harness 内行动，但现在这变成了一个非常漫长的过程，甚至是多智能体 rollout。而目前实现这一点的方式非常别扭且充满权宜之计（hacky）。 这篇博客讨论的核心观点是：如果 harness 基本是在帮助模型解决特定任务，那么不同的 harness 设计选择是否能在“这里有一些工具调用可以帮你，这是通过 grep 搜索代码库的方法”之外，做出更具意义的贡献？实际上，这个博客的想法也与 RLM 的概念同时诞生，只是我们没有那样包装它。我认为这是事实，还有许多围绕 RLM 的其他理念，我们将来会陆续发布，但它们在最初就已存在，全都是关于设计决策的思考。 我喜欢 RLM 的一点是，在我感兴趣的许多抽象概念迭代和版本中，RLM 最终显得最合理。尽管有一些未公开的原因解释为何如此，但大家会看到。在这个例子中，我们发现使用 RLM 的一个特性是：如果你充分卸载上下文（offload context），并要求模型基于该上下文编写代码，你会获得一种奇特但有用的性质。当模型在训练过程中意识到如何解决任务时，结果发现许多任务的解决方案非常相似，即使你甚至不清楚它们为何相似，或者甚至意识不到它们相似。 例如，我们有一个检索任务和一个聚合任务，它们的查询方式截然不同，领域也完全不同。当你在这两个任务上训练常规语言模型时，轨迹看起来差异巨大。而在你使用 Pi、Claude Code 等（这些不在本文讨论范围内，但我们有相关结果）时，你会发现这些 harness 在这些问题上区分度太高了，尽管它们的解法其实是一样的。我们在训练 RLM 时发现，当它看到这些问题时，视为同类。原因是子智能体（sub-agent）看到的是不同的问题，但它解决的是一个较简单的子任务，因此你确信它足够聪明能搞定。但对于整体基础策略而言，它们最终看起来是相同的。 因此，如果你在左侧任务（例如）上训练，它就能立即解决右侧任务。如果你去看我们的图表，你会发现一种现象：当你朴素地在这些任务上训练 RLM 时，它们会自然学会泛化，例如扩展到更长的任务，因为策略基本相同，你只是在修改变量（如长度）。这一特性甚至适用于完全不同的任务，它们不仅在长度上不同，而且是完全不同类型的任务，比如数学任务与写作任务。但解决方案，或者说高层级的元解决方案（meta high-level solution）是相同的。因此，当你用其中一个训练 RLM 时，它会将其行为泛化到另一个任务。这里没有魔法，我想强调的恰恰是这一点。
Vibhu [00:36:38]: 你能描述一下它们到底学到了什么吗？你提到用短任务训练它们，结果能泛化到长 8 到 30 倍的任务上。
Alex Zhang [00:36:47]: 对。
Vibhu [00:36:48]: 它们是在学习怎么解这类问题吗？它们真正学到的核心东西是什么？
Alex Zhang [00:36:52]: 是的。它们学到的是如何在特定长度下解决这类问题。而事实证明，它们掌握的策略可以直接迁移到更长的任务上。就像，它们
Vibhu [00:37:05]: 嗯。