NVIDIA 技術博客出咗一篇教學，教你點樣用 Python 嘅 NVIDIA KvikIO 庫，將 NVMe 碟入面嘅數據直接讀入 GPU 顯存，並確認 GPUDirect Storage（GDS）嘅加速路徑真係激活咗。

點解要急住搞呢個

引用 2025 Stanford AI Index 嘅數據：顯著 AI 模型嘅算力大約每五個月翻倍，訓練 LLM 用嘅數據集規模大約每八個月翻倍。算力同數據一路擴張，儲層向加速器餵數據就成為瓶頸——GPU 再勁，數據供唔上就係白費。GDS 就係為咗呢個問題：喺支援嘅儲存裝置同 GPU 顯存之間開一條直達路徑，繞過 CPU 內存嘅中途暫存（staging），同時減少 CPU 整體負載。NVIDIA 話已有唔少主要儲存廠商支持呢個生態。

兩個把關要分清楚

呢個架構涉及三個組件，但真正揀路徑嘅只有兩個把關點：

  • GDS：底層技術，令支援嘅儲存裝置同 GPU 顯存之間可以直接搬數據，本身唔揀路徑。
  • cuFile：一個 C 庫同 API，就係應用層接觸 GDS 嘅入口。
  • KvikIO：NVIDIA 嘅 Python 同 C++ 庫，做高表現文件 I/O，提供較高層嘅、符合 Python 語法習慣嘅介面，並對 I/O 請求嘅執行方式有額外控制。

喺 KvikIO 呢層，有第一個把關：應用交出檔案路徑同 GPU buffer，KvikIO 揀用 cuFile 定係退返 POSIX 兼容路徑（即舊式，資料經主機內存暫存）。行到 cuFile，KvikIO 會註冊檔案，再用目標 GPU buffer 發起 I/O。

然後係 cuFile 自己嘅把關：cuFile 會根據系統支援、檔案系統同設定，決定用加速 GDS 路徑定係 CPU 暫存兼容路徑。

所以關鍵一句係呢個：行到 cuFile API，只代表 KvikIO 揀咗 cuFile，並唔代表 accelerated GDS 路徑真係開咗。 要確認加速路徑激活，需要另外用 gdscheck 同 gds_stats 等工具去查。

教學嘅測試環境

  • x86_64 系統，NVIDIA H100 GPU，CUDA 13.3，cuFile 1.18
  • 本地 NVMe 裝置，ext4 檔案系統
  • GPU 同 NVMe 之間係 PIX 連線

要求：Linux 系統、已安裝 NVIDIA GPU 同 GDS、GDS 支援嘅儲存同檔案系統設定、對儲存端點有讀寫權限、可存取 gdscheck 同 gds_stats。

Python 喺呢個堆疊入面嘅位置：以喺應用層，Python 係現代 AI 開發嘅主力語言——截至 2025 年 8 月，GitHub 上近半數新 AI 項目係用 Python 做。KvikIO 就係填補 Python 同 cuFile 之間嘅橋。

模姐驗嚇貨

呢篇教學最有價值嘅地方，係佢唔會令你以為「行到 cuFile 就搞掂」。兩層各揀各嘅路徑，KvikIO 揀咗 cuFile 唔代表 cuFile 行緊加速路徑。如果你個生產環境冇 PIX 連線、或者檔案系統唔支援，就算你行到 cuFile，最尾仲係回咗 CPU 暫存。上嘢之前先跑 gdscheck，睇清楚個路徑先講得過得。

測試環境係廠商自己披露，唔係本站實測。

模姐｜深度調教