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