# ZCube ## 定義 ZCube は、Clos(Fat-Tree)の階層的スイッチ積層という設計思想から離脱し、Spine 層を撤廃して Leaf スイッチのみによる**完全フラット化 GPU サーバ相互接続**を実現するネットワークトポロジである。2025年9月の ACM SIGCOMM 2025([[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks|Yan et al. 2025]])で発表され、2026年に [[Zhipu AI|Z.ai]]・[[Harnets.AI]]・[[Tsinghua University]] の共同展開により GLM-5.1 コーディング推論サービスの本番クラスタへ初めて大規模導入された。(Source: [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]]) ## トポロジ構造 ZCube のコアアイデアは次の4点である。 1. Spine スイッチ層を撤廃する。 2. Leaf スイッチを同数の2グループ(典型的には奇数番・偶数番)に分割する。 3. 2つのスイッチグループ間を**完全二部グラフ**で相互接続する(すべての奇数番スイッチがすべての偶数番スイッチと接続)。 4. 各 GPU NIC の2ポートを、single-rail パターンと multi-rail パターンでそれぞれのグループの対応スイッチへ接続する。 ### 数式によるポート割り当て 各 GPU に2ポート NIC(p=2)が対応し、GPU・NIC は共通のインデックス 1,2,…,n を持つ。k を1台のスイッチに接続する GPU 数とすると、スイッチ総数は 2n/k(番号 1,2,…,2n/k)。GPU i(1≤i≤n)について: - 第1ポートは奇数番スイッチへ接続: `((i−1) mod (n/k)) × 2 + 1` - 第2ポートは偶数番スイッチへ接続: `⌈i/k⌉ × 2` p=2, n=32, k=8 の場合の具体構成が原論文・本記事で図示されている(Leaf01〜08、各 Leaf に8 GPU が single-rail/multi-rail 混在で接続)。(Source: [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]]) ## 主要な性質 - **ネットワーク直径**: スイッチ2ホップ。1層ネットワーク(1ホップだが低スケール)と従来の2層ネットワーク(3ホップだが高スケール・高遅延)の中間に位置する設計点。 - **負荷分散**: (1) ZCube 専用ルーティング戦略により GPU ペアごとに一意な最適パスが存在し、マルチパス選択に起因するトラフィック競合を回避する。(2) single-rail(連続 GPU ID 範囲を1スイッチに集約)と multi-rail(グループ間で相対インデックスが同じ GPU を集約)という相補的な2接続パターンにより、AllReduce・All-to-All のような訓練トラフィックと、送信元・宛先が不確実で NIC 負荷が偏りやすい推論トラフィックの両方でほぼ理想的な負荷分散を達成する。 - **スケーラビリティ**: 128×400Gbps ポートを持つ 51.2T スイッチ1層構成で 16,384 台の 400Gbps NIC を接続可能。より高容量のスイッチやプレーン分割の併用でさらに数万〜数十万 GPU 規模へ拡張できる。 - **コスト**: 同一クラスタ規模で従来の Clos/ROFT 比、スイッチ・光モジュールコストを約1/3削減できる。10,000-GPU クラスタでは約2.1億〜6.4億人民元のネットワークハードウェア投資削減が見込まれる。 ## 実運用検証結果(GLM-5.1本番クラスタ) 千 GPU 規模の GLM-5.1 コーディング推論クラスタを ROFT から ZCube へ移行した実測(本番稼働2週間超時点): - GPU 推論スループット: 平均 **15%超向上** - TTFT P99 テイルレイテンシ: **40.6%削減** - スイッチ・光モジュール CapEx: **33%削減**(GPU・ソフトウェアスタック・アプリケーションは無変更) 移行には Spine 層撤廃に伴う配線・IP アドレッシング・ルーティング・スイッチ設定の全面再設計が必要で、[[Harnets.AI]] が ZCube Controller・データセンターレイアウト設計ツール・配線正当性検証プログラムを新規開発してこれを解決した。(Source: [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]]) ## 横断的知見 - **ZCube と Rail-only トポロジは共に Spine 層撤廃で収束するが、撤廃後の設計思想が異なる**: [[Fat-Tree]] concept が扱う [[@2023__arXiv__Rail-only - A Low-Cost High-Performance Network for Training LLMs with Trillion Parameters|Rail-only]] は、LLM 訓練のスパースな通信パターンに着目してスイッチ段数そのものを削減しコスト38-77%減を狙う設計である一方、ZCube は Spine を撤廃した上で Leaf 層を2グループの完全二部グラフに再構成し、single-rail/multi-rail のハイブリッド接続で負荷分散を積極的に作り込む。両者とも「全二分帯域の大半が LLM ワークロードでは未使用」という同根の観察から出発しながら、Rail-only が段数削減による**コスト最適化**を主目的とするのに対し、ZCube は PD 分離推論のトラフィック非対称性という**負荷分散問題への対処**を主目的としており、狙う効用が異なる。(Source: [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]], [[@2023__arXiv__Rail-only - A Low-Cost High-Performance Network for Training LLMs with Trillion Parameters]]) - **「トポロジ誘発輻輳」への対処として、ZCube(トポロジ層)と MRC/SRv6(トランスポート層)は競合ではなく異なるレイヤーの解法である**: [[マルチプレーンClosトポロジ]] が扱う [[MRC]]・[[SRv6]] は Clos トポロジを維持したまま、QP 単位のマルチパス spray とソースルーティングでフロー衝突を緩和するトランスポート層の解法である。対して ZCube は本記事内で adaptive routing・packet spraying・MRC を「回避可能輻輳への対処法」として明示的に言及した上で、「そもそも競合が起きないアーキテクチャ」への刷新をより根本的な解として位置づける。両者は排他的ではなく、マルチプレーン Clos + MRC がトポロジを固定してトランスポートで衝突を回避するのに対し、ZCube はトポロジ自体を変えて衝突の発生確率を構造的に下げる、という異なるレイヤーでの補完関係にある。(Source: [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]], [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - **PD分離のKV Cache転送非対称性が、ROFTのレール割り当て前提を破壊するという因果関係が実測で裏付けられた**: [[Prefill-Decode分離]] concept が扱う KV Cache 転送はソース側で議論されるが、ZCube の本記事はこの非対称性が具体的にネットワークトポロジ設計(ROFT のレールマッピング)をどう破綻させるかを、Grafana 実測(NIC 間スループット最大27.93 GB/sから0 B/s近辺までの偏り、PFC Pause Packets の周期的バースト)で定量的に示した初のソースである。PD分離の議論が従来「KV Cacheをどう速く転送するか」というトランスポート/ストレージ層に閉じていたのに対し、本記事は「PD分離のトラフィックパターンがネットワークトポロジ設計とミスマッチを起こす」というネットワークアーキテクチャ層の問題として再定式化した。(Source: [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]]) ## 未解決の問い - ZCube のスケーラビリティ上限(16,384 400Gbps NIC を1層51.2Tスイッチで接続)を超えて数十万 GPU 規模へ拡張する際、「プレーン分割の併用」と明記されるのみで、[[マルチプレーンClosトポロジ]] のような NIC 分割方式とどう組み合わさるのか、具体的な階層構成は原記事に説明がない。 - single-rail/multi-rail のハイブリッド接続パターンは AllReduce・All-to-All のような訓練トラフィックにも「ほぼ理想的な負荷分散」を提供すると主張されるが、訓練クラスタでの実運用ベンチマークは本記事に含まれておらず、推論クラスタでの実測のみが報告されている。訓練ワークロードでの定量評価はまだない。 - Spine 撤廃後の配線・設定自動化ツール(ZCube Controller 等)は [[Harnets.AI]] による専用開発とされるが、これらのツールが一般化・OSS 化される予定があるかは不明。既存の Clos 前提の運用ツールチェーン(IP アドレッシング・ルーティングポリシー生成)からの移行コストは、クラスタ規模に対してどうスケールするか。 - ZCube のルーティング戦略が「GPU ペアごとに一意な最適パス」を保証するとされるが、リンク障害時のフェイルオーバーパスがどう選択されるか、[[マルチプレーンClosトポロジ]] が議論する MRC の EV 再配置のような障害耐性メカニズムとの比較は原記事にない。 ## 関連 - 概念: [[Fat-Tree]] / [[マルチプレーンClosトポロジ]] / [[Prefill-Decode分離]] / [[MRC]] / [[SRv6]] - エンティティ: [[Zhipu AI]] / [[Harnets.AI]] / [[Tsinghua University]] - ソース: [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]] ## 出典 - [[@2026__X__Next-generation LLM Inference Network - How ZCube Alleviates Network Bottlenecks]](原論文: Yan, Z. et al. From ATOP to ZCube. ACM SIGCOMM 2025, pp. 861-881)