在單機(jī) CPU/GPU 內(nèi)存足以容納的數(shù)據(jù)，在規(guī)模化數(shù)據(jù)集面前已經(jīng)無法被內(nèi)存容納后，意味著每個大規(guī)模數(shù)據(jù)集的集群都需要面對大數(shù)據(jù)集的分區(qū)、緩存和節(jié)點(diǎn)通訊協(xié)同問題，更不用提其中的錯誤處理，意味著要像傳統(tǒng)大數(shù)據(jù)系統(tǒng)一樣構(gòu)建（但完全不同的性能需求）。
GPU 的存儲訪問
在數(shù)據(jù)訪問上，在幾年前就擁有了 GPUDirect Storage，意味著 GPU 可以直接通過 NVMe over Fabric 協(xié)議訪問存儲，而不需要通過 CPU 參與并帶來額外的內(nèi)存拷貝。在去年開始，GPUDirect Async Kernel Initiated Storage （GPUDirect 異步內(nèi)核啟動的存儲）技術(shù)更進(jìn)一步減少了 CPU 和 GPU 的同步開銷，使得 GPU 可以直接向內(nèi)核發(fā)起請求，而不需要 CPU 代理發(fā)起。因此，GPU 對存儲的單次訪問來說，已經(jīng)非常高效。
在 Nvidia CUDA 生態(tài)中，已有 NVSHMEM（如下圖所示）實(shí)現(xiàn)了 GPU 之間的內(nèi)存數(shù)據(jù)通信，屏蔽了 NVLink/PCI/Infiniband/RoCE/Slingshot/EFA 的具體傳輸實(shí)現(xiàn)，極大幫助了 GPU 集群協(xié)同計算的效率，而在存儲方面仍舊沒有對應(yīng)的 API 和實(shí)現(xiàn)，使得 GPU 總要面對十分具體的存儲傳輸和協(xié)同。這意味著需要提供一套新的 API 來處理大數(shù)據(jù)集的訪問問題。
每個 GPU 線程都是存儲訪問的單元，意味著隨著 GPU 并發(fā)度的不斷提高，在一些場景，例如目前 GPU 已經(jīng)直接支持的基于圖的數(shù)據(jù)節(jié)點(diǎn)遍歷，通過 PCIe 的存儲 IO 處理需要高效的手段才能應(yīng)對。
GNN 訓(xùn)練的限制
例如現(xiàn)有的 GNN 框架在遇到無法完全放入內(nèi)存的數(shù)據(jù)集時，會直接通過內(nèi)存映射特征向量文件到 CPU 虛擬地址空間，提供一種無限虛擬內(nèi)存的概念，使得 CPU 上的節(jié)點(diǎn)特征聚合計算可以在所請求的特征向量不在 CPU 內(nèi)存中時觸發(fā) page fault。如下圖所示，在節(jié)點(diǎn)特征聚合階段，CPU 訪問映射在其虛擬內(nèi)存空間的節(jié)點(diǎn)特征，當(dāng)這些特征不在 Page Cache 中時，OS 會從存儲中將包含被訪問特征的頁面帶入 CPU 內(nèi)存。
不幸的是，MMAP 方法使得特征聚合成為整個訓(xùn)練流程中最糟糕的瓶頸。針對 GNN 訓(xùn)練執(zhí)行的每個階段的性能分析顯示，迭代時間明顯受到節(jié)點(diǎn)聚合階段的限制，正如下圖所示。例如在評估中使用的最大的兩個圖—— IGB-Full 和 IGBH-Full，其訓(xùn)練階段幾乎看不見。這是因?yàn)閷τ诖笠?guī)模圖，OOM 的額外成本加劇了數(shù)據(jù)準(zhǔn)備吞吐量和模型訓(xùn)練吞吐量之間的差距。因此，改善 GNN 訓(xùn)練性能的關(guān)鍵是大幅加速特征聚合階段（即數(shù)據(jù)準(zhǔn)備階段）。
隨著新興的應(yīng)用領(lǐng)域拓展，更多的應(yīng)用場景都在面對類似的問題：
這些應(yīng)用都形成了共同的需求：
SCADA 項(xiàng)目的提出
基于此，Nvidia 在 2022 年開始，基于大內(nèi)存和存儲系統(tǒng)的聯(lián)動，提出了 SCADA（Scaled accelerated data access ） 系統(tǒng)，面向 GPU 應(yīng)用的大規(guī)模數(shù)據(jù)集訪問需求而設(shè)計。
SCADA 的設(shè)計面向以下四個原則：
針對這些方面，SCADA 主要實(shí)現(xiàn)了創(chuàng)新的數(shù)據(jù)加載和管理機(jī)制，這里有幾個關(guān)鍵因素：
上圖是整個 SCADA 的服務(wù)邏輯，首先 SCADA 會根據(jù)提供的頭文件里的數(shù)據(jù)結(jié)構(gòu)來初始化，目前支持 C++ 模版方式定義數(shù)據(jù)結(jié)構(gòu)，同時由應(yīng)用自己來管理內(nèi)存，SCADA 提供分配和釋放數(shù)據(jù)結(jié)構(gòu)的 API。CPU 上的應(yīng)用讀取所有數(shù)據(jù)，再通過 GPU 線程寫數(shù)據(jù)到私有的 NVMe。SCADA 會提供連續(xù)數(shù)組 API 來供應(yīng)用讀取這些數(shù)據(jù)。
下圖展示了一個利用 SCADA 的系統(tǒng)整體架構(gòu)示例，通過 cuGraph 適配了 SCADA 框架，無需修改應(yīng)用。整個訓(xùn)練數(shù)據(jù)無論大小都可以得到執(zhí)行，且無需管理內(nèi)存、緩存、分區(qū)等問題。
性能評估
在一個基準(zhǔn)測試中，對比 MMAP 方法，啟用 SCADA 后，整體性能提升達(dá)到了 26 倍以上。同時，相比之前 CPU 驅(qū)動的 IO 并發(fā)度，SCADA 極大提升了針對存儲設(shè)備的并發(fā) 10-100X，甚至達(dá)到了 10000 的 IO 并發(fā)度。
從 IO 角度來分析，下表展示了通過 SCADA 的緩存和 IO 匯聚成果，成功將瓶頸從存儲 IO 能力轉(zhuǎn)移到了 GPU 節(jié)點(diǎn)本身：
XSKY 觀點(diǎn)
SCADA 目前仍然是 Nvidia CUDA 體系的實(shí)驗(yàn)性項(xiàng)目，正在跟應(yīng)用開發(fā)者協(xié)作更多的數(shù)據(jù)結(jié)構(gòu)，如 KV、VectorDB、dataframe。在存儲方面，通過 SCADA 帶來了更高并發(fā) IO 后，可以提供更高效和細(xì)粒度的事務(wù)支持。另外，塊和文件系統(tǒng)的統(tǒng)一使用也成為必需，靈活運(yùn)用塊的高性能 IO 和文件系統(tǒng)的共享能力使得 GPU 應(yīng)用的大數(shù)據(jù)集問題大大緩解。另外，SCADA 實(shí)際上是過去 Big Memory 的 GPU 場景衍生，其差異是充分考慮了 GPU 的生態(tài)能力，使得跟 GPU 應(yīng)用結(jié)合后會有更顯著的性能提升。
這些對于 XSKY 的全共享架構(gòu)（XSEA）都是極好的匹配，更好的支持 GPU 的高并發(fā)、大帶寬的場景需求。
