MRC（多路径可靠连接）

训练一个前沿大模型，要把计算拆到几万甚至几十万张 GPU 上，这些卡之间必须以极短、严格同步的节奏交换梯度。这种场景下，最慢的那条链路决定整体速度：一条路径拥塞、或者一根线缆瞬断（"链路抖动"），就可能卡住一整个训练步，让全集群的 GPU 空等。MRC（多路径可靠连接）就是为了让这种情况尽量不发生而设计的传输协议。

传统的 RoCE（基于以太网的 RDMA）会把一条连接固定走一条路径，出问题后以"整条连接"为粒度慢慢恢复。MRC 则把同一次传输的数据包同时撒到很多条路径上——即"包级多路径喷洒"。某条路径拥塞或断掉时，已经在途的包会从其他路径继续到达，数据流在微秒级就绕开坏链路，连接不需要断开重建。接收端网卡负责把乱序到达的包重新排好，并保证可靠、有序地交给上层。

MRC 于 2026 年 5 月由 OpenAI 联合 AMD、博通、英特尔、微软、英伟达发布，并通过开放计算项目（OCP）以开放规范的形式公开。它在 RoCE 基础上扩展，借鉴了 Ultra Ethernet Consortium 的成果，并加入 SRv6（IPv6 段路由）让发送端可以显式指定走哪几跳。它需要支持该协议的新款 800Gb/s 级网卡，但底层跑在标准以太网交换上，而不是专有互连。

作为 agent 开发者，你不会去配置 MRC——它在数据中心网络里，比 AGENTS.md、比任何 agent 逻辑都低好几层。它值得收录，是因为它是 2026 年前沿模型（以及基于这些模型的编程、自动化 agent）能被训练出来的前提之一：集群网络已经成为模型规模的主要瓶颈之一，MRC 是业界给出的最受关注的一个回应。

怎么运作

一条逻辑连接会被扇出到一大批等价路径上。发送端按包把流量分散到这些路径，而不是用哈希把整条流固定到一条路上。由于同一条消息的包现在会乱序、从不同方向到达，重排序、丢包检测和重传的逻辑都被压到了端侧网卡上——这些在单路径传输里本可以靠"天然有序"的假设简化掉。

路径健康状况被持续监测，SRv6 源路由让发送端能直接表达"走这几跳"，于是劣化的链路可以立即被避开，而不用等路由控制面重新收敛。最终效果是：拥塞和链路故障只会让吞吐平缓、局部地下降，而不会卡死一个横跨整个任务的同步集合通信。

举个例子

一个十万卡集群的训练任务跑到一半，某条交换机之间链路上的一个光模块开始报错并最终断开。在单路径 RoCE 下，所有固定走这条链路的流都会停住，依赖这批梯度的 GPU 干等，整个任务的单步耗时飙升，直到路由恢复。在 MRC 下，本来经过这条链路的包已经由同一连接的其他路径在承载，发送端在微秒级停止使用这条坏路径，单步耗时几乎不变，也不需要重启任务。

和相关概念的区别

常见误解

常见问题