マルチプレーンClosトポロジ - yuuk1's Digital Garden

# マルチプレーンClosトポロジ ## 定義マルチプレーン Clos トポロジ（Multi-Plane Clos Topology）は、1 枚の 800G NIC を 8 本の独立した 100G 物理プレーン（平面）に分割することで、スイッチ段数を増やさずに大規模 GPU クラスタへの拡張を実現するネットワークトポロジ設計である。[[OpenAI]] が [[MRC]] および [[SRv6]] と組み合わせて採用し、スイッチ 2 段で 131,000 GPU 超への拡張を実現した。(Source: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) 主要特性: - **水平スケーリング**: スイッチ段数追加（縦方向）の代わりに NIC を複数プレーンに分割（横方向） - **プレーン独立性**: 各プレーンが物理的に独立するため、1 プレーンの障害が他に波及しない - **2 段スケーリング**: スイッチ 2 段構成で 131,000 GPU 超まで拡張可能（従来型 Fat-Tree より少ない段数） ## 横断的知見 - **VL2(2009)のデータセンター向け 2 段 Clos がコモディティスイッチ Clos の起点**: [[VL2]]([[@2009__SIGCOMM__VL2 - A Scalable and Flexible Data Center Network]])は Intermediate(スパイン)と Aggregation(リーフ)の 2 層折り畳み Clos + [[Valiant Load Balancing]] でスイッチ間 10G / サーバ 1G のリンク速度差を活用した。Broadcom ASIC の標準機能(OSPF・ECMP)のみを使い、スイッチハードウェア変更不要でノーオーバサブスクリプションを実現した最初の実用設計。マルチプレーン Clos は「2 段 + コモディティ」というこの設計哲学を GPU クラスタ規模に外挿する試みと位置づけられる。(Source: [[@2009__SIGCOMM__VL2 - A Scalable and Flexible Data Center Network]], [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - 従来の Fat-Tree / Clos トポロジは帯域幅を確保するためにスイッチ段数を増やす縦方向スケーリングに依存していた。マルチプレーン設計は NIC 側で分割することで、スイッチ側の複雑性と遅延増大を抑制する逆転の発想である。(Source: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - **Fat-Tree はマルチプレーン Clos の直接の先祖**: [[Mohammad Al-Fares]] らが SIGCOMM 2008 で提案した k-ary Fat-Tree（[[@2008__SIGCOMM__A Scalable Commodity Data Center Network Architecture]]）は Clos ネットワークの特殊形であり、均質な商用スイッチで全二分帯域幅を実現した最初の大規模実用アーキテクチャである。マルチプレーン設計は Fat-Tree のさらなる発展形として、NIC を複数プレーンに分割することでスイッチ段数をさらに削減する。Fat-Tree の「均質スイッチ構成」という設計哲学は両者で共通している。(Source: [[@2008__SIGCOMM__A Scalable Commodity Data Center Network Architecture]], [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - [[SAKURAONE]] の 2 段 Spine-Leaf トポロジ（[[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]）とは規模の前提が異なるが、「スイッチ段数を最小化する」という指向は共通する。[[MRC]] のパスプレーン間スプレーとの組み合わせ効果は比較すると興味深い。(Source: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **マルチプレーンは論理分割、シャフル配線は物理層の拡張**: JANOG58 の発表は、マルチプレーンファブリックが NVIDIA B300 世代 ConnectX-8 から登場した論理分割技術であるとした上で、これと[[光ファイバーシャフル配線]]という物理光ファイバーの再結線技術を組み合わせることで GPU クラスタ規模をシャフル配線無しの 8192 GPU(64 Spines・128 Leaves)からシャフル配線有りの 32768 GPU(256 Spines・512 Leaves)へ拡張できると説明する。これは LinkedIn 記事のマルチプレーン設計論(NIC のプレーン分割)に、物理配線レベルでの拡張手段という新しいレイヤーを補完する知見である。(Source: [[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]]) - **プレーン数(4 分割 vs 8 分割)は実運用でトレードオフとして選択されており、単一の最適解ではない**: 原論文([[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]])が報告する 4 つの本番/テストベッドクラスタのうち、Cluster A は NVIDIA GB200 + CX8(800Gbps)を 4x200Gbps の 4 プレーンで、Cluster B は同じ NIC を 8x100Gbps の 8 プレーンで構成する(Table 1)。プレーン数を増やすほど NIC ポート障害時に失うプレーンの割合は小さくなる(8 プレーンの方が単一ポート障害の影響は明らかに小さい)が、4 プレーンでも「訓練ジョブ性能への影響は相対的に小さく抑えられる」と明記されており、プレーン数の選択はポート密度・スイッチラインレートの制約と NIC 障害時の耐性のトレードオフとして運用者が選ぶ設計変数であることが、単一の理論的最適解ではなく複数の本番構成の併存という形で裏付けられた。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]]) - **[[SRv6]] でのプレーン選択と [[MRC]] のプレーン間スプレーの連携が判明した**: MRC は QP 起動時に EV(entropy value)をプレーンごとに均等な数だけ選び、SRv6 アドレス生成時に EV からプレーン番号を全 uSID へ埋め込む(§2.3 Figure 3)。さらに MRC は EV が active set から外れた際、**同じプレーンの別 EV に置き換える**という設計判断を取っており、これによりプレーン間の負荷分散が常に厳密に均等に保たれる(全 NIC が全プレーンを利用可能な場合)。障害プレーンの検知・回避粒度は EV 単位(即座)とプレーン単位(Clustermapper のポリシー判断による denylist)の 2 段階に分かれる——リンク単体の故障は EV レベルで自動対処されるが、「NIC-T0 リンクが完全故障ではなく許容できない高損失率」というグレーな場合は、MRC 自身では自端末側か相手端末側かを判別できず Clustermapper の外部判断(denylist エントリ)に委ねると明記される。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]]) - **マルチプレーン設計は「T0-T1 リンク単体の喪失」への耐性を桁で向上させる**: 原論文は「T0-T1 リンク 1 本を失う影響は 800Gb/s プレーンでは容量の 3% 減だが 100Gb/s プレーンでは 0.4% 減にとどまる」と定量化しており(§2)、マルチプレーン化がプレーン単位の「小さく分割された喪失」に還元することで、[[データセンターネットワーク信頼性]] が求める「部品故障をサービス影響の小さい事象に変換する」という一般原則を、GPU クラスタネットワークの文脈で数値的に実証する一事例になっている。(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]]) - **「マルチプレーンネットワークの本質はNIC」という視点が、物理配線側の資料からも独立に確認された**: [[@2026__SpeakerDeck__マルチプレーンGPUネットワークを実現するシャッフルアーキテクチャの整理と考察]]は、800G NICを2x400G(Dual-Plane、shuffle不要)・4x200G(Quad-Plane)・8x100G(Octal-Plane)に分岐する選択肢を示し、マルチプレーンを期待通り動作させるにはトラフィックを複数planeに"spray"する機能・受信側での集約再整列・プレーン障害時の自動シフトというNICハードウェア/通信ライブラリ側の機能サポートが必須だと明記する(同資料ではこの実装詳細はスコープ外とされる)。これはLinkedIn記事(MRC/SRv6)が示すソフトウェア側(QP起動時のEVプレーン間スプレー)の設計と対になる、NICハードウェア側の要件を明示した知見である。(Source: [[@2026__SpeakerDeck__マルチプレーンGPUネットワークを実現するシャッフルアーキテクチャの整理と考察]]) - **プレーン分散後もhost側のFate Sharingは残るという限界が、シャッフル配線資料側から明示的に定式化された**: 同資料は「プレーン分散しても、同一800G optics/同一NICポート起点のFate Sharingは残る」「ファブリックプレーン側のFate Sharingは減るが、host port起点の共通故障点は消えない」と明記する。これは本concept既存の未解決の問い「NIC側光トランシーバの単一障害点は、プレーン数を増やす(4→8)ことでどこまで軽減されるか」に対し、「プレーン数を増やしてもNIC/optics自体が単一故障点である限り軽減されない」という理論的な上限を与える。(Source: [[@2026__SpeakerDeck__マルチプレーンGPUネットワークを実現するシャッフルアーキテクチャの整理と考察]]) - **マルチプレーン Clos + MRC/SRv6 と [[ZCube]] は、同じ「トポロジ誘発輻輳」問題への異なるレイヤーの解法である**: 本 concept が扱う [[MRC]]・[[SRv6]] は、Clos の階層構造(Spine-Leaf)を維持したまま、NIC を複数プレーンに分割しトランスポート層(QP単位のマルチパススプレー・ソースルーティング)でフロー衝突を回避する設計である。対して [[ZCube]] は Spine 層自体を撤廃し、Leaf スイッチを2グループの完全二部グラフへ再構成することでトポロジ層そのものからフロー衝突の発生確率を下げる。両者は「回避可能輻輳(topology-induced congestion)」という同じ問題意識から出発しながら、マルチプレーン Clos が**NIC 側の水平分割+トランスポート層のパス選択**で対処するのに対し、ZCube は**スイッチファブリック自体の再構成**で対処するという設計判断の違いを持つ。ZCube の原記事は adaptive routing・packet spraying・MRC を「回避可能輻輳への対処法」として明示的に位置づけた上で、「そもそも競合が起きないアーキテクチャ」への刷新をより根本的な解と主張しており、両アプローチが排他的ではなく異なるレイヤーで補完し得ることを示唆する。(Source: [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]], [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]]) ## 未解決の問い - マルチプレーン Clos + MRC/SRv6(トランスポート層でのフロー衝突回避)と ZCube(トポロジ層でのフロー衝突回避)を同一クラスタ規模・同一トラフィックパターンで比較したベンチマークはまだない。両者を組み合わせた場合(ZCube のスイッチファブリック上でマルチプレーン NIC 分割 + MRC を運用する)に追加の利得があるか、それとも冗長になるかは未検証。 - 800G NIC を 8×100G プレーンに分割する実装はハードウェア（NIC 設計）レベルか、ソフトウェア（ドライバ）レベルか。原論文は「NIC をレーン単位で分割する」と述べるのみで、実装レイヤーへの言及はない。[[@2026__SpeakerDeck__マルチプレーンGPUネットワークを実現するシャッフルアーキテクチャの整理と考察]]も「NICハードウェアと通信ライブラリ両方のサポートが必須」と述べるのみで、この境界線には踏み込んでいない。 - [[NCCLX]]（[[@2025__arXiv__Collective Communication for 100k+ GPUs]]）の DQPLB（動的キューペア負荷分散）は、マルチプレーントポロジと組み合わせることでどのような相乗効果があるか。 - **NIC 側光トランシーバの単一障害点(→ [[MRC]] の未解決の問い)は、プレーン数を増やす(4→8)ことでどこまで軽減されるか。** NIC トランシーバ自体がフラップすると全プレーンを同時に失うため、プレーン分割の粒度を増やしても NIC 単位の物理故障には効かない可能性がある——この境界がどこにあるかは原論文でも明示されていない。 - 単一プレーンに T0-T1 リンク喪失が集中し、そのプレーンがボトルネックになる理論的リスク(原論文 §4)は、プレーン数が少ない(4 プレーン)構成の方が高いか。本番で未観測とされるが、恒久的にリスクが低い理由(EV のプレーン内再配置による負荷分散の粘着性)は定量化されていない。 ## 関連 - 概念: [[MRC]] / [[SRv6]] / [[RDMA]] / [[LLM分散学習]] / [[Valiant Load Balancing]] / [[光ファイバーシャフル配線]] / [[データセンターネットワーク信頼性]] / [[ZCube]] - ソース: [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]] / [[@2009__SIGCOMM__VL2 - A Scalable and Flexible Data Center Network]] / [[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]] / [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]] / [[@2026__SpeakerDeck__マルチプレーンGPUネットワークを実現するシャッフルアーキテクチャの整理と考察]] / [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]] ## 出典 - [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]](同じトポロジ誘発輻輳問題への異なるレイヤーの解法として ZCube を対比) - [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]] - [[@2009__SIGCOMM__VL2 - A Scalable and Flexible Data Center Network]] - [[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]] - [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]](§2 Multi-plane Topology Co-Design・Table 1 の Cluster A/B 構成比較・Figure 1) - [[@2026__SpeakerDeck__マルチプレーンGPUネットワークを実現するシャッフルアーキテクチャの整理と考察]](p.8-9・p.31、NIC側要件とFate Sharingの定式化)