CyberAgentの分散学習基盤を支える 400GbE RoCEv2 Lossless networkの運用 第40回情報ネットワーク・ネットワークシステム研究ワークショップ 株式会社サイバーエージェント(CyberAgent, Inc.) 内田 泰広 (Yasuhiro Uchida) 2024/02/29

内田 泰広 (Yasuhiro Uchida) •2020 株式会社サイバーエージェント入社 CIU(CyberAgent group Infrastructure Unit) CA全体に対してインフラの技術的な支援を行う組織 Private Cloud: Cycloud Platform Div NWリーダー •業務内容 - AS運用・peering・拠点間接続 - データセンターのネットワーク設計・構築・運用 - 高負荷DCのGPU向け400G NW構築 - ネットワーク監視・運用自動化 - プロジェクト管理 2

Cycloud (AS24284) • 自社でコンピュートリソースを持ち、設計・構築・運用までを実施 • プライベートクラウドとしてIaaS、 KaaS、 ML Platformを提供 • 今回はML Platformについてのお話 物理サーバー / VM バックボーンネットワーク AS24284 Load Balancer NAT / Firewall ストレージ SSL-VPN GPU データセンターネットワーク 3 IaaS (OpenStack) GPUaaS KaaS /AKEv2 (Kubernetes)

業務での生成AIの活用の増加 • サイバーエージェントでは生成AIを業務で活用していく流れが加速している • 機械学習エンジニア、データサイエンティストは生成AIを応用した研究 • 生成AIなどを活用していくためには豊富な計算機リソース(GPU)が不可欠 • 自社でML Platformを独自に開発する 4

ML Platform

ML Platform 6 ◼ Private CloudとしてGPU基盤を社内に提供 ◼ GPUaaS: Kubernetesベースの基盤でGPUインスタンスを提供 ◼ AI Platform Training:学習基盤 ◼ AI Platform Prediction: 推論基盤 Inferenceなどとも呼ばれる GUI上で操作可能なマネージドなJupyter Notebookも提供

ML Platform 7 • ML Platformで提供しているDashboard

ML Platformを自社で提供する理由 8 • パブリッククラウドより早いスピード感でデプロイする事が可能 • 社内向けに最適化されたGPU資源を用意することで安価に提供 • Jupyter Notebookなど長期利用を想定した場合のコスト • 社内の既存リソースとの接続性 • カスタマイズできる項目が多い • 機器・技術選定、細かいチューニングや切り分けまで可能

ML Platform Distributedで抱えていた課題 • 直面していた課題 今までは1台のサーバーを利用して機械学習を行うことが前提 1. LLMの拡大により1台のGPUサーバーのMemoryで処理が困難 2. 学習時間を短くしたい (データパラレル/モデルパラレルなどで並列数を増やしたい) 9 複数台のGPUサーバーのメモリを使って分散学習できる環境(Distributed) ML Platformをデータセンターからゼロベースで考える必要 大規模言語モデルとは、様々な自然言語で書かれたテキストをデータセットとして、機械的に学習したモデルです。 主に人工知能分野で利用される手法です。 • 日本語大規模言語モデル(LLM)を業務活用・研究 CALM2 OpenCALMで推論した結果

CPU GPUサーバーで分散学習するネットワーク 10 ①Internet (Lossy) GPU IB or Ethernet(Lossless) ③Interconnect (RDMA) ②NVLink それぞれ要件が違ったネットワークが求められる ① CPUセントリックなインターネットなどの通信: Lossy ② サーバー内のGPU間通信はPCIeよりも広帯域なNVLink4で通信 ③ サーバーを跨ぐGPU間通信は①と独立したロスレス低遅延: Lossless ④ ストレージネットワーク(NFS / GPDS:GPU Direct Storage) ⑤ BMC/IPMIなどの管理用ネットワーク NIC GPU CPU Mem NIC NVMe NIC NIC Interconnect SW CPU GPU NIC GPU CPU Mem NIC NVMe NIC NIC PCI switch Storage SW Internet SW Management PCI switch ④NFS / GDS NVSwitch NVSwitch

