作者 | 曾奧涵

智譜成立于 2019 年，源于清華大學計算機系知識工程實驗室 (KEG) 的技術成果。2022 年，智譜訓練并開源了中英雙語預訓練模型 GLM-130B，其性能媲美 GPT-3。2023 年發布了千億參數極速對話模型 ChatGLM 系列，在 Hugging Face 社區獲得了超過一千萬次下載。2024 年，發布的旗艦模型 GLM-4-Plus 在 SuperBench 大模型評測中位列世界前三。

智譜的基礎設施團隊經歷了從支持不足 10 人發展到要支持 200 多人研發團隊的過程。本文將介紹智譜基礎設施發展的初期、擴張和成熟三個階段的挑戰與實踐經驗。希望通過這些分享，激發新的思路和觀點。

1引言

我們從 2021 年底開始參與模型的訓練，負責 GLM-130B 高精度千億模型的訓練工作。團隊的發展與模型的演進密切相關。在初期階段，集群數量較少，研發團隊人數不到 10 人，主要目標是支持基座模型的研發。隨著大模型的崛起，團隊進入了擴張階段，集群數量增加，我們采用了靈活的資源調配策略。如今，團隊已進入成熟階段，集群數量增至 10 個以上，服務的用戶人數超 200 人。此時，團隊的關注點轉向如何提升資源使用效率，減少多套集群帶來的數據流轉和調度成本。

（智譜 AI 模型研發歷史）

目前，我們 GLM 基礎設施團隊的主要職責可以分為三大塊：

1. 基礎設施建設：這一部分主要包括集群搭建、GPU 上架、計算網絡的組網以及存儲規劃等底層設施的建設工作。

2. 基礎設施運維：我們負責保障設施的穩定運行，優化集群的穩定性，主動發現并處理故障節點。此外，還涉及一些繁瑣的任務，如數據遷移、數據拷貝以及數據流轉的管理工作。

3. 支持研發團隊的平臺建設：我們為公司研發團隊提供了“GLM 機器學習平臺”。該平臺支持公司整體研發需求，整合了 GPU、存儲、鏡像等資源，幫助研發團隊進行算法開發與迭代。

目前，我們的資源高度分散，采用云上云下混合模式，集群數量超過 10 個，分布在不同地域，且 GPU 型號和網絡類型各異，導致異構性問題突出。同時，存儲系統也存在混合性，進一步加劇了資源管理的復雜性。最后，由于資源更迭速度較快，數據遷移和集群清理成為瓶頸，而數據初始化速度對訓練至關重要。

接下來，我將詳細介紹我們如何從最初的一兩個集群發展到如今這種復雜的資源環境，以及我們采取了哪些措施來應對這些復雜的資源。

2初期：從裸金屬集群訓練到平臺建設探索

裸金屬集群訓練模型

最早在 2022 年左右，我們開始訓練 GLM-130B 的模型，當時尚未有成熟的調度平臺支持。團隊初期的目標非常明確，即支持基座模型的預訓練。我們通過租賃一批機器，并以裸金屬的形式進行交付，整個過程依賴手動管理。團隊成員和任務是直接與機器綁定的，預訓練任務與實驗任務、微調任務分別分配給不同的機器，任務之間通過共享存儲進行協調，環境管理完全由用戶通過 MiniConda、Docker 等工具自行完成。這種模式存在諸多問題。

首先，環境配置極為困難。由于機器資源分散，團隊將多個小組分配到不同的機器上，導致驅動、庫和軟件包等版本不一致。這種不一致會造成許多訓練任務無法正常運行，環境配置成為了一個巨大的難題。

其次，人力成本較高。由于沒有統一的平臺工具，所有的任務必須手動提交和管理，尤其是在裸機環境中。團隊需要定期值班，監控任務是否正常運行，或通過腳本手動檢查任務狀態。如果任務失敗，排查問題非常繁瑣。雖然可以通過手動操作將故障的 GPU 節點移除，但有時節點問題較復雜，缺乏有效的工具時，排查過程可能需要幾個小時，造成很大的心智負擔。

