OpenAI CEO 奥特曼邀请 GPT-4.5 核心团队成员录制了一次播客，揭秘 GPT-4.5 的研发过程，视频地址：https://www.youtube.com/watch?v=6nJZopACRuQ

以下内容基于播客内容整理

Sam: 好的，通常我们做这类节目，是为了讨论即将发布的新产品。但今天有点不一样，我们要聊聊产品背后的研究。当我们发布 GPT-4.5 时，我们觉得大家会喜欢它，我们对这个模型非常自豪，但大家喜欢的程度远超我们的预期。人们会说各种各样的话，比如，“我从没想过跟模型对话能有这种体验”，“它跟 GPT-4 太不一样了”，“它在某些方面好太多了，这些方面要么显而易见，要么很难解释，诸如此类”。但是，大家对于 GPT-4.5 的研发过程非常感兴趣。所以今天，我们请来了打造 GPT-4.5 的一些核心团队成员，一起来聊聊这个话题。我们会聊聊，它的研发过程是怎样的，我们学到了什么？以及打造这样一个巨型模型需要付出什么？或许我们就可以从这儿开始。打造这样一个巨型模型，到底需要什么？

自我介绍

Alex:我是 Alex。我主要负责预训练数据方面的工作。我也负责了 GPT 4.5 的预训练机器学习部分。

Amin: 我是 Amin Tootoonchian。我是 OpenAI 的首席系统架构师。我负责 OpenAI 整体的系统和网络方面的工作。

Dan: 我是 Dan。我负责数据效率和算法方面的工作。

研发 GPT-4.5 具体都需要投入些什么？

Alex: 我想我们大约是在两年前启动了这个项目。那时候，我们知道有一个新的大型计算集群即将上线。我们预见到了这一点，所以开始做了大量工作，来确定我们想在这次训练运行中包含哪些特性，进行了许多大规模的风险评估运行（de-risking runs），并为此制定了非常长远的计划。计划涵盖了从系统、机器学习到所有方面的全栈。在正式运行开始之前，这是一个漫长的执行过程，旨在降低风险并为运行做准备。而运行本身，你知道，也是一项非常庞大的工程。

Amin: 是的，我认为这个过程从一开始就是机器学习团队和系统团队之间的协作，一直持续到我们确切知道想要训练什么样的模型，然后才开始启动运行过程。以我们目前的工作节奏，特别是要利用好提供给我们的最新计算资源，这使得我们很难事先就完美地规划好一切。所以，我们几乎总是在启动项目时带着许多未解决的问题。我们努力在运行过程中克服所有挑战，持续推进。基本上就是增加更多算力投入，解决我们之前可能没有预料到的所有问题 —— 尽管我们在机器学习和系统方面都做了各种预测。然后努力弥合我们预测应该发生的情况和实际发生情况之间的差距。我想，从宏观和概括的角度来看，这就是整个过程的全貌。最后阶段是执行，这需要很多人投入大量的精力和动力，在很长一段时间内持续推进，才能完成整个训练过程。

实际发生的情况和最初的预期有多接近？

Amin: 通常在开始阶段，从系统方面来看，我们通常离预期目标相差甚远。这时候总会面临一个选择：是推迟启动，等到更多问题解决后再开始，还是提前启动，然后边做边解决问题。这始终需要在合理推进和不过度延迟之间找到平衡。但几乎总会有一些我们在开始时并不一定知道会遇到的问题。整个过程就是尽力处理已知的问题，并为运行应该如何进行制定计划。随着项目的推进，再去处理那些未知因素，比如一次运行是否成功、需要多长时间等等的不确定性。差距有多大呢…

Alex: 是的，我想，从最高层面来看，这个项目的目标是做出 GPT-4.5，也就是比 GPT-4 聪明 10 倍的模型。这大概是我们两年前设定的最初目标。然后在这个过程中发生了很多事情，比如我们会想，我们能做得更好还是更差？嗯，我觉得，这是一个非常复杂的过程，但最终，我们得到了一个我们认为达到了比 GPT-4 聪明 10 倍这个标准的模型。这是就我们投入的有效算力（effective compute）而言的。

Amin: 是的。在执行层面，最初实际花费的时间远远超出了我们的预期。

Sam: 确实比我们想的要长。

Amin: 嗯，是的，但我觉得这个过程就是努力缩短时间，争取达到我们所期望的目标。

为什么从 1 万个 GPU 扩展到 10 万个 GPU，会让问题变得困难得多？（这里的数字是我随便说的）

Amin: 嗯，有很多问题。我确实相信，你在大规模下观察到的问题，如果你有非常敏锐的眼光，在小规模下也能观察到。并不是说这些问题只在大规模下才会显现。但是，一些罕见的事件在大规模下会变成灾难性的问题。特别是如果你没有预料到它会成为问题的话。

