大模型應用領域的迅猛發展，也推動著基礎技術領域持續探索和進步。檔案儲存服務在 AI 基礎設施中成為不可或缺的重要部分。
在過去 18 個月的時間裡，JuiceFS 團隊與 MiniMax，階躍星辰，智譜 AI，面壁智慧，零一萬物等大模型團隊展開了交流與合作，已經支援了多家客戶生產環境中數千卡的訓練任務。
在這篇文章中，我們將分享大型語言模型在儲存領域面臨的一些挑戰與 JuiceFS 在服務這些場景時的實踐經驗，為相關企業提供參考。
01 儲存系統效能與成本之間的平衡
在大家剛開始投入到預訓練模型時，有這樣一種觀點：GPU 很貴，相比之下儲存的成本忽略不計，可以直接選效能最好最貴的儲存方案。典型的高效能檔案系統有 GPFS、Lustre、Weka，以及其他高效能 NAS 等。這些系統通常依賴全快閃記憶體（NVMe） 和高效能網路提供極致效能。
同時，當算力、資料與團隊投入都增大的時候，我們又看到了幾個新的事實：
-
零一萬物在其最新發表的論文《Yi: Open Foundation Models by 01.AI》（以下簡稱《Yi 論文》），其預訓練資料集包含 3T tokens，透過 BPE tokenization 處理，每個 token 大約佔 2Bytes，這意味著 3T tokens 大約等於 6TB 資料。然而，準備可用於正式訓練的資料集的過程包括資料抓取、清洗、轉換等多個前置步驟，涉及大量的實驗。這些實驗處理的資料量通常是正式訓練資料集的 100 倍以上。隨著團隊規模的擴大，將產生更多實驗結果和中間資料，加上各種模型的 checkpoint 和日誌資料，預訓練環節總資料量預計將達到 10PB 到 100PB。
-
正式訓練環節，如上文推算，雖然資料集規模固定為 6T，企業可以將全部資料儲存於高效能儲存系統中。但是，高效能檔案系統的效能都與容量是關聯的。例如，每 TB 容量提供 250MBps 吞吐，也就是說僅僅把 6TB 資料集存在高效能檔案系統，僅能提供 1500MB/s 的吞吐，如果要達到訓練所需的 I/O 效能，需要擴大高效能檔案系統容量。
於是，出於成本考慮使用者通常不會將所有資料僅儲存於之前提及的高效能檔案儲存系統中，如阿里雲的 CPFS，其按官網報價（1.4 元/GB/月）來算，10PB 資料的月成本將達到千萬級別。還需要注意的是在容量規劃方面這類方案不能像 S3 那樣彈性使用，擴容很不方便。
使用者開始採用物件儲存（約 0.13 元/GB/月）與高效能檔案儲存相結合的策略。這種做法雖然成本更低，但隨之而來的是需要額外人力和時間去處理兩套儲存系統間的資料同步、遷移和一致性管理等任務，這些工作不僅過程繁瑣，而且與追求高效率的目標相悖。
那 JuiceFS 如何解決上述效能和成本的問題呢？
-
經濟的物件儲存：JuiceFS 將物件儲存作為資料持久化層，顯著降低了儲存成本。
-
彈性容量管理：它提供類似於彈性檔案儲存的容量規劃能力，彈性擴縮容機制增強了效率，免除了手動管理的需求。
-
高效能：相較於高效能的專用檔案系統，分散式檔案系統的效能是使用者最關心的問題之一。JuiceFS 透過多級快取加速架構為預訓練提供充足的讀寫吞吐能力。使用者生產環境中的 I/O 吞吐量監測資料，峰值超過了 340GB/s。更多 JuieFS 效能調優策略，可參考：千卡利用率超 98%，詳解 JuiceFS 在權威 AI測試中的實現策略。
成本方面，JuiceFS 企業版相較於高效能檔案儲存 AWS FSx for Lustre，價格僅為其 20%；而快取層所需要的硬體資源可使用 GPU 節點配備的 NVMe 驅動器，沒有產生額外成本。由此，使用者能夠以僅 20% 的成本獲得一個具有彈性的高效能檔案儲存解決方案，其效能與傳統的高效能檔案儲存系統相匹敵，且具有更優的擴充套件性。此外，還免除了使用者需考慮資料與物件儲存之間的同步、遷移及一致性管理等問題。
02 為什麼 POSIX 在 AI 訓練中必不可缺?
準備高質量的訓練資料是構建出色基礎模型的基礎。資料準備本身是一個複雜的流程，正如《Yi 論文》中所展示的那樣：
每個環節的資料處理需求都是不同的，而且這個過程在今天仍然沒有一個統一的正規化，資料工程師仍在不斷實驗。
-
資料工程師幾乎都在用 Python，在並行處理中會用到 Ray，如果使用 Spark 也大多透過 PySpark 程式設計。這些操作的靈活性和高效性要求底層檔案系統具備 POSIX 相容性，這樣可以比較高效地滿足各種資料處理的需求。
-
HDFS 只支援追加寫，無法支援需要覆蓋寫的資料處理方法，比如 Pandas。同時，HDFS 的 Python SDK 也不夠成熟。
-
S3 等物件儲存不支援高效的追加或者修改（只能整體覆蓋），不支援重新命名操作。目錄操作的效能會很慢。有成熟的 Python SDK，但使用上仍然沒有 POSIX 的方式簡單直接。另外，資料處理工作還可能會遇到物件儲存的頻寬限制，高併發下可能會遇到 API 的 QPS 限制。
-
使用 S3FS 等方案掛載 S3 等物件儲存時，可以支援 POSIX 方式訪問，但很多操作的效能會比我們預期的慢很多。比如對一個檔案做覆蓋寫，需要將它下載到本地進行修改，然後再完整上傳，和檔案系統中的區域性覆蓋寫是完全不同的。對一個目錄做重新命名也會遇到同樣的問題。（請參考另外一篇文章）
-
使用公有云的 NAS 產品，可以用 pjdfstest 做一下 POSIX 相容性測試。另一個問題是 NAS 的效能與資料量是線性相關的，所以使用中可能會遇到當前資料量提供的效能不能滿足計算需要的問題。
所以，對於資料工程師，一個全功能的 POSIX 檔案系統是資料處理、清洗環節的最佳拍檔。JuiceFS 完全相容 POSIX ，同時也支援 HDFS、S3 API 的訪問方式，在資料處理、清洗的整個流程中能很好地支援各種各樣的計算負載。
關於 POSIX 相容性在 AI 訓練中的重要作用，可參考案例，韓國國民搜尋 NAVER：為 AI 平臺引入儲存方案 JuiceFS。
03 多雲架構：資料同步、一致性管理的挑戰
無論是訓練或是推理的需求，單一資料中心或單一雲區域內的 GPU 資源往往無法滿足使用者的全部需求。特別是對於面向 C 端消費者的應用，為了提供更佳的使用者體驗，常常需要在多個地理區域進行部署。在這種情況下，使用者面臨的挑戰包括資料集和模型在多區域之間的分發、同步及一致性管理等。
下圖是某使用者在最初使用多雲架構時的資料管理方案示意圖。使用者需要面對的挑戰有：
-
物件儲存 A 到物件儲存 B 的資料同步：在處理物件儲存間的資料同步時，雖然可以採用定時同步特定字首的資料或設計物件更新回撥以觸發同步，這些方法在小規模資料處理時簡單有效。然而，當同步作業面對大規模資料時，這些同步方案的複雜性急劇上升。挑戰包括如何管理同步任務的併發執行、確保資料同步的可靠性、任務失敗後的資料重建、系統的觀測性、流量控制以及資料一致性校驗等一系列問題。
-
高效能檔案儲存與物件儲存之間的資料同步：由於高效能檔案儲存的容量有限，需要人工決策哪些資料是近期必需的，並安排合適的時間將這些資料從物件儲存中複製過來。當儲存空間不足時，又必須協調眾多團隊成員共同決定刪除哪些資料，以釋放空間。這一過程中，每個人都傾向於保留自己的資料，從而避免它們被刪除，這使得是否擴容或是進行團隊內部協調成為一個複雜的決策問題。而擴容並非僅僅關乎成本，還涉及到額外的運維工作和資源投入，增加了同步工作的複雜度和管理難度。
-
兩邊高效能檔案系統中的資料同步：當使用者的任務在區域 A 完成執行後，其可能被排程至區域 B 執行。這就要求任務 A 所使用的資料集需要在區域 B 內可獲取，而且其先前的執行輸出和日誌也必須同樣可訪問。
-
同步管理與一致性保證的挑戰：選擇強一致性還是最終一致性依賴於業務需求和技術實現的複雜度；如果選擇最終一致性，明確其時間視窗的界定也是必要的，以保障系統的整體可靠性和預期行為。
-
儲存系統差異問題：這些系統在產品效能、使用限制以及管理策略等方面往往存在細微差異，這些差異要求使用者採用精細化的同步和管理方法來確保資料一致性和系統效率。
手工維護上述這套資料架構，運維負擔可想而見，如果不止兩個區域，上面所有的問題將更加複雜。能否讓上面這些問題自動化？JuiceFS 使用映象功能滿足了這樣的需求，目前已經成了大模型訓練和推理業務中的必備功能。
在 JuiceFS 資料映象方案中，所有主站點的資料變動都會自動同步到各個映象站點。後設資料同步在確定的時間視窗內完成，同城可以達到毫秒級延遲，跨城市在國內約為 10-30 毫秒，跨大洲則為亞分鐘級。在指定時間視窗中，映象站點保證資料一致性。
資料同步完成的時間基本上與在網路環境中傳輸一個 4MB 檔案所需的時間相同。如果資料尚未完成同步，從映象站訪問檔案時，JuiceFS 會自動處理其中的 I/O 路徑，確保檔案可以被訪問。這種處理機制可能會導致短暫的效能下降，但不會影響程式正確執行。而當使用者在映象站產生新資料並寫入 JuiceFS 時，資料會自動回寫到資料來源站，此時的寫入效能取決於網路狀況。更多實踐案例：知乎如何在多雲架構下使用 JuiceFS 映象功能？
04 模型載入慢，GPU 等待時間久
模型載入就是將模型完整讀取載入視訊記憶體的過程，在訓練啟動、訓練恢復和推理服務部署時都包含模型載入過程。模型通常是一個大檔案，隨著模型引數的增加，模型檔案的大小也從幾十 GB 增長到 TB 級別，通常採用 pickle 或 safetensor 等格式。
載入過程需要從儲存系統中單執行緒順序讀取，影響速度的關鍵因素是單執行緒順序讀取時的吞吐量，JuiceFS 當前版本載入模型吞吐效能為 1500MB/s。經過為模型載入場景的最佳化後，讀吞吐可以提升至 3GB/s。
另一方面，以 PyTorch 載入 pickle 格式模型的過程為例，在順序讀取模型檔案的同時會完成 pickle 資料的反序列化，這個過程也會消耗時間。在我們的測試中，從記憶體盤載入 Llama 2 7B 全精度模型，pickle 格式，26GB 大小，吞吐效能是 2.2GB/s。因為記憶體是最快的儲存介質，所以我們將其視為極限值。從 JuiceFS 載入同樣的模型，吞吐效能為 2.07GB/s，是極限值的 94%。
基於這樣的表現，越來越多 AI 使用者在推理業務中使用 JuiceFS 儲存模型，加速模型載入，省下了可觀的 GPU 成本。這裡可以參考 BentoML 的最佳化經驗，他們是一家模型部署 SaaS 服務，要為客戶管理大量模型，非常關心模型載入效能。
結尾
最近兩年大語言模型（LLM，Large Language Model）飛速發展，引數規模迅速提升，這不僅意味著模型大小在增長，也意味著用於訓練的資料規模同時在更快增加，這對於儲存系統的挑戰不言而喻。
JuiceFS 的幾方面能力得到了客戶的認可：
-
高價效比；
-
POSIX 100% 相容性，同時支援 HDFS、S3 協議；
-
透過快取叢集可以彈性擴充套件叢集吞吐能力；
-
自動多雲資料同步，省去人工遷移的低效，和一致性管理的挑戰；
-
加速模型部署，節約推理成本。
我們將繼續與大家分享在 AI 發展過程中所觀察到的變化，和對儲存方案的探索，也期待與業內同仁交流與討論。
希望這篇內容能夠對你有一些幫助，如果有其他疑問歡迎加入 JuiceFS 社群與大家共同交流。