豆包是如何煉成的?字節(jié)放出自研萬(wàn)卡訓(xùn)練系統(tǒng)ByteRobust論文
大型語(yǔ)言模型(LLM)訓(xùn)練的核心基礎(chǔ)設(shè)施是 GPU。現(xiàn)如今,其訓(xùn)練規(guī)模已達(dá)到數(shù)萬(wàn)塊 GPU,并且仍在持續(xù)擴(kuò)大。同時(shí),訓(xùn)練大模型的時(shí)間也越來(lái)越長(zhǎng)。例如,一個(gè) 405B 參數(shù)模型 LLaMA 3 的預(yù)訓(xùn)練,動(dòng)用了 16,384 塊 NVIDIA H100 GPU,耗時(shí) 54 天。字節(jié)跳動(dòng)曾使用 12,288 塊 GPU 訓(xùn)練了一個(gè) 175B 參數(shù)的模型。最近,xAI 建立了一個(gè)擁有 100,000 塊 GPU 的集群以進(jìn)一步擴(kuò)大訓(xùn)練規(guī)模。
資源規(guī)模的擴(kuò)張也帶來(lái)了故障的普遍發(fā)生(例如 CUDA 錯(cuò)誤、NaN 值、任務(wù)掛起等),這對(duì)訓(xùn)練的穩(wěn)定性構(gòu)成了巨大挑戰(zhàn)。Meta 曾報(bào)告稱,在 16,000 塊 GPU 上訓(xùn)練大模型時(shí),硬件故障大約每 2.78 小時(shí)發(fā)生一次。
對(duì)于 LLM 訓(xùn)練,當(dāng)前的故障診斷和處理實(shí)踐通常依賴于在發(fā)生「故障即停止」 (fail-stop) 事件后進(jìn)行日志分析和退出碼評(píng)估,或者獨(dú)占整個(gè)集群進(jìn)行壓力測(cè)試。一旦確定了根本原因,訓(xùn)練任務(wù)會(huì)通過(guò)重新調(diào)度的資源和并行配置來(lái)恢復(fù),并從遠(yuǎn)程文件系統(tǒng)重新加載通常由 TB 級(jí)數(shù)據(jù)組成的檢查點(diǎn) (checkpoints)。這種「故障 - 停止-診斷-恢復(fù)」的流程會(huì)產(chǎn)生不可忽視的開(kāi)銷,耗時(shí)從幾小時(shí)到幾天不等。隨著模型和資源規(guī)模的擴(kuò)大,故障頻率增加,這極大地限制了有效訓(xùn)練時(shí)間比率 (ETTR,即有效訓(xùn)練時(shí)間與任務(wù)總運(yùn)行時(shí)長(zhǎng)的比值)。
因此,任何大規(guī)模 LLM 訓(xùn)練基礎(chǔ)設(shè)施都應(yīng)致力于實(shí)現(xiàn)最小化的訓(xùn)練中斷、高效的故障診斷和有效的容錯(cuò)能力,以支持高效率的連續(xù)訓(xùn)練。
近日,字節(jié)跳動(dòng)一篇論文介紹了他們 LLM 訓(xùn)練基礎(chǔ)設(shè)施 ByteRobust,引發(fā)廣泛關(guān)注?,F(xiàn)在,在訓(xùn)練基礎(chǔ)設(shè)施層面上,我們終于知道字節(jié)跳動(dòng)會(huì)如何穩(wěn)健地訓(xùn)練豆包了。

