在單機(jī) CPU/GPU 內(nèi)存足以容納的數(shù)據(jù)，在規(guī)模化數(shù)據(jù)集面前已經(jīng)無(wú)法被內(nèi)存容納后，意味著每個(gè)大規(guī)模數(shù)據(jù)集的集群都需要面對(duì)大數(shù)據(jù)集的分區(qū)、緩存和節(jié)點(diǎn)通訊協(xié)同問(wèn)題，更不用提其中的錯(cuò)誤處理，意味著要像傳統(tǒng)大數(shù)據(jù)系統(tǒng)一樣構(gòu)建（但完全不同的性能需求）。

 GPU 的存儲(chǔ)訪問(wèn)

在數(shù)據(jù)訪問(wèn)上，在幾年前就擁有了 GPUDirect Storage，意味著 GPU 可以直接通過(guò) NVMe over Fabric 協(xié)議訪問(wèn)存儲(chǔ)，而不需要通過(guò) CPU 參與并帶來(lái)額外的內(nèi)存拷貝。在去年開(kāi)始，GPUDirect Async Kernel Initiated Storage （GPUDirect 異步內(nèi)核啟動(dòng)的存儲(chǔ)）技術(shù)更進(jìn)一步減少了 CPU 和 GPU 的同步開(kāi)銷(xiāo)，使得 GPU 可以直接向內(nèi)核發(fā)起請(qǐng)求，而不需要 CPU 代理發(fā)起。因此，GPU 對(duì)存儲(chǔ)的單次訪問(wèn)來(lái)說(shuō)，已經(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é)同計(jì)算的效率，而在存儲(chǔ)方面仍舊沒(méi)有對(duì)應(yīng)的 API 和實(shí)現(xiàn)，使得 GPU 總要面對(duì)十分具體的存儲(chǔ)傳輸和協(xié)同。這意味著需要提供一套新的 API 來(lái)處理大數(shù)據(jù)集的訪問(wèn)問(wèn)題。

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

 GNN 訓(xùn)練的限制

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

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

隨著新興的應(yīng)用領(lǐng)域拓展，更多的應(yīng)用場(chǎng)景都在面對(duì)類(lèi)似的問(wèn)題：

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

這些應(yīng)用都形成了共同的需求：

• 管理/避免 OOM 帶來(lái)的開(kāi)銷(xiāo)
• 需要緩存、數(shù)據(jù)分區(qū)、多節(jié)點(diǎn)通信能力的支持
• 每個(gè)應(yīng)用都需要針對(duì)性創(chuàng)建，缺乏共同的基礎(chǔ)設(shè)施

 SCADA 項(xiàng)目的提出 

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

SCADA 的設(shè)計(jì)面向以下四個(gè)原則：

• 大規(guī)模的訪問(wèn)：意味著這個(gè) API 需要應(yīng)對(duì)在單個(gè)節(jié)點(diǎn)上處理 10TB級(jí)別的數(shù)據(jù)集。同時(shí)也不用擔(dān)心 OOM 問(wèn)題。無(wú)論數(shù)據(jù)的大小或計(jì)算的復(fù)雜性如何，API 都能夠處理
• 高度抽象：在這個(gè) API 集的前端部分，需要有一個(gè)處理特定數(shù)據(jù)集的接口。這個(gè)接口可以有效處理數(shù)據(jù)局部性、分片和階段性處理后的復(fù)雜性。在后端部分，我們?yōu)閼?yīng)用程序提供直接訪問(wèn)數(shù)據(jù)集的能力，而無(wú)需了解數(shù)據(jù)的局部性和分片問(wèn)題。這個(gè) API 還可以高效利用 GPU 線程、內(nèi)存管理和拓?fù)鋬?yōu)化通信來(lái)處理數(shù)據(jù)
• 易于啟用：不需要改變現(xiàn)有應(yīng)用程序
• 總擁有成本（TCO）：大量的數(shù)據(jù)意味著大量的內(nèi)存，對(duì)應(yīng)大量成本，如果能夠降低存儲(chǔ)和處理大規(guī)模數(shù)據(jù)集的內(nèi)存就意味著降低了成本

針對(duì)這些方面，SCADA 主要實(shí)現(xiàn)了創(chuàng)新的數(shù)據(jù)加載和管理機(jī)制，這里有幾個(gè)關(guān)鍵因素：

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

上圖是整個(gè) SCADA 的服務(wù)邏輯，首先 SCADA 會(huì)根據(jù)提供的頭文件里的數(shù)據(jù)結(jié)構(gòu)來(lái)初始化，目前支持 C++ 模版方式定義數(shù)據(jù)結(jié)構(gòu)，同時(shí)由應(yīng)用自己來(lái)管理內(nèi)存，SCADA 提供分配和釋放數(shù)據(jù)結(jié)構(gòu)的 API。CPU 上的應(yīng)用讀取所有數(shù)據(jù)，再通過(guò) GPU 線程寫(xiě)數(shù)據(jù)到私有的 NVMe。SCADA 會(huì)提供連續(xù)數(shù)組 API 來(lái)供應(yīng)用讀取這些數(shù)據(jù)。

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

性能評(píng)估 

在一個(gè)基準(zhǔn)測(cè)試中，對(duì)比 MMAP 方法，啟用 SCADA 后，整體性能提升達(dá)到了 26 倍以上。同時(shí)，相比之前 CPU 驅(qū)動(dòng)的 IO 并發(fā)度，SCADA 極大提升了針對(duì)存儲(chǔ)設(shè)備的并發(fā) 10-100X，甚至達(dá)到了 10000 的 IO 并發(fā)度。

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

 XSKY 觀點(diǎn) 

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

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

崔歡歡

<tfoot id="fn4zz"><strike id="fn4zz"></strike></tfoot>