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

公众号新闻

2024-06-19 06:06

作者 | Meta 团队

译者 | 王强

策划 | Tina

在我们继续将 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 模型的网络通信在两个集群上都有很高的性能：

我们将由不同模型、数据和管道并行性产生的通信模式分配给网络拓扑的不同层，以便有效利用网络能力。
我们实现了具有网络拓扑感知的集体通信模式，降低它们对延迟的敏感度。为了做到这一点，我们使用自定义算法（例如递归加倍或减半）代替传统算法（如环），更改了集体的默认实现。
就像排名作业一样，GenAI 作业会产生额外的胖流，这使我们很难在所有可能的网络路径上分配流量。这就要求我们进一步投资网络负载平衡和路由，以实现跨网络资源的最佳流量分配。

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