CPU GPUサーバーで分散学習するネットワーク 11 ①Internet (Lossy) GPU IB or Ethernet(Lossless) ③Interconnect (RDMA) ②NVLink ① CPUセントリックなインターネットなどの通信: Lossy ■ Hugging FaceやGCS/S3からモデルやデータセットをダウンロード ■ Kubernetes Pod間通信 ② サーバー内のGPU間通信はPCIeよりも広帯域なNVLink4で通信 ■ NVLink4の片方向の総帯域は450GBytes/sec (25Gx18) ■ GPU内部サーバー内のNVSwitch3でSHARPが利用可能 NIC GPU CPU Mem NIC NVMe NIC NIC Interconnect SW CPU GPU NIC GPU CPU Mem NIC NVMe NIC NIC PCI switch Storage SW Internet SW Management PCI switch ④NFS / GDS NVSwitch NVSwitch

CPU GPUサーバーで分散学習するネットワーク 12 ①Internet (Lossy) GPU IB or Ethernet(Lossless) ③Interconnect (RDMA) ②NVLink ③ サーバーを跨ぐGPU間通信は①と独立したロスレス低遅延: Lossless ■ GPU Direct RDMA: CPUを介さずリモートホストGPUメモリにRDMA -> ACSは無効にしてRoot Complexを経由させない ④ ストレージネットワーク(NFS / GPDS:GPU Direct Storage) ■ コンテナにアタッチされたファイルストレージ(Volume)との通信 ■ 学習用データセットの読み込みやチェックポイントの書き出し ⑤ BMC/IPMIなどの管理用ネットワーク NIC GPU CPU Mem NIC NVMe NIC NIC Interconnect SW CPU GPU NIC GPU CPU Mem NIC NVMe NIC NIC PCI switch Storage SW Internet SW Management PCI switch ④NFS / GDS NVSwitch NVSwitch

CPU GPUサーバーで分散学習するネットワーク 13 ①Internet (Lossy) GPU IB or Ethernet(Lossless) ③Interconnect (RDMA) ②NVLink それぞれ要件が違ったネットワークが求められる ① CPUセントリックなインターネットなどの通信: Lossy ② サーバー内のGPU間通信はPCIeよりも広帯域なNVLink4で通信 ③ サーバーを跨ぐGPU間通信は①と独立したロスレス低遅延: Lossless ④ ストレージネットワーク(NFS / GPDS:GPU Direct Storage) ⑤ BMC/IPMIなどの管理用ネットワーク NIC GPU CPU Mem NIC NVMe NIC NIC Interconnect SW CPU GPU NIC GPU CPU Mem NIC NVMe NIC NIC PCI switch Storage SW Internet SW Management PCI switch ④NFS / GDS NVSwitch NVSwitch

• サーバー間のRDMA専用NW(Interconnect)はInfiniband vs RoCEv2の選択肢 ◼ Infinibandの知見が無くEthernetには安心感を感じた ◼ RoCEv2(Routable RoCE)を採用: マルチテナントに変更することが可能 14 RoCEv2 Infiniband GPU Interconnect Networkの技術選定 VS

GPU Interconnect Networkの技術選定 ◼ Interconnectの帯域はNIC 400GbEx8枚を採用 ◼ 帯域がどの程度出るのか分からない ◼ NVLinkは片方で450GB/sec、パフォーマンスがNICに律速する可能性 ◼ 最速でサービスリリースしたい為POCを行う時間が無かった ◼ 帯域のボトルネックを減らし輻輳制御に極力頼らない構成 ◼ GPUに対するNWコスト比は低い ◼ 100/200/400GのどのNICでリリースされるか不明のため全てを調べる ◼ 全ての後方互換を確認: 金額/ケーブル/トランシーバ/スイッチ/規格の調査(マイグレ案) ◼ RoCEv2には新しいデータセンターネットワークの要件が必要 ◼ Lossless Ethernet ◼ RDMAはLossが無いNWを前提としたプロトコルでLossがパフォーマンスに大きく影響 15

なぜLossがRDMAの性能に影響を与えるのか 16 Server Server SEQ:001 SEQ:002 SEQ:003 SEQ:004 SEQ:005 DROP NAK:003 SEQ:003 SEQ:004 • RDMAではgo-back-N方式が多く採用されている ◼ 最近はSelective Repeatも実装されてきているが一部機能で未サポート • Go-back-NはDROPしたSEQから遡って再送を実施し無駄が多い • RDMAにはLossがないNWが求められる Retransmit

