GPUがSSDを直接読む仕組み｜cuFileオープンソース化とローカルAIでモデルロードが速くなる条件

cuFileとは、GPUがストレージを直接読み書きするAPIである。

2026年8月、サンタクララで開かれたFMS 2026でNVIDIAがcuFileのオープンソース化を発表しました。コードはGitHubの新組織XIO-SIGに置かれる予定で、founding maintainerにはGoogle、Intel、Meta、NVIDIAが名を連ねています。「GPUがSSDを直接読む」と聞けば、ローカルLLMの起動が速くなるのでは、と期待したくなるところ。ただし発表の文脈はデータセンターの推論サービングで、家庭のGeForce機に効くとは書かれていません。何が省かれる経路なのか、どんな条件でだけ意味を持つのかを整理します。

この記事の要点

cuFileはCPUのシステムメモリを介さずGPUメモリとストレージを直結させるAPI。FMS 2026でオープンソース化が発表されたが、2026年8月8日時点でコード本体はまだ公開されていない
省けるのはCPUの中継とシステムメモリへの一度のコピー。効くのはこの中継コピーが所要時間の上限を作る局面で、1操作あたりの固定費が効く512バイト級の大量発行はGPU自身が要求を出すSCADA側の領域
公式ドキュメントの対応要件はTesla / Quadro系のGPU＋Linux＋限定されたファイルシステム。ファイルシステム等のGDS経路要件を欠けばcompat modeでPOSIX経由の従来経路に戻る。GeForceは直読の対応リスト外だが、Linux上ではcompat modeとして動きうる（通り道は従来と同じ）

cuFileとは：GPUがSSDを直接読むためのAPI
従来の経路で何が省かれるのか｜CPU経由がボトルネックになる条件
1. 大きな1回の読み出しと、小さな無数の読み出し
SCADAとStorage-Next｜GPUがI/Oを自分で管理する方向づけ
ローカルAIでモデルロードが速くなる条件、ならない条件
1. GDS経路の前提が揃わないとCPU経由に戻る
2. 起動時のモデルロードと、推論中の細かい読み出しは別の話
GPUの外側の条件が処理内容そのものを変える例
どちらがボトルネックかを切り分ける手順
まとめ
よくある質問
参考資料

cuFileとは：GPUがSSDを直接読むためのAPI

cuFileは、ホストCPUのシステムメモリを経由せずにストレージとGPUメモリの間で直接データをやり取りするためのAPIです。NVIDIAのGPUDirect Storage（GDS）を構成する中核部品で、アプリケーションは cuFileRead / cuFileWrite を呼ぶことでGPUメモリを読み書きの宛先に直接指定できます。

従来のGPUストレージ読み出しは、基本的にホストCPUを通っていました。ファイルシステムを管理し、コマンドを発行し、データを返すのはCPUの役目。ストレージから届いたデータはいったんシステムメモリのバッファに置かれ、そこからGPUメモリへコピーされる、という二段構えでした。cuFileが変えるのは、この「データがどこを通るか」の1点。コマンドを出すのはホストCPUのままで、データだけがシステムメモリを中継せずGPUメモリへ向かいます。

今回の発表で公開対象になったのは、cuFile単体ではなくサポートするソフトウェアスタック一式です。XIO-SIG（Accelerated IO Special Interest Group）の公式プロフィールには、cuFileのほか適合性検証のcuFileConformance、libxFile、xioLinuxの4リポジトリを置く計画が示されています。2026年8月8日時点で公開されているのは組織プロフィール用の .github のみで、コード本体は未公開。公式READMEは、founding memberが各層の統合と検証を終えコミット体制を整えた段階で各リポジトリにコードが現れる、としています。つまり「今日からGitHubで読める」段階ではありません。

