用 MRC（Multipath Reliable Connection）解锁大规模 AI 训练网络

前沿模型训练依赖可靠的 supercomputer 网络，以便在 GPU 之间快速移动数据。为了让这一过程更快、更高效，OpenAI 与 AMD、Broadcom、Intel、Microsoft 和 NVIDIA 合作开发了 MRC（Multipath Reliable Connection）：一种新协议，可提升大型训练集群中的 GPU networking 性能和韧性。我们今天通过 Open Compute Project (OCP) 发布了 MRC（在新窗口中打开），以便更广泛的行业使用它。

每周有超过 900M 人使用 ChatGPT，我们的系统正在成为 AI 的核心基础设施，帮助世界各地的人和企业基于能力不断提升的模型进行构建。在 Stargate 启动之前的几年里，我们与合作伙伴密切协作，谨慎地共同开发、启动并维护了前三代 supercomputer。这段宝贵经验强化了我们的判断：要在 Stargate 的规模上高效使用 compute，并成功推进我们的使命，我们需要重新思考并大幅降低 stack 每一层的复杂性，包括 network design。

发布 MRC specification 是 OpenAI 整体 compute strategy 的一部分：在关键基础设施层采用共享标准，有助于更高效、更可靠地扩展 AI 系统，并覆盖更广泛的合作伙伴生态。在本文中，我们将介绍 MRC 的设计，包括：i) 它如何使我们能够构建 multi-plane high-speed networks，通过冗余来承受网络故障，同时使用更少组件和更低功耗；ii) MRC 的 adaptive packet spraying 如何几乎消除 core congestion；iii) 我们的部署如何使用 static source routing 绕过故障，并消除整类 routing failure。这些收益共同让我们能够更快地向所有人交付更好的模型。

训练大型 AI 模型时，单个 step 可能涉及数百万次 data transfer。一次 transfer 延迟到达，就可能影响整个 job，导致 GPU 空闲。Network congestion、link failure 和 device failure 是 transfer 中 delay 与 jitter 最常见的来源。

随着集群规模增加，这些问题会更加频繁，也更难解决。这使得 networking technology 成为 Stargate 设计中的关键部分。

为了支持当前规模的 Stargate supercomputer，我们面临两个关键网络挑战。首先，在任何可能的情况下，我们都应尽量降低 network congestion 的可能性。某些瓶颈不可避免，例如两个 GPU 同时向同一 destination 发送数据。但在这些情况之外，我们应通过设计避免 congestion。

第二，我们需要尽量降低网络故障对 training job 本身的影响。在足够大的规模下，即使是最好的网络也会持续出现一定背景水平的 link 和 switch failure。过去，单个故障往往会导致 training job 崩溃，迫使其从已保存的 checkpoint 重启，或在网络重新计算 route 时停滞数秒。这类中断在 GPU cycles 和时间上都代价高昂。对于 synchronous pretraining 尤其如此：许多计算机上的许多 GPU 需要同步协作来训练一个 AI 模型。运行的 job 越大，任何一次 link flap 或 failure 的影响就越大。这类 workload 会成为一种“failure amplifier”，因此防止这种情况变得至关重要。

我们的目标不只是构建一个快速网络，还要构建一个即使在出现故障时也能提供高度可预测性能的网络，让 training job 持续推进。

MRC 扩展了 RDMA over Converged Ethernet (RoCE)——这是 InfiniBand Trade Association (IBTA) 的标准，用于在 GPU 和 CPU 之间实现 hardware-accelerated remote direct memory access。它借鉴了 Ultra Ethernet Consortium (UEC) 开发的技术，并通过基于 SRv6 的 source routing 进行扩展，以支持大规模 AI networking fabrics。

MRC 已经部署在 OpenAI 用于训练前沿模型的所有最大规模 NVIDIA GB200 supercomputer 中，包括我们在 Texas Abilene 的 Oracle Cloud Infrastructure (OCI) 站点，以及 Microsoft 的 Fairwater supercomputer。MRC 已用于训练多个 OpenAI 模型，使用了 NVIDIA 和 Broadcom 的硬件。今天，MRC specification 作为 Open Compute Project (OCP) 贡献向社区开放，供其使用和继续构建。我们共同撰写了一篇论文，详细介绍相关经验，“Resilient AI Supercomputer Networking using MRC and SRv6”（在新窗口中打开）。

