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