← 返回 PaperDaily 大模型与智能体

OpenAI等联合提出MRC：开放网络的新补丁

这篇论文不玩“另起炉灶”，而是直接给RoCEv2做增量升级：多路径喷发、选择性确认、快速故障切换一口气补齐。对大规模AI训练来说，网络不是配角，卡住一次就是全员陪跑。

龙哥读论文 阅读 4 查看原文
#AI科研 #人工智能
OpenAI等联合提出MRC：开放网络的新补丁
🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！
👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥推荐理由：
这篇论文不玩“另起炉灶”，而是直接给RoCEv2做增量升级：多路径喷发、选择性确认、快速故障切换一口气补齐。对大规模AI训练来说，网络不是配角，卡住一次就是全员陪跑。


原论文信息如下：
论文标题:
The Multipath Reliable Connection (MRC) Transport
发表日期:
2026年06月 发表单位:
Advanced Micro Devices Inc, Broadcom Inc, Microsoft Corp, NVIDIA Corp, OpenAI OpCo LLC, Intel Corp 原文链接:
https://arxiv.org/pdf/2606.18170v1.pdf 开源代码链接:
https://github.com/opencomputeproject/OCP-Multipath-ReliableConnection 项目链接:
https://github.com/opencomputeproject/OCP-Multipath-ReliableConnection

MRC传输协议：为大规模AI训练量身定制的开放标准

大模型训练最怕什么？不是算力不够，而是网络在关键时刻掉链子。GPU 再强，梯度同步卡在链路抖动、丢包重传、路径故障上，集群照样会“全员等车”。这篇论文提出的 MRC（Multipath Reliable Connection，多路径可靠连接），就是专门给大规模 AI/ML 训练网络补短板的开放传输协议。
它的思路很直接：不推翻 RoCEv2，而是在它上面做“增量升级”。保留业内熟悉的可靠连接语义和软件模型，再补上多路径喷流、选择性确认、快速故障切换、拥塞反馈和端点级可达性信号。说白了，就是让传统 RDMA 还能继续用，但别再一条路走到黑。
封面：MRC 把 RoCEv2 的单路径可靠连接，升级成适合 AI 训练的大规模多路径传输。

痛点直击：RoCEv2为何不堪重负？

要理解 MRC，得先看它在修什么。今天大规模训练网络的主流开放标准是 RoCEv2 的 Reliable Connection（RC，可靠连接）。它的优点很朴素：语义清楚、硬件和软件都熟、部署门槛低。问题也很朴素：太像“单车道高速”，车多了就堵，路坏了就停。
论文把 RC 的缺点概括得很到位：第一，RC 基本是单路径，靠 ECMP 哈希决定路由，端点几乎没法主动调度；第二，常见的拥塞控制要么依赖无损以太网，要么对大规模集群并不友好；第三，一旦链路、端口或路径出问题，RC 对故障的恢复非常被动，往往只能等控制平面收敛或者超时重传。
这在 AI 训练里尤其致命。训练任务不是普通网页请求，它最怕长尾延迟。一次同步通信被拖慢，整个 step 都要陪跑；如果尾延迟反复抖动，吞吐会明显掉下来，集群效率也会变得很难看。于是，网络不再是“配角”，而是直接决定训练成本的核心部件。
这也是为什么 MRC 的定位不是“另起炉灶”，而是“在现有生态上补齐缺口”。它试图解决的不是单个小 bug，而是大规模 AI 训练网络的三件大事：多路径利用率、可靠性恢复速度、故障韧性。

MRC核心原理解读：多路径、可靠性与弹性

