一次调用，多项决策：GLiNER2.5-Decide如何单次前向同时打分意图、紧急度与路由
2026/10/4 8:37:54
MRC（Multipath Reliable Connection）规范
多路径可靠连接：AI/ML 大规模网络的开放 RDMA 传输协议
本文基于 OCP MRC Specification Revision 1.0与 NVIDIA/Broadcom 官方发布材料整理。
1. 概述
MRC（Multipath Reliable Connection，多路径可靠连接）是一种面向大规模 AI/ML 工作负载的 RDMA 传输协议。它扩展了 InfiniBand 的Reliable Connection（RC）传输模型，为单条 RDMA 连接引入显式多路径支持、拥塞控制、路径健康跟踪与故障恢复机制，使端点在标准尽力而为（best-effort）以太网上保持高有效吞吐（goodput）。
核心价值：让单个 RDMA 连接把流量分发到多条网络路径，提升吞吐、负载均衡与可用性——NVIDIA 官方比喻是"把贯穿小镇的单车道公路，替换为精心规划的街道网格 + 实时导航应用，司机可绕开拥堵和封路"。
- 规范版本：OCP MRC Specification Revision 1.0（2026-03-21）
- 公开宣布：2026-05-06（NVIDIA 博客 + Broadcom 新闻稿同日发布）
- 联合贡献方：AMD、Broadcom、Intel、Microsoft、NVIDIA、OpenAI
- 许可：Modified Open Web Foundation Agreement 0.9（OWFa 0.9）
- 运行载体：标准尽力而为以太网（RoCEv2 演进）
2. 背景与动因
传统单路径可靠传输（RC）在十万级 GPU 的 AI 工厂场景下面临三重瓶颈：
| 痛点 | 具体表现 |
|---|---|
| 带宽利用率不足 | 单路径传输无法借用网络中其他空闲路径；局部拥塞即形成吞吐天花板 |
| 故障恢复过慢 | 链路/路径故障时软件层重路由需秒级收敛；AI 训练数千 GPU 必须保持同步，一次短暂网络中断就可能拖慢甚至中断整个训练任务 |
| 控制面复杂 | 网络拓扑感知与手工调优成本高，难以扩展到数十万 GPU；运维对流量路径缺乏细粒度可见性 |
MRC 的目标：通过端点侧协议改造（而非更换物理网络），在标准以太网上实现高有效吞吐、对瞬时故障自愈、并开放为多方可互操作的公开规范。
3. 发展历程与开放治理
3.1 时间线
| 时间 | 事件 |
|---|---|
| 2026-03-21 | OCP 格式MRC Specification Revision 1.0正式发布 |
| 2026-05-06 | NVIDIA 宣布 MRC 向行业开放；Broadcom 同步发布"Enabling AI Networking @ Scale with MRC"新闻稿 |
| 生产验证 | 已在 OpenAI Blackwell 代际部署验证；Microsoft Fairwater、Oracle OCI Abilene 两大 AI 工厂投入使用 |
3.2 开放治理与许可
- 贡献许可：Modified OWFa 0.9Contribution License（六家公司签署）
- 使用许可：Modified OWFa 0.9Final Specification Agreement（FSA）
- 许可文本可在 OCP 官网 contributors/templates-agreements 获取
3.3 主要贡献者
规范由来自六家公司的作者联合撰写，包括 AMD（Rip Sohan、Vipin Jain、Rong Pan、David Riddoch 等）、Broadcom（Eric Spada、Eric Davis、Karen Schramm、Costin Raiciu 等）、Microsoft（Jithin Jose、Abdul Kabbani、Torsten Hoefler 等）、NVIDIA（Shahaf Shuler、Sayantan Sur、Idan Burstein、Yamin Friedman 等）、OpenAI（Mark Handley、Amin Tootoonchian、Michael Papamichael 等）。
3.4 OCP 原则符合性
规范逐条对照 OCP 五项原则：
- 开放（Openness）：发布六个组织的联合设计，基于已广泛采用的协议与软件抽象，降低集成摩擦
- 效率（Efficiency）：提高网络利用率与端点 goodput，容忍瞬时链路抖动，无需专用网络
- 影响（Impact）：标准以太网上即可部署，NIC/交换机/加速器厂商可按公开规范实现互操作
- 规模（Scale）：端点自主检测拥塞、间歇故障与硬故障，自动评估路径健康并重路由；路由模式支持拓扑透明扩展
- 可持续（Sustainability）：故障与局部拥塞下保持高有效吞吐，减少加速器空转、任务中止与重跑，降低超额配置需求
4. 协议定位与栈层次
MRC 位于现有协议层与 AI/ML 框架（运行时库）之间，暴露 API 让 NIC、加速器与主机软件使用多条网络路径，同时保持所需的可靠、有序交付语义。
┌──────────────────────────────────────────────┐ │ AI/ML 框架与运行时（CCL / NCCL 类库） │ ├──────────────────────────────────────────────┤ │ MRC 软件 API（应用 API + 控制面 API） │ ├──────────────────────────────────────────────┤ │ MRC 传输层： │ │ · 多路径喷洒（ECMP / Structured EV / SRv6） │ │ · 可靠投递（SACK / NACK / 选择性重传） │ │ · NSCC 拥塞控制 │ │ · 路径健康探针 / 端口状态通告 │ ├──────────────────────────────────────────────┤ │ RoCEv2 over 标准尽力而为以太网 │ └──────────────────────────────────────────────┘设计取向：语义处理与包投递解耦——可靠性控制包（SACK/NACK）与 RDMA 传输层 ACK 逻辑独立，可独立表达"包已收到"与"语义处理结果"。
5. 核心技术机制
5.1 多路径喷洒（Multipath Spraying）
单个 QP 的连接可同时在多条网络路径上分发请求包，实现路径级负载均衡。
- ECMP 哈希模式：以 UDP 源端口 + IPv6 Flow Label 作为熵字段（entropy），由交换机哈希选择路径
- Structured EV（结构化熵值）模式：将熵值编码进报文头，支持路径感知的多路径选择（path-aware multipath EV selection）与多平面（multi-plane）EV 选择
- SRv6 源路由模式：基于 uSID 寻址，可选 SRH，实现显式路径控制与透明扩展/收缩
5.2 可靠投递：SACK / NACK 与选择性重传
控制消息（SACK/NACK）携带与触发包前向路径一致的熵值，支持请求端"路径跳过"（path skipping）——控制反馈沿数据路径同路返回。
MRC 的可靠性核心是独立于传输层 ACK 的可靠性 SACK/NACK：
| 机制 | 说明 |
|---|---|
| Reliability SACK | 响应端生成，携带累积 ACK 值、响应端位图（哪些邻近包已收到）、前向路径与响应端拥塞状态、反射的请求时间戳 |
| Reliability NACK | 携带错误码（TRIMMED / NO_BITMAP / NO_PKT_BUFFER / NO_RESOURCE / PSN_OOR_WINDOW / UNEXP_EVENT），驱动请求端重传或进入错误态 |
| 选择性重传 | 基于 SACK/NACK 反馈仅重传丢失的包，而非整个窗口；重传包在 BTH 头置 rtx 标志 |
| 乱序容忍 | 响应端维护逻辑 ePSN 跟踪窗口[ePSN, ePSN+max_psn_range)，窗口内乱序包视为有效并处理，不被丢弃 |
| 直接落位 | 请求包自描述（每包携带更新后的 VA 地址），响应端可将负载乱序直接写入目标内存 |
| 丢失检测 | 逻辑计时器（每包或每连接）+ 快速丢失检测与重传（算法实现自定义）+ 强制支持接收 UET TRIM 包 |
5.3 乱序放置与完成排序
响应端允许乱序放置，但完成排序有严格保证：
| 前序操作 | 后续操作 | 响应端放置保证 | 响应端完成排序 |
|---|---|---|---|
| Write | Write | 无放置保证 | 无 |
| Write | WriteIMM | 无放置保证 | WriteIMM 必须在前序 Write 数据落位完成后完成 |
| WriteIMM | Write | 无放置保证 | 无 |
| WriteIMM | WriteIMM | 无放置保证 | 按请求端发送顺序完成 |
5.4 拥塞控制：NSCC
- MRC 实现NSCC——UltraEthernet 传输规范中定义的发送端拥塞控制算法
- 拥塞信号通过 SACK 携带（ECN 标记仅保留在 SACK 中）
- 请求端维护 CC 窗口状态（CWND），按 NSCC 事件表调整；支持 trimmed 与 untrimmed 包流
5.5 路径健康探针与自愈
| 探针/机制 | 作用 |
|---|---|
| Reliability Probes（PETH） | 请求端查询响应端报文接收状态；尽力而为控制消息，不消耗 PSN |
| EV Probes（端点操作） | 测量前向路径可达性与往返延迟；可在任意流量类别上传输 |
| Port Status Update（端点操作） | 节点向对端通告本地端口运行状态（端口状态掩码） |
| 动态 MPR | 响应端可在运行时调整最大在飞包窗口范围（可选特性） |
故障旁路：在 Spectrum-X 硬件上，MRC 可在微秒级检测路径故障并自动重路由——硬件级响应速度，避免数千 GPU 同步训练被一次网络抖动打断。
5.6 流控与资源管理
- 端到端流控由应用管理：MRC QP 不通告消息级流控信用，AETH 信用字段固定填 0x1F（表示不支持端到端流控）
- WriteIMM 资源限制：每连接
max_wimm_inflight限制在飞 WriteIMM 请求数，响应端跟踪并暂存乱序到达的 ImmDt - 重试策略：每 QP 重试计数由线性重试 + 指数重试两部分组成（线性 0-7 次，指数 0-25 次，可配置无限重试）
6. 传输层扩展（报文格式）
6.1 MRC 操作码与头栈
| 操作码 | 描述 | BTH 后续头 |
|---|---|---|
| 0xC6/0xC7/0xC8 | RDMA WRITE First/Middle/Last | METH, [TSETH], RETH, Payload |
| 0xC9 | RDMA WRITE Last with Immediate | METH, [TSETH], RETH, ImmDt, Payload |
| 0xA0/0xB0 | RDMA WRITE Only（±Immediate） | METH, [TSETH], RETH, [ImmDt], Payload |
| 0xD1 | Acknowledge（传输层 ACK） | AETH |
| 0xD8/0xD9 | Endpoint Request/Response | ERTH / EETH |
| 0xD8 | Reliability SACK | SETH + CC_STATE |
| 0x?? | Reliability NACK | NETH |
| 0xDE | Reliability Probe Request | PETH |
6.2 BTH 头修改
- 新增rtx 字段：标记重传包
- 新增ts 字段：指示存在 TSETH 头
- 保留 p_key 校验与 iCRC 计算
6.3 新增/修改头
| 头 | 关键字段与作用 |
|---|---|
| RETH（修改） | 每包携带更新后的 VA（按 PMTU 递增），支持多包消息的直接落位；r_key 消息内恒定；dmalen 为整个 DMA 操作长度 |
| TSETH（新增） | 请求端时间戳（tx_timestamp，128ns 分辨率，时间戳采集后 0.5μs 内应发送），供请求端计算 RTT |
| METH（新增） | RQMSN（接收队列消息序号，WriteIMM 专用）+ MSN（请求端消息序号），用于跟踪在飞 WriteIMM |
6.4 可靠性控制包
- SETH（Reliability SACK 头）：请求端/响应端 QPID、累积 ACK、位图、拥塞状态、反射时间戳、可用位图资源
- NETH（Reliability NACK 头）：QPID、拥塞状态、可靠性错误码、反射时间戳
- PETH（Reliability Probe 头）：探针请求编码
- ERTH/EETH：端点请求/响应（EV Probe、端口状态通告），BTH.QPN 用保留值 0x2，节点作用域而非连接作用域
7. 操作集与限制
7.1 支持的连接能力（核心）
- 多路径传输：ECMP 或源路由分发请求与 SACK，支持 ECN 标记
- 可靠性控制：SACK + NACK 及时反馈
- WriteIMM 限制：用户定义每连接最大在飞 Write-with-Immediate 数
- 拥塞控制：NSCC（UltraEthernet 发送端算法）
- 选择性重传
7.2 可选特性
- 动态最大 PSN 范围（MPR）
- Trim NACK（网络截断通知）
- Service Time（响应端报告本地请求服务时间）
7.3 相对 RC 的限制
| 限制 | 说明 |
|---|---|
| 受限操作集 | 仅支持 RDMA Write 与 WriteIMM；不支持 Read / Send / Atomic |
| WriteIMM 资源受限 | 在飞 WriteIMM 数受响应端跟踪资源约束 |
| 无 RNR-NAK | 不支持传输层 Receiver-Not-Ready 流控语义（由应用层管理流控） |
设计取舍：面向 AI/ML 训练与推理的集合通信（以 Write 为主），放弃通用 HPC 所需的 Read/Atomic 语义，换取极简硬件实现与更高扩展性。
8. 软件 API
MRC 暴露两类 API：
8.1 应用 API
- 镜像 libibverbs 语义：创建与管理 MRC QP（队列对），降低开发者迁移成本
- QP 连接属性：
max_psn_range（默认 128 包）、max_wimm_inflight等由响应端通告
8.2 控制面 API
- 配置每 QP 多路径策略
- 动态调整负载均衡
- 查询路径可达性与遥测（供监控/编排代理集成）
9. 值得研究/关注的点
- 性能量化：MRC vs 传统单路径 RoCEv2 在真实 AI 集群（训练/推理）上的 goodput 与 GPU 利用率增益，缺乏第三方公开基准测试
- 多路径 + 多平面协同：MRC 多路径喷洒与 Spectrum-X Multiplane 硬件负载均衡的分工与叠加效果
- NSCC 与 UET 生态：MRC 复用 UltraEthernet 的 NSCC 算法，与 UltraEthernet Consortium 标准的竞合关系值得跟踪
相比灵衢UB对比：
- 显式 EV 状态机 + 路径状态建模
- 灵衢 2.1 新增「可靠重路由机制」，但规范层面如何判断 “哪条路径坏了、何时拉黑、何时恢复” 仍属实现自定。
- MRC 给出确定性语义：每个路径熵值（EV）归类为 GOOD / SKIP / DENIED / ASSUMED_BAD，仅 GOOD 用于发送；状态由数据面观察（ECN、丢包、NACK、trim）或控制器干预驱动，ASSUMED_BAD 可经 EV Probe 恢复。
- UB 的全光 Mesh 天然多路径，把这套状态机纳入灵衢传输层即可获得** “路径级故障感知 + 自动避开” **能力。
- 控制包反射前向路径标识 → per-path 负载均衡闭环
- MRC 的关键机制：响应端在 SACK 中反射请求包的 EV，请求端据此把 ECN 标记、RTT 关联到具体路径，动态调整各 EV 选择概率 —— 负载均衡从 “全网盲喷” 升级为 “路径感知自调节”。
- UB 的链路层重传能兜底丢包，但没有端到端的路径级拥塞反馈；UBoE 跨域场景尤其需要这个闭环。
- 可靠性控制包与语义处理解耦（SACK/NACK 独立于传输 ACK）
- UB 是总线级强同步语义（load/store 直达），链路层重传解决闪断 / 误码。但 UBoE 承载跨超节点事务时，网络会丢包乱序，需要区分 “丢包” 与 “乱序”
- MRC 的 SACK（累积 ACK + 位图 + 位掩码）+ NACK（主动非投递信号）把包投递层与语义层解耦，可避免 go-back-N 式重传浪费，对 UBoE 的长距跨域传输价值明显。
- 双维度 inflight 限流：MPR（包级）+ WriteIMM（语义级）
- UB 超节点内是同步内存语义，但在 UBoE / 跨域场景需要传输层窗口控制。
- MRC 的 MPR 滑动接收窗口（响应端通告、位图跟踪、动态弹性扩容）作为资源预算模型，防止乱序直写场景的缓冲爆炸。
10. 参考资料
- NVIDIA Blog —NVIDIA Spectrum-X — the Open, AI-Native Ethernet Fabric — Sets the Standard for Gigascale AI, Now With MRC（2026-05-06）：https://blogs.nvidia.com/blog/spectrum-x-ethernet-mrc/
- OCP —Multipath Reliable Connection (MRC) Specification Revision 1.0（2026-03-21）：https://www.opencompute.org/documents/ocp-mrc-1-0-pdf
- Broadcom —Enabling AI Networking @ Scale with Multi-path Reliable Connections (MRC)（2026-05-06）：https://www.broadcom.com/company/news/articles/ai-infrastructure/enabling-ai-networking-scale-with-multi-path-reliable-connections-mrc
- OCP MRC 1.0 规范全文镜像（含作者名单与修订历史）：https://www.zhaocs.info/wp-content/uploads/2026/05/OCP-MRC-1.0.pdf