# Robust LLM Training Infrastructure at ByteDance Navigation: [[index]] | [[ByteRobust]] > [!abstract] 概要 > 大規模言語モデル(LLM)の訓練規模は数万 GPU に達し、さらに拡大を続けることで、より大きなモデルのより高速な学習を可能にしている。リソース規模の拡大に伴い、障害(CUDA エラー、NaN 値、ジョブハング等)の頻発が訓練の安定性に重大な課題をもたらしている。大規模 LLM 訓練インフラはいずれも、訓練の中断を最小化し、効率的な障害診断と効果的な障害許容を実現して、高効率かつ継続的な訓練を可能にすることを目指すべきである。本論文は、LLM の堅牢で安定した訓練に特化した大規模 GPU インフラ管理システム ByteRobust を提案する。ByteRobust は LLM 訓練プロセスの独自性を活用し、障害の検知と復旧を定常的に行うことを最優先する。LLM 訓練の並列性と特性を活用することで、ByteRobust は高容量の障害許容、迅速な障害の境界設定(demarcation)、効果的なデータ駆動アプローチによる箇所特定を実現し、LLM 訓練タスクの継続的で効率的な訓練を包括的に保証する。ByteRobust は本番 GPU プラットフォームに展開され、9,600 GPU・3 か月の訓練ジョブで 97% の ETTR を達成し、訓練ロバスト性の最先端を前進させた。 ## 論文情報 - タイトル: Robust LLM Training Infrastructure at ByteDance - 著者: Borui Wan, Gaohong Liu, Zuquan Song, Jun Wang, Yun Zhang, Guangming Sheng(以上 equal contribution)ほか多数、責任著者は [[Chuan Wu]](香港大学)と Wencong Xiao(ByteDance)。筆頭著者 Borui Wan と Guangming Sheng は [[The University of Hong Kong|香港大学]]兼任、それ以外は [[ByteDance]] Seed 所属。(Source: 本論文 著者欄) - 媒体: SOSP '25(ACM SIGOPS 31st Symposium on Operating Systems Principles、2025-10-13〜16、韓国・ソウル) - arXiv: 2509.16293(v4, 2025-10-20)/ url: https://arxiv.org/abs/2509.16293 - 原本 PDF: [[.raw/papers/arxiv-2509.16293.pdf]] - 既存一次ノート(詳細日本語メモ): [[papers/2025__SOSP__Robust LLM Training Infrastructure at ByteDance|papers/ 側ノート]] ## 概要 ByteRobust は ByteDance の本番 GPU クラスタで 1 年以上稼働している LLM 訓練管理システムである。従来の GPU 管理・障害許容システムが Kubernetes pod レベルで動作するのに対し、ByteRobust は LLM 訓練ジョブのマニフェストをきめ細かいプロセス管理まで拡張し、ランタイム情報を活用した障害検知と高速復旧を実現する。最優先の目標は ETTR(Effective Training Time Ratio、生産的な訓練時間と総経過時間=wall-clock の比)の最大化であり、検知・箇所特定・復旧の非生産的時間を最小化する。(Source: 本論文 §1, §3) ## 問題設定 数万 GPU 規模・数か月に及ぶ LLM 事前訓練では障害がほぼ不可避である。Meta は 16,000 GPU 訓練でハードウェア障害が約 2.78 時間に 1 回発生したと報告している。従来の障害診断は fail-stop 後のログ解析・終了コード評価、あるいはクラスタ全体を占有したストレステストに依存し、リモートストレージから数 TB のチェックポイントを再ロードするため、復旧に数時間〜数日を要し ETTR を圧迫する。(Source: 本論文 §1) 本論文が強調する課題は次の通り。 - 明示的障害と暗黙的障害の混在。明示的障害(エラーメッセージや終了コードで障害源を特定できるもの)に対し、ハング・性能ジッタ・想定外の訓練軌道・Silent Data Corruption(SDC、NaN 損失など)といった**暗黙的障害**は明確な信号を欠く。表1 ではハング(Job Hang)だけで全インシデントの 9.9% を占め、暗黙的障害は全体の 10% 超に及ぶ。(Source: 本論文 §1, §2.2, 表1) - 超大規模ゆえの箇所特定の困難。数万 GPU では障害マシンを全交換できるほどの予備機がないため、障害マシンの箇所特定と隔離が安定訓練のクリティカルパスになる。(Source: 本論文 §1) - 多段階構成とコードの継続的進化。LLM 事前訓練は Warmup / General / Enhance / Long Context / (任意)Anneal の各段階(図1)で、アルゴリズムとシステム最適化を変えながら進む。数か月の訓練中、データ・アルゴリズム・エンジニアリングコードが更新され続け、**人的エラーが不可避**となる(表1 ではコード/データ調整による手動再起動が 17.3%)。(Source: 本論文 §1, §2.1, §2.2, 表1) - 同一症状に複数の根本原因。表2 によれば、Job Hang・Illegal memory access・NaN 値はいずれもインフラ障害とユーザコード障害の双方から生じうる(例: Job Hang はインフラ要因 21 件・ユーザコード要因 5 件)。集団通信(collective communication)が SDC を全ワーカへ伝播させ、原因の特定をさらに難しくする。(Source: 本論文 §2.3, 表2) ## 提案手法 ### システム構成(図4) ByteRobust は訓練ジョブの外で動く**コントロールプレーン**と、各訓練 pod 内に常駐する**データプレーン**から成る。 - コントロールプレーン - **Robust Controller**: 自動障害緩和フレームワーク(§4)をオーケストレーションする。マシンを排除しない変更には in-place hot-update を使い、排除が必要なら自己診断済みの warm standby を起動して再開する。 - **Runtime Analyzer**: ジョブハングや性能低下に対し、訓練 pod からスタックトレースを集約して疑わしいマシンを並列グループ単位で(過剰)排除する。 - データプレーン: 各 pod の Robust Agent デーモンが Controller の制御信号を処理し、4 つのサブモジュールを管理する。 - **Monitor**: 多面的データを収集して外れ値を検知し、リアルタイムチェック(§4.1)と異常時の集約解析をトリガする。 - **Diagnoser**: ジョブ停止後にドメイン固有のベンチマーク・テストスイートを走らせ、複雑な障害を深く診断する(§4.2)。 - **On-Demand Tracer**: 訓練プロセスのスタックトレースを取得し Runtime Analyzer に送る。 - **CKPT Manager**: CPU メモリとローカルディスクへ並列グループをまたいだバックアップを伴う非同期チェックポイントを行う(§6.3)。 (Source: 本論文 §3, 図4) ### 設計哲学 - **迅速な隔離を優先し、正確な箇所特定を追わない**。軽量リアルタイム検知と階層的停止時診断を組み合わせて最小オーバーヘッドで障害マシンを絞り込み、足りなければランタイムスタックトレースのデータ駆動クラスタリングで並列グループ単位に過剰排除する。 - **人的エラーを設計に織り込む**。自動障害許容フレームワークがマシン障害の検知・診断とコードロールバックを統合し、頻発する障害を利用してユーザコード変更を lazy update でまとめて適用する。 - **迅速な復旧中の変動を抑える**。マシン割り当てを変えない変更は in-place hot-update で実行し、排除時は自己チェック済みの warm standby を使い、チェックポイントは障害ドメインをまたいで分散させてリモート取得依存を排除する。 (Source: 本論文 §1) ### 自動障害許容(§4、図5) リアルタイムチェック・停止時診断・in-place 再試行・コードロールバック・リプレイテストを組み合わせる。 - **能動的リアルタイムチェック(§4.1)**: Monitor が秒単位の軽量ヘルスチェック(NIC、GPU の DCGM/PCIe/温度、OS カーネルイベント等)を行い、wandb で loss・gradient norm・MFU 等を継続観測する。RDMA トラフィックや TensorCore 利用率の急減はハング・MFU 低下の信号とみなす。確信度の高い事象(GPU Unavailable, Disk Fault)は即座に排除し、ネットワーク事象は自己回復を見越して数回の警告を許容する。 - **階層的停止時チェック(§4.2)**: Diagnoser がログ・終了コードを解析し、NCCL Internal Error なら EUD → 機内 all-to-all → 機間 all-gather と段階的にテストする。テスト全通過なら一過性障害とみなし再試行(Reattempt)、失敗を繰り返せばユーザコードのロールバックを行い、なお失敗すれば Dual-Phase Replay へ進む。 - **教訓(Lesson)**: 9,600 GPU 以上の 19 ジョブの経験では、リアルタイムチェックによる直接排除が障害の 32.52%、再試行が 22.70%、ロールバックが 9.20% を解決し、Dual-Phase Replay を要したのはわずか 1.23% であった。単純な手法で大半のインシデントが片付く。(Source: 本論文 §4, §4.2) ### Dual-Phase Replay(Algorithm 1、図6) SDC など原因不明の障害には、TP/PP サイズを固定し DP サイズだけを変えて次元を意識したリプレイを行う。水平グルーピングと垂直グルーピングの 2 段で障害グループを特定し、その交差で障害マシンを一意に絞り込む(m=k·PP_size, n=DP_size/k, m≤n)。図6 の例では 2 回のリプレイで SDC マシン #13 を正しく隔離できる。各 SDC は通常 1 台のマシンに起因する。(Source: 本論文 §4.2, Algorithm 1) ### データ駆動型過剰排除(§5、図7) ハングや MFU 低下のように追跡情報が残らない暗黙的障害には、全訓練プロセスのスタックトレースを集約する 3 段手順を用いる。(1) 各 pod のプロセスツリーを解析、(2) スタックトレースを文字列照合でグループ化し、支配的なグループを正常・残りを外れ値とみなす、(3) 外れ値が共有する並列グループ(例: 1 つの PP グループ)を特定し、そのマシンを過剰排除する。fail-slow(MFU 低下)では 10 秒ごとに集約を繰り返し、5 ラウンドで最も外れ値の多い並列グループを degrader として排除する。(Source: 本論文 §5, §5.1, 図7) ### 制御された迅速な復旧(§6) - **In-Place Hot-Update(§6.1)**: コード/データ調整時に既存 pod 環境を壊さず lazy にコードを差し替える。緊急のバグ修正は即時停止して適用、非緊急の変更は次の障害時または既定ウィンドウ(例: 24 時間)で適用する。全変更は DB に永続化して追跡・再現可能にする。 - **Warm Standby マシン(§6.2)**: 自己チェック済みの予備機プールを維持し、障害は独立に起こるという観測のもと予備機数を二項分布の P99 に設定する。排除時に予備機が足りれば即起動、足りなければ不足分のみ補充する。障害時に変わるマシンが最小限で済む。 - **過剰排除を見越したチェックポイント(§6.3、図8・図9)**: ホスト CPU メモリと SSD の階層チェックポイントを採り、ZeRO スタイル並列の各ステップの通信アイドル時間を使って P2P でシャードをピアにバックアップする。3D 並列の各 rank は自身の TP/PP/DP グループ外のマシンへ optimizer 状態をバックアップする(cross parallel group backup)。これによりリモートストレージ依存を排し、過剰排除でも可用性を保つ。(Source: 本論文 §6) ### 実装(§7) Robust Controller は Golang 約 20k 行(Kubernetes CRD でジョブ操作を表現、etcd を内製メタデータシステムに置換)、Robust Agent は Python 約 5k 行(gRPC ハートビート)、Runtime Analyzer は Golang 約 12k 行(イベント駆動、On-Demand Tracer は py-spy と flight-recorder で実装)。(Source: 本論文 §7) ### ETTR の定義 $\text{ETTR} = \frac{\text{生産的な訓練時間}}{\text{ジョブの総経過時間(wall-clock)}}$ 長時間ジョブでは累積 ETTR が時間的動態を覆い隠すため、1 時間窓の sliding-window ETTR も導入する。(Source: 本論文 §1, §8.1.3) ## 新規性 - LLM 訓練の独自性(多段階構成、継続的なコード進化、人的エラー)を明示的に設計へ組み込んだ点。従来の DL 訓練ジョブが単一固定構成・不変コードを前提とするのと対照的。(Source: 本論文 §1, §2.1) - [[MegaScale]] との差異: MegaScale は周期的ハートビートと RDMA メトリクス監視で障害を検知し軽量な停止時チェックを行うが、RDMA トラフィック異常を検知しても疑わしいマシンを自動隔離できず手動調査を要する。ByteRobust はランタイムスタッククラスタリングと粗粒度隔離で gray failure を迅速に緩和する。(Source: 本論文 §1, §10) - TRANSOM ほか先行の障害許容システムとの差異: Hu et al. の手法は LLM ベースのログエージェントと規則ヒューリスティクスで停止時診断の精度を上げるが、ログに依存しランタイム情報を活かさない。Bamboo・Oobleck・Parcae 等の弾力的訓練は特定の並列化戦略に縛られるが、ByteRobust は広範な並列化戦略を支える。さらに ByteRobust は over-eviction を見越した新しいバックアップ戦略を提案する。(Source: 本論文 §10) ## 実験設定 - 本番展開評価(§8.1): 最大 1,200 マシン、各 8 台の NVIDIA Hopper 80GB GPU。本番事前訓練ジョブ 2 件(密モデル Llama 系 70B+ の 3 か月ジョブ、MoE モデル 200B+ の 1 か月ジョブ)を 9,600 Hopper GPU クラスタで収集。(Source: 本論文 §8, §8.1) - ベースライン比較(§8.2): 1,024 マシン、各 16 台の NVIDIA L20 48GB GPU(計 16,384 GPU 超)。全マシンは 8 本の 400 Gbps RDMA リンクで相互接続、96 コア Intel Xeon と 2 TB DRAM を搭載。(Source: 本論文 §8 Testbed) - 評価指標: 障害検知時間、ETTR(累積・sliding-window)、MFU、各機構による解決インシデントの分布。(Source: 本論文 §8) ## 実験結果 - **検知時間の短縮(§8.1.1、表3)**: ネットワーク障害(NIC crash, Port Flapping)は inspection 有りで 30 秒、Switch Down は 30×2 秒で検知。inspection 無しではいずれも PyTorch-Distributed の既定タイムアウト($T_{timeout}$、約 10 分)に頼ることになる。GPU 高温は 10 秒で検知し MFU 低下と相関づけ、gray failure を確認する。(Source: 本論文 §8.1.1, 表3) - **インシデント解決の分布(§8.1.2、表4)**: 明示的障害の大半は自動マシン排除+再起動(AutoFT-ER)で解決し、密ジョブ 73.1%・MoE ジョブ 56.8% を占めた。暗黙的障害(ハング・MFU 低下)は Analyzer の過剰排除で 24 件を人手なしに解決。コード/データ調整の手動再起動はすべて hot-update が処理した。(Source: 本論文 §8.1.2, 表4) - **性能保証(§8.1.3、図10・11)**: 累積 ETTR を最大 97% の高原状態に保ち、非生産的訓練時間は両ジョブとも最大 50 分に収めた。MFU は hot-update でより効率的なコードを順次展開した結果、密ジョブで 1.25×、MoE ジョブで 1.58× 向上した。MoE は密モデルよりコミュニティ最適化が進んでおらず ETTR がやや低い。(Source: 本論文 §8.1.3, 図10, 図11) - **先行手法との比較(§8.1.4、表6)**: selective stress testing に対し全症状で平均解決時間を短縮し、CUDA エラーで最大 84.50% 削減。人的ミス起因の症状ではベースラインのストレステストが箇所特定に失敗する(INF)一方、ロールバックが特定・復旧する。(Source: 本論文 §8.1.4, 表6) - **再起動の高速化(§8.2.1、表7・図12)**: hot-update は full requeue 比 11.04× 高速。warm standby は requeue 比 10.87×、reschedule 比 5.36× 復旧を短縮し、oracle 上限の 5.19% 以内に収まる。requeue は規模拡大で再起動時間が顕著に増えるが、warm standby と hot-update のオーバーヘッドは一定で低い。(Source: 本論文 §8.2.1, 表7, 図12) - **ほぼゼロオーバーヘッドのチェックポイント(§8.2.2、表8)**: ByteRobust save は Megatron save・Memory save 比でブロッキング時間をそれぞれ 99.69%・95.10% 削減し、MFU 損失を 0.71% に抑える(毎イテレーション保存時)。(Source: 本論文 §8.2.2, 表8) - **本番実績(§1)**: 3 か月間に明示的障害 38,236 件・暗黙的障害 5,948 件を自動処理。インフラ障害は件数 11% で GPU 時間の 82% を占める。(Source: 本論文 §1, §2.2) ## 考察 ByteRobust の核心は、超大規模・長期間という LLM 訓練の条件下で「正確さよりも速さ」を選ぶ割り切りにある。原因の精密な特定を諦め、並列グループ単位の過剰排除と warm standby による即時置換で ETTR を稼ぐ。これは、障害が独立かつ単一マシンに起因しやすいという経験的観測(各 SDC は通常 1 台)と、予備機を全交換できない規模制約の双方に裏打ちされている。人的エラーを「不可避な障害源」として lazy hot-update に取り込み、頻発する中断そのものをコード更新の適用機会に変える設計も、数か月スパンの LLM 訓練に固有の発想である。(Source: 本論文 §1, §4, §6) ## 強み - 9,600 GPU・3 か月という本番規模での 97% ETTR という具体的かつ説得力ある成果。1 年以上の実運用に裏打ちされた経験知(表1・表2 の大規模インシデント統計)。(Source: 本論文 Abstract, §2.2) - 明示的障害だけでなく、ハング・MFU 低下・SDC といった暗黙的障害(gray failure)に対する具体的機構(スタックトレース集約、Dual-Phase Replay、ビット単位整合テスト)を備える。(Source: 本論文 §4.2, §5) - 復旧経路(リアルタイム排除→再試行→ロールバック→Dual-Phase Replay)が解決率で定量化され、単純策が大半を占めることを実証。(Source: 本論文 §4.2) ## 弱点・課題 - **未成熟な診断ツール**: GPU ハードウェアの進化に監視・診断ツールが追いつかず、診断ツール自体が新たな障害を生むことがある(EUD が周波数ロックを解除し GPU の意図せぬダウンクロックを招いた例)。(Source: 本論文 §9) - **偽陽性(false positive)**: 診断ツールの不完全性と、迅速化のために PP グループ全体を意図的に過剰排除すること(9,600 GPU ジョブで 1 グループ 8 マシン)に由来し、通常 1〜2 台しか故障していなくても 6〜7 台の偽陽性が出る。早期隔離による復旧短縮との引き換えで許容している。(Source: 本論文 §9) - **SDC の根深さ**: NVIDIA EUD の recall は 70% にとどまる。自作の MiniGPT 検証スイートと Dual-Phase Replay で補うが、いずれもオーバーヘッドが大きく、規模拡大とともに SDC の頻度と影響が増し、LLM 訓練のスケーラビリティを制限する。(Source: 本論文 §9, §10) ## 関連 - ソース原本: [[.raw/papers/arxiv-2509.16293.pdf]] - 既存一次ノート: [[papers/2025__SOSP__Robust LLM Training Infrastructure at ByteDance|papers/ 側の詳細メモ]] - エンティティ: [[ByteRobust]] / [[ByteDance]] / [[MegaScale]] / [[Chuan Wu]] / [[Liang Xiang]] / [[The University of Hong Kong]] - 概念: [[LLM分散学習]] / [[LLM学習モニタリング]] / [[並列化戦略]] / [[GPUクラスタ運用]] / [[Mixture-of-Experts]] / [[Fault Localization]] / [[障害緩和]]