（裸金屬集群訓練模型）

最后，資源管理也非常困難。在沒有統一任務管理系統的情況下，團隊成員只能按照固定的機器進行工作，且很難協調機器的使用情況。由于機器經常出現故障，我們無法清楚知道哪些機器正在運行，哪些機器有問題，整體資源管理效率低下。

適合大模型訓練的簡易調度平臺

盡管裸金屬集群這種模式能夠加快推動基座模型訓練工作的開展 ，但由于管理和操作上的種種問題，我們意識到這種裸金屬的方式并不理想，我們開始探索開發平臺化的管理工具，以應對這些挑戰。

整理需求后，我們發現調度平臺至少要滿足以下 3 個需求：

1. 訓練任務化。能夠將訓練抽象成一個任務，通過 MPI/PyTorchDDP 框架進行拉起。能夠感知任務的不同生命周期，完成狀態判斷和轉移。能夠支持多任務的靈活調度。

2. 任務穩定性。能夠查詢任務日志，監控任務狀態，在任務生命周期變更時通知用戶。

3. 無人值守訓練。能夠完成任務失敗自動重試，自動推進訓練任務進行。能夠自動識別故障節點，自動封禁。能夠篩查慢速節點，提高效率。

（簡易調度平臺）

由于我們的團隊起源于實驗室背景，最初我們嘗試了一些類似于 Slurm 調度工具的方案，但發現這些工具更多地適用于超算環境，并不完全符合大模型時代多級訓練的需求。因此，我們決定自行開發一套簡易的調度平臺。

于是，我們轉向了 Kubernetes，通過 K8s 屏蔽底層異構資源差異，提供統一接口， 通過設備插件注入訓練所需的 GPU、RDMA 等設備。同時，將訓練環境鏡像化，訓練數據和結果存放在 PVC 中。

在此基礎上，我們的調度平臺實現了兩個 CR（Custom Resource）。

• 第一個是訓練任務，它定義了任務所需的鏡像、掛載的數據卷以及節點數，并負責維護整個任務的生命周期。

• 第二個是任務隊列，收集節點信息，將訓練任務成組調度到合適到節點。

通過簡易調度平臺，我們實現了訓練任務化。但是，由于 GPU 設備本身的高故障率，我們仍然需要一個自動化方案來實現無人值守訓練。

任務穩定性： Node Agent - 主動故障發現與處理

在任務的穩定性方面，我們希望能夠查詢任務的日志狀態，并在任務生命周期內進行狀態變更。例如，當任務失敗時，我們希望能夠及時通知用戶。此外，我們還期望實現無人值守的訓練，即在任務失敗時，系統能夠自動重試并繼續推進任務的運行，同時進行故障檢測。

為此，我們采用了 Node Agent 的方式來主動進行故障檢測與發現。通過節點故障探查和運維自動化、故障告警等手段，我們實現了故障的快速響應。

以 GPU 掉卡為例，故障處理流程大致如下：當 GPU 故障時， Node Agent 會首先感知到掉卡問題，并立即禁止該故障節點的調度同時將故障信息通知運維。由于 GPU 掉卡后任務無法繼續運行，任務將直接失敗。任務失敗后，系統會自動觸發重試機制，確保任務能夠繼續執行。

我們通過 Node Agent 主動封禁了故障節點，當任務失敗后，系統會觸發重試機制。重試時，任務會被調度到健康的節點上，確保任務能夠正常運行。一旦任務調度成功，我們還通過飛書電話等通知工具及時告知模型訓練人員，以便他們關注任務的健康狀況。這一流程有效支持了我們最初基座模型的訓練需求。

3擴張期：構建機器學習平臺

隨著團隊的擴張，我們的規模增長到接近 50 人，同時資源也擴展到 3 到 5 個集群。訓練任務的種類也大幅增加，原先只做文本模型，現在已經涉及到圖像生成、視頻生成等多個領域，訓練任務變得更加多樣化。

