> [!abstract] 概要(arXiv abstract の日本語訳) > 大規模訓練システムは典型的に同期訓練を用い、全 GPU が同時に健全であることを要求する。O(100K) GPU での訓練経験から、頻発する障害と長い復旧時間により、同期訓練は低い効率に陥ることが分かった。 > この問題に対処するため、我々は新しい訓練パラダイム、Fault Tolerant Hybrid-Shared Data Parallelism(FT-HSDP)を提案する。FT-HSDP はデータ並列レプリカを耐障害性の単位として用いる。障害が発生すると、障害のある GPU またはサーバを含む単一のデータ並列レプリカのみがオフラインにされ再起動され、他のレプリカは訓練を継続する。この着想を大規模に実現するため、FT-HSDP はいくつかの技術を組み込む: 1) データ並列レプリカ間の勾配交換のための Fault Tolerant All Reduce(FTAR)プロトコルを導入する。FTAR は、参加者を動的に追加・削除するといった複雑な制御ロジックを駆動するために CPU に依存し、最良の性能のためにデータ転送を実行するために GPU に依存する。2) 復旧中のレプリカが最小限のスタールで訓練に参加できるようにする、非ブロッキングな catch-up プロトコルを導入する。 > O(100K) GPU における完全同期訓練と比較して、FT-HSDP は障害復旧によるスタール時間を 10 分から 3 分へ削減し、有効訓練時間を 44% から 80% へ引き上げることができる。さらに、FT-HSDP の非同期復旧が、結果モデルの精度に意味のある劣化をもたらさないことを実証する。 ## 論文情報 - タイトル: Training LLMs with Fault Tolerant HSDP on 100,000 GPUs - 著者: Omkar Salpekar¹、Rohan Varma¹、Kenny Yu²、Vladimir Ivanov¹、Yang Wang¹ ³、Ahmed Sharif¹、Min Si¹、Shawn Xu¹、Feng Tian¹、Shengbao Zheng¹、Tristan Rice¹、Ankush Garg¹、Shangfu Peng¹、Shreyas Siravara¹、Wenyin Fu¹、Rodrigo de Castro¹、Adithya Gangidi¹、Andrey Obraztsov¹、Sharan Narang¹、Sergey Edunov⁴、Maxim Naumov¹、Chunqiang Tang¹、Mathew Oldham¹ - 所属: ¹[[Meta|Meta Platforms]]、²Thinking Machines Labs、³[[The Ohio State University]]、⁴Genesis Molecular AI - 媒体・発表年: arXiv プレプリント、2026 年 - arXiv ID: 2602.00277v1 [cs.DC](投稿日 2026-01-30) ## 概要 本論文は、10 万 GPU 規模の LLM 事前学習において完全同期訓練が抱える障害・復旧コスト問題を実測に基づいて定量化し、データ並列レプリカを耐障害性の単位とする新しい訓練パラダイム FT-HSDP(Fault Tolerant Hybrid-Shared Data Parallelism)を提案する。障害発生時に問題のあるレプリカのみを切り離して再構築し、他のレプリカは訓練を継続するという非同期復旧を、CPU-GPU ハイブリッド設計の Fault Tolerant All Reduce(FTAR)プロトコルと非ブロッキング catch-up プロトコルによって実現し、98K GPU の実クラスタで有効訓練時間を 44% から 80% へ引き上げたと報告する。 ## 問題設定 入力は 70B〜900B のアクティブパラメータを持つ大規模言語モデルを O(trillions) トークン、10 万 GPU 規模のクラスタで訓練するシナリオである。前提として、クラスタは複数のデータセンター(DC)建屋にまたがる 3 層 Clos ネットワークで構築され、GPU 間通信レイテンシはネットワークホップ数に応じて増大する(同一ラック最小、異なる AI Zone・異なる DC 建屋では段階的に増大)。完全同期訓練では、1 台の GPU またはサーバが故障すると全メンバーが直近のチェックポイントから再起動する必要があり、集団通信ライブラリ(NCCL)は初期化時に全メンバーが既知であることを要求し動的な再構成をサポートしないため、通信コネクションの再初期化を伴う長いスタールが大規模で発生する。 ## 提案手法 ### アーキテクチャ **FT-HSDP の全体構成(図3)**: [[HSDP|Hybrid-Shared Data Parallelism]] の発想に従い、複数のレプリカを作成する。各レプリカは訓練データの部分集合を担当し、データ並列・テンソル並列・パイプライン並列・エキスパート並列・コンテキスト並列を組み合わせた数千 GPU で構成される。各 GPU はレプリカ内での位置に応じた一意のランク番号を持ち、固定量のデータ(バッチ)を訓練したのち、異なるレプリカの同一ランクの GPU 群が勾配を交換してその総和を計算し、各ランクのオプティマイザが勾配を適用してモデル重みを更新する。この複製構造は耐障害性に 2 つの利点をもたらす: (1) 障害発生時は、障害 GPU を含むレプリカのみを再構築すればよく復旧規模と復旧時間を縮小できる、(2) 障害レプリカの復旧中も他のレプリカは訓練を継続できる(非同期復旧)。 **Figure 3: FT-HSDP のアーキテクチャ** ![[_attachments/arxiv-2602.00277/fig03-hsdp-architecture.png]] (Figure 3. 4 つのレプリカ(Replica 0〜3)がそれぞれモデル/オプティマイザ状態をランク間でシャードして保持し(Rank 0〜Rank 8191)、レプリカをまたいで一致するランク同士が独立した AllReduce リングを形成して勾配の該当部分を交換する。Source: 本論文 Figure 3。) **Rank 0(レプリカリーダー)の設計(図4)**: レプリカ内の複数ストリームで前向き・後退計算/通信を行うのに加え、勾配交換(FTAR)用のレプリカ間ストリームを 1 本持つ。メインスレッドがオプティマイザステップ(OPT)を実行する。FT-HSDP は FTAR を後退計算とオーバーラップさせて訓練速度を向上させる。レプリカリーダーの Rank 0 は追加の制御ロジックを実行する: (1) CPU スレッドが、Chubby・Delos に類似したコンセンサスサービスを通じて他レプリカの Rank 0 と協調し健全なレプリカを判定する、(2) Rank 0 のメイン GPU スレッドが、レプリカ内の他ランクに勾配交換の完了有無を確認し、全員完了していればオプティマイザステップへ進める。 **Figure 4: Rank 0(リーダー)の設計** ![[_attachments/arxiv-2602.00277/fig04-rank0-design.png]] (Figure 4. CPU 側の main thread が Forward → should_commit → OPT を、bwd thread が Backward を実行する一方、CPU side thread は get_quorum → FTAR Bcast を担う。GPU 側では Inter-replica FTAR stream が FTAR_0・FTAR_1…を実行して他ランクの FTAR 完了を確認し、Intra-replica coordination stream が NCCL AllReduce を、Intra-replica training streams が Forward/Backward の計算・通信を担う。Source: 本論文 Figure 4。) ### ネットワークアーキテクチャ DC 内は 3 層 Clos 構成を採用する(図1a): Rack Training Switch(RTSW)がラック内 GPU を接続し、Cluster Training Switch(CTSW)が AI Zone 内の全ラックを接続し、Aggregator Training Switch(ATSW)が DC 内の CTSW を接続して RoCE ネットワークを単一 AI Zone の外へ拡張する。AI Zone 間の over-subscription 比は 1:2.8。複数 DC の相互接続は、各 DC 建屋の ATSW 層間をフルメッシュで結合する構成を取り(図1b)、DC 間トラフィックも AI Zone 間トラフィックと同じ 1:2.8 の over-subscription 比を経験する。 **Figure 1: 訓練クラスタのネットワークアーキテクチャ** ![[_attachments/arxiv-2602.00277/fig01a-network-topology-dc.png]] (Figure 1(a). DC 建屋内の 3 層 Clos:RTSW(ラック内、Host と 8×400G で接続)→ CTSW(AI Zone 内、400G で RTSW と接続)→ ATSW(AI Zone をまたいで CTSW を接続)。各 DC は複数の AI Zone に分割される。Source: 本論文 Figure 1(a)。) ![[_attachments/arxiv-2602.00277/fig01b-network-topology-multidc.png]] (Figure 1(b). 複数 DC 建屋にまたがるネットワークアーキテクチャ:各建屋の ATSW Layer 同士がフルメッシュ(ATSW Mesh)で接続され、DC を段階的に追加してスケールできる。Source: 本論文 Figure 1(b)。) このトポロジでは、同一ラック内の GPU 間通信が最も低レイテンシであるのに対し、同一 AI Zone 内の異なるラック・異なる AI Zone・異なる DC 建屋の GPU 間通信はそれぞれ 7 倍・15 倍・30 倍高いレイテンシを経験する。この特性が複製データ並列設計を動機づける: FT-HSDP は 1 レプリカの全 GPU を単一の AI Zone または DC に配置し、レイテンシに敏感なレプリカ内集団通信が DC 間リンクを跨がないようにする一方、異なるレプリカは異なる DC に配置する(レプリカ間のデータ並列集団通信の方が高レイテンシに対する耐性が高いため)。 ### アルゴリズム/手法の詳細 **障害検知**: シンプルさを優先し、タイムアウトベースで障害 GPU を検知する。1 ステップの訓練が平均約 20 秒であることから、経験的にタイムアウト間隔を 60 秒に設定している。将来的には §2.3 の高速根本原因分析コンポーネントと統合しスタール時間をさらに縮める計画である。 **障害後の一貫性確保**: 完全同期訓練システムは全 GPU を最新チェックポイントから再起動することで一貫性を達成するが、FT-HSDP では GPU 障害時に他レプリカが一貫状態にない可能性がある(例: あるレプリカの Rank 0 が別レプリカの Rank 0 との勾配交換を完了した直後に故障すると、レプリカ内・レプリカ間の双方で不整合が生じうる)。全レプリカに障害ステップの再訓練を求める単純解は、既に勾配交換を完了したレプリカにとって資源の浪費になる。より効率的な解として、FT-HSDP はレプリカ内の一貫性は必要とする一方、レプリカ間の一貫性は非同期復旧のサポートにより不要と位置づける。障害検知後、レプリカ内の GPU 群は 2 相コミット(2PC)に似たプロトコルを実行する: Rank 0 がレプリカ内の全ランクに勾配交換完了の有無を尋ね、全員が完了と回答すればオプティマイザステップへ進み次ステップへ移る。そうでなければ Rank 0 は全ランクにステップの再試行を指示する(この場合まだモデル重みは未更新のため、他ランクから重みを取得し直す必要はなく単に勾配を破棄すればよい)。各レプリカが独立に判断するため、レプリカ間で異なる状況に陥りうる(例: レプリカ 1 はステップ 100 へ進むが、レプリカ 2・3 はステップ 99 を再訓練する)。この場合、レプリカ 2・3 が復旧プロトコルを起動する。 **FTAR(Fault Tolerant All Reduce)**: FT-HSDP はレプリカ内通信には性能面で優れる NCCL を用いるが、レプリカ間の勾配交換には独自の FTAR プロトコルを導入する。NCCL では以下の目標を同時に達成できないためである: (1) ネットワーク認識アーキテクチャ(FTAR は DC 間を跨ぐ必要があり NVLink ドメイン内通信を伴えない。DC 間帯域は over-subscribe されているため輻輳制御を考慮した高速性が必要)、(2) 再構築可能な通信グループ(障害発生時、健全なランク上で FTAR グループを再構築し、既存の陳腐化した転送資源を破棄して新しいピア群との転送接続を再確立する必要がある)、(3) 容易な障害管理(FTAR は障害が回復可能か致命的かを検知できる必要がある。回復可能な場合〈例: 死んだピアによるネットワークリモートエラー〉は FT-HSDP へエラーを報告し死んだピアを除去させ、致命的な場合〈例: 不良 NIC〉は FTAR が FT-HSDP にランクの kill を指示する)、(4) 並行する計算カーネルへの資源競合の最小化(FTAR は後退計算とオーバーラップするため、並行計算カーネルへの GPU 資源競合を最小化する必要がある)。これらは伝統的な CPU ベースプロトコルでは難しくないが、NCCL は GPU 駆動の通信であり、GPU は複雑な制御ロジック(エラー種別ごとの処理・動的なコネクション再構築・輻輳制御等)を実装する CPU の能力を欠く。そこで FT-HSDP は CPU が全体プロセスを駆動するハイブリッド設計を採る。 **CPU-GPU インタラクション(図5)**: FT-HSDP のメイン CPU スレッドは、送受信バッファ等を作成して RDMA コネクションを初期化する。また FTAR グループに参加するランクを決定する reconfig 関数を実行する。その後、GPU ストリームと CPU asyncThread を起動して FTAR を実行する: GPU ストリームが送信バッファへデータをコピーし CPU asyncThread へ通知する。CPU asyncThread は RDMA 経由で送信バッファのデータをリモート GPU ランクへ送るよう GPU に指示し、他ランクからのデータも待ち受ける。データが到着すると asyncThread が GPU ストリームへ通知し、GPU ストリームが受信バッファに対して reduce 関数を実行する。FT-HSDP は輻輳制御の目的で、勾配の一部分ずつを交換する複数回の FTAR イテレーションを実行しうる。この設計は制御プレーンに CPU を用いる(コネクションの維持・破棄・作成、コンセンサスサービスによるピア決定、輻輳制御のためのフライト中データ量の制限、エラー種別に応じた対応判断)一方、データプレーンには GPU を用いる(性能最大化のための全データ転送)。 **リングアルゴリズムとパイプライン**: FTAR の参加 GPU は AI Zone・DC 建屋をまたいで分散する可能性が高く、Zone/建屋間スイッチは高い over-subscription 比・限られた bisection 帯域を持つため、Zone/建屋をまたぐネットワーク輻輳を避ける必要がある。FTAR は 200MB〜500MB のメッセージサイズ、最大 16 ランク程度に最適化されるべきと見積もり、帯域最適アルゴリズムを好む条件に合致することから、各 GPU がリング内の隣接 2 台とのみ送受信するリングアルゴリズムを採用する。ReduceScatter フェーズと AllGather フェーズ(各 N-1 ステップ、N はリング内 GPU 数=レプリカ数)から成る。固定サイズチャンク(サイズ S × チャンク数 C)に基づくパイプラインプロトコルを設計し、FTAR リソース初期化時に各 GPU 上に内部送受信バッファを事前確保して RDMA 転送用に事前登録する。N ランクの FTAR グループでは、データは各パーティション最大 S×C×N バイトに分割され、各パーティション内で FTAR は 2N-2 ステップの 1 ラウンドのリングアルゴリズムを完了し C チャンクでパイプライン化する。この設計は、(1) 任意の 2 ピア間の同時データパケット量を最大 S×C バイトに制御し、(2) コピー/リデュースカーネル操作とネットワーク転送操作を個別にチューニングできる柔軟性を提供する(スレッドブロック数でコピー/リデュースのスループットを、Queue Pair 数などトランスポート固有ハイパーパラメータでネットワーク転送のスループットをそれぞれ調整可能)。 **Figure 5: FTAR プロトコルの詳細**は、CPU の init/reconfig/run と GPU stream の copyToSendBuf/reduceFromRecvBuf、CPU asyncThread の sync/transSend/transWaitRecv/terminate の相互作用を示す(本論文 Figure 5、ベクター図のため本ページには埋め込んでいない。詳細はテキスト本文を参照)。 ### 実装上の工夫 - **カーネル最適化**: ReduceScatter フェーズの最終ステップ(N-1)は結果をローカルデータバッファと送信バッファの両方に格納する処理を統合し、CPU-カーネル同期を 1 ラウンド削減するとともに、結果がレジスタに残っている段階で HBM ロードを回避する。CUDA カーネルはホストピン留めメモリ上のフラグをビジーポーリングして CPU からの通信完了シグナルを待つ(NCCL 等の通信ライブラリで一般的な手法)。GPU 資源の浪費を最小化するため少数の Streaming Multiprocessor(SM)でカーネルを起動する(例: H100 の 132 SM のうち NCCL AllReduce は 4 SM のみ使用)。低占有率で高いメモリバス利用率・性能を得るため、スレッド当たり複数のロード/ストア・リデュース命令を発行する命令レベル並列性を活用し、これに伴うレジスタ使用量増加は、不要なアルゴリズムコンテキスト情報の除去・コンパイル時 constexpr 式による事前計算・ブロックサイズ縮小で抑える。最終的に FTAR は 2 スレッドブロック(SM)・ブロック当たり 512 スレッド・8MB チャンクサイズで、リデュース処理を並行ネットワーク転送の背後に完全に隠蔽し、native NCCL AllReduce(4 SM)より少ない GPU 計算資源(2 SM)で動作する。AllReduce は既にネットワークバウンドであるため、これ以上コピー/リデュースオーバーヘッドを削っても得はなく、逆に多くの SM を使うと他の計算カーネルの性能を大きく劣化させうる。 - **タイムアウトとエラー処理**: GPU ストリームがピアからのデータ/シグナル待ちをする際、GPU がハングしないよう while ループでフラグをタイムアウト付きでチェックする。エラーは回復可能エラー(タイムアウト・ncclRemoteError 等のネットワークエラー)と回復不能エラー(ncclSystemError・ncclInvalidArgument 等、通常バグやハードウェア故障を示す)に分類し、前者は FT-HSDP へリトライ可能ワークとして返しキューイング済み GPU 操作を終了/キャンセルしてスキップとマークする一方、後者は即座に FTAR をクラッシュさせる(リトライは時間の浪費のため)。 - **非ブロッキング Catch-up プロトコル**: レプリカが復旧などの理由で他レプリカに遅れる場合、伝統的な複製システムでは他レプリカを stall/減速させて追いつかせる必要がある。FT-HSDP は各ステップ開始時にコンセンサスサービス経由で各レプリカが次に実行するステップ番号を報告し、最大のステップ番号 n を報告したレプリカ群を健全とみなしてステップ n を訓練させ、それ以外のレプリカはステップ n-1 終了時点のチェックポイントを健全レプリカから取得する。ステップ終了時、健全レプリカは通常どおり勾配を送信し、遅れているレプリカはゼロ勾配を送信する。FTAR(勾配交換プロトコル)がこれを通じて全レプリカを自動的に同一状態へ揃える。 **Figure 6: 非ブロッキング catch-up の例** ![[_attachments/arxiv-2602.00277/fig06-nonblocking-catchup.png]] (Figure 6. Replica 0〜2 がステップ 99 完了時点で「ステップ100を訓練する」と報告するのに対し、復旧中の Replica 3 は「ステップ96まで」しか報告できない。get_quorum() で最大値 100 が判明すると、Replica 0〜2 はステップ100の訓練を継続し、Replica 3 はステップ99終端のチェックポイントによるピア復旧(peer recovery @ 99)を選ぶ。ステップ終端で FTAR に Replica 3 はゼロ勾配(∅)を送り、全レプリカがステップ101から揃って再開する。Source: 本論文 Figure 6。) これが可能な理由は 2 つの訓練特有の性質による: (1) 全レプリカが同一チェックポイントを共有している限り、訓練作業を行わなかったレプリカもゼロ勾配を送るだけで訓練を行ったレプリカと同一状態に到達できる(一般的な複製システムでは遅れたレプリカが実際にタスクを実行する必要がある)、(2) 効率的なチェックポイント復旧機構(§4.4)により、チェックポイント取得は通常 1 ステップより短時間で完了するため、健全レプリカが遅れたレプリカを待つ必要がない(取得がステップより遅い稀なケースではブロッキングが発生する)。 **チェックポイント取得(図7)**: 通常時、GPU は 100 ステップごとに状態(モデル状態・オプティマイザ状態・データローダ状態)を永続ストレージへ書き込む。モデル状態とオプティマイザ状態はレプリカ間で複製されているため、1 レプリカのみが永続ストレージへ書き込めばよい。データローダ状態(訓練対象データの位置を示す)は複製されないがサイズが小さいため、FT-HSDP は全 GPU のデータローダ状態を単一の loader_state ファイルへ毎ステップ書き込む。永続チェックポイントは全システム再起動に用いられる一方、catch-up プロトコル実行中は、復旧レプリカが健全レプリカから直接状態を取得し、最新ステップに対応する状態を取得できる。状態は複製されているため復旧レプリカは 1 台からのみ取得すればよく、FT-HSDP は永続チェックポイントの場合と同様に負荷分散された方法で取得を組織化する。この過程で健全な GPU は自らの状態を CPU メモリへ書き込み、復旧中の GPU が HTTP プロトコル経由でその状態を取得する(GPU の高速ネットワークを介した前向き・後退通信とは競合しない)。復旧レプリカは前述の loader_state ファイルからデータローダ状態を復元する。この処理は「あるGPUが状態を書き込んでいる間に別のGPUがそれを取得しても状態が変化しない」ことを前提とするが、これはオプティマイザステップ前であれば成立する(一般の分散システムでは Copy-on-Write のような複雑な技法が必要になりうる)。 **Figure 7: チェックポイント取得** ![[_attachments/arxiv-2602.00277/fig07-checkpoint-fetching.png]] (Figure 7. 健全レプリカの GPU が状態を CPU メモリへ書き込み、復旧中の GPU が HTTP 経由で負荷分散的に取得する様子を示す。Source: 本論文 Figure 7。) **バッチの厳密な一回訓練**: ML 専門家が定めた基準として、FT-HSDP は訓練データをスキップしたり同じバッチを複数回訓練したりしてはならない。この基準に従い、障害レプリカは loader_state ファイルの助けを借りて障害発生地点から正確に再開する。この戦略は末尾でのストラグラー発生を招きうるが、1 レプリカが恒常的に他より多く障害を起こす場合(稀)以外は深刻な問題にならないとしている。バッチの再シャッフルのようなより洗練された戦略も可能だが未実装。 **メモリ圧力の低減**: 耐障害性のためには多数の小さなレプリカを持つ方が 1 障害当たりの訓練能力損失が小さいが、各レプリカが全状態を保持する必要があるためメモリ圧力が生じる。対策は 2 つ: (1) レプリカ数を実験的に探索し 10〜20 レプリカに落ち着いた、(2) オプティマイザ状態を GPU メモリから CPU メモリへオフロードし必要時に GPU が取得する仕組みを実装した(実測で 1GB のオプティマイザ状態を CPU メモリから取得するのに約 60ms)。 **ファーストステップ影響の低減**: 復旧後の最初のステップはチェックポインタ再作成・データローダ初期化などの時間のかかる初期化処理を伴うため、復旧レプリカが健全レプリカより遅くなりスタールを招く。対策として、可能な限り FT-HSDP へのチェックイン前にこれらの初期化関数を復旧レプリカに実行させる(例外は最初のバッチのロードで、これはチェックインと最初の FTAR の間に行う必要がある)。結果として、ファーストステップ影響は低減されるが完全には排除されない(§6 参照)。 **CPU による大規模エミュレーション**: 100K GPU での定期的なテストは非現実的であるため、CPU 資源を用いて大規模訓練をエミュレートするツールを構築した。GPU 対象のデフォルトモジュールを CPU ベースのモックモジュールへ透過的に置き換える shadow module loading 機構を実装し、多くの計算では実計算をスキップしテンソル形状情報のみを高レベル訓練ループの論理ステップに渡す。ネットワーク通信は、NCCL コードパスの代わりにカスタム CPU ベースの基本通信ライブラリを使う。GPU 関連コードの問題は見つけられないが、データローディングパイプラインや前処理関数など CPU のみで動くコンポーネントの問題発見、およびジョブスケジューリング・ストレージ・テレメトリ配信・ロギング等の外部サービステストに有用であった。例として、コンセンサスプロトコル get_quorum の初期実装をこのツールでテストしたところ 100K 規模でレイテンシ 9 秒という重大なオーバーヘッドが報告され、反復的な修正により 700ms まで低減した。実際の GPU クラスタが準備できてテストした際も同じレイテンシを示し、エミュレーションの精度を裏付けた。 ## 実験設定 - **ハードウェア/規模**: 98K H100 GPU、12 レプリカ、4 データセンター建屋にまたがる構成、§2.1 のネットワークトポロジ。各レプリカは数兆パラメータの密トランスフォーマーモデルを 8192 GPU で訓練し、フルシャード型データ並列・非同期テンソル並列・コンテキスト並列・カスタムパイプライン並列スケジュールをテキスト+画像トークンの混合で組み合わせる。 - **精度実験**: 256 H100 GPU、3B アクティブパラメータ・16 エキスパートの MoE モデル、500B 多様テキストトークンの訓練セット。評価は分類的損失関数(次トークン予測の負の対数尤度)と、訓練データに含まれないコーディング・推論・数学・一般テキストの 4 つの外部評価セット。 - **FTAR マイクロベンチマーク**: 異なる AI Zone に GPU を配置し、異なるサイズのメッセージを転送。100 回実行の平均。 - **比較対象**: 完全同期訓練(復旧に伴う 10 分のスタール)を主なベースラインとする。FTAR は native NCCL AllReduce と比較する。 ## 実験結果 ### 32K GPU 本番データにおける障害内訳(§2.2) 32K GPU 規模の反復的な訓練ジョブは 95〜97% の有効訓練時間を達成し、平均で 1,000 サーバ当たり 1 日 2.3 件の中断を経験した。以下は Table 1 の全行をそのまま転記したものである。 | Component | Count | % | |---|---:|---:| | GPU HBM3 Memory | 155 | 22.9% | | PCIe Device | 122 | 18.0% | | NCCL Watchdog Timeouts | 61 | 9.0% | | Faulty GPU Compute | 50 | 7.4% | | Software Bug | 48 | 7.1% | | Host Maintenance | 42 | 6.2% | | Kernel Fault | 39 | 5.8% | | System Reboot | 38 | 5.6% | | Numerics/Silent Data Corruption | 37 | 5.5% | | **Network Switch/Cable** | **36** | **5.3%** | | SSD | 30 | 4.4% | | GPU SRAM Memory | 8 | 1.2% | | Unknown | 7 | 1.0% | | System Memory | 2 | 0.3% | | System Cooling | 2 | 0.3% | | GPU Thermal Interface + Sensor | 1 | 0.2% | (Table 1: Classification of unexpected interruptions during LLM pre-training on 32K GPUs.) **検算**: 件数の合計は 155+122+61+50+48+42+39+38+37+36+30+8+7+2+2+1 = **678 件**で、論文本文中の「78% of interruptions were due to hardware-related failures」という記述と整合する規模である。各行の割合(count/678)を独自に再計算すると、GPU HBM3 Memory 22.86%→22.9%・PCIe Device 17.99%→18.0%・NCCL Watchdog Timeouts 9.00%→9.0%・Faulty GPU Compute 7.37%→7.4%・Software Bug 7.08%→7.1%・Host Maintenance 6.19%→6.2%・Kernel Fault 5.75%→5.8%・System Reboot 5.60%→5.6%・Numerics/SDC 5.46%→5.5%・**Network Switch/Cable 5.31%→5.3%(表記どおり)**・SSD 4.42%→4.4%・GPU SRAM Memory 1.18%→1.2%・Unknown 1.03%→1.0%・System Memory 0.29%→0.3%・System Cooling 0.29%→0.3%・GPU Thermal Interface + Sensor 0.147%→表記は 0.2%(四捨五入なら 0.1% が近いが、論文表記は 0.2%)。この最終行のみ丸め方に軽微な不整合があり、全行の表記割合を単純合計すると 100.2% になる(丸め誤差 + GPU Thermal Interface + Sensor 行の表記が理論値よりやや大きいため)。それ以外の全行は独自の再計算値と表記が一致し、Network Switch/Cable の 5.3%(36 件)は論文の記述どおりである。 **光モジュール・光リンクに関する記述**: 本文・図表を精査したが、「optical」「transceiver」「BER」「FEC」「photonic」に該当する語は本文中に一切現れなかった(grep 検索で確認)。すなわち本論文は光モジュール・光リンク起因の障害を独立カテゴリとして計上しておらず、Table 1 の "Network Switch/Cable"(36 件・5.3%)という粗い粒度のネットワーク障害カテゴリに、もし光関連の故障が含まれるとしても暗黙的に丸め込まれていると考えられる。これは、光トランシーバー故障を独立に予測・分類する [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]](OptProphet)のような専門的な障害分類研究と対照的であり、本論文の障害分類の粒度としての限界と言える。 そのほかの内訳の要点: - **Faulty GPU Compute** はかつて最多要因だったが、特定の障害モードへの対処と不調 GPU の積極的隔離により第 4 位(7.4%)へ低下した。 - **GPU HBM3 Memory** は GPU Compute 起因の障害が減少するにつれ現行版で最多要因に浮上した(著者らは今後 HBM サブシステムの信頼性向上を課題としている)。 - **PCIe Device**(18.0%)は前バージョンでは無視できる水準だったが、致命的な NVMe ファームウェアバグにより SSD が read-only モードへ陥り critical I/O エラーを起こす件数が増加した。もう一方の PCIe デバイス問題は GPU に関するもので、訂正不能エラー・訂正可能エラーの増加・パリティ不一致を報告した。いずれも自動化により検知・不調サーバの除去が可能だった。 - Linux カーネルは概ね信頼できるが、カーネル障害・ロックアップ・突発的なシステムハングが散発した。これらは典型的に一過性で、対象サーバの再起動により解消した。 - **Numerics/Silent Data Corruption**(37 件)は 7 台のホストに追跡され、根本原因調査に数時間〜数日を要した。ある SDC 事例では、2T パラメータ中の特定レイヤーの単一エキスパート内で 32 個の連続パラメータが 1e7 超に急上昇していたことが判明した。モデル-サーバ対応関係の逆引きと診断ツールにより不調ホストを特定した。決定的訓練(deterministic training)を単一ホスト上で実行しチェックポイントを比較する内部ツールも開発した。 ### 決定的訓練(§2.2) 決定的訓練フローは以下の不変条件を保証する: (1) 任意の訓練イテレーションのデータが実行間で同一であること、(2) 訓練フロー内の全オペレータが同一入力に対して決定的な出力を返すこと(flash attention 最適化の無効化・cuDNN の決定的アルゴリズム強制・cuDNN オートチューナの無効化により達成)。これにより、固定回数のイテレーション後に複数の訓練実行間で同等のチェックポイントを生成でき、同一ランクのチェックポイントを比較して母集団内の外れ値(問題ホスト)を検出できる。 ### 高速根本原因分析(§2.3) 集団通信ライブラリからの豊富なテレメトリを収集し、5〜20 秒ごとに全 GPU からトレーシングデータを取得して深い分析で問題源を特定するツールを構築した。ジョブがハングした場合、まず集団通信の wait-for グラフを構築し(葉ノードがジョブ全体をブロックしている集団通信)、次にその集団通信内の GPU レベルの wait-for グラフを構築して(葉ノードが実際に待たれているランク)原因ランクを特定する。性能が著しく低下した場合は、各ランクの集団通信完了時間を集計し、完了時間が有意に短い(=集団通信への参加が最後になっている)ランクを遅延の原因として特定する。このツールは 32K GPU 以上のジョブでも 5 秒未満で全分析を完了し、テレメトリはホスト DRAM(GPU HBM ではない)に一時的に滞留し GPU 当たり 1MB 未満、非同期収集で訓練性能への影響はない。約 1,500 件の障害を数十のジョブ(数百 GPU・複数日)に注入して精度を検証した結果、97.8% のケースで不調サーバを正しく特定し、残り 2.2% でも不調サーバが最終候補の少数集合に含まれていた(送信側・受信側どちらに起因するか正確な帰属が困難な稀なケース)。 ### 100K GPU へのスケーリングの課題(§3) 32K GPU では同期復旧により失う GPU 時間は 3〜5% 程度で問題にならないが、100K GPU への拡大に伴い障害率・復旧コストの双方が増加しダウンタイムを著しく増大させる。図2(本ページには埋め込んでいない、ベクター図)は復旧プロセスの各ステップの内訳を示す: - **代替 GPU の確保(Allocation)**: 素朴な方式(cold-N)では訓練ジョブ全体を停止し全 GPU をプライベートクラウドへ返却してジョブ全体の再起動をクラウドへ依頼する(最大 5 分)。予備 GPU を予約しておく warm-N 方式では確保オーバーヘッドを大幅に削減できる。 - **NCCL 初期化**: 全コネクションの確立時間は GPU 数とともに増大し、16K GPU で 17 秒、98K GPU で約 200 秒に達する(起動時間削減を試みたカスタム NCCL 実装を用いてなお、この水準)。 - **その他のロードオーバーヘッド**: PyTorch の起動・チェックポイントの取得とロード・ヘルスチェック等。スケールとともに大きくは増加しない。 - **「ファーストステップ」オーバーヘッド**: チェックポインタの再作成・データローダの初期化(次 N バッチのキャッシングを含む)・JIT コンパイル等で、通常ステップの約 20 秒に対し数分を要しうる。cold 方式では特に非決定的(より多くのエンティティを再構築する必要があるため)。 著者らの結論は、これらのステップの最適化に大きな労力を割いても、より大規模での復旧時間を安定に保つことは難しいというものである。本来は障害率上昇を補うために復旧時間はスケールとともに減少してほしいが、本番データによれば 100K GPU では 18 分ごとに 1 件の障害が発生する。18 分ごとに 10 分の完全停止を要する場合、有効訓練時間は約 44% にとどまる。 ## 考察 ### 6.1 スタール時間と訓練効率 98K H100 GPU・12 レプリカ・4 DC 建屋構成での実験。12 の健全レプリカで開始すると約 450 TFlops/GPU/s(FT-HSDP 非導入時の定常状態と同一で、障害のない場合のオーバーヘッドがないことを示す)。1 レプリカを故意に停止させると、障害の検知・処理・障害ステップの再訓練に約 3 分を要した(これは期待値〈60 秒タイムアウト + FTAR 再構築数秒 + ステップ再訓練約 20 秒〉を上回る)。分析により超過の 2 つの要因が判明した: (1) 電力消費の急変を防ぐ power smoother 技術が、98K 全 GPU を止める障害でトリガーされ 45 秒のスタールを招いていた(その後修正)、(2) 不要な FTAR 再構成を実行するバグにより 45 秒の追加スタールが生じていた(その後修正)。両修正により期待どおりの約 1.5 分に近づく見込みで、100K GPU が再び利用可能になった際に再確認予定としている。その後 FT-HSDP は 11 レプリカで約 450 TFlops/GPU/s の訓練を継続する(期待どおり)。障害レプリカがステップ n で復帰する際、ステップ n+1 の完了に約 2 分を要する(ステップが通常約 20 秒であることを踏まえると、復帰は約 100 秒のスタールをもたらす)。これには 2 つの理由がある: (1) §3 で議論した「ファーストステップ」効果(完全には排除できていないが、全 100 秒がこの効果によるとしても Figure 2 に示す約 200 秒のファーストステップ時間より短く、最適化の有効性を示す)、(2) レプリカがステップ n の途中または終盤で復帰する場合、復旧がステップ n の終了を超えて延びうる(この場合 FT-HSDP はステップ n+1 終了時に参加させる〈スタールなしだがステップ n+1 で活用不可〉か、他レプリカにステップ n の終了を待たせる〈スタールが生じるがステップ n+1 を活用可能〉かを、待機時間の上限を設けてトレードオフを取る)。その後 12 の健全レプリカで約 450 TF/GPU/s の訓練を再開する(完全復旧)。 まとめると、FT-HSDP は 1 レプリカの障害・復旧につき合計約 3 分のスタールで済む。18 分ごとに障害が発生すると仮定した場合の改善分析: 完全同期復旧方式では 18 分ごとに約 10 分の完全停止が生じ有効訓練時間は (18-10)/18 = 44%。FT-HSDP(12 レプリカ想定)では、完全な障害からの復元には依然 10 分要するが完全停止は 3 分のみ(11 レプリカで 7 分間動作)であり、有効訓練時間は (8+7×11/12)/18 = **80%** となる。§4.1 で議論したとおり、60 秒タイムアウトをより高速な障害検知器に置き換えることでこの 3 分のスタールをさらに縮小できる可能性がある。 ### 6.2 モデル精度 非同期復旧によるレプリカの頻繁な追加・削除がモデル精度に影響するかを検証した。資源制約により 98K GPU のフルスケール実験は短時間 1 回のみ実施し、期待どおりの訓練進捗を確認した。より包括的には 256 H100 GPU で 3B アクティブパラメータ・16 エキスパートの MoE モデルを複数設定で訓練した(500B トークン)。設定は `freq_fp_len_con_lr` の命名規則で表され(freq=n ステップ当たりの障害回数、fp=fp8/fp16、len=障害の長さ〈ステップ数〉、con=1 回の障害で同時に停止するレプリカ数、lr=学習率介入戦略)、最も攻撃的な設定(`d2x_fp8_for4k_3reps_X`)を含め、ベースラインと FT-HSDP の間に区別可能な差は観測されなかった(Figure 8:訓練損失・コーディング評価セットで測定した全体進捗、200B トークン時点でレプリカの停止を開始)。ただしトークン数を x 軸に取った場合の話であり、実時間(壁時計時間)を x 軸に取ると FT-HSDP は障害復旧処理のためベースラインより進捗に時間を要する。 短い時間窓に着目すると(Figure 9)、変動は短時間で発生し、3 件の同時障害は 1 件の障害より大きな変動を招く(予想どおり)。平方根学習率介入(sqrt、`num_healthy_replicas/num_total_replicas` の平方根で学習率をスケール、勾配ノイズの標準偏差に比例するよう学習率を保つ)は線形介入(linear)より一般に優れており、変動を平坦化する(デバッグ目的にも有用)。この結論は障害が長い場合(`d2x_fp8_for4k_3reps_lr_X`)でも保たれ、訓練精度は最終的にベースラインへ回帰する。結論として、非同期復旧は最終的な訓練精度を有意に劣化させないが訓練中に一定の変動を招きうるとし、平方根学習率介入を推奨する。fp16 や他の評価セットでも同じ結論に至ったと報告する。 ### 6.3 FTAR の性能 FTAR の性能をマイクロベンチマークで測定した(異なる AI Zone に GPU を配置し種々のサイズのメッセージを転送、100 回実行の平均)。 | Message Size | 2 Ranks (FTAR / NCCL) | 4 Ranks (FTAR / NCCL) | 8 Ranks (FTAR / NCCL) | 16 Ranks (FTAR / NCCL) | |---|---|---|---|---| | 256MB | 40.06 / 40.53 | 41.17 / 41.2 | 40.12 / 41.82 | 41.25 / 41.17 | | 512MB | 39.8 / 42.12 | 42.15 / 42.32 | 43.01 / 43.61 | 43.61 / 43.15 | | 1GB | 40.93 / 43.87 | 44.67 / 43.93 | 44.67 / 44.87 | 45.51 / 44.32 | (Table 2: FTAR bandwidth (GB/s). Average of 100 runs. 単位は GB/s。) FTAR の性能は native NCCL 実装に近く、16 ランク・1GB では FTAR(45.51 GB/s)が NCCL(44.32 GB/s)をわずかに上回る条件もある。 ## 強み / 弱点・課題 **強み**: - 98K GPU という実際の大規模本番クラスタで検証されており、シミュレーションや小規模実験に留まらない実測エビデンスを提供する。 - スタール時間の内訳(Allocation・NCCL 初期化・その他ロード・ファーストステップ)を定量的に分解し、100K GPU 級で完全同期復旧が構造的に破綻することを明快に示す。 - CPU-GPU ハイブリッド設計という単純な原理で、GPU 駆動通信(NCCL)が苦手とする複雑な制御ロジックと、GPU が得意とする高速データ転送を両立させている。 - 非同期復旧が精度に与える影響を、256 GPU の制御された実験で定量評価し、平方根学習率介入という具体的な緩和策まで提示している。 **弱点・限界(著者ら自身が認める点を含む)**: - 図2 の 60 秒タイムアウト起因の遅延は「今後より高速な障害検知器で削減できる可能性がある」と述べるにとどまり、本論文自体はその改善を実証していない。 - 6.1 節の 98K GPU 実験は「大規模実験は資源集約的すぎて複数回の実験でノイズを除去する余裕がない」と明言しており、単発の実測値であることに注意が必要(power smoother 由来の 45 秒・バグ由来の 45 秒という 2 つの偶発的要因が含まれていたことも、そのばらつきの一端を示す)。 - モデル精度の検証は主に 256 GPU・3B アクティブパラメータの MoE 実験に基づく外挿であり、98K GPU フルスケールでの精度検証は短時間 1 回のみ。著者ら自身も小規模実験からの外挿の妥当性を議論している。 - 10〜20 レプリカという設定は経験的探索の結果であり、モデルサイズや障害率に対する一般的な最適レプリカ数の理論的指針は与えられていない。 - Table 1 の障害分類は "Network Switch/Cable" のような粗い粒度のカテゴリを含み、光トランシーバー・光リンク起因の障害を独立に計上していない(§実験結果の光モジュール節を参照)。 ## 関連 - [[耐障害LLM訓練]] / [[LLM分散学習]] / [[GPUクラスタ運用]] / [[ZeROパラメータシャーディング]] / [[チェックポイント]] / [[データセンターネットワーク信頼性]] / [[弾性LLM訓練]] - [[Meta]] / [[NCCL]] - [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]](同じ完全同期チェックポイントベース復旧の課題に取り組む同時期の本番システム) - [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] - [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] - [[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]](パイプライン並列に基づく耐障害設計。本論文はこれを DC 間の長いネットワークレイテンシ・限られた帯域を考慮していないと指摘) - [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]]