NVIDIAがGPUメモリを読み込むPythonの経路をGPUDirectストレージで詳細に説明しています

NVIDIAは、PythonアプリケーションがMagnum IO GPUDirect Storageを使ってGPUメモリに直接データを読み込む方法や、読み取りが加速経路を使ったのかCPUステージのフォールバックを使うかを検証する方法を説明する技術ガイドを 2026-10-22 公開しました。投稿によると、この区別はKvikIOとcuFileがリクエストがストレージに届く前に別々のルーティング決定を行うためです。

経路の選択方法

NVIDIAによると、GPUDirect StorageはサポートストレージとGPUメモリ間に直接データパスを作成し、CPUメモリを使った不要なステージングを避け、全体のCPU使用率を削減します。投稿で説明したPythonスタックでは、KvikIOはcuFileの上に位置します。KvikIOはcuFileを呼び出すかどうかを決定し、cuFileはリクエストが加速されたnvidia-fsパスを使うか、ホストメモリ経由でデータを段階的に移行する互換性パスを使うかを決定します。

同社は、cuFile APIに到達しただけでは加速されたパスが使われたとは証明できないと述べています。この区別はチュートリアルの中心であり、KvikIOのデフォルトを検査し、GDSコンポーネントを gdscheck.py で確認し、gds_statsを使って操作がnvfsかposixかを判断する方法を示しています。

チュートリアルで使われたもの

NVIDIAによると、この例はH100 GPU、CUDA 13.3、cuFile 1.18を搭載したx86_64システムでテストされました。このセットアップでは、ローカルNVMeデバイスがext4フォーマットされ、GPUとNVMeデバイス間のPIX接続、IOMMUとACSが無効化され、nvidia-fsカーネルモジュールがインストールされて加速経路を提供していました。

Pythonの例では、ガイドが 1 GiBファイルを作成し、GPUメモリにCuPy配列を割り当て、そのバッファにKvikIOで読み込みます。投稿によると、KvikIOはチュートリアルシステム上でcompat_modeをAUTOとして報告し、 16 KiBのgds_thresholdとして報告されています。AUTOはKvikIOにまずcuFileを試し、cuFileが利用できない場合はPOSIXにフォールバックするよう指示しています。閾値以下の読み込みはPOSIXパスを直接使います。

cuFile統計による検証

記事によると一実際の転送パスを確認する方法はCUFILE_STATS_LEVEL=3を有効にし、gds_statsで実行中のプロセスを検査することです。チュートリアルの例では、KvikIOのデフォルトの4 MiBタスクサイズが1 GiBリクエストを256リードに分割し、統計ではn=256、nvfs=256、posix=0と示され、すべての操作がnvidia-fsパスを使用していたことを示しています。

また、設定を変更してレイヤーを比較することも投稿されています。KVIKIO_COMPAT_MODE=オフでもKvikIOはcuFileを使用し、cuFileはCUFILE_FORCE_COMPAT_MODE=trueとの互換モードに強制的に移行でき、これによりpoixの操作が移されます。KVIKIO_COMPAT_MODE=onの場合、KvikIOはcuFileを完全にバイパスし、CPUステージのPOSIXバックエンドを通じて読み込みを行います。

cuFile スケジューリングとリクエストサイズ

NVIDIAによると、cuFileはcufile.json独自の実行設定を持ち、リクエストの分割やスケジュールに影響します。これにはexecution.parallel_io、execution.max_io_threads、execution.min_io_threshold_size_kb、execution.max_request_parallelism、execution.max_io_queue_depthなどが含まれます。例の構成では、cuFileワーカースレッド四max_request_parallelism四、min_io_threshold_size_kb 8192に設定されていることで、cuFileを受け取った1 GiBの読み取りをさらに細分化できます。

ガイドによると、KVIKIO_TASK_SIZEが1 GiBに設定されている場合、KvikIOは大きなリクエストをcuFileに一送り、cuFileは宛先バッファが明示的に登録されていないため、未登録のバッファスケジューリングパスを使用します。投稿によると、この場合cuFileはリクエストを四ピース、それぞれ256 MiBに限定し、それらのピースは個別のストレージ転送ではなくスケジュールされた作業単位としています。また、16 MiBリクエストの場合は、8 MiBのスケジューリング目標が重要であり、cuFileはそれを二 8 MiBピースに分割すると述べています。

なぜNVIDIAがスタックを重視しているのか

この記事は、より大きなAIデータ移動の需要を踏まえた文脈でこのチュートリアルを位置づけており、2025スタンフォードAIインデックスによると、著名なAIモデルの計算量は約五か月ごとに倍増し、大規模言語モデルのトレーニングデータセットは約八か月ごとに倍増していると述べています。NVIDIAはまた、Pythonが多くのAIプロジェクトの主要なアプリケーションインターフェースであった一方、cuFileはCのAPIであり、KvikIOはPythonコードとストレージアクセラレーション層の橋渡し役であると述べています。

投稿によると、KvikIOはデータサイエンスのNVIDIA CUDA-Xの一部であり、加速されたParquetやORCインジェスティングに関する初期のcuDF研究にルーツを持っています。同社は、同じストレージパスがその後cuCIMのデジタル病理ワークフロー、cuPhoton xDataReader、GPUアクセラレーションのPrestoの作業にも使われていると述べていますが、チュートリアル自体はPythonの読み取りが実際に加速ルートを通ったかどうかの確認に焦点を当てています。

投稿ではすべての構成にパフォーマンス向上が割り当てられているわけではありません。代わりに、ダイレクトパスの動作は互換性のあるハードウェア、ドライバー、ファイルシステム、トポロジー、設定に依存し、サポートされていない構成は互換性モードにフォールバックできることを強調しています。NVIDIAは、ユーザーが自分のワークロードを高速化を前提にせず、gds_statsで自身のワークロードを検証すべきだと述べています。