- 論文標(biāo)題:Robust LLM Training Infrastructure at ByteDance
- 論文地址:https://arxiv.org/abs/2509.16293
值得注意的是,這項(xiàng)研究共有六位共一作者:Borui Wan、 Gaohong Liu、Zuquan Song、Jun Wang、Yun Zhang、Guangming Sheng。
ByteRobust,一個(gè)穩(wěn)健的 LLM 訓(xùn)練基礎(chǔ)設(shè)施
ByteRobust 是字節(jié)跳動(dòng)基于生產(chǎn)環(huán)境中的觀察和經(jīng)驗(yàn)構(gòu)建的,力求穩(wěn)健。
其關(guān)鍵目標(biāo)是:以最小的非生產(chǎn)時(shí)間實(shí)現(xiàn)高效的事件診斷和處理,即在大規(guī)模 LLM 訓(xùn)練中獲得高 ETTR。ByteRobust 經(jīng)過(guò)精心設(shè)計(jì),用于監(jiān)控和管理 LLM 訓(xùn)練的全生命周期,以便大規(guī)模地自動(dòng)高效處理訓(xùn)練事件。
ByteRobust 由兩個(gè)核心組件構(gòu)成:控制平面 (control plane) 和數(shù)據(jù)平面 (data plane)。

ByteRobust 的架構(gòu)
控制平面在訓(xùn)練任務(wù)外部運(yùn)行,負(fù)責(zé)協(xié)調(diào)穩(wěn)健的事件處理策略,包括檢測(cè)異常、定位故障并觸發(fā)適當(dāng)?shù)幕謴?fù)操作。
其中,Robust Controller 負(fù)責(zé)協(xié)調(diào)一個(gè)自動(dòng)化的故障緩解框架,利用實(shí)時(shí)監(jiān)控和「停止 - 診斷」來(lái)處理大多數(shù)事件。為了實(shí)現(xiàn)可控的快速恢復(fù),當(dāng)沒(méi)有機(jī)器被驅(qū)逐時(shí),它使用一種「原地?zé)岣隆箼C(jī)制來(lái)重啟訓(xùn)練。當(dāng)決定驅(qū)逐某些機(jī)器時(shí),它會(huì)請(qǐng)求經(jīng)過(guò)自檢預(yù)驗(yàn)證的「溫備用」機(jī)器來(lái)恢復(fù)任務(wù)。
Runtime Analyzer 則通過(guò)聚合來(lái)自訓(xùn)練 Pod 的堆棧跟蹤來(lái)隔離和(過(guò)度)驅(qū)逐可疑機(jī)器,以解決任務(wù)掛起和性能下降問(wèn)題。
數(shù)據(jù)平面駐留在每個(gè)訓(xùn)練 Pod 內(nèi)部,集成了監(jiān)控、診斷、檢查點(diǎn)管理和堆棧跟蹤捕獲等模塊,提供實(shí)時(shí)可觀測(cè)性、中斷時(shí)的即時(shí)診斷、快速的檢查點(diǎn)回滾以及按需的聚合分析。
Robust Agent 守護(hù)進(jìn)程在每個(gè)訓(xùn)練 Pod 中運(yùn)行,處理來(lái)自穩(wěn)健控制器的控制信號(hào),并管理以下四個(gè)子模塊:
- 監(jiān)控器 (Monitor) 收集多方面數(shù)據(jù)以檢測(cè)異常值,支持實(shí)時(shí)檢查并在出現(xiàn)異常時(shí)觸發(fā)聚合分析。
- 診斷器 (Diagnoser) 在任務(wù)暫停后運(yùn)行特定領(lǐng)域的基準(zhǔn)測(cè)試和測(cè)試套件,從而能夠?qū)?fù)雜故障進(jìn)行深入診斷。
- 按需追蹤器 (On-Demand Tracer) 從訓(xùn)練進(jìn)程中捕獲堆棧跟蹤(當(dāng)調(diào)用聚合分析時(shí))并將其上傳到運(yùn)行時(shí)分析器。
- 檢查點(diǎn)管理器 (CKPT manager) 執(zhí)行異步檢查點(diǎn)設(shè)置,并將備份跨并行組存儲(chǔ)到 CPU 內(nèi)存和本地磁盤(pán),以最小化恢復(fù)成本)。
與傳統(tǒng)的 GPU 管理和容錯(cuò)系統(tǒng)(通常在 Kubernetes Pod 級(jí)別運(yùn)行)不同,ByteRobust 是將 LLM 訓(xùn)練任務(wù)的清單擴(kuò)展到包含細(xì)粒度的進(jìn)程管理,能夠利用運(yùn)行時(shí)信息進(jìn)行故障檢測(cè)并實(shí)現(xiàn)快速恢復(fù)。ByteRobust 通過(guò)一套全面的技術(shù)實(shí)現(xiàn)了這一目標(biāo),其新穎的系統(tǒng)設(shè)計(jì)理念總結(jié)如下。
優(yōu)先快速隔離,而非精確定位
ByteRobust 傾向于快速的故障隔離,而不是詳盡的定位。在超大規(guī)模的 LLM 訓(xùn)練中(通常涉及數(shù)千塊 GPU),精確定位故障可能會(huì)導(dǎo)致大量 GPU 閑置。
為了最大化 ETTR,字節(jié)跳動(dòng)的做法是將輕量級(jí)的實(shí)時(shí)檢測(cè)與分層的「停止-診斷」相結(jié)合,以最小的開(kāi)銷快速甄別出故障機(jī)器。
當(dāng)這些方法不足以解決問(wèn)題時(shí),ByteRobust 會(huì)應(yīng)用一種數(shù)據(jù)驅(qū)動(dòng)的方法,對(duì)運(yùn)行時(shí)的堆棧跟蹤進(jìn)行聚類分析,以在定義的故障域(即并行組)內(nèi)隔離可疑機(jī)器,寧可「過(guò)度驅(qū)逐」它們,也不去追查確切的根本原因。