もうひとつ押さえておきたいのが、この記事の射程です。どのSSDを買うか、RAMを何GB積むかといった購入選定はローカルAIのSSD・メモリ選びは「どこに効くか」が重要｜VRAMとの役割分担を見極めるで扱っています。ここで扱うのは経路そのものの機構と、それが効く条件・効かない条件だけ。買い物の判断材料ではなく、手元の環境で何がボトルネックになっているかを見極めるための地図にあたる範囲です。

従来の経路で何が省かれるのか｜CPU経由がボトルネックになる条件

ホスト経由のI/Oモデルとは、ストレージ要求の発行と管理をCPUが担い、GPUとストレージ／ネットワーク間の転送もCPUが開始する方式です。CUDAには非同期実行やキューイングがあるので、カーネルの終了ごとにCPUへ律儀に戻るような逐次動作になるとは限りません。それでも、要求を出す主体がホスト側にあり、カーネル起動とCPU-GPU間の同期がそのたびに要るという構造は変わりません。

1操作あたりのコストは、カーネル起動とCPU-GPU間の同期にかかるマイクロ秒単位のオーバーヘッドです。ここが肝心な点で、StorageReviewの報道は、このオーバーヘッドは大きなまとまった転送（bulk transfers）では無視できる、と明記しています。数GBのファイルを一気に読むような場面では、マイクロ秒の往復が数回増えても全体の所要時間はほとんど動きません。

問題が表面化するのは細粒度の操作を大量にさばくとき。512バイト単位の操作を毎秒数百万回処理するような世界では、1回あたりマイクロ秒の固定費が積み上がって全体を押さえ込みます。同報道によれば、SCADAを使った検証で1台のサーバーが512バイトのランダムリードを毎秒2億3000万回記録し、これは3基のPCIeスイッチ配下に置いた44台のGen6 SSDを3枚のH100で駆動した構成で、ドライブ定格のおよそ95%に相当するとのこと。この桁は、SCADAがデータセンター規模の同時アクセスを前提にした設計であることを示しています。

CPU経由＝常に遅い、ではありません。オーバーヘッドが効くかどうかはアクセスパターン次第で、1回あたりの転送サイズが大きいほど固定費の比重は下がります。「直読に変えれば速くなる」と一般化しないこと。

大きな1回の読み出しと、小さな無数の読み出し

同じ「ストレージから読む」でも、性質はまったく別物です。10GBのモデルファイルを一括で読むケースでは、ストレージから連続して読み出す部分について、SSDの帯域とファイルシステム側の能力が主要な上限候補になります。一方、512バイトのランダムリードを大量に投げるケースでは、帯域はまだ余っていて、1操作あたりの手続きコストが先に天井を作ります。

SCADAが対象にするのは、GPUから大量の細粒度I/Oを並列に発行する処理です。NVIDIAはSCADAを scaled, accelerated data access の略とし、大規模なAIデータセットからアプリケーションに必要な分だけをGPU自身が直接引く枠組みだと説明しています。代表例として挙がっているのは、データセットが巨大な一方で1件あたりの演算量が小さい処理、つまりGNN（グラフニューラルネットワーク）の学習やRAG、ベクトル検索といった領域です。推論サービングでも、長い文脈を扱う推論でKVキャッシュをストレージ階層へ退避・再取得する場合には同じように細かなアクセスが生じます。生成済みトークンに対応するキャッシュを大量の小さな単位で出し入れするため、そこにストレージが絡むとアクセス回数が跳ね上がるからです。ただしKVキャッシュはあくまで並ぶ例のひとつで、SCADAをKVキャッシュ専用の技術と捉えるのは適切ではありません。一方でcuFileが効くのは、中継コピーが上限を作る大きな転送の側です。ローカルAIで起きている「起動時にモデルを1回読み込む」という動作とは、性質が違うと理解しておくと後の判断が楽になります。

SCADAとStorage-Next｜GPUがI/Oを自分で管理する方向づけ

