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

在大模型的背景下，存儲系統(tǒng)需處理巨量數(shù)據(jù)和復雜文件操作，要求支持高并發(fā)和高吞吐量。此外，還需應對版本管理、模型訓練性能優(yōu)化和多云分發(fā)的挑戰(zhàn)。

為解決這些問題，團隊基于 JuiceFS 開發(fā)了一個模型倉庫，支持用戶訓練過程存儲 checkpoint，并且控制面支持用戶從各個云環(huán)境上傳并統(tǒng)一管理模型。通過 JuiceFS CSI 組件，好未來將模型倉庫掛載到各個集群中，大模型文件掛載配置只需 1-3 分鐘，使得 AI 應用彈性變得更加容易。

此外，通過實施權限控制、克隆備份等策略，有效減少了用戶誤操作的損失并提高了數(shù)據(jù)安全性。目前好未來在多云多地部署了兩套元數(shù)據(jù)和數(shù)據(jù)倉庫；對象存儲的使用規(guī)模達 6TB，存儲超過 100 個模型。

01 大模型背景下模型倉庫的挑戰(zhàn)

在以往傳統(tǒng)的 DevOps 研發(fā)流程中，我們通常以容器鏡像為交付物，即由 Docker Builder 構建出一個鏡像，然后通過 docker push 命令將其推送至 Docker Hub 或其他鏡像倉庫中。客戶端的數(shù)據(jù)面則會通過 Docker 的方式，從中心鏡像倉庫拉取鏡像至本地，這一過程中可能會采用一些加速手段以提高效率。

到 AI 場景時，情況就有所不同了。以訓練任務為例，它可能會使用 Torch Save、Megatron save_checkpoint或其他方式生成一個序列化的文件，這個文件隨后會以 Linux POSIX 方式寫入到存儲中，這個存儲可以是對象存儲（如阿里云的 OSS）或文件系統(tǒng)（如 GPFS 或 NFS）。簡而言之，訓練任務通過寫文件系統(tǒng)的方式，將模型寫入到遠程存儲中，從而實現(xiàn)了模型的上傳。整個過程中還包含一些評估步驟，但在此我們略去不談，以精簡描述整個流程。與傳統(tǒng) IT 交付中僅僅涉及鏡像的推送和拉取不同，AI 場景需要處理更大規(guī)模的數(shù)據(jù)和更復雜的文件操作，對存儲系統(tǒng)的要求更為苛刻，常常需要高并發(fā)和高吞吐量的支持。

到了推理階段，在容器的場景下，需要通過 CSI 方式去掛載 NFS 或者 GPFS 系統(tǒng)或對象存儲系統(tǒng)來達到將遠程的模型拉取到容器場景中。從表面上看，這個流程似乎并無問題，也能夠正常工作。然而，在實際運行過程中，我們還是發(fā)現(xiàn)了不少明顯的問題。

• 首要問題是缺乏版本管理。對于傳統(tǒng)的容器鏡像，我們有明確的交付物和版本信息，包括上傳者、大小等詳細信息。然而，在模型倉庫中，由于模型通常是以 Linux 文件系統(tǒng)的方式存儲的（文件或文件夾形式），因此缺乏版本管理和元數(shù)據(jù)信息，如上傳者、修改者等。

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

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

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

訓練場景的存儲需求：

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

推理場景的存儲需求：

• 模型版本管理與服務化：當模型更新至新版本時，需要進行版本發(fā)布和審批流程。此外，在模型服務化過程中，可能需要頻繁地擴展或收縮使用的 GPU 資源，這通常在夜間進行資源釋放，在白天進行資源擴展。
• 高讀吞吐性能：由于白天需頻繁拉取模型副本以應對資源擴展，存儲系統(tǒng)需支持高效的讀操作，確?？焖夙憫Ｐ屠⌒枨?。

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

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

02 存儲選型：如何在成本、性能、穩(wěn)定性之間取舍？

核心考量點

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

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

第三，性能是關鍵因素。根據(jù)之前的背景介紹，模型倉庫的讀寫性能都有較高要求。因此，我們需要在單個 IDC 或單個云上實現(xiàn)模型讀寫流量的閉環(huán)，以確保高性能；

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

主要技術選型對比

Fluid + Alluxio + OSS：該方案在前幾年已經相對成熟并受到廣泛關注。它融合了云原生的編排能力和對象存儲的加速能力，實現(xiàn)了多云技術上的統(tǒng)一。無論是在阿里云、騰訊云還是自建的 IDC 中，都能采用這一方案。此外，該方案在社區(qū)的應用也相當廣泛。

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

