在單機 CPU/GPU 內存足以容納的數據，在規(guī)?；瘮祿媲耙呀洘o法被內存容納后，意味著每個大規(guī)模數據集的集群都需要面對大數據集的分區(qū)、緩存和節(jié)點通訊協(xié)同問題，更不用提其中的錯誤處理，意味著要像傳統(tǒng)大數據系統(tǒng)一樣構建（但完全不同的性能需求）。

 GPU 的存儲訪問

在數據訪問上，在幾年前就擁有了 GPUDirect Storage，意味著 GPU 可以直接通過 NVMe over Fabric 協(xié)議訪問存儲，而不需要通過 CPU 參與并帶來額外的內存拷貝。在去年開始，GPUDirect Async Kernel Initiated Storage （GPUDirect 異步內核啟動的存儲）技術更進一步減少了 CPU 和 GPU 的同步開銷，使得 GPU 可以直接向內核發(fā)起請求，而不需要 CPU 代理發(fā)起。因此，GPU 對存儲的單次訪問來說，已經非常高效。

在 Nvidia CUDA 生態(tài)中，已有 NVSHMEM（如下圖所示）實現了 GPU 之間的內存數據通信，屏蔽了 NVLink/PCI/Infiniband/RoCE/Slingshot/EFA 的具體傳輸實現，極大幫助了 GPU 集群協(xié)同計算的效率，而在存儲方面仍舊沒有對應的 API 和實現，使得 GPU 總要面對十分具體的存儲傳輸和協(xié)同。這意味著需要提供一套新的 API 來處理大數據集的訪問問題。

每個 GPU 線程都是存儲訪問的單元，意味著隨著 GPU 并發(fā)度的不斷提高，在一些場景，例如目前 GPU 已經直接支持的基于圖的數據節(jié)點遍歷，通過 PCIe 的存儲 IO 處理需要高效的手段才能應對。

 GNN 訓練的限制

例如現有的 GNN 框架在遇到無法完全放入內存的數據集時，會直接通過內存映射特征向量文件到 CPU 虛擬地址空間，提供一種無限虛擬內存的概念，使得 CPU 上的節(jié)點特征聚合計算可以在所請求的特征向量不在 CPU 內存中時觸發(fā) page fault。如下圖所示，在節(jié)點特征聚合階段，CPU 訪問映射在其虛擬內存空間的節(jié)點特征，當這些特征不在 Page Cache 中時，OS 會從存儲中將包含被訪問特征的頁面帶入 CPU 內存。

不幸的是，MMAP 方法使得特征聚合成為整個訓練流程中最糟糕的瓶頸。針對 GNN 訓練執(zhí)行的每個階段的性能分析顯示，迭代時間明顯受到節(jié)點聚合階段的限制，正如下圖所示。例如在評估中使用的最大的兩個圖—— IGB-Full 和 IGBH-Full，其訓練階段幾乎看不見。這是因為對于大規(guī)模圖，OOM 的額外成本加劇了數據準備吞吐量和模型訓練吞吐量之間的差距。因此，改善 GNN 訓練性能的關鍵是大幅加速特征聚合階段（即數據準備階段）。

隨著新興的應用領域拓展，更多的應用場景都在面對類似的問題：

• GNNs 中的 圖和特征的存儲
• 向量搜索/向量數據庫中的存儲
  • NeMo Retriever，NVIDIA RAFT in RAG-LLM
  • 在萬億級 token 的 LLM 預訓練上進行數據去重
• LLM 微調與 GNN Embedding 的聯(lián)合也需要大量的 KV 存儲
• cuGraph 中圖分析 API

這些應用都形成了共同的需求：

• 管理/避免 OOM 帶來的開銷
• 需要緩存、數據分區(qū)、多節(jié)點通信能力的支持
• 每個應用都需要針對性創(chuàng)建，缺乏共同的基礎設施

 SCADA 項目的提出 

基于此，Nvidia 在 2022 年開始，基于大內存和存儲系統(tǒng)的聯(lián)動，提出了 SCADA（Scaled accelerated data access ） 系統(tǒng)，面向 GPU 應用的大規(guī)模數據集訪問需求而設計。

SCADA 的設計面向以下四個原則：

