利用 NVIDIA GPUDirect Storage 技術，最大化您對用於 AI/ML 工作負載的美光 SSD 投資
導言
在美光，我們對人工智慧（AI）推動的巨大創新感到無比興奮。為此，我們一直在積極探索快閃記憶體對這一新型應用的影響，以及如何利用其他令人驚歎的技術（包括硬體和軟體），透過 AI 加速創新。
最近，我有機會在實驗室試用了 NVIDIA GPUDirect Storage 軟體的早期版本，結果令人印象深刻。不過，在深入瞭解結果之前，我想先簡單介紹一下背景。
自 2007 年以來，NVIDIA CUDA 已實現了對許多不同運算任務的 GPU 加速處理。隨著 2014 年 GPUDirect RDMA 的推出，NVIDIA 實現了 GPU 與各種 PCIe 介面卡（如網絡介面卡、儲存控制器和視訊捕捉裝置）之間的直接資料傳輸。GPUDirect Storage 在 GPUDirect RDMA 和 CUDA 的基礎上進行擴充，支援將資料從儲存裝置（例如 NVMe SSD）直接傳輸到 GPU 記憶體空間。這一更新實際上取消了將資料傳輸到 CPU 系統記憶體（用於 I/O 緩衝）的步驟，這是舊有儲存裝置 I/O 配置所需的步驟（圖 1）。
圖 1：有無 GPUDirect Storage 的資料路徑對比
然而，直到最近，許多標準資料科學庫還缺少 GPU 加速。事實上，最常用的 Python 資料科學庫（NumPy、Pandas、 scikit-learn）都沒有原生 GPU 加速，有些甚至制定具體計畫，不研發此類加速。
雖然其他資料科學庫也在尋求以與 Pandas、NumPy 和 scikit-learn 相容的方式啟用 GPU 支援，但直到現在還沒有一套全面的支援 GPU 的資料科學庫。隨著基於 CUDA 的 RAPIDS 開放原始碼軟體庫的推出，我們現在有了一套開放原始碼庫和 API，能夠完全在 GPU 上執行端到端的資料科學和分析管道。
由於這些新的 GPU 加速 RAPIDS 庫和其他庫的運算效能是非加速庫的數倍，我們發現儲存 I/O 正成為瓶頸，而 GPUDirect Storage 的設計正是為了幫助消除這一瓶頸。
雖然從邏輯上講，這個問題很容易解決（NVMe 硬碟、NIC 和 HBA 都有 DMA 引擎，可以支援將資料直接傳輸到 GPU 記憶體位址），但實際執行起來卻有點複雜。我建議您參考 NVIDIA 的部落格與企業通訊，特別是關於 GPUDirect Storage 的介紹部落格，以瞭解更多資訊。此外，雖然 RAPIDS 是 GPUDirect Storage 的特定用例，但這只是許多可能的實作之一。
現在，讓我們在真實系統上進行一些實際測試，瞭解 GPUDirect Storage 如何提高效能。
測試組態
在此進行的所有測試中，我使用的是搭載 8 個 NVIDIA V100 GPU、2 個 Intel Xeon 8180M CPU（每個 28 核心）和 8 個美光 9300 Pro 15.36TB NVMe SSD 的 SuperMicro SYS-4029GP-TVRT。圖 2 顯示系統的具體佈局。
圖 2：SuperMicro SYS-4029GP-TVRT 的 PCIe 佈局
我們測試中使用的伺服器有一個有趣的架構特徵，即 NVMe SSD 直接連接至 CPU。與本地 NVMe 相比，此特定系統使用遠端儲存（例如透過 NVMe over Fabrics 訪問）以獲得更好的吞吐量。為什麼？ 用於 NIC 的 PCIe 通道是用於 NVMe 硬碟的兩倍。由於 GPUDirect Storage 使用 DMA 將資料從儲存裝置直接傳輸到 GPU，因此它也可以使用 RDMA 和 NVMe-oF。如果更高效能的網絡介面透過通用 PCIe 交換器訪問這些裝置，那麼比起直接透過 CPU 連接這些儲存裝置（如本伺服器所要求的），我們將可以傳輸更多資料。我們計劃在未來探索 GPUDirect Storage 的效能，即透過連接與 GPU 相同的 PCIe 交換器的網絡轉接器訪問遠端儲存裝置，但此處的資料僅討論本地 NVMe。
效能結果
4KB 隨機讀取效能
我們從典型的 4KB 隨機讀取工作負載開始。在這項測試中，每個 GPU 從美光 9300 NVMe SSD 上的 1TB 檔案中讀取資料。這是一對一的關係——每個 GPU 只從一個 NVMe 硬碟讀取資料。這種關係並不一定是生產系統的配置方式，但在實驗室中，它使測試不同數量的 GPU 和 SSD 變得更加容易。對於生產系統，您可以將單個 CPU 上的所有硬碟配置到單個 RAID 組中。
圖 3：在按 4K I/O 傳輸規模的資料路徑分配 8 個 GPU 的情況下，按每個 GPU-NVMe 對的工作線程數計算的 CPU 利用率和吞吐量
在圖 3 中，我們看到 GPUDirect Storage 與使用 CPU「回彈緩衝區」的舊有資料路徑相比，在效能上有顯著的差異。在工作線程數較少的情況下，GPUDirect Storage 路徑看起來速度稍快，但 CPU 利用率稍高。隨著工作線程數的不斷增加，我們看到 GPUDirect Storage 的優勢顯著增加。在此配置中，GPUDirect Storage 達到 8.8 GB/s 吞吐量的峰值（藍色條表示 64 個工作線程），而 CPU 利用率則維持在 6 個 CPU 核心以下（綠線，右軸）。相比之下，舊有路徑的吞吐量峰值為 2.24 GB/秒（灰色條表示 12 個工作線程），在工作線程數增加的壓力下，效能下降，CPU 利用率上升，在 96 個工作線程的情況下，CPU 利用率相當於 52 個滿載的 CPU 核心（黑線，右軸）。
資料傳輸規模對效能的影響
接下來，我們將探討資料傳輸規模對效能的影響。在這項測試中，我們使用每個 GPU-NVMe 對 16 個工作線程。根據之前 4KB I/O 測試的結果，我們選擇了 16 個工作線程，結果顯示 16 個工作線程剛剛超過舊有資料路徑的峰值，而遠遠低於 GPUDirect Storage 資料路徑的峰值。
圖 4：在按每個 GPU-NVMe 對 16 個工作線程的資料路徑分配 8 個 GPU 的情況下，按 I/O 傳輸規模計算的 CPU 利用率和吞吐量
觀察圖 4，我們發現，隨著 I/O 傳輸規模的擴大，舊有資料路徑的固有限制得到緩解。對於較大的傳輸大小，吞吐量和 CPU 利用率實際上是相等的。遺憾的是，要確保訪問儲存裝置的所有工作負載都能始終如一地使用較大的資料傳輸規模，往往具有挑戰性。因此，中小規模傳輸的情況與上述情況相同——-使用 GPUDirect Storage 時，吞吐量大幅提高，CPU 利用率也相應提高。
I/O 延遲
我們再來看看效能的另一個重要方面，即 I/O 延遲。在這項測試中，我們再次使用 16 個工作線程並擴大 I/O 傳輸規模。
圖 5：在每個 GPU-NVMe 對 16 個工作線程並按資料路徑分配 8 個 GPU 的情況下，按 IO 傳輸規模計算的延遲和吞吐量
與吞吐量和 CPU 利用率一樣，GPUDirect Storage 資料路徑的延遲在中小規模傳輸時有顯著改善，而在大規模傳輸時，與舊有資料路徑的延遲實際上相等（圖 5）。此處顯示的延遲單位為微秒 (µs)，我們看到 GPUDirect Storage 的延遲值令人驚訝。4KB 傳輸的平均延遲為 116 微秒，32KB 傳輸的平均延遲僅為 203 微秒。對於對延遲敏感的工作負載，這會對應用程式效能產生重大影響。超過 32KB 傳輸後，延遲將由傳輸資料的時間而不是資料存取負擔所主導，而較小的 I/O 傳輸則屬於這種情況。
結論
在中小區塊大小的情況下，GPUDirect Storage 可大幅增加總吞吐量、顯著減少延遲，並大幅減少所需的 CPU 核心數量。對於任何需要 GPU 加速的應用，任何一項改進都會使該項技術值得探索；而同時獲得所有這些改進標誌著 GPU I/O 領域的階躍式變革。在我的測試中，較大的資料區塊傳輸並不能帶來相同的優勢，但是與舊有資料路徑相比，使用 GPUDirect Storage 沒有不利因素。
NVIDIA 的 GPUDirect Storage 結合美光的資料中心 SSD，可加速您的 AI 解決方案，讓您在更短的時間內完成更多工作。若要瞭解美光和 NVIDIA 如何協助您成功部署 AI 解決方案，請查看這些實用資源：
