2025__arXiv__RDMA Point-to-Point Communication for LLM Systems

## Memo blog記事：[Explorations of RDMA in LLM Systems](https://le.qun.ch/en/blog/2025/11/09/rdma-p2p-for-llm/) LLM システムにおける高性能ポイント・ツー・ポイント通信の実装に関する論文。NVIDIA ConnectX と AWS EFA という異なる [[RDMA]] 実装間のポータビリティ問題を解決するため、TransferEngine という新しい抽象化層を提案している。GPU クラスタ上での[[分散推論]]、[[強化学習]]の重み更新、[[Mixture-of-Experts]] ルーティングといった実用的なシステムで実証されており、実装の複雑さに関わらず高性能を実現している点が特徴。 ## Memo with LLM ### 論文情報 - **タイトル**: RDMA Point-to-Point Communication for LLM Systems - **著者**: Nandor Licker (Perplexity AI), Kevin Hu (Perplexity AI), Vladimir Zaytsev (Perplexity AI), Lequn Chen (Perplexity AI) - **所属**: Perplexity AI - **発表媒体**: arXiv - **arXiv ID**: 2510.27656 - **発表年**: 2025 年 10 月 31 日 ### 論文概要本論文は、LLM システムにおける高性能で可搬性のあるポイント・ツー・ポイント RDMA 通信の実現を目的とした TransferEngine ライブラリを提案している。既存の RDMA 実装がベンダー固有のニック（NIC）に依存しているという問題に対して、NVIDIA ConnectX と AWS Elastic Fabric Adapter（EFA）の両方で動作する統一インターフェースを提供する。提案されたシステムは、分散推論のための KvCache 転送、強化学習のための重み更新（1 兆パラメータモデルで 1.3 秒）、Mixture-of-Experts ディスパッチ/コンバイン操作を含む 3 つの本番環境システムで検証されている。 ### 詳細解説 #### 問題設定大規模言語モデルの新しいアーキテクチャパターン（分散推論、Mixture-of-Experts、非同期強化学習微調整）は、従来のコレクティブ通信では対応できない柔軟なポイント・ツー・ポイント通信パターンを必要とする。しかし現状では以下の課題がある： 1. **ベンダーロックイン**: 既存の RDMA ソリューション（DeepEP、NVSHMEM、Mooncake など）は特定の NIC（主に NVIDIA ConnectX）にのみ対応し、AWS EFA での動作が困難である。 2. **プロトコルの不統一**: NVIDIA ConnectX は Reliable Connection（RC）プロトコル（順序が保証される）を使用する一方、AWS EFA は独自の Scalable Reliable Datagram（SRD）プロトコル（順序が保証されない）を使用しており、両者の実装の差異が課題。 3. **複数 NIC の管理**: AWS p5 インスタンスでは 400 Gbps の帯域幅を実現するため、4 つの 100 Gbps EFA NIC を集約する必要があるが、これを透過的に管理するメカニズムがない。 4. **コレクティブ通信の限界**: 既存のコレクティブライブラリ（NCCL、torch.distributed）は固定メンバーシップ、同期初期化、一様なバッファサイズを要求するため、動的スケーリングや疎な通信パターンに対応できない。 **入力・出力の定義**： - **入力**: 送信側 GPU メモリ領域、受信側 GPU メモリ領域の記述（アドレス、登録キー）、転送するデータサイズ、必要に応じて即座完了通知用の 32 ビット即座値 - **出力**: データの転送完了通知、受信側での即座値カウンターのインクリメント **必要なデータ**: メモリ領域の登録情報、複数 NIC にわたるネットワークアドレスシャーディング情報、ピアグループ情報（ルーティング用） #### 提案手法 TransferEngine は以下の主要な設計原則に基づいている： **1. 共通の信頼性抽象化** ConnectX と EFA の本質的な相違（順序保証の有無）を統一するため、「信頼性があるが順序保証なし」という共通の抽象化レイヤーを設計した。これにより両方のハードウェアで動作する統一インターフェースを提供する。 **2. ImmCounter 基元** 完了通知メカニズムとして novel な ImmCounter を導入した。従来は RDMA の順序保証に依存していたが、ImmCounter は： - 送信側：転送完了後に 32 ビット即座値を送信 - 受信側：完了キューから即座値を取得し、対応するカウンターをインクリメント - ポーリング：コールバックまたはアトミックフラグを使用して即座カウンター値を監視この方式により、メッセージの順序に依存せずに転送完了を検出可能。 **3. API 設計** TransferEngine は以下の操作を公開： - **メモリ登録**: `reg_mr(ptr, len, device)` - ホストまたは GPU メモリを登録し、シリアライズ可能な MrDesc を返す - **2 つ側通信**: `submit_send()`, `submit_recvs()` - RPC スタイルの小ペイロード交換 - **1 つ側書き込み**: - `submit_single_write()` - 単一連続領域への書き込み - `submit_paged_writes()` - ページ指定による書き込み（間接インデックスと stride をサポート） - `submit_scatter()` - ピアグループへの分散書き込み - `submit_barrier()` - ピア群の同期 - **GPU-CPU 同期**: `alloc_uvm_watcher()` - GPU カーネルからの進捗検出 **4. NIC のシャーディング** 複数 NIC から並列アクセスする場合、以下のシャーディング戦略を採用：複数の Writes が $W_1, W_2, \ldots, W_n$ とし、NIC が $N_1, N_2, \ldots, N_m$ の場合、Write $W_i$ を NIC $N_{(i \mod m)}$ に割り当てる。これにより複数 NIC の帯域幅を効果的に利用可能。 **5. ハードウェア固有の最適化** **AWS EFA の場合**: - libfabric API を使用 - ゼロサイズ書き込みに対して有効な記述子を強制 - Work Request (WR) テンプレート機能でオーバーヘッド削減 **NVIDIA ConnectX-7 の場合**: - libibverbs API を使用 - ピアごとに 2 つの RC キューペアを使用（2 つ側と 1 つ側の分離） - WR チェーニングで doorbell ring 削減（最大 4 つの WR をリンク） - `IBV_ACCESS_RELAXED_ORDERING` でアウトオブオーダー PCIe トランザクション許可 #### 新規性本論文の主要な革新は以下の点で先行研究と異なる： **1. ベンダー非依存の統一抽象化** - **既存手法**: DeepEP（ConnectX のみ）、NVSHMEM（EFA で性能低下）、Mooncake、NIXL（EFA サポート不完全） - **本論文**: 両方のハードウェアで等価な性能を実現する統一インターフェースを設計 **2. 順序非依存の完了検出** - **既存手法**: RDMA の順序保証に依存 - **本論文**: ImmCounter による順序非依存の完了通知で、各プロトコルの違いを吸収 **3. 複数 NIC の透過的管理** - **既存手法**: 複数 NIC 使用時は手動でシャーディング - **本論文**: DomainGroup による自動的なシャーディングと負荷分散 **4. 本番環境での実装と検証** - **既存手法**: 主にシミュレーション・ベンチマーク - **本論文**: 分散推論、RL 学習、MoE ルーティングの 3 つの本番環境システムで実装・検証 **5. ホストプロキシ設計による可搬性** - **既存手法**: GPU-initiated RDMA（IBGDA）を使用（ConnectX のみ） - **本論文**: ホストプロキシ設計でポータビリティと性能のバランスを取得 #### 実験設定 **ハードウェア構成**: - GPU: 8×NVIDIA H200（NVLink 接続） - NIC: - ConnectX-7: 単一 400 Gbps - EFA: デュアル 200 Gbps（合計 400 Gbps） - CPU: デュアルソケット Intel Sapphire Rapids - ネットワーク: InfiniBand（ConnectX）、AWS Elastic Fabric Adapter（EFA） **評価対象システム**: 1. **KvCache 転送**: 分散推論（prefill/decode 分離） - 評価指標: レイヤーごとの転送遅延、スループット - テスト環境: EFA で本番環境テスト 2. **RL 重み更新**: 強化学習の非同期重み更新 - 評価指標: 重み更新時間、スループット - テストモデル: Kimi-K2（1T パラメータ）、DeepSeek V3（671B）、Qwen3（235B） - シャーディング: FSDP によるモデルシャーディング、256 個の訓練 GPU から 128 個の推論 GPU へ bf16→fp8 転換 3. **MoE Dispatch/Combine**: Mixture-of-Experts ルーティング - GPU スケール: 8、16、32、64 GPU - 評価対象: DeepEP（接続のみ）、pplx-kernels（NVSHMEM ベース）との比較 - ベンチマーク: DeepSeek-V3 設定 - Dispatch: 7168×fp8 トークン、56×fp32 スケーリング因子 - Combine: bf16 テンソル、同じ次元 - トークン化: 各トークンをランダムに 8 つのエキスパートに割り当て - 測定: ウォームアップ 10,000 回、ベンチマーク 10,000 回、全ランク集計 **比較ベースライン**: - DeepEP: 最高性能のオープンソース実装（ConnectX のみ） - pplx-kernels: NVSHMEM ベース（ConnectX、EFA） - NIXL v0.6.1: NVIDIA Inference Xfer Library - ハードウェアベンチマーク: ibv_write_bw（ConnectX）、fi_rma_bw（EFA） #### 実験結果 **1. ポイント・ツー・ポイント通信性能** | メッセージサイズ | EFA（スループット） | ConnectX-7（スループット） | |--|--|--| | 単一書き込み 64 KiB | 16 Gbps | 44 Gbps | | 単一書き込み 256 KiB | 54 Gbps | 116 Gbps | | 単一書き込み 1 MiB | 145 Gbps | 245 Gbps | | 単一書き込み 32 MiB | 336 Gbps | 378 Gbps | | ページ書き込み 1 KiB | 17 Gbps (2.11M op/s) | 91 Gbps (11.10M op/s) | | ページ書き込み 8 KiB | 138 Gbps (2.10M op/s) | 320 Gbps (4.89M op/s) | | ページ書き込み 64 KiB | 364 Gbps (0.69M op/s) | 370 Gbps (0.71M op/s) | **解釈**: MoE ルーティングに典型的な 256 KiB での書き込みでは、EFA が 54 Gbps、ConnectX-7 が 116 Gbps。KV キャッシュ転送に典型的な 64 KiB ページ書き込みでは両方とも帯域幅飽和。 **2. MoE Dispatch/Combine 遅延** **8 GPU（イントラノード）**: - TransferEngine Dispatch: ~2 μs 遅延増（DeepEP 比） - 理由: NIC 経由のルーティング情報交換オーバーヘッド **16 GPU（インターノード）**: - TransferEngine Dispatch: DeepEP より高速 - TransferEngine Combine: DeepEP より高速 - 理由: 効率的なバルク転送とパイプライニング **32 GPU**: - TransferEngine: DeepEP より一貫して高速 **64 GPU**: - Combine: 依然として DeepEP より高速 - Dispatch: CPU オーバーヘッド顕著（56 ピアへの enqueue オーバーヘッド） **EFA 対 ConnectX-7**: - EFA: 256 KiB 書き込みが低い帯域幅（54 Gbps vs 116 Gbps）のため、約 30% の遅延增 - ただし，デコード処理では帯域幅がボトルネックでないため，実用的な影響は限定的 **3. RL 重み更新性能** - **達成時間**: 1 兆パラメータモデル（1TB のパラメータ bf16→fp8 転換）で 1.3 秒 - **比較**: 既存フレームワークより 100 倍高速化 - **メカニズム**: - 256 個訓練 GPU から 128 個推論 GPU への直接転送 - パイプライン化実行（Host-to-Device memcpy、重み準備、RDMA 転送、全体バリア） - 全クラスタ帯域幅の利用 **4. 私有バッファサイズの影響** - **32 トークン未満**: EFA では性能低下が顕著 - **24~32 トークン**: ConnectX-7 で十分 - **理由**: ルーティング情報交換の遅延を隠蔽するため、ある程度のトークンバッファが必要 **5. Send/Receive 遅延分解** - Dispatch Send: ~0.5 μs（DeepEP より高速、単純なメモリコピー） - Combine Send: ~0.3 μs - Dispatch Receive: ~15 μs（NVLink loads により遅め） - Combine Receive: ~10 μs（より高速な累積） **6. Prefill 性能** - DeepEP: より良い性能（送信側部分和で RDMA トラフィック削減） - TransferEngine: メモリ効率が課題（デコード最適化カーネルが prefill で過度なメモリ使用） - 精度: TransferEngine は fp32 精度、DeepEP は bf16 精度低下 **主要な定量的結論**: 1. ConnectX-7 での MoE dispatch/combine は DeepEP に匹敵または超過 2. EFA での初の実用的な MoE 実装を実現（従来は存在しなかった） 3. RL 重み更新で 100 倍の高速化を達成 4. マルチプロバイダーポータビリティを実現しながら性能を維持