那曲檬骨新材料有限公司

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Meta萬卡GPU集群穩(wěn)定性剖析與最佳實踐

SDNLAB ? 來源:SDNLAB ? 2024-12-17 09:51 ? 次閱讀

一、背景

本文中我們將具體介紹 Meta 對其萬卡 AI 集群穩(wěn)定性的剖析和刻畫,以及在其中遇到的各種挑戰(zhàn),并在其中補(bǔ)充了一些真實場景中遇到的 Case,便于理解。

對應(yīng)的論文為:[2410.21680] Revisiting Reliability in Large-Scale Machine Learning Research Clusters [1](文末附下載

二、摘要

可靠性是運維大規(guī)模機(jī)器學(xué)習(xí)基礎(chǔ)設(shè)施的重要挑戰(zhàn),尤其是 ML 模型和訓(xùn)練集群的規(guī)模在不斷擴(kuò)大,這一挑戰(zhàn)更加明顯。盡管對基礎(chǔ)設(shè)施故障的研究已經(jīng)有數(shù)十年歷史,但不同規(guī)模下作業(yè)故障的影響仍然不是特別明確。

本文中,作者從管理兩個大型多租戶 ML 集群的視角,提供了相應(yīng)的定量分析、運維經(jīng)驗以及在理解和應(yīng)對大規(guī)??煽啃詥栴}上的見解(PS:我們也會重點標(biāo)記其對應(yīng)的 12 個見解)。分析表明,盡管大型作業(yè)最容易受到故障影響,但小型作業(yè)在集群中占大多數(shù),也應(yīng)納入優(yōu)化目標(biāo)。作者識別了關(guān)鍵工作負(fù)載的屬性,進(jìn)行了跨集群比較,并展示了擴(kuò)展大規(guī)模 ML 訓(xùn)練所需的基本可靠性要求。

本文中,作者引入了一種故障分類法和關(guān)鍵可靠性指標(biāo),分析了兩個最先進(jìn)的 ML 集群 11 個月內(nèi)的數(shù)據(jù),涉及超過 1.5 億 GPU 小時和 400 萬個作業(yè)。基于數(shù)據(jù),作者擬合了一個故障模型,以預(yù)測不同 GPU 規(guī)模下的平均故障時間。作者也進(jìn)一步提出了一種方法,根據(jù)作業(yè)參數(shù)估計相關(guān)指標(biāo)——有效訓(xùn)練時間比(Effective Training Time Ratio,ETTR),并利用該模型評估潛在的緩解措施在大規(guī)模環(huán)境中的有效性。

三、Infra 系統(tǒng)

本節(jié)中作者闡述了工作負(fù)載如何影響集群的設(shè)計。盡管集群可以特化以針對特定工作負(fù)載進(jìn)行優(yōu)化,但集群會面對持續(xù)變化并且可能難以預(yù)見潛在的工作負(fù)載需求。因此,作者認(rèn)為集群應(yīng)該具備通用性,以最大化生產(chǎn)力,并最小化附帶復(fù)雜性。作者重點關(guān)注早期的兩個 A100 集群(PS:Meta 后續(xù)又搭建了 2 個 24K H100 GPU 的集群),RSC-1 和 RSC-2,它們遵循相同的設(shè)計模板。

RSC-1 是一個通用 ML 集群(例如,訓(xùn)練一些 LLM),規(guī)模為 16,000 個 A100 GPU;

RSC-2 專注于計算機(jī)視覺應(yīng)用,規(guī)模為 8,000 個 A100 GPU。

后續(xù)章節(jié)也會具體介紹,工作負(fù)載的差異體現(xiàn)在不同的使用模式中,例如,RSC-2 上的工作負(fù)載顯著傾向于 1-GPU 的作業(yè),同時也有高達(dá) 1,000 個 GPU 的作業(yè)。

3.1 調(diào)度和存儲 Infra

RSC-1 和 RSC-2 集群設(shè)計以易用性為優(yōu)先考量,同時追求簡潔性。其優(yōu)勢在于整個技術(shù)棧相對成熟,無需大規(guī)模定制相關(guān)數(shù)據(jù)中心設(shè)計。此外,設(shè)計也力求在不附加任何條件的情況下為用戶提供所需數(shù)量的 GPU,以最大化生產(chǎn)力——用戶無需應(yīng)對新型硬件或虛擬化帶來的復(fù)雜性。如下圖 Fig 1 展示了用戶如何與集群進(jìn)行交互,用戶提交包含多個任務(wù)的作業(yè),每個任務(wù)均可運行于節(jié)點的 GPU 上:

a27540be-b790-11ef-93f3-92fbcf53809c.png

調(diào)度器(Scheduler):依托高性能計算(HPC)技術(shù)棧,作者的機(jī)器采用基于裸金屬分配的 Slurm 調(diào)度器(Slurm Workload Manager [2])。用戶通過 Shell 腳本(sbatch)或 Python 裝飾器(submitit)提交作業(yè)。Slurm 則根據(jù)物理網(wǎng)絡(luò)拓?fù)浞胖萌蝿?wù)。作業(yè)運行 2 小時后可以被搶占,并且最長生命周期為 7 天。Scheduler 根據(jù)優(yōu)先級順序安排任務(wù),優(yōu)先級受多種變量影響,包括項目配額以及任務(wù)時長。

ML工作負(fù)載遵循 Gang Scheduling 語義。Gang Scheduling 確保同一作業(yè)的多個任務(wù)所需的資源同時分配,這對于大規(guī)模 ML 工作負(fù)載的性能和效率優(yōu)化至關(guān)重要。然而,如上圖 Fig 1 所示,單個任務(wù)失敗可能導(dǎo)致整個作業(yè)的重新分配。針對這種情況,通常會采用容錯策略,比如 Checkpointing 和冗余計算,以支持集群的容錯調(diào)度。Checkpointing 確保作業(yè)可以從保存的狀態(tài)恢復(fù),減少對整體作業(yè)的影響,而冗余計算則降低作業(yè)失敗的概率。基礎(chǔ)設(shè)施會為用戶提供這種保障機(jī)制——若健康檢查導(dǎo)致作業(yè)終止,系統(tǒng)會自動將作業(yè)重新排隊,且保留相同的作業(yè) ID。整體而言,RSC-1 集群平均每日提交 7.2k 作業(yè),RSC-2 集群平均每日提交 4.4k 作業(yè),并分別實現(xiàn) 83% 和 85% 的集群利用率。

存儲(Storage):輸入、輸出數(shù)據(jù)以及作業(yè)的 Checkpoint 需要具備持久性,并獨立于特定作業(yè)的生命周期。作者的集群提供了 3 種存儲服務(wù),使用戶能夠在易用性和性能之間進(jìn)行權(quán)衡選擇:

基于閃存存儲,采用 NFS 協(xié)議并兼容 POSIX 的存儲服務(wù)。便于使用,為用戶提供主目錄、Python 環(huán)境及執(zhí)行常見操作(如 Checkpointing)的讀寫能力。

AirStore,自定義、高帶寬的存儲服務(wù)。通過自定義的高性能只讀緩存服務(wù) AirStore 加速數(shù)據(jù)集訪問,同樣依托于大規(guī)模閃存存儲。

ObjectStore,高容量與高吞吐量的對象存儲服務(wù)。用于 Checkpoint 和文件存儲,應(yīng)對 NFS 存儲有限的問題。

3.2 計算和網(wǎng)絡(luò) Infra

高性能計算集群的核心硬件組件包括計算、網(wǎng)絡(luò)和存儲。用戶通過提交給 Scheduler 的作業(yè)來提供使用這些組件的指令。集群的拓?fù)浣Y(jié)構(gòu)如下圖 Fig 2 所示,其中展示了節(jié)點系統(tǒng)的布局以及單個節(jié)點的內(nèi)部結(jié)構(gòu):

a29e3e10-b790-11ef-93f3-92fbcf53809c.png

計算(Compute):RSC-1 和 RSC-2 兩個集群均為基于 DGX 的裸金屬集群,每個節(jié)點配備雙 AMD Rome 7742 CPU 和 8 塊 NVIDIA A100 80GB GPU。GPU 之間通過高帶寬的 NVLink + NVSwitch 互聯(lián)。

網(wǎng)絡(luò)(Networking):在實際應(yīng)用中,一個作業(yè)可能使用數(shù)百個節(jié)點,這些節(jié)點通過前端(Frontend)和后端(Backend)兩種方式互聯(lián)。前端網(wǎng)絡(luò)主要用于以太網(wǎng)管理平面(即調(diào)度和 TCP 連接)和存儲流量。同時,如上圖 Fig 2 所示,節(jié)點后端網(wǎng)絡(luò)通過 IB 鏈接,在模型訓(xùn)練期間可以實現(xiàn)低延遲的梯度交換。通信被劃分為邏輯域:每個機(jī)架包含 2 個節(jié)點,10 個機(jī)架通過優(yōu)化的網(wǎng)絡(luò)連接,形成一個 Pod,Pod 內(nèi)的通信只用通過 Leaf 交換機(jī),Pod 間的通信需要通過 Spine 交換機(jī)。