有哪些类型的事情在大规模下会变成灾难性的问题？

Amin: 我的意思是，其中一些我认为众所周知的问题是与基础设施相关的。你观察到的故障率，你观察到的各种各样的故障类型。既包括故障的种类，也包括故障的数量本身。所以我们会观察到一些我敢肯定供应商都没观察到的现象，因为这是一个非常大的样本池。我们得以观察到我们正在使用的庞大资源池的完整统计分布。网络互连总是其中一部分，单个加速器也是一部分，但归根结底，同时这其中的奇妙之处（或者说挑战）在于，几乎所有东西都需要按预期工作，最终结果才能成立。我们的工作就是尽量减少这种不确定性。

Sam: 显然，对你们所有人来说，在规模的前沿做事情是非常困难的。嗯，所以，即使我们像往常一样进行下一次训练运行，甚至可能更疯狂。但我也注意到，做那些不再是前沿的事情变得容易多了。比如，完成 GPT-4.5 需要数百人，几乎是 OpenAI 的全部力量。如果你们可以随便挑选人手，利用我们现在所知的一切、拥有的所有资源和所有已经就绪的系统，从头重新训练 GPT-4，今天需要的最少团队规模是多少？

从头重新训练 GPT-4，今天需要的最少团队规模是多少？

Alex: 我认为要达到 GPT-4 级别的模型，大概需要 5 到 10 个人。

Amin: 是的，对于 GPT-4 来说，我倾向于这个人数。但 4.5 的情况不同，因为它涉及很多工作流，更多的人参与进来，我会说这跟 GPT-4 的努力是截然不同的。

Alex: 是的，但是既然我们已经完成了那项工作，我认为我们的技术栈已经改进了很多。如果要重新训练，比如说，我们实际上在训练 GPT 4.5 的过程中就做过类似的事，我们训练了一个 GPT 4.0，这是一个 GPT-4 级别的模型，我们使用了 GPT-4.5 研究项目中很多相同的东西来重新训练它。我认为完成那次运行本身，实际需要的人数要少得多。

Sam: Dan，从你的角度来看呢？或者说，为什么训练大模型这么难？

为什么训练大模型这么难？

Dan: 我认为做任何新的事情都很难。我觉得，哪怕只是知道别人做成过某件事，事情就会变得容易得多，因为最难的部分是最初要有做这件事的决心。感觉“某件事是可能的”这个事实本身就是一个巨大的“捷径”（cheat code），让事情变得…。

Alex: 是的，我的意思是，我们每次进行 GPT 预训练，规模总是比上一次扩大 10 倍，总会发现一些你之前不一定预料到的有趣的新事物。

要想在预训练规模上实现下一个 10 倍或 100 倍的增长，我们需要什么？

Dan: 数据效率。

Sam: 这具体指什么？

Dan: 简单的答案。

Sam: 我当然知道，但请解释一下它的含义。

Dan: Transformer 或者说 GPT，在有效利用数据方面非常出色。它能吸收信息，进行一定程度的压缩和泛化。但它的定义性特征是利用算力非常高效地吸收信息。然而，它能从数据中获得多深刻的洞见是存在某种上限的。因此，当算力不断增长，而数据增长速度远没有那么快时，数据就成了这种标准范式下的瓶颈。这就需要算法上的创新，以便能够学到更多东西，花费更多的算力从相同数量的数据中学习更多。

除了数据效率，继续扩大规模还需要什么？

Amin: 我认为这个问题要从系统角度回答。我觉得，即使在我们训练过的不同 GPT 模型之间，GPT-4.5 所需的纯粹工作量，以及我们需要进行的改变，很大程度上是由模型本身的规格决定的。我们不可能用训练 GPT-4 时完全相同的技术栈来训练 GPT-4.5。比如说，状态管理，或者说我们处理状态管理的方法改变了。我们必须扩展到更多的算力，而这些算力并非在一个集群内就能提供，所以我们不得不进行多集群训练。想象一下，有许许多多像这样的不同工作流，必须在短时间内汇集起来，我们才能做到这一点。而要实现下一个 10 倍的跨越，当然，还有其他一些我们可能早就知道存在的问题，只是为了加快执行速度，我们在这次训练中选择了跳过它们。但对于下一次，我们就必须解决，这是无法避免的。正是这些选择，使得构建完美系统的时间线总是被拉长。所以我们总是在妥协，寻找达成目标的最快方式。系统本身不是目的，它产出的结果才是。 所以，对我来说，下一个 10 倍增长需要的当然是容错性。而且是一种可以与工作负载协同设计的容错性， 这样我们就不必担心维持如此大规模运行的运维负担会像我们之前的系统那样沉重。所以我认为，用我们之前的技术栈，GPT-4.5 已经达到了我们能勉强应付的极限。

在 4.5 的运行中，有多少百分比的步骤因为某个地方的某个组件故障而失败吗？

