# 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 除去は難しいことも報告されている。 ## 未解決の問い - 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スイッチ導入とその挑戦]] — 実運用事例 ## 出典 - [[@2023__arXiv__Rail-only - A Low-Cost High-Performance Network for Training LLMs with Trillion Parameters]] - [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]