# アクセラレータ間通信の実際 ## 概要 Preferred Networks(PFN)の上野裕一郎氏が MPLS Japan 2024(2024-10-29、「GenAI/HPCネットワークのパフォーマンス計測とデバッガビリティ」セッション)で発表した資料。PFN の GPU クラスタ(NVIDIA H100 x8、400GbE x4、RoCEv2)を題材に、分散深層学習でアクセラレータ間通信が必要になる理由、それを支えるチップ間通信(NVLink)・ノード間通信(RoCEv2/InfiniBand・DCQCN)・集団通信ライブラリ(NCCL)の技術スタック、そして実際の H100 クラスタ構築で遭遇したノード内 PCIe トポロジ起因の NIC 偏り問題とインターコネクトのクレジット管理問題のトラブルシューティング事例を紹介する。 ## 主要メッセージ - **LLM の分散学習では通信パターンが複雑化している**(p.7-11): データ並列型では AllReduce のみで済むが、LLM 訓練で用いる FSDP/ZeRO(勾配の Reduce-Scatter・パラメータの AllGather)、パイプライン並列(Send/Recv)、テンソル並列(集団通信によるレイヤー単位のパラメータ分割演算)では AllReduce 以外の集団通信も高速である必要がある。 - **アクセラレータ間通信は「チップ間通信」「Accelerator, NIC 通信」「ノード間通信」の3層に分解できる**(p.14): チップ間通信は NVLink(4 GPU は直結、8 GPU は NVLink Switch 経由)、Accelerator-NIC 間は Peer Memory Direct、ノード間は RoCEv2/InfiniBand が担う。 - **RoCEv2 は InfiniBand プロトコルを UDP 上で転送する方式で、ロスレス化に DCQCN(ECN+PFC)を用いる**(p.18-19)。 - **NCCL はノード内トポロジとハードウェアを自動検出し、サイズ・プロセス数に応じて Ring/Tree などのアルゴリズムを自動選択する**(p.28)。 - **H100 クラスタ運用開始後、パイプライン並列で NCCL の NIC 選択が偏り性能が出ない問題が発生**(p.31-33): SuperMicro SYS-821GE-TNHR は NIC 8 枚搭載を前提に PCIe SW を論理的に 2 分割しており、ドキュメント上 4 個の PCIe SW が nvidia-smi 上は 8 個に見える。この結果、GPU1/GPU3 は NIC0・NIC1 のどちらからも等距離、GPU5/GPU7 は NIC2・NIC3 のどちらからも等距離となり、NCCL は常に NIC0・NIC2 を選択して偏りが生じた。ワークアラウンドとして SuperMicro から提供されたファームウェアで PCIe SW を統合適用した(GPU あたりの uplink 帯域が半減するトレードオフあり)。 - **AllGather 性能の不安定さと InfiniBand タイムアウトは、2 台のサーバをレール単位で直結する切り分け実験で再現しなくなり、原因はインターコネクトスイッチ側と判明**(p.34-35): Arista Networks から提供されたクレジット管理に関する修正コンフィグの適用で解決した。 ## 視覚的に重要な図表 **p.6 PFN の計算基盤の変遷** ![[_attachments/MPLS.Japan.2024_/page-006.png]] MN-1(2017、InfiniBand FDR)から H100 クラスタ(2024、400GbE x4・RoCEv2)まで、アクセラレータ間通信が InfiniBand から RoCEv2 へ移行してきた変遷を一覧する。 **p.11 LLM 分散学習の並列化手法と通信パターン** ![[_attachments/MPLS.Japan.2024_/page-011.png]] FSDP/ZeRO(Reduce-Scatter+AllGather)、パイプライン並列(Send/Recv)、テンソル並列(集団通信)の3手法を並置し、LLM の文脈では AllReduce 以外の集団通信も高速化が必要になることを示す。 **p.16 NVIDIA GPU のための NVLink と NVLink Switch** ![[_attachments/MPLS.Japan.2024_/page-016.png]] ノード内 GPU 数が 4 の場合は GPU 同士を直結、8 の場合は NVLink Switch を経由する接続方式の違いを図示する。 **p.19 DCQCN によるロスレスネットワーク** ![[_attachments/MPLS.Japan.2024_/page-019.png]] Ethernet がロッシーである前提から、ECN(輻輳を受信側へ通知)と PFC(キュー単位の pause)の組み合わせである DCQCN がロスレス化を実現する仕組みを整理する。 **p.24 Ring-AllReduce のアルゴリズム** ![[_attachments/MPLS.Japan.2024_/page-024.png]] プロセスをリング状に並べ、Reduce-Scatter フェーズと AllGather フェーズを経て全プロセスが総和を得る Ring アルゴリズムを図解する。1 受信・1 送信のみのためどのトポロジでも性能が出やすいと説明する。 **p.27 Ring-AllReduce の一筆書き経路(両方向)** ![[_attachments/MPLS.Japan.2024_/page-027.png]] 4 GPU x 3 サーバ構成上で Ring-AllReduce を両方向で一筆書きすると、NIC の全二重通信を活用できることを示す。Accelerator Switch(ノード内 GPU 間スイッチ)には十分な速度が要求される。 **p.32-33 PCIe SW の数がドキュメントと合わない原因** ![[_attachments/MPLS.Japan.2024_/page-032.png]] ![[_attachments/MPLS.Japan.2024_/page-033.png]] nvidia-smi で確認すると PCIe SW がドキュメント上の 4 個ではなく 8 個に見える。SuperMicro SYS-821GE-TNHR が NIC 8 枚搭載を前提に PCIe SW を論理分割しているためで、この非対称性が NCCL の NIC 自動選択の偏りを引き起こした。 **p.35 ノード内・インターコネクトの切り分けと問題解決** ![[_attachments/MPLS.Japan.2024_/page-035.png]] 2 台の GPU サーバをインターコネクトスイッチ経由(通常構成)と、レール単位で直結(切り分け用構成)で比較し、直結時に問題が再現しなくなったことからインターコネクト側の問題と特定した過程を示す。 ## 口頭説明・補足 音源・動画は取得していないため transcript なし。スライドおよび公式ページ(speakerdeck.com)、ブログ記事(tech.preferred.jp「PFNにおけるアクセラレータ間通信の実際」2024-11-07)の説明文のみを出典とする。ブログ記事は本スライドと同一著者・同一テーマの詳細版で、Peer Memory Direct のベンダーニュートラルな DMA 実装、DCQCN、Ring/Tree アルゴリズムの使い分けに加え、実装課題として PCIe Switch の論理分割による CPU 経由通信の発生とファームウェア修正、インターコネクトスイッチのファブリッククレジット管理設定による AllGather 性能安定化を報告しており、本スライドの内容と整合する。 ## 概念・実体への接続 - 発表者・組織: [[Preferred Networks]] - 集団通信ライブラリ: [[NCCL]] - 概念: [[RDMA]] / [[RoCE設計課題]] / [[集合通信]] / [[NVLink]] / [[LLM分散学習]] / [[並列化戦略]] ## 限界・不確実点 - 音声・動画・質疑応答の記録は取得していない。スライドと公式ページ・関連ブログ記事のみに基づく。 - p.33 の PCIe SW 統合ファームウェア適用後の性能改善の定量値(before/after のベンチマーク数値)はスライド上に明記されておらず、「ワークアラウンドを適用した」という記述に留まる。 - p.35 のクレジット管理修正コンフィグの技術的詳細(具体的なパラメータ値)は非開示。