SCADAは、GPU間通信で使われてきたNVSHMEMの方式をストレージへ適用した仕組みです。NVSHMEMではデバイス側のコードが転送を自分で開始し、計算と重ね合わせられるため、GPU間のやり取りからホストの関与を外せるようになりました。SCADAはこれをストレージ側に持ち込み、GPU自身がストレージ要求を組み立て、完了処理も自分で扱う形にしています。同時に飛ばせる操作は数十万件規模、というのが報道されている設計方針です。

CPUがストレージのクライアントだった前提を、GPUがクライアントである前提に置き換える。そう言い切ると乱暴に聞こえますが、業界側の動きもその方向で揃いつつあります。NVIDIAが2024年末に立ち上げ、GTC 2025でも公に説明していたStorage-Nextは、2026年にはDDN、KIOXIA、Micronをはじめとするストレージ／フラッシュベンダー40社超に加え、コントローラメーカー、冷却の専門企業、標準化団体が参加する規模へ広がっています。「CPUではなくGPUがクライアントであるとき、ストレージデバイスはどう振る舞うべきか」を共同で定義する枠組みです。

ここまでの整理を表にまとめます。

経路	コマンドを出す主体	データの通り道	得意なアクセス形状	現時点の主な適用先
ホスト経由（従来）	ホストCPU	SSD → システムメモリ → GPUメモリ	大きなシーケンシャル読み出し	一般的なPC・既存アプリ全般
GPU直読（cuFile / GDS）	ホストCPU	SSD → GPUメモリ	中継コピーが上限を作る大量データの読み出し	データセンターの学習・推論サービング
SCADA	GPU自身	SSD → GPUメモリ	細かい読み出しの大量発行	データセンターの学習・推論（GNN・RAG・ベクトル検索など）
compat mode（フォールバック）	ホストCPU（POSIX pread/pwrite）	SSD → システムメモリ → GPUメモリ	従来経路と同じ	cuFileは動くがファイルシステム等のGDS経路要件を欠く環境。GDS modeの対象外であるGeForceも、現行のRelease Notesでは compatibility mode 扱いで、Linuxならここに入りうるが通り道は従来のまま。GPU世代ごとの可否は、使用するCUDA / GDS版のSupport Matrixで確認する。cuFile / GDSの公式サポート対象はLinuxで、Windowsは対応環境に含まれない

表の最終行にあるcompat modeが、消費者向け環境を考えるうえで効いてきます。cuFile対応のコードを書いても、GDS経路側の要件が揃わなければ動作は従来経路と同じ。APIの呼び出し形が変わるだけで、データの通り道は変わりません。

ローカルAIでモデルロードが速くなる条件、ならない条件

GPU直読でモデルロードが速くなるのは、CPU側の中継とメモリコピーが所要時間の主因になっている場合に限られます。逆に言えば、その主因でないなら経路を変えても数字は動きません。

まず対応要件から。NVIDIAのGPUDirect Storage Installation and Troubleshooting Guideには、対応GPUについてこう書かれています。

GDS is supported only on NVIDIA graphics processing units (GPU) Tesla® or Quadro® models that support compute mode, and a compute major capability greater than or equal to 6.
— NVIDIA GPUDirect Storage Installation and Troubleshooting Guide（2026年8月時点）

対象はTesla / Quadro系、つまりデータセンター向けとプロフェッショナル向けの製品です。GeForceは対応リストに含まれていません。加えて動作環境はLinux（Ubuntu、RHEL、SLES、Rocky等）で、x86_64のほかGrace系のarm64も公式対応。IOMMUについても iommu=off が最良、一部プラットフォームでは iommu=pt が対応、と設定レベルの条件が並びます。ファイルシステム側はEXAScaler、WekaFS、IBM Spectrum Scale、BeeGFS、NVMe/NVMe-oF、VAST、NFSoRDMAのほか、ローカルNVMe上のEXT4 / XFSも対象です。WindowsのGeForce機でローカルLLMを回している構成は、この要件表のどこにも当てはまりません。