將人為錯(cuò)誤納入設(shè)計(jì)考量
與標(biāo)準(zhǔn)的深度學(xué)習(xí)訓(xùn)練任務(wù)不同,長(zhǎng)達(dá)數(shù)月的 LLM 訓(xùn)練涉及數(shù)據(jù)、算法和工程代碼的持續(xù)更新,這加劇了系統(tǒng)的脆弱性。
認(rèn)識(shí)到人為錯(cuò)誤是不可避免的故障來(lái)源,字節(jié)跳動(dòng)提出了一個(gè)自動(dòng)化容錯(cuò)框架。

ByteRobust 的自動(dòng)化容錯(cuò)機(jī)制
該框架結(jié)合了用于即時(shí)檢測(cè)常見(jiàn)錯(cuò)誤的實(shí)時(shí)檢查、用于深入分析復(fù)雜故障的「停止-診斷」、用于從瞬時(shí)故障中恢復(fù)的原地重試、用于從有缺陷的用戶代碼中恢復(fù)的代碼回滾,以及用于解決如 SDC 等極端情況的回放測(cè)試。
此外,通過(guò)一種「延遲更新」的方法,用戶代碼的變更可以與確定性故障的恢復(fù)過(guò)程合并,從而利用了故障的必然性和高頻率。
在快速恢復(fù)期間控制可變性
故障源于硬件缺陷和軟件錯(cuò)誤,并且機(jī)器在長(zhǎng)時(shí)間運(yùn)行的任務(wù)中可能會(huì)性能退化。因此,在代碼升級(jí)和恢復(fù)過(guò)程中確保穩(wěn)定性至關(guān)重要。
對(duì)于不改變機(jī)器分配的變更,字節(jié)跳動(dòng)使用一種「原地?zé)岣隆箼C(jī)制來(lái)保留運(yùn)行時(shí)環(huán)境并簡(jiǎn)化診斷。
為確??煽厍铱焖俚幕謴?fù),ByteRobust 利用預(yù)先配置的「溫備用」 (warm standbys) 機(jī)器,這些機(jī)器在交付前會(huì)執(zhí)行自檢,以避免整個(gè)任務(wù)的重新調(diào)度。
最后,字節(jié)跳動(dòng)的檢查點(diǎn)模塊通過(guò)將備份分布在不同的并行組中(位于任何單個(gè)故障域之外),與故障域緊密結(jié)合,消除了對(duì)遠(yuǎn)程文件系統(tǒng)的依賴,從而實(shí)現(xiàn)快速重啟。
ByteRobust 已被實(shí)際部署
字節(jié)跳動(dòng)表示,ByteRobust 已經(jīng)實(shí)現(xiàn)并已實(shí)際部署超過(guò)一年時(shí)間,用于支持字節(jié)跳動(dòng)在高性能生產(chǎn) GPU 集群中的內(nèi)部 LLM 訓(xùn)練。字節(jié)跳動(dòng)表示,ByteRobust 可以有效減少事件檢測(cè)時(shí)間,并通過(guò)自動(dòng)容錯(cuò)框架和聚合分析解決事件。
在為期三個(gè)月的時(shí)間里,ByteRobust 通過(guò)其自動(dòng)化容錯(cuò)訓(xùn)練框架識(shí)別了 38,236 次顯式故障和 5,948 次隱式故障。

