LLM分散学習 - yuuk1's Digital Garden

# LLM分散学習 ## 定義 LLM 分散学習は、数千億パラメータ・terabyte 規模データの大規模言語モデルを、数千〜数万の GPU/AI accelerator クラスタ上で数週間〜数ヶ月かけて訓練する営みと、それを支えるシステム・インフラの総体。従来 DL と異なり、(1)アーキテクチャがほぼ Transformer に統一され特定アーキテクチャ向け最適化の余地が大きい、(2)前例のない規模と訓練時間、(3)専用ソフトウェア最適化を要する、(4)task-specific から self-supervised な foundation model 構築へのパラダイム転換、という特性を持つ。([[2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] §2) 設計上の横断課題は **SER**——Scalability(数万 accelerator への near-linear スケール)・Efficiency(MFU = Model FLOPs Utilization の最大化)・Reliability(長期訓練での障害検知と高速復旧)——の 3 軸に集約される。技術スタックは ① インフラ(accelerator/network/storage/scheduling)、② 並列化([[並列化戦略]])、③ 計算/メモリ/通信最適化、④ fault tolerance の 4 層で整理できる。 ## 横断的知見 - **「異常検知」「failure 起因分析」は運用 observability と訓練インフラで語彙を共有するが対象が異なる**: 本サーベイ §8.2 の anomaly detection は、各 GPU の heartbeat・NVIDIA DCGM メトリクス(SM occupancy/PCIe/NVLink traffic)・network メトリクスを監視し、straggler や hang を検知する。これは既存 wiki の [[テレメトリ]]・[[分散トレーシング]]・[[Fault Localization]] が扱う「本番マイクロサービスの運用時診断」と同じ語彙(metrics 監視・異常検知・failure 起因の特定)を用いるが、対象は **訓練クラスタのハードウェア健全性**であって service の障害ではない。LLaMA3 が「障害の 78% は hardware 起因」と報告する(§8.1)のは、AIOps 系ソースが扱う software/構成起因の障害分布とは性質が異なる。(Source: [[2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]], [[2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **MFU という効率指標**: 本サーベイは LLM 訓練効率を MFU で定量化し、LLaMA3 ですら 16,384 H100 で 38〜41% に留まると報告する。これはスケールに伴う利用率劣化という、[[時系列データベース]]の ingestion スループットや [[HeteroTSDB]] の tiering 効率とは別軸の「大規模分散計算の利用率」問題を示す。(Source: [[2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **MFU の絶対水準は専用 co-design で大きく動く(survey の一般値 vs MegaScale の実測)**: サーベイが LLaMA3 で 38〜41% MFU と報告する一方、[[2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] は 12,288 GPU・175B で 55.2% を達成し、ベースの [[Megatron-LM]] 比 1.34×、256 GPU の ablation では 47.7%→65.3% と累計 +17.6% を積む(Table 2/3)。SER の Efficiency 軸は「数万 GPU では 40% 前後に落ちる」という宿命ではなく、algorithm-system co-design でどこまで押し戻せるかという設計問題であることを 2 ソースの突き合わせが示す。(Source: [[2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **Reliability 軸は本番で「100 回超の自動復旧」という具体形を取る**: サーベイ §8 が fault tolerance を checkpoint/recovery・anomaly detection・checkpoint-free recovery として体系化するのに対し、MegaScale は数週間の本番 run で 100 回超 restart し、障害の 90% 超を robust training framework が自動検知・特定・復旧、検知+診断は平均 10 分未満・追いつき 15 分以内で有効訓練時間率 90% 超を実測する(§6.2/§6.3)。SER の Reliability が運用上どの粒度の数字になるかの参照点。(Source: [[2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **訓練クラスタの可観測性は本番サービス AIOps と同じ「distributed-view 診断」課題に当たる**: MegaScale §5 は単一 GPU の GEMM micro-benchmark では straggler を検出できず、CUDA event の heat-map と DP/PP/TP の distributed timeline trace で初めて root cause を特定する。これは [[分散トレーシング]]・[[Fault Localization]] が本番マイクロサービスで論じる「単一ノード視点では見えず、分散 view の相関で初めて起因を特定する」構図と同型であり、対象(訓練クラスタ HW vs service)は違えど診断方法論を共有する。(Source: [[2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - **MFU 38〜41% は hyperscale 固有でなく mid-scale production でも再現する(3 ソース目)**: サーベイの LLaMA3 38〜41%(16,384 H100)、MegaScale の 55.2%(12,288 GPU・co-design あり)に対し、[[2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] は標準スタックの GPT-3 175B pretraining で 800 GPU 規模ながら MFU 35.9〜41.2%(32–96 ノード、§6.6 Table 9)を出す。専用 co-design なしの mid-scale 構成がサーベイの hyperscale 一般値と同水準に収まることは、MFU の支配要因が GPU 数そのものより並列化構成・通信隠蔽・interconnect 品質にあることを 3 ソースの突き合わせで補強する。(Source: [[2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) - **Reliability 軸の「hardware 起因 dominant」は 800 GPU 規模でも成立する**: サーベイは LLaMA3 で障害の 78% が hardware 起因、Alibaba で 1,000 GPU 規模 84.8%/日、MegaScale は数週間で 100 回超の自動復旧と報告する。[[2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] は 3 ヶ月 21 件の fault のうち GPU 関連(ECC/HW/unresponsive)が 42.9% で最多、interconnect switch 23.8%、NVLink/NVSwitch/PCIe 19.0% と、合計で大半が hardware 起因という分布を 800 GPU 規模で示す(§7.2 Obs.6)。一方 hyperscale と違い大半は node-level restart で数分復旧し、modular server 設計と Slurm drain が blast radius を封じ込める。SER の Reliability が規模を下げると「件数も復旧コストも縮む」連続性を示唆。(Source: [[2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]], [[2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **interconnect は proprietary(InfiniBand)前提でなくフルオープン Ethernet でも SER を満たせる**: MegaScale・サーベイが暗黙に高品質 interconnect(自社 datacenter network / InfiniBand 級)を前提とするのに対し、[[2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] は SONiC + RoCEv2 のフルオープン 800 GbE で NVIDIA Eos(InfiniBand)比 time-to-train 1.02–1.26× を達成し、interconnect の選択自由度が Efficiency を致命的に損なわないことを実証する。ただし ECN/PFC/NCCL channel striping の cross-layer チューニングという運用負荷を代償に要する(→ [[オープンネットワーキング]])。(Source: [[2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) ## 未解決の問い - 訓練インフラの anomaly detection(§8.2:statistical monitoring + proactive validation)と、本番サービスの AIOps 異常検知([[Fault Localization]]/[[テレメトリ]])は、手法・指標を相互転用できるか。GPU heartbeat/DCGM ベースの監視は service-level telemetry mining と統合しうるか。 - SER の 3 軸はトレードオフ関係にある(例:checkpoint 頻度を上げると reliability は増すが efficiency は下がる)。3 軸を同時最適化する統一フレームワークは存在するか。 - future direction の optical computing / optical network(silicon photonics)は、digital 回路ベースのどの層(accelerator/network)から実用化が進むか。これは本サーベイ刊行後(2024-07 以降)の動向で検証すべき。 - 大規模化で障害率が悪化する(Alibaba:単一ノード 1.5%/日 → 1,000 GPU 規模で 84.8%/日)。checkpoint-free recovery(live migration / module redundancy)は checkpoint-based をどこまで置換できるか。MegaScale は 2 段階 checkpoint(host memory への数秒書き込み + 非同期 HDFS 転送)で reactive 復旧を高速化するが、checkpoint-free の本番採用例はまだ見えていない。 - MegaScale の co-design 技術(各並列化次元の通信オーバーラップ・O(n) 初期化・distributed-view 診断)は Ampere・自社 datacenter network 前提だが、どこまで他ハードウェア/他組織に一般化するか。サーベイの一般原則と本番固有チューニングの境界はどこか。 - mid-scale(100–1,000 GPU)・単一テナントの運用観測([[2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])は、hyperscale multi-tenant(Jeon 2019/Kokolis 2025/MegaScale)と何が連続し何が不連続か。歪んだ資源消費分布は tenancy-independent とされるが、cancellation 支配・フェーズ遷移はどこまで規模・テナンシーに依存するか(→ [[GPUクラスタ運用]])。 ## 関連 - ソース: [[2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]] / [[2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] / [[2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] - 概念: [[並列化戦略]] / [[Mixture-of-Experts]] / [[GPUクラスタ運用]] / [[オープンネットワーキング]] - エンティティ: [[Shanghai AI Laboratory]] / [[Jiangfei Duan]] / [[Peng Sun]] / [[MegaScale]] / [[ByteDance]] / [[Megatron-LM]] / [[SAKURAONE]] - 弱い接点(別ドメイン): [[Fault Localization]] / [[テレメトリ]] / [[分散トレーシング]](運用 observability、語彙を共有) - 関連 MOC: [[分散深層学習 - MOC]] / [[HPC - MOC]] ## 出典 - [[2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]](§2 Background/Challenges, §3 Infrastructure, §8 Fault Tolerance, §9 Conclusion) - [[2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]](§1 Introduction, §3 Efficient Training, §4 Fault Tolerance, §5 Troubleshooting, §6 Experience) - [[2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]](§6.6 MLPerf Training, §7 Observations, §8.1 System Implications)