GDS経路の前提が揃わないとCPU経由に戻る

GDS経路の要件を満たさない場合の挙動は、公式ドキュメントに定義されています。cuFileには互換動作の仕組みがあり、cuFileRead と cuFileWrite はそれぞれPOSIXの pread / pwrite を使い、いったんシステムメモリへ読み込んでからGPUメモリへコピーする。これがcompat modeです。compat modeは、ファイルディスクリプタが直接アクセスを使えないときなどにフォールバックとして選ばれるほか、公式ドキュメントには設定ファイルと環境変数でI/O全体をcompat modeへ強制する方法も記載されています。

つまり「cuFile対応と書かれたソフトを入れれば速くなる」という関係は成立しません。対応GPU、対応OS、対応ファイルシステムが揃って初めて直読が働きます。ただし要件を欠いたときの落ち先はひと通りではありません。ファイルシステムやディストリビューションが非対応、nvidia-fs が読み込めない、BAR領域が露出していないといったGDS経路側の条件を満たさない場合は、compat modeが有効ならPOSIXの pread / pwrite を使うCPU経路へフォールバックします。一方、GPUの側は扱いが別です。公式には CU_FILE_DEVICE_NOT_SUPPORTED（GDS is not supported on the current GPU）というエラーコードが定義されており、ファイルシステムの問題ではなくGPUの問題として返る場合があります。互換動作に入れるかどうかを分けるのは直読の対応リストではなくGPU側の条件です。現行のRelease Notes は GDS mode の対象GPUを挙げたうえで、それ以外のカードは compatibility mode のみ対応としています。直読の対応リスト外であるGeForceもここに含まれるため、Linux上では互換動作として動きうる。ただし通る道は従来と同じです。なお compute capability の下限は公式文書間で表記に幅があるので、GPU世代ごとの可否は使用するCUDA / GDS版のSupport Matrixで確認してください。導入＝高速化ではない、という一点は最初に固定しておきたいところ。

起動時のモデルロードと、推論中の細かい読み出しは別の話

ローカルLLMの起動時ロードは、数GB〜十数GBのGGUFファイルを読む処理です。1操作あたりの固定費という軸では、大きなシーケンシャル読み出しは報道が「無視できる」と言っている側にあたります。cuFileが省くもう一方＝システムメモリを経由するコピーについては、NVIDIA公式が大きな転送でも改善を示しているので、そちらまで否定されているわけではありません。ただしSSD1台で数GB〜十数GBを読む一般的なモデルロードでは、ドライブ側の帯域が支配的になりやすいところです。しかもモデルが空きメモリに収まる範囲ならLinuxやWindowsのページキャッシュが効くため、2回目以降のロードはディスクをほとんど触らずに終わります。ここに直読を持ち込んでも、削れる時間は限られます。

そしてロードが終わったあと、必要な重みがRAMやVRAMに収まっている状態での定常的な生成速度は、主に演算性能とメモリ帯域、そしてVRAMへの配置で決まります。当サイトの検証環境（RTX 5080単体・think=false統一・各3回のIQR外れ値除外後の中央値）では、qwen3-coder:30bが73.7 tok/s（2026年7月30日・Ollama 0.32.3）、qwen3.6:35b-a3bが67.7 tok/s（2026年6月18日・Ollama 0.30.7）でした。いずれもGPU常駐が100%未満で一部がCPU側に載った状態の値で、qwen3-coder:30bが74%、qwen3.6:35b-a3bが62%です。全層をVRAMに載せられればこれより上振れします。これらの数値を決めているのはVRAMに全層が載っているかどうかと演算・帯域側の条件で、モデルファイルをどう読んだかは、基本的には生成中の速度に現れません。ただし例外があります。Ollama が GGUF モデルの実行に使っている llama.cpp は、既定でモデルを mmap し、必要な部分をオンデマンドで読み込みます。モデルが総RAM量を超える構成や空きメモリが少ない環境では、推論中にページフォルトやページインが発生し、ストレージ側の速度が生成中のtok/sにも効いてきます。この例外を除けば、ローカルAIの体感を左右する部分の大半はストレージの外側にあります。

