利用 MRC（多路径可靠连接）释放大规模 AI 训练网络的潜力

前沿模型的训练依赖于可靠的超级计算机网络，这些网络能够在 GPU 之间快速传输数据。为了使这一过程更快、更高效，OpenAI 与 AMD、Broadcom、Intel、Microsoft 和 NVIDIA 合作开发了 MRC（多路径可靠连接）：这是一种新颖的协议，可提升大型训练集群中 GPU 网络的性能和弹性。我们今天通过开放计算项目（OCP）发布了 MRC⁠（在新窗口中打开），以便让更广泛的行业能够使用它。 

每周有超过 9 亿人使用 ChatGPT，我们的系统正成为 AI 的核心基础设施，帮助全球各地的人们和企业利用日益强大的模型进行构建。在 Stargate⁠诞生之前，我们在几年的时间里，与合作伙伴密切协作，精心共同开发、启动并维护了我们的前三代超级计算机。这段宝贵的经验让我们坚信，为了在 Stargate 的规模下高效利用算力并实现我们的使命，我们需要重新思考并大幅降低技术栈每一层的复杂性——包括网络设计。 

发布 MRC 规范是 OpenAI 整体算力战略的一部分：在关键基础设施层建立共享标准，有助于更高效、更可靠地扩展 AI 系统，并覆盖更广泛的合作伙伴生态系统。在本文中，我们将介绍 MRC 的设计，包括：i) 它如何使我们能够构建多平面高速网络，以创建冗余来抵御网络故障，同时使用更少的组件和更少的电力；ii) MRC 的自适应数据包喷洒如何几乎消除核心拥塞；iii) 我们的部署如何使用静态源路由来绕过故障并消除整类路由故障。这些优势相辅相成，使我们能够更快地向所有人交付更好的模型。

为什么网络需要新的设计

在训练大型 AI 模型时，单个步骤可能涉及数百万次数据传输。一次传输的延迟可能会波及整个任务，导致 GPU 处于空闲状态。网络拥塞、链路和设备故障是传输延迟和抖动最常见的原因。

随着集群规模的增大，这些问题会变得更加频繁，也更难解决。这使得网络技术成为 Stargate 设计的关键部分。 

为了实现当前 Stargate 超级计算机的规模，我们面临着两个关键的网络挑战。首先，只要有可能，我们就应尽量减少网络拥塞的可能性。有些瓶颈是不可避免的，例如两个 GPU 同时向同一目的地发送数据。但在这些情况之外，我们应通过设计来避免拥塞。 

其次，我们需要尽量减少网络故障对训练任务本身的影响。在足够大的规模下，即使最好的网络也会存在持续的链路和交换机故障背景水平。此前，单次故障往往会导致训练任务崩溃，迫使任务从保存的检查点重新开始，或者在网络重新计算路由时使进度停滞数秒。这样的中断在 GPU 周期和时间上代价高昂。对于同步预训练——即来自多台计算机的众多 GPU 以锁步方式协同训练一个 AI 模型——尤其如此。我们运行的任务规模越大，任何单次链路抖动或故障的影响就越大。这些工作负载充当了一种“故障放大器”，因此防止这种情况变得至关重要。

我们的答案：MRC

我们的目标不仅是构建一个快速的网络，还要构建一个即使在出现故障时也能提供非常可预测的性能的网络，以保持训练任务的持续推进。

为了实现这种可靠性，我们的 Scaling 团队在过去两年中与 AMD⁠（在新窗口中打开）、Broadcom⁠（在新窗口中打开）、Intel、Microsoft⁠（在新窗口中打开） 和 NVIDIA⁠（在新窗口中打开） 合作，开发了一种构建和运营我们网络的新方法。这项工作的成果是一种我们称之为 多路径可靠连接（Multipath Reliable Connection，MRC）⁠（在新窗口中打开） 的技术。它是一种内置于最新 800Gb/s 网络接口中的新型网络协议，使我们能够将单次传输分散到数百条路径上，在微秒级时间内绕过故障，并运行更简单的网络控制平面。

MRC 扩展了 RDMA over Converged Ethernet（RoCE）——这是由 InfiniBand Trade Association（IBTA）制定的一项标准，可在 GPU 和 CPU 之间实现硬件加速的远程直接内存访问。它借鉴了 Ultra Ethernet Consortium（UEC）开发的技术，并通过基于 SRv6 的源路由对其进行了扩展，以支持大规模 AI 网络结构。