构建高韧性网络要求我们从具备足够自然冗余的 network topology 入手，使所有 flow 即使在网络中的 link 或 switch 发生故障时，也能获得良好性能。

我们不把每个 network interface 视为一条 800Gb/s link，而是将其拆分为多条更小的 link。例如，一个 interface 可以连接到八台不同的 switch。这样你就可以构建八个独立的 parallel network，或称 plane，每个以 100Gb/s 运行，而不是构建单个 800Gb/s network。

这一变化会显著改变集群形态。一台可连接 64 个 800Gb/s port 的 switch，可以改为连接 512 个 100Gb/s port。这使你能够仅用两层 switch 构建一个完整连接约 131,000 个 GPU 的网络。传统的 800Gb/s network 则需要三层或四层。

结果是一个成本更低、功耗更低、path diversity 高于传统网络设计的网络。它还允许更多 traffic 保持在 Tier 0 switch 本地，从而提升性能。

不过，充分利用所有这些 path diversity 可能并不容易。用于 AI training 的传统网络协议通常要求每次 transfer 沿单一路径进行，以确保 packet 按顺序到达。在大型 multi-plane network 中，这会产生两个问题：不同 flow 可能在同一 link 上相撞并造成 congestion；每个 flow 也只能使用可用 plane 中的一个。如果其他方面不做改变，multi-plane network 会导致显著的 congestion 和较差的整体性能。

MRC 从根本上改变了这一模型。MRC 不再把一次 transfer 分配到一条路径上，而是把单次 transfer 的 packet 分散喷洒到穿越我们网络的数百条路径上，并覆盖所有不同的 plane。Packet 可以乱序到达，但所有 MRC packet 都包含其最终 memory address，因此 destination 可以在 packet 到达时将其写入 memory。

每个 MRC connection 会为其使用的许多路径保留少量 state。如果检测到某条路径开始 congestion，它会将该路径替换为另一条路径，从而平衡网络负载。如果它丢失了一个 packet，则采取保守做法：假设该路径上可能有某处发生故障，并立即停止使用该路径，同时重传任何可能丢失的 packet。MRC 淘汰一条路径后，会发送 probe packet 来检查是否确实存在故障；如果存在，也检查其是否已经恢复。

不过，故障并不是 packet loss 的唯一原因；另一个常见来源是 destination 处的 congestion。MRC 通过 packet trimming 处理这一点。如果 switch 原本会因 congestion 丢弃一个 packet，它会裁掉 payload，只将 header 转发到 destination，从而触发显式 retransmission request。Packet trimming 减少了 false positive，即我们错误地认为一次 loss 意味着某条路径已经故障的情况。

multi-plane topology、spraying、load-balancing 和 trimming 的组合意味着，MRC connection 可以在微秒级时间尺度上检测网络故障并绕过它们，最大限度降低对 synchronous training job 的影响。相比之下，传统 network fabric 可能需要数秒甚至数十秒才能稳定下来并绕过故障。

MRC 让我们可以进一步简化网络。

传统上，switch 运行 BGP (Border Gateway Protocol) 等 dynamic routing protocol 来计算可用路径并绕过故障。但 switch 是运行复杂软件的复杂设备。当它们以微妙方式失效时，这些问题可能难以诊断，并会在修复之前导致 connection failure。

有了 MRC，dynamic routing 变得不那么必要。如果 packet 在某条路径上丢失，MRC 就会停止使用该路径。我们采取了更彻底的方式：禁用 dynamic routing，改用 IPv6 Segment Routing（或 SRv6）。SRv6 允许 sender 直接指定每个 packet 应通过网络走哪条路径。它通过将 switch identifier 的序列嵌入每个 packet 的 destination address 来做到这一点。