Lossless Ethernetとは • 輻輳制御とQoSを使った信頼性の高いネットワーク : 輻輳制御ではDCQCNを利用 • [IEEE DCB] PFC + ECN (CNP) + ETSを利用したロスが少ない信頼性の高いイーサネット • PFC (Priority Flow Control) ◼ PAUSEフレームを使ったリンクレベルでの輻輳を抑制 ◼ トラフィックはCoSまたはDSCPで分類されキュー毎にPAUSEフレームで制御 • ECN (Explicit Congestion Notification) ◼ エンドノード間の輻輳制御 ◼ IPヘッダのToSを利用し輻輳時に中継SWがパケットにマーキングを行い受信ノードに輻輳を通知 ◼ 受信ノードは送信元ノードにCNP(Congestion Notification Packet)パケットを送信し輻輳を通知 ◼ CNP受信後は送信ノードはトラフィック流量の制限 • ETS (Enhanced Transmission Selection) ◼ プライオリティグループ毎にキューの優先順位を定義 ◼ RDMAとCNPのパケットだけを優先的に送信できるように設定 17

データセンター構築 DC選定 事前検証 設計 機器選定 構築 運用 - 冷却 - 電力 - 回線 - RoCEv2 検証 - 400G 検証 - 納期 - 価格交渉 - 保守 - 商流 - キッティング - ラッキング - コンフィグ - 接続検証 - ケーブリング - 既存DC引越し - 自動化 - 障害対応 - 機能拡張 - ユーザー対応 企画 - 要望ヒアリング - 企画立案 - 情報収集 2022/5〜2022/8 動作検証 - 機能検証 - 性能検証 2022/8〜2022/10 Internet: 2023/1〜2023/2 Interconnect: 2023/4〜2023/5 2023/5〜2023/6 2023/6〜 18 企画からリリースまでを約1年 (ほとんどが納期待ち) Distributedをサービスリリースしてから半年以上が経過

新GPUサーバー選定 • NVIDIA DGX H100/HGX H100を国内初導入 ◼ GPUサーバー1台で実効電力6-10kVA ◼ 既存DCではラックの電力や冷却の課題 • 新たにGPUサーバー用データセンターを選定 ◼ 電力 -> 1ラック 20kVA以上 ◼ 消費電力: 定格12.5kVA(A100と比べて約1.5倍) ◼ 希望としては40kVA/ラックは欲しい ◼ 冷却性能 -> リアドア空調DCを採用 ◼ 既存DCの移設を実施 ◼ 既存DCで電力が足りない ◼ 冷却の問題 ◼ ラックの拡張性が無い 19

リアドア空調システム • 空冷で高負荷サーバーを高密度で設置可能な構成 ◼ 背面に冷却機器を搭載しラック毎の冷却制御が可能 • 前面からのみマウント / ポート面吸気のみ対応 • リアドアの開放時間が長いと温度が上昇 • 作業時にイヤーマフ必須 ◼ リアドア付近は約100dB • フロントドアを拡張 ◼ トランシーバが長い ◼ QSFP-DD/OSPFトランシーバーに合わせて拡張 20

ネットワーク物理設計 • Rail-optimized Topologyを採用 ◼ NVIDIA NCCL2などのワークロードに最適化されたネットワーク ◼ サーバーの各NICのindexが同じLeaf SWに繋がるように収容 (GPU、NICは1:1) ◼ GPU同士が高速なNVLinkが繋がっていることがポイント ◼ NCCLでPXN(PCIe x NVLink)を有効にした場合はGPUに一番近いNICやNVLink経由のGPUで通信 ◼ GPU Node InterconnectはInbound/Outboundで同じIF利用 ◼ Rail-optimized Topologyを活かすためにはNCCLのパラメータをチューニングしていくのが大変 ◼ ブロック図を見てサーバー内部の構成を意識して物理設計する必要がある Leaf Spine Spine Leaf Leaf Leaf Leaf Leaf Leaf Leaf Spine Spine H100 H100 H100 H100 H100 H100 H100 H100 L3GW L3GW インターコネクト (Lossless) 400Gbps x8 インターネット・ストレージ(Lossy) 25Gbps x2(LAG) Storage/ Server FW/LB MC-LAG 21

