好未來：多雲環境下基於 JuiceFS 建設低運維模型倉庫

好未來，前身學而思，於 2010 年在美國紐約證券交易所上市。公司積極將大模型研究應用於教學產品中，近期推出了數學領域的千億級大模型。

在大模型的背景下，儲存系統需處理巨量資料和複雜檔案操作，要求支援高併發和高吞吐量。此外，還需應對版本管理、模型訓練效能最佳化和多雲分發的挑戰。

為解決這些問題，團隊基於 JuiceFS 開發了一個模型倉庫，支援使用者訓練過程儲存 checkpoint，並且控制面支援使用者從各個雲環境上傳並統一管理模型。透過 JuiceFS CSI 元件，好未來將模型倉庫掛載到各個叢集中，大模型檔案掛載配置只需 1-3 分鐘，使得 AI 應用彈性變得更加容易。

此外，透過實施許可權控制、克隆備份等策略，有效減少了使用者誤操作的損失並提高了資料安全性。目前好未來在多雲多地部署了兩套後設資料和資料倉儲；物件儲存的使用規模達 6TB，儲存超過 100 個模型。

01 大模型背景下模型倉庫的挑戰

在以往傳統的 DevOps 研發流程中，我們通常以容器映象為交付物，即由 Docker Builder 構建出一個映象，然後透過 docker push 命令將其推送至 Docker Hub 或其他映象倉庫中。客戶端的資料面則會透過 Docker 的方式，從中心映象倉庫拉取映象至本地，這一過程中可能會採用一些加速手段以提高效率。

到 AI 場景時，情況就有所不同了。以訓練任務為例，它可能會使用 Torch Save、Megatron save_checkpoint或其他方式生成一個序列化的檔案，這個檔案隨後會以 Linux POSIX 方式寫入到儲存中，這個儲存可以是物件儲存（如阿里雲的 OSS）或檔案系統（如 GPFS 或 NFS）。簡而言之，訓練任務透過寫檔案系統的方式，將模型寫入到遠端儲存中，從而實現了模型的上傳。整個過程中還包含一些評估步驟，但在此我們略去不談，以精簡描述整個流程。與傳統 IT 交付中僅僅涉及映象的推送和拉取不同，AI 場景需要處理更大規模的資料和更復雜的檔案操作，對儲存系統的要求更為苛刻，常常需要高併發和高吞吐量的支援。

到了推理階段，在容器的場景下，需要透過 CSI 方式去掛載 NFS 或者 GPFS 系統或物件儲存系統來達到將遠端的模型拉取到容器場景中。從表面上看，這個流程似乎並無問題，也能夠正常工作。然而，在實際執行過程中，我們還是發現了不少明顯的問題。

• 首要問題是缺乏版本管理。對於傳統的容器映象，我們有明確的交付物和版本資訊，包括上傳者、大小等詳細資訊。然而，在模型倉庫中，由於模型通常是以 Linux 檔案系統的方式儲存的（檔案或資料夾形式），因此缺乏版本管理和後設資料資訊，如上傳者、修改者等。

• 其次，模型倉庫無法實現加速和多雲分發。在 Docker 場景中，我們可以使用如 Dragonfly 等工具進行加速。但是，在使用 NFS、GFS 或 OSS 等儲存系統時，卻缺乏一個有效的加速方案。同時，也無法實現多雲分發。以 NFS 為例，它基本上是閉環於一個 IDC 內部的，無法實現跨 IDC 甚至跨雲的掛載。即使能夠實現掛載，其速度也會非常慢，因此我們可以認為它無法實現多雲分發。

• 最後，安全性差。在推理場景下，整個模型倉庫需要掛載到容器中。如果客戶端的掛載許可權過大（例如掛載了一個包含大量模型的目錄），就可能導致模型洩露或誤刪除的問題。特別是當掛載方式為可讀可寫時，客戶端甚至有可能刪除模型檔案。

由此衍生出不同場景對模型倉庫的儲存需求。

訓練場景的儲存需求：

