大型語言模型（LLM）訓練的核心基礎設施是 GPU?，F如今，其訓練規模已達到數萬塊 GPU，并且仍在持續擴大。同時，訓練大模型的時間也越來越長。例如，一個 405B 參數模型 LLaMA 3 的預訓練，動用了 16,384 塊 NVIDIA H100 GPU，耗時 54 天。字節跳動曾使用 12,288 塊 GPU 訓練了一個 175B 參數的模型。最近，xAI 建立了一個擁有 100,000 塊 GPU 的集群以進一步擴大訓練規模。

資源規模的擴張也帶來了故障的普遍發生（例如 CUDA 錯誤、NaN 值、任務掛起等），這對訓練的穩定性構成了巨大挑戰。Meta 曾報告稱，在 16,000 塊 GPU 上訓練大模型時，硬件故障大約每 2.78 小時發生一次。

對于 LLM 訓練，當前的故障診斷和處理實踐通常依賴于在發生「故障即停止」 (fail-stop) 事件后進行日志分析和退出碼評估，或者獨占整個集群進行壓力測試。一旦確定了根本原因，訓練任務會通過重新調度的資源和并行配置來恢復，并從遠程文件系統重新加載通常由 TB 級數據組成的檢查點 (checkpoints)。這種「故障 - 停止-診斷-恢復」的流程會產生不可忽視的開銷，耗時從幾小時到幾天不等。隨著模型和資源規模的擴大，故障頻率增加，這極大地限制了有效訓練時間比率 (ETTR，即有效訓練時間與任務總運行時長的比值)。

因此，任何大規模 LLM 訓練基礎設施都應致力于實現最小化的訓練中斷、高效的故障診斷和有效的容錯能力，以支持高效率的連續訓練。

近日，字節跳動一篇論文介紹了他們 LLM 訓練基礎設施 ByteRobust，引發廣泛關注。現在，在訓練基礎設施層面上，我們終于知道字節跳動會如何穩健地訓練豆包了。

• 論文標題：Robust LLM Training Infrastructure at ByteDance
• 論文地址：https://arxiv.org/abs/2509.16293

值得注意的是，這項研究共有六位共一作者：Borui Wan、 Gaohong Liu、Zuquan Song、Jun Wang、Yun Zhang、Guangming Sheng。

ByteRobust，一個穩健的 LLM 訓練基礎設施

ByteRobust 是字節跳動基于生產環境中的觀察和經驗構建的，力求穩健。

其關鍵目標是：以最小的非生產時間實現高效的事件診斷和處理，即在大規模 LLM 訓練中獲得高 ETTR。ByteRobust 經過精心設計，用于監控和管理 LLM 訓練的全生命周期，以便大規模地自動高效處理訓練事件。

ByteRobust 由兩個核心組件構成：控制平面 (control plane) 和數據平面 (data plane)。

ByteRobust 的架構

控制平面在訓練任務外部運行，負責協調穩健的事件處理策略，包括檢測異常、定位故障并觸發適當的恢復操作。

其中，Robust Controller 負責協調一個自動化的故障緩解框架，利用實時監控和「停止 - 診斷」來處理大多數事件。為了實現可控的快速恢復，當沒有機器被驅逐時，它使用一種「原地熱更新」機制來重啟訓練。當決定驅逐某些機器時，它會請求經過自檢預驗證的「溫備用」機器來恢復任務。

Runtime Analyzer 則通過聚合來自訓練 Pod 的堆棧跟蹤來隔離和（過度）驅逐可疑機器，以解決任務掛起和性能下降問題。

數據平面駐留在每個訓練 Pod 內部，集成了監控、診斷、檢查點管理和堆棧跟蹤捕獲等模塊，提供實時可觀測性、中斷時的即時診斷、快速的檢查點回滾以及按需的聚合分析。

Robust Agent 守護進程在每個訓練 Pod 中運行，處理來自穩健控制器的控制信號，并管理以下四個子模塊：

• 監控器 (Monitor) 收集多方面數據以檢測異常值，支持實時檢查并在出現異常時觸發聚合分析。
• 診斷器 (Diagnoser) 在任務暫停后運行特定領域的基準測試和測試套件，從而能夠對復雜故障進行深入診斷。
• 按需追蹤器 (On-Demand Tracer) 從訓練進程中捕獲堆棧跟蹤（當調用聚合分析時）并將其上傳到運行時分析器。
• 檢查點管理器 (CKPT manager) 執行異步檢查點設置，并將備份跨并行組存儲到 CPU 內存和本地磁盤，以最小化恢復成本）。

與傳統的 GPU 管理和容錯系統（通常在 Kubernetes Pod 級別運行）不同，ByteRobust 是將 LLM 訓練任務的清單擴展到包含細粒度的進程管理，能夠利用運行時信息進行故障檢測并實現快速恢復。ByteRobust 通過一套全面的技術實現了這一目標，其新穎的系統設計理念總結如下。

