> [!abstract] 概要(abstract の日本語訳) > 大規模 DNN モデルの訓練には、数日〜数週間にわたって数千 GPU が必要である。この規模ではハードウェア障害が頻発し、訓練スループットに大きな影響を与える可能性がある。障害によるパフォーマンス低下を緩和するためにスペア GPU サーバを使う方法は、モデルサイズが拡大するにつれてコストが増大する。ReCycle は、スペアサーバに頼らずに障害が存在しても効率的な DNN 訓練を行うために設計されたシステムである。ReCycle は、分散訓練システムに内在する機能的冗長性——データ並列グループにわたるサーバが同一モデルパラメータを保持する——と、各データ並列グループ内のパイプラインスケジュールのバブルを利用する。サーバが障害を起こすと、ReCycle はマイクロバッチをデータ並列ピアへ動的に再ルーティングし、複数の障害が存在してもトレーニングを中断なく継続する。しかしこの再ルーティングにより、パイプラインステージをまたいだ不均衡が生じ、訓練スループットが低下する可能性がある。この問題に対処するため、ReCycle は再ルーティングされたマイクロバッチが元のパイプラインスケジュールのバブル内で処理されるよう保証する 2 つの重要な最適化を導入する。第一に、逆伝播を 2 つのフェーズに分離する。1 つは入力に対する勾配を計算するもの、もう 1 つはパラメータの勾配を計算するものである。第二に、オプティマイザステップをパイプラインステージをまたいでずらすことでパイプラインステージ間の同期を回避する。これら 2 つの最適化を組み合わせることで、障害時の訓練スループット低下を最小化または完全に排除するアダプティブパイプラインスケジュールが実現する。ReCycle のプロトタイプを実装し、複数の障害下でも高い訓練スループットを達成することを示す。Oobleck および Bamboo などの最近の耐障害訓練提案を最大 1.46× および 1.64× 上回る性能を実証した。 ## 論文情報 - **タイトル**: ReCycle: Resilient Training of Large DNNs using Pipeline Adaptation - **著者**: Swapnil Gandhi, Mark Zhao, Athinagoras Skiadopoulos, Christos Kozyrakis(全員 [[Stanford University]]) - **発表媒体**: ACM SIGOPS 30th Symposium on Operating Systems Principles (SOSP '24) - **発表年月**: 2024年11月(Austin, TX, USA) - **arXiv**: 2405.14009v2 [cs.DC] 投稿 2024-09-25 - **DOI**: https://doi.org/10.1145/3694715.3695960 - **コード**: 記載なし(DeepSpeed 上にプロトタイプ実装) - **謝辞**: Stanford Platform Lab・JUMP 2.0 (SRC/DARPA の ACE センター)の支援 ## 概要 ReCycle は、ハイブリッド並列(データ並列・テンソル並列・パイプライン並列の組み合わせ)で大規模 DNN を訓練する際、スペアサーバを持たずに障害から回復するシステムである。同一パイプラインステージのパラメータを持つデータ並列ピアへマイクロバッチを動的に再ルーティングする「適応的パイプライン」に加え、分割逆伝播とストラグラーオプティマイザの 2 技術でバブルを最大活用し、障害時のオーバーヘッドを実質ゼロに近づける。32 GPU クラスタの実証実験で Oobleck を最大 1.46× 上回り、シミュレーションで 145.6B パラメータ GPT モデルを 10% GPU 障害率でも障害スケール済みスループットの 0.5〜11.5% 低下以内に収めた。 ## 問題設定 - **入力**: ハイブリッド並列(DP × PP × TP 次元)で構成された大規模 DNN 訓練ジョブ。数千 GPU で数週間実行する。 - **前提**: 障害(ノード単位)が定常的に発生(MTBF が分単位になりうる)。OPT-175B 訓練では 178,000 GPU 時間が障害で無駄になった例がある。 - **既存アプローチの課題**: - **スペアサーバ方式**: スペアは PP×TP 個単位が必要で、530B 訓練では 280 台のスペアが必要(コスト 11% 増)。 - **Elastic batching**: DP グループ全体をオフラインにするため障害の爆風半径が大きい。1 台障害 → 280 台ダウンという例がある。 - **Bamboo**: 障害なし状態でも冗長計算でスループットが低下し、GPU メモリ消費が増大。大モデルは OOM になる。 - **Oobleck**: 障害ごとにパイプラインテンプレートを切り替えるが、ヘテロジニアスパイプラインによる不均衡とパラメータ再シャッフルのコストが問題。 ## 提案手法 ### 全体設計: 3 つのコアコンポーネント **図8: ReCycle システム概要** ![[_attachments/arxiv-2405.14009/fig08-system-overview.png]] (Figure 8. ReCycle system overview. オフラインフェーズの Profiler・Planner がアダプティブスケジュールを事前計算し、オンラインフェーズの Coordinator が障害検知時に適切なプランを Executor 群に配信する。) - **Profiler**: 訓練ジョブ起動時に 100 イテレーション程度を実行し、マイクロバッチレイテンシ・メモリ要件・帯域幅を計測する。 - **Planner**: 動的計画法(DP)+ 混合整数線形計画法(MILP)で障害数ごとのアダプティブスケジュールを事前計算。etcd 等の分散耐障害ストレージに保管する。 - **Coordinator**: Executor 群を中央管理し、障害検知時に Planner の計画を適用してマイクロバッチの再割り当てを指示する。自身も active replication で可用性を確保。 - **Executor**: 各 GPU ノードに配置。Coordinator の計画に基づいて訓練ステップを実行。ハートビートで Coordinator に状態を通知。 ### 技術 1: 適応的パイプライン(Adaptive Pipelining) **図2: 適応的パイプラインの動作** ![[_attachments/arxiv-2405.14009/fig02-adaptive-pipelining.png]] (Figure 2. W1_2 障害時の適応的パイプライン。W1_1 からのマイクロバッチは W0_2 と W2_2 に動的再ルーティングされ、訓練が中断なく継続する。) - ハイブリッド並列では、同一パイプラインステージを担う複数のデータ並列ワーカーが同一パラメータを保持する。これを「機能的冗長性」と呼ぶ。 - 障害発生時: 障害ワーカー W_{k}_{i} のマイクロバッチを、同ステージ i の他のデータ並列ピア(W_{0}_{i}, W_{2}_{i} 等)に均等に分配する。 - **パラメータ再シャッフル不要**: ピアは既に同一パラメータを保持しているため、Oobleck のような全パイプライン再構成は不要。 - 理論上の耐障害保証: 最悪ケース(全DP分を同一ステージで失う)でなければ DP-1 台の同時障害まで保証。確率的にはそれ以上も継続可能。 - バブルの可用性: LLaMA-3 405B(TP=8, PP=16, DP=64)では 3×(PP-1)×DP = 2880 バブル/イテレーション、バッチサイズ 2048 で最大 30 同時障害を吸収可能。 **問題点**: マイクロバッチの再ルーティングが 1F1B のステディフェーズ(バブルゼロ)で発生するため、バブルを活用できず追加スロットが必要になる。1ワーカー障害(8.3%)で 33% のイテレーション時間増が生じる素朴実装の例がある。 ### 技術 2: 分割逆伝播(Decoupled BackProp) 逆伝播は本来 B_input(入力勾配)と B_weight(パラメータ勾配)を結合した計算として行われる。分割逆伝播はこれを 2 フェーズに分離する。 - **B_input**: 次ステージへの依存あり(ステージ i+1 の B_input が終わるまで待つ必要あり)。 - **B_weight**: ステージ間依存なし。後でまとめて実行できる。 B_weight の計算をクールダウンフェーズのバブルに押し込むことで、ステディフェーズの競合を減らし再ルーティングされたマイクロバッチの処理に空きスロットを与える。 **メモリ上の工夫**: B_weight 遅延のために中間データを長時間保持する必要があるが、パイプラインステージ間のメモリ不均衡(後段ほど少ない)を活用し、追加メモリ圧力を吸収する。MILP がメモリ制約を明示的にモデリングする。 アブレーション結果: Adaptive Pipelining だけでは GPT-3 Medium で 0.46(障害なしの 46%)。分割逆伝播の追加で 0.75 へ 63% 向上、さらにストラグラーオプティマイザで 0.81 へ 7〜11% 上昇する。 ### 技術 3: ストラグラーオプティマイザ(Staggered Optimizer) 1F1B スケジュールには、各イテレーションのウォームアップフェーズ(最初のバブル群)とクールダウンフェーズ(末尾のバブル群)がある。分割逆伝播はクールダウンバブルを活用するが、ウォームアップバブルは前イテレーションのオプティマイザステップの後に来るため活用できない。 ストラグラーオプティマイザはパイプラインステージごとのオプティマイザステップをずらす(後段ほど遅延)。これにより後段ステージの B_weight をさらに遅延でき、クールダウンフェーズのバブルを実質的に増やしてウォームアップのバブルも再ルーティング作業に転用できる。 **数値安定性の処理**: オプティマイザステップがステージごとにずれると、全段同期の numerical validation が困難になる。解決策として validation をポストステップに移し、各ステージが自律的に検証後にオプティマイザを実行。問題があれば全段が次イテレーション前にロールバックする。 ### Planner の 2 フェーズ 1. **障害正規化(Failure Normalization)**: 動的計画法で F 件の障害を PP ステージに最適分配する。複雑度 O(PP × F)。複数の任意障害位置を「後段のバブルが多いステージへ集約」する正規化座標へマッピングする。 2. **アダプティブスケジュール生成**: MILP でクロスステージ依存・ステージ内依存・メモリ制約・タイミングを最適化し、イテレーションのメイクスパン最小化を目的とする。Gurobi ソルバーで 96 コア CPU 上に計算。2048 GPU (DP=32, PP=64) で最大 512 障害分のスケジュール計算が 3,153 秒(52.5 分)——長期訓練の 0.1% 未満のオーバーヘッド。 **図1: ハイブリッド並列化の概念図** ![[_attachments/arxiv-2405.14009/fig01-hybrid-parallelism.png]] (Figure 1. Illustration of hybrid parallelism. パイプラインステージを色分けで示し、テンソル並列化(ステージ内)とデータ並列化(パイプライン間)を組み合わせた 3 次元ハイブリッド並列化の構造。) ## 新規性 | 観点 | 既存手法 | ReCycle | |------|---------|---------| | スペア機 | 必要(コスト 11%+) | 不要 | | Bamboo | 障害なし時も冗長計算でオーバーヘッド・大モデル OOM | 障害なし時のオーバーヘッドなし | | Oobleck | 障害時にパイプライン全体を再構成・ヘテロジニアス不均衡 | パラメータ再シャッフルは最大 1 GPU 点対点コピーのみ | | 弾力的バッチング | 障害 DP グループ全体をオフライン(爆風半径大) | ピアへ分散ルーティングで最小限の影響 | ReCycle の核心的新規性は「バブルをアダプティブスケジューリングの資源として明示的に最大活用する」という設計思想にある。従来手法はバブルを定常的なアイドルスロットとして扱っていたが、ReCycle は分割逆伝播とストラグラーオプティマイザで B_weight 計算をバブルに詰め込むことで、障害対処のオーバーヘッドを実質的に隠蔽する。 ## 実験設定 - **実機クラスタ**: Azure 上の 32 GPU(NVIDIA A100 80GB)。Standard_NC96ads_A100_v4 インスタンス(8 GPU・96 vCPU・880 GB メモリ)。NVLink 600 GB/s(ノード内)・8 NIC 640 Gbps(ノード間)。 - **シミュレータ**: 実測プロファイルを基に大規模クラスタを模擬(最大 1536 GPU / GPT-3 145.6B 相当)。実測との乖離最大 5.98%(表 2)。 - **ワークロード**: GPT-3 の Medium (350M)・3.35B・6.7B。実機では wikitext で訓練。バッチサイズ 8192/1024。 - **ベースライン**: Bamboo, Oobleck(全最適化有効)、障害なし DeepSpeed(1F1B)。 - **障害設定**: 実験 1——6 時間/2 時間/30 分に 1 回の障害頻度(workers 単調減少)。実験 2——GCP インスタンス実障害トレースを再生(24 GPU, 6 時間, 15〜24 GPU で変動)。 - **スケーラビリティ**: GPT-3 18.4B/39.1B/76.1B/145.6B の 1%/5%/10% GPU 障害率をシミュレーションで評価。 ## 実験結果 **表 1: 訓練スループット(samples/sec、高いほど良い)** | システム | GPT-3 Medium (6h/2h/30m) | GPT-3 3.35B (6h/2h/30m) | GPT-3 6.7B (6h/2h/30m) | |---------|--------------------------|--------------------------|------------------------| | DeepSpeed(障害なし) | 27.58 | 14.87 | 5.33 | | Bamboo | 19.47 / 18.98 / 15.24 | OOM | OOM | | Oobleck | 27.26 / 25.37 / 19.47 | 14.55 / 13.44 / 9.78 | 4.98 / 4.65 / 2.78 | | **ReCycle** | **27.27 / 25.42 / 22.27** | **14.59 / 14.17 / 12.63** | **5.17 / 4.85 / 3.53** | **GCP トレース再生実験**: GPT-3 6.7B で Oobleck 対比 1.46×、GPT-3 Medium で Bamboo 対比 1.64× のスループット向上。Bamboo は 6.7B を OOM で訓練不可。 **アブレーション(図 11)**: **図11: 3 技術の貢献** ![[_attachments/arxiv-2405.14009/fig11-ablation.png]] (Figure 11. The contribution of the three optimization techniques to ReCycle's training throughput. 障害なしを 1.0 として正規化。Adaptive Pipelining のみでは 0.46〜0.35。分割逆伝播追加で 0.75〜0.59。ストラグラーオプティマイザ追加で 0.81〜0.66。) - Adaptive Pipelining のみ: 0.46 (Medium) / 0.35 (3.35B) / 0.35 (6.7B) - + Decoupled BackProp: 0.75 / 0.77 / 0.59(63〜118% 向上) - + Staggered Optimizer: 0.81 / 0.85 / 0.66(7〜11% 向上) **スケーラビリティ(図 10)**: **図10: スケーラビリティ評価** ![[_attachments/arxiv-2405.14009/fig10-scalability.png]] (Figure 10. Simulated throughput of ReCycle as model size increases. Fault-Free, Fault-Scaled(故障率×障害なしスループット)、ReCycle の 3 線を比較。1% 障害率では ReCycle が Fault-Scaled を上回り、10% 障害率でも 0.80〜0.99 を維持。) - 1% 障害率: ReCycle が全モデルサイズ・全クラスタサイズで Fault-Scaled 以上のスループット。 - 5% 障害率: Fault-Scaled に匹敵。 - 10% 障害率: Fault-Scaled から 0.5〜11.5% の低下のみ。 **Planner レイテンシ**: 2048 GPU (DP=32, PP=64) で最大 25% 障害まで全スケジュール計算が 3,153 秒。訓練全体の 0.1% 未満。 ## 考察 - ReCycle の優位性の源泉は 2 点に絞られる。①パラメータ再シャッフルがほぼ不要で障害後の復旧が高速(Oobleck の全パイプライン再構成と対比)。②障害なし時のオーバーヘッドがゼロ(Bamboo の冗長計算と対比)。 - 分割逆伝播の恩恵は「ステージ間のメモリ不均衡」という既存のアーキテクチャ的特性に依存する。後段ほどメモリが空いていなければ B_weight を遅延させる余地がない。 - Staggered Optimizer は validation の pre-step→post-step 変更が必要で、オプティマイザの種類によってはロールバックのコスト(特に非可逆な演算を含む場合)が変わる。AdamW はロールバックが追加メモリコストなしで行えるため相性が良い。 - シミュレーションと実測の乖離(最大 5.98%)は、NCCL 集合通信の微細な実行時間変動に起因する。 ## 強み・弱点・課題 ### 強み - 障害なし時のオーバーヘッドなし——既存手法と比べてフェアな出発点で競争できる。 - パラメータ再シャッフルがほぼ不要で障害後の再起動が速い。 - Planner は事前計算で障害発生をクリティカルパスから外せる。 - 10% 以上の GPU 障害率でも Fault-Scaled に近いスループットを維持する。 ### 弱点・課題 - 同一 DP グループ全体が失われる最悪ケース(DP グループの全サーバ障害)ではチェックポイントからの復旧が必要。 - Planner の MILP 計算が PP・DP 次元が大きくなると指数的に増大する。PP=64, DP=32 で 3,153 秒/1 回の事前計算は許容範囲内だが、動的に Planner を更新する場合はより小さい設定に限定される。 - DeepSpeed 上のプロトタイプ実装で評価しており、他フレームワーク(Megatron-LM, Alpa 等)への移植は追加作業が必要。 - ZeRO スタイルのデータ並列(パラメータを DP グループで分割)は機能的冗長性がなくなるため、ReCycle の前提と相容れない。DP グループ全体に同一パラメータがある標準的なハイブリッド並列前提。 - 評価は GPT-3 スタイルの Dense Transformer に限定されており、MoE(Mixture-of-Experts)への適用は検討されていない。