@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6

> [!abstract] 概要(arXiv abstract の日本語訳) > テール遅延は、非常に大規模で実行される同期的な事前学習ジョブの性能を支配する。本稿では三本立てのアプローチを述べる。(1) 新しい RDMA ベースのトランスポートプロトコル MRC は、多数の経路にわたってパケットをスプレーし、それらの間で能動的に負荷分散を行い、フロー衝突の問題を解消する。(2) マルチプレーン Clos トポロジの使用により、高いスイッチ radix と冗長性の利点を得て、物理的な冗長性を高めながら 10 万 GPU を大きく超える訓練クラスタを 2 段トポロジとして構築できるようにする。(3) SRv6 を用いた静的ソースルーティングの使用により、MRC が自ら障害を迂回する自由を得られるようにする。我々は、OpenAI と Microsoft の最大規模の訓練クラスタにおいて MRC と静的 SRv6 ルーティングを本番運用してきた経験を述べる。これらのクラスタは最新のフロンティアモデルの訓練に使われてきた。我々は、MRC によって AI 訓練ジョブが、以前であれば訓練を中断させていたであろう多くのネットワーク障害を乗り切れる(ride out)ようになることを示す。 # @2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6 ## 論文情報 - タイトル: Resilient AI Supercomputer Networking using MRC and SRv6 - 著者・所属: [[OpenAI]]・[[Microsoft]]・[[AMD]]・[[Broadcom]]・[[NVIDIA]] の 5 社連名(58 名)。対応著者は [email protected]([[Mark Handley]])、[email protected](Jithin Jose)、[email protected](Rip Sohan)、[email protected](Eric Spada)、[email protected](Sayantan Sur)の 5 名。 - 媒体: arXiv(cs.NI)、投稿日 2026-05-05 - arXiv ID: 2605.04333v1 - 関連仕様: MRC 仕様書は Open Compute Project(OCP)にオープンライセンスで公開([41]) - 本論文は [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]](LinkedIn 解説記事)が参照する原論文にあたる。LinkedIn 記事は本論文の技術要旨を平易に紹介したもので、本ページは原論文の詳細(数値・実験・光モジュール障害の記述)を扱う。 ## 概要 10 万 GPU を大きく超える AI 訓練クラスタで、同期事前学習のテール遅延支配・ネットワーク障害の増加に対処するため、OpenAI・Microsoft・AMD・Broadcom・NVIDIA が共同で (1) RoCE を拡張したマルチパストランスポート MRC、(2) マルチプレーン Clos トポロジ、(3) SRv6 静的ソースルーティング、を組み合わせた耐障害ネットワークアーキテクチャを設計・実装・本番運用した。OpenAI と Microsoft の最大規模クラスタで、ChatGPT・Codex 向けフロンティア LLM の訓練に使用されている。 ## 問題設定同期事前学習では各ステップの計算がロックステップで実行され、パイプライン並列・データ並列・テンソル並列・エキスパート並列を組み合わせた通信が計算間に挟まる。計算とオーバーラップさせるため通信ラウンドの所要時間は最も遅い転送(テール)で決まり、計算規模が拡大するほど通信は外れ値(outlier)支配になる(HPC コミュニティで長く知られる「システムノイズ」現象)。加えてスケールとともにネットワーク障害が増え、障害がジョブ失敗を招くと高価な GPU 時間の損失に直結する。ソリューションに要求される 3 要件は次のとおり。 - フロー衝突による輻輳を防ぐため、ネットワーク全体を均等に負荷分散すること - 外れ値を生まずに incast ベースの輻輳を処理すること - 訓練ジョブを止めずにリンク・ファブリック障害を優雅に処理することさらに、多数のスイッチを抱える複数のスーパーコンピュータのネットワークを、極めて少人数のチームで運用できる必要がある。個々のネットワーク障害の診断・修復を人手のタイムリーな介入に依存できないため、プロトコルスタック自体が設計上障害耐性を持ち、ネットワークのコントロールプレーンはほぼ無人管理で済むほど単純である必要がある。故障リンクや不調スイッチは自動的に迂回されるべきだが、故障ノードは(グローバルな協調を必要とせず)実行中のジョブから容易に除去できる。 ## 提案手法 ### アーキテクチャ全体(three-pronged approach) MRC・マルチプレーン Clos トポロジ・SRv6 静的ソースルーティングの 3 技術を co-design した。MRC の適応的負荷分散が障害回避に極めて優れているため、スイッチのダイナミックルーティングは意図的に無効化し、2 つの適応的機構が相互作用しないようにした。 **マルチプレーン Clos トポロジ**(§2、Figure 1): 100,000 GPU・各 800Gb/s NIC のクラスタを想定する。従来型の 3 段 Clos トポロジ(51.2Tb/s スイッチ・64x800Gb/s ポート、T0 が 32 NIC に接続・32 T1 に接続、pod サイズ 1024 NIC、T2 が 64 pod に接続し 64K NIC クラスタ)では 100K GPU に届かせるには 4 段・オーバーサブスクリプション・複数独立レールのいずれかが必要になる。代わりに 800Gb/s NIC をレーン単位で 8x100Gb/s ポートに分割し、同じ 51.2Tb/s スイッチで 8 本の並列 100Gb/s Clos プレーンを構築すると、各スイッチは 512 ポートを持ち、T0 は 256 NIC ポートに接続・256 T1 に接続、2 段のみで 131,072 GPU のネットワークが組める。 **Figure 1: 3 段 800Gb/s 単一プレーントポロジ対 2 段 8x100Gb/s マルチプレーントポロジ** ![[_attachments/arxiv-2605.04333/fig01-multiplane-topology.png]] (Figure 1. (a) 3 段 800Gb/s 単一プレーン: T2(64 ポート・1024 T2s)—T1(32 ポート・32 T1s)—T0(32 ポート・32 T0s)—32 NIC、64 pod x 32 T0 x 32 NIC = 65,536 NIC。(b) 2 段 8x100Gb/s マルチプレーン(8 プレーン): T1(512 ポート・256 T1s x 8 プレーン)—T0(256 ポート・512 T0s x 8 プレーン)—256 NIC、512 T0 x 256 NIC = 131,072 NIC。Source: 論文 Figure 1。) マルチプレーン設計の利点として論文が挙げるのは次のとおり。(1) 最長経路がスイッチ 3 段のみ(3 段 vs 5〜7 段)で低遅延、(2) 1 ホップで到達可能なノードが 256(32 に対し)に増え局所性を活かしやすい、(3) フル二分帯域幅に必要な光学部品が 3 段構成の 2/3、スイッチ数が 3/5 で済みコスト・電力を削減、(4) ネットワーク内障害の影響が小さい——T0-T1 リンク 1 本の喪失は 800Gb/s プレーンでは容量の 3% 減だが 100Gb/s プレーンでは 0.4% 減にとどまり、NIC-T0 リンク 1 本の喪失でも NIC 帯域の 12% を失うだけでジョブを止めずリンクフラップを乗り切れる。 ### MRC(Multipath RC)の詳細(§2.1) MRC は RoCEv2 の RC(Reliable Connection)トランスポート層を拡張したもので、Ultra Ethernet Transport(UET)からいくつかの特徴を借用する。通常の RoCE Verbs インターフェースと QP 抽象を踏襲するが、write と write-with-immediate 操作のみサポートする。主な追加機能は次のとおり。 - 各データパケットに RDMA 仮想アドレスとリモートキーを含め、受信 NIC が到着順序にかかわらず即座にメモリへ書き込める(out-of-order 配置)。 - 各パケットが 32-bit の EV(entropy value)を持ち、UDP 送信元ポートと IPv6 flow label にまたがって埋め込まれる。QP 起動時に典型的には 128〜256 エントリの EV セットを生成し、パケットごとに EV をローテーションすることで、アプリケーションが意識せずにマルチプレーンネットワークの全プレーン・多数経路へパケットをスプレーする。 - スプレーは lossless Ethernet の PFC(Priority Flow Control)機構と相性が悪い(単一フローが数百経路で最終ホップスイッチに到達するため)。PFC はコレクティブ間のヘッドオブラインブロッキングも生み、テール遅延を悪化させる。そのため MRC は PFC を無効化し、best-effort(lossy)モードの Ethernet を使う。 - best-effort Ethernet と out-of-order 配送の組み合わせは損失の高速回復を要求する。MRC は SACK(Selective ACK)パケットで到着済みパケットを正確に示す高速選択的再送信を実装する。 - incast 時の再送を高速化するためパケットトリミングを使用できる。輻輳でドロップされるはずのパケットはペイロードを削られ優先転送され、受信 NIC が NACK を生成して高速再送を誘発する。これにより輻輳ロスとそれ以外のロス(AI クラスタでは主にリンクフラップ・障害由来)を区別できる。各スイッチでは通常のランダム化された方式で ECN(Explicit Congestion Notification)を有効にするが、最終ホップでは ECN を無効化する。フル二分帯域幅ネットワークでは最終ホップの incast 以外は輻輳が生じないため、ECN は負荷分散シグナルとして働く——受信側が ECN を送信側へエコーし、特定経路が他より輻輳していることを通知、送信側は一時的にその経路を避ける。異なる MRC 送信側は EV セットの選択を互いに調整しないため、各送信側が良好に負荷分散していても集約トラフィックはわずかに偏る。ECN ベースの負荷分散はこの偏りを均し、内部キューの成長による輻輳ロスを防ぐ。パケットがトリムされずに実際にロストした場合、MRC はその経路が故障したとみなし、対応する EV を直ちに使用停止する。ただし全てのロスがパス故障によるとは限らない(ビットエラー等)ため、1 回のロスで恒久的に EV を退役させると使用可能な EV が不足しうる。そこで MRC はバックグラウンドでパスプローブを送り、故障とみなした経路が実際に故障しているか、あるいは復旧しているかを確認する。十分な数のプローブが成功すると EV は復活する。この仕組みにより、数十マイクロ秒でパス故障を検知し回避できるトランスポートプロトコルが実現する。 ### SRv6 静的ソースルーティング(§2.2〜2.3) 従来のデータセンターネットワークでは BGP のようなダイナミックルーティングプロトコルで到達性を決定し障害を回避するが、収束に多数の RTT を要することがあり、高 radix の 2 段トポロジではこれが悪化する。宛先ごとに大きな ECMP セット(512 ポート T0 スイッチでは最大 256 エントリ)が必要になり、障害がある T1 スイッチではデフォルトの均等分散 ECMP セットを使えなくなるため、必要な大規模 ECMP セット数は T0 スイッチ総数近くまで増大し、ダイナミックルーティングとスイッチの転送エンジンの双方に負荷がかかる。 MRC は自ら障害を素早く回避し冗長なトポロジを構築するため、ダイナミックルーティングは不要と判断し無効化した。EV を具体的な経路にマッピングする手段として IPv6 segment routing(SRv6)の micro-segment ID(uSID)方式(uN スタイル、各スイッチが経路上で明示的に指名される)を採用した。宛先 IPv6 アドレスは 32-bit のロケータプレフィックスと、経路上の各スイッチに対応する 16-bit uSID の並びから構成される。 **Figure 2: uN uSID による SRv6 転送** ![[_attachments/arxiv-2605.04333/fig02-srv6-usid-forwarding.png]] (Figure 2. パケット到着時、スイッチは宛先アドレスの先頭 48 bit を自身の設定済み SRv6 ロケータ・uSID と比較し、一致すればアドレスの uSID 部分を 16 bit 左シフトして次ホップの uSID を先頭 48 bit に移す。この新アドレスをスイッチの静的転送テーブルで通常どおり検索し、エグレスポートを決定する。転送テーブルはスイッチ設置時に設定され基本的に変更されない。このライン速度で処理可能な uN 方式の SRv6 転送を全デプロイスイッチで実装した。Source: 論文 Figure 2。) MRC パケットは outer が SRv6 パスを表す IPv6-in-IPv6 カプセル化で、inner が宛先 NIC 自身のアドレスを含み、受信 NIC がデカプセル化して MRC RDMA パイプラインへ渡せるようにする。EV は SRv6 でハッシュされないため(スイッチが左シフトで uSID を消費していく過程で SRv6 アドレスそのものはエコーできない)、EV と対応する SRv6 アドレスの間にアルゴリズム的マッピングを用いる。 **Figure 3: EV とテンプレートから SRv6 宛先アドレスを生成する過程** ![[_attachments/arxiv-2605.04333/fig03-ev-srv6-address-mapping.png]] (Figure 3. QP 起動時に設定ファイルから宛先 T0 グループ向けの汎用テンプレートアドレスを取得し(Step 1)、宛先 IP アドレスから最終ホップダウンリンクを埋め込んで特化し(Step 2)、送信ごとに EV から変化する bit(プレーン・T0 アップリンク)を埋め込んで最終アドレスを生成する(Step 3)、という 3 段階の過程を示す。src→T0→T1→T0→dst という経路の例で説明される。Source: 論文 Figure 3。) ダイナミックルーティングを無効にしても静的な EV-to-path マッピングは必要であり、静的 ECMP に頼る案は EV と物理経路の対応が不明瞭で障害報告に不向きなため退けられ、ソースルーティングによるスプレーが採用された(先行研究 [20] の示唆に沿う)。 ### Clustermapper と経路選択(§2.4、§3) QP 起動時、MRC はプレーンごとに均等な数の EV を選び、各プレーン内でパスのサブセットをランダムに選択する。同一 T0 グループ内の異なる送信側は選択を互いに調整しない。事前学習ジョブ起動時には、全ノードの全 NIC ポートが正常であることを確認する。MRC は denylist をサポートし、既知の故障リンクを通る経路を避けられる。これを実現するため、全ノードにエージェントが動く Clustermapper を実装し、現在ダウンしている、あるいは損失過多のリンクを集約的にマッピングする。静的 SRv6 ルーティングにより、Clustermapper のプローブパケットが通る経路は正確に既知であり、等価な MRC パケットが通る経路と同一であることも分かる——スイッチベースのテレメトリと異なり、この地図はフォワーディングプレーンの健全性についてground truth を与える。実際には、事前学習では T0-T1 リンク故障の denylist 設定に Clustermapper を使う必要はなかった。QP は非常に長寿命であり MRC は素早く故障を迂回して良好な経路に落ち着く。CX8 の MRC では各 QP が大きな EV セット(通常 100 超のエントリ)とバックアップ EV セットの投入から始まり、パケットスプレー中に故障パスでのロスト・再送信が発生すると EV はバックアップから交換される。事前知識なしでも MRC は十分速く悪路をマッピングするため、わずかな起動時性能低下は問題にならない(Figure 4: 75K GPU 事前学習ジョブ起動時、denylist を事前投入しない状態での損失率が数分以内に 1 loss/sec/NIC(800Gb/s で 2500 万パケットに 1 個の損失率に相当)を大きく下回ることを示す)。 **Reverse path**: MRC は RoCE 累積 ACK・MRC SACK・MRC NACK を逆方向経路で送る。フォワードパスの EV セットは SACK/NACK 情報で更新されるが、逆方向パケットにどの EV を使うべきかは別問題である。多くのコレクティブ QP は瞬間ごとに単方向である。解決策として、プレーンごとに少なくとも 1 つの EV を持つ小さな逆方向 EV セットを制御パケット用に維持し、アウトバウンドトラフィックが無い RTT ごとにランダムに選んだ EV でプローブパケットを送り、ACK されればそのプレーンの逆方向 EV をプローブの EV に更新する。データトラフィックが流れていれば逆方向 EV はデータ SACK から更新される。 ## 新規性 MRC は UET の設計を参考にしつつ RoCEv2 への最小限の拡張として実装されており、Verbs インターフェースと QP 抽象を保持する点が UET(RoCEv2 を置き換える新プロトコルスタック)と異なる。既存のホストベースマルチパス手法(NCCL の QP スケーリング、MSCCL、NCCLX、UCCL)はアプリケーション層/集合通信ライブラリ層で衝突を軽減するが完全には解決しない、と本論文は評価で示す。MPTCP のようなマルチパス TCP はサブフロー単位の状態管理を要するのに対し、MRC は EV という軽量な状態のみを保持する。スイッチベースのマルチパス(Drill・CONGA・Stardust、Broadcom/Cisco の商用実装)はホストへの順序保証付き配送を提供するが独自仕様で均質ネットワークを要求する。 SRv6 ソースルーティングの採用は、既存研究の多くがホスト駆動 ECMP またはスイッチスプレーに依存するのと対照的である。Filsfils ら [14] は単一パス RoCEv2 に対する SRv6 uSID ベースの経路配置を検証したが、本論文は SRv6 をマルチプレーン・マルチパストランスポート(MRC)と組み合わせ、2 段スイッチ構成で 100K GPU 超に到達した最初期の設計の一つとして位置づけられる。Alibaba HPN [33](デュアル ToR・レール最適化、最大 15K GPU、2 段)や Wang ら [43] のレールオンリー(スイッチ単段)とは異なり、マルチプレーンネットワークで 100K+ GPU を 2 スイッチ段に到達させた設計として自らを位置づけている。 ## 実験設定 4 種類の実クラスタで評価した(Table 1)。 | Cluster | NIC | Switch | Topology | |---|---|---|---| | Cluster A | NVIDIA GB200 + CX8(800Gbps) | NVIDIA SP4 & BRCM TH5 | 2-Tier 4x200Gbps Multi-plane | | Cluster B | NVIDIA GB200 + CX8(800Gbps) | NVIDIA Spectrum 5 | 2-Tier 8x100Gbps Multi-plane | | Cluster C | AMD MI355 + Pollara(400Gbps) | Broadcom Tomahawk 5 | 2-Tier 4x100Gbps Multi-plane | | Cluster D | NVIDIA RTX 6000 + Broadcom Thor Ultra | Broadcom Tomahawk 5 | 2-Tier 400Gbps Single-plane | (Table 1. Experiment Platform Configurations。Source: 論文 Table 1。) Cluster A・B は本番の GB200 + CX8 マルチプレーンクラスタ(それぞれ NVIDIA Spectrum-4 & Broadcom Tomahawk 5、NVIDIA Spectrum 5 スイッチ)、Cluster C は AMD Pollara NIC + Broadcom TH5 の小規模テストベッド(64 GPU、RoCE との直接比較用)、Cluster D は Broadcom Thor Ultra NIC の小規模単一プレーンテストベッド。ベンチマークは `ib_write_lat`/`ib_write_bw`(perftest)、NCCL-tests の sendrecv、64-way ring all-reduce・all-to-all(P4 プログラムで意図的にパケットロスを注入)、7-to-1 incast パターン(VRF で単一プレーン 2 段 Clos を Broadcom TH5 上にエミュレートした 16 サーバの Cluster 4)。 ## 実験結果 ### 本番訓練での障害耐性(§5.1)——光モジュール・リンクフラップの核心結果 Cluster A での大規模同期事前学習ジョブ実行中、T0-T1 間リンクフラップは定常的に発生していた。 **Figure 5: T0-T1 間のリンクフラップ数(1 分あたり)** ![[_attachments/arxiv-2605.04333/fig05-t0-t1-link-flaps.png]] (Figure 5. Cluster A で非常に大規模な同期事前学習ジョブを実行中、T0-T1 間の 1 分あたりリンクフラップ総数をスイッチ側の報告値としてプロット。250 分間にわたり概ね 2〜10 件/分で推移し、ピークで約 13 件/分に達する。Source: 論文 Figure 5。) 論文はこの定常的なリンクフラップ率が性能にほとんど影響しないと明記し、**これらのリンクを修理のためにスケジュールはするが優先度は低くしている**。実際、「フラップの修理は非常に優先度の低い活動であり、運用の労力は他に振り向けたほうがよい」と述べる。理由は、MRC が十分多くの経路にトラフィックを分散しているため、あるリンクを使っていた QP がフラップに遭遇しても失われるパケットは QP あたりごく少数(しばしば 1 個のみ)で済み、対応する EV が除去され、欠落パケットは別経路へ選択的に再送信され、ジョブへの影響は無視できるためである。 MRC 導入以前は、フラップするリンクは修理のため管理的にダウンさせ、データトラフィックが使えないようにしてから修理・テスト後に復帰させていた。MRC 導入初期も同じ運用を取っていたが、これが不要であることが判明した。現在は**修理中もリンクを在線状態に残す**運用に変更した。MRC はリンクがドロップした時点で経路を除外し、十分な数のプローブが時間をかけて成功したときのみ復帰させる。これにより協調の必要性が減り、実際に機能しているリンクは常に利用可能になる一方、信頼性が低すぎるリンクは使われない。また、あるリンクを修理中の技術者が隣接リンクを乱してフラップさせてしまうという不可避の混乱にも頑健である。スイッチソフトウェアはバグが起きやすく(先行研究 [28,39,45])、これが障害検知を妨げ、コントロールプレーンが障害を迂回できなくなることがある。180,000 台のスイッチを 3 か月にわたり調査したデータセンター研究 [39] によれば、スイッチ障害の 17% はソフトウェアバグに起因する。こうしたバグはコントロールプレーンとデータプレーンの乖離(control-plane and dataplane divergence)を引き起こしうる。本論文の著者らも同様の経験をしており、コントロールプレーンとリンクは正常に見えるがスイッチがパケット転送を停止するケース(特に厄介)を観測している。静的 SRv6 を使う MRC はコントロールプレーンの状態を気にしない——パケットが流れなければ経路を除去するだけである。不調な T1 スイッチを見つけたときは、ルーティング収束や訓練ジョブとの調整を気にせず単純に再起動する。MRC は故障スイッチを通る EV をマップアウトし、事後に復元する。 NIC-T0 リンクと T0 スイッチには測定可能な影響があるためより注意を要する。NIC リンクが故障しても QP 障害は起きない——NIC がリンクドロップを検知し MRC が故障ポートを避けるよう EV を再マップする。リンクドロップ直後には多くのパケットが失われる。多数の QP にわたる全 EV の再マッピングは CX8 MRC 実装では瞬時ではないため、ジョブスループットに一時的な乱れが生じる。MRC はその後 SACK パケット内のポート状態ビットマップを使い、リモート QP エンドポイントへポートがダウンしていることを通知し、それらも EV を再マップして故障プレーンを避ける。これが完了する(通常数秒)と QP は完全に機能を回復するが、使用プレーンが 1 つ減る。四プレーン(4x200Gb/s)・八プレーン(8x100Gb/s)双方の MRC スーパーコンピュータを運用しており、NIC ポート障害の影響は当然プレーン数が多いほど小さいが、四プレーンでも訓練ジョブ性能への影響は相対的に小さく抑えられる(具体的な度合いはジョブレイアウトに依存)。障害を検知しジョブは性能低下したまま継続させる。ポートは大半の場合すぐに回復し持続的な影響は残らないが、ポートが落ちたまま戻らない場合はそのノードを排除し修理報告する。 **Figure 6 の事例**: 50K GPU の本番事前学習ジョブ(OpenAI、Cluster A、CX-8 NIC、4x200Gb/s ポート/NIC、MRC が各 QP を全 4 ポートにスプレー)実行中に、**T0 スイッチの光トランシーバ 1 個がグリッチし、その 4 リンクを連続してフラップさせた**。これら 4 リンクは異なる 4 ノードの NIC に接続しており、そのうち 3 ノードは当時訓練ジョブでアクティブだった。 **Figure 6: NIC-T0 スイッチトランシーバのフラップによる影響** ![[_attachments/arxiv-2605.04333/fig06-nic-transceiver-flap-impact.png]] (Figure 6. Cluster A、50K GPU 本番事前学習ジョブでの Job Throughput(Pb/s、青)・Ports down (NIC)(マゼンタ)・Ports down (switch)(茶)の時系列。32 分付近で NIC 側の 4 ポートがダウンし、スループットは約 7 Pb/s から約 5 Pb/s まで低下(約 25% 減)、その後速やかに約 7 Pb/s へ回復した。NIC が認識するリンクダウン時刻とスイッチが認識するリンクダウン時刻は厳密には一致しないと本文で言及される。Source: 論文 Figure 6。) このジョブは同期事前学習であるため最も遅いノードが全体性能を決める。**スループットはフラップの 1 分間で約 25% 低下し、その後即座に全速で回復した。ジョブはクラッシュせず、QP も 1 つも失敗せず、影響を受けたノードもジョブから除去する必要がなかった。**こうしたトランシーバのグリッチは個々のリンクフラップよりも稀だが、時折発生すると明記されている。 **Figure 7: Figure 6 のイベント中の最も影響を受けた 8 ノードのパケットロス率** ![[_attachments/arxiv-2605.04333/fig07-packet-loss-during-flap.png]] (Figure 7. 32〜34 分付近をズームインし、8 ノード(node A〜H)ごとの Loss(pkts/sec)を表示。赤系マーカーはポートがフラップしたノード、青系マーカーはフラップ時にその影響ノードへ能動的に送信していたノードを示す。最大約 6,900 pkts/sec のロスがピークで発生。NIC-T0 ports down(マゼンタ)と NIC-T0 ports down(赤線、右軸)も重ねて表示される。MRC はロスを十分速く回復し、ジョブへの影響は相対的に小さかった。Source: 論文 Figure 7。) 75K GPU の事前学習ジョブでは T1 スイッチの再起動が必要になったケースが 4 件あった(Figure 8、本文のみで図は本ページには埋め込んでいない)。ある事例では、Clustermapper が見る限りスイッチはパケット転送を停止したが稼働状態は維持したままだった(control-plane と data-plane の乖離の一例)。自動化がこれを検知し t=0 でスイッチを再起動、t=2 分までに転送を完全に再開した。約 1/4 の QP が影響を受け、約 580,000 パケットがドロップした。ジョブスループットはスイッチが最初に故障した時点で落ち込むが、QP は素早く故障パスをマップアウトしその後スループットはほぼ影響を受けなかった。スイッチが実際に再起動した瞬間には影響がなかった。 ### 残存する単一障害点(光モジュールの限界) 論文はこの高い耐障害性にもかかわらず、なお残る単一障害点があると明記している。 > 「我々は 800Gb/s の NIC 光学を使用しており、これを 4x200Gb/s のリンクに分割している。**もし NIC トランシーバ自体がフラップした場合、NIC の全ポートを失い、QP が失敗するためこれを乗り切る(ride out)ことができない。** 我々は大規模訓練時にこうしたイベントを実際に目にするが、幸いにも稀である。異なる光学設計であればこの問題を完全に避けられるかもしれない。」これは T0 スイッチ側のトランシーバ(Figure 6 の事例)とは異なる、**NIC 側**の 800Gb/s→4x200Gb/s 分割光学が単一障害点として残ることを示す。T0 スイッチ側のトランシーバ故障は複数の異なるノードの NIC ポートを個別にフラップさせるだけで済むが(Figure 6 で確認されたように 3 ノードが影響を受けてもジョブは継続)、NIC 自身のトランシーバが故障すると、そのノードの MRC が使う全プレーンを同時に失い QP が失敗するため、当該ノードの ride out ができなくなる。 ### テストベッド実験(§5.2) Cluster B での制御実験により MRC の障害応答を検証した。 - **NIC-T0 リンクの逐次故障・復旧**(Fig 9a): T0-local の双方向 `ib_write_bw` で NIC-T0 リンクを 1 本ずつ落とすと、スループットは段階的に減少・回復する。 - **4 リンク同時フラップ**(Fig 9b): 1 枚の CX8 NIC の 8 リンク中 4 本を、共有 OSFP ポートやトランシーバに起因する複数リンク同時障害を模した現実的なシナリオとしてフラップさせた。4 リンク同時ダウン時(約 5 秒時点)に MRC は名目帯域の約半分で素早く安定し、リンク復旧(約 17 秒時点)後は迅速に回復した。 - **T0-T1 リンクの逐次故障**(Fig 9c): Cross-T1 の `ib_write_bw` で 20 本のリンクを順次無効化。テレメトリはほとんどのリンクが故障前に実際にトラフィックを運んでいたことを示し(経路の広い利用を実証)、全体スループットへの影響は最小限だった。 - **8 本の T0-T1 リンク同時フラップ**(Fig 9d): スイッチトランシーバのフラップを想定し 8 本を同時にフラップ・数秒後に復旧。テレメトリはフラップ前にこれらのリンクがトラフィックを運んでいたことを示し、MRC はトラフィックを再ルーティングして迅速に回復、ワークロードレベルの性能影響は無視できた。 - **T0/T1 スイッチ障害**(Fig 10・11): T0 スイッチをダウンさせると EV リマッピング完了後、定常帯域が約 100Gb/s 低下し(故障 T0 に紐づく EV の除去を反映)残存容量に比例した水準で安定する——Fig 9a の結果と整合し、MRC の障害処理がエンドツーエンドの経路可用性で駆動されることを裏付ける。T1 スイッチをダウンさせた場合は、各 QP が多数の経路にスプレーされているため十分な代替 EV が残り、定常帯域の劣化は観測されなかった。 - **EV 単位の意図的パケットロス注入**(Fig 12・13): NVIDIA の MRC デバッグ機能で特定 EV に 20% のパケットドロップを注入。約 51 秒時点で EV-A へのドロップが誘発されると EV-A は直ちに非アクティブへ遷移し EV-B が代替としてアクティブ化された。複数のドロップ率で同じ定性的挙動が確認され、アプリケーションレベルの帯域は安定を維持した。 - **EV 間の動的負荷分散**(Fig 14): 2 フロー(EV-A・EV-B)実験で、EV-A に集中していたトラフィックへ 2 本目のフローを強制的に同じ EV に流すと ECN 経由で輻輳を検知し、MRC が client1-server1 フローを EV-B へ移行させ再分散。両フローともピーク付近の帯域を維持した。 - **NCCL 規模実験**(Fig 15): Cluster B、42K GPU 規模で NCCL-tests の sendrecv ベンチマークを実施し、大メッセージサイズで最大 92 GB/s のスループットを達成。 ### RoCE との比較(§5.2.7) Cluster C(AMD Pollara、400Gb/s NIC、Broadcom TH5)で MRC(4 プレーン x 100Gb/s、PFC 無効・SRv6)対 RoCE(単一プレーン、400Gb/s、ECMP、PFC 有効・DCQCN 輻輳制御)を比較した。 - 64-way ring all-reduce(Fig 16): ロスなし条件で RoCE(1 QP)は ECMP ハッシュ衝突により概ね理論帯域の半分に留まる。QP スケーリング(RoCE の従来的な負荷分散改善策)は有効だが 8 QP を超えると効果が薄い。対して MRC(1 QP、256 経路スプレー)は 16 QP の RoCE を上回る。0.1%/1% のパケットロスを注入すると、RoCE は設計上ロス耐性がなく性能が大きく劣化する一方、MRC は大メッセージサイズで 0.1% ロスの影響をほぼ無視できる。**1% ロスでは RoCE はほぼ使用不能になり、MRC も意図した帯域の約 1/3 にとどまる**——短時間のロスバーストは乗り切れるが継続的な訓練には不十分と明記される。 - 64-way all-to-all(Fig 17): 複数 QP が同時にアクティブになるため RoCE の負荷分散問題は目立たなくなり QP スケーリングの効果も薄いが、全メッセージサイズで MRC が RoCE を上回る。ロス条件下では小メッセージサイズで RoCE の性能低下が特に顕著。 ### Collateral damage(incast、§5.2.8) 7-to-1 incast パターンに加え、同一ラック内の別ノード宛に victim フローを流す実験(Fig 18)。RoCE で DCQCN を使わず PFC のみに依存すると victim フローは incast フローとほぼ同レートまで押し下げられる。DCQCN は改善するが不十分——1 QP(Fig 18a)で victim フロー性能はなお約 25% 低下、8 QP(Fig 18b)では平均的な影響は小さくなるものの、1 秒間隔で victim のスループットが 100Gbps(最適比 75% 減)まで落ちる区間がある。**MRC(Fig 18c)はボトルネックリンクをほぼ完璧に incast フロー間で共有し、victim フローへの影響がなかった。** DCQCN パラメータのチューニングで軽減できる可能性はあるが、トラフィックパターンに強く依存し適切な調整は難しく、一部ハイパースケーラーは本番で DCQCN を無効化しているとも述べる([16])。 ## 考察静的ソースルーティング(SRv6)は非常に良い可観測性を与え、運用負荷を軽減する。MRC の耐障害性により、多くのネットワーク障害は修理の緊急性すら持たない(T0-T1 リンクフラップの扱いが好例)。Clustermapper のミリ秒単位の継続的プロービングは、SRv6 のおかげでデータプレーン内でトラフィックとして扱われ ICMP のようにコントロールプレーンでレート制限されないため、高頻度プロービングが可能になり、フォワーディングプレーン健全性についての ground truth を与える。これは pingmesh のようなリモートノードへの往復プローブと異なり、送信元へ戻る自己プローブであるため、対象ノードがダウンしていても解釈が容易という利点がある。 ## 強み / 弱点・課題 **Strengths** - 本番実証: OpenAI・Microsoft の最大級クラスタで、ChatGPT・Codex 向けフロンティアモデルの訓練という実運用ワークロードで有効性を確認している。 - 光トランシーバのグリッチ(Figure 6)のような希少だが実際に発生する障害でも、ジョブをクラッシュさせず自動的に乗り切れることを本番データで実証している。 - SRv6 の決定的経路により、故障箇所の正確な特定(T0-T1 か NIC-T0 かの弁別)と高頻度プロービングが可能になり、運用チームを少人数に保てる。 - 標準 Verbs API・QP 抽象を保持しつつ RoCEv2 への最小拡張として実装しており、既存エコシステムとの親和性が高い。MRC 仕様は OCP でオープンライセンス公開されている。 **Weaknesses / Limitations(論文が明示)** - **NIC 側 800Gb/s 光学を 4x200Gb/s に分割する構成では、NIC トランシーバ自体のフラップに対して単一障害点が残る**——全ポートを失い QP が失敗するため ride out できない。論文は「異なる光学設計であればこの問題を完全に避けられるかもしれない」と述べるにとどまり、解決策は示していない。 - 1% のパケットロス下では MRC も意図したスループットの約 1/3 にとどまり、継続的な訓練には不十分(短時間のロスバーストへの耐性にとどまる)。 - MRC と RoCE の大規模本番環境での直接比較デプロイは存在せず、比較は AMD Pollara(Cluster C)・Broadcom Thor Ultra(Cluster D)の小規模テストベッドに限られる。 - 単一プレーンに過度に集中して T0-T1 リンクを失いすぎた場合、そのプレーンがボトルネックになりうるという理論的な弱点があるが、本番では未観測と述べる。 - NIC-T0 リンクが完全故障ではなく許容できない高パケットロス率を示す場合、MRC 自身は自端末側か相手端末側かを区別できず、Clustermapper のポリシー判断(denylist エントリ)に委ねる必要がある。