Scheduler 和模型訓(xùn)練框架(如 Pytorch)應(yīng)抽象出網(wǎng)絡(luò)的大部分復(fù)雜性,提供基于傳統(tǒng)集合通信的模型,該模型應(yīng)具備跨多種作業(yè)分配的可移植性和高效性。關(guān)鍵在于,后端網(wǎng)絡(luò)軟件能夠利用存在的局部性(例如,可能的話,優(yōu)先使用高帶寬的 NVSwitch,而非同構(gòu)機(jī)架頂部的 Tor Switch 連接)。

3.3 集群 Infra 的見解

見解 1:集群正常運行時間至關(guān)重要。作者的集群處于滿負(fù)載狀態(tài),任何停機(jī)都會導(dǎo)致過度排隊,并被視為重大事件。集群應(yīng)該能夠?qū)崟r適應(yīng)故障,理想情況下應(yīng)自動重新排隊與 Infra 相關(guān)的故障。

健康檢查:由于機(jī)器學(xué)習(xí)作業(yè)的 Gang Scheduling 調(diào)度語義,故障對整個作業(yè)的可靠性影響巨大——系統(tǒng)組件的單一故障可能導(dǎo)致數(shù)千個 GPU 閑置。此外,在大規(guī)模集群中,組件故障之間的間隔時間可能很短。為此,作者的 Infra 設(shè)計側(cè)重于檢查作業(yè)是否在健康硬件上運行,并在發(fā)生故障時將作業(yè)在不同節(jié)點重啟。

為了發(fā)現(xiàn)、檢測并移除故障節(jié)點,Scheduler 相應(yīng)會接收集群中每個節(jié)點定期執(zhí)行的一系列健康檢查的結(jié)果,通過這些健康檢查也可以分析作業(yè)故障。作者的訓(xùn)練集群設(shè)計的核心理念是力求避免異常節(jié)點導(dǎo)致的二次作業(yè)失敗——故障節(jié)點不是一個好的調(diào)度候選。

Slurm 可以在作業(yè)運行前后執(zhí)行健康檢查。此外,也會每 5 分鐘執(zhí)行一次健康檢查,并返回表示成功、失敗和警告的 Code。每個健康檢查都會檢查節(jié)點的幾個方面,涵蓋從 GPU 錯誤(如 XID 錯誤)到文件系統(tǒng)掛載錯誤及服務(wù)狀態(tài)(例如,Scheduler)。需要注意的是,檢查可能具有重疊的故障域信號,例如,即使 GPU 本身未發(fā)生相應(yīng)的 XID 事件,PCIe 故障也可表明 GPU 不可用。這種情況在 RSC-1 上出現(xiàn)的頻率為 57%,在 RSC-2 上為 37%。因此,即使某一檢測未能如期觸發(fā),另一重疊的檢測也有望捕捉到這一問題。此種情況最極端的例子是 NODE_FAIL,用于當(dāng)節(jié)點未能對其他檢測做出響應(yīng)時,通過 Slurm 的心跳機(jī)制實現(xiàn)的全面捕獲手段。

定期健康檢測對于防止同一異常節(jié)點導(dǎo)致的重復(fù)作業(yè)失敗至關(guān)重要。此外,這些檢測也經(jīng)過一系列調(diào)整,以降低誤報率,這使得成功完成的作業(yè)中觀察到健康檢查失敗的比例低于 1%,當(dāng)然,也只是觀察到相關(guān)性而非因果關(guān)系。

不同檢測的嚴(yán)重程度各異。當(dāng)節(jié)點健康檢查失敗時,節(jié)點將進(jìn)入修復(fù)狀態(tài),直到修復(fù)完成且所有檢測通過前,無法再進(jìn)行作業(yè)調(diào)度。

高嚴(yán)重性檢測異常會立即向 Scheduler 發(fā)出信號,移除該節(jié)點并重新調(diào)度所有在該節(jié)點上執(zhí)行的作業(yè)。包括 GPU 不可訪問,NVLink 錯誤,不可糾正的 ECC 錯誤,行重映射(failed row-remaps),PCIe 或 IB 鏈路錯誤,塊設(shè)備錯誤或掛載點缺失。

而較低嚴(yán)重性的檢測異常則會等節(jié)點上的作業(yè)完成(無論成功與否)再向 Scheduler 發(fā)送移除節(jié)點信號并進(jìn)行修復(fù)。

未觸發(fā)任何健康檢查異常的節(jié)點可用于作業(yè)調(diào)度。

健康檢查的重要性也可以通過反向?qū)嶒烌炞C,比如在可能存在異常的節(jié)點上調(diào)度。即使只有一小部分節(jié)點異常,隨著規(guī)模的擴(kuò)大,作業(yè)調(diào)度到異常節(jié)點的概率會呈指數(shù)級增加。需要強(qiáng)調(diào)的是,健康檢查是確??煽?Infra 的第一道防線。

見解 2:一顆老鼠屎壞了一鍋湯。健康檢查機(jī)制能夠防止因反復(fù)調(diào)度到故障節(jié)點而引起的關(guān)聯(lián)性故障(也就是“循環(huán)重啟”)。若無法將此類節(jié)點移除,將導(dǎo)致無法有效運行大規(guī)模作業(yè),并嚴(yán)重削弱集群效率,唯有確保故障節(jié)點能夠可靠地移除,從隨機(jī)故障中恢復(fù)才會有實際效果。

3.4 指標(biāo)

有三個關(guān)鍵指標(biāo)可以幫助理解機(jī)器學(xué)習(xí)集群性能:有效訓(xùn)練時間比(Effective Training Time Ratio,ETTR)、模型浮點運算利用率(Model Flops Utilization,MFU)和 有效產(chǎn)出(Goodput)。

有效訓(xùn)練時間比(ETTR):ETTT 定義為生產(chǎn)性運行時間與作業(yè)運行時間的比值。一個作業(yè)運行包含一個或多個與同一邏輯任務(wù)相關(guān)的調(diào)度任務(wù)。例如,一個為期數(shù)周的 LLM 預(yù)訓(xùn)練作業(yè)可能包含多個不同的任務(wù),這些任務(wù)因為搶占、中斷或 Infra 異常而切分(忽略用戶空間故障對 ETTR 的影響)。作業(yè)運行時間定義為多任務(wù)運行中某個任務(wù)被調(diào)度或符合調(diào)度條件但正在隊列中等待的總時間。生產(chǎn)性運行時間為工作負(fù)載取得實質(zhì)性進(jìn)展的時間(比如,模型在真正訓(xùn)練的時間)。生產(chǎn)性運行時間的精確定義因上下文而異,作者認(rèn)為其存在兩種非生產(chǎn)性調(diào)度時間:1)從上次 Checkpoint 加載后的追趕時間:在最新 Checkpoint 和作業(yè)中斷之間重新訓(xùn)練;2)重啟開銷:重啟后需要執(zhí)行所有初始化操作,這些操作在正常情況下是不必要的。這兩者高度依賴具體的作業(yè),目前缺乏可靠的大規(guī)模追蹤方法,作者根據(jù)和各團(tuán)隊合作找那個遇到的合理值進(jìn)行填充。

ETTR 的取值范圍從 0(作業(yè)從未取得實質(zhì)性進(jìn)展)到 1(100% 的時間用于實際訓(xùn)練,沒有排隊或非生產(chǎn)性時間)。ETTR 類似于經(jīng)典的作業(yè)延遲指標(biāo),然而,ETTR 額外考量了非生產(chǎn)性時間,并反轉(zhuǎn)了比例,以期獲得更好的可解釋性。

模型浮點運算利用率(MFU):業(yè)界普遍采用的指標(biāo)。對應(yīng)于模型理論上利用的浮點運算次數(shù)與硬件峰值浮點運算次數(shù)的比值,MFU 可用于捕獲性能下降或次優(yōu)實現(xiàn)的情況。兩者雖然不同,但是在測量運行時間與理想狀態(tài)的比例方面是可比的,且都介于 0 到 1 之間,不過 MFU 往往更低,比如 LLaMA 3 在 H100 訓(xùn)練,MFU 只有 38%-43%,而 ETTR 可以超過 80%。

有效產(chǎn)出(Goodput):上述兩個指標(biāo)主要用于衡量每個作業(yè),而 Goodput 可以用于衡量整個集群,即單位時間內(nèi)完成的有成效工作的總量。Goodput 可以通過最大可能有效產(chǎn)出進(jìn)行歸一化,介于 0-1 之間。本文中討論的集群在高負(fù)荷下運行(潛在 Goodput 僅受容量限制而非可用工作量),因此,任務(wù)搶占,資源碎片化和故障是 Goodput 損失的主要來源。

3.5 故障分類