優先快速隔離，而非精確定位

ByteRobust 傾向于快速的故障隔離，而不是詳盡的定位。在超大規模的 LLM 訓練中（通常涉及數千塊 GPU），精確定位故障可能會導致大量 GPU 閑置。

為了最大化 ETTR，字節跳動的做法是將輕量級的實時檢測與分層的「停止-診斷」相結合，以最小的開銷快速甄別出故障機器。

當這些方法不足以解決問題時，ByteRobust 會應用一種數據驅動的方法，對運行時的堆棧跟蹤進行聚類分析，以在定義的故障域（即并行組）內隔離可疑機器，寧可「過度驅逐」它們，也不去追查確切的根本原因。

將人為錯誤納入設計考量

與標準的深度學習訓練任務不同，長達數月的 LLM 訓練涉及數據、算法和工程代碼的持續更新，這加劇了系統的脆弱性。

認識到人為錯誤是不可避免的故障來源，字節跳動提出了一個自動化容錯框架。

ByteRobust 的自動化容錯機制

該框架結合了用于即時檢測常見錯誤的實時檢查、用于深入分析復雜故障的「停止-診斷」、用于從瞬時故障中恢復的原地重試、用于從有缺陷的用戶代碼中恢復的代碼回滾，以及用于解決如 SDC 等極端情況的回放測試。

此外，通過一種「延遲更新」的方法，用戶代碼的變更可以與確定性故障的恢復過程合并，從而利用了故障的必然性和高頻率。

在快速恢復期間控制可變性

故障源于硬件缺陷和軟件錯誤，并且機器在長時間運行的任務中可能會性能退化。因此，在代碼升級和恢復過程中確保穩定性至關重要。

對于不改變機器分配的變更，字節跳動使用一種「原地熱更新」機制來保留運行時環境并簡化診斷。

為確保可控且快速的恢復，ByteRobust 利用預先配置的「溫備用」 (warm standbys) 機器，這些機器在交付前會執行自檢，以避免整個任務的重新調度。

最后，字節跳動的檢查點模塊通過將備份分布在不同的并行組中（位于任何單個故障域之外），與故障域緊密結合，消除了對遠程文件系統的依賴，從而實現快速重啟。

ByteRobust 已被實際部署

字節跳動表示，ByteRobust 已經實現并已實際部署超過一年時間，用于支持字節跳動在高性能生產 GPU 集群中的內部 LLM 訓練。字節跳動表示，ByteRobust 可以有效減少事件檢測時間，并通過自動容錯框架和聚合分析解決事件。

在為期三個月的時間里，ByteRobust 通過其自動化容錯訓練框架識別了 38,236 次顯式故障和 5,948 次隱式故障。

字節跳動在三個月期間收集的訓練事故統計數據，涵蓋了 778,135 個 LLM 訓練任務。

字節跳動在 16,384 塊 GPU 上的微基準測試實驗表明，溫備用和熱更新機制在恢復速度上分別實現了高達 10.87 倍和 11.04 倍的提升。

ByteRobust 中高效的檢查點機制實現了「每步檢查點」(every-step checkpointing)，其開銷低于 0.9%，從而加速了故障切換。

部署實驗表明，在一個為期三個月、使用 9,600 塊 GPU 的密集模型（類似 Llama，70B+）訓練任務中，ByteRobust 實現了高達 97% 的 ETTR。

Cumulative ETTR 和 sliding-window ETTR 是字節跳動引入的新指標，其中前者是累積的有效訓練時間與任務運行的累積總時長的比率，而后者在一個小時的窗口內計算的 ETTR，能更準確地反映間歇性故障的影響。

另外，他們也進行了一個為期一個月的 MoE 模型（Doubao-1.5-pro，200B+）訓練任務，ByteRobust 的表現同樣非常不錯。

同時，隨著訓練的進行，兩個任務的相對 MFU（Model FLOPs Utilization）持續增長。在訓練期間，字節跳動最初在集群上部署了一個樸素版本的預訓練代碼，然后不斷地調整和優化其學習過程和計算效率。

在上圖中，MFU 曲線的每一次躍升都表明，一個更高效的訓練代碼版本通過 ByteRobust 的熱更新機制部署了，而這對 ETTR 造成的降低微不足道。與初始運行時相比，字節跳動在密集模型和 MoE 任務中分別實現了 1.25 倍和 1.58 倍的 MFU 提升。

字節跳動還觀察到，與密集模型相比，MoE 訓練的 ETTR 相對較低。

密集模型的訓練性能通常已由社區充分優化，而 MoE 訓練則不同，它通常涉及大量自定義優化，如 GPU 內核調優、計算與通信重疊以及負載均衡策略。雖然這些優化對于提高訓練效率是必要的，并表現出更高的 MFU，但它們也引入了額外的復雜性，增加了代碼回滾和手動重啟的可能性。

更多詳情請參閱原論文。