Amin: 我现在脑子里没有确切的数字。但这通常是这样运作的，这是一个有趣的现象。在新一代硬件的生命周期早期，有些问题不一定被很好地理解或研究。我们启动了进程，并且希望在存在这些问题的情况下也能继续向前推进。当然，在运行初期，故障率是相当高的。但这不一定意味着…很可能一旦我们找到根本原因并消除它，总的故障数量就会显著下降。通常情况就是这样。只是我们需要不断学习，完善基础设施，有人称之为“清理”基础设施，或者说是理解基础设施的根本性问题。之后状况会显著改善，但执行的早期阶段几乎总是相当痛苦的，因为我们一边要取得进展，一边还要了解新基础设施中新的故障模式。当然，到了后期，故障率会显著下降，整体的正常运行时间也会提高等等。但这只是一个优先级的问题。很难预测基础设施生命周期早期的故障风险会是什么样子，如果只为稳定状态进行设计，可能会导致流程早期的可用性非常差。

如果我们遵循每个 GPT 主版本号代表 100 倍提升的惯例，那么我们能走多远？利用我们今天所知的知识，我们能训练出 GPT 几？

Sam: 显然，推理模型是我们未来的重要组成部分。但如果我们暂时不考虑这些，只思考经典的预训练模型能走多远。假设我们有无限的 GPU、无限的网络和无限的电力，但我们仍然受限于当前所有的问题：组件仍然会出故障，我们没有实现容错训练，我们只有现有的数据等等。如果我们遵循每个 GPT 主版本号代表 100 倍提升的惯例，那么我们能走多远？利用我们今天所知的知识，我们能训练出 GPT 几？

Alex: 我认为在机器学习和算法方面，我们还没有发现明显的限制。我觉得，我们才刚刚开始探索更高效的数据算法，以及更好地利用现有数据的方法。这很有趣，因为我认为直到大约现在这个时间点，甚至纵观 GPT-4 的整个过程，我们很大程度上都只是处在一个受算力限制的环境中。所以当时所有的研究都集中在那方面。但现在，从 GPT-4.5 开始，在数据的某些方面，我们进入了一个非常不同的状态，一个更受数据限制的状态。所以现在围绕这方面的研究有了更多的兴奋点。

在 4.5 的训练过程中，在机器学习方面我们学到最有趣的东西是什么？

Sam: 这是一个惊人的变化，我觉得世界还没有真正领会到这一点。我应该换个词，世界还没有理解这一点：我们在能制造出的最好模型上，已经不再受算力的限制了。这太……这曾是我们长期生活的世界。在 4.5 的训练过程中，在机器学习方面我们学到最有趣的东西是什么？你愿意分享的。

Alex: 哦天哪。

Sam: 或者你们俩（指 Alex 和 Dan）谁都可以说？

Alex: 我不知道有什么可以分享的。

Amin: 从普遍意义上讲，我认为是（实际表现）偏离了预测，然后努力找出为什么我们会偏离预期的（性能）曲线。

Alex: 是的，我想也许最令人惊讶的事情之一，我们发现的一件比较惊讶的事情是，我们投入到运行中的机器学习方面的不同要素，它们的扩展方式各不相同，有些东西扩展得好，有些则不好，这是我们在训练这个模型的过程中发现的。是的，我们从中吸取了很多教训。

Dan: 我会说 GPT 范式的两个定义性特征一直是：一，你可以预测测试损失（test loss），并且它会可预测地扩展；二，神奇的是，更低的测试损失意味着在所有那些难以捉摸、令人惊叹、神秘的方式上展现出更高的智能。我想说，我们从 4.5 中发现的一个有趣的事情是，我们再次测试了这一点，这个模型拥有所有这些极其微妙的能力，这些能力并不在任何人事先的预料之中。我们的信念就是，它会变得更智能，而这种智能很难提前具体描述。然后在实际应用中，从用户满意度中，你会看到它在所有这些非常微妙的方面都更聪明了。它拥有更多的常识知识，它能理解细微差别和上下文。这就是从测试损失降低的那一点点中产生的魔力。我认为扩展定律的这一部分得到了很好的验证。

整个训练过程中最积极的时刻是什么？最让你印象深刻的记忆是什么？

Sam: 整个训练过程中最积极的时刻是什么？最让你印象深刻的记忆是什么？显然过程中有很多痛苦，但希望那些不好的记忆已经有些淡忘了。

Amin: 我确实有一个。

Alex: 我能想到的一个是，我们在运行过程中也对机器学习方面做了很多工作。我认为我们在运行期间做出的一些改变产生了相当好的影响，也许比预期的还要好。这对我们来说是一个非常激动人心的时刻。

