> [!abstract] 概要(EuroSys '26 abstract の日本語訳) > 分散 AI 訓練はネットワーク障害にしばしば見舞われる。とりわけスイッチとホストの間の last hop で発生するネットワーク障害は接続喪失を招き、訓練ジョブの停滞と最終的な失敗につながる。これは典型的には fail-stop 機構とそれに続く再起動によって処理され、大きな非効率を招く。本稿では ReCCL を提示する。これは、ネットワーク障害が発生した際に代替経路へシームレスにフェイルオーバーすることで訓練の進行を保存できる、初のネットワーク耐障害 collective communication library(CCL)である。フェイルオーバー中、ReCCL は動的なチャネル負荷分散とホスト内 GPU ルーティングを用いて通信性能を改善しながら、通信状態を同期状態に保つ。我々の評価は、ReCCL が最小限の性能損失でシームレスにフェイルオーバーを実行できることを示す。さらに我々のシミュレーションは、大規模分散 AI 訓練ワークロードにおいて、フェイルオーバーが GPU 時間の大幅な節約を達成するために効果的に利用できることも示す。 ## 論文情報 - タイトル: Handling Network Faults in Distributed AI Training: Failover is Now an Option - 著者: Xin Zhe Khooi(筆頭・ByteDance インターン時、National University of Singapore)、Zhuo Jiang(責任著者)ほか、ByteDance と National University of Singapore の共著者24名(Mun Choon Chan が NUS 側の最終著者) - 媒体: 21st European Conference on Computer Systems (EuroSys '26)、2026-04-27〜30、エディンバラ、英国。ACM、16 ページ - DOI: https://doi.org/10.1145/3767295.3769322 - ISBN: 979-8-4007-2212-7/26/04 - Shepherd: Philip Levis ## 概要 訓練ジョブがスイッチ〜ホスト間の last-hop ネットワーク障害(リンクフラッピング・RNIC 故障・ToR スイッチ障害)に遭遇すると、既存の CCL(NCCL 等)は通信路の障害を想定しておらず、CCL がスタックしクラッシュして訓練ジョブの再起動を強いる。本論文は、こうした障害はソフトウェア・メモリ・GPU 由来の障害と異なりシステム状態自体を破壊しないため、再起動ではなくフェイルオーバーで扱うべきだと主張し、その実現手段として ReCCL を提案する。ReCCL は NCCL の in-place 置き換えとして動作し、既存の訓練フレームワークの再コンパイルを必要としない。 ## 問題設定 - **入力**: last-hop(ToR スイッチ〜ホスト RNIC 間)のネットワーク障害イベント(リンクフラッピング・RNIC 故障・ToR スイッチ全断)。 - **前提**: 現代の GPU サーバーは GPU ごとに複数の single-port RNIC を持つ(冗長性がハードウェアレベルで既に存在する)。ジョブスケジューラは中央調停者として障害検知・ノード除外・再起動を担う既存の fleet management システムが存在する。 - **必要なデータ**: RNIC の Completion Queue Event(CQE)エラー、CCL のチャネル状態(どの channel がどの RNIC を使うか)、communication group とトポロジ(rail-based/rail-optimized)情報。 - **出力**: ネットワーク障害発生後も訓練ジョブを再起動せずに継続させる、代替経路へのフェイルオーバーと(障害復旧時の)リカバリ。 ## 提案手法 ReCCL は Soft Bonding(s-Bond、§3.1)・Dynamic Channel Rebalancing(DCR、§3.2.1)・Transit GPU over NVLink(NVL、§3.2.2)の3つの技術要素からなる。 - **アーキテクチャ**: ReCCL は既存 CCL(NCCL)に動的リンクされる shared library として組み込まれ、drop-in replacement として機能する(Figure 4)。CCL の初期化フェーズで各ホスト間 GPU-to-GPU パスに primary/backup の2経路を事前設定し(proactive setup)、通常運用時は primary のみを使用する。 **Figure 2: CCL における GPU-GPU 通信アーキテクチャの概観** ![[_attachments/2026_Unknown_Handling_Network_Faults_Distributed_AI/fig02-ccl-architecture.png]] (Figure 2. Sender/Receiver 双方の CPU Proxy・Channel Buffer・RDMA NIC・Channel Scheduler/Assembler の関係を示す。receiver 駆動の CTS(Clear-to-Send)方式で、receiver が空き領域を通知してから sender が RDMA Write でデータを転送する構造が、s-Bond や DCR が操作するチャネルの基本単位になる。Source: Adapted from [13, Fig. 14].) - **s-Bond(Soft Bonding)**: ハードウェアボンディング(デュアルポート RNIC の集約)と異なり、single-port RNIC を前提にソフトウェアで primary-backup フェイルオーバーを実現する。 - **backup RNIC の選定**: PCIe スイッチ跨ぎ(+1)・PCIe root complex 跨ぎ(+100)・NUMA ノード跨ぎ(+200)のコストで相対距離を定量化し、最短距離の RNIC を backup に選ぶ。同一 PCIe スイッチを共有する RNIC 間では GPU 割当数に制約を課し負荷分散のタイブレークとする。 - **フェイルオーバー経路**: sender と receiver の backup RNIC 同士を対応づける backup-to-backup 方式を採用し、rail-based トポロジに沿った disjoint な backup path を確立する。これにより ToR スイッチが完全に落ちても訓練は中断なく継続できる。 **Figure 5: primary/backup RNIC の対応づけとフェイルオーバー経路** ![[_attachments/2026_Unknown_Handling_Network_Faults_Distributed_AI/fig05-primary-backup-rnic.png]] (Figure 5. rail-based ネットワークトポロジ上で、各 GPU が primary RNIC(緑線)と backup RNIC(赤線)にどう対応づけられるかを示す簡略図。backup 側は異なる rail switch(RSW)へ接続されるため、単一の ToR/rail switch 障害でも backup path が生き残る。Source: Figure 5.) - **通信状態の同期(§3.1.2)**: sender と receiver の双方が (1) 同じ経路(primary/backup)を使うこと、(2) データポインタが同期して前進することの2条件を満たす必要がある。ACK ロスやデータポインタの不一致(ミスアラインメント)が誤った計算結果や RNR エラーを招くため、Figure 6 に示す in-band 同期フェーズ(sender が receiver に通知 → receiver の状態を probe → receiver 側の CTS 再発行完了を待って再送再開)を導入する。 **Figure 6: sender 起点フェイルオーバーのシーケンス** ![[_attachments/2026_Unknown_Handling_Network_Faults_Distributed_AI/fig06-failover-sequence.png]] (Figure 6. sender が primary 経路の障害を検知すると receiver に通知し、receiver 側の状態を probe しながらデータポインタの整合(A, B)を確認したのち backup 経路で再送を再開する一連の手順を示す。ACK ロスト時の data_ptr 更新・CTS 再発行の待ち合わせが明示されている。Source: Figure 6.) - **数式によるフェイルオーバー判定条件**: チェックポイント間隔 $T_{interval}$、経過時間 $t_{elapsed}$、再起動オーバーヘッド $T_{reload}$、検知時間 $T_{detect}$、RNIC 再送タイムアウト $T_{timeout}$、フェイルオーバー時のスローダウン率 $k$ を用いて、$t_{restart} = T_{timeout} + T_{detect} + T_{reload} + T_{interval}$(式1)、$t_{failover} = T_{timeout} + k(T_{interval} - t_{elapsed}) + T_{reload}$(式2)を定義し、$t_{failover} < t_{restart}$(式3)を整理すると $t_{elapsed} > \frac{T_{interval}(k-1) - T_{detect}}{k}$(式4)が得られる。$k=1.5, T_{detect}=0$ の場合、チェックポイント間隔の 1/3 を過ぎていればフェイルオーバーが有利になる(式5)。 - **DCR(Dynamic Channel Rebalancing、§3.2.1)**: フェイルオーバー後、backup RNIC を共有するチャネルが straggler 化する問題に対し、障害のある(=backup RNIC 使用中の)チャネルを無効化し、残りの健全なチャネルにデータを再分配する。全ワーカーノードで DCR のタイミングを一致させる必要があるため、周期的な AllGather でシステム状態(RNIC 状態)と完了済み集団操作数($ops_{done}$)をノード間で共有し、事前定義したオフセット分の操作数を経てから一斉に DCR を発動する(Figure 7b)。DCR はチャネルが disjoint な RNIC を使う場合(大規模通信グループ)にのみ有効で、小規模通信グループ(全チャネルが同一 RNIC を共有)には効果がない。 **Figure 7: DCR(Dynamic Channel Rebalancing)の仕組み** ![[_attachments/2026_Unknown_Handling_Network_Faults_Distributed_AI/fig07-dcr-illustration.png]] (Figure 7. (a) RNIC1 を共有する c0・c1・c4・c5 が straggler 化する例と、DCR による c0・c4 の無効化で c1・c5 の性能が回復する様子。(b) 全ノードが周期的 AllGather で RNIC 状態と $ops_{done}$ を共有し、既定オフセット(この例では3)を経た $ops_{done}=104$ 以降に DCR を一斉発動する同期手順。Source: Figure 7.) - **NVL(Transit GPU over NVLink、§3.2.2)**: DCR が適用できない小規模通信グループに対しては、高速 GPU インターコネクト(NVLink)を用いて中間 GPU(transit GPU)経由でデータをバックアップ RNIC へルーティングし、ホスト内の PCIe ボトルネックを回避する(Figure 8)。トレードオフとして transit buffer 用の GPU メモリ(チャネルあたり30〜40MB)を消費する。 - **実装上の工夫**: NCCL v2.19 への統合は主に `net_ib.cc`(s-Bond と NVL のデータ・制御パス)と `enqueue.cc`(DCR 用の `addCollToPlan` 修正)の2ファイルに絞られる。fast-failover のためにグローバル RNIC 状態を維持し、アイドルチャネルもタイムアウトを待たず即座にフェイルオーバーできるようにする。GPU メモリの over-allocation を防ぐため、NVL 用 transit buffer にはユーザ設定可能な上限を設ける。 ## 新規性 既存の耐障害アプローチには2系統ある。(1) ハードウェア冗長化(デュアルポート RNIC によるハードウェアボンディング)はトポロジ依存でコストが高く、RNIC 自体の故障には対処できない。(2) ソフトウェアマスキング層(LubeRDMA 等の application-agnostic な userspace IB Verbs プロバイダ)は、追加のソフトウェアエージェントを要し単一障害点を生む上、one-sided Verbs(CCL のホスト間通信で使用)未対応でホスト内経路への制御・可視性も欠く。ReCCL はトポロジ・ハードウェア非依存で外部エージェント不要、かつ CCL 自身がホスト内外の GPU-to-GPU 経路を制御できる立場を活かして性能を最大化する点で両者と異なる。著者らは、NCCL 開発者自身が primary-backup フェイルオーバーの導入を「難問」と述べていた点([1])を踏まえ、これが CCL レベルで実現された初めての事例だと位置づける。 ## 実験設定 - **シミュレーション(§4.1)**: Llama3-405B 訓練(16k GPU、1925時間)をケーススタディとし、RNIC-ToR リンク月間障害率0.057%・ToR スイッチ月間障害率0.051%([41]由来)、チェックポイント間隔1時間、$T_{detect}$=0.5時間、$T_{reload}$=0.5時間、$k$=1.03(1障害)/1.20(2障害)/1.50(3障害以上)をデフォルトパラメータとし(Table 1)、10,000回の反復シミュレーションを実施。比較対象は fault-free・restart・restart+scaling(DP 次元16、障害ノードは24時間後に交換)。 - **テストベッド評価(§4.2)**: 4ノード×8 GPU(NVIDIA Hopper、96GB HBM3)、ノードあたり4基の NVIDIA BlueField-3 SuperNIC(400G)、rail-optimized トポロジ・RoCEv2・51.2Tbps Tomahawk5 ASIC スイッチによる32 GPU 構成。Megatron-LM 上で BEVFormer-V2、Llama2(7B/13B/70B)を用いて評価。比較対象は vanilla NCCL(fault-free 基準)、ReCCL(s-Bond のみ)、ReCCL(全最適化込み)。 - **評価指標**: GPU 時間(シミュレーション)、正規化スローダウン率 $k$(反復あたり訓練時間の相対増加)、正規化バスバンド幅(NCCL tests によるフェイルオーバー時の集合通信性能)、GPU メモリオーバーヘッド。 ## 実験結果 - **エンドツーエンド訓練時間(シミュレーション)**: ReCCL は restart 比で中央値の追加 GPU 時間を64.96%、restart+scaling 比で80.97%削減する(99パーセンタイルでそれぞれ65.43%・80.08%)。50%のスローダウン(k=1.5、非現実的に大きい想定)でも、1分間隔という積極的なチェックポインティングの下で20万 GPU 時間超の節約が見込まれる(Figure 9, 10)。 **Figure 9: fault-free・restart・restart+scaling・ReCCL の GPU 時間分布比較** ![[_attachments/2026_Unknown_Handling_Network_Faults_Distributed_AI/fig09-gpu-hours-savings.png]] (Figure 9. Llama3-405B・16k GPU 訓練シミュレーション(10,000 反復)における、ネットワーク障害発生時の総所要 GPU 時間の CDF。ReCCL(赤)は restart(緑破線)・restart+scaling(青破線)より一貫して少ない GPU 時間で完了する。Source: Figure 9.) - **フォールト無し性能**: ReCCL は vanilla NCCL と比較し、複数モデルでの中央値・99パーセンタイルの反復あたり時間が±0.5%以内に収まる(追加オーバーヘッドなし)。 - **フェイルオーバー時のスローダウン**: BEVFormer-V2・Llama2(7B/13B/70B)で $k$ は1.004〜1.0215(全最適化込み)。Llama2-7B では s-Bond のみと全最適化ありの差が最大15%に達する(小モデルほど compute-to-communication 比が小さく、データ並列オンリーの並列化戦略のため相対的な通信負荷が大きい)。Llama2-70B は絶対時間増加が Llama2-7B比で最大4.36倍だが、ベースライン反復時間が桁違いに大きいため相対スローダウンは小さく見える(Figure 11)。 **Figure 11: モデル別のフェイルオーバー時スローダウン(反復あたり)** ![[_attachments/2026_Unknown_Handling_Network_Faults_Distributed_AI/fig11-avg-slowdown.png]] (Figure 11. BEVFormer-V2・Llama2-7B/13B/70B における反復あたり平均スローダウン(%)。ReCCL(全最適化)は s-Bond のみと比べ全モデルで一貫して低いスローダウンを示し、特に Llama2-7B では 2.15% 対 17.82% と差が顕著。Source: Figure 11.) - **並列化戦略の影響**: TP・PP の並列度が大きいほどフェイルオーバー時のスローダウンは減少し、PP=1 かつ TP≥4、あるいは TP=1 かつ PP≥4 でスローダウンはほぼゼロに収束する(Figure 12)。 - **障害種別の影響**: 1 RNIC/link 障害と rail switch 障害はほぼ同じ影響(同じチャネル集合が巻き込まれるため)。2 RNIC/link 障害は s-Bond のみで約18%のスローダウン、DCR/NVL 込みで約5%増(健全チャネルが半減するため)。 - **集合通信性能(ablation、§4.2.2)**: 大規模通信グループ(AllReduce)では DCR が最良(1 RNIC/rail switch 障害で約75%、2 RNIC 障害で約55%の性能回復)、次いで NVL(約50%、RNIC 共有由来)。小規模通信グループ(Multi-AllReduce)では NVL が vanilla s-Bond・DCR 比で最大11%の性能改善を示す一方、DCR は disjoint channel がないため効果なし。 - **GPU メモリオーバーヘッド**: s-Bond・DCR はゼロオーバーヘッド。NVL はチャネルあたり30〜40MB、8チャネル構成の AllReduce ワークロードで GPU あたり281〜320MB(利用可能 GPU メモリの1%未満)。 ## 考察 - **分析モデル(§5)**: 二項分布に基づくリンク障害モデルから、$E(T_{ReCCL}^{complete}) \le E(T_{restart}^{complete})$(ReCCL は常により有利な選択肢を採るため)を導出。月間リンク障害率0.057%の下では、64k GPU ジョブで約4.63%、16k GPU で約1.25%の改善が見込まれ、1k・4k GPU の小規模ジョブでは1%未満にとどまる(ReCCL の複雑性コストが利益を上回りうる)。64k GPU・3か月訓練($150M 相当のレンタルコスト)における4%削減は数百万ドル規模の節約に相当する。 - **本番展開に関する議論(§6)**: 著者らは、先行研究([41])が「カスタム CCL の本番導入は困難」と主張していたのに対し、社内チーム・外部パートナーとの継続的連携と、既存訓練フレームワークの再コンパイル不要という設計により、実際にはそうではなかったと反論する。ReCCL は本番クラスタでの段階的ロールアウト中であり、計画的なネットワークメンテナンス(スイッチのインプレースアップグレード、予防的なホットリンク交換)を訓練ジョブを止めずに実施できる副次的利点も述べる。 ## 強み / 弱点・課題 - **強み**: - トポロジ・ハードウェア非依存で single-port RNIC 環境でも動作し、既存訓練フレームワークの再コンパイル不要な drop-in replacement。 - フェイルオーバー判定式(式4)がジョブスケジューラとの連携インタフェースとして明快。 - フェイルオーバー時のスローダウンをテストベッド実測で $k<1.1$ に抑えており、1024 GPU 規模の本番早期トライアルでも堅牢性を確認済みと述べる。 - **弱点・限界**: - DCR は disjoint なチャネルを持つ大規模通信グループにしか効かず、小規模通信グループでは NVL に頼らざるを得ない。 - NVL は GPU メモリオーバーヘッドを要し、GPU メモリ使用量の見積もりは著者ら自身も「難しい問題」と認めている(best-effort な閾値管理)。 - 複数のネットワーク障害が重なるとDCRで無効化されるチャネル数が増え、性能利得が縮小する(著者らも極端なケースでは restart の方が有利になりうると認める)。 - ジョブスケジューラ側の設計(式4の条件をいつ・どう enforce するか)は本論文のスコープ外とされ、統合の詳細は示されていない。 - 評価はテストベッド32 GPU規模にとどまり、大規模本番環境での定量評価(GPU 時間削減の実測)はシミュレーションに依存する。