結論として、現時点で語られているcuFile / SCADAはデータセンター側の学習・推論を前提にした技術です。消費者向けの一般的な構成で体感が変わるものとして提示されているわけではありません。ローカル環境でモデルの起動が遅いなら、原因はストレージ経路よりも、VRAMに収まらずCPUオフロードが発生している、あるいは初回ロードでディスクから素直に読んでいるだけ、という可能性の方が高いと考えられます。この見極めをする前にハードを買い替えると、費用だけが増えます。ローカル実行そのものの前提から確認したい場合は、姉妹サイトのローカルLLMとは？Ollama × Gemma 4でコードを外に出さず使うAI環境を初心者向けに解説が入口として使えます。

GPUの外側の条件が処理内容そのものを変える例

GPU本体の演算性能ではなく、その外側にある容量や経路が処理の中身を決めてしまう場面は、実装レベルで存在します。ストレージ経路の話も同じ層の議論です。

MarkTechPostが公開したLingBot-Mapのチュートリアルが分かりやすい例。画像や動画のシーケンスから一貫性のある3Dシーンを構築するストリーミング3D再構成パイプラインの実装ガイドで、処理を始める前に利用可能なGPUを調べ、検出したVRAM容量に応じてフレーム上限、カメラ反復回数、スケールフレーム、KVキャッシュのパラメータを自動で調整する構成になっています。使われているのはストリーミングアテンションと長距離軌跡メモリを持つGCTStreamモデル。推論は混合精度で行い、予測されたカメラ姿勢と内部パラメータをデコードし、深度マップを世界座標系のポイントクラウドへ変換して、PLY / NPZ / GLB形式で書き出す流れです。

注目したいのは、VRAM容量が「動くか動かないか」だけでなく「何フレーム処理するか」「カメラ推定を何回繰り返すか」という処理内容そのものを切り替えている点。容量が足りなければ品質を落として通す、という判断がコードの中に組み込まれています。同じ入力を与えても、GPUが変われば出てくる結果の緻密さが変わるわけです。

ストレージ経路も構造は同じで、GPUの外側にある条件が中身の挙動を規定します。カタログのCUDAコア数やVRAM容量だけを見ていると、この層の差は見えません。ローカルAIの環境を組むときに、演算性能とは別軸で「データがどこからどう届くか」を確認する意味はここにあります。

どちらがボトルネックかを切り分ける手順

手元の環境でストレージ経路が問題かどうかは、モデルロード中のCPU使用率、初回と2回目のロード時間差、そしてストレージの読み出し帯域の3点を見れば概ね判別できます。

前提を先に書いておくと、この経路について当サイトは計測していません。GPUDirect Storageの対応要件を満たす構成を持っておらず、GeForce＋Windows環境で直読と従来経路を比べた数値は取っていない。したがって「何倍速くなる」といった数字は本記事では出しません。代わりに、読者自身が手元で確認できる観測項目を示します。

Ollamaを使っているなら、APIのレスポンスに含まれる load_duration が起点になります。モデルを一度アンロードしてから同じリクエストを2回投げ、1回目と2回目の値を比べる方法です。

# 常駐状態を確認し、対象モデルを解放する
ollama ps
ollama stop qwen3-coder:30b

# 1回目を測る（ollama stop はVRAM/RAM上のモデルを解放するだけで、OSのページキャッシュは残る）
curl http://localhost:11434/api/generate -d '{"model":"qwen3-coder:30b","prompt":"hi","stream":false,"keep_alive":0}'

