整理 | 褚杏娟、核子可乐

时至今日，我们还有没有必要继续关心参数？OpenAI 团队应该很有发言权。

根据网上推测，GPT-4.5 的参数规模可能在 3 万亿至 5 万亿之间，这主要是基于 GPT-4 的参数规模（约 1.76 万亿）和 MoE 模型的参数分布特点得出的‌。

负责预训练数据并领导了 GPT-4.5 训练工作的 Alex Paino、OpenAI 首席系统架构师，负责 OpenAI 的系统和网络架构的 Amin Tootoonchian、主要研究数据效率和算法的 Daniel Selsam 等核心团队成员聊了聊研发 GPT-4.5 这种大规模参数模型的历程并分享了一些打造这类模型的必备基础和经验。

“项目规划量巨大。”

构建这种巨型模型到底需要什么？“大量人力、时间和计算资源。”Alex 言简意赅地说道。

GPT-4.5 项目大概是从两年前开始的，初始目标是让模型比 GPT-4 聪明 10 倍。在执行前，OpenAI 团队进行了大量精密计划。

“项目规划量巨大。”Alex 称，他的团队提前一年开始准备，做了多次大规模验证，从 GPT-4 的成熟配置开始，逐层叠加新特性。要确保每个改进都能稳定扩展且不衰减。团队迭代了无数次 Scaling Law 方法论，而这些经验也会指导未来工作。

“我们也会试着像规划 GPT-4 时那样思考，试着从机器学习的角度来思考。此外，我们会关注新功能要能在更大的规模下继续起效。总之，虽然遵循的是 Scaling Law，但我们其实是从细处着手。 我们在其中学到了很多，这些也将指导我们更好地开发后续 GPT 版本。”

Alex 团队当时就知道会有新的超算集群上线，所以提前布局，做了大量验证性工作——跑了很多次大规模的风险规避测试，制定了从系统到机器学习全栈的长远计划。整个过程就像马拉松，既要排除风险又要为正式训练做好准备，工程量实在太大了。

模型设计和系统团队在 4.5 训练中合作非常紧密，从张量形状到硬件优化。这次还提前 6-9 个月做了大规模联合设计验证。这是两支团队首次大规模联合设计，尝试把系统架构和机器学习需求深度绑定，虽然理想情况下最好能保持解耦，但现实操作时必然有所妥协。

从一开始直到最终确定要训练的模型参数，然后启动训练流程，两个团队的合作一直都非常紧密。“但节奏实在太难把握了，尤其是要充分利用最新的计算资源，根本没法完美规划。”Amin 说道。

每次训练都像带着一堆未解问题硬上，团队全程都在见招拆招。系统要不断扩容，解决那些前期根本预料不到的幺蛾子，尽量缩小预期和现实的差距。“最后执行阶段全靠人力硬堆，好在还是靠所有人的热情和冲劲撑过了整个训练过程。”

预训练规模扩大，

就会有新坑

从 1 万张 GPU 扩展到 10 万张确实会让问题复杂化。很多小问题在规模扩大后会变成灾难。比如某个小概率故障，在 10 万张 GPU 的体量下发生频率会指数级上升，经常会在完全没预料到的时候突然出现。

最典型的是基础设施问题。“我们会观察到厂商都未必见过的故障类型和频率，毕竟我们的硬件池是超大规模的。网络架构、加速器本身都可能出问题，但关键是要让所有环节都符合预期，尽量减少变量。”Amin 说道。

但现在再做之前的模型已经容易很多了。Alex 表示，以 OpenAI 现有的能力，再做一个 GPT-4 级别的模型，可能 5 到 10 人就够了。GPT-4.5 跟 GPT-4 不同，其中涉及太多新问题和跨团队协作，所以投入的人力也不在一个量级上。

至于为什么旧模型重训起来更简单，那是因为团队已经做成过一次了。“我们也确实在 GPT-4.5 的研究过程中重新训练了一个 GPT-4 级别的模型，这就是 GPT-4o。它用了 GPT-4.5 的很多技术积累，但这次的训练团队规模小得多。”Alex 说道。

“我们每次预训练都把规模扩大 10 倍，期间总会有新坑冒出来，简直毁人心态。”Alex 说道。

对于人类能否实现 1000 万张 GPU 同步预训练的问题，Alex 认为，不一定是预训练，但会有某种超大规模无监督学习。虽然不清楚具体是怎么实现的，但看起来可能会跟如今的方式完全不同，而且他估计会继承一些无监督学习的思路；Amin 愿称之为“半同步”，毕竟要受物理规律的限制，他认为这么大的规模下完全同步着实不太可能；Daniel 则表示可能是去中心化系统，各部分未必全互联，但肯定有大规模型协同工作。