• 要件の異なるネットワーク(LossyとLossless)を分離 ■要件が異なったネットワークをQoSで制御していくのは困難と判断 •Lossless NWは400GbEフルバイセクション構成 ■各GPUサーバーがトラフィックをフルで流しても帯域的なボトルネックが無い ■アップリンクとダウンリンクが同じ帯域 •400GbEで統一し異速度カットスルー/バッファリングの低減 ■低遅延 •LAGの撤廃 ■障害時などのトラフィックフローの不均衡問題対策 22 ネットワーク物理設計

ネットワーク物理設計 • ラック構成はEnd of Row(EoR)を採用 ◼ 1ラック最大2サーバーとなるためToR構成は収容効率が悪い ◼ サーバーへの配線は全てパッチパネルを経由 ◼ 拡張時のパッチパネルの納期、MPOケーブルのコスト ◼ パッチパネルを使わない方法も検討中 23

GPUサーバー用トランシーバーの選定 • サーバーはConnectX-7で接続 VPIでEthを利用 ◼ ConnectX-7の接続方式は2パターン ◼ DGX H100: OSFP 800G (400G x2) ◼ HGX H100: OSFP-RHS 400G • 検証時に用意していたトランシーバーが刺さらない問題発生 ◼ MSAのOSFP SpecificationでOSPF-RHSの存在を知る ◼ OSPF-RHSはOSPF Riding Heat Sinkの略 ◼ OSPF-RHSはヒートシンクをNIC側に外付けしたもの ◼ Riding Heat Sinkだがヒートシンクが乗っているわけではない ◼ 他社では取り扱いが無いため純正トランシーバーを採用 24 OSFP-RHS 400G x1 OSFP-RHS 400G x2

スイッチ用トランシーバーの選定 • GPUサーバーとSW間は400G-DR4を選択 ◼ ファイバーはMPO-12/SMFを初採用 ◼ ファイバーケーブルがAPC端面 • スイッチ間はAOCを選択 ◼ EoR構成のためSpine-Leafの物理的距離が近い ◼ トランシーバー x2 + MPOケーブルより安価に構築可能 • 400Gトランシーバーは純正を利用 ◼ 3rd party トランシーバーのリンクアップが遅いケースがある ◼ 純正と比べてLinkupまで時間がかかる(純正:20〜50sec、3rd party:90sec) ◼ shutdown -> no shutdown で Linkupしなくなる問題 ◼ トランシーバのFirmware Revisionの管理が必要 ◼ スイッチ/NICで運用上必要な情報を取得出来るか確認 ◼ 光レベル、シリアルNo、温度 25

ネットワーク論理設計 • GPUサーバー <-> Leafスイッチ間 ■ 各LeafにVLANを設定、 Leafスイッチの数だけスタティックルーティング -> サーバーでルーティングソフトウェアを管理したくない -> GPUサーバー内のトポロジを考慮しNICとIPアドレスの紐づけが一意となるような設計 -> NCCLはIF障害時に学習が止まる仕様のためバックアップ経路は不要 ■ スタティックルートはIPアドレスの設定と一緒にAnsibleで設定投入 ■ 通信するNICの選択はNCCL任せ • Leafスイッチ <-> Spineスイッチ間 ■ Fat-treeでBGP unnumbered -> BGPのオペレーションが楽なため ■ BGP gshut community ■ Adaptive Routing 26

Elephant flow / Mice flow問題 Spine Spine Spine Leaf Leaf Leaf NodeA NodeB •5-tupleが同じパケットはスイッチのhashにより同じ経路を通過(static hashing) •Elephant flowが発生するとMice flowなどにも影響が発生 •バッファを考慮しないHash方式のトラフィックの偏りが問題(Incastなど) Tuple lookup Discard! 27

Elephant flow / Mice flow問題 - Adaptive Routing - Spine Spine Spine Leaf Leaf Leaf NodeA NodeB •パケットをflowletとして認識し、バッファの状況を見てdynamicにhashを実施 •Elephant flowが発生してもLeaf-Spine間均等にhash •IP NWでは厳密なノンブロッキングは不可能なのでAdaptive Routingによるアプローチを選択 •Relaxed Ordering(PCIe Layerでのreordering)を有効化 Tuple lookup 28

•パケットフローのかたまりを時間軸的に分割 •各スイッチはFlowlet単位でトラフィック分散が可能(Flowlet Switching) •Flowlet間のIntervalがNode間の最大遅延より短い場合はOut-Of-Orderは発生しない - Multipath max-delay-time > Interval 29 time Packet Flowlet Flowlet Flowlet Interval NodeA NodeB Multipath max-delay

