2026年5月、OpenAIがMicrosoft・NVIDIA・AMD・Intel・Broadcomと共同開発した新しいトランスポートプロトコル「MRC（Multipath Reliable Connection）」がOpen Compute Project（OCP）経由でオープン規格として公開されました。ChatGPTを学習させている本番クラスタで、すでに稼働中の技術です。
注目すべきは、その設計判断です。MRCを採用したOpenAIのAIスーパーコンピュータでは、スイッチの動的ルーティングプロトコル（BGP・OSPF）をすべて無効化しています。私たちネットワークエンジニア（以下、NE）が「ネットワークの心臓部」として扱ってきた仕組みを、世界最大級のネットワークがあえて捨てた。本記事では、その理由と仕組みを現役NEの視点で整理します。
MRCとは何か
MRCは、AI学習クラスタのGPU間通信（RDMA）向けに設計されたトランスポートプロトコルです。従来のデファクトであるRoCEv2のRC（Reliable Connection）を拡張したもので、Verbs APIなど既存のソフトウェア抽象化を維持しつつ、内部の転送メカニズムを根本から作り替えています。
ポイントは「完全な新規格」ではなく「RoCEv2の最小限の拡張」である点です。対応NICはすでにNVIDIA ConnectX-8、AMD Pollara、Broadcom Thor Ultraで実装済みで、OpenAIとMicrosoftの最大級の学習クラスタで本番運用され、ChatGPTやCodexのフロンティアモデルの学習に使われています。仕様はOCPからオープンライセンスで公開されており、誰でも参照・実装できます。
前提：なぜRoCEv2では限界なのか
AIファブリックの基礎（RoCEv2・PFC・ECN・DCQCNの仕組みと、SD-WANとの違い）は前回の記事で詳しく解説しました。未読の方はまずこちらをどうぞ。
▶ AIファブリックとSD-WANの違い｜Secure AI Factoryで読み解くロスレスEthernet設計
要点だけ復習すると、RoCEv2には構造的な弱点が2つあります。
1つ目はECMPのフロー固定。ECMPはフローのハッシュ値で経路を決めるため、1つのフローは1本の経路に固定されます。AI学習の巨大なエレファントフロー同士がハッシュ衝突すると、他の経路が空いていても特定リンクだけが輻輳する「ホットスポット」が生まれます。
2つ目はPFC依存のロスレス設計。RoCEv2はパケットロスを許容できないため、バッファが溢れそうになるとPFCのポーズフレームで送信元を止めます。このポーズが連鎖するとHead-of-Line Blockingが発生し、無関係なフローまで巻き添えで停止します。
数千〜十数万GPUが同期して動くAI学習では、この「一部の遅れが全体を止める」性質が致命傷になります。1リンクの輻輳がジョブ全体のストールに直結し、高価なGPU時間がまるごと浪費されるからです。
MRCの3本柱
MRCは3つの技術を組み合わせて、この問題を解いています。
①パケットスプレー：1つの接続を数百の経路にばら撒く
RoCEv2がフローを単一経路に固定せざるを得なかった根本原因は、パケットの順序依存にあります。大きなWrite操作を分割したとき、宛先メモリアドレスを含むRETHヘッダは先頭パケットにしか付かないため、後続パケットは順番どおりに届かないとNICがDMA先を判断できません。
MRCはこれを逆転の発想で解決しました。すべてのデータパケットにRETHヘッダ（仮想アドレスとリモートキー）を付与するのです。ヘッダ分のオーバーヘッドは増えますが、各パケットが自己完結するため、どんな順番で届いても受信NICは正しいメモリ位置へ直接書き込めます（Out-of-Orderデータ配置）。
順序の呪縛から解放されたMRCは、1つのQueue Pair（QP）のトラフィックをパケット単位で多数の経路へ分散させます。経路の選択にはEV（Entropy Value：エントロピー値）という32ビットの値を使い、UDPソースポートとIPv6フローラベルに分散して格納します。QPの開始時に128〜256個のEVセットが生成され、送信側NICはパケットを送るたびにEVをローテーションさせます。つまり、同じ転送の連続パケットが、それぞれ別の経路を通るわけです。
さらに各EVには経路の健全性状態が紐づいており、ECNマークが返ってきた経路は一時的に回避、パケットロスが起きた経路は即座に無効化されます。この判断はホストのCPUを介さず、NICハードウェア上でマイクロ秒単位で完結します。無効化された経路には軽量なバックグラウンドプローブが送られ続け、疎通が回復すれば自動で復帰します。
②マルチプレーン：2階層で10万GPU超を収容する
MRCのパケットスプレーは、物理トポロジの再設計とセットで真価を発揮します。
従来の設計では、800GbpsのNICを1本の太いパイプとして扱い、51.2TbpsのスイッチASICを800G×64ポートで使います。この構成で10万GPUをつなぐには3〜4階層のClosが必要で、最悪経路は5〜7ホップに及びます。
マルチプレーン構成では、800GのNICポートをブレイクアウトして100G×8レーンに分割し、それぞれを別のT0スイッチに接続します。同じASICが100G×512ポートのスイッチとして使えるため、ネットワーク全体が8つの独立した「面（プレーン）」に分かれ、わずか2階層・最大3ホップで理論上131,072GPUまで収容できます。
この構成の本当の価値は、障害の影響範囲（Blast Radius）の縮小にあります。論文の数値では、T0-T1間のリンクが1本切れたときのノード帯域への影響は、800G単一プレーンで約3%、100G×8プレーンでは約0.4%まで小さくなります。NICの1ポート（1プレーン分）が丸ごと故障しても、MRCがそのプレーンへのスプレーを止め、残り7プレーンで学習ジョブは継続します。ジョブを落とさず性能が緩やかに下がるだけ──グレースフルデグラデーションです。
③静的SRv6：動的ルーティングを「切る」という決断
そして最も大胆な設計判断が、冒頭で触れた動的ルーティングの無効化です。
理由は明快で、適応制御が二重になるからです。MRCはリンク障害をマイクロ秒単位で検知し、EVの切り替えで勝手に迂回します。その後からBGPが再収束してECMPマッピングを書き換えると、MRCが整えた負荷分散が乱されてしまう。障害回避の主役がエンドポイント（NIC）に移った以上、スイッチ側の動的ルーティングは「問題を解決するより増やす存在」になった、というのがOpenAIの結論です。
代わりに採用されたのが、IPv6セグメントルーティング（SRv6）のuSID（マイクロセグメントID）による静的ソースルーティングです。送信側NICがIPv6宛先アドレスの中に経由スイッチのIDシーケンスを直接埋め込み、各スイッチは自分のIDと照合してアドレスをシフトし、静的な転送テーブルで次ホップへ送り出すだけ。スイッチの転送テーブルは設置時に構成され、基本的に二度と変更されません。ネットワークコアは完全にステートレスな高速転送装置となり、経路制御のインテリジェンスはすべてNICに集約されます。
なお正確に言うと、SRv6はMRC仕様の必須要件ではありません。MRC自体はECMPハッシュベースの既存ネットワークでも動作するよう設計されており、静的SRv6はOpenAIとMicrosoftが大規模運用の知見から選んだデプロイ方式です。静的ソースルーティングにはもう1つ大きな利点があり、プローブパケットがどの物理経路を通るかが完全に特定できるため、障害箇所の切り分けと修理対象の特定が劇的に簡単になります。実際、彼らは全ノードのエージェントが全リンクを毎ミリ秒プローブする監視システムを運用しています。
PFCを捨てた信頼性設計
MRCはPFCを無効化し、Ethernetを本来のベストエフォート（ロス許容）モードで使います。「ロスレスをやめたのに信頼性を上げる」を成立させているのが、トランスポート層の再送設計です。
受信側はビットマップ付きのSACK（選択的確認応答）で「どのパケットが届いたか」を正確に伝え、欠落を検知すればNACKを能動的に返します。送信側はタイムアウトを待たず、欠けたパケットだけをピンポイントで別経路から再送します。Go-Back-N方式のような無駄な再送は発生しません。
インキャスト輻輳への対策としては、UET（Ultra Ethernet Transport）由来のパケットトリミングを採用しています。バッファ溢れでパケットを落とさざるを得ないとき、スイッチはペイロードだけを切り落とし、ヘッダを高優先度で宛先まで届けます。受信側は「経路は生きているがバッファが溢れた」と確定的に判断でき、即座にNACKで再送を要求する。輻輳とリンク障害を明確に区別できるため、健全な経路を誤って無効化することもありません。
UET・Falconとの比較
RoCEv2の後継を狙う規格はMRCだけではありません。主要3規格の設計思想を整理します。
| 比較項目 | UET（Ultra Ethernet） | Falcon（Google） | MRC |
|---|---|---|---|
| 位置づけ | プロトコルスタックを刷新する新規格 | 既存ファブリックとの互換性重視 | RoCEv2の最小限の拡張 |
| マルチパス方式 | パケットスプレー | MPTCP的なサブフロー分割 | EVテーブルによるパケットスプレー |
| スイッチ要件 | トリミング等の新機能対応が前提 | 汎用スイッチで動作 | 既存ASICで対応可（SRv6は選択制） |
| ロス回復 | NACKベースの再送 | 高速ロスリカバリ（RACK-TLP系） | SACK/NACK選択的再送＋μ秒迂回 |
MRCはUETからパケットスプレーやトリミングの発想を取り込みつつ、既存のRoCE Verbsとの互換性を保った「現実解」のポジションです。ただし用途をAI学習に絞り込んでおり、トランスポートレベルでサポートするRDMA操作はWriteとWrite-with-Immediateのみという割り切りがあります。
実運用での実績
論文には本番環境での障害事例が具体的な数値付きで報告されています。NEとして読み応えがあるのはここです。
50,000GPUの学習ジョブ実行中、T0スイッチの光トランシーバがグリッチを起こし、4リンクが連続フラップした事例では、スループットが約1分間25%低下したものの、ジョブはクラッシュせず、直後に全速へ復帰しました。75,000GPUのジョブ中にT1スイッチが転送停止に陥った事例では、自動検知でスイッチを再起動。約58万パケットがドロップしたにもかかわらず、ジョブ全体のスループットはほぼ影響を受けませんでした。
運用哲学の変化も印象的です。従来、フラップするリンクは管理的にダウンさせ、修理・試験後に戻すのが常識でした。MRC導入後は故障リンクを稼働状態のまま放置し、修理の優先度も下げたとのこと。MRCが勝手に避けて、直れば勝手に使い始めるからです。「障害を未然に防ぐ」から「障害は起きる前提で、透過的に無効化する」への転換です。
ネットワークエンジニアは何を学ぶべきか
MRCのようなAIファブリック案件に、私たちが明日から関わる可能性は正直高くありません。それでも押さえておくべき理由が2つあります。
1つは、SRv6の主戦場が広がっていること。SRv6はこれまでキャリア網（5Gコアなど）の技術という印象が強かったですが、AIバックエンドという巨大な適用先が生まれました。IETFでもAIバックエンド向けSRv6の標準化議論が進んでおり、DC系NEにとっても他人事ではなくなりつつあります。
もう1つは、「経路制御の主体がネットワークからエンドポイントへ移る」という潮流です。スイッチはステートレスな土管に徹し、輻輳制御も障害回避もNICが担う。この分業の変化は、AIファブリックに限らず今後のDC設計思想に影響していくはずです。BGPの再収束時間を数秒単位でチューニングしてきた身としては複雑な気持ちもありますが、「なぜ彼らはBGPを切れたのか」を説明できることが、これからのNEの引き出しになると考えています。
まとめ
MRCの要点を整理します。
RoCEv2を最小限に拡張し、全パケットへのRETH付与でOut-of-Order配置を実現。EVによるパケットスプレーで数百経路へ負荷分散し、8プレーン×2階層のトポロジで障害影響を0.4%まで局所化。動的ルーティングを無効化した静的SRv6でコアを完全ステートレス化し、PFCの代わりにSACK/NACKとパケットトリミングで輻輳とロスを捌く──。ネットワークを「壊れないもの」ではなく「壊れても気づかせない緩衝装置」へ変えた規格、それがMRCです。
仕様はOCPで公開されています。一次情報としては、OpenAIの解説記事と論文「Resilient AI Supercomputer Networking using MRC and SRv6」（arXiv:2605.04333）が読み応えがあるので、興味のある方はぜひ原文にあたってみてください。
参考資料
・Supercomputer networking to accelerate large scale AI training | OpenAI
・Resilient AI Supercomputer Networking using MRC and SRv6 | arXiv
・MRC and SRv6 | Cisco Blogs