故障分類是指將作業(yè)失敗的責(zé)任歸咎于某一原因的過程。作者的經(jīng)驗表明,故障歸類是一個充滿挑戰(zhàn)且復(fù)雜的過程。例如,NCCL 超時現(xiàn)象相對常見。在 Pytorch 中,當(dāng)某個節(jié)點觀察到集合操作在幾分鐘內(nèi)未完成時,將發(fā)生 NCCL timeout。這可能意味著網(wǎng)絡(luò)問題,但也可能是其他節(jié)點因為故障未能啟動相同的操作,例如,加載下一個 Step 數(shù)據(jù)時阻塞。在此情況下,超時的節(jié)點功能完好,而故障節(jié)點可能因為用戶軟件問題或基礎(chǔ)設(shè)施錯誤而無法響應(yīng)。從用戶堆棧 Trace 中追溯根因,需要跨越多層次、精確的分布式日志記錄,包括從 ML 應(yīng)用到分布式集合通信操作以及底層 Infra 的各個方面。

因此,如下圖 Table 1 所示,作者的故障分類法基于以下原則:任何給定癥狀可能存在多種潛在根因,限制假設(shè)空間的唯一途徑是排除不太可能的原因。作者因此提出了通過故障域的差異診斷來診斷并根除錯誤——利用多種性能指標(biāo)標(biāo)記錯誤可能發(fā)生的區(qū)域,從而將特定故障限定于少數(shù)可能的原因。

a2c19aae-b790-11ef-93f3-92fbcf53809c.png

作者的故障域涵蓋用戶代碼、系統(tǒng)軟件(如驅(qū)動程序、Pytorch、操作系統(tǒng))以及硬件。正常情況下,用戶應(yīng)確保其程序無明顯錯誤。從集群運維角度考慮,硬件錯誤需進(jìn)一步分類為瞬態(tài)錯誤(如 ECC 錯誤、鏈路抖動)或永久性錯誤(如需要供應(yīng)商維修或更換硬件)。與故障分類相關(guān)的信息追蹤必須實現(xiàn)自動化管理(例如,通過健康檢查),原因在于:1)程序與機(jī)器的配對具有不確定性;2)故障通常是罕見事件。

作者發(fā)現(xiàn),擁有涵蓋硬件和系統(tǒng)軟件多個方法的豐富信息,有助于更快地確定特定癥狀集合的成因。在某些情況,多個同時觸發(fā)的健康檢查可能指向同一錯誤(例如,PCIe 異??赡苡绊?GPU)。

如下圖所示,以我們的一個 Case 為例,訓(xùn)練時遇到過 Pytorch 拋出 CUDA error: an illegal memory access was encountered 錯誤:

a2d4e118-b790-11ef-93f3-92fbcf53809c.png

同時查看相關(guān)系統(tǒng)信息發(fā)現(xiàn) GPU 有 Xid 31 的錯誤:

a2ec4556-b790-11ef-93f3-92fbcf53809c.png

進(jìn)一步根據(jù) NVIDIA Xid 文檔(1. Introduction — XID Errors r555 documentation [3])可知,Xid 31 大部分為用戶程序問題,比如訪存越界等,但也有一定可能是驅(qū)動 Bug 或硬件 Bug:

a30521c0-b790-11ef-93f3-92fbcf53809c.png

見解 3:警惕誤導(dǎo)性線索。具有多種潛在成因的錯誤難以診斷,例如,NCCL 超時錯誤可能被簡單歸咎于近因(proximal cause),比如網(wǎng)絡(luò)問題而非死鎖。網(wǎng)絡(luò)具有更廣泛的影響范圍,導(dǎo)致可能橫跨整個系統(tǒng)堆棧。其他錯誤則與特定節(jié)點硬件相關(guān),隨著其發(fā)生頻率增加,可能性也隨之上升,如上圖 Table 1 是作者總結(jié)的分類法和相關(guān)經(jīng)驗。

同樣以我們自己的一個 Case 為例,如下圖所示,訓(xùn)練中可能會遇到 NCCL timeout 的錯誤,由于缺乏有用的信息,通常很難穩(wěn)定復(fù)現(xiàn)這類異常,調(diào)試起來非常困難。

a317fd22-b790-11ef-93f3-92fbcf53809c.png

