> [!abstract] 概要(abstract 日本語訳) > 複数 GPU ノードはエクサスケールスーパーコンピュータの急速な進化の中でますます一般的になっている。これらのシステムでは、同一ノード上の GPU は専用ネットワークを通じて接続されており、帯域幅は毎秒数テラビットに達する。しかし、技術・設計オプション・ソフトウェアレイヤが多様であるため、性能期待値の把握とシステム効率の最大化は容易でない。本論文では、異なるアーキテクチャと設計をもつ3台のスーパーコンピュータ——Alps・Leonardo・LUMI——を包括的に特性評価する。ノード内・ノード間インターコネクトの性能評価に最大4,096 GPU を用い、ノード内・ノード間のベンチマークを組み合わせて行う。その限界と機会を分析することで、マルチ GPU スーパーコンピューティングを扱う研究者・システムアーキテクト・ソフトウェア開発者に対し実践的な指針を提供することを目指す。我々の結果は、未活用の帯域幅が存在し、ネットワークからソフトウェアに至る最適化の機会が数多く残されていることを示す。 ## 論文情報 - **タイトル**: Exploring GPU-to-GPU Communication: Insights into Supercomputer Interconnects - **著者**: Daniele De Sensi (Sapienza University of Rome), Lorenzo Pichetti (University of Trento), Flavio Vella (University of Trento), Tiziano De Matteis (Vrije Universiteit Amsterdam), Zebin Ren (Vrije Universiteit Amsterdam), Luigi Fusco (ETH Zurich), Matteo Turisini (CINECA), Daniele Cesarini (CINECA), Kurt Lust (University of Antwerp), Animesh Trivedi (IBM Research Europe), Duncan Roweth (HPE Cray), Filippo Spiga (NVIDIA), Salvatore Di Girolamo (NVIDIA), Torsten Hoefler (ETH Zurich) - **媒体**: SC24 (International Conference for High Performance Computing, Networking, Storage and Analysis), November 17–22, 2024, Atlanta, Georgia, USA - **DOI**: 979-8-3503-5291-7/24/$31.00 ©2024 IEEE - **コード**: 論文アーティファクトとして公開(URL 記載なし) ## 概要 Alps(NVIDIA H100, HPE Cray Slingshot)・Leonardo(NVIDIA A100, InfiniBand HDR)・LUMI(AMD MI250X, HPE Cray Slingshot)という異なるアーキテクチャを持つ3台の欧州スーパーコンピュータを対象に、GPU 間通信を点対点からスケール4,096 GPU の集団通信まで包括的にベンチマークした。通信ライブラリ(NCCL/RCCL, GPU-Aware MPI, Device-Device Copy, Trivial Staging)・転送サイズ・GPU 配置距離・ネットワークノイズの4軸で性能を定量化し、8つの重要な観察を提示する。 ## 問題設定 - **入力**: マルチ GPU スーパーコンピュータ上のワークロード(ML・科学計算・ビッグデータ) - **課題**: インターコネクト技術・トポロジ・ソフトウェアの多様性により、最適な GPU 間データ移動方法が不明確 - **前提条件**: 単一ノード内(NVLink/Infinity Fabric)から複数ノード間(Dragonfly/InfiniBand)まで全レイヤを実機評価 ### 評価対象システム(表I) | システム | CPU | GPU | ノード内接続 | ノード間接続 | |---|---|---|---|---| | Alps (#6 Top500) | NVIDIA Grace 72コア | 4× NVIDIA H100 | NVLink 4.0 (1.2 Tb/s/ペア) | HPE Cray Slingshot-11 Dragonfly | | Leonardo (#7 Top500) | Intel Ice Lake 32コア | 4× NVIDIA A100 | NVLink 3.0 (800 Gb/s/ペア) | NVIDIA InfiniBand HDR Dragonfly+ | | LUMI (#5 Top500) | AMD EPYC Trento 64コア | 4× AMD MI250X (8 GCD) | Infinity Fabric (400 Gb/s/リンク) | HPE Cray Slingshot-11 Dragonfly | **Figure 1: Alps および Leonardo ノードアーキテクチャ** ![[_attachments/sc24-gpu-gpu-interconnect/fig01-node-architecture-alps-leonardo.png]] (図1. Alps は GH200 4枚が NVLink 4.0 で全接続(any pair 1.2 Tb/s)し各 GH200 が Cassini-1 NIC に接続。Leonardo は A100 4枚が NVLink 3.0 で接続(any pair 800 Gb/s)し 2枚の dual-port ConnectX-6 NIC を共有する。Source: Figure 1, De Sensi+ SC24.) **Figure 2: LUMI-G ノードアーキテクチャ** ![[_attachments/sc24-gpu-gpu-interconnect/fig02-node-architecture-lumi.png]] (図2. LUMI は AMD MI250X 4枚(8 GCD)が Infinity Fabric でメッシュ状に接続。GCD 間のリンク数は1〜4本で非対称。各 MI250X が Cassini-1 NIC に接続。Source: Figure 2, De Sensi+ SC24.) ## 提案手法(ベンチマーク設計) 独自ベンチマークを scratch から開発した理由: OSU は device-device copy 非対応、nccl-/rccl-tests は *CCL のみ対応、両者ともに per-iteration タイミングを報告しない。 ### 計測手法 - **Trivial Staging**: GPU メモリ→ホストメモリ→MPI でノード間通信。ベースライン。 - **Device-Device Copy**: GPU メモリ間の直接コピー。共有ハンドル経由。 - ***CCL**: NCCL(Alps/Leonardo)または RCCL(LUMI)による GPU 間通信。 - **GPU-Aware MPI**: GPU メモリ上のバッファを MPI で直接転送。 各実験は100〜1,000回反復し、集団通信では全ランクの最大時間(最小スループット)を報告。`MPI_Wtime`で個別イテレーションを計時(Alps 30ns・LUMI/Leonardo 25ns 分解能)。 ### パフォーマンスチューニング デフォルト設定からの主な変更点: - *CCL: `NCCL_IGNORE_CPU_AFFINITY=1`→Alps/LUMI で alltoall 最大1.6×、allreduce 最大6× 改善 - *CCL: `NCCL_NET_GDR_LEVEL=3`→ alltoall 2×、allreduce 3× 改善 - LUMI: `NCCL_NCHANNELS_PER_PEER=32`→ノード内点対点 3.5× 改善 - Alps GPU-Aware MPI: `MPICH_GPU_IPC_THRESHOLD=1`→小転送 2× 改善 - LUMI GPU-Aware MPI: `HSA_ENABLE_SDMA=0`→最大 3× 改善 - Leonardo: GDRCopy パスを修正→小メッセージ最大 6× 改善 > [!warning] 観察1 > マルチ GPU システムで良い性能を得るには非自明なチューニングが必要で、システム・メッセージサイズ・通信ライブラリ・ノード数に依存する。*CCL と GPU-Aware MPI のデフォルト選択は必ずしも最適でなく、手動チューニングで最大1桁の性能向上が得られる。 ## 実験設定 - **Alps**: 512ノード(Santis 早期アクセスパーティション)まで。ノード内 GPU peer access 無効のため device-device copy 不可。 - **Leonardo**: 最大256ノード(1,024 GPU)制限。Open MPI v4.1.4 + UCX v1.13.0 + CUDA v12.1。 - **LUMI**: 最大512ノード(4,096 GPU)。ROCm v5.7.1.1、aws-ofi-rccl plugin v1.4。 ## 実験結果 ### ノード内点対点性能(図3) **Figure 3: GPU-GPU ノード内転送性能** ![[_attachments/sc24-gpu-gpu-interconnect/fig03-p2p-intranode-perf.png]] (図3. 各システムの ping-pong によるノード内 GPU 間帯域幅。Trivial Staging は他手法より1桁低い。Alps/LUMI では*CCL・MPI・Device-Device Copy が同等の帯域に達する。Leonardo では大サイズで GPU-Aware MPI が NCCL 比最大2倍高スループット。ただし小メッセージではシステムにより最適手法が異なる。Source: Figure 3, De Sensi+ SC24.) > [!info] 観察2 > GPU-Aware MPI はノード内点対点転送でほぼすべてのシステムで最高スループットを示す。小転送では、アーキテクチャ特性と MPI の実装最適化に応じて最適解がシステムごとに異なる。 ### LUMI の GPU 配置の影響(図4) LUMI では GCD 間の Infinity Fabric リンク数が1〜4本と異なり、goodput は 250〜1,250 Gb/s にばらつく。RCCL は利用可能帯域幅の推定をホップ数のみで行う(パス数を考慮しない)ため、GPU 0〜7 間で goodput が GPU 0〜6 より大きく低下する場合がある。 > [!warning] 観察3 > LUMI では RCCL の点対点通信プリミティブが GPU 間の利用可能帯域幅を正確に推定できず、利用可能帯域を活かしきれていない。 ### ノード内集団通信(図5/6) Alltoall で: Alps/LUMI では*CCL が大転送で最高性能(トポロジ最適化アルゴリズムを持つため)。Leonardo では*CCL が MPI をわずかに下回る。小転送では LUMI で GPU-Aware MPI が*CCL 比最大3倍高速。 Allreduce で: Alps/Leonardo では*CCL が全サイズで MPI を上回る。Leonardo で Open MPI は GPU メモリのデータをホストにコピーして allreduce を実行するため極端に性能が低い。 > [!info] 観察4 > 単一ノード集団通信では、LUMI の小集団通信を除き*CCL が GPU-Aware MPI より優れる。*CCL が特定 GPU モデル向けに最適化されているためだが、集団アルゴリズムにはさらなる最適化の余地がある。 ### ノード間点対点性能(図7) MPI がすべてのシステムで最高帯域・最低レイテンシを示す。*CCL が GPU カーネルの起動・管理のオーバーヘッドを持つため、小転送では MPI が*CCL より最大1桁高速。 > [!info] 観察5 > ノード間点対点通信では、MPI が*CCL より小転送で最大1桁、大転送で最大3倍高速。 ### ネットワーク距離の影響(図8) **Figure 8: 距離別 GPU 間レイテンシ/帯域幅** ![[_attachments/sc24-gpu-gpu-interconnect/fig08-latency-goodput-distance.png]] (図8. 同一スイッチ・異なるスイッチ・異なる Dragonfly グループ間での GPU メモリ(左)とホストメモリ(右)のレイテンシ・goodput。Leonardo(InfiniBand HDR)は異なるグループ間で最大132μs の外れ値を示し、goodput が平均17%低下(395→328 Gb/s)。Alps/LUMI(Slingshot)は変動が小さい。Source: Figure 8, De Sensi+ SC24.) 各システムの同一スイッチ接続レイテンシ: Alps 4.33 μs、Leonardo 2.03 μs(GPU メモリ)、LUMI 3.71 μs。 > [!info] 観察6 > Alps/LUMI では GPU のネットワーク上の配置が平均性能に与える影響が限定的(レイテンシ30%・goodput 1%以下)。一方 Leonardo は異なるグループ間でレイテンシが平均2倍増加し goodput が17%低下。主因はネットワークノイズ。 ### ノード間集団通信スケーラビリティ **Figure 9: 2 MiB Alltoall スケーラビリティ** ![[_attachments/sc24-gpu-gpu-interconnect/fig09-alltoall-scalability.png]] (図9. 2 MiB alltoall の goodput を8〜4,096 GPU でプロット。*CCL が GPU-Aware MPI を全システムで上回る。Alps は漸近期待 goodput 200 Gb/s に最も近い。Leonardo と LUMI は 100 Gb/s を期待値として下回る。NCCL(Alps)と RCCL(LUMI)は alltoall で512+ GPU でスタックし計測不能。Source: Figure 9, De Sensi+ SC24.) **Figure 10: 1 GiB Allreduce スケーラビリティ** ![[_attachments/sc24-gpu-gpu-interconnect/fig10-allreduce-scalability.png]] (図10. 1 GiB allreduce スケーラビリティ。*CCL が GPU-Aware MPI をすべてのシステムで上回る。Leonardo では Open MPI がデバイスメモリをホストにコピーして allreduce を行うため極端に性能が低い。Alps/LUMI で256→512 GPU で*CCL 性能が急落し、アルゴリズム切り替え以外の要因が示唆される。Source: Figure 10, De Sensi+ SC24.) Alps/Leonardo では*CCL が最大1,024 GPU で約75%の効率を達成。LUMI は若干低い。 > [!info] 観察7 > *CCL はノード内 GPU 間インターコネクトを MPI より効果的に活用し、ターゲットアーキテクチャ向けに最適化されている。その優位性は少ノード数・大転送でより顕著。しかし alltoall では NCCL・RCCL 両方で大ノード数における不安定性を経験した。 ### ネットワーク輻輳とノイズ(§VI) Leonardo では全トラフィックがデフォルトでサービスレベル0に集中するため、ノイズが発生しやすい。非デフォルトのサービスレベルに切り替えると goodput 変動が消えるが、それは「他ジョブが同じサービスレベルを使っていない」という条件付き改善にすぎない。 1,024 GPU 規模では、ネットワークノイズが alltoall を20%・allreduce を50%低下させる。 > [!warning] 観察8 > ネットワークノイズは allreduce・alltoall の goodput を最大50%低下させる。 ## 考察 - 本論文の結論はすべてのマルチ GPU システムに広く適用可能。特にソフトウェア関連の知見は汎用性が高い。 - Slingshot 採用システム(Alps/LUMI)はネットワークノイズに強い。InfiniBand Dragonfly+ の Leonardo はノイズの影響を受けやすく、ルーティングアルゴリズムの改善が必要。 - fat tree トポロジを採用するシステムでは、Dragonfly/Dragonfly+ より直径が大きいため若干レイテンシが増す可能性があるが、主要な結論は成立する。 - Leonardo では Slurm がスイッチ接続情報を保持しておりジョブ配置の最適化が可能。 ## 強み / 弱点・課題 ### 強み - 実機での at-scale 実験(最大4,096 GPU)による初の包括的マルチシステム比較 - 同一ベンチマークを複数通信 API(Trivial Staging/Device-Device Copy/*CCL/GPU-Aware MPI)で統一計測 - 実本番ネットワークノイズの影響を定量化した初の研究(サービスレベル差を利用) - 8つの重要な観察が再現可能なアーティファクトとして公開済み ### 弱点・課題 - Alps は評価当時早期アクセス段階で、本番開放後に結果が変わる可能性を認めている - Leonardo の最大1,024 GPU という制限はシステム側の制約 - NCCL(Alps)/RCCL(LUMI)の alltoall が512 GPU 以上でスタックするバグは論文の制約として残存 - ネットワークノイズの対策として提示したサービスレベル切り替えは「他ジョブが同じ SL を使わない」という仮定に依存しており恒久的解決策ではない ## 関連 - ソース: [[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]](同グループによる Ethernet vs InfiniBand 比較) / [[@2022__SC__HammingMesh - A Network Topology for Large-Scale Deep Learning]] / [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]] - 概念: [[集合通信]] / [[HPCインターコネクトベンチマーク]] / [[GPU観測性]] / [[GPUクラスタ運用]] - エンティティ: [[Daniele De Sensi]] / [[Torsten Hoefler]] / [[Lorenzo Pichetti]] / [[Flavio Vella]] / [[CINECA]] / [[ETH Zürich]] / [[Sapienza University of Rome]] / [[NVIDIA]] / [[Vrije Universiteit Amsterdam]] - 関連 MOC: [[分散深層学習 - MOC]] / [[AI Infra Telemetry - MOC]]