Adaptive Routing(AR)の検証 • ARを有効/無効にしたLeaf SWが混在した環境でnccl-testsを実行 • ARを有効にしたスイッチに置いてSpine向けのTX側トラフィックが均等に分散 30

RoCEv2のパケットフォーマット 31 CNPのパケットをフィルタリングした結果 UDP上でInfinibandの通信していることが分かる

Kubernetes Podネットワーク • Interconnect側は、 SR-IOVを利用し各Podから仮想NIC(VF)をアタッチ • 耐障害性のため物理NIC分のVFをアタッチ 32 Pod1 NIC NIC VF VF PF VF VF GPU PF Interconnect NW Pod2 NIC NIC GPU

インターコネクト動作検証 • RoCEv2での確認 (400Gbps) ■ib_write_bwを利用 -> 初期出荷時にDGX H100で400Gbpsが出ずNICのパラメータをチューニングに苦戦 ■QoS(ETS)の確認: RoCEv2のトラフィックが優先されること -> iPerfはマルチスレッド実行 ■nccl-testsでパフォーマンスを確認 -> NIC to NICの検証ではなくGPU to GPU(GPU Direct RDMA)の通信で新たな問題を発見 -> NCCL周りのチューニングと理解 ■実際の学習を模擬したワークロードを実施 33

インターコネクト動作検証 • Adaptive Routing ■トラフィックを流したときのSpine-Leafのトラフィックが分散していることを確認 ■マルチベンダGPU環境でAR有効時にトラフィックが数Mbps程度しか流れない事象 -> NICの枚数の違いによるスクリプトのミス、意図せずAR有効/無効が混在するとパフォーマンス低下 ■AR有効時はSelective Repeatがサポートされない問題 ■実際のワークロードで分散されるかは別途確認が必要 • ECN/CNP ■輻輳発生時にECN/CNPによって輻輳制御が実施されていることを確認 ■CNPパケットの確認 -> CNP通知側でカウンタは増えているがCNPを受け取る側にパケットが届いていない -> PodにtcpdumpとOFEDをインストールしパケットを確認: NIC側の不具合と判明 -> CNP送信と受信両方のカウンタを必ず確認 34

インターコネクト構築 メリット・デメリット • Ethernetを選定したメリット・デメリット ◼ 運用・監視でこれまでのEthernetと同等の同じ運用が出来る ◼ BGPによる迂回、SNMP・syslog監視、パケットキャプチャ ◼ 機器の選択肢が増える (納期問題も解消) ◼ RoCEv2にはInfinibandの知識が必須 • Lossyと分離したメリット・デメリット ◼ 要件の異なるトラフィックのQoSチューニングを考慮しなくていい ◼ Lossless NWの構築・運用コストがかかる • 400GbEを選択したメリット・デメリット ◼ Ethernetのボトルネック/輻輳制御をあまり気にしなくなった ◼ 規格と部材の選定の調査にコストがかかる 35

36 Interconnect Lossless Lossy Network GPU

今後検討している事 • 800GbEの導入検討 ■収容効率が良い -> ホップする機器の遅延と運用管理の為機器の台数を増やしたくない -> Scalable Unit(SU)で収容できる台数を増やしたい ■800Gx64port = 51.2Tbpsスイッチ / 400G 128port SW • 水冷 DLC / 液浸の調査 ■サーバー周りの知識 ■ファシリティ • フルバイセクションからオーバーサブスクリプション -> NCCLの理解度によりSpineを経由しないワークロードで実行が可能 • ストレージネットワークの改良 • 輻輳制御周りの改善・調査 • 次期GPUサーバーの検証 37

困っている事 1. ワークロードに対してどのような輻輳制御をしていくべきか ■ PFC / ECNだけでなくどこでチューニングしていくか 2. バーストトラフィックが見れない ■ 可能であれば1秒置きのトラフィックが見たい 3. 拡張性の問題 ■ データセンターのキャパシティの問題 4. パフォーマンスの切り分け範囲が広い ■ サーバー面、ソフトウェア面の理解が必要 5. 納期問題 ■一つの納期遅延がプロジェクト全体に影響を与えてしまう 6. 検証環境問題 ■GPUサーバーのコストが大きい ■トランシーバ、スイッチ、電源、配線、NICなど 38

