> [!abstract] 概要(Abstractの日本語訳) > 大規模言語モデル(LLM)の急速な成長により、GPUクラスタとGPU間の効率的なデータ転送への需要が高まっている。GPUDirect RDMAのような近年のGPU間通信技術は、CPUとホストメモリをバイパスすることで通信速度を向上させたが、ネットワーク監視を複雑にした。GPU間通信は、CPU・GPU・ルートコンプレックス・RNICという複数のコンポーネントを経由し、その経路がスループット全体に影響する。NICのスループットだけを計測するのでは不十分であり、サーバ内部のコンポーネントを監視する必要がある。この監視を実現するため、本論文ではInterconnectLens(ICLens)を提案する。これは各サーバの各コンポーネントにおけるGPUデータ転送を包括的に可視化するオブザーバビリティツールである。ICLensはコンポーネントごとの帯域使用量を送信(TX)と受信(RX)の方向に分類し、時系列で示すとともに、各コンポーネントの帯域使用量を可視化するダッシュボードを提供する。本論文では、本番環境で実際に発生した事例を含む、クラスタで一般的な3つの問題――RDMAではなく意図せずTCPを使用してしまう問題、GPUDirect RDMAの誤設定、イーサネットスイッチの輻輳――を再現するケーススタディを通じてICLensを実証する。これらのケーススタディは、ICLensがオブザーバビリティを高め、GPU通信問題の根本原因の発見を助けることを示している。 ## 論文情報 - タイトル: InterconnectLens: Enhancing Observability of Data Transfers in GPU Clusters - 著者・所属: Koshi Eguchi(東京大学)、Ryo Nakamura(東京大学)、Yohei Kuga(トヨタ自動車)、Kenjiro Taura(東京大学、NII LLMC) - 媒体: Practice and Experience in Advanced Research Computing (PEARC '25)、2025年7月20〜24日、Columbus, OH, USA。ACM刊、全5ページ。 - DOI: [https://doi.org/10.1145/3708035.3736055](https://doi.org/10.1145/3708035.3736055) - ACM ISBN: 979-8-4007-1398-9/25/07 - ライセンス: CC BY 4.0(This work is licensed under a Creative Commons Attribution 4.0 International License) ## 概要 LLM訓練でGPU-to-GPU通信がボトルネックになる中、GPUDirect RDMAはCPU・ホストメモリをバイパスして高速化する一方、通信経路がCPU・GPU・ルートコンプレックス・RNICの複数コンポーネントにまたがるため単一のNICメトリクスだけでは性能劣化の原因を追えなくなる。本論文はこの課題に対し、サーバ内の各コンポーネントの帯域使用量をTX/RX方向別・時系列で統合可視化するオブザーバビリティツールInterconnectLens(ICLens)を提案し、3つのケーススタディで有効性を示す。 ## 問題設定 - 入力: GPUクラスタ内の各サーバが備えるCPU・GPU・Root Complex・RNICのハードウェアカウンタ(帯域使用量)。 - 出力: コンポーネント別・TX/RX方向別の帯域使用量を時系列で示すダッシュボード。 - 前提: サーバ間はGPUDirect RDMA対応のRNICで接続され、NCCL等の集合通信ライブラリでトラフィックを生成する環境。GPU-to-GPU通信は設定次第でCPUやホストメモリを意図せず経由しうる。 - 動機: NVIDIA Nsight[7]はGPU、Intel pcm[4]はCPUというように既存の監視ツールは個々のコンポーネントを独立に監視するのみで、GPU間通信路上の全コンポーネントを横断的に観測できるツールが欠けていた。 ## 提案手法 - **アーキテクチャ**: ICLensはExporter群・Prometheus Server・Webダッシュボードの3層で構成される(Figure 2)。各サーバ上のExporterがハードウェアカウンタを収集し、中央のPrometheus Serverがそれらをpullして時系列データベースに蓄積し、Webダッシュボードが`PromQL`[12]でクエリして結果をリアルタイムにグラフ表示する。図中ではオレンジ破線がICLensが新規実装した部分(Exporter群・ダッシュボード)、黒破線が既存ツールを流用した部分(Prometheus Server、DCGM Exporter)を示す。 - **可視化の設計**: ICLensは(1)タイムライン、(2)帯域、(3)サーバコンポーネント(CPU・GPU・PCIe・RNIC)、(4)データ転送方向(TX/RX)の4軸でGPU-to-GPUデータ転送を可視化する。系列ラベルは「RNIC(mlx5_1)[RX]/[TX]」「CPU PCIe [RX]/[TX]」(Root Complex経由のPCIeリンク)「CPU Memory(CPU MEM)[RD]/[WR]」(ホストメモリ)「GPU0 MEM BW [RD/WR]」のように、コンポーネントと方向を組み合わせた命名規則を用いる。Root Complexを介して不適切な経路(例: GPU/RNICの誤配置)を通ると、CPUPCIe[RX/TX]メトリクスの増加として現れる。 - **実装上の工夫**: コンポーネントごとにベンダー・デバイス種別が異なるため、収集手段を作り分けている。 - GPU: NVIDIA公式のdcgm-exporter[8]をそのまま利用。 - CPU PCIe・CPU Memory: Intelのpcm[4](CLIツール)をPrometheus互換形式でメトリクスを出力するよう拡張。複数のCPU世代に対応するため実装は約2,400行に及ぶ。 - RNIC: RDMAトラフィックはRNICハードウェアにオフロードされるため`/proc/net/dev`のような標準のLinuxカーネルインターフェースカウンタには現れない。そこでNVIDIA RNICが`/sysfs`配下(例: `/sys/class/infiniband/mlx5_1/ports/1/counters/port_rcv_data`)に公開するRDMAトラフィックメトリクスを、`prometheus/procfs`[11] APIでポーリングする独自Exporterを開発した。 - 各Exporter(DCGM・CPU Memory・CPU PCIe・RNIC)のCPU使用率はいずれも1コアの1%未満に抑えられている。 ## 新規性 既存の監視ツールはコンポーネントを個別に監視するにとどまり(NVIDIA NsightはGPU、Intel pcmはCPU)、GPU間通信路上の全コンポーネントを統合的に観測する手段がなかった。ICLensは、ベンダー横断の複数のExporterをPrometheusという単一の時系列データベースに統合し、コンポーネント×方向(TX/RX)の系列を単一ダッシュボード上で横並びに比較可能にすることで、この間隙を埋める。GPUDirect RDMAが「CPU・ホストメモリのバイパス」によって高速化する一方でその経路の可観測性を犠牲にしていたという問題意識に対し、ICLensは経路そのものをコンポーネント単位で可視化することで応答する。 ## 実験設定 - ハードウェア: 100Gbps NVIDIA ConnectX-6 Dx NICで直結された2台のサーバ。各ホストにNVIDIA RTX 6000 Ada Generation GPUを1基搭載。GPUDirect RDMAによるRNIC-GPU間通信が可能な構成。 - ソフトウェア: トラフィック生成にNVIDIA Collective Communication Library(NCCL)[9]およびNCCL-Tests(NCCL操作の性能・正当性を検査するテストキット)を使用。 - 比較対象・評価指標: 明示的なbaselineとの定量比較は行わず、3つのケーススタディ(3.1〜3.3節)でコンポーネント別TX/RXメトリクスの時系列を目視・数値検証する定性的な実証形式を取る。 ## 実験結果 - **Figure 1(集合通信操作の可視化例、Broadcast/AllReduce)**: 2台のサーバ間でBroadcastとAllReduceを実行した際のICLensの表示例。Broadcastでは通信負荷が主にTX(緑)に偏るのに対し、AllReduceではRX(青)とTXの両方が生じる。これはBroadcastが送信元サーバから他サーバへ一方向にトラフィックを流すのに対し、AllReduceは各GPUが他の全GPUへ送信しつつ他の全GPUからの受信データを集約するという通信パターンの違いに起因する。ページ制約により通信を開始したサーバのグラフのみを示すと本文は明記する。 **Figure 1: BroadcastとAllReduceの可視化。ICLensは両操作の通信負荷分布の違い——BroadcastはTX(緑)主体、AllReduceはTXとRX(青)の両方——を示す。** ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig01a-broadcast.png]] (Figure 1a. Broadcastの可視化。RNIC(mlx5_1)[TX]とGPU0 PCIe[TX]が11:17:04頃から立ち上がり、RX系列はほぼ無負荷のまま推移する。GPU0 MEM BW[RD/WR]も同時刻から高い値を示す。) ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig01b-allreduce.png]] (Figure 1b. AllReduceの可視化。RNIC(mlx5_1)[RX]/[TX]とGPU0 PCIe[RX]/[TX]がいずれも11:13:33頃から同時に立ち上がり、TXとRXの双方に負荷が生じる。Source: Figure 1.) - **Figure 2(システム構成)**: Exporter群(オレンジ破線: 独自実装)からPrometheus Server(黒破線: 既存ツール)へPull Metricsで収集され、ICLens Webダッシュボード(オレンジ破線: 独自実装)がPromQLでReturn Metricsを取得して表示する、という3層構成をブロック図で示す。 **Figure 2: ICLensのシステム概要図。オレンジ破線が新規実装部分、黒破線が既存ツールの流用部分を示す。** ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig02-overview.png]] (Figure 2. Exportersがハードウェアカウンタを収集し、Prometheus Serverがpull・時系列格納した上で、ICLens Web DashboardがPromQLで取得しリアルタイム表示する構成。Source: Figure 2.) - **3.1節・Figure 3(TCP誤用の検出)**: `NCCL_NET`環境変数が未設定または`Socket`に誤設定されると、NCCLはRDMAではなくTCP通信を使う。ICLensはRDMA使用時とTCP使用時の可視化差分を示す。RDMA使用時はRNICメトリクスのみが現れ、TCP使用時はRNIC活動が一切現れずCPUMEM[RD]/[WR]の負荷として現れる。この差分から、ICLensによりTCPが意図せずRDMAより優先して使われている状況を推定できると論文は述べる。 **Figure 3: TCP誤用ケース。RDMA使用時(a)とTCP使用時(b)を比較すると、TCP時はRNICが不活性でCPU負荷が増加する。** ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig03a-allreduce-rdma.png]] (Figure 3a. RDMA使用時。RNIC(mlx5_1)[RX]/[TX]・GPU0 PCIe[RX]/[TX]が活性化し、CPU PCIe・CPU MEM系列は無負荷のまま推移する。) ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig03b-allreduce-tcp.png]] (Figure 3b. TCP使用時。RNIC(mlx5_1)系列は無負荷のまま、代わりにCPU PCIe[RX]/[TX]とCPU MEM[RD]/[WR]が立ち上がる。RNICはRDMAトラフィックのみを計測対象とするため、TCP通信時はRNIC活動が一切現れない。Source: Figure 3.) - **3.2節・Figure 4(GPUDirect RDMA誤設定の検出)**: PCIeスロットへのGPU/RNICの誤配置・スロット設定・NCCL環境変数の誤設定などにより、GPUDirect RDMAが正しく機能せずデータがCPUを経由してバウンスすることがある。ICLensは誤設定時にCPU PCIe・CPU Memoryへの追加トラフィックが現れることを示す。RNIC自体はRDMAが活性でRX/TXを正しく処理しているように見えても、CPU Memory・CPU PCIe経由の予期しないデータ転送が並行して発生する状況を、ICLensは明らかにする。 **Figure 4: GPUDirect RDMA誤設定ケース。誤設定時(b)はCPU MemoryとCPU PCIe経由でデータが転送される。** ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig04a-gpudirect-rdma-correct.png]] (Figure 4a. GPUDirect RDMA正常時。RNICとGPU0 PCIeが活性化し、CPU PCIe・CPU MEMは無負荷。) ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig04b-gpudirect-rdma-misconfig.png]] (Figure 4b. GPUDirect RDMA誤設定時。CPU PCIe[RX]/[TX]とCPU MEM[RD]/[WR]に追加負荷が生じる一方、RNIC(mlx_1)[RX]/[TX]はRDMAが活性でinter-nodeデータ転送を正しく処理しているように見える。この乖離がGPUDirect RDMAの誤設定またはGPU/RNICの不適切な配置を示唆する。Source: Figure 4.) - **3.3節・Figure 5(イーサネットスイッチ輻輳の検出)**: 2台のサーバを接続するイーサネットスイッチポートのスループットを20Gbpsに制限して輻輳を模擬した。CPU PCIe・CPU Memoryに顕著な負荷はなく、RNICはRDMA通信を示しているにもかかわらず、リンク全体の帯域が低下する。ICLensのダッシュボードはマウスホバーで各コンポーネントの正確な帯域値をツールチップ表示でき、実測ではRNIC(mlx5_1)[TX]の帯域が約2.47GB/sだった。これはRoCEv2でデータペイロード4096バイト・パケットヘッダ58バイト(MAC・IP・UDP・IB BTH・CRC)という条件下の理論最大スループット (4096−58)/4096×20 (Gbps) ≈ 19.72 (Gbps) ≈ 2.47 (GB/s) と一致する。 **Figure 5: イーサネットスイッチ輻輳ケース。輻輳時(b)はRNICの理論最大値と比べ帯域が明確に低下する。** ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig05a-no-congestion.png]] (Figure 5a. 輻輳なし。RNIC(mlx5_1)[RX]/[TX]・GPU0 PCIe[RX]/[TX]が活性化し、CPU側系列は無負荷。) ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig05b-with-congestion.png]] (Figure 5b. 20Gbpsに制限したスイッチポート経由の輻輳あり。ツールチップは「RNIC(mlx5_1)[TX] Time: 12:43:21 Value: 2.47 GBps」を示す。CPU PCIe・CPU Memoryへの顕著な負荷は見られず、RNIC自体はRDMA通信を示しているにもかかわらずリンク全体の帯域が低下している。Source: Figure 5.) ## 考察 3つのケーススタディはいずれも、RNIC単体のメトリクス(RDMAが活性かどうか)だけでは判別できない問題を、CPU PCIe・CPU Memory・GPU PCIeを含むコンポーネント横断の可視化によって切り分けられることを示す。TCP誤用ケースはRNIC不活性+CPU負荷増加という組み合わせで、GPUDirect RDMA誤設定ケースはRNIC活性(RDMA自体は機能)+CPU PCIe/Memory負荷増加という組み合わせで検出され、両者はRNICメトリクスだけを見ていると区別がつかないが、コンポーネント別の並置によって初めて切り分けられる。イーサネットスイッチ輻輳ケースは対照的に、CPU側系列に異常が現れずRNIC自体の帯域低下として現れる点で、他の2ケースとは異なる診断パターンを示す。 ## 強み / 弱点・課題 - **強み**: 複数ベンダー(NVIDIA・Intel)・複数コンポーネント種別(GPU・CPU PCIe・CPU Memory・RNIC)のメトリクスをPrometheusという単一の時系列データベースに統合し、TX/RX方向別・コンポーネント別に横並び比較できるダッシュボードとして提供する。各Exporterのオーバーヘッドは1コアの1%未満に抑えられている。3つの実運用に近いケーススタディ(うち1つは著者らの本番環境で実際に遭遇した問題)で有効性を示している。 - **弱点・課題**: 論文自身が「今後の課題」として、可視化のみにとどまらず通信問題を自動検知・通知する機能への拡張、NVIDIA GPU・Intel CPU以外の幅広いハードウェアへの対応拡大を挙げている。また、ページ制約により通信を開始したサーバのグラフのみを示すと明記しており(§2.1)、クラスタ全体を俯瞰する形での可視化例は本論文には含まれていない。実験は2台のサーバ・各1GPUという小規模構成での実証にとどまり、より大規模なクラスタでのスケーラビリティは論文内で直接評価されていない。