拆开来看：转发时，switch 会检查是否存在自己的 identifier。如果存在，它会通过移位 destination address 来移除该 identifier，从而露出下一个 switch 的 identifier。然后 switch 会在 static routing table 中查找该 identifier，以确定下一步将 packet 发往何处。与 dynamic routing 不同，这个 static routing table 在 switch 首次配置时设置，之后永不更改。

MRC 使用 SRv6 将 packet 同时喷洒到所有 network plane，以及每个 plane 上的多条路径。如果某条路径故障，MRC 只需停止使用它。Switch 不需要重新计算 route，也不需要做任何其他事情，只需盲目遵循它们被配置好的 static route。

我们的训练网络有数百万条 link。虽然这些网络质量很高，但在足够规模下，一些 link flap 不可避免。在训练过程中，我们观察到 tier-0 与 tier-1 switch 之间每分钟会出现多次 link flap，但 MRC 确保它们对我们的 synchronous pretraining job 没有可测量影响。事实上，其影响小到我们甚至不需要优先立即修复这些 link。

并不是只有 link 会故障。在最近一个面向 ChatGPT 和 Codex 的前沿模型训练期间，我们不得不重启四台 tier-1 switch。过去，重启一台 switch 需要 operations team 非常谨慎，以免干扰训练。有了 MRC，我们甚至不需要与在该集群中运行 training job 的团队协调。许多 link repair 也是如此。过去当需要维护时，我们会与 operations team 协调以禁用某条 link。现在我们可以在 link 仍处于服务状态时进行维修。如果一条 link 工作状况足够好，MRC 就会使用它。如果不是，MRC 会避开它，直到它被修复。

在 MRC 之前，如果 GPU 的 network interface 与 tier-0 switch 之间的 link 发生故障，training job 就会失败。有了 MRC，job 可以以合理性能继续运行。如果一个 8-port network interface 丢失一个 port，最高速率会降低八分之一。MRC 会检测到这一点，重新计算路径以避开故障 plane，并立即告知 peer 不要将该 plane 用于 inbound traffic。大多数故障 link 会在一分钟内恢复，届时 MRC 会重新启用该 plane。

由 GPU interface link 丢失造成的 slowdown 在不同 training job 中有所不同，但在实践中，往往显著低于物理容量损失的比例。

MRC 最终在扩展 supercomputer 时为我们带来三项关键优势。

首先，它让我们能够仅使用两层 Ethernet switch，为超过 100,000 个 GPU 的 supercomputer 构建 multi-plane high-speed networks。这为我们提供了足够冗余来承受网络故障，同时功耗低于等价的三层或四层 single-plane network。

第二，MRC 的 adaptive packet spraying 能够实现足够好的 load-balance，使我们基本看不到网络 core 中的 congestion。这大幅减少了 synchronous training 期间不同 flow 之间 throughput 的波动；在这种训练中，消除 outlier 对性能至关重要。这也意味着当多个 job 共享同一集群时，它们不会影响彼此性能。

最后，MRC 使用 SRv6 source routing 快速绕过故障，并只通过可工作的路径发送 packet。这使我们能够运行一个简单的 static network control plane，并消除整类 dynamic routing failure 行为。

MRC 显著提升了我们训练新前沿模型的能力，并确保我们的网络跟得上研究人员雄心勃勃的 AI roadmap。它相较以往方法带来了重要改进，并帮助加快我们可靠地把 AGI 的益处带给所有人的目标。我们为促成这一成果的跨行业协作感到自豪。

随着训练集群持续增长，network design 越来越决定可用 compute 中有多少能够被真正利用。MRC 帮助我们让 GPU 在 congestion、link failure 和 maintenance event 中保持协同运行，而这些事件过去会中断训练。在有意义的规模下，这种可靠性和效率并不是可有可无的附加项；它是 synchronous frontier model training 得以实现的一部分。

致谢

跨行业协作将继续是解决 AI 许多最难问题的关键。我们感谢与 AMD、Broadcom、Intel、Microsoft 和 NVIDIA 在开发 MRC 上的合作，也感谢 Microsoft Azure、OCI、NVIDIA 和 Arista 与我们合作进行大规模部署。我们共同致力于推进生态系统发展，并期待看到行业未来如何应用 MRC。