# ホストネットワークとインターコネクトの教科書 Navigation: [[index]] | [[overview]] | [[conventions]] > [!abstract] この教科書について > サーバの内側でデータが CPU、メモリ、PCIe、NVLink、NIC をどう渡り歩くかを、層ごとに切り分けて整理した 11 章構成の教科書。 > UPI などのソケット間インターコネクトから、PCIe、CXL、NVLink、ホストネットワークスタック、RDMA、ホスト内輻輳制御、そしてスケールアウト網との接合と観測手法までを扱う。 > 本 wiki が持つ 59 本の source ページと 20 近い concept ページを横断して構成し、すべての数値と主張に出典を付した。 > 参照元から転載した図表 63 点を各章に配置している。図は本文の論証を目で追えるものに絞り、構造を示す図、本文が数値で語る現象の根拠グラフ、対比を裏づける比較表を優先した。 > 姉妹編として、ネットワーク側の可観測性を扱う [[RDMAネットワークモニタリングの教科書]] と、学習基盤全体の運用を扱う [[LLM学習インフラ実運用の教科書]] がある。 ## 目次 - [[#第1章 ホストネットワークという見方]] - [[#第2章 CPU ソケット内外のインターコネクトと NUMA]] - [[#第3章 PCIe: ホスト I/O の共通基盤]] - [[#第4章 スケールアップインターコネクト: NVLink とアクセラレータ間結合]] - [[#第5章 CXL: メモリ意味論を持つインターコネクト]] - [[#第6章 ホストネットワークスタック]] - [[#第7章 RDMA と NIC のマイクロアーキテクチャ]] - [[#第8章 ホスト内輻輳制御]] - [[#第9章 スケールアウト網との接合と物理層]] - [[#第10章 インターコネクトの観測と診断]] - [[#第11章 設計と運用の指針]] --- ## 第1章 ホストネットワークという見方 サーバの内部には、ネットワークがある。 プロセッサ、メモリ、周辺機器の各インターコネクトを統合し、ホスト内のデータ転送を担う経路の総体を、**ホストネットワーク**(host network)と呼ぶ (Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 この呼び方は比喩ではない。 ホストネットワークの内部には、送信側と受信側、経路上のホップ、バッファ、フロー制御、そして輻輳が、いずれも実体として存在する。 ホストネットワークを独立した対象として扱う必要が生じたのは、ホスト内部の帯域がホスト外部の帯域に追い越されはじめたからである。 RNIC の線速は 25Gb/s から 200Gb/s へ急増したのに対し、PCIe 帯域の伸びはそれに追いついていない (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 かつてホスト内部は、ネットワークから届いたパケットを取りこぼさずに受け止めるだけの余裕を持っていた。 その余裕が失われた結果、スイッチもケーブルも正常なのにアプリケーションのスループットが出ない、という事象が本番環境で観測されるようになった。 ![[_attachments/nsdi23-liu-kefei/fig02-host-topology.png]] **図1-1**:訓練用ホストの内部トポロジ。 2 基の Intel Xeon CPU が UPI で結ばれ、各 CPU の root complex に 4 基の Nvidia A100 GPU と 2 基の Mellanox CX6-DX 200Gb/s RNIC が複数の PCIe スイッチを介してぶら下がる。 ①から⑤は著者らが実際に遭遇したリンク障害(RNIC PCIe、GPU PCIe、CPU root port、メモリチャネル、UPI)の位置を、⑥はトラフィック輻輳によるホスト内帯域劣化の位置を指す。 (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) ### 1.1 ホスト内部を階層として捉える ホストネットワークは単一の均質な媒体ではなく、性質の異なる複数の層が直列につながった構造をしている。 本書はこの構造を五つの層に分けて扱う。 - **ソケット内インターコネクト**:一つの CPU ソケットの内部で、コア群、LLC と CHA(キャッシュホームエージェント)、IIO(統合 IO コントローラ)、MC(メモリコントローラ)を結ぶ mesh 網。PCIe デバイスはこの IIO にぶら下がる (Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 - **ソケット間インターコネクト**:Intel の QPI と UPI、AMD の HyperTransport と Infinity Fabric が担う、ソケットどうしの結合。NUMA という非一様性はここから生じる。 - **ホスト I/O インターコネクト**:PCIe を共通基盤とし、その上に CXL のようなメモリ意味論を持つプロトコルが積み上がる層。 - **スケールアップインターコネクト**:NVLink と NVSwitch、あるいは Infinity Fabric によるアクセラレータどうしの直接結合。 - **スケールアウトインターコネクト**:NIC を境界として、Ethernet または InfiniBand でホストの外へ出る層。 層の境界は固定されていない。 CXL は PCIe の物理層を借りながらメモリ意味論を持ち込む点で、ホスト I/O 層とメモリ層の境界を動かした。 Scale-Up over Ethernet の議論は、これまでスケールアップ専用の技術が占めていた領域に Ethernet を持ち込もうとしている。 本書が層を分けるのは、境界が動かないと主張するためではなく、どの層で何が律速しているのかを切り分ける道具を得るためである。 ### 1.2 層をまたいで繰り返し現れる三つの性質 異なる層を扱う各章には、同じ性質が別の姿で繰り返し現れる。 読み進めるにあたって、あらかじめ三つを挙げておく。 第一に、公称帯域と実効帯域は一致しない。 PCIe では TLP のヘッダオーバーヘッドとフロー制御が、Ethernet では符号化と FEC が、それぞれリンク速度の一部を消費する。 どの層でも、仕様書の数値をそのままアプリケーションが受け取ることはない。 第二に、インターコネクトは非対称である。 NUMA ノード間のリンクは幅も方向も本数も一様ではなく、最良のスレッド配置はホップ数ではなく総帯域で決まる (Source: [[@2015__ATC__Thread and Memory Placement on NUMA Systems - Asymmetry Matters]])。 同じ非対称性は、GPU 対ごとにリンク本数が異なるアクセラレータ結合にも現れる (Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 非対称性を無視した経路選択は、平均的には妥当に見えて特定の組み合わせで大きく劣化する。 第三に、輻輳はネットワークの専売ではない。 ホストネットワーク内の競合は、資源の絶対的な不足ではなく、プロセッサとメモリと周辺機器のインターコネクト間の相互作用の悪さから生じる (Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 この観察には、輻輳制御という発想をホスト内部へ持ち込む余地があるという含意がある。 第8章で扱うホスト内輻輳制御は、その含意を設計として具体化したものである。 ### 1.3 ドメインごとのフロー制御という抽象化 ホスト内部を「ネットワーク」として扱う見方に、具体的な形を与えたのが**ドメインごとのクレジットベースフロー制御**(domain-by-domain credit-based flow control)である (Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 この抽象化では、ホストネットワークを複数のドメイン(内部のサブネットワーク)に分解し、各ドメインが独立にクレジットベースのフロー制御を行うとみなす。 送信側にはクレジットが割り当てられ、リクエスト 1 件の送信ごとに 1 クレジットを消費し、受信が確認されると補充される。 この見方が有効なのは、ドメインごとにクレジット数と経路長が異なるためである。 リクエストの発生源(コアか周辺機器か)と種別(読みか書きか)の組み合わせで、通過するドメインは変わる。 たとえば C2M-Write ドメインは LFB から CHA までの 1 ホップで完結し MC を含まないのに対し、P2M-Write ドメインは IIO から MC までの 2 ホップを含む (Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 経路が違えば、同じ競合に対して劣化の現れ方も違う。 メモリ帯域が飽和していない段階でコア由来のトラフィックだけが劣化し、周辺機器由来のトラフィックは無傷という現象が観測されるのは、この非対称な構造の帰結である。 ![[_attachments/Understanding-the-Host-Network/fig05-domain-credit-flow-control.png]] **図1-2**:ホストネットワークを四つのドメインへ分解した図。 C2M-Read ドメインは LFB から DRAM まで、C2M-Write ドメインは LFB から CHA まで、P2M-Read ドメインは IIO から DRAM まで、P2M-Write ドメインは IIO から MC までを覆う。 黄色のノードがそのドメインでクレジットを保持する送信側にあたり、ドメインごとに通過ホップ数(ドメインレイテンシ)とクレジット数が異なる。 (Source: [[@2024__SIGCOMM__Understanding the Host Network]]) ![[_attachments/Understanding-the-Host-Network/fig01-c2m-p2m-colocation-degradation.png]] **図1-3**:コア由来のトラフィックだけが劣化する様子。 (a) Redis(C2M)と FIO(P2M)を同居させると Redis は 1.25 倍から 1.32 倍のスループット劣化を示す一方、FIO は無傷である。 (b) GAPBS(C2M)も 1.28 倍から 1.98 倍劣化し、FIO は無傷のままである。 (c)(d) この劣化は、メモリ帯域利用率が理論最大の 33% から 53%(Redis 時)にとどまり飽和曲線が横ばいになっていない段階で発生している。 (Source: [[@2024__SIGCOMM__Understanding the Host Network]]) 古典的な計算機ネットワークの用語で言えば、この抽象化は既存の二つのフロー制御機構の一般化にあたる。 TCP のようなエンドツーエンド型は経路全体が単一ドメインである特殊な場合に、PFC を用いる RDMA のようなホップバイホップ型は各ホップが 1 ドメインである特殊な場合に、それぞれ対応する (Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 ホスト内部の議論にネットワークの語彙をそのまま持ち込めるのは、両者が同じ枠組みの中に置けるからである。 ### 1.4 本書の構成 第2章から第5章までは、ホスト内部のインターコネクトを層ごとに扱う。 第2章は CPU ソケットの内外、すなわち mesh 網と UPI などのソケット間バス、およびそこから生じる NUMA を扱う。 第3章は PCIe を、第4章は NVLink を中心とするスケールアップインターコネクトを、第5章は CXL を扱う。 第6章から第8章までは、そのインターコネクトの上でソフトウェアが何をしているかに移る。 第6章はホストネットワークスタック、第7章は RDMA と NIC のマイクロアーキテクチャ、第8章はホスト内輻輳制御である。 第9章はホストの境界を越えてスケールアウト網と物理層に触れ、第10章は全層を通じた観測と診断の手法を整理する。 第11章では、各章の知見を設計と運用の判断に落とし込む。 ### 未解決の問い - ドメインごとのクレジットベースフロー制御は単一ソケット内で定式化されたが、UPI を越えるソケット間トラフィックや CXL 接続メモリへのアクセスを同じ枠組みで記述できるか。 - ホスト内部の層をまたぐ律速点を、アプリケーションから見た単一の指標で表現する方法はあるか。層ごとの個別指標を並べる以上のことができるか。 - 層の境界が動き続けるなかで(CXL によるメモリ層への侵入、Ethernet のスケールアップ層への侵入)、層に基づく切り分けはいつまで有効か。 --- ## 第2章 CPU ソケット内外のインターコネクトと NUMA NIC が DMA で書き込む先の DRAM は、ホストの中で一様な資源ではない。 その DRAM がどのソケットに属し、どのメモリコントローラの配下にあり、どのリンクを経由して到達されるかによって、同じ転送でもレイテンシと帯域が変わる。 第1章で見たホスト内経路の全体像を、ここではソケットの内側と外側という二つの層に分けて解剖する。 ソケットの内側では、コア群とキャッシュ、キャッシュコヒーレンシを司るエージェント、メモリコントローラ、そして PCIe デバイスの入口が一つのインターコネクトで結ばれている。 ソケットの外側では、複数のソケットが専用のリンクで結ばれ、そのリンクの向こう側にあるメモリが「遠い」メモリになる。 NUMA(Non-Uniform Memory Access)とは、この二層構造の帰結として、メモリへのアクセス時間がアクセス元との相対的な距離によって変わる状態を指す(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]])。 この章の主張は二つある。 第一に、NUMA の距離は「ローカルか否か」という二値では表しきれず、リンクの帯域という連続量で捉えたほうが実測をよく説明する。 第二に、NIC は GPU と同じく特定のソケットにぶら下がる I/O デバイスであり、NUMA 配置の問題はメモリアクセスの最適化と同じ枠組みでネットワーク I/O にも及ぶ。 ### 2.1 ソケット内部のインターコネクト #### core と uncore という二分法 現代の Intel サーバ CPU のソケットは、コアとその専有キャッシュからなる core 部分と、それ以外の共有資源からなる **uncore** 部分に分かれ、両者は mesh インターコネクトで接続される。 uncore はメモリコントローラ(MC)、LLC とそれを管理する CHA、統合 IO コントローラ(IIO)、そしてソケット間インターコネクトである UPI から構成される。 RNIC や GPU や NVMe SSD といったアクセラレータは、この IIO を経由して PCIe ドメインに接続される(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 AMD のプロセッサも同様のアーキテクチャを持つと同論文は述べている。 ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig01-intra-host-network-architecture.png]] **図2-1**:Intel CPU ソケットの core と uncore の構成。 両者は mesh インターコネクトで接続され、uncore はメモリコントローラ、LLC/CHA、IIO(統合 IO コントローラ)、UPI(ソケット間インターコネクト)から成る。 RNIC や GPU や NVMe SSD といったアクセラレータは IIO を経由して PCIe ドメインに接続される。 (Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]]) この構図が意味するのは、NIC からメモリへのデータパスがコアからメモリへのデータパスと同じ uncore を共有するということである。 NIC は独立した配管でメモリに書き込むのではなく、コアが使うのと同じ mesh と同じメモリコントローラを通る。 ホスト内輻輳という現象が成立するのは、この共有があるからである。 #### CHA と IIO と MC の役割分担 より細かく見ると、ソケット内部は L1/L2 を持つコア群、LLC、**CHA**(Caching and Home Agent、LLC とメモリを抽象化しキャッシュコヒーレンシを維持する)、**IIO**(周辺機器が PCIe 経由で接続する統合 IO コントローラ)、**MC**(DRAM への読み書きを制御するメモリコントローラ)から成る(Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 コア由来のトラフィック(C2M)は、L1 ミス時に LFB(Line Fill Buffer)へ登録され、L2、CHA/LLC を経て MC のキューに入る。 周辺機器由来のトラフィック(P2M)は、デバイスが IIO へ DMA リクエストを出し、IIO が CHA へ転送する。 ![[_attachments/Understanding-the-Host-Network/fig04-host-network-architecture.png]] **図2-2**:ソケット内部のデータパスをホップ単位で描いた図。 コア(L1/L2 キャッシュ付き)、LFB、CHA/LLC、IIO、MC(RPQ と WPQ)、DRAM バンクの接続関係が示される。 C2M は L1 ミス時に LFB へ登録され、L2、CHA/LLC を経て MC の RPQ/WPQ にキューイングされる。 P2M は周辺機器が IIO へ DMA リクエストを出し、IIO が CHA へ転送する経路をたどる。 (Source: [[@2024__SIGCOMM__Understanding the Host Network]]) 同論文は、この経路をクレジットベースのフロー制御が及ぶ範囲によって四つのドメインに分解した。 C2M-Read ドメインは LFB から DRAM までの全ホップにまたがり、C2M-Write ドメインは LFB から CHA までの単一ホップにとどまる(書き込みは DRAM へ非同期にサービスされるため MC を含まない)。 P2M-Read ドメインは IIO から DRAM までの全ホップに、P2M-Write ドメインは IIO から MC までの二ホップにまたがる。 無負荷時のドメインレイテンシは、C2M-Read が約 70ns、C2M-Write が約 10ns、P2M-Write が約 300ns と実測された(Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 | ドメイン | 範囲 | クレジットの律速点 | 無負荷レイテンシ | |---|---|---|---| | C2M-Read | LFB から DRAM | LFB サイズ(10〜12 キャッシュライン) | 約 70ns | | C2M-Write | LFB から CHA | LFB サイズ(同上) | 約 10ns | | P2M-Read | IIO から DRAM | IIO 読み取りバッファ(下限 164 キャッシュライン以上) | 記載なし | | P2M-Write | IIO から MC | IIO 書き込みバッファ(約 92 キャッシュライン) | 約 300ns | (Source: [[@2024__SIGCOMM__Understanding the Host Network]]) 書き込みに限れば、I/O デバイス起点の経路はコア起点の経路より一桁以上長い。 理由は経路の物理的な長さそのものというより、ドメインの終端が異なることにある。 C2M-Write は CHA で完了したとみなされるのに対し、P2M-Write は MC まで到達しないと完了しないため、MC の書き込みキューが埋まったときの背圧を直接受ける。 この違いは、メモリ帯域が飽和したときに C2M と P2M のどちらが先に劣化するかを分ける(Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 なお、この分解は単一ソケット、単一 IIO、Intel の二世代のプロセッサに限定された検証であり、著者ら自身がマルチソケットや AMD プロセッサ、CXL や NVLink のような新しいインターコネクトへの拡張を今後の課題としている(Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 つまり、ソケット内部の精密なモデルと、次節以降のソケット間の議論は、まだ一本の式では結ばれていない。 ### 2.2 ソケット間インターコネクトと NUMA の成立 NUMA は設計上の選択というより、共有バスの限界に対する回答として生まれた。 初期のマルチプロセッサはシステムバス(フロントサイドバス)でプロセッサを接続していたが、プロセッサ数が増えると競合によってスケーラビリティの問題が生じる。 そのため、最近のサーバは Intel の QPI や UPI、AMD の HyperTransport といった CPU インターコネクトでプロセッサ間をプライベートに接続し、競合を避ける構成を取る(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.4.1.5)。 この構成では、各プロセッサが自身のメモリバンクを直接持つ。 CPU が自身にメモリバスで直結された DRAM にアクセスするのがローカルメモリ(1ホップ)、他の CPU のメモリにインターコネクト経由でアクセスするのがリモートメモリ(2ホップ以上)であり、後者のレイテンシが高い(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.3.1.2)。 個々の CPU に接続されたメモリバンクをメモリノードと呼び、OS はプロセッサから得られる情報に基づいてこのトポロジを認識し、ローカルメモリを優先する配置とスケジューリングを行う場合がある。 ![[_attachments/systems-performance-2nd-ja/ch07-fig7-4-numa-architecture.png]] **図2-3**:2 プロセッサ NUMA アーキテクチャの例。 CPU 1 は DRAM A へ 1 ホップ(ローカルメモリ)で到達するのに対し、DRAM B へは CPU インターコネクトを介した 2 ホップ(リモートメモリ)で到達し、後者のレイテンシが高い。 (Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]]) 系譜としては、AMD が Opteron 世代で HyperTransport による分散アーキテクチャを先に採り、Intel が QPI で追随し、それぞれ Infinity Fabric と UPI へと発展した。 Opteron のプロセッサはコアと HyperTransport クロスバーを内蔵し、クロスバーがローカルメモリバンクへの直接パスと、他プロセッサや I/O チップセットへの 1 本から 3 本の HyperTransport リンクを提供する(Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]])。 I/O チップセットが特定の NUMA ノードに近接して接続されるという構図は、この時点ですでに現れている。 ### 2.3 距離のコスト階層 NUMA の距離を実感するには、キャッシュ階層からリモート DRAM までを一続きの階層として見るとよい。 書籍の一般論では、レベル 1 キャッシュのアクセスは数サイクル、レベル 2 は 10 サイクル前後、メインメモリアクセスは約 240 サイクル(4GHz で約 60ns)とされる(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.4.1.3)。 より具体的な実測として、Nehalem 世代の 8 コアプロセッサを 8 ソケット構成にしたサーバでは、L1 が 4 サイクル、L2 が 10 サイクル、L3 共有キャッシュが 60 サイクル、そしてローカル DRAM を経て 1 ホップ先の DRAM が約 420 サイクルという階層が報告されている。 さらに QPI を跨ぐと約 100 サイクルが上乗せされる(Source: [[@2013__JPUG__性能測定道 事始め編]])。 ただしこの数値は講演の口頭説明のみを根拠としており、対応するスライド画像で裏取りできていないと出典ページ自身が明記しているため、桁の感覚として受け取るのが妥当である。 より新しい世代では、GPU サーバの文脈でローカル NUMA ノードのメモリアクセスレイテンシが約 80ns、リモートが約 139ns、すなわち約 75% 増という数値が報告されている(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]])。 hwloc 論文はこの比をローカル/リモートメモリアクセス比(NUMA ファクタ)と呼び、典型的には 1.1 から 1.5、時に 3 に達すると述べている(Source: [[@2010__PDP__hwloc a Generic Framework for Managing Hardware Affinities in HPC Applications]])。 世代とマシン構成によって幅はあるが、リモートアクセスのペナルティは数十パーセントから数倍という帯に収まる。 ネットワーク I/O の側から測ると、1 ホップあたりのコストはさらに小さく見える。 Moreaud と Goglin は 2 ソケットの Opteron マシンで、NIC への小要求ラウンドトリップレイテンシが近接ノードと遠隔ノードで 55ns から 95ns しか変わらず、これが 1 HyperTransport ホップあたり約 40ns のオーバーヘッドに相当することを示した(Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]])。 8 ソケットマシンでも、追加のホップごとに片道レイテンシが約 40ns 増えるという線形性が確認されている。 この 40ns が問題になるかどうかは、基準となるレイテンシに依存する。 Myri-10G の約 2.5µs という基準レイテンシに対しては約 25ns(2%)のオーバーヘッドにすぎず、InfiniBand ではさらに無視できる水準になる。 一方、Quadrics Elan4 の Put/Get 操作は基準レイテンシが約 1µs と低いため、遠隔配置による 100ns のオーバーヘッドが全体で約 20% の差になる(Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]])。 ### 2.4 非対称インターコネクト レイテンシで見た NUMA は穏やかだが、帯域で見ると様相が変わる。 同じ 2 ソケットマシンで帯域を測ると、プロセッサ起点のメモリアクセスは読み取りで 31%、書き込みで 38% 低下し、NIC の DMA 書き込みは InfiniBand で 23%、Myri-10G で 24% 低下した(Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]])。 理論帯域が大きいインターコネクトほど遠隔配置の影響を強く受け、900MB/s 級の Elan4 では帯域の低下が観測されなかった。 さらに踏み込んだのが Lepers らの観察である。 彼らは 8 ノードの AMD Opteron 6272 マシンで、ノード間リンクがリンク幅(8bit と 16bit と両者の混在)、方向性(一部のパスは単方向)、共有関係(1 本のリンクを 6 ノードが共有する例がある)のいずれにおいても均一でないことを示した(Source: [[@2015__ATC__Thread and Memory Placement on NUMA Systems - Asymmetry Matters]])。 これが **非対称インターコネクト** であり、任意のノード対間のリンクが同一の帯域とレイテンシを持つという従来の暗黙の仮定を崩す。 ![[_attachments/atc15-paper-lepers/fig01-numa-topology.png]] **図2-4**:非対称なノード間トポロジ。 リンク幅は 8bit、16bit、16bit と 8bit の混在の 3 種類があり、一部のパス(ノード 7 からノード 3)は単方向である。 1 本のリンクが複数ノードに共有される場合もあり、ノード 2 と 3 の間のリンクはノード 0、1、2、3、6、7 が共有する。 machine A は 64 コア(ノードあたり 8 コア)、machine B は 48 コア(ノードあたり 6 コア)である。 (Source: [[@2015__ATC__Thread and Memory Placement on NUMA Systems - Asymmetry Matters]]) 非対称性の効果は大きい。 24 スレッドで 3 ノードを使う 20 種類のアプリケーションについて、使うノードの組み合わせだけを変えて比較すると、最良と最悪の性能差は最大 237%(facerec)、平均で 40%、中央値で 14% に達した。 streamcluster を 2 ノード 16 スレッドで走らせた詳細分析では、ノード対の選び方だけで性能が最大 133% 変動し、しかも 2 ホップの構成が 1 ホップの構成より速い場合があった(Source: [[@2015__ATC__Thread and Memory Placement on NUMA Systems - Asymmetry Matters]])。 ![[_attachments/atc15-paper-lepers/fig02-perf-diff-single-app.png]] **図2-5**:24 スレッドで 3 ノードを使って実行した各アプリケーションについて、平均的な配置に対する最良配置と最悪配置の性能差(%)。 graph500、specjbb、streamcluster、pca、facerec は差が大きいため別軸で表示されている。 (Source: [[@2015__ATC__Thread and Memory Placement on NUMA Systems - Asymmetry Matters]]) ここから導かれる定式化が、この章のもっとも実用的な帰結である。 最良の性能を出す配置は、ホップ数が最小のものではなく、総帯域が最大のものである。 機構としては、レイテンシがホップ数ではなくそのパスで得られる帯域と相関するためで、実際に Table 1 では実行時間とメモリレイテンシと帯域が一貫した順序で並ぶ。 この非対称性は世代とともに強まる傾向がある。 同じ streamcluster を 4 台のマシンで測ると、最良と最悪の差は 64 コア機で 133%、48 コア機で 85%、24 コア機で 33%、16 コア機で 3% であった(Source: [[@2015__ATC__Thread and Memory Placement on NUMA Systems - Asymmetry Matters]])。 全ノード間のリンク帯域が等しい 16 コア機では差がほぼ消えることから、差の源がリンク構成の多様さにあることが確認できる。 なお、この二つの研究はいずれも AMD Opteron 系での評価であり、Intel の QPI や UPI を持つシステムで同じ結論がどこまで成り立つかは、両論文とも将来課題として残している(Source: [[@2015__ATC__Thread and Memory Placement on NUMA Systems - Asymmetry Matters]])。 ### 2.5 I/O 方向の非対称性 NUMA 配置の効果は、データの移動方向によっても非対称になる。 Moreaud と Goglin は、DMA read が NUMA 効果をほとんど受けない一方、DMA write のみが劣化することを見出した(Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]])。 さらに RDMA Write では、書き込み先バッファの物理配置がスループットを左右する一方、送信側バッファの配置はほぼ影響しない。 同じ非対称性は send/receive でも RDMA read でも観測され、いずれもデータが書き込まれる側のバッファ配置だけが効いていた。 著者らはこの原因を、HyperTransport 仕様上リクエストバッファとレスポンスバッファの数が非対称であることに起因するバス飽和ではないかと推測している。 ただしこれは推測であり検証されていないと論文自身が明記しており、BIOS でのチューニングも本番環境では現実的でないとされる。 現行の PCIe Gen5 や CXL 世代のインターコネクト、あるいは CPU を持たない NUMA ノードで同じ非対称性が観測されるかは未検証である。 ホップ数についても、単純な線形モデルは成り立たない。 8 ソケットマシンでの RDMA Write の測定では、遠隔配置になった時点でスループットが低下するが、ホップ数をさらに増やしても追加の劣化は生じなかった(Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]])。 レイテンシはホップ数に線形に増える一方、帯域は「ローカルかどうか」の閾値的な振る舞いをするという、二つの指標の乖離がここに現れている。 ![[_attachments/Moreaud--Goglin-Impact-of-NUMA-Effects-on-High-Speed-Networking-with-Multi-Opteron-Machines/fig05-rdma-write-8socket.png]] **図2-6**:8 ソケットマシンにおける受信側 NUMA ノード位置別の RDMA Write スループット。 遠隔配置になった時点でスループットは低下するが、HyperTransport のホップ数をさらに増やしても追加の性能低下は生じない。 (Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]]) ### 2.6 トポロジをソフトウェアで扱う #### 配置ミドルウェア 非対称性への対応は、いずれも「OS の既定の配置だけでは足りない」という共通の出発点から始まる。 Moreaud と Goglin は Linux 2.6.21 にパッチを当て、各 PCI デバイスが接続されている NUMA ノードをカーネルが公開するようにしたうえで、NEWMADELEINE ミドルウェアがこの情報を InfiniBand と Myri-10G のドライバから取得し、ライブラリ初期化時に通信タスクとバッファを NIC 近接のノードへ自動的にバインドする実装を示した(Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]])。 Lepers らの AsymSched は、実行時の継続的な再配置という異なる粒度で同じ問題に対処する。 ユーザレベルプロセスとして動作し、ハードウェアカウンタで CPU 間および CPU とメモリ間の通信量を測り、通信量の多いスレッドクラスタを帯域の大きいノード集合へ動かす。 配置候補は組合せ爆発するため、通信集約型アプリケーションが 2 ノードを使う場合は 16bit リンクで結ばれたノード対のみを候補にし、帯域が等価な配置には同一のハッシュを割り当てて重複を省くというヒューリスティックで、計算対象の 67% から 99% を削減した(Source: [[@2015__ATC__Thread and Memory Placement on NUMA Systems - Asymmetry Matters]])。 移行コストも実装上の障壁になるため、標準の `migrate_pages` が 10GB の移行に平均 51 秒かかるのに対し、ロックフリーかつ並列な独自システムコールで平均 17 倍、複数ノードペアの同時移行では最大約 34 倍の高速化を得ている。 #### hwloc によるトポロジ抽象化 配置を決めるには、まず機械の形を知る必要がある。 **hwloc**(Hardware Locality)は、プロセッサソケット、キャッシュ、コア、NUMA メモリノードなどを Node や Socket や Cache や Core といった型を持つ汎用オブジェクトの木構造として表現し、OS 非依存の API として公開する(Source: [[@2010__PDP__hwloc a Generic Framework for Managing Hardware Affinities in HPC Applications]])。 設計上の要点は、既存のオブジェクト型の存在や木構造上の相対的な深さについて仮定を置かないことにある。 ソケットとコアの間に新種の資源が入る、キャッシュがプロセッサ外に移る、NUMA ノードがソケット内部に来るといった将来の変化に対して、抽象の側を作り直さずに済ませるためである。 hwloc が提供する近接度は、NUMA ノード単位よりも細かい。 2 ソケットのクアッドコア Xeon E5345 では、コアがペアごとに 4MB の L2 キャッシュを共有するため、2 スレッドがデータを共有するなら同じ L2 を持つコアへ、各々が L2 をフルに使いたいなら別の L2 群へ、メモリ帯域が重要ならソケットをまたぐコアへバインドするのが望ましい、という判断が成り立つ(Source: [[@2010__PDP__hwloc a Generic Framework for Managing Hardware Affinities in HPC Applications]])。 つまり NUMA 対応の配置は、NUMA ノード単位とソケット単位と共有キャッシュ単位という入れ子の粒度を持つ。 トポロジ情報が効くことは、独立した三つの応用で確認されている。 FORESTGOMP のキャッシュ親和性を考慮したスレッド配置は 16 コアホストで 14 倍の高速化を達成し(トポロジ非認識版は 8.52 倍)、SCOTCH による MPI プロセス配置は NAS CG カーネル(64 プロセス)でラウンドロビン比 26%(Class C)と 8%(Class D)の改善をもたらした。 KNEM の Large Message Transfer では、I/OAT へのオフロード閾値を `DMAmin = キャッシュサイズ / (2 × キャッシュを使うプロセス数)` として動的に決定できることが導かれている(Source: [[@2010__PDP__hwloc a Generic Framework for Managing Hardware Affinities in HPC Applications]])。 実務側では、`lstopo(1)` の出力が論理 CPU とコアとキャッシュ、そして PCI デバイスの対応を可視化する(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.6.21)。 #### CPU ピニングとメモリバインド もっとも素朴な対応策は、プロセスとそのメモリを明示的に固定することである。 CPU だけを縛る手段としては `taskset(1)` によるアフィニティ設定と cpuset があり、排他的な cpuset にすればほかのプロセスがその CPU 群を使えなくなるためキャッシュのウォーム度が保たれる(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.9.6, §6.9.7)。 メモリまで含めて縛るには `numactl(8)` の `--membind` と `--physcpubind` を併用し、プロセスを 1 ソケットに制限する(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.6.4)。 配置の成否は `numastat(8)` の numa_hit と numa_miss と numa_foreign で確認できる。 CPU バインドとメモリバインドは別レイヤーの操作であり、前者だけでは足りない。 GPU ワークロードでは、`nvidia-smi topo -m` で GPU ごとの NUMA アフィニティを取得し、各プロセスを対応するノードの CPU とメモリの両方にバインドする運用が取られ、実運用で 5% から 10% のスループット改善とジッタ低減が報告されている(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]])。 Linux の既定の NUMA バランシングだけではスケジューラがプロセスをノード間で移動させうるため、明示的な固定が必要になるという判断である。 ### 2.7 ネットワーク I/O にとっての NUMA ここまでの議論を NIC の側から読み直すと、NIC は GPU と同じ種類のデバイスである。 どちらも IIO を経由して特定のソケットの PCIe ドメインにぶら下がり、どちらもそのソケットのメモリコントローラを通ってメモリに到達する(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 したがって NUMA 対応ピニングの適用対象は GPU に限られず、I/O デバイス全般に一般化できる。 実際、GPU ワークロードでの 5% から 10% の改善と、NIC 近接配置による最大 40% の帯域改善は、同一のハードウェア制約に由来する同型の現象である(Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]], [[@2025__OReilly__AI Systems Performance Engineering - Chapter 3 OS, Docker, and Kubernetes Tuning for GPU-Based Environments]])。 配置の失敗が RDMA でどう現れるかも測定されている。 RHCC の評価では、cross-NUMA のメモリアクセストラフィックは local-NUMA と比べてスループットを最大 24% 低下させ、PFC 一時停止も増やす。 機構としては、cross-NUMA アクセスがより複雑でレイテンシの大きいキャッシュコヒーレンシ処理を要するためである。 local-NUMA と cross-NUMA を同数のコアで混在させた場合はさらに悪化し、local-NUMA 比で最大 40% のスループット低下を示す。 これは双方向の cross-NUMA キャッシュコヒーレンシが UPI リンクの帯域に圧力をかけ、より多くのメモリ帯域を消費するためである(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig06-cross-numa-network-perf.png]] **図2-7**:cross-NUMA 配置が RDMA の性能に与える影響。 cross-NUMA トラフィックは local-NUMA と比べスループットを最大 24% 低下させ、PFC 一時停止も増やす。 local-NUMA と cross-NUMA を同数のアクティブ CPU コアで混在させた hybrid トラフィックはさらに悪化し、local-NUMA 比で最大 40% のスループット低下を示す。 PFC-free のシナリオでも同様の傾向が確認されている。 (Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]]) つまりソケット間インターコネクトは、リモートメモリアクセスの通り道であるだけでなく、キャッシュコヒーレンシトラフィックの通り道でもある。 NUMA をまたぐ配置の代償は、明示的なデータ移動量からは見えないところにも現れる。 将来のアーキテクチャがこの問題を消してくれると考えるのは早い。 NVLink-C2C は CPU と GPU を約 900GB/s のキャッシュコヒーレントなリンクで結び、PCIe Gen5 x16 の約 64GB/s(片方向)を一桁上回るが、Grace CPU の LPDDR5X への C2C 経由のアクセスは HBM への直接アクセスと比べて約 1 桁低い帯域と高いレイテンシを持つ(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 2 AI System Hardware Overview]])。 統合メモリ空間が提供されても、頻出データを HBM に留め CPU メモリはオーバーフロー用途とする、という配置の判断は残る。 リンクを速くしても非均一性そのものは消えず、境界の位置が移動するだけである。 帯域の増加が比例した性能向上を生まないという構図は、ホストの外側でも観測されている。 GPU データ処理の分析では、L4 から GH200 へメモリ帯域が 13.4 倍になっても TPC-H の性能改善は 5.2 倍にとどまり、命令スループットの増加が 2.5 倍しかないことがボトルネックとして残る(Source: [[@2026__arXiv__Over the Memory Wall, Into the Instruction Wall - The New Bottleneck in GPU Data Processing]])。 これは GPU 内部の話であってソケット間インターコネクトの話ではないが、「一つの資源だけを太くしても律速点が移るだけ」という同じ教訓を与える。 ### 未解決の問い - ソケット内部を四つのクレジットドメインに分解するモデル(Source: [[@2024__SIGCOMM__Understanding the Host Network]])は単一ソケットでのみ検証されており、UPI をまたぐ経路を含めたときにドメインの境界とクレジット数がどう変わるかは示されていない。 - 非対称インターコネクトの実測は AMD Opteron 系に限られており、Intel の QPI や UPI を持つシステムで「最良の配置は総帯域で決まる」という定式化がどこまで成り立つかは未検証である。 - RDMA/DMA 書き込みで書き込み先バッファの配置のみが効くという非対称性は HyperTransport 世代の観測であり、現行の PCIe Gen5 や CXL 世代、あるいは CPU を持たない NUMA ノードで再現するかは確認されていない。 - 「総帯域が最大の配置を選ぶ」という基準は CPU とメモリ間の通信を対象に定式化されたが、NIC や GPU のような I/O デバイスを含む配置問題に同じ目的関数をそのまま適用できるかは示されていない。 - hwloc が想定する木構造の抽象は、GPU や NVLink や CXL メモリのようなヘテロジニアスな資源をどこまで無改造で表現できているか。hwloc 論文自身が I/O デバイスと GPGPU のトポロジツリーへの追加を今後の課題として挙げた時点から、どこまで進んだかは本ソース群では確認できない。 --- ## 第3章 PCIe: ホスト I/O の共通基盤 サーバの内側でNIC、GPU、NVMeデバイスをCPUとメモリに結びつけているのは、ほとんどの場合PCIeである。 ネットワークの議論はスイッチとケーブルの帯域に集中しがちだが、パケットがNICに到達したあとホストメモリへ運ばれる区間もまた、帯域と遅延を持つ一本のネットワークである。 この区間の性能を決める規則は、イーサネットやInfiniBandのそれとは異なる。 PCIeはポイントツーポイントのシリアル接続であり、輻輳制御ではなくクレジットベースのフロー制御で動き、ルーティングではなくツリー構造上のアービトレーションで帯域を配分する。 PCIeが独立した設計対象として扱われるようになったのは比較的最近である。 40Gb/s以上のNICが一般化し、単一デバイスの要求帯域がPCIeリンクの能力に迫るか、それを超えるようになって初めて、ハードウェアとソフトウェアの協調設計が必要になった(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 RNICの線速が25Gb/sから200Gb/sへ一桁近く伸びる一方でホスト内帯域の伸びが追いつかず、ホスト内ネットワークがRDMA通信の新たなボトルネックになりつつあるという指摘も、同じ構造的な問題を運用の側から述べたものである(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 PCIeの実効性能を決める要因は三つの層に分かれる。 プロトコル自体のオーバーヘッド、ルートコンプレックス側のホストアーキテクチャ、そして複数フローが同一ファブリックを共有したときの輻輳である。 以下ではこの順に見たうえで、それらが実運用でどのような障害として現れるかをたどる。 ### 3.1 三層構造とポイントツーポイントのシリアル接続 PCIeは物理層、データリンク層(DLL)、トランザクション層の3層からなるポイントツーポイントのシリアル相互接続である(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 DLLは誤り訂正、フロー制御、確認応答を担い、トランザクション層はアプリケーションデータを**トランザクション層パケット(TLP: Transaction Layer Packet)**に変換する。 共有バスではないため、任意の2デバイス間の通信は必ずスイッチまたはルートコンプレックスを経由するツリー上の経路をたどる。 ルートコンプレックス(RC)はソケットと直接通信するツリーの根であり、エンドポイントデバイスが葉、PCIeスイッチが中間ノードとなる(Source: [[@2016__SC__A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers]])。 この構造から二つの帰結が生じる。 通信の性能が送信元と宛先の「距離」に依存すること、そしてツリーの上位ほど多くの通信が集約されるため内部ポートが競合点になることである。 ![[_attachments/multigpu_pcie_bw_model/fig01-topologies-t1-t2.png]] **図3-1**:8 GPUを収容する2種類のPCIeツリートポロジ。 T1は4基のK80を4個の48レーンPCIeスイッチと1個の80レーンスイッチで結び、T2は6個の48レーンPCIeスイッチと1個のルートコンプレックスで結ぶ。 どちらもエンドポイントが葉、スイッチが中間ノード、ルートコンプレックスが根という階層をなす。(Source: [[@2016__SC__A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers]]) ネットワーキングで用いられる主要なTLPタイプは3種類である。 - **Memory Write(MWr)**:ポステッドトランザクション。確認応答を伴わず、書き込み要求だけで完結する。 - **Memory Read(MRd)**:読み出し要求。単体ではデータを運ばず、応答を待つ。 - **Completion with Data(CplD)**:MRdに対する応答としてデータを返すTLP。 読み出しが要求と応答の2種類のTLPを要するという非対称性は、後述するとおり読み出し帯域が書き込み帯域より劣化しやすい理由の一つになる。 ### 3.2 公称帯域と実効帯域の隔たり #### TLP ヘッダと DLL のオーバーヘッド 公称リンク帯域と実効帯域の差は、まずプロトコルの固定オーバーヘッドから生じる。 40Gb/s NICで一般的なPCIe Gen 3 x8は、8レーンそれぞれが8GT/sで動作し128b/130bエンコーディングを用いるため、物理層で `8 × 7.87 = 62.96 Gb/s` を実現する(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 DLLがフロー制御と確認応答のために約8〜10%を消費し、トランザクション層で利用可能な帯域は約57.88Gb/sまで下がる。 各トランザクションには物理層の2Bフレーミングと6BのDLLヘッダが付き、TLPの共通ヘッダが4B、MWrとMRdのヘッダが64bitアドレッシング時に12B、CplDのヘッダが8B加わる。 このオーバーヘッドは転送サイズに対して一定ではなく、パケット化の境界で階段状に変化する。 MWrヘッダ合計24Bを用いると、サイズ `sz` のDMA書き込みが実際に運ぶバイト数は `⌈sz / MPS⌉ × 24 + sz` になる(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 読み出しは要求側と応答側で別々に計算する必要があり、要求側が `⌈sz / MRRS⌉ × 24 + sz`、応答側が `⌈sz / MPS⌉ × 20 + sz` となる。 天井関数が入るため、実効帯域は転送サイズに対してノコギリ歯状の曲線を描く。 #### MPS と MRRS のネゴシエーション 天井関数の分母にあたるのが、リンク確立時にピア間で合意される二つのパラメータである。 **Maximum Payload Size(MPS)**は1つのTLPが運べる最大データ量で、典型値は256Bまたは512Bである。 **Maximum Read Request Size(MRRS)**は1つのMRdが要求できる最大データ量で、典型値は512Bである(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 MPSが小さいほど同じデータ量に対して多くのTLPが必要になり、ヘッダの占める割合が増える。 この効果は小さい転送で顕著になる。 パケットごとにディスクリプタをDMAし、ドライバがパケットごとにキューポインタを読み書きする素朴なNIC実装では、512Bを超えるイーサネットフレームでしか40Gb/sの線速を達成できない(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 パケットデータ自体に加えて、TXディスクリプタとフリーリストディスクリプタの読み出し、RXディスクリプタの書き戻し、割り込み生成、ドライバによるキューポインタ操作がすべてPCIe帯域を消費するためである。 この理論モデルには限界もあり、フロー制御メッセージのオーバーヘッドは推定にとどまるため実効帯域をやや過大評価し、非アライメントなDMA読み出しに伴うRead Completion Boundary由来の追加TLPはモデル化されていない。 ![[_attachments/p327-neugebauer/fig01-effective-bw-model.png]] **図3-2**:PCIe Gen 3 x8の実効帯域を転送サイズごとにモデル化した曲線。 ノコギリ歯状のパターンは、データがMPSごとのTLPに分割されそれぞれにヘッダが付くというパケット化構造から生じる。 単純なNIC実装(Simple NIC)は512Bを超えるイーサネットフレームでしか40Gb/sの線速に届かず、現代的なNICでも要求帯域との余裕は小さい。(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]]) レイテンシへの寄与はさらに大きい。 ExaNICを用いたループバック計測では、128Bペイロードの往復レイテンシ約1000nsのうち約900nsがPCIeに起因し、寄与率は90.6%に達する(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 1500Bパケットでも寄与率は77.2%である。 40Gb/sの線速で128Bパケットを扱うには29.6nsごとに新しいパケットを送受信する必要があるため、レイテンシが対称だと仮定するとNICは各方向で少なくとも30個の同時DMAを扱わなければならない。 ![[_attachments/p327-neugebauer/fig02-nic-pcie-latency.png]] **図3-3**:往復レイテンシに占めるPCIeの寄与。 128Bペイロードでは約1000nsのうち約900nsがPCIeに起因し、寄与率は90.6%に達する。 パケットサイズを増やすほど寄与率は下がるが、1500Bでも77.2%を占める。(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]]) ### 3.3 ルートコンプレックス側の要因 プロトコルのオーバーヘッドを差し引いてもなお、実効性能はホスト側の実装に左右される。 近年のx86サーバではルートコンプレックスがメモリコントローラとともにCPUコアに統合され、PCIeデバイスとCPUキャッシュの結合が進んだ(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 その結果、PCIeの性能はNUMA配置、キャッシュ状態、アドレス変換の3要因に依存するようになった。 #### NUMA 配置 2ソケットシステムでは、ホストバッファがPCIeデバイスの接続されたノードにあるか別ノードにあるかで読み出し性能が変わる。 ウォームキャッシュ下の64B DMA読み出しは、リモートメモリに対してローカルより約20%低いスループット(約32Gb/sから約25Gb/s)を示す(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 差は転送サイズとともに縮小し、128Bと256Bでは5〜7%、512B以上では有意差が見られない。 レイテンシについてはリモートアクセスが常に約100nsを追加する。 一方でDMA書き込みのスループットはバッファのロケーリティにもサイズにも影響されず、すべての書き込みがまずローカルのDDIO領域で処理されていることを示唆する。 この非対称性は運用上の指針に直結し、サイズの小さいディスクリプタリングはデバイスのローカルノードに置き、サイズの大きいパケットバッファは処理が行われるノードに置く、という配置が合理的になる(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 ![[_attachments/p327-neugebauer/fig08-numa-local-remote.png]] **図3-4**:ホストバッファのロケーリティがDMA性能に与える影響。 ウォームキャッシュ下の64B DMA読み出しはリモートメモリで約20%のスループット低下を示し、128Bと256Bでは5〜7%、512B以上では有意差がない。 DMA書き込みのスループットはロケーリティにもバッファサイズにも影響されず、リモートアクセスは常に約100nsのレイテンシを追加する。(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]]) #### DDIO によるキャッシュへの直接配置 **Intel Data Direct I/O(DDIO)**は、PCIeデバイスのDMAをメインメモリではなくLast Level Cache(LLC)に直接向ける機構である。 キャッシュに常駐しているデータへのPCIe読み出しは、非常駐時より約70ns高速になる(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 64B DMA読み出しの帯域ではこの差が有意に現れるが、512B以上の読み出しやDMA書き込みでは有意差が観測されない。 DDIOには容量の制約がある。 LLCのうちDDIOに割り当てられるのは10%であり、書き込みのワーキングセットがこれを超えるとダーティキャッシュラインのフラッシュが必要になり、ほとんどの書き込みで約70nsの遅延が生じる(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 DDIOは無効化できず専用の性能カウンタも存在しないため、DMA書き込みが常にLLCまたはDDIO領域にヒットしているという仮説自体は検証できないままである。 #### IOMMU のアドレス変換と IOTLB ミス IOMMUをデータパスに介在させると、デバイスが発行するアドレスの変換が必要になり、変換キャッシュのミス時にはページテーブルウォークが発生する。 `intel_iommu=on` かつスーパーページを無効化した条件では、ワーキングセットが256KBを超えた時点で64B DMA読み出しのスループットが最大約70%低下する(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 256B読み出しでも約30%低下し、512B以上では変化がない。 64B書き込みでも約55%の低下が見られる。 低下が始まる境界からIO-TLBのエントリ数は64(256KB/4KB)と推定され、64B読み出しのレイテンシは約430nsから760nsに増加することから、IO-TLBミスとページテーブルウォークのコストは約330nsと見積もられる(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 この結果は測定された4世代のIntelマイクロアーキテクチャで一貫しており、独立した2つのデバイス実装でも再現された。 対策としてはI/Oバッファをできるだけ少数のスーパーページに集約することが推奨されるが、PCIeデバイスをVMにアサインするマルチテナント環境では、現状のIntel IOMMUでVM間のI/O性能分離を十分に行うことは難しいとされる。 ![[_attachments/p327-neugebauer/fig09-iommu-effect.png]] **図3-5**:IOMMU有効時のスループット変化率をIOMMU無効時と比較したもの。 ウィンドウサイズが256KBを超えた時点で急激に低下し、64B DMA読み出しで最大約70%、256B読み出しで約30%落ちる一方、512B以上では変化がない。 低下が始まる境界からIO-TLBのエントリ数は64と推定される。(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]]) 同一世代でもルートコンプレックスの実装が揃っているとは限らない。 Xeon E5系では99.9%のトランザクションが最小520ns、中央値547nsを起点とする80nsの狭い範囲に収まるのに対し、同世代のXeon E3系では中央値が1213nsに達し、99.9パーセンタイルは11987ns、最大レイテンシは5.8msに及ぶ(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 著者らは隠れた省電力モードとの関連を疑ったが、BIOSで省電力モードを無効化しても分布は有意に変化せず、原因は未確定のまま残されている。 ### 3.4 単一フローのオーバーヘッドと複数フローの輻輳 ここまで扱ったのは、1本のフローがPCIeファブリックを占有している場合の性能である。 単一フローのオーバーヘッドモデルと複数フローの輻輳モデルは、同じPCIeファブリックの性能を異なる切り口から説明する相補的な二つの層である(Source: [[PCIe性能]])。 #### ポートアービトレーションとフロー制御クレジット GPU間のP2P転送を対象とした輻輳モデルは、帯域配分を4段階で計算する(Source: [[@2016__SC__A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers]])。 | 段階 | 機構 | 内容 | |---|---|---| | (A) | ソースアービトレーション | 1つのGPUが複数の通信を同時に発行しても、非同期コピー関数を使ってもFirst Come First Serve順で逐次処理される | | (B) | 上流ポートアービトレーション | 葉から根へ向かい、根方向へ進む通信同士に均等配分を適用する | | (C) | 下流ポートアービトレーション | 根から葉へ向かい、重み付きラウンドロビンでポート帯域を配分する | | (D) | HOLブロッキング | 輻輳ポートと入力ポートを共有する通信の帯域を、実際には輻輳リンクへ向かっていなくても削減する | ![[_attachments/multigpu_pcie_bw_model/fig02-port-conflict-types.png]] **図3-6**:ポートコンフリクトの2つの型。 上流ポートコンフリクトは根に向かう通信同士がポート上で衝突する場合に生じ、下流ポートコンフリクトは葉に向かう通信同士が衝突する場合に生じる。 アービトレーションの方式が方向によって異なるため、この区別が帯域配分の計算の起点になる。(Source: [[@2016__SC__A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers]]) 上流と下流でアービトレーションの方式が異なるという点は、実測にも現れる。 8GPU構成での計測では、上流ポートコンフリクトが単独時の1.88倍の性能低下、通常の下流ポートコンフリクトが1.80倍の低下を示すのに対し、ルートコンプレックスを通過する通信を含むコンフリクトでは1.44倍にとどまる(Source: [[@2016__SC__A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers]])。 低下が緩やかなのは、ルートコンプレックスを通過する通信がそもそも単独でも1.21倍遅く、より小さいパケットサイズを強いられて理論帯域効率が76%程度まで下がっているためだと推測されている。 モデルはこの劣化を性能損失係数 `τ = 1 − 1/1.21 = 0.17355` として経験的に組み込む。 このτが経験的パラメータであることには方法論上の含意がある。 PCIeスイッチとルートコンプレックスの内部実装はベンダ固有で公開されておらず、アービトレーションポリシーも帯域効率の低下量も、公開仕様から導出できない(Source: [[PCIe性能]])。 #### head-of-line ブロッキング クレジットベースのフロー制御は、輻輳の影響を輻輳点の外へ伝播させる。 1つの通信が異なるスイッチ上の2つ以上のポートを跨ぐ場合、あるポートでのクレジット枯渇が、別のポートを共有するすべての通信の帯域を最低値まで引き下げる(Source: [[@2016__SC__A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers]])。 輻輳を起こしているリンクへ向かっていない通信までが減速するため、ボトルネックの位置と症状の出る位置が一致しない。 このモデルは8GPU構成の2種類のトポロジで検証され、9万件超の通信のうち97%以上が誤差±15%以内で予測された(Source: [[@2016__SC__A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers]])。 誤差が−30%を下回る通信が両トポロジで数百件残っており、著者らはポート容量への間接的な負荷変動などモデルが捉えきれていない要因に起因すると考察している。 ### 3.5 密実装アクセラレータサーバでの P2P 転送 複数のアクセラレータを1台のサーバに高密度搭載する構成では、通信パターンの選び方だけで性能が大きく変わる。 気象予報モデルCOSMOのhalo exchangeに輻輳モデルを適用した結果、2Dドメイン分割では20,736通りの通信順序のうち最速のものが最遅のものの1.9倍、既定実装の1.6倍速かった(Source: [[@2016__SC__A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers]])。 3Dドメイン分割では1,679,616通りを評価し、最速と最遅の比は2.57倍に達した。 最速の順序は、ルートコンプレックスを跨ぐ通信数を同一方向に最小化するリングパターンで構成される。 ただしPCIeレベルの最適化がそのままアプリケーション性能になるわけではない。 COSMOの1タイムステップ全体をトレースすると、最速の通信順序はMPIオーバーヘッドを含めて既定実装より合計5.7%高速にとどまり、100KB未満の小さいメッセージのhalo exchangeでは改善が観測されなかった(Source: [[@2016__SC__A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers]])。 密実装構成の性能はトポロジ以外の要因にも左右される。 DGX-1とDGX-2でのGPU間P2P帯域の実測は、同一PCIeスイッチを共有する近傍GPU間の帯域が遠隔GPU間より低いという**anti-locality**効果を報告している(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]])。 著者らはPCIeスイッチチップセット上の不均衡な物理信号経路に起因すると推測するが、ベンダ非公開の内部実装ゆえ確定的な原因究明には至っていない。 この効果は双方向帯域で顕著に現れ、レイテンシでは観測されない。 PCIeレイテンシ自体は、1回のスイッチ越しでも同一ソケット越しでもQPIブリッジ越しでもほぼ同一で、NUMA効果を示さない。 メッセージサイズによる効率変動はP2P転送でも一貫している。 PCIeの単方向帯域は約4MBで飽和し始め、持続帯域に達するには少なくともこの程度の転送量が必要になる(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]])。 集合通信では飽和点が約16MBまで上がり、参加GPU数が増えるほど帯域が低下する。 小さいメッセージほどPCIeの実効帯域が理論値を下回るという傾向は、単一フローのMPS/MRRSオーバーヘッド、複数フローの輻輳、チップセット配線という異なる原因を経由して、いずれの測定でも共通して現れる(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]], [[@2016__SC__A PCIe Congestion-Aware Performance Model for Densely Populated Accelerator Servers]], [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]])。 ### 3.6 実運用における PCIe 障害 PCIeは静的な性能パラメータではなく、劣化しうる運用対象である。 本番RDMAサーバでは、リンク幅または速度が縮退する**PCIe downgrading**が発生し、RNICのスループットが正常時の197.0Gbpsから67.0Gbpsへ低下すると同時に、Tx pause duration ratioが0%から35.7%へ急増した事例が報告されている(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 1本のホスト内ボトルネックの影響は1台にとどまらず、8ホストのring-based NCCL all-reduceで全ホストのスループットが約185Gbpsから約50Gbpsへ約70%低下した。 集合通信は最も遅い参加者に律速されるため、ホスト内の局所的な劣化がクラスタ全体の性能を決めてしまう。 PCIe downgradingは大規模訓練クラスタの障害統計でも無視できない比率を占める。 9ヶ月分の実行時障害150件のうち、PCIe downgradingは8.6%であり、ECC error(25.7%)、CUDA execution error(15%)、GPU execution error(10%)に次ぐ4番目の頻度だった(Source: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])。 マシン内で複数のGPUやPCIeリンクが同時に劣化すると、3D parallelismのトポロジ上でDP/PPグループへ即座に影響が波及し、秒単位の監視粒度では外れ値として区別しにくくなる(Source: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])。 4台中2台にPCIe downgradingを注入しミリ秒粒度で監視した実験では、故障PCIeにつながる2つのNICを最大の外れ値距離で検出できており、粒度を上げれば検知可能性は改善する。 設定の誤りがハードウェア障害と同等の性能劣化を引き起こす点は、運用上とくに注意を要する。 ACS(Access Control Service)を有効化するとGDR(GPU Direct RDMA)トラフィックがGPUへ直接届かずCPUへ迂回させられ、レイテンシと帯域の双方が劣化する(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 仮想化環境でATS(Address Translation Service)を無効化した場合も、GDRパケットのアドレス変換のためすべてがCPUルートコンプレックスを経由させられ、レイテンシが増加する。 どちらも設定値を戻せば解消するが、帯域行列の見た目はリンク障害と区別がつかない。 経路長がスループットに変換される機構も定量化されている。 GDR readのホストレイテンシは、単一PCIeスイッチ経由で1.0µs、CPUルートコンプレックス経由で2.2µs、UPI越しで2.4µsに増加し、対応するスループットは195.0Gbps、125.5Gbps、116.4Gbpsと低下する(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 わずか1.4µsの追加レイテンシが約40%のスループット低下をもたらす。 機構は単純で、線速を維持するには往復時間に比例した数のoutstanding read request TLPが必要になるが、RNICが保持できる数には上限があるためである。 このためGDRはCPUルートポートを跨ぐ経路を避けるべきだ、という運用上の経験則が導かれる。 輻輳はホスト内でも起きる。 Azureのストレージ向けRDMA展開では、同一サーバ内の複数RDMAアプリケーションインスタンス間の通信と外部通信がNIC上で共存し、PCIeレーンで2:1の輻輳を作った結果、slow receiverとしてPFC frameの送出につながった(Source: [[@2023__NSDI__Empowering Azure Storage with RDMA]])。 ループバックトラフィックのRDMAを無効化するとPFC frameの送出は止まった。 この事例から著者らは、ホスト内ネットワークと物理ネットワークは分離されたものではなく、PCIe、GPU、DPU、NVLink、NICが絡む「収束したネットワーク」として管理されるべきだと論じている。 ### 3.7 NIC 線速の伸びと PCIe 帯域の伸びの乖離 PCIeが繰り返しボトルネックとして現れるのは、個別の実装品質の問題ではなく、世代あたりの伸び率の差に由来する。 RNICの線速は25Gb/sから200Gb/sへ伸びたが、ホスト内帯域の伸びはこれに追いついていない(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 40Gb/s NICの時点ですでにPCIe Gen 3 x8の実効帯域が制約になっていたことを踏まえると、線速が5倍になった現在の構成でホストI/Oが露出するのは想定内の帰結である(Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 アクセラレータ側でも同じ差が観測できる。 PCIe Gen5 x16は片方向約64GB/s、Gen6 x16でも約128GB/sであるのに対し、CPUとGPUを直結する専用インターコネクトは約900GB/sを提供しており、一桁の開きがある(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 2 AI System Hardware Overview]])。 一方でPCIeは汎用I/Oの共通基盤としての地位を保っており、NIC、ストレージ、管理系デバイスの接続はPCIeに依存し続ける。 専用インターコネクトがPCIeを置き換えるのではなく、帯域要求の高い一部の経路をPCIeから切り離す、という分業が進んでいると見るのが実態に近い。 ### 未解決の問い - 単一フローのオーバーヘッドモデル(MPS/MRRS、DDIO、IOMMU)と複数フローの輻輳モデル(ポートアービトレーション、HOLブロッキング)を統合した性能モデルは存在するか。NIC↔ホスト間通信とGPU↔GPU間P2P通信が同じスイッチ配下で競合する構成では両方の要因が同時に効くはずだが、そのような統合モデルは、参照した文献の範囲では見当たらない。 - Gen 3世代で観測されたノコギリ歯状のTLPオーバーヘッドパターンやDDIO、IOMMUの挙動は、Gen 4/Gen 5世代でも同様に再現されるか。 - 経験的パラメータτ(ルートコンプレックス通過ペナルティ)やポートアービトレーションの配分則は、2016年当時のPLX製スイッチ以外の世代でも同じ値と挙動を示すか。またanti-locality効果の根本原因は、同じポートアービトレーションモデルで定量的に説明できるか。 - IOMMUのIO-TLBエントリは、単一サーバに複数の高性能PCIeデバイスを搭載した構成でデバイス間に共有されるか。共有される場合、マルチテナント環境でのPCIe性能分離をどう設計すべきか。 - AMD、ARM64、Powerベースのサーバでは、ルートコンプレックスの実装がIntel Xeonとどう異なり、NUMA、DDIO相当機構、IOMMUの影響はどう変化するか。 - PCIe downgradingやACS/ATSの誤設定を、症状(帯域行列の劣化パターン)だけからハードウェア障害と区別する一般的な手順はあるか。現状の報告は個別事例の積み上げにとどまっている。 --- ## 第4章 スケールアップインターコネクト: NVLink とアクセラレータ間結合 前章までは、ホスト1台の内側でデータが CPU、メモリ、PCIe、NIC をどう渡り歩くかを追ってきた。 本章の対象はその一段上、すなわち複数のアクセラレータを1つの計算資源として束ねる結合網である。 この層は AI データセンターの設計論では**スケールアップネットワーク**(scale-up network)と呼ばれ、ラック間を結ぶ**スケールアウトネットワーク**(scale-out network)と区別される。両者は帯域が一桁以上違うだけでなく、通信の意味論、観測の手立て、障害の現れ方までが異なる。 区別が必要な理由は、この二層構造がモデル並列化の戦略と直接対応しているからである。 テンソル並列やシーケンス並列は層内の行列積を分割するため、計算と重ねて隠すことのできない all-gather と reduce-scatter を高頻度で発生させるのに対し、データ並列やパイプライン並列の通信は相対的に粗く遅延の許容度も高い。 前者をスケールアップ網に、後者をスケールアウト網に載せるという配分が、AI クラスタのトポロジ設計の出発点になっている。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) そして帯域の追加投資が先に効くのはスケールアップ側である。 スケールアップ帯域が 0.8 Tbps のとき露出したネットワーキング時間は 40% と 75% に達するが、NVLink 5 相当の 14.4 Tbps では 5% と 20% まで下がる。一方スケールアウト側は 800 Gbps 付近で頭打ちになりつつあり、改善余地はスケールアップ側に偏って残っている。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) ### 4.1 スケールアップとスケールアウトを分ける境界 #### 帯域と遅延の断絶 両者の差はまず数値に現れる。 スケールアウト経路は GPU から PCIe を経て NIC へ抜け RDMA や RoCE を用いるため帯域 50〜100 GB/s、レイテンシ約 100 マイクロ秒に留まるが、スケールアップ経路は PCIe を介さず GPU から直接ファブリックへ入るため帯域 300 GB/s 以上、レイテンシ数マイクロ秒を達成する。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) ![[_attachments/2026_Unknown_FabricPerf_Measuring_NIC_less_Scale/fig02-ml-network-paradigm.png]] **図4-1**:階層型 ML ネットワークの二層構造とデータパスの違い。 スケールアウトは GPU から PCIe、NIC、PCIe を経て相手の GPU に至り 2 回の PCIe 通過を含むのに対し、スケールアップは PCIe を介さず GPU からファブリックへ直接入って完結し、300 GB/s 以上の帯域を実現する。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) この差は推論のエンドツーエンド時間に直結する。 ある報告では、DeepSeek-V3 の推論で 400 Gbps の InfiniBand NIC を用いた場合の通信時間 129.96 マイクロ秒が、NVL72(900 GB/s)では 6.72 マイクロ秒まで短縮され、総推論時間は 14.76 ミリ秒から 0.82 ミリ秒へ改善した。 ただし同じ資料は、計算時間が残る以上レイテンシ削減の効果には上限があり、極端な低レイテンシが常に必要なわけではないとも注意している。(Source: [[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]]) #### メモリセマンティクスとメッセージセマンティクス より本質的な差は、通信の意味論にある。 スケールアウトが NIC を介した send/recv すなわち**メッセージセマンティクス**で動くのに対し、スケールアップは HBM への直接アクセス、すなわち load/store の**メモリセマンティクス**で動く。(Source: [[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]]) この違いは実装の細部まで波及する。 Ethernet/IP の MTU が 1500 バイトであるのに対し、スケールアップファブリックの転送粒度はメモリ粒度の 128 ビットにすぎず、少数スレッドで飽和する Ethernet と異なり NCCL は H100 の NVLink 350 GB/s を埋めるのに 10,240 スレッドを要する。 結果としてスケールアップの通信プロトコルは、小さな転送単位ごとにヘッダを付けるのではなく、データ列の末尾で制御情報を一括更新する設計を採る。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) ただし境界は固定ではない。 Microsoft の Maia 200 はスケールアップ相当の帯域(双方向 1.4 Tbps)を持ちながらメッセージセマンティクスを採用しており、二分法が実装ごとに揺れうることを示す。(Source: [[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]]) ### 4.2 NVLink の世代とトポロジ #### 直結からスイッチへ NVLink は GPU 間および CPU-GPU 間の高速インターコネクト規格であり、PCIe 経由の相対的に低速な通信を代替してキャッシュコヒーレントな統一メモリ空間を実現することを目的とする。 初期の構成では GPU 同士を直接結線しており、ノード内 4 GPU なら全対全直結が成立するが、8 GPU になると NVLink Switch を経由する構成へ移る。(Source: [[@2024__SpeakerDeck__アクセラレータ間通信の実際]]) スイッチ化の効果は実測で明瞭に出る。 NVSwitch は 18 ポートの完全結合ノンブロッキングクロスバーで、DGX-2 では 2 枚のベースボードにそれぞれ 6 基の NVSwitch と 8 基の GPU を載せ、ベースボード間の生バイセクション帯域 2.4 TB/s を実現した。 16 GPU 構成では対向ベースボードへのアクセスが 2 スイッチホップを要するにもかかわらずレイテンシ差はごくわずかで、帯域も全リモートアクセスで一貫している。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) 現行世代ではこの構造がラック全体へ拡大した。 GB200 NVL72 は 72 基の GPU を NVLink 5(GPU あたり集約双方向帯域約 1.8 TB/s)と 18 基の NVSwitch チップで結び、単一ホップの全結合ネットワークを構成する。NVSwitch ASIC には集約とリダクションのエンジンである NVLink SHARP が統合され、勾配リダクションなどの集合通信の一部をスイッチ内で処理して GPU 側の負荷を減らす。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 2 AI System Hardware Overview]]) ![[_attachments/ai-systems-performance/ch02-fig2-9-nvl72-architecture-nvswitch-topology.png]] **図4-2**:NVL72 の全体アーキテクチャ。 4 GPU コンピュートトレイの各 B200 が 1,800 GB/s の NVLink で 18 基の NVSwitch すべてにつながり、ラック内の任意の GPU 間が 1 ホップで到達する。 ラック全体は約 130 kW、約 2,900 ポンドに達する。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 2 AI System Hardware Overview]]) #### PCIe との性能差の実測 PCIe と NVLink の差は、絶対帯域よりも GPU 数を増やしたときの向きに現れる。 PCIe の集合通信帯域は木構造トポロジ上でバスが競合するため GPU 数の増加とともに低下するのに対し、NVLink の帯域はハイパーキューブメッシュ上で使えるリンク本数が増えるためおおむね増加する。飽和点も異なり、PCIe の集合通信帯域が約 16 MB のメッセージで飽和するのに対し NVLink は約 256 MB まで伸び続ける。 逆にレイテンシでは優位が限定的で、参加 GPU が 3 を超える場合、all_reduce 以外では木構造 PCIe のほうが起動レイテンシが低い。NVLink 系の優位はレイテンシではなく帯域にある、というのが実測から導かれる結論である。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) ![[_attachments/gpu-interconnect-tpds2020/fig20-cl-bandwidth-dgx1.png]] **図4-3**:1 GB ペイロードの集合通信帯域を参加 GPU 数に対して測ったもの。 PCIe は木構造ネットワーク上のバス競合により GPU 数の増加とともに帯域が低下するのに対し、NVLink はハイパーキューブメッシュ上で使えるリンク本数が増えるためおおむね増加する。 NVLink-V2 は 4 GPU で 1.6 倍、8 GPU で 2 倍と NVLink-V1 を上回り、二重リンクと backbone ring の効果が現れる。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) グラフィックス用途から転用された NV-SLI は、2 GPU 限定ながら三段のレイテンシ階層を明示する好例である。 ローカルアクセス約 5 マイクロ秒、対向 GPU への NV-SLI アクセス約 8 マイクロ秒、同じ対向 GPU への PCIe アクセス約 13 マイクロ秒であり、2 GPU が CPU や DMA の介在なしに直結されていることが数値に表れる。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) #### GPUDirect による経路の短縮 NVLink がリンクそのものを速くする技術だとすれば、GPUDirect は経路からホストを取り除く技術である。 GPUDirect 1.0 は NIC と GPU の間でピンメモリを共有し、2.0(P2P)は GPU 間の直接 load/store を可能にし、RDMA は NIC が GPU メモリの BAR 領域を直接読み書きできるようにし、Async は CPU が事前登録したメッセージを GPU 側からトリガーできるようにした。(Source: [[@2026__CSUR__The Landscape of GPU-Centric Communication]]) GPUDirect-RDMA の有効性は世代で反転している点に注意がいる。 SummitDev では 4 KB から 256 KB の領域で GPUDirect-RDMA がむしろ最悪の性能を示しピンメモリ併用方式に劣ったが、Summit では同じ構成が常に最低レイテンシと最高帯域を示し 5 構成中の最良になった。「GPUDirect を有効にすれば速い」という命題は、プラットフォーム世代を跨いでは成立しない。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) ![[_attachments/gpu-interconnect-tpds2020/fig28-internode-p2p-summitdev.png]] **図4-4**:SummitDev における 5 構成のノード間 P2P レイテンシと帯域。 GPUDirect-RDMA はレイテンシで 4〜64 KB、帯域で 4〜256 KB の領域、とくに 32 KB で最悪の性能を示す。 4 MB 以降は帯域で優位に立ち 64 MB で 12 GB/s に達するが、それでも PinnedMem-GPUDirect 方式の 14 GB/s 超には届かない。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) 意味論上の限界も残る。 GPUDirect-RDMA はカーネル境界を越えた GPU と NIC の間のメモリ一貫性を保証しないため、パーシステントカーネルとの併用には原理的な制約がある。(Source: [[@2026__CSUR__The Landscape of GPU-Centric Communication]]) #### 世代進化とベンダー横断の見取り図 スケールアップ結合は NVIDIA の独占領域ではない。 第 5 世代 NVLink/NVSwitch が 1.8 TB/s と最大 576 GPU 接続を掲げる一方、AMD の Infinity Fabric/xGMI は 8 GPU で 896 GB/s をスイッチファブリックなしのフラットメッシュで実現し、Intel の Xe-Link は最大 8-way の全対全を提供する。UALink はこれらに対するオープン規格として新興している。(Source: [[@2026__CSUR__The Landscape of GPU-Centric Communication]]) 次世代では帯域と同期プリミティブの両方が動く。 Rubin GPU は NVLink 6 でスケールアップ帯域 3,600 GB/s を NVLink Switch へ、NVLink-C2C で 1,800 GB/s をコヒーレントな CPU-GPU 通信へ振り向ける。加えて device-initiated NVLink 通信向けに counted writes を導入し、受信側 GPU が転送完了を追跡しやすくすることで、ペイロード転送に付随する同期待ちを削る。(Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]]) ### 4.3 トポロジの非対称性と通信ライブラリの前提 #### リンク本数の違いが生む NUMA 効果 スケールアップ網は「全 GPU が対等」とは限らない。 DGX-1 と Summit 系の実測は、NVLink に起因する 3 種の NUMA 効果を分類している。 第一は NVLink 直結の近傍ノードと手動ルーティングを要する遠隔ノードの差であり、直結時のレイテンシ約 9 マイクロ秒に対し遠隔では P100 で約 2 倍、V100 で約 3 倍に増える。 第二は近傍ノード同士でもリンク本数が 1 本か 2 本(backbone ring)かで帯域が変わる差、第三はルーティング経路が通過する 2 倍帯域リンクの本数に起因する差である。NV-SLI と NVSwitch は全結合トポロジであるため、これらの NUMA 効果を持たない。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) ![[_attachments/gpu-interconnect-tpds2020/fig01-pcie-nvlink-topology-dgx1.png]] **図4-5**:DGX-1 の NVLink トポロジ。 細い黒線が 1 本の NVLink、太い赤線が 2 本の NVLink-V2 による接続を表す。 P100-DGX-1(A)は 12 本の NVLink が GPU を立方体の頂点として結ぶハイパーキューブメッシュで、平面内は UMA、平面をまたぐと NUMA になる。 V100-DGX-1(B)は平面内接続を強化せず、代わりにメッシュ内部に高速な backbone ring を形成する。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) 非対称性はスイッチを持たない設計でより強く出る。 LUMI の AMD MI250X ノードでは GCD 間の Infinity Fabric リンク数が 1 本から 4 本まで異なり、goodput は 250 Gb/s から 1,250 Gb/s まで散らばる。 このとき RCCL は利用可能帯域をホップ数だけから推定し経路の本数を考慮しないため、ホップ数が同じでもリンク本数が少ない GPU 対では帯域を取りこぼす。(Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]]) ![[_attachments/sc24-gpu-gpu-interconnect/fig02-node-architecture-lumi.png]] **図4-6**:LUMI のノード構成。 AMD MI250X 4 枚(8 GCD)が Infinity Fabric でメッシュ状に結ばれるが、GCD 間のリンク数は 1 本から 4 本まで異なり、スイッチを持たないぶん非対称性がそのまま帯域差として残る。(Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]]) これは通信ライブラリの帯域モデルが実トポロジを表現しきれていないという、より一般的な問題の一例である。 同ノード内で最大 4 倍、ノード内外で最大 10 倍という GPU 間帯域の非対称性が集合通信アルゴリズムの設計を難しくしており、線形計画による最適解探索は NP 困難でノード数に対して指数的にスケールし 128 ノードで最大 11 時間を要する。 そのため高レベル言語からのコンパイルによる近似が実用上の落としどころになっている。(Source: [[@2026__CSUR__The Landscape of GPU-Centric Communication]]) #### ホスト側トポロジの誤認 非対称性はアクセラレータ側だけの話ではない。 PFN の H100 クラスタでは、NIC を 8 枚搭載する前提で PCIe スイッチが論理的に 2 分割されており、ドキュメント上 4 個のスイッチが `nvidia-smi` 上は 8 個に見えていた。 この結果、GPU1 と GPU3 は NIC0 と NIC1 のどちらからも等距離、GPU5 と GPU7 は NIC2 と NIC3 のどちらからも等距離になり、NCCL が常に NIC0 と NIC2 を選ぶ偏りが生じた。対処はファームウェアで PCIe スイッチを統合することであり、GPU あたりの上り帯域が半減するというトレードオフを伴った。(Source: [[@2024__SpeakerDeck__アクセラレータ間通信の実際]]) 既定設定への信頼も置きすぎるべきではない。 Alps、Leonardo、LUMI の 3 システムを最大 4,096 GPU で比較した研究は、既定設定がどのシステムでも最適から程遠く手動チューニングで最大 1 桁の性能向上が得られると報告しており、LUMI では `NCCL_NCHANNELS_PER_PEER=32` の設定だけでノード内点対点性能が 3.5 倍改善した。(Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]]) ### 4.4 アクセラレータ内部のネットワーク 観測の対象は、近年アクセラレータのパッケージ内部にまで降りている。チップレット型アクセラレータの内部で計算チップレット、IO チップレット、メモリモジュールを結ぶ結合網は**アクセラレータチップレットネットワーク**(Accelerator Chiplet Network, ACN)と名付けられ、独立したネットワークとして扱われ始めた。(Source: [[@2026__SIGCOMM__Understanding and Profiling the Accelerator Chiplet Network Using PingPoint]]) ACN をネットワークとして扱う根拠は帯域の階層にある。 AMD MI300X では L1 が 38.6 TB/s、L2 が 25.5 TB/s、LLC が 18.1 TB/s、HBM が 5.9 TB/s であるのに対し、ACN の 3 種のリンクは COM-IO が 6.2 TB/s、IO-IO が 2.4 TB/s、IO-MEM が 4.4 TB/s しかない。 非負荷時の計算ユニットから HBM への遅延 372 ナノ秒のうち ACN は 14.4%(54 ナノ秒)にすぎないが、背景に帯域集約的なカーネルを流すと総遅延 949 ナノ秒の 43.1%(436 ナノ秒)を占め最大の寄与因になる。(Source: [[@2026__SIGCOMM__Understanding and Profiling the Accelerator Chiplet Network Using PingPoint]]) ![[_attachments/Understanding-and-Profiling-the-Accelerator-Chiplet-Network-Using-PingPoint/fig02-acn-conceptual-overview.png]] **図4-7**:アクセラレータチップレットネットワーク(ACN)の構成。 計算チップレットは COM-IO リンクで IO チップレットにつながり、IO チップレット同士は IO-IO リンク、IO チップレットとメモリモジュールは IO-MEM リンク、SoC 内の他のネットワークとは IO-EXT リンクで結ばれる。 本文で扱う 3 種のリンクは、この図の COM-IO、IO-IO、IO-MEM に対応する。(Source: [[@2026__SIGCOMM__Understanding and Profiling the Accelerator Chiplet Network Using PingPoint]]) この層が見えないことの実害は、輻輳が計算資源の分離を素通りする点にある。 重ならない計算ユニットに配置した 2 つのカーネルを同時に走らせても、ACN の共有リンクを介して平均遅延が 6.2 倍、P99 遅延が 10.6 倍に悪化し帯域が 58% 低下する事例が観測された。計算ユニットの占有率だけを根拠にした干渉制御は原理的に不十分だということである。(Source: [[@2026__SIGCOMM__Understanding and Profiling the Accelerator Chiplet Network Using PingPoint]]) 既存のプロファイラがこの層を扱えないのは、カウンタの配分に理由がある。 MI300X の 259 個のパフォーマンスカウンタのうち IO チップレット関連は 28 個にすぎず、その大半も L2 からファブリックへのリクエスト量やクレジットストールという粗い信号にとどまる。 PingPoint はカウンタの追加ではなく、ソフトウェアから注入した探査トラフィックの応答差分からリンク単位の輻輳寄与を推定する方針を採り、特権アクセスもハードウェア改変も要さずに ACN を解剖してみせた。(Source: [[@2026__SIGCOMM__Understanding and Profiling the Accelerator Chiplet Network Using PingPoint]]) ### 4.5 NIC を持たない網をどう測るか スケールアップ網の観測が難しい最大の理由は、NIC が消えたことにある。 NIC は従来、パケット単位のタイムスタンプ、PTP クロック、キュー統計といった観測点の集積地であり、それが経路から外れると既存の計測ツールにはアプリケーション層の粗いカーネル所要時間しか残らない。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) 困難は三方向から重なる。 第一に、スケールアップ網は GPU 上の SIMT プログラムモデルだけで動き CPU と OS に対して透過的なため、eBPF のようなホスト側の計測技術が効かない。 第二に、下位のファブリックとスイッチはおおむねプロプライエタリで公開インターフェースが乏しい。第三に、メモリセマンティクスと 128 ビットの転送粒度のため、計測すべきネットワークロジックが Ethernet 系と根本的に異なる。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) 回避策は、観測点を NIC から GPU の通信カーネルへ移すことである。 FabricPerf は NCCL などの送受信コードにアセンブリレベルのプローブを挿して往復を 5 つのタイムスタンプに分解し、クロックには NIC の PTP ではなく GPU 内蔵デバイスクロックを使って 128 ビットに圧縮した PTP 相当のメッセージで GPU 間を同期させる(カーネル内ジッタ 101.8 ナノ秒、三角測量による同期誤差の平均 106.45 ナノ秒)。 さらに通信をメモリトラフィックとしてモデル化することで、ファブリックがブラックボックスのままでも既存のメモリプロファイラから LLC の挙動を推定でき、オフライン収集時のオーバーヘッドはホットパスに対して約 0.6% に収まる。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) 見えるようになった結果は、最適化済みライブラリの内側にも余地が残ることを示した。 第一の発見はチャネル間の不均衡で、P99 レイテンシが P50 の約 2 倍(14 マイクロ秒に対し 7 マイクロ秒)に達し、しかもこれは飽和(300 GB/s 超)より手前の 12 チャネル、約 200 GB/s の時点で既に生じている。 速いチャネルが遅いチャネルの残りを奪う work-stealing を入れると、AllGather のスループットが 17.5 GB/s 改善し、チャネル間のばらつきが 46% 縮んだ。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) 第二の発見はキャッシュの崩壊である。 ネットワークバッファは繰り返し使われるため理論上は LLC に留まるはずだが、16 チャネル以上かつ 350 GB/s 以上の高帯域域では読み書きともヒット率が約 0% まで落ちる。 バッファストアを追い出されにくく、ストリーミングフローを追い出されやすく設定する eviction 優先度のチューニングで ReduceScatter のファブリック帯域は 632.717 GB/s から 648.787 GB/s へ改善した。TB/s 級の帯域は、他のシステムなら無視できたメモリ物理層の挙動を性能の主要因に押し上げる。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) ただし著者ら自身が限界を認めている。 パケット処理エンジンがプログラマブルでないためルーティング決定やリンク層のレイテンシは直接観測できず、NVSwitch の影響はエンドツーエンドのレイテンシからの間接推定にとどまる。チャネル不均衡の根本原因がポート選択なのかスケジューリングなのかも、ネットワーク層の情報が欠けるため確定できていない。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) ### 4.6 ラックスケール実装と superchip の運用 #### ファブリックの分離と障害ドメイン 理論上の二層構造は、実運用では 3 系統のファブリック分離として現れる。 GB200 NVL72 の商用提供では、GPU 間スケールアウトを担う Compute Fabric、インバンド管理とストレージを担う Converged Fabric、施設監視と NVSwitch 管理を担う OOB Fabric が独立に設計される。 Compute Fabric は閉域であるためインバンドでの管理制御が難しく管理ポート経由が単一障害点になるので、800G スイッチの Bonus Port に 2 本結線する案と、アンダーレイ網と BGP マルチパスで Loopback IP の到達性を冗長化する案が比較される。(Source: [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]) 提供単位の設計にもスケールアップ網の構造が効いてくる。 ラック単位は構成が単純だが大規模利用者向けに限られ、トレイ単位では NVLink Partition による論理分割が必要になりその管理プロセスが単一障害点になる。GPU 単位はさらに難しく、Grace CPU と B200 GPU が 1 対 2 であるためメモリ空間を同一粒度で分割できない。 複数ラックをまとめた Scalable Unit という障害ドメインが導入され、性能重視なら同一 SU、可用性重視なら別 SU という配置の判断が実務上発生する。(Source: [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]) 物理層の運用負荷も無視できない。 ラック間ケーブリングの自動化、光リンク劣化の切り分けに用いる Pre-FEC と Post-FEC の BER および FEC Symbol Error Bins、短距離区間での AEC 採用、液冷トレイ交換時の満水確認と水温水圧の監視が日常の作業項目として並ぶ。(Source: [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]) #### 帯域と実効性能の隔たり superchip 形態の CPU-GPU 結合は、スケールアップ帯域の恩恵が自動的には得られないことを示す教材である。 GH200 は Hopper GPU と Grace CPU を NVLink-C2C 900 GB/s で結ぶが、既存の LLM サービングシステムをそのまま移植すると C2C 帯域の 5% 未満しか使えず、原因はハードウェアではなくソフトウェアスタックにある。 PagedAttention の KV キャッシュは層ごと、ブロックごとに非連続で Qwen2.5-32B では連続領域がわずか 64 KB にしかならないが、NVLink-C2C が高帯域を発揮するのは 8 MB 以上の転送であり、加えて数千回のコピーカーネル起動のオーバーヘッドが積み上がる。(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]]) 対処はレイアウトと転送方式の作り直しである。 メモリ配置を層優先からブロック優先に変えて連続領域を 64 KB から 4 MB へ広げ、個別のコピーをバッチ化し、書き込みが完了したブロックを先行退避することで転送方向の衝突を解消した結果、16 GB の双方向転送で 180.99 GB/s と 179.37 GB/s、理想帯域比 94% に達し、素朴な実装(片方向 10.75 GB/s と 9.86 GB/s)の約 33 倍になった。(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]]) ハードウェア管理の統一メモリに任せる代替案も検証されたが、こちらは別のボトルネックに当たる。GPU 側の HBM が 4 TB/s であるのに対し、CPU 側 DRAM は C2C 経由でも自身の 384 GB/s に制限されるという帯域の段差があり、加えてアクセスパターンが蓄積する前にリクエストが完了してしまうため移行が発火しない。(Source: [[@2026__MLSys2026__SuperInfer - SLO-Aware Rotary Scheduling and Memory Management for LLM Inference on Superchips]]) この構図は 2020 年時点の観測と対をなす。 当時のマイクロベンチマークは NVLink が PCIe に対して明確な優位を示したにもかかわらず 13 種の実アプリケーション評価では大半で有意差が出なかった。CPU をマスター、GPU をスレーブとするプログラミングモデルの下では、GPU 間通信自体が実行時間に占める割合が小さかったためである。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) ### 4.7 NVLink のレジリエンス機構 スケールアップ網はデータ完全性の機構を内蔵している。 NVSwitch は CRC で NVLink の転送エラーを検知して再送し、ECC をデータパス、ルーティング、状態構造に適用する。加えて fabric manager が各アプリケーションのルーティングテーブルを監視し、不正なアクセスを防ぐ。(Source: [[@2020__TPDS__Evaluating Modern GPU Interconnect - PCIe, NVLink, NV-SLI, NVSwitch and GPUDirect]]) これらの機構が実運用でどう効いているかは、長期のログでしか見えない。 1,056 台の A100 と H100 を対象に 1,170 万 GPU 時間を分析した研究では、A100 系統で NVLink エラー(XID 74)が 1,922 件観測されたのに対し H100 系統では観測がゼロだった。著者らはこの改善を GH200 における密結合の CPU-GPU 統合とドライバ改善に帰している。(Source: [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) NVLink エラーの性質も、他の GPU エラーとは異なる。 A100 で観測された NVLink エラーのうち 42%(801 件)は 2 基以上の GPU に波及したが、ジョブが遭遇した際の失敗確率は 54% にとどまり、MMU と NVLink を除く GPU エラーがほぼ 100% ジョブ失敗に至るのと比べれば生存率が高い部類に入る。 これは再送機構が一定割合の障害を吸収していることと整合するが、同時に半分近くはジョブを落とすという事実も示している。(Source: [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) ラックスケールでは保守性そのものが設計対象になる。第 3 世代の MGX ラックアーキテクチャは、ホットスワップ可能な NVLink スイッチトレイと改善された RAS 機能を組み合わせ、大規模での耐障害運用を支えるとされる。(Source: [[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]]) ### 4.8 スケールアップ網への Ethernet の流入 スケールアップ結合は長らくベンダー独自の領域だったが、Ethernet 側からの接近が始まっている。 Broadcom が推進する Scale-Up Ethernet(SUE)は HBM3E 世代で 38.4 Tbps、HBM4 世代で 102.4 Tbps の帯域を目標に掲げ、OCP Networking の ESUN ワークストリームがトランスポート層(SUE-T、XPU 固有で置換可能)とデータリンク層(ESUN、全 XPU 共通)の 2 層構成で共通仕様を策定している。(Source: [[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]]) 注目すべきは、Ultra Ethernet の一部技術がスケールアップとスケールアウトの共通基盤として位置づけられている点である。 物理エラーによるパケットロスを防ぐ LLR、バッファ溢れを防ぐ CBFC、リンク対向での能力交換を行う LLDP はいずれも両ドメインで用いられるリンク層技術であり、SONiC と SAI が Ultra Ethernet 仕様 v1.0.2 に基づいて実装を進めている。(Source: [[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]]) 一方で、要求仕様は各社で一致していない。 Alibaba、Microsoft、Tencent、ByteDance の要件を並べると、パケットサイズ、クラスタ規模、レイテンシ、転送方式、マルチテナンシのいずれにも差があり、必ずしもメモリセマンティクス専用を前提としていない社もある。(Source: [[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]]) 観測の側から見ると、この動きは好機でもある。FabricPerf の著者らは、スケールアップ Ethernet や UALink が開放標準のネットワーク層を再導入した場合、現在のトランスポート層に置いた計測点が引き続き適切な粒度であり続けるかは検証課題だと述べている。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) Ultra Ethernet 側のトランスポート設計と輻輳制御の詳細は第9章で扱う。 ### 未解決の問い - スケールアップ網とスケールアウト網の切り替え境界は、並列化戦略(テンソル並列、パイプライン並列、エキスパート並列)ごとにどの粒度で最適化すべきか。高帯域ドメインの目標規模を、実在するモデル群のエキスパート数から定式化できるか。(参考: [[@2026__ICS__Closing the Efficiency Gap - AI Datacenter Co-design Roadmap for Scalable Training of LLMs]]) - 通信ライブラリの帯域推定モデルに、ホップ数だけでなくリンク本数と経路多重度を組み込む一般的な方法はあるか。LUMI で観測された取りこぼしは実装固有の欠陥か、それとも既存のトポロジ検出インターフェースの表現力不足に由来するか。 - FabricPerf が発見したチャネル不均衡の根本原因は、スイッチのポート選択なのか、通信ライブラリのスケジューリングなのか。ネットワーク層のテレメトリが公開されないまま、これを切り分ける方法はあるか。 - ACN(パッケージ内部)、スケールアップ網(ラック内)、スケールアウト網(ラック間)の 3 階層を、共通の指標体系で横断的に可視化できるか。それぞれ別のプロービング手法を要する現状で、統合された輻輳の帰属は成立するか。 - NVLink の CRC 再送は障害の何割を吸収し、どこから先をジョブ失敗として表面化させているか。再送回数や訂正済みエラーのカウンタを予兆指標として使えるか。 - スケールアップ網に Ethernet を持ち込む動きは、ベンダー独自ファブリックの性能特性(単一ホップ全結合、スイッチ内リダクション)をどこまで再現できるか。標準化による観測性の向上と、性能特性の後退はトレードオフになるか。 --- ## 第5章 CXL: メモリ意味論を持つインターコネクト 前章までで扱ってきたインターコネクトは、いずれもデバイスとホストの間でデータの塊を運ぶことを主眼としていた。 CXL(Compute Express Link)はその前提を変える。 CXL は PCIe の物理層の上に構築されたキャッシュコヒーレントなインターコネクト規格であり、サーバのメモリ容量をオンソケットの DRAM チャネルから分離し、外部のメモリエキスパンダ経由でメモリを追加または共有することを可能にする([[CXLによるメモリ拡張]])。 配線と信号は PCIe と同じものを使いながら、その上を流れる意味論がロード命令とストア命令になる点が、この規格の性格を決めている。 この違いは実装上の細部ではなく、システム設計の選択肢そのものを変える。 DMA 転送を前提とする経路では、アプリケーションかカーネルが「いつ、どこからどこへ、何バイト運ぶか」を明示しなければならないのに対し、CXL.mem で接続されたメモリは CPU のキャッシュミスとライトバックがそのままリンク上のトランザクションに変換され、アプリケーションからは単に遅い DRAM がもう一段増えたようにしか見えない([[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 ![[_attachments/2023_Pond_asplos23_official_asplos_version/fig01-cxl-request-flow.png]] **図5-1**: CPU のキャッシュミスとライトバックが HDM デコーダによって CXL ポート上のリクエストへ変換される経路。 Intel の実測ではラウンドトリップのポートレイテンシは 25ns である。(Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]]) その代償がレイテンシ予算の厳しさである。 ページフォルトを介す従来のメモリ切り離し手法がマイクロ秒級の遅延を許容できたのに対し、ロード命令の背後で待たされる CXL はナノ秒級の世界で評価される([[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 以下では、この「ナノ秒級で遅いメモリ」をどう抽象化し、どう配置し、どう観測するかという 3 つの問題を順に見ていく。 ### 5.1 PCIe 物理層の上に載るプロトコル群 CXL は単一のプロトコルではなく、同一のリンク上で役割の異なる複数のプロトコルを多重化する規格として設計されている。 本 wiki が収めるソースの範囲で確認できるのは、デバイス列挙と設定を担う **CXL.io** と、ホストからデバイス側メモリへのロード/ストアアクセスを担う **CXL.mem** の 2 つである。[[Vistara]] ASIC の内部構成は、PCIe Gen5 PHY と CXL 2.0 コントローラからなる CXL サブシステムの下に、CXL.mem 論理と CXL.io 論理を持つ CXL2DDR ブリッジを置き、その先に DDR4 のメモリコントローラを接続するという素直な三段構成をとる (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 ![[_attachments/Vistara_CXL_ISCA2026/fig04-vistara-asic-architecture.png]] **図5-2**: Vistara ASIC の内部構成。 PCIe Gen5 PHY と CXL 2.0 コントローラと内部 NOC からなる CXL サブシステム、CXL.MEM 論理と CXL.IO 論理を持つ CXL2DDR ブリッジ、2 チャネルの DDR4 メモリコントローラと PHY からなる DDR サブシステム、セキュアとブートとコントロールの 3 種の RISC-V プロセッサからなる CPU サブシステムで構成される。(Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]]) 残る CXL.cache は、デバイス側からホストメモリをコヒーレントにキャッシュする用途を担うが、本 wiki が収める実運用事例はいずれも CXL.cache を使っていない。 [[Vistara]] は CXL 2.0/1.1 準拠の Type-3 メモリエキスパンダであり、Pond の外部メモリコントローラ(EMC)は CXL 3.0 が標準化した多頭デバイス(multi-headed device)に相当する構成である (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]], [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 ただし CXL.mem のデータパスは 1 本ではない。 PathFinder は Intel Sapphire Rapids/Emerald Rapids における CXL.mem の経路を、demand read(DRd)、demand write が誘発する read for ownership(RFO)、RFO そのもの、ハードウェア/ソフトウェアプリフェッチ(HW/SW PF)の 4 種に分類している (Source: [[@2025__SIGCOMM__Understanding and Profiling CXL.mem Using PathFinder]])。 1 つのストア命令がストアバッファを経て RFO というコヒーレンスメッセージを発行し、その後にライトバックとして書き込まれるという事実は、「ロード/ストアで透過的にアクセスできる」という表面的な説明の裏側に、経路ごとに異なる遅延特性が隠れていることを意味する。 ![[_attachments/pathfinder-sigcomm25/fig01-cxl-mem-data-paths.png]] **図5-3**: Intel SPR/EMR プロセッサにおける CXL.mem の 4 種のデータパス。 DRd は L1D から LFB、L2、CHA(LLC スライス)を経てメッシュ経由でメモリコントローラへ至り、DWr はストアバッファ経由で RFO コヒーレンスメッセージを発行してからライトバックとして書き込まれる。 ソフトウェアとハードウェアのプリフェッチは DRd と RFO を非同期に誘発する。(Source: [[@2025__SIGCOMM__Understanding and Profiling CXL.mem Using PathFinder]]) ### 5.2 メモリ意味論が課すレイテンシ予算 メモリ意味論の利点は、既存のソフトウェアを変更せずに容量を増やせることにある。 Pond は、既存のメモリ切り離し手法を、ページフォルトを要するプロセスレベルのメモリ圧縮、FPGA ベースのハードウェア切り離し、アプリケーション API の変更を要するランタイムレベル手法の 3 系統に整理し、いずれもマイクロ秒級のレイテンシかゲスト OS の変更を要すると指摘する (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 CXL がこれらと異なるのは、ページフォルトなしでナノ秒級のアクセスを実現しつつ、静的なメモリ事前割り当てを要求する仮想化アクセラレータとの互換性を保てる点である。 その反面、遅延はそのままパイプラインのストールに変わる。 実測されたレイテンシは測定系によって幅があるが、いずれもローカル DRAM の 2 倍から 3.5 倍程度に収まる。 | 測定系 | ローカル | CXL 接続 | 出典 | |---|---|---|---| | Pond のプールサイズ試算(8 / 16 / 32 / 64 ソケット) | 85ns | 155ns(182%)/ 180ns(212%)/ 270ns 超(318%) | [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]] | | Meta MemServer のアイドルレイテンシ | 約 130ns | 約 250ns | [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]] | | Meta MemServer(帯域使用率 60%) | 234ns | 372ns | [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]] | | PathFinder の SPR サーバ実測 | 103.2ns / 131.1GB/s | 355.3ns / 17.6GB/s | [[@2025__SIGCOMM__Understanding and Profiling CXL.mem Using PathFinder]] | この予算のうち、リンクそのものが消費する分は意外に小さい。 Intel Sapphire Rapids における CXL ポートのラウンドトリップレイテンシは 25ns であり、その内訳はトランザクション層とリンク層で 4ns、Arb/Mux で 2ns、CXL および PCIe の物理層で 19ns である (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 残りを支配するのは、プールを大きくするために必要になる配線と中継である。 リタイマーは信号品質を保つために 500mm を超える配線で必要になり片方向あたり約 10ns を追加し、スイッチはポートと調停とオンチップネットワークで少なくとも 70ns を追加するため、プールの規模とアクセスレイテンシは直接トレードオフの関係に立つ (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 帯域についても、ローカル DRAM との差は 1 桁近い。 Meta の MemServer では、ローカルの DDR5-6400 が 12 チャネルで理論ピーク 614GB/s を持つのに対し、2 枚の Vistara ASIC 経由の CXL メモリは約 76GB/s であり、Intel Memory Latency Checker による全読み出しの実測でもローカル 497GBps(理論値の 80%)に対し CXL は 48GBps(同 62%)にとどまる (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 ### 5.3 CPU レス NUMA ノードという抽象化 CXL メモリをソフトウェアからどう見せるかについては、業界がほぼ同じ答えに収束している。 CXL.mem で接続されたデバイスは、ホスト OS からは追加の CPU レス NUMA ノードとして認識され、既存の NUMA 対応メモリ管理機構をそのまま転用できる([[CXLによるメモリ拡張]]、[[NUMAメモリ配置]])。 新しい抽象化を発明せずに済むのは、コアを持たずメモリだけを持つノードという構造を Linux が既に扱えるからである。 Meta の実装では、Linux CXL ドライバが BIOS に依存せず CXL メモリを `ZONE_MOVABLE` としてオンライン化し、ページテーブルやスラブキャッシュのような移動不可能な割り当てが CXL 側に混入しないようにする (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 その上でカーネルの TPP(Transparent Page Placement)とユーザランド駆動の TMO(Transparent Memory Offloading)が、実測アクセスパターンに基づいてホットページをローカル DRAM へ、コールドページを CXL へ動的に移す。 移動不可能な割り当てを排除しておくことが、TPP が自由にページを昇格させられる前提条件である。 ![[_attachments/Vistara_CXL_ISCA2026/fig07-numa-tiering.png]] **図5-4**: NUMA ノードを用いた CXL メモリの階層化。 OS はページをローカル DRAM(NUMA 0)へ割り当てたうえで、アクセスパターンに基づいてコールドページを CXL(NUMA 1)へ、ホットページをローカルへ動的に移す。 この移動はアプリケーションから透過的に行われる。(Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]]) Azure の Pond は同じ原則をハイパーバイザ層で実装した。 **zNUMA**(zero-core virtual NUMA ノード)は、ハイパーバイザが SLIT/SRAT テーブルにコアを持たないメモリブロックを追加することで構成され、ゲスト OS のメモリマネージャがローカル NUMA ノードを優先するという既定動作をそのまま利用する (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 zNUMA ノードのサイズが VM の未タッチメモリ量に正しく合っていればゲストはそこをほとんど触らず、Azure の本番 48 時間実験では動画会議、データベース、KV ストア、ビジネス分析の 4 ワークロードで zNUMA へのアクセスは全体の 0.06% から 0.38% にとどまった (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 ただし、この抽象化はサイズ設定を誤ると急速に破綻する。 同じ Pond のラボ実験では、未タッチメモリを過大に予測して 20% から 75% のメモリが zNUMA へ溢れた場合に最大 30% から 35%、全量をプールへ配置した場合に最大 50% のスローダウンが観測された (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 CPU レス NUMA ノードという見せ方は透過性を提供するのであって、配置の誤りを吸収してくれるわけではない。 ### 5.4 メモリプーリングと stranded memory クラウド事業者が CXL に期待する効果は、容量拡張よりもむしろ無駄の削減にある。 Pond が指摘する **メモリストランディング**(memory stranding)は、全コアが VM に貸与済みであるにもかかわらず未貸与のメモリがサーバに残る現象である (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 DRAM は Azure でサーバコストの 50%、Meta でラックコストの 40% を占めるため、この取り残しはそのままコストになる。 Azure の 100 本番クラスタ 75 日分の分析では、スケジュール済みコア比率が 75% の中央値スナップショットで 6%、85% で 10% 超のメモリがストランディングし、高利用率局面の 95 パーセンタイルでは 25%、個別の外れ値では 30% に達した (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 なお同論文の要約節にはコア比率 60% から 95% の全範囲を通じた 95 パーセンタイル幅として「3 から 27%、外れ値 36%」という別の数値も併記されており、参照範囲の違いに注意がいる。 ![[_attachments/2023_Pond_asplos23_official_asplos_version/fig02-memory-stranding.png]] **図5-5**: スケジュール済み CPU コア比率とメモリストランディングの関係。 コア比率が上がるほどストランディングは顕著に増え、エラーバーは 5 パーセンタイルと 95 パーセンタイル、点は外れ値を表す。(Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]]) Pond の設計判断で興味深いのは、プールを大きくしないという選択である。 本番トレースの分析から、8 から 16 ソケットにまたがるプーリングで利点の大半が得られることが示され、固定 50% プール割り当ての条件では 32 ソケットプールで 12%、64 ソケットプールで 13% と、拡大に伴う効果は明確に逓減した (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 前節で見たとおりプールの拡大はスイッチとリタイマーを要求しレイテンシを跳ね上げるため、効果が飽和する規模とレイテンシが悪化し始める規模がほぼ一致していたことが、小規模プールという設計点を正当化した。 ![[_attachments/2023_Pond_asplos23_official_asplos_version/fig06-emc-design.png]] **図5-6**: 複数の CXL ホストと DDR5 DIMM をつなぐマルチヘッド EMC の構成。 16 ソケットの Pond は 128 本の PCIe 5.0 レーンと 12 個の DDR5 チャネルを要求し、AMD Genoa の IO ダイに匹敵する規模になる。 32 ソケットと 64 ソケットの構成では、スイッチとマルチヘッド EMC を組み合わせる。(Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]]) 配置の決定に機械学習を使う点も Pond の特徴である。 VM は中身を検査できない不透明な存在として扱われるため、利用可能なのは VM のメタデータ、コアの PMU カウンタ、ハイパーバイザのページテーブルアクセスビットに限られる。 Pond は RandomForest によるレイテンシ非感受性の判定と、LightGBM による未タッチメモリ量の予測という 2 つのモデルを組み合わせ、VM 起動前にローカルとプールの配分を決める (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 16 ソケットプールで CXL レイテンシが 182% および 222% 増加する条件下での DRAM 削減はそれぞれ 9% と 7% であり、7% の DRAM 削減はサーバコスト全体の 3.5% に相当する (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 固定 15% をプール化する素朴な方式の削減率が 3% であることを踏まえると、予測の精度がそのまま削減幅に効いている。 予測を前提とする設計では、予測が外れたときの振る舞いが問われる。 Pond の場合、VM のメモリは常にハイパーバイザのページテーブルにマップされ続けるため誤予測は性能の急落ではなく緩やかな劣化として現れ、QoS モニタが許容劣化マージンの超過を検知すると全ローカル DRAM 構成へのライブマイグレーションで補正するが、この補正には 1GB あたり約 50ms のコストがかかる (Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]])。 ### 5.5 ASIC 設計から量産展開まで Pond の評価が本番サーバ上のエミュレーション層に依存していたのに対し、Meta の [[Vistara]] は実シリコンと本番フリートによる報告である (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 出発点は、数百万台のフリートのうち約 40% のサーバがメモリ容量律速にあるという観測だった。 メモリはサーバより長寿命であり(サーバが 5 年から 7 年、メモリが 10 年から 14 年)、DRAM はフリートの体化炭素排出の 69% を占める最大の単一要因でもあるため、廃止サーバから回収した DDR4 DIMM を CXL 経由で再接続する発想は容量とコストと炭素排出の 3 つを同時に狙うものだった。 この DIMM 再利用という要件が、既存の商用 CXL 製品を採用できない理由になった。 商用製品は DRAM をコントローラにバンドルする形態が主流で、回収 DIMM を挿す前提になっていないからである。 Vistara ASIC は Type-3 メモリエキスパンダとして設計され、PCIe Gen5 x16 のホストインタフェース(本番では x8 で運用)と 2 チャネルの独立した DDR4 を持ち、本番構成では 4 枚の 32GB DIMM を 1 チップで 128GB に集約する (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 アイドルラウンドトリップレイテンシは約 50ns、消費電力は約 9W で、RS(36,32) による 2 シンボル誤り訂正と x4 chip-kill 能力で再利用 DDR4 の信頼性を補う。 量産で問題になったのは、性能そのものよりも供給の多様性だった。 回収される DDR4 DIMM は 9 種類のコンポーネント構成に分散しており、上位 2 種でようやく 57% を占める程度で、ASIC は広範な DRAM デバイスと構成をサポートしなければならず、需給管理には専用のツールとプロセスが必要になった (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 論文はそのツールとプロセスの詳細を開示しておらず、他組織が同じ再利用戦略を再現する際の障壁として残っている。 ソフトウェア側では、マルチテナントの公平性が本番固有の課題として現れた。 2 つの分散キャッシュコンテナを同一ホストに同居させた場合、素の TPP ポリシーではコンテナ A がローカル DRAM の 90% を占有し、コンテナ B は 70% にとどまり、P99 レイテンシに 20% の偏差が生じ、ノイジーネイバー発生時にはコンテナ A の QPS が 65% 低下し OOM Kill される事例も観測された (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 コンテナ単位のメモリ階層アカウンティング(Fair Share)を導入してローカル DRAM 使用量に上限を課すと、両コンテナとも約 3:1 のローカル対 CXL 比を保ち、P99 レイテンシがそれぞれ 1.6 倍と 1.8 倍改善し、ノイジーネイバー時の QPS 低下も 12% に抑えられた。 フリート管理では、均一性と個別最適を層で分離する方針がとられた。 Meta は全ノードに一律 1TB の均一メモリトポロジを持たせて選択的な CXL オフラインを避ける一方、`cpuset.mems` cgroup コントローラによるソフトウェアのオプトアウト機構を用意し、BIOS 再設定やリブートなしにワークロード単位やコンテナ単位で CXL 利用を無効化できるようにした (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 本番 A/B テストによる改善は、サービスの性格によって現れ方が異なる。 | サービス | 分野 | 改善 | |---|---|---| | CacheA | 分散キャッシュ | スループット 25% 改善、保持時間 5 から 10 倍延長 | | CacheB | 分散キャッシュ | 平均クエリ処理時間 29% 削減 | | Spark | データウェアハウス | サーバあたり executor 数 25% 増加 | | CI | DevInfra | サーバあたりジョブ数 33% 増加 | | MRS | ML パラメータサーバ | サーバ台数 25% 削減、スループット 12% 向上 | (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]] Table VII) これらの改善が成立する条件は、ホットページとコールドページの分離が効いていることである。 ホットフットプリント割合を合成的に変化させたストレステストでは、60% までレイテンシオーバーヘッドは 1% 以内に収まるが、75% で 4%、80% で 8%、100% で 22% と急速に悪化する膝(knee-of-the-curve)が現れる一方、評価された本番ワークロードはいずれもこの閾値を大きく下回る平坦領域で稼働していた (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 本番テレメトリでも CXL 帯域はローカル帯域の 10 分の 1 から 100 分の 1 にとどまっており、現行の PCIe x8 接続で足りているという判断を裏付ける。 ただしこの帯域比の低さは、ソフトウェアが意図的にコールドページを CXL 側へ寄せてアクセス頻度自体を下げた結果であって、デバイスの帯域が余っていることを意味するわけではない (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 Vistara はまた、CXL に対する 2 つの懐疑論を実測で反証している。 FPGA ベースの先行評価が報告した不安定なテールレイテンシは、低レイテンシ設定、レイテンシクリティカルなブロックのタイトなフロアプランニング、十分な完了バッファとリプレイ深度といった物理設計上の工夫によって解消でき、同時レイテンシスレッド数を変えたレイテンシ CDF は CXL もローカル DRAM と同様の裾の伸び方を示した (Source: [[@2026__ISCA__Vistara - Making CXL Real—Full Path from ASIC Design and OS Support to Hyperscale Deployment]])。 TPP のオーバーヘッドについても、複雑な OS 最適化を追加せずに 0.5% 未満で運用できている。 ただし著者ら自身が留保するとおり、これはシンプルな LRU ベースのホットネス検出器が実運用で十分だったという結果であり、より複雑な検出を要するワークロードが存在しないことの証明ではない。 ### 5.6 CXL.mem の観測はなぜ難しいか CXL メモリが遅いことは合意されているが、なぜ遅いのかを分解する手立ては長らく欠けていた。 困難は 3 つある (Source: [[@2025__SIGCOMM__Understanding and Profiling CXL.mem Using PathFinder]])。 CXL.mem は 4 種のデータパスを持ち計算基盤とメモリ基盤と I/O 基盤にまたがる非透過的な経路であること、ロード/ストア命令が深いアウトオブオーダーパイプラインとナノ秒粒度で密結合しており実行状態を問い合わせるインタフェースがほとんど存在しないこと、そしてローカルメモリと CXL メモリのストリームが同一ハードウェアを共有して交錯するため両者の挙動を切り分けにくいことである。 PathFinder はこの問題に、サーバプロセッサとチップセットを多段 Clos ネットワークとみなすという着想で応えた([[CXL.memプロトコル実行プロファイリング]])。 コア、ストアバッファ、L1D、LFB、L2、CHA、CXL DIMM を頂点、オンコア FIFO やメッシュインターコネクトや FlexBus を辺とするグラフを構成し、各モジュールに PMU ベースのテレメトリエンジンを配置して 232 種の PMU カウンタから CXL.mem の実行を追跡する (Source: [[@2025__SIGCOMM__Understanding and Profiling CXL.mem Using PathFinder]])。 その上で、経路上のノードを特定する traceroute、逆向きに遅延を帰属させる reverse traceroute、Little's Law に基づく遅延ベースのキューイング解析という、ネットワーク領域で確立された解析技術をホスト内部へ転用する。 方法論としての新しさは、オンチップの非効率とオフチップの CXL アクセスを同一のモデルの下で関連づけた点にある。 得られた知見は、CXL の遅さが単一の場所に局在しないことを示す。 CXL メモリへのアクセスは、L1D でパイプラインストールサイクルを平均 2.1 倍、L2 でコアストールサイクルを平均 2.7 倍に増加させ、LLC ヒットを DRd で 46.5%、RFO で 41.3%、HWPF で 62.2% 減少させる一方、LLC ミスをそれぞれ 4.2 倍、4.0 倍、5.3 倍に増やす (Source: [[@2025__SIGCOMM__Understanding and Profiling CXL.mem Using PathFinder]])。 back-propagation によるストールサイクル分解では、CXL 起因のストールが FlexBus とメモリコントローラから L1D へ向かうにつれ DRd 経路で平均 74.5%、RFO 経路で 67.8% 減衰することが定量化され、階層キャッシュが遅さを段階的に吸収するという直感が実測値として裏づけられた。 干渉の検出は、この手法がとくに有効な領域である。 同一コア上にローカルと CXL の 2 つのメモリフローを置いて CXL 側の負荷を 20% から 100% へ上げると、FlexBus と CHA のキューイングが安定しているにもかかわらず、コア内の CXL 起因ストールがストアバッファで 1.7 倍、L1D と LFB で 2.2 倍、L2 と LLC で 2.4 倍に増加した (Source: [[@2025__SIGCOMM__Understanding and Profiling CXL.mem Using PathFinder]])。 共有資源が輻輳していなくてもコア内部で待ちが育つという現象は、単一レイヤーのプロファイラでは見えない。 PathFinder は Linux Perf 上に実装され、平均 1.3% の CPU サイクルと 38MB のメモリという軽量さで動作する。 観測は配置最適化の入力にもなる。 PathFinder が TPP を有効化した際の内部変化を追った事例では、FlexBus とメモリコントローラのレイテンシが DRd で 78.6%、RFO で 83.5%、HWPF で 79.1% 削減され、GUPS のスループットは 3.0 倍に向上した (Source: [[@2025__SIGCOMM__Understanding and Profiling CXL.mem Using PathFinder]])。 さらに PathFinder が算出するローカルと CXL のレイテンシを Colloid の固定 DRd レイテンシの代わりに与えることで、GUPS スループットが 1.1 倍向上している。 ただし実測アプローチには限界もある。 RFO と HWPF 専用の PMU カウンタがコア内に存在しないため、L1D と LFB のレベルでは RFO と demand write を監視できず、L2 の RFO カウンタは demand と prefetch を区別できない (Source: [[@2025__SIGCOMM__Understanding and Profiling CXL.mem Using PathFinder]])。 CXL 仕様 3.0/3.1 が定義するデバイス側の QoS テレメトリも、評価に使われた市販デバイスはいずれも未対応だった。 この空白を別方向から埋めるのが [[CXLMemSim]] のようなシミュレーションであり、同じ著者らの eGPU は GPU のロード/ストア命令をフックして動的にレイテンシを挿入し、CXL アタッチメモリの高レイテンシと低帯域を疑似する手法を示した (Source: [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]])。 実機 PMU で見える範囲を PathFinder が、見えない範囲をシミュレーションが担うという役割分担になっている。 ### 5.7 LLM サービングにおけるティアードメモリ CXL の議論をそのまま LLM サービングへ持ち込む前に、区別しておくべき点がある。 LLM 推論のメモリ圧迫は深刻で、OPT-30B は重みだけで 60GB、コンテキスト長 8K の KV キャッシュがさらに 10.56GB を要する (Source: [[@2026__SIGCOMM__DynamoServe - A Distributed Tiered Memory System for Multi-tenant LLM Serving]])。 だが DynamoServe が構成するメモリ階層はローカル GPU、ピア GPU、CPU、NVMe の 4 段であり、ピア GPU の遊休 HBM を NVLink 経由でプールする設計であって、CXL 接続メモリを階層に含んでいない。 それでも設計論としての共通点は明確である。 どちらも「遅いが容量の大きい階層」を追加し、どの状態をどの階層に置くかという配置問題に帰着する。 DynamoServe の集中型コントローラは、各リクエストの重み、KV キャッシュ、活性化について階層ごとの配置割合を決め、転送コストと SLO を考慮して総レイテンシを最小化する (Source: [[@2026__SIGCOMM__DynamoServe - A Distributed Tiered Memory System for Multi-tenant LLM Serving]])。 オフロード先を単一のリモート階層に限定する FlexGen や Aqua に対し、複数のピア GPU へ状態を分散できる点が DynamoServe の差分であり、単一ピアに空きがなければ PCIe 経由の DRAM オフロードに落ちる Aqua と比べてスループットを 2 倍以上に改善した。 CXL メモリプールを LLM 推論に用いる方向としては、KV キャッシュの TTFT 短縮に特化した専用プールの事例が [[KVキャッシュ管理]] に記録されている。 [[CXLによるメモリ拡張]] が整理するとおり、CXL の用途はワークロード粒度によって、汎用ワークロードを対象にページ単位のホット/コールド判定で透過的に階層化する「容量階層化」と、単一用途に特化した「専用プールオフロード」の 2 系統に分岐する。 Vistara は前者、KV キャッシュ向けプールは後者にあたり、Pond は 8 から 16 ソケットの小規模プールと VM 起動前の ML 予測配分という第三の設計点を占める。 CXL メモリプーリングの設計空間は、対象スケールと配置決定のタイミングという 2 軸で分岐していると整理できる。 ### 未解決の問い - 汎用の容量階層化(Vistara/TPP)と用途特化の専用プールを同一データセンターで使い分ける基準は何か。両者を 1 つの CXL ファブリック上で共存させる際のリソース競合とスケジューリング設計は、本 wiki のソースには現れていない。 - Pond の配置前予測と TPP の実行時ページ配置を組み合わせたハイブリッド設計は成立するか。誤予測を継続的な再配置で吸収できれば、より少ない補正コストで同等の DRAM 削減を達成できる可能性があるが、統合した実証はまだない。 - Pond が前提とする 8 から 16 ソケットの小規模プールで有効だった ML 予測モデルは、ラック規模やデータセンター規模のプールでも精度を維持できるか。プール規模の拡大は VM 間の競合パターンを変え、特徴量設計に影響しうる。 - Vistara の設計判断は DDR4 再利用と PCIe Gen5 x8 という現行世代の前提に立つ。CXL メモリ圧縮のような高帯域を要する用途が普及した場合、PCIe x16 や DDR5 ベースのデバイスへの移行は既存の TPP/NUMA 階層化スタックにどの程度の変更を要求するか。 - PathFinder が明らかにしたマイクロアーキテクチャレベルの劣化パターンは、Vistara のような本番システムのホットページ判定をどう改善しうるか。Vistara は PMU ベースの微視的診断を用いておらず、両者を組み合わせた実証は未着手である。 - マルチノードかつマルチテナントの CXL メモリプールで、PMU ベースの診断は帰属を保てるか。プール共有によって、どのテナントのメモリフローが競合の原因かを PMU カウンタから切り分けること自体が困難になる可能性がある。 --- ## 第6章 ホストネットワークスタック アクセスリンクが 100 Gbps へ到達した時点で、ネットワーク性能の制約はネットワークコアからホストの内側へ移った。 データセンターのアクセスリンク帯域は数年で 4 倍から 10 倍に伸びたのに対し、コア速度、コア数、キャッシュ容量、NIC バッファ容量の伸びははるかに小さい。 この不均衡が、ホストネットワークスタックのボトルネックを質的に変えた。 最適化をすべて有効にした Linux でも、100 Gbps リンク上の単一の長フローに対するスループット毎コアは約 42 Gbps に留まり、単一コアでは線速に届かない。 (Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) 本章は、NIC からアプリケーションバッファまでの経路を三つの観点から分解する。 第一はスループットであり、どの処理段がコアあたりのバイト転送量を制限しているかを CPU サイクルの内訳とキャッシュミス率で説明する。 第二はレイテンシであり、同じ Linux スタックでも要求単位のテールを支配する要因はスループット効率を支配する要因と一致しない。 第三はソケット内部のインターコネクトであり、CPU サイクルを一切消費しない LFB、CHA、IIO、メモリコントローラの間でもホストネットワークは競合する。 ![[_attachments/Understanding_host_network_stack_overheads/fig01-linux-network-stack-data-path.png]] **図6-1**: Linux ネットワークスタックの送信経路と受信経路。 受信側は NIC の DMA から IRQ、NAPI、GRO、RPS/RFS を経てソケットへ到達し、送信側はアプリケーションからソケット、TCP/IP、ネットワークサブシステム、ドライバへ下る。(Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) 高速化の系譜も同じ枠組みで整理できる。 BPF、netmap、XDP、SmartNIC はいずれも「どの処理を、どの保護境界の内側で、どの粒度で行うか」を組み替えた設計であり、速度と引き換えに何かを捨てている。 何を捨てたかを明示しないまま性能値だけを比較すると、適用条件を誤る。 最後に、コンテナ環境ではこの経路にさらに veth、ブリッジ、Netfilter、オーバーレイトンネルが積み重なることを見る。 ### 6.1 スループット側のオーバーヘッド分解 #### per-byte コストとしてのデータコピー 100 Gbps の Linux スタックにおいて、受信側 CPU の最大の消費要因はカーネルバッファからアプリケーションバッファへのデータコピーである。 最適化をすべて有効にした状態で、データコピーは受信側 CPU 使用率の約 49% を占めた。 受信側は NIC が DMA したデータのコピーと `skb` の確保、解放を担うため、送信側より常に CPU 使用率が高い。 (Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) この配分は測定条件の副産物ではなく、per-packet 処理を先に削減した結果として per-byte コストが露出したものである。 2012 年の netmap がパケットごとの動的メモリ確保、システムコール、カーネルとユーザー空間のコピーを取り除いて 10 Gbps の線速を達成したのに対し、TSO と GRO が per-packet 処理を吸収した先ではデータ移動そのものが次のボトルネックとして残る。 (Source: [[@2012__USENIX-ATC__netmap A Novel Framework for Fast Packet IO]]) ![[_attachments/Understanding_host_network_stack_overheads/fig03-single-flow-performance.png]] **図6-2**: 単一フローでの最適化ごとの送受信 CPU 使用率、CPU サイクル内訳、キャッシュミス率、TCP 受信バッファサイズと NAPI からコピー開始までの遅延。 受信側ではデータコピーが最大の消費要因になる。(Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) #### per-packet 処理とパケット集約 per-packet コストは固定値ではなく、集約がどれだけ効くかで変わる。 送信側では TSO が TCP/IP 層と netdevice 層の処理量を減らし、受信側では GRO が `skb` の個数を減らす。 問題は、集約機会がフロー数に反比例して減ることである。 all-to-all で 1×1 から 24×24 までフロー数を増やすと、GRO が一つのフローから十分なパケットを集められず、64 KB の `skb` が減り、スループット毎コアは約 67% 低下した。 同じ理由で、RPC サイズ 4 KB の短フローでは GRO の効果が限定的であり、データコピーではなく TCP/IP 処理とスケジューリングが相対的に大きくなる。 16 KB へ増やすとデータコピーが主要因になり、64 KB では長フローと似た内訳になる。 (Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) #### キャッシュ容量と NUMA 配置 **DDIO** に代表される **DCA**(Direct Cache Access)は、NIC の DMA を L3 キャッシュへ直接書き込むことでメモリ往復を省く。 ただし利用できるキャッシュ容量には上限があり、測定環境では L3 の約 18%、およそ 3 MB であった。 帯域遅延積がこの容量を超えると、アプリケーションがコピーする前に後続の DMA が同じキャッシュ領域を追い出す。 実際、TCP 受信バッファを 1600 KB より大きくすると NAPI 処理からコピー開始までの遅延が急増し、単一フローでもキャッシュミス率は約 49% に達した。 DCA を無効化するとスループット毎コアは 19% 低下し、aRFS の効果も約 50% 減少する。 (Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) バッファを増やせば性能が上がるという直感は、この領域では逆に働く。 NUMA 配置も同じ経路上の問題である。 NIC からリモート NUMA ノードのアプリケーションへデータを渡すと、スループット毎コアは NIC ローカル配置より約 20% 低下し、キャッシュミス率も増える。 aRFS はアプリケーションが動作するコアへ受信フローを寄せることでこの非局所性を減らすが、無効にすると NIC はリモート NUMA メモリへ DMA し、データコピーのコストが増える。 短フローはリモート NUMA でも長フローほど劣化しないため、長フローを NIC ローカル NUMA へ、短フローをリモート NUMA へ配置する資源配分の余地がある。 また IOMMU を有効にすると、DMA 用ページをデバイスページテーブルへ登録し DMA 後に解除する処理により、受信側のメモリ管理が CPU サイクルの 30% を占め、スループット毎コアは 26% 低下した。 (Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) #### フロー競合が per-byte コストを押し上げる フローの多重化は、CPU 内訳の形を変えずに 1 バイトあたりのコストを押し上げる。 incast でフロー数を 1 から 8 へ増やすと、同じ L3 キャッシュを共有するアプリケーション間の競合により L3 キャッシュミス率が 48% から 78% へ上がり、スループット毎コアが約 19% 低下した。 TCP は送信側主導であるため、受信側は一つのコアが同時に処理するアクティブフロー数を制御できない。 一方で送信側の処理経路は効率がよく、outcast ではスループット毎送信コアが最大約 89 Gbps に達し、incast の受信側ボトルネックの約 2.1 倍になった。 長フローと短フローを同じコアへ混在させると全体のスループット毎コアは約 43% 低下し、長フローは約 42 Gbps から約 20 Gbps へ、短フローは約 6.15 Gbps から約 2.6 Gbps へ落ちる。 異なるボトルネックを持つフローに同じ固定処理経路を適用することが、この劣化の機構である。 なお輻輳制御アルゴリズムの選択(CUBIC、BBR、DCTCP)は、受信側 CPU がボトルネックになるこの条件ではスループット毎コアにほとんど差を生まなかった。 3 方式がいずれも送信側主導であり、受信側処理の差が小さいためである。 (Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]]) ### 6.2 レイテンシ側の分解が示す別の支配要因 #### 単一フロー時のスタック性能 テールレイテンシの分析は、スループット分析とは異なる結論に着地する。 64 バイト RPC の ping-pong を 400 Gbps 環境で計測すると、孤立した 1 スレッドでの Linux の平均エンドツーエンドレイテンシは 12.9 マイクロ秒、P99.9 は 19 マイクロ秒であった。 ビジーポーリングを使えば P99.9 は 14 マイクロ秒になるが、両端の CPU 使用率が約 2.28 倍になる。 ユーザー空間スタック TAS の高速経路との差も 5 マイクロ秒に過ぎない。 (Source: [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) つまり、しばしば報告されるミリ秒規模のテールは、パケット処理そのもののコストではなく競合下でのみ現れる。 #### CPU 資源管理の三つの欠陥 競合が入ると様相が変わる。 単一コアへスレッドを増やすと、アプリケーション起床までの区間 `rx_sched` がテールの最大要因になり、48 スレッドの knee point で P99.9 は 1,139 マイクロ秒に達した。 第一の原因は、softIRQ の処理時間がそのパケットの所有者とは無関係に現在実行中のスレッドへ課金されることである。 パケット到着の偶然の偏りが virtual runtime の差に変換され、その差が起床順序と処理量の差をさらに広げる正のフィードバックになる。 各 CPU accounting event で IRQ 時間を更新する ACCa は、この knee point の P99.9 を 415 マイクロ秒へ下げた。 既存の IRQ 時間計上オプションだけを有効にした構成は逆に P99.9 が 4.7% 増加しており、計上の粒度が結果を左右する。 第二は、CPU runtime を公平性の抽象として使うことの限界である。 softIRQ 時間を除いても、キャッシュミスや TLB ミスによる stall が実行時間を伸ばし、それが「より多く仕事を進めた」と解釈されてしまう。 送受信した要求数を公平性の単位に置き換える PCSched は、同じ点で 276 マイクロ秒を達成した。 第三は、バースト性トラフィックに対する割り込み調整の非効率である。 DIM は過去履歴から最適点を予測できないが、ping-pong では in-flight パケット数と処理時間が事前にわかる。 これを利用する AutoDIM は 44 スレッドの knee point で P99.9 を 215 マイクロ秒まで下げた。 (Source: [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) ![[_attachments/Understanding_Host_Network_Stack_Latency/fig03-thread-contention.png]] **図6-3**: 単一コア上のスレッド数を増やしたときのスループットと P99.9 レイテンシ。 Linux、IRQa、ACCa、PCSched の 4 構成を比較すると、knee point の位置とテールの高さが構成ごとに異なる。(Source: [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) #### 二つの分析は何が違うのか 両者は同じ Linux スタックを対象にしながら、測定単位と支配要因が異なる。 | 観点 | スループット分析(2021) | レイテンシ分析(2026) | |---|---|---| | 主指標 | スループット毎コア、CPU サイクル内訳 | 要求単位のエンドツーエンド P99.9 | | 計測粒度 | 8 分類の CPU 使用率 | 受信 6 区間、アプリケーション、送信 5 区間の 12 コンポーネント | | 代表ワークロード | 100 Gbps の長フロー、5 通信パターン | 400 Gbps の 64 バイト RPC ping-pong | | 支配要因 | 受信側データコピー(約 49%)、DCA キャッシュ、NUMA | `rx_sched` と `rx_irq`、CPU 資源管理 | | 処方 | ゼロコピー、資源認識型スタック | IRQ 時間計上、公平性単位、割り込み調整 | (Source: [[@2021__SIGCOMM__Understanding Host Network Stack Overheads]], [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) この対比から読み取るべきは、ホストネットワークスタックのボトルネックが固定されていないことである。 帯域、フローサイズ、接続数、in-flight 数、CPU 競合の組み合わせによって、支配要因はデータ移動からスケジューリングへ移りうる。 (Source: [[ホストネットワークスタック性能]]) 運用上の含意もこの差から導かれ、スレッド数を増やして並行度を上げるより 1 コアあたり少数スレッドで in-flight 要求を増やすほうが集約を保ちやすい。 2 スレッドで 32 in-flight の構成は 1.28 million IOPS と P99.9 90 マイクロ秒を両立した。 (Source: [[@2026__SIGCOMM__Understanding Host Network Stack Latency]]) ### 6.3 ソケット内部のコンポーネント間競合 CPU サイクルを一つも使わない場所でも、ホストネットワークは競合する。 ホストネットワークを、コア、LFB(Line Fill Buffer)、CHA(Caching and Home Agent)、LLC、IIO(Integrated IO controller)、MC(Memory Controller)、DRAM が連なる内部ネットワークとして捉えると、この競合は**ドメインごとのクレジットベースフロー制御**として説明できる。 各ドメインは独立にクレジットを持ち、1 リクエストの送出で 1 クレジットを消費し、受信確認で補充される。 任意のドメインのスループットは $T \leq C \times 64 / L$ で上界され、$C$ はクレジット数、$L$ はドメイン内の全ホップを通過するレイテンシである。 (Source: [[@2024__SIGCOMM__Understanding the Host Network]]) コアと LFB と CHA/LLC と IIO と MC と DRAM の接続関係、および C2M と P2M の 2 種のデータパスは、第2章の図2-2 に示したとおりである。 ドメインの範囲は、リクエストの発生源と種別で非対称に決まる。 | ドメイン | 範囲 | クレジット源 | 無負荷レイテンシ | |---|---|---|---| | C2M-Read | LFB から DRAM まで | LFB(10〜12 キャッシュライン) | 約 70 ns | | C2M-Write | LFB から CHA までの 1 ホップ | LFB | 約 10 ns | | P2M-Read | IIO から DRAM まで | IIO 読み取りバッファ(164 以上) | 未確定 | | P2M-Write | IIO から MC までの 2 ホップ | IIO 書き込みバッファ(約 92) | 約 300 ns | (Source: [[@2024__SIGCOMM__Understanding the Host Network]]) この非対称性が、直感に反する現象を生む。 コアからのメモリアクセス(C2M)は無負荷でも約 70 ns で完結し、単独実行の時点で LFB クレジットを使い切っているため、ドメインレイテンシがわずかに伸びただけでスループットが落ちる。 一方、NIC やストレージからのメモリ書き込み(P2M)は非同期にサービスされ、クレジットにも余裕がある。 結果として、メモリ帯域が理論最大の 33% から 53% しか使われていない段階でも、Redis は 1.25 倍から 1.32 倍、GAPBS は 1.28 倍から 1.98 倍に劣化する一方、同居する P2M 側は無傷という「青レジーム」が生じる。 その機構は、C2M と P2M が異なるアドレス空間へアクセスすることで DRAM の行局所性が崩れ(行ミス率は最大 4 倍)、静的なアドレスからバンクへの写像がバンク間の負荷を偏らせることにある。 メモリ帯域が飽和した後は、MC の書き込みキュー飽和が CHA へバックログを作り、MC を含む P2M-Write 側が大きく劣化する「赤レジーム」へ移る。 著者らはこの全観測を、ネットワーク越しの転送を一切介さずローカルストレージだけで再現しており、現象はネットワークアプリケーションに固有ではない。 (Source: [[@2024__SIGCOMM__Understanding the Host Network]]) 処理オーバーヘッドと内部競合は区別すべき別の現象である。 前者は CPU が処理し切れないことによる遅延であり、後者はインターコネクトが輸送し切れないことによる輻輳である。 両者が 100 Gbps を超えるホストでどう複合するかは、いずれの側からも未検証のまま残る。 (Source: [[ホストネットワークスタック性能]]) ### 6.4 カーネルバイパスの系譜 #### BPF: コピーをフィルタで減らす 高速パケット処理の系譜は、1993 年の BPF から始まる。 BPF はレジスタ 2 個の仮想機械命令セットと制御フローグラフに基づく評価を導入し、先行する CSPF に対して 5 倍から 20 倍の高速化を示した。 ただし著者らが強調したのは命令実行の速さではなく、合格したパケットだけをユーザー空間へコピーすることでコピーコストを削減する点である。 フィルタプログラムのコンパイルをユーザー空間で行い、カーネルはバイトコードを検証してから実行するという分離も、この時点で定まった。 (Source: [[@1993__USENIX__The BSD Packet Filter A New Architecture for User-level Packet Capture]]) #### netmap によるリング共有 netmap は、汎用 OS のパケット I/O が抱える 3 種のコストを名指しした。 FreeBSD の `sendto()` はワイヤ到達まで 950 ns を要し、これは 1.05 Mpps に相当する。 10 Gbps の線速 14.88 Mpps には 14 倍以上足りない。 netmap は資源の事前確保で動的メモリ確保を排し、システムコールを大きなバッチで償却し、カーネルとユーザー空間でバッファとメタデータを共有することでコピーを排した。 その結果、900 MHz の単一コアで 14.88 Mpps に到達し、パケットあたりの償却コストは 60 から 65 CPU サイクルになった。 バッチサイズの効果は明瞭で、バッチ 1 では 2.45 Mpps(408 ns/パケット)に留まり、8 以上で線速に届く。 `poll()` 自体のオーバーヘッドが約 250 ns あり、これを何パケットで割れるかが分かれ目になる。 (Source: [[@2012__USENIX-ATC__netmap A Novel Framework for Fast Packet IO]]) netmap が捨てたのはプロトコル処理である。 インタフェースを netmap モードにすると NIC はホストプロトコルスタックから部分的に切り離され、TCP/IP はアプリケーション側の責任になる。 捨てなかったのは保護であり、デバイスレジスタとカーネルメモリはユーザー空間から隔離される。 この点で、NIC を完全にユーザー空間へ渡す方式とは安全モデルが異なる。 ![[_attachments/atc12-final186/fig03-netmap-mode-architecture.png]] **図6-4**: netmap モードのアーキテクチャ。 NIC のリングは netmap API を通じてアプリケーションとやり取りし、ホストスタックへは別のリングペアで接続されるため、OS は `ifconfig` のような管理機能を実行し続けられる。(Source: [[@2012__USENIX-ATC__netmap A Novel Framework for Fast Packet IO]]) #### XDP: カーネルの中へ処理を持ち込む XDP はバイパスの逆方向を選んだ。 ハードウェアの制御をカーネルの外へ出すのではなく、性能に敏感な処理をデバイスドライバのコンテキストへ持ち込み、`sk_buff` の確保やパケット解析より前に eBPF プログラムを実行する。 安全性は verifier が担保し、制御フローグラフに閉路がないことを確認したうえで、全経路のメモリアクセス境界とヘルパー関数の引数型を検査する。 単一コアのパケットドロップ性能は 24 Mpps であり、Linux ネットワークスタックの最速モード(raw テーブル)の 4.8 Mpps に対して 5 倍、conntrack を使う標準構成の 1.8 Mpps に対して 13 倍以上になる。 DPDK の 43.5 Mpps には届かないが、DPDK は制御タスクに 1 コアを専有し、busy polling のため CPU 使用率が常に 100% に張り付くのに対し、XDP と Linux は負荷に応じて CPU 使用率が滑らかに下がる。 (Source: [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]]) XDP が捨てたのは表現力である。 verifier はループを許さず、プログラムサイズにも上限があり、標準ライブラリを持たない。 安全と証明できないプログラムは、実際には安全であっても拒否される。 ステートフルなトランスポートプロトコルへの拡張は著者ら自身が「自明ではない」としている。 ![[_attachments/The_eXpress_data_path/fig01-architecture.png]] **図6-5**: XDP フックの位置と処理の分岐。 デバイスドライバはパケットデータに触れる前に eBPF プログラムを実行し、ドロップ、同一インタフェースへの送り返し、別インタフェースや AF_XDP ソケットへのリダイレクト、通常のスタックへの継続のいずれかを選ぶ。 通常のスタックへ進んだ場合は、キューイング前に TC BPF フックがさらに処理できる。(Source: [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]]) | 方式 | 得たもの | 捨てたもの | |---|---|---| | BPF | コピー削減と安全なカーネル内フィルタ | フィルタ以上の処理能力 | | netmap | 線速のパケット I/O と OS プリミティブとの互換 | ホストプロトコルスタックの処理 | | XDP | ドライバ文脈での高速処理とカーネルの管理境界 | プログラムの表現力(ループ、サイズ、ステート) | | 完全バイパス(DPDK 等) | 最高のパケットレート | OS の分離機構、管理ツール、CPU の弾力性 | (Source: [[@1993__USENIX__The BSD Packet Filter A New Architecture for User-level Packet Capture]], [[@2012__USENIX-ATC__netmap A Novel Framework for Fast Packet IO]], [[@2018__CoNEXT__The eXpress Data Path - Fast Programmable Packet Processing in the Operating System Kernel]]) 処理をカーネル外へ移すこと自体は、ホスト資源の問題を解決しない。 NUMA 配置、キャッシュ競合、長短フローの混在、アプリケーションとネットワークのスケジューリング協調は、スタックの置き場所とは独立した設計問題として残る。 (Source: [[ホストネットワークスタック性能]]) ### 6.5 SmartNIC、IPU、DPU への機能移動 機能をホストの外へ移す動きは、直線的な進歩ではなく振り子として現れてきた。 1990 年代はトランスポートプロトコルの最適解が未確定だったため、CPU と当時最大級の FPGA を載せた最大限柔軟な NIC が合理的だった。 2000 年代に TCP/IP が数十 Gbps を問題なく捌けることが実証されると、プロトコルは固定化し NIC も固定機能へ回帰した。 2010 年代に SDN、ネットワーク仮想化、ソフトウェア定義ストレージでネットワーキングが再び動的になると、ソフトウェアの頻度で更新できる柔軟な NIC が求められた。 (Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]]) TCP ヘッダー処理を NIC へ移す TCP オフロードは、単純な TCP/IP ヘッダーには有効だったが、ネットワーク仮想化のカプセル化ヘッダーが加わると恩恵を受けられず、むしろ不利になった。 この経験が GENEVE というカプセル化標準へ繋がっている。 オフロードの単位を決めるうえで効く判断基準は、対象機能が独立した操作の集合か、相互依存した処理パイプラインかである。 仮想スイッチのような複合機能では、機能の 90% しか移せなければ残り 10% の CPU 処理がボトルネックとして残る。 したがってオフロード用エンジンには完全なプログラム可能性が要る。 Intel の Mount Evans ASIC が ARM CPU コアと P4 プログラマブルなネットワーキングハードウェアを組み合わせるのは、この要求への応答である。 (Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]]) 一方、コネクション確立や切断のように互いに独立した操作であれば、ホストが制御の主導権を保持したまま部分的なオフロードが成立する。 (Source: [[スマートNICオフロード]]) IPU と DPU の位置づけは、性能最適化の枠を越える。 ゲスト(テナント)のワークロードとクラウド運用者が責任を持つインフラ機能を、別々の計算機システムへ分離する手段として捉え直せる。 分離が実現すれば、IPU 側の負荷急増がゲストの性能に波及せず、ゲストがハイパーバイザを持つ必要すらなくなる。 サーバをゲストへ 100% 割り当てられるようになり、物理サーバの構成に縛られないネットワーキングとストレージの組み合わせが可能になる。 ただしこれは、移した先が当該タスクを効率よく実行できて初めて成り立つ話である。 機能をカーネル内に置くかユーザー空間に置くか、ホストのプロセッサに置くか NIC に置くかという問いは、セキュリティ境界とコストのトレードオフの両方に依存し、単一の正解を持たない。 (Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 10 SmartNIC、IPU、DPU]]) ### 6.6 コンテナ環境での追加コスト コンテナオーケストレーションは、これまで見てきた経路の上にさらに層を重ねる。 Kubernetes では **CNI**(Container Network Interface)プラグインが、IP アドレス管理、インタフェース設定、route と iptables の設定、ネットワークポリシー適用を担う。 実装は通信レイヤー(Layer-3 かハイブリッド)と転送方式(オーバーレイかアンダーレイ)の 2 軸で 4 クラスに整理できる。 (Source: [[Container Network Interface (CNI)]]) プラグインの違いは、パケットあたり CPU サイクル(CPP)の内訳として現れる。 同一ホスト内の Pod 間通信では、Netfilter の走査コストが最大の要因になりうる。 eBPF ベースの Cilium は veth にアタッチした eBPF プログラムで転送とフィルタリングを一体化し、iptables のチェーン数を 0 にする。 結果として約 44.5 Gbps のスループットと約 20.2 マイクロ秒のレイテンシで全プラグイン中最良となり、eBPF のオーバーヘッドは約 189 CPP で他プラグインの Netfilter(約 245 CPP)より小さい。 対照的に、ネットワークポリシーを有効にした Calico は既定で 17 の追加ルールを持ち、Netfilter が 324 CPP(他プラグインの 1.35 倍)を占め、レイテンシは約 25.3 マイクロ秒と最も高い。 (Source: [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]]) ![[_attachments/cni-plugins-tnsm2021/fig09-overhead-breakdown-intra-host.png]] **図6-6**: 同一ホスト内 Pod 間通信におけるパケットあたり CPU サイクル(CPP)の内訳。 FIB、ブリッジ、Netfilter、BPF、IP、veth の各要素に分解すると、ネットワークポリシー有効の Calico は Netfilter だけで 324 CPP を占める。 Cilium の eBPF オーバーヘッドは約 189 CPP で、他プラグインの Netfilter(約 245 CPP)より小さい。(Source: [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]]) ホスト間通信では、オーバーレイのカプセル化と NIC のオフロード対応が効く。 ネイティブルーティング(アンダーレイ)は約 18 Gbps から 19.7 Gbps を維持する一方、IP-in-IP トンネルオフロードに対応しない NIC ではオーバーレイ構成が 11 Gbps から 12.5 Gbps へ落ちる。 オフロードが効かない場合、`ip_send_check()` などのカーネル内トンネル処理だけで約 170 CPP が加わる。 ポリシー有効の Calico をオーバーレイで動かすと Netfilter は 749 CPP に達し、同時接続数 400 では RPS が単一接続時を下回るまで劣化する。 (Source: [[@2021__TNSM__Assessing Container Network Interface Plugins - Functionality, Performance, and Scalability]]) CNI の性能差をソフトウェア実装の差だけで説明することはできない。 NIC のトンネルオフロード対応という、見落とされやすいハードウェア要因が実効性能を左右する。 (Source: [[Container Network Interface (CNI)]]) ### 未解決の問い - 現行の Linux カーネル、最新世代の NIC、CXL や DPU を含む構成でも、受信側データコピーと DCA のキャッシュミスは依然として支配的か。測定はいずれも特定のカーネル版と NIC 世代に依存している。 - 長フローのデータコピーと短 RPC の `rx_sched` を、一つのワークロードモデルで予測できるか。支配要因が帯域とフローサイズで切り替わることは示されたが、切り替え点を事前に与える方法は未提示である。 - ホスト内部の競合(IIO バッファ飽和や MC のバックプレッシャー)が起きている状況で、受信側データコピーの CPU オーバーヘッドはどう変化するか。処理オーバーヘッド削減と内部輻輳制御を同時に適用したときの相互作用は測定されていない。 - `MSG_ZEROCOPY`、TCP 受信 `mmap`、AF_XDP、io_uring を同一の長短フロー混在ワークロードで比較したとき、アプリケーション変更コストを含む最適点はどこにあるか。 - 要求数を公平性の単位とする方針は、異種要求、ストリーム混在、複数アプリケーションを横断する一般的な定義へ拡張できるか。実証された範囲は ping-pong 型の RPC に限られる。 - 内部競合の分析は単一ソケット、単一 IIO、2 世代の Intel プロセッサに限られている。マルチソケット、AMD、CXL や NVLink を含む構成で同じドメイン分解が成立するかは未検証である。 - コンテナ環境の測定は 2021 年時点のカーネルとプラグイン実装に基づく。その後の eBPF の進化や、eBPF ネイティブな同一ホスト処理とネイティブルーティングを組み合わせた構成が、当時の予測どおりの性能を示すかは確認されていない。 --- ## 第7章 RDMA と NIC のマイクロアーキテクチャ RDMA(Remote Direct Memory Access)は、リモートホストのメモリへ CPU を介さず NIC が直接読み書きする通信機構である(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 DMA がローカルホスト内で CPU を介さずバッファ間コピーを行う機構であるのに対し、RDMA はそれをネットワーク越しへ拡張し、NIC 上の RDMA エンジン同士が互いのメモリを直接読み書きする(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 この拡張が持つ価値は、カーネルバイパス、ゼロコピー、プロトコルオフロード、ワンサイドオペレーションの 4 点に整理される(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 前章までホスト内のインターコネクトを物理的な経路として見てきたが、RDMA はその経路の上に「誰がデータ移動を起動するか」という制御の問題を持ち込む。 CPU がプロトコル処理から降りるということは、性能上の利得と引き換えに、輻輳への応答、再送、資源配分といった判断がすべて NIC の内部へ移ることを意味する。 RNIC(RDMA NIC)の内部はベンダーにとってブラックボックスであり、利用者は verbs という標準インターフェースの背後を直接観測できない。 この不透明性が、性能異常の発見、マルチテナントでの性能分離、トランスポートの拡張という 3 つの異なる課題を同時に生む。 ### 7.1 verb と QP というメモリモデル RDMA のプログラミング抽象は verb と呼ばれ、その中核にあるデータ構造が **キューペア(QP: Queue Pair)** である。 QP は送信キュー(SQ)、受信キュー(RQ)、完了キュー(CQ)の 3 キューから構成される(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 QP はソケットのリングバッファモデルと異なりデータ自体を格納せず、HCA がアクセスするためのメタデータである **WQE(Work Queue Element)** のみを保持する(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 データ本体はアプリケーションが登録した **メモリ領域(MR: Memory Region)** に置かれたままであり、NIC が WQE の指すアドレスを解決して直接 DMA する。 このデータとメタデータの分離こそが、後述する NIC 内部キャッシュの枯渇問題の構造的な出発点になる。 verb は用途によって 2 種類に分かれる。 **control verb** はオブジェクトの割り当てと破棄を担い、`ibv_reg_mr` や `ibv_create_qp` がこれにあたる(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 **data verb** はデータ転送そのものを担い、`ibv_post_send` や `ibv_poll_cq` がこれにあたる(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 両者は経路が異なり、control verb はユーザ空間ライブラリとカーネルドライバの双方を経由してコマンドキューへ投入されるのに対し、data verb はカーネルをバイパスして直接 RNIC へ発行される(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 カーネルバイパスという RDMA の特徴は、正確には data verb のみに適用される性質である。 ![[_attachments/nsdi23-kong/fig02-rdma-workflow.png]] **図7-1**:control verb(`ibv_open_device`、`ibv_alloc_pd`、`ibv_reg_mr`、`ibv_create_cq`、`ibv_create_qp`、`ibv_modify_qp`)はユーザ空間ライブラリとカーネルドライバの双方を経由して RNIC の control verb 処理へ到達するのに対し、data verb(`ibv_post_send`、`ibv_post_recv`、`ibv_poll_cq`)はユーザ空間ライブラリから直接 RNIC の data verb 処理へ届く。カーネルバイパスが適用される範囲がこの経路差として現れる。(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]]) トランスポートサービスは、信頼性の有無と接続の有無という 2 軸で RC、UC、RD、UD の 4 種に分類される(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 このうち RD は実装が存在せず UC も使われないため、実運用で使われるのは RC(Reliable Connected)と UD(Unreliable Datagram)にほぼ限られる(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 RDMA の READ と WRITE、すなわちリモート OS に検知されないワンサイドオペレーションは RC(または RD)でのみサポートされる(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 トランスポートの改良を論じる研究がほぼ例外なく RC の再送方式を標的にするのは、代替経路が存在しないからである(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]])。 ### 7.2 InfiniBand と RoCEv2 のロスレス前提 RDMA の物理層とリンク層の実装は InfiniBand、RoCE、iWARP の 3 種類である(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 InfiniBand は RDMA のために設計されたプロトコルであり最も性能が高いが、専用の HCA と専用スイッチを必要とする(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 RoCE は標準 Ethernet 上で RDMA を実現する代わりにロスレス Ethernet を要求し、iWARP は TCP/IP ベースでロスレス Ethernet を要さないがその分やや低性能になる(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 ![[_attachments/markunet-rdma-ib-roce/page-015.png]] **図7-2**:IBTA が定義する層(青)と IEEE および IETF が定義する層(緑)を色分けし、InfiniBand、RoCEv1、RoCEv2、iWARP が共通の RDMA API(verbs)の下でどこまで層を共有し、どこから分岐するかを対応づける。RoCEv2 が InfiniBand のトランスポート層を UDP/IP の上に載せる構成であることが、この階層の並びから読み取れる。(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]]) RoCEv2 は InfiniBand Transport Protocol を UDP/IP の上に載せる形で構成される(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 ロスレス Ethernet は ETS(802.1Qaz)、PFC(802.1Qbb)、CN(802.1Qau)という 3 技術からなる Data Center Bridging によって実現される(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 ロスレスを前提とする理由は再送方式にある。 RDMA の再送はハードウェア実装であり、RoCEv2 は基本的に Go-Back-N を採用するため、ドロップが発生すると性能が極度に低下する(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 つまり「ロスレスが必要だから PFC を使う」のではなく、「Go-Back-N しか実装していないからロスレスが必要になる」という因果である。 この因果の向きは 2018 年時点で既に反証されていた。 IRN は、SACK ベースの効率的なロス回復と BDP-FC という 2 つの小変更を RoCE NIC に加えるだけで、PFC なしの構成が PFC ありの RoCE を 6〜83% 上回れることをシミュレーションで示し、追加のハードウェアオーバーヘッドは NIC リソースの 3〜10% に留まるとした(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]])。 PFC 自体も副作用を持つ。 PFC は優先キュー単位で PAUSE フレームを送出してバッファ溢れを防ぐが、トラフィッククラス単位の停止であるため Head-of-Line Blocking を生じ、輻輳を上流スイッチへ伝播させる輻輳ツリーを形成しうる(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 実務ではこの副作用を避けるため、全スイッチと全 NIC で PFC と ECN を有効化するロスレス構成のほかに、NIC とスイッチ間のみ単方向 PFC を使う Semi-lossless、PFC を排して End-to-End ECN のみとする Lossy-1、いずれも使わない Lossy-2 という段階的な緩和構成が置かれる(Source: [[@2023__SpeakerDeck__RDMAネットワークアーキテクチャ基礎 - IB／RoCE 編 -]])。 ロスレスは二値の選択ではなく、どこまで PFC の伝播範囲を狭めるかというスペクトラムとして設計される。 ### 7.3 RNIC のマイクロアーキテクチャ資源 性能分離を論じるには、RNIC の内部で何が共有されているかを見る必要がある。 Kong らは RDMA 操作が RNIC 内部の資源をどう消費するかをモデル化し、資源を NIC 帯域、PCIe 帯域、処理ユニット(PU)、NIC キャッシュ(ICM/MTT/MPT/WQE キャッシュ)の 4 種類に整理した(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 このうち NIC 帯域は帯域制御機構が扱える **アーキテクチャ資源** だが、残りの 3 つは標準インターフェースからは見えない **マイクロアーキテクチャ資源** である(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 ![[_attachments/nsdi23-kong/fig03-rnic-microarchitecture.png]] **図7-3**:ドアベルが鳴らされると RNIC はホスト DRAM から verb リクエストを取得する。(1) 処理に必要なメタデータ(QP コンテキストなど)は複数種類のキャッシュに置かれ、(2) キャッシュミス時は DRAM から取得する(赤線)。その後 (3) control verb なら応答をホスト DRAM へ返し、data verb ならペイロード読み出しの DMA を発行する。(4) データ読み出し後、(5) ネットワークパケットへ加工し (6) ファブリックへ送出する。verbs の背後で共有されている資源がどこに位置するかを、この経路が示す。(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]]) | 資源 | 主に消費する操作 | 枯渇の症状 | |---|---|---| | NIC 帯域 | data verb のデータ転送 | 帯域の按分 | | NIC キャッシュ | control verb(特に MR の登録解除) | キャッシュミス率上昇と帯域低下 | | 処理ユニット | 複雑な data verb、エラー処理 | リクエストレートの崩壊 | | PCIe 帯域 | 特定サイズ範囲のリクエスト | 追加 DMA による帯域制限 | (Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]]) #### 7.3.1 キャッシュの枯渇 RNIC はリクエスト処理に必要なメタデータ(QP コンテキストやアドレス変換テーブルなど)を内部キャッシュに保持し、ミスするとホスト DRAM から取得する(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 このキャッシュを最も激しく汚すのは data verb ではなく control verb である。 攻撃側が 1 スレッドで毎秒約 5,000 回の MR 登録解除を繰り返すだけで、被害側の帯域は 96.6 Gbps から 48.0 Gbps へ落ち、MTT キャッシュミス率は 17.2% から 49.1% へ上昇した(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 同じ MR 操作でも登録のみでは 95.9 Gbps とほぼ影響がなく、登録解除だけが破壊的である(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 帯域を消費しない制御操作が帯域を半減させるという事実は、帯域という指標だけで分離を設計する発想の限界を示す。 #### 7.3.2 処理ユニットの競合とエラー処理 処理ユニットの競合は verb の複雑さに依存する。 NVIDIA ConnectX-5 では、READ 単独で 60 Mrps を達成していた被害側が、攻撃側が CAS(compare-and-swap)を実行すると 3 Mrps まで低下した(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 これは NVIDIA 固有の現象ではなく、Chelsio の iWARP NIC でも、WRITE 単独で 4.76 Mrps の被害側が SEND 攻撃で 55.0%、READ 攻撃で 73.1% 低下した(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 より極端なのはエラー処理経路である。 受信側が受信リクエストを投入せず RNR(Receive Not Ready)エラーを誘発すると、被害側の帯域は 93.53 Gbps から 0.018 Gbps へ、事実上ゼロまで崩壊した(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 攻撃側自身の帯域もゼロになる点が特徴で、これは帯域を奪う攻撃ではなく処理ユニットを止める攻撃である。 機構としては、RNR の処理が RNIC の処理ユニット全体を占有し、当該フローと無関係なテナントのリクエスト処理まで巻き込んで停止させるためである(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 #### 7.3.3 PCIe 帯域 PCIe 帯域がボトルネックになるのは常時ではなく、リクエストサイズが特定の範囲にあるときに限られる。 ペイロードが 28 バイト未満では WQE と同一の MMIO に埋め込まれるため PCIe 消費が増えないが、29〜256 バイト付近では PCIe の送信帯域が NIC 帯域を上回り、追加の DMA が必要になる領域が現れる(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 #### 7.3.4 既存の分離機構がなぜ破れるのか Kong らは以上の資源消費モデルからテストスイート Husky を構築し、SR-IOV、ハードウェアトラフィッククラス分離、その組み合わせ、Justitia を評価した(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 結果は、RC のエラー処理を SR-IOV が分離できた 1 項目を除き、全ての組み合わせで分離が破られるというものだった(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 攻撃に必要な帯域はわずかで、50 Gbps を保証された被害側が、攻撃側のわずか 1 Gbps のトラフィックで約 2 Gbps まで落ちる(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 影響は合成ワークロードに留まらず、allreduce の実行レートはキャッシュ攻撃で約半分から 71.3% 低下し、処理ユニット攻撃ではほぼ完全に停止した(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 ![[_attachments/nsdi23-kong/table03-isolation-solution-comparison.png]] **表7-4**:✓ は性能分離が機能したこと、✗ は Husky が攻撃側と被害側の組み合わせで分離を破れたことを表す。RC のエラー処理を SR-IOV および SR-IOV と HW TC の組み合わせが分離できた 1 項目を除き、UD と UC のエラー処理、data verb、NIC キャッシュ、PCIe 帯域はすべての機構で分離に失敗している。Justitia は同一デバイスを使うアプリケーション間しか分離できないため SR-IOV とは組み合わせていない。(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]]) 破れる理由は単純である。 SR-IOV は仮想関数ごとに帯域と RC の RNR エラー処理を分離できるが、UD と UC のエラー処理、NIC キャッシュ、PCIe 帯域は分離対象に含まれない(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 ハードウェア仮想化機構が想定する資源の粒度が、RNIC が実際に内部で共有している資源の粒度と一致していない(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 著者らはこれらの発見が NVIDIA によって再現、確認され、control verb によるキャッシュミスについてはファームウェア修正が計画されたと報告する(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 ### 7.4 QP 数のスケーリングをめぐる報告の不一致 QP 数を増やすと RNIC のオンチップ SRAM に収まらなくなり、コンテキストのスワッピングが性能を落とす。 SRNIC はこの劣化を、RC QP を 256 から 512 へ増やすと約 23%、16k へ拡大すると約 46% の帯域低下として報告している(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 ところが同じ現象を測った UCCL-Tran は、60 QP から 60,000 QP へ拡大しても RC で約 17%、UC ではさらに小さい低下しか観測しないと報告する(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 UCCL-Tran はこの差を 2 つの条件に帰す。 第一に、ML ワークロードは MTU サイズの大きなパケット転送を行うため、QP スワッピングのオーバーヘッドが転送量で償却される(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 第二に、GPUDirect によって GPU と NIC の間のトラフィックが PCIe ルートコンプレックスを経由せず PCIe スイッチのみを通るため、CPU と NIC の間のトラフィックとの PCIe 競合が生じない(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 「QP を増やすと遅くなる」は無条件の法則ではなく、メッセージサイズとデータ経路に依存する条件付きの現象である。 ![[_attachments/osdi26-zhou-yang/fig06-cx-ib-qp-scaling.png]] **図7-5**:16 台の 400G NIC からなるテストベッドで 60、3.75K、15K、60K QP の 4 条件を比較した結果。(a) RC QP と (b) UC QP のいずれも、QP 数を 1000 倍に増やしても 50 GB/s のライン速度付近へ到達し、劣化はわずかに留まる。QP スケーリングの劣化を報告する先行研究と食い違う観測である。(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]]) ### 7.5 ハードウェアトランスポートの硬直性 RNIC のトランスポートロジックがハードウェアに焼き込まれていることは、輻輳制御、再送方式、経路選択のいずれも利用者が変更できないことを意味する。 単一パスの RDMA トラフィックはフロー衝突を起こしやすく、集合通信の性能を著しく低下させる(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 UCCL-Tran は、この硬直性を NIC を改造せずに迂回する。 データパスとコントロールパスを分離し、輻輳制御、パケット信頼性、マルチパス負荷分散というコントロールパスの判断だけをホスト CPU 上のソフトウェアへ移す(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 実装上の鍵は RDMA の UC で `write_with_immediate` を使う点にある。 UC は NIC によるセグメンテーションと再構成のオフロードを保持したまま、ハードウェアに焼き込まれた輻輳制御とロス回復と順序制御をバイパスできる(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 32 ビットの `imm_data` にコントロールヘッダを載せることで、NIC はコントロールヘッダを受信 CPU へ、データペイロードを受信 GPU へそれぞれ直接届ける(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 ![[_attachments/osdi26-zhou-yang/fig03-uc-rc-imm.png]] **図7-6**:送信側 CPU は `imm_data` と `src_addr, dst_addr, len` を NIC へ渡し、NIC はコントロールヘッダ(`imm_data`)を受信 CPU へ、データペイロードを受信 GPU へ分けて届ける。UC が成功到達した任意のチャンクに対し `imm_data` 付きの完了エントリを生成することを保証するため、NIC を改造せずにコントロールパスとデータパスを分離できる。(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]]) UC を持たないベンダーでは輻輳制御を無効化した RC を、RC を持たない AWS EFA では scatter-gather を使った UD を代替経路として用いる(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 マルチパスでは最大 256 QP を使い、パスごとの RTT に基づく power-of-two サンプリングで経路を選ぶ(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 受信側主導の輻輳制御 EQDS は、InfiniBand の送信側主導の輻輳制御に対し、15 対 1 のインキャストで P99 と P99.9 をそれぞれ 1.73 倍と 1.72 倍改善した(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 選択的再送は、1/16384 のドロップ率で約 1%、1/256 という高いドロップ率でも 6〜30% の性能低下に留まり、Go-Back-N ベースのハードウェアトランスポートが示す 26〜76% の低下を大きく下回る(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 集合通信全体では既存 RDMA NIC 比で最大 4.5 倍の性能向上が報告されている(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 ここで注意すべきは、この路線が万能ではないことである。 コントロールパスのソフトウェア化は GPU あたり 2 CPU コアを追加で消費する(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 輻輳シグナルも RTT とパケットロスに限定される。 既存 RDMA NIC が ECN マークやパケットトリミングの情報をソフトウェアへ渡さないためである(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 同じ RC のマルチパス化という目標を、[[MRC]] はプログラマブル NIC 側で追求しており、どちらが将来の帯域増大に対してよりスケールするかは決着していない(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 ### 7.6 GPU 主導の通信開始 トランスポートの制御主体をホスト CPU へ寄せる UCCL-Tran とは逆に、GPU 側へ寄せる方向も進んでいる。 従来の GPU 通信はホスト起動モデルに従い、CPU がすべての通信操作を統括する(Source: [[@2025__arXiv__GPU-Initiated Networking for NCCL]])。 この方式は集合通信には堅牢だが、Mixture-of-Experts の動的なトークンルーティングのように計算と通信の緊密な統合を要する処理では、CPU の協調オーバーヘッドが問題になる(Source: [[@2025__arXiv__GPU-Initiated Networking for NCCL]])。 NCCL 2.28 の GIN(GPU-Initiated Networking)は、GPU カーネルから直接 one-sided の put と put with signal を発行できるようにする(Source: [[@2025__arXiv__GPU-Initiated Networking for NCCL]])。 バックエンドは 2 つある。 GDAKI バックエンドは GPU スレッドが RDMA の WQE をデバイスメモリ上に構築し、NIC のドアベルレジスタへ直接書き込んで DMA を起動する(Source: [[@2025__arXiv__GPU-Initiated Networking for NCCL]])。 Proxy バックエンドは GPU が 64 バイトの操作記述子をロックフリーキューへ投入し、専用の CPU スレッドがこれを取り出して発行する(Source: [[@2025__arXiv__GPU-Initiated Networking for NCCL]])。 小メッセージの往復レイテンシは GDAKI が 16.7 µs、Proxy が 18.0 µs であり、NVSHMEM IBRC の 16.0 µs に並び IBGDA の 24.3 µs を上回る(Source: [[@2025__arXiv__GPU-Initiated Networking for NCCL]])。 二重バックエンドが必要な理由はハードウェア要件にある。 GDAKI は ConnectX-6 Dx 以降の NIC と CUDA 12.2 以降を要求し、それ以外の環境では Proxy へフォールバックせざるを得ない(Source: [[@2025__arXiv__GPU-Initiated Networking for NCCL]])。 GPU 主導の通信は、同じ InfiniBand や RoCE という物理層の上に、NIC 側実装がデバイスアクセス可能な制御構造を持つかどうかという新しい互換性の軸を追加する(Source: [[@2025__arXiv__GPU-Initiated Networking for NCCL]])。 なお UCCL-Tran と GIN は排他的ではなく、IBGDA の CPU 支援モードを使えば、CPU プロキシの内部に拡張可能なトランスポート層を実装できると UCCL-Tran の著者らは論じている(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 ### 7.7 異常をどう発見するか RNIC がブラックボックスであるという前提は、性能異常の発見手法にも制約を課す。 Collie はこの制約を、ハードウェア内部をモデル化する代わりに verbs API が公開する操作の組み合わせから探索空間を構築するという方針で回避した(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 探索空間はホストトポロジ、メモリ割り当て設定、トランスポート設定、メッセージパターンという 4 次元からなる(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 探索の指針には、商用 RNIC が標準で提供する性能カウンタと診断カウンタを使い、焼きなまし法でこれらを極値領域へ駆動する(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 追加のハードウェア計装を必要としない点が、この設計を運用可能なものにしている(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 ![[_attachments/nsdi22-paper-kong/fig02-system-overview.png]] **図7-7**:Workload Generator が焼きなまし法でワークロードパターンを決め、Workload Engine が RDMA サブシステムへトラフィックを流す。Anomaly Monitor がスループットと PFC の PAUSE フレームから異常を検知して最小特徴集合(MFS)を生成し、その結果が Workload Generator へ戻る。ハードウェア内部をモデル化せず、外から観測できるカウンタだけで探索が閉じる構成になっている。(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]]) 異常の定義は測定可能な 2 種類、すなわちネットワークが輻輳していないのに PFC の PAUSE フレームが発生すること、およびスループットが RNIC 仕様の上限より 20% 以上低いことである(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 レイテンシは無負荷時の仕様値以外に正しさの基準がないため異常定義に含めない(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 8 種類の商用 RDMA サブシステムでの評価では、既知の 3 件を再現したうえで新たに 15 件、合計 18 件の異常が見つかり、全件がベンダーに承認され 7 件は修正済みとなった(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 既存手法である Perftest の手動チューニングで再現できたのは 4 件のみであり、ランダム探索は 7 件、ベイズ最適化は 8 件で頭打ちになった(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 発見された異常の原因は RNIC 内部に留まらず、PCIe コントローラ、クロスソケット通信、GPUDirect RDMA のトラフィック、ホスト内ループバックトラフィックにまたがっていた(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 Collie 自身は根本原因を特定する設計ではない(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 代わりに、異常の再現に本当に必要な条件だけを残す最小特徴集合(MFS)を計算し、開発者へ回避策を提示する(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 実際、分散機械学習アプリケーションが新しいサブシステムで遭遇した異常について、複数ベンダーと数週間協働しても原因が特定できなかった事例で、MFS との突き合わせによりベンダー修正を待たずに回避が実現した(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 Collie と Husky は同じ著者陣による一連の研究であり、前者はデプロイ前の異常発見、後者はマルチテナントの性能分離という異なる文脈で、同じ「見えない内部資源」という問題意識を確認している(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]], [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 ### 未解決の問い - マイクロアーキテクチャ資源を分離するには RNIC にどのような設計変更が必要か。Intel RDT のようなキャッシュ QoS 機構の RNIC 版が提案されているが、具体的なハードウェア実装は示されていない(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 - 著者らが提案するソフトウェアベースの間接化レイヤー(保護ドメインで動作する中央コントローラ)は、カーネルバイパスという RDMA の性能優位をどの程度犠牲にするか。レイテンシとスループットへの定量的影響は未検証である(Source: [[@2023__NSDI__Understanding RDMA Microarchitecture Resources for Performance Isolation]])。 - Collie の探索空間はホスト側の 4 次元に限られ、制御パス挙動やリクエストの到着間隔は含まれない。ネットワーク内輻輳を含む探索空間へ拡張したとき、同じ枠組みで PFC 連鎖などの異常も発見できるか(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 - プログラマブル NIC 側([[MRC]])とホスト CPU 側(UCCL-Tran)のマルチパス実装を、同一テストベッドと同一ワークロードで直接比較した定量評価は、この wiki が持つソースからは確認できていない(Source: [[@2026__OSDI__UCCL-Tran - An Extensible Software Transport Layer for GPU Networking]])。 - IRN が 2018 年に PFC 不要を実証してから、RoCE の主流実装が Go-Back-N と PFC 依存のまま推移した 5 年以上のギャップは何に起因するか(Source: [[@2018__SIGCOMM__Revisiting Network Support for RDMA]])。 --- ## 第8章 ホスト内輻輳制御 輻輳制御という語は長らくネットワークファブリックの話だった。 システムとネットワークの両コミュニティにおける従来の通念は、輻輳は主にネットワークファブリック内で発生するというものである(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 この通念は、end-to-end という言葉の「端」を NIC と解釈することで成立していた。 NIC から先、すなわち NIC と CPU およびメモリを結ぶ経路は、輻輳が起きない十分な余裕を持つ領域として不可視のまま扱われてきた(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 その前提が成り立たなくなった理由は、前章までに見た帯域トレンドの非対称である。 RNIC の線速が 25 Gbps から 200 Gbps へ急伸する一方、PCIe 帯域は 63 Gbps から 256 Gbps 程度の伸びに留まる(Source: [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]])。 CPU の速度、キャッシュ容量、メモリアクセスレイテンシ、コアあたりメモリ帯域、NIC バッファサイズといったホスト内資源の技術トレンドは、いずれもアクセスリンク帯域の伸びに追随していない(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 このギャップが、**ホスト輻輳(host congestion)** という新しい輻輳形態を顕在化させた(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 本章は、この輻輳がどこで起き、なぜ既存の輻輳制御では扱えず、どのような制御機構が提案されているかを追う。 診断の側面、すなわちホスト内のどのリンクが劣化しているかを特定する話は前章で扱った [[ホスト内ネットワークボトルネック]] の主題であり、本章はその観察を能動的な資源配分へ変換する側を扱う(Source: [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]])。 ### 8.1 輻輳点はどこにあるか ホストネットワークは、NIC と CPU およびメモリの間でデータ交換を可能にするプロセッサ、メモリ、周辺機器のインターコネクトの総称である(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 Intel の CPU ソケットでは、コアとアンコアがメッシュインターコネクトで結ばれ、アンコアはメモリコントローラ、LLC と CHA、IIO(Integrated IO Controller)、ソケット間インターコネクトである UPI から構成される(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 RNIC、GPU、NVMe SSD といったデバイスは IIO 経由で PCIe ドメインに接続される(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 受信データの経路は 2 区間に分けられる。 NIC から IIO までの区間と、IIO からメモリコントローラまでの区間である(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 PCIe のスループットは $P/\max\{\ell_p, \ell_m\}$ で与えられる。 ここで $P$ は PCIe が維持できる最大 in-flight バイト数、$\ell_p$ は NIC と IIO の間の固定レイテンシ、$\ell_m$ は IIO とメモリコントローラの間のレイテンシである(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 $\ell_m$ はメモリコントローラの書き込みキューサイズ、負荷、DDIO の有無に依存して変動する(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 通常時は $\ell_m$ が $\ell_p$ より十分小さく PCIe 利用率は $\ell_p$ に律速されるが、ホスト輻輳時は $\ell_m$ が増大して律速要因が入れ替わる(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig02-intra-host-congestion-overview.png]] **図8-1**:RNIC トラフィック(青矢印)は RNIC から IIO を経てメモリコントローラへ、ロスレスかつクレジットベースのフロー制御で流れる。CPU からメモリへのトラフィック(緑矢印)との競合でメモリコントローラへのクレジット補充が遅れると、IIO バッファでのキューイングと RNIC への PCIe 背圧が生じ、最終的に RNIC が PFC の一時停止フレームまたは CNP を生成する。(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]]) 輻輳点の候補は複数ある。 PCIe のリンクとスイッチ、IIO、メモリ帯域、UPI などのソケット間バス、そして LLC と DDIO の相互作用である。 このうち LLC と DDIO は間接的に効く。 RDMA の実測では、輻輳度が上がるにつれて DDIO のミス率が上昇する(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 機構としては、キャッシュラインの退避に伴うメモリ書き戻しが十分なメモリ帯域を必要とするため、メモリ帯域が競合している状況では書き戻しが減速し、DDIO の書き込み割り当てが追いつかなくなるからである(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 DDIO は LLC 競合を増大させ、CPU からメモリへのトラフィックがより多くのメモリ帯域を消費するようにも働く(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 UPI も独立した悪化要因である。 NUMA を跨ぐメモリアクセストラフィックは、ローカル NUMA の場合と比べてスループットを最大 24% 低下させる(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 ローカル NUMA と NUMA 越えを同数のコアで混在させた場合の低下は最大 40% に達する(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 原因は、双方向の NUMA 越えキャッシュコヒーレンシが UPI リンク帯域を圧迫し、より多くのメモリ帯域を消費することにある(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 輻輳の帰結は明確に測られている。 3 倍のホスト内輻輳負荷を与えると、PFC 有効環境ではスループットが 62% 低下し平均レイテンシが 2.4 倍に、PFC を使わない環境ではそれぞれ 68% 低下と 2.6 倍増加になる(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 根本原因は PCIe のバックプレッシャー増大と DDIO ミス率の上昇である(Source: [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]])。 ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig03-network-perf-vs-congestion-level.png]] **図8-2**:輻輳度 0 倍から 3 倍までの (a) 受信スループット、(b) 平均レイテンシ、(c) 99 パーセンタイルレイテンシ、(d) PFC 一時停止と CNP 数。3 倍の輻輳下では PFC 有効環境で 62%、PFC を使わない環境で 68% のスループット低下が生じ、平均レイテンシはそれぞれ 2.4 倍と 2.6 倍になる。RNIC トラフィックの低下幅は CPU からメモリへのトラフィックのメモリ帯域消費の増加幅より大きく、DDIO による LLC 競合の増大がこの差を生む。(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]]) ### 8.2 既存の輻輳制御が届かない理由 ホスト輻輳が既存の枠組みで扱えない理由は、性能の問題ではなく前提の問題である。 第一に、ドロップが輻輳点で起きない。 ホストネットワークはロスレスでクレジットベースのフロー制御を用いるため、メモリコントローラが輻輳してもそこではパケットが失われない(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 代わりに、輻輳点から離れた NIC のバッファでキューイングが起き、最終的にそこでドロップする(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 「パケットドロップは輻輳点で発生する」という古典的輻輳制御の前提が崩れるため、ドロップを輻輳のシグナルとして受け取った制御機構は、輻輳の場所を誤って推定する(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 第二に、競合相手が輻輳制御プロトコルに従わない。 ホストローカルトラフィック、たとえば CPU からメモリへの直接アクセスは、いかなる輻輳制御にも参加しない(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 しかも輻輳点に近いため、RTT より短い時間スケールで急変しうる(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 RTT 粒度で動く DCQCN や DCTCP は、この変動に追随できない。 第三に、時定数が合わない。 DCQCN の既定のレート増加タイマーは 300 µs であり、ホスト間ネットワークには適切だがサブマイクロ秒スケールのホスト内ネットワークには不適切である(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 この不整合の代償は実測されている。 ホスト内輻輳とホスト間輻輳を区別しない制御では、RNIC のトラフィックが帯域を取り戻すのに DCQCN の 300 µs 間隔を待たねばならず、CPU からメモリへのトラフィックに対して著しく不利になり、RNIC のスループットは 27 Gbps まで落ちる(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 第四に、PFC はホスト輻輳の解ではなく症状の伝播路である。 ホスト内で輻輳が生じると RNIC は PFC の一時停止フレームまたは CNP を生成し、輻輳をネットワーク側へ押し戻す(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 第7章で見たとおり PFC は上流へ輻輳を伝播させるため、ホスト内部の一点の資源競合がファブリック全体の問題として現れうる。 ### 8.3 ホスト輻輳制御の設計要素 以上を踏まえると、ホスト輻輳制御の設計は 4 つの決定に分解できる。 - **信号の取得源**: どの計測点から輻輳を読むか。データパス上の点は輻輳自体の影響を受けるため使えない。 - **制御対象**: ネットワークトラフィックを絞るのか、ホストローカルトラフィックを絞るのか、両方か。 - **粒度**: サブ RTT で動く応答と RTT で動く応答をどう分けるか。 - **公平性**: 何と何の間の、どのような公平性を目標とするか。 信号の取得源として提案された答えが **IIO バッファ占有量** である(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 これが選ばれる理由は 3 つある。 第一に、メモリコントローラが輻輳した瞬間にのみ増加し輻輳が解消すれば増加が止まるため、時刻と場所と理由の正確性が高い(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 第二に、IIO の挿入レートと組み合わせれば、瞬時 PCIe スループットやホスト遅延といった派生指標を導出できる(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 第三に、既存ハードウェアの 2 つのモデル固有レジスタで測定でき、追加のハードウェア支援を必要としない(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 決め手は計測点の位置である。 IIO の計測点は NIC とメモリを結ぶデータパスの外側にあるため、ホスト輻輳の有無にかかわらずサブマイクロ秒粒度で読める(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 RDMA 環境での実測でも、MSR の読み出しレイテンシは輻輳の有無によらず約 400 ns で安定している(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 粒度については、関心の分離という設計判断が置かれる。 ホストローカルの輻輳応答は RTT を待たずサブ RTT 粒度で資源配分を調整し、ネットワーク資源配分は RTT 粒度で行う(Source: [[ホスト輻輳制御]])。 この分離により、ホスト輻輳シグナルを既存のネットワーク輻輳制御へエコーするだけで統合が済み、プロトコル本体を書き換えずに済む(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 ### 8.4 hostCC の設計と実測 hostCC は、ホスト輻輳シグナルの生成、サブ RTT 粒度のホストローカル輻輳応答、RTT 粒度のネットワーク資源配分という 3 つのアイデアで構成される(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 ![[_attachments/Host-Congestion-Control/fig05-hostcc-architecture.png]] **図8-3**:送信ホスト(左)と受信ホスト(右)のそれぞれで、ホストローカル輻輳応答がホスト輻輳シグナルを入力に応答レベルを出力する。既存のネットワーク輻輳制御とフロー制御は、ホスト輻輳シグナルとネットワーク輻輳シグナルの両方を受け取り、送信側ではネットワーク資源配分を、受信側ではフロー制御とエコーを行う。プロトコル本体を書き換えずシグナルのエコーだけで統合できる形になっている。(Source: [[@2023__SIGCOMM__Host Congestion Control]]) 資源配分の判断は 4 つのレジームに分かれる。 ホスト輻輳がなく目標帯域を達成している場合はホストローカルトラフィックへの配分を増やす(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 ホスト輻輳があり目標帯域を達成している場合は、ホストローカル側では何もせず、シグナルをネットワーク輻輳制御へエコーしてネットワークトラフィックのレートを下げる(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 ホスト輻輳があり目標帯域に未達の場合はホストローカルトラフィックへの配分をまず削る(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 ホスト輻輳がなく目標帯域に未達の場合はホストローカルへの配分を増やさず AIMD 機構に委ねる(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 バックプレッシャーの実行手段には Intel Memory Bandwidth Allocation(MBA)を用いる(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 MBA は CPU コアの L2 キャッシュミス時に追加のレイテンシを導入してメモリトラフィックのレートを抑制する仕組みで、hostCC は 5 段階の応答レベルを用いる(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 実装は約 800 行の Linux カーネルモジュールであり、アプリケーション、ホストハードウェア、ネットワークハードウェアのいずれの変更も要さない(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 効果は次のとおりである。 3 倍のホスト輻輳下でも目標帯域 80 Gbps をほぼ達成しつつ、パケットドロップ率を桁違いに削減した(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 128 B の RPC におけるテールレイテンシの劣化は 13 µs に留まり、hostCC なしでは P99.9 で観測された再送タイムアウトが消えた(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 ネットワーク輻輳のみでホスト輻輳がない条件では、hostCC はネットワーク輻輳制御単体とほぼ同等の性能を示し、常時のオーバーヘッドが小さいことも確認されている(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 3 つのアイデアはいずれも省略できない。 ホストローカル応答を外すとドロップ率は最小化できてもスループットが約 28 Gbps へ劣化し、エコーのみでは反応が遅れて PCIe 帯域が目標に届かない(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 制約も明示されている。 MBA の MSR への書き込みには約 22 µs を要し、ネットワーク RTT の半分程度に相当するため細粒度の応答を妨げる(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 応答レベルの効果は非線形かつ粗粒度で、レベル 3 から 4 への切り替えでネットワークアプリケーションが得る 5.2 GBps の増加に対し、ホストローカル側は 13.8 GBps を失う(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 ### 8.5 RHCC: RDMA へ移すと何が変わるか hostCC は TCP を前提としており、そのまま RDMA へ持ち込めない。 理由は受信側でのシグナル通知の実装にある。 hostCC は受信側で ECN ビットをマーキングして送信側へ伝えるが、RDMA は輻輳制御ロジックをすべて RNIC ハードウェア内で実装しており、商用 RNIC はカーネルモジュールがパケットを能動的に改変するインターフェースを提供しない(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 これは第7章で見たカーネルバイパスという設計上の利点の裏面であり、TCP では自明な制御手段が RDMA では使えなくなる一例である(Source: [[RDMA]])。 RHCC はこの制約を、商用 RNIC の **Programmable Congestion Control(PCC)** が持つプローブ機構で迂回する(Source: [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]])。 送信側は 32 KB のデータごとに約 60 バイトのプローブパケットを 1 個送出し、受信側がハードウェアタイムスタンプを付与した ACK を返す(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 送信側はプローブ送出時刻と ACK 生成時刻の差から受信処理遅延を測る(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 この遅延は輻輳なしで約 120 ns、3 倍のホスト内輻輳下では約 900 ns まで増える(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig07-rhcc-framework-overview.png]] **図8-4**:RHCC は受信側で完結する CPU からメモリへのトラフィックの輻輳応答(①監視と②資源配分)と、送信側と受信側のプローブ往復で完結する RNIC トラフィックの輻輳応答(①プローブ送出と②レート更新)を組み合わせる。受信側は IIO バッファ占有量をサブ RTT 粒度で監視して資源を配分し、送信側はタイムスタンプ付き ACK から受信処理遅延を測ってレートを更新する。2 つのループは互いに独立に動き、最終的な送信レート計算で統合される。(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]]) データパケットを一切改変しないため上位アプリケーションに透過であり、ネットワーク帯域のオーバーヘッドは 0.2%、状態は QP あたり 16 バイトに収まる(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 レート調整には AIMD ではなく PID(比例、積分、微分)ベースの調整を用いる(Source: [[@2024__APNet__Rethinking Intra-host Congestion Control in RDMA Networks]])。 最終的な送信レートは $R_{sending} = \min(R_{rev}, R_{cc})$ とし、受信処理遅延から求めた受信側レートと、既存のホスト間輻輳制御が計算するレートの小さい方を採る(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 この形にすることで、任意のホスト間輻輳制御プロトコルと共存しつつ RNIC トラフィック間の max-min 公平性が得られる(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 なおこの収束性は RHCC 自身の新規の証明ではなく、PID 制御が SISO ARMAX モデルで特徴づけられ大域収束性を持つという先行の制御理論を援用して示されている(Source: [[ホスト輻輳制御]])。 hostCC と RHCC の設計差は 5 点に整理されている(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 | 観点 | hostCC | RHCC | |---|---|---| | 受信側シグナル通知 | ECN ビットのマーキング | PCC のプローブと ACK | | ホスト間輻輳制御との関係 | 受信側駆動のため INT 方式と協調しにくい | 独立した制御ロジックで任意方式に適応 | | パラメータ | ホスト内とホスト間を区別しない | 分離する | | 純粋な PCIe 輻輳 | IIO 占有量が閾値を超えず無輻輳と誤判定 | プローブが受信データパス全体の背圧を捉える | | NUMA 越えトラフィック | 考慮しない | レベル 4 まで直接制限するカスケード調整 | 実測では、3 倍のホスト内輻輳下で PCIe のスタール書き込み要求を 80〜97% 削減し、PFC の一時停止時間を最大 64%(NUMA 越えのシナリオでは最大 92%)削減した(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 アプリケーションレベルのスループットとレイテンシはそれぞれ最大 2 倍と 1.4 倍改善する(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig14-rhcc-pcie-backpressure-throughput.png]] **図8-5**:図8-2 と同一の実験に RHCC を適用した結果(PFC 有効時)。(d) PCIe のスタール書き込み要求は 1 倍、2 倍、3 倍の輻輳下でそれぞれ 80%、93%、97% 削減され、RNIC トラフィックが十分なホスト内資源を獲得できるようになる。その結果 (c) PFC 一時停止時間は 3 倍輻輳下で最大 64% 減り、(a)(b) ネットワークスループットと平均レイテンシがそれぞれ最大 2 倍と 1.4 倍改善する。(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]]) ホスト間輻輳とホスト内輻輳が併存する条件でも、PFC 一時停止を最大 2.9 倍削減しスループットを最大 1.85 倍改善した(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 ただし全てのシナリオで同じ効果が出るわけではない。 受信側 RNIC が他の 2 台のサーバから TCP トラフィックを受ける純粋な PCIe 輻輳では、PCIe 背圧の削減は最大 50%、PFC 一時停止の削減は最大 47% に留まる(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 理由は 2 つある。 RDMA と TCP の競合は PCIe バス上でのみ生じて IIO バッファ占有量に現れず、加害側のトラフィックが他サーバ由来のため受信側が直接配分できない(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 TCP 側は損失によって自律的にレートを下げるため、背圧が自然に緩和される分の寄与も混ざる(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 両手法の共通の制約として、Intel MBA の粗粒度な 5 段階配分への依存は RHCC でも解消されていない(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 ![[_attachments/revisiting-intra-host-congestion-control-ton2025/fig18-pcie-congestion-scenario.png]] **図8-6**:受信側 RNIC を別の 2 台のサーバへ直接接続し、iPerf で 1 本から 4 本の TCP トラフィック(37、71、95 Gbps)を流して PCIe 輻輳を模擬した実験。RHCC は能動的な RDMA トラフィック調整により PCIe 背圧を最大 50%、PFC 一時停止を最大 47%、TCP のドロップ率を 58% 削減するが、改善幅は他のホスト内輻輳シナリオほど大きくない。同じ条件で hostCC は IIO バッファ占有量が閾値を超えないため無輻輳と誤判定し、ホスト間トラフィックのレートを上げて輻輳を悪化させる。(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]]) ### 8.6 本番運用で観測された事例 ホスト輻輳は実験室の現象ではない。 Azure Storage の RDMA 展開では、同一サーバ内の複数の RDMA アプリケーションインスタンス間の通信と外部との通信が NIC 上で共存し、PCIe レーンで 2 対 1 の輻輳を作った(Source: [[@2023__NSDI__Empowering Azure Storage with RDMA]])。 この輻輳が slow receiver として現れ、PFC フレームの送出を招いた(Source: [[@2023__NSDI__Empowering Azure Storage with RDMA]])。 切り分けの決め手は、ループバックトラフィックで RDMA を無効化すると PFC フレームの送信が止まったことである(Source: [[@2023__NSDI__Empowering Azure Storage with RDMA]])。 ネットワーク側からは PFC ストームとして見える現象の原因が、ホスト内部の PCIe レーン上の競合だったことになる。 同じ論文が引き出す教訓は、ホスト内ネットワークと物理ネットワークは分離された対象ではなく、PCIe、GPU、DPU、NVLink、NIC が絡む収束したネットワークとして管理されるべきだというものである(Source: [[@2023__NSDI__Empowering Azure Storage with RDMA]])。 Collie が発見した異常のうちホスト内ループバックトラフィックと受信トラフィックの共存が PFC の PAUSE フレームを誘発する事例も、同じ構造を別の手法で捉えたものである(Source: [[@2022__NSDI__Collie - Finding Performance Anomalies in RDMA Subsystems]])。 診断と制御の関係も整理しておく。 Hostping は RNIC の線速急増と PCIe 帯域の停滞という観察を診断ツールの設計動機に使い、ホスト内の帯域劣化とレイテンシ増加という症状を検知する(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 RHCC は同じ観察から出発しながら、診断ではなく能動的な資源配分とレート制御を構築する(Source: [[ホスト内ネットワークボトルネック]])。 両者は同じ著者グループから同年に発表された補完的な貢献である(Source: [[ホスト内ネットワークボトルネック]])。 症状の検知と根本原因の機構解明はさらに別の階層にあり、[[@2024__SIGCOMM__Understanding the Host Network]] はホストネットワークをドメインごとに独立したクレジットベースフロー制御を行う複数のサブネットワークとして抽象化し、どのドメインのクレジット枯渇に起因するかを説明する(Source: [[ホスト内ネットワークボトルネック]])。 ### 未解決の問い - [[@2024__SIGCOMM__Understanding the Host Network]] が報告する「青レジーム」(メモリ帯域が飽和していなくても CPU からメモリへのアプリケーションの性能が劣化する現象)を、IIO 占有量ベースの輻輳シグナルは検知できるか(Source: [[ホスト輻輳制御]])。 - Intel MBA の限界(MSR 書き込みに約 22 µs、非線形かつ粗粒度な応答)を克服する細粒度なホスト資源配分のハードウェア支援は実現しているか。AMD の Memory Bandwidth QoS のような代替インターフェースでも同じ限界があるか(Source: [[ホスト輻輳制御]])。 - IOMMU に起因するホスト輻輳を検知する輻輳シグナルは何か。ATS のような技術はどの程度緩和に寄与するか(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 - CXL によるメモリ拡張はメモリインターコネクトのレイテンシ $\ell_m$ を緩和しうるか。CXL 接続メモリを用いた場合に IIO 占有量というシグナルの妥当性はどうなるか(Source: [[@2023__SIGCOMM__Host Congestion Control]])。 - RHCC は DCQCN との組み合わせでのみ評価されている。TIMELY や HPCC のような他プロトコルとの組み合わせでも $R_{sending} = \min(R_{rev}, R_{cc})$ という設計が成立するかの実証は残されている(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 - RNIC のオンチップ SRAM 制約による ICM キャッシュミスは、QP 数が閾値を超えたときに生じる別種のホスト内輻輳だが、IIO 占有量でも受信処理遅延でも検知できない可能性がある。キャッシュフリーな QP スケジューラとホスト輻輳制御の輻輳シグナル設計を統合する方式は、この wiki が持つソースからは確認できていない(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 - ホスト内資源配分は現状 RNIC トラフィック間の max-min 公平性と CPU からメモリへのトラフィックの保証のみを扱う。重み付き公平性や優先度スケジューリングをどう組み込むかは未解決である(Source: [[@2025__TON__RHCC - Revisiting Intra-Host Congestion Control in RDMA Networks]])。 --- ## 第9章 スケールアウト網との接合と物理層 ここまでの章はホストの内側、すなわち GPU と CPU とメモリと NIC が PCIe や NVLink や UPI でどう結ばれ、その経路の非対称性がどう性能に現れるかを扱ってきた。 本章はその外側との継ぎ目を扱う。 ホスト内インターコネクトはどこで終わり、データセンター規模のスケールアウト網はどこから始まるのか。 境界を引く部品は NIC である。 NIC はホスト側から見れば PCIe ツリー上の一デバイスに過ぎず、DMA でホストメモリや GPU メモリを読み書きする。 ネットワーク側から見れば Ethernet のリンクを終端し、SerDes でシリアル信号を送受信する終端点である。 この二つの顔が同じシリコンに同居しているため、NIC は変換点であると同時に、両側の制約が衝突する場所にもなる。 衝突は二方向から来る。 下からは物理層の制約が上がってくる。 レーンあたりの信号速度をどこまで上げられるか、その信号を銅で運ぶか光で運ぶか、誤り訂正にどれだけのレイテンシを払うかという問いが、そのまま NIC とスイッチの帯域密度の上限を決める。 上からは集合通信ライブラリの都合が降りてくる。 NCCL のような集合通信ライブラリはホスト内の NVLink 経路とホスト間の RDMA 経路を同じアルゴリズムの中で使い分けており、その使い分けの巧拙がホスト内トポロジの設計と直結する。 本章は物理層から集合通信ライブラリへ、下から上へ辿る。 ### 9.1 物理層のレーン速度と帯域密度の上限 スイッチやサーバの集約帯域を決めているのは、しばしばシリコンの処理能力ではなく配線の本数である。 ORv3 の 600mm ラックのケーブルバックプレーンでは、1 OU 分の開口部に通せる信号線が 1,024 対から 1,152 対に制限される。 200G の SerDes を前提にすると、この本数がそのまま 102.4 Tb/s から 115.2 Tb/s という集約帯域の上限を与え、スイッチトレイでは典型的にここが律速する。 物理的な開口部の面積は増やせないため、集約帯域を伸ばす道はレーンあたりのデータレートを上げることしかない。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) ![[_attachments/markunet-ai-ethernet-serdes-trends/page-024.png]] **図9-1**: ORv3 の 600mm ラックにおけるケーブルバックプレーンの開口部と、そこを通る信号線の本数。1 OU 分に通せるのは 2 本 1 組で 1,024 対から 1,152 対であり、200G SerDes を前提にすると 102.4 Tb/s から 115.2 Tb/s が集約帯域の上限になる。(Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) その「レーンあたりのデータレートを上げる」の次の一歩が **400 Gb/s/レーン(業界呼称 448G、IEEE のプロジェクト名は P802.3dv)** である。 OIF の CEI の系譜はレーンあたり速度を 56G(2014-2017)、112G(2017-2021)、224G(2021-)と倍々に伸ばしてきており、448G はその延長線上にある。 ただし過去 3 世代が一貫して変調方式に PAM4 を採ってきたのに対し、448G は初めて変調方式が未決定(TBD)のまま標準化プロジェクトが立ち上がった。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) #### 変調方式における SNR とチャネル帯域のトレードオフ 変調が決まらない理由は、448G において帯域と SNR のトレードオフが初めて厳しい制約になったからである。 448 Gbps の Nyquist 周波数は PAM4 で 112 GHz(224 GBd)、PAM6 で 89.6 GHz(179.2 GBd)、PAM8 で 74.67 GHz(149.33 GBd)になる。 高次変調ほど 1 シンボルに載るビット数が増えるためシンボルレートが下がり、チャネルに要求する帯域も下がる。 その代償として振幅レベルの間隔が詰まり、SNR は PAM4 比で PAM6 が -4.44 dB、PAM8 が -7.36 dB 悪化する。 つまり PAMn の選択は、銅チャネルの帯域が足りないという物理的事実を、符号側の余裕で肩代わりするかどうかの判断になる。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) チャネル帯域が 90 GHz 程度に留まるなら高次変調が必要になるが、そこには副作用が伴う。 IMDD 光との不整合が生じ、448G の LPO が成立しなくなり、より強い FEC が必要になる。 2026年6月時点で XPO MSA が Ansys によるシミュレーションで「400G-PAM6(85 GHz Nyquist)で性能は良好に見える」という報告を出したが、実測は 2026年9月末見込みであり、測定による裏づけはまだない。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) ![[_attachments/markunet-ai-ethernet-serdes-trends/page-017.png]] **図9-2**: チャネル帯域が 90 GHz 程度に留まる場合に高次変調が必要になる関係と、その副作用。高次変調へ寄せるとシンボルレートが下がってチャネル帯域の要求は緩むが、IMDD 光との不整合が生じ、448G の LPO が成立しなくなり、より強い FEC が要る。(Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) #### 符号利得とオーバーヘッドとレイテンシの三すくみ FEC をめぐる論点は、方式そのものよりも「必須にするか」という位置づけにある。 現行の RS(544,514)(KP4)を土台の FEC として残す点では Huawei と Alphawave と Broadcom と Cisco の見解が揃うが、その内側にもう一段の inner FEC を入れるか、入れられるようにするかは対立点として残っている。 複数の提案に共通するのは「inner FEC を常時必須とせず、必要に応じて使えるようにする」という方向である。 背景には、FEC が符号利得とオーバーヘッドとレイテンシの三すくみだという事情がある。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) このレイテンシがクラスタ規模に跳ね返る経路は具体的に定量化されている。 400 Gb/s で利用率 90%、ファイバ 150m のリンクでは媒体の往復遅延が約 1.5µs であり、Ultra Ethernet の LLR(リンク層再送)には片側 71.5 kB のバッファが要る。 ここに PHY の固有遅延が上乗せされ、1×400G は inner FEC(12-way インタリーブ)込みで +0.43µs、ファイバ 43m 相当になる。 片側バッファの合計は構成により 77 kB(+8%)から 92 kB(+28%)まで増え、ラディックス 1024 のスイッチでは合計 92 MB のバッファが必要になる。 LLR の到達距離が 150m から 120m へ 20% 縮むと、2 次元トポロジでノード数が 36% 減、3 次元で 48.8% 減になる。 つまり FEC の選択は、クラスタの物理サイズという運用上の指標を直接制約する。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) #### 標準化団体と MSA の分業 2026年8月時点の P802.3dv は、枠組みは固まったが技術選択は未決という状態にある。 2026年3月の CFI が賛成122、反対0、棄権1 で可決されて 400GPL スタディグループが設立され、6月に全12項目の Objective が採択され、7月に IEEE P802.3dv として正式発足した。 決定済みの Objective は、光が 1/2/4 対の SMF で少なくとも 500m まで、銅が twinax 銅ケーブルで少なくとも 1m まで、BER が MAC/PLS サービスインタフェースで 10⁻¹³ 以下、バックプレーンは対象外、というものである。 変調方式と inner FEC は依然として Objective に未記載であり、2026年9月の SASB 会合で PAR が承認されて初めて発足するタスクフォースの手に判断が渡る見込みである。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) この未決状態を支えているのが団体の分業である。 IEEE 802.3 が物理層規格(変調、FEC、PHY とインタフェース)を、OIF がパッケージ内から 1m 級とバックプレーン(CEI-448G-LR)を、UEC が MAC より上の信頼性機構(LLR、CBFC)を定義して物理層への要求を逆算して IEEE に伝え、OCP がシステムとラックとモジュールの実装形態を、SNIA/SFF が共通の COM パラメータセットを担い、2026年3月以降に発足した MSA 群(OCI、Open CPX、XPO)が実装の形を決める。 規格団体が「何を満たすか」を決め、MSA が「どんな部品で実現するか」を決めるという構造である。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) ### 9.2 Co-Packaged Copper と光への移行の線引き 銅か光かという問いは、448G の世代では「どこまでを銅で引くか」という距離の問いに変換される。 **Co-Packaged Copper(CPC)** は、スイッチ ASIC のパッケージ直近に銅コネクタを配置し、ホスト SerDes とパッケージ外のコネクタとの電気配線長を最小化する構成である。 Co-Packaged Optics(CPO)が光エンジンをパッケージに統合するのに対し、CPC は銅で同じアプローチを取る銅インターコネクトの延命策にあたる。 この 1 年でチャネル帯域は大きく改善しており、TEF 2024 ではほぼすべてのチャネルが 80 GHz から 85 GHz 程度しか支えられなかったのに対し、2025年の OCP Global Summit では主要ケーブルベンダすべてが 100 GHz 超をデモした。 Huawei の実測では CPC チャネルの帯域が 85 GHz から 106 GHz へ改善している。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) この改善が効くのは、PAM4 が通るかどうかの判定が前提条件(channel assumption)に強く依存するからである。 CPC を前提にすると PAM4 は通る(Altera 1.2m、Huawei 400mm、MediaTek 200mm)。 前面パネルに挿す 1m のパッシブ銅ケーブルを含めると PAM4 は厳しく、TE Connectivity の実測では BER が 1.40×10⁻¹ に達する。 この差は矛盾ではなく、400mm の CPC と 1m の前面パネル銅ケーブルという条件の違いである。 したがって「448G の世代でも前面パネルまでの銅チャネルを残すか」が分岐点になっている。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) 光側の電力効率は DSP の搭載範囲を削るほど改善し、1.6T あたりで FRO が 14 pJ/bit(25W)、TRO が 10 pJ/bit(18W)、LPO が 6.4 pJ/bit(11W)、CPO が 4 pJ/bit(7W)という順になる。 CPO が有力な選択肢になるという認識は業界で広く共有されているが、何を CPO にし何をプラガブルに残すかは未決である。 Cisco は双方が必要という立場を取り、CPO は電力効率と密度とシンプルな AUI のため、プラガブルはインタフェースの柔軟性のためとする。 Ranovus は、CPO 用シリコンフォトニクスが 400G シリアルの帯域に届かず、1 波長あたりの速度を落として波長数を増やす構成にせざるを得ないという留保をつけている。 NVIDIA は CPO を主軸に据えて電力効率 3.5 倍を主張するが、これは一社の主張であって業界合意ではない。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) ![[_attachments/markunet-ai-ethernet-serdes-trends/page-040.png]] **図9-3**: DSP の搭載範囲を段階的に削る 4 方式の電力効率。1.6T あたりで FRO が 14 pJ/bit(25W)、TRO が 10 pJ/bit(18W)、LPO が 6.4 pJ/bit(11W)、CPO が 4 pJ/bit(7W)となり、到達距離を伸ばせば電力が増えるという構造の中で DSP の電力を取り除くことが削減余地になる。(Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) 前面パネルのフォームファクタについては、新しいものが必要だという点で見解が揃う一方、具体案は並立したままである。 Amphenol は 8 レーンが銅に好ましく 64 レーンは光に有利とし、Huawei は OIF の高密度コネクタ(HDC)を推し、Lightmatter は高速銅ピンを廃して LGA で電力と低速制御だけを供給する方式を提案する。 Molex はフォームファクタではなく機械精度を論点化し、嵌合位置 0.25mm の差で挿入損失が 1.5dB、インピーダンスが 15Ω 動くとする。 これらの具体案は 2026年3月以降、XPO MSA と Open CPX MSA に集約されつつある。 (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]]) ### 9.3 Ultra Ethernet が置き換えた前提 物理層の上に載るトランスポートの側では、**Ultra Ethernet(UE)** が 2025 年に 1.0 仕様として公開された。 中心的な貢献は Ultra Ethernet Transport(UET)という新しいトランスポートプロトコルであり、完全ハードウェアオフロードが可能なコネクションレス設計を持つ。 (Source: [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) UE が何を変えたのかを理解するには、何を前提から外したかを見るのが早い。 InfiniBand は 25 年前に「帯域は高価、計算は安価」という前提で設計された。 2025年時点でトランジスタあたりの計算コストは 100,000 分の 1 以下になった一方、帯域は 100 倍しか伸びていない。 ビットあたりに使える計算が 1,000 倍になったという事実が、パケットスプレーや選択的確認応答やゼロ RTT 接続確立といった「計算コストのかかる」機構をシリコンで合理的に実装可能にした。 UE の設計は、この計算対帯域比の反転を前提の書き換えとして受け止めた結果である。 (Source: [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) 具体的には、RoCEv2 の 3 つの設計限界がそれぞれ置き換えられている。 | RoCEv2 | Ultra Ethernet(UET) | |---|---| | PFC による無損失転送が必須 | 有損失ネットワークでも動作 | | Go-back-N 再送 | 選択的確認応答(SACK ビットマップ) | | 経路固定(フロー単位 ECMP) | エントロピー値(EV)変更によるパケット単位スプレー | | コネクション確立に RTT が追加される | ゼロ RTT の PDC 確立 | | キューペアが接続の概念を担う | JobID と PIDonFEP と Resource Index によるコネクションレス | | セキュリティは後付け | TSS によるゼロトラスト標準組み込み | (Source: [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) 引き継いだものもある。 UE は物理層と MAC を変更せず、スイッチには ECMP と出力側 ECN マーキングのみを要求する。 これにより既存の Ethernet データセンターに段階的に展開できるという移行経路が確保されている。 一方で残された課題も明示されており、ロードバランシングの最善策は仕様上「研究課題」と書かれ、受信クレジット型の RCCC はアウトキャストシナリオで帯域を取り残すためネットワーク信号型の NSCC との併用が推奨される。 著者自身が 562 ページの仕様に対して複数ラウンドのエラータ修正を予告している。 (Source: [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) ![[_attachments/arxiv-2508.08906/fig03-layered-architecture.png]] **図9-4**: Ultra Ethernet の階層構造。アプリケーション層(CCL や MPI)から libfabric を経てトランスポート層(SES、PDS、CMS、TSS)へ入り、その下にネットワーク層(IP)、データリンク層(MAC と任意の LLR や CBFC)、物理層が続く。UE が置き換えたのはトランスポート層であり、物理層と MAC はそのまま引き継ぐ。(Source: [[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]]) ### 9.4 集合通信ライブラリはホスト内トポロジをどう使うか ここまでが NIC の外側の話である。 NIC の内側に戻ると、ホスト内トポロジを実際に使うのは集合通信ライブラリである。 NCCL の内部設計を体系的に文書化した研究は、この使い分けが 2 つの軸で決まることを示した。 プロトコル(Simple、LL、LL128)の選択と、データ転送機構(ノード内の P2P や SHM、ノード間の IB Verbs)の選択である。 (Source: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]]) プロトコルは帯域とレイテンシのトレードオフを形成する。 Simple はメモリフェンスで順序を保証し、ほぼピーク帯域を出す代わりにホップあたり約 6µs を要する。 LL は 4B のデータと 4B のフラグを同時送信してフラグポーリングで即座に検知でき、ホップあたり約 1µs だが帯域利用率は 25% から 50% に留まる。 LL128 は 128B のアトミック書き込みを前提に 120B のデータと 8B のフラグで構成し、ホップあたり約 2µs で帯域の約 95% を得る。 LL128 は 128B アトミックが保証されない PCIe やアーキテクチャ制約下では無効化される。 (Source: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]]) 最適プロトコルは、メッセージサイズだけでなく経路によっても変わる。 CSCS Alps(GH200、16 ノード、Cray Slingshot)での実測では、ノード内(NVLink)では LL128 が全メッセージサイズにわたり最も安定した性能を示す。 ノード間では小メッセージ(64 KiB 未満)で LL と LL128 が最速だが、ギガバイト域では 8B または 128B ごとのフラグ同期オーバーヘッドが数百万回累積して性能が急落し、Simple が一貫して最速になる。 この非対称性は、ホスト内経路とホスト間経路が帯域だけでなく同期コストの構造からして別物であることの現れである。 (Source: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]]) 転送機構の選択は、ホスト内トポロジの読み取り結果に従う。 ノード内では NVLink P2P、PCIe P2P、SHM の優先順で選ばれ、GPU が別ソケットに属してローカル NIC を持つ場合は CPU ボトルネックを避けるために GPU から NIC、NIC から GPU という経路が選ばれる。 ノード間では GPU と NIC が同一 PCIe スイッチに接続する場合に GPUDirect RDMA が使われ、NIC が GPU メモリに直接アクセスしてホストメモリ経由のコピーを排除する。 (Source: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]]) ![[_attachments/arxiv-2507.04786/fig01-intra-node-transfer.png]] **図9-5**: NCCL がノード内で使い分ける転送経路。同一プロセス内で NVLink を使う P2P(DIRECT)、PCIe を越える P2P(IPC/CUMEM)、ホストメモリを経由する SHM が、トランスポートとハードウェアサポートの違いとして色分けされている。(Source: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]]) #### PXN によるホスト間経路の短縮 ホスト内経路とホスト間経路の使い分けを、ライブラリ側から積極的に組み替える機構が PXN(PCI × NVLink)である。 NCCL 2.12 で導入されたこの機能は、GPU が自身のローカルメモリに送信バッファを置く代わりに、NVLink 経由で中間 GPU 上のバッファへ書き込み、その GPU に近い NIC を管理する CPU プロキシに準備完了を通知する。 GPU と CPU の同期はソケットを跨ぐ可能性があるためやや遅くなりうるが、データ自体は NVLink と PCIe スイッチのみを経由するため最大帯域が保たれる。 (Source: [[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]) この機構が効くのは、[[Rail-Optimizedトポロジ]] を前提にした場合である。 同じ番号の NIC が同じ leaf スイッチに接続される構成では、宛先と同じ rail 上の GPU へ先にデータを移してから送信すれば、spine を跨がずに 1 ホップで届く。 PXN 無効時に L0 と S1 と L3 の 3 ホップを要した経路が、PXN 有効時には L3 経由の 1 ホップになる。 加えて、ある宛先に対するデータをノード内の 1 つの GPU に集めることで、最大 8 メッセージを 1 つに集約する multireceive が可能になる。 DGX A100 と InfiniBand の環境で、128 ノード 1024 GPU 構成の all2all レイテンシは約 3980µs から約 1560µs へ、約 2.55 倍改善した。 (Source: [[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]) ![[_attachments/doubling-all2all-performance-nccl-2-12/fig02-message-path.png]] **図9-6**: DGX-A の GPU0 から DGX-B の GPU3 へ届けるときの、PXN の有無による経路の違い。PXN 無効時(濃い経路)は NIC0 と L0 を経て spine の S1 を跨ぎ L3 へ抜ける 3 ホップになる。PXN 有効時(薄い経路)は NVLink で NIC3 に近い GPU3 へデータを移してから L3 経由の 1 ホップで届く。(Source: [[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]) 同じ機構が解く問題は 2 種類ある点に注意が要る。 all2all では交換されるメッセージ数が O(N²) になり、各ペアのメッセージ内容が異なるため tree や ring による最適化ができず、メッセージ数そのものがホットスポットを生む。 一方 all-reduce では、NIC に近い GPU が 1 基しかないトポロジで ring が閉じられないという別の問題が生じる。 ring は最初と最後の GPU の両方が NIC に近い必要があり、閉じられなければ CPU 経由の送信を強いられるからである。 PXN は前者にはメッセージ集約と rail 内経路集約で、後者には NVLink 経由で最初の GPU にデータを戻すことで対処する。 (Source: [[@2022__NVIDIA Developer Blog__Doubling all2all Performance with NVIDIA Collective Communication Library 2.12]]) ### 9.5 大規模クラスタにおける既定値の妥当性 集合通信ライブラリの既定値は、開発者環境の想定に基づいて調整されている。 その想定には、10µs 未満の非常に低い RTT と、適応的ルーティング機構と、オーバーサブスクリプションのない非ブロッキングトポロジが含まれる。 本番の RoCE ファブリックはこれらの想定を満たさない。 CTSW スイッチが Virtual Output Queuing を用いて egress から ingress へクレジット情報を交換するため、無負荷 RTT は約 22µs になる。 NCCL はサーバトポロジは学習して適応するが、ネットワークトポロジへの既定の認識は持たない。 結果として、Meta の本番環境では既定設定の RoCE 性能が本来出せる値の 50% 以下になりうる。 (Source: [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]) 対処はネットワーク側とライブラリ側の協調チューニングとして行われた。 高い RTT に対しては投稿するメッセージサイズと中間バッファサイズを増やしてインフライトデータを確保し、受信側駆動アーキテクチャが依存する CTS(Clear to Send)メッセージの復路遅延に対してはスイッチでの高優先度キューイングにより P90 の遅延を 43µs から 4µs へ削減した。 小メッセージに対しては、既定より大きい集合通信サイズで Tree や Rail-based Alltoall や LL128 を選ぶようチューニングアルゴリズムを調整した。 これらの組み合わせで既定の RoCE 性能を多くのケースで 2 倍以上改善している。 (Source: [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]) 10 万 GPU 規模になると、制約の種類がさらに変わる。 複数のデータセンタ建屋にまたがる物理トポロジでは、ラック内を基準としてラック間が約 7 倍、AI Zone 間が約 15 倍、建屋間が約 30 倍のレイテンシになる。 このレイテンシ階層は、集合通信が BDP を埋めるだけのデータを注入しつつ持続的な輻輳を生まない量に留めるという、相反する要求を課す。 Meta の CCLX はこれに対し、宛先あたりの QP 数とセグメントサイズと未確認メッセージ数という 3 パラメータの積を接続種別ごとに調整する DQPLB を導入し、256 GPU の AllGather で 1GB メッセージのピークバッファを 72% 削減しつつ 8MB メッセージで帯域を 13% 改善した。 (Source: [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]]) ![[_attachments/2026_Unknown_Connecting_100K_GPUs_Building_Communication/fig01-multibuilding-architecture.png]] **図9-7**: 建屋をまたぐネットワーク構成。各建屋は複数の AI Zone を持ち、AI Zone 内はホストから RTSW、CTSW、ATSW の階層で接続され、建屋間は ATSW 層の全結合メッシュで結ばれる。本文のレイテンシ階層は、通信がこの図のどの層まで登るかに対応する。(Source: [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]]) この規模ではデータプレーンだけでなく制御プレーンも問題になる。 100K GPU 規模では 1 日あたり約 49.15 回の障害が想定され、90% の有効訓練時間を保つには 1 回の再起動につき 175 秒しか許容できない。 ベースラインの NCCL 初期化はこの規模で 4 分を超え、予算を超過する。 CCLX は eager 初期化と非同期 I/O ブートストラップと遅延リソース割り当てにより、96K GPU で初期化時間を 265.0 秒から 24.0 秒へ短縮した。 HBM 側でも、遅延通信子リソース割り当てと遅延チャネルプロビジョニングとスラブアロケータにより、64K 規模で通信子あたりの GPU メモリ使用量を約 2 倍削減している。 (Source: [[@2026__SIGCOMM__Connecting 100K+ GPUs - Building the Communication Stack for Large-Scale LLM Training]]) 輻輳制御についても、この規模の運用は教科書的な解から距離を取っている。 Meta は 400G 展開で DCQCN を採用せず、1 年以上にわたり PFC のみのフロー制御と集合通信ライブラリ側の上位層輻輳管理で運用してきた。 この判断はチューニングの困難さに基づく経験的なものであり、著者ら自身が「GPU とネットワークの相対スループットに依存する可能性があるため全シナリオに適用可能とは限らない」と留保をつけている。 (Source: [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]) ### 未解決の問い - P802.3dv タスクフォースが変調方式(PAM4/PAM6/PAM8)と inner FEC をどう決着させるか。XPO MSA の PAM6 実測(2026年9月末見込み)が判断材料として十分な重みを持つかは、この wiki のソースからは確認できていない。 - 「前面パネルまでの銅チャネルを残すか」という分岐が、XPO と Open CPX いずれかの MSA 仕様として決着するのか、両者の併存になるのかは未決である。 - UE と Falcon v1.1 と MRC のどれが AI クラスタの主流になるか。相互運用性と多ベンダー採用の実態は、第 1 世代製品が出揃うまで判断材料が足りない。 - NCCL のプロトコル選択やチューニングは、現状ではオートチューニングか運用者による環境変数の上書きに委ねられている。サービスとして任意ノード数を払い出す環境で望ましい設定を確実に適用させる仕組みは、この wiki のソースからは確認できていない。 - Meta が DCQCN なしで運用できている条件(GPU とネットワークの相対スループット)が、どの範囲のハードウェア構成まで成立するかは定量化されていない。 - UE の LLR バッファ量が制約するクラスタ物理サイズと、集合通信ライブラリ側のバッファ設計(DQPLB のセグメントサイズ等)が、同じインフライトデータ量という資源をどう分け合うべきかは、両者を突き合わせた議論がこの wiki のソースには見当たらない。 --- ## 第10章 インターコネクトの観測と診断 前章までで、ホスト内インターコネクトが性能を左右する経路であることと、その経路がスケールアウト網へどう接続されるかを見てきた。 残るのは運用の問いである。 その経路が今どういう状態にあるのかを、どうやって知るのか。 この問いが厄介なのは、ホスト内には観測点がほとんど存在しないという構造的な事情があるからである。 ネットワーク側にはスイッチという観測点がある。 スイッチはポート単位のカウンタを持ち、キュー占有率を報告し、ECN をマークし、PFC の送出回数を数える。 これに対しホスト内の PCIe リンクやメモリチャネルや UPI には、パケットを数えて外部に報告する主体がいない。 リンクは黙って遅くなり、症状は RNIC のスループット低下や pause frame の増加という形でしか外に現れない。 もう一つの事情は、症状が出る場所と原因がある場所が離れていることである。 ホスト内の 1 本のリンクが劣化すると、そのホストの RNIC が受信を捌けなくなり、pause frame がネットワークへ逆流し、集合通信全体が律速される。 8 ホストの ring-based NCCL all-reduce テストでは、あるホストの RNIC の PCIe リンクが帯域劣化した結果、全ホストのスループットが約 185Gbps から約 50Gbps へ、およそ 70% 低下した。 (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) 運用者が最初に見るのはネットワーク側のメトリクスであり、そこから 1 台のホストの 1 本の PCIe リンクへ辿り着く道筋は自明ではない。 ![[_attachments/nsdi23-liu-kefei/fig01-single-bottleneck-throughput.png]] **図10-1**: 200Gb/s RNIC を持つ 8 ホストの ring-based NCCL all-reduce テストで、1 台の RNIC の PCIe リンクが帯域劣化したときの全ホストのスループット。正常時の約 185Gbps(上側の線)から約 50Gbps へ落ちており、ホスト内の 1 本のリンクが分散システム全体を律速することが読み取れる。(Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) 本章は、この「見えなさ」に対する複数のアプローチを順に見る。 能動的にプローブを打って箇所を特定する系統、ハードウェアカウンタを集めて可視化する系統、NIC が存在しないスケールアップ網を測る系統、ネットワークとホストのテレメトリを統合する系統、そして本番規模でのトレーシングである。 最後に、何が測れて何がまだ測れないのかを整理する。 ### 10.1 既存のネットワーク監視がホスト内を見られない理由 ホスト内が観測されてこなかったのは、長らく観測する必要がなかったからである。 ホスト内ネットワークは十分な余剰帯域を持ち、通信のボトルネックにならないと見なされてきた。 この前提が崩れたのは RNIC 線速の急増による。 RNIC の線速が 25Gb/s から 200Gb/s へ増える一方、PCIe の帯域は世代交代のペースがそれに追いつかず、PCIe Gen3 x8 の約 63Gb/s から Gen4/Gen5 世代の約 252Gb/s という伸びに留まった。 結果として、かつて余裕のあったホスト内ネットワークが RNIC の実効スループットを制限する側へ転じた。 (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) 既存のツールが役に立たなかった理由は 3 つに整理されている。 第一に、既存のボトルネック診断ツールはベンダー固有である。 Intel PCM は Intel CPU 用、AMD uProf は AMD CPU 用、Nvidia SMI は Nvidia GPU 用、Mellanox Neohost は Mellanox RNIC 用であり、複数ベンダーの部品を組み合わせたホストでは複数ツールの学習と運用のコストが発生する。 第二に、ホスト内ネットワークに特化した監視システムが存在しなかったため、ボトルネックが発生してから気づくまでに時間がかかった。 第三に、perftest や nccl-test のようなベンチマークは end-to-end の性能を反映するため、ボトルネックがネットワーク側にあるのかホスト内にあるのかを即座に切り分けられない。 (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) ### 10.2 能動的プロービングによる箇所特定 観測点がないなら作ればよい、というのが能動的プロービングの発想である。 [[ホスト内ネットワークボトルネック]] の診断が成立する土台は、根本原因は多様でも観測可能な症状は 2 つに収斂するという経験則にある。 リンク障害でもトラフィック輻輳でも誤設定でも、外に現れるのはホスト内帯域の劣化とホスト内レイテンシの増加のいずれか、または両方である。 この収斂があるからこそ、ベンダー固有の多数のメトリクスを個別に読む代わりに、単一の計測手法で大半のボトルネックを捉えられる。 (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) #### ループバックテストは RNIC を計測器として使う Hostping の計測手法は、RNIC 自身を計測器に仕立てるものである。 `ibv_reg_mr` でエンドポイント上に read 用と write 用の 2 つのメモリ領域を登録し、`ibv_post_send` で write WQE を投げる。 送信者と受信者が同一 RNIC であるため、RNIC は read 領域から読んだデータをネットワークへ送出せず直接 write 領域へ書き戻す。 `ibv_post_send` の呼び出しから completion のポーリングまでの時間差がループバックレイテンシになる。 測定値は $Lat = T_{proc} + Lat_{host} + Size/BW_{host}$ と分解でき、1 バイトの小メッセージでは $T_{proc} + Lat_{host}$ に、128KB の大メッセージでは $Size/BW_{host}$ に近似できるため、両者の差分からホスト内帯域が求まる。 (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig05-hostping-core-idea.png]] **図10-2**: Hostping の 2 つのプローブ経路。赤の破線は RNIC とホスト内エンドポイント(GPU とメモリノード)の間のループバックテストで、通信はホスト内で完結しネットワークへ出ない。黒の破線は後述する R2R probing で、同一ホスト上の RNIC 同士が ToR スイッチを経由してプローブし合う。(Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) レイテンシが帯域に効く機構は明示されている。 RNIC がエンドポイントへ PCIe read request TLP を送ってからデータが返るまでの往復が伸びると、line rate を維持するにはより多くの outstanding read request が必要になるが、RNIC にはその上限がある。 GDR トラフィックが単一 PCIe スイッチ経由(距離1)なら 1.0µs、CPU root complex 経由(距離3)なら 2.2µs、UPI 経由(距離4)なら 2.4µs になり、対応するスループットは 195.0 Gbps、125.5 Gbps、116.4 Gbps と落ちる。 わずか 1.4µs の追加レイテンシが約 40% のスループット低下をもたらす。 (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) #### binary network tomography のホスト内適用 パスごとの正常と異常だけからリンク単位の状態を逆算する手法は、もともとスイッチとリンクの箇所特定に使われてきた binary network tomography である。 Hostping はこれをホスト内トポロジに適用する。 ホストがアイドルのとき、RNIC と各エンドポイントの間で full-mesh のループバックテストを行い、パス $j$ の状態を $y_j = \prod_{i: link_i \in path_j} x_i$ としてそのパス上の全リンクの積で表す。 アルゴリズムは全リンクを uncertain に初期化し、正常パス上のリンクを normal にマークし、異常パス上に uncertain のリンクがあればそれを abnormal にマークして `abnormal_cnt` を増やす。 異常パスの全リンクが既に normal である場合はフラッピングを疑って gray とマークし、3 回連続で gray なら flapping link と確定する。 (Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) この推論には、原因の種類を切り分ける追加情報が要る。 ある帯域劣化がトラフィック輻輳によるものかリンク障害によるものかは、ループバックテストだけでは判別できない。 そこで Bus Monitor が PCIe リンクとソケット間バスとメモリチャネルの使用率を監視し、リンクが閾値を超えて過負荷なら輻輳、そうでなければリンク障害と推定する。 ホストが混雑しているときは full-mesh を諦め、RNIC とその affinitive エンドポイント間のみを測る。 同一 root port 配下のエンドポイントへの帯域はサービストラフィック下でも通常ほぼ同一のはずなので、ある宛先だけが閾値(20%)以上低ければそのパスを異常と判定できる。 (Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) 本番展開の成果は、この手法が見つけるものの幅を示している。 300 台超の本番サーバへの展開で、既知の 4 種のリンク障害(RNIC PCIe、GPU PCIe、メモリチャネル、UPI)に加えて 6 種が新たに発見された。 CPU ルートポート障害は、そのルートポート自体との直接パスは正常なのに、それを経由する他のパスが劣化するという固有のパターンを示す。 メモリチャネルのフラッピングは、単発の手動テストでは発見できず、継続的な実行によってのみ捉えられた。 残りは設定に起因するもので、ACS の意図しない有効化は GDR トラフィックを CPU へ迂回させ、仮想化環境での ATS 無効化は GDR パケットのアドレス変換のために全て CPU root complex を経由させる。 ホスト内ボトルネックの根本原因は物理故障に限らず設定層にも及ぶ。 (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]]) ![[_attachments/diagnosing-end-host-network-bottlenecks-rdma/fig08-bandwidth-matrices-idle.png]] **図10-3**: ホストがアイドル時に計測したホスト内 end-to-end 帯域行列。緑が正常、赤が異常、灰が不確実である。(a) は RNIC PCIe リンク障害、(b) は GPU PCIe リンク障害とメモリチャネル障害、(c) は UPI 障害、(d)(e) は CPU ルートポート障害、(f) は ACS 有効化による誤設定に対応する。(d)(e) では、ルートポート自体との直接パスが正常なままそれを経由するパスだけが劣化するという、他とは異なるパターンが現れている。(Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) #### RNIC 間相互プロービングは第3の症状カテゴリを切り出す 拡張版では、ホスト内の 2 症状に加えて第 3 の症状カテゴリが導入された。 接続性問題である。 ルーティング設定の欠落や RNIC のフラッピングにより、ある RNIC が他の RNIC と RDMA 通信できなくなるという症状は、ホスト内リンクの帯域やレイテンシとは別の軸にある。 R2R(RNIC-to-RNIC)probing は、ホスト上の各 RNIC が 100ms 間隔で 1 バイトの RDMA パケットを構築し、同一ホスト上の他の RNIC からランダムに 1 台を選んでプローブする機構である。 プローブは ToR スイッチを経由するため、ループバックテストと違ってホスト外へ出る。 (Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) この機構が切り分けられる粒度には限界がある。 RNIC A から RNIC B へのプローブがタイムアウトしたとき、原因は A にも B にも ToR スイッチにもありうるため、これらはまとめて「RNIC ネットワーク問題」として扱われる。 ホスト内診断がリンク単位まで原因を特定できるのに対し、接続性診断の粒度は明らかに粗い。 それでも実運用では成果を出しており、全 RNIC へのタイムアウト率が約 2/3 で高止まりしていた事例では、RNIC2 と RNIC3 が異なるサブネットに属する誤ったスイッチポートに接続されていたことが判明した。 継続的に 100% タイムアウトする場合は RNIC ダウンかルーティング誤設定、突発的なタイムアウトはハードウェア障害という経験則も報告されている。 (Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) ここで注目すべきは、[[RDMAネットワーク監視]] の側でも同じ推論が独立に採用されていることである。 パス単位の観測からリンク単位の状態を逆算するという枠組みは、対象がホスト内の PCIe とメモリチャネルであっても、ネットワーク内のスイッチとリンクであっても同じ数理で機能する。 箇所特定アルゴリズムは計装位置に依存しない汎用的な設計パターンとして再利用できる。 (Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) ### 10.3 ハードウェアカウンタからの観測 能動的プロービングとは対照的に、既にハードウェアが数えている値を集めて並べるという方向もある。 GPUDirect RDMA は CPU とホストメモリをバイパスして通信を高速化する一方、その経路の可観測性を犠牲にした。 GPU 間通信は CPU と GPU と Root Complex と RNIC という複数のコンポーネントを経由し、どの経路を通るかがスループット全体に影響する。 したがって NIC のスループットだけを計測するのでは足りない。 (Source: [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]]) InterconnectLens(ICLens)はこれを、コンポーネント別かつ TX/RX 方向別の帯域を単一ダッシュボードへ時系列で並置することで解く。 実装はコンポーネントごとに手段を変えている。 GPU は NVIDIA の dcgm-exporter をそのまま使い、CPU PCIe と CPU Memory は Intel の pcm を Prometheus 互換形式でメトリクスを出すよう約 2,400 行かけて拡張し、RNIC は独自の Exporter を書いた。 RNIC に独自実装が要ったのは、RDMA トラフィックが RNIC ハードウェアにオフロードされるため `/proc/net/dev` のような標準のカーネルインターフェースカウンタには現れず、`/sys/class/infiniband/mlx5_1/ports/1/counters/port_rcv_data` のような `/sysfs` 配下から取る必要があるからである。 各 Exporter の CPU 使用率はいずれも 1 コアの 1% 未満に抑えられている。 (Source: [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]]) 横並びにすることの価値は、単一メトリクスでは区別できない状態が区別できるようになる点にある。 `NCCL_NET` が未設定または `Socket` に誤設定されて意図せず TCP が使われる場合、RNIC の系列は無負荷のまま CPU PCIe と CPU Memory が立ち上がる。 GPUDirect RDMA が誤設定されてデータが CPU をバウンスする場合、RNIC は RDMA が活性で正常に見えるのに CPU PCIe と CPU Memory に追加負荷が現れる。 この 2 ケースは RNIC のメトリクスだけを見ていると区別がつかない。 スイッチ輻輳のケースはこれらと対照的で、CPU 側の系列に異常が出ず RNIC 自体の帯域低下として現れる。 (Source: [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]]) ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig04a-gpudirect-rdma-correct.png]] ![[_attachments/InterconnectLens_Enhancing_Observability_Data_Transfers/fig04b-gpudirect-rdma-misconfig.png]] **図10-4**: GPUDirect RDMA が正常な場合(上)と誤設定の場合(下)のダッシュボード。正常時は RNIC と GPU0 PCIe だけが活性で CPU PCIe と CPU MEM は無負荷に留まる。誤設定時は CPU PCIe と CPU MEM に追加負荷が現れるのに対し、RNIC は RDMA が活性でノード間転送を正しく処理しているように見える。この乖離が誤設定の手がかりになり、RNIC 単独のメトリクスからは読み取れない。(Source: [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]]) ここで著者らが取った設計判断は明示的である。 ICLens は異常検知アルゴリズムも閾値判定も持たない。 上記の切り分けは、人間がコンポーネント別のグラフを並べて見比べることで行うと論文中に書かれている。 自動診断を志向する他の監視系と比べると逆方向の判断だが、複数ベンダーにまたがる異種メトリクスをまず単一の可視化平面へ統合すること自体に価値があるという立場として理解できる。 自動検知への拡張は著者ら自身が今後の課題として挙げている。 (Source: [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]]) ### 10.4 NIC が存在しないスケールアップ網をどう測るか ここまでの手法はいずれも NIC の存在を前提としている。 ループバックテストは RNIC を計測器に使い、カウンタ収集は RNIC の `/sysfs` を読む。 ところが NVLink や UALink で 8 基から 72 基の GPU を結ぶスケールアップ網には NIC が存在しない。 経路は GPU から Fabric を経て GPU へ直行し、PCIe すら通らない。 その結果、eBPF のようなホスト側の計装技術は使えず、観測はアプリケーション層の粗いカーネル所要時間に限定されてきた。 (Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) 計測が難しい理由は 3 つある。 スケールアップ網は GPU 上の SIMT プログラムモデルのみで動作し CPU と OS に対して透過的であること、下位のファブリックとスイッチがプロプライエタリで公開インターフェースに乏しいこと、そしてネイティブなセマンティクスが send/recv ではなくメモリの ld/st であることである。 最後の点は測るべき対象そのものを変える。 Ethernet と IP の MTU が 1500 バイトで少数スレッド(50 未満)で飽和するのに対し、スケールアップファブリックの MTU は 128bit しかなく、NCCL が H100 の NVLink の 350GB/s を飽和させるには 10,240 スレッドを要する。 (Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) FabricPerf は 3 つの設計でこの空白を埋める。 第一に、GPU の通信カーネルにアセンブリレベルのプローブを挿入し、通信の往復を 5 つのタイムスタンプと 2 つのスピンカウントに分解してパケット単位のレイテンシを取る。 NIC のバッファがないため送信側は受信バッファの空き通知を待ってから送信を開始せざるを得ず、ACK に相当する CLEAR を先頭へ移す設計変更が必要になった。 第二に、GPU 内蔵のデバイスクロックを使う GPTP により、NIC の PTP クロックに頼らず GPU 間のクロックを同期する。 第三に、通信をメモリトラフィックとしてモデル化し、成熟したメモリプロファイラ(CUPTI)で LLC の挙動などの物理層の振る舞いを推定する。 オーバーヘッドはオフライン収集でホットパスの約 0.6%、オンライン計測で 8.9% に留まる。 (Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) ![[_attachments/2026_Unknown_FabricPerf_Measuring_NIC_less_Scale/fig01-overview.png]] **図10-5**: FabricPerf の 3 設計が計測対象のどこに載るか。GPU の通信カーネルコード(SEND と RECV)に GPTP の時刻同期とパケット単位のタイムスタンプを挿し、通信をメモリトラフィックとして捉えることで、128bit MTU のメモリからファブリックを経てメモリへ至る経路をハードウェア層まで計測する。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) 測れるようになって初めて見えたものが 2 つ報告されている。 一つはチャネル間の不均衡である。 P99 レイテンシが P50(約 7µs)の約 2 倍に達し、P1 は 4µs まで低いという分布の広がりが観測された。 これが飽和による不可避な現象でないことは、飽和水準の 300GB/s 超から程遠い約 200GB/s の 12 チャネル時点で既に不均衡が生じることから確認された。 work-stealing によるチャネルバランサで SendRecv のスループットが 262.1GB/s から 349.3GB/s へ改善している。 もう一つはキャッシュの非効率で、16 チャネル以上かつ 350GB/s 以上になると LLC のヒット率が読み書きとも約 0% まで崩壊する。 PTX の eviction 優先度指定でチューニングすると、ReduceScatter の LLC 読み取りヒット率が 34.86 ポイント改善した。 (Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) ただしこの手法にも届かない層がある。 Layer-2 のパケット処理エンジンがプログラマブルでないため、ルーティング決定やパケット化の詳細や Layer-2 のレイテンシは直接観測できない。 NvSwitch と UASwitch は GPU と独立に動作し公開インターフェースが限られるため、スイッチの影響は end-to-end のレイテンシからの間接推定に留まる。 チャネル不均衡の根本原因がポート選択なのかスケジューリングなのかも、ネットワーク層の詳細が得られないため確証できないと著者らは明記している。 (Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) ### 10.5 ネットワーク側とホスト側のテレメトリの結合 ここまでの手法は、ホスト内ならホスト内、スケールアップ網ならスケールアップ網と、対象を絞ることで成立してきた。 これに対し、ネットワーク内テレメトリとホスト側トレーシングをフロー単位で結合しようという試みもある。 両者が別々に発展してきた結果、監視システムが断片化してクローズドループ制御とクロスレイヤー最適化の有効性が制限されているという問題意識である。 (Source: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) INTFusion の設計判断は、INT のソースとシンクの機能をスイッチではなくエンドホストの smartNIC へオフロードする点にある。 これによりスイッチへの要件は INT トランジット機能のみに縮小され、ネットワーク計測とアプリケーションコンテキストが同じ場所で結合できる。 ホスト側では eBPF と PF_RING と `/proc` により、システムコールイベントとパケットレベル統計とカーネル状態を並行して収集する。 エクスポートは二層構成で、閾値超過のような遅延に厳しいイベントは即時配信し、非クリティカルな計測はレート制御して送る。 長期持続する TCP コネクション上の複数アプリケーションメッセージを分離するため、5 タプルとパケット間隔閾値によるフローレット識別子を導入している。 (Source: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) ![[_attachments/1571262346/fig02-intfusion-architecture.png]] **図10-6**: INTFusion のデータの流れ。送信側ホストが INT 命令を挿入し、トランジットノードがメタデータを付加し、宛先の smartNIC が INT シンクとして集計とイベント検知を行う。フロー完了時の集計データはレート制御してコレクタへ送り、検知したイベントは即時に送る。コレクタでホスト層とネットワーク層のテレメトリが結合される。(Source: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) 統合の代償はオーバーヘッドとして現れる。 smartNIC の処理能力は INT ノード数と命令数の両方に比例して落ち、1 ノード 1 命令で 3.9 Mpps だったものが 5 ノード 4 命令では約 1.25 Mpps になる。 10 GbE の最大約 14.88 Mpps と比べると、これは制限要因になりうる。 ホスト側では Spooler がイベントバッファ用のポーリングスレッドで約 2 コア相当を消費する。 評価環境が 10 GbE の smartNIC に限られるため、100G 以上のデータセンターネットワークへの適用性は検証されていない。 eBPF によるホスト側トレースが送信フローのみに限定されており受信フロー側が欠けている点も、著者ら自身が挙げる限界である。 (Source: [[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]]) ### 10.6 本番規模のトレーシングにおける常時稼働と細粒度の両立 1 万 GPU を超える本番クラスタになると、要求はさらに厳しくなる。 性能劣化(fail-slow)は断続的で予測不能なため、手動トリガーや短時間サンプリングでは捉えられず、常時稼働が要る。 一方で GPU 時間は高価であり、細粒度プロファイラの 5% から 30% というオーバーヘッドは許容できない。 4096-GPU の訓練ジョブでは、反復時間のスパイクにより約 23,758 GPU 時間、総計算量の 7% が浪費された事例が報告されている。 (Source: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]]) ARGUS は観測を訓練の呼び出し階層に沿って 3 層に分解する。 CPU コールスタックは改造した `py-spy` による外部サンプリングで、フレームワークセマンティクスは forward と backward と optimizer と communication の各フェーズ境界へ挿入した CUDA Event で、GPU カーネル実行は CUPTI Activity API で取る。 いずれも訓練コードへの変更を要さず、合計オーバーヘッドは 2% 未満に収まる。 比較対象の PyTorch Profiler は常時稼働モードで 20% から 44% の遅延増加の末に OOM に至り、nsys は 8-GPU で 9 ステップ、32-GPU で 4 ステップでクラッシュした。 (Source: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]]) ![[_attachments/arxiv-2606.20374/fig02-hierarchy.png]] **図10-7**: 訓練実行の階層と計装の対応。Python 層、訓練フレームワーク層、GPU ランタイム層という 3 層に対して、CPU コールスタック、フレームワークセマンティクス、カーネル実行という 3 つの観測機構が割り当てられる。(Source: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]]) 規模の問題はデータ量として現れる。 1 万 GPU の生トレースは毎分 6GB から 60GB に達し、そのままでは cross-rank の比較が計算量でもストレージでも成立しない。 ARGUS は分散訓練のカーネル実行が高度に規則的な繰り返しパターンを持つことを利用し、`(kernel, stream, rank)` の組ごとに対数変換した持続時間へ KDE を適用してクラスタを切り、各クラスタの `(count, p50, p99)` の 3 統計だけを残す。 これにより 10 MB が 2.7 KB へ、約 3,700 倍に圧縮される。 診断は L1 の反復時間異常検出から L5 の CPU コールスタック確認まで 5 段階で行われ、自動の L1 から L3 が対象範囲を数万ランクから一桁まで絞り、手動の L4 と L5 が根本原因を確認する。 (Source: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]]) 本章の関心に照らすと、ケーススタディの 2 件が示唆的である。 512-GPU の音声モデル訓練では、反復時間は安定しているのに総スループットが低いという状態が続いていた。 L3 の分布比較で特定のグループの通信カーネル分布が系統的に乖離していることを検出し、L4 でそのグループ内の AllGather と ReduceScatter が待機時間ゼロのまま遅いことを確認した結果、PCIe リンクのハードウェア障害に行き着いた。 反復時間の閾値や heartbeat に依存する監視系ではこの種のサイレントな劣化は検出できない。 逆に 12,960-GPU の MoE 訓練では、アウトオブバンド監視が「サーバーポートダウン」と報告したにもかかわらず、実際には演算のみのフェーズが約 5.7 倍に劣化しており通信は正常だった。 症状の現れる層と原因のある層は一致しないため、層をまたいで突き合わせられる計装がないと誤診断が起きる。 (Source: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]]) ### 10.7 何が測れて、何がまだ測れないのか 測れるようになったものを整理すると次のようになる。 | 対象 | 手法 | 得られる粒度 | |---|---|---| | ホスト内リンク(PCIe、メモリチャネル、UPI) | RNIC ループバックテストと binary network tomography | リンク単位の正常と異常 | | RNIC の接続性 | R2R probing | RNIC と ToR をまとめた単位 | | GPU 間通信路のコンポーネント別帯域 | ハードウェアカウンタの並置 | コンポーネント単位かつ TX/RX 方向別 | | スケールアップ網の Transport 層 | 通信カーネルへのプローブ挿入と GPTP | パケット単位のレイテンシとスループット | | フロー単位のネットワークとホストの結合 | smartNIC への INT オフロードと eBPF | フローレット単位 | | 本番クラスタの性能異常 | 3 層計装と統計圧縮 | カーネル単位の分布 | 測れないものも同様に明確である。 Hostping が検知できるのは外因的な問題(障害、誤設定、トラフィック輻輳)に限られ、IOMMU や DDIO のようなホスト内在的な問題や、RNIC のハードウェアネットワークスタックや資源や性能分離といった RNIC 内在的な問題は対象外である。 (Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) スケールアップ網では Layer-2 以下がブラックボックスのままであり、スイッチの影響は間接推定に留まる。 (Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) 本番トレーシングでも、パイプライン並列のバブル転送や勾配同期によるアライメント効果が異常を覆い隠すため、自動診断が失敗して手動確認に落ちるケースが残る。 (Source: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]]) もう一つ、断片化そのものが残された課題である。 ホスト内診断とネットワーク監視は binary network tomography という共通の推論を独立に再発明しており、接続性検証の実装も収斂しつつある。 それでも両者を単一のダッシュボードと単一の根本原因分析パイプラインへ統合する仕組みは、この wiki が持つソースからは確認できていない。 (Source: [[@2024__TON__Diagnosing End-Host Network Bottlenecks in RDMA Servers]]) ### 未解決の問い - Hostping が症状として検知する帯域劣化とレイテンシ増加を、ホストネットワーク内部のどのドメインのクレジット枯渇に帰着させるかという根本原因メカニズムとの接続は、この wiki のソースでは同一の運用パイプラインとして設計されていない。 - ホストが混雑している状態での診断精度は affinitive エンドポイントの相対比較に依存する。end-to-end のトラフィック情報を得ればより正確になるとされるが、どの情報源が有効かは示されていない。 - R2R probing がタイムアウトの原因を RNIC 自体と RNIC-ToR 間リンクと ToR スイッチポートに切り分けられない理由が、ToR 側の情報が得られないという制約だけなのかは確認できていない。 - FabricPerf が発見したチャネル不均衡の根本原因(ポート選択かスケジューリングか)は、ネットワーク層の詳細が公開されない限り確証できない。スケールアップ Ethernet や UALink が開放標準の層を再導入した場合に測定設計がどう変わるかも未検証である。 - INTFusion の評価は 10 GbE の smartNIC に限られており、100G 以上での処理能力とコレクタのスケーラビリティは評価されていない。 - 可視化に徹する ICLens のような設計と、自動検知を志向する設計のどちらが運用上有効かは、判断基準がこの wiki のソースからは導けない。両者を役割分担させる設計指針も示されていない。 --- ## 第11章 設計と運用の指針 ここまでの各章は、層ごとに何が起きているかを記述してきた。 この章は向きを変えて、設計や運用の場面で下す判断に知見を対応づける。 新しい事実は導入せず、既出の観察を判断の順序として並べ直す。 ### 11.1 律速点を切り分ける順序 ホスト内部の性能問題に直面したとき、どの層から疑うかには手がかりがある。 出発点は、症状が帯域に出ているかレイテンシに出ているかの区別である。 両者は独立に評価する必要があり、同じ非対称性でもレイテンシ差はホップあたり約 40ns と小さい一方、帯域は最大 40% 低下しうる (Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]])。 ホップ数だけを見て配置を決めると、レイテンシは説明できても帯域の劣化を見落とす。 次に、劣化しているのがコア由来のトラフィックか周辺機器由来のトラフィックかを見る。 この区別が効くのは、両者の通るドメインが異なり、同じ競合に対する劣化の現れ方が逆転しうるからである。 メモリ帯域が飽和していない段階でコア由来のトラフィックだけが劣化する状況は実際に観測されており、メモリ帯域の使用率だけを見ていると原因を取り違える (Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 ホスト内部とネットワークの切り分けには、ホスト内に閉じたループバック測定が使える。 RNIC とエンドポイントの間で full-mesh のループバックテストを行えば、スイッチやケーブルを経由せずにホスト内リンクの状態を観測できる (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 ここで異常が出なければ、疑いをネットワーク側へ移してよい。 ただし、この順序は万能ではない。 ホスト内部の症状は、リンクの故障だけでなく正常動作時の設計上の非対称性からも生じる (Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 「どこも壊れていないのに遅い」という結論は、切り分けの失敗ではなく妥当な結論でありうる。 ### 11.2 配置をどう決めるか 配置の判断には、繰り返し確認された基準がある。 最良の配置はホップ数ではなく総帯域で決まる (Source: [[@2015__ATC__Thread and Memory Placement on NUMA Systems - Asymmetry Matters]])。 この基準は 2 ソケット構成と 8 ソケット構成という異なる規模で独立に確認されている。 スレッド配置の違いだけで性能が大きく変動する以上、既定のスケジューリングに任せきる設計は避けたほうがよい。 配置が必要な対象は CPU とメモリに限らない。 NIC も GPU と同じく特定のソケットにぶら下がる I/O デバイスであり、近接配置の効果は同じ枠組みで説明できる (Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]])。 GPU のピニングだけを行い NIC の配置を放置する構成は、片手落ちになる。 書き込み方向の非対称性にも注意がいる。 DMA や RDMA の書き込みでは、書き込み先バッファの配置だけが帯域を左右するという非対称な効果が観測されている (Source: [[@2007__PDCS__Impact of NUMA Effects on High-Speed Networking with Multi-Opteron Machines]])。 送信側と受信側を対称に扱うと、片方の最適化が無駄になる。 なお、これらの実測はいずれも AMD Opteron 系に限られており、Intel の UPI を持つ構成で同じ定式化がどこまで成り立つかは未検証である。 基準として使う際は、自環境での再測定を前提に置くのが妥当である。 ### 11.3 帯域収支を見積もる 公称帯域から実効帯域を見積もるとき、差し引くべき要因は層ごとに決まっている。 PCIe では、TLP のヘッダオーバーヘッド、DLL のフロー制御と確認応答、そして MPS と MRRS のネゴシエーション結果が実効帯域を決める (Source: [[@2018__SIGCOMM__Understanding PCIe performance for end host networking]])。 これらはリンク速度の表記には現れないため、カタログ値をそのまま容量計画に使うと過大な見積もりになる。 物理層では、レーンあたりの速度と変調方式と FEC の選択が帯域密度の上限を決める。 FEC の選択はレイテンシを通じてクラスタの物理サイズにまで及び、リンク層再送の到達距離が 20% 縮むとノード数が 2 次元トポロジで 36% 減少する (Source: [[@2026__SpeakerDeck__AIのためのEthernet技術動向 (SerDes)]])。 物理層の判断は、電気的な性能だけでなくクラスタ設計の制約として現れる。 構造的な傾向として、NIC の線速の伸びに PCIe 帯域の伸びが追いついていない (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 NIC を高速なものに交換しても、ホスト内部が受け止められなければ効果は出ない。 帯域収支は NIC 単体ではなく、NIC からメモリまでの経路全体で見積もる必要がある。 ### 11.4 既定値と自動選択を疑う 既定設定が最適である保証はない。 大規模クラスタ 3 システムを最大 4,096 GPU で比較した研究は、既定設定がどのシステムでも最適から程遠く、手動チューニングで最大 1 桁の性能向上が得られると報告する (Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 既定値は無難な妥協点であって、特定構成に対する最適解ではない。 通信ライブラリの自動選択も、前提が実機と食い違えば外れる。 ホップ数だけから帯域を推定する実装は、リンク本数が異なるトポロジで帯域を取りこぼす (Source: [[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 自動選択はトポロジ検出の表現力に依存しており、その表現力が実機の非対称性に追いついていないことがある。 誤設定は性能問題としてハードウェア障害と区別しにくい形で現れる。 ACS や ATS の誤設定が、ハードウェア障害と同水準の深刻な劣化を引き起こした事例が報告されている (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 症状だけから設定起因と故障起因を切り分ける一般的な手順は確立していないため、構成の受け入れ検査で設定を確認しておくほうが安上がりになる。 ### 11.5 観測点を先に配置する ホスト内部は観測点が乏しく、事後に足すのが難しい層である。 カーネルバイパスは、性能を得る代わりに OS が持っていた観測点を消す。 ワンサイド操作は受信側の OS に記録を残さないため、受信側から見ると通信が起きたこと自体が見えない (Source: [[@2023__NSDI__Hostping - Diagnosing Intra-host Network Bottlenecks in RDMA Servers]])。 高速化の手段を選ぶ時点で、何が見えなくなるかを併せて決めている。 スケールアップ網は NIC を経由しないため、ネットワーク機器側のテレメトリが存在しない。 そのため GPU の通信カーネルをプロファイリングするという、計算側から通信を推し量る手段が採られている (Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]])。 観測手段が層ごとに分かれている現状では、輻輳の帰属を層をまたいで行うのは難しい。 粒度の選択も設計時に決まる。 細粒度の監視を加えれば複数の同時障害も扱えるようになる一方 (Source: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])、常時稼働のオーバーヘッドとの釣り合いを取る必要がある。 粗い粒度で取り始めると、後から細かくしたくなったときに過去のデータが使えない。 ### 11.6 層をまたいで残る問い 各章の末尾に挙げた問いのうち、複数の層に共通して現れるものを三つ挙げておく。 第一に、ホスト内部の精密なモデルは単一ソケットに閉じている。 ドメインごとのクレジットベースフロー制御は単一ソケット、単一 IIO、Intel の 2 世代で検証されたにとどまり、UPI をまたぐ経路や CXL 接続メモリ、NVLink を含む構成へ拡張できるかは示されていない (Source: [[@2024__SIGCOMM__Understanding the Host Network]])。 ソケット内の精密なモデルと、ソケット間や外部インターコネクトの議論は、まだ一本の式で結ばれていない。 第二に、層ごとに別々の観測手法が積み上がった結果、統合された帰属が成立していない。 ホスト内プロービング、ハードウェアカウンタ、GPU カーネルのプロファイリング、ネットワーク側テレメトリは、それぞれ別の前提と粒度で動いている。 どの層が律速しているかをアプリケーションから見た単一の指標で表現する方法は、まだない。 第三に、層の境界そのものが動いている。 CXL はメモリ層へ、Ethernet はスケールアップ層へ侵入しつつある。 層に基づく切り分けは現時点では有効な道具だが、その有効期限は境界の移動速度に依存する。 ### 未解決の問い - 層ごとの律速点を統合した性能モデルは構築可能か。単一フローのオーバーヘッドモデルと複数フローの輻輳モデルさえ、PCIe という単一の層の内部で未統合のままである。 - ホスト内部の観測手法(能動プロービング、ハードウェアカウンタ、カーネルプロファイリング)を共通の指標体系へ束ねる設計はありうるか。 - 「総帯域が最大の配置を選ぶ」という基準は、CPU とメモリの通信を対象に定式化された。NIC や GPU や CXL メモリを含むヘテロジニアスな配置問題に、同じ目的関数を適用できるか。 - 設定起因の劣化とハードウェア障害を、症状の観測だけから区別する一般的な手順は作れるか。 ---