# Rail-Optimizedトポロジ ## 定義 GPU サーバーの NIC(ネットワークインターフェースカード)番号と Leaf スイッチ(Rail)の対応を固定した GPU インターコネクトのトポロジ設計。サーバー内の GPU N 番と接続する NIC N 番は、必ず Leaf N 番(Rail N)に繋がるよう配線する。これにより、同じ GPU 番号を持つノード間の通信が同一 Rail(Leaf)を経由することになり、Spine を跨ぐクロス通信を最小化できる。NCCL 等の集合通信ライブラリはこのトポロジを前提に AllReduce リングを Leaf 内で形成しようとする。 ## 横断的知見 - **NCCL はデフォルトでトポロジを正しく選択しない(ソース: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])**: 3 ノード以上の AllReduce では NCCL がデフォルトで Spine 越えのリングを形成することがある。特に奇数ノードで顕著。`NCCL_CROSS_NIC=0` を設定して同一 NIC を同一リングで使うよう指定することで Leaf 内にリングが閉じる。設定による性能劣化は報告されていない。 - **異種 GPU サーバー混在時は物理配線の再チェックが必須(ソース: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])**: サーバーベンダーにより GPU/NIC の物理ポート番号体系が異なる(例: NVIDIA DGX H100 と DELL XE9680)。同じ GPU 番号のサーバーを混在させると NIC-Leaf の対応がずれ、Rail-Optimized を正しく保てなくなる。Full Bisection Bandwidth 時代は帯域余裕で問題が顕在化しなかったが、Oversubscription 構成では Spine 越えトラフィックが直接性能劣化に繋がる。 - **Rail-only への発展(ソース: [[@2023__arXiv__Rail-only - A Low-Cost High-Performance Network for Training LLMs with Trillion Parameters]])**: LLM 訓練トラフィックの 99% 超が同一 Rail 内に留まるという観測から、Spine 層を完全に除去する Rail-only アーキテクチャが提案されている。スイッチ・トランシーバコストを 38〜77% 削減。実際の運用ではサービス形態(マルチユーザー・任意ノード数払い出し)により Spine 除去は難しいことも報告されている。 - **HPN はレール最適化 + デュアル ToR + デュアルプレーンの組み合わせで 1 セグメントに 1024 GPU を収容した**: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] は NVIDIA が提唱したレール最適化を 51.2Tbps シングルチップスイッチ × 16 台（デュアル ToR で 1 NIC に 2 ToR）と組み合わせ、1 ホストの 3.2Tbps を 16 台の ToR スイッチに分散させることで 1 セグメント 1024 GPU を実現した。Rail-only と異なり Tier2 では any-to-any 接続を維持しており、MoE モデルや複数テナントのクロスレール通信に対応する。本番ジョブの 96.3% が 1 セグメント内に収まり、Tier1 内のみで最高性能を享受できている。(Source: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]]) - **非スタック型デュアル ToR はレール最適化の信頼性を強化する**: HPN が Rail-Optimized トポロジをデュアル ToR と組み合わせる場合、スタック型デュアル ToR では連鎖障害（過去 3 年で重大障害の 40% 以上）が生じる。非スタック型では ToR 間の直接リンクを除去し BGP で自律収束させることで、1 台の ToR 障害が 6.25% の性能劣化に留まる。(Source: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]]) - **CCL の backup path が rail の同一性を利用して cross-rail トラフィックを避ける**: [[@2026__EuroSys__Handling Network Faults in Distributed AI Training]](ReCCL)は、GPU の primary RNIC が属する rail と disjoint な rail 上に backup RNIC を選び、sender-backup と receiver-backup を対応づける「backup-to-backup」方式でフェイルオーバー経路を確立する。これにより ToR スイッチが完全に落ちても、フェイルオーバー通信は同一 rail 内に留まり cross-rail の追加ホップを発生させない。HPN のデュアル ToR がハードウェア冗長化で ToR 障害の影響を性能劣化に留める(6.25%)のに対し、ReCCL はソフトウェア(CCL)側で single-port RNIC のまま同種の効果——ToR 障害時も訓練を中断させない——を実現しており、Rail-Optimized トポロジの均質な rail 構造がハードウェア冗長化とソフトウェアフェイルオーバーの双方で異なる耐障害設計の土台になっていることを示す。(Source: [[@2026__EuroSys__Handling Network Faults in Distributed AI Training]], [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]]) - **NCCL_CROSS_NIC=0 が防ぐ「Spine越えリング」は、NCCL自身がPXNという機構で先に回避しようとしていた問題と同根である**: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]は3ノード以上のAllReduceでNCCLがデフォルトでSpineを越えるリングを形成する問題への運用対応として`NCCL_CROSS_NIC=0`を報告するが、[[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]はより早い段階(NCCL 2.12、2022年)で、PXN機能によりNVLink経由で宛先と同じrail上のGPUへデータを移してからネットワークに出すことで、そもそもrailを跨ぐ経路が選ばれにくくなるようアルゴリズム側から手当てしていたことを示す。前者はユーザーが明示的に環境変数で制約する運用回避策であるのに対し、後者はNCCL自身がPXNで経路選択を最適化する機構的解決であり、両者は「rail-optimizedトポロジの前提(同一GPU番号=同一Rail)をNCCLがどこまで自動的に守れるか」という同じ課題に、異なるレイヤー(ユーザー設定 vs. ライブラリ内部機構)から取り組んでいる。(Source: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]], [[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]) - **PXNはall2allのO(N²)メッセージ問題とall-reduceのring閉塞問題という異なる2つの課題を、同一機構(rail内へのNVLink経由データ移動)で解決する**: all-reduceはメッセージがtree/ringで最適化できるためNCCL_CROSS_NIC=0のような経路制約が有効に働く一方、all2allは各GPUペア間のメッセージが distinct でtree/ringによる最適化ができず、O(N²)個のメッセージがネットワークホットスポットを生みやすい。[[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]はPXNが(1)最大8メッセージを1つに集約するmultireceiveによるメッセージレート改善、(2)rail内への経路集約によるSpine越えトラフィック削減、の2軸でall2all性能を最大2.55倍(DGX A100・128ノード/1024GPU実測)改善したと報告する。Rail-Optimizedトポロジがall-reduce向けに設計された前提(NCCLのring形成)を、all2allという別の通信パターンにまで機構的に拡張した事例である。(Source: [[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]) - **Rail-Optimized は、GPU サーバーと Leaf の対応を固定する配線・トポロジ設計として 400GbE RoCEv2 の初期導入時点から使われている**: [[@2023__JANOG52__AI ML基盤の400G DCネットワークを構築した話]] は、各 Leaf スイッチにケーブルを1本ずつ接続し、アプリケーション側で最適な NIC を選ぶ構成として Rail Optimized を採用した。後続の `NCCL_CROSS_NIC=0` や PXN は、この物理対応を集合通信の経路選択でも維持するためのソフトウェア側の補完と位置づけられる。(Source: [[@2023__JANOG52__AI ML基盤の400G DCネットワークを構築した話]], [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) ## 未解決の問い - NIC 枚数の最適値はどう決めるべきか? ワークロードにより 1〜8 枚で性能が異なるが nccl-tests は参考値(各 1 回実行)であり統計的評価手法が確立していない。 - サービスとして任意ノード数を払い出す場合、NCCL_CROSS_NIC=0 を確実に適用させる仕組みはどうあるべきか(ユーザーが環境変数を上書きするリスクをどう管理するか)? - Oversubscription 比(現行 7:1)と Spine を通過するトラフィック量の関係を定量化する手法は? - 400GbE 世代の「アプリケーション側で最適な NIC を選ぶ」運用を、複数 GPU サーバー種別・800GbE 構成・任意ノード数のサービス提供へどう自動化すべきか。([[@2023__JANOG52__AI ML基盤の400G DCネットワークを構築した話]], [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) ## 関連 - [[集合通信]] — NCCL の Ring-AllReduce がこのトポロジの上で動作する - [[マルチベンダーLosslessネットワーク]] — Rail-Optimized を Lossless ネットワーク上で動かす際のチューニング課題 - [[Fat-Tree]] — Rails を Spine で接続した場合の等価物 - [[@2023__arXiv__Rail-only - A Low-Cost High-Performance Network for Training LLMs with Trillion Parameters]] — Spine 除去への発展 - [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]] — 実運用事例 - [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] — デュアル ToR + デュアルプレーン組み合わせによる本番大規模展開 - [[@2026__EuroSys__Handling Network Faults in Distributed AI Training]] — rail 内 disjoint な backup RNIC 経路によるソフトウェアフェイルオーバー - [[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]] — PXN によるrail内経路集約とall2all性能改善(NCCL側の機構的対応) ## 出典 - [[@2023__arXiv__Rail-only - A Low-Cost High-Performance Network for Training LLMs with Trillion Parameters]] - [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]] - [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] - [[@2026__EuroSys__Handling Network Faults in Distributed AI Training]] - [[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]