Amin: 我认为对我来说，这可能是就运行期间个人投入而言，付出最大努力的一次。我们一边运行模型，一边还在并行地开发东西。当然，为了更快地达到目标，我们大力地将工作并行化。我们坚信这会有回报，我们能够越过那个性能悬崖 —— 那个可能导致模型因为训练时间过长而变得实际上无法训练的障碍。我们有计划，每个人都在执行，但这需要很长时间，非常艰难，比我想象的要难得多。我对需要多长时间才能解决这些问题的预测是错误的。我想，看到那个时刻，当其中几个问题得到解决后，我们获得了巨大的性能提升。我记得这个。每个人的……你能感觉到整个团队的氛围都变了。就是每个人都感到兴奋，更有动力去推动一切直到最后。这真是心态上一个很奇妙的部分。

Alex: 是的，你可以在我们的状态追踪器上看到预计完成时间（ETA）不断变化，从像是“两年后完成”变成了某个具体可感的时间。

Amin: 然后，这对团队士气和其他一切的影响，我认为是这其中的美妙之处。另一部分我要指出的是，机器学习方面的工作并没有停止。机器学习协同设计的部分在启动时并没有结束。大家继续跟进那些被搁置说“以后再解决”的问题。人们积极地进行开发并实施方案，这些都帮助缩短了执行时间。我认为这种团队合作的精神，这种没有“我做完我的工作了，交给你了”的团队界限感，是非常强大的。

Dan: 我想说的是，虽然大家很关注运行本身的挑战以及预测的偏差，但这并不是因为缺乏大量周密的规划。恰恰相反，我们做了大量规划。

Amin: 哦，这当然是。

Sam: 你想多谈谈一些...

Amin: 你没用那个比喻吗？ (可能指内部笑话或特定比喻)

Alex: 是的，这是迄今为止规划最周密的一次。就像我说的，我们在这个项目正式开始训练运行的大约一年前就开始了工作。在此期间，我们进行了数次大规模的风险评估运行。我们非常小心地对想要引入的所有变更进行排序，从一个我们非常有信心的、已知良好的配置开始 —— 你可以想象成 GPT-4 那样的，我们非常了解的设置。然后从机器学习的角度，逐层引入新的东西，并且非常仔细地研究我们所做更改的扩展性。所以，仅仅看到某种改进是不够的，我们还希望任何新特性带来的好处能够在不同规模下都持续有效，而不是随着规模扩大效果就减弱了。很多东西在小规模下看起来不错，但在大规模下就不行了。所以在这个过程中我们必须非常非常谨慎。而且，我们确实持续迭代了我们的扩展定律（Scaling Laws）方法论。在这次风险评估过程中，我们在这方面学到了很多，这些经验将继续指导我们未来 GPT 的研发。

Amin: 我想起了另一个我漏掉的非常有趣的时刻。是关于一个 torch.sum 的 bug。想象一下，我们启动一次运行，它里面没有 bug 是非常不可能的。我的意思是，各种各样的 bug，这几乎是必然的。但我们需要继续推进，并且需要确信，我们真的确定运行在正轨上吗？这些 bug 会不会对运行的健康状况产生严重的负面影响？虽然我们非常确定，我们最初就非常确定存在一些后果严重的 bug。我们确实构建了很多系统来提供可见性，并使我们能够区分：这是硬件故障吗？是什么类型的硬件故障？是某种形式的数据损坏吗？还是可能是机器学习的 bug？或者是我们代码中的竞争条件？当时的情况是，我们有好几个关于各种问题的未解决线索，这些问题都表现出不同的症状，但都与正确性相关。当然，我们已经发现并修复了一些 bug 等等。我们最终到了一个点，有好几个悬而未决的线索，大家都在思考是什么导致了这一切？它们是不同的 bug 吗？还是同一个 bug 导致了所有这些现象？大家围坐在一张桌子旁说，每个人都投票，你认为哪个是这个 bug 最可能的原因？结果，最后被证明是真正原因的那个选项（torch.sum 的 bug）得票最少。就是一个上游 Pytorch 库里的简单求和函数 torch.sum。有趣的是，我们特定的代码路径会触发它。需要说明的是，我们大部分用的是 Triton Kernels，只是在一些边缘情况下，比如某些操作对性能影响不大时，我们会退回到使用 Torch 的操作。我们特定的代码路径或数据触发了 torch.sum 函数的一个 bug。而且它发生的频率非常低，因为它取决于数据的分布。在好的情况下，它会触发非法内存访问，因为它在计算某块内存中的某些偏移量时出错了。最后有趣的发现是，当有人修复了这个 bug —— 我们的工程师发现，“哦，我找到 bug 了，就是这行，是 torch.sum。我们推送一个修复补丁，看看能不能解决所有问题。”——它确实修复了所有那些悬而未决的、看起来症状各不相同的 bug。这非常有趣，我记得我们当时在 Slack 上把好几个频道的名字从“多 bug 理论”改成了“单 bug 理论”之类的（multiple box theory to single box theory，可能指代 bug 的内部术语）。那真的很有趣，基本上就是，好了，现在…