まとめ • 機械学習、データサイエンティストの新しい要望に対しGPU分散学習基盤を構築 • GPUサーバーのインターコネクト技術の構築と運用について共有 ■CPU centricだけでは無い新しいネットワークの形 • 生成AI向けネットワークエンジニアで求められる技術領域は広がっている GPU分散学習基盤のエンジニアで必要となってくるスキルセットの一部 ◼ Network: RoCEv2 / Infiniband / Congestion Control / Workload ◼ NIC(Connect-X) / Transceiver / Cable / PCIe SW / Server Diagram / SR-IOV ◼ Collective Communications / Collective Communications Libraries ◼ GPU / LLM ◼ k8s CNI ◼ Storage: NFS / GPU Direct Storage ◼ Facility: Direct Liquid Cooling / Power Consumption 39

END

APPENDIX

PFC (Priority Flow Control) • VLAN CoS(PCP)またはIP ToS(DSCP)を参照しmapping表でパケットを分類 • 輻輳時にキュー毎にXoff(一時停止)、Xon(送信再開)をイーサネットフレームで制御 • 閾値を超えたらXoff、閾値を下回ったらXonを送信 • 遅延計算のためにケーブル長などを設定 • トラフィックが完全停止する場合があるためPFC watchdogなどを設定することが推奨 42 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 Sender Receiver Xon (Resume) Xoff (Pause) Buffer Xon Threshold Xoff Threshold RoCEv2 CNP Mapping table CoS DSCP Priority 0 0-7 0 1 8-15 1 2 16-23 2 3 24-31 3 4 32-39 4 5 40-47 5 6 48-55 6 7 56-63 7

ECN (Explicit Congestion Notification) • IP ToSのECNで2bitで輻輳制御を実施 • 輻輳を検知したらRED (Random Early Detection): [REDはoptionであることが多い] • 輻輳時は全てのパケットにECN CE(11) • ReceiverはSenderにCNPを送信、Senderは送信レートの制限を実施 • エンドノード間の輻輳制御により輻輳の原因の根本解決に役立つ 43 Sender Receiver Server Server bit Description 00 ECN非対応 01 ECN対応 ECT[1] (CNPの時に利用/CNPはBTHで定義) 10 ECN対応 ECT[0] (一般的に利用) 11 輻輳発生 / CE Switch Switch ECN:10 Congestion RED DROP ECN:10 ECN:11 CNP(BTH)

ETS (Enhanced Transmission Selection) • データ転送側のキューの制御 • 各PriorityGroup毎にQoSを使いキューの優先処理を決定する • RoCEv2やCNPのキューの優先度を上げてAI/MLワークロードに最適なチューニングを実施 44 TCP: DWRR: 10% 7 6 5 4 3 2 1 0 RoCE: DWRR: 80% UDP: DWRR: 10% CNP: High Priority TCP: DWRR: 10%

CPU GPUサーバーで分散学習するネットワーク 45 ①Internet (Lossy) GPU IB or Ethernet(Lossless) ③Interconnect (RDMA) ②NVLink それぞれ要件が違ったネットワークが求められる ① CPUセントリックなインターネットなどの通信: Lossy ■ Hugging FaceやGCS/S3からモデルやデータセットをダウンロード ■ Kubernetes Pod間通信 ② サーバー内のGPU間通信はPCIeよりも広帯域なNVLink4で通信 ■ NVLink4の片方向の総帯域は450GBytes/sec (25Gx18) ■ GPU内部サーバー内のNVSwitch3でSHARPが利用可能 ③ サーバーを跨ぐGPU間通信は①と独立したロスレス低遅延: Lossless ■ GPU Direct RDMA: CPUを介さずリモートホストGPUメモリにRDMA -> ACSは無効にしてRoot Complexを経由させない ④ ストレージネットワーク(NFS / GPDS:GPU Direct Storage) ■ コンテナにアタッチされたファイルストレージ(Volume)との通信 ■ 学習用データセットの読み込みやチェックポイントの書き出し ⑤ BMC/IPMIなどの管理用ネットワーク NIC GPU CPU Mem NIC NVMe NIC NIC Interconnect SW CPU GPU NIC GPU CPU Mem NIC NVMe NIC NIC PCI switch Storage SW Internet SW Management PCI switch ④NFS / GDS NVSwitch NVSwitch