# keep_alive:0 で即座に解放されるので、続けて2回目を測る
curl http://localhost:11434/api/generate -d '{"model":"qwen3-coder:30b","prompt":"hi","stream":false,"keep_alive":0}'

上のコマンドはPOSIXシェル（Linux / macOS / WSL）向けです。PowerShellはPOSIXシェルではありませんが、7.3以降の新しいネイティブ引数渡しを前提にすれば利用できます。Windowsのコマンドプロンプトや Windows PowerShell 5.1、PowerShell 7.0〜7.2 ではJSONの引用符の扱いが異なるため、curl.exe を明示して適切にエスケープするか、WSL か PowerShell 7.3以降から実行してください。また keep_alive:0 を付けないと、Ollama は既定でリクエスト後5分モデルを保持するため2回目はロード自体が起きず、load_duration は比較対象になりません。なお本当のコールドリードを見たいならOS側のキャッシュも落とす必要があります（Linuxなら sync; echo 3 | sudo tee /proc/sys/vm/drop_caches、Windowsなら再起動が確実）。キャッシュを落とした状態の値と、その直後にもう一度測った値を比べて、後者が大きく縮むなら初回はストレージから素直に読んでいて、2回目はOSのキャッシュに助けられている状態です。2回とも同じくらい遅い場合は、まず空きメモリがモデルサイズを上回っているかを確認します（Linuxでは単純な空き容量より MemAvailable を見ます。回収可能なキャッシュ分は free とは別に管理されているためです）。モデル全体を保持できるだけのメモリ余裕がなければ、ページキャッシュの効果は限定されます。ページキャッシュはファイル単位ではなく読んだページ単位で保持・回収されるため、一部のページが回収されれば、2回目以降でもその部分だけがストレージから再読込されます。「モデルサイズが空きRAMを超えたら毎回全量をディスクから読む」とは限りません。この場合、2回とも遅いこと自体が読み出し側の症状になりえます。空きが十分にあるのに縮まないなら、そこで初めて読み出し以外の要因を疑う番です。なおこのフィールドはOllamaが返す計測値なので、内訳を「ディスクからの読み込み時間」と断定はできません。キャッシュの効き方やメモリ割り当ての状況で中身は変わります。

ロード中の負荷側は、CPU使用率とGPUの状態を並べて眺めるのが手っ取り早い方法です。

# ロード中のVRAM使用量とGPU使用率を1秒ごとに記録する
nvidia-smi --query-gpu=name,memory.used,utilization.gpu --format=csv -l 1

CPUの1コアが張り付いているなら、CPU側で直列に走っている何か（中継コピー、量子化の展開、チェックサム）が効いている状態です。この形だけでは中継と展開の区別は付かないので、同時にディスクの読み出し帯域が出ているかを併せて見ます。帯域がSSDの実力に届いていないなら読み出し経路側を疑う手がかり、CPU・ディスクとも余裕があるのに時間がかかるならGPUへの転送やモデルサイズそのもの、という順で絞れます。ただし読み出し帯域が低いこと自体は、CPU側の処理が詰まって生じるバックプレッシャーでも起こるため、ここは切り分けの入口にとどめます。なお中継が主因だと分かっても、GeForce＋Windows構成に直読という選択肢は現時点でありません（前節の対応要件）。加えて ollama ps のPROCESSOR表示でCPUオフロードが起きていないかも確認してください。VRAMに収まらず一部がCPU側に載っている状態なら、ストレージの話をする前にそちらが先です。

比較するときは条件を揃えるのが前提。同じモデル・同じ量子化・同じランタイムのバージョンで測らないと、数値の差がどこから来たのか判別できなくなります。ランタイムを更新した直後の値と、更新前の値を並べても意味を持ちません。

