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