字節(jié)跳動(dòng)在三個(gè)月期間收集的訓(xùn)練事故統(tǒng)計(jì)數(shù)據(jù),涵蓋了 778,135 個(gè) LLM 訓(xùn)練任務(wù)。
字節(jié)跳動(dòng)在 16,384 塊 GPU 上的微基準(zhǔn)測(cè)試實(shí)驗(yàn)表明,溫備用和熱更新機(jī)制在恢復(fù)速度上分別實(shí)現(xiàn)了高達(dá) 10.87 倍和 11.04 倍的提升。

ByteRobust 中高效的檢查點(diǎn)機(jī)制實(shí)現(xiàn)了「每步檢查點(diǎn)」(every-step checkpointing),其開(kāi)銷低于 0.9%,從而加速了故障切換。

部署實(shí)驗(yàn)表明,在一個(gè)為期三個(gè)月、使用 9,600 塊 GPU 的密集模型(類似 Llama,70B+)訓(xùn)練任務(wù)中,ByteRobust 實(shí)現(xiàn)了高達(dá) 97% 的 ETTR。

Cumulative ETTR 和 sliding-window ETTR 是字節(jié)跳動(dòng)引入的新指標(biāo),其中前者是累積的有效訓(xùn)練時(shí)間與任務(wù)運(yùn)行的累積總時(shí)長(zhǎng)的比率,而后者在一個(gè)小時(shí)的窗口內(nèi)計(jì)算的 ETTR,能更準(zhǔn)確地反映間歇性故障的影響。
另外,他們也進(jìn)行了一個(gè)為期一個(gè)月的 MoE 模型(Doubao-1.5-pro,200B+)訓(xùn)練任務(wù),ByteRobust 的表現(xiàn)同樣非常不錯(cuò)。
同時(shí),隨著訓(xùn)練的進(jìn)行,兩個(gè)任務(wù)的相對(duì) MFU(Model FLOPs Utilization)持續(xù)增長(zhǎng)。在訓(xùn)練期間,字節(jié)跳動(dòng)最初在集群上部署了一個(gè)樸素版本的預(yù)訓(xùn)練代碼,然后不斷地調(diào)整和優(yōu)化其學(xué)習(xí)過(guò)程和計(jì)算效率。

在上圖中,MFU 曲線的每一次躍升都表明,一個(gè)更高效的訓(xùn)練代碼版本通過(guò) ByteRobust 的熱更新機(jī)制部署了,而這對(duì) ETTR 造成的降低微不足道。與初始運(yùn)行時(shí)相比,字節(jié)跳動(dòng)在密集模型和 MoE 任務(wù)中分別實(shí)現(xiàn)了 1.25 倍和 1.58 倍的 MFU 提升。
字節(jié)跳動(dòng)還觀察到,與密集模型相比,MoE 訓(xùn)練的 ETTR 相對(duì)較低。
密集模型的訓(xùn)練性能通常已由社區(qū)充分優(yōu)化,而 MoE 訓(xùn)練則不同,它通常涉及大量自定義優(yōu)化,如 GPU 內(nèi)核調(diào)優(yōu)、計(jì)算與通信重疊以及負(fù)載均衡策略。雖然這些優(yōu)化對(duì)于提高訓(xùn)練效率是必要的,并表現(xiàn)出更高的 MFU,但它們也引入了額外的復(fù)雜性,增加了代碼回滾和手動(dòng)重啟的可能性。
更多詳情請(qǐng)參閱原論文。






