Sam: 那是在运行的哪个阶段发生的？我现在记不清了。

Amin: 它从运行的早期就一直存在，直到我认为运行进行了相当长一段时间之后。我甚至会说到 40% 的时候。

Sam: 你们还记得是怎么发现的吗？

Amin: 嗯，我确实记得。我想它是在一个列表里，想象一下有一系列的内核调用。第二个内核是触发非法内存访问的那个。那是一个我们自己写的非常复杂的内核。当然，我们团队会怀疑是那里有 bug。很明显，bug 肯定在那里。好几个非常聪明的人逐行检查代码，每个人都在看。确实找到了一个 bug。但我们推送了修复后，一些问题消失了，但不是所有问题。到某个时候，有人发现，在输入列表里，torch.sum 是给这个复杂内核提供输入的众多来源之一。我们的一位工程师开始查看代码和不同的代码路径，然后说：“哦，这个非常罕见的代码路径，可能大多数人都不会触发，但我们触发了。”他说：“好吧，这行代码有 bug。”当然，我们对此唯一的验证和确认方法就是推送这个更改，然后观察所有的崩溃是否消失。结果它们确实消失了。我想这就是我们需要的验证。但这是通过…我的意思是，事情是这样的：它是一个以非常非常低的频率发生的崩溃，可能是每 100 步发生一次，或者每 1000 步发生一次。这是很容易被忽视的事情。但我们的原则是运行中不应该有这样的问题，关键在于坚持不懈地追查下去。

按下“开始”按钮之后，你的日常工作是怎样的？你就是坐在那里盯着损失曲线看吗？具体是怎么进行的？

Sam: Alex，我能理解你在按下运行“开始”按钮之前的生活是什么样的。但那之后呢？你的日常工作是怎样的？你就是坐在那里盯着损失曲线看吗？具体是怎么进行的？

Alex: 肯定有很多时间在看损失曲线。我们都看了很多。不，我觉得在那之后，还有各种各样的事情要做。仍然要和系统团队合作，争取把那些在启动前没来得及完成的、协同设计方面的改进给加上去。我们要持续监控运行中的很多指标，看是否有任何我们没预料到的趋势。这包括损失曲线，但也有一系列我们可以查看的其他统计数据。然后，嗯，还要从机器学习的角度，致力于对运行进行其他可能的改进。所以在数据方面，一旦你点击了“开始”，确实不会立刻那么忙了，但其他方面，仍然有很多事情要做。

Amin: 我认为我们在机器学习方面非常依赖的是确保正确性。想象一下，有很多嘈杂的信号，你有时就像在解读茶叶（reading tea leaves，意指根据模糊信息猜测）一样，猜测运行是否健康。当然，如果你等得足够久，你最终会知道它到底健康不健康。只是这个责任…

Sam: 那这种情况（指解读信号）下，有多少次是虚惊一场？就是你觉得“哦，情况看起来很糟”，但最后发现没事？

Alex: 我觉得挺频繁的。

Amin: 是的。

Alex: 可能大概一半的时间吧，因为我们是一群容易多虑的人。所以我觉得，如果不是一半的时间都在担心，那可能说明我们观察得还不够仔细。

如果在下一次大型运行之前，你能让一个机器学习问题得到解答，你最想知道什么？

Sam: 我有几个简短的快问快答问题。如果在下一次大型运行之前，你能让一个机器学习问题得到解答，你最想知道什么？

Alex: 我想，主要的问题是，在特定领域数据有限的情况下，我们应该应用什么算法。这问题或者说答案有点模糊。

Sam: 如果你可以对当前的硬件做任何改变，比如发明一种新型网络，或者全新的芯片架构。现阶段系统方面的限制因素是什么？你不能只说“哦我想要…”之类的。

Amin: 嗯，是在传输层，一个网络传输层的改变。就是说，当存在一些可以在应用层以下层面被绕过的故障时，我更希望网络传输层能自己处理好这些问题，让系统继续运行，并提供可用的带宽，而不需要我（在应用层）为此操心。

Sam: 在这方面有什么有希望的进展吗？

Amin: 嗯，是的，我们可以（私下）谈谈。

Sam: 好的，至少有进展就好。

Amin: 是的，只是…

目前我们最好的算法离人类水平的数据效率有多远？

Sam: Dan，为你准备一个两部分的问题。关于数据效率的问题，人类，不管我们学习方面有什么其他缺陷，似乎在数据效率上高得令人难以置信。是的。目前我们最好的算法离人类水平的数据效率有多远？

Dan: 很难进行同类比较。我觉得只能凭感觉说。在语言方面，差距极其遥远。