当前，如果预训练规模再想扩大 10 倍甚至 100 倍，Daniel 认为需要数据效率。具体来说，Transformer 架构在数据利用上已经很高效了，但仍存在天花板。当算力持续增长、而数据增长放缓时，数据会成为瓶颈。这时候就必须创新算法，用更多算力从相同数据中榨取更多价值。

此外，系统层面也得改进。比如 GPT-4.5 的训练需要多集群协同，而之前的单集群算力不够。每次迭代都要解决新硬件的兼容问题，还得在容错性和执行效率之间权衡。下次扩 10 倍的话，这些绕不过去的坎必须提前处理。

Amin 还指出，下一轮 10 倍扩容的关键是硬件容错，需要和计算负载协同设计，避免运维负担拖垮系统。

“4.5 已经让我们捉襟见肘了。”Amin 说道，“新硬件早期故障率确实高，我们得边修边推进，等找到根源后故障率会骤降。但早期阶段实在痛苦，得边摸索新故障模式边前进。后期故障率开始下降，系统稳定性则逐步提升，但早期风险太难预测了。”

Amin 表示，“我们总是在妥协——选最快出成果的方式，而不是建完美系统。毕竟系统是手段，产品才是目的。”

那对于推理模型来说，是不是也是越大越聪明呢？Alex 认为这个结论“算是成立”。更大的模型往往拥有更好的预训练和监督学习能提升泛化能力，和推理形成互补。

具体来说，推理是针对特定问题的细致思考，可以有针对性地提升特定能力，而预训练是全面打底，跨领域压缩数据，找类比和抽象，这是更高级的抽象学习。两者是互相依存的关系。

误报非常多，能占到一半

执行层面的耗时远比预期要长。

训练初期总有奇怪 bug。单就 Amin 团队来说，就得区分是硬件故障、数据损坏还是机器学习逻辑问题。

Amin 举例称，“有次多个线程报告不同症状，大家投票猜根源，结果得票最少的‘上游代码中的 torch.sum 的简单加法错误’反而是真凶！”

“我们其实主要是在用 Triton 和 XLA，但在某些边缘情况、某些无关紧要的算子上，我们就会回退到 PyTorch 默认实现。而其中一段数据刚好触发了 PyTorch 的这个错误路径，造成了一个非常低频的 bug，具体表现是非法内存访问，内存偏移计算错了。为了纪念这个大乌龙，团队把 Slack 频道名从‘多假设讨论频道’改成了‘单 bug 理论频道’，超搞笑。”他解释道。

这 bug 从早期到训练中期都有，涵盖了大概 40% 的项目阶段。有个工程师在检查输入到复杂内核的参数时，发现了某个输入来自 Pytorch 一个相当偏门的代码路径。虽然崩溃频率低，但修复后所有问题都解决了。后来团队进行了验证、变更和发布，自此这个 bug 才彻底消失。

“其实 很多问题就是这样积少成多的，所以我们必须打起十二分精神来。”Amin 说道。

启动训练后，Alex 团队盯 loss 曲线是日常工作，此外还要和系统团队优化未完成的改进，监控各种异常指标。数据方面虽然启动后会变得轻松点，但机器学习侧仍有大量工作。

机器学习侧依赖很多正确性判断，得从噪声中找线索。其中的误报非常多，估计能占到一半。“训练中期我们实时调整了机器学习方案，而且效果比预期好，就挺让人激动的。”Alex 说道。

整个团队还一直在预测性能曲线，然后分析偏差原因。比如分析某些机器学习侧的改进在训练中效果为何超预期，就让团队对算法有了新的认知。

Daniel 提到，GPT 范式的两大特点是：性能可预测、智能提升会带来更难以言喻的能力提升。4.5 再次验证了这点——很多并未事前规划的微妙能力，部署后才自然显现。比如更强的常识推理、语境理解，这就是规模带来的魔法。

“至少 4.5 再次证明了这点。模型会有意想不到的能力，用户满意度也充分证明了这种‘更聪明’的评价。这种智能扩展性保持得非常好。”Daniel 说道。

“中间无数次怀疑能不能达成”

“这两年过程曲折，中间无数次怀疑能不能达成，但最后还是把有效算力堆到了预期值，模型表现也达到了‘变聪明 10 倍的目标。”Alex 说道。

系统设计对模型设计影响很大。比如训练规模扩大后，系统团队得持续创新。前期总是比预期差一大截。

这时候就得纠结：是推迟上线等问题解决，还是带着问题硬上？得在“边做边修”和“不合理拖延”之间找平衡。但总会有预料之外的坑，只能尽量把控已知风险，制定应对计划，执行中再处理未知变量——比如训练到底要多久，结果能有多好，这些都很玄学。

现在离真正“完美系统”还差得远。“但实践就是不断逼近理想。我们拥有计算资源和明确目标，可以快速验证设计，这比纯理论有趣多了。”Amin 说道。

