目前大模型的客戶(hù)在存儲系統的選型上可能會(huì )有以下幾種選擇：并行文件系統、基于對象存儲的存儲系統、NFS等。
首先我們看一下并行文件系統：
Density distribution plots of I/O activity from ML jobs using GPFS
《Characterizing Machine Learning I/O Workloads on Leadership Scale HPC Systems》中關(guān)于ML在GPFS中的IO模型示意圖，可以看到在并行文件系統的傳統科學(xué)計算領(lǐng)域IO模式，讀寫(xiě)比例基本平衡且大部分為小IO，這種GPFS適用的IO模式是否能夠完全匹配AI大模型下的場(chǎng)景呢？
這里引用Vast Data（https://vastdata.com/blog/five-reasons-why-parallel-file-systems-are-not-silver-bullet-for-ai）的數據，95%的AI Workloads是讀密集型的，當然也有例外情況，比如大型語(yǔ)言模型的Checkpoint。并行文件系統在擁有高性能的同時(shí)，也引入了高復雜性，包括額外的客戶(hù)端以及較高難度的維護工作，并行文件系統適用的HPC科學(xué)研究場(chǎng)景需要一個(gè)對存儲系統代碼和操作系統有深入了解的團隊，這在科研實(shí)驗室中是相對常見(jiàn)的，但對于商業(yè)企業(yè)來(lái)說(shuō)，往往缺乏這種人員配置，在目前的大模型場(chǎng)景下，類(lèi)似于GPFS的并行文件系統并不完全適用。
根據UCloud優(yōu)刻得云平臺上的客戶(hù)IO模式來(lái)看，大模型計算的工作負載大部分場(chǎng)景下是讀密集型的，并非大部分文件系統面對的讀寫(xiě)比例平衡的場(chǎng)景，短時(shí)間的高讀吞吐需求較為常見(jiàn)，高吞吐讀之前會(huì )對文件進(jìn)行大量列表操作等元數據操作，以及Checkpoint時(shí)期會(huì )有大量順序寫(xiě)入，對于歷史數據有一定的歸檔需求。
針對上述場(chǎng)景，目前UCloud優(yōu)刻得提供全面優(yōu)化升級的US3FS 2.0來(lái)滿(mǎn)足大模型客戶(hù)的存儲需求。
US3FS是基于UCloud優(yōu)刻得對象存儲系統US3的文件系統，支持將對象存儲中的Bucket直接以文件的形式掛載至客戶(hù)端，方便客戶(hù)業(yè)務(wù)通過(guò)文件的POSIX接口來(lái)訪(fǎng)問(wèn)數據，避免客戶(hù)業(yè)務(wù)層面做過(guò)多的修改適配。面向大模型場(chǎng)景，目前UCloud優(yōu)刻得對US3FS進(jìn)行了升級優(yōu)化，US3FS 2.0 整體架構如下：
從前述大模型的存儲需求來(lái)看，后面將從高吞吐讀需求，大量列表操作，大量順序寫(xiě)入這三方面描述UCloud優(yōu)刻得針對US3FS的優(yōu)化升級過(guò)程。
這里首先考慮高吞吐讀之前的大量列表的問(wèn)題，整體分為兩種解決思路：
1.打散后端US3的存儲結構，旁路一套元數據系統進(jìn)行元數據的性能優(yōu)化等維護操作，不利用現有US3的元數據能力。
2.不打散后端US3的存儲結構，優(yōu)化升級現有的US3元數據性能，并進(jìn)行Meta Cache等近計算端優(yōu)化。
第一種方案理論上可以規避現有架構的歷史負擔，需要額外的硬件資源來(lái)提供元數據服務(wù)，改造后能夠規避業(yè)務(wù)層面文件大小等因素對US3在高并發(fā)情況下發(fā)揮高吞吐能力的限制，也可以?xún)?yōu)化元數據結構以更貼近文件存儲的樹(shù)狀方式，而不是對象存儲的KV方式。但此方案整體改動(dòng)較大，引入的風(fēng)險也較多，且無(wú)法直接利用US3對象存儲現有的增值服務(wù)，包括但不限于歸檔、低頻等廉價(jià)存儲的功能。
第二種方案需要對現有關(guān)系型數據庫的老架構US3元數據進(jìn)行升級，這里由于US3同時(shí)正在進(jìn)行元數據UKV的升級過(guò)程，將US3整體的元數據遷移至KV的方式進(jìn)行存取，可以直接利用數據，與此同時(shí)，還需要對現有的對象存儲語(yǔ)義的ListObject進(jìn)行一定優(yōu)化來(lái)適配文件存儲的場(chǎng)景，進(jìn)而解決對象和文件之間元數據差異的問(wèn)題。
經(jīng)過(guò)對比，UCloud優(yōu)刻得選擇了第二種方案來(lái)實(shí)現US3FS2.0的元數據部分，依賴(lài)于UKV（UCloud優(yōu)刻得自研的分布式KV存儲系統）的整體存儲計算分離的架構，可以支持0數據搬遷的Shard Split，快速進(jìn)行列表請求計算部分的壓力分攤，底層的統一存儲層Manul也可以進(jìn)行存儲層面的壓力分攤。
這里UCloud優(yōu)刻得也會(huì )進(jìn)行近端元數據的Cache，由于對象存儲和文件存儲存在天然的區別，對象存儲的結構近似于KV的方式平鋪，文件存儲的方式近似于樹(shù)狀結構，客戶(hù)在文件層面的readdir操作在極端情況下會(huì )導致底層KV層的大量seek操作效率不高，這里我們優(yōu)化成直接進(jìn)行平鋪的ListObject操作并在近端進(jìn)行整體的元數據重構以及Cache，保證客戶(hù)的元數據檢索效率，以在UCloud優(yōu)刻得云平臺實(shí)際上線(xiàn)的某客戶(hù)為例，30PiB的數據元數據異步Cache的整體時(shí)間可控制在10分鐘到20分鐘級別。
其次，UCloud優(yōu)刻得還綜合考慮了客戶(hù)高并發(fā)讀吞吐的需求，這里面向客戶(hù)的業(yè)務(wù)實(shí)際場(chǎng)景，大模型通常是GiB級別的文件高并發(fā)的重復讀取，UCloud優(yōu)刻得并不希望這些重復的讀取消耗后端對象存儲的帶寬。
UCloud優(yōu)刻得在US3FS的掛載端通過(guò)本地NVMe來(lái)提供近計算端的分布式緩存，這里的緩存會(huì )利用計算節點(diǎn)間的東西向帶寬，一般建議實(shí)際操作時(shí)，在計算網(wǎng)和存儲網(wǎng)做網(wǎng)絡(luò )層面的隔離，防止和計算部分的流量有干擾，UCloud優(yōu)刻得也提供獨立專(zhuān)有化部署的一整套解決方案。
后續UCloud優(yōu)刻得還會(huì )提供通過(guò)US3FS的管理節點(diǎn)US3FS Master來(lái)支持業(yè)務(wù)層主動(dòng)提前Load指定的數據至緩存中的功能，但這需要將業(yè)務(wù)層和存儲層做一些深度的結合才能實(shí)現。
在未進(jìn)行預Cache時(shí)，上層應用從US3FS掛載點(diǎn)讀取數據時(shí)，Kernel會(huì )將上層的讀緩沖區拆分成固定大小傳遞給US3FS, 當US3FS接收到這些讀請求時(shí)，會(huì )根據讀的偏移，傳入的緩沖區的大小以及設置的預讀大小來(lái)確定實(shí)際要讀的Range。默認情況下，US3FS以1MiB一個(gè)CachePage的形式組織文件的緩存區，通過(guò)讀Range可以確定涉及的Pages，接著(zhù)根據Page的狀態(tài)（Ready, Missing or Infight）, 如Pages全為Ready，則可直接向上返回，如存在Missing或者Inflight的Pages，則Missing的Pages需要向數據層發(fā)送GET_RANGE請求，Inflight的Pages需要等待對應的GET_RANGE執行完成，這里一定程度的耦合了大模型下客戶(hù)順序讀的IO模型，通過(guò)參數能夠最大優(yōu)化在這種場(chǎng)景下的讀取并發(fā)吞吐。
接下來(lái)還需要對業(yè)務(wù)Checkpoint場(chǎng)景進(jìn)行優(yōu)化。由于業(yè)務(wù)的特殊性，寫(xiě)入Checkpoint期間計算訓練是暫停的，寫(xiě)入速度的快慢就直接影響了客戶(hù)整體的效率，又由于此時(shí)是大量順序寫(xiě)，對存儲系統的性能需求就明確為寫(xiě)吞吐。
這里也有兩種解決思路:
3.寫(xiě)緩存，異步的上傳到后端對象存儲，保證當時(shí)寫(xiě)入的速度是近似于本地盤(pán)的速度。
4.提高并發(fā)，直接寫(xiě)至后端對象存儲，由于后端整體的吞吐是可以支持平行擴展的，這里瓶頸如果能夠打滿(mǎn)掛載的網(wǎng)絡(luò )則是最優(yōu)的情況，那需要提高的就是寫(xiě)入的并發(fā)，降低整體吞吐對于寫(xiě)延遲的依賴(lài)。
綜上UCloud優(yōu)刻得選擇了兩者結合的方式。純粹寫(xiě)緩存的方式在數據一致性以及系統復雜度上都有不少的麻煩，且能否解決問(wèn)題強依賴(lài)于不可控的計算節點(diǎn)的緩存盤(pán)，而不是依賴(lài)于存儲系統自身的環(huán)境。UCloud優(yōu)刻得會(huì )在寫(xiě)入時(shí)將上層Kernel拆分下載為固定大小的IO進(jìn)行進(jìn)一步的合并整合，整合一個(gè)4MiB大小的Logic Block，用于后續并發(fā)上傳至后端US3對象存儲。上層的IO到達US3FS之后會(huì )直接返回成功，并逐步累積緩存對后端進(jìn)行并發(fā)的分片上傳，這里并發(fā)的大小以及緩存的度都是支持對參數隨時(shí)配置修改的。
這樣上層的串行IO通過(guò)US3FS后會(huì )變成高并發(fā)的分片上傳請求到US3后端，進(jìn)而提升整體的吞吐。
以上為一個(gè)實(shí)例集群US3FS Runtime的實(shí)時(shí)Stat功能展示的寫(xiě)吞吐，相較于優(yōu)化前有50%左右的吞吐提升。
本文描述了面向大模型場(chǎng)景的存儲需求，UCloud US3FS2.0 在元數據性能、讀緩存、寫(xiě)吞吐三個(gè)方面的優(yōu)化內容。在A(yíng)I大模型的需求推動(dòng)下，對整個(gè)存儲系統以及IaaS計算、網(wǎng)絡(luò )架構提出了較大的挑戰。對于對象存儲來(lái)說(shuō)，前端的壓力能夠釋放到后端之后，后續，UCloud優(yōu)刻得還將在存儲容量與性能需求不匹配、讀緩存預熱等方面持續進(jìn)行優(yōu)化。*圖片來(lái)源由UCloud優(yōu)刻得提供授權使用
