新聞 
幣種資訊 
關於我們 
NVIDIA（輝達，$NVDA）22 日在技術部落格發布教學，說明如何用 Python 將檔案資料讀入 GPU 記憶體時，確認實際資料傳輸路徑。範例將 1 GiB 的讀取拆成 256 個請求；統計工具 gds_stats 顯示，加速路徑 nvfs 計 256 次，相容路徑 posix 則為 0 次。
作者安德魯・霍伊爾（Andrew Hoyle）表示，他在 NVIDIA GPUDirect Storage 團隊負責開發資料移動功能及軟體函式庫整合。NVIDIA 開發者論壇也於 22 日發布介紹這篇部落格的貼文。
KvikIO 選擇呼叫方式，cuFile 決定傳輸路徑
GPUDirect Storage（GDS）是一項技術，可減少支援的儲存裝置與 GPU 記憶體之間經過 CPU 記憶體的中間複製。NVIDIA 的 GPUDirect Storage 概述文件指出，直接路徑是否可用，取決於硬體、檔案系統與設定；若無法使用，系統會在相容模式下採用 POSIX 呼叫。
這篇教學的重點是，資料路徑分兩階段決定。作為 Python 與 C++ 介面的 KvikIO，會先選擇呼叫 cuFile，或使用自己的 POSIX 相容路徑。即使呼叫了 cuFile，系統仍會依支援的檔案系統、系統配置與設定，選擇以 nvidia-fs 為基礎的 GDS 路徑，或經過 CPU 記憶體的相容路徑。也就是說，指定 GPU 記憶體為目的地並呼叫 cuFile，本身不足以證明使用了 GDS 加速。
KvikIO 的 compat_mode 預設值為 AUTO。若嘗試使用 cuFile 但不可行，KvikIO 會改用 POSIX 後端。教學所用系統的 gds_threshold 設為 16 KiB；小於此門檻的讀取會直接使用 KvikIO 的 POSIX 路徑。
環境變數會改變統計結果
要確認資料路徑，可先設定 CUFILE_STATS_LEVEL=3，再使用 gds_stats。NVIDIA 展示了不同設定下統計結果的變化。
△ KVIKIO_COMPAT_MODE=off：KvikIO 使用 cuFile，統計列在 nvfs。
△ CUFILE_FORCE_COMPAT_MODE=true：仍會呼叫 cuFile，但工作會計入 posix。
△ KVIKIO_COMPAT_MODE=on：KvikIO 略過 cuFile，改走獨立的 POSIX 路徑，因此不會記入 cuFile 統計。
NVIDIA 將 gdscheck.py介紹為檢查安裝配置與支援狀態的工具；gds_stats則可顯示某個程序分別透過 nvfs與 posix處理了多少次工作。
256 個請求代表什麼
256 這個數字來自 KvikIO 預設的 4 MiB 工作大小。1 GiB 除以 4 MiB，會得到 256 個 cuFile 請求。若將 KVIKIO_TASK_SIZE改為 1 GiB，KvikIO 會向 cuFile 傳送一個大型請求，再由 cuFile 切分成四個 256 MiB 的工作單位排程。NVIDIA 說明，這些是排程單位，與個別儲存裝置的傳輸大小不同。
教學也說明，若目的 GPU 緩衝區尚未向 cuFile 註冊，資料會先複製到已註冊的 GPU 暫存緩衝區，再複製到目的緩衝區。
測試環境為 x86_64伺服器，搭載 NVIDIA H100、CUDA 13.3、cuFile 1.18，以及以 ext4格式化的本機 NVMe。GPU 與 NVMe 透過最多只經過一座 PCIe 橋接器的 PIX 方式連接。測試關閉 IOMMU 與 ACS，並載入 nvidia-fs核心模組。NVIDIA 表示，這只是教學使用的測試環境，並非所有系統都能符合的保證條件。NVIDIA 疑難排解文件建議，在其他系統上應一併檢查支援的檔案系統、驅動程式與函式庫版本、cuFile 設定及硬體連接。
KvikIO 是 NVIDIA CUDA-X 資料科學函式庫的一部分。官方程式碼儲存庫將它介紹為 cuFile 的 Python 與 C++ 綁定，也說明即使環境無法使用 GDS，仍可讀寫主機與裝置資料。關於 CUDA-X 函式庫，本刊先前曾報導NVIDIA 表示 7 月為 CUDA-X 函式庫新增代理工具。
這篇教學未涵蓋的內容
在儲存裝置方面，本刊先前曾報導美光說明，以 PCIe Gen 6 為基礎的資料中心 NVMe SSD，可降低儲存裝置與運算資源之間的資料移動限制。這次教學探討的是如何透過軟體設定與統計確認實際路徑，並未著重硬體規格。
NVIDIA 的文章及 KvikIO、GDS 官方文件均未提及虛擬資產或區塊鏈的應用案例。NVIDIA 也未提供效能提升幅度或吞吐量比較數據。nvfs=256僅代表該次執行的請求統計，不代表速度提升幅度。
留言 0