MRC 的核心不是“把包乱扔”，而是把“乱扔”变成可控的工程能力。它围绕一条主线展开：端点主动选路，网络负责承载，接收端负责反馈，控制器负责配置。四者配合起来，才能让多路径既能跑满，又不至于失控。
先看最关键的概念：Entropy Value，EV（熵值）。它是 MRC 里决定单个包走哪条路的“旋钮”。请求端在每个包上带上 EV，并按包级别变化它，让同一个连接的流量可以被喷洒到多条 fabric 路径上。这样一来，单 QP（Queue Pair，队列对）不再被锁死在一条路径上，路径容量也不再白白闲着。
表1
表1：MRC 传输原语总览。表中把多路径、多平面、在途约束、可靠性恢复、拥塞控制和快速故障切换拆成了若干原语，并标出哪些是必须实现、哪些是可选增强。MRC 的思路很工程化：先保证正确性，再按硬件能力逐步加料。
EV 不是只有一种用法。论文给了三类机制：一类是今天就能用的 ECMP 哈希；一类是 Structured EV，把路径信息编码进 UDP 源端口和 IPv6 flow label；还有一类是基于 SRv6（Segment Routing over IPv6，基于 IPv6 的段路由） 的显式源路由。三者共享同一套 EV 抽象，意思是：底层硬件支持到哪一步，MRC 就能往哪一步落地，不必一上来就换整套网络栈。
但多路径有个老问题：乱序。包一旦喷到不同路径，接收端收到的顺序就可能像被猫踩过的毛线团。MRC 的处理方式不是假装没看见，而是引入 Maximum PSN Range，MPR（最大包序号范围），把在途窗口严格限定住。这样请求端不会无限制地发，接收端也不会被乱序缓存撑爆。简单理解，就是给“包可以乱飞”这件事加上一个安全边界。
可靠性方面，MRC 也比传统 RC 更细。它引入 SACK（Selective ACK，选择性确认） 和 NACK（Negative ACK，否定确认）。SACK 不再只告诉发送端“我大概收到了”，而是明确指出哪些包到了、哪些还缺；NACK 则在确定丢失或资源耗尽时，直接把“该重传了”这件事提前说出来。对训练网络来说，这种反馈比死等超时靠谱得多。
表2
表2：MRC 头部改造一览。可以看到，MRC 并不是把协议完全推翻，而是在 BTH（基础传输头）上增加少量标志位和新头部，例如 TSETH、METH、SETH、NETH、PETH、ERTH、EETH 等，用更细的控制信息支撑多路径、可靠性和端点操作。
这里还有一个很实用的小设计：Trimmed Packet（裁剪包）。当网络里发生丢弃时，交换机不一定要把整包都转发过去，保留头部就够了，接收端据此快速发 NACK。这样做的好处很现实：损失信号更快到达，重传更早启动，别让超时定时器成了“最后一个知道真相的人”。

技术细节：MRC如何实现快速故障切换与精准拥塞控制？

MRC 真正“像样”的地方，不是多塞了几个头部字段，而是把故障恢复和拥塞控制做成了端到端闭环。它不是只靠控制平面慢悠悠地修路，而是让端点和数据平面直接参与判断。
先说故障切换。MRC 定义了 EV Probes（EV 探测） 和 Port Status Update（端口状态更新） 两种端点级操作。前者用来验证某条 EV 对应的路径是否还活着，后者则直接把本地端口健康状态上报出去。这样一来，路径坏了不必等控制平面慢半拍，端点就能先把“坏路”踢出候选集。
再说拥塞控制。论文提到 MRC 支持一种面向发送端的窗口型算法 NSCC。这里 NSCC 的全称是 Window-based, SACK-clocked ECN+RTT congestion control，中文可以理解为“基于窗口、由 SACK 驱动、结合 ECN 和 RTT 的拥塞控制”。它依赖 MRC 统一标准化的反馈信号：ECN 标记、接收端累计收到的字节数、以及接收端侧的拥塞惩罚信息。
这里最值得注意的是，MRC 还支持 host backpressure（主机反压）。很多协议只盯着链路拥塞，却忽略了接收端主机自己的内存和处理队列也会堵。MRC 把这层压力也显式反馈给发送端，避免网络没爆、主机先爆。这个设计很像给协议装了“体温计”，不是只看表面流量，还看内部器官是否在抗议。
更细一点看，MRC 还把 RTT 测量做得更实用。请求端可以在包里塞时间戳，接收端把时间戳反射回来；如果接收端处理开销比较大，还能上报 service-time compensation（服务时间补偿），把主机处理时间从 RTT 里减掉。这个细节很重要，因为训练流量里主机处理延迟并不总是可以忽略，测不准 RTT，拥塞控制就容易“瞎猜”。
还有一个很工程化的点：MRC 允许把数据流、重传流和控制流分到不同的 DsCP traffic classes。这里 DsCP 可以理解为数据平面里的差分服务代码点。把重传和控制包放到更高优先级，能减少“救火包”被普通数据包淹没的概率。对于尾延迟敏感的同步训练，这种小分流经常比大口号更值钱。
从机制上看，MRC 的关键不是某一个点多聪明，而是各个点之间能互相咬合：EV 负责选路，MPR 负责约束在途量，SACK/NACK 负责恢复，EV probes 和端口更新负责避障，SACK 里的拥塞元数据负责动态调速。这个闭环一旦转起来，协议就不再只是“传包”，而是在“管理一条会变坏的网络”。

从协议到实践：MRC的应用接口与部署展望