在這個過程中，運維成本也顯著上升。隨著集群數量的增加，機器和 GPU 型號的多樣化導致機器故障頻發，任務失敗的情況也變得更加頻繁。管理的復雜度也隨之增加。最初只有一個團隊進行訓練時，資源分配和內部協商相對簡單。但隨著規模的擴大，如何合理分配和管理資源，以及建立有效的統計機制，成為了新的挑戰。

另外，安全隱患問題也逐漸顯現。最早的模式是通過共享存儲來處理集群內的數據，這雖然方便，但也存在較大安全隱患。例如，某些用戶可能會不小心執行一些操作，導致存儲空間被占滿，從而影響其他任務的正常運行。

于是，我們基于 Kubernetes 構建了一個機器學習平臺，底層實現了計算、存儲和網絡的統一管理，全部通過 K8s 進行協調。調度層通過 Operator 實現，我們使用了 Kubernetes 的原生資源對象來完成資源調度，避免了復雜的開發工作，基本上遵循了 K8s 的標準做法。

在訓練平臺層，我們還需要滿足日常的開發需求，因此抽象出了開發機、訓練任務和推理任務等工作負載。同時，設計了任務隊列、存儲池和個人卷等機制，用于資源分配和權限管理。此外，我們引入了多種保障機制，確保任務的順利推進，并與運維團隊緊密配合，確保重點任務的實施。

（智譜 GLM 訓練基礎設施架構圖）

我們的目標是以下述四個特征來構建我們的機器學習平臺：

1. 易用性：我們需要提供一個統一的功能抽象，屏蔽不同業務資源的差異，確保用戶能方便地訪問和使用。此外，平臺還需要提供多種訪問方式，包括 Web 界面、 Web Shell、SSH 直連以及命令行工具（CLI），以適應不同用戶的需求。我們還需要一個靈活的資源分配機制，確保資源能根據任務需求進行合理調配。

2. 穩定性：我們希望平臺能夠實現無人值守的任務管理。在任務失敗時，系統應能夠自動重試，例如，基于已保存的 checkpoint 自動恢復訓練。整個任務生命周期中，任務狀態的變更應能及時通知相關人員，并且系統應能保留運行環境的 debug 日志，方便調試和故障排查。

3. 高效性：在任務量大、節點多的情況下，我們需要優化存儲管理，并確保鏡像能夠迅速分發到各個節點，以提高訓練效率。這包括存儲的優化和高效的資源調度，確保大規模任務的順利執行。

4. 安全性：我們希望可以進行細粒度的存儲訪問控制，以防止未經授權的訪問。例如，防止敏感數據（如 SIP 數據）被未經授權的用戶或不當操作者下載或盜取等。

平臺功能 1： 開發機抽象，共享 GPU 模式

接下來，我們介紹了平臺中幾個重要的抽象功能，并闡述了背后的設計考慮。

在傳統的開發機模式中，通常會采用獨占 GPU 和塊存儲的方式，即為每個開發機分配一個獨立的 GPU 和一個持久化的存儲（如云卷）。這種方式類似于 ECS 模式，用于長期的開發任務。我們沒有選擇這種模式，而是采用了共享 GPU 的模式，避免了 GPU 獨占。存儲方面，我們沒有使用持久化的塊設備存儲，而是依賴于 Pod 的臨時存儲，并將設備掛載在集群的共享存儲中。我們通過 K8s Pod 實現這種架構，重點提供開發機和鏡像保存功能，使得開發機更輕便且易于管理。

（智譜機器學習平臺功能：開發機抽象）

我們選擇這種開發機的設計方式，主要是考慮到大模型研發的需求。在研發過程中，很多開源模型會提供鏡像，而大模型的交付環境通常都是基于鏡像的，這使得容器化模式非常適合此類場景。使用容器模式可以直接利用現有的鏡像，而不需要額外安裝 Docker 或進行透傳，簡化了環境配置。

