通过 MRC（多路径可靠连接）解锁大规模 AI 训练网络

超级计算机网络加速大规模AI训练

前沿模型训练依赖于可靠的超级计算机网络，这些网络能够在GPU之间快速传输数据。为了使其更快、更高效，OpenAI与AMD、博通、英特尔、微软和英伟达合作，开发了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

我们的目标不仅是构建一个快速的网络，还要构建一个即使在发生故障时也能提供高度可预测性能的网络，从而确保训练任务持续进行。

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

MRC 扩展了融合以太网上的远程直接内存访问（RoCE）——这是 InfiniBand 贸易协会（IBTA）的一项标准，可在 GPU 和 CPU 之间实现硬件加速的远程直接内存访问。它借鉴了超以太网联盟（UEC）开发的技术，并通过基于 SRv6 的源路由对其进行扩展，以支持大规模 AI 网络结构。

MRC 已部署在 OpenAI 所有用于训练前沿模型的最大型 NVIDIA GB200 超级计算机上，包括我们在德克萨斯州阿比林与甲骨文云基础设施（OCI）合作的站点，以及微软的 Fairwater 超级计算机。MRC 已被用于训练多个 OpenAI 模型，利用了来自 NVIDIA 和 Broadcom 的硬件。目前，MRC 规范已作为开放计算项目（OCP）的贡献提供，供社区使用和在此基础上进行开发。我们合著了一篇详细介绍我们经验的论文，题为《使用 MRC 和 SRv6 构建弹性 AI 超级计算机网络》。

基础：多平面网络

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

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

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

MRC 对多平面网络的支持意味着我们只需两层交换机就能连接超过十万块 GPU。与传统方案相比，这降低了所需功耗、减少了可能发生故障的组件数量，并降低了网络的总成本。

最终得到的网络比传统网络设计成本更低、功耗更低，并且为我们提供了更多的路径多样性。它还能让更多流量停留在第 0 层交换机本地，从而提升性能。

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

采用单路径数据流（例如经典的 RoCE 部署）时，单个链路经常会发生拥塞。由于集合通信对最差情况下的延迟非常敏感，这对 AI 训练工作负载的干扰尤其严重。

数据包流相互碰撞导致拥塞。动画由 Mark Handley 制作。

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

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

MRC 将数据包同时分散到多条路径上，从而减少了可能拖慢同步式 AI 训练的拥塞。

通过将流量分散到多条路径上，MRC 避免了网络中的热点，防止某些事务的耗时远长于其他事务。这就能避免影响同步 AI 训练的减速问题。

跨多条路径的数据包喷洒。动画制作：Mark Handley。

每个 MRC 连接会为其使用的多条路径维护少量状态信息。如果检测到某条路径出现拥塞，它就会将该路径替换为另一条，从而平衡整个网络的负载。如果发生丢包，它会采取安全策略：假设该路径上的某个环节可能已发生故障，立即停止使用该路径，并重传可能丢失的数据包。在 MRC 弃用一条路径后，它会发送探测包来检查是否真的发生了故障，如果确实有故障，则检查故障是否已恢复。

不过，故障并非导致丢包的唯一原因；另一个常见原因是目的端拥塞。MRC 通过数据包裁剪来处理这一问题。如果交换机因拥塞而本应丢弃某个数据包，它会裁剪掉有效载荷，仅将报头转发至目的端，从而触发显式的重传请求。数据包裁剪减少了误报情况——即我们错误地认为丢包就意味着路径发生故障。

这种多平面拓扑、喷洒、负载均衡与裁剪的组合，意味着 MRC 连接能够在微秒级时间尺度上检测网络故障并重新路由，从而将对同步训练任务的影响降至最低。相比之下，传统网络架构可能需要数秒甚至数十秒才能稳定下来并绕开故障。

用源路由替代动态路由

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

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

采用 MRC 后，动态路由的必要性大大降低。如果某个路径上发生数据包丢失，MRC 便会停止使用该路径。我们采取了更为激进的做法：禁用动态路由，改用 IPv6 段路由（即 SRv6）。SRv6 允许发送方直接指定每个数据包在网络中应走的路径。其实现方式是将一系列交换机标识符嵌入到每个数据包的目的地址中。

SRv6 允许发送方为每个数据包编码出其在网络中应走的完整路径。由于这种路径是确定性的，发送方可以独立地对特定路径上的拥塞或丢包做出反应。

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

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

由甲骨文云基础设施（OCI）在德克萨斯州阿比林建造的 Stargate 超级计算机

在生产环境中的实际表现

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

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

在一次训练运行期间捕获的真实数据，显示了 MRC 对一级交换机完全失效的响应。训练任务经历了短暂的减速，但很快恢复了正常。

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

由 GPU 接口链路丢失导致的减速，在不同训练任务中有所差异，但在实践中，其程度往往远小于实际损失的物理容量。

关键改进

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

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

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

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

开放协议

MRC显著提升了我们训练新一代前沿模型的能力，并确保我们的网络能够跟上研究人员雄心勃勃的AI发展路线图。与以往方法相比，它带来了重大改进，并有助于加速我们实现将AGI惠及所有人的可靠目标。我们为促成这一成果的跨行业合作感到自豪。

随着训练集群规模持续扩大，网络设计越来越决定了可用算力的实际利用率。MRC帮助我们让GPU在拥塞、链路故障以及以往会中断训练的维护事件中保持同步运行。在规模化部署中，这种可靠性和效率并非锦上添花，而是实现同步前沿模型训练的基础条件之一。

致谢

跨行业合作将继续成为解决AI领域诸多最棘手问题的关键。我们感谢与AMD、博通、英特尔、微软和英伟达合作开发MRC，也感谢微软Azure、OCI、英伟达和Arista与我们合作将其大规模部署。我们都共同致力于推动生态系统发展，并期待看到业界未来将MRC带向何方。