Sam: 10 万倍？1 万倍？

Dan: 确实是那个数量级。大概在那个范围内。这取决于你是否计算视神经上的每一个像素信息。但我们从算法上还不知道如何利用这些信息来在文本处理上达到人类水平。所以我认为从算法角度进行直接比较的话，是的，差距非常非常大。

你认为以我们当前方法的发展方向，我们最终能达到人类水平的数据效率吗？还是说这根本不会发生，或者即使达不到也无所谓？

Sam: 第二部分是，你认为以我们当前方法的发展方向，我们最终能达到人类水平的数据效率吗？还是说这根本不会发生，或者即使达不到也无所谓？

Dan: 嗯，我认为几十年来，深度学习一直关注的是计算效率。除了数据和算力的增长，神奇之处在于算法上的改进能够很好地叠加。不同地方的不同人发现某个小技巧能提升 10%，另一个提升 20%，这些改进不断累积。只是过去围绕数据效率的这种努力还不够，因为它不值得。当数据充足而你受算力限制时，追求数据效率就不划算了。所以现在我们进入了 AI 研究的一个新阶段，我们将开始叠加数据效率方面的进展，这里提升 10%，那里提升 20%。我认为预测它会遇到我们无法预见的瓶颈有点不明智。我没有理由预测会遇到瓶颈，但是……大脑运作的算法原理肯定与我们现有做法的小修小补有很大不同。所以在这方面我们必须保守一点。但我认为有充分的理由保持乐观。

人类会有一天进行一次使用一千万或更多 GPU 的同步预训练运行吗？

Sam: 下一个问题对你们三位都一样。回答“是”或“否”，或者你也可以补充解释。人类会有一天进行一次使用一千万或更多 GPU 的同步预训练运行吗？

Alex: 我不知道那是否会完全是像现在这样的“预训练”运行，但我认为可能会有某种类型的训练运行，是的，是的。我不知道它会是什么样子，可能和我们今天做的完全不同，但会有某种具有无监督学习精神的东西达到那种规模。我想，我认为会的。

Amin: 我会称之为半同步（semi-synchronous）。至于那个规模，我希望如此。我觉得这听起来非常有趣。

Sam: 你说你会称之为半同步？

Amin: 是的，我认为不是完全同步，这只是自然法则，我们无法完全改变它。

Dan: 我认为很可能会比那更去中心化。肯定会有 1000 万个 GPU 协同工作，为一个正在学习和做事情的 AI 系统服务。但这个“大脑”的各个部分不一定都会相互通信。

关于更智能、更大的预训练模型与模型学习推理能力的好坏之间存在怎样的关联，我们有没有学到或观察到什么可以分享的？

Sam: 这说得通。关于更智能、更大的预训练模型与模型学习推理能力的好坏之间存在怎样的关联，我们有没有学到或观察到什么可以分享的？

Alex: 是的，所以我想我们观察到的是，更好的预训练和无监督学习倾向于提升模型广泛的基础智能，并极大地帮助其泛化能力。我们发现这与推理能力形成了很好的互补，因为推理能力的提升可能在智能提升方面表现得更“尖锐”或更“集中”，即在某些特定方面提升显著。我认为它们被发现是很好的互补。

Sam: 稍微跑个题。你们有没有一种直觉，预训练似乎对所有事物都具有如此广泛的通用性，而当我们教模型进行推理时，却只能让它在某一类事情上表现得特别好，这是否有点奇怪？或者我们能从中得到什么启示吗？

Alex: 是的，我不知道这是否……我觉得这很有趣。但我认为，当你看看你用来训练的东西时，从预训练中看到这一点并不奇怪。当你为预训练构建一个训练数据集时，它本质上是非常广泛的，我们的目标就是广度和多样性。我认为当你谈论进行强化学习（RL）并需要能够清晰地获得良好奖励信号和良好环境时，总是很难达到同样的广度。

Dan: 我同意，但我认为还有另一个因素。预训练本质上是在压缩数据，而压缩数据就是要看到不同事物之间的联系。它关乎类比，关乎抽象。而针对特定问题的推理，仔细思考本身就像是一种技能和技艺。仔细思考可以解锁不同领域解决问题的能力。但是，当你像预训练那样跨领域进行压缩时，你是在一个更抽象的层面上学习。

在系统进展方面，什么会限制我们？芯片、处理器、内存、网络，还是电力？继续扩大规模的瓶颈会是什么？

Sam: 这说得通… 哦，我等下要改变问你的问题了，我刚想到了别的事。嗯，在系统进展方面，什么会限制我们？芯片、处理器、内存、网络，还是电力？继续扩大规模的瓶颈会是什么？