• 模型下載與處理：在演算法建模階段，需要下載並可能轉換及切分各種模型，這包括開源模型、參考模型或自設計的網路結構。例如，進行模型的 TP（Tensor Parallelism）和 PP（Pipeline Parallelism）切分。
• 高效能讀寫：訓練階段要求儲存系統具備極高的讀寫吞吐能力，以便儲存大規模的 checkpoint 檔案。這些檔案可能非常龐大，如單個 checkpoint 檔案大小接近 1TB。

推理場景的儲存需求：

• 模型版本管理與服務化：當模型更新至新版本時，需要進行版本釋出和審批流程。此外，在模型服務化過程中，可能需要頻繁地擴充套件或收縮使用的 GPU 資源，這通常在夜間進行資源釋放，在白天進行資源擴充套件。
• 高讀吞吐效能：由於白天需頻繁拉取模型副本以應對資源擴充套件，儲存系統需支援高效的讀操作，確保快速響應模型拉取需求。

此外，從管理者角度存在以下需求：

• 團隊級模型管理：模型倉庫應支援按團隊進行模型的隔離管理，確保不同團隊之間模型的隱私和獨立性。
• 詳盡的版本控制：儲存系統應能清晰記錄模型的迭代時間、版本用途等元資訊，支援模型的上傳、下載、審計和分享功能。

02 儲存選型：如何在成本、效能、穩定性之間取捨？

核心考量點

首先，要降低對雲廠商的依賴，確保技術方案在自建 IDC 以及多個雲廠商之間保持一致性和統一性；

其次，成本也是一個重要的考量因素。雖然資金充足可以支援更好的解決方案，但成本效益分析同樣重要。我們需要綜合考慮各種儲存方案的成本，包括本地磁碟、GPFS 以及物件儲存（如 OSS）等；

第三，效能是關鍵因素。根據之前的背景介紹，模型倉庫的讀寫效能都有較高要求。因此，我們需要在單個 IDC 或單個雲上實現模型讀寫流量的閉環，以確保高效能；

最後，穩定性也是不可忽視的因素。我們不會為了支撐模型倉庫而引入過高的運維複雜度。因此，對元件的繁雜程度和穩定性都有很高的要求。

主要技術選型對比

Fluid + Alluxio + OSS：該方案在前幾年已經相對成熟並受到廣泛關注。它融合了雲原生的編排能力和物件儲存的加速能力，實現了多雲技術上的統一。無論是在阿里雲、騰訊雲還是自建的 IDC 中，都能採用這一方案。此外，該方案在社群的應用也相當廣泛。

然而，它也存在一些不足。例如，它無法與 Ceph Rados 進行結合，這在我們集團內部是一個已有的技術棧。同時，該方案的運維複雜度較高，元件較多且資源消耗較大。對於大檔案的讀取速度，該方案的表現也並不理想。此外，客戶端的穩定性也有待進一步驗證。

GPFS：它是一個商業並行檔案系統，讀寫效能強勁，且我們集團已經購買了這一產品。此外，GPFS 在處理海量小檔案方面也具有顯著優勢。然而，它的劣勢同樣明顯。首先，它無法實現多雲同步，這意味著我們在 IDC 購買的 GPU 無法在其他雲上再購買一套 GPFS，成本高昂。其次，GPFS 的容量價格也非常昂貴，是 OSS 的好幾倍。

CephFS：我們集團內對該技術有一定的技術沉澱和優勢。然而，它同樣無法實現多雲同步，運營成本較高。

JuiceFS：它的優勢在於支援多雲同步，運維簡單，元件較少且觀測性較好。成本方面，它基本上只有物件儲存的費用，除了後設資料管理外，沒有其他額外成本。此外，JuiceFS 既可以在雲上搭配物件儲存使用，也可以在 IDC 搭配 Ceph Rados 使用。綜合考慮以上因素，我們選擇了 JuiceFS 作為支援大模型模型倉庫的底層儲存系統。

03 好未來模型倉庫實踐方案

訓練場景中模型倉庫讀寫設計: 單雲訓練

首先，聚焦於訓練場景中的模型倉庫讀寫設定。我們採用單雲訓練策略，即在單一雲平臺上進行模型訓練，而非跨多雲進行，這主要考慮到實際操作中的可行性和效率。

