# RDMA ## 定義 RDMA(Remote Direct Memory Access)は、リモートホストのメモリへ CPU を介さず NIC が直接読み書きする通信機構である。LLM 訓練や HPC では、InfiniBand または Ethernet 上の RoCEv2 として用いられ、低レイテンシ・高帯域の GPU 間通信を支える。 ## 子概念 - [[LLM分散学習]] - [[オープンネットワーキング]] - [[ホスト内ネットワークボトルネック]] - [[ホスト輻輳制御]] - [[マルチテナントRDMA性能分離]] - [[分散合意プロトコル]] - [[GPUDirect RDMA]] ## 横断的知見 - **RoCEv2 の商用 Ethernet 大規模展開を初めて体系的に報告**: [[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]] は Microsoft が全データセンタで RoCEv2 を Layer-3 IP 上に展開した経験を報告した。DSCP ベース PFC で VLAN 制約を脱却し、PFC デッドロック・トランスポートライブロック・NIC PFC ストーム・スローレシーバーの 4 つの安全課題を発見・解決した。RDMA Pingmesh による能動レイテンシ監視を実装し、本番での 99 パーセンタイルレイテンシ 90 µs（TCP は 700 µs）を実証。この展開が DCQCN 採用の本番先行例となった。(Source: [[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]]) - **AI 訓練クラスタにおける RoCEv2 展開は輻輳制御の再設計を要求する**: [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]] は Meta が 24,000 GPU の RoCE クラスタで Llama 3 を訓練した事例を報告した。DCQCN は集合通信パターンにはそのまま適合せず、受信側駆動のトラフィック許可制御へ転換した。ルーティングも ECMP からフローレットスイッチングへ段階的に改善し、NCCL のデフォルト性能が本番で 50% 以下になる問題をネットワーク・ライブラリ協調チューニングで 2 倍以上改善した。DCQCN 提案から約 10 年で、AI ワークロード固有の要求が輻輳制御の再設計を促している。(Source: [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]) - **RoCEv2 と PFC による RDMA 展開の原点**: [[Microsoft]] と [[Mellanox]] は SIGCOMM 2015 で DCQCN を発表し、IP ルーティングされた大規模データセンターへの RDMA 展開を初めて実証した。PFC による無損失ファブリックと ECN ベースのフロー単位輻輳制御(DCQCN)の組み合わせという基本構造は、その後の Azure Storage・SAKURAONE・OpenAI MRC 等の大規模 RDMA 展開でも継承されている。スパインスイッチの PAUSE メッセージを 6 百万件→約 3000 件に削減し、ユーザートラフィックを 16 倍まで処理できることを 3 階層 Clos テストベッドで実証。(Source: [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - [[SAKURAONE]] は SONiC + RoCEv2 の open Ethernet で MLPerf Training を実行し、InfiniBand 系に近い time-to-train を示した。ただし ECN/PFC/NCCL channel striping などのクロスレイヤ調整が必要である。([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - RDMA は高性能な一方、PFC pause、head-of-line blocking、misbehaving flow など独自の障害モードを持つため、[[RDMAネットワーク監視]] が重要になる。([[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]]) - **RNIC 線速の急増はホスト**内**部を新たなボトルネックに変える**: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]] は、RNIC 線速が 25Gb/s→200Gb/s へ急増する一方、PCIe 帯域の伸びがそれに追いつかず、RNIC とホスト内エンドポイント(GPU・メモリノード)間の PCIe リンク・メモリチャネル・CPU ソケット間バス(UPI)が新たな性能ボトルネックになりつつあると報告する。これまでの本 concept の横断的知見(DCQCN・PFC・ECMP 等)はいずれもネットワーク層(スイッチ〜RNIC間)を扱うが、Hostping はさらにホスト**内**部(RNIC〜エンドポイント間)という別の層に焦点を当てる。([[ホスト内ネットワークボトルネック]])(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) - [[集合通信]] は RDMA の性能特性に強く依存する。NCCL/NCCLX のようなライブラリは、並列化次元ごとに通信パターンを使い分ける。 - [[OpenAI]] が開発した [[MRC]]（Multipath RC）は、RC トランスポートを拡張し 1 キューペアが数百パスへパケットスプレーを行う新トランスポートである。フロー衝突・インキャスト輻輳・障害収束遅延という RDMA の三大問題を一括して解き、10 万 GPU 超本番環境でトランシーバー障害やスイッチ再起動中も訓練継続を実証した。[[SRv6]] ソースルーティングおよび [[マルチプレーンClosトポロジ]] と組み合わせる「検知・回避・回復」設計は、RDMA を前提としつつもその弱点を上位レイヤで吸収する注目すべき方向性である。([[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]]) - **RDMA の本番価値は GPU/HPC だけでなくクラウドストレージの CPU 予約削減にも現れる**: [[SAKURAONE]] や OpenAI MRC は LLM/HPC の集団通信性能を中心に RDMA を扱う。一方、[[@2023__NSDI__Empowering Azure Storage with RDMA]] は [[Azure Storage]] のフロントエンド/バックエンド通信を RDMA 化し、ネットワークスタック処理の CPU コア予約を削減することを主要動機に置く。RDMA は「高速アクセラレータ間通信」の技術であると同時に、ディスアグリゲートされたクラウドストレージで CPU を顧客 VM やストレージ処理へ戻すためのコスト構造改善技術でもある。(Source: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[@2023__NSDI__Empowering Azure Storage with RDMA]]) - **クラスタ内 RDMA からリージョン内 RDMA へ広げると、性能問題はプロトコルでなく運用異種性に移る**: Azure Storage の展開は、異世代 NIC の DCQCN 実装差、異種スイッチ OS/ASIC、長距離リンクの PFC headroom、PFC と MACsec の標準解釈差、NIC firmware の head-of-line blocking などを主要課題として扱う。これは [[Hawkeye]] や [[R-Pingmesh]] が後年扱う「RDMA 性能異常はネットワークの局所故障だけでなく、制御機構・デバイス実装・運用更新の相互作用から生じる」という見方の本番先行例である。(Source: [[@2023__NSDI__Empowering Azure Storage with RDMA]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) - **RoCE の設計欠陥は学術と産業が共同で体系化する段階に入った**: [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]] は ETH Zürich・HPE・Broadcom・Google・Microsoft の共著という産学連合で RoCE の 8 つの構造的問題(PFC 過大バッファ・輻輳ツリー・Go-back-N・輻輳制御の相互不干渉性・ヘッダオーバーヘッド・スマートスタック不対応・セキュリティ・リンク信頼性)を整理し、「TCP と RoCE は 10 年以内に次世代 Ethernet に置き換わる」と予測した。DCQCN の実証([[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]])から 8 年でプロトコル自体の設計限界が IEEE の主要誌面に掲載されたことは、RoCE のライフサイクルが曲がり角を迎えていることを示す。(Source: [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]], [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - **PFC の限界は帯域増大とともに指数的に悪化する構造問題である**: Hoefler+ 2023 は、スイッチ帯域が 2 年ごとに 2 倍になる(Tomahawk 系列 2014〜2022)につれて PFC ヘッドルームバッファも比例拡大し、次世代スイッチ設計の主要阻害要因になることを定量的に示した。これは [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] が「PFC storm」の診断を課題とする背景であり、[[@2023__NSDI__Empowering Azure Storage with RDMA]] が長距離 RDMA の PFC headroom を問題視する文脈とも一致する。PFC は設計当初の「クラスタ内無損失転送」の想定を超えてリージョン間・ハイパースケール規模で使われた結果、副作用が主作用を脅かしている。(Source: [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]], [[@2023__NSDI__Empowering Azure Storage with RDMA]]) - **RoCEv2 の設計限界に対する 4 方式の応答が出揃った**: [[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]] の p.6 比較表は、RoCEv2・UE Transport・Falcon v1.1・MRC の 4 方式を 12 軸で並べ、RoCEv2 のみがロスレス前提（PFC 必須）・Go-Back-N・Out-of-Order 非対応であることを可視化した。残り 3 方式はいずれもパケットロス許容・SACK・パケット粒度マルチパスを採用する。Hoefler+ 2023 が指摘した RoCE の 8 つの構造的問題のうち、Go-back-N・PFC バッファ肥大・輻輳制御の相互不干渉性の 3 つは UE Transport/Falcon/MRC が共通的に解消しており、「次世代 Ethernet への移行」が実装レベルで具体化していることを示す。さらに SONiC/SAI が UE spec v1.0.2 に基づき LLR・CBFC・LLDP を実装中であり、オープンネットワーキングスタック上で次世代プロトコルが動き始めている。(Source: [[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - **UE 1.0 は UET の詳細設計を公式論文で初めて開示した**: [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]] は UEC 仕様書(562 ページ)の著者自身による高レベル解説であり、EV ベースのパケットスプレー・PDC のゼロ RTT 確立・NSCC+RCCC の 2 アルゴリズム組み合わせ・TSS のゼロトラストセキュリティという 4 つの核心技術を解説した。「計算 1,000 倍・帯域 100 倍」という非対称が SACK・パケットスプレー・ゼロ RTT を今後のシリコンで合理的にする根拠として明示されており、これは RDMA の次世代標準が InfiniBand から Ethernet へ移行する構造的な理由の技術的裏付けとなっている。(Source: [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) - **LLM 訓練ネットワークでは ECMP ハッシュ偏極が根本問題になる**: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] は、LLM 訓練の少数 elephant flow（各ホスト 400Gbps 瞬間飽和）が従来の多数フロー前提の ECMP を無力化することを本番データで示した。3 層 Clos では 3 段のカスケードハッシュ偏極が生じる。HPN はデュアルプレーントポロジで問題を解消した。RoCEv2 はトランスポート層をハードウェアオフロードするため、スイッチ側での動的フロービンパッキング等が困難であり、ハッシュ偏極の解決はトポロジ設計とホスト側の非重複経路計算に委ねられた。(Source: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]], [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]) - **RDMA を GPU カーネルから直接叩く「GPU起動型」利用は、NIC 側のデバイスアクセス可能な制御構造という別のハードウェア要件を課す**: [[@2025__arXiv__GPU-Initiated Networking for NCCL]] は、GPU-initiated networking(GDAKI バックエンド)には ConnectX-6 Dx 以降・BlueField DPU といった「デバイスアクセス可能な制御構造」を持つ NIC が必須であり、それ以外のハードウェアでは CPU 仲介の Proxy バックエンドにフォールバックせざるを得ないと報告する。RoCEv2/InfiniBand の一般的な RDMA 展開([[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]] 等)がホスト CPU からの RDMA 発行を前提とするのに対し、GPU-initiated networking は同じ物理層(InfiniBand・RoCE)の上に、NIC 側実装が対応しているかどうかという新しい互換性軸を追加する。(Source: [[@2025__arXiv__GPU-Initiated Networking for NCCL]]) - **RDMA は「ネットワーク越しの機構」という単一の抽象ではなく、ノード内 P2P・ノード間 GPUDirect RDMA・GPU起動型 RDMA という段階的な自律性のスペクトラムとして体系化できる**: 本 concept のこれまでの知見はもっぱらノード間ネットワーク層(RoCEv2・InfiniBand・輻輳制御)を扱ってきたが、[[@2026__CSUR__The Landscape of GPU-Centric Communication]] は GPUDirect RDMA(CUDA 5.0〜、NIC が GPU メモリの BAR リージョンを直接読み書き)をノード間通信 5 分類の 3 番目(GPU RDMA)に位置づけ、GPU-Triggered(GPUDirect Async)・Device Native(NVSHMEM IBGDA 等)という上位段階への進化経路を示す。RDMA はネットワークプロトコル(RoCEv2/InfiniBand)の選択だけでなく、「誰が NIC のメッセージ登録・トリガーを行うか」という制御主体の段階的移行としても分解できることを示す。(Source: [[@2026__CSUR__The Landscape of GPU-Centric Communication]]) - **GPUDirect RDMA はカーネル境界を越えた GPU-NIC メモリ一貫性を保証しないという、GDAKI/GIN が要求する NIC ハードウェア要件とは別のソフトウェア的限界がある**: [[@2026__CSUR__The Landscape of GPU-Centric Communication]] は、GPUDirect RDMA が一貫性をカーネル境界(ホストへ制御を戻す)でしか保証しない点を明示し、パーシステントカーネルとの併用がデータ正当性の問題を招くと指摘する。AMD ROC_SHMEM のみがカーネル内で GPU-NIC 一貫性を保証する実装を持つ。既存知見([[@2025__arXiv__GPU-Initiated Networking for NCCL]])が指摘する「NIC 側のデバイスアクセス可能な制御構造」というハードウェア要件に加え、GPUDirect RDMA 自体のメモリ一貫性モデルというソフトウェア的制約が、GPU 完全自律実行への到達を阻む二重の壁を形成する。(Source: [[@2026__CSUR__The Landscape of GPU-Centric Communication]], [[@2025__arXiv__GPU-Initiated Networking for NCCL]]) - **RDMA のプロセッサバイパスは「性能最適化」だけでなく「障害モデルの粒度」を変える構造的特性である**: 本 concept のこれまでの知見はもっぱらデータセンター内ネットワーク層(RoCEv2・輻輳制御・GPUDirect)の性能面を扱ってきたが、[[@2026__TPDS__R2aft - A Speedy and Highly Available RDMA-Based Consensus Protocol]] は RDMA のプロセッサバイパス特性を「プロセッサ障害とサーバ全体の障害を切り離せる」という可用性の観点から再解釈する。既存の合意プロトコル研究([[Dare]]・[[Sift]]・[[Mu]])はログ複製ではリモートプロセッサをバイパスするが、リーダー選出では依然としてリモートプロセッサに依存しており、RDMA の低レイテンシ性という一側面のみを利用してきた。R2aft は Single Writer Multiple Reader Region という構造的制約により、リーダー選出でも完全にプロセッサをバイパスできることを示し、「RDMA=速い」という理解に「RDMA=故障モデルを細粒度化できる」という新しい軸を加えた。(Source: [[@2026__TPDS__R2aft - A Speedy and Highly Available RDMA-Based Consensus Protocol]]) - **RDMA one-sided primitive のみで排他制御なしの合意を実現するには、処理順序の入れ替え(Write-Read-Verify)という単純だが非自明な設計が必要**: R2aft は既存の「Read-Verify-Write」の順序では、リモートプロセッサによる同期がない環境で複数サーバの操作が競合して両方成功しうることを反例(Fig. 1)で示し、書き込みを先に行う「Write-Read-Verify」への転換で解決する。これは RDMA one-sided primitive がロックやアトミック CAS のような強い同期プリミティブなしに CPU バイパスの合意ロジックを実装する際の一般的な設計パターンとなりうる。(Source: [[@2026__TPDS__R2aft - A Speedy and Highly Available RDMA-Based Consensus Protocol]]) - **RDMA Write のフラグメントは受信順序を保証する代わりにパケットスプレーによる経路分散を放棄する**: [[@2025__SpeakerDeck__AIインフラを考える]] は RoCEv2 のパケット構造(Ethernet/IP/UDP ヘッダ + IBA の BTH/RETH/Payload/ICRC)を示し、PMTU を超える RDMA Write メッセージが Write First(拡張ヘッダ RETH 付き)→Write Middle→Write Last の順にフラグメントされ、IBA 仕様(“IBA does not support selective packet retransmission nor the out-of-order reception of packets”)により後続パケットが先着することを許容しない設計であることを Wireshark キャプチャ実例とともに具体化した。これは [[Ultra Ethernet]] や MRC がパケット粒度スプレー・SACK・アウトオブオーダー配送を採用する動機を、パケットフォーマットレベルで裏付ける一次資料となる。(Source: [[@2025__SpeakerDeck__AIインフラを考える]], [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) - **RDMAのサイレントフォールバックは、大規模本番運用の障害調査だけでなく、コンテナ化された単一ノードの誤設定でも起きる実務上ありふれた落とし穴である**: 本conceptのこれまでの知見はハイパースケール本番クラスタ([[Azure Storage]]・[[SAKURAONE]]・OpenAI MRC等)での運用課題を中心に扱ってきたが、[[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]] は、DockerやKubernetesでコンテナがホストの`/dev/infiniband`にアクセスできない、あるいは`rdma-shared`イメージでGIDが不一致という単純な設定ミスだけで、NCCLがGPUDirect RDMAからTCPソケットへエラーなしにフォールバックし、スループットが数十GB/sから数Gb/sへ低下すると報告する。これは大規模障害調査のノウハウ([[Hawkeye]]・[[R-Pingmesh]]等)とは別に、個々のワークロード開発者が`lsmod | grep nvidia_peermem`・`NCCL_DEBUG=INFO`・RDMA perftestsの`--use_cuda`で日常的に自己検証すべき実務的チェックリストが必要であることを示す。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]]) - **Magnum IOはRDMAを含む複数I/O技術群を4層(Storage I/O・Network I/O・In-network compute・I/O management)に体系化する、NVIDIAのベンダー公式な分類軸を提供する**: 本conceptはRDMA単体の技術的深掘りが中心だったが、NVIDIA Magnum IOの枠組みでは GPUDirect RDMA は「Network I/O」層(NCCL・NVSHMEM・UCX・HPC-Xと並ぶ)に位置づけられ、SHARPは別の「In-network compute」層として区別される。これは [[@2026__CSUR__The Landscape of GPU-Centric Communication]] のAPI/データパス/メッセージ構築/トリガーの4軸分類とは異なる、ベンダー公式のプロダクト整理軸であり、実務者が技術選定する際の参照点になる。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]]) - **RDMA サブシステムの性能異常は、ネットワークプロトコル層(RoCEv2・輻輳制御)だけでなく、ホスト側ハードウェアの相互作用(RNIC-PCIe-CPU-メモリ-GPU)からも生じる**: 本 concept のこれまでの知見はもっぱらネットワークプロトコル層(DCQCN・PFC・輻輳制御・UE Transport)を扱ってきたが、[[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]](Collie)は、同一 RNIC でもホスト側 PCIe 仕様のわずかな差や NUMA 設定、ホスト内のループバックトラフィックといった**ネットワークの外側**の要因で PFC pause frame ストームや低スループットが発生することを、8 種類の商用 RDMA サブシステムから 18 件(新規 15 件)の性能異常として実証した。RDMA の性能・信頼性を左右する要因は、RoCEv2/PFC/輻輳制御というネットワークプロトコル設計だけでなく、RNIC とサーバハードウェアの統合(RNIC internal cache・MMU・PCIe switch・NUMA topology)にも同程度存在するという、本 concept の知見の範囲を広げる観察である。(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]) - **verbs API という「狭いウエスト」の抽象は、RNIC のブラックボックス性を回避してワークロード探索空間を体系的に構築するための足がかりになる**: Collie は RNIC の内部設計にアクセスできないという制約下で、標準 verbs ライブラリ(`ibv_reg_mr`・`ibv_create_qp`・`ibv_post_send`・`ibv_poll_cq` 等)が公開する操作の組み合わせから、ホストトポロジ・メモリ割り当て・トランスポート設定・メッセージパターンという 4 次元の探索空間を構築した。これは Ultra Ethernet や MRC がプロトコル層の再設計でハードウェアの限界を克服しようとするのとは異なるアプローチで、既存の RDMA プログラミングモデルを変えずに、そのモデルが許容する組み合わせ空間を体系的に検証することでハードウェアの弱点を洗い出す。(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]) - **性能カウンタ・診断カウンタという「非侵襲的なベンダー提供情報」だけで、事前(デプロイ前)の性能異常探索が成立する**: Collie は追加のハードウェア計装を必要とせず、商用 RNIC が標準的に提供する性能カウンタ(bits/秒等)と診断カウンタ(PCIe backpressure・NIC cache miss 等)を焼きなまし法で極値領域へ駆動するだけで異常を発見する。これは [[RDMAネットワーク監視]] が扱う本番運用中の反応的診断(Hawkeye の PFC プロベナンス解析、R-Pingmesh の能動プロービング)とは異なり、**デプロイ前**に同じ種類のカウンタ情報を使って予防的にハードウェアの弱点を洗い出す設計であり、「RDMA サブシステムのライフサイクル」に事前検証というもう一つの段階を加える。(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]) - **RNIC の「見えないマイクロアーキテクチャリソース」は、性能異常の発見(Collie)から性能分離の破壊(Husky)へと同一著者陣によって研究が発展した**: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]](NSDI '22)は第一者トラフィックの通常操作から RNIC 内部キャッシュ・PCIe backpressure に起因する性能異常を焼きなまし法で探索したが、control verb・エラー処理・atomic verb は探索空間に含めなかった。同じ Xinhao Kong・Danyang Zhuo らによる [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]](NSDI '23)は、クラウドプロバイダがテナントのアプリケーションを制御できないという前提に立ち、control verb(特に MR deregistration によるキャッシュミス)とエラー処理(RNR エラーによる処理ユニット全停止)を含めて RDMA verb の資源消費モデルを構築し、SR-IOV・HW TC・Justitia のいずれもがこれらのマイクロアーキテクチャリソースを分離できないことを実証した。2 本の論文は「RNIC はブラックボックスであり、標準インターフェース(verbs)の背後に隠れた内部リソースが性能問題の根本原因になる」という一貫した問題意識を、それぞれ「デプロイ前の異常発見」と「マルチテナント性能分離」という異なる文脈で確認している。(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]], [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]]) - **ハードウェアベースの分離機構(SR-IOV)は architectural resource は分離できてもマイクロアーキテクチャリソースは分離できない**: SR-IOV は仮想関数(VF)ごとに帯域と RC の RNR エラー処理を分離できるが、UD/UC のエラー処理・NIC キャッシュ・PCIe 帯域は分離対象に含まれない。これは、RoCE の設計課題として Hoefler+ が指摘する「セキュリティの設計上の弱さ」(マルチテナント環境での認証・暗号化が後付け、[[RoCE設計課題]] 参照)とは異なる層の問題であり、ハードウェア仮想化機構自体が想定するリソース粒度が、実際に RNIC が内部で共有するリソース粒度と一致していないことを示す。(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]]) - **「RNICはブラックボックス」という同一の問題意識から、性能異常の発見(Collie/Husky)と仕様準拠・正しさの検証(Lumina)という補完的な2方向のテスト手法が並行して生まれた**: [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]](SIGCOMM '23)は、Collie・Huskyと同様「商用RNICの内部実装は不透明」という前提に立つが、アプローチは対照的である。Collie/Huskyはfirst-party trafficの通常操作パターンを焼きなまし法/体系的探索で駆動し、RNIC内部キャッシュ・PCIe backpressure由来の**性能異常**を発見する。一方Luminaはプログラマブルスイッチによるin-network決定論的イベント注入(パケットドロップ・ECNマーク・破損)でRNICに正確な障害シナリオを与え、再送ロジック・輻輳通知・カウンタが**仕様どおりに正しく動くか**を検証する。実際、LuminaのTable 2が報告するバグ(CX6 DxのETS非work-conserving性、CX4 Lxのnoisy neighbor問題、E810/CX4 Lxのカウンタ不整合)は、いずれもverbs APIごしの通常操作だけでは発見しにくい「見えないRNIC内部状態」がトリガーになっている点でCollie/Huskyの知見と同じ根を持つ。(Source: [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]], [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]], [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]]) - **ソフトウェアネットワークスタックのテスト手法(packetdrillのシムレイヤー注入)はカーネルバイパスするRDMA NICには適用できず、in-network方式という別の解法が必要になる**: Luminaは、TCP/IPスタックの`libpcap`・TUNデバイスによるシムレイヤー注入(packetdrill)がRDMA NICのようなハードウェアオフロード型スタックには使えないと指摘し、代わりにプログラマブルスイッチを2ホスト間のイベント注入器として使うin-network方式を採る。これは、RDMAがCPUをバイパスする通信機構であるという本concept冒頭の定義(「リモートホストのメモリへCPUを介さずNICが直接読み書きする」)が、性能面の利点であると同時に、末端ホストからの直接計測・イベント注入を困難にするテスト上の制約でもあることを示す一次資料である。(Source: [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]]) - **ロッシーRoCEの再送性能に関する先行研究の楽観的評価は、より精密な計測手法によって覆されうる**: 先行研究(Shpiner et al.)はNVIDIA ConnectX-4のロッシー環境下でのgoodputを高く評価し「packet dropが存在してもソリッドな性能を提供できる」と結論づけたが、Luminaによる精密な再送遅延計測では、同NIC(CX4 Lx)の実際の再送遅延が約200µs(約100 base RTT分)に達することが判明した。これは、goodputのようなマクロな指標だけでは、NACK生成・NACK反応の内訳に隠れたマイクロビヘイビア上の欠陥(遅いスローパス)を見逃しうることを示す。(Source: [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]]) - **PFC は RoCE の性能に必須ではなく、現行 NIC 設計のアーティファクトにすぎない——2018 年時点で既に厳密に反証されていた**: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]](IRN、SIGCOMM '18)は、RoCE NIC に (1) SACK ベースの効率的ロス回復と (2) BDP-FC(帯域幅遅延積ベースのエンドツーエンドフロー制御)という 2 つの小変更を加えるだけで、PFC なしで RoCE(PFC あり)を 6〜83% 上回れることをシミュレーションで示した。追加ハードウェアオーバーヘッドは NIC リソースのわずか 3〜10%。本 concept の他の知見が集約する「PFC の副作用」(head-of-the-line blocking・輻輳伝播・デッドロック、[[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]] 等)は、2018 年時点で既に「そもそも PFC は必要か」という前提への反証を伴っていたことになる。DCQCN(2015)・RoCEv2 の商用大規模展開(2016)から 2〜3 年という早い段階で、PFC 依存からの脱却が技術的に実証されていたにもかかわらず、RoCE の主流実装は go-back-N・PFC 依存のまま 2023 年の Hoefler+([[RoCE設計課題]])まで温存された。(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]]) - **iWARP の「ロスを NIC で処理する」思想は正しかったが、TCP スタック全体をハードウェア化するという実装選択が敗因だった**: IRN は iWARP と RoCE を実機ベンチマーク(64B RDMA Write、単一 QP)で直接比較し、iWARP NIC(Chelsio T-580-CR)が RoCE NIC(Mellanox MCX416A-BCAT)の 3 倍のレイテンシ・4 分の 1 のスループットしか出ないことを実測した。しかし IRN は「TCP バイトストリーム抽象化ではなく RDMA セグメントに直接作用し、輻輳制御をロス回復から分離する」という設計により、iWARP と同じ設計思想をはるかに単純な実装で実現し、iWARP を上回る性能を達成した。RoCE が市場で勝った理由は設計思想の優劣ではなく実装の複雑さだったことを、本 concept の RoCE vs iWARP に関する先行知見に定量的な裏付けとして加える。(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]]) - **Collie/Husky が探索空間とする verbs API は、QP(Queue Pair)というソケットのリングバッファモデルとは異なるメモリモデル上に成り立つ**: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]] は、RDMA メモリモデルの中核である QP(送信キューSQ・受信キューRQ・完了キューCQ)がデータ自体を格納せず、HCA がアクセスするためのメタデータ(WQE: Work Queue Element)のみを保持する構造を解説する。これは [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]] や [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]] が探索空間として使う `ibv_create_qp`・`ibv_post_send`・`ibv_poll_cq` 等の verbs API が実際に操作するメモリ構造の基礎を裏付け、QP 単位の WQE キューイングが RNIC 内部キャッシュ資源(Collie/Husky が発見した性能異常の原因)と直結する構造を明確にする。(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]], [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]) - **RDMA 実装3種(InfiniBand・RoCE・iWARP)のうち、実運用で使われるトランスポートサービスは RC(Reliable Connected)と UD(Unreliable Datagram)にほぼ限られる**: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]] は IBA のトランスポートサービス4分類(RC/UC/RD/UD)のうち RD は実装がなく UC も使われないため無視してよいとし、RDMA READ/WRITE は RC(または RD)でのみサポートされることを示す。これは [[@2018__SIGCOMM__Revisiting Network Support for RDMA]](IRN)が RC トランスポートの Go-back-N 再送を主要な改善対象とする理由(RC が事実上唯一の信頼性転送経路である)を補強し、また [[MRC]] が RC を「1キューペアが数百パスへパケットスプレーする新トランスポート」へ拡張する設計判断(既存の RC 以外の代替パスを使わない)の背景にある実装上の制約を明確にする。(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]], [[@2018__SIGCOMM__Revisiting Network Support for RDMA]]) - **RNICが不透明な「ハードウェアのブラックボックス」であることに起因する障害系統(Collie/Husky/Lumina)とは別に、カーネル・ドライバのコードは公開されているにもかかわらず本番運用で追跡する仕組みがないという「テレメトリの欠落」に起因する障害系統がある**: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]](RDMATracer)は、[[Meta]]のAI訓練ジョブ失敗の5〜20%がNICドライバのカーネルバグに起因すると報告するが、その診断が困難なのはRNIC内部のマイクロアーキテクチャが不透明だから([[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]・[[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]]・[[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]]が扱う不透明性)ではなく、`libibverbs`がカーネルのioctlへの薄いラッパーでリトライロジックを持たないため、カーネル・ドライバコード自体は読めても本番でその実行パスを継続的に追跡する仕組みが存在しないためである。「RNICの内部が見えない」障害と「カーネルのコードは見えるが実行を追跡できない」障害は、いずれもRDMAサブシステムの不可視性という同じ問題意識に属しながら、対処法(RNIC外部からの探索/イベント注入 vs. カーネル内部への直接計装)が根本的に異なる。(Source: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) - **verbs層の薄いラッパーという設計は、RDMAの低レイテンシ性(プロセッサバイパス)の代償として障害の伝播を無防備にする**: 本conceptが強調する「RDMAはCPUをバイパスして低レイテンシを実現する」という利点([[@2026__TPDS__R2aft - A Speedy and Highly Available RDMA-Based Consensus Protocol]]が可用性の観点から論じる特性)は、RDMATracerの観察によれば裏面も持つ。`rdma-core`バンドルの`libibverbs`はパラメータ検証とioctlへの受け渡しのみを行う薄いラッパーで、リトライロジックを持たないため、カーネルのエラーは即座かつ無加工でユーザ空間(NCCL)へ伝播し、通信中断・communicator破棄・アプリケーションクラッシュへ直結する。低レイテンシのための「薄さ」が、同時に障害の吸収余地の無さでもあるというトレードオフを、RDMATracerは本番のジョブ失敗率(5〜20%)という具体的なコストで示した。(Source: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]) - **クラウドストレージのフロントエンドでは、RDMAの性能利得よりTCPの互換性と広域接続性が優先される場合がある**: LUNA論文は、2017年当時のフロントエンドが異なるデータセンター・可用性ゾーン間の通信と旧世代アプリケーションを必要としたためRDMAではなくユーザーレベルTCPを選んだ。一方、RDMAをストレージのCPU予約削減に使うAzure Storageの事例は、同じストレージ計算分離でも通信条件と運用異種性が技術選択を変えることを示す。(Source: [[@2023__USENIX ATC__Deploying User-space TCP at Cloud Scale with LUNA]], [[@2023__NSDI__Empowering Azure Storage with RDMA]]) - **Peer Memory Direct の実運用チェックリストは、カーネルモジュールのロード確認だけでなく PCIe Switch の DMA 折り返し可否という物理経路の確認も要求する**: [[@2024__SpeakerDeck__アクセラレータ間通信の実際]](PFN)は、GPUDirect RDMA(NVIDIA での実装は Peer Memory Direct、`ib_register_peer_memory_client()` で登録した Peer Memory Client が `ibv_reg_mr()` 時の memory pinning と `ibv_post_send/recv()` 時の DMA アドレス解決を担う)の障害切り分けとして、(1) `modprobe nvidia_peermem` の実行有無、(2) PCIe Switch が DMA の折り返しに対応しているか(できない場合 Root Complex まで折り返して帯域を無駄に消費するため Access Control Service を無効化する)、(3) GPU/NIC の affinity(システムのブロック図で経路を確認)という 3 点チェックリストを提示する。既存知見(AI Systems Performance Engineering 第4章)が「コンテナの `/dev/infiniband` アクセス不可・GID 不一致でサイレントに TCP へフォールバックする」という**カーネルモジュール/デバイスアクセス層**の落とし穴を扱うのに対し、本知見は同じ Peer Memory Direct の障害モードのうち**PCIe トポロジ物理層**(Switch の折り返し可否・Access Control Service)に焦点を当てており、両者は GPUDirect RDMA の障害切り分けチェックリストとして相補的である。(Source: [[@2024__SpeakerDeck__アクセラレータ間通信の実際]], [[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]]) - **RDMAの受信側カーネルモジュールがデータパケットを直接改変できないという制約は、ホスト輻輳制御方式の選択に直接影響する**: [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]](RHCC)は、[[@2023__SIGCOMM__Host Congestion Control]](hostCC、TCP向け)がホスト輻輳シグナルを受信側でECNビットへマーキングする方式を採るのに対し、RDMAでは受信側カーネルモジュールがデータパケットを直接改変できないためこの方式が展開不能であることを指摘する。RHCCは商用RNIC(Mellanox ConnectX-6 DX)が持つProgrammable Congestion Control(PCC)のプローブ機構で代替し、データパケットを一切改変せずにホスト輻輳シグナルを送信側へ伝える。verbs層の薄いラッパー([[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]]が指摘するリトライロジック非搭載)と同様に、RDMAの「カーネルバイパスによる低レイテンシ」という設計上の利点が、TCPでは自明な制御機構(受信側でのパケット改変)をRDMAでは使えなくするという副作用の一例である。(Source: [[@2023__SIGCOMM__Host Congestion Control]], [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]]) - **RDMA のコントロールパスをホスト CPU へ移す「ソフトウェア拡張性」路線が、IRN の 2018 年の反証から Flor・ZeroNIC を経て GPU ネットワーキング規模まで到達した**: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]](IRN)は SACK ベースロス回復と BDP-FC という 2 変更だけで PFC なしの RoCE が PFC ありの RoCE を上回れることを 2018 年に実証したが、当時は NIC ハードウェアの改修が前提だった。[[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]](UCCL-Tran)は同じ「go-back-N の限界」という問題意識を、既存 RDMA NIC を一切改造せず RDMA UC の `write_with_immediate` でコントロールヘッダとデータペイロードを CPU/GPU へ分離するというソフトウェアのみの手法で解決する。選択的再送により、UCCL-Tran は 1/16384 のドロップ率で約 1%、1/256 の高いドロップ率でも 6〜30%の性能低下に留め、Flor が報告する go-back-N ベースハードウェアトランスポートの 26〜76%の低下を大幅に下回る(Source: Flor[Figure 7]の数値を UCCL-Tran 論文が引用)。「NIC ハードウェアを変える」(IRN)から「NIC ハードウェアは変えずコントロールパスだけソフトウェア化する」(Flor→UCCL-Tran)へと、PFC/go-back-N 問題への解法の力点が移っている。(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]], [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]]) - **[[MRC]](OpenAI)と UCCL-Tran は同じ「RC のマルチパス化」という目標を、プログラマブル NIC 側かホスト CPU 側かという対照的な実装場所で追求しており、UCCL-Tran 論文自身が MRC を「1 年後に発表され SCR と同様の課題を抱えうる」後続研究として位置づける**: 本 concept の既存知見は MRC を「RC を数百パスへ拡張する新トランスポート」として扱ってきたが、MRC は NVIDIA ConnectX-8・Broadcom Thor Ultra のようなプログラマブル NIC 上に実装される。一方 UCCL-Tran は既存の非プログラマブル RDMA NIC(ConnectX-7・Thor-2・EFA)上で、コントロールパスをホスト CPU に完全に移すことで同じくマルチパス(256 QP・power-of-two サンプリングによる per-path RTT ベースの経路選択)を実現する。UCCL-Tran 論文の Related Work は、SCR(BlueField-3 DPA 上の受信側主導 CC)が DPA の限られた処理能力・キャッシュ容量ゆえに数百パスへスケールできない可能性を指摘し、MRC も「UCCL-Tran の 1 年後に発表され、同様の課題を抱えるかもしれない」と評する——プログラマブル NIC 上の RISC/ARM コアより汎用ホスト CPU の方が処理能力に優れるという主張である。同じ「RC マルチパス化」というゴールに対し、ハードウェア側(MRC・SCR)とホスト側(UCCL-Tran・Flor)という 2 つの異なる実装場所が並行して追求されていることは、本 concept にとって未解決の設計論争として記録に値する。(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]]) - **SRNIC が報告する QP スケーリングによる帯域低下(256→512 QP で約 23%、16k QP で約 46%)は、ML ワークロード固有の条件下では再現されない**: 本 concept の既存知見は QP コンテキストスワッピングによる性能劣化を RNIC マイクロアーキテクチャの構造的制約として扱ってきたが、UCCL-Tran は 60〜60,000 QP という広い範囲で RC が約 17%、UC はさらに小さい低下しか観測しないと報告する。UCCL-Tran はこの差の理由を、(1) ML ワークロードが MTU サイズの大きなパケット転送を行うため QP スワッピングオーバーヘッドが償却されること、(2) GPUDirect によって GPU-NIC トラフィックが PCIe ルートコンプレックスを経由せず CPU-NIC トラフィックとの PCIe 競合が生じないこと、の 2 点に帰す。SRNIC の測定対象(小メッセージの RDMA RPC ワークロード)と UCCL-Tran の測定対象(バルクデータ転送の ML collective)というワークロード特性の違いが、同じ QP スケーリング問題に対して正反対の結論を導いている。(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]]) - **InfiniBandのRDMA機構は2000年代半ば時点で既に「受信側オーバーヘッド削減」を実測しており、OSバイパス/ゼロコピーという現代RDMA文献の前提は登場当初から測定・実証されていた**: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]] §F.8は、Mellanox MHEA28-XTチャネルアダプタでの実測として、4バイトパケットの送受信オーバーヘッドがsend/receive機構で0.946/1.423µs、RDMA機構で0.910/0.323µsになることを報告し、RDMAが特に受信側オーバーヘッド(1.423µs→0.323µs、約4.4分の1)を削減することを定量的に示す。同章はMVAPICH実装によるOSバイパス(ネイティブVAPI)対非バイパス(IPoIB)の比較でも、OSバイパスがワイヤ速度近くまで実効帯域幅を引き上げることを示す。本conceptが集約する2015年以降のRoCEv2文献(DCQCN・IRN等)が前提とする「RDMAはCPUバイパスで低レイテンシを実現する」という定義は、2005年前後のInfiniBand実測データとして既に定量化されていたことになる——ただしAppendix Fの記述はInfiniBand単体のSAN実装が対象であり、Ethernet上のRoCEv2への拡張やPFC/ECNとの相互作用には触れていない。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]] §F.8) - **本conceptが集約するRoCEの構造的弱点(Go-back-N・PFC依存)は、H&P Appendix Fが2019年時点で既に指摘していたロスレスネットワークの一般的なフロー制御トレードオフの具体例である**: Appendix F §F.2は、クレジットベースのフロー制御(バッファオーバーフローを起こさずリンクレベルで送信を止める方式)がXon/Xoffより半分以下のバッファで済むという一般論を示し、§F.7ではリンクレベルのバックプレッシャフロー制御が「輻輳源に気づくのが遅すぎる」という一般的な弱点を持つと述べる。これはIRN([[@2018__SIGCOMM__Revisiting Network Support for RDMA]])やHoefler+([[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]])が指摘するPFC(RoCEの一種のリンクレベルバックプレッシャ)の構造的欠陥——head-of-line blocking・輻輳伝播——と同じ現象を、より一般的な相互結合網理論の枠組みで先取りして記述していたことになる。ロスレスネットワークにおけるリンクレベルフロー制御の限界は、RoCE固有の設計ミスというより、あらゆる相互結合網に共通する構造的トレードオフである。(Source: [[@2019__MorganKaufmann__Computer Architecture - A Quantitative Approach - Appendix F Interconnection Networks]] §F.2, §F.7, [[@2018__SIGCOMM__Revisiting Network Support for RDMA]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - **AI訓練向けRDMAの性能差は、ネットワークプロトコルだけでなくホスト内の責任境界で決まる**: [[@2025__Netdev 0x19__AI Networking - RoCEv2 and netdev]] は、ConnectX-7の同一条件でsocket networkingが単一フロー215-220Gbps、RoCEv2の`ib_send_bw`が392Gbpsに達する比較を示した。前者ではsoftirqと`skb`処理が受信側を制約し、後者ではユーザー管理キュー、ゼロコピー、順序どおりのペイロード配置、ハードウェアオフロードでデータ経路を短縮する。これはRDMAの優位性を「線速なプロトコル」とだけ捉えず、netdevの制御モデルとIB verbsのデータパス設計の組み合わせとして捉える必要を示す。(Source: [[@2025__Netdev 0x19__AI Networking - RoCEv2 and netdev]]) - **GPU訓練のRDMA性能目標は、通信時間ではなく計算と通信の重なりを基準に置く必要がある**: [[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]]は、データ並列の逆伝搬計算とAllReduce通信がBucket単位で並列実行され、逆伝搬時間が通信時間を上回れば通信の大半が隠れる一方、通信時間が長ければGPU idle時間が増えることをPyTorch Profileと二つのモデルで示す。RDMAの帯域目標はリンクの最大値だけでなく、アプリケーションの計算時間・同期データ量・分散GPU数から決めるべきである。(Source: [[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]]) - **長距離RDMAではACK遅延とPFC headroomが同時に設計変数になる**: 本資料は札幌〜稚内約300kmを想定し、光の片道遅延を約1.5msと試算する。RDMA WriteのWrite Lastに対するACKが返るまで処理が完了せず、PAUSE後のin-flightパケットを吸収するPFC headroomも距離・帯域・流量に応じて増える。Azure Storageの最大100km事例と合わせると、クラスタ内RDMAの帯域設計をそのまま拠点間へ延長できず、トランスポート遅延とバッファ設計を一体で評価する必要がある。(Source: [[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]], [[@2023__NSDI__Empowering Azure Storage with RDMA]]) - [接続スケーラビリティ] RNICの接続スケーラビリティ問題(QP数が数百を超えると性能崩壊)は、ブラックボックスの商用RNICでも「RDMA概念モデル」でオンチップデータ構造を体系的に洗い出せば定量分析できる。SRNICはヘッダ拡張とcache-free QPスケジューラでOutstanding Request Table・Reordering Buffer・WQE Cacheを完全排除し、4.4MBのオンチップメモリで10K QPを実現、Mellanox CX-5比18倍の正規化接続スケーラビリティを達成した(Source: [[@2023__NSDI__SRNIC - A Scalable Architecture for RDMA NICs]])。 - [GPUDirect RDMA] GDR初期実装(2013年)はネットワークアダプタがGPUメモリを読み取る方向でのみP2P read帯域制限を受けるという非対称性を持ち、MPIライブラリ側でのハイブリッド設計(小メッセージはGDR、大メッセージはホスト経由)が必要になった(Source: [[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]]) - [低レベル最適化] FaRMは登録メモリ量の増加によるNICページテーブルキャッシュ溢れを、起動時に物理的に連続な2GB境界のメモリ領域を確保する専用カーネルドライバPhyCoで解決し、100GB規模の登録でもリクエストレートを一定に保った(VirtualAllocでは16MB超の登録でレートが4分の1に低下)(Source: [[@2014__NSDI__FaRM- Fast Remote Memory]]) - [低レベル最適化] FaRMはスレッド対リモートマシンで単一コネクションを共有し(2×m×t個のQP)、さらにNUMAを意識したq個のスレッドでのキューペア共有によりQPデータのキャッシュ溢れを抑えた。最適なqはクラスタサイズに依存する(小規模はq小、大規模はq大が有利)(Source: [[@2014__NSDI__FaRM- Fast Remote Memory]]) - [one-sided読み出し] FaRMのRDMAベースメッセージングは16〜512バイトの典型的なリクエストサイズでTCP/IP比9〜11倍のリクエストレートを達成し、one-sided RDMA読み出しは256バイトまでのサイズでさらに2倍のレイテンシ改善を得る。ピーク負荷時のTCP/IPレイテンシはRDMAメッセージングの145倍以上である(Source: [[@2014__NSDI__FaRM- Fast Remote Memory]]) - **両側データグラムRPCが片側RDMAの代替になりうる: verbの選択がトランザクション処理システムの性能を左右する**: [[@2016__OSDI__FaSST- Fast, Scalable and Simple Distributed Transactions with Two-Sided (RDMA) Datagram RPCs]]は、既存の分散トランザクション処理システム(FaRM・DrTM等)がリモートCPUバイパスのため片側RDMA(READ/WRITE/ATOMIC)を用いるのに対し、両側の非信頼データグラム(UD)上のRPCを採用することでより高いスループット・スケーラビリティ・CPU効率を達成できることを示した。データグラムトランスポートはコネクション指向トランスポート(RC/UC)と異なり1コアあたり1QPで全リモートコアと通信できるため、大規模クラスタでのQPキャッシュ枯渇によるQP共有(CPU効率を最大5.4倍低下させる)を回避できる。またDoorbellバッチングにより複数のワークリクエストを1回のPCIeバストランザクションでNICへ通知でき、CPU起点のオーバーヘッドを削減する。InfiniBandの実運用に近い環境で50PB超・約100兆パケットの転送を計測しパケットロスをゼロ観測しており、両側非信頼トランスポートでもリンク層の信頼性(フロー制御・再送・前方誤り訂正)により実用上十分な信頼性が得られることを裏付けた。(Source: [[@2016__OSDI__FaSST- Fast, Scalable and Simple Distributed Transactions with Two-Sided (RDMA) Datagram RPCs]]) - [RDMA仮想化からのSR-IOV排除という設計選択] AlibabaのStellar(SIGCOMM 2025)は、クラウドAI向けRDMA仮想化においてSR-IOV由来のVirtual Function(VF)を完全に廃止し、PCIe Scalable Functions(SF)+virtio直接メモリマッピング(vStellar)へ置き換えることで、VF数の静的上限・PCIeスイッチLUT容量制限・RDMA/TCP間のハードウェアフロー steering干渉という3つの独立した制約を同時に解消した。オンデマンドメモリピン留め(PVDMA)により1.6TBメモリのセキュアコンテナの起動時間を最大15倍短縮し、128パスのOblivious Packet Spraying(OBS)によるRDMAマルチパスをAI/MLクラスタの本番環境に投入した初の事例だとしている。(Source: [[@2025__SIGCOMM__Alibaba Stellar - A New Generation RDMA Network for Cloud AI]]) - [RDMAトランスポートのカスタマイズ手法] SCR([[@2025__NSDI__White-Boxing RDMA with Packet-Granular Software Control]])は、スイッチのwhite-boxing(制御プレーンのソフトウェア化とデータプレーンのハードウェア温存)をRDMAトランスポートへ転用し、既存のverb/メッセージ粒度のソフトウェアオーバレイ(Justitia・Flor等)と異なりトランスポート層のパケット粒度(典型1024B)でRNIC QPスケジューラのデキュー速度を制御する。BlueField-3のDPA(Datapath Accelerator)を実行基盤とし、フロー数がスレッド数を超えても処理忠実度が劣化しないGranularity Invariance Principleを理論的に示す。(Source: [[@2025__NSDI__White-Boxing RDMA with Packet-Granular Software Control]]) - [本番運用の知見] Tencentのベアメタル AI クラウド Pegasus は、RDMA send/recv verbs がAIクラウドでほとんど使われない(GPU向け通信ライブラリはRDMA writeとwrite with immediateのみを使う傾向)という観測に基づき、RNIC上でsend/recvオフロードを省略してFPGAリソースを最大7K ALM節約し、輻輳制御やパケットスプレイングの実装に転用している(Source: [[@2026__SIGCOMM__Pegasus - A Data Center Network for Bare-Metal AI Cloud]])。 ## 未解決の問い - GPU 間 RDMA を CPU 中心の Lossy ネットワークから分離する設計は、400GbE から 800GbE へ移行したときにも、QoS・トランシーバー・運用検証の複雑性をどこまで抑えられるか。([[@2023__JANOG52__AI ML基盤の400G DCネットワークを構築した話]], [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) - AI/MLジョブの逆伝搬時間と同期データ量から算出した帯域目標は、FSDP・パイプライン並列・テンソル並列のように通信形式と頻度が異なる方式へどこまで一般化できるか。([[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]]) - DCQCN の流体モデルは固定遅延を仮定する。マルチボトルネックや 100/400 Gbps 環境でのパラメータ再チューニングはどのように行われたか。([[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]]) - RoCEv2 + open Ethernet は、どの規模・トポロジ・テナント分離条件まで InfiniBand 代替として成立するか。 - RDMA ネットワークの障害を、LLM 訓練のストラグラー・MFU 低下・ジョブ失敗へどう因果的に結びつけるか。 - RPC ワークロードで RDMA を使う場合、[[クラウドスケールRPC特性]] のレイテンシ tax と CPU tax はどう変わるか。 - [[MRC]]（Multipath RC）は RC の単一パス制約をパケット粒度のスプレーで解くが、PFC pause との相互作用はどうなるか。MRC 導入で PFC の挙動は変わるか。 - RDMA failover は TCP へ戻すための CPU 余力を必要とする。クラウド事業者が RDMA で節約した CPU を顧客 VM に再配分した後、障害時のフェイルオーバー容量をどう予約・価格付け・自動化すべきか。([[@2023__NSDI__Empowering Azure Storage with RDMA]]) - Hoefler+ 2023 が予測する「次世代 Ethernet が 10 年以内に TCP/RoCE を置き換える」は 2026 年時点で具体化が進んでいる。[[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]] は SONiC/SAI が UE spec v1.0.2 に基づき LLR・CBFC・LLDP を実装中であることを示し、OCP ESUN Base Specification 1.0 が 2026-02-09 に公開された。UE Transport 自体の設計は [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]] で初めて論文として詳細に公開された(arXiv:2508.08906、2025 年 8 月)。第 1 世代製品は「数か月以内に入手可能」と予告されている。市場シェアの定量的変化は不明。([[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]], [[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]], [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) - Go-back-N を廃止して選択的確認応答に移行する場合、アウトオブオーダー配送が可能になることで RoCE の集合通信パターン(ring-allreduce など)への影響はどの程度あるか。([[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - IRN(2018)は PFC を不要にする設計を実証し Mellanox も実装検討を表明したが、2023 年時点でも RoCE の主流実装は go-back-N・PFC 依存のままだった([[RoCE設計課題]])。技術的実証から実運用展開までの 5 年以上のギャップは何が原因か(標準化プロセス・後方互換性・エコシステムのロックイン等)。([[@2018__SIGCOMM__Revisiting Network Support for RDMA]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]]) - GPUDirect RDMA のカーネル境界一貫性制約(`cudaDeviceFlushGPUDirectRDMAWrites()` によるコールバック方式)は、CPU への依存を完全には除去できない。ROC_SHMEM のカーネル内一貫性保証と同等の仕組みを NVIDIA エコシステムが採用する予定はあるか、それとも一貫性保証はハードウェア世代交代を待つ必要があるか。([[@2026__CSUR__The Landscape of GPU-Centric Communication]]) - Collie の探索空間はホスト側(トポロジ・メモリ・トランスポート・メッセージパターン)の 4 次元に限定され、制御パス挙動やリクエスト間の inter-arrival time は考慮されていない(§8 Discussion)。ネットワーク内輻輳(パケットロスあり、複数ホップ)を含めた探索空間へ拡張した場合、[[RDMAネットワーク監視]] が扱う PFC 連鎖輻輳(Hawkeye)や光トランシーバー劣化(OptProphet)由来の異常も、同じホリスティックな事前探索の枠組みで発見できるか。([[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]) - Collie が発見する異常(RNIC internal cache miss・PCIe backpressure 由来)と、[[RDMAネットワーク監視]] が発見する異常(PFC 連鎖・光トランシーバー劣化)は根本的に異なる層のものである。両者を統合したパイプライン(デプロイ前の Collie 探索結果を、本番監視の異常検知の事前知識として利用する等)は構築可能か。([[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]) - Luminaのin-network決定論的イベント注入と、Collieのfirst-party探索(焼きなまし法)を組み合わせたハイブリッドなテスト手法は構築可能か。Luminaは現状シンプルなRDMAワークロードに焦点を当てており、Collie/Huskyが探索するような複雑なマイクロアーキテクチャ資源競合ワークロードは対象外である。([[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]], [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]) - Luminaは主にRDMA(RoCEv2)のトランスポート挙動を扱うが、同じin-network決定論的イベント注入の手法は、SRD・SOLAR・[[Ultra Ethernet]] Transportのような他のハードウェアオフロード型トランスポートの検証にも拡張可能か。([[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]]) - RDMATracerのkernel-verbs層・ドライバ層への計装(戻り値ゲート型)は、Collie/Huskyが探索するverbs API経由の性能異常やLuminaが検証する仕様準拠性とは異なる「カーネルバグ」を対象とする。3系統(性能異常発見・仕様準拠性検証・カーネルバグ診断)を統合したRNIC/カーネル共通の診断パイプラインは構築可能か。またRDMATracerが除外するクリーンアップパス由来の失敗(∼21%)は原理的に戻り値ゲートで捕捉できないが、これをカーネルパニックの前兆検知など別の計装点で埋める設計は可能か。([[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]], [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]], [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]]) - LUNAのTCP、Azure StorageのRDMA、後続のDPU協調型Solarを、広域性、互換性、CPU削減、NIC/DPU要件、障害復旧の共通軸で比較したとき、ストレージサービスのフロントエンドとバックエンドに最適な境界はどこか。 - RHCCはDCQCNとの組み合わせでのみ評価されている。TIMELY・HPCCのような他のRDMA向け輻輳制御プロトコルともPCCプローブ機構ベースのホスト輻輳シグナルを統合できるか。詳細は [[ホスト輻輳制御]] の未解決の問いを参照。([[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]]) - UCCL-Tran はカメラレディ時にテストベッドを喪失し、CX-7 の 256 QP における実測比較を過去ログ(128 QP まで)からの外挿に頼っている(Figure 15)。MRC・SCR のようなプログラマブル NIC 上のマルチパス実装とホスト CPU ベースの UCCL-Tran を、同一テストベッド・同一ワークロードで直接比較した定量評価は本 wiki が持つソースからはまだ確認できていない。プログラマブル NIC 側とホスト CPU 側のどちらが将来的な帯域増大(800 Gbps 世代)に対してよりスケールするかは未解決である。([[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]]) - UCCL-Tran は輻輳シグナルを RTT とパケットロスに限定する(既存 RDMA NIC が ECN マーク・パケットトリミング情報をソフトウェアへ渡さないため)。NIC ベンダーが CQE に ECN マーク・トリミング情報を埋め込むようになった場合、UCCL-Tran のようなホスト CPU ベースのソフトウェアトランスポートは、Ultra Ethernet Transport が持つより精緻な輻輳シグナルにどこまで近づけるか。([[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]], [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) - FaRMが将来課題とするDynamically Connected Transportによるコネクション多重化の動的解決は、その後のRDMA NIC世代でどこまで実現されたか ## 関連 - 概念: [[RDMAネットワーク監視]] / [[データセンター輻輳制御]] / [[オープンネットワーキング]] / [[集合通信]] / [[LLM分散学習]] / [[クラウドスケールRPC特性]] / [[Ultra Ethernet]] / [[GPU起動型ネットワーキング]] / [[分散合意プロトコル]] / [[マルチテナントRDMA性能分離]] / [[障害注入]] / [[RoCE設計課題]] / [[InfiniBand]] / [[eBPF]] / [[分散トランザクション]] - ソース(追加): [[@2025__OReilly__AI Systems Performance Engineering - Chapter 4 Tuning Distributed Networking Communication]] — Magnum IO 4層分類でのRDMAの位置づけ、コンテナ環境でのサイレントフォールバック実務チェックリスト - エンティティ: [[Torsten Hoefler]] / [[ETH Zürich]] / [[Hewlett Packard Enterprise]] / [[Broadcom]] / [[Microsoft]] / [[Yang Zhou]] / [[Costin Raiciu]] / [[Ion Stoica]] - ソース: [[@2024__SpeakerDeck__アクセラレータ間通信の実際]] / [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]] / [[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]] / [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]] / [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]] / [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] / [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] / [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] / [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]] / [[@2023__NSDI__Empowering Azure Storage with RDMA]] / [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]] / [[@2026__CSUR__The Landscape of GPU-Centric Communication]] / [[@2026__TPDS__R2aft - A Speedy and Highly Available RDMA-Based Consensus Protocol]] / [[@2025__SpeakerDeck__AIインフラを考える]] / [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]] / [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]] / [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]] / [[@2018__SIGCOMM__Revisiting Network Support for RDMA]] / [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]] / [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]] / [[@2023__NSDI__SRNIC - A Scalable Architecture for RDMA NICs]] / [[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]] / [[@2014__NSDI__FaRM- Fast Remote Memory]] / [[@2016__OSDI__FaSST- Fast, Scalable and Simple Distributed Transactions with Two-Sided (RDMA) Datagram RPCs]] / [[@2025__SIGCOMM__Alibaba Stellar - A New Generation RDMA Network for Cloud AI]] / [[@2025__NSDI__White-Boxing RDMA with Packet-Granular Software Control]] / [[@2026__SIGCOMM__Pegasus - A Data Center Network for Bare-Metal AI Cloud]] ## 出典 - [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]](RNIC マイクロアーキテクチャリソース(キャッシュ・処理ユニット・PCIe 帯域)を経由した性能分離違反を体系的に示し、既存の全分離ソリューションを破壊するテストスイート Husky を提案。詳細は [[マルチテナントRDMA性能分離]] を参照) - [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]](RDMA サブシステムの性能異常をデプロイ前に体系的に発見するツール。verbs 抽象からの探索空間構築、性能/診断カウンタを焼きなまし法で駆動、8 サブシステムで 15 件の新規異常を発見・ベンダー承認) - [[@2026__TPDS__R2aft - A Speedy and Highly Available RDMA-Based Consensus Protocol]](RDMA のプロセッサバイパス特性を合意プロトコルの細粒度障害モデルへ応用した事例。Write-Read-Verify による排他制御なしの合意) - [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]] - [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]] - [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] - [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] - [[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]] - [[@2023__NSDI__Empowering Azure Storage with RDMA]] - [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] - [[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]]（p.6 RoCEv2 対 UE Transport/Falcon/MRC の 12 軸比較表。SONiC/SAI が UE spec v1.0.2 に基づき LLR・CBFC・LLDP を実装中） - [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]（UE 1.0 の設計解説論文。EV ベーススプレー・NSCC+RCCC・PDC ゼロ RTT・TSS ゼロトラストを詳述） - [[@2025__arXiv__GPU-Initiated Networking for NCCL]]（GPU カーネルから直接 RDMA を発行する GDAKI バックエンドの NIC 要件を詳述） - [[@2026__CSUR__The Landscape of GPU-Centric Communication]]（ノード内外の通信をAPI/データパス/メッセージ構築/トリガーの4軸で分類し、GPUDirect RDMA→GPU-Triggered→Device Nativeという段階的GPU自律化の系譜にRDMAを位置づける) - [[@2018__SIGCOMM__Revisiting Network Support for RDMA]](IRN。PFC を不要にする改良版 RoCE NIC 設計を SACK ベースロス回復 + BDP-FC の 2 変更で実現し、PFC ありの RoCE を 6〜83% 上回ることを実証。iWARP との定量比較も含む) - [[@2023__SpeakerDeck__クラウドデータセンターネットワークのいまとこれから]](クラウド事業者実務者が RDMA の Go-Back-N 再送とロスレス前提の関係、Web Scale/AI-ML ネットワーク分離の必要性を2023年時点で整理した資料。詳細は [[RoCE設計課題]] を参照) - [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]](RDMA の DMA 拡張としての基本概念、IB/RoCE/iWARP の3実装比較、QP(SQ/RQ/CQ)+WQE のメモリモデル、One-Side/Atomic Operation を体系的に解説する基礎資料。詳細は [[InfiniBand]] を参照) - [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]](AI訓練ジョブ失敗の5〜20%を占めるNICドライバのカーネルバグをeBPFで診断するフレームワーク。`libibverbs`が薄いラッパーでリトライロジックを持たないためカーネルエラーがユーザ空間へ無加工で伝播する構造、4ヒューリスティックによる13-hook選択的計装) - [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]](既存 RDMA NIC のコントロールパスとデータパスを分離し、コントロールパスをホスト CPU 上のソフトウェアとして実行する拡張可能トランスポート層。マルチパス・受信側主導 CC(EQDS)・選択的再送を実装し ML collective で最大 4.5 倍の性能向上) - [[@2023__NSDI__SRNIC - A Scalable Architecture for RDMA NICs]](RNICオンチップメモリの体系分析と接続スケーラビリティの定量的解決) - [[@2013__ICPP__Efficient Inter-node MPI Communication using GPUDirect RDMA for InfiniBand Clusters with NVIDIA GPUs]](GPUDirect RDMAの初期性能特性とMVAPICH2向けハイブリッド設計)