Amin: 我认为这就是系统的奇妙之处，在于如果我们进行协同设计，工作负载就能适应你所构建的基础设施。没有一个普遍的说法是网络一定是瓶颈，或者内存带宽是瓶颈，或者计算是瓶颈。我们有选择去调整资源需求，甚至对于同一个模型规格，我们也有选择去调整资源需求，以创建一个更平衡的系统。不过，话虽如此，我认为比如预训练的答案和推理的答案是不同的等等。但是，拥有更多的内存带宽总没有坏处。我会…是的，我认为这是一个很难在不加限定条件的情况下回答的问题…

在为 4.5 运行做准备时，你们的团队在模型规范（spec）等方面有多大程度的合作？有多大程度上只是你们（ML 团队）说“这就是我们想要的”？

Sam: 回到刚才那点，在为 4.5 运行做准备时，你们的团队在模型规范（spec）等方面有多大程度的合作？有多大程度上只是你们（ML 团队）说“这就是我们想要的”？

Alex: 是的，合作非常紧密。我的意思是，甚至细到我们想要进行的矩阵乘法（matmuls）的形状，确保它们得到良好优化。但对于这个项目，合作要深入得多，可以追溯到运行启动前大约六到九个月。为了实现我们想加入运行的一些功能，以及为了实现 4.5 我们需要做的某些方面，我们进行了一次专门的、非常大规模的风险评估运行，这次运行特别侧重于与系统团队的协同设计，目的是让机器学习和系统在大规模下能够良好地协同工作。所以我们在那次运行中，我想是第一次如此重视协同设计这个方面。我认为这非常关键。

Amin: 是的，我认为那是我记忆中第一次大规模的努力，不仅仅是关于微调某个方面，而是你从根本上希望系统层面保持某个特性。而这个特性不会凭空出现，你真的需要引导系统来赋予你这个特性。所以，那次协同设计的努力塑造了模型中的架构和架构元素。这在某种程度上将系统和机器学习方面紧密地联系在了一起。这可能是我们不太希望拥有的一种特性——理想情况下，我希望所有东西都是解耦的，以便给彼此最大的空间。但有时事情会紧密地联系在一起，你确实需要迎合基础设施的要求，或者事情应该如何运作。很多时候，你确实想要一个平衡的系统，平衡的通信和一个非常对称类型的系统。而我们能使用的最好调节手段始终是协同设计。

我们离理想化的系统有多近？

Sam: 我们离理想化的系统有多近？

Amin: 我们离那个还差得远呢。我认为是的，我们差得很远。但这很有趣。构建系统的实践总是关乎此：你对事物应该如何运作有一个理想化的看法，然后就是要调和（reconciling）这种理想与现实之间的差异。我认为我们不是为了理论而理论，比如说仅仅谈论我们希望它成为什么样子。我们只是想让它发生，并尽可能地接近（approximate）那个理想状态。所以，老实说，我认为这对系统领域来说可能是最激动人心的时刻了。你能够真正地提出关于什么是好的系统设计的假设，然后从那里开始，非常快地在实践中看到结果。对于那些以前人们会说“这是一个优雅的系统设计”的东西，现在我们有大量的算力，我们有一个问题，我们知道目标，我们就可以去看看我们的选择是对是错，而不再是让历史告诉我们这是对是错。

当你的团队（指 ML 团队）决定要在运行中加入什么时，他们有多大程度会考虑系统设计方面的约束？

Alex: 是的，我认为这对于进行大规模预训练运行来说，是一个非常重要的考虑因素。我认为自从 4.5 以来，很多在架构方面的工作，也一直有持续的线索是关于进一步的协同设计，寻找更多可以为未来硬件进行设计并共同构建的地方。我认为自那时以来，已经有很多有希望的工作在进行了。

为什么无监督学习有效？

Sam: 好的，这是我为你改的问题。（对 Dan 说）为什么无监督学习有效？

Dan: 压缩。所以，理想的智能被称为所罗门诺夫归纳法（Solomonoff induction）。基本上，它不确定自己处于哪个宇宙中。它会考虑所有可能的宇宙，并且认为简单的宇宙比不简单的宇宙可能性更大。它是完全贝叶斯主义的，将所有这些可能性都记在脑中，并随着进程不断更新其观点。你可以通过找到计算你所见一切的最短程序来近似这个过程。我们用预训练所做的事情，或者说理解预训练的一种方式是，它在进行压缩，它试图找到解释迄今为止人类产生的所有数据的最短程序，以此作为一种近似…

为什么预测下一个 token 能做到这一点（压缩/学习）？