為了解決這個問題,常見的方式是 Fork NCCL 代碼,添加相應(yīng)的時間戳信息,以便更好地顯示崩潰發(fā)生時正在執(zhí)行的消息或操作,從而確定哪個 Node 或 GPU 可能阻塞了,如下圖所示為 ImbueAI 在解決類似問題時的方案(https://github.com/boweiliu/nccl/commit/0966031bdb5905b8ea5aef3fb2a8ce6317040234)。

a32703c6-b790-11ef-93f3-92fbcf53809c.png

Meta 在 LLaMA 3 的技術(shù)報告(The Llama 3 Herd of Models | Research - AI at Meta [4])也提到相關(guān)的解決方案。具體來說,為了增加有效訓(xùn)練時間,減少作業(yè)啟動和 Checkpointing 時間,LLaMA 3 作者開發(fā)了用于快速診斷和解決問題的工具。其主要是利用 Pytorch 內(nèi)置的 NCCL flight recorder(參考 PyTorch 2: Faster Machine Learning Through Dynamic Python Bytecode Transformation and Graph Compilation [5]),將集合通信的元數(shù)據(jù)以及堆棧信息捕獲到 ring buffer 中,基于此可以快速診斷 Hang 以及性能相關(guān)問題,尤其是與 NCCLX(Meta 的內(nèi)部 NCCL 版本) 相關(guān)的問題。利用此功能,可以有效地記錄每個通信事件以及每個集合通信操作的持續(xù)時間,并且可以自動將 Trace 信息轉(zhuǎn)存到 NCCLX Watchdog 或 Heart timeout。也可以在生產(chǎn)環(huán)境中在線修改配置,以便根據(jù)需要選擇性地實現(xiàn)計算密集型的跟蹤操作和元數(shù)據(jù)收集,而無需發(fā)布代碼或重新啟動作業(yè)。

四、理解大型 ML 訓(xùn)練集群的現(xiàn)狀

這里的分析基于上述的兩個集群,涵蓋 11 個月的觀察數(shù)據(jù)。分析建立在 Slurm Scheduler 和前面介紹的健康檢查的基礎(chǔ)上。需要說明的是,這里討論的集群存在過度配置現(xiàn)象,因此項目級的 QoS 和服務(wù)分配是決定哪些作業(yè)可以運行的主要因素。

Scheduler 作業(yè)狀態(tài)細(xì)分:Slurm 作業(yè)可能處于以下狀態(tài)之一:Cancelled(取消)、Completed(完成)、Out_of_Memory(內(nèi)存不足)、Failed(應(yīng)用返回非零退出碼)、Node_Fail(節(jié)點故障)、Preempted(為更高優(yōu)先級作業(yè)讓位)、Requeued(重新排隊)或 Timeout(超時)。如下圖 Fig 3 展示了 RSC-1 集群的 Scheduler 作業(yè)狀態(tài)細(xì)分。60% 的作業(yè)成功完成,24% 和 0.1% 的作業(yè)分別有 Failed 和 Node_fail 失敗,10% 的作業(yè)被搶占,2% 的作業(yè)重新排隊,0.1% 的作業(yè)內(nèi)存不足失敗,0.6% 的作業(yè)超時。

a3331210-b790-11ef-93f3-92fbcf53809c.png

如上圖 Fig 3 所示,其中 Infra 故障(HW)只影響了 0.2% 的作業(yè),但影響了 18.7% 的運行時間。鑒于預(yù)期 Infra 故障會影響大型作業(yè)(這類作業(yè)數(shù)量很少,但占用大量運行資源),這一現(xiàn)象也并不意外(可以參考后文 Fig 6)。

見解 4:由于健康檢查機(jī)制,硬件故障構(gòu)成了一組罕見的結(jié)果。硬件故障只影響了不到 1% 的作業(yè),但影響了 19% 的 GPU 運行時間。一旦考慮 Checkpointing 機(jī)制,這種影響顯著減小,因為 Checkpointing 緩解了這種損失。

作業(yè)級故障刻畫:歸因于硬件的故障可根據(jù)歸因進(jìn)一步細(xì)分。這些原因可以按照節(jié)點級組件細(xì)分,如 GPU、網(wǎng)絡(luò)及各種系統(tǒng)組件,如文件系統(tǒng)。如下圖 Fig 4 中展示了 RSC-1 和 RSC-2 集群每小時每 GPU 的故障率。若故障原因在作業(yè)失敗前 10 分鐘內(nèi)或失敗后 5 分鐘內(nèi)被檢測到(Failed 或 Node_Fail),則將故障歸因于該原因。需要注意的是,作者根據(jù)所開發(fā)的啟發(fā)式方法報告了最可能的故障原因,該方法指示節(jié)點是否應(yīng)被隔離以進(jìn)行相關(guān)修復(fù)。某些故障可能有多重原因。一些 Node_Fail 事件并未與任何健康檢查相關(guān)聯(lián),這可能是節(jié)點本身變得無響應(yīng)。其中 IB 鏈路、文件系統(tǒng)掛載、GPU 內(nèi)存錯誤和 PCIe 錯誤占比最大。

a342d498-b790-11ef-93f3-92fbcf53809c.png

對于 IB 鏈路而言,似乎主要由 2024 年夏季少數(shù)節(jié)點在短時間內(nèi)發(fā)生的眾多 IB 鏈路故障相關(guān),如下圖 Fig 5 的黃色部分。其中 GSP 超時是由代碼回退引起,該問題通過驅(qū)動補(bǔ)丁得以修復(fù)。

a359f52e-b790-11ef-93f3-92fbcf53809c.png

我們在 A100 中也遇到過 GSP(GPU System Processor) 相關(guān)問題,通過關(guān)閉 GSP 可以解決。阿里云的 FAQ 中也有相關(guān)介紹,如下所示,具體可以參考 ACK集群GPU使用常見問題和解決方法- 容器服務(wù)Kubernetes 版 ACK - 阿里云 [6]:

a3f64b5e-b790-11ef-93f3-92fbcf53809c.png

故障可能同時發(fā)生:RSC-1/RSC-2 上 3% 和 5% 的硬件故障伴隨著類似優(yōu)先級的共現(xiàn)事件,例如,作者觀察到 PCIe 錯誤常與 XID 79(通常意味著掉卡,比如從 PCIe 總線上斷開鏈接)和 IPMI “Critical Interrupt” 同時發(fā)生。在 RSC-1(及 RSC-2)上,作者觀察到 43%(63%)的 PCIe 錯誤與 XID 79 共現(xiàn),21%(49%)則同時包含所有上述 3 種事件類型。這是預(yù)料之中的,因為所有這些檢查都與 PCIe 總線健康狀況有重疊。此外,作者還觀察到 2%(6%)的 IB 鏈路故障與 GPU 故障(如與總線斷開連接)同時發(fā)生,這可能表明與 PCIe 存在關(guān)聯(lián)。

同樣以我們的一個 Case 為例,如下圖所示,使用 Pytorch 訓(xùn)練時遇到 CUDA error: unknown error 的問題:

a404efb0-b790-11ef-93f3-92fbcf53809c.png

進(jìn)一步排查發(fā)現(xiàn)系統(tǒng)中同時出現(xiàn)了 pciehp Link Down,Xid 79(GPU fallen off the bus)以及 NVSwitch timeout 的錯誤,與此同時還在后續(xù)出現(xiàn) Xid 45 的錯誤,這個就是常見的掉卡問題。

a4172cc0-b790-11ef-93f3-92fbcf53809c.png

其實 Xid 也經(jīng)常會一起出現(xiàn),如下圖所示,一個 uncorrectable 的 ECC Error 往往會伴隨多個不同的 Xid 同時出現(xiàn):

a43e0f8e-b790-11ef-93f3-92fbcf53809c.png

見解 5:許多硬件故障未被歸因,而最常見的故障歸因于后端網(wǎng)絡(luò)、文件系統(tǒng)和 GPU。GPU 有細(xì)粒度的 Xid,也有豐富的錯誤類別,不過主要的錯誤都與內(nèi)存相關(guān)。PCIe 總線錯誤和 GPU 脫離總線也非常常見并且相關(guān)聯(lián)。CPU 內(nèi)存和 Host 服務(wù)對應(yīng)用影響較小。

故障率隨著時間演變:進(jìn)一步將剖析轉(zhuǎn)向更大規(guī)模的作業(yè),相應(yīng)也切換到節(jié)點級(而非 GPU 級)剖析。如上圖 Fig 5 所示,作者展示了 RSC-1 在過去一年中的故障率情況,揭示了如下幾點:

故障率持續(xù)波動。

故障模式起伏不定:比如 23 年末,驅(qū)動程序錯誤導(dǎo)致 Xid 錯誤成為 RSC-1 上作業(yè)失敗的主要來源;24年夏季,IB 鏈路故障激增同樣推高了兩個集群的故障率。

新的健康檢測揭示新的故障模式:圖中標(biāo)識了新的健康檢查(之前就在發(fā)生,但未被準(zhǔn)確識別)添加到集群的時間點,這也會導(dǎo)致故障率看似增加。

如下圖所示,上海 AI Lab 等團(tuán)隊在 [2403.07648] Characterization of Large Language Model Development in the Datacenter [7] 中提到一個類似的故障,其 AI 集群在 2023.07(最熱的月份) 時,機(jī)房溫度升高了 5 度,導(dǎo)致故障率明顯增加:

a44b5400-b790-11ef-93f3-92fbcf53809c.png

見解 6:集群故障具有動態(tài)性,集群故障是一場持續(xù)戰(zhàn)斗,新的軟件更新也就意味著集群在不斷變化,工作負(fù)載和性能也在持續(xù)調(diào)整。

訓(xùn)練任務(wù)多樣性:必須考慮任務(wù)規(guī)模和時間,以在整體多樣性和訓(xùn)練 GPU 小時數(shù)之間取得平衡。Scheduler 需要權(quán)衡單個訓(xùn)練作業(yè)的公平性、整體集群利用率及訓(xùn)練性能。如下圖 Fig 6 所示,描繪了 RSC-1 集群中作業(yè)規(guī)模的分布,超過 40% 的訓(xùn)練作業(yè)使用單個 GPU 進(jìn)行開發(fā)或者模型評估,僅有少數(shù)大模型作業(yè),比如超過 1000 GPU。在同一個圖中,作者還展示了相對于單個 GPU 作業(yè)的 GPU 時長的歸一化結(jié)果。雖然有眾多單 GPU 作業(yè),但是 RSC-1 和 RSC-2 中分別有 66% 和 52% 的總 GPU 時間來自 256+ GPU 的作業(yè)。

a4707ea6-b790-11ef-93f3-92fbcf53809c.png

見解 7:超過 90% 的作業(yè)規(guī)模小于一臺機(jī)器(包含 8 個 GPU),但僅占不到 10% 的 GPU 時間。RSC-1 集群傾向擁有更多 8 GPU 作業(yè),而 RSC-2 則更傾向于 1 GPU 作業(yè)。RSC-1 集群往往包含規(guī)模最大的作業(yè)。

MTTF 隨規(guī)模減?。喝缦聢D Fig 7 所示,1024 GPU 作業(yè)的平均故障時間(MTTF)為 7.9 小時,比 8 個 GPU 作業(yè)(47.7 天)低約兩個數(shù)量級。這也符合預(yù)期,經(jīng)驗上,硬件可靠性與 GPU 數(shù)量成反比,且在 32 個 GPU 以上時趨勢更為一致。圖 Fig 7 還展示了從集群節(jié)點故障率推導(dǎo)出的理論預(yù)期 MTTF(MTTF ∝ 1/Ngpus):MTTF=(Nnodesrf)-1,其中 rf 根據(jù)所有超過 128 個 GPU 作業(yè)的總故障數(shù)和節(jié)點運行天數(shù)計算,與較大作業(yè)(>32 GPU)的實際 MRRF 數(shù)據(jù)吻合:

a499e2c8-b790-11ef-93f3-92fbcf53809c.png

基于在上述集群中大規(guī)模訓(xùn)練任務(wù)所觀測到的故障概率,作者預(yù)測 16384 個 GPU 任務(wù)的 MTTF 為 1.8 小時,131072 個 GPU 任務(wù)的 MTTF 為 0.23 小時。為了在故障發(fā)生時最大化 ETTR,必須加快故障檢測與恢復(fù)過程。

如下圖 Table 5 所示,Meta 在 LLaMA 3 的技術(shù)報告(The Llama 3 Herd of Models | Research - AI at Meta [4])中也描述了相關(guān)故障率,其提到在 54 天的訓(xùn)練中,共遇到 466 個任務(wù)中斷,包括 47 次的有計劃中斷,以及 419 次的預(yù)期外中斷。在這些非預(yù)期中斷中,78% 是硬件問題,例如 GPU 或物理機(jī)其他組件的異常,其中 GPU 相關(guān)問題占到 58.7%。其訓(xùn)練使用了 16384 H100 GPU,對應(yīng)的平均故障時間為 54*24/419=3 小時,也就是平均每 3 小時出現(xiàn)一次故障。當(dāng)然,組著通過自動化運維手段仍然可以獲得超過 90% 的有效訓(xùn)練時間。

a4abbdf4-b790-11ef-93f3-92fbcf53809c.png

見解 8:盡管故障并不直接影響多數(shù)作業(yè),但大型作業(yè)受其影響顯著,故障率與理論趨勢相符。在 4K 規(guī)模下,MTTF 約為 10 小時,并預(yù)計在 RSC-1 的更大規(guī)模下會進(jìn)一步下降。MTFF 預(yù)測與 RSC-1 的 4-512 節(jié)點實測 MTTF 吻合。對于 RSC-2,預(yù)測趨勢類似,但是 16 個 GPU 的實測 MTTF 數(shù)據(jù)波動較大,部分原因是一組相關(guān)任務(wù)引發(fā)多次 Node_Fail??傮w上 RSC-1 和 RSC-2 趨勢類似,部分差異可以歸因于兩個集群工作負(fù)載稍有不同觸發(fā)了不同的故障。

搶占與故障級聯(lián):作業(yè)失敗的次級效應(yīng)之一是:對其他優(yōu)先級較低且可能規(guī)模較小的作業(yè)的影響,從而導(dǎo)致級聯(lián)效應(yīng)。在實際操作中,大型作業(yè)往往具有較高的優(yōu)先級,而小型作業(yè)優(yōu)先級最低,這樣大型作業(yè)通過搶占低優(yōu)先級作業(yè)得以快速調(diào)度。當(dāng)一個大型高優(yōu)作業(yè)因硬件不穩(wěn)定而失敗時,Slurm 會重新調(diào)度該作業(yè),在這個過程中可能搶占數(shù)百個作業(yè)。最糟糕的情況是循環(huán)崩潰,也就是配置為作業(yè)失敗時重新排隊。作者發(fā)現(xiàn)一個 1024 GPU 作業(yè)發(fā)生 Node_Fail 后重新排隊 35 次,總共導(dǎo)致 548 次搶占,共涉及 7000 個 GPU。此類情況應(yīng)盡可能的避免,不然會造成集群 Goodput 的損失。

在考慮作業(yè)失敗時,搶占是一個次級效應(yīng)。作者集群中,為了確保即使是最低優(yōu)先級的作業(yè)也能取得進(jìn)展,搶占只能在運行兩個小時后發(fā)生。然而,如果沒有精確的 Checkpointing 機(jī)制,作業(yè)被搶占時相應(yīng)的工作進(jìn)度也會丟失。關(guān)鍵在于,大型作業(yè) 1) 預(yù)計會損失大量工作,2) 失敗頻率更高,導(dǎo)致作業(yè)規(guī)模與 Goodput 吞吐之間呈二次函數(shù)關(guān)系。為了估計各種 Goodput 損失來源對整個集群 Goodput 的影響(包括重新調(diào)度失敗作業(yè)發(fā)生的搶占),作者假設(shè)所有作業(yè)每個小時進(jìn)行一次 Checkpointing,平均損失半個小時的工作量。通過 Slurm 日志可以確定相應(yīng)作業(yè) 1)收到 Node_Fail(集群相關(guān)問題)或歸因于硬件問題的 Failed 狀態(tài)的作業(yè),2)因引發(fā) Node_Fail 或 Failed 而被搶占的作業(yè),并估計損失的 Goodput(作業(yè)運行時間與 30 分鐘的最小值,乘以分配給該作業(yè)的 GPU 數(shù)量)。