GPFS：它是一個商業(yè)并行文件系統(tǒng)，讀寫性能強勁，且我們集團已經購買了這一產品。此外，GPFS 在處理海量小文件方面也具有顯著優(yōu)勢。然而，它的劣勢同樣明顯。首先，它無法實現(xiàn)多云同步，這意味著我們在 IDC 購買的 GPU 無法在其他云上再購買一套 GPFS，成本高昂。其次，GPFS 的容量價格也非常昂貴，是 OSS 的好幾倍。

CephFS：我們集團內對該技術有一定的技術沉淀和優(yōu)勢。然而，它同樣無法實現(xiàn)多云同步，運營成本較高。

JuiceFS：它的優(yōu)勢在于支持多云同步，運維簡單，組件較少且觀測性較好。成本方面，它基本上只有對象存儲的費用，除了元數(shù)據(jù)管理外，沒有其他額外成本。此外，JuiceFS 既可以在云上搭配對象存儲使用，也可以在 IDC 搭配 Ceph Rados 使用。綜合考慮以上因素，我們選擇了 JuiceFS 作為支持大模型模型倉庫的底層存儲系統(tǒng)。

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

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

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

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

在元數(shù)據(jù)管理方面，我們選擇了 Redis。相較于 OceanBase 或 TiKV 等復雜元數(shù)據(jù)管理引擎，我們選擇 redis 主要出于以下考慮：我們僅將其用于大文件的存儲，而每個文件的大小可能達到數(shù) GB。因此，我們判斷其數(shù)據(jù)量相對較小，無需采用復雜的元數(shù)據(jù)管理引擎，以減輕運維負擔。

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

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

在面對某些挑戰(zhàn)時，當需要在白天大規(guī)模擴容推理服務時，以擴容 HPA（Horizontal Pod Autoscaler）為例，這種定點擴容會導致大量推理服務同時啟動，并需要迅速讀取大量的模型文件。這種情況下，如果沒有本地緩存的支持，帶寬消耗將極為巨大。

為了應對這一挑戰(zhàn)，我們采用了 “warm up” 策略。即在定時擴容之前，通過預熱的方式將即將被讀取的模型文件預先加載到緩存中。這樣做可以顯著提升擴容的彈性速度，確保推理服務能夠迅速啟動并投入運行。

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

管理端主要聚焦于上傳和下載功能。我們自主開發(fā)了一個客戶端，該客戶端支持通過 S3 協(xié)議上傳模型文件。S3 網關會接收并轉化這些請求，然后與元數(shù)據(jù)系統(tǒng)進行交互，如 Redis 等。

在我們的應用場景中，還有一項重要的設計是對相同文件進行去重處理。我們采用了類似于 Docker 鏡像倉庫的設計思路，即為每個文件計算 MD5 值。如果兩個文件的 MD5 值相同，則不會進行重復上傳。這一設計不僅節(jié)省了存儲空間，還提高了上傳效率。

此外，在更新模型時，我們還會保留一些快照。使用 JuiceFS 快照功能復制文件時，它并不會在 OSS 中新增文件，而只是在元數(shù)據(jù)中進行記錄。這種方式使得我們在進行模型更新和快照保留時更加便捷高效。

04 未來展望

按需同步多云的模型倉庫：我們目前的做法是采取定期批量同步的方式，將 JuiceFS 在某個云上的集群數(shù)據(jù)進行同步。然而，這種做法相對簡單粗暴，可能無法滿足未來對于數(shù)據(jù)同步的更高需求。因此，我們計劃進行改進，實現(xiàn)一個標記型的同步系統(tǒng)。該系統(tǒng)將能夠識別需要同步的區(qū)域，并在收到模型上傳事件后，自動將這些數(shù)據(jù)同步到多云平臺上。此外，我們還將引入一些 warm up 策略，以優(yōu)化數(shù)據(jù)同步的過程，提高同步效率和準確性。

擴展單機 cache 和分布式 cache：我們目前單機使用了3T MVME的 cache 方式，在短期內來看，這種方式的容量還是相對充足的。然而，從長遠來看，為了滿足更大的數(shù)據(jù)存儲和訪問需求，我們將基于一致性哈希的原理，在客戶端自主研發(fā)一個分布式 cache 組件。這個組件將能夠更大程度地提升開啟的容量和命中率，從而滿足未來對于數(shù)據(jù)存儲和訪問的更高要求。

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