# fabric-lib: RDMA Point-to-Point Communication for LLM Systems > [!info] Talk metadata > - **会議:** [[MLSys2026]] Day 3 (May 20 / Wed)、Grand Ballroom 1、15:30 - 15:45 PDT > - **登壇者:** Nandor Licker\*, Kevin Hu, Vladimir Zaytsev, Lequn Chen\* (Perplexity AI)　\*Equal contribution > - **URL:** https://mlsys.org/virtual/2026/oral/3807 > - **OpenReview:** https://openreview.net/forum?id=SjVa05wEiY > - **関連リンク:** https://github.com/perplexityai/pplx-garden/ > [!abstract] 概要（論文） > 分離型推論（disaggregated inference）、MoE ルーティング、非同期強化学習ファインチューニングなどの新興 LLM システムパターンは、単純なコレクティブ通信を超えた柔軟なポイントツーポイント通信を必要とする。既存実装は特定の NIC に固定されており、推論エンジンへの統合やハードウェアプロバイダ間の可搬性を阻害している。本論文では fabric-lib を提示する。これは共通 NIC の機能を橋渡しし、統一インタフェースを公開するライブラリである。fabric-lib は片側 WRITEIMM 操作と IMMCOUNTER プリミティブを用い、順序保証に依存しない完了通知を実現し、GPU あたり複数の NIC を透過的に管理する。NVIDIA ConnectX-7 と AWS EFA の双方でピークスループット 400 Gbps を達成する。本ライブラリを 3 つの本番システムで実証する。(1) 動的スケーリングを伴う分離型推論向け KvCache 転送、(2) 1 兆パラメータモデルに対し 1.3 秒を達成する RL 重み更新、(3) ConnectX-7 上で DeepEP のデコードレイテンシを上回り、EFA 上で初の実用的実装を実現する MoE ディスパッチ／コンバイン。ポータブルなポイントツーポイント通信がコレクティブ通信を補完しつつ、ベンダロックインを回避できることを実証する。fabric-lib は https://github.com/perplexityai/pplx-garden/ でオープンソース公開されている。 ## テーゼ LLM システムの通信パターンは従来のコレクティブ中心から、分離型推論・MoE ルーティング・非同期 RL 更新といった柔軟なポイントツーポイント通信へと変化している。fabric-lib は「信頼性はあるが順序なし（reliable-but-unordered）」という RDMA トランスポートの共通部分を抽出し、IMMCOUNTER による順序非依存の完了通知を組み合わせることで、ConnectX-7 と EFA の双方で 400 Gbps のピーク帯域を達成する可搬な P2P 通信ライブラリを実現した。ベンダロックインを回避しつつ、3 つの本番ユースケースで専用実装と同等以上の性能を示す。 ## 問題設定・動機 ### コレクティブ通信の限界 LLM フレームワークは NCCL や `torch.distributed` を通じたコレクティブ通信に大きく依存している。コレクティブ通信はテンソル並列やデータ並列などの静的パターンには優れるが、以下の 4 つの制約により新興ワークロードに適さない。 1. **固定メンバシップ**: 全参加者の事前把握が必要であり、動的スケーリングを阻害する 2. **同期的初期化**: 独立した接続確立をブロックする「ワールド」の形成にグローバルな協調を要する 3. **操作順序**: 全参加者が操作列に合意する必要があり、NCCL が並行受信をサポートしていても追加的な同期が発生する 4. **形状の均一性**: ポイントツーポイント通信であっても、参加者間で転送サイズを揃える制約がある ### RDMA の多様性とベンダロックイン RDMA 仕様には Reliable Connection (RC)、Unreliable Connection (UC)、Unreliable Datagram (UD) の 3 種のトランスポートが定義される。NVIDIA ConnectX は従来の RC トランスポートを順序付き配信で用いるのに対し、AWS EFA は独自の SRD（Scalable Reliable Datagram）プロトコルを実装し、順序なしだが信頼性のある配信を行う。DeepEP は IBGDA（GPU 起動型 RDMA）を要求し ConnectX 専用、NVSHMEM は EFA 上で深刻な性能劣化を起こす。Mooncake や NIXL は EFA サポートが欠如または予備的である。結果として、クロスプロバイダで実用的な LLM 推論向けポイントツーポイント通信ライブラリは存在しなかった。 ### fabric-lib の着眼点 ConnectX RC と EFA SRD の共通項は「信頼性はあるが順序なし」のセマンティクスである。ConnectX RC は順序保証を持つが無視でき、EFA SRD は本質的に非順序である。fabric-lib はこの共通基盤上に構築され、片側 WRITEIMM 操作と新たな IMMCOUNTER プリミティブにより順序に依存しない完了通知を実現する。 ## 設計と実装 ### TransferEngine のアーキテクチャ fabric-lib の中核コンポーネントである TransferEngine は、異種 RDMA ハードウェアを単一プロトコルの下に抽象化する。設計目標と特徴は以下のとおりである。 - **最小 API**: RDMA インタフェースの複雑さを隠蔽する簡潔な API を公開する。SEND/RECV（双方向）と WRITEIMM（片側）の操作をサポートする - **複数 NIC の透過的管理**: EFA では GPU あたり 4 本の 100 Gbps NIC（または p5en では 2 本の 200 Gbps NIC）を束ねて 400 Gbps を達成する必要がある。TransferEngine はトポロジを自動検出し、NUMA ノード内の全 GPU・NIC を単一インスタンスで管理する - **ゼロコピー**: 低レイテンシ操作はゼロコピーインタフェースとハードウェア固有の最適化により達成される アーキテクチャは GPU ごとに 1 ワーカスレッドを NUMA コアにピン止めし、各ワーカが 1〜4 の DOMAIN（NIC 1 枚に対応）を管轄する。ロックフリーキューによるスレッド間通信を採用する。 ### API 設計 TransferEngine の API は以下の主要操作で構成される。 - **メモリ登録** (`reg_mr`): ホスト側バッファと GPU メモリの両方を登録し、シリアライズ可能な `MrDesc` を返す - **ポイントツーポイント転送** (`submit_send` / `submit_recvs`): SEND/RECV をラップし、RPC 的な通信を実現する - **片側書き込み** (`submit_single_write` / `submit_paged_writes`): 連続またはページ単位のデータを宛先バッファに直接書き込む。複数のゼロコピー片側 RDMA WRITE に変換され、利用可能な NIC 間でシャーディングとローテーションが行われる - **グループ操作** (`submit_scatter` / `submit_barrier`): ピアグループに対する分散書き込みと即時値のみの通知をサポートする - **UVM ウォッチャ** (`alloc_uvm_watcher`): UVM（統合仮想メモリ）ロケーションへの GPU 側の変更を GDRCopy 経由で CPU スレッドがポーリングし、GPU 進捗に応じて転送を起動するコールバック機構 ### ImmCounter プリミティブ IMMCOUNTER は fabric-lib の鍵となる新規プリミティブであり、WRITEIMM の 32 ビット即時値を活用した順序非依存の完了通知機構である。 - 送信側では転送完了後、受信側ではペイロード配信完了後にそれぞれイベントが生成される - カウンタは DOMAIN ワーカと同一 NUMA ノードに割り当てられ、GDRCopy 経由で GPU と透過的に同期可能 - コールバックまたはアトミックフラグによる通知配信をサポートする - 正当性は PCIe の順序保証に依拠する。WRITEIMM のデータペイロードは即時値より先に発行され、PCIe スイッチが同一デバイス宛の書き込み順序を保証するため、CPU が即時値を観測した時点でデータは GPU 上で可視である ### ハードウェア固有の最適化 **AWS EFA**: `libfabric` を用いて実装。EFA は RDMA 仕様から逸脱し即時値のみのゼロサイズ書き込みの有効なターゲットディスクリプタを要求するため、全転送に有効ディスクリプタを強制する。バルク転送とピアグループにはワークリクエスト（WR）テンプレーティングを採用する。 **NVIDIA ConnectX-7**: `libibverbs` を通じて実装。ピアごとに UD キューペア 1 つ（ハンドシェイク用）と RC キューペア 2 つ（SEND/RECV 用と WRITE/WRITEIMM 用の分離が必要）を確立する。WR チェイニングにより `ibv_send_wr` の `next` ポインタで最大 4 つの WR を連結し、ドアベルリング回数を削減する。`IBV_ACCESS_RELAXED_ORDERING` を有効化し、NIC-GPU 間の PCIe トランザクションの順序外実行を許可してレイテンシを低減する。 ### 実装 TransferEngine は Rust で実装されており、アロケーション・スレッディング・同期を入念に最適化している。 ## ユースケース・評価 ### ユースケース 1: KvCache 転送（分離型推論） 分離型推論（disaggregated inference）において、プリフィラノードがプリフィル処理後に KV ページと追加コンテキスト（ラストトークン隠れ状態やロジットなど）をデコーダノードに転送する。 - **動的スケーリング**: 同期初期化や固定メンバシップが不要であり、プリフィラ・デコーダの弾力的スケーリングを実現する - **レイヤ単位のパイプライン**: UVM ウォッチャを CUDA グラフ対応で使用し、各アテンション層の出力射影後に UVM カウンタをインクリメント。TransferEngine が変化を検出して `submit_paged_writes` で該当レイヤの KV ページをデコーダに転送する - **性能（Qwen3-235B、H200、TP4、2×200 Gbps EFA）**: KvCache ページサイズ 32 kB（128 トークン）、チャンクプリフィル長 16384 トークンの条件で、レイヤあたりの転送時間は 0.661〜1.611 ms。シーケンス長 4K で非分離型の TTFT 214 ms に対し分離型は 260 ms（+21%）だが、128K では 16735 ms 対 17056 ms（+1.9%）とオーバーヘッドが相対的に縮小する - Rust コールバックの UVM ウォッチャレイテンシは CUDA グラフ下で平均 6.3 μs（p99: 12.6 μs）、Python でも平均 9.8 μs と実用的である ### ユースケース 2: RL ロールアウト重み更新 非同期強化学習ファインチューニングでは、訓練ステップごとに新しい重みを推論ノードに配信する必要がある。 - **従来手法の問題**: コレクティブベースでは訓練サブグループの Rank0 に重みを集約し、各推論サブグループの Rank0 にブロードキャストするため、Rank0 の NIC がボトルネックとなる - **P2P アプローチ**: 各訓練 GPU が片側 RDMA WRITE で推論 GPU に直接送信し、クラスタ全体の NIC 帯域を活用する - **パイプライン実行**: 各パラメータテンソルの転送を 4 段階（H2D memcpy、full\_tensor() による FSDP アンシャーディング+射影融合+量子化、RDMA 転送、GLOO による全メッシュグループ間バリア）に分割し、重畳実行する - **性能**: Kimi-K2（1T パラメータ）、DeepSeek-V3（671B）、Qwen3（235B）の規模のモデルで、256 台の訓練 GPU（BF16、FSDP/PP=16/2/8、EP=32）から 128 台の推論 GPU（FP8）への重み転送が合計 1.2 秒で完了する。これは既存フレームワークが報告する 10〜100 秒に対し桁違いの高速化である - クリティカルパスは FSDP パラメータアンシャーディング（`full_tensor()`、518 ms）とランク間同期（357 ms）が支配し、RDMA 転送自体の CPU オーバーヘッドは 1144 回の WR ポストで 26 ms にとどまる ### ユースケース 3: MoE ディスパッチ／コンバイン MoE モデルのデコードにおけるトークンルーティングのため、ホストプロキシスレッドが GPU と NIC を協調させる低レイテンシカーネルを実装した。 - **設計**: ルーティングはスプリットカーネルで実装され、送信側カーネルがデータを準備、受信側カーネルがトークンを再配置する。ホストプロキシが GDRCopy でバッファ準備完了をポーリングし TransferEngine を呼び出す - **プライベートバッファ**: ルーティング情報交換のレイテンシを隠蔽するため、少数トークンを投機的にプライベートバッファにディスパッチし、ルート確定後に残りを共有バッファに散布する - **DeepEP との比較**: DeepEP は IBGDA と `mlx5` ドライバに依存し ConnectX 専用である。fabric-lib のカーネルはホストプロキシ方式であるにもかかわらず、ConnectX-7 上で DeepEP と同等以上のデコード性能を達成し、EFA 上で初の実用的 MoE 推論実装を実現した ### 定量評価 **ポイントツーポイント通信性能**: 評価環境は 8×H200（2×200 Gbps EFA）ノードと 8×H100（400 Gbps ConnectX-7）ノード。 - 単一 WRITE でピーク帯域を飽和させるには 16 MiB 以上（EFA・CX-7 とも）が必要。ページ WRITE では 32 KiB（TransferEngine）・64 KiB（NIXL）で飽和する - 256 KiB 単一 WRITE（MoE ルーティングの典型サイズ）で、TransferEngine は EFA 上 54 Gbps、CX-7 上 116 Gbps を達成する - ページ WRITE 64 KiB で EFA 364 Gbps（0.69M ops/s）、CX-7 370 Gbps（0.71M ops/s） **MoE エンドツーエンドデコード速度（DeepSeek-V3、MTP、EP=DP=64）**: | クラスタ | カーネル | batch=2 | batch=8 | batch=32 | |---|---|---|---|---| | H200 EFA | fabric-lib | 66.752 | 56.459 | 32.003 | | H200 EFA | pplx-kernels | 20.972 | 11.607 | 4.903 | | H100 CX-7 | fabric-lib | 78.420 | 67.666 | 36.066 | | H100 CX-7 | DeepEP | 73.758 | 65.785 | 36.253 | （単位: tokens/s） EFA 上では fabric-lib カーネルは pplx-kernels の 3〜6 倍のスループットを達成し、リアルタイム推論を初めて EFA 上で実用化した。ConnectX-7 上では全バッチサイズで DeepEP と同等かやや上回る。 **MoE デコードレイテンシ（マイクロベンチマーク、DeepSeek-V3/R1 設定）**: ノード間（16 ランク以上）で fabric-lib のディスパッチ・コンバインとも DeepEP を上回る。バルク転送と combine フェーズの効率的パイプライニングが寄与している。 **ホストプロキシオーバーヘッド**: EP64 での MoE all-to-all において、アプリケーション呼び出しから最初の RDMA WRITE ポストまでの CPU オーバーヘッドは p50 で 1.5 μs 未満。WRITE 全体のポスト時間（scatter）は EP64 で CX-7 上 p50 8.5 μs、EFA 上 p50 30.2 μs であり、エンドツーエンド性能への影響は限定的である。 ## 結論・オープン課題 fabric-lib は異種 RDMA ハードウェア間の共通機能を階層化することでベンダロックインの問題を解決した。順序保証なしの信頼性ある抽象をプロトコル上に重ね、複数 RDMA NIC へのサポートを EFA と ConnectX を中心に透過的に拡張した。3 つの本番システム（KvCache 転送、RL 重み更新、MoE ディスパッチ／コンバイン）で実証し、ポータブルなポイントツーポイント通信がコレクティブ通信を補完しつつクラウドネイティブ展開に適合することを示した。 **今後の課題と議論**: - **GPU 起動型通信（GDA）**: GDA はホスト CPU を迂回しレイテンシを低減するが、多くのクラウドインスタンス（AWS p5/p5e、eRDMA）ではまだ利用不可であり p5en でも予備的。現行のホストプロキシ設計は可搬性を維持しつつ現世代ハードウェアに対応するものである - **次世代 GPU（GB300 NVL72 等）**: 広域 NVLink ドメインにより MoE 通信は RDMA から NVLink に移行する可能性がある一方、KvCache 転送と RL 重み更新では RDMA 通信は依然として計算に隠蔽されるため、CPU ベースアプローチで最終性能を犠牲にしない - **追加 NIC サポート**: 現在は ConnectX と EFA をサポート。eRDMA・Broadcom・AMD 等の RC 互換 NIC へのポーティングはハードウェアチューニングのみで、TransferEngine API 上のアプリケーションコードは変更不要である