## 定義 GPU ストレージ I/O データパスとは、GPU アクセラレータがストレージデバイス(SSD・NVMe・PMem 等)からデータを取得・書き込みする際に経由するソフトウェア・ハードウェア経路の総称である。カーネル内非同期 I/O(libaio)、ハイブリッドなカーネル・ユーザー I/O(io_uring、割り込み駆動/各種ポーリングモード)、ユーザー空間ポーリング I/O(SPDK)、GPU 直接転送([[GPUDirect Storage]] = GDS)の4段階に大別され、CPU 仲介型(libaio・io_uring・SPDK、ホスト DRAM を経由)と Direct-to-GPU(GDS、ホスト DRAM をバイパスし NVMe と GPU HBM 間を PCIe 経由で直接 DMA)の2系統に分かれる(Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]] §2.2)。GPU 計算性能の向上にストレージ I/O スタックの改善が追いつかず、訓練時間の 10〜70% が I/O 待ちで失われるという報告があり、この「ストレージ・計算間のギャップ」を埋める設計選択の対象がこのデータパスである。 ## 横断的知見 - **単一のデータパスが全フェーズで最適になることはなく、「粗粒度・シーケンシャル」対「細粒度・ランダム」というアクセスパターンの違いが最適解を二分する**: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]]は、LLM の推論(細粒度・ランダム・レイテンシ重視)では interrupt-driven io_uring が最良、事前学習・ファインチューニング(粗粒度・シーケンシャル・スループット重視)では [[GPUDirect Storage]] が最良と、フェーズによって逆転する結果を示す。CPU 効率(GB/s per core)で見ると、GDS はメディア律速の帯域上限(NVMe で ≈6.14 GB/s)に libaio(~49% CPU)・io_uring(~100% CPU)の 1/4〜1/8 の CPU(~12%)で到達する一方、64 KB 未満の細粒度 I/O では POSIX 相当の挙動に後退しレイテンシ・スループットが悪化する。この非対称性(粗粒度で圧勝・細粒度で劣後)は GDS という単一技術の内部でも観測され、「データパスの選定はワークロードのアクセスパターンに従うべきで、単一の万能解は存在しない」という設計原則を裏付ける。(Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]]) - **ポーリング系 I/O(SQPOLL・HIPRI・FULL・SPDK)は「CPU を犠牲にしてレイテンシのわずかな改善を得る」という共通のトレードオフを持つ**: SQPOLL は interrupt 駆動 io_uring に対し CPU 消費をほぼ1桁(NVMe SSD で最大 +1289.6%)増やす一方、slat(submission latency)は I/O 時間全体の 3% 未満しか占めず、レイテンシ改善効果はごくわずかである。この「ポーリングの CPU コスト対レイテンシ便益」の非対称性は、GPU が複数台(最大8台)共有ホストの I/O 複合体からデータを取り込む際に CPU 資源の枯渇として顕在化し、単一 GPU 環境では許容できる CPU コストが、マルチ GPU 環境では非現実的になる。(Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]]) - **NIXL のようなプロダクション推論スタックは、GDS を汎用バックエンドの1つとして扱うが、ストレージ性能の実測研究([[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]])はその適用範囲をフェーズ・粒度で限定する**: [[NIXL]] は KV キャッシュ転送のバックエンドとして UCX/[[GPUDirect Storage]]/OBJ/MoonCake/HF3FS の5種を提供し、フレームワーク側はバックエンド選択を意識しなくてよい抽象化を志向する。しかし、GDS の性能特性を単独で系統評価した本ソースは、GDS が推論のような細粒度・KV キャッシュアクセスパターンには不向きであることを定量的に示しており、NIXL のようなバックエンド抽象化層の下でも「粗粒度のコールドスタート/モデルロードには GDS、KV キャッシュのようなオンデマンド細粒度アクセスには CPU 仲介パス」という使い分けが性能上望ましい可能性を示唆する。(Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]]、[[NIXL]]) ## 未解決の問い - 論文が提案する静的なフェーズ別データパス選択ポリシーを、ブロックサイズ・キュー深度・GPU ストール・CPU 余裕といったリアルタイム信号に基づいて動的に切り替えるランタイム制御は、実際にどの程度の追加利得をもたらすか。 - GDS 向けにテンソルシャード・チェックポイントのデータレイアウトを co-design(デバイス/GPU ページサイズへの整列、DMA セーフな圧縮等)した場合、64 KB 未満の細粒度アクセスでも GDS の優位性を確保できるか。 - 本評価はノードローカル・単一ノードに限定されている。分散訓練・推論(NIXL・NVMe-oF 等を介したノード間データパス)において、同じ「粗粒度は GDS 有利・細粒度は CPU 仲介パス有利」という骨格はどこまで成立するか。ネットワーク層のオーバーヘッドが加わることで閾値は変化するか。 - CXL や GPUDirect RDMA など新興のメモリ/I/O ファブリックの登場によって、本研究が識別したブレークイーブン点(64 KB 前後、8 GPU 前後の CPU 飽和点)はどう移動するか。 - KV キャッシュオフロード([[NIXL]] の GDS バックエンド)のような「推論だが粗粒度になりうる」アクセスパターン(バッチ処理・プリフェッチ)は、本研究の「推論=細粒度」という一般化からどの程度外れ、GDS が有利になる領域はあるか。 ## 関連 - [[GPUDirect Storage]] — 本概念が扱う4データパスのうち、事前学習・ファインチューニングで優位な GPU 直接転送技術 - [[NIXL]] — GDS をバックエンドの1つとして利用する LLM 推論向け KV キャッシュ転送ライブラリ - [[GPU最適化]] — カーネルレベルの GPU 最適化技術群(本概念はストレージ側のボトルネックに焦点を当て、GPU 最適化はカーネル内計算最適化に焦点を当てる点で相補的) - [[GPUクラスタ運用]] — GPU クラスタの運用・障害・ワークロード動態(本概念はストレージ I/O という単一のリソース軸に特化) - [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]] — 本概念の一次ソース ## 出典 - [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]](§2.2 データパス定義、§3.2 推論、§3.3 事前学習、§3.4 ファインチューニング、§3.5 チートシート)