如下圖 Fig 8 所示,RSC-1 因故障和二次搶占導(dǎo)致的大部分 Goodput 損失(y 軸),主要源自規(guī)模在 2K-4K 個 GPU (x軸)的大型作業(yè)。在 RSC-2 集群,由于作業(yè)構(gòu)成的差異,中等規(guī)模作業(yè)占據(jù) Goodput 損失的比例更高。此外,RSC-2 上 Goodput 損失比 RSC-1 上小一個數(shù)量級,這是作業(yè)構(gòu)成和故障率差異的結(jié)果。盡管優(yōu)化大型作業(yè)至關(guān)重要,但硬件故障導(dǎo)致的 Goodput 損失中,依然有 16% 源于二次搶占。

a4d16ef0-b790-11ef-93f3-92fbcf53809c.png

見解 9:大型、高優(yōu)先級作業(yè)在故障時會使 Scheduler 產(chǎn)生波動。雖然 1K+ GPU 作業(yè)故障的一級效應(yīng)顯著,但總故障開銷的 16% 來自于搶占其他作業(yè)。因此,作業(yè)多樣性的增加為優(yōu)化提供了額外的途徑。

量化大規(guī)模訓(xùn)練的 ETTR:ETTR 提供了一個可解釋性的指標(biāo),用于量化中斷、排隊時間和開銷對訓(xùn)練進(jìn)度影響的程度。理解 ETTR 如何隨著配置、調(diào)度及故障等不同因素的變化而變化,有助于評估各種措施的影響規(guī)模。

這個部分,作者提供了:

基于作業(yè)訓(xùn)練參數(shù)、作業(yè)優(yōu)先級和集群資源可用性作為輸入的 ETTR 期望值公式。這里,公式通過假設(shè) Checkpointing 頻率和重啟開銷,使得能夠模擬作業(yè)的可靠性特征。需要注意的是,期望 ETTR(E[ETTR]) 對于較長的訓(xùn)練最為有效——根據(jù)大數(shù)定律,較長的訓(xùn)練趨向于使觀測到的 ETTR 值更接近這一期望值。利用對期望 ETTR 的解析公式,可以幫助快速估算并理解優(yōu)化措施的影響,例如將故障率減半的影響是什么?

利用作業(yè)級數(shù)據(jù)對 RSC-1 和 RSC-2 集群進(jìn)行 ETTR 估計的設(shè)計空間探索研究。繼續(xù)使用先前的參數(shù)作為工具,探索不同因素對作業(yè)開銷的相對重要性——探討在之后大規(guī)模 GPU 訓(xùn)練中,實現(xiàn)合理 ETTR(>=0.90)所需的必要條件。

解析近似 E[ETTR]:首先,定義 Q 為符合調(diào)度條件但處于排隊等待的作業(yè)的時間,R 為有效運行時間,U 為無效運行時間??倳r間為 W=Q+R+U。Checkpointing 之間的間隔為 Δtcp,初始化任務(wù)所需時間(如加載 Checkpoint)為 u0,提交后及每次中斷后的期望排隊時間為 q(假設(shè)排隊時間服從獨立正態(tài)分布 i.i.d,且在遭遇中斷后并未系統(tǒng)性地縮短)。作業(yè)需要的節(jié)點數(shù)為 Nnodes,集群故障率 rf 表示每節(jié)點、每天內(nèi)預(yù)期發(fā)生的故障次數(shù)。如下圖所示可以得出期望 ETTR 的解析公式:

a4eb0ebe-b790-11ef-93f3-92fbcf53809c.png

對于 RSC 集群,每個 GPU 節(jié)點(8 GPU)每天的故障率 rf 約為 5x10-3,tcp 約為 1 小時,也就是 0.04 天,u0 約為 5-20 分鐘,而 (Nnodesrf)-1 >= 0.1 天。與預(yù)測各種期望值的蒙特卡洛方法相比,即便對于大型、長時間運行的假設(shè)性任務(wù)(例如 8000 GPU),上述近似值的誤差也在 5% 以內(nèi)。

與實際作業(yè)對比:作者將上述期望值公式與兩個集群上實際作業(yè)的觀察結(jié)果進(jìn)行了比較。一個作業(yè)運行多個任務(wù)(可能具備不同的任務(wù) ID),它們都屬于同一訓(xùn)練作業(yè)。假設(shè) Δtcp 為 60 分鐘,u0 為 5 分鐘。這里重點關(guān)注總訓(xùn)練時間為 24 小時的長時間作業(yè),并針對以最高優(yōu)先級運行的作業(yè),以理解最高優(yōu)先級作業(yè)的 ETTR。需要說明的是,這里計算作業(yè) ETTR 時,不考慮健康檢查,并且假設(shè)每個作業(yè)都因基礎(chǔ)設(shè)施故障而中斷,意味著對 ETTR 的數(shù)據(jù)估計應(yīng)為低估。

為了獲取計算 E[ETTR] 所需的機(jī)器級故障率 rf,作者將所有使用超過 128 個 GPU 且被標(biāo)記為 Node_Fail 狀態(tài)的作業(yè)以及那些因關(guān)鍵健康檢查在作業(yè)最后 10 分鐘(或完成后 5 分鐘內(nèi))觸發(fā)而狀態(tài)變?yōu)?Failed 的作業(yè),均計為故障。然后,將故障次數(shù)除以節(jié)點運行天數(shù)(節(jié)點運行天數(shù)乘以節(jié)點數(shù)的總和)。作者發(fā)現(xiàn),RSC-1 的 rf 為每千節(jié)點日 6.5 次故障,而 RSC-2 的 rf 顯著低于 RSC-1,為每千節(jié)點日 2.34 次故障。這一發(fā)現(xiàn)通過觀察集群中 GPU 的交換率也可以得到印證,RSC-1 的 GPU 交換率為 RSC-2 的 3 倍。GPU 交換率和故障率的差異可能源于 RSC-1 上更為繁重的工作負(fù)載。

ETTR 結(jié)果分析:如下圖 Fig 9 展示了作者的研究結(jié)果。除較小任務(wù)(< 64 GPU)外,E[ETTR] 與實際測量的任務(wù)運行平均 ETTR 相吻合,在 RSC-1 上,超大任務(wù)(> 1024 GPU)的 ETTR 高于 E[ETTR] 預(yù)測值(>0.9),原因在于這些大型任務(wù)運行的實際等待時間小于平均值。

