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