GPU 集群规模从 4K 飙升至 24K，Meta 如何引领大规模语言模型训练突破

在我们继续将 AI 研究和开发的重点放在解决一系列日益复杂的问题上时，我们经历的最重大和最具挑战性的转变之一是训练大型语言模型（LLM）所需的巨大计算规模。

传统上，我们的 AI 模型训练任务会训练大量模型，而这些模型需要的 GPU 相对较少。我们的推荐模型（例如 feed 和排名模型）就是这种情况，这些模型能够获取大量信息以提供准确的建议，为我们的大多数产品提供支持。

随着生成式 AI（GenAI）的出现，我们看到了模型训练在向更少的模型数量与更庞大的作业转变。大规模支持 GenAI 意味着重新思考我们的软件、硬件和网络基础设施结合在一起的方式。

在我们增加作业中 GPU 数量的同时，由于硬件故障而中断的可能性也会增长。此外，所有这些 GPU 仍然需要在同一个高速结构上通信才能实现最佳性能。这就引出了四大重要因素：

• 硬件可靠性：确保硬件可靠是非常重要的。我们需要尽量减少硬件故障中断训练作业的可能性。这涉及严格的测试和质量控制措施，以及自动化的快速检测和问题补救机制。

• 故障时快速恢复：尽管我们尽了最大努力，但硬件故障仍会发生。当它们发生时，我们需要能够快速恢复。这就需要减少重新调度开销和快速实现训练重初始化。

• 训练状态的有效保存：如果发生故障，我们需要能够从中断的地方继续。这意味着我们需要定期检查我们的训练状态，并有效地存储和检索训练数据。

• GPU 之间的最佳连接：大规模模型训练需要以同步方式在 GPU 之间传输大量数据。GPU 子集之间的缓慢数据交换会拖累整个作业的速度。解决这个问题需要强大而高速的网络基础设施，以及高效的数据传输协议和算法。

  跨基础设施栈进行创新

由于 GenAI 的大规模需求，完善基础设施栈的每一层都很重要。这需要在众多领域取得广泛进展。

我们使研究人员能够使用 PyTorch 和其他新的开源开发工具，从而实现极快的研究到生产开发速度。这些努力包括了开发新的算法和技术以进行高效的大规模训练，并将新的软件工具和框架集成到我们的基础设施中。

高效的调度有助于确保我们的资源得到最佳利用。这方面的成果包括了可以根据不同作业的需求分配资源的复杂算法，和能够适应不断变化的负载的动态调度。

我们需要高性能硬件来处理大规模模型训练的计算需求。除了大小和规模之外，许多硬件配置和属性都需要针对 GenAI 进行最佳优化。鉴于硬件开发时间通常很长，我们必须调整现有硬件，为此，我们探索了包括功率、HBM 容量和速度以及 I/O 在内的各个方面。

我们还修改调整了使用 NVIDIA H100 GPU 开发的 Grand Teton 平台，将 GPU 的 TDP 提高到 700W，并迁移到了 GPU 上的 HBM3 内存上。由于我们没有时间改进冷却基础设施，所以只能留在风冷环境中。机械和热设计必须做出改变以适应这种情况，这触发了一个用来支持大规模部署的验证周期。

所有这些与硬件相关的更改都颇具挑战性，因为我们必须找到一种适合现有资源限制的解决方案，并且方案的更改自由度很小，还要满足紧迫的时间表。

一旦我们选定了 GPU 和系统，将它们放置在数据中心中来充分利用各种资源（电源、冷却、网络等）的任务，就需要重新考虑为其他类型的负载所做的许多权衡。数据中心的电源和冷却基础设施无法快速（或轻松）调整，我们必须找到一种最佳布局，以在数据大厅内实现最大算力。这需要将读取器等支持服务移出数据大厅，并安装尽可能多的 GPU 机架，以最大限度地提高功率和网络能力，从而通过最大的网络集群实现最高的计算密度。

我们需要规划检测和补救措施，以尽可能减少硬件故障期间的停机时间。故障数量与集群的大小成正比，而跨集群的作业需要保留足够的备用容量，以便尽快重新启动作业。此外，我们还会监控各种故障，有时可以采取预防措施来减少停机时间。

我们观察到的一些最常见的故障模式包括：

• GPU 脱落：在这种情况下，主机无法在 PCIe 接口上检测到 GPU。这种故障有多种原因，但这种故障模式在早期更常见，并随着服务器使用时间增加而逐渐减少。

• DRAM 和 SRAM UCE：内存中经常出现不可纠正的错误，我们监控和识别重复犯错的单元，跟踪阈值，并在错误率超过供应商阈值时启动 RMA。

• 硬件网络电缆：在常见的服务器无法访问的错误类别中，这些故障也最常出现在服务器刚开始部署的时期。

  网络

大规模模型训练需要在 GPU 之间快速传输大量数据。这需要强大而高速的网络基础设施以及高效的数据传输协议和算法。

业界有两种符合这些要求的领先选项：RoCE 和 InfiniBand 架构。这两个选项都有各自的权衡。一方面，Meta 在过去四年中构建了一些 RoCE 集群，但其中最大的集群仅支持 4K GPU。我们需要更大的 RoCE 集群。另一方面，Meta 已经使用 InfiniBand 构建了多达 16K GPU 的研究集群。但是，这些集群并没有紧密集成到 Meta 的生产环境中，也不是为最新一代的 GPU/ 网络构建的。这让我们很难决定使用哪种架构来构建。

因此，我们决定同时构建两个 24k 集群，一个使用 RoCE，另一个使用 InfiniBand。我们的目的是构建并从运营经验中学习。这些经验将为 GenAI 网络架构的未来发展方向提供参考。我们优化了 RoCE 集群以缩短构建时间，并优化了 InfiniBand 集群以提供全双工带宽。我们使用 InfiniBand 和 RoCE 集群来训练 Llama 3，其中 RoCE 集群用于训练最大的模型。尽管这些集群之间存在底层网络技术的差异，但我们可以调整它们，为这些大型 GenAI 负载提供同等的性能

我们优化了整个堆栈的三个方面，使 GenAI 模型的网络通信在两个集群上都有很高的性能：

1. 我们将由不同模型、数据和管道并行性产生的通信模式分配给网络拓扑的不同层，以便有效利用网络能力。

2. 我们实现了具有网络拓扑感知的集体通信模式，降低它们对延迟的敏感度。为了做到这一点，我们使用自定义算法（例如递归加倍或减半）代替传统算法（如环），更改了集体的默认实现。

3. 就像排名作业一样，GenAI 作业会产生额外的胖流，这使我们很难在所有可能的网络路径上分配流量。这就要求我们进一步投资网络负载平衡和路由，以实现跨网络资源的最佳流量分配。

我们在 Networking @Scale 2023 上深入讨论了我们的 RoCE 负载平衡技术。

我们需要高效的数据存储解决方案来存储模型训练中使用的大量数据。这需要我们投资高容量和高速存储技术，以及为特定负载开发新的数据存储解决方案。

在未来几年中，我们将使用数十万个 GPU 处理更大量的数据，并应对更长的距离和延迟。我们将采用很多新的硬件技术（包括更新的 GPU 架构）并改进我们的基础设施。

这些挑战将推动我们以自己尚无法完全预测的方式来创新和适应变化。但有一件事是肯定的：我们这段旅程才刚刚开始。随着我们继续探索不断发展的 AI 格局，我们还在努力突破可能的边界。

原文链接：

https://engineering.fb.com/2024/06/12/data-infrastructure/training-large-language-models-at-scale-meta/

声明：本文为 InfoQ 翻译，未经许可禁止转载。