此外，獨占單卡會產生大量碎片化資源。研發人員可能需要頻繁切換模型，每次都需要創建獨立的開發機。如果采用獨占模式，資源碎片化嚴重，尤其在多卡部署時，這樣的資源使用效率低。共享多卡的模式能更好地支持靈活調度和調試。

考慮到我們的集群環境比較混雜，且不是每個集群都有很完善的基礎設施，因此無法為每個集群都提供專門的塊存儲設備池。為保證平臺能夠提供一個穩定的抽象，我們沒有使用塊存儲來持久化用戶數據。開發機中的數據在關閉后會丟失，若需要保存數據，用戶只能通過鏡像保存功能將環境保留。我們認為這是合理的，因為開發機本質上不應存儲數據，數據應該存儲在共享存儲中，而開發機的核心任務是作為模型開發和調試的環境。

總的來說，我們的開發機抽象設計旨在提供靈活、便捷的開發環境，同時確保平臺的穩定性和資源使用的高效性。

平臺功能 2： 訓練任務抽象

訓練任務的抽象設計與常見的任務調度模式大同小異，核心在于實現了任務隊列的調度管理。我們采用了 Gang Scheduling 機制，確保調度的任務要么全部不調度，要么能夠同時調度到位。為了提高資源分配效率，我們還實現了資源超賣策略，進一步優化了資源的整體利用。

此外，借助 Dragonfly 以及多級緩存架構的設計，在集群內部實現了基于 P2P 的鏡像分發功能，解決了大規模任務提交時的效率問題；

例如，在開發機上跑完一個 8 卡訓練任務并保存為鏡像后，使用該鏡像在本集群內提交一個 256 臺機器的任務。如果沒有 P2P 分發，拉取鏡像的時間可能超過一個小時，而通過 P2P 分發，鏡像拉取速度得到了顯著提升。

此外，基于多級緩存的設計，保存鏡像時除了向中心存儲上傳數據，還會同時加載到本集群 的自建存儲中作為一級緩存；同時在各個集群的邏輯上層，還設有統一的 Gateway 集群，緩存從互聯網拉取的鏡像，作為二級緩存，如果集群內沒有查詢到所需要的鏡像，會穿透到二級緩存拉取。

通過生產環境的上線前后對比，20G 以上鏡像拉取效率提高 3 倍以上。隨著集群內任務規模的擴大、節點數的增多，效率提高更顯著，截止目前任務啟動成功率 100%。

在任務管理方面，我們重點關注了任務的狀態通知。從任務排隊到開始運行，再到結束，我們與飛書等平臺深度集成，提供實時通知功能，確保團隊成員能夠及時掌握任務進度。對于多人協作的任務，我們還可以將任務狀態通知到團隊的群聊中，平臺的機器人會自動拉取任務信息，并向群成員發送更新。

為了實現無人值守的訓練流程，我們還設計了任務的自動重試策略，確保任務在出現問題時能夠自動恢復。

（智譜機器學習平臺功能：訓練任務抽象）

平臺功能 3： 推理服務

推理服務的需求是將訓練好的模型快速部署、測試和評估。推理架構相對簡單，主要由兩個部分組成：網關和模型。模型層負責負載均衡，啟動多個模型實例，可能是 TGI 或者 vLLM 實例，然后進行負載均衡。網關層通過鏡像啟動，處理格式轉換和策略調度等任務。

最終，推理服務通過一個 VIP 對外暴露，確保訓練集群和評測集群之間的網絡互通。評測集群可以直接通過 VIP 接入進行模型評測，從而加快整個迭代流程。

平臺功能 4： 數據處理任務抽象

在推理服務發現后，我們注意到很多用戶除了部署模型外，還需要處理數據。例如，用戶可能需要對一批數據進行處理，比如使用模型對數據進行改寫。然而，傳統的推理服務抽象并不適合這種需求。推理服務通常是一個固定的服務，比如如果需要 32 張卡，它就會擴展到 32 張卡，再擴展到 64 張卡，而這類固定抽象并不適用于數據處理任務。

