# AI/ML基盤の400G DCネットワークを構築した話 ## 概要 サイバーエージェントの [[CIU]] が運用するプライベートクラウド [[Cycloud]] の ML Platform において、GPU 間の分散学習を支える 400GbE インターコネクトを構築した事例である。 発表は JANOG52 Day3 の 2023年7月7日に行われ、前半を [[内田泰広]]、後半を [[小障子 尚太朗]] が担当した。 ML Platform は Kubernetes の Pod として GPU を提供し、AI/ML ジョブの学習環境、モデルのデプロイ環境、マネージド Jupyter Notebook を提供する。 オンプレミスを選んだ理由として、クラウドより速い開発速度、既存サービスとの接続、長期利用時のコストが挙げられている。 ## 主要メッセージ - LLM の拡大により単一 GPU サーバーのメモリでは処理しにくくなり、モデル並列が必要になった。 - 学習時間を短縮するため、データ並列の並列数を増やせる複数 GPU サーバーの分散学習環境が必要になった。 - CPU 中心の Kubernetes などの通信は Lossy Ethernet、同一サーバー内の GPU 間は NVLink、サーバーを跨ぐ GPU 間は RDMA インターコネクトに分離した(p.7)。 - Interconnect はマルチテナント運用と既存 Ethernet 運用への親和性を理由に RoCEv2 を選択し、帯域は 400GbE とした(p.8)。 - RoCEv2 の Go-back-N 再送では、1 パケットの損失から後続パケットを含む再送が発生するため、パケット損失が性能に大きく影響する(p.9)。 - Lossless Ethernet は PFC、ECN/CNP、ETS を組み合わせて、リンクレベルの一時停止、エンドツーエンドの輻輳通知、キュー優先度を制御する(p.10)。 ## 視覚的に重要な図表 **p.4 Cycloud のサービス構成** ![[_attachments/janog52-aiml400-uchida-koshoji/page-004.png]] AS24284 のバックボーンネットワーク配下に IaaS、AKE、ML Platform があり、今回の対象は物理サーバー・VM・ストレージ・GPUを収容する ML Platform のデータセンターネットワークである。 **p.7 分散処理に用いる3種類のネットワーク** ![[_attachments/janog52-aiml400-uchida-koshoji/page-007.png]] CPU中心の通信には Lossy Ethernet、同一サーバー内の GPU 間には NVLink、サーバー間の GPU 通信には IB または Lossless Ethernet 上の RDMA を割り当てる。 **p.9 Go-back-N 再送** ![[_attachments/janog52-aiml400-uchida-koshoji/page-009.png]] SEQ:004 が DROP されたとき、受信側の NAK:003 に対して SEQ:003 以降をまとめて再送する構造を示している。 **p.11 400GbEインターコネクト構成** ![[_attachments/janog52-aiml400-uchida-koshoji/page-011.png]] Spine と Leaf をフルバイセクションで接続し、GPU サーバーと Leaf の対応を Rail Optimized に固定する構成である。LAG は使わず、Adaptive Routing を採用する。 **p.12 静的ハッシュによる Elephant flow / Mice flow 問題** ![[_attachments/janog52-aiml400-uchida-koshoji/page-012.png]] 同一 5-tuple のパケットを同じ経路へ送る static hashing では、Elephant flow が一部経路を占有し、Mice flow が影響を受ける。バッファを考慮しないハッシュによる偏りが問題になる。 **p.13 Adaptive Routing** ![[_attachments/janog52-aiml400-uchida-koshoji/page-013.png]] パケットを flowlet として認識し、バッファ状況に応じて動的にハッシュすることで Spine–Leaf 間の分散を改善し、flowlet 単位の処理で out-of-order を抑制する。 **p.14 Adaptive Routing の検証** ![[_attachments/janog52-aiml400-uchida-koshoji/page-014.png]] AR を有効にしたスイッチでは、Spine 向け TX 側トラフィックが複数ポートへ均等に分散している。図中の端末出力を比較する検証である。 **p.15 ラック写真** ![[_attachments/janog52-aiml400-uchida-koshoji/page-015.png]] Lossy 側と Interconnect Lossless 側のラックを色分けして示し、ネットワーク要件の異なる通信を物理的にも分離している。 **p.19 End of Row とネットワーク分離** ![[_attachments/janog52-aiml400-uchida-koshoji/page-019.png]] 1ラックあたり最大 GPU サーバー3台という前提から End of Row を採用し、インターネット・ストレージの Lossy ネットワークと、400GbE x8 の Lossless インターコネクトを分離する。 **p.21 OSFP-RHS** ![[_attachments/janog52-aiml400-uchida-koshoji/page-021.png]] ConnectX-7 の接続方式として OSFP-RHS 800G(400G x2) と OSFP-RHS 400G x1 を比較し、通常のトランシーバーが装着できない問題から OSFP-RHS の存在を確認した。 **p.22 スイッチ用トランシーバー** ![[_attachments/janog52-aiml400-uchida-koshoji/page-022.png]] GPU サーバー側 OSFP-RHS とスイッチ側 QSFP-DD の 400G-DR4、MPO-12/SMF、Spine–Leaf 間の AOC を選定した。純正品と 3rd party 製品ではリンクアップ時間と再接続挙動に差があった。 **p.23 インターコネクト動作検証** ![[_attachments/janog52-aiml400-uchida-koshoji/page-023.png]] RoCEv2 の L3 ルーティング、400Gbps のエンドツーエンド帯域、BGP による迂回、ETS のキュー優先度、Adaptive Routing の分散、ECN/CNP の動作を検証項目にした。 **p.25 構築後の評価** ![[_attachments/janog52-aiml400-uchida-koshoji/page-025.png]] Ethernet は既存の運用方法や BGP による迂回を活用できる一方、RoCEv2 には InfiniBand の知識と大変な QoS チューニングが必要である。Lossy/Lossless の分離は QoS 設計を単純化するが、構築・運用コストを増やす。 **p.28 まとめ** ![[_attachments/janog52-aiml400-uchida-koshoji/page-028.png]] 400G Lossless ネットワークでは、複数の DR4 規格と OSFP・OSFP-RHS・QSFP-DD の相互接続性を調査・検証する必要がある。ネットワーク側だけでなく、SR-IOV、CNI、AI/ML ワークロードの知識も必要になる。 **p.31–33 PFC・ECN・ETS** ![[_attachments/janog52-aiml400-uchida-koshoji/page-031.png]] ![[_attachments/janog52-aiml400-uchida-koshoji/page-032.png]] ![[_attachments/janog52-aiml400-uchida-koshoji/page-033.png]] PFC は CoS/DSCP によるキュー分類と Xoff/Xon、ECN は CE マーキングと CNP、ETS は優先度グループごとの DWRR で構成される。例では RoCE の DWRR を70%、CNP を High Priority としている。 **p.34 リアドア空調ラック** ![[_attachments/janog52-aiml400-uchida-koshoji/page-034.png]] 高負荷サーバーを高密度に設置するためリアドアに冷却機器を搭載し、QSFP-DD/OSFP トランシーバーに合わせてフロントドアも拡張した。作業時は約100dBの騒音に対応するためイヤーマフが必要になる。 ## 構成と導入過程 - Fat-Tree とフルバイセクションを採用し、BGP Unnumbered、メンテナンス時の G-shut community による迂回、L2 を1台の Leaf 内に閉じる設計とした(p.20)。 - LAG を使わず、Adaptive Routing で Elephant flow による経路偏りを抑えた(p.20)。 - NVIDIA DGX H100/HGX H100 を国内初導入し、従来の A100 から分散学習向けに更新した。データセンターは1ラック35kVA以上、消費電力12.5kVA、リアドア空調、最大200ラックを要件とした(p.18)。 - GPU サーバーは ConnectX-7 で接続し、OSFP-RHS 400G x1 または 800G(400G x2)を選定した(p.21)。 - GPU サーバー–スイッチ間は 400G-DR4、サーバー側 OSFP-RHS、スイッチ側 QSFP-DD、ファイバーは MPO-12/SMF とした。Spine–Leaf 間は距離が近いため AOC とした(p.22)。 ## 検証と運用上の知見 - 検証では、RoCEv2 の L3 ルーティング、400Gbps の E2E 帯域、BGP 迂回、ETS のキュー優先度を確認した。 - Adaptive Routing では Spine–Leaf 間の flow 分散と、AR の ON/OFF によるパケット内容の変化を確認した。 - ECN/CNP では 200GbE の Congestion Point を作り、輻輳制御と CNP パケットを検証した。 - 400G トランシーバーは、純正品でリンクアップ20〜50秒、3rd party 製品で90秒を要した。`shutdown -> no shutdown` 後にリンクアップしない症状も記録された(p.22)。 - スイッチと NIC から光レベル、シリアル番号、温度を取得できるかを運用要件として確認した(p.22)。 - 構築後の次の課題として、800GbE、GPU サーバー増設、水冷・液浸、Dragonfly トポロジ、3rd party トランシーバー、GPUDirect Storage、マイクロバースト検知(Telemetry)を挙げている(p.26)。 ## 概念・実体への接続 - [[RDMA]] — サーバーを跨ぐ GPU メモリへの直接アクセス。 - [[RoCE設計課題]] — Go-back-N、Lossless 前提、PFC/ECN の運用課題。 - [[データセンター輻輳制御]] — DCQCN、PFC、ECN/CNP、ETS の構成。 - [[Rail-Optimizedトポロジ]] — GPU サーバーと Leaf の対応を固定する設計。 - [[マイクロバースト]] — 今後の検知課題として挙げられた高頻度トラフィック観測。 - [[Dragonflyトポロジ]] — Clos の次の検討候補として挙げられたトポロジ。 - [[マルチベンダーLosslessネットワーク]] — 本資料は単一ベンダー構成だが、後続の800GbE導入事例と連続する。 - [[サイバーエージェント]] / [[CIU]] / [[内田泰広]] / [[小障子 尚太朗]] / [[Cycloud]] ## 限界・不確実点 - transcript は取得していないため、口頭説明と質疑応答は反映していない。 - Adaptive Routing の検証画面は画像内の端末出力を定性的に比較する形式であり、具体的なフロー数・測定条件・統計的なばらつきは示されていない。 - 「国内初導入」や DR4 規格の相互接続性は発表時点の資料記述であり、現在の市場全体を評価する主張ではない。 - p.22 の純正品・3rd party 製品のリンクアップ時間は資料記載の測定例であり、製品一般の性能保証ではない。