在假設(shè)情景中,若 RSC-1 集群用于單一 16,000 GPU 訓(xùn)練任務(wù),占據(jù)整個集群,60 分鐘 Checkpointing 間隔下的期望 ETTR 為 0.7,縮短為 5 分鐘 Checkpointing 間隔,期望 ETTR 增至 0.93,凸顯了頻繁 Checkpointing 對抵御中斷的價值(PS:假設(shè) Checkpointing 寫入為非阻塞,可以通過異步、分布式存儲實現(xiàn),當(dāng)前很多框架已經(jīng)提供該能力)。

a4fddb2a-b790-11ef-93f3-92fbcf53809c.png

展望未來:對于未來需要 O(105) GPU 的其他集群,基于類 RSC-1 故障率(每千節(jié)點日 6.50 次故障)推導(dǎo)的 MTTF 為 15 分鐘。這意味著 1 小時的 Checkpointing 間隔不可行。如圖 Fig 10 展示了故障率與 Checkpointing 間隔的權(quán)衡,例如,對于類 RSC-1 故障率,需要 7 分鐘的 Checkpointing 間隔才能實現(xiàn) E[ETTR]=0.5,若故障率接近 RSC-2,則需 21 分鐘。在類 RSC-2 故障率下要達(dá)到 E[ETTR] 0.9,需 2 分鐘的 Checkpointing 間隔和 2 分鐘的重啟開銷。

a50ed588-b790-11ef-93f3-92fbcf53809c.png

見解 10:RSC 集群對最大及最高優(yōu)先級作業(yè)極為高效(ETTR > 0.9)。盡管 RSC-1 集群資源緊張且共享,在其上運行 2048-4096 GPU 且超過 1 天的作業(yè),假設(shè) 1 小時的 Checkpointing 間隔,可以實現(xiàn) ETTR 超過 0.9。若每次故障后的排隊時間為 1 分鐘, Checkpointing 間隔為 30 分鐘,在 RSC-1 上可以實現(xiàn)最大可行訓(xùn)練(8,000 GPU,占 RSC-1 一半資源)ETTR 達(dá)到 0.9。在假設(shè)具有類 RSC-2 類故障率的集群上進(jìn)行 100,000 GPU 訓(xùn)練時間,要達(dá)到 ETTR 0.9,Checkpointing 間隔和 Restart 開銷需要為 2 分鐘。(PS:如上所示,Meta 在 LLaMA 3 技術(shù)報告中也提到,其 LLaMA 3 在 16K H100 GPU 集群實現(xiàn)了 90% 的有效訓(xùn)練時間)

五、提升集群穩(wěn)定性和效率

這個章節(jié)作者介紹了為提升集群可靠性所實施的緩解措施。健康檢查只是其中之一,尤其擅長發(fā)現(xiàn)隨機(jī)節(jié)點故障。然而,故障可能與特定節(jié)點(作者稱為 lemon node)相關(guān)聯(lián),這可能是由于配置錯誤,老化或硬件缺陷所致。因此,健康檢查工具也可以用以識別反復(fù)出現(xiàn)問題的節(jié)點。此外,作者也將其拓展到節(jié)點外,包括針對網(wǎng)絡(luò)路由不可靠時的網(wǎng)絡(luò)層緩解措施。最后,作者也概述了集群設(shè)計和工作負(fù)載本身如何影響集群級指標(biāo)。

5.1 識別和修復(fù)故障節(jié)點

盡管健康檢查機(jī)制在初始階段可以幫助避免同一故障導(dǎo)致多個作業(yè)失敗的情況,實踐中作者也發(fā)現(xiàn)某些節(jié)點的作業(yè)失敗率顯著高于平均水平。因此,可以懷疑硬件可能正在退化或節(jié)點運行了錯誤配置的軟件。遺憾的是,快速識別此類節(jié)點非常困難,需要長時間觀察其故障行為以獲得統(tǒng)計顯著性。更糟糕的是,這些節(jié)點失敗恢復(fù)后仍會導(dǎo)致新作業(yè)的不斷失敗,最終導(dǎo)致作業(yè)失敗并延長整體恢復(fù)時間。

在存在故障節(jié)點的情況下,無論是由于訓(xùn)練集群中不同硬件組件的瞬時或永久性故障,研究人員通常會根據(jù)過往經(jīng)驗手動排除導(dǎo)致任務(wù)失敗的節(jié)點。然而,這種做法難以擴(kuò)展,且過度排除節(jié)點可能導(dǎo)致容量枯竭。

為提升 ETTR,作者設(shè)計了 lemon node 檢測機(jī)制,以主動識別、隔離并替換 lemon node。lemon node 是指那些反復(fù)導(dǎo)致作業(yè)失敗但無法通過現(xiàn)有健康檢查和修復(fù)流程識別的節(jié)點。如前所示,導(dǎo)致訓(xùn)練作業(yè)失敗的最重要因素之一是節(jié)點故障(Node_Fail),這凸顯了主動處理 lemon node 的重要性。

lemon 檢測信號:在每個節(jié)點上可用的數(shù)十種檢測信號中,以下幾種與 lemon node 最相關(guān),盡管報告的結(jié)果是基于預(yù)測 lemon node 準(zhǔn)確率和誤報率人工調(diào)整的,依然可以將這些信號視為二分類模型的潛在特征。

excl_jobid_count:驅(qū)逐節(jié)點上的作業(yè)數(shù)量。

xid_cnt:節(jié)點上單一 Xid 錯誤數(shù)量。

tickets:為某節(jié)點創(chuàng)建的修復(fù)工單數(shù)量。

out_count:節(jié)點從 Scheduler 中移除的次數(shù)。

multi_node_node_fails:由單節(jié)點引起的多節(jié)點作業(yè)失敗次數(shù)。

single_node_node_fails:由節(jié)點引起的單節(jié)點作業(yè)失敗數(shù)量。

single_node_node_failure_rate:節(jié)點上單節(jié)點作業(yè)失敗的比例。

如下圖 11 所示,展示了基于 RSC-1 的 28 天數(shù)據(jù)快照信號分布情況,可以據(jù)此設(shè)定檢測標(biāo)準(zhǔn)的閾值。x 軸表示每個 GPU 節(jié)點信號出現(xiàn)的歸一化次數(shù)。y 軸表示經(jīng)歷每種信號的 GPU 節(jié)點的累積數(shù)量,同樣進(jìn)行歸一化處理。作者發(fā)現(xiàn),excl_jobid_count 信號與節(jié)點故障之間并無顯著相關(guān)性,大量節(jié)點因至少一個作業(yè)而被排除。這促使作者主動檢測 lemon node,而非將其留給用戶。超過 85% 的已識別 lemon node 在某一測試中失敗,失敗類型詳見 Table II。

a51da2de-b790-11ef-93f3-92fbcf53809c.png

a52d515c-b790-11ef-93f3-92fbcf53809c.png

作者設(shè)計、實施并評估了 lemon 檢測機(jī)制,成功識別出 RSC-1(24 個節(jié)點)和 RSC-2(16 個節(jié)點)中的 40 個故障節(jié)點,準(zhǔn)確率超過 85%。這些被識別的 lemon node 占 RSC-1 總規(guī)模的 1.2%,每日作業(yè)的 13%。這種 lemon 檢測機(jī)制使得大規(guī)模作業(yè)(512+ GPU)的失敗率降低 10%,從 14% 降低至 4%。

見解 11:歷史數(shù)據(jù)對于識別缺陷節(jié)點至關(guān)重要。實施 lemon node 檢測技術(shù)可將大型任務(wù)完成率提升超過 30%。

5.2 通過自適應(yīng)路由增強(qiáng)網(wǎng)絡(luò)結(jié)構(gòu)韌性

故障特征分析揭示了 IB 鏈路錯誤引發(fā)的故障的重要性。正如節(jié)點可能在不同階段由于瞬時或永久性組件退化而異常,網(wǎng)絡(luò)鏈路也可能因物理或電氣特征的變化而表現(xiàn)出類似行為。大規(guī)模并行模型訓(xùn)練不可避免會遭遇故障鏈路,這些鏈路可能具有高錯誤率、在上下行狀態(tài)間頻繁切換的抖動行為、永久性斷開或在高密度租戶環(huán)境中出現(xiàn)嚴(yán)重?fù)砣K羞@些情況都會導(dǎo)致跨節(jié)點的通信性能下降。

大規(guī)模物理鏈路更換操作繁瑣,因此 IB 網(wǎng)絡(luò)結(jié)構(gòu)配備了交換機(jī)級別的鏈路問題容錯技術(shù),其中一種自我修復(fù)技術(shù)稱為 SHIELD,允許交換機(jī)在鏈路故障時進(jìn)行協(xié)調(diào)。然而,即使啟動了此功能,將鏈路視為斷開的閾值可能過于保守,導(dǎo)致協(xié)議層面的重傳及潛在的網(wǎng)絡(luò)性能下降。特別是在 RSC-1 的啟動階段,作者觀察到了 50%-75% 的帶寬損失。

