作者 | 曾奧涵
智譜成立于 2019 年，源于清華大學(xué)計(jì)算機(jī)系知識(shí)工程實(shí)驗(yàn)室 (KEG) 的技術(shù)成果。2022 年，智譜訓(xùn)練并開源了中英雙語預(yù)訓(xùn)練模型 GLM-130B，其性能媲美 GPT-3。2023 年發(fā)布了千億參數(shù)極速對話模型 ChatGLM 系列，在 Hugging Face 社區(qū)獲得了超過一千萬次下載。2024 年，發(fā)布的旗艦?zāi)Ｐ?GLM-4-Plus 在 SuperBench 大模型評測中位列世界前三。
智譜的基礎(chǔ)設(shè)施團(tuán)隊(duì)經(jīng)歷了從支持不足 10 人發(fā)展到要支持 200 多人研發(fā)團(tuán)隊(duì)的過程。本文將介紹智譜基礎(chǔ)設(shè)施發(fā)展的初期、擴(kuò)張和成熟三個(gè)階段的挑戰(zhàn)與實(shí)踐經(jīng)驗(yàn)。希望通過這些分享，激發(fā)新的思路和觀點(diǎn)。
1引言
我們從 2021 年底開始參與模型的訓(xùn)練，負(fù)責(zé) GLM-130B 高精度千億模型的訓(xùn)練工作。團(tuán)隊(duì)的發(fā)展與模型的演進(jìn)密切相關(guān)。在初期階段，集群數(shù)量較少，研發(fā)團(tuán)隊(duì)人數(shù)不到 10 人，主要目標(biāo)是支持基座模型的研發(fā)。隨著大模型的崛起，團(tuán)隊(duì)進(jìn)入了擴(kuò)張階段，集群數(shù)量增加，我們采用了靈活的資源調(diào)配策略。如今，團(tuán)隊(duì)已進(jìn)入成熟階段，集群數(shù)量增至 10 個(gè)以上，服務(wù)的用戶人數(shù)超 200 人。此時(shí)，團(tuán)隊(duì)的關(guān)注點(diǎn)轉(zhuǎn)向如何提升資源使用效率，減少多套集群帶來的數(shù)據(jù)流轉(zhuǎn)和調(diào)度成本。
（智譜 AI 模型研發(fā)歷史）
目前，我們 GLM 基礎(chǔ)設(shè)施團(tuán)隊(duì)的主要職責(zé)可以分為三大塊：
基礎(chǔ)設(shè)施建設(shè)：這一部分主要包括集群搭建、GPU 上架、計(jì)算網(wǎng)絡(luò)的組網(wǎng)以及存儲(chǔ)規(guī)劃等底層設(shè)施的建設(shè)工作。
基礎(chǔ)設(shè)施運(yùn)維：我們負(fù)責(zé)保障設(shè)施的穩(wěn)定運(yùn)行，優(yōu)化集群的穩(wěn)定性，主動(dòng)發(fā)現(xiàn)并處理故障節(jié)點(diǎn)。此外，還涉及一些繁瑣的任務(wù)，如數(shù)據(jù)遷移、數(shù)據(jù)拷貝以及數(shù)據(jù)流轉(zhuǎn)的管理工作。
支持研發(fā)團(tuán)隊(duì)的平臺(tái)建設(shè)：我們?yōu)楣狙邪l(fā)團(tuán)隊(duì)提供了“GLM 機(jī)器學(xué)習(xí)平臺(tái)”。該平臺(tái)支持公司整體研發(fā)需求，整合了 GPU、存儲(chǔ)、鏡像等資源，幫助研發(fā)團(tuán)隊(duì)進(jìn)行算法開發(fā)與迭代。
目前，我們的資源高度分散，采用云上云下混合模式，集群數(shù)量超過 10 個(gè)，分布在不同地域，且 GPU 型號(hào)和網(wǎng)絡(luò)類型各異，導(dǎo)致異構(gòu)性問題突出。同時(shí)，存儲(chǔ)系統(tǒng)也存在混合性，進(jìn)一步加劇了資源管理的復(fù)雜性。最后，由于資源更迭速度較快，數(shù)據(jù)遷移和集群清理成為瓶頸，而數(shù)據(jù)初始化速度對訓(xùn)練至關(guān)重要。
接下來，我將詳細(xì)介紹我們?nèi)绾螐淖畛醯囊粌蓚€(gè)集群發(fā)展到如今這種復(fù)雜的資源環(huán)境，以及我們采取了哪些措施來應(yīng)對這些復(fù)雜的資源。
2初期：從裸金屬集群訓(xùn)練到平臺(tái)建設(shè)探索
裸金屬集群訓(xùn)練模型
最早在 2022 年左右，我們開始訓(xùn)練 GLM-130B 的模型，當(dāng)時(shí)尚未有成熟的調(diào)度平臺(tái)支持。團(tuán)隊(duì)初期的目標(biāo)非常明確，即支持基座模型的預(yù)訓(xùn)練。我們通過租賃一批機(jī)器，并以裸金屬的形式進(jìn)行交付，整個(gè)過程依賴手動(dòng)管理。團(tuán)隊(duì)成員和任務(wù)是直接與機(jī)器綁定的，預(yù)訓(xùn)練任務(wù)與實(shí)驗(yàn)任務(wù)、微調(diào)任務(wù)分別分配給不同的機(jī)器，任務(wù)之間通過共享存儲(chǔ)進(jìn)行協(xié)調(diào)，環(huán)境管理完全由用戶通過 MiniConda、Docker 等工具自行完成。這種模式存在諸多問題。
首先，環(huán)境配置極為困難。由于機(jī)器資源分散，團(tuán)隊(duì)將多個(gè)小組分配到不同的機(jī)器上，導(dǎo)致驅(qū)動(dòng)、庫和軟件包等版本不一致。這種不一致會(huì)造成許多訓(xùn)練任務(wù)無法正常運(yùn)行，環(huán)境配置成為了一個(gè)巨大的難題。
其次，人力成本較高。由于沒有統(tǒng)一的平臺(tái)工具，所有的任務(wù)必須手動(dòng)提交和管理，尤其是在裸機(jī)環(huán)境中。團(tuán)隊(duì)需要定期值班，監(jiān)控任務(wù)是否正常運(yùn)行，或通過腳本手動(dòng)檢查任務(wù)狀態(tài)。如果任務(wù)失敗，排查問題非常繁瑣。雖然可以通過手動(dòng)操作將故障的 GPU 節(jié)點(diǎn)移除，但有時(shí)節(jié)點(diǎn)問題較復(fù)雜，缺乏有效的工具時(shí)，排查過程可能需要幾個(gè)小時(shí)，造成很大的心智負(fù)擔(dān)。
（裸金屬集群訓(xùn)練模型）
最后，資源管理也非常困難。在沒有統(tǒng)一任務(wù)管理系統(tǒng)的情況下，團(tuán)隊(duì)成員只能按照固定的機(jī)器進(jìn)行工作，且很難協(xié)調(diào)機(jī)器的使用情況。由于機(jī)器經(jīng)常出現(xiàn)故障，我們無法清楚知道哪些機(jī)器正在運(yùn)行，哪些機(jī)器有問題，整體資源管理效率低下。
適合大模型訓(xùn)練的簡易調(diào)度平臺(tái)
盡管裸金屬集群這種模式能夠加快推動(dòng)基座模型訓(xùn)練工作的開展 ，但由于管理和操作上的種種問題，我們意識(shí)到這種裸金屬的方式并不理想，我們開始探索開發(fā)平臺(tái)化的管理工具，以應(yīng)對這些挑戰(zhàn)。
整理需求后，我們發(fā)現(xiàn)調(diào)度平臺(tái)至少要滿足以下 3 個(gè)需求：
訓(xùn)練任務(wù)化。能夠?qū)⒂?xùn)練抽象成一個(gè)任務(wù)，通過 MPI/PyTorchDDP 框架進(jìn)行拉起。能夠感知任務(wù)的不同生命周期，完成狀態(tài)判斷和轉(zhuǎn)移。能夠支持多任務(wù)的靈活調(diào)度。
任務(wù)穩(wěn)定性。能夠查詢?nèi)蝿?wù)日志，監(jiān)控任務(wù)狀態(tài)，在任務(wù)生命周期變更時(shí)通知用戶。
無人值守訓(xùn)練。能夠完成任務(wù)失敗自動(dòng)重試，自動(dòng)推進(jìn)訓(xùn)練任務(wù)進(jìn)行。能夠自動(dòng)識(shí)別故障節(jié)點(diǎn)，自動(dòng)封禁。能夠篩查慢速節(jié)點(diǎn)，提高效率。
（簡易調(diào)度平臺(tái)）
由于我們的團(tuán)隊(duì)起源于實(shí)驗(yàn)室背景，最初我們嘗試了一些類似于 Slurm 調(diào)度工具的方案，但發(fā)現(xiàn)這些工具更多地適用于超算環(huán)境，并不完全符合大模型時(shí)代多級訓(xùn)練的需求。因此，我們決定自行開發(fā)一套簡易的調(diào)度平臺(tái)。
于是，我們轉(zhuǎn)向了 Kubernetes，通過 K8s 屏蔽底層異構(gòu)資源差異，提供統(tǒng)一接口， 通過設(shè)備插件注入訓(xùn)練所需的 GPU、RDMA 等設(shè)備。同時(shí)，將訓(xùn)練環(huán)境鏡像化，訓(xùn)練數(shù)據(jù)和結(jié)果存放在 PVC 中。
在此基礎(chǔ)上，我們的調(diào)度平臺(tái)實(shí)現(xiàn)了兩個(gè) CR（Custom Resource）。
第一個(gè)是訓(xùn)練任務(wù)，它定義了任務(wù)所需的鏡像、掛載的數(shù)據(jù)卷以及節(jié)點(diǎn)數(shù)，并負(fù)責(zé)維護(hù)整個(gè)任務(wù)的生命周期。
第二個(gè)是任務(wù)隊(duì)列，收集節(jié)點(diǎn)信息，將訓(xùn)練任務(wù)成組調(diào)度到合適到節(jié)點(diǎn)。
通過簡易調(diào)度平臺(tái)，我們實(shí)現(xiàn)了訓(xùn)練任務(wù)化。但是，由于 GPU 設(shè)備本身的高故障率，我們?nèi)匀恍枰粋€(gè)自動(dòng)化方案來實(shí)現(xiàn)無人值守訓(xùn)練。
任務(wù)穩(wěn)定性： Node Agent - 主動(dòng)故障發(fā)現(xiàn)與處理
在任務(wù)的穩(wěn)定性方面，我們希望能夠查詢?nèi)蝿?wù)的日志狀態(tài)，并在任務(wù)生命周期內(nèi)進(jìn)行狀態(tài)變更。例如，當(dāng)任務(wù)失敗時(shí)，我們希望能夠及時(shí)通知用戶。此外，我們還期望實(shí)現(xiàn)無人值守的訓(xùn)練，即在任務(wù)失敗時(shí)，系統(tǒng)能夠自動(dòng)重試并繼續(xù)推進(jìn)任務(wù)的運(yùn)行，同時(shí)進(jìn)行故障檢測。
為此，我們采用了 Node Agent 的方式來主動(dòng)進(jìn)行故障檢測與發(fā)現(xiàn)。通過節(jié)點(diǎn)故障探查和運(yùn)維自動(dòng)化、故障告警等手段，我們實(shí)現(xiàn)了故障的快速響應(yīng)。
以 GPU 掉卡為例，故障處理流程大致如下：當(dāng) GPU 故障時(shí)， Node Agent 會(huì)首先感知到掉卡問題，并立即禁止該故障節(jié)點(diǎn)的調(diào)度同時(shí)將故障信息通知運(yùn)維。由于 GPU 掉卡后任務(wù)無法繼續(xù)運(yùn)行，任務(wù)將直接失敗。任務(wù)失敗后，系統(tǒng)會(huì)自動(dòng)觸發(fā)重試機(jī)制，確保任務(wù)能夠繼續(xù)執(zhí)行。
我們通過 Node Agent 主動(dòng)封禁了故障節(jié)點(diǎn)，當(dāng)任務(wù)失敗后，系統(tǒng)會(huì)觸發(fā)重試機(jī)制。重試時(shí)，任務(wù)會(huì)被調(diào)度到健康的節(jié)點(diǎn)上，確保任務(wù)能夠正常運(yùn)行。一旦任務(wù)調(diào)度成功，我們還通過飛書電話等通知工具及時(shí)告知模型訓(xùn)練人員，以便他們關(guān)注任務(wù)的健康狀況。這一流程有效支持了我們最初基座模型的訓(xùn)練需求。
3擴(kuò)張期：構(gòu)建機(jī)器學(xué)習(xí)平臺(tái)
隨著團(tuán)隊(duì)的擴(kuò)張，我們的規(guī)模增長到接近 50 人，同時(shí)資源也擴(kuò)展到 3 到 5 個(gè)集群。訓(xùn)練任務(wù)的種類也大幅增加，原先只做文本模型，現(xiàn)在已經(jīng)涉及到圖像生成、視頻生成等多個(gè)領(lǐng)域，訓(xùn)練任務(wù)變得更加多樣化。
在這個(gè)過程中，運(yùn)維成本也顯著上升。隨著集群數(shù)量的增加，機(jī)器和 GPU 型號(hào)的多樣化導(dǎo)致機(jī)器故障頻發(fā)，任務(wù)失敗的情況也變得更加頻繁。管理的復(fù)雜度也隨之增加。最初只有一個(gè)團(tuán)隊(duì)進(jìn)行訓(xùn)練時(shí)，資源分配和內(nèi)部協(xié)商相對簡單。但隨著規(guī)模的擴(kuò)大，如何合理分配和管理資源，以及建立有效的統(tǒng)計(jì)機(jī)制，成為了新的挑戰(zhàn)。
另外，安全隱患問題也逐漸顯現(xiàn)。最早的模式是通過共享存儲(chǔ)來處理集群內(nèi)的數(shù)據(jù)，這雖然方便，但也存在較大安全隱患。例如，某些用戶可能會(huì)不小心執(zhí)行一些操作，導(dǎo)致存儲(chǔ)空間被占滿，從而影響其他任務(wù)的正常運(yùn)行。
于是，我們基于 Kubernetes 構(gòu)建了一個(gè)機(jī)器學(xué)習(xí)平臺(tái)，底層實(shí)現(xiàn)了計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)的統(tǒng)一管理，全部通過 K8s 進(jìn)行協(xié)調(diào)。調(diào)度層通過 Operator 實(shí)現(xiàn)，我們使用了 Kubernetes 的原生資源對象來完成資源調(diào)度，避免了復(fù)雜的開發(fā)工作，基本上遵循了 K8s 的標(biāo)準(zhǔn)做法。
在訓(xùn)練平臺(tái)層，我們還需要滿足日常的開發(fā)需求，因此抽象出了開發(fā)機(jī)、訓(xùn)練任務(wù)和推理任務(wù)等工作負(fù)載。同時(shí)，設(shè)計(jì)了任務(wù)隊(duì)列、存儲(chǔ)池和個(gè)人卷等機(jī)制，用于資源分配和權(quán)限管理。此外，我們引入了多種保障機(jī)制，確保任務(wù)的順利推進(jìn)，并與運(yùn)維團(tuán)隊(duì)緊密配合，確保重點(diǎn)任務(wù)的實(shí)施。
（智譜 GLM 訓(xùn)練基礎(chǔ)設(shè)施架構(gòu)圖）
我們的目標(biāo)是以下述四個(gè)特征來構(gòu)建我們的機(jī)器學(xué)習(xí)平臺(tái)：
易用性：我們需要提供一個(gè)統(tǒng)一的功能抽象，屏蔽不同業(yè)務(wù)資源的差異，確保用戶能方便地訪問和使用。此外，平臺(tái)還需要提供多種訪問方式，包括 Web 界面、 Web Shell、SSH 直連以及命令行工具（CLI），以適應(yīng)不同用戶的需求。我們還需要一個(gè)靈活的資源分配機(jī)制，確保資源能根據(jù)任務(wù)需求進(jìn)行合理調(diào)配。
穩(wěn)定性：我們希望平臺(tái)能夠?qū)崿F(xiàn)無人值守的任務(wù)管理。在任務(wù)失敗時(shí)，系統(tǒng)應(yīng)能夠自動(dòng)重試，例如，基于已保存的 checkpoint 自動(dòng)恢復(fù)訓(xùn)練。整個(gè)任務(wù)生命周期中，任務(wù)狀態(tài)的變更應(yīng)能及時(shí)通知相關(guān)人員，并且系統(tǒng)應(yīng)能保留運(yùn)行環(huán)境的 debug 日志，方便調(diào)試和故障排查。
高效性：在任務(wù)量大、節(jié)點(diǎn)多的情況下，我們需要優(yōu)化存儲(chǔ)管理，并確保鏡像能夠迅速分發(fā)到各個(gè)節(jié)點(diǎn)，以提高訓(xùn)練效率。這包括存儲(chǔ)的優(yōu)化和高效的資源調(diào)度，確保大規(guī)模任務(wù)的順利執(zhí)行。
安全性：我們希望可以進(jìn)行細(xì)粒度的存儲(chǔ)訪問控制，以防止未經(jīng)授權(quán)的訪問。例如，防止敏感數(shù)據(jù)（如 SIP 數(shù)據(jù)）被未經(jīng)授權(quán)的用戶或不當(dāng)操作者下載或盜取等。
平臺(tái)功能 1： 開發(fā)機(jī)抽象，共享 GPU 模式
接下來，我們介紹了平臺(tái)中幾個(gè)重要的抽象功能，并闡述了背后的設(shè)計(jì)考慮。
在傳統(tǒng)的開發(fā)機(jī)模式中，通常會(huì)采用獨(dú)占 GPU 和塊存儲(chǔ)的方式，即為每個(gè)開發(fā)機(jī)分配一個(gè)獨(dú)立的 GPU 和一個(gè)持久化的存儲(chǔ)（如云卷）。這種方式類似于 ECS 模式，用于長期的開發(fā)任務(wù)。我們沒有選擇這種模式，而是采用了共享 GPU 的模式，避免了 GPU 獨(dú)占。存儲(chǔ)方面，我們沒有使用持久化的塊設(shè)備存儲(chǔ)，而是依賴于 Pod 的臨時(shí)存儲(chǔ)，并將設(shè)備掛載在集群的共享存儲(chǔ)中。我們通過 K8s Pod 實(shí)現(xiàn)這種架構(gòu)，重點(diǎn)提供開發(fā)機(jī)和鏡像保存功能，使得開發(fā)機(jī)更輕便且易于管理。
（智譜機(jī)器學(xué)習(xí)平臺(tái)功能：開發(fā)機(jī)抽象）
我們選擇這種開發(fā)機(jī)的設(shè)計(jì)方式，主要是考慮到大模型研發(fā)的需求。在研發(fā)過程中，很多開源模型會(huì)提供鏡像，而大模型的交付環(huán)境通常都是基于鏡像的，這使得容器化模式非常適合此類場景。使用容器模式可以直接利用現(xiàn)有的鏡像，而不需要額外安裝 Docker 或進(jìn)行透傳，簡化了環(huán)境配置。
此外，獨(dú)占單卡會(huì)產(chǎn)生大量碎片化資源。研發(fā)人員可能需要頻繁切換模型，每次都需要?jiǎng)?chuàng)建獨(dú)立的開發(fā)機(jī)。如果采用獨(dú)占模式，資源碎片化嚴(yán)重，尤其在多卡部署時(shí)，這樣的資源使用效率低。共享多卡的模式能更好地支持靈活調(diào)度和調(diào)試。
考慮到我們的集群環(huán)境比較混雜，且不是每個(gè)集群都有很完善的基礎(chǔ)設(shè)施，因此無法為每個(gè)集群都提供專門的塊存儲(chǔ)設(shè)備池。為保證平臺(tái)能夠提供一個(gè)穩(wěn)定的抽象，我們沒有使用塊存儲(chǔ)來持久化用戶數(shù)據(jù)。開發(fā)機(jī)中的數(shù)據(jù)在關(guān)閉后會(huì)丟失，若需要保存數(shù)據(jù)，用戶只能通過鏡像保存功能將環(huán)境保留。我們認(rèn)為這是合理的，因?yàn)殚_發(fā)機(jī)本質(zhì)上不應(yīng)存儲(chǔ)數(shù)據(jù)，數(shù)據(jù)應(yīng)該存儲(chǔ)在共享存儲(chǔ)中，而開發(fā)機(jī)的核心任務(wù)是作為模型開發(fā)和調(diào)試的環(huán)境。
總的來說，我們的開發(fā)機(jī)抽象設(shè)計(jì)旨在提供靈活、便捷的開發(fā)環(huán)境，同時(shí)確保平臺(tái)的穩(wěn)定性和資源使用的高效性。
平臺(tái)功能 2： 訓(xùn)練任務(wù)抽象
訓(xùn)練任務(wù)的抽象設(shè)計(jì)與常見的任務(wù)調(diào)度模式大同小異，核心在于實(shí)現(xiàn)了任務(wù)隊(duì)列的調(diào)度管理。我們采用了 Gang Scheduling 機(jī)制，確保調(diào)度的任務(wù)要么全部不調(diào)度，要么能夠同時(shí)調(diào)度到位。為了提高資源分配效率，我們還實(shí)現(xiàn)了資源超賣策略，進(jìn)一步優(yōu)化了資源的整體利用。
此外，借助 Dragonfly 以及多級緩存架構(gòu)的設(shè)計(jì)，在集群內(nèi)部實(shí)現(xiàn)了基于 P2P 的鏡像分發(fā)功能，解決了大規(guī)模任務(wù)提交時(shí)的效率問題；
例如，在開發(fā)機(jī)上跑完一個(gè) 8 卡訓(xùn)練任務(wù)并保存為鏡像后，使用該鏡像在本集群內(nèi)提交一個(gè) 256 臺(tái)機(jī)器的任務(wù)。如果沒有 P2P 分發(fā)，拉取鏡像的時(shí)間可能超過一個(gè)小時(shí)，而通過 P2P 分發(fā)，鏡像拉取速度得到了顯著提升。
此外，基于多級緩存的設(shè)計(jì)，保存鏡像時(shí)除了向中心存儲(chǔ)上傳數(shù)據(jù)，還會(huì)同時(shí)加載到本集群 的自建存儲(chǔ)中作為一級緩存；同時(shí)在各個(gè)集群的邏輯上層，還設(shè)有統(tǒng)一的 Gateway 集群，緩存從互聯(lián)網(wǎng)拉取的鏡像，作為二級緩存，如果集群內(nèi)沒有查詢到所需要的鏡像，會(huì)穿透到二級緩存拉取。
通過生產(chǎn)環(huán)境的上線前后對比，20G 以上鏡像拉取效率提高 3 倍以上。隨著集群內(nèi)任務(wù)規(guī)模的擴(kuò)大、節(jié)點(diǎn)數(shù)的增多，效率提高更顯著，截止目前任務(wù)啟動(dòng)成功率 100%。
在任務(wù)管理方面，我們重點(diǎn)關(guān)注了任務(wù)的狀態(tài)通知。從任務(wù)排隊(duì)到開始運(yùn)行，再到結(jié)束，我們與飛書等平臺(tái)深度集成，提供實(shí)時(shí)通知功能，確保團(tuán)隊(duì)成員能夠及時(shí)掌握任務(wù)進(jìn)度。對于多人協(xié)作的任務(wù)，我們還可以將任務(wù)狀態(tài)通知到團(tuán)隊(duì)的群聊中，平臺(tái)的機(jī)器人會(huì)自動(dòng)拉取任務(wù)信息，并向群成員發(fā)送更新。
為了實(shí)現(xiàn)無人值守的訓(xùn)練流程，我們還設(shè)計(jì)了任務(wù)的自動(dòng)重試策略，確保任務(wù)在出現(xiàn)問題時(shí)能夠自動(dòng)恢復(fù)。
（智譜機(jī)器學(xué)習(xí)平臺(tái)功能：訓(xùn)練任務(wù)抽象）
平臺(tái)功能 3： 推理服務(wù)
推理服務(wù)的需求是將訓(xùn)練好的模型快速部署、測試和評估。推理架構(gòu)相對簡單，主要由兩個(gè)部分組成：網(wǎng)關(guān)和模型。模型層負(fù)責(zé)負(fù)載均衡，啟動(dòng)多個(gè)模型實(shí)例，可能是 TGI 或者 vLLM 實(shí)例，然后進(jìn)行負(fù)載均衡。網(wǎng)關(guān)層通過鏡像啟動(dòng)，處理格式轉(zhuǎn)換和策略調(diào)度等任務(wù)。
最終，推理服務(wù)通過一個(gè) VIP 對外暴露，確保訓(xùn)練集群和評測集群之間的網(wǎng)絡(luò)互通。評測集群可以直接通過 VIP 接入進(jìn)行模型評測，從而加快整個(gè)迭代流程。
平臺(tái)功能 4： 數(shù)據(jù)處理任務(wù)抽象
在推理服務(wù)發(fā)現(xiàn)后，我們注意到很多用戶除了部署模型外，還需要處理數(shù)據(jù)。例如，用戶可能需要對一批數(shù)據(jù)進(jìn)行處理，比如使用模型對數(shù)據(jù)進(jìn)行改寫。然而，傳統(tǒng)的推理服務(wù)抽象并不適合這種需求。推理服務(wù)通常是一個(gè)固定的服務(wù)，比如如果需要 32 張卡，它就會(huì)擴(kuò)展到 32 張卡，再擴(kuò)展到 64 張卡，而這類固定抽象并不適用于數(shù)據(jù)處理任務(wù)。
數(shù)據(jù)處理任務(wù)的抽象與此不同。我們設(shè)計(jì)了一個(gè)數(shù)據(jù)處理任務(wù)隊(duì)列，任務(wù)會(huì)分配給每個(gè) Worker 進(jìn)行處理。每個(gè) Worker 處理完任務(wù)后會(huì)結(jié)束，從而釋放資源。這意味著，處理完成后，資源不會(huì)被占用，避免了在傳統(tǒng)推理服務(wù)中無法釋放資源的問題。例如，如果有 1000 張卡用于視頻特征提取，傳統(tǒng)方式可能會(huì)導(dǎo)致長尾任務(wù)占用資源，資源長時(shí)間無法被釋放。
因此，我們的設(shè)計(jì)專門針對模型數(shù)據(jù)處理、特征提取等流程和 pipeline 場景，提供了一種數(shù)據(jù)處理任務(wù)抽象，確保資源高效利用并避免不必要的資源占用。
平臺(tái)保障： 多項(xiàng)關(guān)鍵策略確保穩(wěn)定性
為了確保訓(xùn)練的穩(wěn)定性，我們采取了三項(xiàng)主要措施，這些措施涵蓋了常見的故障處理和任務(wù)恢復(fù)需求：
故障主動(dòng)檢測與封禁：我們使用 Node Agent 主動(dòng)監(jiān)控并檢測常見故障，包括驅(qū)動(dòng)版本、GPU 數(shù)量、電源風(fēng)扇告警、共享存儲(chǔ)掛載等問題。節(jié)點(diǎn)故障檢測還涵蓋了 GPU 的 XID ECC 錯(cuò)誤、路由問題、網(wǎng)絡(luò)抖動(dòng)等情況。如果發(fā)現(xiàn)故障，系統(tǒng)會(huì)自動(dòng)封禁該節(jié)點(diǎn)，避免調(diào)度到故障節(jié)點(diǎn)上。
任務(wù)自動(dòng)重試機(jī)制：訓(xùn)練任務(wù)通常是以任務(wù)形式提交的。如果任務(wù)因?yàn)?GPU 故障而失敗，系統(tǒng)會(huì)自動(dòng)重試，并且由于壞節(jié)點(diǎn)已被封禁，新的任務(wù)會(huì)分配到健康的節(jié)點(diǎn)，確保任務(wù)能夠自動(dòng)恢復(fù)。這種自愈機(jī)制在大多數(shù)情況下能確保任務(wù)的穩(wěn)定執(zhí)行。
任務(wù)掛起（hang）與慢速報(bào)警：對于一些特殊情況，比如訓(xùn)練速度、GPU 功率突然下降等，雖然這些問題不會(huì)直接導(dǎo)致任務(wù)掛掉，但可能會(huì)影響訓(xùn)練效果。在這些情況下，我們會(huì)通過條件檢測識(shí)別異常并向用戶發(fā)出告警。用戶可以根據(jù)告警信息進(jìn)行人工干預(yù)，避免問題進(jìn)一步惡化。
通過以上這三項(xiàng)措施，我們能夠有效保證預(yù)訓(xùn)練的穩(wěn)定性，以一個(gè)訓(xùn)練任務(wù)的生命周期為例，：
訓(xùn)練任務(wù)在我們平臺(tái)內(nèi)申請通過后，調(diào)度器從可使用 Pool 中分配節(jié)點(diǎn)，隨后智能篩查服務(wù)會(huì)使用 NCCL 對這些節(jié)點(diǎn)進(jìn)行高性能網(wǎng)絡(luò)測試和 GPU 狀態(tài)探測，確保環(huán)境穩(wěn)定可正常啟動(dòng)訓(xùn)練任務(wù)；否則重新分配節(jié)點(diǎn)，并將探測不通過的節(jié)點(diǎn)放入備池。
訓(xùn)練任務(wù)正常啟動(dòng)后，Node Agent 會(huì)實(shí)時(shí)監(jiān)控、檢測節(jié)點(diǎn)的狀態(tài)和訓(xùn)練任務(wù)的進(jìn)程；主動(dòng)感知訓(xùn)練過程中是否存在降速、抖動(dòng)以及容器內(nèi)掉卡等異常；并主動(dòng)感知 GPU 的 XID ECC 等異常，并識(shí)別異常類型針對性 callback 修復(fù)流程。
對于訓(xùn)練過程中存在問題的節(jié)點(diǎn)，智能篩查會(huì)在訓(xùn)練結(jié)束后根據(jù) Node Agent 的 callback 進(jìn)行再次篩查，并根據(jù)結(jié)果反饋給運(yùn)維、機(jī)房，提起工單自動(dòng)化報(bào)障、維修流程。
雖然大部分故障可以通過主動(dòng)檢測來發(fā)現(xiàn)，但仍然存在一些極端情況下，訓(xùn)練任務(wù)由于未知原因無法啟動(dòng)。在這種情況下，所有已知的方法都無法解決問題，這時(shí)我們只能退回最原始的故障排查方式——二分查找。例如，如果我們有 100 個(gè)節(jié)點(diǎn)，發(fā)現(xiàn)無法啟動(dòng)訓(xùn)練任務(wù)時(shí)，可以將這些節(jié)點(diǎn)分為前 50 和后 50，逐一測試。
為了更高效地解決這個(gè)問題，我們開發(fā)了智能篩查功能，將這一過程自動(dòng)化。通過智能篩查，系統(tǒng)能夠主動(dòng)檢測并篩選出問題節(jié)點(diǎn)。篩查流程如下圖所示：
（智譜智能篩查流程）
在實(shí)際應(yīng)用中，我們使用兩兩分組的方式進(jìn)行篩查。通過對每一組節(jié)點(diǎn)運(yùn)行 NCCL 測試，若發(fā)現(xiàn)某一組特別慢，基本可以確定其中有一個(gè)問題節(jié)點(diǎn)。通過奇偶輪換的方法，我們逐步鎖定問題節(jié)點(diǎn)。
通過這種智能篩查方法，我們能夠高效地識(shí)別和排除問題節(jié)點(diǎn)，確保訓(xùn)練任務(wù)在穩(wěn)定的節(jié)點(diǎn)上運(yùn)行。即使無法完全分析故障的原因，這種自動(dòng)篩查功能也能保證節(jié)點(diǎn)在端到端訓(xùn)練中表現(xiàn)符合預(yù)期，從而解決大部分復(fù)雜故障問題。
4穩(wěn)定期：從各集群獨(dú)立存儲(chǔ)到構(gòu)建中心化存儲(chǔ)架構(gòu)
隨著平臺(tái)功能的不斷迭代和完善，進(jìn)入了穩(wěn)定期。此時(shí)，團(tuán)隊(duì)人數(shù)大幅增長，使用機(jī)器學(xué)習(xí)平臺(tái)的研發(fā)人員數(shù)量增加到 200 多人。同時(shí)，集群數(shù)量從 3~5 個(gè)增加到 10 個(gè)以上。
在前期易用性和穩(wěn)定性問題基本解決的情況下，當(dāng)前的主要關(guān)注點(diǎn)轉(zhuǎn)向了資源使用效率和整體資源利用率的提升。例如，當(dāng)我們新增一個(gè)集群時(shí)，如何快速進(jìn)行冷啟動(dòng)，除了前期的基礎(chǔ)配置，還需要下載所有相關(guān)數(shù)據(jù)才能開始訓(xùn)練。如果數(shù)據(jù)無法在集群之間流動(dòng)，跨集群調(diào)度就無法順利實(shí)現(xiàn)，手動(dòng)拷貝數(shù)據(jù)既麻煩又低效。
因此，數(shù)據(jù)流轉(zhuǎn)成為這一階段的核心瓶頸。單一集群下不存在這個(gè)問題，但在多云、異構(gòu)、混合的復(fù)雜環(huán)境中，數(shù)據(jù)流轉(zhuǎn)和調(diào)度的優(yōu)化顯得尤為重要。
存儲(chǔ)發(fā)展歷史
在數(shù)據(jù)存儲(chǔ)的發(fā)展歷程中，最初我們采用了機(jī)器上的 NVMe 盤去構(gòu)建 Ceph 存儲(chǔ)系統(tǒng)，最大規(guī)模達(dá)到 2000 多個(gè)盤，裸容量為 8PB。選擇這種方式的原因在于搭建速度較快，因?yàn)橛行┘涸诔跗诓⑽刺峁┥虡I(yè)存儲(chǔ)資源，與商務(wù)溝通較為繁瑣，使用機(jī)器上盤的方式可以快速啟動(dòng)訓(xùn)練，避免了依賴其他團(tuán)隊(duì)。
Ceph 的另一個(gè)優(yōu)勢是其與 Kubernetes CSI 的兼容性非常好，完美支持 quota 等功能。由于平臺(tái)上的個(gè)人卷抽象是基于 K8s PVC 的，我們需要通過 quota 來限制用戶存儲(chǔ)，防止超標(biāo)。
最初，我們用 Ceph 主要支持普通的預(yù)訓(xùn)練任務(wù)，讀寫壓力較小。然而，隨著多模態(tài)數(shù)據(jù)的引入，問題逐漸顯現(xiàn)。特別是文件數(shù)量激增后，存儲(chǔ)系統(tǒng)變得非常不穩(wěn)定，數(shù)以億計(jì)的小文件導(dǎo)致性能急劇下降，系統(tǒng)常?？ㄗ?/strong>。遇到這種情況，我們幾乎只能通過將數(shù)據(jù)遷移到其他存儲(chǔ)來解決問題。
此外，由于我們使用的是 GPU 節(jié)點(diǎn)構(gòu)建的 Ceph 存儲(chǔ)，在不穩(wěn)定的 GPU 環(huán)境下，管理 Ceph 存儲(chǔ)變得特別復(fù)雜，運(yùn)維成本非常高。比如，Ceph 使用三副本存儲(chǔ)，如果剛好三副本中兩個(gè)副本所在的 OSD 節(jié)點(diǎn)同時(shí)宕機(jī)，整個(gè) Ceph 系統(tǒng)會(huì)卡住，而且影響面會(huì)很大。我們曾遇到過幾臺(tái)節(jié)點(diǎn)被誤下線，導(dǎo)致少量的一些 OSD 下線，但由于 Ceph 的數(shù)據(jù)是打散存儲(chǔ)，進(jìn)而影響了大量數(shù)據(jù)的穩(wěn)定性，特別是一些 checkpoint 數(shù)據(jù)損壞，導(dǎo)致大量數(shù)據(jù)丟失。在不穩(wěn)定的 GPU 環(huán)境中自建 Ceph 存儲(chǔ)的運(yùn)維成本過高，且很難有效管理。
在中期，我們?nèi)孓D(zhuǎn)向采用高性能商業(yè)化存儲(chǔ)解決方案，如 DDN、GPFS 等。這些傳統(tǒng)高性能商業(yè)化存儲(chǔ)的主要優(yōu)勢是性能高、運(yùn)維簡單。然而，我們也遇到了一些問題。
首先，這類商業(yè)存儲(chǔ)的價(jià)格較高，且供貨周期較長，有時(shí)擴(kuò)容需要 1 到 2 個(gè)月。
另一個(gè)主要的劣勢是它們的 CSI 兼容性不理想。例如，GPFS 的 CSI 兼容性不好，特別是在處理 quota 時(shí)存在問題，導(dǎo)致即使我們啟用了 quota 功能，但在 GPFS 卷上并沒有滿足業(yè)務(wù)預(yù)期。這使得平臺(tái)出現(xiàn)了“某用戶填滿文件系統(tǒng)，導(dǎo)致其他任務(wù)掛掉”的問題，且無法通過常規(guī)方式解決。解決方案可能需要在 GPFS 上再加一層額外的存儲(chǔ)管理系統(tǒng)，但這會(huì)導(dǎo)致性能下降，得不償失。
盡管這些傳統(tǒng)商業(yè)化存儲(chǔ)在性能和運(yùn)維上有明顯優(yōu)勢，但它的兼容性和成本問題仍然是我們面臨的挑戰(zhàn)。
從集群獨(dú)立存儲(chǔ)到統(tǒng)一中心存儲(chǔ)
最初，在我們的架構(gòu)中，每個(gè)集群有不同的用途，如訓(xùn)練集群、推理集群等。它們都有自建的存儲(chǔ)系統(tǒng)，數(shù)據(jù)準(zhǔn)備要在各個(gè)集群的存儲(chǔ)系統(tǒng)間遷移數(shù)據(jù)，且大量依賴人工操作，過程繁瑣又效率低下，往往都要持續(xù)幾天，且極容易出錯(cuò)。
（智譜集群獨(dú)立存儲(chǔ)到中心存儲(chǔ)的架構(gòu)轉(zhuǎn)變）
為了解決這個(gè)問題，我們逐步引入了統(tǒng)一的中心存儲(chǔ)解決方案。具體來說，我們在公有云上建立了一個(gè)中心存儲(chǔ)，通過專線連接所有集群（包括訓(xùn)練集群和推理集群），確保集群之間的數(shù)據(jù)可以無縫對接。這樣，每個(gè)集群都能訪問到一個(gè)統(tǒng)一的命名空間。例如，A 集群訓(xùn)練好的 checkpoint 可以直接在 B 集群中訪問，無需額外的拷貝操作。
通過這個(gè)跨集群的統(tǒng)一存儲(chǔ)方案，所有集群的數(shù)據(jù)共享變得更加高效，且實(shí)現(xiàn)了類似 K8s 卷的跨集群掛載，使得任務(wù)提交和數(shù)據(jù)訪問變得更加便捷。
使用 JuiceFS 構(gòu)建中心存儲(chǔ)
雖然中心存儲(chǔ)方案看起來非常理想，但實(shí)際實(shí)現(xiàn)起來仍然有不少挑戰(zhàn)。經(jīng)過調(diào)研，我們最終選擇了 JuiceFS 來構(gòu)建我們的中心存儲(chǔ)。JuiceFS 提供了優(yōu)秀的鏡像文件系統(tǒng)和鏡像寫入能力，適合我們的需求。
（JuiceFS 鏡像讀寫流程圖）
我們中心存儲(chǔ)的架構(gòu)是這樣組織的：
公有云對象存儲(chǔ)：所有資源都存儲(chǔ)在公有云上的對象存儲(chǔ)中，我們通過專線連接公有云和集群。每個(gè)集群之間都通過 100G 專線進(jìn)行連接?？紤]到穩(wěn)定性問題，目前我們采用主備 100G 專線來確?？煽啃浴?/p>
鏡像文件系統(tǒng)：主文件系統(tǒng)位于公有云上，在集群內(nèi)部署 JuiceFS 的鏡像文件系統(tǒng)，鏡像文件系統(tǒng)部署在 200G 的存儲(chǔ)網(wǎng)上，這大大提高了訪問速度。
分布式緩存：使用 JuiceFS 提供的獨(dú)立分布式緩存組。我們將 GPU 節(jié)點(diǎn)上的 NVMe 盤用在分布式緩存，能夠提供 PB 級別的緩存。相比原來用這些 NVMe 盤來構(gòu)建 Ceph 集群的方案，緩存數(shù)據(jù)本身是不怕丟失的，即使緩存盤的節(jié)點(diǎn)故障，只需要從中心存儲(chǔ)上重新拉取數(shù)據(jù)。另外 Ceph 使用三副本存儲(chǔ)，而分布式緩存使用單副本存儲(chǔ)，意味著 分布式緩存的容量會(huì)更大，甚至超過集群中傳統(tǒng)商業(yè)存儲(chǔ)的緩存容量。
支持多協(xié)議訪問的統(tǒng)一命名空間：完全兼容 POSIX 和 S3 協(xié)議的數(shù)據(jù)訪問支持，同時(shí)滿足機(jī)器學(xué)習(xí)平臺(tái)數(shù)據(jù) Pipeline 的高性能處理和研發(fā)人員管理數(shù)據(jù)的便捷性。
我們使用 JuiceFS 的整體邏輯是，將源集群部署在公有云，其底層數(shù)據(jù)存儲(chǔ)在對象存儲(chǔ)上。JuiceFS 采用的是元數(shù)據(jù)與數(shù)據(jù)分離的架構(gòu)。我們在鏡像集群內(nèi)部署了元數(shù)據(jù)的鏡像。通過一系列同步策略和寫入策略，確保數(shù)據(jù)的強(qiáng)一致性。這意味著，當(dāng)用戶在任意一個(gè)集群修改數(shù)據(jù)時(shí)，在寫確認(rèn)后，其他集群可以立即看到更新，從而實(shí)現(xiàn)了跨集群的統(tǒng)一命名空間。另外，JuiceFS 支持幾乎所有的公有云對象存儲(chǔ)，同時(shí)也支持如 Ceph、MinIO 等開源和兼容 S3 協(xié)議的商業(yè)私有化對象存儲(chǔ)，借助 JuiceFS 可以幫助業(yè)務(wù)層屏蔽各個(gè)集群自建的底層存儲(chǔ)的異構(gòu)性，實(shí)現(xiàn)統(tǒng)一、多融合的中心存儲(chǔ)管理。
我們對存儲(chǔ)性能進(jìn)行了測試，發(fā)現(xiàn)整體表現(xiàn)不錯(cuò)。在單進(jìn)程寫入性能上，表現(xiàn)比較理想，能夠滿足需求。對于讀取性能，主要有冷讀和熱讀兩種情況：
冷讀：是指當(dāng)數(shù)據(jù)不在集群的緩沖區(qū)內(nèi)時(shí)，而通過專線回源對象存儲(chǔ)。冷讀性能雖不如本地存儲(chǔ)理想，但在實(shí)際應(yīng)用中已經(jīng)足夠滿足需求。
熱讀：熱讀性能表現(xiàn)出色，基本可以與本地的高性能商業(yè)存儲(chǔ)持平。
（JuiceFS 性能測試）
根據(jù)我們的經(jīng)驗(yàn)，存儲(chǔ)性能不必追求極致，只要確保訓(xùn)練數(shù)據(jù)讀取不成為瓶頸即可。過度追求單點(diǎn)性能可能導(dǎo)致緩存雪崩。例如，我們曾通過激進(jìn)的預(yù)讀調(diào)優(yōu)，使單節(jié)點(diǎn)達(dá)到了 100+GB/s 的吞吐量，但過多的讀取線程導(dǎo)致緩存崩潰，致使很多緩存組節(jié)點(diǎn)失聯(lián)，最終出現(xiàn)雪崩現(xiàn)象，反而需要 GPU 節(jié)點(diǎn)回源對象存儲(chǔ)影響讀取性能。因此，我們決定不再追求單節(jié)點(diǎn)的極限性能，而是通過多個(gè)節(jié)點(diǎn)聚合來充分利用專線帶寬。實(shí)際訓(xùn)練場景通常是多機(jī)訓(xùn)練，單機(jī)性能并非關(guān)鍵，確保專線帶寬的充分利用即可滿足需求。
在機(jī)器學(xué)習(xí)平臺(tái)的集成過程中，我們發(fā)現(xiàn)使用 JuiceFS 非常方便，其中一大優(yōu)勢在于其完善的 CSI 驅(qū)動(dòng)。不同于其他傳統(tǒng)商業(yè)存儲(chǔ)，JuiceFS 的 CSI 驅(qū)動(dòng)非常完善，能夠無縫對接我們的平臺(tái)資源體系，支持跨集群的云個(gè)人卷概念。這樣，如果任務(wù)只使用云個(gè)人卷，數(shù)據(jù)就能夠在不同集群之間無縫調(diào)度。
此外，它的 quota 配置還是非常完善的，而且它有非常及時(shí)的統(tǒng)計(jì)信息，甚至可以實(shí)時(shí)顯示例如一個(gè) 300TB 的卷已經(jīng)使用了 167TB，占比 55%。同時(shí)，我們還可以限制文件數(shù)量，因?yàn)檫^多的文件會(huì)帶來管理壓力。因此，我們可以設(shè)置文件數(shù)量的限制。整體而言，這些功能使得存儲(chǔ)系統(tǒng)能夠非常友好地與我們的機(jī)器學(xué)習(xí)平臺(tái)無縫集成。
這個(gè)中心存儲(chǔ)架構(gòu)，給我們帶來了如下優(yōu)勢：
減少單個(gè)集群本地存儲(chǔ)容量的硬性要求：在大規(guī)模數(shù)據(jù)處理中，尤其是多模態(tài)應(yīng)用，數(shù)據(jù)量通常達(dá)到 PB 級別。傳統(tǒng)的分散集群架構(gòu)需要將數(shù)據(jù)拷貝到各個(gè)集群進(jìn)行訪問。采用 JuiceFS 的中心存儲(chǔ)架構(gòu)后，用戶幾乎無需感知數(shù)據(jù)存取過程，能夠方便地使用數(shù)據(jù)，避免了傳統(tǒng)方式中數(shù)據(jù)頻繁拷貝的開銷。
有效利用 GPU 節(jié)點(diǎn)本地磁盤：GPU 節(jié)點(diǎn)通常帶有多個(gè) NVMe 硬盤，由于節(jié)點(diǎn)本身的故障率較高，傳統(tǒng)的分布式存儲(chǔ)方案（如 Ceph）容易導(dǎo)致存儲(chǔ)集群頻繁故障，造成較差的可用性。在新的架構(gòu)中，數(shù)據(jù)存儲(chǔ)于對象存儲(chǔ)，NVMe 盤資源用于數(shù)據(jù)緩存，從而顯著提升數(shù)據(jù)訪問效率。
便于集群遷移：訓(xùn)練任務(wù)可以在新集群直接啟動(dòng)，無需額外的數(shù)據(jù)準(zhǔn)備。數(shù)據(jù)訪問會(huì)在中心存儲(chǔ)和集群本地的分布式緩存中透明路由，集群加載數(shù)據(jù)在從中心對象存儲(chǔ)上下載過程中會(huì)自動(dòng)加載到集群本地的分布式緩存中，下一次訪問時(shí)，數(shù)據(jù)讀取直接命中本地分布式緩存，從而加速數(shù)據(jù)讀取效率。
多集群大一統(tǒng)調(diào)度：未來，我們計(jì)劃實(shí)現(xiàn)多個(gè)集群的大一統(tǒng)調(diào)度，將多個(gè)集群整合為一個(gè)開發(fā)環(huán)境，通過集中調(diào)度最大化資源利用率，從而提升整體架構(gòu)的效率。
5總結(jié)
在發(fā)展的初期，我們專注于系統(tǒng)穩(wěn)定性，快速利用現(xiàn)有機(jī)器資源，推動(dòng)模型的研發(fā)和訓(xùn)練。在擴(kuò)張期，我們通過標(biāo)準(zhǔn)化抽象屏蔽了復(fù)雜的異構(gòu)細(xì)節(jié)，提升了平臺(tái)的易用性，進(jìn)一步支持了高效的模型研發(fā)。而在成熟期，我們解決了存儲(chǔ)和數(shù)據(jù)流轉(zhuǎn)的核心難題，優(yōu)化了跨集群的數(shù)據(jù)管理和調(diào)度，提高了整體資源利用率。隨著系統(tǒng)的不斷完善，中心存儲(chǔ)架構(gòu)的引入使得大規(guī)模數(shù)據(jù)處理變得更加高效。
關(guān)于作者
曾奧涵，智譜 GLM 基座模型 & 訓(xùn)練基礎(chǔ)設(shè)施負(fù)責(zé)人，作為主要開發(fā)者參與了 GLM-130B、ChatGLM、GLM-4 (All Tools)、GLM-4-Plus、GLM-4-Voice 等模型或系統(tǒng)的研發(fā)。
會(huì)議推薦
AICon 2025 強(qiáng)勢來襲，5 月上海站、6 月北京站，雙城聯(lián)動(dòng)，全覽 AI 技術(shù)前沿和行業(yè)落地。大會(huì)聚焦技術(shù)與應(yīng)用深度融合，匯聚 AI Agent、多模態(tài)、場景應(yīng)用、大模型架構(gòu)創(chuàng)新、智能數(shù)據(jù)基建、AI 產(chǎn)品設(shè)計(jì)和出海策略等話題。即刻掃碼購票，一同探索 AI 應(yīng)用邊界！
熱門跟貼