• 大規(guī)模的訪問：意味著這個 API 需要應對在單個節(jié)點上處理 10TB級別的數據集。同時也不用擔心 OOM 問題。無論數據的大小或計算的復雜性如何，API 都能夠處理
• 高度抽象：在這個 API 集的前端部分，需要有一個處理特定數據集的接口。這個接口可以有效處理數據局部性、分片和階段性處理后的復雜性。在后端部分，我們?yōu)閼贸绦蛱峁┲苯釉L問數據集的能力，而無需了解數據的局部性和分片問題。這個 API 還可以高效利用 GPU 線程、內存管理和拓撲優(yōu)化通信來處理數據
• 易于啟用：不需要改變現有應用程序
• 總擁有成本（TCO）：大量的數據意味著大量的內存，對應大量成本，如果能夠降低存儲和處理大規(guī)模數據集的內存就意味著降低了成本

針對這些方面，SCADA 主要實現了創(chuàng)新的數據加載和管理機制，這里有幾個關鍵因素：

• 直接存儲訪問：通過通過允許 GPU 直接從 NVMe SSDs 讀取數據，GPUDirect Async Kernel Initiated Storage 減少了傳統(tǒng)的數據加載流程中 CPU 的介入。這種直接訪問機制避免了數據在 CPU 和 GPU 之間的不必要拷貝，從而節(jié)省了大量的內存空間，并減少了訪問延遲
• 軟件定義的緩存和窗口緩沖：利用 GPU 內存作為一個軟件定義的緩存，配合窗口緩沖機制，有效地管理即將被處理的數據。這種策略使得系統(tǒng)能夠在有限的 GPU 內存中存儲最頻繁訪問的數據，同時直接從 SSD 加載其他數據，從而擴展了數據處理的能力，超出了物理內存的限制
• 高效的數據預取和管理：通過智能的數據預取和管理策略，能夠確保 GPU 在需要數據時能夠迅速獲取，從而最小化了 I/O 開銷和等待時間。這種策略進一步提高了數據加載的效率，使得可以在不受物理內存大小限制的情況下處理大規(guī)模數據集
• 減少 I/O 開銷：通過合并多個數據請求和優(yōu)化數據訪問模式，顯著減少了對 SSD 的 I/O 請求，這不僅提高了數據訪問速度，還降低了對存儲設備的負載。這意味著系統(tǒng)可以更有效地利用存儲資源，處理更大的數據集

上圖是整個 SCADA 的服務邏輯，首先 SCADA 會根據提供的頭文件里的數據結構來初始化，目前支持 C++ 模版方式定義數據結構，同時由應用自己來管理內存，SCADA 提供分配和釋放數據結構的 API。CPU 上的應用讀取所有數據，再通過 GPU 線程寫數據到私有的 NVMe。SCADA 會提供連續(xù)數組 API 來供應用讀取這些數據。

下圖展示了一個利用 SCADA 的系統(tǒng)整體架構示例，通過 cuGraph 適配了 SCADA 框架，無需修改應用。整個訓練數據無論大小都可以得到執(zhí)行，且無需管理內存、緩存、分區(qū)等問題。

性能評估 

在一個基準測試中，對比 MMAP 方法，啟用 SCADA 后，整體性能提升達到了 26 倍以上。同時，相比之前 CPU 驅動的 IO 并發(fā)度，SCADA 極大提升了針對存儲設備的并發(fā) 10-100X，甚至達到了 10000 的 IO 并發(fā)度。

從 IO 角度來分析，下表展示了通過 SCADA 的緩存和 IO 匯聚成果，成功將瓶頸從存儲 IO 能力轉移到了 GPU 節(jié)點本身：

 XSKY 觀點 

SCADA 目前仍然是 Nvidia CUDA 體系的實驗性項目，正在跟應用開發(fā)者協(xié)作更多的數據結構，如 KV、VectorDB、dataframe。在存儲方面，通過 SCADA 帶來了更高并發(fā) IO 后，可以提供更高效和細粒度的事務支持。另外，塊和文件系統(tǒng)的統(tǒng)一使用也成為必需，靈活運用塊的高性能 IO 和文件系統(tǒng)的共享能力使得 GPU 應用的大數據集問題大大緩解。另外，SCADA 實際上是過去 Big Memory 的 GPU 場景衍生，其差異是充分考慮了 GPU 的生態(tài)能力，使得跟 GPU 應用結合后會有更顯著的性能提升。

這些對于 XSKY 的全共享架構（XSEA）都是極好的匹配，更好的支持 GPU 的高并發(fā)、大帶寬的場景需求。

崔歡歡