數據處理任務的抽象與此不同。我們設計了一個數據處理任務隊列，任務會分配給每個 Worker 進行處理。每個 Worker 處理完任務后會結束，從而釋放資源。這意味著，處理完成后，資源不會被占用，避免了在傳統推理服務中無法釋放資源的問題。例如，如果有 1000 張卡用于視頻特征提取，傳統方式可能會導致長尾任務占用資源，資源長時間無法被釋放。

因此，我們的設計專門針對模型數據處理、特征提取等流程和 pipeline 場景，提供了一種數據處理任務抽象，確保資源高效利用并避免不必要的資源占用。

平臺保障： 多項關鍵策略確保穩定性

為了確保訓練的穩定性，我們采取了三項主要措施，這些措施涵蓋了常見的故障處理和任務恢復需求：

1. 故障主動檢測與封禁：我們使用 Node Agent 主動監控并檢測常見故障，包括驅動版本、GPU 數量、電源風扇告警、共享存儲掛載等問題。節點故障檢測還涵蓋了 GPU 的 XID ECC 錯誤、路由問題、網絡抖動等情況。如果發現故障，系統會自動封禁該節點，避免調度到故障節點上。

2. 任務自動重試機制：訓練任務通常是以任務形式提交的。如果任務因為 GPU 故障而失敗，系統會自動重試，并且由于壞節點已被封禁，新的任務會分配到健康的節點，確保任務能夠自動恢復。這種自愈機制在大多數情況下能確保任務的穩定執行。

3. 任務掛起（hang）與慢速報警：對于一些特殊情況，比如訓練速度、GPU 功率突然下降等，雖然這些問題不會直接導致任務掛掉，但可能會影響訓練效果。在這些情況下，我們會通過條件檢測識別異常并向用戶發出告警。用戶可以根據告警信息進行人工干預，避免問題進一步惡化。

通過以上這三項措施，我們能夠有效保證預訓練的穩定性，以一個訓練任務的生命周期為例，：

• 訓練任務在我們平臺內申請通過后，調度器從可使用 Pool 中分配節點，隨后智能篩查服務會使用 NCCL 對這些節點進行高性能網絡測試和 GPU 狀態探測，確保環境穩定可正常啟動訓練任務；否則重新分配節點，并將探測不通過的節點放入備池。

• 訓練任務正常啟動后，Node Agent 會實時監控、檢測節點的狀態和訓練任務的進程；主動感知訓練過程中是否存在降速、抖動以及容器內掉卡等異常；并主動感知 GPU 的 XID ECC 等異常，并識別異常類型針對性 callback 修復流程。

• 對于訓練過程中存在問題的節點，智能篩查會在訓練結束后根據 Node Agent 的 callback 進行再次篩查，并根據結果反饋給運維、機房，提起工單自動化報障、維修流程。

雖然大部分故障可以通過主動檢測來發現，但仍然存在一些極端情況下，訓練任務由于未知原因無法啟動。在這種情況下，所有已知的方法都無法解決問題，這時我們只能退回最原始的故障排查方式——二分查找。例如，如果我們有 100 個節點，發現無法啟動訓練任務時，可以將這些節點分為前 50 和后 50，逐一測試。

為了更高效地解決這個問題，我們開發了智能篩查功能，將這一過程自動化。通過智能篩查，系統能夠主動檢測并篩選出問題節點。篩查流程如下圖所示：

（智譜智能篩查流程）

在實際應用中，我們使用兩兩分組的方式進行篩查。通過對每一組節點運行 NCCL 測試，若發現某一組特別慢，基本可以確定其中有一個問題節點。通過奇偶輪換的方法，我們逐步鎖定問題節點。

