中國科學院計算所在建設大模型訓練與推理平臺過程中，模型規模與資料集數量呈爆發式增長。最初採用簡單的裸機儲存方案，但很快面臨資料孤島、重複冗餘、管理混亂和資源利用不均等問題，於是升級到了 NFS 系統。然而，隨著使用強度增加，NFS 的瓶頸日益凸顯：高峰期訓練任務嚴重延遲甚至完全停滯，多使用者併發時系統性能斷崖式下降，儲存擴容困難且缺乏有效的資料一致性保障。這些問題嚴重影響到了實驗室研究人員的使用，迫使我們尋求更先進的儲存方案。
經過對多種開源儲存系統的評估對比，我們選擇了 JuiceFS 。我們的架構採用 Redis 進行高效能元資料管理，同時構建了自有 MinIO 叢集作為底層物件儲存，這一架構完美解決了模型訓練場景中的資料讀寫瓶頸、元資料訪問延遲以及計算資源之間的儲存互通問題。
我們的平臺是面向實驗室內部的大模型訓練與推理一體化平臺，核心功能聚焦於模型、資料集和使用者程式碼的統一管理。在資源排程方面，平臺透過 Kubernetes 對實驗室內所有伺服器的計算資源進行集中管理與分配，提升整體算力利用效率。同時，平臺還提供模型相關的服務能力，如內建模型評估列表，並支援將模型一鍵部署為應用服務，方便實驗室內的師生共享與呼叫。
首先，平臺需具備儲存模型檔案與資料集檔案的基礎功能。在此基礎上，我們更期望能實現模型檔案與資料集檔案的快速使用。在專案初期，我們曾採用一種尚不成熟的方案，即在啟動容器（Pod）時，透過克隆方式將模型檔案複製到容器內以啟動容器。然而，由於平臺主要面向大模型儲存，模型檔案體積龐大，導致該流程效率低下。
其二，支援 Container Storage Interface（CSI），平臺底層採用 K8s 架構，若缺乏 CSI 支援，諸多 K8s 特性將無法使用，可能引發運維難題，甚至需要額外進行配置工作
此外，平臺還需支援 POSIX 協議。目前，多數深度學習處理框架，如 Transformer 和 TensorFlow，均基於 POSIX 協議構建。若平臺不支援該協議，則需自行實現儲存協議層，這將增加開發複雜度與工作量。
最後，儲存配額管理。實驗室的儲存資源有限，若不對使用者儲存進行限制，單個使用者可能過度佔用儲存空間，導致資源迅速耗盡。同時，缺乏配額管理也將影響對未來儲存需求的準確評估與合理規劃。
早期儲存架構及問題專案初期，鑑於底層採用 K8s 架構，儲存版本管理借鑑了 Hugging Face 的模式，選用 Git 進行管理，涵蓋分支與版本控制。然而，實踐過程中發現，該方案存在明顯弊端。實驗室的學生與教師群體，尤其是學生，對 Git 操作不夠熟悉，導致使用過程中問題頻發。
初期儲存架構
在儲存架構設計上，最初採用了極為簡單的方案：啟動 Pod 時掛載本地磁碟，透過 K8s PVC 實現磁碟掛載。此方案的優勢在於速度快，但缺陷同樣突出。由於眾多同學同時使用，Pod 可能分佈於不同節點，每個節點均需同步模型檔案，造成大量資源浪費。
為解決上述問題，我們引入了 Network File System（NFS）替代純硬碟方案。NFS 作為成熟方案，具有搭建簡便的優點，尤其契合實驗室運營團隊規模較小的實際情況。同時，NFS 獲得了官方 K8s CSI 的支援，進一步提升了其吸引力。
（NFS 架構）
在專案初期，NFS 方案表現尚可。當時平臺僅在組內小範圍使用，使用者數量少，訓練與微調任務不多，模型資料量也有限。但隨著專案逐步完善，進入全實驗室內測階段，使用者數量激增，模型與資料量大幅增加，NFS 方案的侷限性逐漸顯現。
一方面，大模型檔案數量增多，磁碟佔用率持續攀升。由於採用本地磁碟，擴容操作繁瑣複雜。另一方面，使用 NFS 需自行管理儲存，增加了管理難度。更為關鍵的是，隨著使用者數量的增加，效能瓶頸問題凸顯，模型訓練與推理速度顯著變慢。例如，原本僅需幾十小時即可完成的模型訓練任務，在使用者數量增多後，耗時大幅延長，甚至出現一個週末過去仍未訓練完成的情況。
此外，NFS 缺乏分散式支援，也未找到理想的分散式解決方案。若強行實現，只能複製 NFS 例項，這不僅無法解決單點故障問題，反而可能因伺服器宕機導致整個叢集儲存癱瘓。
為解決上述問題，我們對 JuiceFS 進行了深入調研，並最終選定其作為新的儲存方案。JuiceFS 採用資料與元資料分離儲存的架構。檔案資料本身會被切分儲存在物件儲存，而元資料則可以儲存在 Redis、MySQL、TiKV、SQLite 等多種資料庫中，使用者可以根據場景與效能要求進行選擇。
（JuiceFS 社群版架構圖）
在底層物件儲存選擇上，實驗室內部此前已搭建了 MinIO 叢集，且運維團隊對 MinIO 較為熟悉，因此未進行過多調研，便直接採用。同時，考慮到 Redis 搭建便捷且實驗室內部已有 Redis 叢集，可直接複用，故選用 Redis 作為元資料引擎。
（引入 JuiceFS 後的架構）
然而，在後續使用過程中，我們發現自行維護物件儲存面臨諸多困難。運維團隊在儲存管理方面經驗不足，導致各類問題頻發。鑑於此，我們計劃在未來對儲存架構進行最佳化升級：將自行搭建的 MinIO 叢集替換為商業物件儲存服務，以提升儲存的穩定性與可靠性；將 Redis 升級為 TiKV，以增強分散式儲存能力與效能表現。
我們之所以選擇 JuiceFS，主要基於以下幾個關鍵因素：
-
高效能與彈性儲存：這是我們極為看重的一點。高效能儲存能夠顯著提升模型的推理與訓練速度，從而最佳化整體業務處理效率，滿足平臺對高效運算的需求。
-
簡單易用與分散式架構：JuiceFS 使用簡便，降低了使用門檻與運維複雜度。作為分散式檔案系統，它有效規避了單點故障風險，保障了儲存系統的穩定性和可靠性，為業務連續性提供了有力支撐。
-
K8s 支援：與底層 K8s 架構深度相容，便於在容器化環境中進行部署與管理，提升了資源排程與應用的靈活性。
-
POSIX 支援：遵循 POSIX 協議，與大多數深度學習框架（如 Transformer、TensorFlow 等）無縫適配，避免了協議層面的適配難題，簡化了開發流程。
-
配額管理：提供精細化的儲存配額管理功能，可對使用者儲存空間進行合理限制，防止個別使用者過度佔用儲存資源，保障了儲存資源的公平分配與有效利用。
在 JuiceFS 的實際使用過程中，我們發現了諸多超出預期的實用功能，為平臺運營與使用者體驗帶來了顯著提升：
-
快取預熱功能：在部署階段，我們利用 JuiceFS 的快取預熱功能，將常用的大模型資料提前載入到常用計算節點的快取中。如此一來，當同學使用這些計算節點進行模型推理或訓練時，能夠直接從快取中快速讀取資料，大幅縮短資料載入時間，顯著提升任務執行效率。
-
快速克隆功能：JuiceFS 支援透過元資料克隆實現快速資料複製。鑑於我們內部存在將儲存在檔案系統中的檔案克隆到實際儲存的同步機制，該功能有效滿足了快速資料複製的需求，提高了資料同步效率，降低了資料遷移成本。
-
與 Prometheus 和 Grafana 的監控整合：JuiceFS 具備與 Prometheus 和 Grafana 監控系統的整合能力，使我們能夠輕鬆將其接入現有的監控體系。透過統一的監控平臺，我們可以即時、全面地掌握儲存系統的執行狀態、效能指標等關鍵資訊，便於及時發現並解決潛在問題，保障系統穩定執行。
-
回收站功能：以往使用 NFS 時，曾出現學生誤刪工作程式碼且因未做非同步備份而無法找回的尷尬情況。JuiceFS 的回收站功能有效解決了這一問題，當用戶誤刪檔案時，檔案會暫時存放在回收站中，在一定時間內可進行恢復操作，避免了因誤刪導致的資料丟失風險，保障了使用者資料的安全性與完整性。
-
控制檯功能：JuiceFS 控制檯提供了對所有區域中與 JuiceFS 相關的 PV（持久化卷）和 PVC（持久化卷宣告）的集中管理功能。透過控制檯，運維人員可以方便地檢視、監控和管理儲存資源，簡化了運維流程，提高了管理效率。
-
SDK 支援：早在 JuiceFS SDK 商業版上線之初，我們便予以關注。後續，我們計劃針對 SDK 開展相關嘗試，探索其在業務場景中的更多應用可能性，以進一步挖掘 JuiceFS 的潛力，為平臺發展注入新的動力。
在開發環境中，我們採用 Helm 進行 JuiceFS 的部署。Helm 的部署方式極為簡便，僅需修改 values.yaml 配置檔案，即可實現一鍵部署，且在部署過程中基本未遭遇明顯阻礙。
不過，在部署過程中仍遇到一個小問題。由於實驗室內部伺服器叢集處於內網環境，禁止直接連線外網，我們搭建了內網映象倉庫用於儲存 JuiceFS 映象。然而，在修改 values.yaml 檔案後進行部署時，發現部署失敗。經排查，系統在嘗試拉取 juicefs.mount 映象檔案時出現問題，推測此映象拉取需要額外配置。隨後，我們在官方配置文件中找到定製化映象的相關說明，透過使用定製化映象成功解決了部署問題。
為加速模型推理過程，我們啟用了 JuiceFS 的快取和模型預熱功能。在模型推理任務執行前，提前將相關資料預熱至快取中。當實際推理任務啟動時，系統可直接從快取中讀取資料，避免了頻繁從底層儲存讀取資料帶來的效能損耗，顯著提升了推理效率。
我們為實驗室的每位學生和教師分配了獨立的目錄配額。透過這種精細化的配額管理，有效控制了每個賬號的儲存資源使用量，防止個別使用者過度佔用儲存空間，確保了儲存資源的公平分配與合理利用。同時，基於目錄配額，我們計劃在內部構建類似於算力資源的計費體系，依據使用者對儲存資源的佔用情況進行費用核算，以實現資源的精細化管理。
對於部分官方模型檔案，為保障其完整性與安全性，我們設定了只讀模式。在該模式下，學生無法對這些模型檔案進行修改操作，避免了因誤操作或惡意修改導致模型檔案損壞或資料洩露的風險。
控制檯功能啟用啟用 JuiceFS 控制檯後，運維人員能夠即時監控訓練過程中所有 PV（持久化卷）和 PVC（持久化卷宣告）的狀態。透過控制檯，運維人員可以直觀地檢視儲存資源的使用情況、效能指標等資訊，及時發現並解決潛在問題，為儲存系統的穩定執行提供了有力保障。
在儲存架構設計上，我們首先掛載一個大的動態儲存卷，然後在底層將其細分至每個學生和教師。這種動態配置方式能夠根據實際需求靈活分配儲存資源，提高了儲存資源的利用率，同時也便於對不同使用者的儲存使用情況進行獨立管理和監控。
當前儲存架構中，底層採用物件儲存，並劃分為兩個 S3 桶：S3 桶 1 和 S3 桶 2。其中，git 和 git lfs 檔案儲存在 S3 桶 1 中。JuiceFS 會定期從 S3 桶 1 同步檔案，以確保資料的即時性和一致性。
這樣的架構我們也是遇到了一些問題：
-
儲存冗餘：由於採用上述同步機制，同一個大檔案可能會在儲存系統中儲存兩份，導致儲存空間被大量佔用，增加了儲存成本。
-
Git 倉庫可拓展性弱：實驗室使用的開源 GitLab 倉庫在可拓展性方面存在不足。例如，在建立 Git 使用者時，不僅需要在自身的使用者表中建立使用者資訊，還需在開源 GitLab 中再次建立使用者，操作流程繁瑣，增加了管理成本。
-
大檔案同步效率低：以往架構中，JuiceFS 從 Git 倉庫同步大檔案時採用 git 克隆方式，這種方式在處理大模型檔案時效率極低，導致同步過程緩慢，影響了整體業務處理效率。
未來我們準備去做一些最佳化以解決上述問題和最佳化我們的平臺使用：
針對大檔案同步效率低的問題，我們計劃對開源 Git 服務端進行自定義開發，構建一個統一的檔案處理中間層。在該中間層中，利用 JuiceFS 的元資料克隆功能實現檔案同步。相較於傳統的 git 克隆方式，元資料克隆能夠顯著提高同步速度，快速完成模型檔案的同步任務，提升整體業務流程的效率。
為進一步提升使用者體驗，我們計劃對 SDK 進行定製開發，重點針對 Git 客戶端或 Transformer 庫進行最佳化。透過整合 JuiceFS 的快速克隆功能，使實驗室的老師和同學即便使用自有計算資源，也能夠快速在自己的機器上獲取並使用模型檔案和資料集檔案。
目前，社群版 JuiceFS 似乎不支援儲存檔案的許可權管理。為滿足實驗室對資料安全和管理的嚴格要求，我們希望在未來能夠對 JuiceFS 進行二次開發，實現更完善的許可權管理功能。透過精細化的許可權控制，確保不同使用者對儲存資源的訪問和操作符合其許可權範圍，保障資料的安全性和隱私性。
孫瑋，中國科學院計算所後端開發工程師