針對訓練場景下的讀寫需求，我們制定了以下方案：我們將大量 GPU 機器上冗餘的 NVMe 磁碟組成一個 ceph 叢集，使用 JuiceFS 對接 Rodos， 從而實現 ceph 叢集的讀寫操作。 在模型訓練過程中，模型會以 JuiceFS CSI 方式掛載一個盤。當需要執行 checkpoint 儲存或載入時，將直接對 Rodos 進行讀寫操作。經實測，在大模型訓練過程中，checkpoint 寫入速度可達到 15GB/s。

在後設資料管理方面，我們選擇了 Redis。相較於 OceanBase 或 TiKV 等複雜後設資料管理引擎，我們選擇 redis 主要出於以下考慮：我們僅將其用於大檔案的儲存，而每個檔案的大小可能達到數 GB。因此，我們判斷其資料量相對較小，無需採用複雜的後設資料管理引擎，以減輕運維負擔。

推理場景中模型倉庫讀寫設計: 多雲推理

與訓練場景不同，推理資源通常分佈在多雲平臺上，如阿里雲、騰訊雲等。在這些雲平臺上，我們不會購買大量的 NVMe 機器，因為雲上本身具備物件儲存能力。因此，我們採用了 JuiceFS 的經典模式，即 JuiceFS 加上 Redis，與雲廠商的物件儲存組成一個叢集。在推理過程中，模型檔案以只讀方式掛載，以避免程式對其進行修改。此外，我們還設計了一個面向多雲環境的間歇性同步方案，以確保模型能夠同步到所有云的 JuiceFS 上。

在面對某些挑戰時，當需要在白天大規模擴容推理服務時，以擴容 HPA（Horizontal Pod Autoscaler）為例，這種定點擴容會導致大量推理服務同時啟動，並需要迅速讀取大量的模型檔案。這種情況下，如果沒有本地快取的支援，頻寬消耗將極為巨大。

為了應對這一挑戰，我們採用了 “warm up” 策略。即在定時擴容之前，透過預熱的方式將即將被讀取的模型檔案預先載入到快取中。這樣做可以顯著提升擴容的彈性速度，確保推理服務能夠迅速啟動並投入執行。

管理端：模型倉庫上傳與下載的設計

管理端主要聚焦於上傳和下載功能。我們自主開發了一個客戶端，該客戶端支援透過 S3 協議上傳模型檔案。S3 閘道器會接收並轉化這些請求，然後與後設資料系統進行互動，如 Redis 等。

在我們的應用場景中，還有一項重要的設計是對相同檔案進行去重處理。我們採用了類似於 Docker 映象倉庫的設計思路，即為每個檔案計算 MD5 值。如果兩個檔案的 MD5 值相同，則不會進行重複上傳。這一設計不僅節省了儲存空間，還提高了上傳效率。

此外，在更新模型時，我們還會保留一些快照。使用 JuiceFS 快照功能複製檔案時，它並不會在 OSS 中新增檔案，而只是在後設資料中進行記錄。這種方式使得我們在進行模型更新和快照保留時更加便捷高效。

04 未來展望

按需同步多雲的模型倉庫：我們目前的做法是採取定期批次同步的方式，將 JuiceFS 在某個雲上的叢集資料進行同步。然而，這種做法相對簡單粗暴，可能無法滿足未來對於資料同步的更高需求。因此，我們計劃進行改進，實現一個標記型的同步系統。該系統將能夠識別需要同步的區域，並在收到模型上傳事件後，自動將這些資料同步到多雲平臺上。此外，我們還將引入一些 warm up 策略，以最佳化資料同步的過程，提高同步效率和準確性。

擴充套件單機 cache 和分散式 cache：我們目前單機使用了3T MVME的 cache 方式，在短期內來看，這種方式的容量還是相對充足的。然而，從長遠來看，為了滿足更大的資料儲存和訪問需求，我們將基於一致性雜湊的原理，在客戶端自主研發一個分散式 cache 元件。這個元件將能夠更大程度地提升開啟的容量和命中率，從而滿足未來對於資料儲存和訪問的更高要求。

希望這篇內容能夠對你有一些幫助，如果有其他疑問歡迎加入 JuiceFS 社群與大家共同交流。