另一種更為先進(jìn)的功能是自適應(yīng)路由(AR),它根據(jù)實時網(wǎng)絡(luò)狀況動態(tài)調(diào)整路由決策。AR 平衡了所有網(wǎng)絡(luò)鏈路上的流量,提高了整體鏈路利用率。通過允許數(shù)據(jù)包避開擁塞區(qū)域和不健康鏈路,自適應(yīng)路由提升了網(wǎng)絡(luò)資源利用率和效率,從而減少因網(wǎng)絡(luò)問題導(dǎo)致的訓(xùn)練作業(yè)性能波動。作者在集群中啟用了 AR 以提升性能的可預(yù)測性。

為了展示 AR 在作者集群中的重要性,作者進(jìn)行了兩項實驗。

第一個實驗中,使用 mlxreg 工具修改網(wǎng)絡(luò)中的端口寄存器,引入位錯誤(BER)。隨后,針對 512 GPU,在啟用與未啟用 AR 的情況下,運行 nccl-tests 中的 AllReduce 基準(zhǔn)測試。如下圖 Fig 12a 所示,在鏈路錯誤條件下,AR 能夠維持更高的帶寬。

第二個實驗中,在 64 個節(jié)點上分組進(jìn)行 AllReduce 的多輪迭代,每組包含兩個節(jié)點(16 個 GPU),以展示 AR 在資源競爭環(huán)境下的表現(xiàn)。如下圖 Fig 12b 所示,網(wǎng)絡(luò)中充斥著多個 NCCL 環(huán)路時,使用 AR 的性能波動較小,且 AR 能實現(xiàn)更高的性能。這是因為 AR 能夠保護(hù) GPU 免受擁塞鏈路的瓶頸效應(yīng)。通過使用交換機(jī)根據(jù)端口負(fù)載選擇的輸出端口,AR 將不良鏈路的影響分散到各個任務(wù)中,而非僅懲罰恰好映射到這些不良鏈路的訓(xùn)練任務(wù)。

a534acc2-b790-11ef-93f3-92fbcf53809c.png

見解 12:網(wǎng)絡(luò)必須具備故障排除和繞行能力,若缺乏彈性機(jī)制,可能會損失超過 50% 的帶寬。

六、關(guān)鍵教訓(xùn)和研究機(jī)會

在介紹了集群運維和優(yōu)化方面的經(jīng)驗后,作者認(rèn)為有多個機(jī)會可以提升可靠性、管理日益增長的 Infra 復(fù)雜性,并與框架和算法共同設(shè)計解決方案。

訓(xùn)練可靠性:作者展示了如何通過運行監(jiān)控檢測和歷史分析來發(fā)現(xiàn)瞬態(tài)故障,這些故障阻礙了可靠性的保障;作者也介紹了 lemon node 檢測,通過移除 lemon node 可以將大型作業(yè)完成率提高 30%。展望未來,也看到了進(jìn)一步給 Scheduler 和分布式算法暴露可靠性信息的重要機(jī)會,以便工作分配可以最大化可靠性和 Goodput。此外,作者也注意到網(wǎng)絡(luò)結(jié)構(gòu)本身在彈性方面的潛在改進(jìn)機(jī)會,例如,能夠重新調(diào)整拓?fù)湟岳@過故障,這也與上述的 AR 部分相對應(yīng)。因此,作者設(shè)想未來的 Infra 系統(tǒng)應(yīng)試圖使不可靠不那么明顯,而不是試圖完全消除。此外,當(dāng)未來的 GPU 系統(tǒng),比如 NVIDIA GB200,將修復(fù)單元從單個節(jié)點轉(zhuǎn)為整個機(jī)架時,可能需要重新思考整個系統(tǒng)。

更接近應(yīng)用層面:訓(xùn)練作業(yè)的預(yù)期訓(xùn)練恢復(fù)時間是與故障相關(guān)的延遲開銷的函數(shù)。提高 ETTR 的有效方式之一是盡量減少重啟延遲成本,同時降低重啟的概率。如之前工作(字節(jié) [2402.15627] MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs [8])介紹,像 NCCL 初始化等操作可能會隨著 GPU 節(jié)點數(shù)量的增加而表現(xiàn)不佳。因此,未來的軟件系統(tǒng)支持快速且可靠的程式(優(yōu)化重啟的延遲開銷)顯得尤為重要。作者認(rèn)為,完全替代類似 MPI 的集合通信機(jī)制以及提升硬件預(yù)檢測效率等措施將成為未來的關(guān)鍵發(fā)展方向。

調(diào)試工具:在通過健康檢查排除大量且顯著故障后,剩余的故障通常表現(xiàn)為近端故障,這些故障并不立即提示根本原因。NCCL 超時是此類故障中最常見的癥狀之一,其根本原因可能涉及網(wǎng)絡(luò)基礎(chǔ)設(shè)施、有缺陷的模型代碼或其他組件。

定期檢查硬件基礎(chǔ)設(shè)施的健康狀況可以幫助主動發(fā)現(xiàn)網(wǎng)絡(luò)或硬件問題,減少 NCCL 超時的頻率,這樣這些問題可以在表現(xiàn)為 NCCL 內(nèi)核卡住之前就被發(fā)現(xiàn)。然而,識別剩余超時的根本原因則需要引入新的健康檢查或進(jìn)行錯誤修復(fù)。通過回溯性識別 NCCL 超時的根本原因,可以提高訓(xùn)練的成功率,比如,通過比較參與集合通信的不同 Rank 記錄的數(shù)據(jù)來實現(xiàn)。例如,記錄每個集合通信的啟動 Rank 及其之間的關(guān)系,可以找到某些 Rank 啟動而其他 Rank 未啟動的第一個集合通信操作,并進(jìn)一步調(diào)查缺失的 Rank。如果所有集合通信 Rank 都進(jìn)行通信但未退出,可以進(jìn)一步檢查集合通信內(nèi)的網(wǎng)絡(luò)流量,以識別哪個組件未發(fā)送或接收預(yù)期的 Message。從未來的作業(yè)中刪除所有有問題的 Rank 或網(wǎng)絡(luò)組件,將降低這些作業(yè)遇到相同問題的可能性。為了實現(xiàn)高效且可靠的大規(guī)模分布式訓(xùn)練,需要更完善的診斷和調(diào)試工具??梢詳U(kuò)展現(xiàn)有的管理工具,如 IPMI,以通過帶外網(wǎng)絡(luò)提供機(jī)器調(diào)試信息,并縮小歸因差距。

編程模型:診斷 NCCL 超時的一個復(fù)雜因素是 Pytorch 中實現(xiàn)的 SPMD 編程模型,如果不同 Rank 意外的以錯誤順序發(fā)出集合通信指令,如 AllReduce,任務(wù)將陷入死鎖,導(dǎo)致 NCCL 超時。因此,調(diào)試 NCCL 超時的第一步是確定訓(xùn)練腳本是否存在缺陷,這為追蹤 Infra 的不穩(wěn)定性增加了復(fù)雜性。動態(tài)檢測錯誤程序并引發(fā)異常而非死鎖,有助于提升系統(tǒng)穩(wěn)定性?;蛘撸梢酝耆贤ㄐ挪僮鞑黄ヅ涞目赡苄裕纾琍athways 引入了單一的通信調(diào)度入口,確保每臺機(jī)器的通信調(diào)度一致。

七、參考鏈接

https://arxiv.org/abs/2410.21680

https://slurm.schedmd.com/overview.html

https://docs.nvidia.com/deploy/xid-errors/index.html

https://ai.meta.com/research/publications/the-llama-3-herd-of-models/

https://pytorch.org/assets/pytorch2-2.pdf

https://www.alibabacloud.com/help/zh/ack/ack-managed-and-ack-dedicated/user-guide/gpu-faq#55a6b327214cg

https://arxiv.org/abs/2403.07648

https://arxiv.org/abs/2402.15627

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • gpu
    gpu
    +關(guān)注

    關(guān)注

    28

    文章

    4769

    瀏覽量

    129347
  • AI
    AI
    +關(guān)注

    關(guān)注

    87

    文章

    31498

    瀏覽量

    270296
  • Meta
    +關(guān)注

    關(guān)注

    0

    文章

    279

    瀏覽量

    11434

原文標(biāo)題:Meta 萬卡 GPU 集群穩(wěn)定性剖析與最佳實踐

