# LLM分散学習 ## 定義 LLM分散学習は、数千億から兆規模の言語モデルを、数百から数万 GPU/AI アクセラレータ上で長時間訓練するためのシステム・運用・インフラの総体である。主要な設計軸は SER、すなわち Scalability、Efficiency、Reliability であり、技術スタックはインフラ、[[並列化戦略]]、計算/通信最適化、[[耐障害LLM訓練]] に分けられる。([[Efficient Training of Large Language Models on Distributed Infrastructures]]) このページは親ページとして、分散学習システム全体の地図を保持する。並列化の詳細は [[並列化戦略]]、実行時監視は [[LLM学習モニタリング]]、復旧設計は [[耐障害LLM訓練]]、クラスタ運用は [[GPUクラスタ運用]]、通信プリミティブは [[集合通信]] に置く。 ## 横断的知見 - **分散学習のネットワーク帯域目標は、GPU数やパラメータ数だけでなく計算・通信オーバーラップから決まる**: [[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]]は、データ並列の逆伝搬時間が通信時間より長ければ通信が隠れ、短ければGPU idle時間が増えることを示す。1 StepあたりのAllReduce送信量は分散GPU数とパラメータ数から概算できるため、ネットワークの過剰な高性能化を避けつつ、通信を計算時間内に収めるアプリケーション依存の目標値を設定できる。(Source: [[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]]) - **100B規模の事前学習では、データ・数値安定性・並列化を一体で設計する必要がある**: [[PLaMo-100B]]は2T tokenのデータパイプライン、QK Normalizationとz loss、3D parallelismとZero Bubbleを同時に組み合わせた。記事は各手法の学習安定化効果を単独には切り分けられていないと明記しており、超大規模ランでは再現実験コストがSER評価の制約になる。(Source: [[@2024__Preferred Networks__1,000億パラメータ規模の独自LLM「PLaMo-100B」の事前学習]]) - **SER は独立軸ではなくトレードオフである**: MFU を上げる通信隠蔽や巨大 batch は効率を上げるが、障害復旧・チェックポイント・運用複雑性を増やす。MegaScale、SAKURAONE、ByteDance の各システムは、同じ SER を異なる制約下で最適化している。PTD-P(SC 2021)が 1T パラメータで MFU 52% を達成したのは、正確な並列化配置とインターリーブドスケジュールの相乗によるものであり、単一軸最適化では到達できなかった。([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]]) - **訓練クラスタ診断は AIOps と語彙を共有するが、信号源が違う**: サービス AIOps は不均質な依存グラフを使う一方、LLM 訓練では均質な並列ワーカー群から外れた GPU/ノード/通信を探す。([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - **効率は大域設計と局所チューニングの両方で動く**: MegaScale の並列化・通信オーバーラップ、SAKURAONE の open Ethernet チューニング、PMBS の ZeRO/batch/NCCL 設定探索は、同じ Efficiency 軸の異なる層である。([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]]) - **Reliability はチェックポイントだけでなく検知・隔離・復旧時間の問題である**: 大規模化で MTTF は GPU 数にほぼ反比例し、10万 GPU 級では分単位の復旧要件になる。([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) - **ネットワークは InfiniBand 専有から open Ethernet/RoCE へ設計空間が広がる**: SAKURAONE は SONiC + RoCEv2 で NVIDIA Eos 比 1.02-1.26x の time-to-train を示したが、ECN/PFC/NCCL striping のクロスレイヤ調整を要する。([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **FP8 混合精度が端末間コスト削減の新次元を加える**: [[LLM分散学習]]の効率軸はこれまで並列化・通信隠蔽・チェックポイント設計として議論されてきたが、FP8-LM(Microsoft、2023 年)はデータ型の精度を訓練全段階(計算・ストレージ・通信)に降ろすことで BF16 比 75% 高速化・39% メモリ削減を GPT-175B で実現した。この「数値精度」軸は SER 設計の効率(E)・信頼性(R)の両方に作用する: 小 batch 時はメモリ削減が主の利益になり、大 batch 時は通信削減とスループット向上が主になる。また FP8 ZeRO によるオプティマイザ状態の 2.6 倍メモリ削減は、同 GPU 数でより長いシーケンス長や大バッチを扱う可能性を開く。([[@2023__arXiv__FP8-LM Training FP8 Large Language Models]]) - **「超大規模 vs 中規模」トレードオフの経済合理性**: [[Glenn K. Lockwood]]（元 Microsoft）の観察によると、本番訓練ランのプロファイリングデータは実務者が「中規模 GPU クラスタで中規模モデルを数時間〜数日訓練する」パターンを好むことを示す。100,000 GPU クラスタの利点は「1 ヶ月かかる訓練が 3 日で完了し障害を数時間で検知できる」ことであり、経済的価値は「速度」と「リスク低減」であって「パラメータ規模の拡大」ではないという整理が出てきた。MegaScale（10,000 GPU 超）・SAKURAONE（InfiniBand 代替）が示すシステム設計の複雑性と、この「中規模選好」傾向は、大規模化のコスト対効果についての問いを再提起する。(Source: [[@2026__Glenn K. Lockwood Blog__AI doesnt need giant supercomputers after all]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **百万 GPU スケールではスケールアップネットワークが支配的ボトルネックになる**: [[Costin Raiciu]] らの HotNets 2024 計算では、スケールアップ 0.8 Tbps 時に露出ネットワーキング時間が Dense Transformer 40%・MoE 75% に達する。14.4 Tbps(現行 NVLink 相当)に増速すると 5%/20% に激減し、スケールアップ帯域がスケールアウト(スイッチ速度)より先に飽和する。万 GPU 規模では見えにくかった現象が百万 GPU で顕在化する設計シフトである。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) - **MoE は Dense Transformer より通信要求が厳格**: MoE の backward 計算が 90 ms(Dense: 265 ms)と短いため、DP 勾配交換との重なりが減り、スケールアウトが露出しやすい。スケールアウト 800 Gbps では Dense に追加改善効果がない水準でも MoE は依然 20% 露出する。1.6 Tbps まで増速して初めて 5% 未満に収まる。MoE の採用はネットワーク設計基準を引き上げる。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) - **東西 DC 分割は 30 ms 伝播遅延を計算で完全隠蔽できる(無損失条件)**: GPU あたり 20 Gbps 以上のワイドエリア帯域があれば、両海岸間の 30 ms 伝播遅延を forward/backward 計算時間で完全に覆い隠せる。テール損失(再送=60 ms)が発生すると隠蔽が崩れ、特に MoE で悪化する。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) - **LLM 訓練向けネットワークは 3 層 Clos から 2 層デュアルプレーンへ移行しつつある**: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] は、LLM 訓練の few large elephant flows が ECMP を無力化するため、従来の 3 層 Clos が根本的に不適合であることを示した。HPN の 2 層デュアルプレーンは、レール最適化 × 非スタック型デュアル ToR × デュアルプレーン × 最適化パス選択の組み合わせで 1 Pod 内 15K GPU を収容し、DCN+ 比で訓練スループット 14.9% 向上を達成した。RDMA ハードウェアオフロードの制約から「スイッチ側複雑処理不可、ホスト側経路計算 + CCL 層負荷分散」が基本原則になっている。(Source: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]]) - **マルチモーダルLLM訓練は「動的ワークロード」という第4の SER 制約軸を単一モデル訓練に追加する**: 既存の LLM 分散学習知見群(MegaScale・SAKURAONE 等)は、モデル構造とデータ分布が訓練を通じて概ね安定していることを暗黙の前提に Scalability・Efficiency・Reliability を最適化する。[[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]] は、encoder と LLM バックボーンという 2 つの異質なサブモデル間の相対ワークロードが、モダリティ混合比率とサンプル長分布の変化により訓練フェーズを通じて連続的にシフトすると報告する(§2.2)。この動的性を無視した既存の unimodal-like 統合(Megatron-LM 型)や静的 disaggregation(DistTrain 型)は、いずれも本番環境で最大 2.84× のスループット低下・OOM に直面しており、SER の効率(E)軸に「ワークロードの時間変化への追従性」という新しい要求を追加する。(Source: [[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **本番運用の「静的合成ワークロード vs 実運用の動的ワークロード」ギャップは、ベンチマーク設計そのものへの問いを提起する**: MegaScale-Omni は実運用の動的マルチモーダルワークロードで MFU を測定すると、静的な合成入力での評価に比べ 17% の MFU ギャップが生じると開示する(§7.2)。SER 各軸の既存知見(MegaScale の MFU 52%、SAKURAONE の time-to-train 比較等)はいずれも静的あるいは制御されたベンチマーク条件下の数値であり、本番の動的性を織り込むと効率が系統的に過大評価されうることを、MegaScale-Omni は定量的に示した最初のソースである。(Source: [[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]]) - **同一設計原理(PTD-P型3D並列化)でも、GPU規模の拡大とともにMFUが52%から38〜41%へ低下する**: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 2 Background]] は、Meta LLaMA3 が 16,384 GPU 規模で MFU 38〜41% しか達成できなかったと報告する。これは既出の PTD-P(1T パラメータ・3072 GPU で MFU 52%)より 1 桁小さい GPU 数でより高い MFU を得ていたことと対照的であり、「正確な並列化配置とインターリーブドスケジュールの相乗」(既出の横断的知見)だけでは説明しきれない規模依存の効率低下が、GPU 数を 5 倍以上に拡大した領域で生じていることを示す。この低下がモデルサイズの違い(1T 対 405B 程度)によるものか、GPU 数そのものの効果(通信・障害対応コストの増大)によるものかは、両ソースの記述だけでは切り分けられない。(Source: [[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]], [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 2 Background]]) - **2018年時点で、単一の TPU メッシュ上に複数のモデル次元を同時分割する大規模並列学習がすでに実証されていた**: [[@2018__NeurIPS__Mesh-TensorFlow - Deep Learning for Supercomputers]] は、512 コアの TPUv2 メッシュ上で 50 億パラメータの Transformer を学習し、WMT'14 英仏翻訳と 10 億語言語モデリングベンチマークで当時最高性能を達成した。これは Megatron-LM(2019, 83 億パラメータ・512 GPU)や GPT-3(2020)以前の事例であり、「データ並列の限界(メモリ・レイテンシ・小バッチ非効率)を任意次元のメッシュ分割で解く」という後の 3D 並列化・GSPMD に連なる設計思想が、GPU クラスタではなく TPU メッシュを舞台に先行して確立していたことを示す。(Source: [[@2018__NeurIPS__Mesh-TensorFlow - Deep Learning for Supercomputers]]) - [単一コントローラvs複数コントローラ] PATHWAYSは、複数コントローラ方式(JAX・PyTorch)のPCIe経由低遅延ディスパッチと、単一コントローラ方式(TensorFlow v1)のリソース仮想化・柔軟な表現力という、これまでトレードオフだった性質を非同期分散データフローと並列非同期ディスパッチで両立させ、2048 TPU規模のSPMD計算で約100%のアクセラレータ利用率を達成した。データセンターネットワークで接続された2つのアクセラレータアイランドに跨る64B/136Bパラメータモデルの学習でも、単一アイランド相当の約97%のスループットを達成している。(Source: [[@2022__MLSys__Pathways - Asynchronous Distributed Dataflow for ML]]) - [並列化計画のコンパイラ自動生成] Alpa は、data・operator・pipeline のすべての並列化手法を統合した実行計画を、モデル記述とクラスタ構成から自動生成する初めての end-to-end コンパイラである。GShard MoE では手動最適化された DeepSpeed に対し 2 ノードで 3.5 倍・4 ノードで 9.7 倍のスループットを達成し、[[並列化戦略]]の手動チューニングという LLM 分散学習の労力集約的な工程を自動化する方向性を具体的に示した。(Source: [[@2022__OSDI__Alpa - Automating Inter- and Intra-Operator Parallelism for Distributed Deep Learning]]) ## 未解決の問い - データ並列で整理された「逆伝搬時間 > 送信データ量 / 帯域」という目標条件を、FSDP、パイプライン並列、テンソル並列の異なる通信形式・頻度へ拡張する一般式はどう設計すべきか。([[@2025__JANOG55__AI ML基盤におけるGPU間ネットワークの負荷と性能影響を探る]]) - 1T級MoEの実効効率は約220 TFLOP/s/GPUで、PLaMo-100Bの約540 TFLOP/s/GPUを下回った。メモリアクセス、バッチサイズ、再計算、モデル並列を共同最適化した場合の改善余地と、低精度オプティマイザ状態の安定性への影響は未解明である。(Source: [[@2024__Preferred Networks__1兆 (1T) パラメータ規模のLLMの事前学習検証]]) - SER の 3 軸を、MFU・ETTR・TCO・復旧時間・運用複雑性を含む単一の設計評価へ落とせるか。 - open Ethernet は InfiniBand 代替としてどの規模まで成立し、どの時点で運用チューニングの複雑性が支配的になるか。 - 訓練クラスタの診断手法は、サービス AIOps の RCA/緩和とどの部分を共有でき、どこから専用設計が必要か。 - 大規模 MoE/長コンテキスト訓練では、並列化・チェックポイント・再現性・ロス安定化のどの制約が次の支配要因になるか。 - 100,000 GPU クラスタ（例: [[Microsoft Fairwater]]）と 10,000 GPU クラスタ（例: MegaScale）で、「訓練速度向上 × リスク低減」の便益が「未テスト新規ハードウェア投入・障害モード複雑化・24 時間体制運用コスト」のコストを上回る条件は何か。(Source: [[@2026__Glenn K. Lockwood Blog__AI doesnt need giant supercomputers after all]]) - 百万 GPU × 複数 DC スケールでは、テンソル並列の障害ドメインがラック固定されることでスケジューリングの自由度がどれほど制限されるか。マルチプレーン・マルチレール構成との最適な組み合わせは何か。(Source: [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]]) - マルチモーダルLLM訓練の動的ワークロード(モダリティ混合比率・サンプル長分布のシフト)に対する耐性は、単一モダリティ LLM 訓練の SER 設計(MegaScale・SAKURAONE 等)にどこまで転用できるか。encoder-LLM multiplexing のような「サブモデル間の時間多重化コロケーション」は、MoE の Expert Parallelism のような「モデル内の異質な計算単位の分離」と統一的に扱えるか。(Source: [[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]]) - 静的合成ワークロードと実運用の動的ワークロードの間の MFU ギャップ(MegaScale-Omni で 17%)は、単一モダリティ LLM 訓練でも同様に存在するか。存在する場合、その規模はモデル種別・並列化構成・データセット特性のどれに最も強く依存するか。 - PTD-P(3072 GPU、MFU 52%)と LLaMA3(16,384 GPU、MFU 38〜41%)の MFU 差は、モデルサイズ差・GPU 数そのものの効果(通信・障害対応コスト増)のどちらに主に起因するか。両者を対等に比較できる規模別 MFU のベンチマークは存在するか。(Source: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 2 Background]]) ## 関連 - 子 concept: [[並列化戦略]] / [[LLM学習モニタリング]] / [[耐障害LLM訓練]] / [[GPUクラスタ運用]] / [[集合通信]] / [[チェックポイント]] / [[ストラグラー]] / [[オープンネットワーキング]] / [[性能可搬性]] / [[PTD-P]] / [[混合精度訓練]] / [[AIデータセンタートポロジ]] - 隣接 concept: [[Mixture-of-Experts]] / [[LLMスケーリング則]] / [[GPUレジリエンス]] / [[RDMAネットワーク監視]] / [[データセンター輻輳制御]] / [[ビジョン言語モデル]] - ソース: [[Efficient Training of Large Language Models on Distributed Infrastructures]] / [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 1 Introduction]] / [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 2 Background]] / [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 3 Infrastructure for LLM Training]] / [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] / [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]] / [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] / [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] / [[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]] / [[@2023__arXiv__FP8-LM Training FP8 Large Language Models]] / [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]] / [[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]] / [[@2022__MLSys__Pathways - Asynchronous Distributed Dataflow for ML]] / [[@2022__OSDI__Alpa - Automating Inter- and Intra-Operator Parallelism for Distributed Deep Learning]] - 概念: [[非同期分散データフロー]] / [[自動並列化]] ## 出典 - [[Efficient Training of Large Language Models on Distributed Infrastructures]] - [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 1 Introduction]](SER の 3 課題の提示・全 9 章の構成) - [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 2 Background]](LLM 訓練ワークロードの 4 特性・LLaMA3 の MFU 38〜41%・先行サーベイとの差別化) - [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey - Chapter 3 Infrastructure for LLM Training]](AI アクセラレータ・ネットワーク・ストレージ・スケジューリングの4層インフラ整理) - [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] - [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] - [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] - [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] - [[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]] - [[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]](PTD-P の提案・1T パラメータ 3072 GPU 502 PF/s MFU 52% の実証・インターリーブドスケジュール・スキャッター・ギャザー最適化) - [[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]](百万 GPU スケールにおけるネットワーキング課題体系化・MoE vs Dense の通信要求比較) - [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]](LLM 訓練専用 DC ネットワーク設計・2 層デュアルプレーン・非スタック型デュアル ToR・レール最適化・14.9% 訓練スループット向上) - [[@2026__EuroSys__MegaScale-Omni - A Hyper-Scale, Workload-Resilient System for MultiModal LLM Training in Production]](マルチモーダルLLM訓練特有の動的ワークロード:encoder-LLM multiplexing・decoupled parallelization・workload-resilient joint pipeline。4ベースライン比1.27×〜7.57×のスループット改善、数千GPU本番運用、実運用/静的合成ワークロード間の17% MFUギャップ開示)