GPUストレージIOデータパス - yuuk1's Digital Garden

## 定義 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]]) - **「ホストメモリコピーを排除する」という同一の設計目標に対し、業界は「カーネル統合による汎用直接パス」（GDS）と「専用ファイルシステムによるキャッシュ完全排除」（3FS）という異なる解法へ収束している**: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 5 GPU-Based Storage IO Optimizations]] は、[[GPUDirect Storage]] が既存の並列ファイルシステム(BeeGFS・WekaFS・VAST等)にカーネルレベルで統合することで汎用性を確保する一方、DeepSeekの[[3FS]] はページキャッシュそのものをゼロから排除する専用実装によって、68ノードクラスタで6.6TB/s(同等ハードウェアのCephの約1.1TB/sの約6倍)という極端な集約スループットを達成したと報告する。POMACS論文が示す「GDSは粗粒度シーケンシャルで優位・細粒度ランダムで劣位」という非対称性は、3FSが「AIワークロードは大量のランダム読み取りを行い、かつ従来型キャッシュはそれに対し逆効果になる」という正反対の前提からファイルシステムをゼロ設計した動機と整合しており、両ソースを合わせると「ランダム読み取り耐性」がGPU向けストレージ設計における中心的な設計変数であることが浮かび上がる。(Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]]、[[@2025__OReilly__AI Systems Performance Engineering - Chapter 5 GPU-Based Storage IO Optimizations]]) - **gdsioによる実測(+20%)とVAST Dataの実運用報告(A100で20%・H100で30%超)は、POMACS論文の「大規模シーケンシャル転送でGDSが優位」という主張と方向は一致するが、改善幅の桁は一致しない**: POMACS論文はGDSがメディア律速スループット上限に到達すると報告する一方、書籍(ch.5)の実測例はCPU仲介パス自体が8.0GB/sとすでに高いベースラインを持つ環境での相対的改善(+20%)を報告しており、絶対的なスループット上限と相対的な改善率のどちらで語るかによって「GDSの効果」の印象が変わりうる。ベンチマーク条件(IOサイズ・キュー深度・NIC世代)の違いが改善幅のばらつきの主因と考えられる。(Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]]、[[@2025__OReilly__AI Systems Performance Engineering - Chapter 5 GPU-Based Storage IO Optimizations]]) ## 未解決の問い - 論文が提案する静的なフェーズ別データパス選択ポリシーを、ブロックサイズ・キュー深度・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 が有利になる領域はあるか。 - [[3FS]] のような「キャッシュを完全排除する専用ファイルシステム」アプローチと、GDS のような「既存並列ファイルシステムへのカーネル統合」アプローチは、どのような組織規模・運用コスト条件で使い分けが正当化されるか。3FS の6.6TB/sという極端な数値はDeepSeek固有のハードウェア・運用投資にどの程度依存しており、一般組織で再現可能な範囲はどこまでか。 - gdsio等のマイクロベンチマークが示す相対的改善率(+20%前後)と、POMACS論文が示す絶対的スループット上限到達という2つの評価軸は、実運用上どちらがより意思決定に有用か。両者を統一的に比較できる標準的なベンチマーク手法は存在するか。 ## 関連 - [[GPUDirect Storage]] — 本概念が扱う4データパスのうち、事前学習・ファインチューニングで優位な GPU 直接転送技術 - [[NIXL]] — GDS をバックエンドの1つとして利用する LLM 推論向け KV キャッシュ転送ライブラリ - [[3FS]] — キャッシュを完全排除する専用ファイルシステムによる代替アプローチ。GDSとは異なる経路で同じ「ホストメモリコピー排除」を実現する - [[GPU最適化]] — カーネルレベルの GPU 最適化技術群(本概念はストレージ側のボトルネックに焦点を当て、GPU 最適化はカーネル内計算最適化に焦点を当てる点で相補的) - [[GPUクラスタ運用]] — GPU クラスタの運用・障害・ワークロード動態(本概念はストレージ I/O という単一のリソース軸に特化) - [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]] — 本概念の一次ソース - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 5 GPU-Based Storage IO Optimizations]] — GDS実測(gdsio・VAST Data)と3FSの詳細を追加した実務書ソース ## 出典 - [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]](§2.2 データパス定義、§3.2 推論、§3.3 事前学習、§3.4 ファインチューニング、§3.5 チートシート) - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 5 GPU-Based Storage IO Optimizations]](§Using NVIDIA GDS, §Measuring GDS with gdsio, §DeepSeek's Fire-Flyer File System)