通過這種智能篩查方法，我們能夠高效地識別和排除問題節點，確保訓練任務在穩定的節點上運行。即使無法完全分析故障的原因，這種自動篩查功能也能保證節點在端到端訓練中表現符合預期，從而解決大部分復雜故障問題。

4穩定期：從各集群獨立存儲到構建中心化存儲架構

隨著平臺功能的不斷迭代和完善，進入了穩定期。此時，團隊人數大幅增長，使用機器學習平臺的研發人員數量增加到 200 多人。同時，集群數量從 3~5 個增加到 10 個以上。

在前期易用性和穩定性問題基本解決的情況下，當前的主要關注點轉向了資源使用效率和整體資源利用率的提升。例如，當我們新增一個集群時，如何快速進行冷啟動，除了前期的基礎配置，還需要下載所有相關數據才能開始訓練。如果數據無法在集群之間流動，跨集群調度就無法順利實現，手動拷貝數據既麻煩又低效。

因此，數據流轉成為這一階段的核心瓶頸。單一集群下不存在這個問題，但在多云、異構、混合的復雜環境中，數據流轉和調度的優化顯得尤為重要。

存儲發展歷史

在數據存儲的發展歷程中，最初我們采用了機器上的 NVMe 盤去構建 Ceph 存儲系統，最大規模達到 2000 多個盤，裸容量為 8PB。選擇這種方式的原因在于搭建速度較快，因為有些集群在初期并未提供商業存儲資源，與商務溝通較為繁瑣，使用機器上盤的方式可以快速啟動訓練，避免了依賴其他團隊。

Ceph 的另一個優勢是其與 Kubernetes CSI 的兼容性非常好，完美支持 quota 等功能。由于平臺上的個人卷抽象是基于 K8s PVC 的，我們需要通過 quota 來限制用戶存儲，防止超標。

最初，我們用 Ceph 主要支持普通的預訓練任務，讀寫壓力較小。然而，隨著多模態數據的引入，問題逐漸顯現。特別是文件數量激增后，存儲系統變得非常不穩定，數以億計的小文件導致性能急劇下降，系統常常卡住。遇到這種情況，我們幾乎只能通過將數據遷移到其他存儲來解決問題。

此外，由于我們使用的是 GPU 節點構建的 Ceph 存儲，在不穩定的 GPU 環境下，管理 Ceph 存儲變得特別復雜，運維成本非常高。比如，Ceph 使用三副本存儲，如果剛好三副本中兩個副本所在的 OSD 節點同時宕機，整個 Ceph 系統會卡住，而且影響面會很大。我們曾遇到過幾臺節點被誤下線，導致少量的一些 OSD 下線，但由于 Ceph 的數據是打散存儲，進而影響了大量數據的穩定性，特別是一些 checkpoint 數據損壞，導致大量數據丟失。在不穩定的 GPU 環境中自建 Ceph 存儲的運維成本過高，且很難有效管理。

在中期，我們全面轉向采用高性能商業化存儲解決方案，如 DDN、GPFS 等。這些傳統高性能商業化存儲的主要優勢是性能高、運維簡單。然而，我們也遇到了一些問題。

首先，這類商業存儲的價格較高，且供貨周期較長，有時擴容需要 1 到 2 個月。

另一個主要的劣勢是它們的 CSI 兼容性不理想。例如，GPFS 的 CSI 兼容性不好，特別是在處理 quota 時存在問題，導致即使我們啟用了 quota 功能，但在 GPFS 卷上并沒有滿足業務預期。這使得平臺出現了“某用戶填滿文件系統，導致其他任務掛掉”的問題，且無法通過常規方式解決。解決方案可能需要在 GPFS 上再加一層額外的存儲管理系統，但這會導致性能下降，得不償失。

盡管這些傳統商業化存儲在性能和運維上有明顯優勢，但它的兼容性和成本問題仍然是我們面臨的挑戰。

從集群獨立存儲到統一中心存儲

