1.AI 訓(xùn)練穩(wěn)定性的演進(jìn)歷程
2012 年 ImageNet 競(jìng)賽中 AlexNet 的橫空出世,開啟了現(xiàn)代 AI 發(fā)展的新紀(jì)元。彼時(shí)我們不會(huì)想到,十年后支撐 AI 訓(xùn)練的 GPU 集群會(huì)從研究室里的幾臺(tái)服務(wù)器,發(fā)展成需要專門供電系統(tǒng)的萬卡級(jí)計(jì)算矩陣。在這個(gè)算力爆發(fā)式增長(zhǎng)的過程中,訓(xùn)練系統(tǒng)的穩(wěn)定性管理正經(jīng)歷著從「簡(jiǎn)單運(yùn)維」到「精密工程」的深刻變革。
1.1早期的小模型時(shí)代:手動(dòng)運(yùn)維的黃金年代
2022 年之前的 AI 訓(xùn)練,更像是手工作坊式的精雕細(xì)琢。大多數(shù)訓(xùn)練任務(wù)只需十幾塊 GPU,利用 PyTorch 或 TensorFlow 的數(shù)據(jù)并行功能就能輕松應(yīng)對(duì)。記得那時(shí)算法工程師們有個(gè)共識(shí):如果訓(xùn)練遇到問題,重啟往往比排查更高效。
當(dāng)時(shí)我們構(gòu)建的監(jiān)控系統(tǒng)就像汽車儀表盤,只能顯示最基本的任務(wù)狀態(tài)。當(dāng)訓(xùn)練意外中斷時(shí),工程師們會(huì)像偵探一樣翻查日志 —— 如果發(fā)現(xiàn)是 GPU 報(bào)錯(cuò),就聯(lián)系運(yùn)維同事。運(yùn)維人員則帶著「NVIDIA三件套」(nvidia-smi、dcgm、nsys)到機(jī)房巡檢,像老中醫(yī)把脈般通過溫度、功耗等指標(biāo)判斷硬件狀態(tài)。這種工作模式雖簡(jiǎn)單,但應(yīng)對(duì)數(shù)十卡規(guī)模的集群還算游刃有余。
1.2大模型風(fēng)暴:從量變到質(zhì)變的沖擊
ChatGPT 的登場(chǎng)如同打開潘多拉魔盒,將 AI 訓(xùn)練帶入新的紀(jì)元。當(dāng)我們開始部署千卡/萬卡集群時(shí),才發(fā)現(xiàn)原有的運(yùn)維體系就像用小漁網(wǎng)捕鯨魚 —— 完全無法匹配新需求。
讓我們通過百度百舸經(jīng)歷過的一個(gè)真實(shí)案例來深入理解這個(gè)問題:
2024 年初,百度百舸幫助一家 AIGC 創(chuàng)業(yè)公司迅速將其訓(xùn)練規(guī)模從百卡擴(kuò)展到千卡級(jí)別。然而在訓(xùn)練數(shù)天后的某個(gè)周末凌晨,訓(xùn)練進(jìn)程意外發(fā)生了 hang 死。由于當(dāng)時(shí)缺乏有效的故障感知和容錯(cuò)機(jī)制,直到第二天算法工程師發(fā)現(xiàn)任務(wù)超時(shí)退出時(shí),已經(jīng)耽誤了數(shù)小時(shí)寶貴的訓(xùn)練時(shí)間。更糟糕的是,任務(wù)日志中除了簡(jiǎn)單的 timeout 報(bào)錯(cuò)外毫無線索,平臺(tái)監(jiān)控也顯示所有訓(xùn)練節(jié)點(diǎn)狀態(tài)正常。著急恢復(fù)訓(xùn)練的算法工程師沒有立即上報(bào)問題,而是選擇直接重新提交任務(wù)。但不幸的是,新任務(wù)運(yùn)行數(shù)小時(shí)后再次出現(xiàn)相同的超時(shí)退出。這時(shí)他們才不得不尋求技術(shù)支持,但值班工程師面對(duì)這種任務(wù) hang 死的問題也缺乏診斷經(jīng)驗(yàn),只能通過二分法慢慢定位。最終發(fā)現(xiàn)是某個(gè)節(jié)點(diǎn)的靜默故障(SDC)導(dǎo)致了訓(xùn)練進(jìn)程假死。等問題得到解決時(shí),距離首次故障已經(jīng)過去將近 30 小時(shí),這意味著損失了價(jià)值巨大的千卡算力資源。
2.百度百舸集群訓(xùn)練穩(wěn)定性全景圖
站在現(xiàn)在的時(shí)間點(diǎn)回望,AI 訓(xùn)練穩(wěn)定性已從輔助功能演變?yōu)楹诵幕A(chǔ)設(shè)施。就像現(xiàn)代建筑中的抗震結(jié)構(gòu),它雖不直接參與空間構(gòu)成,卻是萬丈高樓得以屹立的關(guān)鍵。當(dāng)行業(yè)向著數(shù)萬卡集群邁進(jìn)時(shí),這套隱形護(hù)甲的質(zhì)量,將直接決定 AI 進(jìn)化的速度與邊界。
在 2024 年百度百舸對(duì)訓(xùn)練過程的生命周期進(jìn)行了更細(xì)致的拆分,提出了「無效訓(xùn)練時(shí)間」這一關(guān)鍵指標(biāo),并致力于將其最小化。具體來說:
任務(wù)無效訓(xùn)練時(shí)間 = 故障中斷次數(shù) × 任務(wù)故障恢復(fù)時(shí)長(zhǎng) + 任務(wù)常態(tài)寫 Ckpt 總時(shí)長(zhǎng)
其中,任務(wù)故障恢復(fù)時(shí)長(zhǎng) = 故障感知召回耗時(shí)(自動(dòng)/人工定位)+ 任務(wù)調(diào)度耗時(shí) + 任務(wù)初始化耗時(shí) + 任務(wù)重算時(shí)長(zhǎng)。
通過這個(gè)公式可以看出,要降低無效訓(xùn)練時(shí)間,需要「圍繞基礎(chǔ)設(shè)施穩(wěn)定性」、「任務(wù)容錯(cuò)」兩個(gè)維度來系統(tǒng)展開,重點(diǎn)解決三個(gè)方面的問題:
提高基礎(chǔ)設(shè)施的交付質(zhì)量。
提高任務(wù)故障容錯(cuò)的召回率、準(zhǔn)確率和時(shí)效性。
優(yōu)化 checkpoint 機(jī)制,減少保存時(shí)間和恢復(fù)時(shí)的重算時(shí)間。
經(jīng)過容錯(cuò)架構(gòu)的整體變革,百度百舸形成了從「任務(wù)負(fù)載 —框架 —通信—基礎(chǔ)架構(gòu)」全鏈路的自動(dòng)異常感知、診斷、恢復(fù)能力,可覆蓋 90%+ 的訓(xùn)練異常場(chǎng)景,時(shí)效性最快可以實(shí)現(xiàn)秒級(jí)異常感知、分鐘級(jí)定位,以及平均 3 分鐘的故障自愈能力。
3. 基礎(chǔ)設(shè)施交付質(zhì)量保障
基礎(chǔ)設(shè)施的交付質(zhì)量保障是穩(wěn)定性的基礎(chǔ)。
CPU 時(shí)代,機(jī)器的交付前可能僅會(huì)跑一些常規(guī)的 CPU 計(jì)算、網(wǎng)絡(luò)的壓力測(cè)試,并不會(huì)從業(yè)務(wù)視角去評(píng)估基礎(chǔ)架構(gòu),機(jī)器交付后硬件異常的故障頻率相對(duì)較少。有硬件故障時(shí),通常走工單系統(tǒng)人工換機(jī)用戶相對(duì)是可接受的。
而 GPU 時(shí)代,AI Infra 的交付則需要考慮 CPU、GPU、RDMA 網(wǎng)絡(luò)、存儲(chǔ),甚至機(jī)房的功率、溫度等各方面因素,遺漏任何一個(gè)環(huán)節(jié)都會(huì)成為后續(xù)穩(wěn)定性的隱患。在交付給客戶后,機(jī)器也可能會(huì)由于長(zhǎng)時(shí)間的高負(fù)載運(yùn)行頻繁出現(xiàn)硬件故障,而 GPU 機(jī)器的高昂成本,使客戶對(duì)節(jié)點(diǎn)故障感知、換機(jī)的時(shí)效性提出了非常高的要求。
因此百度百舸對(duì) GPU 機(jī)器交付前及交付后的穩(wěn)定性質(zhì)量進(jìn)行了系統(tǒng)性管理:
交付前,百度百舸會(huì)對(duì)機(jī)器進(jìn)行 200 多項(xiàng)指標(biāo)檢測(cè),然后進(jìn)行 48 小時(shí)烤機(jī),以及 NCCL-Test 的機(jī)內(nèi)、機(jī)間的大環(huán)、同號(hào)卡通信性能基準(zhǔn)測(cè)試,端到端的大模型訓(xùn)練、推理性能基準(zhǔn)測(cè)試。
交付后,需要能夠?qū)崟r(shí)的感知節(jié)點(diǎn)故障及定期巡檢,并具備分級(jí)處理的自愈能力,例如 Error 級(jí)別的故障實(shí)現(xiàn)自動(dòng)排水、重啟,Fault 級(jí)別故障實(shí)現(xiàn)自動(dòng)換機(jī)。
4. 任務(wù)容錯(cuò)的準(zhǔn)召率保障
任務(wù)層面穩(wěn)定性最核心的就是做好容錯(cuò),能夠讓業(yè)務(wù)在無論遇到何種故障時(shí)都能快速恢復(fù)。那么,首要的工作就是我們能夠準(zhǔn)確的識(shí)別出異常,然后對(duì)故障進(jìn)行診斷定位,最后能夠自動(dòng)化的從異常中恢復(fù)。因此,任務(wù)容錯(cuò)需要能夠從端側(cè)(即每個(gè)訓(xùn)練 worker)探測(cè)到進(jìn)程與環(huán)境的各類異常,同時(shí)有個(gè)中心服務(wù)(Master)從任務(wù)全局的視角去診斷、定位異常,最終做出相應(yīng)的決策來使任務(wù)能夠快速?gòu)漠惓Ｖ谢謴?fù)。
任務(wù)容錯(cuò)最重要的就是提升故障的召回率與準(zhǔn)確率,即如何能夠盡可能的準(zhǔn)確識(shí)別、定位所有故障。我們將故障分類兩類:顯式故障和隱式故障。
顯式的故障通常比較容易召回,我們將實(shí)踐積累的各種進(jìn)程異常狀態(tài)及各類報(bào)錯(cuò)pattern形成專家知識(shí)庫(kù),再結(jié)合硬件感知服務(wù)(HAS Agent)的硬件全鏈路 10 秒級(jí)監(jiān)控能力,可以實(shí)現(xiàn)顯式故障的召回率達(dá)到 95%+。
隱式的異常則往往很難輕易的識(shí)別,例如訓(xùn)練進(jìn)程 hang、慢節(jié)點(diǎn)就是典型的隱式故障,需要豐富的經(jīng)驗(yàn)積累才能準(zhǔn)確的識(shí)別出異常。
下面我們就以最典型的隱式故障場(chǎng)景 —— 訓(xùn)練進(jìn)程 hang 死為例,來看下如何能夠做好 hang 自動(dòng)感知、診斷。
4.1. 訓(xùn)練 hang 的自動(dòng)感知
訓(xùn)練任務(wù)發(fā)? hang 之后,絕?多數(shù)情況都會(huì)以 timeout 的?式報(bào)錯(cuò)并退出進(jìn)程,最常?的就是在通信過程中如果發(fā)? hang,NCCL 的 watchdog 會(huì)中斷通信,并有報(bào)如下 timeout 報(bào)錯(cuò),然后再由 pytorch 的 torchrun 進(jìn)程感知并中斷訓(xùn)練過程。
[E ProcessGroupNCCL.cpp:828] [Rank 1] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=15173, OpType=ALLREDUCE, Timeout(ms)=1800000) ran for 1802710 milliseconds before timing out.
[E ProcessGroupNCCL.cpp:828] [Rank 0] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=15173, OpType=ALLREDUCE, Timeout(ms)=1800000) ran for 1802713 milliseconds before timing out.
Pytorch 默認(rèn)為 10 分鐘 NCCL 通信超時(shí),而 Megatron-LM 為 30 分鐘。在萬卡規(guī)模訓(xùn)練場(chǎng)景中,意味著一萬張卡要至少浪費(fèi) 30 分鐘才能被發(fā)現(xiàn)。這個(gè)時(shí)效性是不可接受的。而且當(dāng) 30 分鐘超時(shí)后程序會(huì)立馬退出,很難有機(jī)會(huì)進(jìn)行下一步定位,需要一些時(shí)效性更高的感知機(jī)制,并且在程序退出前獲取一些有效信息供后續(xù)診斷分析。
很多公司、實(shí)驗(yàn)室在面對(duì) hang 的問題時(shí),會(huì)在采用框架層插樁的方式來 trace 訓(xùn)練進(jìn)程,這種方式通常是比較直接且準(zhǔn)確的,但是有比較強(qiáng)的侵入性,而且可能還會(huì)有一些性能開銷。對(duì)于云廠商來說,需要尋找對(duì)用戶更透明、更無損的方式來感知、定位 hang 異常。
如何感知訓(xùn)練 hang,以百度百舸的產(chǎn)品設(shè)計(jì)思路為例,我們可以從以下幾個(gè)方向去思考:
1.訓(xùn)練進(jìn)程 hang 的最直觀表現(xiàn)是什么?
人工判斷一個(gè)任務(wù)是否 hang 了,最直接的方式就是看是否所有 worker 的任務(wù)日志一段時(shí)間內(nèi)都不輸出日志了,所以 hang 自動(dòng)感知的第一種方法就是采集所有 worker 的日志,并判斷所有 worker 日志中最后一行日志是否為 x 分鐘前的(x 小于 Pytorch 的通信超時(shí)時(shí)間,例如 8 分鐘),如果是則基本可以判定為 hang。
2.任務(wù) hang 時(shí)進(jìn)程有什么樣的表現(xiàn)?
任務(wù) hang 時(shí),可能進(jìn)程的調(diào)用棧都不在發(fā)生變化,進(jìn)程的調(diào)用?？梢酝ㄟ^ py-spy/pystack 等工具進(jìn)行探測(cè),所以我們可以用此類工具對(duì)所有訓(xùn)練任務(wù)進(jìn)行一個(gè)定時(shí)采樣,當(dāng)采集 n 個(gè)樣本所有進(jìn)程棧都沒有變化時(shí),可以判定一次 hang,這種方式通?？梢詫?hang 感知縮小至 3～5 分鐘。
3.任務(wù) hang 時(shí)監(jiān)控指標(biāo)有哪些變化?
訓(xùn)練進(jìn)程中的 CUDA 算子計(jì)算、集合通信操作通常都是在毫秒,甚至微秒、納秒內(nèi)完成的,當(dāng)任務(wù)在正常迭代過程中發(fā)生了 hang,我們常遇到的情況是所有 rank 的 RDMA 流量會(huì)降到 0,而 GPU 的利用率為 100%、SM 利用率則在很低的水位。如果持續(xù)幾分鐘都是這種狀態(tài)時(shí),意味著訓(xùn)練進(jìn)程已經(jīng)計(jì)算完成,在等著集合通信完成,這種情況下基本可以判定為 hang。
4.是否能在通信庫(kù)中更快的感知通信 hang?
通常單次集合通信操作都是在 ms 級(jí)的,如果一次操作在 30 秒鐘都沒有完成,那就可以判定為通信 hang 死了。百度自研的 BCCL 集合通信庫(kù)層可以對(duì)每一次集合通信操作都進(jìn)行打點(diǎn),來實(shí)現(xiàn)通信 hang 感知。
上述幾種方法,我們可以分別實(shí)現(xiàn)一種探針,來抓取相應(yīng)的特征到中心端 master 組件進(jìn)行下一步診斷和容錯(cuò)決策。
百度集合通信庫(kù) BCCL是百度智能云推出的一款面向大模型訓(xùn)練場(chǎng)景優(yōu)化的集合通信庫(kù)。
BCCL 基于開源的 NCCL 進(jìn)行了功能擴(kuò)展和能力增強(qiáng),針對(duì)大模型訓(xùn)練場(chǎng)景在可觀測(cè)性、故障診斷、穩(wěn)定性等方面進(jìn)行優(yōu)化,進(jìn)一步提升集合通信庫(kù)的可運(yùn)維能力。相比 NCCL,BCCL 的關(guān)鍵特性如下:
* 可觀測(cè)性:新增集合通信帶寬實(shí)時(shí)統(tǒng)計(jì)能力;
* 故障診斷:新增集合通信 hang 時(shí)的故障診斷能力;
* 穩(wěn)定性:增強(qiáng)網(wǎng)絡(luò)穩(wěn)定性和故障容錯(cuò)能力;
* 性能優(yōu)化:提升大模型訓(xùn)練主流 GPU 芯片的集合通信性能。
4.2. 訓(xùn)練 hang 的自動(dòng)診斷
有了以上感知手段,我們需要進(jìn)一步的診斷、定位,來確定是否真的發(fā)生了 hang,以及 hang 的具體位置。具體的來講,master 收集到各類 agent 的數(shù)據(jù)后,會(huì)做一些綜合分析:
1.是否真的發(fā)生了 hang?感知階段各種探針只能探測(cè)到 hang 的一種特征,并沒有辦法 100% 的確定是否真的 hang 住了,事實(shí)上不侵入用戶進(jìn)程是很難做到 100% 確定 hang 的。因此,為了提高 hang 的判定準(zhǔn)確率,我們需要將各種特種綜合起來判斷,探針上報(bào)到 master 后,由一個(gè) hang 診斷模塊,按照一個(gè)時(shí)間窗口(例如 5 分鐘),進(jìn)行綜合判斷。如果在時(shí)間窗口內(nèi)日志、監(jiān)控、進(jìn)程調(diào)用棧、通信庫(kù)中有 2 條以上都處于不處于活躍狀態(tài)時(shí),我們判斷任務(wù)真正發(fā)生了 hang。
2.hang 的具體發(fā)生的位置?確定任務(wù) hang 了之后,我們需要找到 hang 所在的節(jié)點(diǎn)來對(duì)它進(jìn)行隔離。因此診斷模塊需要在探針上報(bào)的數(shù)據(jù)中進(jìn)一步找尋特征,來確定 hang 發(fā)生的位置:
a.BCCL Tracehang 診斷:在感知階段,BCCL 可以在通信庫(kù)層面對(duì)所有 rank 的通信進(jìn)行打點(diǎn)。如果有節(jié)點(diǎn)一直未完成通信則是發(fā)生了 hang。但是此節(jié)點(diǎn)可能并非真正發(fā)生 hang 的源頭,有可能是在等待其他節(jié)點(diǎn)完成通信。診斷模塊可以根據(jù) BCCL 打印的通信組信息,進(jìn)行交叉判斷,如果某個(gè)節(jié)點(diǎn)在多個(gè)通信組中都未完成通信,那這個(gè)節(jié)點(diǎn)就是 hang 的源頭。
b.RDMA/GPU 指標(biāo)診斷:上文中我們提到,通信階段發(fā)生 hang 之后,所有 rank 的 RDMA 流量都會(huì)降到 0,而同時(shí)絕大部分 rank 的 GPU 利用率持續(xù)為 100%,只有某一兩個(gè) rank 的 GPU 利用率為 0,那這個(gè) rank 很有可能是 hang 的源頭。
c.進(jìn)程調(diào)用棧診斷:進(jìn)程調(diào)用棧也可以作為一個(gè) hang 源頭診斷的重要參考。當(dāng)發(fā)生 hang 之后,絕大部分的 rank 都要么處于 barrier 等待狀態(tài),要么處于通信等待階段。只有個(gè)別的 rank 卡在其他函數(shù)上,那么通過對(duì)比分析,可以將調(diào)用棧與其他 rank 不同的節(jié)點(diǎn)初步判定為 hang 的源頭。
d.綜合診斷:上面 3 種特征為我們提供了 hang 的診斷依據(jù),將 3 者關(guān)聯(lián)起來分析后,我們基本上可以比較準(zhǔn)確的確定一個(gè)具體的 hang 的源頭,再結(jié)合硬件故障感知的相關(guān)信息可以進(jìn)一步明確根因。
4.3.基于 eBPF 的隱式故障感知與診斷在復(fù)雜的大規(guī)模分布式訓(xùn)練場(chǎng)景中,傳統(tǒng)用戶態(tài)監(jiān)控往往難以捕獲系統(tǒng)內(nèi)核層面的異常事件。百度百舸基于 eBPF(Extended Berkeley Packet Filter)技術(shù)的隱式故障感知體系,能夠在不侵入用戶代碼的前提下,對(duì)訓(xùn)練進(jìn)程的系統(tǒng)調(diào)用、網(wǎng)絡(luò)通信、CPU 調(diào)度等內(nèi)核態(tài)行為以及訓(xùn)練框架關(guān)鍵函數(shù)運(yùn)行時(shí)間建立立體觀測(cè)能力。eBPF 探針部署原理通過在內(nèi)核關(guān)鍵路徑注入輕量級(jí)探針,實(shí)現(xiàn)低開銷的系統(tǒng)級(jí)行為捕獲。針對(duì)訓(xùn)練場(chǎng)景特點(diǎn),主要聚焦 4 類事件跟蹤:
訓(xùn)練關(guān)鍵函數(shù)跟蹤:微秒級(jí)跟蹤訓(xùn)練過程中,前向計(jì)算、反向計(jì)算、集合通信操作等關(guān)鍵函數(shù)執(zhí)行耗時(shí),記錄函數(shù)間調(diào)用關(guān)系。
進(jìn)程調(diào)度阻塞跟蹤:掛鉤 sched_switch 事件,檢測(cè)進(jìn)程在 TASK_UNINTERRUPTIBLE 狀態(tài)持續(xù)時(shí)間,當(dāng)單次持續(xù)超過閾值(如 5 秒)時(shí)捕獲調(diào)用棧。
CUDA 運(yùn)行時(shí) API 監(jiān)控:通過 uprobe 在 libcuda.so 等關(guān)鍵庫(kù)注入探針,記錄 CUDA API 調(diào)用耗時(shí)分布。
RDMA Verbs 級(jí)通信監(jiān)控:在 ibv_post_send/ibv_poll_cq 等核心通信接口設(shè)置觀測(cè)點(diǎn),統(tǒng)計(jì)通信時(shí)延分布。
結(jié)合上面 4 類事件,完成以下 2 類數(shù)據(jù)分析:
單體異常探測(cè)基線與實(shí)時(shí)數(shù)據(jù)對(duì)比。
群體一致性檢測(cè)。采用卡間對(duì)比算法,當(dāng)某一 rank 的以下指標(biāo)偏離集群中位數(shù)超過閾值時(shí)判定異常,包括系統(tǒng)調(diào)用頻率、進(jìn)程就緒隊(duì)列等待時(shí)長(zhǎng)、NVLink/RDMA 帶寬利用率等。
基于以上所述方法,百度百舸針對(duì)以下 2 類典型的隱式故障進(jìn)行診斷:
訓(xùn)練 hang 根因定位。通過關(guān)聯(lián) eBPF 捕獲的多維度數(shù)據(jù)進(jìn)行如下操作:
當(dāng)檢測(cè)到某 rank 的 GPU Kernel 執(zhí)行出現(xiàn)分鐘級(jí)空跑(SM 利用率 > 70% 但無有效計(jì)算輸出)。
同時(shí)伴隨該節(jié)點(diǎn) RDMA QP 狀態(tài)停滯(ibv_poll_cq 無新完成事件)。
內(nèi)核調(diào)度器顯示進(jìn)程處于 D 狀態(tài)超過閾值。
性能抖動(dòng)溯源。基于 eBPF 火焰圖、時(shí)序圖等進(jìn)行分析:
抓取發(fā)生性能下降時(shí)段的 CPU on-cpu/off-cpu 堆棧。
對(duì)比正常時(shí)段數(shù)據(jù),識(shí)別出異常的鎖競(jìng)爭(zhēng)(futex 調(diào)用占比上升)。
結(jié)合 NUMA 內(nèi)存訪問統(tǒng)計(jì),定位跨 NUMA 內(nèi)存訪問導(dǎo)致的 TLB 顛簸問題。
此類技術(shù)已在百度百舸的萬卡規(guī)模訓(xùn)練集群中驗(yàn)證,相比單純依賴應(yīng)用層監(jiān)控的方案,將隱式故障的平均檢測(cè)時(shí)間從分鐘級(jí)縮短至秒級(jí),診斷準(zhǔn)確率提升 40% 以上。
通過與既有硬件故障感知服務(wù)、BCCL 通信庫(kù)監(jiān)測(cè)體系聯(lián)動(dòng),百度百舸形成了覆蓋從硬件到系統(tǒng)內(nèi)核再到應(yīng)用層的立體化診斷能力。
5. 任務(wù)故障恢復(fù)的時(shí)效性保障
故障恢復(fù)的時(shí)效性也是容錯(cuò)能力的一個(gè)重要指標(biāo),反映的是任務(wù)從故障發(fā)生到再次重新進(jìn)入訓(xùn)練迭代的時(shí)間,恢復(fù)效率越高則算力浪費(fèi)越少。影響到任務(wù)恢復(fù)效率有 2 個(gè)重要因素,一是任務(wù)平均中斷時(shí)間,二是訓(xùn)練重算時(shí)間。5.1.多級(jí)重啟策略減少故障中斷時(shí)間
任務(wù)發(fā)生異常后,上文中我們提到需要經(jīng)過故障自動(dòng)感知、診斷和自愈等 3 個(gè)環(huán)節(jié),那么減少中斷時(shí)間的核心思想,就是盡可能的縮短這 3 個(gè)環(huán)節(jié)的時(shí)間,通過多維度的感知、診斷手段可以將故障發(fā)現(xiàn)、定位的時(shí)效性降低至分鐘級(jí)甚至秒級(jí)。自愈則需要能夠根據(jù)不同的診斷結(jié)果進(jìn)行分級(jí)恢復(fù)和故障屏蔽的能力:
單點(diǎn)顯式故障:重調(diào)度異常節(jié)點(diǎn)(replace),對(duì)節(jié)點(diǎn)進(jìn)行集群級(jí)別屏蔽。
單點(diǎn)隱式故障:重調(diào)度異常節(jié)點(diǎn),對(duì)節(jié)點(diǎn)進(jìn)行任務(wù)級(jí)別屏蔽。
非單點(diǎn)故障:原地重啟嘗試恢復(fù)(restart),無法恢復(fù)時(shí)重新調(diào)度所有節(jié)點(diǎn)(resubmit)。
通過多級(jí)重啟策略,盡可能避免單點(diǎn)故障引發(fā)全部節(jié)點(diǎn)的重新調(diào)度。在萬卡級(jí)別的訓(xùn)練場(chǎng)景中,百度百舸將大部分訓(xùn)練異常場(chǎng)景恢復(fù)時(shí)間從過去的 30min 縮短至現(xiàn)在的 30s 內(nèi),成功率到 95%+。
5.2. 觸發(fā)式 checkpoint 減少訓(xùn)練重算時(shí)間
除了上述的多級(jí)任務(wù)重啟策略外,另一個(gè)提高任務(wù)故障恢復(fù)效率的重要手段就是減少訓(xùn)練重算時(shí)間。在探討具體技術(shù)方案之前,我們先來看看目前主流的 checkpoint 保存策略。
傳統(tǒng)的 checkpoint 保存通常采用固定間隔策略,比如每隔 N 個(gè) step 或每隔 T 小時(shí)保存一次,這種方式實(shí)現(xiàn)簡(jiǎn)單但缺乏靈活性,可能會(huì)產(chǎn)生大量冗余存儲(chǔ),同時(shí)在故障發(fā)生時(shí)可能會(huì)損失較多訓(xùn)練進(jìn)度。
而觸發(fā)式 checkpoint 則是一種更智能的方案,它根據(jù)特定條件或異常事件(如故障、顯存不足、顯式指令等)動(dòng)態(tài)觸發(fā)模型狀態(tài)保存。其核心目標(biāo)是通過靈活的控制保存時(shí)機(jī),減少不必要的存儲(chǔ)開銷和訓(xùn)練中斷時(shí)間,從而降低因頻繁或冗余保存導(dǎo)致的重算時(shí)間浪費(fèi)。
隨著大模型訓(xùn)練規(guī)模的擴(kuò)大,還有一種更激進(jìn)的「零重復(fù) checkpoint」技術(shù),即在每個(gè)訓(xùn)練 step 都保存一次 checkpoint。這種方案的優(yōu)勢(shì)在于可以將重算時(shí)間降到最低,確保故障發(fā)生時(shí)能夠從最近的 step 恢復(fù),幾乎不會(huì)損失訓(xùn)練進(jìn)度。但其顯著的缺點(diǎn)是存儲(chǔ)開銷巨大,即使采用增量式存儲(chǔ),仍然需要相當(dāng)大的存儲(chǔ)空間和 I/O 帶寬。此外,頻繁的 checkpoint 操作也可能影響訓(xùn)練性能。
相比之下,觸發(fā)式 checkpoint 走的是一條平衡之路。我們來看下它實(shí)現(xiàn)的幾個(gè)核心要點(diǎn):
集成容錯(cuò):訓(xùn)練進(jìn)程集成容錯(cuò)的故障感知與定位機(jī)制,在進(jìn)程退出前自動(dòng)觸發(fā)保存。這種主動(dòng)感知機(jī)制能夠在故障發(fā)生的第一時(shí)間保存訓(xùn)練狀態(tài),最大限度減少進(jìn)度損失。
高速轉(zhuǎn)儲(chǔ):異步 checkpoint 保存機(jī)制會(huì)將 checkpoint 暫存到共享內(nèi)存中,再由外部程序轉(zhuǎn)儲(chǔ)至磁盤。當(dāng)某個(gè)節(jié)點(diǎn)異常時(shí),容錯(cuò)組件會(huì)拉起新節(jié)點(diǎn),并在新節(jié)點(diǎn)訓(xùn)練進(jìn)程啟動(dòng)前,利用 RDMA 技術(shù)實(shí)現(xiàn) checkpoint 快速?gòu)墓收瞎?jié)點(diǎn)轉(zhuǎn)儲(chǔ)至新節(jié)點(diǎn),這大大減少了從遠(yuǎn)程存儲(chǔ)拉取 checkpoint 的時(shí)間。
冗余備份:觸發(fā)式 checkpoint 也并非完美無缺,例如在節(jié)點(diǎn)發(fā)生內(nèi)核 crash 等嚴(yán)重故障時(shí),可能無法觸發(fā)自動(dòng)保存。因此,需要通過定期的冗余備份機(jī)制進(jìn)行兜底,確保 checkpoint 不會(huì)完全丟失。
實(shí)踐表明,當(dāng)觸發(fā)式 checkpoint 與異步、增量式的 checkpoint 機(jī)制結(jié)合使用時(shí),可以在保證數(shù)據(jù)安全性的同時(shí),顯著提高 checkpoint 保存效率,減少訓(xùn)練重算時(shí)間。
相比零重復(fù) checkpoint 的重型方案,觸發(fā)式 checkpoint 提供了一個(gè)更實(shí)用的折中方案,在合理的存儲(chǔ)開銷下實(shí)現(xiàn)較好的容錯(cuò)效果。當(dāng)然,具體選擇哪種方案,還需要根據(jù)實(shí)際的訓(xùn)練規(guī)模、硬件條件和可用資源來權(quán)衡。
隨著分布式訓(xùn)練規(guī)模的持續(xù)增長(zhǎng),相信未來會(huì)出現(xiàn)更多創(chuàng)新的 checkpoint 方案,比如基于預(yù)測(cè)的主動(dòng)保存策略、多級(jí)存儲(chǔ)架構(gòu)的智能調(diào)度等,這些都將為提高大規(guī)模訓(xùn)練的可靠性提供新的可能。
6.業(yè)務(wù)發(fā)展對(duì)穩(wěn)定性的要求
AI 訓(xùn)練的穩(wěn)定性管理已經(jīng)演變?yōu)橹悄軙r(shí)代的精密工程。從最初靠人工重啟解決問題的摸索階段,到如今能自動(dòng)感知異常、快速恢復(fù)的智能系統(tǒng),每一次進(jìn)步都映照著算力規(guī)模的跨越式發(fā)展。
讓人不禁思考,在未來十萬卡集群的算力洪流中,或許會(huì)出現(xiàn)更精妙的動(dòng)態(tài)平衡方案:既能像鷹隼般敏銳捕捉故障征兆,又能如雁群遷移般智能調(diào)度資源,在秒級(jí)恢復(fù)與 PB 級(jí)存儲(chǔ)成本之間找到新的平衡支點(diǎn)。
目前百度百舸支持廠內(nèi)千卡和萬卡集群有效訓(xùn)練時(shí)長(zhǎng)已經(jīng)可達(dá) 99.5%,為客戶大模型的預(yù)訓(xùn)練保駕護(hù)航,比如國(guó)內(nèi)第一個(gè)數(shù)學(xué)大模型——九章算術(shù),國(guó)內(nèi)第一個(gè)類 Sora 大模型 —— Vidu 等。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
