@2025__ATC__GREYHOUND - Hunting Fail-Slows in Hybrid-Parallel Training at Scale

# GREYHOUND: Hunting Fail-Slows in Hybrid-Parallel Training at Scale > [!abstract] 概要 > フェイルスロー(fail-slow)、すなわちストラグラーは、多数の GPU サーバからなる大規模フリートで長期間走る大規模ハイブリッド並列学習における一般的な問題である。しかし、これらの問題は十分に研究されていない。本論文ではまず、10,000 基を超える GPU を持つ共有本番クラスタでの特性評価研究を示す。フェイルスローは、競合・デバイス劣化・ネットワーク輻輳による低速な計算または通信が引き起こす一過性のストラグラーとして現れ、サブ分単位から約 10 時間にわたって継続し、大規模学習ジョブを平均 1.34 倍遅らせることが分かった。現行の実務は、フェイルスローを手動で検知し、チェックポイントと再起動によるフェイルオーバーでフェイルストップとして扱うことであり、時間がかかる。本論文では GREYHOUND を提案する。GREYHOUND は、低速な GPU や通信リンクを迅速に特定し、新規の多段階緩和機構で効果的に対処するシステムであり、すべて人手を介さない。GREYHOUND は本番クラスタで 99% を超える精度でフェイルスローを正しく検知する。256 基の H800 GPU のテストベッド実験では、(手動で注入した)ストラグラーを効果的に処理し、エンドツーエンドのスループットを 1.58 倍に改善することをさらに示す。 ## 論文情報 - タイトル: GREYHOUND: Hunting Fail-Slows in Hybrid-Parallel Training at Scale - 著者・所属: [[Tianyuan Wu]]、[[Wei Wang]](責任著者)、[[Qinkai Duan]]([[Hong Kong University of Science and Technology]])。[[Yinghao Yu]]、[[Siran Yang]]、[[Wenchao Wu]]、[[Guodong Yang]]、[[Jiamang Wang]]、[[Lin Qu]]、[[Liping Zhang]]([[Alibaba Group]]) - 媒体: 2025 USENIX Annual Technical Conference(ATC '25)、2025 年 7 月 7〜9 日、米国ボストン。pp. 731–747 - 発表年: 2025(`date_published` は会議初日) - 一次資料: 発表ページ(上記 `url`)と、USENIX が公開する論文 PDF。arXiv ID と DOI は本文に無い ## 概要 10,000 GPU 超の共有本番クラスタの特性評価から、フェイルスローが計算側(CPU 競合・GPU 熱スロットリング)と通信側(ネットワーク輻輳)の一過性ストラグラーであり、規模とともに頻度と被害が増すことを示す。この知見に基づき、訓練フレームワークに手を入れない検知系 GREYHOUND-DETECT と、継続時間の不確実性をスキーレンタル問題として扱う多段階緩和系 GREYHOUND-MITIGATE を設計する。本番トレースの検知精度は 99.8%、256 H800 の注入実験のスループットは 1.58 倍に回復する。 ## 問題設定ハイブリッド並列(TP・DP・PP の組み合わせ)の大規模学習は、反復ごとの同期を要するため、1 基の GPU または 1 本のリンクの性能劣化がジョブ全体を遅くする。停止を伴うフェイルストップと違い、フェイルスローは動き続けるため検知と箇所特定が難しい。同期学習の性質上、ストラグラーが 1 つあるだけで全 GPU の SM 使用率が同時に下がる。1 本のリンクを複数ジョブが共有するため、RNIC の CNP(輻輳通知パケット)の増加もジョブ単位の性能問題を意味しない。ゆえにハードウェアメトリクスの収集だけでは箇所を特定できない。既存のベンチマークツールで箇所特定するにはジョブ全体を止めて全 GPU・全リンクを測る必要があり、コストが大きい。 ### 特性評価の方法対象は 4,000 ノード超・10,000 GPU 超(H800 約 1,800 基と A100 約 2,600 基)の共有マルチテナントクラスタである。ノード内は NVLink/NVSwitch、ノード間はスパイン・リーフ構成の RoCE(A100 ノードは 4×200 Gbps、H800 ノードは 4×400 Gbps)である。本番ワークロードの計装は許されないため、2 つの方法を併用する。 - **オンラインプロービング**: 同一の小規模学習ジョブをスポットワークロードとして繰り返し投入し、ランダムに割り当てられたノードで、後述の検知手法によりフェイルスローを測る。 - **オフライン検査**: 512 GPU 以上を使う大規模ジョブの 1 か月分(2024 年 7 月)のトレースを人手で検査する。 ### 計算フェイルスロー GPT2-11B を 4×H800(TP 2・DP 1・PP 2、Megatron-LM)で 10,000 反復学習するジョブ(70〜90 分)を 400 件投入し、392 件が完走した。プロービングは H800 約 1,800 基のうち約 500 基(28%)を覆う。6 件が計算フェイルスローを経験し、4 件が CPU 競合、2 件が GPU 性能劣化だった。平均継続時間は 10 分、JCT の延びは 11.79% である。 **Figure 1: フェイルスロー継続時間の CDF(左)と JCT スローダウンの CDF(右)** ![[_attachments/atc25-wu-tianyuan/fig01-fail-slow-duration-jct-cdf.png]] (Figure 1. 計算フェイルスロー(Comp)は短命で、通信フェイルスロー(Comm)は継続時間の幅が広く、大規模ジョブ(Large)は最も長く、JCT への影響も大きい。) **Table 1: 本特性評価で観測したフェイルスローの原因と JCT スローダウン** | 分類 | オンライン 1 ノード | オンライン 4 ノード | オフライン大規模(512 GPU 以上) | |---|---|---|---| | フェイルスローなし | 386 | 64 | 11 | | CPU 競合 | 4 | 1 | 0 | | GPU 劣化 | 2 | 0 | 0 | | ネットワーク輻輳 | 0 | 42 | 13 | | 複数の問題 | 0 | 0 | 3 | | ジョブ総数 | 392 | 107 | 27 | | 平均 JCT スローダウン | 11.79% | 15.45% | 34.59% | (Table 1. 原因別のジョブ数と平均 JCT スローダウン。) **事例 1: CPU 競合。** ジョブは 22 分と 55 分の 2 回フェイルスローし、性能は最大 21.6% 落ちた。4 基すべての SM 使用率が同時に下がったが、検知時に止めて行列計算を走らせても GPU の劣化は見つからなかった。原因は同一ノードで高 CPU ジョブが急増し、学習ジョブの CPU 充足率が下がったことだった(Figure 2)。 **Figure 2: CPU 競合によるフェイルスロー事例** ![[_attachments/atc25-wu-tianyuan/fig02-cpu-contention-case.png]] (Figure 2. 左上がスループット、右上が 4 基の SM 使用率、左下が同一ノードの高負荷ジョブ数、右下が学習ジョブ(赤)と同居ジョブ(青)の CPU 充足率。高負荷ジョブの急増と 2 回のスループット低下が重なる。) **事例 2: GPU 性能劣化。** 最初の 10 分だけスローダウンし、4 基すべての SM 使用率が下がった。調べると GPU0 だけが他より 20% 遅く、原因は熱スロットリングだった(Figure 3)。温度が上がっても性能問題に至らない場合があり、これはハードウェアの問題を示唆しうる。発生率は約 0.5% で、ByteDance の報告と整合する。 **Figure 3: GPU 性能劣化によるフェイルスロー事例** ![[_attachments/atc25-wu-tianyuan/fig03-gpu-degradation-case.png]] (Figure 3. 左上がスループット、右上が 4 基の SM 使用率、左下がフェイルスロー中の正規化 GPU 性能(GPU0 だけが他より低い)、右下が NVML の GPU 温度。) 計算フェイルスローは一過性で、数十分で解消することが多く影響が比較的小さい。よって緩和は軽量でオーバーヘッドが小さくなければならない。 ### 通信フェイルスロー GPT2-7B を 4 ノード・8×A100(TP 2・DP 4・PP 1)で学習するジョブを 120 件投入し、107 件が完走した(各約 5 時間、A100 約 2,600 基のうち 690 基・26.5% を覆う)。43 件がフェイルスローし、1 件が CPU 競合、42 件がネットワーク輻輳だった。RNIC などのハードウェア起因は観測されていない。通信フェイルスローの継続はサブ分から 100 分超まで幅があり、平均約 24 分、JCT を 15.45% 遅らせる(Table 1、Figure 1 左)。 **Figure 4: ネットワーク輻輳によるフェイルスロー事例** ![[_attachments/atc25-wu-tianyuan/fig04-network-congestion-case.png]] (Figure 4. 左がスループット、中央が RNIC の輻輳通知パケット数(×1000)、右が 8 基の平均 SM 使用率。t=90 分で 0.57 から 0.41 iter/s へ、t=265 分でさらに 0.31 iter/s へ下がり、CNP の急増と一致する。) 原因は、同じリンクを他ジョブが共有し帯域が絞られたことだった。スパイン・リーフ構成ではスパインスイッチを複数ジョブが共有するため、マルチテナント環境で輻輳は避けにくく予測もできない。本論文はこの輻輳起因の遅れをフェイルスローに分類する。持続時間が長く影響が大きいため、より積極的で高コストな緩和も見合う。 ### 大規模でのフェイルスロー 512〜1,024 GPU を使う大規模ジョブ 27 件のうち 16 件がフェイルスローし、平均 JCT を 34.59% 遅らせた。20% のジョブは 50% 超遅れた(Figure 1 右の緑線)。平均継続時間は 72 分で、小規模プロービングより大幅に長い。原因は 13 件がネットワーク輻輳、残る 3 件がネットワークと GPU 劣化の両方である(Table 1)。8 GPU 単位で割り当てるため CPU の同居競合はない。 **Figure 5: ネットワーク輻輳でフェイルスローした 1,024 GPU の 2 ジョブ** ![[_attachments/atc25-wu-tianyuan/fig05-1024gpu-congestion-jobs.png]] (Figure 5. 左が LLM 学習ジョブ、右が MoE 学習ジョブ。前者は初期に、後者は学習全体を通して、スループットが大きく変動する。) **Figure 6: 高い GPU 温度と輻輳が重なった 1,024 GPU ジョブ** ![[_attachments/atc25-wu-tianyuan/fig06-compound-fail-slow-1024gpu.png]] (Figure 6. スループットと SM 使用率は一致して動く。t=62 分の輻輳でスループットが 80% 落ち、t=80 分前後の GPU 熱スロットリングが加わって通常の 10% まで下がり、t=120 分以降の輻輳が約 2 時間続いて再び 85% 落とした。) 規模が大きいほど計算と通信の問題が同時に起き、複合して 90% 超の低下に至りうる。緩和は適応的で柔軟でなければならない。 ### 特性評価の要点 - 要点 1: フェイルスローは通常一過性で、計算と通信の劣化が主因である。前者は低速 GPU や CPU 競合、後者はネットワーク輻輳に由来する。 - 要点 2: 計算フェイルスローは短命で頻度が低く影響が小さい。通信フェイルスローは頻度が高く長く続き、影響が大きい。 - 要点 3: 規模が大きいほど複数の問題に同時に遭遇しやすく、複合で 90% 超の低下が起きうる。他社の報告として、ByteDance が計算フェイルスロー、Meta の Llama チームと Alibaba Cloud が通信フェイルスローを報告している。単一テナントの超大規模クラスタでも同様の問題があると他社から聞いている。 ## 提案手法 ### GREYHOUND-DETECT 設計要件は 4 つある。R1 は非侵入でフレームワーク非依存、R2 は迅速かつ正確、R3 は完全自動、R4 は軽量(チェックポイントと再起動を要するジョブ全体の検証をしない)。 **Figure 7: GREYHOUND-DETECT のアーキテクチャ** ![[_attachments/atc25-wu-tianyuan/fig07-detect-architecture.png]] (Figure 7. マスタ(GlobalController・GlobalAnalyzer・Validator の TestScheduler と TestDispatcher)とワーカ(LocalController・LocalAnalyzer・Monitor・BenchmarkExecutor)の構成。Monitor と BenchmarkExecutor は訓練フレームワークと NCCL・CUDA の間の薄い層に置く。) マスタ・ワーカ構成で、追跡・プロファイリング・検証の 3 段階を踏む。 - **追跡**: ワーカが各 rank の反復時間を監視し、遅い反復を検知したらマスタに報告する。 - **プロファイリング**: 進行中のジョブから詳細な実行プロファイルを集め、疑わしいワーカグループへ絞る。 - **検証**: 疑わしいグループ内で遅い GPU または輻輳リンクを特定する。プロファイリングや検証の途中で一過性のフェイルスローが解消したら、異常なしとして通常の訓練に戻る。 **追跡(Tracking)。** Monitor が LD_PRELOAD で NCCL 関数をフックし、通信操作の種類とタイムスタンプを共有メモリに記録する。AllReduce や AllGather のような、通信ライブラリ間で共通の最上位インタフェースだけを傍受するため、ACCL・MSCCL・独自 NCCL にも載せられる。LocalAnalyzer が次の 2 手法で遅い反復を検知する。 **Figure 8: 通信操作の周期性** ![[_attachments/atc25-wu-tianyuan/fig08-periodic-communication.png]] (Figure 8. 反復学習では通信操作が周期的に現れる。1 周期に ReduceScatter・AllGather・AllReduce などが含まれる。) - 周期の特定: 1 周期に含まれる呼び出し数と並びはフレームワークとモデルで変わるため、事前に分からない。呼び出し列の自己相関関数 ACF(X)k が閾値 M(実験では 0.95)を超える最小のラグ k を周期とする。反復時間は、ある通信操作と前の周期における同じ操作の時刻差である。 - 遅い反復の検知: 反復時間は Python のガベージコレクション、CUDA メモリアロケータのキャッシュミス、系列長の不揃いなどで本来ゆらぐ。そこでベイズオンライン変化点検知(BOCD)を使う。各時刻の連長 r_t を、変化点でなければ r_{t-1}+1、変化点なら 0 とし、r_t=0 の尤度が閾値(0.9)を超えたら変化点と報告する。BOCD は線形時間で動き、反復時間が 10% 超変わる変化を拾う。BOCD 単独では通常のゆらぎを誤って拾うため、変化点前後の平均反復時間の差が 10% 未満なら揺らぎとして棄却する検証を足す。 **プロファイリング(Profiling)。** 全 GPU・全リンクの測定を避けるため、疑わしいグループに絞る。GPU Monitor が傍受した NCCL 呼び出しに CUDA イベントを挿入し、通信グループごとの実行時間を測る。GlobalAnalyzer は、同じデータ転送量を扱うグループを同じ比較可能クラスタにまとめ、クラスタ内の実行時間を比べる。中央値を 10% 超えるグループを劣化とみなす。 **Figure 9: グループ間比較の例** ![[_attachments/atc25-wu-tianyuan/fig09-cross-group-comparison.png]] (Figure 9. PP を均等に分けると 4 つの DP AllReduce グループ AR0〜AR3 の通信量が等しく、4 グループの比較可能クラスタになる。AR3 の実行時間だけが著しく長く、その中にストラグラーがある。) **検証(Validation)。** ベンチマークを走らせるため訓練を一時停止する。チェックポイントと再起動の代わりに、GPU Monitor が NCCL 呼び出しを一斉に待機ループへ捕捉して訓練を止め、検証後に制御を戻す。プロセスの再起動や再初期化はない。 - 計算検証: TestDispatcher が疑わしいグループの全 GPU に標準の GEMM テストを並列に配り、遅いものを見つける。GEMM は学習の基本演算で、SuperBench などの標準テストでもある。 - 通信検証: グループ内の全リンクを総当たりで測ると O(N²) かかる。そこで集団通信のトポロジをリングまたはツリーとし、重ならない P2P 送受信に分解して、学習で使うリンクだけを測る。これにより所要はグループサイズによらず O(1) になる。偶数ランクのリングは 2 パス、奇数ランクのリングは 3 パス、ツリーは 4 パスで覆う。NCCL が実際のトポロジを動的に決めるため、リングとツリーの両方を検証する。転送量は同一なので、遅いリンクは通信時間が長く出る。 **Figure 10: リングとツリーの O(1) 検証** ![[_attachments/atc25-wu-tianyuan/fig10-ring-tree-validation.png]] (Figure 10. 各セルが rank、線がネットワークリンク。偶数リングは 2 パス、奇数リングは 3 パス、ツリーは 4 パスで全リンクを測る。) 実装は約 5.5k 行の C++ と Python で、ノード内は共有メモリ、ノード間は Redis で通信する。BenchmarkExecutor は学習側の CUDA コンテキストと NCCL コミュニケータを再利用して初期化コストをなくす。計算ベンチマークは FP8・FP16・FP32 の GEMM を、各実行で全 SM を専有して順に走らせる。通信ベンチマークは図 10 の NCCL send/receive を 16・32・64 MB で同時に走らせる。各テストを 3 回繰り返し平均を使う。限界として、計算と通信のカーネルが特定パターンで同時実行されたときだけ現れるフェイルスローは検知できない。ただし、これは特定ハードウェアロットの欠陥に結びつく極めてまれな事例だと述べる。 ### GREYHOUND-MITIGATE 緩和は訓練フレームワークの支援を要するため、検知と違って完全な非侵入にはできない。Megatron-LM のプラグインとして約 1.5k 行の Python で実装し、プランナが Redis から低速な ID を受け取って調整戦略を作る。 **4 つの戦略。** 一過性のフェイルスローをフェイルストップとして再起動するのは、かえって害になりうる。GPT2-100B のチェックポイント書き出しは約 100 分かかり、平均フェイルスロー継続時間より長い。 - S1: 何もしない。回復を待つ。検知手段がないため既存システムの多くはこれを選ぶ。 - S2: マイクロバッチ配分を調整する。計算フェイルスローによるレプリカ間の速度差を、DP グループの処理速度に応じてマイクロバッチを再配分して均す。 - S3: 並列化トポロジを調整する。混雑リンクを軽トラフィックのグループへ移し、複数のストラグラーを最小数の PP ステージに集約する。計算・通信の両方に効く。 - S4: チェックポイントと再起動。最後の手段で、低速部品を交換して全フェイルスローを消すが、オーバーヘッドが最大で人手も要りうる。 **Table 2: 緩和戦略の効果とオーバーヘッドの比較** | 戦略 | 計算フェイルスローへの効果 | 通信フェイルスローへの効果 | 行動オーバーヘッド | |---|---|---|---| | S1: 無視 | 効果なし | 効果なし | なし | | S2: マイクロバッチ調整 | 緩和 | 効果なし | 低 | | S3: トポロジ調整 | 緩和 | 緩和 | 中 | | S4: チェックポイントと再起動 | 解消 | 解消 | 高 | (Table 2. S1 から S4 へ進むほど効果は上がるがオーバーヘッドも増える。TP の調整は TP がノード内で閉じ通信フェイルスローに晒されないため無効とされる。) **スキーレンタル型の多段階緩和。** 最適な戦略は深刻度と継続時間で変わる。深刻度は測れるが、継続時間は数十秒から数時間まで幅が大きく事前に予測できない。この問題は古典的なスキーレンタル問題に似ており、繰り返し払うレンタル料がフェイルスローによる損失、一括のスキー購入が緩和行動に当たり、継続時間の事前知識がない点も同じである。そこで最も安い S1 から始め、フェイルスローが続き現行戦略が効かなければ、より効果的で高コストな S2〜S4 へ段階的に切り替える。切り替えは、累積スローダウン(スローした反復数×(t_slow−t_healthy))が次の戦略の行動オーバーヘッドに達した時点で行う(Algorithm 1)。継続時間を事前に知っていれば直ちにその戦略を採れたはずだ、という後悔を抑える設計である。 **S2: マイクロバッチ配分の調整。** グローバルバッチの M 個のマイクロバッチを D 個の DP グループに配分し、グループ i の割当を m_i、1 マイクロバッチの処理時間を t_i(GREYHOUND-DETECT がプロファイルする)とする。最も遅い DP グループの処理時間を最小化するため、式 (1) の二次計画問題に定式化する。 $\min \max_{i} m_i t_i \iff \min \sum_{i=1}^{D}\Bigl(m_i t_i - \tfrac{\sum_j m_j t_j}{D}\Bigr)^2,\quad m_i\in\mathbb{N}^+,\ \sum_i m_i = M$ 1F1B パイプラインでは m_i ≡ 0 (mod PP) の制約を足す。配分が不均等になっても、重み付き勾配集約により学習結果は変わらない。グローバルバッチサイズとマイクロバッチサイズは不変で、1F1B のピークメモリは m_i に依らないためメモリ使用量も増えない。cvxpy で解き、各 DP グループは反復前にグローバルコントローラから m_i を取得して、次の反復から再起動なしで反映する。 **S3: 並列化トポロジの調整。** PP 通信は GPU あたり O(m_i×activation_size) で、1 反復あたり数十〜数百 MB である。一方、DP の勾配同期は数十 GB を超えうる。DP グループのほうが輻輳に脆弱なので、混雑リンクを重い DP から軽い PP のグループへ付け替える。 **Figure 11: 輻輳を緩和するトポロジ調整** ![[_attachments/atc25-wu-tianyuan/fig11-topology-adjustment.png]] (Figure 11. ノード 3-4 間のリンクが混雑して DP 通信に使われている場合、ノード 2 と 3 の DP・PP の役割を入れ替えると、混雑リンクが軽トラフィックの PP 通信に移る。) 複数のストラグラーがあるときは 1 つの PP ステージに集約する。同じ PP ステージ内のワーカは同期して動くため、性能は最も遅いストラグラーで決まり、ステージ内の台数には依らない。集約に必要な最小ステージ数は ⌈ストラグラー数 / PP ステージあたり GPU 数⌉ で求める。先頭と末尾のステージは前後処理(埋め込み層など)で負荷が高いため、内側のステージへ寄せる。 **Figure 12: ストラグラーの PP ステージ数が反復時間を決める** ![[_attachments/atc25-wu-tianyuan/fig12-straggler-consolidation.png]] (Figure 12. 通常のマイクロバッチは 1 秒、遅いものは 1.5 秒。健全時 6 秒に対し、2 ステージに散らばると 8.5 秒、1 ステージに集約すると 8 秒に収まる。) 実装は、訓練の一時停止、パラメータのメインメモリへの一時退避、P2P RDMA によるパラメータ交換、訓練プロセスの再開の 4 手順で、所要は GPU あたりのパラメータ数だけで決まり、学習規模に依らない。通常は約 1 分で終わる。 ## 新規性 - 従来はフェイルスローへの言及が断片的で、本番クラスタで全体像を特性評価した研究は初めてだと主張する。 - 検知は、フレームワーク非依存の非侵入計装(NCCL フック)で反復時間を追い、オンライン異常検知(BOCD+検証)とマイクロベンチマークを組み合わせて実行時に箇所特定する。ジョブ全体を止める侵入的な全数検証に頼らない点が新しい。 - 緩和は、有効性とコストのトレードオフを、継続時間が未知のオンライン意思決定としてモデル化し、スキーレンタル理論で段階的切り替えを与える。先行の解はこの均衡を考えていないとする。 - 関連研究として、フェイルストップは Oobleck などがチェックポイントや弾力的フレームワークで扱う。フェイルスローは、同時期の Holmes(NSDI '25)が検知だけを扱い、緩和を欠くとする。クラウドサービス・OS・ストレージのフェイルスローは伝播元の特定が主題だが、学習は同期型で 1 つの遅い部品が即座にクラスタ全体へ響く。異種混在の学習は静的で初期に高コストの探索ができるが、フェイルスロー対応は動的でそれができない。 ## 実験設定 - 環境: 8×H800(NVSwitch)を 55 ノード、400 Gbps InfiniBand のスパイン・リーフ構成(ノード間帯域は対称)。Megatron-LM で各種サイズ・並列戦略の GPT-2 を学習する。CUDA 12.2、NCCL 2.18.1。 - フェイルスロー注入: 計算は nvidia-smi で SM 周波数を固定する。通信はサイドチャネルの通信ジョブを流して特定リンクの帯域に競合を作る。 - 検知のベースライン: スライディングウィンドウ(現在の中央値から 10% 超の変化で報告)と、検証なしの古典的 BOCD。正解は §3 のトレースの人手ラベルである。 - 評価指標: 精度、偽陽性率(FPR)、偽陰性率(FNR)、反復時間、オーバーヘッド、反応時間、スループット。 ## 実験結果 ### 検知の精度反復時間の推定は、ACF 推定の相対誤差が単一ノード(4 GPU)で 1.2% 未満、2 ノード(TP 2・DP 2・PP 2)で 0.7%、4 ノード(TP 2・DP 4)で 0.1% だった。 **Figure 13: 単一ノード(S)と複数ノード(M)での反復時間推定の精度** ![[_attachments/atc25-wu-tianyuan/fig13-iteration-time-accuracy.png]] (Figure 13. xTyDzP は TP x・DP y・PP z。真値と推定値の反復時間はほぼ一致し、相対誤差は 0.0〜1.2% に収まる。) **Table 3: 計算フェイルスローの検知評価** | 手法 | 精度(%) | FPR(%) | FNR(%) | |---|---|---|---| | SlideWindow | 99.5(390/392) | 0.0(0/386) | 25.0(2/8) | | BOCD | 77.8(305/392) | 18.39(87/473) | 0.0(0/6) | | BOCD+V | 100.0(392/392) | 0.0(0/386) | 0.0(0/6) | (Table 3. BOCD+V(検証つき BOCD)は誤検知も見逃しもない。表の分母は原文のまま。) **Table 4: 通信フェイルスローの検知評価** | 手法 | 精度(%) | FPR(%) | FNR(%) | |---|---|---|---| | SlidingWindow | 93.5(100/107) | 1.5(1/65) | 12.2(6/49) | | BOCD | 69.2(74/107) | 34.0(33/97) | 0.00(0/43) | | BOCD+V | 99.1(106/107) | 0.00(0/64) | 2.3(1/44) | (Table 4. BOCD+V の見逃し 1 件は、10% 未満の劣化が連続する希少な事例による。素の BOCD は疑わしい変化点をすべて報告するため FNR は低いが FPR が高い。) ### 緩和の効果以下の実験は、フェイルスローの位置を GREYHOUND に教えず実行時に検知させるため、検知のエンドツーエンド検証にもなり、すべて検知精度 100% だった。 **S2(マイクロバッチ調整)。** 8 GPU の単一ノードで、DP 2・4・8 に弱(W)・中(M)・強(S)の計算フェイルスローを注入した。平均反復時間はベースラインの 1.7 倍から 1.3・1.1・1.2 倍に下がり、最大 1.52 倍の改善になる(Figure 14)。DP 4 のジョブで 0〜4 グループに中程度の低速を注入すると、低速が 1 グループのときに最も効き、反復時間が 1.31 秒から 0.83 秒(1.59 倍の改善)になる。低速グループが増えると総計算力が減り、調整の余地が縮む。全グループが遅ければ余地はない(Figure 15 左)。 **Figure 14: 各種深刻度・DP 設定でのマイクロバッチ調整の効果** ![[_attachments/atc25-wu-tianyuan/fig14-microbatch-adjustment.png]] (Figure 14. #DP=2・4・8 のそれぞれで、フェイルスロー時(青)より緩和後(橙)の反復時間が短く、健全時(緑)に近づく。) **S3(トポロジ調整)。** 2 ノード 16 GPU で PP 4 と PP 8 に通信フェイルスローを注入した。強い輻輳のとき、平均反復時間は PP 4 で最大 1.23 倍、PP 8 で 1.14 倍短くなる。PP 8 のほうが効果が小さいのは、パイプラインが長いとバブル率とアイドルが増え、効果を過小評価する設定になるためと説明する。 **Figure 16: 各種深刻度・PP 設定でのトポロジ調整の効果** ![[_attachments/atc25-wu-tianyuan/fig16-topology-adjustment-effect.png]] (Figure 16. #PP=4 と #PP=8 のそれぞれで、緩和後の反復時間がフェイルスロー時より短くなる。) ストラグラー集約の実験は 16 GPU(DP 4・PP 4)で行った。1 本または 2 本のリンクの輻輳で反復時間は 1.6〜1.7 倍になり、1 つの PP ステージに集約すると両方とも 1.3 倍に収まる。6 GPU に及ぶ 3 本の輻輳では 1.9 倍から 1.7 倍になるだけである。1 ステージは 4 GPU しか含まず、6 基のストラグラーは 2 ステージにまたがらざるを得ないためだ。全リンクが遅ければ調整の余地はない(Figure 15 右)。 **Figure 15: 低速 DP グループ数(左)と輻輳 PP ステージ数(右)への効果** ![[_attachments/atc25-wu-tianyuan/fig15-slow-dp-groups-and-pp-stages.png]] (Figure 15. 左は S2 が低速 DP グループ 1 つで最も効く様子、右は S3 のストラグラー集約が輻輳 1〜2 ステージで反復時間を 1.3 倍へ抑える様子を示す。) ### オーバーヘッド - **追跡**: 検知器なしの学習と比べ平均 0.39%、最大 1.1% である。検知器ありのほうがわずかに速い例もあり、ゆらぎの範囲である。フェイルスロー発生時は BOCD が次の 2〜3 反復で検知し、反応は通常 5 秒未満である。 **Figure 18: 各並列戦略での GREYHOUND-DETECT のオーバーヘッド** ![[_attachments/atc25-wu-tianyuan/fig18-detect-tracking-overhead.png]] (Figure 18. 検知器あり・なしの反復時間の差は 0.0〜+1.1% に収まる。) - **プロファイリング**: オフライン分析用のプロファイル収集だけで、追加のオーバーヘッドはない。 - **検証**: 計算検証は正常時に A10/A100/H800 で 0.59/0.51/0.24 秒、フェイルスロー時(GPU クロックを 300 MHz に固定)に 1.94/1.23/0.87 秒かかる。通信検証は NVLink・PCIe・RDMA のうち RDMA が輻輳に最も弱いが、3 回の繰り返しでも 3.04 秒以内に終わる。総ベンチマーク時間は重いフェイルスローや低性能 GPU でも約 5 秒である。 **Figure 17: 計算(左)と通信(右)のベンチマーク実行オーバーヘッド** ![[_attachments/atc25-wu-tianyuan/fig17-validation-overhead.png]] (Figure 17. 左は GPU 別の検証時間(A10 0.59/1.94 秒、A100 0.51/1.23 秒、H800 0.24/0.87 秒)、右は NVLink・PCIe・RDMA の検証時間(RDMA のフェイルスロー時で 3.04 秒)。) **Table 5: 最適なマイクロバッチ配分を求める時間** | DP グループ数 | 16 | 32 | 64 | 128 | 256 | 512 | |---|---|---|---|---|---|---| | 時間(秒) | 0.01 | 0.01 | 0.01 | 0.11 | 6.78 | 35.93 | (Table 5. S2 の主なオーバーヘッドは式 (1) を解く時間である。本文は 512 DP でも約 30 秒と述べ、表の 35.93 秒とは丸めが合わない。) - **S3 のオーバーヘッド**: GPU あたりのダンプ量を 10・22・38・76 GB にし、8 GPU の単一ノードで測った。ディスクベースのチェックポイント再起動と比べ、停止時間を最大 6.72 倍短くする(2.46・3.03・5.01・6.72 倍)。主にチェックポイントの書き出しと読み込みが不要になるためで、パラメータが多いほど差が開く。 **Figure 19: S3 のオーバーヘッド内訳** ![[_attachments/atc25-wu-tianyuan/fig19-s3-overhead-breakdown.png]] (Figure 19. M はメモリベースのダンプとロード(本手法)、D はディスクベースの C/R。10/80GB で 2.46 倍、22/80GB で 3.03 倍、38/80GB で 5.01 倍、76/80GB で 6.72 倍短い。) ### 大規模でのエンドツーエンド評価 GPT2-40B を 256 基の H800(TP 8・DP 16・PP 2)で学習し、12 件のフェイルスロー(通信輻輳 2 件、計算低速 10 件、深刻度はまちまち)を手動で注入した。計算と通信が同時に起きる複合ケースも作る。同じ注入スケジュールで GREYHOUND あり・なしを A/B 比較する。スケジュールは GREYHOUND に知らせない。 **Table 6: 256 H800 実験での検知精度と平均反応時間** | 通信の低速 | 計算の低速 | 検知精度 | 平均反応時間 | |---|---|---|---| | 中: 2 | 弱: 3、中: 5、強: 2 | 100% | BOCD: 3.7 秒、プロファイリングと検証: 6.86 秒、合計: 10.56 秒 | (Table 6. 12 件すべてを検知し、反応時間は BOCD の変化点通知が注入の約 4 秒後、根本原因の特定がさらに 6〜10 秒である。) 緩和では、GREYHOUND なしだと計算ストラグラーでスループットが大きく落ちるが、ありだとマイクロバッチ調整(S2)で準最適水準まで素早く回復する。通信輻輳の間は t=850 と t=2100 で 1 分未満の一時停止によるトポロジ調整(S3)を行い、輻輳解消後に t=1150 と t=2350 で元に戻す。従来のチェックポイント再起動は数十分かかる。複合フェイルスローで学習スループットは約 55% 下がるが、GREYHOUND により 25% の低下に抑えられる。 **Figure 20: 256 H800 の学習における GREYHOUND の評価** ![[_attachments/atc25-wu-tianyuan/fig20-256gpu-end-to-end.png]] (Figure 20. 上がスループット(緩和あり=青、なし=橙)で AdjustTopo の位置を示し、下が計算(青破線)と通信(赤実線)の相対性能を示す。) エンドツーエンドでは、GREYHOUND なしでは注入により 37.4 から 18.9 iter/min に落ちる。ありでは検知と検証のオーバーヘッドを含めて 29.8 iter/min まで回復し、1.58 倍の改善になる。 ## 考察 - 計算フェイルスローと通信フェイルスローは性質が違い、要求される緩和の強度も違う。前者は短命で軽い緩和(S2)で足りる。後者は長く続くため、停止を伴う S3 でも見合う。 - 段階的切り替えは、継続時間を予測しなくても、累積損失で行動を決められる点に意義がある。S4 は最後の手段として残る。 - 効果には限界がある。S2 は全 DP グループが遅ければ、S3 は全リンクが遅ければ、調整の余地がない。複数のストラグラーが PP ステージ数を超えて散らばる場合も、集約しきれない。 - PP が長いほど S3 の効果が小さく見える。これは本手法の限界というより、バブルの増える設定が効果を過小評価するためだと解釈している。 - 追跡は 5 秒未満で反応し、検証は約 5 秒の停止で済む。ゆえにジョブ全体の検証を避けられる。 ## 強み / 弱点・課題 - 強み - 512 GPU 以上の本番ジョブ 27 件を含む実運用規模の特性評価で、規模による被害の拡大を数値で示す。 - フレームワークに手を入れない検知(NCCL フック)が、既存の学習基盤へ載せやすい。 - 有効性とコストのトレードオフを、継続時間の不確実性を明示した意思決定として定式化する。 - 検知・緩和の両方を、オーバーヘッドと反応時間つきで評価する。 - 弱点・課題(論文が述べるもの) - 計算と通信のカーネルが特定パターンで同時実行されたときにだけ現れるフェイルスローは検知できない。 - 緩和は訓練フレームワークの支援を要し、完全な非侵入にはできない。実装は Megatron-LM のプラグインである。 - TP は通信フェイルスローに晒されないため、TP の調整は無効とされる。 - 読み取れる懸念 - 緩和の評価は手動注入したフェイルスローが中心で、本番トレース上で緩和まで閉じて評価した結果はない。 - エンドツーエンドの比較対象は GREYHOUND なしの場合だけで、他の緩和手法との比較はない。 - 特性評価は 1 組織の 1 クラスタが母集団であり、小規模プロービングは同一構成のジョブの繰り返しである。 - 継続時間の分布が変わると、累積損失で切り替える方針の閾値の妥当性は変わりうるが、その感度は示されていない。