最初，在我們的架構中，每個集群有不同的用途，如訓練集群、推理集群等。它們都有自建的存儲系統，數據準備要在各個集群的存儲系統間遷移數據，且大量依賴人工操作，過程繁瑣又效率低下，往往都要持續幾天，且極容易出錯。

（智譜集群獨立存儲到中心存儲的架構轉變）

為了解決這個問題，我們逐步引入了統一的中心存儲解決方案。具體來說，我們在公有云上建立了一個中心存儲，通過專線連接所有集群（包括訓練集群和推理集群），確保集群之間的數據可以無縫對接。這樣，每個集群都能訪問到一個統一的命名空間。例如，A 集群訓練好的 checkpoint 可以直接在 B 集群中訪問，無需額外的拷貝操作。

通過這個跨集群的統一存儲方案，所有集群的數據共享變得更加高效，且實現了類似 K8s 卷的跨集群掛載，使得任務提交和數據訪問變得更加便捷。

使用 JuiceFS 構建中心存儲

雖然中心存儲方案看起來非常理想，但實際實現起來仍然有不少挑戰。經過調研，我們最終選擇了 JuiceFS 來構建我們的中心存儲。JuiceFS 提供了優秀的鏡像文件系統和鏡像寫入能力，適合我們的需求。

（JuiceFS 鏡像讀寫流程圖）

我們中心存儲的架構是這樣組織的：

• 公有云對象存儲：所有資源都存儲在公有云上的對象存儲中，我們通過專線連接公有云和集群。每個集群之間都通過 100G 專線進行連接。考慮到穩定性問題，目前我們采用主備 100G 專線來確保可靠性。

• 鏡像文件系統：主文件系統位于公有云上，在集群內部署 JuiceFS 的鏡像文件系統，鏡像文件系統部署在 200G 的存儲網上，這大大提高了訪問速度。

• 分布式緩存：使用 JuiceFS 提供的獨立分布式緩存組。我們將 GPU 節點上的 NVMe 盤用在分布式緩存，能夠提供 PB 級別的緩存。相比原來用這些 NVMe 盤來構建 Ceph 集群的方案，緩存數據本身是不怕丟失的，即使緩存盤的節點故障，只需要從中心存儲上重新拉取數據。另外 Ceph 使用三副本存儲，而分布式緩存使用單副本存儲，意味著 分布式緩存的容量會更大，甚至超過集群中傳統商業存儲的緩存容量。

• 支持多協議訪問的統一命名空間：完全兼容 POSIX 和 S3 協議的數據訪問支持，同時滿足機器學習平臺數據 Pipeline 的高性能處理和研發人員管理數據的便捷性。

我們使用 JuiceFS 的整體邏輯是，將源集群部署在公有云，其底層數據存儲在對象存儲上。JuiceFS 采用的是元數據與數據分離的架構。我們在鏡像集群內部署了元數據的鏡像。通過一系列同步策略和寫入策略，確保數據的強一致性。這意味著，當用戶在任意一個集群修改數據時，在寫確認后，其他集群可以立即看到更新，從而實現了跨集群的統一命名空間。另外，JuiceFS 支持幾乎所有的公有云對象存儲，同時也支持如 Ceph、MinIO 等開源和兼容 S3 協議的商業私有化對象存儲，借助 JuiceFS 可以幫助業務層屏蔽各個集群自建的底層存儲的異構性，實現統一、多融合的中心存儲管理。

我們對存儲性能進行了測試，發現整體表現不錯。在單進程寫入性能上，表現比較理想，能夠滿足需求。對于讀取性能，主要有冷讀和熱讀兩種情況：

• 冷讀：是指當數據不在集群的緩沖區內時，而通過專線回源對象存儲。冷讀性能雖不如本地存儲理想，但在實際應用中已經足夠滿足需求。

• 熱讀：熱讀性能表現出色，基本可以與本地的高性能商業存儲持平。

（JuiceFS 性能測試）

