# 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]]) ## 未解決の問い - NIC 枚数の最適値はどう決めるべきか? ワークロードにより 1〜8 枚で性能が異なるが nccl-tests は参考値(各 1 回実行)であり統計的評価手法が確立していない。 - サービスとして任意ノード数を払い出す場合、NCCL_CROSS_NIC=0 を確実に適用させる仕組みはどうあるべきか(ユーザーが環境変数を上書きするリスクをどう管理するか)? - Oversubscription 比(現行 7:1)と Spine を通過するトラフィック量の関係を定量化する手法は? ## 関連 - [[集合通信]] — 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 経路によるソフトウェアフェイルオーバー ## 出典 - [[@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]]