文章出處:【微信號:SDNLAB,微信公眾號:SDNLAB】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    國產(chǎn)千GPU集群完成大模型訓(xùn)練測試,極具高兼容性和穩(wěn)定性

    集群的方式成為了必然的選擇。 ? 2023年底,摩爾線程推出首個全國產(chǎn)千千億模型訓(xùn)練平臺“摩爾線程KUAE智算中心”。摩爾線程相關(guān)負(fù)責(zé)人此前談到,百或更小規(guī)模都是實驗性的,千
    的頭像 發(fā)表于 06-11 07:50 ?3445次閱讀
    國產(chǎn)千<b class='flag-5'>卡</b><b class='flag-5'>GPU</b><b class='flag-5'>集群</b>完成大模型訓(xùn)練測試,極具高兼容性和<b class='flag-5'>穩(wěn)定性</b>

    小米加速布局AI大模型,搭建GPU集群

    近日,有消息稱小米正在緊鑼密鼓地搭建自己的GPU集群,旨在加大對AI大模型的投入力度。據(jù)悉,小米的大模型團(tuán)隊在成立之初就已經(jīng)擁有了6500張GP
    的頭像 發(fā)表于 12-28 14:25 ?255次閱讀

    庫存平臺穩(wěn)定性建設(shè)實踐

    作者:京東物流 尹昊喆 前言 本文總結(jié)庫存平臺穩(wěn)定性建設(shè)中遇到的問題以及解決方案。感謝【金鵬】、【孫靜】、【陳瑞】同學(xué)在本文撰寫中提供的內(nèi)容及幫助! 庫存平臺面臨的穩(wěn)定性挑戰(zhàn) 庫存平臺為貨品流通鏈路
    的頭像 發(fā)表于 12-11 09:50 ?245次閱讀
    庫存平臺<b class='flag-5'>穩(wěn)定性</b>建設(shè)<b class='flag-5'>實踐</b>

    是德34460A用表的測量穩(wěn)定性提升

    是德科技(Keysight Technologies)的34460A數(shù)字用表以其高精度、多功能性和可靠性而聞名于儀器測試領(lǐng)域。然而,即使是高端儀器,其測量穩(wěn)定性也可能受到多種因素的影響,從而導(dǎo)致
    的頭像 發(fā)表于 12-05 10:06 ?209次閱讀
    是德34460A<b class='flag-5'>萬</b>用表的測量<b class='flag-5'>穩(wěn)定性</b>提升

    質(zhì)量視角下的系統(tǒng)穩(wěn)定性保障--穩(wěn)定性保障常態(tài)化自動化實踐

    常態(tài)化穩(wěn)定性治理。在常態(tài)化治理過程中我們將識別問題等重復(fù)性有規(guī)律的工作實現(xiàn)自動化,技術(shù)人員更專注于解決問題。 二、穩(wěn)定性治理常態(tài)化 保障穩(wěn)定性治理常態(tài)化,部門組建了一支由研發(fā)團(tuán)隊、測試團(tuán)隊、架構(gòu)師組成的
    的頭像 發(fā)表于 11-19 11:19 ?550次閱讀
    質(zhì)量視角下的系統(tǒng)<b class='flag-5'>穩(wěn)定性</b>保障--<b class='flag-5'>穩(wěn)定性</b>保障常態(tài)化自動化<b class='flag-5'>實踐</b>

    反射內(nèi)存是如何保障數(shù)據(jù)傳輸?shù)?b class='flag-5'>穩(wěn)定性

    反射內(nèi)存數(shù)據(jù)傳輸穩(wěn)定性的保障
    的頭像 發(fā)表于 11-14 10:21 ?232次閱讀
    反射內(nèi)存<b class='flag-5'>卡</b>是如何保障數(shù)據(jù)傳輸?shù)?b class='flag-5'>穩(wěn)定性</b>的

    簡化穩(wěn)定性檢查

    電子發(fā)燒友網(wǎng)站提供《簡化穩(wěn)定性檢查.pdf》資料免費下載
    發(fā)表于 10-11 11:23 ?0次下載
    簡化<b class='flag-5'>穩(wěn)定性</b>檢查

    鳳凰動力舵輪驅(qū)動輪的穩(wěn)定性如何影響AGV的運行效率和穩(wěn)定性

    舵輪的穩(wěn)定性對AGV(自動導(dǎo)引車)的運行效率和整體穩(wěn)定性具有顯著的影響。以下是關(guān)于舵輪穩(wěn)定性與AGV運行效率和穩(wěn)定性之間關(guān)系的詳細(xì)分析: 首先,舵輪的
    的頭像 發(fā)表于 08-27 13:20 ?386次閱讀
    鳳凰動力舵輪驅(qū)動輪的<b class='flag-5'>穩(wěn)定性</b>如何影響AGV的運行效率和<b class='flag-5'>穩(wěn)定性</b>

    VCO的頻率穩(wěn)定性是什么

    VCO(Voltage-Controlled Oscillator,壓控振蕩器)的頻率穩(wěn)定性是一個關(guān)鍵的性能指標(biāo),它描述了VCO輸出頻率對輸入電壓變化的敏感程度及在長時間或不同環(huán)境條件下保持頻率穩(wěn)定
    的頭像 發(fā)表于 08-20 16:08 ?1191次閱讀

    環(huán)路增益的穩(wěn)定性

    由基本反饋電路的電路組成結(jié)構(gòu),得出閉環(huán)傳遞函數(shù)為,電路的開環(huán)增益是各個晶體管參數(shù)和電容參數(shù)的函數(shù),所以也是頻率的函數(shù),于是閉環(huán)增益就可以寫作,反饋電路的穩(wěn)定性和1環(huán)路增益A(w)有關(guān),當(dāng)環(huán)路增益的幅
    發(fā)表于 06-18 15:00

    集群解決大模型訓(xùn)算力需求,建設(shè)面臨哪些挑戰(zhàn)

    ? 電子發(fā)燒友網(wǎng)報道(文/李彎彎)集群是指由一萬張及以上的加速(包括GPU、TPU及其他專用AI加速芯片)組成的高性能計算系統(tǒng),主要用
    的頭像 發(fā)表于 06-02 06:18 ?4882次閱讀
    <b class='flag-5'>萬</b><b class='flag-5'>卡</b><b class='flag-5'>集群</b>解決大模型訓(xùn)算力需求,建設(shè)面臨哪些挑戰(zhàn)

    影響放大器穩(wěn)定性的因素

    在電子電路設(shè)計中,放大器作為信號放大的關(guān)鍵元件,其穩(wěn)定性對于整個電路的性能至關(guān)重要。穩(wěn)定性良好的放大器能夠確保信號的準(zhǔn)確傳輸和放大,避免產(chǎn)生自激振蕩、頻率失真等不良影響。因此,深入了解放大器穩(wěn)定性
    的頭像 發(fā)表于 05-28 14:43 ?1993次閱讀

    摩爾線程、無問芯穹合作完成國產(chǎn)全功能GPU集群

    據(jù)介紹,此項訓(xùn)練歷時13.2天,過程穩(wěn)定而有序,集群整體運行穩(wěn)定性達(dá)到了100%。相較于單機(jī)訓(xùn)練,千集群的擴(kuò)展效率提升了超過90%。
    的頭像 發(fā)表于 05-27 14:40 ?669次閱讀

    運放穩(wěn)定性的判斷原理的補(bǔ)償原理?

    有反饋的運放是從輸出端到輸入端的反饋支路,但是在電路上輸入和輸出也是通過反饋支路直接電氣連接的,為什么不考慮輸入經(jīng)反饋支路到輸出端的電路作用? 由反饋之路的數(shù)學(xué)關(guān)系可得知反饋運放的穩(wěn)定性數(shù)學(xué)關(guān)系,1
    發(fā)表于 05-06 22:09

    什么是熱電偶穩(wěn)定性?影響熱電偶穩(wěn)定性的主要因素

    什么是熱電偶穩(wěn)定性?影響熱電偶穩(wěn)定性的主要因素 熱電偶熱穩(wěn)定性怎樣檢測? 熱電偶穩(wěn)定性是指熱電偶在一定時間范圍內(nèi)的溫度測量值的穩(wěn)定程度。在實
    的頭像 發(fā)表于 03-08 15:32 ?1801次閱讀
    大发888老虎机下载| 百家乐最新心得| 百家乐推荐| 网上百家乐官网网| tt娱乐城网址| 百家乐软件稳赚| 百家乐官网开过的路纸| 新葡京百家乐现金网| 百家乐官网去哪里玩最好| 百家乐系列抢庄龙| 桐庐县| 网上百家乐游戏下载| 百家乐官网稳赢投注方法| 百家乐双倍派彩的娱乐城| 百家乐官网投注网站是多少| 百家乐视频麻将游戏| 模拟百家乐官网游戏软件| 大发888娱乐英皇国际| 百家乐官网视频画面| 足球投注网址| 网上百家乐软件大全酷| 博彩百家乐官网后一预测软件| 百家乐园蒙特卡罗| 百家乐官网娱乐平台真人娱乐平台 | 网上百家乐官网真实度| 闲和庄百家乐的玩法技巧和规则 | 全讯网433234| 柬埔寨百家乐官网的玩法技巧和规则 | 百家乐官网真人游戏网| 大发888备用地址| 八运24山下卦局| 百家乐官网胜率被控制| 大发888电话客服| 有破解百家乐仪器| 巴特百家乐官网的玩法技巧和规则 | 环球百家乐官网的玩法技巧和规则| 去澳门赌博| 网上百家乐是真是假天涯论坛| 大发888pt| 百家乐有多少网址| 百家乐官网赌博玩法技巧|