Dan: 这实际上是一个很微妙的问题。统计学界曾长期存在一个悖论或者说类似悖论的现象：为什么深度网络能够泛化，而它们看起来并没有进行压缩？通常在统计学中，你有大量数据和小模型，模型预测了数据。因此，模型必定进行了压缩并且学到了东西。但在预训练中，模型通常相当庞大，并且其规模大致与数据量成比例增长。所以一直存在一个问题：它们到底是在压缩还是在泛化？当然，也有批评者说，这只是记忆、插值和肤浅的模仿。但是，有一种看待预训练的方式，可以让你确实看到它是一个压缩器，尽管是以一种非直观的方式。这个想法叫做序贯压缩（prequential compression）。它的核心思想是，模型在训练期间学习速度很快这个事实，意味着你可以把它变成一个很好的压缩器。所以，即使最终的权重很大，（压缩后的）二进制文件也不需要存储这些权重。二进制文件可以在解压时从头开始预训练。而它学习得非常非常快意味着大部分数据你都可以用非常非常少的比特来编码。所以，基本上，由于一个微妙的原因，它确实是一个相当好的压缩器。我认为这是一个相当令人满意的解释，说明了为什么它确实能导向智能。

Sam: 你们有什么要补充的吗？

Alex: 没有。

指标（metrics）的选择和使用规范

Sam: 太好了。谢谢。还有一件有点相关但还没提到的事情，就是指标（metrics）的选择和使用规范。这就像是…当你运用这些扩展定律，进行所有这些机器学习科学研究时，你得到的结果很大程度上取决于你选择的衡量指标。

Amin: 你想详细说说吗？

Alex: 是的。就是说你在哪个测试集上评估你的困惑度（perplexity）。所以如果你指的是…

Dan: 嗯，即使是主要关注困惑度本身。这里已经…有些观众可能以为我们在看大学考试成绩之类的。

Alex: 是的，那么，Dan 你想解释一下困惑度吗？是的。我觉得值得解释一下。

Dan: 尝试用那些人类容易理解的测试形式来评估模型的智能，这是非常诱人的。但如果你这样做，你很可能会偏好那些让模型更容易记忆的改变，而牺牲了让系统实际变得更聪明的机会，因为几乎所有我们现有的测试，网上都有类似的东西。如果你真的能在整个互联网上进行训练，那么与对无法接触训练数据的人类的测试相比，这些测试在某种程度上就失效了（degenerate）。因此，该领域的主要方法是看模型在一些被认为是好的、并且被刻意保留未用于训练的（held-out）数据上的压缩程度如何。即使这样，如果你对这些留存数据不够小心，比如它和你的训练数据太相似，那么那些让训练算法更擅长记忆的改变，就会看起来让模型更聪明了，因为它已经“认识”你的测试集了。而我们不想仅仅衡量记忆能力，我们追求的是泛化能力。也就是分布外泛化能力。

[0:43:23] Alex: 所以这就是为什么，我想是的，也许我之前提到过。就是说，我们关注的关键测试集，我们非常在乎它们不能以任何程度，哪怕是最轻微的程度，出现在我们的训练集中。因为那会完全破坏我们应用扩展定律的方式。所以是的，这是其中一个非常关键的点。

Sam: 我们在这方面最好的参照物是什么？

Alex: 是我们的内部代码库（internal code base）。我们知道这个是外面没有的。所以…

Sam: 这个指标在很多次（迭代/模型）中都一直是我们最好的参照物吗？

Alex: 它仍然是最好的。是的。

Sam: 这真是了不起。我的意思是，我们开玩笑说，一个模型的好坏就看它在内部代码库（monorepo）上的损失值。就像其他一切一样。这其中有某种极其元（meta）的、递归的东西。(注：第二句似乎与上下文稍有脱节)

Dan: 不知何故，你预训练了模型，它在单一代码库（monorepo）上有一个损失值。然后不知何故，这个值就能告诉你很多关于它后续行为表现的信息。它能告诉你一个哲学研究生会如何看待它回应中的细微差别。这太神奇了。太神奇了。

为什么扩展定律是宇宙的一个属性？

Sam: 与此相关，也是最后一个问题。从某种意义上说，这整个耗费了大量人力、时间、资金和其他一切资源的努力，本身就是一个实验，旨在进一步验证扩展定律（Scaling Laws）是否持续有效。结果证明它们确实有效，而且可能在很长一段时间内都会持续有效。我接受扩展定律，就像我接受量子力学或其他什么东西一样，但我仍然不明白为什么。就像，为什么这会是宇宙的一个属性？所以，为什么扩展定律是宇宙的一个属性？

Dan 我可以试着说一下。“更多压缩会导致更高智能”这一点，有很强的哲学基础。所以问题就变成了，为什么训练更大的模型、训练更长时间，就能带来更多的压缩？这里有很多理论。我比较喜欢的一个理论是，相关的概念在世界的数据中某种程度上是稀疏（sparse）分布的。特别是，它呈现幂律（power law）分布，比如说，第 100 个最重要的概念可能出现在百分之一的文档中，诸如此类。所以存在长尾效应（long tails）。你可以持续挖掘（mining）下去。不过，正如你之前提到的，（在数据效率方面）我们可能可以做得更好得多。