2026 年，训练一个前沿 AI 模型需要数万个 GPU 协同工作数月。但制约训练速度的关键因素往往不是 GPU 算力，而是连接这些 GPU 的网络。当一条链路拥塞或一台交换机故障就能让整个训练任务停滞、导致数千块昂贵加速器空转时，网络就成为 AI 基础设施的决定性瓶颈。
OpenAI 的回应是 MRC（Multipath Reliable Connection，多路径可靠连接），一种与 AMD、Broadcom、Intel、Microsoft、NVIDIA 联合开发的新型传输协议，并通过 Open Compute Project（OCP）以开放规范形式发布。MRC 已在 OpenAI 和 Microsoft 数据中心投入生产，用于训练最新前沿模型。本文分析传统网络协议为何在 AI 规模下失效、MRC 的架构如何针对性解决这些问题，以及其开源发布对 AI 基础设施未来意味着什么。
瓶颈转移：网络为何在 AI 规模下崩溃
关于 AI 训练瓶颈的标准叙事集中在 GPU 稀缺性上。但在前沿模型实际运行的数据中心里，约束已经转移。当集群规模超过 10 万块 GPU 时，网络 fabric 成为整体吞吐量的限制因素。
传统协议如何失效
当前大规模 AI 训练主要运行在 RoCEv2（RDMA over Converged Ethernet）上，它将 InfiniBand 的可靠连接语义扩展到以太网。RoCEv2 对传统数据中心负载表现良好，但应用于大规模同步 AI 训练时存在三个根本性缺陷：
单路径约束。 RoCEv2 为每个连接建立单条路径。即使物理网络在两块 GPU 之间提供多条路径，RoCEv2 流量仍遵循由 ECMP 哈希确定的单一路由。这导致可用带宽闲置，并在多个流碰撞到同一路径时形成拥塞热点。
故障处理能力差。 当链路故障或交换机重启时，RoCEv2 连接必须重新建立，这个过程可能需要毫秒到秒级。在同步训练中，所有 GPU 必须同时完成每次迭代，即使短暂的干扰也会迫使整个任务暂停。单台交换机故障可能级联为集群范围的停滞。
恢复效率低下。 RoCEv2 使用 go-back-N 重传：当丢包时，发送方重传该包及当前窗口中所有后续包。这产生不必要的流量，放大拥塞而非缓解拥塞。
这些限制随着集群规模增长而叠加。Dell'Oro Group 指出，以太网已经超越 InfiniBand 成为 AI 后端网络的主导 fabric，但标准以太网传输并非为万亿参数模型训练的同步需求而设计。
空转 GPU 的经济学
财务 stakes 使这成为一个硬件优化问题。10 万块 GPU 集群代表数十亿美元的资本支出。当网络故障或拥塞导致这些 GPU 空转时，成本以每天数百万美元的训练进度损失来衡量。瓶颈不是 GPU 本身，而是连接它们的基础设施，这一模式在单个组件超越集成网络的速度时反复出现。
MRC 架构：三项设计原则
MRC 通过三项协同工作的架构创新解决这些限制：跨多路径的包喷洒、智能故障恢复，以及为 AI 负载设计的拥塞控制。
包喷洒：利用所有可用路径
MRC 的核心洞见是，单个 RDMA 连接不应绑定到单条网络路径。相反，MRC 同时在所有可用路径上分发包，并根据路径状况实时调整分配。
这种自适应包喷洒方法从根本上不同于 ECMP。传统 ECMP 基于流标识符的哈希将每个流分配到一条路径。如果两个大训练流哈希到同一路径，该路径拥塞而替代路径闲置。MRC 通过将路径选择变为逐包决策来避免这一问题，该决策由关于路径健康和负载的持续反馈驱动。
OpenAI 报告称，这种负载均衡效果足够好，他们在网络核心几乎看不到拥塞。通过均匀分散流量，MRC 防止了在同步训练中产生尾延迟的热点。
微秒级故障恢复
MRC 处理路径故障无需拆除和重建连接。协议在几个往返时间内（微秒而非毫秒）检测故障并自动重路由流量。这发生在 NIC 层面，无需涉及应用或网络控制平面。
快速检测与自动重路由的结合意味着，许多此前会中断训练的网络故障现在可以无影响地通过。训练任务继续运行，而网络在故障周围自愈。
选择性恢复与拥塞控制
MRC 用选择性确认（SACK）和否定确认（NACK）替代 go-back-N 重传。当丢包时，仅重传该包，而非整个窗口。这减少恢复流量，防止困扰 RoCEv2 的拥塞放大。
对于拥塞控制，MRC 实现了基于 Ultra Ethernet Consortium 规范的 Network-Signaled Congestion Control（NSCC）。NSCC 在路径层面而非网络层面运行，允许发送方基于每条路径的状况调整速率，而非对全局拥塞信号作出反应。它还整合了基于 RTT 的窗口控制，根据测量的往返时间调整发送速率。
从专有到开放：OCP 发布的意义
MRC 由 OpenAI、AMD、Broadcom、Intel、Microsoft、NVIDIA 联合开发，并于 2026 年 5 月通过 Open Compute Project 以开放规范形式发布。这一发布机制的选择具有战略意义。
为什么开放标准在 AI 规模下重要
AI 基础设施已变得过于庞大和复杂，封闭、垂直整合的系统难以高效扩展。10 万块 GPU 集群涉及多家供应商：NVIDIA 或 AMD 的 GPU、各供应商的 NIC、多家制造商的交换机、云服务商和 AI 实验室的软件栈。当网络协议是专有时，每家供应商必须协商互操作性，产生摩擦，拖慢部署并限制优化。
通过 OCP 发布 MRC，OpenAI 及其合作伙伴正在建立一个任何供应商都可以实现的共同基础。这校准了激励：NIC 制造商可以为 MRC 优化，交换机供应商可以验证兼容性，AI 实验室可以部署多供应商集群而无需协议层面的集成工作。
生产验证
MRC 不是研究原型。它已在 OpenAI 最大训练集群和 Microsoft Fairwater 超级计算机投入生产。NVIDIA 报告称 MRC 也在 Oracle Cloud Infrastructure 的 Abilene 数据中心使用。这些部署横跨多代硬件，包括 NVIDIA Blackwell 平台，并已被用于训练生产前沿模型。
这段生产历史对采用很重要。数据中心运营者对新网络协议持保守态度，因为故障代价高昂。MRC 的大规模部署提供了降低其他组织采用风险的验证。
行业联盟
MRC 联盟的广度值得注意。它包括 GPU 供应商（NVIDIA、AMD）、NIC 供应商（Broadcom、Intel）、云服务商（Microsoft）和 AI 实验室（OpenAI）。这不是单一供应商推动专有协议，而是行业范围对共同传输层的共识。
Dell'Oro Group 的分析将此解读为网络正在变得与计算同等重要的信号。从 InfiniBand 向以太网的转变已在进行中，而 MRC 通过使以太网适用于最大训练集群的协议强化了这一趋势。
对 AI 基础设施的影响
MRC 的发布影响超越包传输的技术细节。
基础设施成为差异化因素
当 GPU 计算可从多家供应商和云服务商获得时，连接这些 GPU 的基础设施效率成为竞争优势。采用 MRC 的集群可以维持更高的 GPU 利用率、更快从故障中恢复、扩展到更大的节点数。这将竞争基础从原始计算能力转向基础设施效率。
验证挑战
开源网络协议带来验证挑战。与软件不同，软件的正确性可以通过单元测试检验，网络协议必须在真实世界条件下验证：混合流量模式、硬件故障、 varying load。MRC 在 OpenAI 和 Microsoft 的生产部署提供了一种验证形式，但更广泛的采用将需要在多样化硬件和拓扑配置中的额外测试。
OCP 规范和参考实现为此验证提供了基础。随着更多供应商实现 MRC，协议将在超出原始开发者使用范围的场景中被测试，形成提高可靠性的反馈循环。
以太网角色的扩展
MRC 强化了一个已有趋势：以太网在 AI 后端网络中日益增长的作用。InfiniBand 历史上在高性能计算中占主导地位，但需要专用硬件和专业知识。以太网提供更广泛的供应商基础、更低的成本和运营熟悉度。MRC 解决了此前使以太网对同步训练吸引力较低的性能和可靠性差距。
据 Dell'Oro Group 数据，以太网在 2025 年已占 AI 后端网络收入的大部分。MRC 的发布通过提供使以太网适用于最大训练集群的标准协议，强化了这一轨迹。
常见问题
什么是 MRC，为什么创建它？
MRC（Multipath Reliable Connection，多路径可靠连接）是一种将 RDMA 语义扩展到在多条网络路径上分发流量的传输协议。它是因为传统协议如 RoCEv2 无法在 10 万+ GPU 集群中高效利用可用网络容量或快速从故障中恢复而创建的。
MRC 与 TCP 或标准 RDMA 有何不同？
TCP 在单条路径上运行，通过重传恢复丢包，对同步训练来说太慢。标准 RDMA（RoCEv2）也使用每条连接的单条路径和 go-back-N 恢复。MRC 在多条路径上喷洒包，选择性恢复，并在微秒级处理 NIC 层面的故障。
MRC 是否特定于 OpenAI 的基础设施？
不是。MRC 通过 Open Compute Project 以开放规范形式发布，已由 AMD、NVIDIA、Broadcom 等多家供应商实现。它已在 Microsoft 和 Oracle Cloud Infrastructure 部署，除 OpenAI 外。
MRC 会取代 InfiniBand 吗？
MRC 扩展了 RoCEv2，后者运行在以太网上。它不直接取代 InfiniBand，但使以太网在 AI 训练负载上更具竞争力。市场趋势显示以太网在 AI 后端网络中份额增长，MRC 通过解决以太网在同步训练上的历史局限加速了这一趋势。
MRC 需要什么硬件？
MRC 需要支持该协议的 NIC。AMD 已在其 Pensando Pollara 400 和 Vulcano 800 AI NIC 上实现 MRC。NVIDIA 在其 Spectrum-X 以太网平台上通过 ConnectX SuperNIC 支持 MRC。Broadcom 也宣布在其 Thor Ultra NIC 上支持。
参考资料
- OpenAI. "Supercomputer networking to accelerate large scale AI training." 2026年5月. https://openai.com/index/mrc-supercomputer-networking/
- Araujo, J., et al. "Resilient AI Supercomputer Networking using MRC and SRv6." arXiv:2605.04333, 2026年5月. https://arxiv.org/abs/2605.04333
- Open Compute Project. "Multipath Reliable Connection (MRC) Specification." https://www.opencompute.org/documents/ocp-mrc-1-0-pdf
- NVIDIA. "NVIDIA Spectrum-X Sets the Standard for Gigascale AI, Now With MRC." 2026年5月. https://blogs.nvidia.com/blog/spectrum-x-ethernet-mrc/
- AMD. "Next Gen Networking Transport for Large Scale AI Training." 2026年5月. https://www.amd.com/en/blogs/2026/next-gen-networking-transport-for-large-scale-ai-training.html
- AMD. "AMD and OpenAI Advance AI Networking at Scale with MRC." 2026年5月. https://www.amd.com/en/blogs/2026/amd-advances-ai-networking-at-scale-with-mrc.html
- Broadcom. "Enabling AI Networking @ Scale with Multi-path Reliable Connections (MRC)." 2026年5月. https://www.broadcom.com/blog/enabling-ai-networking-scale-with-multi-path-reliable-connections-mrc
- Dell'Oro Group. "OpenAI's MRC Initiative Reinforces Ethernet's Expanding Role in AI Back-end Networks." 2026年5月. https://www.delloro.com/openais-mrc-initiative-reinforces-ethernets-expanding-role-in-ai-back-end-networks/
- Futurum Group. "Can OpenAI's MRC Networking Protocol Redefine the Economics of AI Training?" 2026年5月. https://futurumgroup.com/insights/can-openais-mrc-networking-protocol-redefine-the-economics-of-ai-training/
- 4sysops. "Multipath Reliable Connection (MRC): a new, open networking protocol for AI supercomputers." 2026年5月. https://4sysops.com/archives/multipath-reliable-connection-mrc-a-new-open-networking-protocol-for-ai-supercomputers/