根據我們的經驗，存儲性能不必追求極致，只要確保訓練數據讀取不成為瓶頸即可。過度追求單點性能可能導致緩存雪崩。例如，我們曾通過激進的預讀調優，使單節點達到了 100+GB/s 的吞吐量，但過多的讀取線程導致緩存崩潰，致使很多緩存組節點失聯，最終出現雪崩現象，反而需要 GPU 節點回源對象存儲影響讀取性能。因此，我們決定不再追求單節點的極限性能，而是通過多個節點聚合來充分利用專線帶寬。實際訓練場景通常是多機訓練，單機性能并非關鍵，確保專線帶寬的充分利用即可滿足需求。

在機器學習平臺的集成過程中，我們發現使用 JuiceFS 非常方便，其中一大優勢在于其完善的 CSI 驅動。不同于其他傳統商業存儲，JuiceFS 的 CSI 驅動非常完善，能夠無縫對接我們的平臺資源體系，支持跨集群的云個人卷概念。這樣，如果任務只使用云個人卷，數據就能夠在不同集群之間無縫調度。

此外，它的 quota 配置還是非常完善的，而且它有非常及時的統計信息，甚至可以實時顯示例如一個 300TB 的卷已經使用了 167TB，占比 55%。同時，我們還可以限制文件數量，因為過多的文件會帶來管理壓力。因此，我們可以設置文件數量的限制。整體而言，這些功能使得存儲系統能夠非常友好地與我們的機器學習平臺無縫集成。

這個中心存儲架構，給我們帶來了如下優勢：

• 減少單個集群本地存儲容量的硬性要求：在大規模數據處理中，尤其是多模態應用，數據量通常達到 PB 級別。傳統的分散集群架構需要將數據拷貝到各個集群進行訪問。采用 JuiceFS 的中心存儲架構后，用戶幾乎無需感知數據存取過程，能夠方便地使用數據，避免了傳統方式中數據頻繁拷貝的開銷。

• 有效利用 GPU 節點本地磁盤：GPU 節點通常帶有多個 NVMe 硬盤，由于節點本身的故障率較高，傳統的分布式存儲方案（如 Ceph）容易導致存儲集群頻繁故障，造成較差的可用性。在新的架構中，數據存儲于對象存儲，NVMe 盤資源用于數據緩存，從而顯著提升數據訪問效率。

• 便于集群遷移：訓練任務可以在新集群直接啟動，無需額外的數據準備。數據訪問會在中心存儲和集群本地的分布式緩存中透明路由，集群加載數據在從中心對象存儲上下載過程中會自動加載到集群本地的分布式緩存中，下一次訪問時，數據讀取直接命中本地分布式緩存，從而加速數據讀取效率。

• 多集群大一統調度：未來，我們計劃實現多個集群的大一統調度，將多個集群整合為一個開發環境，通過集中調度最大化資源利用率，從而提升整體架構的效率。

5總結

在發展的初期，我們專注于系統穩定性，快速利用現有機器資源，推動模型的研發和訓練。在擴張期，我們通過標準化抽象屏蔽了復雜的異構細節，提升了平臺的易用性，進一步支持了高效的模型研發。而在成熟期，我們解決了存儲和數據流轉的核心難題，優化了跨集群的數據管理和調度，提高了整體資源利用率。隨著系統的不斷完善，中心存儲架構的引入使得大規模數據處理變得更加高效。

關于作者

曾奧涵，智譜 GLM 基座模型 & 訓練基礎設施負責人，作為主要開發者參與了 GLM-130B、ChatGLM、GLM-4 (All Tools)、GLM-4-Plus、GLM-4-Voice 等模型或系統的研發。

會議推薦

AICon 2025 強勢來襲，5 月上海站、6 月北京站，雙城聯動，全覽 AI 技術前沿和行業落地。大會聚焦技術與應用深度融合，匯聚 AI Agent、多模態、場景應用、大模型架構創新、智能數據基建、AI 產品設計和出海策略等話題。即刻掃碼購票，一同探索 AI 應用邊界！