# AI/ML基盤におけるGPU間ネットワークの負荷と性能影響を探る ## 概要 トヨタ自動車の加納浩輝・奥澤智子がJANOG55で発表した資料である。 GPU間通信を用いるAI/MLジョブについて、必要なネットワーク性能、発生するトラフィック量、アプリケーションを意識した性能試験の方法を整理している。 後半では、再生可能エネルギーを活用した分散計算基盤の構想と、拠点間の長距離RDMAを検討する際の課題を扱う。 ## 発表情報 - イベント: JANOG55 Meeting @Kyoto - 日時: 2025年1月22日(水) 14:45〜15:30 - 発表者: 加納浩輝、奥澤智子(トヨタ自動車株式会社) - 公開ページ: [JANOG55公式ページ](https://www.janog.gr.jp/meeting/janog55/gpupfm/) - スライド: 40ページ - 対象: 第一部「AI/ML基盤におけるGPU間通信の特性理解」、第二部「分散型計算基盤に向けた課題と展望」 ## 中心メッセージ - GPU間通信を専用のロスレスネットワークへ閉じ込めるだけでは不十分であり、AI/MLジョブの通信特性をネットワーク性能目標の入力にする必要がある。 - データ並列では逆伝搬計算と通信が並行実行されるため、通信時間をそのままGPU idle時間とみなしてはならない。 - ネットワーク性能の目標は、アプリケーションの逆伝搬時間、同期データ量、利用帯域の関係から定めるべきである。 - ベンチマークのMessage Sizeは、RDMAメッセージ、集合通信、Bucket、Chunk、MTUのどの粒度を表すかを確認してから解釈する必要がある。 - 再生可能エネルギーの地域偏在を計算資源の分散配置で活用する場合、拠点間距離がRDMAのACK遅延、バッファ設計、運用方法を左右する。 ## GPU間ネットワークと検証対象 ![[_attachments/janog55-gpu-network-load/page-004.png]] GPU間通信には専用のロスレスネットワークを用い、CPU-ストレージ通信にはロッシーなネットワークを使い分ける構成が示される。 一方、物理帯域は10Mbps級から400Gbps、1.6Tbps級へ増加しており、AI/MLジョブにどこまでの高性能ネットワークが必要かが問題になる。 資料の第一部は、GPU間通信ネットワークとAI/MLジョブの関係を次の三点から検証する構成である。 1. ネットワークがAI/MLジョブのボトルネックにならないための性能目標 2. 分散学習で実際に流れるトラフィック量 3. アプリケーションを意識したネットワーク性能試験の方法 ロスレスネットワークの構築方法、DCQCN、Dynamic LBの検証結果は対象外としている。 ## 分散方式ごとの通信特性 ![[_attachments/janog55-gpu-network-load/page-006.png]] 分散方式は、学習の高速化やメモリ消費削減などの目的に応じて使い分ける。 データ並列はAllReduceをStepごとに行い、FSDPはReduceScatterとAllGatherをレイヤごとに行う。 パイプライン並列はSendRecv、テンソル並列はAllReduceなどをレイヤごとに行う。 したがって、分散方式によってGPU間のデータ通信形式と頻度が異なり、ネットワーク性能の評価条件も変わる。 今回の分析対象はデータ並列である。 各GPUへ同じモデルをコピーし、学習データを分配するため、各GPUのモデル状態を同期させる通信が必要になる。 ![[_attachments/janog55-gpu-network-load/page-009.png]] データ並列の一つのStepでは、順伝搬、逆伝搬、データ同期、パラメータ更新が進む。 同期が完了するまで次の処理へ進めないため、通信性能が学習全体のボトルネックになりうる。 ## 計算と通信の重なり 資料は、単純な「逆伝搬後に通信を行う」図は正確でないと指摘する。 実際には、更新対象のパラメータを複数のBucketへ分割し、Bucket単位で逆伝搬計算と通信を並列実行する。 ![[_attachments/janog55-gpu-network-load/page-011.png]] 逆伝搬計算時間が通信時間より長い場合、通信は逆伝搬に隠れる。 最後のBucketの通信完了を待つ時間だけがGPU idle時間として露出する。 ![[_attachments/janog55-gpu-network-load/page-012.png]] 逆に、逆伝搬計算時間が通信時間より短い場合は、通信が計算を追い越す。 後続の通信と計算が詰まり、GPU idle時間が長くなる。 この関係はPyTorch Profileでも確認されている。 ![[_attachments/janog55-gpu-network-load/page-014.png]] 実験環境は、RoCEv2、コンテナあたり100GbpsのサーバNIC、Kubernetes上のPyTorch Job、PyTorch DDPで構成される。 ノード内通信は使わず、2台のサーバ、4コンテナ、Leaf-Spine型のネットワークで評価している。 プロファイルには逆伝搬、データ同期、並列実行時間、通信完了待ち時間が現れ、逆伝搬と通信の重なりが可視化される。 ![[_attachments/janog55-gpu-network-load/page-015.png]] パラメータサイズを1 Billionに固定し、計算量を変えた二つのモデルを比較している。 モデルAは逆伝搬時間が通信時間より長く、モデルBは逆伝搬時間が通信時間より短い。 モデルBではGPU分散数に対して学習時間が線形に減少する一方、モデルAでは通信完了待ちの影響が残る。 ## ネットワーク性能目標 ![[_attachments/janog55-gpu-network-load/page-017.png]] 計算と通信が並列実行されるため、通信時間とGPU idle時間は同じではない。 GPU idle時間は、逆伝搬時間と通信時間の大小関係に依存する。 逆伝搬時間が通信時間を上回る条件は、次式で表される。 > 逆伝搬時間 ＞ (送信したいデータ量 / 帯域) 逆伝搬時間はアプリケーションに依存し、送信データ量は分散GPU数とパラメータサイズから推測できる。 ネットワークエンジニアは、この条件を満たすようにネットワークを構築し、性能チューニングを行う。 ## AllReduceとトラフィック量 ![[_attachments/janog55-gpu-network-load/page-019.png]] AllReduceは、各GPUが持つデータを集めて加算し、その結果を各GPUへ配布する集合通信である。 資料はRing-AllReduceを代表例として挙げ、1 Stepで1 GPUが送信するデータ量を次式で表す。 > 2(N − 1) / N × 4P ここで、Nは分散GPU数、Pはパラメータ数である。 分散GPU数とパラメータ数が分かれば、ネットワーク負荷を概算できる。 ![[_attachments/janog55-gpu-network-load/page-020.png]] パラメータ数を変えながらGPUの送信トラフィック総量を測定した結果、理論値と概ね一致した。 この結果から、分散GPU数とパラメータ数をネットワーク性能設計の初期指標にできるとまとめている。 ## Message Sizeの定義 ![[_attachments/janog55-gpu-network-load/page-021.png]] AI/ML基盤のRDMA性能試験では、主に`perf-tests`と`nccl-tests`が使われる。 どちらもMessage Sizeに対するスループットや送信時間を評価するが、Message Sizeの定義が異なる。 | ツール | 主な目的 | Message Size | |---|---|---| | `perf-tests` | 単一RDMA通信の性能試験 | 単一RDMAメッセージ | | `nccl-tests` | 集合通信の性能試験 | 単一の集合通信 | ![[_attachments/janog55-gpu-network-load/page-022.png]] `perf-tests`のMessage Sizeは、一つのRDMAメッセージ、すなわちRDMA Write FirstからRDMA Write Lastまでに転送されるデータ量である。 RDMA Write FirstのRDMA Extended Transport HeaderにはDMA Lengthが記載される。 ![[_attachments/janog55-gpu-network-load/page-023.png]] `nccl-tests`のMessage Sizeは、一つの集合通信で送信されるデータ量であり、RDMAヘッダのDMA Lengthとは異なる。 資料では、`perf-tests`のMessage Sizeと`nccl-tests`のChunk Sizeが対応すると説明している。 Chunk Sizeは分散GPU数やオプションパラメータに応じてNCCL側で自動決定される。 ![[_attachments/janog55-gpu-network-load/page-024.png]] アプリケーション側の全データは、Bucket、Chunk、MTUの順に分割されて送信される。 PyTorchの既定Bucket値は25MB、NCCLの既定Chunkは1M程度と整理される。 したがって、性能試験のMessage Sizeが、PyTorch、NCCL、ネットワークのどの段階を表すかを確認しなければならない。 ## 第一部のまとめ ![[_attachments/janog55-gpu-network-load/page-025.png]] AI/MLジョブの特性から決まるパラメータは、ネットワーク性能をどこまで向上させるべきかを議論する指標になる。 - 目標データ送達時間: 逆伝搬計算時間を一つの目安にする - 送信データ量: 分散GPU数とパラメータサイズから推測する - ネットワーク帯域: 送信データ量を目標データ送達時間で運ぶために必要な容量 - チューニング: `perf-tests`と`nccl-tests`のMessage Sizeの定義差を考慮する ## 分散計算基盤の構想 第二部では、なぜトヨタが計算機基盤を作るのかという問いから始める。 ![[_attachments/janog55-gpu-network-load/page-027.png]] 背景には「モビリティ × AI・通信」があり、交通事故ゼロに向けたAI・通信基盤の構築を掲げている。 市街地・交差点での事故防止、地方・郊外での安全で安心な移動サービス、高速道路での円滑な合流や行動予測などが例として示される。 データセンター需要、半導体、AI利用の増加で電力消費が増えるため、再生可能エネルギーが豊富な地域で計算資源を確保する構想を示す。 ![[_attachments/janog55-gpu-network-load/page-028.png]] 図では、九州の豊富な再生可能エネルギーと、北海道の風力・冷却への期待を対比し、地域の再生可能エネルギーを活用した地産地消の分散コンピューティング基盤を描いている。 太陽光や風力は発電量の制御が難しく、電力の需給バランスを取るため供給過多時には出力抑制が行われる。 この余剰電力を計算資源へ振り向けることが、分散計算基盤の動機である。 ![[_attachments/janog55-gpu-network-load/page-029.png]] 北海道ではユーラスエナジーが21の発電所を操業中であり、トヨタ、豊田通商、ユーラスエナジーで再生可能エネルギーの有効利用に関するPoCを実施している。 計画の中心は北海道稚内市である。 ## 長距離RDMAの課題 ![[_attachments/janog55-gpu-network-load/page-032.png]] 想定ユースケースは、遠隔地からの学習データ転送と拠点間GPUクラスタの構築である。 札幌〜稚内間では距離約300km、光の片道遅延約1.5msと試算し、車両・交通データを札幌側、再生可能エネルギーを稚内側へ配置する専用線相当の構成を描いている。 RDMA Writeでは、データはMTUに収まるようにWrite First、Write Middle、Write Lastへ分割される。 Write LastにはACK要求ビットが立ち、ResponderからACKが返るまで処理は完了しない。 ![[_attachments/janog55-gpu-network-load/page-034.png]] NTTの先行事例として、長距離でResponderからのACKが遅延すると性能が低下すること、RDMA WANアクセラレータで擬似ACKを生成・送信して距離による遅延の影響を軽減することを紹介している。 ![[_attachments/janog55-gpu-network-load/page-035.png]] Work RequestはInfiniBand Verbsを通じてSendまたはReceive Queueへ積まれ、HCAが処理する。 ResponderからのACK応答はCompletion Queueへキューイングされるため、キューが捌けないと新しいWork Requestを発行できない。 MicrosoftのAzure Storageの事例では、リージョン間最大100kmのVMとストレージクラスタ間でRDMAを利用し、高集積かつ長距離リンクを収容するため数GBのPFC headroom bufferが必要になると説明される。 ![[_attachments/janog55-gpu-network-load/page-036.png]] 提示される対策は、オフチップメモリにRDMA用のdeep bufferを用意すること、Queue単位ではなく全てのingress lossless queueでPFC headroom poolを共有することである。 PFC headroomは、PAUSEフレームを送信してから送信が停止するまでに到着するin-flightパケットを吸収するバッファである。 ![[_attachments/janog55-gpu-network-load/page-037.png]] headroom bufferの最適値は距離、帯域、流量によって変化する。 資料は、IEEE 802.1 DatacenterでPFCの拡張としてAutomatic calculationの標準化が進んでいると紹介する。 ## AECCと議論の論点 ![[_attachments/janog55-gpu-network-load/page-039.png]] AECC(Automotive Edge Computing Consortium)への参加目的として、コネクティッド領域の研究開発を加速するために社外知見を取り込むこと、企業間連携をリードしてコネクティッド基盤のベストプラクティスを迅速に策定することを挙げる。 2024年4月の東京デモイベントでは、トヨタから12件のデモを出展したと記載されている。 資料の最後には、次の議論を提起している。 1. 専用ネットワークの最適化で、アプリケーションの通信特性をどのように検証しているか。 2. ネットワーク設計にアプリケーション特性をどの程度取り込むか。性能最大化とコスト・要件の妥協点はどこか。 3. AIワークロード実行中のネットワーク負荷、特にマイクロバーストをどのように可視化するか。 4. 100kmを超えるデータセンター間でRDMAを利用するか。 5. 現在提案されているAI/ML基盤ネットワークアーキテクチャに、まだどのような最適化余地があるか。 ![[_attachments/janog55-gpu-network-load/page-040.png]] ## 概念・実体への接続 - [[RDMA]] — RoCEv2、RDMA Write、ACK応答、長距離RDMA、PFC headroom - [[RDMAネットワーク監視]] — アプリケーション特性とマイクロバーストを含むネットワーク可視化 - [[RoCE設計課題]] — PFC、長距離リンク、ACK遅延、headroom buffer - [[集合通信]] — AllReduce、Ring-AllReduce、Bucket、Chunk、`nccl-tests` - [[LLM分散学習]] — データ並列、計算・通信オーバーラップ、ネットワーク帯域設計 - [[データセンターネットワークトポロジ]] — Leaf-Spine構成と分散計算基盤 - [[Toyota Motor Corporation]] — 発表者の所属組織 - [[加納浩輝]] / [[奥澤智子]] — 発表者 ## 限界・不確実点 - transcriptは取得していないため、スライドにない口頭説明、質疑、デモ内容は反映していない。 - グラフの細かな測定条件や一部の軸ラベルは、スライド画像で判読できる範囲に限って記述した。 - 再生可能エネルギーの出力抑制量、光帯域の推移、先行研究の実験条件は、発表資料が引用する外部資料の要約であり、本資料自体の実験結果とは区別する必要がある。 - 資料内には`RdeseScatter`など表記揺れ・誤記とみられる表現があるが、内容の意味を変えずに原表記を保持した。