MRC 已部署在 OpenAI 所有用于训练前沿模型的最大 NVIDIA GB200 超级计算机中，包括我们在德克萨斯州阿比林与 Oracle Cloud Infrastructure（OCI）合作的站点，以及 Microsoft 的 Fairwater 超级计算机。MRC 已被用于训练多个 OpenAI 模型，利用了 NVIDIA 和 Broadcom 的硬件。目前，MRC 规范已作为 Open Compute Project（OCP）贡献提供，供社区使用和在此基础上构建。我们合著了一篇详细介绍我们经验的论文，“Resilient AI Supercomputer Networking using MRC and SRv6”⁠（在新窗口中打开）。

基础：多平面网络

构建高度弹性的网络要求我们从一种网络拓扑开始，该拓扑具有足够的自然冗余，即使网络中的链路或交换机发生故障，所有流量也能获得良好的性能。

我们不再将每个网络接口视为一条 800Gb/s 链路，而是将其拆分为多条较小的链路。例如，一个接口可以连接到八个不同的交换机。这样，你就可以构建八个独立的并行网络（或称为平面），每个平面以 100Gb/s 运行，而不是构建一个单一的 800Gb/s 网络。

这一改变对集群的形态产生了很大影响。一台能够以 800Gb/s 连接 64 个端口的交换机，改为可以以 100Gb/s 连接 512 个端口。这使得你只需两层交换机就能构建一个完全连接约 131,000 个 GPU 的网络。而传统的 800Gb/s 网络则需要三到四层交换机。

其结果是一个成本更低、功耗更低，并且比传统网络设计提供更多路径多样性的网络。它还允许更多流量保留在 Tier 0 交换机本地，从而可以提升性能。

然而，所有这些路径多样性可能难以被充分利用。用于 AI 训练的传统网络协议通常要求每次传输都遵循单一路径，以确保数据包按顺序到达。在大型多平面网络中，这会造成两个问题：不同的流可能在同一条链路上冲突并造成拥塞，而且每个流只能使用可用平面中的一个。如果我们不做其他任何改变，多平面网络将导致严重的拥塞和糟糕的整体性能。

MRC 的转变：将数据包喷洒到数百条路径上

MRC 从根本上改变了这一模型。MRC 不再将一次传输分配给一条路径，而是将单次传输的数据包喷洒到我们网络中数百条路径上，跨越所有不同的平面。数据包可能会乱序到达，但所有 MRC 数据包都包含其最终内存地址，因此目的地可以在数据包到达时将其直接送入内存。

每个 MRC 连接会为其使用的众多路径保存少量状态。如果它检测到某条路径正在变得拥塞，就会将该路径换成另一条，从而平衡整个网络的负载。如果它丢失了一个数据包，它会采取安全选项：假设该路径上可能发生了故障，并立即停止使用它，同时重传任何可能丢失的数据包。在 MRC 停用一条路径后，它会发送探测数据包来检查是否真的发生了故障，如果确实发生了，再检查它是否已经恢复。

不过，故障并非导致丢包的唯一原因；另一个常见的丢包来源是目的地的拥塞。MRC 通过数据包修剪来处理这一问题。如果交换机因拥塞而要丢弃某个数据包，它会修剪掉负载，仅将头部转发到目的地，从而触发显式重传请求。数据包修剪减少了误报，避免我们错误地将丢包判定为路径故障。

多平面拓扑、喷洒、负载均衡和修剪的结合，意味着 MRC 连接可以在微秒级检测网络故障并绕行，从而将对同步训练任务的影响降至最低。相比之下，传统网络架构可能需要数秒甚至数十秒才能稳定并绕过故障。

用源路由取代动态路由

MRC 让我们能够进一步简化网络。

传统上，交换机运行 BGP（边界网关协议）等动态路由协议来计算可用路径并绕过故障。但交换机是运行复杂软件的复杂设备。当它们以隐蔽的方式发生故障时，这些问题可能难以诊断，并且在修复之前会导致连接失败。

有了 MRC，动态路由变得不那么必要。如果数据包在某条路径上丢失，MRC 就停止使用该路径。我们采取了更激进的方法：禁用动态路由，改用 IPv6 分段路由（或 SRv6）。SRv6 允许发送方直接指定每个数据包应通过网络的路径。它通过将交换机标识符序列嵌入每个数据包的目的地址来实现这一点。