発表の場	FMS 2026（サンタクララ、2026年8月）
公開形態	cuFileと関連スタックをGitHubのXIO-SIG組織で公開（2026年8月8日時点でコード本体は未公開、統合・検証後に公開予定）
参画している組織	founding maintainerはGoogle・Intel・Meta・NVIDIA／Storage-Nextには40社超が参加
当サイトでの検証状況	この経路は未検証（対応要件を満たす構成を保有していないため数値は掲載せず）
結論の一言	効くのはCPUの中継とメモリコピーが上限を作るI/O。512バイト級の細粒度はSCADA側の領域で、消費者向けGeForce＋Windows構成は現時点で対応要件外

まとめ

経路を変えて意味が出るのは、CPUの中継とシステムメモリへのコピーが所要時間の上限を作っているときです。SSD1台で数GB〜十数GBを一括で読む起動時ロードなら、ドライブ側の帯域が支配的になりやすく、中継を省いても縮む余地は小さい。1操作あたりの固定費のほうが効いてくるのは、512バイト級の読み出しを毎秒数百万回さばく世界で、そこは前述のSCADAが狙う領域です。しかもモデルが空きメモリに収まる範囲なら2回目以降はOSのページキャッシュが効くため、直読で削れる余地はさらに狭まります。

仮に効く形のI/Oを扱っていても、要件の壁が残る。公式ドキュメントが挙げるのはTesla / Quadro系のGPU、OSはLinux。ファイルシステムは分散ストレージのほかローカルのEXT4 / XFS（ローカルNVMe上）も対象ですが、消費者向け構成で先に外れるのはGPUとOSの側です。cuFileが動く環境でも、ファイルシステム等のGDS経路要件を欠けばcompat modeへ落ち、APIの呼び方が変わるだけで通り道は従来のまま（互換動作に入れるかどうかはGPU側の条件で決まります。GPU世代ごとの可否は、使用するCUDA / GDS版のSupport Matrixで確認してください）。GeForce＋Windowsでローカル LLMを回している構成は、この要件表のどこにも入りません。なお当サイトはこの経路を未検証で、倍率の数字は本記事では出していません。

手を動かす順番は3段です。まず ollama ps のPROCESSOR表示、次に load_duration の初回と2回目の比較、最後にロード中のCPU使用率とディスクの読み出し帯域。CPUオフロードが出ていればVRAM側、キャッシュを落とした初回だけ遅ければ素直な読み出し、CPU・ディスクとも余裕があるのに時間がかかるならGPUへの転送やモデルサイズそのものを疑う番。ただし空きメモリがモデルサイズに届かない構成ではページキャッシュの効果が限定され、回収されたページだけがストレージから再読込されます（全量を読み直すわけではありません）。2回とも遅いことが、そのまま読み出し以外の症状だとは限りません。ハードを買い替えるのは、この切り分けを終えてからで間に合います。

よくある質問

Q. cuFileとGPUDirect Storageは何が違う？

GDSはGPUがストレージを直接読み書きするための仕組み全体を指し、cuFileはその中核となるAPIです。アプリケーション側は cuFileRead / cuFileWrite を呼び、GPUメモリを読み書きの宛先として直接指定します。GDSという枠組みに対する入口の部分がcuFile、と捉えると関係が整理できます。

Q. 公開されたコードはもうGitHubで読める？

2026年8月8日時点では未公開です。置き場所はXIO-SIG（Accelerated IO Special Interest Group）という新組織で、公式プロフィールにはcuFileのほかcuFileConformance、libxFile、xioLinuxのリポジトリを置く計画が示されています。founding memberによる統合と検証が終わってから出るとされています。

Q. すべてのI/Oを強制的にcompat modeで動かせますか？

できます。公式ドキュメントには、設定ファイルの項目と環境変数のどちらからでもI/O全体をcompat modeへ倒す方法が記載されています。明示的に指定しない場合は、ファイルディスクリプタが直接アクセスを使えないときなどにフォールバックとして選ばれる動作です。中身はPOSIXの pread / pwrite でシステムメモリへ読み込み、そこからGPUメモリへコピーする流れになります。