如果一个协议只停留在论文里，那再漂亮也只是“纸面体操”。MRC 在这一点上比较务实：它不仅定义了线上的包格式，还给出了应用 API 和控制器 API。前者面向程序员，后者面向运维和网络控制平面，两者分工清楚。
应用侧接口沿用了 libibverbs 的风格，资源命名也尽量贴近现有生态，例如 mrc_qp、mrc_cq 这些对象，降低迁移成本。真正和传统 verbs 不同的地方，主要集中在 mrc_modify_qp() 这类配置接口，它负责动态 MPR、裁剪包支持、服务时间补偿，以及 EV/CC profile 的绑定。换句话说，应用层不需要理解所有底层花活，只要知道这条连接该用什么路径、什么拥塞策略就行。
控制器 API 则更像“总闸门”。它运行在特权进程里，负责 EV/CC profile 管理、设备和端口查询，以及可选的 EV 状态事件和探测能力。这个设计的好处是，策略集中、数据面轻量、端点自治。在大规模集群里，这种分层很重要，因为不是每个连接都该自己当网络管理员。
部署层面，MRC 的最大卖点是“可渐进采用”。它不要求立刻更换所有硬件，也不要求重写上层通信库。论文明确指出，MRC 是对 RC 的最小增量改造：协议前缀不同，因此 MRC 与 RC 不互通，但实现上可以沿着现有 RDMA 生态逐步演进。对厂商来说，这是能落地的方案；对用户来说，这是不会把整个机房一把梭重做的方案。
当然，MRC 也不是“无脑全能”。它依赖更丰富的头部、更多的端点状态和更细的控制面协同，意味着实现复杂度会比传统 RC 高一些。好消息是，它把复杂度放在了更合理的位置：协议层和控制器承担该承担的事，应用端尽量保持熟悉的编程模型。对于大规模 AI 训练这种“网络一抖，钱就烧得更快”的场景，这种复杂度交换是值得认真考虑的。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决了什么问题？它解决的是大规模 AI 训练里 RoCEv2 RC 的三类老毛病：单路径利用率低、丢包和乱序恢复慢、链路或端口故障时恢复太被动。MRC 的目标不是更“酷”，而是更能扛。

EV、MPR、SACK 这些术语分别是什么意思？EV 是熵值，用来决定包走哪条路；MPR 是最大包序号范围，用来限制在途窗口；SACK 是选择性确认，用来告诉发送端哪些包到了、哪些没到。三者连起来，才能既多路径又不失控。

普通读者最该记住的背景知识是什么？一句话：训练集群里网络不是“可有可无”，而是直接影响吞吐和成本的核心瓶颈。只要同步通信有长尾延迟，GPU 就会空转，训练效率就会掉。所以协议设计的重点，不只是“能连上”，而是“在大规模、易故障、易拥塞的环境下还能稳”。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

不是“从零发明一套宇宙级新协议”，而是把 RC 的关键短板拆开补齐，做成可组合的开放标准。创新点偏工程体系化，胜在实用和可落地。

实验合理度：★★★★☆

从协议论文角度看，设计目标、机制拆分和已有生态的衔接都比较清楚。真正的性能结论由 companion paper 给出，这篇更偏规范定义，合理但不是完整性能展示。

学术研究价值：★★★★☆

它的价值不在于某个单点技巧，而在于把大规模 AI 网络需要的能力模块化、标准化。这对后续研究和工业实现都很有参考意义。

稳定性：★★★★☆

多路径、SACK、NACK、端口状态更新这些设计都在增强鲁棒性，但系统复杂度也随之上升。只要实现到位，稳定性会明显优于传统单路径 RC。

适应性以及泛化能力：★★★★☆

它对不同硬件层次给了清晰的渐进路径，从传统 ECMP 到 SRv6 都能兼容思路，适应性不错。但前提是底层 NIC、交换机和控制器能力要跟得上。

硬件需求及成本：★★★☆☆

比传统 RC 更吃头部处理、状态维护和控制能力，成本不会低到“白嫖”。但它没有要求完全推倒重来，属于可控增量成本。

复现难度：★★★☆☆

规范和代码仓库都给了，但要真正搭出可验证的多路径 RDMA 环境，门槛不低。对普通研究者来说，复现更多是系统工程而不是单纯跑个脚本。

产品化成熟度：★★★★☆

论文明确写了已经是 production-grade，而且有开放规范和项目仓库支撑，成熟度相当高。真正落地时，仍需看硬件生态和部署规模是否匹配。

可能的问题：机制很完整，但协议更复杂、实现成本更高，且跨厂商一致性和大规模互操作仍是硬门槛。

参考文献


主要参考文献

[9] R. Sohan, E. Spada, E. Davis, M. Handley, I. Burstein, T. Hurson, J. Jose, V. Kashyap, R. Pan, and S. Sur, Open Compute Project: Multipath Reliable Connection (MRC) Specification, Version 1.0, Open Compute Project Foundation, 2026.
[10] J. Araujo et al., “Resilient AI Supercomputer Networking using MRC and SRv6,” 2026.
[6] Ultra Ethernet Consortium, “Ultra ethernet specification v1.0.1,” 2025.
[7] InfiniBand Trade Association, InfiniBand Architecture Specification, Volume 1, Release 1.8, 2025.
开源项目：https://github.com/opencomputeproject/OCP-Multipath-ReliableConnection
原文链接：https://arxiv.org/pdf/2606.18170v1.pdf

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～ 想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！  

end
欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如 图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
wechat_helperdianzan
转发文章 微博 X LinkedIn Facebook
龙哥读论文 · PaperDaily

本文基于龙哥读论文 PaperDaily 数据库整理，结合论文原文与工程视角进行解读。