RDMAネットワークモニタリングの教科書

# RDMAネットワークモニタリングの教科書本書は wiki に蓄積された 40 本超のソースと 20 近い概念ページを横断し、RDMA ネットワークそのものの可観測性を主題として体系化したものである。扱う範囲は、機構の理解から障害の分類学、計装点の設計空間、実務のカウンタと粒度、そして未解決の問題までである。姉妹編との分担を先に述べる。 LLM 学習基盤の一部としてのネットワーク設計と運用は [[LLM学習インフラ実運用の教科書]] 第 IV 部が扱う。光トランシーバー単体をどう監視するかは [[NIC光トランシーバーのモニタリング]] が扱う。本書はその中間にあたる、RDMA ネットワークを対象とした計測と診断の設計を縦に貫く。 --- ## 第 I 部　対象と語彙 ### 第 1 章　RDMA という監視対象 #### 1.1 機構の骨格 **RDMA(Remote Direct Memory Access)** は、リモートホストのメモリへ CPU を介さず NIC が直接読み書きする通信機構である。 DMA をリモートホストへ拡張した技術と位置づけられ、CPU を介さず NIC の RDMA エンジンがリモートメモリを読み書きする(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。ソケットを介す TCP/IP がカーネル経由のメモリコピーを要するのに対し、RDMA の価値はカーネルバイパス、ゼロコピー、プロトコルオフロード、ワンサイドオペレーションの 4 点にある。この 4 点はそのまま監視の制約になる。本章で機構を確認するのは、第 3 章でその制約を導くためである。メモリモデルの中核は **QP(Queue Pair)** で、送信キュー SQ と受信キュー RQ、そして完了キュー CQ から構成される。 QP はソケットのリングバッファと異なりデータ自体を格納せず、HCA がアクセスするためのメタデータである **WQE(Work Queue Element)** のみを保持する(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。アプリケーションは `ibv_reg_mr` でメモリ領域を登録し、`ibv_post_send` で WQE を投入し、`ibv_poll_cq` で完了を回収する。この標準 verbs API が、監視と探索の双方にとって唯一の共通インターフェースになる(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。操作は **ワンサイドオペレーション**(Write と Read)と **アトミックオペレーション**(Fetch and Add、Compare and Swap)に分かれる。ワンサイドオペレーションはリモート OS に検知されない(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。この一文が意味するのは、宛先ホストのソフトウェア層には通信の記録が一切残らないということである。 #### 1.2 トランスポートの 4 象限 IBA は信頼性(Reliable と Unreliable)と通信方式(Connected と Datagram)の 2 軸で RC、UC、RD、UD の 4 種を規定する。実運用で使われるのは、TCP と論理的に同等な RC と、UDP と論理的に同等な UD の 2 つである。 RD は実装が存在せず、UC も使われない(Source: [[InfiniBand]])。監視設計で効いてくるのは次の非対称性である。 RDMA READ と WRITE を含む全操作は RC でのみサポートされ、UD は SEND しかサポートしない(Source: [[InfiniBand]])。つまり RC が事実上唯一の信頼性転送経路であり、これが IRN が RC の Go-back-N 再送を主改善対象に据えた理由でもあり、MRC が RC を拡張した理由でもある(Source: [[RDMA]])。一方で、能動プロービングは RC ではなく UD を選ぶ。理由は第 9 章で扱う。 #### 1.3 InfiniBand と RoCEv2 の分岐 InfiniBand は RDMA のために設計された専用プロトコルで、専用 HCA と専用スイッチを要する。 RoCE は標準 Ethernet 上で動くがロスレス Ethernet を必要とする。 iWARP は TCP/IP ベースでロスレスを要さないが性能で劣り、実測では iWARP NIC が RoCE NIC の 3 倍のレイテンシと 4 分の 1 のスループットを示した(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]], [[@2018__SIGCOMM__Revisiting Network Support for RDMA]])。両者の差で監視に直結するものを表にする。 | 論点 | InfiniBand | RoCEv2 | |---|---|---| | 管理主体 | サブネットマネージャが LFT を作成し、Active は常に 1 台 | 相当する機構の記載なし | | フロー制御 | リンク層のクレジットベース | PFC(Ethernet L2) | | 優先度分離 | Virtual Lane 最大 16 本と Service Level 16 段階 | DSCP または PCP による 8 キュー | | ヘッダ | ローカルルーティングで 20 バイト | 66 バイト(L2 22 + IP 20 + UDP 8 + BTH 12 + ICRC 4) | | 最大パケットレート | 3.5 Gpps | 1.4 Gpps | | 経路 | Adaptive Routing | ECMP ハッシュ | ヘッダサイズの差は監視の話ではないが、8 バイトメッセージではパケットのほぼ 90% がヘッダになるという事実が、後述する小メッセージ主体の集団通信の挙動を理解する下地になる(Source: [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]])。経路の違いは箇所特定に直接効く。 ECMP はプローブがどの物理経路を通るか厳密には分からないため、後述するトモグラフィ的投票で統計的に均す必要がある。 IB の Adaptive Routing 下では経路が固定されず、経路集約に基づく箇所特定そのものが崩れる(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])。 > [!note] クレジットベースと PFC の因果は仮説段階にある > [[InfiniBand]] は「IBA 独自のクレジットベースフロー制御や VL の仕組みが RoCEv2 には存在せず、この欠如が RoCEv2 が PFC を必要とする直接の理由になっているか」を未解決の問いとして残している。両者が別の機構を採ることは確定しているが、因果として断定する記述はソースにない。 ### 第 2 章　lossless Ethernet の機構 #### 2.1 三層の分業ロスレス Ethernet は、輻輳によるバッファ溢れを防ぐバッファ管理技術の集合である。リンクダウンや伝送エラーは対象外で、そちらは BER と FEC の層が担う(Source: [[@2024__SpeakerDeck__GPUネットワーク設計・運用基礎勉強会 Lossless Ethernet - PFC-ECN編]])。機構は 3 つの層に分かれ、それぞれ別のプロトコル階層に住む。 - **PFC(Priority-based Flow Control)**:Ethernet の L2 で動き、隣接ノード間のホップバイホップ制御としてキュー単位に送信を停止させる。 - **ECN(Explicit Congestion Notification)**:IP と UDP の L3 で動き、輻輳したスイッチがパケットに印を付ける。 - **CNP(Congestion Notification Packet)**:InfiniBand BTH の L4 で動き、受信側が送信元へ輻輳を通知する。動作は 4 段である(Source: [[@2024__SpeakerDeck__GPUネットワーク設計・運用基礎勉強会 Lossless Ethernet - PFC-ECN編]])。送信側が IP ヘッダの ECN ビットに ECT(0b10)を立て、輻輳したスイッチが CE(0b11)へ書き換え、受信側が CE を検知し、Opcode 129 の CNP を送信元へ返す。役割分担は明快で、ECN と CNP による **DCQCN** が主たる防御層であり、PFC は瞬間的な最終防波堤である。 PFC がポートとキューの単位で送信を完全停止する以上、輻輳解消まで PAUSE が続けば head-of-line blocking でスループットが落ちる(Source: [[@2024__SpeakerDeck__GPUネットワーク設計・運用基礎勉強会 Lossless Ethernet - PFC-ECN編]])。 #### 2.2 設定値のデファクト実務で最初に揃えるべき値は決まっている。 | 項目 | 値 | 備考 | |---|---|---| | RoCEv2 のトラフィッククラス | DSCP 26、TC 3 | NVIDIA 推奨かつ Broadcom NIC の既定値 | | CNP のトラフィッククラス | DSCP 48、TC 6 | 最高優先度、Strict スケジューリング | | 帯域配分 | TC 3 に DWRR 95%、TC 1 に 5% | TC 6 は絶対優先 | | MTU | 9000 バイト | HPC AI ワークロードでのチューニング例 | パケットを PCP で識別するか DSCP で識別するかは Trust Mode の設定で決まり、送信側と受信側で独立に設定が要る(Source: [[@2024__SpeakerDeck__GPUネットワーク設計・運用基礎勉強会 Lossless Ethernet - PFC-ECN編]])。明示しないと機器の既定挙動に依存する。ホスト側の具体的な手順は次のとおりである(Source: [[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]])。 ``` # インボックスドライバから OFED ドライバへ移行したうえで cma_roce_mode # RoCEv2 モードの確認 mlnx_qos --pfc 0,0,0,1,0,0,0,0 --trust dscp # PFC をキュー 3 に限定 ip link set dev <if> mtu 9000 # MTU を 9000 バイトに設定 ``` スイッチ側は Arista EOS の例で 3 点が必要になる(Source: [[@2024__SpeakerDeck__GPUネットワーク設計・運用基礎勉強会 Lossless Ethernet - PFC-ECN編]])。 ``` priority-flow-control priority 3 no-drop tx-queue 3 bandwidth percent 95 random-detect ecn platform trident mmu queue profile # Headroom 再配分 ``` 第 3 の項目を落とすと PFC が継続動作して性能が落ちる。この設定例は StrataXGS を前提とし、DNX では異なる旨がソース側に明記されている。 #### 2.3 Headroom という設計変数 **Headroom** は、PFC 発動時に伝送路上を飛んでいるパケットを受け切るための安全領域である。ケーブル長と MTU から算出する必要があり、IEEE 802.1Q-2012 の計算式に基づく(Source: [[@2024__SpeakerDeck__GPUネットワーク設計・運用基礎勉強会 Lossless Ethernet - PFC-ECN編]])。失敗の仕方が両側にあることが厄介である。 XOFF 閾値が高すぎて Headroom が不足するとロスレスでなくなり、低すぎると不要な送信停止とバッファ浪費が生じる。必要量は `BW×RTT + MTU` 以上になる(Source: [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]])。スイッチ帯域が 2 年ごとに倍増するとヘッドルームも比例して拡大し、転送用バッファを圧迫する。 DCQCN の論文は Arista 7050QX32(12 MB、32 ポート)で 1500 バイト MTU のとき in-flight 分が 22.4 KB/ポート/優先度、$t_{PFC}$ が 24.47 KB と算出している(Source: [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]])。現場では距離が効く。同一データセンタールーム内でケーブル長 50m 未満なら既定値で問題ないが、300m 超が混在すると回線帯域と正確な線路長、そしてスイッチ ASIC 固有のパラメータからの計算が必要になる(Source: [[RoCE設計課題]])。 Shallow Buffer と Deep Buffer が混在する経路では、区間ごとに適切なプロファイルが異なる。 #### 2.4 輻輳制御アルゴリズムの系譜主要な 4 つを、監視の観点で並べる。 | アルゴリズム | シグナル | 計装点 | 監視への含意 | |---|---|---|---| | DCQCN(2015) | ECN 1 ビット | スイッチの RED/ECN | 標準機能のみで動く。PAUSE 数とキュー長で評価する | | TIMELY(2015) | RTT | NIC ハードウェアタイムスタンプ | 計測精度が要件になる。RTT ノイズ平均 50µs 超で劣化 | | HPCC(2019) | INT のキュー長と送信バイト数 | スイッチ ASIC の INT | パラメータが 3 個に減る。ヘッダに 8 バイト/ホップ | | IRN(2018) | 選択的確認応答 | NIC のみ(スイッチ変更不要) | PFC 自体を不要にする方向 | DCQCN は送信側 RP、スイッチ CP、受信側 NP の三者モデルで動き、スイッチには標準の RED と ECN 以外の追加機能を求めない(Source: [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]])。本番 3 階層 Clos での効果は、スパインの PAUSE を 6 百万件超から約 3000 件へ落とし、ユーザートラフィックを 16 倍まで処理できるというものだった。 TIMELY はスイッチからのフィードバックを一切使わず、RTT の絶対値ではなく勾配を使う(Source: [[@2015__SIGCOMM__TIMELY - RTT-based Congestion Control for the Datacenter]])。 99 パーセンタイル尾部レイテンシは PFC 比で 9 倍、最適化カーネル DCTCP 比で 13 倍低い。ただしこれは NIC のハードウェアタイムスタンプと NIC ベースの即時 ACK 生成を前提とする。 HPCC は本番の PFC 観測から出発する。 Alibaba の本番では約 10% の PFC イベントが 3 ホップ伝播し、10% 超の PFC ポーズがデータセンター全体容量の 3% 超を抑制し、最悪ケースで 25% の容量損失が生じていた(Source: [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]])。 DCQCN が 15 個のノブを持つのに対し HPCC のパラメータは 3 個で、50% 負荷時の 95 パーセンタイルキュー長を 1.1 MB から 19.7 KB へ落とす。 IRN は問いの立て方が異なる。「PFC は Ethernet 上で RDMA をサポートするために根本的に必要なのか」を問い、NIC への 2 つの変更だけで PFC なしの RoCE が PFC ありの RoCE を 6〜83% 上回ることを示した(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]])。追加ハードウェアオーバーヘッドは NIC リソースの 3〜10% である。 > [!important] 「PFC を切ると壊れる」は現行 NIC の実装に由来する > PFC 無効化がパケット損失を招いて性能が壊滅するのは、現行 RoCE NIC の go-back-N 設計に起因するのであって、輻輳制御全体の宿命ではない。同じ「PFC を切る」操作が、ロス回復方式によって 1.5〜3 倍の悪化から改善まで反転する(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]], [[データセンター輻輳制御]])。 ### 第 3 章　監視を難しくする構造前 2 章で確認した機構から、RDMA 固有の観測困難性が導かれる。 7 点を挙げる。 **1. カーネルバイパスが観測点そのものを消す。** TCP/IP スタック向けの `libpcap` や TUN デバイスによるシムレイヤー注入は、ハードウェアオフロード型スタックには使えない(Source: [[RDMA]])。 Lumina がプログラマブルスイッチをイベント注入器に使う設計を選んだのは、末端ホストに刺す場所がないからである。 **2. ワンサイドオペレーションは受信側 OS に記録を残さない。** 第 1 章で見たとおり、Write と Read はリモート OS に検知されない。 **3. RNIC がブラックボックスである。** RNIC 内部キャッシュ、MMU、PCIe スイッチ、NUMA トポロジといったマイクロアーキテクチャ資源が性能問題の根本原因になるが、ベンダーカウンタ以外に窺う手段がない(Source: [[RDMA]], [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 **4. カウンタ自体が壊れうる。** Lumina は Intel E810 の `cnpSent` が CNP を生成しても増えず、NVIDIA CX4 Lx の `implied_nak_seq_err` が Read 応答の順序異常と再送があっても増えないことを発見した(Source: [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]])。カウンタベースの監視は、カウンタの正しさを独立に検証する層と併用しない限り誤った像を与える。 **5. verbs 層が薄すぎて障害を吸収も記録もしない。** `libibverbs` はパラメータ検証とカーネル ioctl への受け渡しのみを行い、リトライロジックを持たない(Source: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]])。カーネルのエラーが無加工で NCCL へ伝播し、communicator 破棄とアプリケーションクラッシュへ直結する。 Meta では AI 訓練ジョブ失敗の 5〜20% が NIC ドライバのカーネルバグに起因していた。 **6. 失敗がエラーでなく静かな性能低下として現れる。** コンテナがホストの `/dev/infiniband` に届かない、あるいは GID が一致しないという設定ミスだけで、NCCL が GPUDirect RDMA から TCP ソケットへエラーなしにフォールバックし、スループットが数十 GB/s から数 Gb/s へ落ちる(Source: [[RDMA]])。同様に、goodput のようなマクロ指標は約 200µs の再送スローパスを隠す。 **7. 責任境界が観測を制約する。** 公開 AI 訓練サービスでは事業者が利用者のコードにアクセスできないため、監視は非侵入でなければならない(Source: [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]])。マルチテナントではテナントがジョブ構成すら共有しない(Source: [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]])。この 7 点のうち、1 から 4 はハードウェアの不透明性に起因し、5 と 6 はソフトウェアスタックの構造に起因し、7 は組織的な制約に起因する。対処法が層ごとに異なるのは、不可視性の出どころが違うからである。 --- ## 第 II 部　何が壊れるのか ### 第 4 章　障害の実態 #### 4.1 何が原因になっているか監視の設計は、実際に何が壊れているかの分布から始める。 Facebook のデータセンター内ネットワーク 7 年分と WAN 18 か月分の記録では、サービスに影響する事象の根本原因は次のように分布した(Source: [[@2018__IMC__A Large Scale Study of Data Center Network Reliability]])。 | 根本原因 | 割合 | |---|---| | Undetermined | 29% | | Maintenance | 17% | | Hardware | 13% | | Misconfiguration | 13% | | Bug | 12% | | Accidents | 11% | | Capacity | 5% | ハードウェア障害は 13% にすぎず、保守と設定ミスとバグと事故の合計がそれを大きく上回る。そして 29% は原因が特定できないまま終わっている。 MTTR は中央値 13 時間、90 パーセンタイル 60 時間である。この分布から読める設計要件は 2 つある。第 1 に、監視対象を部品故障に絞ると 13% しか見ないことになる。第 2 に、原因を特定できないまま復旧する経路を最初から用意しておく必要がある。 AI クラスタに限定した内訳も同じ傾向を示す。 Tencent の Astral では、ホスト環境と設定が 32%、NIC エラー 15%、スイッチ設定 14%、ユーザコード 14% だった(Source: [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]])。ネットワーク機器だけを見ていると半分以上を取り逃す。 #### 4.2 どのくらいの頻度で壊れるか RDMA クラスタ固有の頻度は Alibaba HPN の報告が具体的である(Source: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]])。 - NIC と ToR 間リンクの障害率:月あたり 0.057% - ToR の致命エラー率:月あたり 0.051% - リンクフラップ:1 日あたり 5,000 件から 60,000 件 - 単一の LLM 訓練ジョブのクラッシュ:月に 1 回から 2 回リンクフラップが 1 日に数万件という数字は、フラップを例外として扱う設計が成り立たないことを意味する。 OpenAI らの報告でも T0 と T1 の間のリンクフラップは 250 分間に毎分 2 件から 10 件、ピークで約 13 件観測されている(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]])。 #### 4.3 どう現れるか障害の顕在形は 4 つに分類される。 Astral の本番統計では fail-stop 66%、fail-hang 17%、fail-slow 13%、fail-on-start 4% だった(Source: [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]])。 fail-slow と fail-hang は合計 30% を占め、いずれも明示的な診断ログを出さない。 Astral が MTTLF を fail-stop で最大 12 倍、fail-hang で最大 25 倍、fail-slow で約 5 倍短縮したという数値のばらつきは、この 3 つが難易度の異なる問題であることを反映している。 Pulse はこれを 2 軸に整理する(Source: [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]])。顕在形が fail-stop か fail-slow か、そして起因が computation か communication か。 | | computation 起因 | communication 起因 | |---|---|---| | fail-stop | ECC エラー、CUDA エラー | NIC ダウン、スイッチ再起動、AOC/NVLink エラー | | fail-slow | GPU スロットリング、CPU 競合 | PCIe ダウングレードと競合、ネットワーク輻輳、NIC と GPU のクロス NUMA バインド | この 2×2 が本書全体の診断対象の座標になる。 ### 第 5 章　輻輳と PFC の病理 #### 5.1 PFC が生む 4 つの症状 PFC は無損失を保つために上流ポートへ pause フレームを送り送信を止めさせる。この単純な機構が 4 段階の病理を生む。 - **head-of-line blocking**:PFC は 3 ビットのトラフィッククラス単位で全フローを一律停止するため、輻輳と無関係なフローまで止まる(Source: [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]])。 - **victim flow**:輻輳パスを共有しないフローが劣化する。DCQCN の論文では 10 Gbps のフローが 4.5 Gbps へ落ち、経路を共有しないスパインスイッチで 6 百万件超の PAUSE が観測された(Source: [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]])。 - **輻輳ツリーと PFC ストーム**:下流の輻輳が上流バッファを埋め、輻輳ツリーが逆方向に成長する。連鎖が広がると PFC ストームになる。 - **PFC デッドロック**:待機依存がループを閉じると解けなくなる。デッドロックは理論上の懸念ではない。 Microsoft は Clos の up-down ルーティングがデッドロックしないという通説にもかかわらず、Ethernet のパケットフラッディングとの相互作用で実際に発生させた(Source: [[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]])。 ARP エントリはあるが MAC アドレステーブルにエントリがない不完全 ARP 状態でパケットが届くと、スイッチが全ポートへフラッディングし、損失なしクラスのパケットが循環バッファ依存を形成する。教訓は「ブロードキャストとマルチキャストを損失なしクラスに入れない」ことだった。 #### 5.2 単一 NIC がネットワーク全体を止める同じ報告には、NIC 受信パイプラインのバグでパイプラインが停止し受信バッファが満杯になると NIC が常時 pause フレームを送出する事例がある(Source: [[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]])。単一 NIC の障害が ToR から Leaf、Spine、そして全 ToR へ連鎖してネットワーク全体を麻痺させた。対処は二重のウォッチドッグである。 NIC 側は 100 ms 以上の受信パイプライン停止を検出して pause フレーム生成を無効化し、ToR スイッチ側は該当ポートの損失なしモードを 200 ms 間無効化する。 Meta も同様に 200 ms を超える PFC pause をデッドロックや不良 NIC の指標として検知するウォッチドッグを運用している(Source: [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]])。関連して、MTT キャッシュミスが頻発して受信パイプラインが遅延し、NIC が不必要な pause フレームを生成する「スローレシーバー症状」も報告されている。 MTT エントリ数 2K では 4 KB ページで 8 MB しかカバーできず、緩和はページサイズを 2 MB へ上げることだった。 #### 5.3 輻輳がコアへ移動する PFC の導入は輻輳を防ぐだけでなく、輻輳の発生場所を動かす。 Meta の本番 RDMA AI データセンターの測定は、輻輳箇所が TCP/IP のエッジ(ToR から host)から RDMA のネットワークコア(ToR から spine)へ一段シフトしたことを実測で示した(Source: [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]])。数値は明快である。あるゾーンで ToR 層は平均 10 万 pause/sec 超を spine へ送っていた一方、host から ToR の層は平均 1,000 pause/sec 未満で、2 桁の差があった。機序は、複数の送信ホストが同時に単一の受信ホストへ送るインキャスト的バーストが宛先 ToR でバッファを積み上げ、PFC が最終ホップでのロスは防ぐものの宛先 ToR から spine へ大量の pause frame を発生させるというものである。これは Google と Facebook が TCP/IP について報告してきた「最終ホップが最も輻輳する」という定説と逆になる。この知見は計装点の設計に直結する。 ToR スイッチは host から ToR、ToR から spine、spine から ToR、ToR から host の 4 ホップすべてを見渡せる戦略的観測点になる。 #### 5.4 平均レートは不均衡を隠す同じ測定は、指標の選び方が時間粒度と独立した設計軸であることも示した(Source: [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]])。スパイン層の 8 本のインターフェースのうち 4 本が平均 1.8 Kpause/sec 超、別の 4 本が 100 pause/sec 未満という 2 桁の不均衡を示していた。ところが同じリンクの分単位平均トラフィックレートは、最も高利用なリンクでも最低利用リンクの 12% 増にとどまる。つまり平均レートで見ればほぼ均衡しているように見える負荷が、PFC 一時停止カウンタで見ると 2 桁違う。バーストの実測値も押さえておく。 1 ランあたりのバースト数は中央値 3、90 パーセンタイル 6。バースト長の中央値はゾーンによって 4.8 ms と 9.6 ms、90 パーセンタイルはゾーン B で 30 ms 超だった。 1 ホストの 8 個の RNIC にまたがる同期バーストは、ゾーン A で 13%、ゾーン B で 53% のホストに見られた。 > [!important] 既に展開済みの粗粒度カウンタが未使用の資源になっている > PFC 一時停止カウンタはほぼ全ての RDMA ネットワークに既に展開されている。分単位という粗い粒度でも、平均トラフィックレートでは見えないバースト性と負荷不均衡の代理指標として機能する。新しい計装を足さずに読み方を変えるだけで得られる可視化がある(Source: [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]])。 ### 第 6 章　破損、物理劣化、ホスト内、NIC 内部輻輳は RDMA 障害の一部にすぎない。本章は輻輳系の監視が原理的に見落とす 4 つの障害クラスを扱う。 #### 6.1 破損は輻輳と質的に異なる 15 の本番データセンター、35 万本のスイッチ間光リンク、7 か月の計測から、パケット破損が輻輳と同水準の規模を持ちながら性質がまったく異なることが示された(Source: [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]])。 | 性質 | 破損 | 輻輳 | |---|---|---| | 損失率 10⁻³ 以上のリンク割合 | 12.67% | 0.22% | | 利用率との平均ピアソン相関 | 0.19 | 0.62 | | 時間変動 | ほぼ一定 | 3 桁のオーダーで短時間変動 | | 空間局所性 | 弱い | 強い | | 双方向で発生する割合 | 8.2% | 72.7% | 決定的なのは利用率との無相関である。破損は送信レートを下げても消えない。つまり輻輳制御的な対処が原理的に効かない。このことは監視系の設計に強い含意を持つ。 PFC 連鎖を解析する系も、通信律速を検知する系も、いずれも「送信レート低下や経路変更で緩和できる」という想定の上に立っている。破損に対しては、リンクを物理的に無効化して技術者が修理するしかない。破損の根本原因は光パワーのパターンで判別できる。送信と受信の光パワー水準の高低(H と L)の組み合わせから 5 種を切り分ける診断表が確立された(Source: [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]])。 | 根本原因 | 症状(TxPower→RxPower / RxPower←TxPower) | 貢献割合 | |---|---|---| | コネクタ汚染 | H→H / L←H(片方向のみ RxPower 低下) | 17〜57% | | ケーブルの折れ曲がりや損傷 | H→L / L←H(両側 RxPower 低下、TxPower 安定) | 14〜48% | | 送信機の劣化 | \*→\* / L←L(両側とも低下または低い) | 1% 未満 | | トランシーバ不良や緩み | H→H / H←H(単一リンクのみ) | 6〜45% | | 共有コンポーネント故障 | H→H / H←H(同一スイッチ上の複数リンクで同時) | 10〜26% | 貢献割合が幅を持つのは、技術者が複数のアクションをログなしに実施するため下限と上限を仮定計算したことによる。なおこの研究はスイッチ間光リンクのみを対象とし、サーバーと ToR の間のリンクは「電気信号かつ短距離でケーブル交換で済む」として明示的に除外している。 #### 6.2 光層の劣化は予測できる破損への対処が「検知して直す」なら、その手前に「壊れる前に気づく」段がある。 Huawei の実運用 LLM 訓練クラスタ 2 系統(10,804 台 20 日間と 3,394 台 30 日間)で、DDM メトリクスから光トランシーバー故障を予測 F1 0.884、分類 F1 0.855 で当て、平均 1.11 日前にアラームを上げることが示された(Source: [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]])。より大規模な母集団での特性は別の研究が押さえている(Source: [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]])。 350 万台超、131 リージョン、15 か月の追跡で、ハード故障(5 分窓の平均エラーレートが 5 pps 超)の AFR は 0.1341% だった。これは DIMM の 0.22% と同程度で HDD の 1.7〜8.6% より有意に低い。一方でソフト故障はハード故障の最大 12.22 倍発生する。何が予兆になるかの lift 分析は実務的に有用である。 | パターン | lift | |---|---| | エラーレートが高値 | 9.13× | | 温度の分散が高い | 7.29× | | バイアス電流の分散が高い | 6.71× | | Rx パワーの分散が高い | 6.53× | | バイアス電流が高値 | 6.24× | | パケットロス | 1.27〜1.28× | 分散が高値を上回る項目があること、そしてパケットロスがほぼ無相関であることの 2 点が重要である。上位層のロス監視は光トランシーバー故障の代替指標にならない。予測モデルの精度は 72.8〜95.7% だが再現率は 21.2〜50.0% にとどまり、モニタリング情報だけでは故障の一部しか予測できない。 #### 6.3 ホスト内部という第 5 の層 RNIC の線速が 25 Gb/s から 200 Gb/s へ急増する一方、PCIe 帯域の伸びが追いつかない。その結果、RNIC とエンドポイントの間の PCIe リンク、PCIe スイッチ、メモリチャネル、CPU ソケット間バスが新たなボトルネックになった(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。影響の大きさを示す数値がある。 8 ホストの ring ベース nccl all-reduce で、1 本の PCIe 帯域劣化により全ホストが約 185 Gbps から約 50 Gbps へ、およそ 70% 落ちた。 PCIe ダウングレード時の単体測定では 197.0 Gbps が 67.0 Gbps へ落ち、Tx pause duration ratio が 0% から 35.7% へ跳ね上がる。 GPUDirect RDMA の距離による差も無視できない。 | 経路 | レイテンシ | スループット | |---|---|---| | 単一 PCIe スイッチ経由 | 1.0µs | 195.0 Gbps | | CPU root complex 経由 | 2.2µs | 125.5 Gbps | | UPI 経由 | 2.4µs | 116.4 Gbps | わずか 1.4µs の追加レイテンシで約 40% のスループットが失われる。根本原因は物理故障だけではない。 Hostping が新たに発見した 6 種のうち 2 種は設定ミスだった。 ACS(Access Control Service)の意図しない有効化は GPUDirect RDMA のトラフィックを GPU へ直接届けず CPU へ迂回させ、ATS(Address Translation Service)の無効化は仮想化環境で全パケットを CPU root complex 経由にする。いずれもリンク障害と同水準の帯域劣化とレイテンシ増加を引き起こす。診断は「リンク障害か設定ミスか」を切り分ける段を持つ。 GPU 側のレイテンシが異常なら誤設定、そうでなければリンク障害と推定する。 #### 6.4 RNIC マイクロアーキテクチャという第 6 の層さらに内側に、RNIC 自身の内部資源がある。 Husky は RNIC のマイクロアーキテクチャ資源を NIC 帯域、PCIe 帯域、処理ユニット、NIC キャッシュの 4 種に整理し、既存の性能分離機構がこれらを守れないことを示した(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。被害の規模が異様である。 victim が単独で約 80 Gbps 出ていた状態で、SR-IOV による分離を有効にして 50 Gbps を保証していても、attacker がわずか 1 Gbps の攻撃トラフィックを流すだけで victim は直ちに約 2 Gbps へ落ちる。主要な発見は 3 つある。第 1 に、`ibv_reg_mr` の解除のような control verb が MTT キャッシュを枯渇させる。 1 スレッドあたり約 5,000 registration/s の解除で victim が 96.6 Gbps から 48.0 Gbps へ落ち、MTT キャッシュミス率が 17.2% から 49.1% へ上がった。登録のみなら 95.9 Gbps とほぼ無害である。第 2 に、data verb 間の処理ユニット競合は verb の複雑さに依存する。 victim の READ が 60 Mrps 出ていたところへ CAS の attacker を入れると 3 Mrps へ落ちる。第 3 に、RNIC の RNR(Receive Not Ready)エラーが処理ユニット全体を停止させ、無関係なテナントの通信も巻き込む。これらは NVIDIA が全件を再現確認し、ファームウェア修正が計画された。 #### 6.5 カーネルとドライバという第 7 の層最後に、ネットワークでもハードウェアでもない層がある。 Meta では AI 訓練ジョブ失敗の 5〜20% が NIC ドライバのカーネルバグに起因していた(Source: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]])。 2025 年 10 月から 2026 年 2 月の月別で、syscall 失敗が GPU 失敗の 4.2% から 15.1% を占める。この層の不可視性は他の層と質が違う。 12 か月の観測で syscall 失敗試行の約 96% が、非同期イベントもポートフラップもトランスポートタイムアウトも伴わなかった。つまり既存のネットワーク監視系が持つどのシグナルにも現れない。さらに既存の分類器は、生の syscall 失敗証拠を含む試行の約 25% を「Network Event」と誤ラベルしていた。原因は第 3 章で挙げた `libibverbs` の薄さである。 RNIC やスイッチという「ハードウェアの内部が見えない」不可視性と、「カーネルのコードは公開されているのに実行を追跡する仕組みがない」不可視性は、対処法が根本的に異なる。 ### 第 7 章　グレイ障害と責任分界 #### 7.1 差分可観測性前章までの障害の多くは、完全に停止するのではなく劣化として現れる。この状態を **グレイ障害(gray failure)** と呼ぶ。定義は Observer と App のモデルで与えられる(Source: [[グレイ障害]])。 System は Observer(ヘルス収集)と Reactor(復旧)を内包し、App は端点間メトリクスから独自にヘルスを観測する。グレイ障害は、少なくとも 1 つの App が System を不健全と観測しているのに Observer は健全と観測している状態を指す。核心は、Reactor が呼ばれないために回復しないことにある。この非対称性を **差分可観測性(differential observability)** と呼ぶ。 RDMA での現れ方は次のとおりである。 - Clos のコアスイッチがランダムにパケットを落としてもルーティングプロトコルが再ルーティングしないため、高い冗長性が逆に可用性を下げる。 - スイッチが故障を報告せず正常に見えたまま特定の通信パターンだけを落とし続ける(Source: [[サイレントパケットドロップ検知]])。 - NCCL がアダプタ障害を透過的にリルートして帯域が実質半減し、ステップ時間が約 0.3 秒増えるが、ジョブはクラッシュせず見かけ上動き続ける(Source: [[集合通信]])。粒度が機序を決める。 Harp はネットワーク層で物理パス単位、PERSEUS はストレージで同一ノード内ドライブ群という異なる層で、独立に同じ原理へ到達した。集約や広域での比較は平均化によってグレイ障害を隠し、最小の同質集団まで粒度を絞ってはじめて検知できる(Source: [[グレイ障害]])。 #### 7.2 平均帯域を見ても劣化は見えないグレイ障害の議論を、RDMA の実測値で裏づける知見がある。本番訓練の集団通信の変動係数は孤立ベンチマークの 2 倍から 5 倍あり、NVLink 経路で 0.336 対 0.067、NIC 経路で 0.174 対 0.078 だった。一方で平均帯域は 4〜8% 以内で一致する(Source: [[集合通信]])。平均帯域の監視は本番の劣化をほぼ検出せず、変動係数と外れ値の監視が本体になる。同じことが他ジョブ由来のノイズについても言える。 1,024 GPU 規模でネットワークノイズが allreduce を最大 50%、alltoall を 20% 低下させ、Dragonfly グループ間では goodput が 17% 低下して最大 132µs の外れ値が出た(Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。加えて、既定設定のままでは最大 1 桁の性能を取りこぼす。 #### 7.3 ネットワークは無罪か RDMA 監視の第一の価値は、しばしば障害の原因を特定することではなく、ネットワークが原因でないことを示すことにある。 Pingmesh の出発点は「ネットワーク問題として報告される障害の約 50% はネットワーク起因ではない」という経験だった(Source: [[@2015__SIGCOMM__Pingmesh - A Large-Scale System for Data Center Network Latency Measurement and Analysis]])。 R-Pingmesh は、NCCL の "error code 12" がネットワーク問題に見えて実際は GPU のダウンやハング、メモリ不足によるリモートプロセス異常終了であることがある、という例を挙げる(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])。誤帰属は具体的な形で観測されている。 Pulse の評価では、既存手法が CPU 競合と MoE のエキスパート不均衡を通信異常と誤診した(Source: [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]])。機序は明快で、オペレータ単位の実行時間には計算のオーバーヘッドが織り込まれているため、通信の遅さと計算の遅さが同じ数字に潰れてしまう。弁別に成功している設計は、いずれも「通信そのもの」を計算から切り離す量を作っている。 Pulse は転送レートが非ゼロのエポックだけを足した「実際の通信時間」を使い、待ち時間の gap を除外する。 VCCL は帯域低下と NIC 上の未送信データ量の急増という 2 条件の同時成立を要求し、GPU-burn による帯域低下を誤検知しない(Source: [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]])。 --- ## 第 III 部　計測の設計空間 ### 第 8 章　計装点の座標系 #### 8.1 どこに計器を置くかで見える層が決まる RDMA 監視の研究群を並べると、単一の設計軸が浮かび上がる。 **計測点をどこに置くかによって、可視化できる異常の層が固定される**(Source: [[RDMAネットワーク監視]])。これまでに 7 つの計装点が開かれてきた。 | 計装点 | 代表システム | 見える異常 | 見えない異常 | | -------------------- | ------------------------- | ------------------------------------ | ---------------- | | スイッチ ASIC のデータプレーン | Hawkeye | PFC の連鎖(backpressure、storm、deadlock) | ホスト内部、NIC 内部 | | スイッチ層のミラーリング | LLMPrism | ジョブ構造とフロー帯域の劣化 | ノード内通信(TP) | | 市販 RNIC からの能動プローブ | R-Pingmesh、SkeletonHunter | RoCE 固有問題、リンクとスイッチの箇所特定 | GPU 起因、根本原因の自動診断 | | NIC 上の受動計測 | Pulse | マイクロ秒級の通信 gap、ストラグラー | NVLink、ノード内計算 | | 集団通信ライブラリ | C4、VCCL | 同期点のずれ、NIC ポート障害 | PFC 連鎖、光劣化 | | ホスト内(RNIC とエンドポイント間) | Hostping | PCIe、メモリチャネル、UPI、ACS/ATS 設定 | ネットワーク側 | | カーネル verbs とドライバ | RDMATracer | syscall 失敗、ドライバのカーネルバグ | 性能劣化そのもの | | 物理部品 | OptProphet、CorrOpt | 光トランシーバーの劣化と破損 | 輻輳 | 表の最右列が本質的である。各手法は計測点に応じて可視化できる層が固定され、単一の計装では起因層を取り違える。 #### 8.2 時間軸という第 2 の座標計装点と直交する軸として、いつ測るかがある。 RDMA サブシステムのライフサイクル全体では 4 つの時間軸が成立する(Source: [[RDMAネットワーク監視]])。 1. **デプロイ前の性能異常探索**:まだ起きていない異常を人工的に誘発して発見する。Collie。 2. **デプロイ後の仕様準拠性検証**:決定論的にイベントを注入し、仕様どおりに動くかを検証する。Lumina。 3. **稼働中の反応型診断**:劣化が顕在化してから素早く切り分ける。R-Pingmesh、Hawkeye、C4、Astral。 4. **劣化の予防型予測**:故障の前に先回りする。OptProphet。第 1 と第 2 の違いは問いの違いである。 Collie が答えるのは「なぜ遅いか」であり、Lumina が答えるのは「仕様どおりに動いているか」である(Source: [[RDMAネットワーク監視]])。第 3 と第 4 の違いは効果の測り方に現れる。 Hawkeye は性能異常を 90% 以上の精度で即時診断し、C4 は故障検知を数時間から数十秒へ短縮してエラー誘発ダウンタイムを 31.19% から 1.16% へ削減する。対して OptProphet は光トランシーバー故障を平均 1.11 日前に予測する。 #### 8.3 座標の使い方この 2 軸は、自クラスタの監視の空白を見つけるための地図として使える。第 15 章で、埋めるべき順序を含めた実務の指針を示す。 ### 第 9 章　能動プロービングと箇所特定 #### 9.1 Pingmesh から R-Pingmesh へ能動プロービングの系譜は Pingmesh に始まる。全サーバに Agent を置き、Pod 内、intra-DC、inter-DC の 3 階層で完全グラフを張り、アプリケーションと同じ TCP/HTTP で probe する設計である(Source: [[@2015__SIGCOMM__Pingmesh - A Large-Scale System for Data Center Network Latency Measurement and Analysis]])。 4 年以上の運用で 1 日 24 テラバイト、2000 億件超の probe を扱い、約 2500 サーバへの常時 probing で平均メモリ 45 MB 未満、平均 CPU 0.26% に収まった。設計判断として記録しておく価値があるのは、常時稼働か要求時起動か、全サーバ参加か一部選択かという当時の内部論争である。 Pingmesh は「いつインシデントが起きるか予測できない」「どのサーバを選ぶべきか自明でない」の 2 つを理由に、常時かつ全数を選んだ(Source: [[ネットワーク監視]])。 RoCE へそのまま持ち込むと 4 点が足りない(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])。 TCP プローブは RoCE 固有の問題を検知できず、RNIC 起因のドロップとネットワーク内のドロップを区別できず、ソフトウェア層で RTT を測るためネットワーク RTT と処理遅延を分離できず、サービスを認識しないためサービスが実際に使う経路の RTT を測れない。 #### 9.2 UD を選ぶ理由 R-Pingmesh の設計上の要点は、RC ではなく UD の QP を使うことにある。正確なネットワーク RTT を得るには 4 つのタイムスタンプが要る。 prober の送信、responder の受信、responder の ACK 送信、prober の ACK 受信である。市販 RNIC は CQE 生成時にしかタイムスタンプを出さない。 RC は全パケットの ACK を受け取った後にしか CQE を生成しないため、必要なタイムスタンプのうち 2 つが得られない。 UD は送信直後に CQE を生成するため 4 つとも測れる(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])。副次的な利点もある。 RC と UC は宛先ごとに QP を作るため限られた QPC キャッシュを消費し、サービストラフィック側の QPC ミスを誘発する。 UD はコネクションレスなので RNIC あたり 1 つの QP で済む。これにより、クロック同期なしでネットワーク RTT とエンドホスト処理遅延を分離できる。 $\text{ネットワーク RTT} = (t_5 - t_2) - (t_4 - t_3)$ サービス認識は eBPF で実現する。カーネル verbs の `modify_qp` と `destroy_qp` の呼び出しを追跡し、RC QP の接続確立と切断、そして 5-tuple をリアルタイムに把握する。これらの verb は接続の確立時と切断時にしか呼ばれないため、サービス性能への影響が小さい。得られた 5-tuple で同じ 5-tuple の probe を撃つことで、ECMP により実サービスと同じ経路へ流せる。 #### 9.3 箇所特定は投票に帰着する異常なプローブから故障箇所を絞る手法は、複数の研究で同じ形に収束している。 R-Pingmesh は二分ネットワークトモグラフィに着想した投票機構を使う。異常なプローブの経路を辿って各リンクの通過回数を数え、最多得票のリンクを最も疑わしいとする(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])。 SkeletonHunter も underlay ではネットワークトモグラフィで最も故障しやすい物理リンクへ投票する(Source: [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]])。 Hostping は同じ着想を、対象をスイッチファブリックからホスト内部の PCIe とメモリチャネルへ置き換えて適用する(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。パス単位の観測からリンク単位の状態を逆算するという数理的枠組みが、対象の層を変えても機能することを示している。成績も押さえておく。 R-Pingmesh は数万 RNIC に 6 か月以上展開し、直近 1 か月で 207 件を検知していずれも 1 分析周期(20 秒)で箇所特定した。うち 85% が正確で、報告した 157 件のスイッチ問題はすべて正確だった。 #### 9.4 RNIC 問題での偽陽性同じ報告で、RNIC 問題は 50 件中 20 件しか確認できなかった。残り 30 件の原因は、サービスによる Agent の CPU 占有で ACK 応答の処理遅延が高くなり、prober 側でタイムアウトを起こしたことだった(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])。つまり監視システム自身の資源競合が偽陽性の主因になっている。 SkeletonHunter も agent のクラッシュで probing 応答が滞ると当該リンクを誤って問題とみなすとして、監視システム自体の信頼性の重要性を明記する。 Pingmesh が Agent に 4 つの fail-closed 機構を組んだのも同じ問題意識である。 #### 9.5 プローブ集合をどう設計するか完全グラフが不可能になる規模で、3 通りの解が出ている。 **削らない。** Pingmesh はオーバーヘッドが許容範囲である限り全サーバを常時 probe する。 **用途で分ける。** R-Pingmesh は ToR-mesh、inter-ToR、Service Tracing の 3 種の pinglist に分け、確率 0.99 で全 ToR 間リンクを被覆する 5-tuple 数を式で算出する。 **削り込む。** SkeletonHunter は 2 段階で削る(Source: [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]])。第 1 段は rail-optimized トポロジの性質から同一 rail 外のペアを除いて 87.5% 削減する。第 2 段は RNIC のスループットのバーストサイクルを短時間フーリエ変換で周波数領域へ移し、階層クラスタリングで並列化グループ(DP、TP、PP、MoE では EP)を推論して 95% 超をさらに削減する。結果として 2,048 RNIC の probing 時間が full-mesh の 2,034.12 秒から 25.09 秒になった。 6 か月で 4,816 件のネットワーク障害を検知し、precision 98.2%、recall 99.3%、1,302 個の問題コンポーネントを 95.7% の精度で箇所特定している。 #### 9.6 経路が確定していれば統計処理は要らない能動プロービングの前提を変える報告がある。静的な SRv6 経路を使う環境では、プローブパケットが通る経路を正確に把握でき、かつ ICMP のようにコントロールプレーンでレート制限されずデータプレーン内で処理されるため、ミリ秒単位の高頻度プロービングを継続できる(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]])。 R-Pingmesh の投票機構は、ECMP による経路の不確実性を統計的に均して精度を出す設計である。経路が確定的である環境では、理論上この統計処理自体が不要になる。ルーティング方式が能動プロービングの設計そのものを規定するという軸が、ここで立ち上がる。 #### 9.7 集団通信を診断対象にする単一フローの監視では答えられない問いがある。「計算と通信のどのフローが集合通信全体のクリティカルパスを律速しているか」である。 Vedrfolnir は集合通信アルゴリズムをステップ単位に分解し、フロー間の待機依存を有向重み付きグラフとして明示的に表現する(Source: [[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]])。ノード $i$ の $j$ 番目ステップのフローを $F_iS_j$ とし、その開始と終了を頂点、待機関係を有向辺、待機時間を重みとする。ホスト側でクリティカルパスを計算し、ネットワーク側では Hawkeye のプロベナンスグラフを構築して、両者を統合する。ステップごとに検知を 1 回に制限する適応的検知により、NS3 評価で Hawkeye 比 98% のテレメトリ削減を達成した。ただし対象アルゴリズムは Ring と Halving and Doubling に限られ、実機評価は未実施である。 ### 第 10 章　データプレーン内の計装 #### 10.1 INT の位置づけ **INT(In-band Network Telemetry)** は、プログラマブルデータプレーンでテレメトリ情報を通過パケットに直接埋め込む監視技術である(Source: [[インバンドネットワークテレメトリ]])。 INT ソースが命令ヘッダを挿入し、トランジットノードが自身のメタデータ(キュー占有率、ホップごとの遅延、ノード ID)を付加し、INT シンクがヘッダを除去してコレクタへ出す。コントロールプレーンの介入なしにデータプレーン内で直接動くため、SNMP ポーリングや NetFlow、sFlow サンプリングの粗粒度と高レイテンシを克服する。 HPCC のフォーマットが具体例になる(Source: [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]])。 UDP ヘッダの後、IB BTH の前に挿入し、nHop 4 ビットと pathID 12 ビットに続いて各ホップが帯域 4 ビット、タイムスタンプ 24 ビット、送信バイト数 20 ビット、キュー長 16 ビットの計 8 バイトを追加する。 5 ホップ以内で最大 42 バイト、1 KB パケットの 4.2% になる。 INT の課題は 3 つある(Source: [[インバンドネットワークテレメトリ]])。帯域オーバーヘッド、シンクの処理オーバーヘッド(100G から 800 Gbps ではパケットごとのレポートが分析基盤を圧倒する)、そしてコンテキストの欠如である。最後の 1 点は、ネットワーク内計測がホストとアプリケーションの文脈を持たないという原理的な限界を指す。なお INT の用途は「輻輳制御という閉ループ制御」から「監視と診断という開ループ観測」へ主軸を移した。 HPCC(2019)が前者の最初期の応用であり、後年の INT 活用は後者に寄っている。 #### 10.2 PFC の来歴を辿る第 5 章で見たとおり、PFC の病理は連鎖として現れる。末端で個別フローの性能劣化として顕在化するため、苦情の出たフローから上流の根本原因へ来歴を遡る必要がある。 Hawkeye はこれを P4 スイッチのデータプレーン内で解く(Source: [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]])。 3 つの構成要素からなる。第 1 に、エポックベースの多粒度テレメトリ。タイムスタンプの特定ビットでエポックを定義し、フローレベルでは各フローが PFC によって一時停止されたパケット数を、ポートレベルではポート間トラフィック量を記録する。第 2 に、データプレーン内での PFC 因果関係解析。ホスト常駐の検出エージェントが性能劣化を検出すると、被害フロー情報を含むポーリングパケットをネットワークへ注入する。スイッチが線速で PFC 因果関係を推論し、因果関係のあるスイッチにのみ転送してテレメトリ収集を起動する。第 3 に、プロベナンスに基づく診断アルゴリズム。フローとポートをノード、待機関係を有向辺とする異種の wait-for グラフを構築し、ポートレベル辺の重みを次式で与える。 $w = \frac{paused\_num[P_i] \times meter[P_i][P_j]}{\sum_k meter[P_i][P_k]} \times qdepth[P_j]$ 精度は全体で 90% 以上、最適パラメータ設定時は 100% に達する。異常タイプ別では backpressure が精度 100%、storm が 95%、deadlock がループ内開始で 98%、ループ外開始で 92% で、再現率はいずれも 100% である。処理オーバーヘッドはベースライン比で 1 桁から 4 桁低く、テレメトリ収集スイッチ数は全ポーリング方式の約 1/10 で 100% の因果カバレッジを保つ。エポックサイズの設計値は実務的に重要である。 100µs から 1 ms で高精度、2 ms を超えると精度が落ちる。 #### 10.3 データプレーン計装の代償 Hawkeye も Vedrfolnir も P4 プログラマブルスイッチ(Intel Tofino)を前提とする。これは展開容易性と引き換えの可観測性である。 R-Pingmesh はこのトレードオフを逆向きに解いた。 INT の方がスイッチポートのキュー情報を得られて箇所特定に有利だと認めつつ、レガシースイッチが非対応であることを理由に Traceroute を選び、経路追跡モジュールを能動プローブモジュールから分離して新クラスタでは採用しやすくした(Source: [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])。 SkeletonHunter も「スイッチの IP-in-IP のような特殊なハードウェア機能を要する手法は運用コストと安定性のリスクを伴う」と述べている。展開容易性は、この分野で第一級の設計制約として扱われている。 ### 第 11 章　エンドホストの計装 #### 11.1 NIC 上での受動計測能動プローブが「外から撃つ」なら、NIC 上の受動計測は「内で測る」である。 Pulse は RNIC の組み込みマイクロプロセッサ上に計測を置き、パケット処理のクリティカルパスから外す 3 層構成を採る(Source: [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]])。集約層はパケットパイプライン上で 4 KB 送信ごとにイベントを発火し、計測層は DPA 上で QP ごとのレートをエポック単位(32µs)で計測し、収集層はホスト上で PCIe 経由の周期ポーリングを行う。 RDMA RC の 24 ビット source QPN が一意なので、16M エントリの直接アドレス表で衝突なく定数時間の索引が引ける。なぜマイクロ秒でなければならないのか。根拠は 2 つある(Source: [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]])。第 1 に、CCL はデータを slice 単位で送受信して同期するため、1 つの rank の遅れで他の rank が停止して転送の gap が生じるが、ストラグラーと正常な rank のオペレータ単位の実行時間は同一になる。 gap は 32µs 粒度では見えるが 1 ms 粒度では消える。第 2 に、400 Gbps で 2 チャネルの場合 slice 送信は約 40µs かかり、帯域が $1/p$ に落ちれば正常ノードに $40(p-1)$µs の gap が生じる。監視粒度がこれを超えると不可視になる。 1/25 への劣化を許容しない限りマイクロ秒級の監視が必須で、800 Gbps 化すると要求はさらに厳しくなる。成績は、12 シナリオ中 10 でマシン単位まで箇所特定でき(既存手法は 4 のみ)、適合率 90% 超かつ再現率 100%、診断遅延は平均約 6 秒である。オーバーヘッドは NIC あたり 2,000 フローの計測でもスループット劣化がなく、平均レイテンシは計測ありで 1.52µs、なしで 1.53µs だった。 #### 11.2 ホストと NIC の境界にタイムスタンプを置く Azure Storage の **RDMA Estats** は、RDMA operation ごとに WQE 投稿、NIC 内部、CQE 生成、CQE ポーリングのタイムスタンプを収集する(Source: [[@2023__NSDI__Empowering Azure Storage with RDMA]])。送信側とネットワークと受信側のどこがボトルネックかを切り分けるためである。この計測が効いた実例が FMR hidden fence である。 FMR と Send のペアが送信キューに並ぶと、NIC が実装簡略化のため FMR を先行リクエストの完了後に処理し、Send の間に隠れた fence が生じる。異なるデータセンター間では 1 RTT に 1 Send しか飛ばず、巨大なネットワークパイプを埋められない。診断には `T5 - T1` とデータセンター間 RTT の強い相関を使った。同じ報告には他に 3 件の運用上の発見がある。 MACsec 標準が PFC フレームの暗号化扱いを規定していないためベンダー間で解釈が食い違い、長距離リンクで高いパケット破損率として報告された事例。 Gen2 NIC のファームウェアの head-of-line blocking により、1 つの NIC から出る全フローが最も遅いフローの送信率に収束した事例。同一サーバ内の複数 RDMA アプリインスタンス間の通信と外部通信が NIC 上で共存し、PCIe レーンで 2 対 1 の輻輳を作った事例である。 #### 11.3 集団通信ライブラリの自己計装外部計装を一切必要としない系統がある。 C4 は Alibaba の ACCL を拡張し、通信、オペレーション、トランスポートの 3 層で監視情報を収集する(Source: [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]])。検知は BSP モデルの同期点を利用し、反復ごとの同期点における各 GPU の到達タイミングのずれと通信遅延行列の行と列の偏りから、遅い接続を特定する。本番の 10,000 GPU 超のクラスタで 30 か月以上稼働し、エラー誘発ダウンタイムを 31.19% から 1.16% へ、故障検知を数時間から数十秒へ落とした。 VCCL のスライディングウィンドウ型 RDMA モニタは、さらに CCL 内で対処まで完結させる(Source: [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]])。 WR(Work Request)投稿時と対応する WC(Work Completion)生成時のタイムスタンプを記録し、ウィンドウ内の平均スループットをマイクロ秒粒度で推定する。「帯域が直近平均の 50% 未満」かつ「未送信データ量が過去最大の 2 倍超」という二重閾値で NIC ポート異常を検知し、プライマリからバックアップの QP へ切り替える。なぜウィンドウで集約するのか。複数の集合通信が同時に 1 つの NIC を共有するため、単一の集合通信のトレースではネットワーク状態を反映できず、メッセージ単位の帯域推定はクロストラフィックで不安定になるからである。 VCCL の追加 CPU 利用は約 2% で、24K GPU のクラスタでポートダウン後のリトライ期間を経てバックアップ QP へ切り替え、GPU 待機時間を約 90% 削減した。 > [!note] CCL 内蔵モニタの利点と限界 > NIC や P4 スイッチへの外部アクセス権限を必要としないため、クラウド事業者環境やサードパーティ CCL 利用者でも導入できる。一方で NIC ポート単位の障害は捕捉するが、PFC 連鎖輻輳や光トランシーバーの物理劣化は見えない(Source: [[RDMAネットワーク監視]])。 #### 11.4 スイッチ層のミラーリングでジョブを再構成するホストにもスイッチのデータプレーンにも触れずに、既存のパケットミラーリングだけで診断する系統がある。 LLMPrism は ERSPAN で収集した RoCE ネットワークフローデータだけから 4 段階の処理を行う(Source: [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]])。第 1 にジョブ認識で、通信する GPU ペアを素集合で併合し、物理トポロジで同一マシン集合を共有するクラスタを Jaccard 類似度 1 で併合する。第 2 に並列化戦略の識別で、フロー間隔にベイズ的オンライン変化点検知を適用してステップ境界を求め、各ステップ内の相異なるフローサイズ数から PP と DP を分類する。第 3 に訓練タイムラインの再構築、第 4 に性能診断である。成立根拠は集団通信の性質にある。通信は空間的に安定して同じ DP または PP グループ内に限定され、訓練ステップが循環するため明確な時間的周期性を示し、PP と DP で通信特性が異なる。 2,880 GPU のクラスタで 1 分間のフローデータから 19 件のジョブを正確に識別し、並列化戦略の識別はノイズ精緻化ありで 1 分から 10 分の全窓長で 100%、1,024 GPU ジョブのタイムライン再構築は誤差 0.3% 以内だった。スイッチ層診断では、1 時間窓の平均 DP フロー帯域が通常 100 から 180 Gb/s のところ一部スイッチが約 30 から 60 Gb/s へ劣化する異常を検知している。限界も明確である。 TP の通信はマシン内に閉じるためスイッチからは観測できない。 #### 11.5 4 層を貫くフルスタック Astral は 4 層を同時に計装し、階層相関で切り分ける(Source: [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]])。 | 層 | 計測内容 | |---|---| | アプリケーション | NCCL タイムライン、CUDA イベント | | トランスポート | NCCL と RDMA のエラーログ、ACL で RDMA 先頭パケットを抽出し RETH の DMA 長を解析するミリ秒級レート監視 | | ネットワーク | sFlow による受動的パス復元、INT 搭載 ping によるホップごとの遅延と接続性 | | 物理 | CPU/GPU 使用率、メモリエラー、PCIe/NVLink メトリクス、CNP/PFC/ECN カウンタ、SNMP、Mirror On Drop | 相関はユーザ知覚に最も近いアプリケーション層から始め、予測コンポーネント Seer が出すジョブ別しきい値とホスト間の水平比較で異常ノードを判定する。そこから計算異常なら物理層ログへ、通信異常ならエラー CQE と QP レート、パス重複解析、INT のホップ別遅延へ分岐する。 fail-slow の実例が診断の流れを具体化している。 NCCL タイムラインで通信が期待より長いノードを特定し、ミリ秒級の QP レートでリンク帯域の 50% 未満を検出し、sFlow でパスを辿って INT ヒートマップで各ホップ 0.6µs、179µs、266µs の転送遅延を確認し、Agg と ToR の間の下りリンクの輻輳と推定し、PFC pause カウンタが正常域を大幅に超えていることを確認して、上流の ECMP による非効率な経路選択という根本原因に到達した。 #### 11.6 カーネル verbs 層 RDMATracer はカーネルの verbs 層とベンダードライバ層に `fexit` プローブを置き、戻り値が非ゼロのときだけ記録する(Source: [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]])。 hook の選定に 4 つの経験則を使う。読み取り専用の操作を除外し、同期プリミティブやメモリ管理といった汎用カーネル内部処理を除外し、クリーンアップと参照カウントのパスを除外し、QP、MR、PD、CQ の作成や更新およびハードウェア通信を開始するパスに集中する。これを名前空間ゲート(`ib_*`、`rdma_*`、`mlx[45]_*` ほか)と正規表現で機械的に符号化した結果、約 2,000 個の関数から 13 個へ絞り込んだ。 44 関数のサンプルでの検証は再現率 1.000、F1 0.765 である。データ構造の分離が実務的に効いている。 per-CPU 配列は戻り値を問わず常時インクリメントして「発生したか」を厳密に保ち、256 KB のリングバッファは非ゼロ戻り値のときだけタイムスタンプと errno とプロセス名を記録して「何が発生したか」を運ぶ。バースト時にはコンテキストだけを失い、件数は正確に残る。オーバーヘッドは 1 ホストあたり約 0.0000024% の CPU で、全 RDMA 関数追跡比で約 2,000 分の 1 である。 BPF の実行コストは P50 で 56 ns、P99 で 79 ns で、フリート全体の BPF の P50 501 ns、P99 7,500 ns より 1 桁から 2 桁低い。診断例を 1 つ挙げる。 `ibv_reg_mr` が数千ホストで `EFAULT` を返すフリート規模の障害で、NCCL はトップレベルの失敗しか出さなかったが、RDMATracer はカスケードする 4 層すべてで同一の `EFAULT` を各約 1,900 万回捕捉し、根本原因を GPU の peer-memory サブシステムへ局所化して汎用 NIC ドライバの失敗と弁別した。原理的な限界は設計の帰結として明示されている。戻り値ゲート型であるため、クリーンアップパス由来の失敗(約 21%)と読み取り専用パス(約 3%)はカバーできない。 #### 11.7 ホスト内ループバック Hostping は RNIC とエンドポイントの間をホスト内で完結するループバックテストで測る(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。読み書き 2 つの領域を登録し、write の WQE を投げると同一 RNIC のためネットワークへ出ずに write 領域へ書き戻される。投稿から完了ポーリングまでの時間差を測る。分離の式は単純である。 $Lat = T_{proc} + Lat_{host} + \frac{Size}{BW_{host}}$ 1 バイトの小メッセージで $T_{proc} + Lat_{host}$ に近似し、128 KB の大メッセージとの差分から $Size/BW_{host}$ を得る。プロービングの頻度はホストの状態で切り替える。アイドル時は full-mesh、混雑時は同一 root port 配下のエンドポイントとの相対比較とアイドル RNIC とのベースライン比較に落とす。 300 台超の本番サーバで既知 4 種と新規 6 種の計 10 種のボトルネックパターンを特定した。 ### 第 12 章　稼働前と稼働後の探索 #### 12.1 デプロイ前に異常を誘発する Collie は、まだ起きていない性能異常を人工的に誘発して発見する(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。探索空間は標準 verbs API が張る 4 次元である。ホストトポロジ、メモリ割り当て、トランスポート設定、メッセージパターン。空間サイズは約 $10^{36}$ に及ぶ。探索は焼きなまし法で駆動する。性能カウンタは低い方向へ、診断カウンタは高い方向へエネルギー関数を動かす。白箱ファジングのコードカバレッジに相当する信号としてカウンタを使う点が設計の核心である。異常を見つけるたびに **MFS(Minimal Feature Set)** を構築して重複探索を避け、別の点から再開する。 8 サブシステムで 18 件の異常を発見し、うち 15 件が新規だった。既存の Perftest 手動チューニングで再現できたのは 4 件のみである。性能カウンタだけでは 13 件中 11 件で、診断カウンタ(代表は Receive WQE Cache Miss)を併用してはじめて捕捉できた異常があった。発見された根本原因は RNIC 内部キャッシュミス、PCIe backpressure、クロスソケット通信に集中している。つまり NIC と DPU の層である。スイッチ層の PFC 連鎖や物理層の光劣化は本番トラフィックがなければ顕在化しにくいのに対し、この層の異常はデプロイ前に人工的に誘発できるという層ごとの事前検証可能性の違いが読み取れる。なお Collie は根本原因そのものは特定しない設計である。 RNIC がブラックボックスである以上、MFS という必要条件を出すところで止める。 #### 12.2 仕様どおりに動いているかを検証する Lumina が答えるのは別の問いである。「RNIC は IB 仕様どおりに動いているか」を、決定論的なイベント注入で検証する(Source: [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]])。第 3 章で述べたとおり、カーネルバイパスのため末端ホストにシムを刺せない。そこで requester と responder の間にプログラマブルスイッチ(Intel Tofino)を挿入し、パケット転送とイベント注入(ECN マーク、ドロップ、破損)を兼務させる。詳細な解析はスイッチ上では行わず、MMU による実ドロップの前の ingress パイプラインで全 RDMA パケットをミラーリングしてオフライン解析へ回す。見つかった隠れた挙動を並べる。 | 発見 | 対象 NIC | |---|---| | ETS が work-conserving でない | CX6 Dx | | noisy neighbor(無関係なコネクションまでタイムアウト) | CX4 Lx | | MigReq 不一致による APM 遅パスの誘発 | CX5 と E810 の組み合わせ | | カウンタが実際の事象を反映しない | CX4 Lx、E810 | | CNP レート制限の粒度が未文書 | 全テスト対象 | | adaptive retransmission が想定外のリトライ回数と短縮タイムアウトを示す | 全 CX 系 | noisy neighbor は第 5 章の PFC 連鎖と現象として似ているが、原因の層が違う。 36 コネクション中 8 つにドロップを注入すると無関係なコネクションの平均 MCT が約 160µs、12 以上で約 430 ms に達し、同時に `rx_discards_phy` が $10^7$ 増加した。 PFC がスイッチとリンクの輻輳制御機構に起因するのに対し、こちらは RNIC 内部のパイプラインストールに起因する。無関係なフローへの波及という現象は、スイッチ層と NIC 層の両方で生じうる。先行研究との食い違いも記録に値する。ある先行研究は goodput で CX-4 のロッシー環境の性能を高く評価していたが、Lumina の精密計測では実際の再送遅延が約 200µs(base RTT のおよそ 100 倍)だった。 #### 12.3 4 つの時間軸をどうつなぐか Collie の発見を本番監視の事前知識として使えるか、Lumina の noisy neighbor をリアルタイムに検知するにはどの計装が要るか、そして OptProphet の予測と Hawkeye の即時診断を結んで劣化しつつあるリンクを先回りで切り離せるか。いずれも [[RDMAネットワーク監視]] が未解決の問いとして明示的に残しているものである。 --- ## 第 IV 部　実務 ### 第 13 章　カウンタの体系 #### 13.1 5 つの計測点と 3 つの種別個々の研究がアドホックに言及するカウンタ名は、ベンダーが公開する統一仕様の部分集合として位置づけ直せる。 mlx5 ドライバの公式仕様は、計測点と種別の 2 軸で全カウンタを定義する(Source: [[@2023__LinuxKernelDocs__mlx5 Ethtool Counters]])。 | 計測点 | 内容 | |---|---| | Ring | ドライバがキュー単位で数えるソフトウェアカウンタ | | Netdev | Ring の集約(ソフトウェアポート単位) | | vPort | eSwitch に接続された NIC ポート上のトラフィックとドロップ。Ethernet と RDMA/RoCE の双方を含む | | Physical Port | アダプタとネットワークの間の外部ポート統計。IEEE 802.3 ほかの標準にフロー制御と FEC の拡張を加えたもの。VM には非公開 | | Priority Port | Physical Port を L2 優先度(0 から 7)ごとに分解。PFC 有効優先度でのみ意味を持つものがある | | Device Counters | PCIe の信号品質とバッファ管理 | 種別は 3 つある。 Traffic Informative は負荷推定と一般デバッグ用の純粋なカウント、Traffic Acceleration はハードウェアやドライバでアクセラレーションされた分で対応する Informative と二重に計上される、Error は増加が問題を示唆する。集計軸と診断軸を混ぜないというこの設計思想は、RDMATracer の per-CPU 配列とリングバッファの分離とも同型である。 #### 13.2 実務で最初に見るカウンタ用途ごとに代表カウンタを挙げる(Source: [[@2023__LinuxKernelDocs__mlx5 Ethtool Counters]])。 **輻輳とバッファ** - `rx_discards_phy`:物理ポートでのバッファ不足によるドロップ。増加はアダプタ側の輻輳を示唆する。Lumina が noisy neighbor の診断に使った。 - `tx_discards_phy`:送信破棄。リンクダウン、head of line drop、ネットワークからの pause など。 - `rx_pause_ctrl_phy` と `tx_pause_ctrl_phy`:リンク層 pause の送受信数。 - `rx_prio[p]_pause` 系:PFC 有効優先度ごとの pause 受信、送信、遷移回数、duration。第 5 章で見た不均衡の検知に使う。 - `rx_out_of_buffer` と `dev_out_of_buffer`:受信キューとデバイス所有キューのソフトウェアバッファ不足。 **リンク品質と物理層** - `rx_crc_errors_phy`:FCS エラーによるドロップ。高頻度なら次の 2 つで追加確認せよと仕様に明記されている。 - `rx_pcs_symbol_err_phy`:FEC で訂正しきれなかったシンボルエラー数。`rx_bits_phy` との比でエラーレートを算出できる。 - `rx_corrected_bits_phy`:FEC による訂正ビット数。増加は高い BER を意味する。 - `rx_err_lane_[l]_phy`:レーン単位の FEC 訂正前の物理エラー数。 - `link_down_events_phy`:リンクダウン遷移回数。ポートフラッピングを示唆する。 - `module_bus_stuck`、`module_high_temp`、`module_bad_shorted`、`module_unplug`:トランシーバ固有の障害と状態。 **PCIe** - `rx_pci_signal_integrity` と `tx_pci_signal_integrity`:PCIe 物理層の信号品質エラー。増加時はスロット変更やファームウェアと BIOS の更新が推奨される。 - `outbound_pci_buffer_overflow`、`outbound_pci_stalled_rd`、`outbound_pci_stalled_wr`:PCIe バス側の輻輳とクレジット不足による滞留。第 6 章のホスト内ボトルネックに対応する。 CorrOpt が根本原因診断に使う RxPower と TxPower の水準も、`rx_pcs_symbol_err_phy` や `rx_corrected_bits_phy` と同じ物理層診断の語彙に属する(Source: [[RDMAネットワーク監視]])。 #### 13.3 ネットワーク機器側のカウンタスイッチと NIC のハードウェアカウンタのうち、Meta が重視する 3 つを挙げる(Source: [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]])。 - **OOS(Out-of-Sequence)**:NIC が受信したシーケンス外パケット数。スイッチ障害や NIC のハードウェアバグの発見に有効。 - **リンクフラップカウンタ**:NIC が報告するハードウェアとソフトウェアのフラップ。 - **LAT(Local Ack Timeout)**:QP のタイムアウト発生回数。性能劣化やジョブ障害の強い指標。自動緩和として PFC ウォッチドッグ(200 ms 超の pause)と RTSW バッファ使用率 80% 超のアラームを組む。一方で不足も明記されている。 Microsoft は pause フレーム数だけでなく、severity をより正確に反映する **pause の間隔** を監視したかったが、当時のスイッチは非対応で ASIC ベンダーへ将来実装を要求する段階にとどまった(Source: [[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]])。 > [!warning] カウンタの正しさを前提にしない > Lumina は Intel E810 の `cnpSent` と NVIDIA CX4 Lx の `implied_nak_seq_err` が実際の事象を反映しないことを発見した(Source: [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]])。またベンダー横断でカウンタ名と意味を対応づけるマッピング表は本 wiki の範囲では未整理であり、マルチベンダー環境の根本原因診断は標準化されていない。 ### 第 14 章　粒度と周期の設計 #### 14.1 各手法が選んだ周期監視の時間粒度は、何を捉えたいかで決まる。主要な設計値を並べる。 | システム | 粒度 | 根拠 | |---|---|---| | Pulse | 32µs エポック | slice 送信が約 40µs。1 ms 粒度では gap が消える | | VCCL | マイクロ秒粒度のウィンドウ | 集合通信は O(ms) から O(µs) で完了、ハードウェアカウンタは O(s) | | Hawkeye | 100µs から 1 ms のエポック | 2 ms 超で精度低下 | | Astral | ミリ秒級 QP レート | 秒級では異常レートを見分けられない | | R-Pingmesh | ToR-mesh 10 packets/s、Service Tracing 10 ms、分析周期 20 s | 100 ms 粒度で異常 RNIC を検知 | | Meta の finecounters | 4.8 ms | NIC の割り込み合体ウィンドウに合わせた | | Meta の switchos | 分単位、1 から 5 分でエクスポート | スイッチ CPU オーバーヘッド 0.1% 未満 | | Hostping | ホスト状態 5 分、異常メトリクス 1 秒 | | | RDMATracer | 5 秒間隔のポーリング | 約 3 失敗イベント/ホスト/秒 | | OptProphet と CCGrid | 5 分 | DDM の実務的な取得周期 | 粒度を細かくすればよいという話ではない。 Hawkeye はエポックを短くするほど精度が上がる一方、メモリと処理コストが線形に増える。 Meta の `switchos` は分単位という粗さと引き換えにスイッチ CPU への影響を 0.1% 未満に抑え、第 5 章で見たとおりその粗い粒度でもバースト検知の一次シグナルとして機能する。 #### 14.2 マイクロバースト収集の現場の壁理論値と現場の乖離を示す実測がある(Source: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])。収集間隔とピークの見え方の関係は次のとおりだった。 | 収集間隔 | 見えるピークトラフィック | |---|---| | 100 ms | 400 Gb | | 500 ms | 80 Gb | | 1 秒 | 40 Gb | 通常の 500 ms から 1 秒の間隔では、マイクロバーストの捕捉に不十分である。さらにマルチベンダー構成では収集手段そのものが分岐する。 Leaf(QFX5240、JunOS)は gNMI で最短 2 秒間隔が可能だが、データレートが高いと更新が止まる事象があり、gNMIc のプロセスをデータ種別ごとに多重化して回避した。 Spine(SN4700、Cumulus Linux)は gNMI では約 15 秒間隔が限界だったが、Cumulus Linux 5.11 以降の OpenTelemetry 対応で約 2 秒間隔とスイッチから TSDB への直接書き込みが可能になった。それでも取得間隔の微妙なずれによるレート計算の不安定性というリスクが残り、投資判断に使える正確な可視化はまだ達成していないと報告されている。 #### 14.3 オーバーヘッドの実績値計装のコストは、設計判断の材料として具体的な数字で持っておくとよい。 | システム | オーバーヘッド | |---|---| | Pingmesh Agent | 平均メモリ 45 MB 未満、平均 CPU 0.26% | | R-Pingmesh Agent | 8 枚 RNIC のホストで CPU 約 3%、メモリ約 18.5 MB、RNIC あたり帯域 300 Kbps 未満 | | SkeletonHunter Agent | CPU 約 1%、メモリ約 35 MB | | Pulse | 2,000 フロー/NIC でスループット劣化なし、PCIe 最大約 0.3 MB/s | | VCCL | CPU 約 2% 増、GPU HBM は最大 26.7% 削減 | | RDMATracer | 1 ホストあたり約 0.0000024% CPU、BPF 実行 P50 56 ns | | LLMPrism | 訓練プロセスから独立。侵入的な XPUTimer は 3D 並列ジョブで 5% 劣化 | | Meta の switchos | スイッチ CPU 0.1% 未満 | | HPCC の INT パディング | 5 ホップで最大 42 バイト、1 KB パケットの 4.2% | 削減の工夫も同じ軸に乗る。 Hawkeye は収集スイッチ数を全ポーリングの約 1/10 にして 100% の因果カバレッジを保ち、SkeletonHunter は probing を 2 桁削減し、Vedrfolnir は Hawkeye 比 98% のテレメトリ削減を達成し、RDMATracer は約 2,000 個の関数を 13 個へ絞る。いずれも「網羅性とオーバーヘッドのトレードオフ」という同じ設計軸に、別の切り口で答えている。 ### 第 15 章　運用のプレイブック #### 15.1 クラスタ受け入れ時に確認すること本文中の出典で本番の事故として報告された事象に対応する項目を挙げる。 | 段階 | 確認事項 | 根拠 | |---|---|---| | 配線 | レール最適化の GPU と NIC と Leaf の対応が全ノードで一致しているか。異種サーバ混在時にポート番号体系の差を吸収できているか | 配線ずれで Spine 経由のリングが形成され性能劣化(Source: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) | | 配線 | レール最適化とデュアルプレーンで複雑化した配線を INT ベースのプローブで事前検証したか | 初期展開時に多数の配線ミス(Source: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]]) | | ホスト内 | 稼働開始前と再起動後に Hostping 相当のホスト内診断を実行したか | 出荷時点でリンク障害が存在しうる(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) | | ホスト内 | ACS が意図せず有効になっていないか、仮想化環境で ATS が有効か | 設定ミスがリンク障害と同水準の劣化を生む(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) | | 設定 | Trust Mode、DSCP と TC の対応、PFC 有効優先度を送受信の双方で揃えたか | 明示しないと機器の既定挙動に依存(Source: [[@2024__SpeakerDeck__GPUネットワーク設計・運用基礎勉強会 Lossless Ethernet - PFC-ECN編]]) | | 設定 | Headroom をケーブル長と MTU から計算したか。長距離区間が混在していないか | 50m 未満は既定値で足りるが 300m 超は計算が要る(Source: [[RoCE設計課題]]) | | 設定 | MMU のキュー閾値を変更したか | 変更しないと PFC が継続動作して性能が落ちる(Source: [[@2024__SpeakerDeck__GPUネットワーク設計・運用基礎勉強会 Lossless Ethernet - PFC-ECN編]]) | | 光部品 | Pre-FEC と Post-FEC の BER、FEC Symbol Error Bins を取得し切り分け手順を用意したか。短距離区間は AEC を検討したか | Optics 障害切り分けの実務手順(Source: [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]) | | CCL | GPUDirect RDMA が実際に使われているか(`lsmod \| grep nvidia_peermem`、`NCCL_DEBUG=INFO`、perftest の `--use_cuda`) | 設定ミスで TCP へ無警告フォールバックし数十 GB/s が数 Gb/s に(Source: [[RDMA]]) | | ウォッチドッグ | NIC 側 100 ms、スイッチ側 200 ms の PFC ウォッチドッグを入れたか | 単一 NIC の pause ストームがネットワーク全体を麻痺させる(Source: [[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]], [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]) | #### 15.2 既定値のままでは性能が出ないチューニングの効き幅は無視できる規模ではない。 Alps、Leonardo、LUMI の 3 システムで、既定設定はすべて最適から程遠く、手動チューニングで最大 1 桁の性能向上が得られた(Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。具体例を挙げる。 - `NCCL_IGNORE_CPU_AFFINITY=1` で alltoall が最大 1.6 倍、allreduce が最大 6 倍改善 - `NCCL_NET_GDR_LEVEL=3` で alltoall が 2 倍、allreduce が 3 倍改善 - `NCCL_NCHANNELS_PER_PEER=32` でノード内点対点が 3.5 倍改善 NCCL 側の既定閾値も本番環境を想定していない。 Meta では論理トポロジ(Tree と Ring)とプロトコル(LL、LL128、Simple)の切り替え閾値が本番レイテンシの想定と合わず、既定のままでは 50% 以下の性能になりうると報告されている(Source: [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]])。開発環境が想定する RTT 10µs 未満に対し、VOQ を持つ CTSW 経由の本番 RTT は 22µs だった。奇数ノードの AllReduce では NCCL が既定で Spine 越えのリングを形成する。 `NCCL_CROSS_NIC=0` で同一 NIC を同じリングに使わせ、リングを Leaf 内に閉じ込めることで、性能劣化なしに Spine 通過トラフィックをほぼゼロにできた(Source: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])。 #### 15.3 NCCL の内部を知らないと数字を読み違える監視で得た帯域の数字を解釈するには、CCL が何を選んでいるかを知る必要がある。 NCCL は 3 つのプロトコルを持つ(Source: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]])。 | プロトコル | 同期機構 | 帯域利用率 | ホップあたり遅延 | |---|---|---|---| | Simple | メモリフェンス | ほぼピーク | 約 6µs | | LL | フラグ同期(4B データ + 4B フラグ) | 25 から 50% | 約 1µs | | LL128 | フラグ同期(120B データ + 8B フラグ) | 約 95% | 約 2µs | 選択はメッセージサイズ、トポロジ、GPU アーキテクチャ、利用可能リソースからオートチューニングが動的に行う。ここで監視上の落とし穴が 2 つある。第 1 に、LL は中間バッファをホストメモリに置くため GPUDirect RDMA を使えず、帯域が制限される。第 2 に、LL128 は 128 バイトのアトミック書き込みを前提とするため、PCIe やアーキテクチャの制約で保証されない環境では無効化される。実測では、ノード間の大メッセージで Simple が一貫して最速で、LL と LL128 はギガバイト域で急落する(フラグ同期が数百万回累積するため)。ノード内では LL128 が全サイズで最も安定する。「帯域が出ない」の原因が経路にあるのかプロトコルにあるのか並列化次元にあるのかを、切り分けられる計装が要る。 #### 15.4 トラフィックの実態に合わせる汎用データセンターのトラフィックを前提にしたサンプリング設計は、LLM 訓練には適合しない。 GPT 系のモデルでは 100 MB 超の大規模フローが支配的である(Source: [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]])。 GPT-3B を 32 GPU で PTD-P 並列化したときの rank 0 の通信内訳は次のとおりだった。 | 通信種別 | 通信量 | メッセージ数 | メッセージサイズ | |---|---|---|---| | TP | 約 85 GB | 680 | 125 MB | | PP | 約 1 GB | 16 | 125 MB | | DP | 741 MB | 1 | 741 MB | | EmbTableSyn | 96 MB | 1 | 96 MB | TP が総通信量の約 99% を占める。ところが TP はノード内で完結するため、TCP から RoCEv2 への切り替えの恩恵をまったく受けない。実際に恩恵を受けたのはノード間の PP(2.5 倍削減)と DP(1.6 倍削減)だった。さらに TP はスイッチから観測できないため、LLMPrism のようなスイッチ層の計装では原理的に見えない。 TP と PP と DP を、そしてノード内とノード間を分離して観測しない限り、帯域の数字は誤って帰属される。密なモデルは予測可能で周期的だが、MoE は半予測可能にとどまる。 AllToAllv では MoE のエキスパート選択によって転送量が数百ミリ秒単位で変化し、スキューが最大 12 倍に達する(Source: [[集合通信]])。標準的な集合通信に従わないワークロードでは、SkeletonHunter のスケルトン推論のような事前知識に依存する手法の忠実度が落ちる。 --- ## 第 V 部　統合と展望 ### 第 16 章　信号の統合 #### 16.1 各系統が見落とすもの第 8 章の座標系を、見落としの側から読み直す。輻輳を主眼とする系(Hawkeye、C4、R-Pingmesh)は、破損という質的に異なる障害クラスを暗黙に見落とす。第 6 章で見たとおり、破損損失は利用率と相関せず時間的に安定するため、送信レート低下や経路変更で緩和できるという前提が原理的に成り立たない(Source: [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]])。 CCL 内蔵モニタ(VCCL)は NIC ポート単位の障害を捕捉するが、PFC 連鎖輻輳と光トランシーバーの物理劣化は見えない。スイッチデータプレーン計装(Hawkeye)は PFC 連鎖を精密に追えるが、ホスト内部と NIC 内部には届かない。能動プローブ(R-Pingmesh)は GPU 起因の問題を直接検知できず、GPU メモリでの RDMA プロービングは高コストで非現実的だと自ら述べている。スイッチ層ミラーリング(LLMPrism)は TP の通信を原理的に見られない。カーネル計装(RDMATracer)は syscall の成否という二値を対象とし、性能がどれだけ劣化したかは測らない。 #### 16.2 統合の 3 つの形複数の信号を束ねる方法は、これまでに 3 通り試みられている。 **階層相関。** Astral はアプリケーション層から始めて計算異常と通信異常へ分岐し、通信側ではエラー CQE から QP レート、パス重複解析、INT のホップ別遅延へ順に降りる(Source: [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]])。 **グラフ統合。** Vedrfolnir はホスト側の待機グラフとネットワーク側の PFC プロベナンスグラフを独立に構築し、後から統合する(Source: [[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]])。 **楽観的分離。** SkeletonHunter は overlay の根本原因がソフトウェア関連、underlay がハードウェア関連で互いに伝播しないという楽観的仮定を置き、各層を相手が健全と仮定して独立に検査する(Source: [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]])。両層で問題が見つからないのに障害が存在する場合は、RNIC にオフロードされたフローテーブルをダンプして不整合を検出する。実際にこの経路で、RNIC が flow counter を適時に更新せずコントロールプレーンが flow を非アクティブとみなして無効化していた事例を 60 秒で復旧させた。 #### 16.3 なお統合されていないものホスト内診断(Hostping)とネットワーク監視(R-Pingmesh)を単一の根本原因分析パイプラインへ統合する仕組みは、本 wiki のソースからは確認できない(Source: [[ホスト内ネットワークボトルネック]])。性能異常探索(Collie)と仕様準拠性検証(Lumina)とカーネルバグ診断(RDMATracer)の 3 系統を統合した診断パイプラインが構築可能かも、未解決として明示されている(Source: [[RDMA]])。 Astral 自身も限界を認めている。クロスホストの階層相関は単一デバイスに起因する障害に有効だが、特定のデバイスに紐づかない問題(訓練フレームワーク層の不適切な戦略によるオペレータの資源奪取)には届かず、デバイス間でランダムに現れる異常を示せても根本原因を特定できない。 ### 第 17 章　トランスポート層の耐性と可視性 #### 17.1 ride out できる障害とできない障害トランスポート層の耐性は、障害を吸収すると同時に見えなくする。 MRC は RDMA の RC トランスポートを拡張し、1 つの QP が数百の並列経路へパケットをスプレーする(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]])。パケットがトリムされずに失われたらその経路を故障とみなして該当エントロピー値を直ちに使用停止し、バックグラウンドのパスプローブで復旧を確認する。数十マイクロ秒で経路障害を検知して回避する。実際の効果は劇的である。 50K GPU の本番事前学習ジョブで、T0 スイッチの光トランシーバ 1 個がグリッチして 4 リンクを連続フラップさせたとき、スループットは約 7 Pb/s から約 5 Pb/s へ 25% ほど落ちたが 1 分後に全速回復し、ジョブはクラッシュせず QP も 1 つも失敗しなかった。ところが同じ光モジュール障害でも、NIC 側では事情が違う。 800 Gb/s の光学を 4×200 Gb/s に分割する構成でトランシーバ自体がフラップすると、NIC の全ポートを同時に失って QP が失敗するため ride out できない、と論文自身が明記している。解決策は示されていない。この非対称性は予防型検知の投資配分に直結する。 OptProphet の光トランシーバー故障予測は、T0 スイッチ側ならトランスポート層の耐性で吸収できるため予防の価値が相対的に低い障害と、NIC 側なら耐性で吸収できず唯一の防衛線になる障害の両方を、無差別に対象としている(Source: [[RDMAネットワーク監視]])。 #### 17.2 運用が変わる耐性が上がると運用の判断も変わる。 MRC 導入以前はフラップするリンクを管理的にダウンさせてから修理していたが、不要と判明して現在は修理中もリンクを在線状態に残す運用に変えた(Source: [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]])。リンクフラップの修理は「非常に優先度の低い活動であり、運用の労力は他に振り向けたほうがよい」と述べられている。 QP あたり失われるパケットがごく少数(しばしば 1 個のみ)で済むためである。その裏返しとして、劣化しつつあるリンクを別系統から拾い上げる必要が生じる。モジュール自身の CMIS VDM が公開する pre-FEC BER や eSNR、あるいは FEC の訂正ブロック数といった、トラフィックへの影響が出る前の物理指標である。冗長性が性能問題を隠すという同型の問題は、他の文脈でも報告されている。 ### 第 18 章　エージェントによる診断 LLM エージェントがツール呼び出しを通じて稼働中のネットワークを対話的に探査し、不完全かつ層をまたいで連鎖する症状から根本原因を特定するタスクが立ち上がりつつある(Source: [[エージェント型ネットワーク障害診断]])。従来の LLM ネットワーク研究が「望ましい結果が既知の意図を設定へ変換する」順問題を扱うのに対し、これは根本原因が未知の逆問題であり、証拠収集と仮説改訂を観測の蓄積に応じて繰り返す点で本質的に異なる。本書の文脈で意味を持つ知見が 3 つある。第 1 に、証拠取得と仮説確定の分離が中心的な設計軸になる。既存エージェントは自由形式の熟考の中で両者を混同することが主要な失敗要因だった。第 2 に、ボトムアップな層順スキャンが健全性の誤認を防ぐ。 L2 とインフラから制御プレーン、ホストローカル、サービスの順に証拠を積み上げる順序は、下位層の故障が上位層の症状として現れるという観測的な非対称性に基づく。これは第 16 章で見た Astral の階層相関と同じ構造を、逆向きに適用したものと読める。第 3 に、停止規則の明示化が探索の暴走を防ぐ。ベースラインの主要な失敗は「予算が尽きるまで探索を広げ続ける」か「反証せずに最初の仮説へ固執する」のいずれかであり、いずれも明示的な終了規則と反証規則の欠如に起因していた。ただし現時点の評価はエミュレーション環境が中心である。実運用ネットワーク(ハードウェア転送の挙動、NIC オフロード、ASIC レベルのキューイング、テレメトリ遅延)への転移で、層順スキャンの前提がどこまで崩れるかは未検証として残っている(Source: [[エージェント型ネットワーク障害診断]])。 ### 第 19 章　未解決の問い本 wiki のソースが明示的に残している問いのうち、本書の主題に直結するものを整理する。 **計装の統合。** 能動プローブ、受動トラフィック、フルスタック計装を併用したとき、計装オーバーヘッドと箇所特定精度をどう配分するのが最適か。スイッチデータプレーン、NIC と DPU、集団通信ライブラリ、物理部品の計測点をどう分業すれば、各手法が固定的に可視化する層を 1 つの診断パイプラインに束ねられるか。計測点ごとに見える異常が異なる以上、単一の計装では起因層を取り違えるという課題が、層をまたいで再帰しないか(Source: [[RDMAネットワーク監視]])。 **時間軸の接続。** PFC 連鎖輻輳の即時診断と光トランシーバー故障の事前予測を結べば、光リンクの物理劣化が PFC backpressure として顕在化する前に、劣化しつつあるリンクを先回りで切り離せるか。 Collie がデプロイ前に発見した MFS を本番監視の異常検知ルールへ事前知識として組み込めるか。 Lumina が発見した NIC 内部由来のシグナルを本番でリアルタイムに検知するには、どのような計装が必要か。 **粗粒度カウンタの活用。** PFC 一時停止カウンタの不均衡を既存の監視パイプラインへリアルタイムに統合すれば、スイッチデータプレーン計装なしにバースト性の負荷不均衡を検知できるか。ポート単位の分単位カウンタとホスト側のミリ秒級サンプリングを紐付けられない限界は、RDMA Estats や PFC プロベナンスのような細粒度手法と組み合わせて解消できるか。 **経路と箇所特定。** IB の Adaptive Routing 下では経路が固定されず、経路集約に基づく箇所特定が崩れる。トモグラフィ的な局所化をどう実現するか。 **ワークロードの前提。** 標準的な集合通信に従わないワークロードで、スケルトン推論の忠実度をどう事前に保証するか。 MoE の動的なエキスパート選択パターンを持つ AllToAllv では、ステップ定義が実行時に変化するため事前分解が困難になるが、どう対処するか。 **ベンダー横断。** mlx5 のカウンタ仕様は NVIDIA ConnectX 向けの一次資料だが、他ベンダーの RNIC カウンタ体系との対応関係は未整理である。 Lumina が報告する CX5 と E810 の相互運用性問題の一部は、両ベンダーのカウンタ意味論の食い違いに起因していないか。 **耐性と可視性。** 迂回機構を持つ設計では、個別の光モジュールの監視精度への要求をどこまで下げてよいか。逆に、迂回に頼りすぎると劣化の蓄積を見逃さないか。 NIC 側光モジュールのフラップが唯一 ride out できない障害だとすると、NIC 側の光設計でどこまで緩和できるか。 **運用の標準化。** マルチベンダー混在でスイッチごとに NOS が異なる場合、2 秒以下のマイクロバースト収集に向けた統一収集パイプラインをどう設計するか。 gNMIc の多重化と OpenTelemetry 移行のどちらが長期的に維持しやすいか。 --- ## 付録 ### A. 用語集 - **RDMA**:リモートホストのメモリへ CPU を介さず NIC が直接読み書きする通信機構。 - **QP(Queue Pair)**:送信キューと受信キューの対。データ自体でなく HCA 用のメタデータを保持する。 - **WQE(Work Queue Element)**:QP に積まれる作業要求のメタデータ。 - **CQE(Completion Queue Entry)**:完了キューに積まれる完了通知。市販 RNIC はこの生成時にタイムスタンプを出す。 - **verbs**:RDMA の標準 API。`ibv_reg_mr` や `ibv_post_send` など。 - **MR(Memory Region)**:RDMA 転送のために固定化して登録したメモリ領域。 - **RC / UC / UD**:信頼性と通信方式による IBA のトランスポート分類。実運用では RC と UD が使われる。 - **ワンサイドオペレーション**:リモート OS に検知されない Write と Read。 - **RoCEv2**:IBA のトランスポート層を UDP と IP の上に載せた Ethernet 上の RDMA。 - **PFC**:優先度単位でリンクの送信を停止させる L2 のフロー制御。 - **Headroom**:PFC 発動時の in-flight パケットを受け切るバッファの安全領域。 - **ECN と CNP**:輻輳を印付けして送信元へ通知する L3 と L4 の機構。 - **DCQCN**:ECN に基づく RDMA 向けのレート制御アルゴリズム。 - **INT**:通過パケットにテレメトリを埋め込むデータプレーン内計測。 - **プロベナンス**:ある事象の因果的な来歴。Hawkeye は PFC の来歴を辿る。 - **トモグラフィ的投票**:パス単位の観測からリンク単位の状態を逆算する手法。 - **グレイ障害**:App は不健全と観測しているのに Observer は健全と観測している状態。 - **fail-slow / fail-stop / fail-hang**:障害の顕在形。fail-slow と fail-hang は明示的な診断ログを出さない。 - **MFS(Minimal Feature Set)**:Collie が出す、性能異常を引き起こす最小の条件集合。 - **DDM**:光トランシーバーの電圧、バイアス電流、温度、Rx/Tx 光パワーを読み出す診断インターフェース。 ### B. 主要システムの一覧 | システム | 年 | 会議 | 計装点 | 時間軸 | 代表数値 | |---|---|---|---|---|---| | Pingmesh | 2015 | SIGCOMM | 全サーバの TCP/HTTP プローブ | 稼働中 | 1 日 2000 億件、CPU 0.26% | | DCQCN | 2015 | SIGCOMM | スイッチの ECN | 稼働中(制御) | PAUSE 6 百万件から約 3000 件 | | TIMELY | 2015 | SIGCOMM | NIC のハードウェアタイムスタンプ | 稼働中(制御) | 99%ile が PFC 比 9 倍低下 | | RoCE at Scale | 2016 | SIGCOMM | 設定監視、PFC カウンタ、RDMA Pingmesh | 稼働中 | 99%ile RDMA 90µs 対 TCP 700µs | | CorrOpt | 2017 | SIGCOMM | 光パワーと SNMP カウンタ(15 分) | 反応 | 35 万リンク、修復成功率 50% から 80% | | IRN | 2018 | SIGCOMM | NIC(スイッチ変更不要) | 稼働中(制御) | PFC なしで RoCE を 6 から 83% 上回る | | HPCC | 2019 | SIGCOMM | スイッチ ASIC の INT | 稼働中(制御) | 95%ile キュー 1.1 MB から 19.7 KB | | Collie | 2022 | NSDI | verbs API とカウンタ | デプロイ前 | 18 件の異常、うち 15 件が新規 | | Hostping | 2023 | NSDI | ホスト内ループバック | 稼働中 | 300 台超、10 種のボトルネック | | Husky | 2023 | NSDI | verbs の資源消費モデル | デプロイ前 | 1 Gbps の攻撃で 80 Gbps が 2 Gbps に | | Lumina | 2023 | SIGCOMM | プログラマブルスイッチによるイベント注入 | 仕様準拠検証 | 追加レイテンシ 0.4µs 未満 | | Azure Storage RDMA | 2023 | NSDI | RDMA Estats(4 点タイムスタンプ) | 稼働中 | トラフィックの約 70% が RDMA | | R-Pingmesh | 2024 | SIGCOMM | 市販 RNIC の UD QP と CQE | 稼働中 | 207 件を 20 秒で箇所特定、85% 正確 | | Meta RoCE | 2024 | SIGCOMM | OOS、リンクフラップ、LAT | 稼働中 | 24,000 GPU、CTS で P90 43µs が 4µs | | Alibaba HPN | 2024 | SIGCOMM | INT ベースの配線事前検証 | デプロイ前 | 8 か月で ToR 起因の単一障害点ゼロ | | MegaScale | 2024 | NSDI | ハートビート、CUDA イベント、RDMA トラフィック | 稼働中 | 100 回超の障害から自動復旧 | | Hawkeye | 2025 | SIGCOMM | P4 スイッチのデータプレーン | 反応 | 精度 90% 超、収集スイッチ 1/10 | | SkeletonHunter | 2025 | SIGCOMM | コンテナ sidecar とホストエージェント | 稼働中 | probing 2,034 秒が 25 秒、precision 98.2% | | Astral | 2025 | SIGCOMM | 4 層フルスタック | 稼働中 | MTTLF を最大 25 倍短縮 | | Vedrfolnir | 2025 | SIGCOMM(poster) | 待機グラフ + PFC プロベナンス | 反応 | Hawkeye 比 98% のテレメトリ削減 | | C4 | 2025 | HPCA | 集団通信ライブラリ(ACCL 拡張) | 反応 | ダウンタイム 31.19% が 1.16% | | LLMPrism | 2025 | DSN | スイッチ層ミラーリング | 稼働中 | 1 分で 19 ジョブ識別、タイムライン誤差 0.3% | | OptProphet | 2025 | APNET | 光トランシーバーの DDM(5 分) | 予防 | 予測 F1 0.884、平均 1.11 日前 | | Congestion Patterns | 2025 | IMC | switchos(分)と finecounters(4.8 ms) | 稼働中 | PFC が輻輳をコアへ 2 桁シフト | | Pulse | 2026 | ASPLOS | RNIC 組み込みプロセッサ(32µs) | 稼働中 | 12 中 10 でマシン単位、適合率 90% 超 | | VCCL | 2026 | arXiv | CCL 内蔵の WR/WC タイムスタンプ | 稼働中 | GPU 待機時間を約 90% 削減 | | MRC と SRv6 | 2026 | arXiv | トランスポート層の経路自己診断 | 稼働中 | 50K GPU で 4 リンクフラップを ride out | | RDMATracer | 2026 | NAIC | カーネル verbs とドライバの eBPF | 稼働中 | 13 hook、CPU 約 0.0000024% | ### C. 章とソースの対応 | 章 | 主要ソース | |---|---| | 1 から 3 | [[RDMA]], [[InfiniBand]], [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]], [[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]], [[@2024__SpeakerDeck__GPUネットワーク設計・運用基礎勉強会 Lossless Ethernet - PFC-ECN編]] | | 4 | [[@2018__IMC__A Large Scale Study of Data Center Network Reliability]], [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]], [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] | | 5 | [[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]], [[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]], [[@2025__IMC__Congestion Patterns in a Large-scale RDMA Datacenter]] | | 6 | [[@2017__SIGCOMM__Understanding and Mitigating Packet Corruption in Data Center Networks]], [[@2023__CCGrid__An Optical Transceiver Reliability Study based on SFP Monitoring and OS-level Metric Data]], [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]], [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]], [[@2026__NAIC__RDMATracer - A scalable eBPF-based framework for tracing RDMA syscalls]] | | 7 | [[グレイ障害]], [[集合通信]], [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]] | | 8 | [[RDMAネットワーク監視]] | | 9 | [[@2015__SIGCOMM__Pingmesh - A Large-Scale System for Data Center Network Latency Measurement and Analysis]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]], [[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]], [[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]] | | 10 | [[インバンドネットワークテレメトリ]], [[@2019__SIGCOMM__HPCC - High Precision Congestion Control]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]] | | 11 | [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]], [[@2023__NSDI__Empowering Azure Storage with RDMA]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]], [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]], [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] | | 12 | [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]], [[@2023__SIGCOMM__Understanding the Micro-Behaviors of Hardware Offloaded Network Stacks with Lumina]] | | 13 | [[@2023__LinuxKernelDocs__mlx5 Ethtool Counters]], [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]] | | 14 | [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]] | | 15 | [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]], [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]], [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]], [[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]] | | 16 から 17 | [[@2026__arXiv__Resilient AI Supercomputer Networking using MRC and SRv6]], [[RDMAネットワーク監視]] | | 18 | [[エージェント型ネットワーク障害診断]] | ### D. 数値を引用するときの注意 > [!warning] 本書の数値をそのまま自クラスタへ持ち込まない > 以下はいずれも出典側が明示している制約である。 - **障害率と AFR は母集団に強く依存する。** CorrOpt の破損統計は「既存の破損無効化システムが稼働している状態」での値であり、無ければ 2 桁高いと著者自身が見積もっている。 - **CorrOpt の対象はスイッチ間光リンクに限られる。** サーバーと ToR の間は「電気信号かつ短距離」として明示的に除外されており、NIC 側は検証されていない。 - **設定例は ASIC 依存である。** 第 2 章の Arista EOS の例は StrataXGS 前提で、DNX では異なる旨が出典に明記されている。Headroom も ASIC 固有パラメータからの計算が要る。 - **予測モデルの再現率は低い。** CCGrid の光トランシーバー故障予測は精度 72.8 から 95.7% に対し再現率 21.2 から 50.0% で、モニタリング情報だけでは故障の一部しか予測できない。 - **粒度の限界を数値と一緒に読む。** Meta の finecounters は 4.8 ms 以上のバーストしか捕捉できず、それより短いスパイクは過小サンプリングの可能性がある。ポート単位の分単位カウンタとホスト側サンプリングは紐付けられていない。 - **シミュレーション評価と本番評価を区別する。** IRN は商用ベンダー提供のシミュレータに依存し、当時は実機大規模本番検証がない。Vedrfolnir は NS3 のみで実機評価が未実施である。 - **単一組織単一ベンダーの検証にとどまるものがある。** RDMATracer の 4 つの経験則は Meta と Mellanox 系ドライバでの検証であり、他ベンダーへの一般化は限定的である。 - **既定設定の性能は参考にならない。** 3 システムいずれも既定設定は最適から程遠く、手動チューニングで最大 1 桁の差が出た。ベンチマーク値を比較するときはチューニング状態を揃える。 ### E. 関連 - 概念: [[RDMAネットワーク監視]] / [[RDMA]] / [[InfiniBand]] / [[RoCE設計課題]] / [[データセンター輻輳制御]] / [[インバンドネットワークテレメトリ]] / [[ホスト内ネットワークボトルネック]] / [[マルチテナントRDMA性能分離]] / [[サイレントパケットドロップ検知]] / [[グレイ障害]] / [[Fault Localization]] / [[障害予測]] / [[LLM学習モニタリング]] / [[集合通信]] / [[テレメトリ]] / [[ネットワーク監視]] - 姉妹編: [[LLM学習インフラ実運用の教科書]](学習基盤全体の運用) / [[NIC光トランシーバーのモニタリング]](光部品単体の監視) - 関連 MOC: [[HPC - MOC]] / [[分散深層学習 - MOC]]