本ノートは、[[LLM学習]]に用いられる計算機クラスタの実行効率と障害による問題を既存文献を基に整理する。 ## 実行効率の問題 [[2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]]では、ディープラーニングジョブのGPU利用について、706の低GPU利用問題を取り上げ、次のようにその原因が分類されている。粗粒度では、Model要因が45%、Data要因が46%である。 細粒度では次の項目が上位の要因である。 - Improper Batch Size: 25% - Inefficient Host-GPU Data Transfer: 28% - Model Checkpointing: 16% - Data Exchange: 7% ![[Pasted image 20241010153842.png]] ## 障害による問題 ディープラーニングのトレーニングジョブが失敗したときの症状として、[[2023__ICSE__An Empirical Study on Quality Issues of Deep Learning Platform]]より、55%がジョブのクラッシュ、次点の14%がジョブの投入失敗、13%がジョブの異常な振る舞いと続く。 ![[Pasted image 20241009234739.png|600]] 共通の根本原因は、ハードウェア、プラットフォーム、ユーザーの2:2:3の割合で分類される。 ![[Pasted image 20241009234828.png|600]] ハードウェアの故障28%のうち、ノードの故障が16%、GPUが5.5%、ネットワークが7%の内訳となった。 ![[Pasted image 20241009234846.png|600]] LLM学習のインフラに特化したサーベイである [[2024__arXiv__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] によると、各文献で次のように報告されている。 - Acme [23]によると、最も深刻な影響は、GPU(例:CUDA-Error、ECC-Error)、NVLink、ネットワークシステム(例:NCCL-Timeout -Error、Connection-Error)の問題などのハードウェア障害に起因する。 - 同様の観察は、Alibaba C4 [377]でも行われている。C4はさらに、エラーの大部分(約82.5%)は特定のノード、あるいは 個々のデバイスに限定されていることを観察しているが、ユーザーが観察するエラーのほとんどはNCCLエラーである。 - LlaMA3の事前学習[9]でも、障害の78%がハードウェアの問題であると報告されている。 - 最新世代の GPU(A100 と H 100)は、急速な開発、急速な配送、消費電力の増加 [377], [399] に起因すると思われる高いエラー率を示す傾向がある。 - ハードウェアだけでなく、分散学習フレームワーク、データ 前処理パイプライン、またはライブラリ依存性におけるソフ トウェア関連の問題は、クラッシュや予期せぬ動作につなが る可能性がある [23], [378], [399]。 - モデル自体の複雑な性質は、損失jスパイク、数値オーバーフローやアンダーフロ ー、勾配爆発、最適化の困難さなどの不安定性を導入する可能性がある[398]、[400]。 - クラスタサーバルームの温度が高いと、GPU が過熱する傾向があり、NVLink-Error や ECC-Error [23]、あるいは学習速度が不安定になる [9]。（[[LLaMA3]]） このような頻繁なエラーにより、GPUが浪費される。故障の回復と性能の低下を招き、ネットワークリンクの障害[377]や計算速度の異常[71]によって引き起こされるクラスタ内のストラグラーは、MFUを大幅に低下させ、全体的な学習の非効率性をさらに悪化させる可能性がある [[2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]は、ごく一部のマシン(約0.5%)が学習中に大幅に性能が低下し、学習全体の進捗が阻害されている、と報告している。したがって、一部のマシンの不調を自動か手動で検出することが求められる。 [[2023__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]]によると、LLM学習タスクの失敗率は、リソース集約的な上位5%のタスクで43.4%に急上昇することがわかった。(Fig. 1)失敗の内訳の上位は、NCCLタイムアウト（10.1%）、ECCエラー（5%）、NVLinkエラー（4.5%）、リンクフラッピング（3.9%）である。 128 GPUの典型的なセットでは、1週間に1〜7回の頻度で故障が発生し、平均故障間隔は1日以上である。 ![[Pasted image 20241010172822.png|600]]** また、Fig.2ではAlibaba Cloud上でGPT-3トレーニング中のエラー回復パスが説明されている。 ![[Pasted image 20240910222313.png]] - エラーの73%は一時的で、トレーニング再開により解決可能 - All-Recuce通信タイムアウトで最大30分のシステムハング発生 - タスク終了後、以下の時間が必要 - タスク再投稿に9分 - 環境とCUDA設定に14分 - 再計算に15分 - 合計ダウンタイム：68分 - ハードウェア故障が発生した場合、37%のケースでノード排水（ドレイン）が必要 - 手動での故障特定、ノード排水、Megatron構成縮小、チェックポイント再調整が必要 - 回復作業には数時間から数日かかる可能性 - システムは「能力が制限された状態」で稼働 - GPUリソースの不足と高コストにより、故障は訓練時間の浪費に直結 - これにより、経済的損失が増大 さらに、Fig.3より、スループットとFLOP/sの損耗率が、障害耐性に特化した分散学習システムよりも効率性を重視したMagatronのほうがスループットが高い。わずか2％のダウンタイムが、最適なシナリオの3倍以上のスループットロスにつながる可能性があることがわかる。 ![[Pasted image 20241010185106.png]] Table 1は、ノードレベルの接続消失、ECCエラー、DMAマッピングの不整合、NVLinkエラー、GPUドライバーエラーの重大度が最も高いことを示している。 ![[Pasted image 20241010224918.png|500]] --- [[2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] ![[Pasted image 20260213153041.png]] > Slurm can run checks before and after a job runs [10]. Moreover, we have health checks that are periodically scheduled to run every five minutes and return codes indicating success, failure, or warning. Each health check examines some aspect of node health, spanning from GPU errors (e.g. XID errors [9]) to file system mounts, and services status (i.e., scheduler). Note that checks can have overlapping signals into a failure domain.  > In the first category of check are the following: GPU not accessible, an NVLink error, uncorrectable ECC, failed row-remaps, PCI or IB link errors, block device errors, and missing mountpoints.