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

JuiceFS發表於2024-11-08

好未來,前身學而思,於 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 社群與大家共同交流。

相關文章