具体来说：在转发时，交换机会检查自身标识符是否存在。如果存在，它会通过移动目的地址来移除该标识符，从而露出下一个交换机的标识符。然后，交换机在静态路由表中查找该标识符，以确定数据包的下一个发送位置。与动态路由不同，这个静态路由表在交换机首次配置时就已设定，此后永不更改。

MRC 使用 SRv6 将数据包喷洒到所有网络平面，以及每个平面上的多条路径。如果某条路径发生故障，MRC 只需停止使用它。交换机无需重新计算路由，也无需做任何其他事情，只需盲目遵循配置好的静态路由即可。

由 Oracle Cloud Infrastructure (OCI) 在德克萨斯州阿比林建造的 StarGate 超级计算机

生产环境中的实际表现

我们的训练网络拥有数百万条链路。虽然这些网络质量很高，但在足够大的规模下，一些链路抖动是不可避免的。在训练期间，我们观察到 tier-0 和 tier-1 交换机之间每分钟发生多次链路抖动，但 MRC 确保了它们对我们的同步预训练任务没有可测量的影响。事实上，它们的影响非常小，我们甚至不需要优先立即修复这些链路。

会出问题的不只是链路。在为 ChatGPT 和 Codex 训练最新的前沿模型期间，我们不得不重启了四台一级交换机。此前，重启交换机需要运维团队非常小心，以免干扰训练。有了 MRC，我们甚至不需要与集群中运行训练任务的团队进行协调。许多链路修复也是如此。过去，当需要进行维护工作时，我们会与运维团队协调以禁用链路。现在，我们可以在链路仍在服务中时对其进行修复。如果一条链路运行得足够好，MRC 就会使用它。如果不是，MRC 会避开它，直到它被修复。

在 MRC 之前，如果 GPU 网络接口与 0 级交换机之间的链路发生故障，训练任务就会失败。有了 MRC，任务可以以合理的性能继续运行。如果一个 8 端口网络接口失去一个端口，最大速率会降低八分之一。MRC 会检测到这一点，重新计算路径以避开故障平面，并立即通知对等方不要将该平面用于入站流量。大多数故障链路会在一分钟内恢复，届时 MRC 会将该平面重新投入使用。

由 GPU 接口链路丢失引起的减速在不同训练任务中有所不同，但在实践中，往往显著小于所损失的物理容量。

关键改进

在扩展我们的超级计算机时，MRC 最终为我们带来了三个关键优势。

首先，它让我们能够仅使用两级以太网交换机，为拥有超过 100,000 个 GPU 的超级计算机构建多平面高速网络。这为我们提供了足够的冗余来抵御网络故障，同时比同等的三级或四级单平面网络消耗更少的电力。

其次，MRC 的自适应数据包喷洒负载均衡效果非常好，以至于我们在网络核心中几乎看不到拥塞。这大大减少了同步训练期间流之间的吞吐量变化，而在同步训练中，消除异常值对性能至关重要。这也意味着，当多个任务共享集群时，它们不会相互影响性能。

最后，MRC 使用 SRv6 源路由快速绕过故障，并仅通过正常路径发送数据包。这使我们能够运行简单的静态网络控制平面，并消除整类动态路由故障行为。

开放协议

MRC 显著提升了我们训练新前沿模型的能力，并确保我们的网络跟上研究人员雄心勃勃的 AI 路线图。它比以前的方法提供了显著的改进，并有助于加速我们可靠地将 AGI 的益处带给每个人的目标。我们为促成这一成果的跨行业合作感到自豪。

随着训练集群的持续增长，网络设计越来越决定了可用算力中有多少能被真正利用。MRC 帮助我们在拥塞、链路故障和维护事件中保持 GPU 同步运行，而这些情况在过去会中断训练。在有意义的规模下，这种可靠性和效率不是可有可无的；它是使同步前沿模型训练成为可能的一部分。

致谢

跨行业合作对于解决人工智能的许多最棘手问题仍然至关重要。我们感谢与 AMD、Broadcom、Intel、Microsoft 和 NVIDIA 的合作，共同开发 MRC；也感谢 Microsoft Azure、OCI、NVIDIA 和 Arista 与我们合作，将其大规模部署。我们都致力于推动生态系统的发展，并期待看到业界未来将 MRC 带向何方。