# 弾性LLM訓練 ## 定義 弾性 LLM 訓練は、ノードの追加・削除・障害が発生したときに訓練ジョブの GPU 数や並列設定を動的に変更して中断なく継続させる能力の総称。3D 並列(データ並列・テンソル並列・パイプライン並列)が提供する内在的な弾力性(parallelism 軸ごとの設定変更で同じ訓練セマンティクスを保てること)を活用する。弾性を持つことで、ノード障害時に残存ノードで縮退(scale-in)しつつ訓練を継続でき、新規ノードが加わったら再拡張(scale-out)できる。(Source: [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]]) ## 横断的知見 - **弾性はスループットとのトレードオフを内包する——Megatron を上回る訓練効率と弾性の両立は 2024 年時点では未解決**: Oobleck・Bamboo・Varuna は弾性を持つが、Megatron と比べてスループットで著しく劣る(図3: GPT-3 7B、64 GPU で Oobleck・Bamboo・Varuna は Megatron の 60〜80% 程度)。Unicron はこの問題を「弾性を Megatron の外側(ワークロードマネージャ層)に置く」ことで解決し、Megatron の最適化をそのまま継承しながら自己修復と弾性を実現した。(Source: [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]]) - **GPU 数と実効スループットの関係は非線形・非単調——単純に GPU を増やしても性能が下がることがある**: Megatron の図4 が示すように、48 GPU クラスタに 8 台追加して 56 GPU にしても、並列設定の最適組合せが存在しないためにスループットが低下するケースがある。弾性設計は「最適並列設定を動的推定する」能力を不可欠な要件として含む。(Source: [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]]) ## 未解決の問い - 弾性を「ワークロードマネージャ層で提供」する Unicron アプローチと、「訓練フレームワーク自体に組み込む」Oobleck/Bamboo アプローチは、スケールが 1,000 GPU を超えるとどちらが ETTR を高く保てるか。 - 並列設定の最適推定（T(t, x) の精度）は、クラスタキャリブレーション + 自動実行プラン生成に依存する。新規ノード参加・GPU ヘテロジェニティへの対応精度はどれほどか。 - 弾性訓練でも訓練の再現性（同じモデル収束を保証）は完全に維持できるか。グラジェントの再分配・部分蓄積再利用が数値的一貫性に与える影響。 ## 関連 - ソース: [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]] - 概念: [[耐障害LLM訓練]] / [[LLM分散学習]] / [[チェックポイント]] - エンティティ: [[Unicron]] / [[Megatron-LM]] / [[Alibaba Group]] - 関連 MOC: [[分散深層学習 - MOC]] ## 出典 - [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]](§2 Background: 3D parallelism の弾力性、§3 System Design: Unicron の弾性設計、§4 Error Handling, §5 Plan Generation, §7 Evaluation: 図3・図4・図10)