## 概要
[[サイバーエージェント]] の [[CIU]](CyberAgent group Infrastructure Unit)が運用するプライベートクラウド Cycloud の機械学習基盤 ML Platform Distributed において、GPU 需要増に伴う 800GbE スイッチ(Juniper [[Juniper QFX5240]])の導入事例を報告する。400G/800G 混在構成でのネットワーク設計・物理配線・負荷分散チューニング・モニタリング整備の全工程を網羅し、TOP500 ランクインという成果も示す。発表者は [[小障子 尚太朗]] と [[疋田 紅樹]] の 2 名。
## 主要メッセージ
- **400G 増設より 800G スイッチ再構築が有利**(p.8): 400G スイッチ 12 台増設では SU をまたぐ GPU 間通信が増えて品質保証が難しくなる一方、800G 64 ポートスイッチは SU あたりの GPU 収容数増加・ラックスペース削減が可能で、Leaf 4 台 + Spine 3 台とシンプルな構成になる。
- **NCCL_CROSS_NIC=0 で Spine を迂回**(p.14-15): 奇数ノードの AllReduce では NCCL がデフォルトで Spine 越えのリングを形成する。同 NIC を同じリングで使うよう `NCCL_CROSS_NIC=0` を設定するとリングが Leaf 内に閉じ、性能劣化なしに Spine 通過トラフィックをほぼゼロにできる。
- **異種 GPU サーバー混在時の配線ズレが性能障害の原因**(p.20-21): NVIDIA DGX H100 と DELL XE9680 を混在させると物理ポート番号体系が異なるため Rail-Optimized Topology での GPU-NIC-Leaf の対応がずれ、Spine 経由のリングが形成されて性能劣化する。接続変更で解消。
- **Ingress interface hashing + DLB の組み合わせが最善**(p.34-35): Broadcom ASIC の DLB 単体では CNP(Congestion Notification Packet)・Reorder が残る。Spine(SN4700)で Ingress interface hashing を有効にしてトラフィックをポート単位で分散させることで CNP 発生率が大幅低下し、チューニング後はデフォルト比ほぼ 2 倍の帯域を達成。
- **SN-MT コネクタで物理密度 4 倍**(p.28-29): MPO-12 32 ポートパッチパネルでは 56 台の GPU サーバーに 448 本の MPO ケーブルが必要で 14U 以上を専有するが、SN-MT(VSFF)コネクタの 1U 72 ポートパッチパネルへ移行して収容密度を 4 倍・ラック間ケーブルを 1/2 に削減。
## 視覚的に重要な図表
**p.18 GPU 増設後のネットワーク構成**
![[_attachments/janog56-800gbe-cycloud/page-018.png]]
Rail-Optimized Topology。Leaf は Juniper QFX5240-64OD ×4、Spine は NVIDIA SN4700 ×4。ダウンリンク:アップリンク = 7:1 のオーバーサブスクリプション。1 SU で H100/H200 を 56 台まで収容可能。インターコネクト(Lossless)は 400GbE ×8/サーバー、インターネット・ストレージ(Lossy)は 100GbE ×2(LAG)。
**p.22 TOP500 ランクイン**
![[_attachments/janog56-800gbe-cycloud/page-022.png]]
2025 年 6 月発表の TOP500 で世界 132 位(国内 15 位)に登録。登録名は "Cycloud ML Platform"。実際のシステム: DELL PowerEdge XE9680 / NVIDIA DGX H100、GPU: NVIDIA H100 / H200、インターコネクト: Juniper QFX5240-64OD / NVIDIA SN4700。Rmax = 10.82 PFlop/s、Rpeak = 16.97 PFlop/s、37,376 コア(図 22)。
**p.24 800G スイッチの活用**
![[_attachments/janog56-800gbe-cycloud/page-024.png]]
2U 800G 64 ポートスイッチを 2U 400G 128 ポートとして活用。OSFP 800G-DR8(2×400G-DR4) トランシーバ 1 本で 400G ×2 ポートを提供する写真(黄色の OSFP モジュール)。
**p.30 構築後のラック写真**
![[_attachments/janog56-800gbe-cycloud/page-030.png]]
左:インターコネクトラック全体。中上:SN-MT パッチパネル(高密度で黄色ケーブルが密集)。中下:800G スイッチ(Juniper QFX5240)の背面接続。右:GPU サーバー(DELL XE9680)側面。
**p.35 Ingress interface hashing + DLB の効果**
![[_attachments/janog56-800gbe-cycloud/page-035.png]]
棒グラフで Reorder[p/s] と CNP[p/s] の 4 条件比較。Ingress interface Hashing 有効 + DLB on が最も低い。右の Spine トラフィックグラフでは Ingress hashing 有効時にトラフィックの分散が確認できる。
**p.38 パフォーマンスチューニングの最終結果**
![[_attachments/janog56-800gbe-cycloud/page-038.png]]
nccl-tests のスループット[GB/s] vs データサイズ[B]。チューニング後(赤)がデフォルト(青)のほぼ 2 倍の性能。大きいサイズ領域で差が顕著。
## 発表前史
2023 年 7 月から 400GbE ×8 の Rail-Optimized Full Bisection Bandwidth 構成でインターコネクトを稼働。JANOG52 でも 400GbE 構成の事例を発表している([参照](https://www.janog.gr.jp/meeting/janog52/aiml400/))。GPU 需要増により 2024 年 12 月頃から増設計画を開始、JANOG56(2025 年 7 月)で 800G 化事例を報告。
## ハードウェア構成まとめ
| 役割 | 機器 | ポート・規格 |
|---|---|---|
| インターコネクト Leaf | Juniper QFX5240-64OD × 4 | 800G 64 ポート(400G 128 ポートとして使用) |
| インターコネクト Spine | NVIDIA SN4700 × 4 | 400G 32 ポート |
| GPU サーバー NIC | NVIDIA ConnectX-7 × 8 | 400GbE(サーバー 1 台あたり) |
| トランシーバ | OSFP 800G-DR8(2×400G-DR4) | 2 MPO(将来は 1 MPO 製品を検討) |
| パッチパネル | SN-MT 1U 72 ポート | VSFF コネクタ(MPO-12 ×2 ブレイクアウト) |
| インターネット/ストレージ | NVIDIA SN4700(MLAG) | 100GbE |
## インターコネクト監視とマイクロバースト検出
インターコネクトの稼働状況を可視化し将来の投資判断に活用するため、高頻度テレメトリ収集を整備した。
**p.39 マイクロバースト可視化の必要性**
![[_attachments/janog56-800gbe-cycloud/page-039.png]]
100 ms 間隔では 400 Gb のピークトラフィックが確認できるが、500 ms 間隔では 80 Gb、1 秒間隔では 40 Gb にしか見えない。マイクロバーストを捕捉するには通常の 500 ms〜1 秒間隔では不十分で、より細粒度の収集が必要になる。
**p.40 スイッチ別のマイクロバースト収集手段**
![[_attachments/janog56-800gbe-cycloud/page-040.png]]
NOS が異なるため収集手段が分岐する。Leaf(QFX5240 / JunOS)は gNMIc で最短 2 秒を達成できるが高データレート時の更新停止を gNMIc 多重化で回避。Spine(SN4700 / Cumulus Linux)は gNMI が約 15 秒間隔が限界だったが Cumulus Linux 5.11+ の OpenTelemetry で約 2 秒・TSDB 直接書き込みが可能に。
### スイッチ別の収集方法
| スイッチ | NOS | 収集方法 | 達成した間隔 | 課題 |
|---|---|---|---|---|
| Leaf QFX5240 | JunOS | gNMI(gNMIc) | 最短 2 秒 | データレートが高いと更新が停止する事象あり → gNMIc プロセスをデータ種別ごとに多重化して対応 |
| Spine SN4700 | Cumulus Linux | gNMI → OpenTelemetry | 約 15 秒(gNMI) → 約 2 秒(OTel) | Cumulus Linux 5.11 以降で OpenTelemetry をサポート。スイッチから直接 TSDB への書き込みが可能に |
### 残る課題
- **レート計算の不安定性**: 取得間隔の微妙なズレによってレート計算が不安定になるリスク。
- **監視基盤の再設計**: 現行構成では高頻度データ収集に限界があり、監視基盤全体の見直しが必要と認識されている(今後の課題)。
## 主な知見と未解決点
### 解決した課題
- NCCL_CROSS_NIC=0 でリング経路を Leaf 内に限定(Spine 不要化の実質的実現)
- 異種サーバー混在時の配線対応(GPU/NIC 番号体系の違いを手動配線で吸収)
- Ingress interface hashing + DLB 組み合わせでマルチベンダー Lossless を実現
- SN-MT コネクタで高密度パッチパネルを実現
### 残課題・今後の検討
- DLB の inactivity-interval は安定最適値が存在しないため手動・経験的チューニング(将来の自動最適化機能に期待)
- gNMI 取得間隔のズレによるレート計算不安定リスク
- Spine 監視: SN4700 の gNMI は約 15 秒間隔が限界(Cumulus Linux 5.11+ の OpenTelemetry で約 2 秒へ改善)
- 今後: 1.6T スイッチ・CPO スイッチ・水冷/液浸・LPO トランシーバー・新世代 GPU 対応
## 概念・実体への接続
- [[Rail-Optimizedトポロジ]] — 本資料の中心構成。GPU 番号と Leaf の対応が厳密に必要。
- [[マルチベンダーLosslessネットワーク]] — SN4700(Mellanox)+QFX5240(Broadcom)混在のチューニング事例。
- [[データセンター輻輳制御]] — DLB と DCQCN(PFC/ECN)のマルチベンダー適用。
- [[集合通信]] — NCCL_CROSS_NIC 設定によるトポロジ制御。
- [[GPUクラスタ運用]] — 本番で発生した異種サーバー混在の配線ズレ問題。
- [[サイバーエージェント]] / [[CIU]] / [[小障子 尚太朗]] / [[疋田 紅樹]] / [[Juniper QFX5240]]
## 限界・不確実点
- transcript なし(発表動画未取得)。質疑の内容は不明。
- TOP500 登録スペック: 登録名義は "NVIDIA H100, 400g Ethernet" だが実際は H100/H200 混在・QFX5240/SN4700 混在(スライド p.22 の注記より)。
- nccl-tests のパフォーマンス測定数値は "各パターン 1 回のみの実行"(p.17)。統計的信頼性は限定的。
- inactivity-interval の最適値は未確定(p.37)。