目前限制系统扩展的因素很多。系统的美妙之处，就在于各种因素相互依存，而设计的目标就是消除瓶颈，不让网络、内存带宽或者算力成为单一瓶颈，打造一套更加均衡的系统。当然了，协同设计的话，可以调整工作负载适配硬件。预训练和推理需求不同，但有更多的内存带宽总是好的。

Alex 认为，算法层面，目前还远没触及明显瓶颈。“数据利用效率还有进一步深挖的空间，现在我们刚刚开始从算力受限转向数据受限，这方面研究会带来更多令人兴奋的成果。”

人类的数据效率远超 AI，现在离人类水平是天文数字般的差距。“算法上我们还没摸清楚门道。”Daniel 认为，过去几十年深度学习靠计算效率，现在数据效率会成为新战场。虽然目前发掘不足，但未来会有大量优化堆叠，没理由预言会遇到瓶颈。“不过，大脑的工作原理和现有方法差异太大，还是得保持谨慎乐观。”

而在整个研发过程中，团队积极向上的氛围给三人都留下了深刻印象。

对 Amin 而言，这是他时间投入最大的项目。“并行推进各项优化时，大家坚信可以突破性能瓶颈。虽然解决速度比预期慢，但问题解决后团队士气大振，进度追踪器上的预计完成时间也从模糊的两年变得切实可行，那种能量变化特别震撼。而且机器学习团队从不止步，而是会持续优化训练流程，这种无界限合作太关键了。”

“那种热情满满的感受很打动人，这种为工作付出一切的经历真的让人难忘。”Amin 说道，“我们能深切感受到团队士气的变化，这也是参与其中的美妙之处。再就是我们与机器学习团队的合作，大家会把有待解决的问题贴在标签上，提醒稍后解决。总之，人人都在积极努力，这就是亲密无间的跨团队合作精神。我做好自己的事、再把成果传递给你，这就是 OpenAI 的力量源泉。”

为什么存在 Scaling Law?

理想智能是 Solomonoff 归纳，用最短程序解释所有观察数据。预训练就是在压缩数据，类似找最短程序。那为什么预测下一个 token 的机制能实现智能？

Daniel 表示，统计学上曾经有个类似的悖论：为什么深度网络能泛化，而它们看上去并没有压缩数据？传统统计里，模型小、数据多，模型能拟合数据，说明它“压缩”了信息。但现在的预训练模型本身非常庞大，甚至跟数据量是同级别的， 那它到底是在压缩、还是只是记忆？这就是核心谜题。

当然，也有批评者说这只是记忆、插值和浅薄的表象。但从训练的角度来看，大模型的学习过程意味着可以用很少的 bit 对大部分数据进行编码，也就是说大模型其实是一个相当典型的压缩器。我觉得这个解释不错，基本点明了为什么它真的能带来智慧。

“Scaling law 和机器学习之所以可以实现，都离不开度量指标的选择……”Daniel 说道。

所谓“度量指标”，主要是指如何衡量模型的“困惑度”。而“困惑度”概念是：人们总是很想用人类可读的测试来评估模型的智能——但如果你这么做，可能反而会鼓励模型靠记忆取胜，而不是变聪明。

市面上几乎所有测试题，在互联网上都能找到类似版本。而如果训练数据包含了整个互联网，那模型考这些题其实就不算本事了。

所以目前业内更主流的做法是：看模型在一组“高质量、未见过的数据”上的压缩效果。但就算这样，如果对这个“held-out 数据集”选择不够严格， 而它又跟训练集太像，那优化训练算法只会让模型更容易记忆，从而假装自己变聪明了。

“我们追求泛化，而非记忆。 测试集必须完全独立，否则 scaling law 就发挥不出作用了。”Alex 说道。“我们的内部代码库里就有（最好的测试集），绝对好，但在这就不多说了……”

Daniel 认为，哲学上，更多压缩带来更多智能是有其理论依据的。但问题在于：为什么训练更大的模型、更久，它就能“压缩”得更多？他最喜欢的一个解释是：这个世界的数据中，有用的概念其实是稀疏分布的，而且这是一种幂律分布：比如最重要的前 100 个概念，只在大约 1% 的文档中出现。这说明世界是“长尾”的。

如果真能找出完美的数据集和算法，或许可以彻底解决这个问题。这意味着只要在“数据选择”上变得更聪明，就有可能获得指数级的算力节省。

但现实中，我们还是主要在“被动地捞数据”。如果只是海量采集数据，那每扩充 10 倍的训练规模，也许只能挖掘“尾部新增”的几个知识点，而那个尾巴还在不断延伸。不过，我们确实有可能用更聪明的方式去做挖掘。

在下轮训练之前，Alex 最想先解决如何用有限数据在特定领域优化模型架构；Daniel 是想解决数据效率问题；Amin 则想改进传输层网络，“最好让网络自己处理故障，别让我在应用层操心。”

原文链接：

https://www.youtube.com/watch?v=6nJZopACRuQ