LLM学習インフラ実運用の教科書

# LLM学習インフラ実運用の教科書本教科書は、この wiki に蓄積された 145 のソースと 90 を超えるコンセプトページを横断し、大規模言語モデルの学習インフラを「実際に運用する」という観点から体系化したものである。扱う問いは一貫している。**数千から数万の GPU を、数週間から数か月にわたって、止めずに走らせ続けるには何が要るか**。この問いは推論インフラのそれとは別物である。学習ジョブは長時間であり、全体同期であり、単一の障害が全体を止める。この三性質が、可観測性・障害対応・資源管理のすべてを別の問題にする。構成は 13 部からなる。第 I 部で成果を測る物差しを定め、第 II 部から第 V 部で性能を作る層(並列化・集合通信・ネットワーク・ストレージとスケジューリング)を、第 VI 部から第 IX 部で信頼性の層(可観測性・障害の実態・検知と箇所特定・復旧)を扱う。第 X 部は事前学習とは別問題である事後学習と強化学習のインフラを、第 XI 部は投資の正当化を、第 XII 部は運用の意思決定を、第 XIII 部は未解決問題を扱う。読み方は役割によって変わる。初学者は第 I 部から順に読めば「なぜ難しいか」から「どう回すか」までたどれる。実務者は第 VII 部から第 IX 部と第 XII 部を起点にできる。研究者は第 XIII 部から逆引きすると、各未解決問題が本文と一次文献へ繋がる。詳しい経路は付録 B に置いた。 ![[Attachments/llm-training-infrastructure-operations-overview.png]] *図 1. LLM 学習インフラの設計スタックと運用閉ループ。性能を作る学習データプレーン、障害の波及、観測から復帰までの制御、評価指標の関係を示す。* > [!important] 数値の扱いについて > 本書の表に並ぶ故障率・復旧時間・改善倍率は、それぞれ異なる規模・期間・定義の下で測られている。指標名が同じでも測定対象が違う場合がある(MTBE / MTTF / MTBI など)。引用する際は必ず付録 C を先に読むこと。 > [!note] 記述の原則 > 本書の数値・固有名詞・具体的主張はすべて wiki 内の一次ソースに紐づけ、`([[出典]])` の形式で示した。出典のない一般論は書いていない。各部の末尾には、その部で引用したソースの一覧を HTML コメントとして残してある。 --- ## 第 I 部 LLM学習インフラとは何か — 規模・経済性・評価軸 ![[Attachments/llm-training-ch01-metrics.png]] *図 2. 第 I 部の指標体系。MFU は走行中の計算効率、ETTR は壁時計時間に対する生産的実行、MPG はフリート生産性を捉える。*（Source: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]） ### 1.1 定義 — 何を「学習インフラ」と呼ぶか LLM 学習インフラとは、数千億から兆規模のパラメータを持つ言語モデルを、数百から数万の GPU/AI アクセラレータ上で長時間訓練するためのシステム・運用・インフラの総体である。設計軸は SER、すなわち拡張性(Scalability)・効率(Efficiency)・信頼性(Reliability)の三つであり、技術スタックはインフラ、[[並列化戦略]]、計算/メモリ/通信の最適化、[[耐障害LLM訓練]]の四層に分けられる([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。このワークロードが従来の深層学習と異なる点は四つある。アーキテクチャがほぼ Transformer に統一されて同質的であること、数千億パラメータ・テラバイト規模のデータ・数週間から数か月という前例のない規模と訓練時間、Megatron/DeepSpeed のような専用のソフトウェア最適化を要すること、そしてタスク特化型から自己教師あり基盤モデルへのパラダイム転換である([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。 #### 1.1.1 推論インフラとの本質的差異学習インフラの運用設計を推論インフラから流用できない理由は、次の三性質に集約される。 **長時間である**。LLaMA3 は 16,384 台の H100 で 54 日の事前訓練を行い、その間に 466 回中断した([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。ByteDance の本番事前訓練ジョブは 9,600 GPU で 3 か月続く([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。1 兆トークンの訓練に数週間かかり、規模・時間ともに通常の深層ニューラルネットワーク訓練の桁違いであるため、障害とストラグラーは例外でなく常態になる([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。 **全体同期である**。学習ジョブは embarrassingly parallel ではなく、モデルを GPU 間で分割し GPU は密に通信する。単一ジョブが数万 GPU を占有するため、1 つのストラグラーがジョブ全体を減速させる([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。スケジューラ側でもジョブはギャングスケジューリングの意味論を持ち、1 タスクの失敗がジョブ全体の再割当を引き起こす([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。504 GPU の中規模本番でも 60 ノード訓練は全ノードの同時確保を要する([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。 **単一障害が全体を止める**。1 件の障害が連鎖して半千台をアイドル化しうる([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])。[[集合通信]]が Silent Data Corruption を全ワーカへ伝播させるため、起因の特定はさらに難しくなる([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。この非対称は、学習と推論を同一システム内に併置する強化学習の事例で明瞭に見える。推論(rollout)側の故障は自己完結かつ無状態であるため、落ちたレプリカの分だけの損失で済み別ワーカへ即座に再ルーティングできる。高コストなのは「単一のタイトに結合されたコンポーネント」である trainer 側の故障だけである([[@2026__Cognition__SWE-1.7 - Frontier Intelligence at a Fraction of the Cost]])。 | 観点 | 学習インフラ | 推論インフラ(参考として同一ソース内の対比) | | --- | --- | --- | | ジョブ寿命 | 数週間から数か月 | リクエスト単位 | | 障害の波及範囲 | ジョブ全体(ギャングスケジューリング) | 該当レプリカのみ | | 復旧単位 | チェックポイントからの全体再開 | 別ワーカへの再ルーティング | | 復旧コスト | 高い(結合が密) | 低い(自己完結・無状態) | (Source: [[@2026__Cognition__SWE-1.7 - Frontier Intelligence at a Fraction of the Cost]], [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) ### 1.2 SER 軸による技術スタックの地図サーベイの四層分類を SER 軸に重ねると、本書が扱う技術の全体地図になる。 | 層 | 主な構成要素 | 主に効く SER 軸 | | --- | --- | --- | | インフラ | AI アクセラレータ、ネットワーク(NVLink/NVSwitch/PCIe、InfiniBand/RoCE、Clos・rail-optimized 等のトポロジ、輻輳制御)、ストレージ、スケジューリング | 拡張性・効率 | | [[並列化戦略]] | 手作業のハイブリッド並列(データ/テンソル/パイプライン/シーケンス/エキスパート)、自動並列、異種並列 | 拡張性・効率 | | 計算・メモリ・通信最適化 | 演算子最適化とコンパイラ、[[混合精度訓練]]、活性化再計算、ZeRO/FSDP、オフローディング、集合通信とネットワーク内集約 | 効率 | | [[耐障害LLM訓練]] | 障害分析、異常検知、[[チェックポイント]]に基づく復旧、チェックポイント不要の復旧 | 信頼性 | (Source: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]) 重要なのは、SER が独立した三軸ではなくトレードオフであることだ。MFU を上げる通信隠蔽や巨大バッチは効率を上げる一方で、障害復旧・チェックポイント・運用複雑性を増やす([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。効率もまた大域設計と局所チューニングの両方で動き、MegaScale の並列化・通信オーバーラップと、ZeRO/バッチサイズ/NCCL 設定の探索は同じ効率軸の異なる層にある([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]])。 ### 1.3 規模の推移と経済性 #### 1.3.1 スケーリング則が計算需要を作る Kaplan らは、テスト損失がモデルの非埋め込みパラメータ数 $N$・データセットサイズ $D$・計算量 $C_{\min}$ のそれぞれに対して独立に冪乗則でスケールし、その傾向が 7 桁以上にわたることを示した。指数は $\alpha_N \approx 0.076$、$\alpha_D \approx 0.095$、$\alpha_C^{\min} \approx 0.050$ である。計算予算の最適配分は $N_{\text{opt}} \propto C_{\min}^{0.73}$、$D_{\text{opt}} \propto C_{\min}^{0.27}$ となり、「大きなモデルを控えめなデータで早期停止する」という戦略を導いた([[@2020__arXiv__Scaling Laws for Neural Language Models]])。 Hoffmann らはこれを否定した。訓練曲線エンベロープ・IsoFLOP プロファイル・パラメトリック損失フィットという三つの独立手法がいずれも $a \approx b \approx 0.50$ を支持し、計算予算を増やすときモデルサイズと訓練トークン数は等比率でスケールすべきという結論に至った([[@2022__arXiv__Training Compute-Optimal Large Language Models]])。 | 推定手法 | 指数 $a$($N_{\text{opt}} \propto C^a$) | 指数 $b$($D_{\text{opt}} \propto C^b$) | | --- | --- | --- | | 訓練曲線エンベロープ | 0.50 | 0.50 | | IsoFLOP プロファイル | 0.49 | 0.51 | | パラメトリックフィット | 0.46 | 0.54 | | (参考)Kaplan et al. 2020 | 0.73 | 0.27 | (Source: [[@2022__arXiv__Training Compute-Optimal Large Language Models]] §3 Table 2、[[@2020__arXiv__Scaling Laws for Neural Language Models]]) DeepSeek LLM はモデルスケールの表現として非埋め込みフロップス/トークン $M$ を導入し、$M_{\text{opt}} \propto C^{0.5243}$、$D_{\text{opt}} \propto C^{0.4757}$ を導いた。さらに最適バッチサイズと学習率を計算予算の冪乗則($\eta_{\text{opt}} = 0.3118 \cdot C^{-0.1250}$、$B_{\text{opt}} = 0.2920 \cdot C^{0.3271}$)として定式化し、データ品質が高いほどモデル側への配分が増えることを示した([[@2024__arXiv__DeepSeek LLM - Scaling Open-Source Language Models with Longtermism]])。詳細は [[LLMスケーリング則]] と [[計算最適訓練]] に譲る。 #### 1.3.2 計算最適訓練が学習インフラの要件をどう規定するか Chinchilla 則が学習インフラに与える帰結は、要求トークン数の桁が上がることである。 | パラメータ数 | フロップス | 推奨トークン数 | | --- | --- | --- | | 10B | $1.23 \times 10^{22}$ | 2,051 億 | | 67B | $5.76 \times 10^{23}$ | 1.5 兆 | | 175B | $3.85 \times 10^{24}$ | 3.7 兆 | | 280B | $9.90 \times 10^{24}$ | 5.9 兆 | (Source: [[@2022__arXiv__Training Compute-Optimal Large Language Models]] §3.4 Table 3) これは学習インフラの三つの要件に直結する。第一に、データ基盤の要件である。LLaMA3 は 15 兆トークン超(約 30 TB)で訓練され、前処理で処理するデータは最終的なデータセットの 100 倍超に達しうる([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。第二に、壁時計時間の要件である。トークン数が増えれば訓練期間が延び、後述する障害率と乗算されて有効訓練時間比を圧迫する。第三に、推論側の経済性である。Chinchilla は Gopher の 1/4 のサイズで同等以上の性能を出したため、推論に必要な GPU メモリが約 1/4 になり、総保有コスト(TCO)の最小化という設計目標につながる([[@2022__arXiv__Training Compute-Optimal Large Language Models]], [[計算最適訓練]])。 #### 1.3.3 スケーリング則はインフラ調達の計画ツールでもあるスケーリング則はモデル性能の予測だけでなく、物量設計の演繹にも使われている。HotNets 2024 のポジションペーパーは 1,000 億ドル規模のデータセンター建設計画を出発点に、Hoffmann らの計算最適則から 103.8 兆パラメータモデルを導き、必要総メモリ 384.14 TB(モデル 144.04 TB、勾配 48.01 TB、オプティマイザ状態 192.05 TB)、テンソル/シーケンス並列度 18・パイプライン並列度 134・データ並列度 696 という並列化配置まで演繹した([[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]])。その結論は、律速はフロップスではなくネットワークであるというものだ。理想条件でも露出ネットワーキング時間は Dense Transformer 5%・[[Mixture-of-Experts]] 20% であり、スケールアップ帯域が 0.8 Tbps に落ちるとそれぞれ 40%・75% に跳ね上がる([[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]])。 GPT-4 では、訓練計算量の 1/1,000〜1/10,000 しか使わない小規模モデルに不可逆損失項付き冪乗則 $L(C) = aC^b + c$ をフィットし、内部コードベース損失と HumanEval パス率を訓練完了前に正確に予測した。予測可能スケーリングが明示的な設計目標として掲げられた最初の公的事例である([[@2023__arXiv__GPT-4 Technical Report]])。 #### 1.3.4 失敗の経済規模の経済は障害の経済と裏表である。Meta の OPT-175B は 992 台の A100 で理想 25 日のところ実測 57 日を要し、総時間の 56% が障害処理に費やされた([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。ハードウェア側から見ると、A100/H100 のノード可用性は 99.3〜99.4%(1 日あたり 9〜10 分のダウンタイム)であり、608 GPU・復旧 2.2 時間のジョブでジョブレベル 99.9% を保つには 5% のオーバープロビジョニングが必要で、1,000 ノード規模では月 100 万ドル超のコストになる。復旧時間を 5 分に短縮できればこの比率は 2% に下がる([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。**復旧時間の短縮は、そのまま資本コストの削減である**。一方で、規模拡大の経済合理性そのものへの再検討も始まっている。GPT-4 以降に超大規模クラスタで訓練された或るモデルは GPT-4o 比でトークン単価 15 倍・推論に 120 GPU を要して経済的に破綻し、2025 年 4 月に非推奨化された。100,000 GPU クラスタの価値は「1 か月かかる訓練が 3 日で完了し障害を数時間で検知できる」という速度とリスク低減であって、パラメータ規模の拡大そのものではないという整理が出てきている([[@2026__Glenn K. Lockwood Blog__AI doesnt need giant supercomputers after all]])。 ### 1.4 評価指標の体系 #### 1.4.1 MFU — 計算そのものの効率 MFU(Model FLOPs Utilization)は観測スループットを理論ピークフロップスで割った比である([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。 | システム | 規模 | MFU | | --- | --- | --- | | PTD-P(1T パラメータ) | 3,072 GPU | 52% | | MegaScale(175B) | 12,288 GPU | 55.2% | | Megatron-LM(175B、同条件) | 12,288 GPU | 41.2% | | LLaMA3 | 16,384 H100 | 38〜41% | | SAKURAONE(MLPerf GPT-3 175B、非公式) | 96 ノード | 35.9% | (Source: [[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]], [[@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]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) MFU が見落とすものは二つある。第一に、規模とともに劣化する。MegaScale ではバッチサイズを固定して GPU を増やすと計算/通信比が下がり MFU は 59.1% から 55.2% へ漸減した([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。第二に、停止時間を含まない。MFU は「走っている間の効率」であって、障害・復旧・待機を含む壁時計時間の効率ではない。 #### 1.4.2 ETTR — 壁時計時間の効率 ETTR(Effective Training Time Ratio、有効訓練時間比)は生産的実行時間 $R$ と壁時計時間 $W$ の比 $R/W$ である。長時間・高優先度ジョブでは $E[\text{ETTR}] \approx 1 - N_{\text{nodes}} r_f (u_0 + \Delta t_{cp}/2)$ と単純化でき、障害率・チェックポイント間隔・再起動オーバーヘッドを同じ設計空間に置ける([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。 | 条件 | ETTR | | --- | --- | | ByteRobust(9,600 GPU、3 か月の密モデル本番) | 最大 97% | | MegaScale(10,000 GPU 超、数週間の本番) | 90% 超 | | RSC の最大・最高優先度ジョブ(1 時間チェックポイント) | 平均 0.9 超 | | RSC-1 全体を 16,000 GPU 単一訓練に使う仮想シナリオ(60 分チェックポイント) | 0.7 | | 同(5 分チェックポイント) | 0.93 | | 10 万 GPU 級で ETTR 0.9 を保つ要件 | 約 2 分チェックポイント + 約 2 分再起動 | (Source: [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) ETTR が見落とすものは時間的動態である。長時間ジョブでは累積 ETTR が「いつ・どれだけ悪かったか」を覆い隠すため、ByteRobust は 1 時間窓の移動 ETTR を併用する([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。 #### 1.4.3 ML Productivity Goodput — 利用率指標の解体フリート規模では、Capacity(展開済み資源)・Occupancy(割当済み資源)・Duty Cycle(稼働中資源)のいずれも「本当に有用な計算をどれだけ達成したか」を測れない。三者に共通する誤りは「利用率 = 生産性」という前提である([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。 | 従来指標 | 限界 | 対応する MPG 成分 | | --- | --- | --- | | Capacity | トポロジ制約・地理的制約を無視し、高 Capacity は高可用性を意味しない | SG | | Occupancy | 割当済みでも I/O 待ちや非最適コード実行中でありうる | RG | | Duty Cycle | 行列演算ユニットの稼働有無しか見ず、冗長計算でも計上される | PG | MPG は $\text{MPG} = \text{SG} \times \text{RG} \times \text{PG}$ と分解される。SG は「進捗に必要な資源をすべて同時に保有しているか」、RG は「保有しているとき実際に進捗しているか」、PG は「進捗しているとき理論ピークにどれだけ近いか」に答える。Google の本番 TPU フリートでは全ジョブサイズにわたり SG が 95% を超えた([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]], [[ML Productivity Goodput]])。 PG の設計は Roofline 効率の既知の欠陥を意識している。Roofline は演算子を独立に評価するため、演算子融合や再マテリアライゼーションといった正しい最適化がかえってスコアを下げて見える。PG は融合後の予測ステップ時間を分母に取ることでこの余地を正しく計上する。通信計算オーバーラップにより 1,024 TPU チップ・500B パラメータのモデルでスループット最大 1.38 倍・フロップス利用率 72% を達成した([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。見落とすもの: 論文の数値軸は守秘のためマスクされ、TPU + Borg 固有の設計(特に SG の all-allocated の定義)が Slurm/Kubernetes ベースのフリートへどう対応するかは未検証である([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。 #### 1.4.4 ジョブ完了時間と[[性能可搬性]] 利用者が最終的に見るのは所定の品質へ到達するまでの壁時計時間である。SAKURAONE の MLPerf GPT-3 175B(非公式)では time-to-train が 32 ノード 105.31 分・64 ノード 58.30 分・96 ノード 41.86 分となり、同一ノード数での NVIDIA Eos 比は 1.02〜1.26 倍であった([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。複数プラットフォームにまたがる評価には性能可搬性 $\Phi$ が使える。IB-A100・RoCE-A100・RoCE-H100 の 3 プラットフォームで、チューニング後の計算効率はそれぞれ 0.3529・0.3272・0.1735、全体の性能可搬性は $\Phi = 0.2574$ にとどまった。これは単純な計算律速でもネットワーク律速でもなく、通信と計算の重なり・同期・パケット管理を含むレイテンシ律速の構図を示す。RDMA を無効化して TCP に落とすと backward pass は 12 倍遅くなる([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]])。 #### 1.4.5 何を測り、何を見落とすか | 指標 | 測るもの | 主な見落とし | | --- | --- | --- | | MFU | 走行中の計算効率 | 停止・待機・復旧の時間、規模に伴う漸減 | | ETTR | 壁時計時間に占める生産的時間 | 時間的動態(累積値が悪化区間を覆う) | | MPG(SG/RG/PG) | 層別の生産的計算 | スケジューラ固有の定義依存、静的予測の限界 | | ジョブ完了時間 | 利用者から見た成果 | 内訳(どの層が律速か)が見えない | | 性能可搬性 $\Phi$ | 複数環境にまたがる効率 | フロップス近似ゆえメモリ帯域・同期の寄与を分離できない | (Source: [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]], [[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]]) ### 1.5 実運用クラスタの実測像 #### 1.5.1 規模とワークロード分布 | クラスタ | 規模 | 観測期間 | 主な分布の特徴 | | --- | --- | --- | --- | | Philly(Microsoft) | 14 仮想クラスタ | 75 日・96,260 ジョブ | 実行時間は分から週まで広がり、0.5% のジョブが 1 週間超。killed + unsuccessful は件数 30.7% だが総 GPU 時間の約 55% | | Acme(LLM 専用) | 4,704 A100 | 6 か月 | GPU ジョブ実行時間の中央値 2 分。事前学習は件数 0.9〜3.2% で GPU 時間 69.5〜94.0%。SM Activity 中央値約 40%、CPU/InfiniBand の 60% 超がアイドル | | RSC-1 / RSC-2(Meta) | 16k + 8k A100 | 11 か月・400 万ジョブ・1.5 億 GPU 時間超 | 90% 超のジョブは 1 サーバ未満だが GPU 時間は 10% 未満。256 GPU 以上のジョブが GPU 時間の 66% 超(RSC-1)・52% 超(RSC-2) | | SAKURAONE | 800 GPU 単一テナント | 3 か月 | GPU 時間の 73.5% がユーザ起因のキャンセル、FAILED は 0.3% のみ | | ByteDance 本番 | 9,600 Hopper GPU | 3 か月 | 明示的障害 38,236 件・暗黙的障害 5,948 件を自動処理 | | Lablup ほか共同運用 | 63 ノード・504 B200 GPU | 55 日(時系列)/73 日(ログ) | 224 のマルチノードセッション、上位 3/63 ノードが全除外の 50% 超 | (Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]], [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]], [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]]) 一貫して現れるのは、**件数の支配者と GPU 時間の支配者が分かれる**という構造である([[GPUクラスタ運用]])。 #### 1.5.2 中断の頻度は規模にほぼ反比例するノード障害率を $r_f$、ジョブのノード数を $N_{\text{nodes}}$ とすると MTTF は $(N_{\text{nodes}} r_f)^{-1}$ で近似でき、32 GPU 以上では実測とよく合う([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。 | ジョブ規模 | MTTF | | --- | --- | | 8 GPU | 47.7 日 | | 1,024 GPU | 7.9 時間 | | 16,384 GPU | 1.8 時間(予測) | | 131,072 GPU | 0.23 時間(予測) | (Source: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) 本番ランの報告もこの傾向と整合する。Bloom は 384 GPU で週 1〜2 回の GPU 障害、MegaScale は 12,288 GPU で数週間に 100 回超、LLaMA3 は 16,384 H100・54 日で 466 回の中断を経験し、その 78% がハードウェア起因であった([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。数千から 10,000 GPU 規模の本番ではタスクあたり平均 1 日 2 回の障害が観測される([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])。他方、800 GPU の単一テナントでは 3 か月で 21 件([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])、504 GPU では 55 日で 17 件([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])にとどまる。 #### 1.5.3 原因分布と障害コスト | 観測 | 分布 | | --- | --- | | Minder(数千〜10,000 GPU、7 か月) | ハードウェア 55.8%(うち ECC エラー 38.9%)、ソフトウェア 28.0%、ネットワーク 6.0% | | SAKURAONE(800 GPU、3 か月 21 件) | GPU 関連 42.9%、相互接続スイッチ 23.8%、NVLink/PCIe 19.0% | | Astral(超大規模) | 障害の現れ方として fail-stop 66%、fail-hang 17%、fail-slow 13%、fail-on-start 4% | | EROICA(約 100,000 GPU、1.5 年) | 性能問題の原因はハードウェア起因 44.4%、アプリケーション層起因 48.2%。既存監視でオンライン診断できたのは 29.6% | (Source: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]], [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]]) コストは件数ではなく GPU 時間に現れる。ByteDance ではインフラ障害が件数 11% でありながら GPU 時間の 82% を消費した([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。Meta の研究クラスタではハードウェア関連の失敗はジョブ件数の 0.2% だが GPU 実行時間の 18.7% に影響し、障害オーバーヘッド全体の 16% は失敗した大規模ジョブそのものではなく、その再キューに伴う小規模ジョブのプリエンプションから生じた([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。クラッシュに至らない fail-slow だけでも全 GPU 時間の 10.4% が浪費される([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]])。**運用指標は件数でなく GPU 時間で見る**というのが、Philly から現在に至るまで一貫した測定原則である([[GPUクラスタ運用]])。 #### 1.5.4 復旧の実像 MegaScale では障害の 90% 超を頑健なフレームワークが自動で検知・特定・復旧し、障害検知と診断テストは平均 10 分未満、最新チェックポイントからの追いつきは 15 分以内であった([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。ByteDance の 9,600 GPU 級 19 ジョブでは、リアルタイム検査による直接排除が 32.52%、再試行が 22.70%、コードロールバックが 9.20% を解決し、最も重い Dual-Phase Replay を要したのは 1.23% にすぎない。単純な手法で大半のインシデントが片付く([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。中規模では別の律速が現れる。504 GPU の本番では自動リトライチェーンの成功率が 33.3% と手動復旧の 12.5% の 2.7 倍であり、リトライ間隔の中央値は 11 分であった。一方でチェックポイントのロード時間は中央値 31 分、書き込み側の WRITE RPC は 1 要求あたり平均 2.03 秒でそのうち 1.89 秒(93.1%)がキュー時間であり、読み出しスループットは最大帯域の 21.5% にとどまった([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。復旧時間は帯域ではなくキュー形成と資源確保に支配される。 ### 1.6 この教科書の読み方本書は SER の三軸と四層スタックを縦糸に、実運用の意思決定を横糸にして進む。全 13 部の構成は次のとおりである。 | 部 | 主題 | 中心となる問い | 主要概念 | | --- | --- | --- | --- | | 第 I 部(本部) | LLM学習インフラとは何か — 規模・経済性・評価軸 | 何を成果として測るか | [[LLM分散学習]] / [[LLMスケーリング則]] / [[計算最適訓練]] / [[ML Productivity Goodput]] | | 第 II 部 | 並列化戦略とメモリ設計 — 何をどこに置くか | 計算・パラメータ・活性化をどの次元へ分割するか | [[並列化戦略]] / [[テンソル並列]] / [[パイプライン並列化]] / [[シーケンス並列化]] / [[ZeROメモリ最適化]] / [[混合精度訓練]] | | 第 III 部 | 集合通信 — 学習を律速するプリミティブ | どの同期がクリティカルパスに残るか | [[集合通信]] / [[RDMA]] / [[Mixture-of-Experts]] | | 第 IV 部 | ネットワーク設計と物理層の運用 | トポロジと物理層は何を吸収し、何を通すか | [[AIデータセンタートポロジ]] / [[Rail-Optimizedトポロジ]] / [[データセンター輻輳制御]] / [[オープンネットワーキング]] / [[光トランシーバー電力方式]] | | 第 V 部 | ストレージ、データ経路、資源スケジューリング | 学習を止めるのは計算か、それとも I/O とキューか | [[分散ストレージ]] / [[GPUストレージIOデータパス]] / [[GPUクラスタスケジューリング]] / [[チェックポイント]] | | 第 VI 部 | 学習の可観測性 — 何を、どの粒度で、どれだけの代償で測るか | 監視の解像度とオーバーヘッドの均衡はどこか | [[LLM学習モニタリング]] / [[GPU観測性]] / [[テレメトリ]] / [[MLプロファイリング]] | | 第 VII 部 | 障害の実態 — 何が、どのくらいの頻度で壊れるか | 障害分布と障害コストをどの単位で測るか | [[GPUクラスタ運用]] / [[GPUレジリエンス]] / [[運用障害分析]] / [[グレイ障害]] | | 第 VIII 部 | 検知と箇所特定 — 誰が遅いのか、誰が壊れているのか | 同質なワーカ群のどこが外れているか | [[Fault Localization]] / [[ストラグラー]] / [[異常検知]] / [[障害予測]] | | 第 IX 部 | 復旧と耐障害設計 — 壊れた後にどう戻すか | 正確な箇所特定と迅速な隔離のどちらを選ぶか | [[耐障害LLM訓練]] / [[チェックポイント]] / [[弾性LLM訓練]] / [[障害緩和]] | | 第 X 部 | 事後学習と強化学習のインフラ | 学習と推論が同居するとき運用はどう変わるか | [[人間フィードバックからの強化学習]] / [[検証可能報酬による強化学習]] / [[RL重み差分配信]] / [[耐障害LLMサービング]] | | 第 XI 部 | 効率・電力・経済性 | 同じ成果をより少ない資源と電力で出せるか | [[GPUエネルギー効率]] / [[性能可搬性]] / [[Rooflineモデル]] / [[計算最適訓練]] | | 第 XII 部 | 実運用プレイブック | 誰がいつ何を判断するか | [[SRE]] / [[インシデント管理]] / [[ポストモーテム]] / [[サービスレベル目標]] | | 第 XIII 部 | 未解決問題と研究フロンティア | どこがまだ解けていないか | [[LLM分散学習]] / [[LLMスケーリング則]] / [[GPUクラスタ運用]] | 読み進め方は立場によって変えてよい。この分野に初めて触れる読者は、第 I 部から順に読むのがよい。指標・並列化・通信・障害という語彙が後の部で前提として使われるためである。すでにクラスタを運用している実務者は、第 VII 部から第 IX 部(障害の実態・検知・復旧)と第 XII 部(プレイブック)を起点にし、必要に応じて第 II 部から第 V 部へ遡ればよい。研究者は第 XIII 部の未解決問題から逆引きし、関連する部と出典へ降りる読み方が効率的である。第 I 部で定めた指標は、以降のすべての部で判断基準として繰り返し用いる。効率(MFU)の改善が信頼性(ETTR)を損なっていないか、局所最適が層別の Goodput のどこを削っているかを、常に同じ物差しで問い直すためである。  --- ## 第 II 部並列化戦略とメモリ設計 — 何をどこに置くか第 I 部では、LLM 学習インフラを Scalability・Efficiency・Reliability の三軸で捉える視座を確認した。第 II 部はそのうち Efficiency の中核、すなわち「モデルの状態と計算を、どのデバイスにどう置くか」を扱う。並列化は速度のための技法である以前に、**単一デバイスに収まらないものを収める**ための必然だった。この出発点を忘れると、並列化次元の選択が単なるチューニングの遊びに見えてしまう。 ![[Attachments/llm-training-ch02-parallelism.png]] *図 3. 第 II 部の並列化設計。DP・TP・PP・SP・EP は、分割対象、通信プリミティブ、適切なハードウェア階層がそれぞれ異なる。*（Source: [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]], [[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]]） ### 2.1 なぜ単一 GPU に収まらないか — メモリの内訳 #### モデル状態: パラメータ 1 個あたり 16 バイト混合精度([[混合精度訓練]])と Adam オプティマイザを組み合わせた標準的な訓練では、パラメータ数 Ψ のモデルに対して次のメモリが必要になる([[@2020__SC__ZeRO Memory Optimizations Toward Training Trillion Parameter Models]])。 | 項目 | 精度 | サイズ | |---|---|---| | パラメータ | fp16 | 2Ψ | | 勾配 | fp16 | 2Ψ | | パラメータのマスタ複製 | fp32 | 4Ψ | | Adam の一次モーメント | fp32 | 4Ψ | | Adam の二次モーメント | fp32 | 4Ψ | | **合計** | | **16Ψ** | パラメータ本体は全体の 8 分の 1 でしかなく、残り 14Ψ はオプティマイザ状態とマスタ複製が占める。GPT-2(1.5B)でさえ 24 GB 超を要し、32 GB の V100 単体での訓練は事実上不可能だった([[@2020__SC__ZeRO Memory Optimizations Toward Training Trillion Parameter Models]])。サーベイもこの 16Φ という定数を LLM 訓練のメモリ計算の基準値として掲げている([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。 #### 活性: シーケンス長の二乗が効く項モデル状態が「モデルサイズに比例する固定費」であるのに対し、活性(activation)は「バッチサイズ・シーケンス長に比例する変動費」である。テンソル並列度 t を適用した Transformer 1 層あたりの活性メモリは次式で与えられる([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。 $sbh\left(10 + \frac{24}{t} + 5\frac{as}{ht}\right)$ ここで s はシーケンス長、b はマイクロバッチサイズ、h は隠れ次元、a は注意ヘッド数である。注目すべきは第一項 `10sbh` が t で割られていない点で、これは LayerNorm・Dropout・各ブロックへの入力がテンソル並列の対象外であり全デバイスに複製されるためである([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。この「テンソル並列の穴」がシーケンス並列化を要請することになる。第三項の `5as/h` はシーケンス長に対して二乗で効き、GPT-3(a=96, s=2048, h=12288)では 80 に達して定数項 34 を大きく上回る([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。長コンテキスト化がメモリ設計を根底から変える理由がここにある。さらに ZeRO の著者らは、残余メモリとして活性のほかに「一時バッファの肥大化」と「メモリ断片化」を挙げた。3B パラメータモデルの fp32 融合バッファが 12 GB に達する例、そして空きメモリが 30% 以上あるのに OOM が発生する断片化の実例が報告されている([[@2020__SC__ZeRO Memory Optimizations Toward Training Trillion Parameter Models]])。メモリ設計は総量の計算だけでは終わらない。 ### 2.2 並列化の五つの次元サーベイは並列化を、手作業で次元を組み合わせる Hybrid Parallelism、探索で戦略を決める Auto Parallelism、異種ハードウェア向けの Heterogeneous Parallelism の 3 系統に大別する。data/tensor/pipeline の組は 3D parallelism とも呼ばれる([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。ここでは Hybrid の構成要素である 5 次元を順に見る。 #### データ並列 — シャーディング係数という連続量入力バッチを分割し、各デバイスがモデル複製で処理して勾配を集団通信で集約する。PyTorch FSDP はこれを**シャーディング係数 F** という一つの連続量として整理した。F=1 はフル複製(DDP と等価)、F=W はフルシャード(ZeRO-3 相当)、その中間がハイブリッドシャーディングである([[@2023__VLDB__PyTorch FSDP Experiences on Scaling Fully Sharded Data Parallel]])。データ並列は「複製かシャードか」の二択ではなく、メモリと通信のトレードオフを制御する連続的なつまみになった。 #### テンソル並列 — ノード内高帯域が前提 Megatron-LM は Transformer の MLP と多頭注意それぞれに固有の分割を与えた。MLP は第一 GEMM の重みを列方向に分割することで GeLU を各 GPU が独立に適用でき、第二 GEMM を行方向に分割して all-reduce で同期する。多頭注意はヘッド単位で分割し、出力射影を行並列とする。結果として **1 層あたり順伝播 2 回・逆伝播 2 回の計 4 回の all-reduce** で全 GEMM が分散される([[@2019__arXiv__Megatron-LM Training Multi-Billion Parameter Language Models Using Model Parallelism]])。この設計はノード内 300 GB/秒(NVSwitch)とノード間 100 GB/秒(InfiniBand)という帯域差を前提とする。8-way で 77% のスケーリング効率、512 GPU の model+data 並列で 74% を達成したが、論文自身が「ノード内 8-way が実用上の限界」と示唆している([[@2019__arXiv__Megatron-LM Training Multi-Billion Parameter Language Models Using Model Parallelism]])。実測でも PTD-P 構成における TP の通信量は総トラフィックの約 99% を占め(GPT-3B・32 GPU の rank 0 で TP 約 85 GB に対し PP 約 1 GB・DP 741 MB)、通信時間の約 50% を占める。ただし TP はノード内に閉じるため、RoCEv2 と TCP のプロトコル差の影響を受けない([[@2024__APNet__Understanding Communication Characteristics of Distributed Training]])。 #### パイプライン並列 — 層間分割と点対点通信層をステージに分割してデバイスへ割り当てる。通信はステージ境界の活性テンソルの受け渡しのみで、集団通信を要しない([[@2019__NeurIPS__GPipe Easy Scaling with Micro-Batch Pipeline Parallelism]])。この低通信性ゆえに、GPipe は NVLink のない PCI-E 環境でも K=8・M=32 で Transformer に 3.3 倍の高速化をもたらし、128 加速器で 83.9B パラメータまでスケールさせた([[@2019__NeurIPS__GPipe Easy Scaling with Micro-Batch Pipeline Parallelism]])。 #### シーケンス並列 — 通信量を増やさずに穴を埋めるテンソル並列の対象外である LayerNorm・Dropout をシーケンス次元で分割する。境界に g(順伝播 All-Gather / 逆伝播 Reduce-Scatter)と ḡ(その逆)を挿入するが、`all-reduce = reduce-scatter + all-gather` という恒等式により**追加の通信帯域はゼロ**である([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。活性メモリ式は $(sbh/t)(34 + 5as/h)$ となり、並列化なしの式を t で割ったものに一致する。22B モデルの順伝播は 7.7 ms から 7.2 ms へ 6% 高速化した([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。より長いコンテキストでは、注意機構そのものを ring ベース(Ring Self-Attention・DistFlashAttn・Striped Attention)またはヘッド分割(DeepSpeed-Ulysses)で分散する系統が別に存在する([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。 #### エキスパート並列 — 条件付き計算の分散 MoE のエキスパートをワーカー間に分散する。サーベイはその技術課題を Sparse Activation・Communication Optimization・Load Balance の 3 つに整理する([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。詳細は後述する。 #### 五次元の比較 | 次元 | 分割対象 | 主な通信 | 同期粒度 | 典型的配置 | スケール限界の要因 | |---|---|---|---|---|---| | データ並列 (DP) | 入力バッチ | AllReduce / ReduceScatter + AllGather | イテレーション単位(低頻度) | 最外殻 | グローバルバッチサイズの上限、シャード時 1.5 倍の通信量 | | テンソル並列 (TP) | 層内の重み行列 | AllReduce(1 層 4 回) | 層内(高頻度) | ノード内 NVLink | ノード間で通信律速。実用上 8-way 程度 | | パイプライン並列 (PP) | 層(ステージ) | 点対点 send/recv | マイクロバッチ単位 | ノード間 | パイプラインバブル、ステージ分割の不均衡 | | シーケンス並列 (SP) | シーケンス次元 | AllGather / ReduceScatter | 層内 | TP グループと同一 | TP グループに閉じる実装制約 | | エキスパート並列 (EP) | MoE エキスパート | All-to-All(ディスパッチ・結合) | 層内(MoE 層のみ) | ノードをまたぐ | 負荷不均衡と All-to-All 帯域 | TP の通信量は総トラフィックの約 99% を占めるがノード内に閉じるため露出しない、DP は 1 イテレーションに 1 回の巨大転送、PP は小容量で一定サイズの点対点転送、という通信フットプリントの差は明確であり、外部観測のみから並列化戦略を逆推定できるほどである([[@2024__APNet__Understanding Communication Characteristics of Distributed Training]], [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]])。なお、各通信プリミティブ自体の実装とアルゴリズムの詳細は第 III 部が扱う。 ### 2.3 ZeRO / FSDP 系 — 段階的シャーディング #### 三段階の設計 ZeRO の核心的な洞察は「**すべての状態を常時全プロセスに保持する必要はない**」という一点にある。オプティマイザ状態は訓練ステップ末尾でのみ、勾配は逆伝播直後にのみ、パラメータは該当層の計算時にのみ必要である([[@2020__SC__ZeRO Memory Optimizations Toward Training Trillion Parameter Models]])。この時間的性質を利用して段階的に分割する。 | 段階 | 分割対象 | メモリ削減 | 通信量(DP 基準) | |---|---|---|---| | Stage 1 (P_os) | オプティマイザ状態 | 約 4 倍 | 変化なし(2Ψ) | | Stage 2 (P_os+g) | + 勾配 | 約 8 倍 | 変化なし(2Ψ) | | Stage 3 (P_os+g+p) | + パラメータ | Nd 倍 | 1.5 倍(3Ψ) | 7.5B パラメータモデルでは、DP 次数 64 のとき 120 GB が Stage 3 で 1.88 GB に、DP 次数 1024 では 0.12 GB にまで落ちる([[@2020__SC__ZeRO Memory Optimizations Toward Training Trillion Parameter Models]])。**Stage 1 と 2 は通信量を一切増やさない**という点が実務上重要で、既存の DP ワークロードからの移行コストが低い。 ZeRO はさらに残余メモリを ZeRO-R として扱った。分割活性チェックポイント(MP=16 で 100B モデルの活性を 33 GB から 2 GB へ)、定数サイズバッファ、メモリ断片化解消の 3 要素である([[@2020__SC__ZeRO Memory Optimizations Toward Training Trillion Parameter Models]])。400 V100 GPU で 100B パラメータを 38 テラフロップス/GPU・集計 15 ペタフロップスで訓練し、モデル並列なしで最大 13B を扱えるようにした点が「民主化」として評価された([[@2020__SC__ZeRO Memory Optimizations Toward Training Trillion Parameter Models]])。DeepSpeed として OSS 化され、1024 台の V100 での BERT 事前訓練を 67 分から 44 分へ短縮する記録も同じ基盤から出ている([[@2020__KDD__DeepSpeed System Optimizations Enable Training Deep Learning Models with Over 100 Billion Parameters]])。 #### FSDP — 通信効率のための実装知見 PyTorch FSDP は同じ発想を PyTorch のテンソル・ディスパッチャ・CUDA キャッシュアロケータと共設計した。実装上の知見が三つある([[@2023__VLDB__PyTorch FSDP Experiences on Scaling Fully Sharded Data Parallel]])。第一に **FlatParameter**。NCCL は均等な入力サイズを要求し、かつ入力が小さいと効率が急落する(33M 要素未満で顕著)。そこで FSDP ユニット内の全パラメータを 1 次元テンソルへ連結・パディングして均等分割し、大きな AllGather を 1 回発行する。第二に**プリフェッチ**。逆伝播で ReduceScatter と次の AllGather が同一 NCCL ストリームで直列化されるのを避け、順伝播時に記録したモジュール実行順を代理として次の AllGather を先行発行する。GPT-175B で約 18% のスループット向上を得た。第三に**レートリミッター**。CPU スレッドが先行しすぎると CUDA キャッシュアロケータが過剰確保して cudaMalloc リトライを起こす。処理中の AllGather を最大 2 つに制限することで、T5-11B(4 マシン)で 21.81 秒/バッチが 15.33 秒/バッチへ改善した。ただし効果はモデル依存で、DeepViT 8B では 5% 悪化している。**万能の最適化ではない**ことを実装者は知っておくべきだ。 #### veScale-FSDP — 固定粒度シャーディングの限界 FSDP2 は per-parameter の均等シャーディングへ移行してメモリ管理を改善したが、AllGather 後に interleaved アドレスからパラメータをコピーアウトし、ReduceScatter 前にコピーインする必要を新たに生んだ。GPT-OSS-120B・64 H800 の実測で AllGather 43.71 ms に対し Copy-Out 5.22 ms、ReduceScatter 94.24 ms に対し Copy-In 12.37 ms、訓練イテレーションの最大 14% を消費する([[@2026__MLSys2026__veScale-FSDP - Flexible and High-Performance FSDP at Scale]])。より根本的な問題は、要素単位(DeepSpeed・FSDP1)または行単位(FSDP2・Megatron-FSDP)という**固定粒度**が、ブロック単位量子化や Shampoo・Muon のような非要素単位オプティマイザと衝突することである。veScale-FSDP は任意粒度のブロックを表現できる RaggedShard フォーマットと、通信バッファのレイアウトを最適化する構造認識プランナ、そしてゼロコピー通信プリミティブ DBuffer の 3 層でこれを解く([[@2026__MLSys2026__veScale-FSDP - Flexible and High-Performance FSDP at Scale]])。プランニング問題は Partition 問題に帰着でき NP-hard だが、Transformer の構造的規則性を利用した多項式時間の動的計画法ヒューリスティックで実行時間 0.3 秒未満に収まる。結果としてスループット 5〜66% 向上・ピークメモリ 16〜30% 削減を達成し、ByteDance Seed の本番で 10K GPU 級に展開されている([[@2026__MLSys2026__veScale-FSDP - Flexible and High-Performance FSDP at Scale]])。アブレーションが示唆的で、DBuffer 無効化はスループット 7.2% 減、プランナ無効化は 34.6% 減にとどまるのに対し、RaggedShard 無効化はブロック単位量子化そのものを実現不可能にする。**RaggedShard は最適化ではなく抽象化である**([[@2026__MLSys2026__veScale-FSDP - Flexible and High-Performance FSDP at Scale]])。なお、Megatron-FSDP は固定 `Shard(0)` 粒度のため MoE モデルで最大 33% のバッファパディング膨張を生じ、FSDP2 は GPT-OSS-120B を 128 デバイスで訓練できても 256 デバイスで OOM する([[@2026__MLSys2026__veScale-FSDP - Flexible and High-Performance FSDP at Scale]])。シャーディング粒度はメモリの上限そのものを左右する。 ### 2.4 パイプラインのバブルとスケジュール #### バブルの定式化素朴なモデル並列では各ステージが前後の処理を待つ。GPipe はミニバッチを M 個のマイクロバッチに分割してこれを緩和し、バブルの時間的比率を $O((K-1)/(M+K-1))$ と定式化した。**M ≥ 4K でバブルは無視可能**というのが経験則である([[@2019__NeurIPS__GPipe Easy Scaling with Micro-Batch Pipeline Parallelism]])。ただしこの理論値は計算が均質なモデルを前提とする。同じ K=8・M=32 でも、均質な Transformer は 6.3 倍の正規化スループットを示す一方、層コストが偏る AmoebaNet は 3.48 倍に留まる([[@2019__NeurIPS__GPipe Easy Scaling with Micro-Batch Pipeline Parallelism]])。M を増やして理論バブルを縮めることと、ステージの計算時間を均衡させて実効バブルを縮めることは、**別の最適化問題**である。 #### 1F1B と重みスタッシング GPipe は全マイクロバッチ投入後にフラッシュするため、m=4 では計算時間の約 75% がストールになる([[@2019__SOSP__PipeDream Generalized Pipeline Parallelism for DNN Training]])。PipeDream はこれを **1F1B**(One-Forward-One-Backward)で解いた。定常状態では各ワーカーが順伝播と逆伝播を厳密に交互に繰り返し、フラッシュが不要になる。ただし非同期にミニバッチを注入すると順伝播と逆伝播で異なる重みバージョンが使われ、勾配が無効になる。PipeDream は**重みスタッシング**——順伝播時の重みを保存して逆伝播で再利用する——でこれを解決した。n ステージでは最大 n ミニバッチが同時処理中になるが、各ステージは重みの 1/n しか持たないためピークメモリはデータ並列と同水準に収まる([[@2019__SOSP__PipeDream Generalized Pipeline Parallelism for DNN Training]])。さらに PipeDream は、単一 GPU での 1,000 ミニバッチのプロファイリングをもとに、2 段階の動的計画法で「最も遅いステージの処理時間を最小化する」分割を 8 秒未満で自動導出する。VGG-16 でデータ並列比 5.28 倍、GPipe 比 35〜71% のスループット優位を示した([[@2019__SOSP__PipeDream Generalized Pipeline Parallelism for DNN Training]])。一方 ResNet-50 は「重みが軽く出力活性が大きい」ためパイプライン化の恩恵がない。**モデルの形状が並列化方式の適否を決める**という教訓である。 #### インターリーブドスケジュールと以降の系譜 Megatron-LM の SC 2021 論文は、各デバイスに非連続な複数の層チャンク(v 個)を担当させるインターリーブドスケジュールを提案し、バブル比率を $(p-1)/m$ から $(p-1)/(m \cdot v)$ へ削減した。代償としてパイプライン通信量が v 倍になるが、スキャッター・ギャザー通信最適化——テンソル並列ランク間で活性が複製される冗長性を利用し、送信側で t 分割、受信側で NVLink 上の AllGather により再構成する——でノード間 InfiniBand の通信量を 1/t に削減して補う([[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]])。この組み合わせにより 1 兆パラメータモデルを 3072 A100 で 502 petaFLOP/s・MFU 52% で訓練した。ZeRO-3 との比較では、175B で 6〜70%、530B で 24〜70% 高いスループットを示す。差が GPU 数に応じて開く理由は、ZeRO-3 のノード間 AllReduce が GPU 数とともに増えるのに対し、PTD-P はノード間通信を PP の安価な点対点に限定できるからである([[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]])。その後の系譜は次のように分岐する。MegaScale は interleaved 1F1B を保ったまま LAMB オプティマイザでバッチサイズを 4 倍にし、バブルを 87.5% 削減した([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。DeepSeek-V3 の DualPipe は順伝播・逆伝播のチャンクを再配置して双方向にパイプラインを流し、バブルを $(PP/2-1)(F\&B+B-3W)$ へ圧縮しつつ All-to-All と PP 通信を計算中に完全隠蔽する([[@2024__arXiv__DeepSeek-V3 Technical Report]])。一方 Kimi K2(1.04T、384 エキスパート)は DualPipe を**採用しなかった**。運用複雑性と障害復旧の困難さを理由に、16-way PP + 16-way EP + ZeRO-1 DP と interleaved 1F1B を選んでいる([[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]])。MFU 最大化と復旧容易性のトレードオフが、産業的判断として現れた例である。 #### バブルはアイドルであると同時に資源でもある視点を変えれば、バブルは「使われていない計算スロット」である。ReCycle はこれを耐障害資源として転用した。1F1B のバブル量はデータ並列度 DP・パイプライン深度 PP に対して $3 \times (PP-1) \times DP$ 個存在し、LLaMA-3 405B(PP=16, DP=64)では 1 イテレーションあたり 2,880 個、最大 30 同時障害分を収容できる([[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]])。バブルがウォームアップとクールダウンに偏在するという性質に対しては、分割逆伝播とストラグラーオプティマイザで対処する。効率の指標が信頼性の資源に反転する構図は、第 IX 部で改めて扱う。 ### 2.5 混合精度と FP8 — 数値安定性という運用リスク #### なぜ BF16 が主流になったか | 形式 | 最大値 | 相対誤差 | 特性 | |---|---|---|---| | FP32 | 3.40×10^38 | ~10^-7 | 基準精度 | | BF16 | 3.39×10^38 | ~10^-2 | FP32 と同じ動的範囲。LLM 訓練の主流 | | FP16 | 65,504 | ~10^-3 | 動的範囲が狭く 100B 超で不安定 | | FP8 E4M3 | 448 | ~10^-1 | テンソルスケーリング必須 | | FP8 E5M2 | 57,344 | ~2×10^-1 | 範囲広め | FP16 は 16 ビット幅のまま指数部が 5 ビットしかなく、100B 超のモデルで数値不安定が顕在化した。BF16 は指数部を FP32 と同じ 8 ビットにすることでこれを解消し、Bloom-175B・Gopher・Chinchilla が採用している([[@2023__arXiv__FP8-LM Training FP8 Large Language Models]])。 #### FP8 — 精度分離という原則 NVIDIA Transformer Engine は GEMM 計算のみを FP8 化したが、勾配・オプティマイザ状態・集団通信は FP16/FP32 のままだった。FP8-LM は訓練全段階へ FP8 を浸透させ、GPT-175B で BF16 比 75% 高速化・メモリ 39% 削減・重み関連通信量 65% 削減を達成した([[@2023__arXiv__FP8-LM Training FP8 Large Language Models]])。その鍵が**精度分離**である。訓練変数を精度感度で分類し、感度の低いものだけを低精度化する。 - **高精度必須**: マスタ重み(更新量が極小のため精度損失が直接劣化に連鎖)、Adam の二次モーメント(二乗計算でアンダーフロー感度が高い) - **低精度許容**: Adam の一次モーメント(方向情報が主)、GEMM の中間活性この分離により Adam の 16 バイト/パラメータを 6 バイト/パラメータへ 2.6 倍削減した。アブレーションは境界の厳しさを示す——二次モーメントを FP8 化すると**訓練損失が発散する**([[@2023__arXiv__FP8-LM Training FP8 Large Language Models]])。運用上の落とし穴はここに集中している。集団通信も難所である。事前スケーリングは GPU 数 N で割るためアンダーフローしやすく、事後スケーリングは加算前にオーバーフローしやすい。FP8-LM は動的な共有スカラー μ を導入し、FP8 最大値を超える値の比率が 0.001% を超えたら μ を半減、継続的に下回れば 1,000 ステップかけて倍増させる。さらに全 GPU のスケーリングファクタの最小値 $s'_g$ を事前共有することで、通常の NCCL AllReduce をそのまま使えるようにした([[@2023__arXiv__FP8-LM Training FP8 Large Language Models]])。低精度と集団通信の交差点は第 III 部でも改めて扱う。 #### DeepSeek-V3 — 671B 規模での FP8 検証 DeepSeek-V3 は 671B 規模で FP8 訓練を初めて検証し、BF16 ベースラインとの相対損失誤差を 0.25% 以下に抑えた([[@2024__arXiv__DeepSeek-V3 Technical Report]])。運用上重要な設計判断が四つある。第一に**細粒度量子化**。活性はタイル単位(1×128)、重みはブロック単位(128×128)でスケーリングし、外れ値の影響を局所化する。第二に**高精度累積**。H800 の FP8 GEMM の累積精度は約 14 ビットに制限されるため、128 要素ごとに部分結果を CUDA コアの FP32 レジスタへ昇格させる。第三に **E4M3 の統一使用**。細粒度量子化により動的範囲の制約が緩和されるため、E4M3/E5M2 のハイブリッドを捨てた。第四に**保護対象の明示**。埋め込み・出力ヘッド・MoE ゲーティング・正規化・注意は BF16/FP32 のまま残す([[@2024__arXiv__DeepSeek-V3 Technical Report]])。低精度化は「どこまで下げられるか」ではなく「**どこを下げてはいけないか**」を決める作業である。 ### 2.6 活性再計算 — メモリと計算のトレードオフ活性を保存せず逆伝播時に順伝播を再実行する[[再マテリアライゼーション]]は、GPipe がパイプライン並列と組み合わせて実用化した。ピーク活性メモリは $O(N \times L)$ から $O(N+(L/K)\times(N/M))$ へ削減され、単一 TPUv3 で扱える Transformer が 282M から 785M パラメータへ 2.7 倍に拡大した([[@2019__NeurIPS__GPipe Easy Scaling with Micro-Batch Pipeline Parallelism]])。問題は代償である。完全再計算は 30〜40% の計算オーバーヘッドを生む([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。[[選択的活性化再計算]]はこの「全か無か」を崩した。 | 方式 | メモリ | 計算オーバーヘッド | |---|---|---| | 完全保持 | 最大 | なし | | 完全再計算 | 最小 | +30〜40% | | 選択的再計算 | 中間(5 倍削減) | +2〜7% | 選択の基準は分析的である。**FLOPs/入力要素比が低く、かつメモリ占有が大きい演算**を再計算対象とする。Transformer では Q/K/V 射影後にシーケンス次元が a 倍に拡大した後の QKᵀ・Softmax・Softmax Dropout・V への注意がこれに該当し、活性式の `5as/h` 項に対応する([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。GPT-3 で活性削減率 70%・再計算 FLOPs オーバーヘッド 2.7%、MT-NLG で 65%・1.6% である。 22B モデル 1 層あたりの実測では、完全再計算が +39% のオーバーヘッドなのに対し、シーケンス並列 + 選択的再計算は +4% に収まる。エンドツーエンドでは 22B から 1T まで一貫して 29〜32% のスループット向上を示し、530B・2,240 A100 で MFU 42.1% から 54.2% へ改善した([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。シーケンス並列が定数項 `10sbh → 10sbh/t` を削り、選択的再計算が二乗項 `5as/h` を削る。両者はメモリ式の**異なる項**を担当するため、単独ではそれぞれ約 50% 削減にとどまるものが、組み合わせで 5 倍削減という超加法的効果を生む([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。なお、再計算を有効にすべきかはバッチサイズにも依存する。小バッチでは 33% のスループット低下を招くが、大バッチではバブルが小さくなり全体スループットが最大 2 倍向上する場合もある([[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]])。 ### 2.7 注意機構のカーネル最適化が学習インフラに与える影響 [[FlashAttention]] の主張は、注意計算の実行時間が FLOP ではなく **HBM アクセス数**に律速されているというものだった。標準実装が N×N の中間行列を HBM に実体化するのに対し、タイリングとオンライン softmax で SRAM 上に処理を閉じ、HBM アクセスを $\Theta(N^2d^2M^{-1})$ に抑える(標準は $\Theta(Nd+N^2)$)([[@2022__arXiv__FlashAttention - Fast and Memory-Efficient Exact Attention with IO-Awareness]])。 GPT-2 medium・シーケンス長 1024 の実測が示唆的である。FlashAttention は GFLOP が 66.6 から 75.2 へ**増えている**にもかかわらず、HBM 読み書きが 40.3 GB から 4.4 GB へ落ちることで実行時間は 41.7 ms から 7.3 ms へ短縮する([[@2022__arXiv__FlashAttention - Fast and Memory-Efficient Exact Attention with IO-Awareness]])。計算量を増やしてメモリ移動を減らすという反直感的な設計が現代 GPU では正しい。学習インフラへの影響は三方向に及ぶ。第一に**訓練時間の直接短縮**——BERT-large で MLPerf 1.1 記録比 15% 高速、GPT-2 で HuggingFace 比 3 倍([[@2022__arXiv__FlashAttention - Fast and Memory-Efficient Exact Attention with IO-Awareness]])。第二に**メモリのシーケンス長に対する線形化**で、長コンテキスト訓練の実行可能領域そのものが広がる。シーケンス長 4K の FlashAttention は Megatron-LM のシーケンス長 1K より 30% 高速でパープレキシティが 0.7 良い([[@2022__arXiv__FlashAttention - Fast and Memory-Efficient Exact Attention with IO-Awareness]])。第三に**活性メモリ設計との相互作用**——FlashAttention は内部で中間行列を保存せず再計算しており、選択的再計算が削減対象とする `5as/h` 項と同じ領域を扱う。両者の実装上の相互依存は未整理の課題として残されている([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。世代進化はハードウェアとの協調設計の連続である。FlashAttention-2 は A100 で理論最大の 50〜73% に到達したが、H100 では 35% に落ちた。FlashAttention-3 は Hopper の非同期機構(TMA・WGMMA)をワープ特殊化で活用し、ブロック単位 GEMM と softmax をピンポンスケジューリングでインターリーブすることで FP16 740 TFLOPs/s(利用率 75%)、FP8 で約 1.2 PFLOPs/s を達成した([[@2024__arXiv__FlashAttention-3 - Fast and Accurate Attention with Asynchrony and Low-precision]])。ここで学習インフラの設計者が知っておくべき数字がある。H100 の FP16 行列積スループットは 989 TFLOPS だが、softmax の指数関数を担う multi-function unit はわずか 3.9 TFLOPS である。ヘッド次元 128 の FP16 では指数関数が行列積の 50% ものサイクルを消費しうる([[@2024__arXiv__FlashAttention-3 - Fast and Accurate Attention with Asynchrony and Low-precision]])。テンソルコアが世代ごとに倍増しても非行列積ユニットは据え置かれるため、**注意機構の利用率は 70〜75% 付近に収束する**([[@2026__arXiv__FlashAttention-4 - Algorithm and Kernel Pipelining Co-Design for Asymmetric Hardware Scaling]])。GEMM カーネルの 80〜90% に届かないのは構造的制約である。 FP8 注意については、ブロック量子化と非コヒーレント処理(Q と K をランダム直交行列で乗算してから量子化し、外れ値を分散させる)により、テンソル単位量子化ベースラインの RMSE 2.4e-2 を 9.1e-3 へ 2.6 倍改善した([[@2024__arXiv__FlashAttention-3 - Fast and Accurate Attention with Asynchrony and Low-precision]])。 ### 2.8 MoE 特有の負荷不均衡と全対全通信 #### 負荷不均衡は設計の原点にあるスパースゲート MoE を確立した Shazeer らは、ゲーティングネットワークが特定のエキスパートに集中する**自己強化的な不均衡**を最初から中心課題として認識していた。対処として重要度損失(バッチ内のゲート値の変動係数の二乗)と負荷損失(各エキスパートが受け取る例数の平滑化推定の変動係数の二乗)という 2 つの補助損失を導入した([[@2017__ICLR__Outrageously Large Neural Networks The Sparsely-Gated Mixture-of-Experts Layer]])。同論文はもう一つの課題も予言していた。「ネットワーク帯域がボトルネックになる」という指摘である([[@2017__ICLR__Outrageously Large Neural Networks The Sparsely-Gated Mixture-of-Experts Layer]])。当時は 16〜64 台の K40 GPU での観察だったが、現代の分散実装ではクロスノード Expert Parallelism がこれを深刻化させた。 #### All-to-All が訓練時間の 30〜56% を占める MoE の AllToAllv は訓練時間の 30〜56% を占め、GPU 対間の転送量が最大 12 倍ばらつく。しかもゲーティング関数により数百ミリ秒ごとにパターンが変化する動的ワークロードである([[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]])。従来「スケジューリング不可能」とされてきたこの通信に対し、FAST は Birkhoff 分解と 2 フェーズ設計でオンラインスケジューリングが成立することを示し、RCCL 比最大 4.48 倍のエンドツーエンド改善を得た([[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]])。集団通信スケジューリング一般の議論は第 III 部に譲り、ここでは並列化構成の選択に直結する部分に絞る。 MoE は密モデルより通信要求が厳格でもある。MoE の逆伝播計算は 90 ms(Dense は 265 ms)と短いため、データ並列の勾配交換と重ねられる余地が小さく、スケールアウトが露出しやすい。スケールアウト 800 Gbps で Dense に追加改善の余地がない水準でも MoE は 20% 露出し、1.6 Tbps でようやく 5% 未満に収まる([[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]])。**MoE の採用はネットワーク設計基準を引き上げる**。 DeepSeek-V3 の対処は三層である。アーキテクチャ側では補助損失に依存せず、エキスパートごとのバイアス項をバッチ単位の負荷監視で動的に調整する(バイアスはルーティング決定のみに使い、ゲーティング値は元のアフィニティスコアから算出する)。通信側ではノード制限ルーティングで各トークンの送信先を最大 4 ノードに限る。カーネル側では IB(50 GB/s)と NVLink(160 GB/s、約 3.2 倍)の帯域差を利用し、IB でノードに到達させた後 NVLink で GPU へ転送する二段構成を 20 SM で実装した([[@2024__arXiv__DeepSeek-V3 Technical Report]])。 #### 不均衡は信頼性の問題でもある MoE は密モデルにない 2 つの同期点(All-to-All によるトークンディスパッチと結果結合)を持つ。1 ノードのネットワークアダプタ障害で帯域が実質半減すると、その影響がエキスパート並列グループの 32 層分にわたって累積し、ジョブ全体を律速する([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])。疎な活性化は計算効率を稼ぐ一方で、フェイルスローなノードに対する**影響増幅源**として作用する。スパーシティ自体をスケーリング変数とする定量則も出てきた。Kimi K2 は活性化パラメータを固定したままエキスパート数を変化させ、スパーシティ 48(384 エキスパート)がスパーシティ 8 比で 1.69 倍の FLOPS 節約をもたらすことを示した([[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]])。ただしスパーシティの上限は EP 通信量というインフラ制約で規定される可能性がある。 ### 2.9 実運用の要点 — 3D/4D 構成をどう決めるか #### 基本の設計原則 Megatron-LM の SC 2021 論文が示した 3 つのテイクアウェイが、いまも出発点として有効である([[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]])。 1. **テンソル並列はノード内に留める**。それ以上はパイプライン並列を使う。ノード間 AllReduce は通信律速になり、テンソル次元を上げるほど行列計算が小さくなり GPU 利用率も落ちる。 2. **モデル並列サイズ M = t × p をモデルがメモリに収まるように設定し、残りをデータ並列に割り当てる**。基本式は $p \times t \times d = n$。 3. **マイクロバッチサイズ b は GPU 利用率とバブル削減のトレードオフで選ぶ**。この原則は別組織・別インターコネクトでも成立する。MegaScale は 175B で TP=8/PP=8、530B で TP=8/PP=35 を採用し、TP をノード内に閉じ DP グループを PP より優先して cross-minipod 通信を緩和した([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。open Ethernet ベースの SAKURAONE は GPT-3 175B で PP=16 を厚く取る異なる配分を選んだが、PyTorch Profiler の実測で PP の SendRecv が NCCL 時間の 91.2% を占め、TP の集団通信はノード内 NVLink に留まることを確認している([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。 #### ハードウェア構成との対応で崩れるところ原則は原則として、実運用では次の落とし穴がある。 **トポロジとの不整合**。SAKURAONE は 64 ノードで 2 つの pod を spine 経由でまたぐと、通信比率が 16.4% から 19.3% へ、計算通信オーバーラップが 72.3% から 67.2% へ悪化し、96 ノードで MFU が 35.9% まで低下した([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。PP を厚く取る構成は cross-pod 通信に敏感である。トポロジ設計そのものは第 IV 部が扱う。 **マッピングの選択**。同じ (p,t,d)=(4,2,4) でも、DeepSpeed の既定マッピングと「TP・PP をノード内に閉じ DP をノード間に割り当てる」カスタムマッピングでは、TP のオーバーヘッドは同じまま PP が減り DP が増えるという異なるプロファイルが得られる。重要なのは、論理的な (p,t,d) と物理マッピングが定まれば**通信マトリクスは実行前に計算できる**という点である([[@2024__APNet__Understanding Communication Characteristics of Distributed Training]])。構成探索は事前シミュレーションで評価できる。 **分割の不均衡**。パイプラインステージ分割では、最終ステージの損失層が Transformer 層の約 9 倍の計算量を要し、39.3% のジョブで最終ステージが 50% 以上のスローダウン寄与を占める。シーケンス長の不均衡も、自己注意の計算量が $O(\sum s_i^2)$ であるため 21.4% のジョブに平均 1.34 倍のスローダウンをもたらす。貪欲法によるシーケンス再分配だけで 23.9% のスループット改善が得られた([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]])。**並列化の「分割の仕方」そのものが浪費源になる**。 **分割の粒度の離散性**。テンソル並列では、FFN 層は中間次元が大きく細かく分割できるが、注意層はヘッド数という粗い離散単位でしか分割できない。LLaMA-3.1-70B(8 KV ヘッド)を 8 GPU から 7 GPU の非均一 TP に落とすと、一部ランクが 2 ヘッド・他が 1 ヘッドを担当し最大 2 倍の計算不均衡が生じる([[@2025__arXiv__FailSafe - High-performance Resilient Serving]])。障害後の再構成では均等分割の前提が崩れる。 **移行時の性能回帰**。FSDP から Megatron へバックエンドを移行した際、FFN 重みのレイアウト変化が Tensor Core の 128 バイトアラインメント不適合を招き、FLOPS が 65.3% 低下した事例がある([[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]])。並列化次元の変更はレイアウトの変更でもある。 #### 探索空間は次元の次数だけではない実務的な探索空間は TP/PP/DP の次数に留まらない。同じ ZeRO-DP 系でも Stage 1/2/3、バッチサイズ、勾配累積、そしてフレームワークが実際に使う通信プリミティブの違いが性能を左右する。ある評価では 3 つのプラットフォームすべてで ZeRO Stage 2・バッチサイズ 128・勾配累積 2 が最良となり、Stage 1 のバッチサイズ 128 は OOM になった([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]])。さらに DeepSpeed の ZeRO Stage 2 は既定では論文の説明と異なり reduce-scatter ではなく all-reduce で動作するため、`reduce_scatter=true` に加えて `use_multi_rank_bucket_allreduce=false` の設定が必要になる([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]])。 **論文上の通信量と実装が実際に発行する通信プリミティブは一致しない**。並列化戦略は「モデルをどう分割するか」だけでなく、「その分割をフレームワークがどの通信プリミティブで実行するか」まで含めて測る必要がある。 #### オーバーラップ設計は次元ごとに固有である通信隠蔽は単一の技法ではない。MegaScale はデータ並列の all-gather をプリフェッチし、TP/SP では FFN パスの Linear と融合して GEMM をチャンク化し、PP では send/receive を分離するという、次元ごとに別々のオーバーラップを実装した。アブレーションでは TP/PP/DP のオーバーラップが累計 +6.2% MFU と最大の寄与を示している([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。集団通信ライブラリ側も同様に作り分けられており、NCCLX はパイプライン並列にゼロコピー/SM フリーの send-recv、テンソル並列に RMA Put、最外殻のデータ並列に耐障害 AllReduce を割り当てている([[@2025__arXiv__Collective Communication for 100k+ GPUs]])。ライブラリ層の設計は第 III 部で詳述する。さらに一歩進んだ方向として、同期の単位そのものを再設計する系統がある。DreamDDP は Local SGD の全層一括同期を層単位に分解し、どの層をどのイテレーションで同期するかを深さ優先探索でスケジューリングする。オーバーラップ設計が「固定された同期単位を計算の影に隠す」段階から「**同期単位そのものを再設計してオーバーラップの機会を作り出す**」段階へ進んだ事例であり、低帯域の地理分散環境で ASC-WFBP 比 1.73〜5.22 倍の高速化を示した([[@2026__MLSys__DreamDDP - Accelerating Low-Bandwidth Geo-Distributed LLM Training with Layer-wise Partial Synchronization]])。層単位の部分同期は S-SGD と同じ収束率 O(1/R) を理論的に保証し、H イテレーション以内に全層が同期されるという境界がチェックポイント整合性も担保する([[@2026__MLSys__DreamDDP - Accelerating Low-Bandwidth Geo-Distributed LLM Training with Layer-wise Partial Synchronization]])。 #### まとめ — 並列化は効率だけの問題ではない第 II 部を通じて繰り返し現れたのは、並列化構成の選択が効率以外の軸と結合するという事実である。Kimi K2 が MFU 最大化(DualPipe)より復旧容易性(interleaved 1F1B)を選んだこと([[@2025__arXiv__Kimi K2 - Open Agentic Intelligence]])、ReCycle がパイプラインバブルを耐障害資源に転用したこと([[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]])、データ並列度 N が大きいほど複製による障害復旧が堅牢になること([[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]])——いずれも並列化と信頼性の結合を示す。効率最適化が要求する並列化配分と、耐障害性が要求する配分は衝突しうる。この緊張関係が、第 IX 部で扱う耐障害設計の出発点になる。  --- ## 第 III 部集合通信 — 学習を律速するプリミティブ分散学習の性能は、突き詰めれば「GPU がどれだけ計算したか」ではなく「GPU がどれだけ待たされなかったか」で決まる。その待ち時間の大半を生むのが[[集合通信]]である。第 III 部では、プリミティブと並列化次元の対応から NCCL の内部構造、ワークロードの通信特性、10 万 GPU 規模のスケール則、そして運用者が通信劣化をどう切り分けるかまでを扱う。 ![[Attachments/llm-training-ch03-collectives.png]] *図 4. 第 III 部の集合通信。並列化次元ごとに通信プリミティブは異なり、計算とのオーバーラップは露出通信を減らす一方で SM 競合を生む。*（Source: [[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]], [[@2024__APNet__Understanding Communication Characteristics of Distributed Training]]） ### 3.1 プリミティブと並列化次元の対応 #### 3.1.1 集合通信ライブラリが提供する操作 NCCL が提供する API は四カテゴリに整理される。コミュニケータ管理(`ncclCommInitAll` / `ncclCommInitRank` と `ncclCommDestroy` / `ncclCommAbort`)、集団通信の 5 操作(`ncclAllReduce` / `ncclBroadcast` / `ncclReduce` / `ncclAllGather` / `ncclReduceScatter`)、点対点の `ncclSend` / `ncclRecv`、そして複数操作を束ねて起動オーバーヘッドを削る `ncclGroupStart` / `ncclGroupEnd` である([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]])。 #### 3.1.2 並列化次元との対応 [[並列化戦略]]の各次元は、それぞれ固有のプリミティブと通信量の性格を持つ。 | 並列化次元 | 主なプリミティブ | 通信の性格 | |---|---|---| | データ並列(DP / FSDP) | AllReduce、ReduceScatter + AllGather | 大容量だが内側の計算で隠蔽されやすい | | [[テンソル並列]](TP) | AllReduce(トランスフォーマーブロックあたり 6 回、再計算込み) | 実行中に完全に露出し、高帯域域に留まる | | [[パイプライン並列化]](PP) | Send / Recv | 中サイズで部分的に隠蔽される | | エキスパート並列(EP、[[Mixture-of-Experts]]) | AllToAll / AllToAllv | MoE 層あたり 2 回、動的でスキューが大きい | この「内側の並列領域は露出し、外側は隠蔽される」という層別は NCCLX の設計前提そのものである([[@2025__arXiv__Collective Communication for 100k+ GPUs]])。一方 TP の AllReduce 回数と通信量の解析的定式化は APNet 2024 の実測研究が与えている([[@2024__APNet__Understanding Communication Characteristics of Distributed Training]])。 #### 3.1.3 量的な偏り — TP が通信の 99% を占める GPT-3B を 32 GPU で PTD-P 訓練したときの rank 0 の通信量内訳は次のとおりで、この傾向は全実験で一貫していた([[@2024__APNet__Understanding Communication Characteristics of Distributed Training]])。 | 通信種別 | 通信量 | メッセージ数 | メッセージサイズ | |---|---|---|---| | TP | 約 85 GB | 680 | 125 MB | | PP | 約 1 GB | 16 | 125 MB | | DP | 741 MB | 1 | 741 MB | | EmbTableSyn | 96 MB | 1 | 96 MB | 重要なのは、量的支配とプロトコル最適化の効きが一致しないことである。TP はノード内(NVLink / PCIe)で完結するため TCP → RoCEv2 の恩恵をほとんど受けないのに対し、ノード間を通る PP は 2.5 倍、DP は 1.6 倍の通信削減を得た([[@2024__APNet__Understanding Communication Characteristics of Distributed Training]])。「どのプリミティブが重いか」ではなく「どのプリミティブがどのネットワーク層を通るか」が、打つべき手を決める。 ### 3.2 NCCL の内部 — チャネル・プロトコル・アルゴリズム NCCL はオープンソースだが内部設計は長く不透明で、チャネル管理・プロトコル選択・アルゴリズム選択ロジックは十分に文書化されていなかった。これを初めて体系的に解析したのが Demystifying NCCL である(対象は NCCL 2.19.1)([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]])。 #### 3.2.1 チャネル各通信チャネルは独立した CUDA ブロックであり、独自の SM 上で動作する。入力バッファを分割して並行処理し、複数 NIC をまたぐ負荷分散にも寄与する。ただしチャネルあたりのチャンクサイズが NIC FIFO バッファの 512 KiB を下回ると帯域効率が落ちるため、小メッセージでは `calcP2pChunkSize` が発見的にチャネル数を削減する。グリッドは `(nChannels, 1, 1)` で、`blockIdx.x` が 1 チャネルに 1 対 1 対応する。ワープ 0 がコミュニケータメタデータ、ワープ 1 がチャネルデータをロードし、残りが通信と計算を担う([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]])。 #### 3.2.2 三つのプロトコル | プロトコル | 設計目標 | 同期機構 | ペイロード | 帯域利用率 | ホップあたり遅延 | |---|---|---|---|---|---| | Simple | 高帯域 | メモリフェンス | データチャンク | ほぼピーク | 約 6 µs | | LL | 低遅延 | フラグ同期 | 4 B データ + 4 B フラグ | 25〜50% | 約 1 µs | | LL128 | 低遅延・高帯域 | フラグ同期 | 120 B データ + 8 B フラグ | 約 95% | 約 2 µs | LL は中間バッファをホストメモリに置くため GPUDirect RDMA を使えず帯域が制限される。LL128 は 128 B アトミック書き込みを前提とし、PCIe やアーキテクチャ制約でこれが保証されない場合は無効化される。選択はメッセージサイズ・トポロジ・GPU アーキテクチャに基づくオートチューニングで動的に行われ、`NCCL_PROTO` で上書きできる([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]])。 #### 3.2.3 データ転送機構ノード内の優先度は NVLink P2P → PCIe P2P → SHM → NIC 経由である。同一プロセス内では P2P_DIRECT モードが IPC ハンドルを不要にし、`directSend` / `directRecv` プリミティブで中間 FIFO バッファのコピーを排除する。ノード間では IB Verbs トランスポートが GPUDirect RDMA、NIC あたり 2 論理チャネル(`NCCL_IB_QPS_PER_CONNECTION` で制御)、順方向 QP と逆方向 QP の分離によるヘッドオブラインブロッキング防止、GDRDMA 有効時のループバック `RDMA_READ` によるローカルフラッシュを備える([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]])。 #### 3.2.4 Ring と Tree Ring AllReduce は 2k-1 ステップで完結する。ステップ 0 が `send`、ステップ 1〜k-2 が `recvReduceSend`、ステップ k-1 が `recvReduceCopySend`、ステップ k〜2k-3 が `recvCopySend`、最終ステップが `recv` である。Ring AllGather と Ring ReduceScatter はそれぞれ k-1 ステップ。これらは各 GPU が 1 ループ反復内の全ステップを完了してから次へ進む非パイプラインパターンに属する。対して Tree AllReduce、Ring Broadcast、Ring Reduce はパイプラインパターンで、SM を非対称に 2 グループへ分割し Reduce フェーズと Broadcast フェーズを並行実行する(帯域集約の縮約フェーズにより多くのスレッドを割り当てる)([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]])。この「プリミティブの種類と順序が確定している」という Ring の性質は、外部からの依存トレース([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])と内部の SM-free 再設計([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]])の双方を成立させる共通の土台になっている。 #### 3.2.5 実測特性 CSCS Alps(GH200 16 ノード、ノード内 150 GB/s、ノード間 Cray Slingshot 25 GB/s)での AllReduce 実測は次を示した([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]])。 - ノード間: LL・LL128 が 64 KiB 未満で最速。ギガバイト域では 8 B / 128 B ごとのフラグ同期が数百万回累積して性能が急落し、Simple が一貫して最速になる。ノード間の大メッセージでは LL128 が LL を下回る場合すらある。 - ノード内: LL128 が全メッセージサイズで最も安定した最高性能を示す(大メッセージでも Simple の 5% 遅れ程度)。Ring は大メッセージ、Tree は小メッセージで優位。同論文の教訓は「ノード内外でアルゴリズムの性能特性が異なることを前提に置くこと」と「ほとんどの場合はオートチューニングに任せるのが有益」の二点に集約される。ここには NVLS と CollNet、および NCCL 2.23 以降の PAT が含まれていない点は留意が要る。 #### 3.2.6 デフォルト設定は最適ではない Alps・Leonardo・LUMI の 3 台を最大 4,096 GPU で横断計測した研究は、デフォルト設定がすべてのシステムで最適から程遠いと結論する。`NCCL_IGNORE_CPU_AFFINITY=1` で Alps / LUMI の alltoall が最大 1.6 倍・allreduce が最大 6 倍、`NCCL_NET_GDR_LEVEL=3` で alltoall 2 倍・allreduce 3 倍、LUMI の `NCCL_NCHANNELS_PER_PEER=32` でノード内点対点が 3.5 倍改善した。手動チューニングで最大 1 桁の性能向上が得られる([[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。同研究はさらに、スコープによって最適な通信ライブラリが逆転することを示した。ノード内の集団通信では集合通信ライブラリがトポロジ最適化ゆえに優位だが、ノード間の点対点では GPU-Aware MPI が小転送で最大 1 桁・大転送で最大 3 倍高速である。集合通信ライブラリはカーネルの起動・管理オーバーヘッドを負うためである([[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 Rail-Optimized トポロジ上では、3 ノード以上の AllReduce で NCCL がデフォルトで Spine を越えるリングを形成することがあり(特に奇数ノード)、`NCCL_CROSS_NIC=0` によってリングを Leaf 層内に閉じ込め Spine 通過トラフィックをほぼゼロにできる([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])。→ [[Rail-Optimizedトポロジ]] ### 3.3 学習ワークロードの通信特性 #### 3.3.1 メッセージサイズ分布 VGG16 は全結合層に起因する最大 392 MB の巨大メッセージを持ち、ResNet50 はすべて小さい。PyTorch DDP の 25 MB バケットサイズ設計により多くのメッセージが 25 MB 付近に集中する。GPT モデルでは 100 MB 超の大規模フローが支配的で、従来のデータセンターアプリケーションとは分布が根本的に異なる([[@2024__APNet__Understanding Communication Characteristics of Distributed Training]])。 #### 3.3.2 予測可能性と半予測可能性密活性化モデルでは、論理的な並列化戦略と物理マッピングが決まれば、どの GPU ペアが通信するかを実行前に計算できる。対して MoE の AllToAll は動的で、訓練初期と後期でヒートマップが大きく異なる。ただしゲートネットワークの学習に伴いトークン分布の均一性が増し、3 サイズ(125M / 350M / 760M)すべてで訓練初期 100 イテレーション内に収束する傾向が観測された。すなわち MoE は「半予測可能」である([[@2024__APNet__Understanding Communication Characteristics of Distributed Training]])。 #### 3.3.3 バースト性とスキュー AllToAllv は MoE 層ごとに 2 回呼び出され、訓練時間の 30〜56% を占める。ゲーティング関数が一部エキスパートに偏るため GPU 対間の転送量は最大 12 倍以上ばらつき、トークンルーティングは入力とゲーティングで決まるため数百ミリ秒ごとにパターンが変化する([[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]])。この時間スケールは、静的スケジュールの前提を単独で破壊する。一方 DP 系の集合通信は「少数の長寿命フロー」からなる予測可能な通信モデルであり、この規則性がトラフィック計画・QP 単位負荷分散・シミュレーション高速化という三つの独立した最適化の共通前提になっている([[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]], [[@2025__arXiv__Collective Communication for 100k+ GPUs]], [[@2026__NSDI__Supercharging Packet-level Network Simulation of Large Model Training via Memoization and Fast-Forwarding]])。 #### 3.3.4 帯域感度は操作ごとに大きく違う Mixtral-8x22B を 32 GPU(TP/SP=4、EP=8)で訓練し、InfiniBand を 400 Gb/s から 100 Gb/s へ落としたときの実行時間増加は、AllToAll 4.1 倍・AllGather 4.4 倍・ReduceScatter 1.5 倍・AllReduce 9.7 倍だった。通信量の小さい AllReduce ほど帯域低下の影響を強く受ける([[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]])。さらに同研究のハードウェアインザループ実験では、AllReduce と AllToAll をそれぞれ単独実行すると安定するのに、両者を混在させると相互に悪化した。AllReduce の高レートフローが DCQCN 輻輳制御を発火させ、AllToAll の多数の低帯域フローを不釣り合いに抑制して、フロー完了時間分布に長いテールを作るためである([[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]])。単一操作のベンチマークが健全でも、混在時に破綻しうる。 ### 3.4 通信と計算のオーバーラップ設計 #### 3.4.1 SM 競合という本質オーバーラップの障害は帯域ではなく SM である。NCCL の P2P 操作は縮約を伴わないにもかかわらず無視できない SM を消費し、SendRecv で SM 利用率 9.7%、AlltoAll で 3.5% を占めて GEMM との重複を阻害する([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]])。またコピーベース設計は送受信双方で FIFO バッファを介する D2D コピーを要し、SM と HBM 帯域を計算と奪い合う([[@2025__arXiv__Collective Communication for 100k+ GPUs]])。 #### 3.4.2 SM をどこまで削れるか — 二つの流儀 | 設計 | 手段 | 到達点 | |---|---|---| | CTran(NCCLX) | ホスト駆動・ゼロコピー・SM フリーを原理とし、communicator ごとの CPU バックグラウンドスレッドがアルゴリズムをスケジュールする。同期は host-pinned フラグで、オーバーヘッドは常に 1 µs 未満 | 大半のカーネルを排除するが、device-initiated API が未完で一部操作に SM が残る | | VCCL | ノード内データ移動を CPU スレッドとコピーエンジンに移譲し、ストリーム依存性は `cuStreamWriteValue` / `cuStreamWaitValue` で表現(`cudaLaunchHostFunc` は単一スレッドでシリアライズされデッドロックした) | 非リダクション系 P2P でカーネル起動をゼロにし、訓練スループット平均 4.00%・最大 5.28% 向上 | 出典は順に [[@2025__arXiv__Collective Communication for 100k+ GPUs]] と [[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]]。VCCL は 1 SM を残す NCCLX 類似ベースラインより最大 1.73% 高く、1 SM でも訓練効率が計測可能な程度に低下することを示した。ノード間の小メッセージレイテンシは平均 18.9% 削減、ノード内の大メッセージ帯域は約 7% 向上した(コピーエンジンが SM より広いトランザクションを発行して NVLink を飽和させるため)。 #### 3.4.3 TP のオーバーラップ既存の TP オーバーラップは CUDA IPC 依存で単一ホスト(TP ≤ 8)に限られていた。CTran は MPI-2 準拠の片側 Put セマンティクスを持つ `CtranWindow` / Put API を用い、ノード内は SM フリーの NVLink CopyEngine、ノード間は RDMA write にマップする。Ring パイプラインをトポロジ対応の Tree パイプラインに拡張し、低速なノード間 RDMA 転送を高速なノード内 NVLink チャンク転送で隠すことで、単一ノードで E2E レイテンシを 1.57 倍低減した([[@2025__arXiv__Collective Communication for 100k+ GPUs]])。 #### 3.4.4 「隠す」から「隣接演算ごと削る」へ推論側では、AllReduce と直後の RMSNorm(残差加算込み)を NVSHARP / Multimem で単一カーネルに融合し、SM 占有を 2〜8 個に抑えたうえで逐次実装比 1.34〜1.39 倍を得る設計が現れた([[@2025__arXiv__TokenWeave - Efficient Compute-Communication Overlap for Distributed LLM Inference]])。注意すべきは、単純に AllReduce を ReduceScatter + AllGather へ分解して RMSNorm を挟むだけでは分解自体のオーバーヘッドが削減分を相殺し、512〜8K トークン域で 0.92〜0.98 倍と逆に悪化することである。同じ着想でも融合の設計次第で利得にも損失にもなる。 #### 3.4.5 制御プレーンもオーバーラップを妨げる Horovod のコーディネータ・ワーカー方式は毎イテレーション同一メタデータを送り続け、GPU 数に対して O(N) で増大する。6000 GPU ではコーディネータ処理が律速し GPU 利用率が 55% 未満に落ちた。応答キャッシュとビットベクタの大域積集合で 2 イテレーション目以降の制御通信を完全にバイパスし、テンソルのグルーピングで通信バッファサイズを明示制御した結果、既存 Horovod 比 1.97 倍、GPU 利用率 1.48 倍を達成した([[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]])。AllReduce と計算の重複率は Horovod と torch.DDP で 95% 超、tf.distribute で約 75% と報告されており、オーバーラップ率そのものがフレームワーク間の性能差になる。なおグルーピングの効果はバックエンド依存である。NCCL では大きなバッファでの AllReduce が可能になり帯域利用効率が改善するが、MPI では効果が限定的または負になる場合がある([[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]])。 ### 3.5 10 万 GPU 規模の課題とスケール則 #### 3.5.1 ファブリック階層とレイテンシの段差 10 万 GPU 超を単一 RoCE ファブリックに統合する構成では、DC 内が 3 層 Clos(RTSW / CTSW / ATSW)、建屋間が ATSW 層の全結合メッシュとなる。同一ラック内が最低レイテンシで、ラック間・AI-Zone 間・DC 建屋間はそれぞれ約 7 倍・15 倍・30 倍のレイテンシ増を被る([[@2025__arXiv__Collective Communication for 100k+ GPUs]])。この段差の存在が、トポロジ対応のジョブ配置と、リング系の線形複雑度を避ける recursive doubling / halving の採用を必然にする。 #### 3.5.2 規模とともに非線形に膨らむコスト | 項目 | 大規模での症状 | 対処と効果 | |---|---|---| | 初期化 | 通信協調のコストが二次的に増大し、96K 規模では NCCL の初期化が 4 分超に達して再起動時間を支配する | Global Process Group、TCPStore による bootstrap ring 形成、O(N²)→O(N) の CPU 最適化で最大 11 倍高速化 | | メモリ | Llama4 事前学習で 10 以上の並列グループにわたり約 10 GB(H100 HBM の約 12.5%)を消費 | Lazy Algorithm Initialization、Lazy Channel Allocation、Slab Allocator により 64K GPU でほぼ半減 | | 輻輳 | ゼロコピーの一括ハンドオフがファブリック任せの輻輳制御となり過剰なバッファ蓄積を招く | DQPLB で接続種別・トポロジ別に未確認データ量・QP 数・最大セグメントサイズを設定し、スイッチバッファ蓄積を一桁削減 | いずれも [[@2025__arXiv__Collective Communication for 100k+ GPUs]]。加えて CUDA / RDMA を mock ライブラリで差し替える CPU エミュレーションにより、3,072 CPU サーバから 96K 規模のテストを行い、busy-loop on I/O、O(N²) 複雑度、64K rank 超での TCP listen queue 溢れといった問題を実機投入前に発見している。 #### 3.5.3 律速層はスケールとともに移動する 2022 年時点の 6000 GPU 評価で同定されたボトルネックはコーディネータの制御通信、すなわち制御プレーンだった([[@2022__NSDI__Accelerating Collective Communication in Data Parallel Training across Deep Learning Frameworks]])。10 万超 GPU 規模では、カーネル駆動・コピーベースというデータプレーン設計そのものが限界として再設計を迫られている([[@2025__arXiv__Collective Communication for 100k+ GPUs]])。同じ「集合通信が律速する」という問題意識が、規模の拡大に伴って層を移しながら現れ続けている。 #### 3.5.4 スケール則の実測集合通信ライブラリは最大 1,024 GPU で約 75% の効率を維持したが、alltoall では 512 GPU 以上で NCCL・RCCL の双方がスタックし計測不能になる不安定性が観測された。さらに 1,024 GPU 規模では実本番のネットワークノイズが allreduce を最大 50%・alltoall を最大 20% 低下させる。InfiniBand HDR Dragonfly+ の Leonardo は全トラフィックがデフォルトでサービスレベル 0 に集中してノイズを受けやすく、HPE Cray Slingshot の Alps / LUMI はほぼ影響を受けなかった([[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。規模だけでなくファブリック技術が性能を支配する局面がある。 #### 3.5.5 障害を前提とした集合通信 10 万デバイス規模では障害でジョブが頻繁に停止・再起動する。FSDP は冗長な重みを持たず弾力化が難しいため、最外殻を Hybrid Sharding Data Parallel へ移行し、replica group 内は FSDP でシャード、group 間はステップ末に AllReduce で勾配同期する構成が採られた。Fault Tolerant AllReduce は Ring を用い固定チャンクサイズと本数で決定的トラフィックを実現し、標準 NCCL AllReduce と同等レイテンシを thread block 半分で達成する(同数に揃えると 9〜18% 低レイテンシ)([[@2025__arXiv__Collective Communication for 100k+ GPUs]])。→ [[耐障害LLM訓練]] ### 3.6 異種クラスタのスケジュール合成と全対全のスケジューリング #### 3.6.1 なぜ既存の合成器が壊れるか SCCL・TACCL・TE-CCL・SyCCL は各リンクの転送完了時間を MILP / SMT 式に符号化するが、リンク帯域がクラスタ内で大きく異なると、同一ステップに所要時間の不均一なプリミティブが混在してパイプラインバブルが生じ、合成された「最適」スケジュールが実性能を大幅に下回る。さらに対称性ベースの探索削減がヘテロジニアス環境では失効し、TACCL は 32 GPU で解を得られず、TE-CCL は 64 GPU で 9 時間超を要した([[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]])。 #### 3.6.2 HeteCCL — 均質化と反例誘導 HeteCCL の中心的洞察は二つ。第一に、各ステップ内のプリミティブ実行時間を均一化すること。チャンキングにより各物理リンクを論理リンクへ分割し、論理容量を `C(u, v) = (τ_ref / τ_{u,v}) × n` として量子化することで、連続時間ドメインの問題を離散パッキング問題に変換する。第二に、所要時間が揃うと反例 1 件が部分木ごと(n! 規模以上)の候補を枝刈りできるため、CEGIS(反例誘導的帰納合成)が対称性の代わりのスケーラビリティを与える([[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]])。 | GPU 数 | TACCL | TE-CCL | HeteCCL | 速度向上 | |---|---|---|---|---| | 16 | 30 s | 2.2 s | 0.9 s | 2.4× | | 32 | タイムアウト | 24.7 s | 6.9 s | 3.6× | | 48 | タイムアウト | 497 s | 5.5 s | 90.4× | | 64 | タイムアウト | 33,990 s | 105.3 s | 322.8× | H20 と V100 の混在クラスタで AllGather は NCCL 比 1.5〜2.5 倍、AllReduce は NCCL 比 1.2〜2.8 倍、エンドツーエンドの訓練イテレーション時間は TACCL 比 10〜37% 削減された。GPU 障害による非対称トポロジでも有効スケジュールを合成し NCCL 比 3.25 倍の帯域改善を示す。ただし SMT の直接適用は 64 GPU までが実用的で、それ以上はポッド内・ポッド間の階層合成に依存し、ポッド境界を越えるグローバル最適性は犠牲になる([[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]])。 #### 3.6.3 FAST — 全対全を多項式時間に落とす FAST は「スケール内帯域はスケール外より約 1 桁高速」という観察から、スケール外に見せるワークロードをスケール内で整形する。フェーズ 1 でサーバ内バランシングとピアトランスファーを行い GPU レベル行列をサーバレベル行列に縮約し、フェーズ 2 で Birkhoff 分解によって任意のトラフィック行列を置換行列の加重和へ分解する。各置換行列が「すべての能動的送信元が一つの受信先へ同量を送り、全員が同時に終わる」ステージに対応するため、インキャストが原理的に起きず、ボトルネックサーバが全ステージで稼働し続けるため理論的完了時間の下限に達する。計算量は O(N⁵)([[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]])。合成時間は 32 GPU で 25 µs、64 GPU で 221 µs、96 GPU で 805 µs、EP320(40 サーバ)でも 77 ms。最速のソルバーベースである SyCCL が 16 GPU で 3.6 秒を要するのに対し、FAST は同規模 3.1 µs と約 1,000 倍速い。AMD MI300X での Megatron-LM MoE 訓練では RCCL 比 1.18〜4.48 倍(Top-K を変えた場合は 1.75〜7.88 倍)のスループット向上を得た。ただし均等 AllToAllv ではバランシング・再配布のオーバーヘッドが乗るため既存手法と同水準に留まり、実測は 4 サーバ 32 GPU に限られる([[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]])。 #### 3.6.4 対比 | | HeteCCL | FAST | |---|---|---| | 対象操作 | AllGather・AllReduce | AllToAllv | | 対象環境 | ヘテロジニアス | 2 層ファブリック(ホモジニアス) | | 探索削減の手口 | チャンキングによる均質化 + CEGIS | スケール内での整形 + Birkhoff 分解 | | オンライン性 | 合成コストを多数イテレーションで償却 | 数百ミリ秒ごとの再合成に耐える | 両者は「問題固有の構造で NP 困難な探索を削減する」という同じ設計志向を、異なる前提の下で独立に体現している([[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]])。ヘテロジニアス環境での AllToAllv スケジューリングは、両者の交点として未解決のまま残っている。 ### 3.7 レイテンシ最小化の最前線長文脈・デコード主体の[[LLM推論]]では、多くの小さな集合通信がトークン生成のクリティカルパス上に直接位置するため、数マイクロ秒のオーバーヘッドが性能とコストに効く。ここで問題になるのが明示的なメモリバリアである。GB200 で実測したバリアレイテンシは GPU 数 2〜32 にわたり unicast で 0.85〜1.68 µs、NVLS マルチキャストで 1.12〜1.25 µs に達し、小メッセージ AllReduce が約 5 µs で完了する場合、2 回のバリアだけで総レイテンシの約 40% を占める([[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]])。同研究は理論下限を実測から導いた。`__threadfence()` のレイテンシ計測で L2 ラウンドトリップを、2 GPU 間 ping-pong で remote store レイテンシを求め、`L_SoL = 2·L_L2RTT + L_remote store` とする。GB200 では 0.306 µs と 0.792 µs から 1.404 µs が得られる。バリア排除には四つの技術を用いる。 1. **LL**: 8 バイトのフラグを 8 バイトのデータとパックし 16 バイトの atomic store で送る。有効帯域を半減させるため極小メッセージ向け。 2. **sentinel 同期**: 受信側 scratch バッファを `-NaN` のような出現しにくい値で初期化し、値の変化で到着を検知する。帯域を保つが再利用前のリセットが要る。 3. **双方向通信 + double buffering**: 2 つの scratch バッファを交互に使い、ピアからの受信そのものを次送信への暗黙の許可として扱う(credit-based flow control に類似)。複数イテレーションを大域バリアなしで回せる。 4. **two-shot LL128 atomic**: 8 スレッドの group が 128 バイトのキャッシュライン単位で atomic addition により縮約結果を蓄積し、flag carrier が先頭要素がランク数 N に達したことをポーリングして完了を検知する。FP32 で 128 バイトあたり 4 バイト(約 3%)の追加バッファで済む。ただし浮動小数点 atomic の順序非保証により non-deterministic である。結果、2 GPU で SoL 下限比約 7% のオーバーヘッドに到達し、64 GPU でもマルチキャスト one-shot 亜種は約 70% に収まる。vLLM 推論での inter-token latency は 4 GPU で 7〜13%、8 GPU で 9〜11.4% 削減され、DeepSeek-V3 の 8 GPU 構成では出力 100 万トークンあたり 11 ドル超のコスト削減が推定された。伝統的 HPC でも cuSOLVERMp の GFLOPS/GPU が最大 7.0% 改善している([[@2026__arXiv__Every Microsecond Matters Achieving Near Speed-of-Light Latency in GPU Collectives]])。この方向はハードウェアへも波及している。Rubin GPU は device-initiated NVLink 通信に counted writes を導入し、受信側 GPU が転送完了をカウンタで追跡できるようにすることで、メモリバリア・確認応答・アトミックフラグに頼るコーディネーションそのものを不要にする方向を取る([[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]])。 ### 3.8 集合通信ライブラリに求められる可観測性と信頼性集合通信ライブラリは内部状態を露出しないブラックボックスとして振る舞うため、性能と信頼性の両面で運用上の課題を生む([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])。この壁の破り方は大きく三通りに分かれる。 | 経路 | 代表例 | 計装点 | 主な成果 | |---|---|---|---| | 外から見えるようにする | Mycroft | NCCL proxy スレッドへの約 1,100 行の C++ 計装、フロー単位とチャンク単位 | 90% のケースを 15 秒以内に検知、60% を 20 秒以内に根本原因特定 | | 内側から計装する | VCCL | WR 投稿時 t1・WC 生成時 t2 のスライディングウィンドウ集約 | O(µs) 粒度の帯域推定、ランタイム診断率が 100% に接近 | | ライブラリ自身が診断機能を持つ | NCCLX | CollTrace(collective・RDMA 粒度)+ Fault Analyzer、Perf profiler | 初発の停止コレクティブと故障ホストを特定 | 出典は順に [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]]、[[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]]、[[@2025__arXiv__Collective Communication for 100k+ GPUs]]。いずれの設計にも共通する制約は「GPU の本計算を邪魔しないこと」である。Mycroft はホスト共有メモリ上の固定サイズ環形バッファ(ホストあたり 512 MB)へ直接書き込み、別の read-only エージェントが Kafka 経由でアップロードすることで臨界経路のオーバーヘッドをほぼゼロにする。10,000 GPU のジョブは 1 日あたり約 3 TB のトレースを生成し、1 日保持後に破棄される。対照的に、Nsight Systems は単一サーバでしか使えず、NPKit は実験でバス帯域を 3 分の 2 に低下させ、NVRx は 60 秒ごとにしか結果を出さない([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])。可観測性の設計は、常に計装コストとの綱引きになる。→ [[GPU観測性]] / [[LLM学習モニタリング]] 信頼性の側では、VCCL がブートストラップ時に各 GPU ペア間で最近傍 NIC を使うプライマリ QP と次近傍 NIC を使うバックアップ QP を生成し、受信側主導で切り替える。SyncFifo で送受信状態を同期し、`restartPos` を参照して breakpoint から in-place に再送する。24K GPU の本番クラスタでは、デュアルプレーン化で GPU 時間浪費を 29.6% 削減した後、この耐障害機能で残余の GPU 待機時間をさらに約 90% 削減した([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]])。ライブラリ内に冗長機構を持たせる発想は独立に複数現れており、sender 起点の in-band 同期でフェイルオーバーを完結させ、さらに Dynamic Channel Rebalancing と Transit GPU over NVLink でフェイルオーバー後の劣化まで埋める設計もある([[@2026__EuroSys__Handling Network Faults in Distributed AI Training]])。トレース形式の標準化も進んでいる。Chakra Execution Trace は計算・メモリ・通信のノードと制御・データ・同期の依存関係を DAG として記録し、モデルパラメータやデータセットの詳細を開示せずに企業間でワークロードを共有できるようにする。リプレイした NCCL カーネルのバス帯域比は概ね 1.0〜1.3 倍(計算とのメモリ競合がないため元より速い)で、この手法により AllGather と ReduceScatter の並列実行機会を特定して通信性能を 2 倍改善した実績が報告されている([[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]])。 ### 3.9 実運用の要点 — 通信劣化をどのレイヤの問題として切り分けるか #### 3.9.1 まず押さえるべき原則第一に、**NCCL タイムアウトは症状であって原因ではない**。障害タクソノミーでは NCCL timeout はユーザコード・システムソフトウェア・ハードウェアの全ドメインにまたがる曖昧な症状として扱われ、近接原因であるネットワークへ素朴に帰属しがちだが、実際にはデッドロック・userspace crash・故障ハードウェアなど複数の原因がありうる([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。第二に、**集合通信は障害を隠す**。NCCL がアダプタ障害を透過的にリルートすると帯域が実質半減しステップ時間が約 0.3 秒増えるが、ジョブはクラッシュせず見かけ上動き続けるため[[ストラグラー]](フェイルスロー)になる。MoE ではエキスパート並列の 2 同期点で影響が層数分累積する([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])。「落ちていない」ことは「健全である」ことを意味しない。第三に、**同じ症状でも単一のシグナルでは切り分けられない**。VCCL が「現在帯域が直近の同プリミティブ平均の 50% 未満」かつ「NIC 上の未送信データ量が過去最大の 2 倍超」という二重しきい値を採るのは、帯域低下だけを見ると GPU-burn のような非ネットワーク原因を誤検知するからである([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]])。 #### 3.9.2 症状からレイヤへの一次仕分け | 観測される症状 | まず疑うレイヤ | 根拠 | |---|---|---| | 導入直後から全体的に遅い | 設定(環境変数・トポロジ認識) | デフォルト設定は最適から程遠く、手動チューニングで最大 1 桁改善しうる([[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。Rail-Optimized 環境では `NCCL_CROSS_NIC=0` の適用有無を確認する([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) | | ジョブ配置によって性能が揺れる | ファブリック・ジョブ配置 | Dragonfly+ ではグループ間で goodput が平均 17% 低下し、1,024 GPU 規模のノイズが allreduce を最大 50% 低下させる([[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]]) | | 帯域が急に半減し、その後一定 | NIC・リンク障害と透過的リルート | 帯域実質半減とステップ時間 +0.3 秒([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])。ポート障害は 400 Gbps 超クラスタで多発する([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]]) | | 特定ランクだけが遅い | ノード内の計算・ストレージ・ハードウェア | 他より 1 秒以上遅く開始/終了するランクをストラグラーと判定する運用閾値([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]]) | | 単独ベンチマークは健全なのに本番だけ遅い | 操作間の輻輳制御干渉 | AllReduce と AllToAll の混在が DCQCN を介して相互干渉し、AllToAll のフロー完了時間に長いテールを生む([[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]]) | | 初期化・再起動が遅い | 制御プレーン | 96K 規模で NCCL の初期化が 4 分超に達し再起動時間を支配する([[@2025__arXiv__Collective Communication for 100k+ GPUs]]) | | メッセージサイズによって速度が逆転する | プロトコル/アルゴリズム選択 | ノード間の大メッセージでは LL128 が LL を下回ることがあり、最適プロトコルはノード内外で異なる([[@2025__IEEE__Demystifying NCCL - An In-depth Analysis of GPU Communication Protocols and Algorithms]]) | #### 3.9.3 切り分けの前提となる観測粒度集合通信の Op をひとかたまりとして見るかぎり、上表の多くは区別できない。単一フローのみに影響するトラフィックスパイク・ジッタ・輻輳は Op 単位のトレーシングでは検知も箇所特定もできず、フロー単位・チャンク単位まで降りて初めて見える([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])。集合通信ライブラリを差し替え可能なレイヤとして扱い、計装点をあらかじめ確保しておくことが、事後の切り分け能力を決める。なお、どの粒度(フロー / QP / チャンク / ステップ)を選ぶべきか、そして観測されたシグナルから根本原因へどう到達するかという診断手法そのものは第 VIII 部で扱う。本部の役割は、そこで観測される値が何を意味するかを与えるプリミティブ側の構造を明らかにすることにある。  --- ## 第 IV 部ネットワーク設計と物理層の運用大規模学習クラスタでは、計算資源そのものよりネットワークが律速要因になる。100 兆パラメータ級の学習を想定した試算では、理想ネットワーク下でも露出通信時間が密な Transformer で 5%、MoE で 20% を占め、スケールアップ帯域を 0.8 Tbps に落とすとそれぞれ 40%・75% まで膨らむ([[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]])。第 IV 部では、この制約に対して事業者がどのようなトポロジ・トランスポート・物理層を選び、どう運用しているかを扱う。 ![[Attachments/llm-training-ch04-network.png]] *図 5. 第 IV 部のネットワーク設計。マルチレール・マルチプレーンの経路分離と、RoCEv2 の輻輳制御・リンク停止・障害迂回を示す。*（Source: [[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]], [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]） ### 4.1 学習トラフィックの特異性 #### 4.1.1 少数の大象流と低エントロピー汎用クラウドが数百万のフローを生成して [[ECMP]] のハッシュ分散が統計的に機能するのに対し、LLM 学習では各ホストが数十から数百のフローしか生成せず、しかも逆伝播の勾配同期で瞬間的に 400 Gbps まで飽和する([[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]])。この低エントロピー分布が 3 層 Clos では 3 段のカスケードハッシュ偏極を生む。Meta も同じ問題を「5 タプルエントロピーが低くフロー衝突が最大 40% 超の輻輳を引き起こす」「最多リンクフロー数対平均比(MMR)が 1.2 以上になる」と報告している([[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]])。 #### 4.1.2 同期バリアとテイルレイテンシ支配学習は全 GPU が同期してイテレーションを完了するため、単一の GPU・ホスト・リンクの遅延が全体を止める。この「桶の効果(barrel effect)」により、単一のフラッピングするスイッチポートや RNIC のパケットドロップに極端に敏感になる([[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])。コンテナ化学習の実測では、RTT が 10 µs 増えるだけで学習が約 20% 減速し、接続性問題が 4 秒を超えると集合通信がタイムアウトしてタスク全体が失敗する([[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]])。設計哲学としては「検知・修復・再開」から「検知・回避・回復」への転換が語られる([[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]])。 #### 4.1.3 障害の経済的コスト Alibaba の本番統計では NIC-ToR リンクの 0.057%/月が障害、ToR の 0.051%/月が致命エラーとなる。チェックポイント間隔が 2〜4 時間のため、3K GPU の学習では 1 回の障害が約 3 万ドルの損失に相当する([[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]])。同じ障害率を用いた 16K GPU・Llama3-405B のシミュレーションでは、再起動方式に対してフェイルオーバー方式が GPU 時間の中央値超過分を 64.96% 削減できると試算されている([[@2026__EuroSys__Handling Network Faults in Distributed AI Training]])。 #### 4.1.4 通信パターンの疎性 Meta が約 3 万件の学習ジョブを Chakra で分析した結果、DDP 系は AllReduce と AlltoAll(v) が支配的、FSDP 系は AllGather と ReduceScatter が支配的で、AlltoAll(v) は 1 GPU あたり平均 15 の QP を使い 128 GPU 構成でスイッチバッファを 65.6 MB 占有する([[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]])。一方で MegatronLM 系の分析では、テンソル並列のトラフィックは HB ドメイン内に完全に留まり全転送量の 75% 超を占め、NIC ドメインの通信は全 GPU ペアの 0.04% 未満、そのほぼすべてが同一レール内に限られる([[@2023__arXiv__Rail-only - A Low-Cost High-Performance Network for Training LLMs with Trillion Parameters]])。この疎性が、後述するトポロジ簡素化の根拠になる。 ### 4.2 トポロジ設計 #### 4.2.1 Fat-Tree/Clos という出発点 k-ary [[Fat-Tree]] は均質な商用スイッチのみで全二分帯域幅を提供する設計で、k=48 なら 5k²/4 のスイッチで 27,648 ホストを収容し、任意のポッド間ホスト対に 576 の等コスト経路を持つ([[@2008__SIGCOMM__A Scalable Commodity Data Center Network Architecture]])。現代の [[データセンターネットワークトポロジ]] 議論はここを起点とするが、百万 GPU 規模では 4 段・87,500 スイッチ・240 万リンクとなり光トランシーバだけで 50 億ドルに達し、予算内に収まらない([[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]])。 #### 4.2.2 レール最適化とレール専用 [[Rail-Optimizedトポロジ]] は、サーバ内 GPU N 番に対応する NIC N 番を必ず Leaf N 番へ配線し、同一 GPU 番号のノード間通信を同一 Leaf 内で閉じる設計である。NCCL は既定でこれを正しく使わず、3 ノード以上の AllReduce で Spine 越えのリングを作ることがあるため、`NCCL_CROSS_NIC=0` を設定してリングを Leaf 内に閉じ込める運用が要る([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])。また、サーバベンダごとに GPU/NIC の物理ポート番号体系が異なるため、異種サーバ混在時は配線のずれで Spine 経由のリングが形成され性能が劣化する。疎性を極限まで使うと Spine 層自体が不要になる。Rail-only は各レールを独立した小規模 Clos とし、レール間通信を HB ドメイン経由の 2 段フォワーディングで処理する。32,768 GPU 構成でスイッチ台数 1,280 → 256(77% 減)、トランシーバ 196,608 → 65,536(67% 減)、コスト 38〜77%・消費電力 37〜75% の削減となり、MoE の All-to-All のオーバーヘッドは 8.2〜11.2% に留まる([[@2023__arXiv__Rail-only - A Low-Cost High-Performance Network for Training LLMs with Trillion Parameters]])。 #### 4.2.3 マルチプレーンとマルチレール [[マルチプレーンClosトポロジ]] は 1 枚の 800G NIC を 8 本の独立した 100G プレーンに分割し、スイッチ段数を増やさず横方向に拡張する。OpenAI はこれで 2 段構成のまま 131,000 GPU 超へ拡張したとされる([[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]])。マルチプレーン(NIC 側の分割)とマルチレール(ラック単位の分割)を組み合わせるとスイッチコスト 50%・リンクコスト 66% の削減が見込まれる([[@2024__HotNets__I've Got 99 Problems But FLOPS Ain't One]])。ただしトポロジとスケジューリングは密結合になり、障害時の配置変更自由度が下がるという代償を伴う。 #### 4.2.4 Dragonfly の位置づけ [[Dragonflyトポロジ]] は複数のハイラジックスルータをグループとして束ね、グループを仮想ルータとして扱う階層設計で、16K ノード以上で折り畳み Clos 比 52% のコスト削減が成立する。ただし最小ルーティングのみでは他トポロジに対する優位が薄く、グローバル適応ルーティングの活用が前提になる([[@2008__ISCA__Technology-Driven, Highly-Scalable Dragonfly Topology]], [[@2009__IEEE-Micro__Cost-Efficient Dragonfly Topology for Large-Scale Systems]])。実機比較では InfiniBand HDR Dragonfly+ を採る Leonardo でネットワークノイズが AllReduce を最大 50%・AllToAll を最大 20% 劣化させたと報告されており、ノイズ耐性がファブリック技術に強く依存する([[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 #### 4.2.5 設計インテントから設定を生成する層トポロジを決めても、インタフェース命名・ポートマッピング・IP 割当・AS 番号・ルーティングポリシーを数千台分生成する工程が残る。Matryoshka はこの空白を埋めるインテント駆動の設定生成システムで、Clos とフルメッシュを基本ブロックとするモジュラー合成、決定論的かつステートレスなコンパイル、ベンダ非依存の中間表現 GSC を柱とする([[@2026__NSDI__Matryoshka - Realizing Hyperscale Data Center Network Design for the AI Era]])。6 年の本番運用で 18 種類・約 900 DCN を管理し、10 万 GPU スーパークラスタを含む。設計変更は週 800〜2,000 オペレーション発生し、差分増分更新への移行でファブリック拡張のトランザクションを 34.60 分から 46 秒(97.8% 削減)へ短縮している。決定論的・ステートレス設計により、ブラウンフィールド改修をグリーンフィールド新設と同じコードパスで扱える点が運用上の要点である。 ### 4.3 主要事業者の実装比較 | システム | 規模 | 段数 | トポロジの要点 | トランスポートの選択 | 特徴的な運用判断 | |---|---|---|---|---|---| | Alibaba HPN | 1 Pod 15,360 GPU | 2 層 | デュアルプレーン + レール最適化 + 非スタック型デュアル ToR。1 セグメント 1,024 GPU | RoCEv2 | 経路選択の探索空間を O(60) に圧縮。DCN+ 比で学習スループット 14.9% 向上、8 か月間 ToR 起因の単一障害点ゼロ | | Meta RoCE | クラスタ 24,000 GPU(Llama3 は 16,000 GPU 使用) | RTSW/CTSW の 2 段 Clos + ATSW | AI Zone 単位。Zone 間はオーバーサブスクリプション。最小カットベースのトポロジ認識スケジューラ | RoCEv2。400G 以降は DCQCN を廃止し PFC のみ | 輻輳制御を集合ライブラリ層の受信側駆動許可制御へ移譲。ルーティングは ECMP → 拡張 ECMP → 集中型 TE → フローレットへ段階的に進化 | | Tencent Astral | 現在 2 Pod・128K GPU、512K GPU へ拡張中 | 3 階層 | 同一レール相互接続を tier-2 まで引き上げ、単一レール最大 8K GPU・1 Pod 64K GPU。全階層で集約帯域を同一に保つ | RoCEv2 | 全階層でオーバーサブスクリプションを排除。8K GPU で効率損失 0.6%。分散 HVDC 電源と空気液体統合冷却で平均 PUE を最大 16.34% 改善 | | SAKURAONE | 100 ノード・800 GPU | 2 段 leaf-spine(2 pod、leaf 16 + spine) | レール最適化。800 GbE(2×400 GbE) | RoCEv2 + SONiC | TOP500 上位 100 で唯一のフルオープンなネットワーキングスタック。ECN 閾値のみ調整し PFC バッファはベンダ既定を維持 | | Rail-only(提案) | 分析対象 32,768 GPU | レールごとの独立 Clos(Spine 除去) | レール間通信は HB ドメイン経由の 2 段フォワーディング | 前提を置かず | スイッチ 77%・トランシーバ 67% 削減。実クラスタ実装による検証は未実施 | | Meta Matryoshka | 約 900 DCN、最大 10 万 GPU の BE ネットワーク | 種別ごとに可変(18 種類) | Clos とフルメッシュのモジュラー合成。Rail-based と DSF に対応 | 対象外(設定生成層) | 設計インテントからスイッチ設定を決定論的に生成。GSC 出力正確率 95.4% | | Cycloud(サイバーエージェント) | 1 SU で GPU サーバ 56 台 | Leaf 4 + Spine 3 | レール最適化、ダウンリンク:アップリンク 7:1 | RoCEv2、400G/800G 混在 | NVIDIA SN4700 と Juniper QFX5240 の異 ASIC 混在。Ingress interface hashing + DLB で既定比ほぼ 2 倍 | | ソフトバンク GB200 NVL72 | ラック単位 | ラックスケール | Compute / Converged / OOB の 3 Fabric 分離 | RoCEv2、BGP unnumbered + W-ECMP | Scalable Unit を障害ドメイン単位とし、性能重視なら同一 SU、可用性重視なら別 SU へ GPU を割り当てる | HPN の論文が示す既存事例との比較では、NVIDIA SuperPod が 16,384 GPU・3 層・経路選択複雑度 O(4096)、Google Jupiter が 26,000 GPU・3 層・O(2048)、Fat-tree(k=48) が 27,648 GPU・3 層・O(2304) であるのに対し、HPN は 15,360 GPU・2 層・O(60) と探索空間を 1〜2 桁削減している([[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]])。Astral はこれらを「同一レール最適化が ToR に留まる」「Pod 間にオーバーサブスクリプションを課す」と評価し、tier-2 まで同一レールを引き上げる設計を対置する([[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]])。 ### 4.4 ロスレス転送の実際 #### 4.4.1 PFC と DCQCN の基礎 RoCEv2 は無損失 L2 を前提とし、[[データセンター輻輳制御]] の観点では PFC が防衛の盾、ECN/DCQCN が攻めの調整機構という二層構造をとる。PFC はポートと優先度の単位で一律に停止するため、4 送信者・1 受信者の実験で 1 フローが 20 Gbps を独占する不公平や、輻輳パスを共有しないフローが 10 Gbps から 4.5 Gbps へ落ちる被害者フロー問題を生む([[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]])。DCQCN は QCN と DCTCP を融合したレート制御を NIC ハードウェアに実装し、スパインの PAUSE を 600 万件超から約 3,000 件へ減らし、ユーザトラフィックを 16 倍まで増やしても性能を維持した。ただし QCN/DCTCP の推奨値をそのまま使うと 2 フロー系ですら収束せず、流体モデルによりタイマー 55 µs・バイトカウンタ 10 MB・K_max 200 KB・K_min 5 KB・P_max 1%・g=1/256 を導出する必要があった。 #### 4.4.2 本番で顕在化した安全課題 Microsoft の大規模展開は、理論上正しい設計が本番で破綻する事例を 4 つ報告している([[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]])。 - **トランスポートライブロック**: go-back-0 再送では 0.4% のパケットロス率でも 4 MB メッセージの goodput がゼロになる。go-back-N への変更で解消した。 - **PFC デッドロック**: Clos の up-down ルーティングでも、ARP テーブル(4 時間)と MAC アドレステーブル(5 分)のタイムアウト不一致から生じる不完全 ARP 状態がフラッディングを誘発し、循環バッファ依存を作った。ブロードキャスト・マルチキャストを無損失クラスに入れてはならないという教訓を得た。 - **NIC PFC ストーム**: NIC の受信パイプライン停止で PAUSE が出続け、単一 NIC の障害がネットワーク全体を麻痺させた。NIC 側 100 ms・ToR 側 200 ms の二重ウォッチドッグで封じ込めた。 - **スローレシーバー**: NIC の MTT キャッシュ(2K エントリ、4 KB ページで 8 MB 相当)のミス多発が不要な PAUSE を生む。ページサイズを 2 MB に変更し、スイッチの動的バッファ共有を有効化して緩和した。 VLAN-based PFC は PXE ブート不能と L3 越えでの優先度消失という問題を持つため、DSCP-based PFC へ移行した点も実装上の要点である。 #### 4.4.3 運用判断の分岐同じ RoCEv2 でも事業者の判断は割れる。Meta は 200G 展開で DCQCN を使ったが、ECN 閾値を厳しくすると AllReduce 性能が 5% 悪化し緩めると PFC が 2〜3 倍増えるトレードオフを避けられず、400G では NIC ファームウェアの DCQCN 実装バグにも遭遇したため、400G 以降は DCQCN を廃止して PFC のみで運用している。4 年以上の運用で本番学習トラフィックが CTSW から RTSW への永続的な PFC を引き起こした事例はないという。代わりに集合ライブラリ層で受信側駆動の許可制御(CTS)を導入し、CTS に高優先度キューイングを適用して P90 遅延を 43 µs から 4 µs へ削減した([[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]])。一方 SAKURAONE は ECN/PFC をベンダ検証済みの値に調整する保守的な方針を採る。ECN min/max = 2 MB/10 MB、ECN 最大マーキング確率 1%、PFC 優先キュー 3、共有バッファの動的 alpha=1 とし、PFC バッファはベンダ既定を維持して ECN 閾値のみ DCQCN の早期飽和を避けるよう調整した([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。 [[マルチベンダーLosslessネットワーク]] はさらに難易度が上がる。NVIDIA SN4700(Mellanox ASIC)と Juniper QFX5240(Broadcom ASIC)の混在では、Spine の Adaptive Routing と Leaf の Dynamic Load Balancing を単純に有効化すると CNP とパケットリオーダーが増え、AR + DLB がもっとも悪い結果になった。Spine で Ingress interface hashing を有効にし Leaf で DLB を使う組み合わせが実用解で、既定比でスループットがほぼ 2 倍になった。DLB の inactivity-interval には「常に最良」の値が存在せず、経験的に総合成績のよい値を選んでいる([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])。 #### 4.4.4 RoCE の構造的限界これらの個別対処の背後には、RoCE 設計そのものの問題がある。[[RoCE設計課題]] は 8 項目に体系化されており、要点は (1) PFC が `BW×RTT + MTU` 以上のヘッドルームバッファを要求し帯域倍増に比例して膨らむ、(2) 3 ビットのトラフィッククラス単位停止がヘッドオブラインブロッキングと輻輳ツリーを生む、(3) Go-back-N が 1 パケットの損失で帯域遅延積全量の再送を招きマルチパスと本質的に非互換、(4) ECN ベース速度制御にベンダ間互換性がない、(5) 66 B のヘッダが 8 B メッセージでは 90% を占める、(6) スマートスタック非対応、(7) セキュリティが後付け、(8) PAM4 で BER が 1e-4 に達する中で RS544 FEC が 800G リンクで 30〜80 ns のレイテンシを占める、である([[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]])。同論文は 10 年以内に TCP と RoCE が次世代 Ethernet に置き換わると予測している。なお、Ethernet が InfiniBand に対して劣るという通念は測定で限定される。32 KiB 以上のメッセージでは帯域差が 4% 未満、AllToAll と AllReduce では 3% 未満に収まり、インキャストでも全メッセージサイズで 20% 以内、32 KiB 超では 1% 以内である。差が残るのはレイテンシ(約 1.4 倍)と 512 B 未満の小メッセージ(最大 1.6 倍)であり、これは [[HPCインターコネクトベンチマーク]] の観点で LLM 学習の大きなテンソル交換にはあまり効かない([[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]])。 ### 4.5 Ultra Ethernet と SONiC #### 4.5.1 UET の設計 [[Ultra Ethernet]] 1.0 仕様は、完全ハードウェアオフロード可能なコネクションレス型トランスポート UET を中核に据える。UET は Semantics(SES)・Packet Delivery(PDS)・Congestion Management(CMS)・Transport Security(TSS)の 4 サブレイヤからなり、スイッチ側には ECMP と出力側 ECN マーキングのみを要求する([[@2025__arXiv__Ultra Ethernet's Design Principles and Architectural Innovations]])。設計の前提は「25 年でトランジスタあたりの計算コストが 10 万分の 1 になった一方、帯域は 100 倍しか伸びていない」という非対称であり、計算コストのかかる機構をシリコンで実装できる時代になったという主張である。 | 項目 | RoCEv2 | Ultra Ethernet Transport | |---|---|---| | 無損失前提 | PFC 必須 | 有損失ネットワークでも動作 | | 再送 | Go-back-N | 選択的確認応答(SACK ビットマップ) | | 経路 | フロー単位 ECMP で固定 | エントロピー値(EV)によるパケット単位スプレー | | 接続確立 | RTT 追加 | ゼロ RTT の PDC 生成 | | 順序 | アウトオブオーダー非対応 | RUD/RUDI で完全対応 | | セキュリティ | 後付け | TSS が AES-GCM-256 でゼロトラスト標準組み込み | | 接続モデル | キューペア = 接続 | JobID + PIDonFEP + Resource Index でコネクションレス | 配送モードは RUD(信頼・無順序、AI プロファイルの既定)、ROD(信頼・順序、HPC の MPI ワイルドカード向け)、UUD(非信頼・無順序)、RUDI(冪等限定)の 4 種。輻輳制御は ECN と RTT を組み合わせる NSCC と、受信側クレジット割当の RCCC の 2 本立てで、RCCC はインキャストに最適だがアウトキャストや網内輻輳に弱いため NSCC との併用が推奨される。リンク層には PFC の代替となる CBFC と、リンク単位で誤り回復する LLR が定義されている。 #### 4.5.2 次世代トランスポートの並走と SONiC SONiC Scale-Up Working Group の比較(12 軸)では、RoCEv2・UE Transport・Falcon v1.1・[[MRC]] のうち RoCEv2 のみがロスレス前提・Go-Back-N・アウトオブオーダー非対応であり、他の 3 方式はいずれもパケットロス許容・SACK・パケット粒度のマルチパス負荷分散を採用する([[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]])。独立に開発された 3 方式が同じ解に収斂している点は、次世代 Ethernet の設計コンセンサスを示唆する。MRC は OpenAI 主導で AMD・Broadcom・Intel・Microsoft・NVIDIA と連携するオープンプロトコルとして位置づけられ、UET の packet spraying・congestion notification・packet trimming を取り込みつつ [[SRv6]] ソースルーティングを活用する([[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]])。 SONiC/SAI 側では、リンク層共通技術である LLR・CBFC・LLDP を UE spec v1.0.2 に基づき実装中で、Alibaba・Microsoft・Broadcom・NVIDIA・Tencent・ByteDance など 13 社が 2025 年 4 月から約 30 回の議論を重ねている。AI インフラのネットワークは、ノード/ラック内の Scale-Up(NVLink / SUE / UALink)、ラック間の Scale-Out(Ethernet / InfiniBand)、データセンター間の Scale-Across(WAN / DCI)の 3 層に分類され、Scale-Up はメモリセマンティクス(Load/Store)、Scale-Out はメッセージセマンティクス(Send/Recv)という根本的な違いを持つ。Alibaba の報告では、400 Gbps InfiniBand NIC の通信時間 129.96 µs に対し NVL72(900 GB/s)では 6.72 µs となり、DeepSeek-V3 の総推論時間が 14.76 ms から 0.82 ms へ短縮された([[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]])。オープン化には代償もある。SAKURAONE の経験報告は、フルオープンな Ethernet が HPC/AI 双方で競争力のある性能を出せることを実証する一方、安定動作にはファームウェア・カーネル・RDMA スタックの版の整合と、ECN 閾値・PFC・NCCL のチャネルストライピングの精緻な調整が不可欠で、InfiniBand に比べて深い層をまたぐ専門知識を要すると明記している([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。 ### 4.6 物理層の運用 #### 4.6.1 光配線と高密度実装 [[データセンター内光配線設計]] の中心は、限られたラック間通線孔に必要心数を通すことにある。光ケーブルの心線構造を 12 心間欠固定リボンから 16 心間欠固定リボンへ移すと同一心数での収容効率が 1.5 倍になり、288 心ケーブルでは MPO コネクタ数が 24 個から 36 個に増える。MPO 規格は BASE-8/12/16/24 の心数、Method A/B/C の配線方式、ジェンダー、研磨方式(フラット PC / APC)の組み合わせで複雑化し、LC インタフェースのトランシーバ向けには BASE-12 から BASE-8 への移行で実装密度の低下を回避する([[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]])。VSFF コネクタは Duplex 系で CS(LC の 2 倍)・SN/MDC(3 倍)、Multi Fiber 系で SN-MT/MMC(MPO の 3 倍)の密度を提供し、CPO スイッチでは MMC が採用される。実運用では、MPO-12 の 32 ポートパッチパネルで 56 台の GPU サーバに 448 本のケーブルと 14U 以上を要していた構成を、SN-MT の 1U 72 ポートパッチパネルへ移行して収容密度 4 倍・ラック間ケーブル半減を達成した事例がある([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])。 [[光トランシーバー電力方式]] は、送受信ともに DSP を持つ FRO から、送信側のみの LRO、DSP を排してホスト SerDes に委ねる LPO、光エンジンをスイッチ ASIC と同一パッケージに統合する CPO へと、段階的に消費電力を下げる方向に進んでいる([[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]])。 [[光ファイバーシャフル配線]] は物理ファイバーの結線を交差させる技術で、マルチプレーンと組み合わせるとシャフルなしの 8,192 GPU(64 Spines / 128 Leaves)からシャフルありの 32,768 GPU(256 Spines / 512 Leaves)へクラスタ規模を 4 倍に拡張できる。実装はラック内収容のシャフル BOX と、Breakout 構造で余長処理の再検討が要る 4×4 シャフルアッセンブリの 2 方式がある。導入課題としてファイバーマッピングの複雑化、損失測定の手間、不具合箇所特定の困難、そして 1 か所の不具合で全シャフル配線が使えなくなるリスクが挙げられている。 #### 4.6.2 800GbE 導入とラックスケール GPU サーバ 800G スイッチは、2U 64 ポートを 2U 400G 128 ポートとして使い、OSFP 800G-DR8(2×400G-DR4)1 本から 400G を 2 ポート引き出す運用が実際に行われている。400G スイッチ 12 台の増設では SU をまたぐ GPU 間通信が増えて品質保証が難しくなるのに対し、800G 化は Leaf 4 台 + Spine 3 台という単純な構成に収まる([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])。 GB200 NVL72 のようなラックスケールサーバでは、Compute Fabric(GPU 間 Scale-Out、RoCEv2、BGP unnumbered + W-ECMP)、Converged Fabric(Inband + ストレージ)、OOB Fabric(施設監視・NVSwitch 管理)の 3 種を独立に設計する。Compute Fabric は閉域のため in-band 管理制御が難しく、Mgmt ポート経由は単一障害点になる。対策として 800G スイッチの Bonus Port へ 2 本結線する(コスト大)か、Underlay Network + BGP Multipath で Loopback IP の到達性を冗長化する(低コスト)かを比較している([[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]])。サービス提供形態は Rack 単位・Tray 単位・GPU 単位の 3 種があり、Tray 単位では NVLink Partition による論理分割が必要で NVSwitch 管理プロセスが単一障害点になり、GPU 単位では Grace CPU と B200 GPU が 1:2 のためメモリ空間を同一粒度で分割できず対応コストが大きい。物理層では、ラック間ケーブリングの短納期化と自動化、Pre-FEC/Post-FEC の BER と FEC Symbol Error Bins を用いた Optics 障害の切り分け、短距離区間での AEC(Active Electrical Cable)による Optics 代替、液冷トレイ交換時の満水確認・水温・水圧監視が実務上の対応として挙げられている。 #### 4.6.3 マイクロバーストの可視化物理層の稼働状況を投資判断に使うには、集合通信のバーストを捉える粒度が要る。100 ms 間隔なら 400 Gb のピークが見えるが、500 ms では 80 Gb、1 秒では 40 Gb にしか見えない。NOS ごとに収集手段が分岐し、Leaf(QFX5240 / JunOS)は gNMI で最短 2 秒を達成できるがデータレートが高いと更新が止まるため gNMIc プロセスをデータ種別ごとに多重化して対応し、Spine(SN4700 / Cumulus Linux)は gNMI で約 15 秒が限界だったものが Cumulus Linux 5.11 以降の OpenTelemetry サポートで約 2 秒間隔・TSDB への直接書き込みが可能になった。それでも取得間隔のズレでレート計算が不安定になるリスクが残り、正確な可視化は未達成と報告されている([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])。 ### 4.7 ネットワーク障害の検知と箇所特定本節はネットワーク層に固有の検知・箇所特定を扱う。学習ジョブ全体の検知と箇所特定の枠組みは第 VIII 部が扱う。 [[RDMAネットワーク監視]] は、計装点をどこに置くかで見える異常の層が固定される。 | システム | 計装位置 | 主な検知対象 | 定量的成果 | |---|---|---|---| | R-Pingmesh | 市販 RNIC からの能動プローブ(UD QP + CQE タイムスタンプ) | RoCE 固有問題、RNIC 起因とネットワーク内ドロップの区別 | 数万 RNIC に 6 か月以上展開。1 か月で 207 件を全件 20 秒以内に箇所特定、85% が正確、スイッチ問題 157 件は全件正確。Agent は CPU 約 3%・メモリ 18.5 MB | | Hawkeye | P4 スイッチ(Intel Tofino)のデータプレーン | PFC backpressure / storm / deadlock の因果来歴 | 全体精度 90% 以上(backpressure 100%、storm 95%、deadlock 92〜98%、再現率いずれも 100%)。オーバーヘッドをベースライン比 1〜4 桁削減、収集スイッチ数は全ポーリングの約 1/10 | | SkeletonHunter | コンテナのサイドカー + ホスト常駐エージェント | コンテナ化学習の接続性障害(19 タイプ・6 コンポーネント) | 2,048 RNIC で probing 時間を full-mesh の 2,034.12 秒から 25.09 秒へ。6 か月で 4,816 件を precision 98.2% / recall 99.3% で検知、1,302 個を 95.7% の精度で箇所特定。修正後に月次障害率が 99.1% 低下 | | Vedrfolnir | ホスト側の待機グラフ + Hawkeye の PFC プロベナンス | 集合通信のクリティカルパスと根本原因フロー | NS3 評価で Hawkeye 比 98% のテレメトリ削減 | | OptProphet | 光トランシーバの物理メトリクス | 光トランシーバ故障の予測と分類 | 予測 F1 0.884、平均 1.11 日前にアラーム。分類 F1 0.855 | | Astral のフルスタック監視 | アプリ・トランスポート・ネットワーク・物理の 4 層 | fail-stop / fail-slow / fail-hang | MTTLF を fail-stop で最大 12 倍、fail-hang で最大 25 倍、fail-slow で約 5 倍短縮し日単位から分単位へ | | Meta のカウンタ収集 | スイッチ・NIC・PCIe のハードウェアカウンタ | OOS、リンクフラップ、LAT(Local Ack Timeout) | 200 ms 超の PFC pause を検知する PFC ウォッチドッグ、RTSW バッファ 80% 超のアラーム | R-Pingmesh の設計上の要点は、RC ではなく UD QP を選ぶことで送信直後に CQE が生成され、クロック同期なしにネットワーク RTT とエンドホスト処理遅延を分離できる点にある。箇所特定は二分ネットワークトモグラフィに着想した投票機構(異常プローブ経路で各リンクの通過回数を数え最多得票を最疑とする)で行う。一方、RNIC 問題は 50 件中 20 件しか確認できず、原因はサービスによる Agent の CPU 占有で ACK 応答が遅れ prober 側 timeout を起こす偽陽性だった([[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]])。[[Fault Localization]] の一般則である「単一信号では起因の層を取り違える」が RDMA でも成立する。 Astral の階層相関はこの弱点への一つの回答である。ユーザ知覚に最も近いアプリケーション層から始め、Seer の予測で得たジョブ別しきい値とホスト間水平比較で異常ノードを判定し、計算異常なら物理層ログ、通信異常なら errCQE と QP レート、パス重複解析、INT のホップ別遅延と分岐する。実例では、NCCL タイムラインで通信が長いノードを特定 → ミリ秒級 QP レートでリンク帯域の 50% 未満を検出 → sFlow でパスを辿り INT ヒートマップで各ホップ 0.6 µs / 179 µs / 266 µs を確認 → Agg-ToR 下りリンクの輻輳と推定 → PFC pause カウンタの正常域超過を確認 → 上流の ECMP による非効率経路選択が根本原因、という順で特定している([[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]])。本番の障害は fail-stop 66%、fail-hang 17%、fail-slow 13%、fail-on-start 4% で、根本原因はホスト環境・設定 32%、NIC エラー 15%、スイッチ設定 14%、ユーザコード 14% と分布する。 SkeletonHunter が扱うコンテナ環境では、検査対象が X×Y×Z(例: 1K×8×16 = 128K)と乗算的に膨れ上がり、約 30 秒の学習ラウンド内での網羅検査は非現実的になる。そこで、レール最適化トポロジの性質から full-mesh を 87.5% 削減した基本 ping リストを作り、さらに RNIC のスループットのバーストサイクルを STFT で周波数領域へ変換して階層クラスタリングし、並列化グループ(DP/TP/PP/EP)を推論することで 95% 超の追加削減を行う。箇所特定は、オーバーレイの根本原因はソフトウェア、アンダーレイはハードウェアで互いに伝播しないという楽観的仮定の下、各層を独立に検査する([[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]])。時間軸では、反応型(Hawkeye の即時診断、R-Pingmesh の 20 秒周期)と予防型(OptProphet の平均 1.11 日前の予測)に分岐する。光リンクの物理劣化が PFC の backpressure として顕在化する前に劣化リンクを切り離せるかは、両者を接続する未解決の問いとして残っている([[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]], [[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]])。 ### 4.8 ネットワーク障害への耐性 #### 4.8.1 トポロジによる耐性 HPN の非スタック型デュアル ToR は、ToR 間の直接リンクを除去して BGP で自律収束させる設計である。スタック型では ToR1 のデータプレーン障害時に ToR2 が整合性を保つため自らシャットダウンしてラック全体がオフラインになり、過去 3 年のアップグレードの 70% が ISSU の前提を満たさず、内部報告では重大障害の 40% 以上がスタック型デュアル ToR 由来だった。非スタック化のために、RFC 予約済み仮想ルータ MAC `00:00:5E:00:01:01` を 2 台で共有しつつポート ID をオフセットで区別し、学習した ARP を /32 ホストルートとして BGP に流す。障害注入試験では、シングル ToR が 10 秒後に学習を停止するのに対し、デュアル ToR は 6.25% の性能劣化のみで継続した([[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]])。Astral も同様に「NIC の各ポートを異なる ToR スイッチに接続する」を設計原理 P3 として掲げ、共通光モジュール・リンクの損傷を避けている([[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]])。 #### 4.8.2 リルーティングとトランスポートによる耐性 Meta はルーティングを段階的に進化させた。パスピニングは部分アロケーションのラックやリンク障害時に不均等な輻輳を生み 30% 以上の性能劣化を招いたため、RTSW アップリンク帯域を 2 倍化して緩和した。次に集合通信ライブラリの QP スケーリングとスイッチ ASIC の UDF による拡張 ECMP を展開し AllReduce で最大 40% 改善したが、ランキングジョブは QP=4、LLM ジョブは QP=16 と使い分ける運用の複雑さが残った。集中型トラフィックエンジニアリング(Open/R によるトポロジ収集、CSPF、30 秒周期最適化)は E-ECMP 比 5〜10% の改善を得たが、多重リンク障害時は E-ECMP に劣った。現在はフローレットスイッチング(256〜512 µs の間隔)を、TE 相当の性能をより低い運用コストで得る方向として検証している([[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]])。 [[MRC]] は RDMA の RC トランスポートを拡張し、1 キューペアが数百の並列パスへパケットスプレーすることで、フロー衝突の排除・輻輳パスの自動回避・マイクロ秒級の障害回復を実現する。[[SRv6]] は経路情報をパケット自体に埋め込むソースルーティングで、OSPF/BGP の収束を待たず障害パスを新パケットから即座に迂回できる。OpenAI の本番環境では、トランシーバ障害やスイッチ再起動が学習を停止させないことが実証されたとされる([[@2026__LinkedIn__Resilient AI Supercomputer Networking - How MRC and SRv6 Keep 100,000+ GPUs Training]])。 #### 4.8.3 集合通信ライブラリによるフェイルオーバースイッチとホスト間の last-hop 障害は記録された障害の 12% 超を占め、従来は CCL がスタックしてジョブ再起動を強いられていた。ReCCL はこれを NCCL の in-place 置き換えとして解く。GPU ごとの single-port RNIC を前提に、PCIe スイッチ跨ぎ(+1)・PCIe root complex 跨ぎ(+100)・NUMA ノード跨ぎ(+200)のコストで最短距離の backup RNIC を選び、送信側と受信側の backup 同士を対応づける backup-to-backup 方式でレールに沿った独立経路を確立する。これにより ToR スイッチが完全に落ちても学習は継続する([[@2026__EuroSys__Handling Network Faults in Distributed AI Training]])。フェイルオーバーと再起動の選択は、チェックポイント間隔 T_interval、経過時間 t_elapsed、検知時間 T_detect、スローダウン率 k から `t_elapsed > (T_interval(k-1) - T_detect) / k` という単純な閾値条件で判定できる。k=1.5、T_detect=0 ならチェックポイント間隔の 1/3 を過ぎていればフェイルオーバーが有利になる。32 GPU のテストベッド実測ではスローダウンが 1.004〜1.0215 に収まり、16K GPU の Llama3-405B シミュレーションでは再起動比 64.96%、再起動+スケールダウン比 80.97% の GPU 時間削減となった。フェイルオーバー後の straggler 化には、backup RNIC を共有するチャネルを無効化して健全チャネルへ再分配する DCR(大規模通信グループ向け)と、NVLink 経由の中間 GPU ルーティングで PCIe ボトルネックを避ける NVL(小規模通信グループ向け)を使い分ける。 ### 4.9 シミュレーションによる設計検証トポロジ・輻輳制御・負荷分散の設計判断を実機を作らずに検証するには [[ネットワークシミュレーション]] が要るが、LLM 学習規模ではパケット単位の離散イベントが O(10¹²) を超え、GPT3-175B の 1 イテレーションに ns-3 で数週間かかる([[@2026__NSDI__Supercharging Packet-level Network Simulation of Large Model Training via Memoization and Fast-Forwarding]])。 | 手法 | 例 | 高速化 | 誤差 | |---|---|---|---| | PLDES(フル) | ns-3、OMNeT++ | 1×(基準) | ほぼゼロ | | 並列 PLDES | Unison、DONS | 最大約 10× | ほぼゼロ | | フローレベル | max-min / 水充填 | 2〜3 桁 | 10〜25% | | AI ベース | M3、RouteNet | 数桁 | 10〜25% | | PLDES + メモ化 + 早送り | ns-3 + Wormhole | 744×(GPT)/510×(MoE)、並列と組合せで 1012× | 1% 未満 | Wormhole が依拠するのは LLM 学習固有の 2 種の冗長性である。データ並列フローは同一イテレーション内で同じ競合パターンを繰り返し(GPT-13B/128 GPU で 1,633 種のパターンが 1,200 回超、GPT-175B/1024 GPU では 4 万回超)、輻輳制御の収束後はフローが安定レートに入る(GPT-175B で 99% 超、MoE でも約 97.5%)。この性質を利用して非ステディ状態をメモ化しステディ期間を早送りすることで、GPT-13B/128 GPU の 1 イテレーションのシミュレーション時間を 9 時間から 5 分へ短縮し、フロー完了時間の誤差は 1% 未満、実世界トレースのエンドツーエンド学習時間の誤差は 3.02% に収まる。ただしこの効果はパブリッククラウドやマルチテナントのようなランダム性の高いワークロードでは薄れる。より軽量な参照としては、Astral の Seer がある。オペレータ実行時間をテンソルサイズ÷理論帯域で定式化した基本モデリングに、実測スループットへの多項式カーブフィッティングによる自己補正を加えることで、パケットレベル挙動を暗黙に織り込みながら数秒以内にタイムラインを生成し、密モデルで 0.3% の偏差を達成した。比較として 1K GPU・1 イテレーションで ASTRA-sim は 48 コアサーバで 1 日、SimAI でも数時間を要する([[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]])。Seer は完全一致を狙わず「参照として使える精度」に割り切ることで、配置前のパラメータ調整・本番実行時間の検証による障害診断支援・新アーキテクチャ探索という 3 用途を実用速度で支えている。診断系の評価でも NS-3 は標準的な検証環境として使われる([[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]], [[@2025__SIGCOMM__POSTER - Vedrfolnir - RDMA Network Performance Anomalies Diagnosis in Collective Communications]])。 ### 4.10 実運用の要点: 新規クラスタ立ち上げ時のネットワーク検証項目以上を、新規クラスタの受け入れ時に確認すべき項目として整理する。いずれも本文中の出典で「本番で実際に起きた」と報告された事象に対応する。 | 段階 | 検証項目 | 根拠 | |---|---|---| | 物理配線 | レール最適化の GPU-NIC-Leaf 対応が全ノードで一致しているか。異種サーバ混在時はポート番号体系の差を吸収できているか | 配線ずれで Spine 経由のリングが形成され性能劣化([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) | | 物理配線 | レール最適化とデュアルプレーンで複雑化した配線を、INT ベースのプローブで事前検証したか | 初期展開時に多数の配線ミスが発生([[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]]) | | 物理配線 | 配線検証・設定検証・Hostping・GPU Burn をオフラインツールとして整備したか | Astral の物理層オフラインツール群([[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]]) | | 光部品 | Pre-FEC/Post-FEC の BER と FEC Symbol Error Bins を取得し、光リンク劣化の切り分け手順を用意したか。短距離区間は AEC 代替を検討したか | Optics 障害切り分けの実務手順([[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]) | | 光部品 | シャフル配線を採用する場合、1 か所の不具合の影響範囲とファイバーマッピングの管理方法を決めたか | シャフル配線の運用課題([[@2026__JANOG58__AIインフラ時代のデータセンター内光配線の実践知]]) | | ロスレス設定 | PFC ヘッドルーム・ECN 閾値が `t_ECN < t_PFC` の関係を満たすか。ベンダ検証済みの値から出発したか | 閾値誤設定では DCQCN が本来の性能を出せない([[@2015__SIGCOMM__Congestion Control for Large-Scale RDMA Deployments]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) | | ロスレス設定 | ブロードキャスト・マルチキャストが無損失クラスに入っていないか。不完全 ARP 状態のパケットを落とす設定があるか | PFC デッドロックの実発生原因([[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]]) | | ロスレス設定 | NIC 側と ToR 側の PFC ウォッチドッグが有効か(NIC 100 ms / ToR 200 ms、あるいは 200 ms 超の pause 検知) | NIC PFC ストームの封じ込め([[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]], [[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]) | | ロスレス設定 | 異 ASIC 混在なら AR/DLB の単純有効化ではなく、Ingress interface hashing との組み合わせと inactivity-interval を実測で決めたか | マルチベンダー環境での CNP・リオーダー([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) | | トランスポート | NIC ファームウェアの DCQCN 実装に既知バグがないか。400G 以上では DCQCN を使うか PFC のみとするかを実測で決めたか | Meta の 400G での方針転換([[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]) | | 集合通信 | NCCL の既定値が本番 RTT を前提としているか。Tree/Ring とプロトコル(LL/LL128/Simple)の切替閾値を実測 RTT に合わせたか | 既定設定のままでは本番性能が 50% 以下になりうる([[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]) | | 集合通信 | `NCCL_CROSS_NIC=0` などトポロジ依存の設定を、利用者が上書きできない形で適用できるか | 任意ノード数払い出し時の運用課題([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) | | 監視 | 能動プローブ(RTT・処理遅延の分離)、PFC/ECN/CNP カウンタ、OOS・リンクフラップ・LAT の 3 カウンタを収集しているか | 監視なしでは検知・箇所特定・根本原因分析が困難([[@2016__SIGCOMM__RDMA over Commodity Ethernet at Scale]], [[@2024__SIGCOMM__R-Pingmesh - A Service-Aware RoCE Network Monitoring and Diagnostic System]]) | | 監視 | マイクロバースト観測に足る収集間隔(数百 ms 以下)を確保したか。NOS ごとの収集手段の差を吸収したか | 1 秒間隔では 400 Gb のピークが 40 Gb にしか見えない([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]]) | | 監視 | ECN マーキング率・PFC pause カウンタを稼働開始時から収集しているか | 未収集だと帯域を輻輳へ帰属できない([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) | | 耐障害 | ToR 単一障害点をトポロジで解消したか(非スタック型デュアル ToR、あるいは NIC ポートの ToR 分散) | ToR 障害の影響範囲([[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]], [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]]) | | 耐障害 | リンク障害・リンクフラッピングを注入して、学習が継続するか・何%劣化するかを実測したか | HPN の障害注入試験([[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]]) | | 耐障害 | フェイルオーバーと再起動の判断基準(チェックポイント間隔とスローダウン率の関係)をスケジューラに組み込んだか | ReCCL の判定式([[@2026__EuroSys__Handling Network Faults in Distributed AI Training]]) | | ベンチマーク | 点対点・インキャスト・AllToAll・AllReduce を排他実行で計測し、32 KiB 以上で理論ピークに対する到達率を確認したか | Ethernet と InfiniBand の差はメッセージサイズに依存([[@2024__SC-W 2024__Benchmarking Ethernet Interconnect for HPC AI workloads]]) | | ベンチマーク | 標準 HPC ベンチマーク(HPL・HPCG・IO500)と MLPerf 相当で多面的に裏付けたか | 単一指標では性能特性を捉えられない([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) | | 設定管理 | 設定生成が決定論的か。既存改修と新規構築が同じコードパスを通るか。1 件のバグの爆発半径をどう抑えるか | 1 件のバグが数千デバイスに波及しうる([[@2026__NSDI__Matryoshka - Realizing Hyperscale Data Center Network Design for the AI Era]]) | | 変更管理 | スイッチのソフトウェアイメージ変更後にポート間レイテンシを継続監視しているか。ファームウェア更新とバースト性ジョブの重なりを想定した検証体制があるか | ソフトウェアイメージ差異とマルチイベント連鎖によるドロップ([[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]]) | 最後に、これらの検証を通っても残る不確実性を明示しておく。SAKURAONE は 3 か月で 21 件の障害を記録し、GPU 関連が 9 件(42.9%)、インターコネクトのスイッチが 5 件(23.8%)、NVLink/NVSwitch/PCIe が 4 件(19.0%)で、21 件中 10 件はノード単位の再起動で復旧した。障害は 1 月に 13 件が集中しており burn-in 期の存在を示唆する([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。立ち上げ直後の障害率は定常状態を代表しない。  --- ## 第 V 部ストレージ、データ経路、資源スケジューリング計算資源の割り当てと、その計算資源へデータを届ける経路は、LLM 学習インフラの運用において表裏一体の問題である。第 IV 部までで見た通信とネットワークが「GPU 同士をつなぐ経路」だったのに対し、本部が扱うのは「GPU と永続データをつなぐ経路」と「ジョブと GPU を結び付ける決定」である。両者は独立した設計課題に見えるが、実測研究はどちらも同じ症状——割り当て済みの GPU が仕事をしていない——に収束することを示す。 ![[Attachments/llm-training-ch05-storage-scheduling.png]] *図 6. 第 V 部のデータ経路。起動・復旧、定常学習、チェックポイントでは I/O 要求が異なり、I/O 待ちは割り当て済み GPU の前進も止める。*（Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]], [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]]） ### 5.1 ストレージとデータ経路 #### 5.1.1 学習クラスタの三つの I/O 要求学習クラスタの I/O は単一の要求ではない。少なくともデータセット読み出し、チェックポイント書き込み、モデル・チェックポイントのロードという三種類が、それぞれ異なる帯域・レイテンシ・粒度の要求を持つ。[[GPUストレージIOデータパス]] の一次ソースである [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]] は、事前学習とファインチューニングのワークロードが粗粒度・シーケンシャルな読み書きに支配されるのに対し、推論は細粒度・ランダム・レイテンシ重視であると実測トレースから示す。先行研究の報告として、訓練時間の 10〜70% が I/O 待ちで失われるという数字も引かれており、ストレージと計算のギャップは学習インフラの一次的なボトルネックとして扱うべきものである。 | 要求 | 主な粒度 | 律速する指標 | 発生パターン | |---|---|---|---| | データセット読み出し(事前学習・ファインチューニング) | 粗粒度・シーケンシャル | 帯域(GB/s)と CPU 効率(GB/s per core) | 定常的なストリーミング | | チェックポイント書き込み | 粗粒度・整列済み | 書き込み帯域とキュー時間 | 周期的なバースト | | モデル/チェックポイントのロード | 粗粒度・整列済み | Time-To-Ready(TTR) | 起動時・復旧時の一回性 | | 推論の KV/オンデマンド読み出し | 細粒度・ランダム | テールレイテンシ | 継続的だが不規則 | (Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]] §3.2〜§3.5) #### 5.1.2 データパスの選択はフェーズに従う同ソースは、libaio(カーネル内非同期 I/O)、io_uring(ハイブリッド、割り込み駆動とポーリング各種)、SPDK(ユーザー空間ポーリング)、GPUDirect Storage(GDS、Direct-to-GPU)の四段階を、SATA SSD・NVMe SSD・Optane NVMe・Optane PMem の四メディア上で 25,000 通りの構成にわたり比較した。結論は明快で、単一のデータパスが全フェーズで最適になることはない。事前学習のストリーミング読み出しでは、すべてのエンジンが同じメディア律速の帯域上限(NVMe で約 6.14 GB/s)に収束する一方、その上限に到達するための CPU コストが一桁違う。GDS が約 12% の CPU で済むのに対し、libaio は約 49%、割り込み駆動 io_uring は約 100% を要する。逆に推論側では、16 KiB のブロックサイズで GDS の平均レイテンシが約 152 マイクロ秒、CPU 仲介パスが 133〜137 マイクロ秒であり、GDS が劣後する。64 KB 未満の I/O では GDS が POSIX 相当の挙動へ後退することが原因である。(Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]]) | フェーズ | 推奨データパス | 根拠となる測定 | |---|---|---| | 推論(ランダム、テール重視) | 割り込み駆動 io_uring を既定。CPU に余裕がありマイクロ秒テールが最優先なら io_uring+HIPRI。GDS は非推奨 | 帯域・IOPS が libaio 比 +6〜11%、slat が −60〜−100% | | 事前学習(帯域重視) | 大きく整列した読み書きは GDS、それ以外は割り込み駆動 io_uring | 同一帯域上限に GDS は 1/4〜1/8 の CPU で到達 | | ファインチューニング(初期化) | 同上。ジョブ数が少なく I/O 深度が高いほど GDS が有利 | GDS が平均レイテンシを最大約 10 マイクロ秒削減し TTR を短縮 | | ファインチューニング(定常) | GDS、フォールバックは割り込み駆動 io_uring | 縮小版の事前学習と同傾向 | (Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]] Table 3・Table 4) 運用上とくに重要なのは、ポーリング系 I/O のトレードオフである。SQPOLL は割り込み駆動 io_uring に対して CPU 消費をほぼ一桁増やす(NVMe SSD で +1289.6%)が、submission latency は I/O 時間全体の 3% 未満しか占めない。しかもポーリングモードは 4 GPU を超えると急速にコアを飽和させるため、単一 GPU 環境で許容できた CPU コストが 8 GPU 共有ホストでは非現実的になる。GPU 密度が上がるほど、レイテンシのわずかな改善のために CPU を焼く選択は取りにくくなる。(Source: [[@2026__POMACS__Towards Scalable Storage Architectures for GPU Clusters Running Large Language Models]]) #### 5.1.3 並列ファイルシステムと階層化・異種ストレージクラスタ全体の I/O 基盤としては [[並列ファイルシステム]] が事実上の標準である。[[@2025__TOS__Lustre Unveiled - Evolution, Design, Advancements, and Current Trends]] によれば、Top500 の上位 10 台中 6 台、上位 100 の 65% 以上、上位 500 の 60% 以上が Lustre を採用している。エクサスケール機 [[Frontier]] の [[Orion]] は 700 PB の容量で逐次書き込み 4.6 TiB/s・逐次読み出し 4.7 TiB/s を達成し、40 の MDT による分散メタデータ処理とフラッシュ・HDD の多層構成を採る。データとメタデータの分離、オブジェクトベースストレージ、分散ロック管理、ストライピングという四つの設計原則は、Lustre・GPFS・Ceph・BeeGFS・DAOS に共通する。ただし運用者にとって重要なのは、AI/ML ワークロードへの移行がこの設計の前提を崩しつつある点である。従来の HPC が想定した大規模逐次 I/O から、大量の小ファイルランダムアクセスとチェックポイント I/O へワークロードが移り、並列ファイルシステムのメタデータ性能がボトルネックになっている。Lustre の分散名前空間(DNE)やクライアントメタデータキャッシュはこの変化への対応策だが、当初 2001〜2005 年の設計文書で構想されたクライアントメタデータライトバックキャッシュは 2025 年時点でもなお「将来の方向性」として挙げられており、設計意図の実現に 20 年以上を要している。(Source: [[@2025__TOS__Lustre Unveiled - Evolution, Design, Advancements, and Current Trends]], [[@2019__arXiv__The Lustre Storage Architecture]]) 異種ストレージの束ね方についても再考が進む。[[@2026__ACM TOS__Horizontally Scaling Heterogeneous Storage for Combined Capabilities with PolyStore]] は、キャッシングとティアリングという既存手法がいずれも「速いデバイスを遅いデバイスの上に置く」垂直積層設計であり、複数デバイスの合算帯域を使い切れないと指摘する。[[PolyStore]] はデバイス固有のファイルシステム(PM 向け NOVA、フラッシュ向け F2FS/ext4)を温存したまま、その上のメタ層で単一論理ファイルのブロックを複数デバイスへ水平分散する。結果として、マイクロベンチマークで既存手法比 1.11〜9.38 倍、実アプリケーションで 1.52〜2.02 倍の性能向上を示し、32 スレッドで PM+NVMe の合算帯域の 92.3%、三デバイス構成でも 91.7% を活用する。異種性を意識した DRAM キャッシュ(Poly-cache)は既存手法比で最大 3.18 倍のスループット改善をもたらす。もっとも、著者自身が水平配置の弱点を明示している。帯域の高いデバイスへレイテンシ critical なリクエストを分散させると、レイテンシに悪影響を与えうる。将来のストレージは垂直・水平スケーリングのハイブリッドになると論文は予想しており、階層化と水平合算は択一ではなく配置エンジンの差し替え可能性として扱うのが妥当である。(Source: [[@2026__ACM TOS__Horizontally Scaling Heterogeneous Storage for Combined Capabilities with PolyStore]] §4.9) #### 5.1.4 チェックポイント I/O が生む突発負荷チェックポイントの方式そのもの(頻度、非同期化、インメモリ複製、増分化)は第 IX 部で扱う。ここでは、チェックポイントがネットワークとストレージに与える**突発負荷**という、資源計画側の観点に絞る。 [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]] は 63 ノード・504 GPU の本番クラスタで 523 件のチェックポイントイベントを追跡し、この負荷の実像を定量化した。ストレージは 2 PiB の VAST Data E-Box を NFS マウントし、最大 read 700 GB/s・最大 write 250 GB/s である。にもかかわらず、再起動時のロードは平均 NFS read スループット 150.8 GB/s、すなわち最大帯域の 21.5% に留まり、保存バーストも書き込み帯域の 16.0% にしか達しない。20 セッションの平均ロード時間は 33 分、中央値 31 分である。帯域が余っているのに時間がかかる理由は、キュー形成にある。checkpoint save の WRITE RPC は平均 2.03 秒/要求で、うち 1.89 秒(93.1%)がキュー時間である。load の READ RPC は平均 78.2 ミリ秒/要求で、54.2 ミリ秒(57.0%)がキュー時間を占める。この分析の運用上の含意は明確で、「200G から 400G へ回線を増速すればロードが速くなる」とは単純に言えない。NFS/RPC のキュー形成と restore 末尾の残余シャード処理を切り分けなければ、投資は空振りする。(Source: [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]]) チェックポイント I/O は GPU 側にも直接跳ね返る。[[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] は、低利用率ジョブの原因の 16.43% がモデルチェックポイントであり、GPU メモリ→ホストメモリ→分散ストアへの同期書き込みによってエポック終了ごとに GPU が長時間停止すると報告する。ストレージ側のキューと GPU 側のストールは同じ現象の両端である。 #### 5.1.5 SSD 上のデータ配置ノードローカルの層では、SSD 上でデータをどう並べるかが書き込みスループットとテールレイテンシを左右する。[[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]] は、[[ホスト誘導データ配置]] のインターフェース群(Multi-Stream 2016、Open-Channel 2017、[[ゾーン名前空間SSD]] 2021、FDP 2022)が「少数アプリケーションで実証され数年で廃れる」パターンを繰り返してきたと総括する。配置ロジックをアプリケーションに実装すれば工数と陳腐化の問題を抱え、ファイルシステムに実装すればカーネル内更新の困難とアプリケーション意味論の喪失を招く。 [[Valet]] の解は、責務をユーザー空間のシムレイヤーに切り出すことである。`LD_PRELOAD` で libc 呼び出しを横取りし、アプリケーション・ファイルシステム・カーネルを一切変更せずに配置ヒントを生成する。配置の指針は従来の temperature(hot/cold/warm/undefined の 4 値)ではなく、affinity(同一書き込み元のデータをまとめる)と lifetime(生成・削除の時間局所性でまとめる)の 2 軸である。実測では f2fs に対して 2〜4 倍の書き込みスループットと最大 6 倍低いテールレイテンシを達成し、RocksDB の p99.99 レイテンシは Valet 約 20 マイクロ秒に対しアプリケーション固有解の zenfs が約 555 マイクロ秒であった。追加コード量はカーネル・アプリケーション変更ゼロでユーザー空間 1,700 行に収まる。学習インフラの文脈で見逃せないのはマルチテナンシーの結果である。RocksDB と MongoDB を同一デバイス上で同時実行させると、f2fs はテールレイテンシで書き込みが約 2 倍まで悪化したのに対し、Valet はデバイスバッファと領域の分離マッピングにより劣化を抑えた。共有ストレージ上で複数ジョブが同居する GPU クラスタでは、この分離が I/O の予測可能性を決める。(Source: [[@2025__SoCC__Valet - Efficient Data Placement on Modern SSDs]]) ### 5.2 スケジューリングと資源管理 #### 5.2.1 深層学習ジョブはなぜ一般のバッチと違うのか [[GPUクラスタスケジューリング]] が一般のバッチスケジューリングと異なる理由は、[[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]] が Microsoft [[Philly]] の 75 日・96,260 ジョブ・14 仮想クラスタのトレースから抽出した三点に集約される。第一に、GPU はユーザー間で細粒度に共有できない一枚岩の資源である。第二に、深層学習フレームワークはギャングスケジューリング(要求 GPU の同時確保)を要し、スケジューリングの柔軟性を下げるとともにジョブを実行時障害に対して非弾力的にする。第三に、局所性が実行効率を大きく左右する。この三点の帰結は数字に表れる。断片化待ちは 5〜8 GPU ジョブの待ち発生の 74.2%、8 GPU 超では 97.9% を占め、全ジョブの待ち時間量でも約 80% を占める。局所性を緩めれば待ちは減るが実行効率が落ちる——16 GPU ジョブを 2/4/8 サーバへ広げると平均 GPU 利用率は 43.66%/40.94%/28.56% へ低下する。数時間から数日走るジョブでは 10〜20% の効率低下が数時間の追加実行時間になるため、「短い待ち時間を最適化する」だけでは足りず、ジョブ長に応じて局所性を待つ価値を見積もる必要がある。(Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]]) もう一つの構造的な差異は、ジョブ所要時間が予測しにくいことである。損失曲線は非滑らかであり、ハイパーパラメータ探索の試行中断が常態であるため、残り時間を事前に知ることはできない。加えてプリエンプションにはチェックポイント書き込みと再ロードが伴い、VGG16 で 26.3 秒というオーバーヘッドが生じる。一般のバッチスケジューラが前提とする「所要時間の推定」と「安価なプリエンプション」がどちらも成り立たない。(Source: [[@2019__NSDI__Tiresias - A GPU Cluster Manager for Distributed Deep Learning]] §2.2) #### 5.2.2 主要スケジューラの比較これらの制約に対し、研究群は異なる最適化目標を掲げて別々の角度から答えを出してきた。 | スケジューラ | 主な最適化目標 | 中核となる手法 | 事前知識の要否 | 報告された効果 | |---|---|---|---|---| | YARN-CS(基線) | 容量保証 | FIFO + クォータ、consolidation 配置 | 不要 | 平均キューイング遅延 4,102 秒(Philly 2016〜2017) | | Gandiva | クラスタ効率 | 内省的プロファイリングによる配置最適化と時間多重化 | 不要 | 公平性は主目的としない | | [[@2019__NSDI__Tiresias - A GPU Cluster Manager for Distributed Deep Learning|Tiresias]] | 平均 JCT | 2DAS(GPU 数 × 経過時間)+ MLFQ 式離散化キュー、テンソル歪みプロファイルによる配置 | 不要(Gittins 版は所要時間分布) | YARN-CS 比平均 JCT 5.5 倍・中央値 27 倍(実機)、makespan 1.21 倍短縮 | | [[@2020__NSDI__Themis - Fair and Efficient GPU Cluster Scheduling|Themis]] | 公平性 + 効率 | 仕上がり時間公平性 $r = T_{sh}/T_{id}$ + 部分割り当てオークションの多ラウンド実施 | アプリからの入札表 | 最大 $r$ を 2.2〜3.25 倍改善、Tiresias 比 2.25 倍以上、効率も Gandiva 比 4.8%〜SLAQ 比 250% 改善 | | [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees|HiveD]] | アフィニティ保証(共有安全性) | セル抽象 + [[Virtual Private Cluster]] + バディセル割り当て | 不要(VC 定義は外部化) | [[共有異常]]をゼロ化(YARN-CS 最大 1,000 分・Gandiva 400 分・Tiresias 330 分の余剰遅延を解消)、動的結合でプリエンプション 55% 削減 | | [[@2024__NSDI__Cassini Network-Aware Job Scheduling in Machine Learning Clusters|Cassini]] | ネットワーク認識(反復時間) | 通信位相の円形幾何抽象 + Affinity グラフによるタイムシフト割り当て | ジョブのイテレーション時間・リンク使用量のプロファイル | Themis 比平均反復時間 1.6 倍・p99 2.5 倍改善、ECN マーク数最大 33 倍削減 | | Alibaba PAI(予約+パッキング) | 待ち時間 + 利用率 | 高 GPU タスクへ NVLink 機を予約、低 GPU タスクを旧世代機へパッキング + GPU 共有 | 性能モデルと繰り返しタスク履歴 | V100 タスクの平均待ち時間 68% 削減・全体 45% 削減、GPU 共有で必要台数平均 50%(ピーク 73%)削減 | (Source: [[@2019__NSDI__Tiresias - A GPU Cluster Manager for Distributed Deep Learning]], [[@2020__NSDI__Themis - Fair and Efficient GPU Cluster Scheduling]], [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]], [[@2024__NSDI__Cassini Network-Aware Job Scheduling in Machine Learning Clusters]], [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]]) この表から読み取るべきは、四者が競合ではなく直交する層を扱っているという点である。HiveD は自らを「関心の分離」と位置づけ、VC 内に YARN-CS・Gandiva・Tiresias のいずれを組み込んでも、そのスケジューラ本来の設計目標を保ったまま共有異常を解消できると示した。JCT への影響は最大 3% 悪化(YARN-CS)から 12% 改善(Gandiva)の範囲に収まる。(Source: [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]]) [[ネットワーク対応スケジューリング]] も同様にプラグイン設計を採る。Cassini はハイパーパラメータや GPU 割り当て数には介入せず、「どの配置候補を最終選択するか」と「いつイテレーションを開始するか」のみを変えるため、公平性最適化の Themis とグッドプット最適化の Pollux という設計目的の異なる二つのスケジューラで同様の改善を得た。改変規模は約 1,000 行である。ここで重要な設計上の主張は、「局所配置」と「通信位相互換性」が独立した最適化軸だということである。大規模クラスタでは断片化配置が避けられないため、集約だけを追う従来のネットワーク最適化ではタイミング軸を取り逃がす。(Source: [[@2024__NSDI__Cassini Network-Aware Job Scheduling in Machine Learning Clusters]]) 一方、Themis と HiveD は同じ「共有クラスタの不公平」に別角度から答える。Themis は、ML ジョブがギャングスケジューリングを要し配置に敏感であるという二特性が、DRF や LAS における共有インセンティブ・パレート効率性・嫉妬自由性の同時達成を不可能にすると形式的に示し(定理 3.1)、公平性指標そのものを仕上がり時間比へ置き換えた。HiveD は指標を変えず、資源抽象をクォータ(GPU 本数)からアフィニティ階層のセルへ置き換えた。前者は「何を公平と呼ぶか」、後者は「何を予約単位とするか」の問題である。(Source: [[@2020__NSDI__Themis - Fair and Efficient GPU Cluster Scheduling]], [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]]) #### 5.2.3 マルチテナント GPU クラスタの実測ワークロード解析スケジューラ設計の前提は、実測トレースから来る。主要な四つの公開分析を並べると、テナンシーと世代によって何が動き何が動かないかが見える。 | クラスタ | 規模・期間 | ジョブ長分布 | 失敗・キャンセル | 資源断片化と利用率 | |---|---|---|---|---| | Philly(Microsoft、2017) | 数千 GPU、75 日、96,260 ジョブ、14 VC | 分〜週。0.5% が 1 週間超 | killed 13.5% + unsuccessful 17.2% = 件数 30.7% で総 GPU 時間の約 55% | 断片化待ちが待ち時間量の約 80%、GPU 処理サイクル利用率平均 52.32%(16 GPU ジョブは 40.39%) | | Alibaba PAI(2020) | 6,742 GPU、1,897 ノード、2 か月、120 万タスク・750 万インスタンス、1,300+ ユーザー | 中央値 23 分、P90 4.5 時間 | — | 中央値インスタンスの SM 使用率 0.042 GPU、約 18% は GPU をほぼ使わない | | Acme(4,704 A100、LLM 専用) | 6 か月 | GPU ジョブ実行時間中央値 2 分 | — | SM Activity 中央値約 40%、CPU・IB の 60% 超がアイドル、IB 帯域は最大 25% 未満 | | Meta RSC(RSC-1 16k A100 / RSC-2 8k A100) | 研究クラスタ | 90% 超のジョブが 1 サーバ未満だが GPU 時間は 10% 未満 | ハードウェア関連失敗は件数 0.2% でも GPU 実行時間の 18.7% に影響 | 256+ GPU ジョブが GPU 時間の 66% 超(RSC-1)・52% 超(RSC-2) | (Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]], [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]], [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) 共通するのは、件数の支配者と GPU 時間の支配者が分かれるロングテール構造である。この構造は 2017 年の DNN 訓練クラスタから 2025 年の LLM 研究クラスタまで一貫して観測される。したがって運用指標は件数ではなく GPU 時間で見るべきだ、という測定原則が導かれる。([[GPUクラスタ運用]]) 分岐するのは資源の余り方である。Philly と PAI が示した「GPU が余り CPU が混む」像は、LLM 専用クラスタでは反転する。PAI では CPU 過剰使用が 19% のインスタンスで発生し(GPU は 3%、メモリは 9%)、遅延インスタンスを実行するマシンの CPU 利用率は加速インスタンスより有意に高い一方、GPU 利用率には同様の相関が見られない。CTR 予測タスクは実行時間の 80% を TensorFlow の `IteratorGetNext`(データフェッチ・前処理)に費やす。対して Acme では GPU が殺到し CPU・メモリ・ネットワークが余剰になる。異種混合 MLaaS では CPU/メモリの共有制御が GPU スケジューリングと同等に重要になり、LLM 専用クラスタではその余剰が非同期チェックポイントなどの設計空間になる。(Source: [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]], [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]]) 待ち時間の非一様性も運用者が見るべき数字である。PAI では GPU 共有可(0〜1 GPU 要求)の P90 待ち時間が 497 秒、1 GPU 要求で 1,150 秒、1 GPU 超要求で 8,286 秒へ急増する。高性能 V100 を要求するインスタンスは中央値 113 秒に対し P90 が 13,709 秒という極端なロングテールを示す。Acme では、Pretraining のために大半の GPU を予約し Evaluation を低優先で余剰資源に流す構造上、最短・最低 GPU 需要の Evaluation が最長のキュー遅延を持つという逆転が生じた。Acme の対応はプリエンプションではなく、モデルロードの precursor job 分離・メトリック計算の CPU ジョブ分離・事前分布に基づく弾力的スケジューリングであり、makespan を 1.3〜1.8 倍短縮した。LLM クラスタでは「公平キュー」よりも「ジョブ種別ごとに資源パイプラインを分ける」設計が運用最適に近い。(Source: [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]], [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]]) なお、ジョブ長予測は不可能とは限らない。PAI ではタスクの 65% が 5 回以上繰り返し実行され、(User, Group, Resource) の三特徴量による回帰で 78% のインスタンスが予測誤差 25% 以内に収まる。この予測を SJF に適用すると FIFO 比で平均完了時間が 63〜77% 短縮する。Tiresias が「所要時間不明」を前提に 2DAS を設計したのに対し、繰り返し性の高い MLaaS 環境では別の前提が成り立つ。自クラスタがどちらの世界にいるかを先に測るべきである。(Source: [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]], [[@2019__NSDI__Tiresias - A GPU Cluster Manager for Distributed Deep Learning]]) #### 5.2.4 GPU 低利用率の実証研究スケジューラをいくら改善しても消えない低利用率がある。[[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] は、Microsoft 社内プラットフォームで平均 GPU 利用率 50% 以下のジョブ 400 件を無作為抽出し、706 件の問題を四次元 15 カテゴリに分類した。観点をクラスタではなく個々のジョブのコードロジックに絞った点が Philly 分析との決定的な違いである。 | 次元 | 件数比 | 主なカテゴリと比率 | |---|---|---| | データ操作 | 46.03% | 非効率なホスト-GPU データ転送 27.90%、データ交換 7.08%、データ前処理 3.97%、リモートデータ読み込み 2.55% | | モデル層 | 45.18% | バッチサイズ不適切 25.64%、モデルチェックポイント 16.43%、GPU メモリ不足 3.12% | | ジョブ設定 | 4.82% | インタラクティブジョブ 2.12%、未解放ジョブ 1.27%、GPU 過剰申請 0.85% | | ライブラリ | 3.97% | API 誤用 2.27%、ライブラリインストール長時間 1.70% | (Source: [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] §3) 最多原因が PyTorch の DataLoader で `pin_memory` が既定で無効なことに起因するホスト-GPU 転送の非効率である、という事実は示唆的である。84.99% の問題は少数のコード修正で解消でき、バッチサイズ拡大・非同期チェックポイント・自動メモリピニングの三修正を組み合わせると BERT で 7.52 倍、Swin Transformer で 3.95 倍の速度向上が得られた。裏を返せば、これらはギャングスケジューリングをどれだけ改良しても消えない。クラスタ側とジョブ側の最適化は直交しており、一方が他方を自動的に解決することはない。この帰結として、スケジューラ設計にはクラスタ全体の利用率指標に加えて「ジョブのコードレベルの問題を投入前に検出・排除する仕組み」が補完的に要る。論文自身が、静的解析でジョブ投入前に問題を検出し修正提案まで行う「コードアドバイザー」を研究方向として挙げている。(Source: [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]]) #### 5.2.5 実運用の要点: 割り当てポリシーの設計と指標の選び方以上を運用の判断手順に落とすと、次のようになる。 **第一に、予約単位をクォータからアフィニティ階層へ移す。** GPU 本数によるクォータは、複数テナントが同居した瞬間にアフィニティ保証を提供しなくなる。HiveD が本番 2,232 GPU で示した通り、クォータ十分なテナントが私有クラスタなら経験しないはずの最大 1,000 分超のキューイング遅延を被る[[共有異常]]は、設計思想の異なる三スケジューラすべてで発生した。スケジューラの改良では解けず、[[Virtual Private Cluster]] のようなアフィニティ階層ごと予約する抽象が要る。(Source: [[@2020__OSDI__HiveD Sharing a GPU Cluster for Deep Learning with Guarantees]]) **第二に、ジョブ種別ごとに資源パイプラインを分ける。** Acme の Trial Coordinator と PAI の予約+パッキングは、どちらも「単一の公平キューで全ジョブを捌く」発想を捨てている。長時間の事前学習には局所性と予約を、短命な評価ジョブには別経路を、CPU 律速のタスクには CPU 資源を、それぞれ独立に割り当てる。異種混合クラスタではさらに、どのワークロードをどの世代の GPU に載せるかが最適化変数になる。(Source: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]], [[@2022__NSDI__MLaaS in the Wild - Workload Analysis and Scheduling in Large-Scale Heterogeneous GPU Clusters]]) **第三に、予備ノード比率を復旧 SLO から逆算する。** 504 GPU クラスタの分析は、60 ノード訓練 + 3 予備ノードという余裕の小ささにより、単一ノードセッションを使った意図的隔離が上位除外ノードを固定し、自動リトライの成否を左右することを示した。実際、224 セッションのノード除外は集中し、63 ノード中上位 3 ノードが全除外の 50% 超を占める。障害頻度だけでなく「予備ノード数 / 大規模ジョブ要求ノード数」の比率が復旧性の隠れた設計変数である。なお自動リトライチェーンの成功率は 33.3% で手動復旧の 12.5% の 2.7 倍、リトライ間隔の中央値は 11 分であり、自動化の価値そのものは実測で裏づけられている。(Source: [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]]) **第四に、指標を割り当て率から実効的な生産性へ移す。** Philly で割り当て済み GPU の処理サイクル利用率が平均 52.32% に留まったという観測は、「クラスタが埋まっている」ことと「GPU が有効に使われている」ことを分離せよという要求である。[[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]] はこれをフリート規模で体系化し、[[ML Productivity Goodput]](MPG = Scheduling Goodput × Runtime Goodput × Program Goodput)として三層に分解した。指標体系そのものの詳細は第 XI 部で扱う。本部で押さえるのは、従来の三指標が本部で見た症状のどれも捉えられないという対応関係だけでよい。 | 従来指標 | 定義 | 限界 | 対応する MPG 成分 | |---|---|---|---| | Capacity | 展開済み資源 | トポロジ・地理制約を無視し、高 Capacity が高可用性を意味しない | Scheduling Goodput | | Occupancy | 割り当て済み資源 | 割り当て済みでも I/O 待ち・非最適コード実行で進捗ゼロがありうる | Runtime Goodput | | Duty Cycle | アクティブ資源 | 行列演算ユニットの稼働有無しか見ず、演算の質を評価しない | Program Goodput | (Source: [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]) **第五に、ストレージとスケジューリングを同じ指標系で見る。** 本部で見た二つの領域は、Runtime Goodput の同じ分子を削り合う関係にある。データパスの選択ミスも、チェックポイントの RPC キューも、断片化配置による同居干渉も、最終的には「割り当て済みなのに前進していない chip-time」として現れる。ストレージ側の改善(フェーズに応じたデータパス、異種デバイスの水平活用、SSD 上の affinity/lifetime 分離)と、スケジューリング側の改善(アフィニティ保証、種別別パイプライン、ネットワーク位相の調停)を別々の KPI で管理すると、どちらも局所最適に留まる。  --- ## 第 VI 部学習の可観測性 — 何を、どの粒度で、どれだけの代償で測るか本部までに扱った性能改善も、これから第 VII 部以降で扱う障害対応も、前提として「何が起きているかが見えていること」に依存する。だが大規模 LLM 学習ほど、見ることそれ自体が難所になる領域は少ない。本部では、なぜ難しいのかを構造から解き、観測階層と計装手法を整理し、主要システムが何を測って何を狙うのかを対照し、最後に常時オンと深掘りをどう設計するかという運用の問いへ降りる。 ![[Attachments/llm-training-ch06-observability.png]] *図 7. 第 VI 部の観測階層。低オーバーヘッドの常時観測が異常を捉え、条件付きの同期トレースとオフライン分析を起動する。*（Source: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]], [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]]） ### 6.1 学習クラスタの可観測性が難しい三つの理由 #### 6.1.1 GPU 内部が不透明である GPU は SIMT(Single Instruction, Multiple Thread)実行モデルを採る。数千のスレッドがワープ(通常 32 スレッド)単位でロックステップ実行され、複数のストリーミングマルチプロセッサ上で非同期にスケジュールされる。この構造がワープ分岐・メモリ結合・バンクコンフリクト・占有率変動といった性能特性を生むが、CPU と GPU の境界で計装しても、これらの内部挙動は見えない([[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]])。さらに非同期 API がこれを悪化させる。同期実行なら `cudaMemcpy()` の壁時間から転送律速か計算律速かを粗く判断できたが、`cudaMemcpyAsync()` や複数ストリームでのカーネル起動では API 呼び出しは即座に戻り、実作業は背後のストリームで進む。ホスト側からは最終的な `cudaStreamSynchronize()` の集計値しか見えず、どの操作が遅延を生んだかが失われる([[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]])。この不透明さは運用の一次指標にも波及する。プラットフォーム標準の GPU 利用率メトリクスは閾値アラートには使えるが、低利用率の理由——ホストと GPU 間の転送待ち 27.90%、バッチサイズ不足 25.64%、同期チェックポイントのブロッキング 16.43%——を区別できず、原因特定にはコードレベルの人手分析が要った([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]])。 #### 6.1.2 規模がデータ量として跳ね返る細粒度プロファイリングの生成データは 1 ワーカーあたり毎秒約 100 MB に及び、10,000 GPU の学習では毎秒約 1 TB になる。この量ゆえに本番全規模での常時展開が成り立たず、テストベッドでの再現に頼らざるを得ないが、それも 7.4% の問題は再現できなかった([[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]])。1 万 GPU の生トレースは毎分 6〜60 GB に達し、生データのまま cross-rank 比較を行うことは計算・保存の双方で不可能である([[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]])。既存プロファイラの重さも実測されている。PyTorch 内蔵プロファイラは Llama-70B・512 GPU で 1 ステップあたり 5.5 GB(JSON)のログを生み([[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]])、常時稼働させると 20〜44% の遅延増加ののちメモリ枯渇で停止し、Nsight Systems は常時稼働モードで学習そのものを破壊した([[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]])。 #### 6.1.3 同期構造が因果を伝播させる LLM 学習は集合通信で全ランクが同期するため、1 ノードの異常が連鎖して健全なノードまで巻き込み、観測値を均してしまう。この連鎖効果が箇所特定を難しくする中心問題である([[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]])。結果として、演算子単位の観測では遅れているランクと正常なランクが同一の実行時間を示し、両者を弁別できない。しかも通信は GPU・CPU・NIC の協調で動くため、演算子の実行時間には計算側のオーバーヘッドが織り込まれ、計算のボトルネックを通信の異常と誤判定する。なお、伝播の症状は逆向きにも現れる。12,960 GPU の MoE 学習では、演算ストラグラーの遅延がエキスパート並列の集合操作へ伝播した結果、他ランクの ReduceScatter がむしろ短縮するという逆パターンが観測され、帯域外監視は「サーバーポートダウン」と誤報告した([[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]])。 #### 6.1.4 責任境界という第四の制約事業者としてクラスタを提供する立場では、利用者のアプリケーションコードを計装できず、アプリケーションログも取得できない。ゆえに提供側の可観測性は GPU・CPU・NIC・ストレージのリソース分析から始まる([[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]])。マルチテナント環境では、利用者がプライバシー配慮からジョブ構成すら共有しないため、提供者にとって学習ジョブは文字どおり黒箱になる([[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]])。「非侵入・低オーバーヘッド」は研究上の美点ではなく、責任境界から導かれる運用要件である。 ### 6.2 観測階層の整理学習スタックは実行のヒエラルキーを持ち、観測もそれに沿って層別できる。ARGUS は Python 層・学習フレームワーク層・GPU ランタイム層の 3 層に対応させて 3 つの観測機構を置いた([[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]])。GPU ゼロコード計装に限れば、CUDA API 層(uprobes / `libcudart.so`)・GPU ドライバ層(tracepoints / kprobes)・GPU 内部層(PTX への eBPF 注入)の 3 層に整理される([[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]])。両者を通信・ネットワークまで拡げると次のようになる。 | 観測階層 | 主な観測対象 | 代表的な計装点 | 見えるもの | 見えないもの | |---|---|---|---|---| | フレームワーク層 | 順伝搬・逆伝搬・最適化・通信フェーズ、Python ランタイム | CPython の `PyEval_SetProfile`、CUDA Event、py-spy | フェーズ境界、GC ポーズ、データローダのストール、GIL 競合 | カーネル単位の劣化 | | CUDA・カーネル層 | カーネル名・起動時刻・持続時間・ストリーム | CUPTI Activity API、`LD_PRELOAD`、`libcudart.so` への uprobe | どのカーネルが遅くなったか | SM 占有率、ワープ実行 | | 通信ライブラリ層 | 集合通信の内部進行(フロー・チャンク単位) | NCCL への計装(約 1,100 行) | 送信・完了通知の状態差、障害の所在(局所かリモートか) | アプリケーション層全体 | | ネットワーク層 | RDMA フローのレート、スイッチのフロー統計、キュー占有率 | NIC のマイクロプロセッサ、スイッチのパケットミラーリング、INT | 通信の内部ギャップ、輻輳、帯域劣化 | ノード内の計算、NVLink | | ハードウェア層 | 電力・温度・利用率・ECC・キャッシュ挙動 | DCGM、`nvidia-smi`、ipmitool、PMC | 物理的な劣化とエネルギー | 「なぜ」に当たる意味づけ | 通信ライブラリ層の例が Mycroft である。NCCL を計装して CUDA カーネル実行・RDMA 送信・完了通知の 3 段階のチャンク進行を内側から束ね、状態差から障害の所在を判定する。ただし可観測性は集合通信層に閉じ、アプリケーション層全体は見ない([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])。ネットワーク層では、INT のソース・シンク機能を SmartNIC へ載せ、eBPF によるホスト側トレースとフロー単位で融合する試みもある([[@2026__IFIP Networking__INTFusion - Unifying Network and Host Telemetry in Data Center Networks]])。重要なのは、層を計装できることと、それを学習処理の意味へ帰着させられることが別問題である点だ。各層のイベントを相関させて分散トレーシングへ落とすには意味づけが要るが、そうしたツールは現状存在せず研究開発領域である([[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]])。 ### 6.3 計装手法の比較 | 手法 | 代表例 | 侵襲度 | 粒度 | オーバーヘッド | 観測できるもの | 主な死角 | |---|---|---|---|---|---|---| | フレームワーク計装(コード改変あり) | MegaScale の FSDP パッチ、CCL 改変系 | 高(バックエンドへ侵入) | 演算子単位 | 実測値により中程度 | 全スタックのフェーズ境界 | 他バックエンドへの移植性 | | フレームワーク計装(非侵入) | Flare(旧 XPUTimer)の `PyEval_SetProfile` + `LD_PRELOAD` | 低(コード改変なし) | Python API・カーネル単位 | 平均 0.43%(1024 GPU)、TorchRec で 1.02% | 発行遅延分布、空白割合、性能回帰 | 計装外の少数派カーネル | | ベンダープロファイラ | PyTorch Profiler、Nsight Systems、CUPTI | 中(有効化が要る) | マイクロ秒級 | PyTorch Profiler は 20〜44% 増でメモリ枯渇、nsys は常時稼働で学習破壊 | カーネル・メモリ・通信の詳細 | 常時稼働に耐えない | | ベンダープロファイラの再設計 | ARGUS(CUPTI を 3 経路分離)、XProf(TraceMe) | 低 | カーネル単位・フェーズ単位 | ARGUS 合計 2% 未満、XProf は TPU で 0.3% 未満・H100 で 0.13〜2.30% | 常時稼働の細粒度トレース | SM 占有・ワープ実行 | | コンパイル時計装 | hip-analyzer(LLVM パス) | 高(再コンパイルが要る) | 制御フロー・イベント単位 | Rodinia でプログラム全体平均 1.60 倍・中央値 1.26 倍 | 決定的な実行トレース | 本番の動的な観測 | | ホスト側 eBPF | ProfInfer、CUDA API トレース | 極低(改変・再コンパイル不要) | トークン・グラフ・演算子・スケジューラ | ProfInfer は BCC で 2.8〜4.0%、libbpf 最小 1.7%、上位 2 粒度のみなら 0.1% | 演算子の型・次元・PMC・スレッド競合 | GPU 内部の詳細 | | GPU 内部 eBPF(PTX 注入) | eGPU / bpftime | 低(稼働中カーネルを中断しない) | スレッド・ワープ単位 | NVBit 系(gpumemtrace)より低く、128 KB 以下で安定 | メモリアクセスパターン、ワープスケジューリング、カーネル内制御フロー | 評価が単一 GPU・マイクロベンチマークに限定 | | ネットワークトラフィック観測(非侵入) | Pulse(NIC 上)、LLMPrism(スイッチ層) | ゼロ(学習側に一切触れない) | Pulse はマイクロ秒級、LLMPrism はフロー単位 | Pulse は遅延 1.52 対 1.53 マイクロ秒で実質ゼロ、LLMPrism はほぼゼロ | 通信の内部ギャップ、並列化戦略、学習タイムライン | ノード内・NVLink・ホストメトリクス | | ハードウェアカウンタ | DCGM、PMC、ipmitool | ゼロ | 秒〜分単位、または演算子単位の PMC | 無視できる | 電力・温度・利用率・キャッシュミス | 根本原因の分類 | コンパイル時計装の値は先行研究との対比で読むと意味が立つ。CUDAAdvisor や PPT-GPU はおおよそ 10〜120 倍、CUDA Flux は 1〜151 倍(平均 13.2 倍)のオーバーヘッドを生じており、hip-analyzer の 1.6 倍は 1 桁の改善に当たる([[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]])。粒度と侵襲度は独立した軸である。非侵入だが演算子単位に留まる系(GreyHound)が存在することは、非侵入化だけでは粒度問題が解けないことを示す。演算子単位の限界は粒度に由来するため、侵襲度をいくら下げても解けない([[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]])。 ### 6.4 主要システム — 何を観測し、どの障害像を狙うか #### 6.4.1 XProf — フルスタックの統一ビューと拡張性 XProf は OpenXLA の一部として公開された ML プロファイリングシステムで、ホスト(CPU)とデバイス(TPU / GPU)を単一の相関タイムラインへ統合する([[@2026__MLSys2026__XProf - An Open, Scalable and Extensible Profiling System for the Modern ML Stack]])。設計の核は四つある。第一に軽量ホスト計装 TraceMe で、非活動時は影響ゼロ、スレッドローカル記憶と償却型の確保でブロックせず、ホストトレース量を毎秒数キロバイトに抑える。第二に「後で点を繋げる」戦略で、実行中は小さなローカル識別子だけを伝播させ、エンドツーエンドの相関は後処理で再構築する。第三に Global Timestamp Counter による高精度クロッキングで、1 GHz クロックドメインでは 1 ティックが 1 ナノ秒に相当し、チップ間のトレースを相関できる。第四に MapReduce 型の分散バックエンドと、ビューポート内だけを描画する動的レンダリングである。 XProf が狙う障害像は狭義の故障ではなく効率である。実測オーバーヘッドは TPU で一貫して 0.3% 未満だが、H100 では 0.13〜2.30% と一桁近く高い。これはコールバックで全アクティビティ種別を監視する計装方式に由来し、要約が掲げる「1% 未満」は GPU の一部ワークロードで成り立たない。代表的な成果として、Trace Viewer で実行タイムラインと電力・熱テレメトリを相関させ、同期操作が電力スパイクの要因と特定し、アイドル期間に低影響な操作を挿入する緩和で電力変動を約 50% 削減し、チップ温度変動を 20°C から 10°C へ半減させた。プロファイラを PJRT C API の拡張として切り出したことで、TPU・NVIDIA / AMD GPU・Amazon Trainium・Intel GPU を横断できる。 #### 6.4.2 ARGUS — 常時稼働・細粒度・実時間の同時達成 ARGUS は、学習コールヒエラルキーに沿って観測を CPU コールスタック(py-spy 改造)・フレームワークセマンティクス(CUDA Event)・カーネル実行(CUPTI Activity API)の 3 機構へ分解し、層ごとにオーバーヘッド上限を設けることで合計 2% 未満を達成した([[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]])。CUPTI のバックエンドを制御パス・収集パス・処理エクスポートパスの 3 経路に分離し、コールバックがホットパスをブロックしないようにした点が要である。もう一つの柱がデータ削減である。分散学習のカーネル実行は高度に規則的な反復パターンを持つが、同一カーネル名でも位置やストリームが異なれば持続時間は数倍違う。ARGUS は `(カーネル, ストリーム, ランク)` ごとに対数変換後の持続時間へカーネル密度推定を適用し、密度曲線の谷でクラスタを切り、各クラスタの `(件数, p50, p99)` だけを残す。K の事前指定も履歴データも不要で計算量は線形である。圧縮率は約 3,700 倍(10 MB から 2.7 KB)で、1 万 GPU 規模でも毎分約 2.7 GB に収まり時系列データベースへ取り込める。診断は L1(反復時間の異常ウィンドウ、秒オーダー)、L2(ストラグラーランクとボトルネックフェーズ、秒オーダー)、L3(劣化カーネル、分オーダー)、L4 / L5(手動深掘り)の 5 段階が並行稼働し、対象を数万ランクから一桁へ絞り込む。L3 では圧縮統計から対数正規混合の累積分布を再構成し、ランク間の Wasserstein-1 距離を四分位範囲ベースの外れ値検出にかける。10,000 GPU 超の本番へ 6 ヶ月以上展開されたが、パイプライン依存によるバブル転送や勾配同期のアライメント効果が異常を覆い隠す事例(Case 3)、断続的な JIT コンパイルによるストール(Case 4)では自動 L1〜L3 が検知に失敗し、手動 L4 が必要だったことも明記されている。 #### 6.4.3 Pulse — トラフィック計測という別レイヤからの細粒度化 Pulse は、学習コードにも通信ライブラリにも一切触れず、NIC 上の RDMA トラフィック計測だけで異常箇所を特定する([[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]])。RNIC の組み込みマイクロプロセッサを計測基盤にし、集約層(パケットパイプライン上、4 KB 送信ごとにイベント発火)・計測層(マイクロプロセッサ上、キューペア単位でエポック単位のレート計測)・収集層(ホスト上、周期ポーリングと老化)の 3 層で、計測をパケット処理のクリティカルパスから外す。フロー層の計測を演算子へ結び付けるのが Host Agent である。関数フックで各演算子の期待通信量と相手を導き、理論量の下限と時間間隔閾値の 2 条件で演算子境界を識別する。並列化戦略も決定木で推定し、評価では 100% の精度を得た。狙う障害像は明快で、演算子単位の観測が原理的に取りこぼす二種類のギャップ——受信側の実行遅延によるミリ秒級ギャップと、ストラグラーによるマイクロ秒級ギャップ——である。400 Gbps・2 チャネルでスライス送信は約 40 マイクロ秒であり、帯域が 1/p に落ちれば正常ノードに 40(p−1) マイクロ秒のギャップが生じる。監視粒度がこれを超えると不可視になるため、1/25 への劣化まで許容しない限りマイクロ秒監視が要る。 12 シナリオ中 10 でマシン単位の箇所特定を達成し、既存手法は 4 のみ成功し 2 を誤診した。適合率 90% 超・再現率 100%、平均約 6 秒。ただし対象はノード間 RDMA 通信に限られ、NVLink などのスケールアップネットワークやノード内の計算ストラグラーは監視外に残る。 #### 6.4.4 LLMPrism — 黒箱をスイッチ層から解く LLMPrism は、データセンターに既存のスイッチ層 RoCE フロー監視だけを入力に、学習タイムラインを再構築する([[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]])。成立根拠は学習通信の三つの性質——空間的に安定(同じデータ並列またはパイプライン並列グループ内に限定)、時間的に周期的、並列化ごとに通信特性が異なる——である。素集合データ構造で通信ペアを併合してジョブを認識し、フロー間隔にベイズ的オンライン変化点検知をかけてステップ境界を取り、ステップ内の相異なるフローサイズ数からデータ並列とパイプライン並列を分類する。 2,880 GPU から 19 ジョブを正確に識別し、雑音精緻化を加えると 1〜10 分のいずれの窓長でも並列化戦略の識別が 100% になった。タイムライン再構築の誤差は 0.3% 以内。スイッチ層診断では、通常 100〜180 Gb/s の平均帯域が一部スイッチで 30〜60 Gb/s へ劣化する異常を検知して通知した。狙うのは fail-slow の検知であり、根本原因の同定は範囲外で追加調査を要する。テンソル並列はノード内に閉じスイッチから見えないため、物理トポロジ情報で間接的に扱う。 #### 6.4.5 Flare(旧 XPUTimer)— 性能回帰という未踏の障害像 Flare は、突発的で検知しやすい fail-slow と、持続的で検知しにくい性能回帰を明確に二分し、後者に注力する([[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]])。回帰はコード更新や設定ドリフトに由来し、スループットという巨視指標には現れない。そこで二つの微視指標を導入した。第一が発行遅延分布(カーネル発行時刻と GPU 実行開始時刻の差の分布)で、不要な GPU 同期や Python の GC が起こす発行ストールを、タイムラインの人手精査なしに検知する。第二が空白割合で、計装外のステップ間 CPU 操作と少数派カーネルが残す空白時間を比率として捉える。計装は CPython の `PyEval_SetProfile` と `LD_PRELOAD` によるプラグアンドプレイで、バックエンドのコードに侵入しない。新バックエンドへの拡張は環境変数の追加だけで済む。通信ハングの診断には、CUDA-GDB で停止中のプロセスにアタッチし、稼働中の ring-allreduce カーネルのレジスタからループステップを読む手法を用いる。全 GPU で並列に行えるため計算量は一定で、実測 29.4〜309.2 秒。NCCL テストの全数探索が数千 GPU で 30 分超かかるのと対照的である。6,000 GPU で 8 ヶ月以上稼働し、平均オーバーヘッドは 0.43%、GPU あたりのトレースログは 1.5 MB。実世界の回帰 113 件に対し偽陽性率 1.9%・真陽性診断精度 81.8%、微小な回帰では 2.66% のスローダウンまで捉えた。運用効果として、再発回帰に関するチーム横断協業の頻度が 1 週間で 63.5% 減った。診断精度そのものより「正しいチームへ自動で振り分ける」ことに主眼がある点が特徴的である。 #### 6.4.6 EROICA — 差分可観測性による全ワーカー同時プロファイリング EROICA は、性能劣化を検知したら全ワーカーに同期プロファイリングを通知し、既定 20 秒のウィンドウで一斉に測る([[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]])。生データを比較する代わりに、クリティカルパス上の関数ごとに 3 次元ベクトル——β(クリティカルパス占有率)、μ(ハードウェア資源利用率の平均)、σ(その標準偏差)——へ圧縮する。3 次元とも絶対時刻に依存しないため、クロック同期なしにホスト間比較ができる。パターンはワーカーあたり約 30 KB で、生プロファイル約 3 GB の 10 万分の 1 である。異常判定は二つの距離を使い分ける。期待範囲からのマンハッタン距離は設定不備や非効率なコードという共通問題を、無作為抽出した 100 ワーカーとの差分距離は特定ワーカー固有のハードウェア障害を捉える。約 100,000 GPU に 1.5 年展開し、既存手法で解けなかった深刻な性能問題 80 件のうち 78 件(97.5%)で根本原因を特定した。同じ 7 問題に対し MegaScale と NCCL Profiler は 1 件、bpftrace は 3 件、Nsight Systems と PyTorch Profiler は 4 件しか検出できず、しかも後二者はオフラインで 1.5 日・3.5 日を要したのに対し EROICA は 3 分だった。母集団の内訳も示唆的で、性能問題の 44.4% がハードウェア起因、48.2% がアプリケーション層起因(利用者コード 26.0%、設定 22.2%)であり、既存監視でオンライン診断できたのは全体の 29.6% にすぎなかった(障害の実測分布そのものの詳細は第 VII 部)。弱点は判定からデータ収集まで 20 秒強を要し瞬間的な劣化に届かないこと、通信が計算と完全に重なる実装では通信ストールがクリティカルパスに現れず見落としうることである。 #### 6.4.7 ProfInfer — 端末側推論への eBPF の適用 ProfInfer は学習ではなく端末上の推論を対象とするが、計装設計として学習側にも示唆が大きい([[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]])。eBPF の uprobe・uretprobe・tracepoint を llama.cpp のランタイム関数へ動的にアタッチし、ソース改変も再コンパイルもせずにトークン・グラフ・演算子・スケジューラの 4 粒度でトレースを取る。演算子レベルでは PMC を読み、`ggml_tensor` 構造体を辿って演算子の型・次元・依存を抽出することで、ハードウェア挙動とモデル構造を対応づける。注目すべきは粒度とオーバーヘッドの交換関係を実行時に調整する設計である。トークン単位の計測から復号速度を求め、サービス品質要件を下回ったらトレース機能を部分的に切る。全機能有効時の復号速度低下は BCC で 2.8〜4.0%、libbpf で最小 1.7% だが、トークンとグラフの 2 粒度のみなら 0.1% に収まる。得られた知見も具体的で、復号のボトルネックはメモリ帯域で 2 スレッド程度までしか伸びず、4 スレッドでは停滞サイクルが全 CPU サイクルの 80% を超えて資源の浪費になること、MoE では活性化エキスパートの再利用距離が演算子時間にほぼ比例し、ボトルネックはメモリ帯域ではなくディスク I/O にあることを示した。 ### 6.5 GPU 可観測性のギャップと eBPF on GPU 既存の GPU ツールは三類型に整理できる。CPU と GPU の境界をトレースするツール(カーネル内部は黒箱)、ベンダー専用の重量級プロファイラ(閉じたイベントモデル、専用セッションが要る、本番常時運用に向かない、ベンダーロックイン)、研究ツール(CUPTI は高レベル指標に留まり、NVBit や NEUTRINO はアセンブリ・PTX レベルの計装で安全性と移植性を欠く)である([[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]])。 eGPU はこの穴を、eBPF バイトコードを実行時に PTX へコンパイルして稼働中のカーネルへ注入することで埋めようとする([[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]])。稼働中カーネルを中断せずに計装を追加・変更・削除でき、SASS バイナリ書き換えより高位の中間表現で扱うためレジスタ利用やワープスケジューリングを活かしやすい。CPU と GPU の双方から参照できる共有メモリ上の eBPF マップにより、繰り返しコピーなしでイベントと統計を交換する。マイクロベンチマークでは NVBit ベースの gpumemtrace より低いオーバーヘッドを示したが、評価は単一 GPU・マイクロベンチマークに限られ、実ワークロードでのエンドツーエンド評価は残る。verifier が SIMT 実行モデルへどこまで安全性保証を与えられるかも未解決である。前段としての CPU 側 CUDA API トレースも実装入門として機能する。`libcudart.so` への uprobe により、割当・ホストからデバイスへの転送・カーネル起動・デバイスからホストへの転送・解放というライフサイクルを、API 呼び出しあたり約 2 マイクロ秒のオーバーヘッドで再構成できる([[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]])。ただしホスト側 eBPF は GPU 内部の死角を残し、SM 利用率などマイクロアーキテクチャ内部の情報は依然ハードウェアカウンタか PTX 注入に頼る。 ### 6.6 性能モデリングと what-if 分析観測の対極にあるのが「測らずに知る」系統である。二つの方向がある。第一が事前の性能モデリングである。LLM を演算プリミティブへ分解し、演算種別ごとに木ベース回帰器(RandomForest / XGBoost)を学習して 3 次元並列のタイムラインモデルへ階層的に集約する手法は、Perlmutter(A100)で平均予測誤差 4.98%、Vista(GH200)で 9.38% を達成した([[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]])。木ベースを選ぶ理由は、自動チューニングやカーネル切り替えに由来する段階的・不連続な性能曲線を、命令レベルのプロファイリングなしに捉えられるからである。予測は完全に CPU 上で動くため、20B モデルを 128 GPU で 60 秒サンプリングして 2 ノード時間を消費するような実機探索を避けられる。計算演算が総実行時間の 70〜95% を占め高精度に予測される一方、通信演算の誤差は 50% を超えることもあるが、反復時間の 5% 未満しか占めないため全体精度への影響は小さい。実行時間への寄与に比例してモデリング能力を配分した結果である。第二が事後の反事実分析である。SMon の what-if 分析は、ストラグラーが存在しない代替タイムラインをトレースから再構成し、実トレースと対比してスローダウンをワーカー別・演算種別別に帰属する([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]])。5 ヶ月・3,079 ジョブの分析から得た結論は運用の直観を覆す。ジョブの 42.5% が 10% 以上スローダウンし、全 GPU 時間の 10.4% がストラグラーで浪費されていた。しかし上位 3% のワーカーがスローダウンの過半を説明するのはストラグラージョブのわずか 1.7% にすぎず、問題ワーカーは主因ではない。支配的なのは、最終パイプラインステージの分割不均衡(39.3% のジョブで過半を占める)、シーケンス長の不均衡(21.4% のジョブ、平均スローダウン 1.34)、そして Python の GC である。緩和策も具体的で、シーケンス再分配で 23.9%、全ワーカー同期の計画 GC で 12.6% のスループット改善を得た。ここから導かれる帰結は重い——従来のハードウェア健全性チェックでは大半のストラグラーを検知も予防もできない。なお、スローダウンはステップ単位で持続的であるため、学習ステップの 10% をサンプリングすれば足りるという費用対効果の根拠も示されている。 ### 6.7 トレース標準化とベンチマーク観測の出力をどう共有するかという層の問題もある。Chakra は分散 AI ワークロードの実行トレースを有向非巡回グラフとして標準化する取り組みで、ノードは計算・メモリ・通信のいずれかを、エッジは制御依存とデータ依存を表す([[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]])。ホスト側(PyTorch の Execution Graph Observer)とデバイス側(Kineto)という別々に集めたトレースを Trace Linker が結合し、制御・データ・同期の 3 種の依存を持つ単一の DAG へ正規化する。この標準化が解く実務課題は二つある。ベンダー固有形式による断片化と、モデル詳細を開示できないためにワークロードを共有できないことである。計算・メモリ・通信ノードへ抽象化することで、重みやデータセットを開示せずに移植可能なベンチマークが成立する。実際の分析例として、帯域を 400 Gb/s から 100 Gb/s へ落とすと AllToAll が 4.1 倍、AllGather が 4.4 倍、AllReduce が 9.7 倍に伸び、通信量の小さい集合ほど帯域低下の影響を強く受けることが示された。ハードウェアインザループ検証では、AllReduce と AllToAll を単独実行すれば安定するのに混在させると相互干渉が起き、AllReduce の高レートフローが輻輳制御を発火させて AllToAll の多数の低帯域フローを不釣り合いに抑制することが判明した。トレースは MLCommons の下で 40 以上の組織が関与し、ASTRA-sim や商用エミュレータに採用されている。課題は残り、大規模ワークロードのトレースがギガバイト級に達する問題は未解決で、圧縮や階層索引は今後の課題である。 ### 6.8 日本の AI スーパーコンピュータにおける計測実践事業者としての実践は、研究システムが前提にする条件との段差を率直に示す。まずユーザー視点(学習処理性能・計算資源利用率)とプロバイダ視点(障害・故障管理・計算資源利用率)を分け、前者をワークロード分析、後者をリソース分析として整理する([[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]])。責任境界によりアプリケーションログもコード計装も取れないため、まず OTel と Grafana で GPU 電力・温度・メモリ、NVLink / NIC スループット、ジョブ履歴を可視化し、そのうえで学習処理スパンや集合通信スパンのトレース化を課題に置く。具体構成も公開されている。GPU ノード 100 台上に DCGM Exporter・Node Exporter・Lustre Exporter・IPMI Exporter・自作の RDMA Exporter・opentelemetry-ebpf-profiler を配し、OTel Collector Agent から Gateway を経て VictoriaMetrics / VictoriaLogs / Pyroscope へ流し、Grafana で見る。ダッシュボードは空間ビュー(ラックからサーバ、GPU への入れ子)・時系列ビュー・ジョブビュー(ガントチャート)の 3 種に分化する([[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]])。一方でログとプロファイルは「有効利用できていない」と述べ、リソース分析は機能してもワークロード分析には届いていないと認める。PyTorch Profiler については利用者側で有効化が要り、1.42 倍の遅延増加という定量値もあってプラットフォーム要件に合わないと整理される。GPU 利用率 100% でもテンソルコア使用率 40〜50% でようやく良い効率という運用実感も、平均利用率だけでは足りないことを裏づける。運用判断への波及も記録されている。64 ノード級ジョブの不安定さが解消後も不安として残り、安定していた 32 ノード構成を選ぶ判断が語られた。可観測性の出力は可視化に留まらず、構成選択・代替ノード・チェックポイント復旧という意思決定に入る。故障率の実感が事業者間でばらつくことも語られており、その実測統計の扱いは第 VII 部に譲る。エネルギーもまた測るべき対象である。H100 と B200 を同一条件で比較すると、B200 は利用率で 1〜6%、学習時間で最大 15%、GPU あたり TFLOPs で最大 32% 上回るが、TFLOPs/kW とキロジュールあたりトークン数では 5 モデルすべてで H100 を下回った([[@2026__AI__Scalable and Energy-Efficient AI - System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training]])。スループット向上がエネルギー効率向上に比例しないというこの計算とエネルギーの不整合は、施設規模では中負荷 2,000 ノードで年間 62 万ドル、高負荷 5,000 ノードで年間 426 万ドルの超過コストとして現れる。計算効率とエネルギー効率は別の指標であり、両方を測らないと調達判断を誤る。参考として、フリート規模の効率指標を二軸で持つ実践もある。FLOPs/秒を一次効率指標に、rDevice hour/Byte を正規化コスト指標に据える分離である([[@2023__SystemAtScale__AI Observability]])。 ### 6.9 実運用の要点 — 常時オンと深掘りの設計 #### 6.9.1 二層構造で考えるここまでの事例が一致して示すのは、単一の計装ですべてを賄う設計は成り立たないということである。常時オンにできる軽い層と、条件を満たしたときだけ有効化する重い層に分け、前者が後者を起動する契機を作る。ARGUS の L1〜L3 が自動・L4/L5 が手動という 5 段階も、EROICA が劣化検知を契機に 20 秒の同期プロファイリングを起動する設計も、ProfInfer がサービス品質要件を下回ったらトレース機能を切る設計も、同じ構造の変奏である。 | 層 | 稼働形態 | 具体的な計測 | 許容オーバーヘッドの目安 | 起動条件・出力 | |---|---|---|---|---| | 第 1 層(常時オン・基盤) | 無条件・常時 | 電力・温度・利用率・ECC・NVLink / NIC スループット・ジョブ履歴 | 実質ゼロ | 閾値アラートと空間・時系列・ジョブの各ビュー | | 第 2 層(常時オン・意味づき) | 無条件・常時 | 反復時間、フェーズ持続時間(順伝搬・逆伝搬・最適化・通信)、カーネル統計サマリ | 合計 2% 未満を上限に置く | 異常ウィンドウ・ストラグラーランク・劣化カーネルの自動特定 | | 第 3 層(常時オン・非侵入外部) | 無条件・常時 | NIC 上の RDMA レート、スイッチ層フロー統計 | 学習側にゼロ | 通信の内部ギャップ、帯域劣化、輻輳 | | 第 4 層(条件付き起動) | 劣化検知時のみ、時間窓を区切る | 全ワーカー同期プロファイリング、コールスタック、実行トレース | 一時的に数%〜数十% を許容 | 根本原因の確認、責任チームへの振り分け | | 第 5 層(オフライン) | 事後・任意 | what-if シミュレーション、性能モデリング、トレース再生 | 本番影響なし | 反事実による帰属、設計空間探索、協調設計 | #### 6.9.2 指標設計のチェックリスト以下は本部で読んだ事例から抽出できる設計上の問いである。 - **一次シグナルは利用者可視の量になっているか**。ハードウェアのエラーカウンタでなく、最終的なエンドツーエンド性能を説明する量——反復時間やステップ時間——を起点に置く。 - **絶対閾値に頼っていないか**。参照系を空間軸(同一役割のピア群)に取るか、時間軸(同期点の周期性)に取るかを明示する。EROICA が期待範囲からの距離とピアからの差分距離を使い分けたように、共通問題と個別問題は別の参照系で捉える。 - **粒度がその障害の時間スケールに足りているか**。マイクロ秒級のギャップは秒単位のスクレイプでは原理的に見えない。逆に、持続的な回帰は巨視指標に現れず微視指標を要する。狙う障害像から必要粒度を逆算する。 - **時刻の基準は何か**。絶対タイムスタンプに依存する指標はクロック同期を要求する。EROICA の 3 次元パターンや、ARGUS の分布統計のように時刻非依存な表現を選べば、この制約から自由になる。ハードウェア同期カウンタを持てるならそれに越したことはない。 - **保存と比較のコストを設計に含めたか**。細粒度データは取れても保存・比較できなければ意味がない。分布を保ったまま圧縮する(統計サマリと累積分布の再構成)か、意味のある派生指標だけを残すかを先に決める。 - **オーバーヘッドの上限を層ごとに置いたか**。全体で「軽くする」ではなく、機構ごとに上限を割り当てて構造的に制御する。上限を超えたら粒度を落とす経路を実装に組み込む。 - **観測の出力が誰のどの行動につながるか**。診断精度そのものより、正しいチームへ自動で振り分けることに運用価値がある場合がある。可視化で終わらず、緩和・復旧・構成選択の判断へ接続する。 - **効率とエネルギーを別々に測っているか**。計算スループットの指標だけでは、エネルギー効率の劣化を見逃す。 - **自動で検知できない障害クラスを明示したか**。パイプライン依存によるマスキング、通信症状に隠れた演算ストラグラー、完全に重なった通信のストールなど、自動層が構造的に取りこぼす種類を列挙し、手動深掘りの導線を用意しておく。 #### 6.9.3 残る問い観測の空白は依然として広い。ホスト側の傍受だけで GPU 内部の可視性(SM 占有・ワープ実行・キャッシュ挙動)をどこまで補えるか、PTX 注入とハードウェアカウンタの併用が現実解かは未決着である。マシン単位の箇所特定とカーネル・デバイス層の観測をどう統合するか、GPU ドライバ層・CUDA API 層・GPU 内部層の計装を順伝搬・逆伝搬・重み更新・集合通信というスパンへどう帰着させるかも、現状は研究開発領域に留まる。履歴依存の回帰検知が公開クラスタや dense から sparse MoE への大幅なアーキテクチャ変更にどう一般化するかも開いた問いである。観測されたシグナルを検知と箇所特定の判断へどうつなぐかは第 VIII 部が扱う。  --- ## 第 VII 部障害の実態 — 何が、どのくらいの頻度で壊れるか大規模学習インフラの運用設計は、まず「何が、どのくらいの頻度で壊れるか」の実測像から始まる。本部は現象の実証的記述に徹する。すなわち、公開された運用データが示す故障率・障害種別の内訳・故障モードの性質を並べ、そこから読み取れる構造を整理する。検知の手法(どう気づくか)は第 VIII 部、復旧の手法(どう立て直すか)は第 IX 部が扱うため、本部では対処法へ踏み込まず、対処すべき対象の輪郭を確定させることに集中する。 ![[Attachments/llm-training-ch07-failures.png]] *図 8. 第 VII 部の障害像。起因と症状は多対多で対応し、同期学習では一台の障害が全ランク待機、ジョブ停止、再キューへ増幅する。*（Source: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]） ### 7.1 実測された故障統計 — 複数クラスタの横並びまず、公開されている実証研究の規模と主要指標を横並びに置く。母数も観測期間も指標定義も揃っていないため、そのまま比較すると誤読を招く。以下の表は「何を、どの規模で、どれだけの期間測ったか」を明示したうえで並べたものである。 | クラスタ | 規模 | 観測期間 | 主要な故障指標 | 出典 | |---|---|---|---|---| | Meta RSC-1 / RSC-2 | 16k + 8k A100(計 24k) | 11 か月・4 百万ジョブ・1.5 億超 GPU 時間 | 1,024 GPU ジョブの MTTF 7.9 時間、8 GPU ジョブ 47.7 日 | ([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) | | NCSA Delta(A100 系統) | 106 ノード / 448 GPU | 3 年・1,250 万 GPU 時間 | 運用期の per-node MTBE 154 時間(事前運用期 199 時間) | ([[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]]) | | NCSA Delta(A100 + H100) | 1,056 GPU | 2.5 年・1,170 万 GPU 時間 | メモリの per-GPU MTBE:H100 88,768 時間 / A100 283,271 時間 | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | | ByteDance 本番 | 9,600 Hopper GPU | 3 か月 | 明示的障害 38,236 件・暗黙的障害 5,948 件 | ([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) | | ByteDance 訓練クラスタ(Minder 対象) | 4〜1,500 台超(最大 10,000 GPU) | 9 か月・障害 150 件 | タスクあたり平均 1 日 2 回の障害 | ([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) | | Lablup 他 5 者共同クラスタ | 63 ノード / 504 B200 GPU | 55 日(時系列)・73 日(ログ)・224 セッション | 55 日で 17 障害イベント | ([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]]) | | SAKURAONE | 800 GPU・単一テナント | 3 か月 | 障害 21 件、大半はノード再起動で数分復旧 | ([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) | | Azure A100 クラスタ | 24k+ A100 GPU(3k+ VM) | 2 年超 | MTBI 17.5 時間、38.1% のインシデントが復旧に 1 日超 | ([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]]) | この表から読み取るべき第一点は、指標の桁が大きく開いているのは測定対象が違うからだという事実である。Delta の MTBE は GPU コンポーネント単位のエラー間隔、Meta の MTTF はジョブ規模ごとの故障間隔、Azure の MTBI はノード単位のインシデント間隔で、直接の比較はできない。第二点として、可用性の水準はおおむね「2 nines」に収まる。Delta の A100 は GPU ノード可用性 99.5%(1 日 7 分のダウンタイム)、A100/H100 併せて per-GPU ノード可用性は A100 約 99.4%・H100 約 99.3%(1 日 9〜10 分)である([[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]], [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。608 GPU・復旧 2.2 時間のジョブでジョブレベル 99.9% を保つには約 5% のオーバープロビジョニングが要り、1,000 ノード規模では月 100 万ドル超のコストになる([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。第三点は、故障率が定数ではないことである。Meta の RSC-1 では、約 2.5 failures/1000 node-days の期間から約 17.5 failures/1000 node-days のスパイクまで変動した([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。故障率を一つの数値に固定して設計する前提そのものが成り立たない。 ### 7.2 障害の分類学と寄与率障害の内訳もクラスタごとに大きく異なる。以下に、種別内訳を報告している研究を並べる。 | 出典 | 分類軸 | 内訳 | |---|---|---| | ([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) | 起因層 | ハードウェア 55.8%(うち ECC error 38.9%)、ソフトウェア 28.0%(CUDA 14.6% / GPU 実行 7.7%)、ネットワーク 6.0% | | ([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]]) | 障害イベント種別(17 件) | NVLink 29.4%、ECC 11.8%、GPU カード脱落 11.8%、マシン到達不能 11.8%、GPU 実行エラー 5.9%、その他 29.4% | | ([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) | 部位(21 件) | GPU 関連 42.9%、インターコネクトスイッチ 23.8%、NVLink/PCIe 19.0% | | ([[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]]) | 障害の現れ方 | fail-stop 66%、fail-hang 17%、fail-slow 13%、fail-on-start 4% | | ([[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]]) | 根本原因 | ホスト環境・設定 32%、NIC エラー 15%、スイッチ設定 14%、ユーザコード 14%、ほか | | ([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) | レモンノードの部品別根本原因 | GPU 28.2%、DIMM 20.5%、PCIe 15.4%、EUD 10.3%、NIC 7.7%、BIOS 7.7%、PSU 5.1%、Optics 2.6%、CPU 2.6% | | ([[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]]) | 性能問題の起因 | ハードウェア 44.4%、アプリケーション層(コード・設定)48.2% | | ([[@2025__OSDI__Training with Confidence - Catching Silent Errors in Deep Learning Training with Automated Proactive Checks]]) | サイレントエラー 88 件の根本原因 | ユーザコード 32%、フレームワーク 32%、数学演算 12%、ハードウェア/ドライバ 12%、コンパイラ 8%、その他 4% | 内訳の食い違いは矛盾ではなく、分類軸と対象の違いである。ハードウェアが最多という骨格は Minder(55.8%)と SAKURAONE(GPU 関連 42.9%)で連続するが、EROICA が約 10 万 GPU・1.5 年の本番データで示すとおり、性能問題まで含めるとアプリケーション層が約半数を占める([[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]])。寄与率を件数で測るか GPU 時間で測るかで結論が反転する点は、繰り返し確認されている。ByteDance ではインフラ障害が件数の 11% でありながら GPU 時間の 82% を消費し、人手によるコード・データ調整起因の手動再起動が件数の 17.3% を占める([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。Meta ではハードウェア関連失敗がジョブ件数の 0.2% にとどまる一方、GPU 実行時間の 18.7% に影響する([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。分類そのものが難しいという事実も記録されている。Meta の障害タクソノミーは、同じ症状が複数ドメインにまたがるため根本原因を誤帰属しやすいと整理し、実際に多くのハードウェア障害は未帰属のまま残る([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。ByteDance も、Job Hang・不正メモリアクセス・NaN 値がいずれもインフラ障害とユーザコード障害の双方から生じうると報告する([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。 ### 7.3 GPU 固有の障害モード GPU の故障は XID エラーコードを通じて観測される。Delta の研究は XID を GPU ハードウェア(MMU・GPU Fallen Off the Bus・GSP・PMU SPI)、NVLink インターコネクト、GPU メモリ(DBE・連続 SBE)の 3 カテゴリに分類する([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。[[GPUレジリエンス]] の中核的な観測は、世代間で弱点が反転することである。 | コンポーネント | A100(895 日) | H100(146 日) | 出典 | |---|---|---|---| | メモリ(訂正不能 ECC)per-GPU MTBE | 283,271 時間 | 88,768 時間(3.2 倍短い) | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | | メモリ per-GB MTBE | 約 11,330,826 時間 | 約 8,521,728 時間(24% 低い) | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | | GSP エラー | 3,857 件 | 3 件 | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | | NVLink エラー | 1,922 件 | 0 件 | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | | PMU SPI エラー | 77 件 | 0 件 | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | | GPU Fallen Off the Bus | 10 件 | 0 件 | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | | Row Remapping Failure | 0 件 | 8 件 | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | A100 単体では、運用期の per-node MTBE で GPU メモリが 24,749 時間、非メモリ GPU ハードウェアが 155 時間であり、メモリのほうが 160 倍高信頼だった([[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]])。この直感に反する結果が A100 世代の基準線を与える。一方 H100 世代では、回復機構である spare row が世代をまたいで 512 行に据え置かれたまま容量だけが 2.4 倍に増えたため、メモリが弱点化する([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。回復可能なエラーと回復不能なエラーの区別は、ジョブ失敗確率として現れる。 | XID / エラー種別 | ジョブ失敗確率 | 出典 | |---|---|---| | GSP RPC timeout(XID 119) | 100% | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | | Contained ECC(XID 94) | 100% | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | | PMU SPI(XID 122) | 97.56% | ([[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]]) | | MMU(XID 31) | A100 90.48% / H100 73.80% | ([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]]) | | NVLink(XID 74) | 53.75% | ([[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]]) | MMU と NVLink を除く GPU エラーは、アプリケーション側で処理されずほぼ 100% がジョブ失敗に至る([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。逆に NVLink エラーは約 46% のジョブが完走しており、著者らは NVLink が未使用だった場合と CRC による検知・再送が効いた場合を理由に挙げる([[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]])。メモリ側では、row remapping と error containment が H100 で訂正不能メモリエラーの 92% を緩和し、A100 の運用期には訂正不能メモリエラーを 100% 緩和した([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]], [[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]])。エラーは単独では終わらず伝播する。PMU SPI エラーは確率 0.88 で MMU エラーへ伝播し、A100 では GSP エラーの 99% 超が GPU をエラー状態に落とす。NVLink エラーの 42%(801 件)は 2 GPU 以上へ波及する([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。時間軸では、GPU エラー率は古典的なバスタブ曲線に従う。infant-mortality 期の system-wide MTBE 0.15 時間が、normal-life 期には 1.4 時間へ 10 倍改善した([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。運用期に入ってからの劣化も観測されており、A100 の per-node MTBE は事前運用期 199 時間から運用期 154 時間へ 23% 悪化した。著者らは利用率上昇に伴う GSP・PMU のハードウェアエラー増加を主因とみる([[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]])。熱環境も故障要因になる。Kalos クラスタでは 7B モデル訓練中にサーバ室温が約 5°C 上昇し、NVLinkError と ECCError が増加した([[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]])。GPU の外側では光トランシーバも頻発かつ影響の大きい部品であり、故障予測の対象として扱われている([[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]])。 ### 7.4 サイレントデータ破損と静かな誤りここまでの障害は、XID なりログなりの明示的な信号を伴う。しかし学習を汚染しながら何も報告しない障害が存在する。ByteDance はこれを暗黙的障害と呼び、ハング・性能ジッタ・想定外の訓練軌道・サイレントデータ破損(SDC、NaN 損失など)を含める。3 か月で暗黙的障害 5,948 件が処理され、ハングだけで全インシデントの 9.9% を占める([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。SDC が厄介なのは、集合通信が破損を全ワーカへ伝播させるためで、原因の特定がさらに難しくなる。NVIDIA EUD の再現率は 70% にとどまり、規模拡大とともに SDC の頻度と影響が増して学習のスケーラビリティを制限すると報告されている([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。 [[DLトレーニングサイレントエラー]] の典型例が BLOOM-176B の事例である。DeepSpeed の BF16Optimizer にある勾配クリッピングのバグにより、テンソル並列ランク間で LayerNorm 層の重みが静かに乖離した。損失・精度には 10 日間まったく異常が現れず、重みのマージ時に初めて矛盾が露呈し、診断にさらに 9 日を要した。384 台の A100 GPU × 3.5 か月の訓練コストが危険にさらされた([[@2025__OSDI__Training with Confidence - Catching Silent Errors in Deep Learning Training with Automated Proactive Checks]])。なぜ損失曲線だけでは気づけないのか。理由は二つある。第一に、損失は「活動」を測る指標であって「正当性」を測る指標ではない。監視されているのは損失・GPU 使用率・クラッシュログ・ステップ時間であり、勾配が実際に更新されたか・GPU 間で同期が取れているか・訓練ループが正しいかは監視されていない([[@2026__SREcon26Americas__Beyond Loss and Accuracy - Closing the Observability Gaps in AI Training with TrainCheck]])。第二に、損失は他の要素によって補償されうる。Apple Silicon 上でスパース自動エンコーダを訓練した事例では、PyTorch MPS バックエンドの `Adam.addcmul_` が非連続テンソルでサイレントに失敗しエンコーダ重みが初期値のまま固まったが、デコーダが補償したため損失は下がり続けた([[@2026__SREcon26Americas__Beyond Loss and Accuracy - Closing the Observability Gaps in AI Training with TrainCheck]])。コストの計算基準も重要である。BLOOM-176B は 39,999 ステップ健全に見えたあとスパイクが出現し、そこからさらに 5,000 ステップ以上前へのロールバックを強いられた。監視の遅延コストは、損失が悪化した時点ではなく根本原因が発生した第 1 ステップから数えなければならない([[@2026__SREcon26Americas__Beyond Loss and Accuracy - Closing the Observability Gaps in AI Training with TrainCheck]])。実際、20 件の実世界サイレントエラーのうち、損失監視・トレンド検知・異常検知といった従来のベースラインが検知できたのは合計 2 件にとどまる([[@2025__OSDI__Training with Confidence - Catching Silent Errors in Deep Learning Training with Automated Proactive Checks]])。 ### 7.5 性能劣化型の障害 — 止まらないが遅くなる止まらない障害の実態も定量化されている。ByteDance の 5 か月・3,079 ジョブのトレースでは、42.5% のジョブが 10% 以上のスローダウンを経験し、全 GPU 時間の 10.4% が[[ストラグラー]]で失われた。p90 のジョブは 21.3% 以上、約 1% のジョブは 45.0% 以上の GPU 時間を浪費する([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]])。意外なのは主因の所在である。最も遅い 3% のワーカーがスローダウンの過半を説明するジョブはわずか 1.7% にすぎず、支配的な根本原因はパイプラインステージ分割の不均衡(39.3% のジョブ)とシーケンス長の不均衡(21.4%、平均スローダウン 1.34)、そして Python の stop-the-world GC である([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]])。「遅いワーカー = 壊れたマシン」という直感は、少なくとも広帯域の専用クラスタでは成り立たない。一方で、標準ヘルスチェックを通過しながら性能を落とすノードも実在する。Guard はこれをグレーノードと呼び、NCCL テストや GPU バーンインを通過するためジョブをクラッシュさせず、数週間にわたり沈黙のまま残存すると報告する。2% 程度の平均速度低下でもスループットは 20〜30% 損なわれ、学習コストは 1.3〜1.5 倍に膨らむ。ベースライン構成の MTTF は 6.6 時間、人的介入間隔は 5.6 時間だった([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])。この現象の一般名が[[グレイ障害]]である。Huang らは、少なくとも 1 つのアプリケーションがシステムを不健全と観測しているのに、システム内部の Observer は健全と観測している状態として定義した。特徴は[[差分可観測性]]、すなわち内部監視と利用側の観測の乖離にある([[@2017__HotOS__Gray Failure - The Achilles' Heel of Cloud-Scale Systems]])。 AI インフラ特有の増悪要因として、冗長機構そのものが劣化を覆い隠すことが挙げられる。Azure A100 の本番データでは、HBM の correctable error が 10 件を超えるとエンドツーエンド回帰確率が 5.6% から 83.3% へ跳ね上がる。さらに、ToR の冗長 uplink が複数本切れたとき「動く最小本数だけ復旧」する部分修復が常態化しており、同じノードの 1 回目と 20 回目のインシデント間隔は 719.4 時間から 151.7 時間まで縮む([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]])。冗長は信頼性の床を底上げするが、床が下降していく過程を見えなくもする。 Astral の分類では fail-slow が 13%、fail-hang が 17% を占め、いずれも明示的な診断ログを出さないため特定が難しい([[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]])。MegaScale でも約 0.5% のマシンが顕著に遅い計算ストラグラーとなり、除去により MFU が 0.7% 改善した。これらはいずれも単一 GPU の GEMM マイクロベンチマークでは検出できず、分散ビューの可観測性で初めて特定された([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。 ### 7.6 障害の規模依存性なぜ規模が増えると期待中断間隔が短くなるのか。Meta は、ノード障害率を `rf`、ジョブのノード数を `Nnodes` として、MTTF を `(Nnodes rf)^-1` と近似する。32 GPU 以上では、実測 MTTF が GPU 数に反比例する理論傾向とよく合う([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。 | ジョブ規模 | MTTF | 種別 | |---|---|---| | 8 GPU | 47.7 日 | 実測 | | 1,024 GPU | 7.9 時間 | 実測 | | 16,384 GPU | 1.8 時間 | モデル予測 | | 131,072 GPU | 0.23 時間 | モデル予測 | (いずれも [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) 同期学習では 1 タスクの失敗がジョブ全体の再割当を引き起こすギャングスケジューリング意味論を持つため、ノード数に比例して中断確率が上がる。ByteDance も、Meta の 16,000 GPU 訓練でハードウェア障害が約 2.78 時間に 1 回発生したという報告を出発点に置く([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。規模の影響は当該ジョブの外にも漏れる。1,024 GPU ジョブが NODE_FAIL 後に 35 回再キューされ、548 件のプリエンプションと 7,000 GPU 超の巻き込みを起こした事例があり、障害オーバーヘッド全体の 16% は失敗した大規模ジョブそのものではなく再キューに伴う小規模ジョブのプリエンプションから生じる([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。規模と復旧性の関係には、GPU 総数以外の変数も効く。504 GPU のクラスタは 60 ノード訓練 + 3 予備ノードという構成で、予備ノードの余裕の小ささが自動リトライの成否を左右した([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。すなわち「予備ノード数 / 大規模ジョブ要求ノード数」という比率が、絶対規模とは別に復旧性の設計変数になる。 ### 7.7 GPU 信頼性評価そのものの再考 — 予測より優先順位付け以上の統計は「いつ壊れるか」を予測したくなる動機を生むが、その予測は本質的に困難であるという実証がある。数千 GPU 規模の本番クラスタで DBE と GPU Lost を対象に 5 モデル(XGBoost・CNN・LSTM・Transformer・MoE)を横断評価したところ、8 時間観測窓での最良モデルでも F1 は 0.4837 にとどまった。原因はテレメトリの性質にあり、Frame Buffer Used は同一ワークロード条件下では Kendall τ = 0.861 に達するのにワークロードを跨ぐと相関がゼロ近傍まで崩壊し、障害前 24 時間と正常時の分布は KL 距離 0.09〜0.10 でほぼ完全に重複する([[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]])。一方で、はるかに安定した統計的規則性が存在する。障害はホスト単位で Pareto 分布に集中し、全ホストの 10% 未満が critical な DBE・GPU Lost 障害の 24〜33% を四半期・90 日ローリング窓を通じて安定的に占める。χ² 適合度検定はポアソン帰無仮説を p ≪ 10^-10 で棄却する([[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]])。この集中は他クラスタでも独立に観測されている。504 GPU クラスタでは 63 ノードのうち上位 3 ノードが全除外の 50% 超を占めた([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。Meta の「レモンノード」検知は 40 台の故障疑いノードを 85% 超の精度で特定し、それらは RSC-1 の 1.2%・RSC-2 の 1.7% のフットプリントにすぎないが、512+ GPU の大規模ジョブ失敗率を 14% から 4% へ下げた([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。含意は、信頼性評価の問い自体を組み替えるべきだということである。絶対的なタイミング予測ではなく、相対的なリスク順位を出す定式化に切り替えると、教師信号が疎で確率的なものから密で安定したものへ変わる([[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]])。これは[[障害予測]]の枠組みそのものに対する再考であり、詳しい手法と運用への接続は[[プロアクティブ障害管理]]とあわせて第 VIII 部で扱う。 ### 7.8 障害注入とレジリエンス評価の方法論自クラスタの故障プロファイルを能動的に測るには[[障害注入]]が要るが、AI システムの層構造にはまだ大きな空白がある。AI システムを Service / Model / Framework / Toolkit / Platform / Infrastructure の 6 層に分割して 142 本の論文を体系化したサーベイによれば、AI Framework 層では 6 種のうち 4 種(API 誤用・設定・性能・コード)が、AI Toolkit 層では 11 種のうち 5 種が、AI Platform 層では 11 種のうち 6 種が FI 未対応である。とりわけ NCCL 障害・NVLink 障害・InfiniBand 障害という分散学習の基幹通信障害は、既存 FI ツールがカバーしていない([[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]])。数少ない例外として、集合通信層へ 7 種のハードウェア/システム障害(NIC シャットダウン・NIC 帯域制限・PCIe ダウングレード・GPU パワーリミット・バックグラウンド計算・バックグラウンドトラフィック・NCCL 遅延)を注入した検証がある([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])。この層の注入は明確な観測可能信号を生む。対象が確率的なサービス負荷ではなく決定的なハードウェア状態だからである。観測側の方法論も明示しておく価値がある。Delta の研究は、同一 GPU・同一メッセージのエラーが短時間窓 Δt = 5 秒内に連続するバーストを 1 件に集約してから統計を取る。集約しないと MTBE を大きく過小評価する。実際、事前運用期には 1 台の故障 GPU が 17 日間 uncontained memory error を出し続け、100 万件超の重複ログを生んだ事例がある([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]], [[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]])。障害とジョブ失敗の紐付けも、GPU エラー発生から 20 秒以内に失敗したジョブを "GPU-Failed" と判定する時間相関であり、因果ではなく潜在的寄与要因にとどまる([[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]])。 ### 7.9 実運用の要点 — 自クラスタの故障プロファイルをどう作るか以上を踏まえ、自分のクラスタの故障プロファイルを作るときに押さえるべき点を整理する。 **測る単位を件数と GPU 時間の両方で持つ。** 件数だけを見ると、GPU 時間の 82% を消費するインフラ障害が 11% の脇役に見える([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。件数・GPU 時間・失われたノード時間の 3 系列を最初から分けて集計する。 **データ源を 4 系統そろえる。** 実証研究が共通して用いるのは、(i) 全計算ノードのシステムログから正規表現で抽出した XID エラーと回復ログ、(ii) スケジューラのジョブデータベース(開始・終了・割当ノード・終了コード)、(iii) DCGM の GPU メトリクス、(iv) RAS ログや環境センサーである([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]], [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]])。504 GPU の事例では DCGM exporter・node_exporter・all-smi・独自 exporter を 30 秒間隔でスクレイプし約 751 メトリクスを収集した([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。 **除外規則と集約規則を先に決める。** ユーザジョブ起因で GPU の健全性を示さない XID 13(General GPU Software Error)と XID 43(Reset Channel Verification Error)は除外し、バーストは短時間窓で集約する([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。この規則を決めずに集計した数値は、他クラスタの公表値と比較できない。 **事前運用期と運用期を分ける。** バスタブ曲線の infant-mortality 期を混ぜたまま平均すると、定常運用の故障率を大きく誤る。Delta では system-wide MTBE が 0.15 時間から 1.4 時間へ 10 倍改善した([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。また新規ハードウェアは infant mortality を前提とした保守的な扱いが妥当である([[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]])。 **ホスト単位の再発を追う。** 個々の障害タイミングの予測に投資する前に、ホスト別の障害履歴・再発間隔・未解決件数を蓄積する。この recurrence/recency 系の特徴量が最も情報量が大きく、除去すると AUC が 0.834 から 0.704 へ落ちる([[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]])。 **暗黙的障害を別カウントで持つ。** 明示的障害の集計だけではハング・fail-slow・SDC が漏れる。ByteDance は 3 か月で暗黙的障害 5,948 件を別枠で数え、そのうちハングが全インシデントの 9.9% を占めることを把握している([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。同期学習ではステップ時間が最も素直な一次シグナルになる([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])。 **指標を規模へ外挿する式に落とす。** ノード障害率 `rf` を実測し、`MTTF ≈ (Nnodes rf)^-1` と `E[ETTR] ≈ 1 - Nnodes rf (u0 + Δtcp/2)` に代入すれば、目標規模で必要なチェックポイント間隔と再起動時間が逆算できる。RSC-1 全体を 16,000 GPU の単一訓練に使う仮想シナリオでは、60 分チェックポイントの ETTR は 0.7、5 分チェックポイントでは 0.93 になり、10 万 GPU 級では ETTR 0.9 のために約 2 分チェックポイントと約 2 分再起動が要る([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。この逆算結果をどう実装するかは第 IX 部が扱う。 **冗長の残量を可視化する。** 冗長機構が働いている間は劣化が見えない。HBM の row remap 件数や IB uplink の生存本数といった「残っている冗長」を定期的に棚卸ししないと、MTBI が漸減していく過程を捕まえられない([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]])。プロアクティブに検証してこの残量を測る手法は第 VIII 部で扱う。  --- ## 第 VIII 部検知と箇所特定 — 誰が遅いのか、誰が壊れているのか第 VII 部で見たとおり、大規模学習の障害は避けられない。だが「障害が起きた」ことと「どのノードのどの部品が原因か」を知ることの間には、大きな隔たりがある。この部はその隔たりを埋める技術、すなわち検知(detection)と箇所特定(localization)に絞って論じる。隔離や再起動といった復旧動作は第 IX 部に譲る。 ![[Attachments/llm-training-ch08-diagnosis.png]] *図 9. 第 VIII 部の箇所特定。局所遅延は集合通信によって全ランクの同一症状へ変わるため、ピア比較からカーネル単位へ段階的に絞り込む。*（Source: [[@2026__PPoPP__CCL-D - A High-Precision Diagnostic System for Slow and Hang Anomalies in Large-Scale Model Training]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]]） ### 8.1 問題設定 — 何を検知するのか #### 8.1.1 四つの類型学習ジョブに起きる異常は、症状の現れ方で四つに分けると整理しやすい。 **停止(hang)**。プロセスは生きているが進まない。集合通信の中で全ランクが待ち合わせたまま動かない状態が典型である。[[@2026__PPoPP__CCL-D - A High-Precision Diagnostic System for Slow and Hang Anomalies in Large-Scale Model Training]] はハングをさらに三つに割る。一部のランクが通信オペレーションを取りこぼして集合通信に参加できない Not-Entered-Hang、同一コミュニケータ内で異なる GPU が不整合なオペレーションを同時実行する Inconsistent-Hang、個々のデバイスで GPU・NIC・ドライバが壊れる Hardware-Fault である。1 年間の観測ではハングが全体の 62.1% を占め、そのうち Inconsistent-Hang が 58.9% と最多だった。 **遅延(slow)**。クラッシュしないまま速度だけが落ちる。CCL-D はこれも演算スロー(事前演算の遅延・低速なデータロード・熱制約による周波数スロットリング)、通信スロー(ネットワーク変動・輻輳)、両者の混在の三つに割り、スローのうち演算スローが 81.8% を占めると報告する。[[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] は同じ空間を「fail-stop / fail-slow」×「計算起因 / 通信起因」の 2 軸で切る。 **静かな誤り(silent)**。ジョブは正常に走り続け、損失も精度も異常を示さないまま、生成されるモデルだけが壊れる。[[@2025__OSDI__Training with Confidence - Catching Silent Errors in Deep Learning Training with Automated Proactive Checks]] が挙げる BLOOM-176B の事例では、DeepSpeed の BF16Optimizer の勾配クリッピングの不具合により LayerNorm 層の重みが GPU 間で静かに乖離し、10 日間発見されず、重みマージ時に露呈してから診断にさらに 9 日を要した。88 件の実世界事例の根本原因は、ユーザーコード 32%・フレームワーク 32%・数学演算 12%・ハードウェア/ドライバ 12%・コンパイラ 8% と多層に散る([[DLトレーニングサイレントエラー]])。 **異常終了(crash)**。プロセスが落ちる。[[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]] が Platform-X の 428 件の障害報告を分類したところ、症状の内訳は起動失敗 21.3%・訓練クラッシュ 57.5%・異常挙動 16.6%・その他 4.7% だった。 #### 8.1.2 類型ごとに難しさが違う四類型は「検知の容易さ」と「箇所特定の容易さ」が独立に変わる。crash は検知が容易で箇所特定が難しい。hang は検知自体が遅れる。PyTorch の Watchdog は 30 分のタイムアウトを待ってからしか発火しない(CCL-D)。slow は検知も箇所特定も難しく、silent は検知手段そのものが存在しない。コストの偏りも大きい。CCL-D は 1,000 基の H800 クラスタの 3 か月観察で、スロー/ハングが障害件数の 35.2% でありながら診断時間の 58.8%(70 時間)を消費したと報告する。L4 は本番 LLM プラットフォームの診断が約 90% を訓練ログに依存し、平均診断時間 34.7 時間・41.9% が 24 時間超、障害 1 件あたりのログが平均 16.92GB に達すると述べる。 [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]] はさらに、遅延を fail-slow(突発的・検知しやすい・ハードウェアの過渡障害)と性能回帰(持続的・検知しにくい・ソフトウェアや設定のドリフト起因)に二分し、後者を主眼に据える。6,000 GPU クラスタの 3 か月・3,047 ジョブで、エラー 127 件に対しスローダウン 135 件(うち性能回帰 78・fail-slow 57)を観測した。「突発は目立つから見つかる、持続は目立たないから見つからない」という非対称は、この部を通じて繰り返し現れる。 ### 8.2 同期構造ゆえの「犯人隠し」箇所特定を難しくする中核は、同期学習の構造そのものにある。各ステップで全ランクが集合通信のバリアで待ち合わせるため、1 台の異常が全ノードに同じ症状として現れる。 [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]] はこれを最も明快に言語化する。訓練では単一点の障害がタスク全体のクラッシュとして現れ、多数のホストが同時に同じ CCL タイムアウトを報告する。一般的なクラウドなら送信元と宛先の 5-tuple で箇所を絞れるが、訓練では原因が全障害タスクのエラー報告の中に埋もれる。汎用のデータセンターネットワーク診断ツールを持ち込むと、大量の二次エラーが根本原因を覆い隠して偽陽性が多発する。伝播は速い。[[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] は、集合通信オペレーションが停止するとランク群・ネストした通信グループを次々にブロックし、異常が数百ミリ秒以内にクラスタ全体へ広がると述べる。粒度の問題も絡む。Pulse は、オペレータ単位(OP-level)の監視ではストラグラーと正常ランクが同一の実行時間を示してしまうと指摘する。遅延は通信オペレータ内部の送信ギャップとして現れるが、そのギャップは 32 マイクロ秒の粒度では見えても 1 ミリ秒の粒度では消える。介入度をいくら下げても粒度の問題は解けない。さらに厄介なマスキングもある。[[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]] のケース 3 では、パイプライン並列のランク 3760 の逆伝播計算が正常ランクの約 1.9 倍に達しながら自動検知が失敗した。遅いランクのボトルネックがパイプライン依存を通じて他ランクのアイドル時間として分散する「バブル転送」と、後続の勾配同期バリアが全ランクの合計時間を揃えてしまう「アライメント効果」の二つが働くためである。ケース 5(12,960 GPU の MoE 学習)では、アウトオブバンド監視が「サーバーポートダウン」を報告してネットワーク修理が計画されたが、ARGUS は計算専用オペレータのみの異常(通信は正常)を示し、ノード交換で即時復旧した。通信層のアラートが必ずしも通信起因でないことを本番規模で実証した事例である([[ストラグラー]])。 ### 8.3 信号源で分類する検知手法は「何を見るか」で分岐する。同じ現象を別の観測面から捉えるため、多くは排他ではなく補完関係にある([[LLM学習モニタリング]])。 **ホストメトリクスの統計**。[[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] は 3D 並列で計算・通信・ストレージ負荷が均等化される性質を逆手に取る。正常時は全マシンのメトリクスが秒単位で類似するので、類似性から逸脱した 1 台を故障候補とみなす。 **通信依存グラフ**。Mycroft は NCCL を 1,100 行で計装し、フロー単位・チャンク単位の進行状態を内側から露出させる。CCL-D は Send/Recv というプリミティブに着目し、SendCount/RecvCount/SendRate/RecvRate の 4 指標でハードウェアトポロジ・通信プロトコル・CCL 実装に依存しない診断を組む。 **トラフィック観測**。Pulse は NIC の組み込みマイクロプロセッサ上でマイクロ秒粒度の per-QP 計測を行う。[[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] はスイッチ層の RoCE フローだけから学習タイムラインを再構築する。[[@2025__SIGCOMM__SkeletonHunter - Diagnosing and Localizing Network Failures in Containerized Large Model Training]] はコンテナ網の探索対象を「トラフィックスケルトン」の推論で絞る([[RDMAネットワーク監視]])。 **ログ**。L4 は訓練ログを Drain で構造化し、成功ジョブとの差分・ノード間の空間パターン・イテレーション間の時間パターンの三つを足場にする([[ログ解析]])。 **トレースとプロファイル**。ARGUS は Python 層・フレームワーク層・GPU ランタイム層に対応する 3 機構を独立に走らせる。[[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]] は関数の実行挙動を 3 次元ベクトルに圧縮する。XPUTimer は発行遅延分布と空白率という新しい微視指標を導入する([[分散トレーシング]]、[[GPU観測性]])。 **不変条件**。TrainCheck は正常な学習で常に成立すべき規則を自動推論し、実行時に違反を監視する([[訓練不変条件]])。 **能動検証**。[[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] はベンチマーク群を能動的に走らせて劣化を顕在化させる([[プロアクティブ検証]])。 ### 8.4 主要診断システムの比較 | システム | 対象障害 | 入力信号 | 手法 | 箇所特定粒度 | 検知時間 | オーバーヘッド | 実運用規模 | |---|---|---|---|---|---|---|---| | Minder | 停止前の劣化・故障マシン | ホストメトリクス 20 種(秒単位) | メトリクス別 LSTM-VAE によるノイズ除去 + マシン単位の類似度 + 連続性 | マシン単位 | 平均 3.6 秒 | 訓練に非介入(常駐バックエンド) | ByteDance、最大 1,500 台超/1 年以上 | | Guard | ストラグラー(グレーノード) | 学習ステップ時間を一次、DCGM とサイドカーを補助(30 秒〜1 分間隔) | ピアベース相対比較 + 多信号融合 + 時間フィルタ + 段階的緩和 | ノード単位 | 記載なし(段階的緩和で対応) | 低オーバーヘッド | Amazon、数千 GPU | | Aegis | 訓練障害 + 性能劣化 | ログ + 20 種超のメトリクス + カスタム CCL カウンタ | 手順認識型診断(起動数/要求数/完了数)+ Z-Score 相関 | デバイス単位(GPU・NIC・リンク) | 実行時診断率 77% → 約 100% | 軽量カウンタ | Alibaba Cloud、数十クラスタ/1 年以上 | | C4D | 通信異常(ハング・通信スロー) | ACCL 拡張による通信/オペレーション/トランスポートの 3 層 | BSP 同期点の到達ずれ → 通信遅延行列の行・列の偏り | 接続(slow connection) | ハング 5 分・スロー 1 分、特定 104/138 ms | 低 | Alibaba、1 万 GPU 超/30 か月以上 | | CCL-D | ハング 3 種 + スロー 3 種 | Send/Recv のカウントとレート(カーネル + ホスト) | 決定木 + P 値による演算/通信の弁別 | ランク単位 | ハング 5 分・スロー 1 分、全体 6 分以内 | CPU 0.3%/ノード、通信 0.45% 未満、学習 0.95% 以下 | Ant Group、4,000 GPU/1 年 | | Mycroft | グレイフェイラー・フェイルスロー | CCL 内部のフロー/チャンク進行 | 依存駆動の根本原因分析 + サンプリングトリガー | ランク・GPU + 障害カテゴリ | 90% を 15 秒以内に検知、60% を 20 秒以内に特定 | 臨界経路にほぼ影響なし | ByteDance、数万 GPU/6 か月以上 | | SkeletonHunter | コンテナ網の接続性障害 | エンドツーエンドのレイテンシとパケットロス | トラフィックスケルトン推論 + LOF/Z 検定 + オーバーレイ・アンダーレイ分離 | コンポーネント(6 種 19 タイプ) | 2,048 RNIC で 1 巡 25.09 秒 | CPU 約 1%・メモリ約 35MB | Alibaba Cloud、40K+ RNIC/10 か月以上 | | L4 | 訓練障害(クラッシュ等) | 訓練ログ | cross-job フィルタ + Isolation Forest + DTW と three-sigma | ノード単位(上位 k 件) | 記載なし | — | Platform-X、平均 632 アクセラレータ | | TrainCheck | 静かな誤り | API 呼び出しと変数状態のトレース | 訓練不変条件の自動推論 + 実行時検証 | 変数・API(根本原因の近傍) | 1 イテレーション以内 | 通常 2% 以下、最大 1.6 倍 | 研究評価(実世界 20 件を再現) | | XPUTimer | 性能回帰 + ハング | Python/C++ の選択計装 | 発行遅延分布(Wasserstein 距離)・空白率・稼働カーネルのレジスタ検査 | GPU 単位 | ハング特定 29.4〜309.2 秒 | 平均 0.43%、1.5MB/GPU | Ant Group、6,000 GPU/8 か月以上 | | EROICA | 性能問題(ハード・ソフト混合) | オンラインプロファイル | 差分オブザーバビリティ(β・μ・σ) | 関数 × ワーカー | 3,400 GPU で 3 分以内 | ウィンドウ中ほぼ影響なし | Alibaba Cloud、約 100,000 GPU/1.5 年 | | Pulse | fail-stop/fail-slow × 計算/通信 | NIC 上の RDMA トラフィック(32 マイクロ秒) | オペレータ分割 + 実通信時間と通信量 | マシン単位(12 中 10) | 平均約 6 秒 | 無視できる(遅延 1.52 対 1.53 マイクロ秒) | 64 基の H200 のテストベッド | | ARGUS | フェイルスロー全般 | py-spy + CUDA Event + CUPTI の 3 層 | KDE 圧縮 + Wasserstein-1 距離 + L1〜L5 の段階診断 | カーネル × ランク | L1/L2 は秒、L3 は分 | 2% 未満 | Tencent、10,000 GPU 超/6 か月以上 | | SuperBench | グレイ障害(事前) | ベンチマーク群の実測分布 | CDF 類似度クラスタリング + Cox-Time による部分集合選択 | ノード単位 | 検証 7.96 時間/ノード | 検証時間そのものがコスト | Azure、24k+ の A100/2 年以上 | ### 8.5 個別解説 — 設計判断の勘所 #### 8.5.1 均質性を武器にする — Minder Minder は「教師あり異常検知が成立しない」という認識から出発する。正常の定義がタスク依存(GPU 温度 70℃ はクロック 1350MHz では異常だが 1800MHz では正常)であり、障害種別とメトリクスも一対一に対応しない(ECC エラーは CPU か GPU の使用率のどちらかに出るが両方の保証はない)。そこで目的を「正常/異常の分類」から「責を負うマシンの特定」へ置き換える。メトリクスごとに個別の LSTM-VAE でノイズを除去し、埋め込み間のユークリッド距離の和で最も遠いマシンを候補とし、4 分間の連続性で一過性のジッタを落とす。適合率 0.904・F1 0.893、平均 3.6 秒で警報を出し、手動の逐次検査に比べて時間を 99% 短縮した。限界も明快である。マシン単位までしか降りられず、部品種別の同定は人手に残る。秒単位の粒度ゆえに高速伝播する障害(GPU 実行エラー・PCIe のダウングレード)は再現率が落ち、スイッチ再起動で 600 台中 32 台が同時に落ちるような複数同時障害では外れ値の判別が難しい。 #### 8.5.2 計算と通信の境界に計装する — Aegis と CCL-D Aegis の核心は「CCL は計算と通信の境界に位置し、主要フレームワークで独立に差し替えられる」という発見である。顧客のモデルコードに一切触れずに、通信オペレータごと・GPU ごとの起動回数・ワークリクエスト数・完了数を記録できる。計算側の障害は起動回数の同期ずれとして、通信側の障害は要求数と完了数の不一致として現れ、両者を弁別できる。実行時診断率が 77% から約 100% へ上がり、診断待ちのアイドル時間を 97% 以上、再起動回数を 84% 以上削減した。 CCL-D はこの発想をカーネル層まで降ろす。すべての集合通信は最終的に Send/Recv に分解できるという性質を使い、カーネル内で実際に発行された送受信命令数を取る。オペレーション層の起動カウントだけでは見えない、層をまたぐ挙動の乖離が見える。根本原因の特定は決定木で行う。ハングでは「全ランクが参加したか」「ハングしていないランクが存在するか」の 2 問でハング 3 種を切り分け、スローでは P = (T_max − T_min) / (T_max − T_base) を計算し、1 に近ければ演算スロー、0 に近ければ通信スロー、中間なら混在と判定する。CUDA の統合仮想アドレッシングによるゼロコピー共有メモリとホスト駆動の計測で、CPU 使用率を全規模で 0.3% に抑えた点も実装上の要である。 #### 8.5.3 依存を辿る — Mycroft Mycroft は「CCL がブラックボックスであること」を問題の本質と見る。オペレータ単位のツールは集合通信オペレータ全体の開始と終了しか記録せず、内部で止まっても状態を出せない。カーネル単位のツールは詳細を取れるがコストが高く、実際 NPKit はバス帯域を 3 分の 1 減らし、NVRx は 60 秒ごとにしか結果を出さない。Mycroft は中間の「集合通信レベル」を切り出し、フロー単位とチャンク単位で状態を追う。数万 GPU の全量トレースは扱えないので、データ並列グループあたり最低 1 ランク・最大 10 ランクをサンプルする。異常が数百ミリ秒でクラスタ全体に広がるという性質が、この粗いサンプリングを正当化する。 #### 8.5.4 スパース性を推論する — SkeletonHunter コンテナ化された学習環境では、検査すべき組み合わせが乗算的に膨れる。1 タスクで 1K × 8 × 16 = 128K のコンポーネントを 30 秒程度の学習ラウンドごとに調べるのは非現実的である。SkeletonHunter は、rail-optimized トポロジの性質から full-mesh を 87.5% 削減したうえ、事業者がテナントの並列化戦略を見られないという制約下で、RNIC のスループットのバーストサイクルを短時間フーリエ変換して階層クラスタリングし、並列化グループを推論してさらに 95% 超削減する。2,048 RNIC での 1 巡が full-mesh の 2,034.12 秒から 25.09 秒へ縮んだ。6 か月で 4,816 件の障害を適合率 98.2%・再現率 99.3% で検知し、1,302 個の問題コンポーネントを 95.7% の精度で箇所特定した。 #### 8.5.5 マクロで見えないものをマイクロで見る — XPUTimer と EROICA XPUTimer の設計思想は「fail-slow はスループットのステップ間比較で足りるが、性能回帰はマクロ指標に現れない」という二分法にある。そこで発行遅延分布(カーネルの発行時刻と GPU 実行開始時刻の差の分布)と空白率(計装外の CPU 操作と少数派カーネルが残す空白時間の割合)という微視指標を導入する。実際に、Megatron のタイマー誤有効化による不要な同期が引き起こした 2.66% という微小な回帰を捉えた。通信ハングでは、全ランクが同じ関数で止まりコールスタックで区別できないため、CUDA-GDB で稼働中の ring-allreduce カーネルのレジスタを読み、最小ステップの接続から故障 GPU を割り出す。総当たりの NCCL テストが数千 GPU で 30 分超かかるのに対し、計算量が規模に依存しない。 EROICA は「粒度」と「全体カバレッジ」の二者択一を差分オブザーバビリティで解く。生プロファイルはワーカーあたり約 3GB になるが、関数ごとにクリティカルパス占有率 β・資源利用率平均 μ・その標準偏差 σ の 3 次元に圧縮すれば約 30KB で済む。3 次元すべてが絶対時刻に依存しないため、ホスト間のクロック同期なしに比較できる。期待レンジからの距離で共通の問題(設定不備・非効率なコード)を、ピアとの差分距離で個別の問題(ハードウェア障害)を切り分ける。約 100,000 GPU で 1.5 年運用し、既存手法で解けなかった 80 件のうち 78 件(97.5%)の根本原因を特定した。 #### 8.5.6 正当性を測る — TrainCheck 既存の監視は「活動」を測るが「正当性」を測らない。TrainCheck は正常な学習で常に成立すべき規則を 5 種の関係テンプレート(分散ランク間の値の一致、イベントの包含、API の呼び出し順序、引数の一貫性、出力の制約)として表現し、少数の健全なパイプラインから自動推論する。鍵は前提条件で、「この規則がいつ適用されるか」を推論できない不変条件は「浅い」として捨てる。これが偽陽性の抑制と別パイプラインへの転用の両方を支える。実世界の 20 件のうち 18 件を根本原因の発現から 1 イテレーション以内に検知し、DeepSpeed と Accelerate から未報告のバグを 6 件発見した。63 件の正常プログラムに対する偽陽性率は 2% 以下、選択的計装のオーバーヘッドは通常 2% 以下である。 ### 8.6 ストラグラー検知 — 影響評価とノード健全性管理 #### 8.6.1 what-if 分析による影響評価 [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]] は検知とは逆向きのアプローチを取る。ストラグラーが存在しない理想タイムラインをトレースからシミュレートし、実トレースと対比してスローダウンをワーカー・オペレーション種別・パイプラインステージごとに帰属する。スローダウン比 S = T / T_ideal、資源浪費率 1 − 1/S で定量化する。結果は直観を裏切る。ByteDance の 5 か月・3,079 ジョブで、42.5% のジョブが 10% 以上のスローダウンを経験し、全 GPU 時間の 10.4% がストラグラーで失われていた。ところが最も遅い 3% のワーカーが主因となるジョブはわずか 1.7% にすぎない。支配的な根本原因はパイプラインステージ分割の不均衡(39.3% のジョブ)、シーケンス長の不均衡(21.4%、平均 S=1.34)、Python の stop-the-world ガベージコレクションだった。「遅いワーカー = 壊れたマシン」は成り立たない。緩和策も具体的で、貪欲法によるシーケンス再分配で 23.9%、計画的なガベージコレクションで 12.6% のスループット改善を得た。ただしこの結論は前提に依存する。論文自身が、通信の影響が軽微なのは専用クラスタの広帯域ネットワークが通信ボトルネックを事実上除去しているためと明言している。ネットワーク品質という前提が結論の符号を変える。 #### 8.6.2 ノード健全性管理 [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] は検知を単発の判定ではなく、健全性の継続管理として設計する。中心概念は**グレーノード**、すなわち NCCL テストや GPU バーンインといった標準ヘルスチェックを通過しながら実ワークロードでは性能が落ちており、ジョブをクラッシュさせないため数週間沈黙的に残存する状態である。2% 程度の平均速度低下でもスループットが 20〜30% 損なわれ、学習コストが 1.3〜1.5 倍に膨らむという非線形性が、fail-slow を一級の検知対象に押し上げる。設計上の判断が三つある。第一に、ハードウェアのエラーカウンタではなく**利用者から見えるステップ時間を一次シグナル**に据え、ハードウェアメトリクスを補助に回す。第二に、固定の絶対しきい値を置かず、同一役割のピアノード群を基準にした相対比較で判定する。ワークロードとハードウェアの異質性に自然に適応し、しきい値の調整負荷が消える。第三に、検知結果を 0〜1 の異常スコアに写し、深刻度に応じて 3 段階に分岐させる(10% 未満は検証保留、10〜20% は次のチェックポイントまで待って緩和、20% 以上は即座に正常プールから除外)。適用の結果、実行間のステップ時間の分散が 20% から 1% へ、平均ステップ時間が 17 秒から 10 秒へ改善し、MFU は最大 1.7 倍になった。 ### 8.7 事前検証と事後検知 — どちらに投資するか検知は必ずしも障害の後でなくてよい。障害の前に能動的に叩いて劣化を顕在化させる道がある([[プロアクティブ障害管理]])。 SuperBench はこの経路を最も体系的に扱う。Azure の A100 ではインシデント間平均時間が 17.5 時間と短く、しかも 20 回目のインシデントでは 1 回目の 719.4 時間から 151.7 時間へ縮退していた。ハードウェア冗長が段階的に失われることで「グレイ障害」が生じるという診断である([[グレイ障害]])。SuperBench は、経験累積分布関数の類似度クラスタリングで合否境界を学習する Validator と、Cox-Time 生存解析でノードのインシデント確率を予測して確率がしきい値を超えたときだけベンチマーク部分集合を貪欲に選ぶ Selector を組む。1,000 ノード・30 日のシミュレーションで、インシデント間平均時間は未検証比 22.61 倍、フルセット検証比でも 1.11 倍となり、検証時間は 92.07% 削減された。**全部検証するより選んで検証するほうが指標が良くなる**のは、検証自体がノード時間を奪うからである。事前検証は別の形でも現れる。Aegis は訓練タスクの 73% が最初の 10 分以内に失敗していた事実から、資源を顧客へ引き渡す直前に 10 分未満の納品前チェックを挟み、再起動回数を最終的に 84.6% 削減した。Guard のオフラインノードスイープは、現実的なワークロードパターンを再現して持続スループットを直接測る 1〜2 時間の検証で、2 ノード構成でも大半の通信関連の劣化を検出できたと報告する。だが事前検証だけでは足りない。Minder は SuperBench について、(a) 訓練中の漸進的な劣化は観測しづらい、(b) ハードウェア側が中心で実行時のソフトウェアエラーを逃す、(c) そもそもオフラインである、と整理し、両者を補完的と位置づける。Aegis も同様に、SuperBench は納品前検証に限られ 1 回の実行に数時間かかるため実行時障害を覆えないと述べる。事前検証は「持ち込ませない」、事後検知は「持ち込まれた後に見つける」であり、どちらか一方では閉じない。 ### 8.8 検知時間と誤検知率のトレードオフ検知を速くすれば誤検知が増える。誤検知は健全なノードを隔離するコストとして跳ね返る。この均衡点は、**緩和動作の可逆性と重さ**によって決まる。 Guard の偽陽性率は 12.4%(偽陰性率 7.8%)と高めだが、論文はこれを許容できるとする。根拠は「早期段階の緩和が軽量かつ可逆である」ことにある。裏を返せば、緩和が不可逆で高コストな構成ではこの設計は成り立たない。対極にあるのが XPUTimer である。性能回帰の候補は通知するだけで学習を強制終了しない保守的な方針を取り、113 件のうち真の回帰 9 件・偽陽性 2 件、偽陽性率 1.9% に抑えた。偽陽性の内訳(ランク間で画像解像度が不均衡なマルチモーダルジョブ、CPU 埋め込みで空白率が高い推薦モデル)は、しきい値の調整で解消したという。 L4 は逆に**再現率を適合率より優先する**設計を明示する。F1 0.873 の内訳は適合率 0.786・再現率 0.982 で、取りこぼしを避けている。検出結果が SRE による追加調査を前提とするからである。故障ノードの特定でも上位 1 件の 65.8% に対し上位 5 件で 80.5%・上位 8 件で 91.2% と、複数候補を推薦する方針を採る。同一の通信領域にある隣接ノードも外れ値のログを出しうるためである。 Aegis は誤検知のコストを別の角度から述べる。報告されるエラーがすべて致命的とは限らず、シングルビット ECC のような訂正可能なエラーは障害を引き起こさない。無差別な隔離はクラスタ利用率を毀損する。だからこそ致命的エラーの一覧を明示的に持ち、そこに該当するホストだけを直ちに隔離する。 [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]] は、Aurora(63,744 GPU)での運用から、集中型のメタデータベースに履歴と相関イベントを蓄えたうえで、頻度ベースの「マルチストライク」判定によって過剰なノードドレインを防ぐ設計を示す。修復の粒度をノードでなく GPU 単位まで下げることで、手動保守比で平均復旧時間を最大 84 倍短縮した。正確さと速さの調停を、単発の判定ではなく履歴の統計に委ねる考え方である([[Fault Localization]])。 Mycroft はしきい値の設定そのものが精度を左右すると率直に認める。ストラグラー判定を厳しくしすぎると重い処理を担うマスターランクを誤検知し、緩めると適合率が下がるため、実運用では 1 秒を閾値に落ち着けている。 ### 8.9 実運用の要点 #### 8.9.1 階層的な切り分け手順実運用では、単一の判定器ではなく手順の順序が効く。Aegis の実行時診断アルゴリズムはその典型である。(1) タスク異常を確実に招く致命的エラー(二重ビット ECC・回復不能 ECC・リンクダウン・GPU/NVLink/NIC の消失・ファンや電源のエラー・ドライバエラー・過熱)を先に識別して該当ホストを直接隔離する。(2) 分散エラーが 2 ホスト以下なら隔離して再起動する(候補集合が小さければ全隔離のほうが速い)。(3) 複数マシンにまたがる場合は送信元と宛先でクラスタリングできるか調べる。(4) パターンが不明なら構成チェックとネットワーク診断を走らせる。(5) それでも特定できなければ全ホストを隔離してオフライン診断へ回す。得られた教訓は明快である。ホスト側の致命的障害を先に潰すのが最も効率的であり、実際に分散障害の 71% はネットワークと無関係だった。 ARGUS は同じ発想を並行稼働する 5 段階として定式化する。L1(反復時間の異常ウィンドウ、秒オーダー)、L2(ストラグラーランクとボトルネックフェーズ、秒オーダー)、L3(劣化カーネル、分オーダー)が自動で走り、診断対象を数万ランクから一桁まで絞り込む。L4(実行トレースによるクリティカルパス確認)と L5(CPU コールスタックによるホスト側ストールの特定)はオンデマンドの手動である。重要なのは、ARGUS 自身がケース 3 とケース 4 で L1〜L3 の自動検知が失敗したと記録している点で、「自動レベルで確実に検知できない障害クラスには手動の深掘りが要る」という限界が設計に織り込まれている。層の切り分けには他系統のツールとの組み合わせも効く。Mycroft は能動トリガーに加えて外部の受動トリガーの接続口を持ち、py-spy による Python スタックのダンプでデータローダーやチェックポイントの停止を、PyTorch の Flight Recorder で同期の問題を特定して、問題が CCL の内か外かを絞り込む。 #### 8.9.2 検知から隔離判断まで検知結果をそのまま隔離につなぐと過剰排除を招く。Guard のノードトリアージは 5 段階のエスカレーションを踏む。(1) 隔離ノードが GPU/ネットワークのエラーを出しているか確認、(2) 出ていれば再起動とドライバの再配備、(3) 継続する場合は再プロビジョニング、(4) エラーが解消すればノードスイープへ、(5) 通過すれば正常プールへ復帰、失敗すれば交換する。経験則として、1 週間以内に 3 回トリアージに入ったノードは恒久的な不良と判定して人手の交換対象に指定する。この閉ループ全体の効果は大きく、NCCL テストとバーンインだけのベースラインに対して、平均故障間隔が 6.6 時間から 16.7 時間へ(2.5 倍)、人的介入の間隔が 5.6 時間から 0.5 時間へ(11 倍)、MFU が 5% から 17% へ(3.4 倍)改善した。一方で、未解決のまま残る判断もある。Aegis は「再起動で直るのか修理が要るのか(後者は数週間から数か月かかる)はエラー報告だけでは判別できない」と明言し、隔離後に再起動と包括的なストレステストを行う標準手順を整備したうえで、効率的な判定方法は未解決だと述べる。検知と箇所特定が自動化されても、そこから先の「どう直すか」の意思決定にはまだ空白がある。 #### 8.9.3 設計上の要点以上を運用の観点でまとめる。第一に、**単一の先行指標に賭けない**。[[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]] は 751 の Prometheus メトリクスと 10 種の XID 判定 GPU 障害の分析から、NVLink・ECC・バス障害をまたいで常に支配的な単一メトリクスは存在しないと報告する。第二に、**相対比較を軸にする**。Guard のピア群、C4D の BSP 同期点という周期性、EROICA のピアとの差分距離、ARGUS の Wasserstein-1 距離による分布比較はいずれも絶対しきい値を避ける。第三に、**検知を緩和と閉ループで結ぶ**。[[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]] は検知を隔離とタスク再開へ直結させ、エラー誘発ダウンタイムを 31.19% から 1.16% へ落とした。検知は独立した目的ではなく、復旧までの時間を決める最初の一手である([[耐障害LLM訓練]])。  --- ## 第 IX 部復旧と耐障害設計 — 壊れた後にどう戻すか第 VII 部で障害の統計を、第 VIII 部で検知の手法を見た。この部が扱うのは、障害が確定した後の話である。すなわち、どこまで巻き戻し、何を捨て、どの順序で立て直すか。復旧は単一の操作ではなく、時間を食う段階の連なりであり、設計はその各段を個別に削る作業になる。 ![[Attachments/llm-training-ch09-recovery.png]] *図 10. 第 IX 部の復旧設計。検知から定常復帰までを七段階に分解し、状態・複製・余力に応じて継続、復元、予備ノード、縮退運転を選ぶ。*（Source: [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]]） ### 9.1 復旧の時間分解 — どの段階が何秒を食うか復旧を「検知 → 判定 → 隔離 → 再スケジュール → チェックポイント読み出し → 再同期 → 定常復帰」の 7 段に分けると、実測はどの段が支配的かを教えてくれる。 **検知**。受動的な待ちに任せると、PyTorch の集合通信タイムアウト 1,800 秒がそのまま検知時間になる([[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]])。能動的なハートビートを入れると 4〜11 秒に落ち、約 99% の短縮になる。FFTrainer はクロスレイヤ信号で 6 秒([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])、ByteRobust は NIC クラッシュ・ポートフラッピングを 30 秒、GPU 高温を 10 秒で捕える([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。Unicron はプロセス終了 1.8 秒・例外伝播 0.3 秒・性能劣化を平均イテレーション時間の 3 倍で判定し、既定の 30 分タイムアウトを置き換える([[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]])。 **再スケジュールと環境再構築**。ここが見落とされやすい。Gemini の内訳では新規インスタンス確保に 4〜7 分、再起動ウォームアップに 4 分超を要し、ソフトウェア障害でも合計約 7 分、ハードウェア障害では約 12 分になる([[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]])。FFTrainer の内訳はさらに露骨で、ポッド作成 392 秒・依存関係インストール 421 秒が支配項であり、これを 7 秒・0 秒に落とすことが MTTR 削減の大半を占める([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])。 **再同期**([[集合通信]]の再確立)。2,048 GPU 規模で通信グループ初期化に 1,000 秒超を要した実測がある([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])。MegaScale は TCPStore を Redis に置換しバリアを非同期化して計算量を $O(n^2)$ から $O(n)$ に落とし、2,048 GPU で 1,047 秒を 5 秒未満、10,000 GPU 超でも 30 秒未満にした([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。FlashRecovery はランクテーブル更新を共有ファイル経由で $O(1)$ 化し、18,000 デバイスで 249 秒を 0.5 秒未満にした([[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]])。 **チェックポイント読み出し**。504 GPU(63 ノードの NVIDIA B200)の本番運用分析は、ここが分単位でなく数十分になりうることを示す。20 セッションの再起動ロード時間は平均 33 分・中央値 31 分であり、NFS の平均読み出しスループット 150.8 GB/s は最大 read 帯域 700 GB/s の 21.5% にすぎない([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。帯域は余っている。詰まっているのはキューであり、保存側の WRITE RPC は平均 2.03 秒/要求のうち 1.89 秒(93.1%)がキュー時間、読み出し側の READ RPC も 78.2 ms のうち 54.2 ms(57.0%)がキュー時間である。「回線を太くすれば速くなる」という直感がここでは外れる。 **判定と隔離**。同じ 504 GPU の運用では、224 セッションのノード除外が上位 3/63 ノードに集中し全除外の 50% 超を占めた。しかもその一部はオペレータが単一ノードセッションで意図的に隔離した結果であり、60 ノード訓練+3 予備ノードという構成では、予備の枯渇が自動リトライの成否を左右した([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。自動リトライチェーンは 12 チェーン・73 試行で成功率 33.3%、手動復旧の 12.5% の 2.7 倍であり、再試行間隔の中央値は 11 分(四分位範囲 10〜11 分)で手動より予測可能だった。段ごとの改善を積み上げると、系全体の到達点が見える。MegaScale は検知と診断を平均 10 分未満、最新チェックポイントへの追いつきを 15 分以内に収めて有効訓練時間率 90% 超を維持し([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])、ByteRobust は非生産時間を 1 件あたり最大 50 分に抑えて累積 ETTR 97% に達した([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。 ### 9.2 失われる計算の定量化 — 間隔と期待損失復旧設計の中心にあるのは、チェックポイント間隔と期待損失時間の関係である。FlashRecovery は固定訓練期間 $d$・チェックポイント間隔 $t$・期間中の障害回数 $m$・復旧オーバーヘッド $s_0$・保存時間 $k_0$ を用いて総復旧時間を次式で表す([[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]])。 $\mathcal{F}(t) = m \cdot \left(s_0 + \frac{t}{2}\right) + \frac{d}{t} \cdot k_0$ 巻き戻しによる再計算は平均して間隔の半分($t/2$)だから、間隔を伸ばせば保存 I/O は減り再計算は増える。$t$ について最適化すると $t^{*} = \sqrt{2dk_0/m}$、最小値 $\mathcal{F}_{min} = m \cdot s_0 + \sqrt{2dk_0m}$ が得られる。この式は改善の方向を 3 つに分解する。機器安定化で $m$ を下げる、$s_0$ をクラスタ規模から切り離して定数化する、$k_0$ を削る(チェックポイントフリーなら $k_0 = 0$)。同じ関係を有効訓練時間率(ETTR)側から見たのが Meta の研究クラスタ分析で、長時間・高優先度ジョブでは $E[\text{ETTR}] \approx 1 - N_{nodes} r_f (u_0 + \Delta t_{cp}/2)$ と近似される([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。MTTF はノード数にほぼ反比例し、1,024 GPU で 7.9 時間、16,384 GPU で 1.8 時間、131,072 GPU で 0.23 時間と予測される。この式に数字を入れると、16,000 GPU の単一訓練では 60 分チェックポイントで ETTR 0.7、5 分で 0.93 になり、10 万 GPU 級で ETTR 0.9 を狙うには約 2 分チェックポイントと約 2 分再起動が要る。[[チェックポイント]]間隔は I/O チューニングの値ではなく、ジョブ規模と障害率から逆算される設計変数である。 Gemini はこれを無駄時間の形で書く。チェックポイント時間 $t_{ckpt}$・頻度 $f$・取得時間 $t_{rtvl}$ に対し $T_{wasted} = t_{ckpt} + 1/(2f) + t_{rtvl}$、制約は $1/f \geq \max(t_{ckpt}, T_{iter})$ である([[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]])。この制約が示すとおり、頻度の理論上限は毎イテレーションであり、以後の高速チェックポイント研究はこの上限に到達することを目標にしてきた。 ### 9.3 チェックポイント設計の五つの軸 **頻度**。上の式が決める。**粒度**。ジョブ単位かプロセス単位かで再起動の巻き込み範囲が変わる。TRANSOM はプロセスレベルの状態機械で異常ノードのみを排除し、健全ノードの計算資源を残す設計を 2023 年時点で採っている([[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]])。**同期/非同期**。Acme の計測では CPU メモリ利用率が 50% 未満、GPU メモリは 75% 以上に張り付くという二極化があり、この余剰 CPU メモリへ非同期に退避することでチェックポイントオーバーヘッドを 3.6〜58.7 倍削減した([[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]])。 **階層**。GPU メモリ・ホストメモリ・ローカル SSD・共有ストレージのどこに置くか。MegaScale は 2 段階方式を採り、第 1 段で各 GPU の状態をピン留めホストメモリへ数秒で書いて訓練を継続し、第 2 段でバックグラウンドプロセスが非同期に HDFS へ転送する([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。ByteRobust はホスト CPU メモリと SSD の階層に加え、[[ZeROオプティマイザ]]系並列の通信アイドル時間を使ってシャードをピアへ P2P バックアップする([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。TRANSOM の TCE はインメモリキャッシュへ即時書き込み後に非同期永続化し、各ノードのサーバが次ノードランクへ [[RDMA]] 経由でバックアップする([[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]])。 **シャーディングと冗長除去**。ここが最も効く。データ並列度が 1 を超えると同一データ並列グループ内でモデル重みは冗長であり、分散オプティマイザを使わない構成ではオプティマイザ状態も冗長である。FFTrainer の Checkpoint Razor はこの冗長を除いて一意な状態だけを保存し、チェックポイントサイズを 1/10 以下に落とす(Adam の場合デバイスあたり $12\varphi/d$)([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])。ByteRobust は 3D 並列の各ランクが自身のテンソル/パイプライン/データ並列グループ**外**のマシンへオプティマイザ状態を退避する交差バックアップを採り、過剰排除が起きても可用性を保つ([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。保存コストの実測はこれらの効果を裏づける。TRANSOM は GPT3-175B の保存を 255 秒から 16 秒、読み出しを 171 秒から 7.8 秒に短縮した([[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]])。ByteRobust は毎イテレーション保存でもブロッキング時間を Megatron 比 99.69% 削減し、MFU 損失を 0.71% に抑える([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。FFTrainer は毎イテレーション保存でオーバーヘッド 3% 未満、MFU 損失 0.27% 以下である([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])。 ### 9.4 インメモリチェックポイントと、その耐久性の考え方保存先を共有ストレージからホスト CPU メモリへ移す発想は Gemini が体系化した。p4d.24xlarge では GPU メモリ合計 320 GB に対し CPU メモリが 1,152 GB あり、しかも GPU 間の高帯域ネットワークが使える([[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]])。問題は 2 つ、可用性と干渉である。可用性については、$N$ 台・$m$ レプリカのときレプリカをどこに置けば復旧成功確率が最大化されるかを解く。$N$ が $m$ で割り切れるならグループ配置が最適であることを証明し(Theorem 1)、割り切れない場合はリング配置を混ぜた混合戦略で上界とのギャップを $(2m-3)/\binom{N}{m}$ に抑える。$N=16$、$m=2$ のとき同時故障 2 台で復旧確率 93.3%、3 台でも 80.0%(リング戦略比 25.0% 高い)である。ここで重要なのは、インメモリチェックポイントの耐久性が「保証」ではなく「確率」で語られる点だ。同一配置グループの全マシンが同時に落ちれば共有ストレージへ退避するしかなく、その場合の無駄時間は従来手法並みに劣化する。TRANSOM の RDMA ピア間バックアップも同様に「ほぼすべてのインフラ障害は単一ノード規模の事象である」という仮定に依拠している([[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]])。FFTrainer は 2,000 ホスト(16,000 GPU)規模で 12 時間以内にメモリ内チェックポイントから復旧できる確率を 99.50% と見積もる([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])。干渉については、訓練通信のネットワーク遊休時間帯にチェックポイント通信をパイプライン化して割り込ませる。チェックポイントをチャンクに分割し、あるチャンクの GPU→CPU コピー中に次のチャンクの GPU 間通信を並行させる(Algorithm 2)。訓練開始時の 20 イテレーションでオンラインプロファイリングを行い、遊休時間帯の標準偏差はイテレーション間で 10% 未満だった。結果として 400 Gbps 環境でチェックポイント時間を最大 250 倍削減し、頻度を毎イテレーションまで上げてもイテレーション時間はチェックポイントなしとほぼ同一で、障害復旧は既存手法比 13 倍超になる([[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]])。この「訓練ネットワークの遊休帯域を保存経路に転用する」設計は、2 年後に FFTrainer がネットワーク平均利用率 1〜3% という観測から再定式化し、隣接冗長と自由チェックポイント比 $FCR = sbV/(2C) \geq 1$ という成立条件へ発展させた([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])。 ### 9.5 高速フェイルオーバー系の比較 | 方式 | チェックポイント配置 | 復旧時間(実測) | 定常オーバーヘッド | 対応する障害 | 実運用/評価規模 | |---|---|---|---|---|---| | Gemini([[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]]) | ホスト CPU メモリ(混合配置 $m$ レプリカ)+ 共有ストレージ | ソフトウェア障害約 7 分・ハードウェア障害約 12 分、取得のみなら 3 秒未満(既存比 13 倍超) | イテレーション時間ほぼ不変(遊休帯域へパイプライン化) | ソフトウェア障害/ハードウェア障害を分離処理。同一配置グループ全滅時は共有ストレージへ退避 | AWS 16×p4d.24xlarge(128 A100)、GPT-2 100B。1,000 インスタンスはシミュレーション(ETTR 約 91%) | | FlashRecovery([[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]]) | 周期チェックポイントなし($k_0=0$)。データ並列複製から集合通信で復元 | 総復旧 97〜147.5 秒(4,800 デバイスで 150 秒以内)。従来 2,031〜2,915 秒比で 93〜95% 削減 | 定期保存 I/O ゼロ。損失は最大 1 ステップ | ハードウェア障害 59.6%・ソフトウェア障害 40.4%。同一データ並列グループ同時全滅($0.001^N$)のみ非対応 | Ascend NPU 実機、32〜4,800 デバイス(10,000 基超展開) | | FFTrainer([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]]) | 隣接ワーカーの CPU メモリ(冗長除去後の一意状態のみ)、遅延バックアップで障害時のみ永続化 | MTTR 899 秒 → 26 秒(16 GPU)、994 秒 → 29 秒(128 GPU)。97% 削減 | チェックポイント 3% 未満、MFU 損失 0.27% 以下(毎イテレーション) | ノード障害全般。隣接データ並列ワーカー同時故障時は 500 イテレーション毎の非同期チェックポイントへ退避 | 128 GPU テストベッド(RTX 4090×16 サーバ)。32,768 ワーカーは負荷試験 | | Unicron([[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]]) | Gemini 方式インメモリを利用。復元は同一データ並列グループの健全ランク優先 | 検知 0.3〜5.6 秒(既定 30 分比)。遷移はクラスタ規模が増えても安定 | 監視は CPU 上のスレッドのみで GPU 負荷なし、通常時 Megatron と同等スループット | SEV1(接続断)/SEV2(異常終了・CUDA 等)/SEV3(リンクフラッピング等)の 3 段 | Alibaba Cloud 128 GPU(A800)。GPT-3 1.3B〜175B | | ReCycle([[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]]) | チェックポイント・スペア機ともに不要。データ並列ピアの機能的冗長性を利用 | 再起動そのものが発生しない(マイクロバッチを即時再ルーティング) | 障害なし時のオーバーヘッドはゼロ。障害時スループットは障害なし比 0.81〜0.85 | ノード障害。同一データ並列グループ全滅時はチェックポイント復旧が必要。[[ZeROオプティマイザ]]型データ並列には非適用 | Azure 32 GPU(A100)実機 + 最大 1,536 GPU シミュレーション | | TRANSOM([[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]]) | インメモリキャッシュ + 非同期永続化 + 次ランクへの RDMA バックアップ | 平均タスク再起動数時間 → 12 分。保存 255→16 秒、読み出し 171→7.8 秒 | チェックポイント読み書き最大 20〜27 倍高速化。GPT3-175B 訓練期間 118 日 → 85 日(28% 短縮) | ストレージ/ネットワーク/ノード/ユーザコードの 4 系統。ラック以上の同時障害は未評価 | SenseCore 512 A800 GPU 本番、GPT3-175B | | ByteRobust(参考)([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) | ホスト CPU メモリ + SSD 階層、並列グループを跨いだ交差バックアップ | ホット更新は完全再投入比 11.04 倍、ウォームスタンバイは 10.87 倍(再スケジュール比 5.36 倍)高速 | 毎イテレーション保存でブロッキング 99.69% 削減、MFU 損失 0.71% | 明示的障害 38,236 件・暗黙的障害(ハング・SDC・fail-slow)5,948 件を 3 か月で自動処理 | 9,600 GPU・3 か月本番(ETTR 最大 97%)。比較評価は 16,384 GPU | 表の読み方は 2 つある。第一に、復旧時間の桁が方式で分かれる。分単位(Gemini・TRANSOM)、秒単位(FlashRecovery・FFTrainer)、そもそも停止しない(ReCycle・CCL 層フェイルオーバー)。第二に、秒単位以下を達成した系はいずれも「同時故障が起きない」という確率的仮定の上に立っており、最後の砦としてのチェックポイントは残る。 ### 9.6 チェックポイントを使わない復旧 ReCycle は復旧資源として訓練スケジュールの余白そのものを使う([[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]])。ハイブリッド並列では同一パイプラインステージを担うデータ並列ワーカーが同一パラメータを持つ(機能的冗長性)。障害ワーカーのマイクロバッチをピアへ動的に再ルーティングすれば、パラメータの再配布なしに訓練が続く。問題は再ルーティング先が 1F1B の定常フェーズ(バブルがない区間)であることで、素朴な実装ではワーカー 1 台(8.3%)の障害でイテレーション時間が 33% 増える。ReCycle はこれを 2 つの最適化で潰す。逆伝播を入力勾配と重み勾配に分割し、ステージ間依存のない重み勾配計算をクールダウンフェーズのバブルへ押し込む。さらにオプティマイザステップをステージごとにずらし、ウォームアップのバブルまで転用する。段階効果は明瞭で、適応パイプラインのみで障害なし比 0.46、分割逆伝播で 0.75、ずらしオプティマイザで 0.81 に達する。結果として Oobleck 比 1.46 倍・Bamboo 比 1.64 倍、GPU 障害率 10% でも障害率換算スループットからの低下は 0.5〜11.5% に収まる。バブルの量も十分で、LLaMA-3 405B 構成(テンソル並列 8・パイプライン並列 16・データ並列 64)では 1 イテレーションあたり 2,880 バブルがあり、最大 30 台の同時障害を吸収できる。ただし[[ZeROオプティマイザ]]型のデータ並列はパラメータを分散保持するため機能的冗長性が消え、この手法は適用できない。 FlashRecovery は同じ冗長性を別の使い方で活かす。データ並列度 $N$ のとき各デバイスにはモデル状態の複製が $N-1$ 個ある。障害時は同一グループの健全デバイスから集合通信で復元し、オプティマイザステップ直前のバリアで位相を確定して再開ステップを一意に決める。このバリアは勾配の all-reduce に統合できるため追加遅延はほぼ生じない([[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]])。「保存しない」方向はほかに、[[べき等性]]を持つ GPU カーネルのチェックポイントを省いて耐障害システムのコストを 4% 未満にする手法もある([[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]])。 ### 9.7 弾性訓練と縮退運転 3D 並列は本来、並列軸ごとに設定を変えても同じ訓練意味論を保てる内在的な弾力性を持つ([[弾性LLM訓練]])。だが弾性の実装はスループットとの取引になる。Oobleck・Bamboo・Varuna は弾性を持つが、GPT-3 7B・64 GPU で Megatron の 60〜80% 程度のスループットしか出ない([[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]])。しかも GPU 数と実効スループットの関係は非線形かつ非単調であり、48 GPU に 8 台足して 56 GPU にすると、最適な並列設定の組合せが存在しないためにスループットが下がる場合がある。弾性設計は「最適並列設定を動的に推定する」能力を必須要件として含む。 Unicron はこの矛盾を、弾性を訓練フレームワークの内部でなくワークロードマネージャ層に置くことで回避した。Megatron の最適化をそのまま継承しつつ、外側で自己修復と再構成を行う。目標関数はクラスタ全体の加重達成集約 FLOP/s(WAF)であり、$m$ タスク × $n$ ワーカーの最適配分を動的計画法($O(mn^2)$、事前計算で $O(1)$)で解く。遷移ペナルティ項が頻繁な再構成を抑え、健全タスクへの不要な再配分を防ぐ。結果は実障害トレースで Megatron 比 1.2 倍、20 倍に増幅した高頻度障害トレースで 1.9 倍(Varuna 比 5.8 倍)の累積 WAF である。注意すべきは、通常運転では Megatron が最も効率的であり、Unicron の優位は障害頻度が上がるほど拡大する点だ。実運用で期待できる値は 1.2 倍側に近い。縮退の別の形として、ByteRobust の in-place ホット更新がある。マシン割り当てを変えない変更(コード・データの修正)は既存のポッド環境を壊さずコードを差し替え、緊急でない変更は次の障害時か既定ウィンドウ(たとえば 24 時間)にまとめて適用する([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。障害という避けられない中断を、コード更新の適用機会に転用する発想である。 ### 9.8 予備ノード戦略とその経済性予備を持つか持たないかは、耐障害設計の分水嶺である。 **持つ側**。ByteRobust は自己診断済みの予備機プールを維持し、障害が独立に起こるという観測のもと予備機数を二項分布の 99 パーセンタイルに設定する。効果は大きく、ウォームスタンバイは完全再投入比 10.87 倍・再スケジュール比 5.36 倍の高速化を達成し、理論上限からの乖離は 5.19% 以内に収まる([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。ハードウェア側から見た必要量の見積もりもある。NCSA Delta の分析では、MMU/NVLink 以外の GPU エラーはほぼ 100% ジョブ失敗につながり、99.9% のジョブ可用性には 5% のオーバープロビジョニング(1,000 ノードで月 100 万ドル超)が要る([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。 **持たない側**。ReCycle が予備を否定する根拠は費用である。予備はパイプライン並列度 × テンソル並列度の単位で必要になり、530B 訓練では 280 台のスペアが要ってコストが 11% 増える([[@2024__SOSP__ReCycle - Resilient Training of Large DNNs using Pipeline Adaptation]])。この費用を払う代わりに、既に存在する冗長性(データ並列ピア)とバブルを使う。 **足りない側**。504 GPU の運用分析は、中規模でも予備比率が復旧性を直接支配することを示す。60 ノード訓練に対し予備 3 ノード、しかも 60 ノードのギャングスケジューリング制約があるため、意図的隔離で予備が食われると自動リトライが成立しなくなる([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。[[GPUクラスタ運用]]における隠れた設計変数は障害頻度ではなく「予備ノード数 / 大規模ジョブ要求ノード数」の比率である。 ### 9.9 統合設計としての ByteRobust 個別技術を並べるだけでは 9,600 GPU・3 か月の本番は回らない。ByteRobust は制御プレーン(Robust Controller と Runtime Analyzer)とデータプレーン(各ポッドの Robust Agent が Monitor・Diagnoser・チェックポイント管理・オンデマンドトレーサを持つ)を分離し、検知から復旧までを 1 本の経路にした([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。設計哲学は明快で、正確な[[Fault Localization]]よりも迅速な隔離を優先する。起因が解けなければランタイムスタックトレースをデータ駆動でクラスタリングし、外れ値が共有する並列グループごと過剰排除する。9,600 GPU ジョブでは 1 グループ 8 マシンなので、実際に壊れているのが 1〜2 台でも 6〜7 台の偽陽性が出る。これを早期隔離の対価として許容する。経路ごとの解決率が公開されている点が実務的に貴重である。19 ジョブの経験で、リアルタイムチェックによる直接排除が 32.52%、再試行が 22.70%、コードロールバックが 9.20% を解決し、最も重い Dual-Phase Replay を要したのは 1.23% にすぎなかった。本番ジョブ別では自動障害許容による排除+再起動が密モデルで 73.1%、MoE で 56.8% を占める。単純な手法が大半を片付ける、という事実は復旧設計の投資順序を決める。同時に、この論文は限界も率直に書く。診断ツール自体が新たな障害を生むことがある(EUD が周波数ロックを解除して GPU の意図しないダウンクロックを招いた)。SDC に対する NVIDIA EUD の再現率は 70% にとどまる。障害の 11%(件数)が GPU 時間の 82% を食うという構造は、[[障害緩和]]の投資対象を件数でなく消費資源で選べという指針でもある。 ### 9.10 ネットワーク障害への耐性ネットワーク障害は「状態が壊れない障害」であり、だからこそ再起動以外の選択肢が成立する。ReCCL はスイッチ〜ホスト間の last-hop 障害が記録された障害の 12% 超を占めることを示し、CCL 層で代替経路へフェイルオーバーする([[@2026__EuroSys__Handling Network Faults in Distributed AI Training]])。技術要素は 3 つ。ソフトボンディング(single-port RNIC 前提で主系/予備系を事前設定し、PCIe スイッチ跨ぎ +1・root complex 跨ぎ +100・NUMA 跨ぎ +200 のコストで予備を選ぶ)、動的チャネル再平衡(予備 RNIC を共有して[[ストラグラー]]化したチャネルを無効化し健全チャネルへ再分配)、NVLink 経由の中継 GPU(小規模通信グループ向けに PCIe ボトルネックを回避)。この論文の核心は復旧の速さではなく、判定式にある。チェックポイント間隔 $T_{interval}$・経過時間 $t_{elapsed}$・検知時間 $T_{detect}$・フェイルオーバー時のスローダウン率 $k$ に対し、 $t_{elapsed} > \frac{T_{interval}(k-1) - T_{detect}}{k}$ を満たすときフェイルオーバーが再起動より有利になる。$k=1.5$・$T_{detect}=0$ ならチェックポイント間隔の 1/3 を過ぎていれば継続が勝つ。実測のスローダウンは 32 GPU テストベッドで $k = 1.004 \sim 1.0215$ と小さく、Llama3-405B・16k GPU のシミュレーションでは再起動比で追加 GPU 時間の中央値を 64.96%、再起動+縮退比で 80.97% 削減する。ただし利得は規模依存で、64k GPU で約 4.63%、16k GPU で約 1.25%、1k〜4k GPU では 1% 未満にとどまり、小規模では実装の複雑性が利得を上回りうる。 CCL 層で吸収する系はほかにもある。VCCL は NIC ポート障害時に受信側主導で予備 QP へ切り替え、ブレークポイント再送と組み合わせてジョブ再起動もチェックポイントも不要にし、GPU 待機時間を約 90% 削減する(24K GPU 本番運用)([[@2026__arXiv__An Efficient, Reliable and Observable Collective Communication Library in Large-scale GPU Training Clusters]])。トポロジで殺す方向もある。Alibaba HPN の非スタック型デュアル ToR は、ToR 障害を訓練停止でなく 6.25% の性能劣化に留め、8 か月の本番運用で ToR 起因の単一障害点をゼロにした([[@2024__SIGCOMM__Alibaba HPN - A Data Center Network for Large Language Model Training]])。同論文によれば、3K GPU 訓練では月 1〜2 回のクラッシュが発生し 1 回あたり最大 3 万ドルの損失になる。MegaScale はより素朴に、NCCL の再送タイムアウトと NIC の adap_retrans を調整してリンクフラッピングからの高速復旧を図る([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。層の分業が要点で、ファブリック(トポロジ冗長)・CCL(経路フェイルオーバー)・ジョブ(隔離と再起動)がそれぞれ担う障害域を明示的に切り分けておかないと、同一障害を三層が独立に処理して再送ループや帯域浪費を招く。 ### 9.11 実運用の要点 **チェックポイント間隔の決め方**。手順は 3 段である。第一に $m$(期間中の期待障害回数)を規模から見積もる。MTTF はノード数にほぼ反比例するので、1,024 GPU で 7.9 時間、16,384 GPU で 1.8 時間という参照値から自ジョブの値を引く([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。第二に $k_0$(1 回の保存にかかる実効時間)と $s_0$(検知から定常復帰までのオーバーヘッド)を実測する。ここは推定でなく計測が要る。特に共有ストレージ経由なら帯域でなくキュー時間を見る([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。第三に $t^{*} = \sqrt{2dk_0/m}$ で最適間隔を出し、ETTR 目標($1 - N_{nodes} r_f (u_0 + \Delta t_{cp}/2)$)から要求間隔を逆算して、両者の厳しい方を採る。もし要求間隔が $k_0$ より短くなったら、間隔の調整では解けない。$k_0$ そのものを削る設計(階層化・冗長除去・遊休帯域転用)へ移る必要がある。 **復旧設計のチェックリスト**。 1. 検知をタイムアウト依存から能動的ハートビートへ移したか。既定タイムアウト 1,800 秒(PyTorch)や 30 分(Megatron)が復旧時間に直乗りしていないか([[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]])。 2. 7 段のうちどこが支配項かを実測したか。ポッド作成や依存関係インストールが数百秒を占めていないか([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])。 3. 通信グループの再初期化が規模に線形増加していないか。ランクテーブル配布や TCPStore 確立を $O(1)$/$O(n)$ 化したか([[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])。 4. モデルロードと通信初期化が直列になっていないか。訓練ロールと通信ランクを分離すれば並列化できる([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])。 5. チェックポイントの冗長を除いたか。データ並列度が 1 を超えるなら保存量は原理的に $1/d$ に落とせる([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])。 6. 複製やインメモリ退避の配置が、想定する同時故障パターンと整合しているか。同一データ並列グループや同一配置グループの全滅は確率が小さいだけで零ではなく、最後の砦としての永続チェックポイントは残す([[@2023__SOSP__Gemini - Fast Failure Recovery in Distributed Training with In-Memory Checkpoints]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]])。 7. 予備ノード数を「大規模ジョブ要求ノード数」との比率で設計したか。意図的隔離が予備を食い潰す運用になっていないか([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。 8. ネットワーク障害を再起動と同列に扱っていないか。状態が壊れない障害には継続の選択肢があり、判定は閾値式で自動化できる([[@2026__EuroSys__Handling Network Faults in Distributed AI Training]])。 9. 自動リトライが構造的障害を識別して止まるか。同条件の再試行を延々と繰り返して GPU 時間を溶かす経路が塞がれているか([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。 10. 復旧経路ごとの解決率を計測しているか。単純な経路(直接排除・再試行)が大半を処理しているなら、重い診断機構への投資は後回しでよい([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。 11. 隔離の粒度を選んだか。プロセス単位(精密)・グループ単位(巻き込み許容)・ジョブ単位(単純)の三者は、精度・実装コスト・偽陽性許容度のトレードオフである([[@2023__arXiv__TRANSOM - An Efficient Fault-Tolerant System for Training LLMs]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。細粒度化は HPC 側でも有効で、Aurora(63,744 GPU)では GPU 単位の修復と頻度ベースのストライク判定で MTTR を手動比最大 84 倍短縮した([[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]])。 12. 復旧の成果を件数でなく GPU 時間・ETTR・MFU で測っているか。件数 11% の障害が GPU 時間の 82% を食う構造では、件数ベースの改善指標は誤導する([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。 [[耐障害LLM訓練]]の全体像として整理すれば、復旧の高速化は「速く保存する/予備機で待たない/そもそも保存しない/複製で保存を不要化する/そもそも停止しない」の五系統に分岐する([[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]])。どれを採るかは規模と並列設定に依存し、単一の正解はない。ただし全系統に共通する前提が一つある——最後の砦としてのチェックポイントは、頻度を下げられても消せない。  --- ## 第 X 部事後学習と強化学習のインフラ — 事前学習とは別の運用問題 ![[Attachments/llm-training-ch10-rl-loop.png]] *図 11. 第 X 部の RL 学習ループ。生成 GPU、報酬用 CPU サンドボックス、更新 GPU の異種資源を接続し、同期実行の長尾待ちと非同期実行の方策ラグを対比する。*（Source: [[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]], [[@2025__arXiv__Training Long-Context Multi-Turn SWE Agents with Reinforcement Learning]]） ### 10.1 なぜ事後学習は別の運用問題になるのか事前学習のインフラは、均質な並列ワーカー群が同一のデータ並列ループを回す構造をしている。設計軸は Scalability・Efficiency・Reliability の三つに整理され、障害探索は「均質な並列ワーカー群から外れた GPU・ノード・通信を探す」問題に帰着する([[LLM分散学習]]、[[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])。規模が上がるほど平均故障間隔は GPU 数にほぼ反比例し、10 万 GPU 級では分単位の復旧要件になる([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。事後学習、とりわけ[[強化ファインチューニング]]は、この構造をそのまま持ち込めない。RFT の訓練システムでは、ロールアウト生成・報酬計算・参照制約付き方策更新・価値推定・(場合により)ツールや環境との相互作用が密結合し、報酬軌跡・KL ダイバージェンス・エントロピー・return・応答長・方策損失といった中間信号を外部に露出する。この密結合ゆえに RFT は SFT よりはるかに脆く、報酬設計の誤り・不安定な方策更新・誤った信用割当・破損した相互作用フィードバックが訓練全体に伝播して最適化を歪める([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]])。形式面でも断絶がある。選好ベースの事後学習(PBRFT)はホライズン T=1・決定論的遷移・単一スカラー報酬という退化 MDP だが、[[エージェント型強化学習]]は T>1・確率的遷移・ステップごと報酬の POMDP として定式化される([[@2025__arXiv__The Landscape of Agentic Reinforcement Learning]])。運用上の帰結は明快で、後者では「1 件の学習サンプル」が外部環境との数十ターンの対話になり、所要時間も成否も事前に決まらない。 #### 事前学習と事後学習(RL)のインフラ要件比較 | 観点 | 事前学習 | 事後学習(RL) | |---|---|---| | 計算パターン | 単一の順伝播・逆伝播ループ | 生成・報酬計算・方策更新の三段が相互依存する複合ループ([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]]) | | 実行エンジン | 訓練フレームワーク単独 | 推論エンジン(vLLM・SGLang)と訓練フレームワーク(DeepSpeed・FSDP・Megatron-LM)を単一ループに結合する必要がある([[@2025__arXiv__Agent-R1 - Training Agents with End-to-End RL]]) | | 同期構造 | 反復ごとの全体同期 | 同期実行はストラグラーに支配され、非同期化は方策ラグを持ち込む([[@2025__arXiv__Training Long-Context Multi-Turn SWE Agents with Reinforcement Learning]]、[[@2025__arXiv__AgentRL - Training Language Model Agents with Reinforcement Learning]]) | | 資源の異種性 | GPU が支配的 | GPU に加えてサンドボックス実行の CPU・コンテナ・外部 API が一次資源になる(DeepSWE は 1 イテレーションあたり 512 コンテナを 1,000 超の CPU コアで管理)([[@2025__Together AI__DeepSWE - Training a Fully Open-sourced State-of-the-Art Coding Agent by Scaling RL]]) | | 資源配分の自由度 | 並列化戦略とバッチ | 問題バッチ $B_p$・並列ロールアウト数 $n$・更新ステップ数 $M$ の三軸配分が加わる([[@2026__arXiv__IsoCompute Playbook - Optimally Scaling Sampling Compute for LLM Reinforcement Learning]]) | | 障害の性質 | ハードウェア故障・通信障害・ストラグラー([[LLM分散学習]]) | 最適化ダイナミクスの障害。報酬・方策生成・最適化ダイナミクス・信用割当・ツール/環境の 5 ファミリ 16 種別に分類されている([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]]) | | 一次テレメトリ | インフラメトリクス・通信ログ | 報酬軌跡・KL・エントロピー・return・応答長・ツール/環境フィードバック(同上) | | ボトルネック | 通信とメモリ帯域 | 生成側のサンプリング計算と、長尾ロールアウトの待ち時間([[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]]) | | 進行の健全性判定 | 損失曲線 | 損失に相当する単一指標がない。訓練セット報酬は検証セット精度と相関が乏しい([[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]]) | DAPO の著者らは、大規模 LLM の RL 訓練を「相互依存する複数サブシステムからなる本質的に複雑なシステムエンジニアリング課題」と明示的に位置づけている([[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]])。この一文が、本部の前提そのものである。 ### 10.2 RL 学習ループの構成要素 #### 生成・報酬・更新の三段分離実装は例外なく段の分離に向かう。DeepSeek-R1 の RL インフラは、ロールアウト(vLLM ワーカー + エキスパート並列 + MTP 自己投機デコーディング)、推論(報酬モデル・参照モデル)、規則ベース報酬(非同期スケジューリング)、訓練(データパッキング + DualPipe パイプライン並列)の 4 モジュールに分離され、各モジュール完了時に VRAM を自動オフロードする([[@2025__arXiv__DeepSeek-R1 - Incentivizing Reasoning Capability in LLMs via Reinforcement Learning]])。ScaleRL は GB200 を 80 ノード使い、生成に 64・訓練に 16 と物理的に割り当てを分ける([[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]])。資源を分けるか時分割するかは設計上の分岐点である。Kimi K1.5 は Kubernetes の Sidecar コンテナで Megatron-LM と vLLM を同一 Pod に配置し、全 GPU を訓練と推論で時分割共有する。切り替えは訓練から推論が 1 分未満、推論から訓練が約 10 秒であり、重み転送はチェックポイントエンジンが Mooncake 経由の RDMA で担い、グローバル状態は etcd で同期する([[@2025__arXiv__Kimi K1.5 - Scaling Reinforcement Learning with LLMs]])。 #### 報酬計算は独立したサービスである報酬計算はしばしば GPU 外に出る。Scaling Up RL は報酬計算をサンドボックス化したサーバに分離し、コード実行を訓練プロセスから隔離して安全性と耐障害性を確保したうえで、訓練クラスタ全体に分散した報酬サーバで並列評価する。さらに、応答が完了しだい報酬を必要としない GPU 側の計算($\pi_\theta(\tau)$・$\pi_{old}(\tau)$)と並行して報酬計算を起動する非同期オーバーラップを採る([[@2025__arXiv__Scaling Up RL - Unlocking Diverse Reasoning in LLMs via Prolonged Training]])。Kimi K1.5 のコードサンドボックスは crun(Docker 比 3 倍速のコンテナ起動)・cgroup 再利用・tmpfs オーバーレイで最適化されている([[@2025__arXiv__Kimi K1.5 - Scaling Reinforcement Learning with LLMs]])。検証のタイムアウトはそのまま計算予算になる。DeepSWE はテストが 5 分以内に通れば +1、失敗またはタイムアウトで 0 とし、生成時タイムアウトは 20 分に設定する([[@2025__Together AI__DeepSWE - Training a Fully Open-sourced State-of-the-Art Coding Agent by Scaling RL]])。Scaling Up RL のコード報酬はコンパイル失敗・構文エラー・5 秒タイムアウト超過を報酬 0 とする([[@2025__arXiv__Scaling Up RL - Unlocking Diverse Reasoning in LLMs via Prolonged Training]])。 #### 同期実行と非同期実行同期パイプラインは実装が単純で、131K トークン・最大 80 ターンという長コンテキストのマルチターン RL を 16 ノード × 8 H200 GPU で完走させた実績がある。ただし最遅軌跡がボトルネックになるストラグラー問題を抱え、非同期化はスケーラビリティを改善しうるが方策ラグのリスクを伴う([[@2025__arXiv__Training Long-Context Multi-Turn SWE Agents with Reinforcement Learning]])。非同期側の実測値は明確である。AgentRL はロールアウトと訓練を独立資源グループで非同期実行し、コルーチンスケジューリングで GPU スロットを埋めることで、14B モデルの Webshop タスクで同期比 1.7〜1.9 倍のスループットを得た。オフポリシーの偏りはデータキューの最大サイズ上限で抑える([[@2025__arXiv__AgentRL - Training Language Model Agents with Reinforcement Learning]])。ScaleRL は PipelineRL-8 を採用し、非同期化が計算効率 B を大きく改善しつつ漸近性能 A も向上させたと報告する([[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]])。逆に Agent-R1 は非同期ロールアウトに未対応であることを自ら限界として挙げ、遅いツール・分岐ワークフロー・永続環境ではロールアウトがボトルネックになると述べる([[@2025__arXiv__Agent-R1 - Training Agents with End-to-End RL]])。 ### 10.3 生成側の資源配分 — サンプリング計算の配分問題エージェント型 RL では、データ生成コストの中心がシミュレータ操作ではなくモデル自身のサンプリング計算にある([[エージェント型強化学習]])。IsoCompute Playbook は総サンプリング計算を $C = B_p \cdot n \cdot M$ と定義し、約 120,000 H200 GPU 時間の掃引でその配分則を導いた([[@2026__arXiv__IsoCompute Playbook - Optimally Scaling Sampling Compute for LLM Reinforcement Learning]])。 | 軸 | 挙動 | 運用上の含意 | |---|---|---| | 並列ロールアウト数 $n$ | 計算最適値が $C$ とともにシグモイド的に増加し飽和。Easy は $n=512$、Hard は $n=128$ で飽和 | 最も性能を左右する軸。$n^*(C)$ カーブから先に決める | | 問題バッチサイズ $B_p$ | 安定性のノブ。Easy では検証報酬への影響が 1.9% にとどまり、$n$ の 9.2% より弱い(Hard は 2.2% 対 3.1%) | 安定に回る最小値でよい | | 更新ステップ数 $M$ | 残余として配分 | 最後に決める | $n$ を増やす効果は問題難易度で機構が違う。容易な問題では worst@k が改善する(シャープニング)のに対し、困難な問題では best@k が改善する(カバレッジ拡張)。表形式の理論が $M$ 優先を予測するのに対し実証は $n$ 優先を支持し、その乖離は問題間干渉——LLM 固有で、タブラー設定には現れない現象——で説明される。$n$ の増加は更新を問題間により均一に分配して干渉を緩和する。なお、ベースライン推定の分散削減は $n$ 増加の主効果ではないことが分離実験で確認されている(同上)。この配分則は訓練が安定していることを前提とする。同論文は「健全なレシピ」の三条件として、問題難易度の制御(Easy は avg@16 が 0.3〜0.6 の 6k 件、Hard は 0〜0.0625 の 5k 件)、正則化の使い分け(Easy はエントロピー正則化 + KL 正則化、Hard は双方除去)、有効バッチサイズに対する学習率の平方根スケーリング $\eta \propto \sqrt{B}$ を挙げる(同上)。 ### 10.4 長時間・多ターンのエージェント学習に固有の運用問題 #### 環境が外部依存になる Kimi-Researcher が挙げる 4 課題は、そのまま運用課題の一覧になっている——同一クエリでも検索結果が時間とともに変わる動的環境、1 軌跡あたり 70 以上の検索クエリと数十万トークンに及ぶ長期ホライズン、エージェント型 QA の高品質データ希少性、そしてマルチターン推論とツール利用による訓練速度低下と GPU 低稼働率である。対策として、Kubernetes ベースのハイブリッドクラウド上にゼロダウンタイムスケジューリングの統一サンドボックス環境を置き、エージェントとツールの通信を [[Model Context Protocol]] のステートフル接続(再接続機能付き)で行い、マルチレプリカ配置で耐障害運用する([[@2025__Moonshot AI__Kimi-Researcher - End-to-End RL Training for Emerging Agentic Capabilities]])。 AgentRL は同じ問題にタスクごとの隔離コンテナと集中コントローラで応じる。コントローラは数千の並列訓練エピソードのライフサイクルを管理し、ノンブロッキングなディスパッチとタイムアウト駆動の障害検知・自己修復を持つ。行動形式は OpenAI Function Call Format に統一し、独自形式を排する([[@2025__arXiv__AgentRL - Training Language Model Agents with Reinforcement Learning]])。RFT-FM の障害分類でツール呼び出しエラー・観測破損・終了エラーが独立したファミリとして立っているのは、この外部依存が障害面として一級市民であることの裏返しである([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]])。 #### ロールアウト長のばらつきとストラグラー化生成時間は長尾サンプルに支配される([[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]])。対処は大きく三系統ある。第一に、長い軌跡を分割して再利用する。Kimi K1.5 のパーシャルロールアウトは長い軌跡を固定トークン予算で分割し、前回の軌跡の大部分を再利用して新しいサンプリングを行う。非同期ロールアウトワーカーにより、長い軌跡が一部のワーカーを占有しても他のワーカーが短い軌跡を処理でき、計算資源の遊休を防ぐ([[@2025__arXiv__Kimi K1.5 - Scaling Reinforcement Learning with LLMs]])。Kimi-Researcher のターンレベル部分ロールアウトは、時間バジェットを超過したタスクをリプレイバッファに保存し、後続イテレーションで更新済み重みで残りターンを実行することで 1.5 倍以上の高速化を得る([[@2025__Moonshot AI__Kimi-Researcher - End-to-End RL Training for Emerging Agentic Capabilities]])。第二に、不完全な軌跡を学習信号から除く。DeepSWE の Compact Filtering は、最大コンテキスト長到達・生成時タイムアウト・最大ステップ到達の軌跡に損失マスクをかける([[@2025__Together AI__DeepSWE - Training a Fully Open-sourced State-of-the-Art Coding Agent by Scaling RL]])。DAPO は打ち切りサンプルの損失をマスクする Overlong Filtering だけで naive GRPO から AIME24 avg@32 を 30 点から 36 点へ引き上げ、さらに最大長 16,384 トークンの手前に 4,096 トークンの罰則区間を設ける Soft Overlong Punishment を加えた([[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]])。第三に、除きすぎない。コンテキスト長を超えた軌跡を一律に除外すると、反復ループに陥る失敗パターンの負例まで消えてしまい、結果としてループ行動を学習しやすくなる([[@2025__arXiv__Training Long-Context Multi-Turn SWE Agents with Reinforcement Learning]])。ノイズ除去と負例保存のバランスが要る。 #### コンテキスト管理は効率でなく品質の問題である記憶管理のないエージェントは 10 イテレーション以内でコンテキスト上限に達する。Kimi-Researcher は重要情報を保持し不要文書を破棄する機構で単一ロールアウト軌跡を 50 イテレーション超に拡張し、コンテキスト管理ありのモデルが 30% 多いイテレーションを使ってより高い性能に達したと報告する([[@2025__Moonshot AI__Kimi-Researcher - End-to-End RL Training for Emerging Agentic Capabilities]])。Agent-R1 の制御実験(GSM8K + GRPO)ではスライディングウィンドウが最良で、追記のみは弱く、LLM 要約は小規模モデル設定で最も劣った([[@2025__arXiv__Agent-R1 - Training Agents with End-to-End RL]])。 #### サンプリング分布と訓練分布の一致見落とされやすい落とし穴がある。訓練途中で vLLM をアップグレードした際に top-k / min-p フィルタが暗黙に有効化され、ロールアウト分布 $\pi_{\text{rollout}}$ が真の方策 $\pi_{\theta_{old}}$ と乖離した結果、重要度サンプリング比が不正確になり 5〜10 反復後に性能が劣化した。無偏サンプリングに戻すことで回復している([[@2025__arXiv__Training Long-Context Multi-Turn SWE Agents with Reinforcement Learning]])。Kimi-Researcher が「ツール呼び出しフォーマットの強制器などの LLM エンジン機構を訓練時に無効化し、各軌跡がモデル自身の確率分布のみから生成されることを保証する」と明記しているのは、同じ問題への予防的設計である([[@2025__Moonshot AI__Kimi-Researcher - End-to-End RL Training for Emerging Agentic Capabilities]])。推論エンジンのバージョンとデコーディングパラメータは、この文脈では設定ではなく学習アルゴリズムの一部だと見るべきである。 ### 10.5 RL のスケーリング挙動 — 計算量を増やすと何が改善するか | 軸 | モデル化・知見 | 出典 | |---|---|---| | RL 計算量 $C$(有界指標) | $R_C - R_0 = (A - R_0)/(1 + (C_{mid}/C)^B)$。漸近性能 A と計算効率 B に分離でき、50k GPU 時間までのフィットで 100k を外挿できる | [[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]] | | 計算量・データ量(損失) | $\log L(N,X) = -k(N)\log X + E(N)$、$k(N)=K_{max}/(1+N_0/N)$。R² > 0.99、32B 超で学習効率の増加率が鈍化 | [[@2025__arXiv__Scaling Behaviors of LLM Reinforcement Learning Post-Training]] | | サンプリング配分 | $n^*(C)$ がシグモイド的に増加し飽和 | [[@2026__arXiv__IsoCompute Playbook - Optimally Scaling Sampling Compute for LLM Reinforcement Learning]] | | コンテキスト長 | 応答長と性能に正の線形相関(傾き 2.46e-05〜4.24e-05)。生成長 14k→32k で A が 0.61→0.645 に上がるが B は低下 | [[@2025__arXiv__Kimi K1.5 - Scaling Reinforcement Learning with LLMs]]、[[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]] | | 事前学習との配分 | 総計算量が増えるほど最適 RL 計算比率が増加(50M で約 20%、680M で約 28%)。事前学習トークン配分は Chinchilla 則から系統的には逸脱しない | [[@2026__arXiv__Understanding Reasoning from Pretraining to Post-Training]] | | ベースモデル規模 | 7B dense・16B MoE では AIME 改善が観察されず、32B dense 以上(230B MoE 以上)で純粋 RL が有効になる | [[@2025__arXiv__DeepSeek-R1 - Incentivizing Reasoning Capability in LLMs via Reinforcement Learning]] | | データ再利用 | 再利用係数 τ ≤ 25 では最終テスト損失がほぼ不感、τ = 100 で過学習の兆候 | [[@2025__arXiv__Scaling Behaviors of LLM Reinforcement Learning Post-Training]] | インフラ設計に直結する含意は二つある。ひとつは「少計算での優位は大計算での優位を保証しない」という苦い教訓であり、小規模評価だけでレシピを選ぶと大規模で逆転する([[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]])。もうひとつは、改善が「どこに効くか」の区別である。損失集約・アドバンテージ正規化・カリキュラムは主に計算効率 B を変調し、損失関数・FP32 精度修正・オフポリシー方式は漸近性能 A を動かす。ScaleRL の FP32 精度修正(LM ヘッドの FP32 計算)は A を 0.52 から 0.61 へ改善した(同上)。 RL が何を改善するかにも非対称がある。RL は pass@1 を直接改善する一方 pass@k は事前学習規模により敏感で、方策変化は難易度に応じて正解の増幅・テールの発見・誤ったモードの増幅の三類型に分かれる。易しい問題では正解の増幅が支配的(約 0.8)だが、最難ビンでは誤ったモードの増幅が 0.18〜0.20 に達する([[@2026__arXiv__Understanding Reasoning from Pretraining to Post-Training]])。サーベイの整理では、約 2/3 の研究が pass@1 改善に、約 1/3 が pass@k フロンティア拡張に分類される([[@2025__arXiv__The Landscape of Agentic Reinforcement Learning]])。 ### 10.6 主要な公開システムとレシピ | システム | 規模・計算資源 | インフラ上の特徴 | 主要結果 | |---|---|---|---| | DeepSeek-R1 | 671B MoE、64×8 H800。R1-Zero 約 198 時間 + R1 約 80 時間、総コスト約 $294K | 4 モジュール分離 + VRAM 自動オフロード、規則ベース報酬の非同期スケジューリング | AIME 2024 pass@1 79.8、MATH-500 97.3 | | DAPO | Qwen2.5-32B、verl | Clip-Higher・Dynamic Sampling・Token-Level Loss・Overlong Reward Shaping | AIME24 avg@32 が 30 → 50、DeepSeek-R1-Zero-Qwen-32B(47)を半分のステップで超過 | | Kimi K1.5 | 非公開(GPU 数・GPU 時間とも未報告) | 訓練/推論の時分割共有、パーシャルロールアウト、crun サンドボックス | AIME 77.5、MATH-500 96.2 | | Kimi-Researcher | 非公開 | 完全非同期ロールアウト、ターンレベル部分ロールアウト、MCP + マルチレプリカ | HLE Pass@1 8.6% → 26.9% | | DeepSWE | Qwen3-32B、64 H100 × 6 日、R2E-Gym 4,500 問 | rLLM + Kubernetes で 512 コンテナ/イテレーション、1,000 超 CPU コア | SWE-Bench-Verified Pass@1 42.2%、ハイブリッド Best@16 59.0% | | Golubev+ | Qwen2.5-72B、16 ノード × 8 H200 | 同期 RL パイプライン、コンテキスト並列で 131K 全パラメータ訓練 | SWE-bench Verified 11% → 39% | | AgentRL | Qwen2.5 系 3B〜32B、H800 最小 16 基 | 完全非同期 + コンテナ化環境 + 集中コントローラ、SGLang + FSDP | 5 タスク平均成功率 70.4%(32B) | | Agent-R1 | Qwen3-4B | ステップレベル MDP による軌跡表現とコンテキスト管理の明示化 | GRPO で GSM8K 83.3%・ALFWorld Unseen 74.58% | | Scaling Up RL | 1.5B、4 ノード × 8 H100、約 16,000 GPU 時間 | サンドボックス報酬サーバ、8 ラン逐次訓練 + ハードリセット | 論理パズル +54.8%、数学 +14.7% | | ScaleRL | 8B dense / Llama-4 Scout MoE、GB200 80 ノード、400,000 GPU 時間超 | PipelineRL-8 非同期、CISPO、FP32 精度修正、ゼロ分散フィルタリング | 8B で A = 0.61(GRPO 0.45、DAPO 0.53) | DAPO は naive GRPO の失敗(AIME 30 点)を、エントロピー崩壊・報酬ノイズ・勾配消失という異なる層の障害に分解し、それぞれに対応する技術を積み上げた点で運用寄りの読み方ができる。Dynamic Sampling は正答率が 0 か 1 のプロンプトを除いてバッチを埋め直すため追加サンプリングを要するが、生成時間が長尾サンプルに支配されるため訓練効率への影響は限定的で、収束に必要なステップ数が減ることでむしろ収束時間は短縮した([[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]])。 AgentRL と Agent-R1 は同じマルチターン問題への対照的な解になっている。前者はインフラ側(非同期化・コンテナ隔離・タスクアドバンテージ正規化)で、後者は表現側(ステップレベル MDP による再トークン化ドリフトの排除、コンテキスト構成規則の明示化)で応じる。AgentRL のアブレーションでは、タスクアドバンテージ正規化の除去が平均成功率を 65.0 から 59.4 へ、交差方策サンプリングの除去が 60.7 へ下げた([[@2025__arXiv__AgentRL - Training Language Model Agents with Reinforcement Learning]])。Agent-R1 は最適アルゴリズムがタスク依存であること(GRPO が算術・検索・具現化で最良、PPO がショッピングで最強)も示す([[@2025__arXiv__Agent-R1 - Training Agents with End-to-End RL]])。 ### 10.7 検証可能報酬が資源配分に与える影響 [[検証可能報酬による強化学習]]の採用は、アルゴリズム選択であると同時にインフラ設計の選択である。DeepSeek-R1 は正確性報酬とフォーマット報酬の規則ベース報酬のみを使い、ニューラル報酬モデルは大規模 RL で報酬ハッキングに脆弱かつ再学習コストが高いとして意図的に排除した([[@2025__arXiv__DeepSeek-R1 - Incentivizing Reasoning Capability in LLMs via Reinforcement Learning]])。DAPO も同じ理由で $R(\hat y, y) = 1$(正解時)/ $-1$(それ以外)という二値報酬を採る([[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]])。対比すべきは[[人間フィードバックからの強化学習]]の構成である。InstructGPT は SFT → 報酬モデル学習 → PPO の 3 段構成を採り、報酬モデルは 175B では訓練不安定かつ計算コストが高いため 6B を採用している([[@2022__NeurIPS__Training language models to follow instructions with human feedback]])。資源配分の観点では、RLVR はこの報酬モデル用 GPU を丸ごと不要にする代わりに、検証器を動かすためのサンドボックス・コンテナ・CPU コアを一次資源へ昇格させる。DeepSWE の 512 コンテナ・1,000 超 CPU コアという構成([[@2025__Together AI__DeepSWE - Training a Fully Open-sourced State-of-the-Art Coding Agent by Scaling RL]])と、Scaling Up RL の分散報酬サーバ([[@2025__arXiv__Scaling Up RL - Unlocking Diverse Reasoning in LLMs via Prolonged Training]])は、その帰結である。さらに、検証可能性はデータ側の前処理コストにも跳ね返る。DAPO は数式・分数・根号を含む多様な形式の数学解答をルールベース報酬でパースできる整数解へ LLM 自身に書き換えさせ、DAPO-Math-17K を構築した([[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]])。検証可能性は所与ではなく、作り出す対象である。ただし規則ベース報酬とLLM ベース判定は堅牢である一方、オープンエンド生成や長文作文のような主観的タスクには適用困難であり、DeepSeek-R1 も汎用段では有用性・安全性の報酬モデルを併用し、報酬ハッキングを避けるため選好報酬の投入を最後の 400 ステップに限定している([[@2025__arXiv__DeepSeek-R1 - Incentivizing Reasoning Capability in LLMs via Reinforcement Learning]])。 ### 10.8 事後学習における自動障害管理 RFT-FaultBench は、RFT の障害を訓練プロセスレベルで扱う初のベンチマークであり、5 障害ファミリ・16 障害種別・779 ラン・22,549 の train-step 記録・1,457,288 の軌跡レベル記録から成る([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]])。 | 障害ファミリ | 障害種別 | |---|---| | 報酬(RF) | 報酬スパイク / 報酬崩壊 / [[報酬ハッキング]] | | 方策生成(PG) | 空応答 / 反復崩壊 / 応答長の過短 / 応答長の過長 | | 最適化ダイナミクス(OD) | KL 爆発 / 更新凍結 / [[エントロピー崩壊]] | | 信用割当(CA) | 価値の不一致 / アドバンテージ不安定 / 遅延信用 | | ツール・環境(TE) | ツール呼び出しエラー / 観測破損 / 終了エラー | 同論文の実験から、運用上重要な三点が読み取れる。第一に、RFT の異常検知は絶対量ではなく相対的である。健全ランから較正した正常プロファイルを外すと検知 F1 が 21.23%(easy)/2.21%(hard)まで崩壊する。第二に、障害は大きさではなく形で区別される。KL 爆発は KL と応答長の双方に強いピークを持ち最も識別的である一方、信用割当系は粗いテレメトリでは健全ランに近く、検知・診断とも全手法で最難である(easy でも 53.17%)。第三に、自動修復はまだ危うい。緩和率は 46.25% に達するが、severity 変化の中央値は −5.84% であり、失敗した介入が訓練を大きく悪化させうる(同上)。現場の運用も、この評価と整合する。DAPO は生成応答長・報酬の推移・アクターのエントロピーと生成確率を健全性判断に用いつつ、応答長は単調増加とは限らず停滞・減少期間も観測されるため検証精度と併用すると述べる([[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]])。Scaling Up RL は 8 ランの逐次訓練で KL・エントロピー・応答長・検証スコアを監視し、劣化やプラトー時に参照方策とオプティマイザ状態のハードリセットを入れるが、リセットのタイミングとハイパーパラメータ調整は手動介入に依存しており自動化されたカリキュラムではないと明記する([[@2025__arXiv__Scaling Up RL - Unlocking Diverse Reasoning in LLMs via Prolonged Training]])。自動障害管理は、この手動介入を置き換えるための研究段階の取り組みだと位置づけるのが正確である。 ### 10.9 実運用の要点 #### 最初に用意すべき可観測性 | 信号 | 見るべき点 | 根拠 | |---|---|---| | 報酬(訓練/検証を分離) | 訓練セット報酬は検証セット精度と相関が乏しい。両方を出す | [[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]] | | 生成エントロピー・生成確率 | 低すぎれば探索能力喪失、高すぎれば意味不明・反復生成。ただしエントロピーは汎化の信頼できる予測子ではない | 同上、[[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]] | | KL ダイバージェンス | 過大(KL 爆発)と過小(エントロピー崩壊)の両端が障害になる | [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]]、[[@2025__arXiv__Scaling Up RL - Unlocking Diverse Reasoning in LLMs via Prolonged Training]] | | 応答長・ターン数の分布 | 平均ではなく分布。長尾が生成時間を支配する | [[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]] | | 実効プロンプト率 | 正答率 0/1 のプロンプト比率は訓練とともに増え、勾配が消える | 同上 | | 打ち切り率(コンテキスト・タイムアウト・ステップ上限) | マスク対象の割合そのものを監視対象にする | [[@2025__Together AI__DeepSWE - Training a Fully Open-sourced State-of-the-Art Coding Agent by Scaling RL]] | | クリッピング率 | 切り詰め率 5% 未満が安定、10〜15% で不安定化 | [[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]] | | ツール・環境の呼び出し結果 | ツールエラー・観測破損・終了エラーは独立した障害ファミリ | [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]] | | ロールアウト分布の設定 | 推論エンジンのバージョンとデコーディングパラメータを構成管理下に置く | [[@2025__arXiv__Training Long-Context Multi-Turn SWE Agents with Reinforcement Learning]] | 正常プロファイルの較正は前提条件である。健全ランの集合を持たずに閾値だけ置いても検知は成立しない([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]])。また、時間窓の取り方も効く。RFT-FM の検知性能は temporal horizon を伸ばすほど概ね向上し、easy では 18〜20 ステップ付近で最良になる一方、hard では早期に頭打ちになる(同上)。 #### 失敗しやすい箇所 - **推論エンジンの暗黙の設定変更**。アップグレードでサンプリングフィルタが有効化されると重要度サンプリング比の前提が崩れ、5〜10 反復後に性能が劣化する([[@2025__arXiv__Training Long-Context Multi-Turn SWE Agents with Reinforcement Learning]])。 - **フィルタリングのやりすぎ**。長軌跡の一律除外はループ失敗の負例まで消し、ループ行動を助長する(同上)。 - **同期パイプラインのストラグラー**。最遅軌跡がイテレーション全体を律速する。非同期化は方策ラグと引き換えである(同上、[[@2025__arXiv__AgentRL - Training Language Model Agents with Reinforcement Learning]])。 - **勾配の実効的な消失**。正答率 0/1 のプロンプトが増えると実効バッチが縮み、勾配のノイズ耐性が悪化する([[@2025__arXiv__DAPO - An Open-Source LLM Reinforcement Learning System at Scale]])。 - **コンテキスト上限への早期到達**。記憶管理がないと 10 イテレーション以内に上限へ達する([[@2025__Moonshot AI__Kimi-Researcher - End-to-End RL Training for Emerging Agentic Capabilities]])。 - **単一難易度への偏り**。困難問題のみでの訓練は容易問題での壊滅的忘却を招き、容易データの混合で緩和される([[@2026__arXiv__IsoCompute Playbook - Optimally Scaling Sampling Compute for LLM Reinforcement Learning]])。 - **報酬設計の抜け穴**。合成タスクの設計次第で高度な報酬ハッキングが現実に起きる。二値かつ操作しにくい報酬はリスクを構造的に下げる([[@2025__Together AI__DeepSWE - Training a Fully Open-sourced State-of-the-Art Coding Agent by Scaling RL]]、[[@2025__arXiv__DeepSeek-R1 - Incentivizing Reasoning Capability in LLMs via Reinforcement Learning]])。 - **信用割当まわりの静かな劣化**。この系統の障害は粗いテレメトリでは健全ランと見分けがつかず、検知も診断も最難である([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]])。 - **小規模評価だけでのレシピ確定**。少計算での優位は大計算での優位を保証しない([[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]])。 - **ベースモデルの準備不足**。7B dense や 16B MoE では純粋 RL の効果が現れなかった。インフラを整える前に、そもそも RL が効く土台かを確認する必要がある([[@2025__arXiv__DeepSeek-R1 - Incentivizing Reasoning Capability in LLMs via Reinforcement Learning]])。  --- ## 第 XI 部効率・電力・経済性 — 投資をどう正当化するか学習インフラへの投資は、最終的には「同じ電力・同じ資本で、どれだけ有用な学習が進んだか」で正当化される。第 XI 部では、フリート効率の定義、損失要因の分解、電力とエネルギー、ハードウェア世代交代と可搬性、そして改善施策の優先順位付けを扱う。最後に、これらを経営へ報告する指標セットへ落とし込む。 ![[Attachments/llm-training-ch11-economics.png]] *図 12. 第 XI 部の投資判断。MPG を SG・RG・PG に分解し、失われる GPU 時間を削減可能性と実装コストで優先順位付けする。*（Source: [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]], [[@2026__AI__Scalable and Energy-Efficient AI - System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training]]） ### 11.1 フリート効率をどう定義するか #### 11.1.1 利用率指標の三つの罠大規模フリートで最初に使われる指標は利用率系だが、([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]) はこれらがいずれも「有用な仕事量」を直接測っていないと指摘する。三指標に共通する誤りは「利用率 == 生産性」という前提である。 | 従来指標 | 定義 | 限界 | |---|---|---| | Capacity | 展開済みリソース | トポロジ制約・地理的制約を無視し、高 Capacity が高可用性を意味しない | | Occupancy | 割り当て済みリソース | I/O 待ちや非最適コードの実行中でも計上され、「高 Occupancy だが進捗ゼロ」があり得る | | Duty Cycle | アクティブリソース | 行列演算ユニットの稼働有無しか見ず、冗長計算でも計上される | 同じ指摘は、クラスタ全体の利用率が高くてもジョブ単位では GPU が遊んでいるという実証 ([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]]) とも重なる。利用率は「どこで無駄が起きているか」を分解できない一枚岩の指標である。 #### 11.1.2 ML Productivity Goodput の分解 ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]) は計算機アーキテクチャの iron law に着想を得て、[[ML Productivity Goodput]](MPG)を三成分の積として定義する。 ``` MPG = Scheduling Goodput (SG) × Runtime Goodput (RG) × Program Goodput (PG) SG = all-allocated chip-time / capacity 同期進捗に必要な資源を同時に保有できているか RG = productive chip-time / all-allocated 保有しているとき実際に進捗しているか PG = ideal predicted time / actual time 進捗しているとき理論ピークにどれだけ近いか ``` RG の分子は「チェックポイントに保存済みの進捗に対応する chip-time」であり、直前チェックポイントから障害・プリエンプションまでの作業は算入されない。すなわち復旧で捨てた計算は定義上そのまま無駄として計上される ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。 #### 11.1.3 MFU だけを見る場合との違い [[LLM分散学習]] の効率議論は伝統的に MFU を軸にしてきた。PTD-P は 1T パラメータ・3072 GPU で MFU 52% を達成した ([[@2021__SC__Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM]])。しかし MFU は MPG の PG に相当する層だけを見ており、スケジューリング待ちや復旧の損失は視野に入らない。さらに PG は roofline 効率とも異なる。roofline は演算子を独立に評価するため、演算子融合・再計算・メモリ配置変更といった正しい最適化がかえってスコアを下げて見える。PG は融合後の予測ステップ時間を分母に取ることでこの余地を正しく「改善」として計上する ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。この設計のおかげで、1024 TPU チップ・500B パラメータの通信計算オーバーラップによるスループット最大 1.38 倍・FLOPS 利用率 72% という成果が指標上に現れる。 | 見えるもの | 利用率(Occupancy/Duty Cycle) | MFU / roofline | MPG | |---|---|---|---| | 資源が揃わない待ち | 見えない | 見えない | SG | | データロード・チェックポイント・コンパイル待ち | 見えない | 見えない | RG | | 復旧で捨てた計算 | 見えない | 見えない | RG | | 演算子融合・通信オーバーラップの余地 | 見えない | 過小評価 | PG | ### 11.2 効率損失の分解本節は損失を経済性の観点から集計する。障害の実態そのものは第 VII 部、復旧設計は第 IX 部が扱う。 #### 11.2.1 中断と復旧損失は障害の件数ではなく GPU 時間に現れる。ハードウェア関連の失敗はジョブ件数では 0.2% にすぎないが GPU 実行時間の 18.7% に影響し、さらに障害オーバーヘッド全体の 16% は失敗した大規模ジョブ自身ではなく、再キューに伴う小規模ジョブの二次的プリエンプションから生じる ([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。本番 LLM 訓練でも、インフラ障害は件数 11% でありながら GPU 時間の 82% を消費する ([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。復旧側の損失は有効訓練時間率(ETTR)として定式化できる。長時間・高優先度ジョブでは `E[ETTR] ≈ 1 - N_nodes × r_f × (u0 + Δt_cp/2)` に単純化され、16,000 GPU の単一訓練という仮想シナリオでは 60 分チェックポイントで ETTR 0.7、5 分チェックポイントで 0.93 になる ([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。[[チェックポイント]] 間隔は効率指標に直接効く設計変数である。復旧時間の内訳も測る必要がある。504 GPU の本番クラスタでは再起動時ロードの平均が 33 分・中央値 31 分に達し、その間の NFS read スループットは最大帯域 700 GB/s の 21.5% にとどまる。保存側の WRITE RPC は平均 2.03 秒/要求のうち 1.89 秒(93.1%)がキュー時間である ([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。帯域を増やしても縮まらない損失が存在する。 #### 11.2.2 ストラグラーとグレーノードクラッシュしない劣化も大きな損失源である。5 か月・3079 ジョブの実トレースでは、LLM 学習ジョブの 42.5% が少なくとも 10% スローダウンしており、浪費の約 80% は通信ではなく計算オペレーションのスローダウンに帰属する ([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]])。標準ヘルスチェックを通過するグレーノードでは、平均 2% 程度の速度低下でもスループットが 20〜30% 損なわれ、学習コストが 1.3〜1.5 倍に膨らむ ([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])。[[ストラグラー]] は信頼性の問題であると同時に経済性の問題である。 #### 11.2.3 ジョブ内の低利用率損失はハードウェアだけでなくジョブのコードにも宿る。400 件の実ジョブから発見された 706 件の低 GPU 利用率問題は、データ操作 46.03%・モデル層 45.18%・ジョブ設定 4.82%・ライブラリ 3.97% に分布し、単一原因では非効率なホスト-GPU データ転送 27.90%、バッチサイズ不適切 25.64%、モデルチェックポイント 16.43% が上位を占める ([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]])。重要なのは、これらの 84.99% が少数のコード修正で解消できる点である。 #### 11.2.4 待機と開発者の生産性待機は SG の問題である。Google の本番 TPU フリートでは全ジョブサイズにわたり SG > 95% が達成されており、スケジューリング層の残余は小さい ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。一方、LLM 専用クラスタでは事前学習のために大半の GPU を予約する結果、最も短く資源要求も小さい評価ジョブが最長のキュー遅延を持つという逆転が生じる ([[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]])。低利用率は資源の無駄遣いであると同時に [[開発者生産性]] の低下でもある ([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]])。効率の損失は電力請求書だけでなく、実験の回転速度としても現れる。 | 損失要因 | 代表値 | 出典 | |---|---|---| | ハードウェア障害 | 件数 0.2% で GPU 実行時間の 18.7%、二次的プリエンプションが障害オーバーヘッドの 16% | ([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) | | インフラ障害全般 | 件数 11% で GPU 時間の 82% | ([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) | | 復旧(ロード) | 再起動ロード平均 33 分、read 帯域利用率 21.5% | ([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]]) | | ストラグラー | ジョブの 42.5% が 10% 以上スローダウン、浪費の約 80% が計算側 | ([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]]) | | グレーノード | 平均 2% 低下でスループット 20〜30% 損、コスト 1.3〜1.5 倍 | ([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]) | | ジョブ内低利用率 | 706 件中データ操作 46.03%・モデル層 45.18%、84.99% はコード修正で解消可能 | ([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]]) | | 未完了ジョブ | クラスタ全体エネルギーの約 50% | ([[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]]) | ### 11.3 電力とエネルギー #### 11.3.1 システムレベルの電力プロファイリング [[GPUエネルギー効率]] は計算効率とは独立した軸であり、両者の乖離は「計算-エネルギー不整合」と呼ばれる。8×H100 ノードと 8×B200 ノードを同一の分散データ並列設定で比較した実測では、B200 は GPU 利用率で 1〜6%、訓練時間で最大 15%、TFLOPs/GPU で最大 32% 優位でありながら、TFLOPs/kW と tokens-per-kilojoule では LLM 5 モデル全てで H100 を下回った ([[@2026__AI__Scalable and Energy-Efficient AI - System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training]])。 | モデル | ノード | 訓練時間(s) | 平均電力(W) | TFLOPS/GPU | TFLOPs/kW | Tokens/kJ | |---|---|---|---|---|---|---| | Mistral-7B-v0.3 | H100 | 2702 | 437.8 | 35.19 | 80.4 | 5634 | | Mistral-7B-v0.3 | B200 | 2370 | 579.8 | 46.56 | 80.3 | 4850 | | Gemma-2-27B | H100 | 8393 | 467.7 | 39.17 | 83.8 | 1517 | | Gemma-2-27B | B200 | 7111 | 616.3 | 50.96 | 82.7 | 1358 | | Qwen2.5-32B | H100 | 9738 | 458.8 | 37.42 | 81.6 | 1270 | | Qwen2.5-32B | B200 | 8302 | 605.1 | 48.7 | 80.5 | 1129 | ただし効果はワークロードの演算密度に依存する。畳み込み・プーリング・疎注意カーネルに依存する視覚言語モデルでは B200 の高いベースライン消費電力が不利に働く一方、演算強度の高い Vita-CLIP は B200 で約 2 倍高速かつ総エネルギー消費も少ないという例外を示した ([[@2026__AI__Scalable and Energy-Efficient AI - System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training]])。 #### 11.3.2 施設規模への外挿ノード実測を施設規模へ拡張すると、差は年間コストとして現れる。稼働率 99%・配電損失 10% を仮定した試算では、中負荷(2000 ノード)で H100 70.4 GWh に対し B200 76.6 GWh(年間 +$0.62M)、高負荷(5000 ノード)で 185.0 GWh 対 217.8 GWh(年間 +$4.26M)となる ([[@2026__AI__Scalable and Energy-Efficient AI - System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training]])。なお同論文の PUE 値は実測ではなくシナリオ上の仮定であり、電力上限を設定した構成も未評価である点は明記されている。 #### 11.3.3 熱と混在ワークロード電力は冷却制約としても効く。国家規模の HPC データセンターの実測では、ML ジョブはノード数の 15%・投入件数の 9%・ランタイムの 17% にすぎないのにエネルギー消費の 39% を占め、GPU ラックの合計 TDP(6,650 W)は冷却容量(5,500 W)を常に超過し、GPU 温度が 17.4% の時間で 90% 超えとなる ([[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]])。同一ノード内でも物理位置により温度に最大 9% の差が出る。LLM 専用クラスタ側では、電力の 65.7% を GPU が占め CPU は 11.2% にとどまる ([[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]])。 #### 11.3.4 推論側の対照推論でも同じ構図が観測される。データフローアクセラレータは小バッチでスループット・レイテンシに 1 桁の優位を示すが、エネルギー効率では GPU に劣る(Cerebras CS-3 0.15 tok/J・24,200 W、SambaNova SN40L 0.38 tok/J・5,230 W に対し NVIDIA A100 0.73 tok/J、H100 0.91 tok/J)([[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。実行時制御でも、バッチングと動的電圧周波数制御は同一の SLO スラック予算を奪い合う結合軸であり、これらをミリ秒粒度で同時制御すると vLLM 比で最大 51% のエネルギー削減が得られる ([[@2026__MLSys__BEAM - Joint Resource-Power Optimization for Energy-Efficient LLM Inference under SLO constraints]])。 ### 11.4 ハードウェア世代交代と性能可搬性 #### 11.4.1 世代交代で何が変わるか世代交代は帯域と数値形式を大きく動かす。Rubin は HBM4 を最大 288GB 搭載しピーク帯域 22 TB/s(Blackwell 比 2.8 倍)、第 3 世代 Transformer Engine が NVFP4 で最大 50 PFLOPS を実現し、K 次元のテンソルコアスループット倍増により GEMM の K ループ反復回数を半減させる ([[@2026__NVIDIA Developer Blog__Inside NVIDIA Rubin GPU Architecture Powering the Era of Agentic AI]])。電力側では Intelligent Power Smoothing が平均電力を約 10%・50ms ピーク電力を約 20% 削減し、DSX MaxLPS は同一電力予算内で最大 40% 多くの GPU をプロビジョニングできるとされる。座礁電力の回収という観点は、固定電力予算下での投資判断に直結する。一方で、世代が新しいほど効率が良いとは限らない。世代の成熟度も指標に現れ、特定チップ世代の PG は導入初期に低く、モデルとコンパイラの適応が進むにつれ上昇し、退役が近づくと再び低下する ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。新ハードウェア導入直後の効率低下は異常ではなく想定すべき挙動である。 #### 11.4.2 性能可搬性の定量化 [[性能可搬性]] は、モデル `m`・データセット `d`・プラットフォーム集合 `H` に対する `Φ(m,d,H)` を各プラットフォームの計算効率の調和平均として定義する ([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]])。8 ノード 64 GPU の実測では、チューニング後でも計算効率は IB-A100 0.3529、RoCE-A100 0.3272、RoCE-H100 0.1735、通信効率は 0.146・0.158・0.27、全体の `Φ = 0.2574` にとどまった。注目すべきは、最も高速なプラットフォーム(RoCE-H100 は RoCE-A100 の約 1.85 倍高速)の計算効率が最も低いことである。速度の優位と効率の優位は一致しない。 #### 11.4.3 性能可搬性のチューニング戦略同論文の通信を意識した方法論は三段からなり、既定構成比で最大 1.6 倍の高速化を得た ([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]])。 | 段 | 対象 | 実測された知見 | |---|---|---| | 1 | 集合通信の単体測定 | NCCL のアルゴリズム・スレッド数・チャネル数など 10 パラメータを探索。64 GPU 規模では改善は小さい | | 2 | バッチサイズ・勾配累積・ZeRO stage | 一定の `C = batch_size × grad_acc` の下でも最適点は変わり、「バッチサイズを最大化すればよい」は成り立たない | | 3 | 通信オプション | 全プラットフォームで最良のコレクティブは reduce-scatter。既定実装は Stage 2 で all-reduce を呼んでいた | RDMA を無効化して TCP に落とすと forward pass は変わらないが backward pass が 12 倍遅くなる。[[集合通信]] の経路が性能可搬性の中心制約であることを示す実測である ([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]])。既定設定は実装・プラットフォーム・モデルに依存して容易に外れるため、移行のたびに設定空間を測り直す前提で計画する。 ### 11.5 改善施策の優先順位付け投資先は、まず MPG の三層のどこに損失が乗っているかを測ってから決める。Google の本番フリートで SG > 95% が達成されていることは、スケジューリング層の残余が限られ、主戦場がランタイム層とプログラム層に移っている可能性を示唆する ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。ただしこれは単一組織・単一スケジューラの結果であり、自組織で同じ分解を測ることが前提になる。 | 層 | 施策 | 報告された効果 | 出典 | |---|---|---|---| | プログラム | 通信計算オーバーラップ | 1024 TPU・500B でスループット最大 1.38 倍、FLOPS 利用率 72% | ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]) | | プログラム | 通信を意識した設定チューニング | 既定構成比最大 1.6 倍 | ([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]]) | | ランタイム | 非同期チェックポイント・事前コンパイル・入力処理最適化 | アクセラレータのアイドル時間を削減 | ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]) | | ジョブ | バッチサイズ拡大 + 非同期チェックポイント + メモリピニング | BERT 7.52 倍、Swin Transformer 3.95 倍 | ([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]]) | | ノード健全性 | グレーノード検知と段階的緩和 | MFU 最大 1.7 倍、ステップ時間分散 20%→1%、MTTF 2.5 倍、人的介入間隔 11 倍 | ([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]) | | ノード隔離 | レモンノード検知 | 512+ GPU の大規模ジョブ失敗率 14%→4%(対象は全体の 1.2〜1.7%) | ([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) | | ワークロード | シーケンス長再分配・計画的 GC | スループット 23.9%・12.6% 改善 | ([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]]) | | 復旧 | 自動リトライ | 成功率 33.3%(手動 12.5% の 2.7 倍)、間隔中央値 11 分 | ([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]]) | 優先順位を決める際の判断基準は三つある。第一に、投資対象の分母が大きいか。ジョブ単位のコード修正は 84.99% の問題を少数の変更で解消でき、単価が最も低い ([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]])。第二に、損失が GPU 時間で大きいか。件数の小さい障害が GPU 時間の大半を食う構造は複数の本番クラスタで一貫している ([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。第三に、規模で効き方が変わるか。10 万 GPU 級では ETTR 0.9 を保つのに約 2 分のチェックポイントと約 2 分の再起動が要求され、現在の運用前提では届かない ([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。 ### 11.6 実運用の要点 — 経営に報告する指標セットの設計報告用の指標は三層に分ける。経営層には投資判断に使える少数の合成指標を、運用層には責任分界に対応した分解指標を、診断層には原因追跡用の生データを置く。MPG の三成分分解は、スケジューリングチーム・ランタイムチーム・コンパイラチームのどこが何を担当すべきかを明確にする点でこの分業に適合する ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。 | 層 | 指標 | 根拠 | |---|---|---| | 経営 | フリート効率(MPG または同等の goodput) | 利用率は生産性を意味しない ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]) | | 経営 | 有効訓練時間率(ETTR) | チェックポイント間隔・再起動時間・障害率を同じ設計空間に置ける ([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) | | 経営 | 年間エネルギー量とエネルギーコスト | ノード実測から施設規模へ外挿できる ([[@2026__AI__Scalable and Energy-Efficient AI - System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training]]) | | 経営 | tokens-per-kilojoule / TFLOPs/kW | 計算効率と独立した軸として並記する ([[@2026__AI__Scalable and Energy-Efficient AI - System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training]]) | | 運用 | SG / RG / PG の三成分 | ボトルネックの層を特定する ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]) | | 運用 | 失われた GPU 時間(障害種別ごと) | 件数でなく GPU 時間で測る ([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) | | 運用 | MTTF・MTTR・人的介入間隔 | 組織・ドメインを横断する共通の成果尺度 ([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]) | | 運用 | ステップ時間の分散 | グレーノードの症状が最初に現れる ([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]) | | 診断 | チェックポイント I/O の内訳(帯域とキュー時間) | 帯域利用率だけでは復旧遅延を説明できない ([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]]) | | 診断 | ノード別の除外回数 | 上位 3/63 ノードが全除外の 50% 超という集中を捉える ([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]]) | 設計にあたっての注意を四つ挙げる。第一に、単一指標に寄せない。利用率も MFU も、それだけでは損失の所在を語らない(§11.1.3)。第二に、計算効率とエネルギー効率を必ず並記する。スループット優位はエネルギー効率優位を意味せず、この乖離は訓練と推論の双方で独立に観測されている ([[@2026__AI__Scalable and Energy-Efficient AI - System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training]], [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。第三に、組織横断の数値比較には慎重になる。MTTR や MTTF の改善倍率はいずれも自組織の従来運用に対する比であり、対象規模・ワークロード・既存運用の成熟度という母数が異なる ([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。第四に、新ハードウェア導入直後の効率低下を織り込む。PG は導入初期に低く成熟とともに上昇するため、移行初期の数値だけで投資の成否を判断しない ([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。最終的に、経営に対して答えるべき問いは「GPU がどれだけ忙しかったか」ではなく「同じ電力と同じ資本で、学習がどれだけ前に進んだか」である。この問いに答えられる指標だけを報告に載せる。  --- ## 第 XII 部実運用プレイブック — 誰がいつ何を判断するか第 I 部から第 XI 部までは、層ごとに「何が起きるか」と「どう測るか」を積み上げてきた。第 XII 部はそれらを時間軸に並べ直す。すなわち、クラスタを立ち上げる 90 日、定常運用の一日、インシデントの一時間で、誰が何を判断するかを扱う。本部に新しい技術は出てこない。すべて前の部で引いた出典に基づく。役割は、層別の知識を意思決定の順序へ変換することにある。 ![[Attachments/llm-training-ch12-playbook.png]] *図 13. 第 XII 部の運用プレイブック。症状から一次仕分けと隔離判断を行い、再起動・再配備・ノードスイープを経て正常プールへ戻す。*（Source: [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]） ### 12.1 設計の初手 — 目標から逆算する運用設計は「どの指標をいくつにするか」から始まる。技術の選択はその後である。 #### 12.1.1 三つの数字を先に置く第一に、**目標 ETTR**。有効訓練時間率は $E[\text{ETTR}] \approx 1 - N_{nodes} r_f (u_0 + \Delta t_{cp}/2)$ で近似でき、ノード障害率 $r_f$・再起動オーバーヘッド $u_0$・チェックポイント間隔 $\Delta t_{cp}$ を同じ設計空間に置ける([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。本番の到達水準は 9,600 GPU・3 か月で最大 97%([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])、10,000 GPU 超で 90% 超([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])である。第二に、**最大ジョブ規模**。MTTF はノード数にほぼ反比例するため、8 GPU で 47.7 日だったものが 1,024 GPU で 7.9 時間、16,384 GPU で 1.8 時間になる([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。規模を決めた瞬間に中断頻度が決まる。第三に、**予備ノード比率**。絶対数ではなく「予備ノード数 / 大規模ジョブ要求ノード数」の比率で置く。504 GPU の事例では 60 ノード訓練に対し予備 3 ノードという構成が、意図的隔離で予備を食い潰した結果として自動リトライの成否を左右した([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。ハードウェア側からの見積もりでは、608 GPU・復旧 2.2 時間のジョブでジョブレベル 99.9% を保つのに約 5% のオーバープロビジョニングが要り、1,000 ノード規模では月 100 万ドル超になる([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。この三つが決まると、チェックポイント間隔の要求値が逆算される。16,000 GPU の単一訓練では 60 分チェックポイントで ETTR 0.7、5 分で 0.93、10 万 GPU 級で ETTR 0.9 を狙うなら約 2 分チェックポイントと約 2 分再起動が要る([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。要求間隔が 1 回の保存所要時間より短くなったら、間隔の調整では解けない。保存そのものを削る設計(階層化・冗長除去・遊休帯域転用)へ移る(第 IX 部)。 #### 12.1.2 測る単位を先に固定する運用指標は件数ではなく **GPU 時間**で見る。この原則は 2017 年の Philly から一貫している([[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]])。件数で見ると重要な障害が脇役に見えるからだ。ByteDance ではインフラ障害が件数 11% で GPU 時間の 82% を消費し([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])、Meta ではハードウェア関連失敗がジョブ件数の 0.2% で GPU 実行時間の 18.7% に影響する([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]])。件数・GPU 時間・失われたノード時間の 3 系列を、集計の最初から分けて持つ。後から分離することはできない。 ### 12.2 立ち上げの 90 日前版のロードマップを、本書の各部の内容で裏づけ直したものである。 #### 12.2.1 第 0〜30 日 — 見える状態にする **受け入れ検証を通す**。ネットワークの検証項目は第 4.10 節の表に譲る。ここでは順序だけ示す。物理配線(レール対応の一致、異種サーバのポート番号体系)→ 光部品(Pre-FEC/Post-FEC の BER 取得手順)→ ロスレス設定(PFC ヘッドルーム、ECN 閾値、ウォッチドッグ、ブロードキャストの無損失クラス混入)→ 集合通信(既定値が本番 RTT を前提としているか、`NCCL_CROSS_NIC=0` 相当のトポロジ依存設定)→ ベンチマーク。デフォルト設定は最適から程遠く、手動チューニングで最大 1 桁の性能差が出る([[@2024__SC__Exploring GPU-to-GPU Communication - Insights into Supercomputer Interconnects]])。 **バーンイン期を定常運用と混ぜない**。GPU のエラー率はバスタブ曲線に従い、infant-mortality 期の system-wide MTBE 0.15 時間が normal-life 期には 1.4 時間へ 10 倍改善する([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。SAKURAONE でも 3 か月 21 件の障害のうち 13 件が最初の 1 か月に集中した([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]])。この期間の数値で定常の故障率を見積もると必ず外す。 **第 1 層の可観測性を立てる**。電力・温度・利用率・ECC、NVLink/NIC スループット、ジョブ履歴。DCGM Exporter・Node Exporter・並列ファイルシステムの Exporter・IPMI Exporter を配し、時系列データベースへ流す構成が公開されている([[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]])。ダッシュボードは空間ビュー(ラック→サーバ→GPU)・時系列ビュー・ジョブビューの 3 種に分ける。 **除外規則と集約規則を先に決める**。ユーザジョブ起因で GPU の健全性を示さない XID 13 と XID 43 を除外し、同一 GPU・同一メッセージのバーストは短時間窓(たとえば 5 秒)で 1 件に集約する([[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]])。この規則を決めずに集計した数値は、他クラスタの公表値と比較できない。実際、1 台の故障 GPU が 17 日間エラーを出し続けて 100 万件超の重複ログを生んだ事例がある([[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]])。 #### 12.2.2 第 31〜60 日 — 早く止め、早く再開する **検知をタイムアウト依存から外す**。PyTorch の集合通信タイムアウト 1,800 秒や Megatron の 30 分タイムアウトが、そのまま検知時間として復旧時間に直乗りしていないか確認する。能動的ハートビートに置き換えると 4〜11 秒に落ちる([[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2024__arXiv__Unicron - Economizing Self-Healing LLM Training at Scale]])。 **復旧の 7 段を実測する**。検知 → 判定 → 隔離 → 再スケジュール → チェックポイント読み出し → 再同期 → 定常復帰。どこが支配項かは環境で変わる。ポッド作成 392 秒・依存関係インストール 421 秒が支配していた事例([[@2025__arXiv__FFTrainer Fast Failover in Large Language Model Training with Almost Free State Management]])、2,048 GPU で通信グループ初期化が 1,000 秒超だった事例([[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])、チェックポイントのロードが中央値 31 分だった事例([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])が並存する。推定でなく計測が要る。 **帯域とキューを混同しない**。504 GPU の事例では、NFS read スループットが最大帯域の 21.5% にとどまる一方、WRITE RPC の 93.1% がキュー時間だった([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。回線を太くしても縮まない待ちがある。 **自動リトライを入れる**。同事例では自動リトライチェーンの成功率 33.3% が手動復旧 12.5% の 2.7 倍、間隔の中央値 11 分と手動より予測可能だった([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。ただし同条件の再試行を延々と繰り返して GPU 時間を溶かす経路は塞ぐ。 #### 12.2.3 第 61〜90 日 — 学習する運用へ進める **第 2 層の可観測性を足す**。反復時間、フェーズ持続時間(順伝播・逆伝播・最適化・通信)、カーネル統計サマリ。合計オーバーヘッド 2% 未満を上限として層ごとに配分する([[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]])。 **ストラグラーを一級のインシデントに昇格させる**。クラッシュしない劣化は放置されやすいが、ジョブの 42.5% が 10% 以上スローダウンし全 GPU 時間の 10.4% が失われる([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]])。グレーノードでは平均 2% の速度低下がスループット 20〜30% の損失、学習コスト 1.3〜1.5 倍に増幅される([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])。 **ホスト単位の再発を追う**。障害はホストに集中する。全ホストの 10% 未満が critical な障害の 24〜33% を四半期・90 日ローリング窓を通じて安定的に占め([[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]])、63 ノードのうち上位 3 ノードが全除外の 50% 超を占めた事例もある([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。個々の障害タイミングを予測するより、ホスト別の障害履歴・再発間隔・未解決件数を蓄積するほうが投資効率がよい。 **プロアクティブ検証を入れる**。全ノードを毎回検証するより、インシデント確率がしきい値を超えたノードだけを選んで検証するほうが指標がよくなる。1,000 ノード・30 日のシミュレーションで、インシデント間平均時間は未検証比 22.61 倍、フルセット検証比でも 1.11 倍となり、検証時間は 92.07% 削減された([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]])。検証それ自体がノード時間を奪うからである。 ### 12.3 当番の判断表インシデント時に当番が最初の 10 分で行う一次仕分けを、症状から起点レイヤへ写す表として置く。詳細な診断は第 VIII 部、ネットワーク固有の切り分けは第 4.7 節を参照する。 | 観測される症状 | まず疑うレイヤ | 一次確認 | 根拠 | |---|---|---|---| | プロセスが落ちた | ホスト側の致命的エラー | 二重ビット ECC・回復不能 ECC・リンクダウン・GPU/NVLink/NIC の消失・過熱・ドライバエラーの有無 | 分散障害の 71% はネットワークと無関係([[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]]) | | 全ランクが同じ NCCL タイムアウトを報告 | 症状であって原因ではない | 起因をユーザコード・システムソフトウェア・ハードウェアの三方向で保留する | NCCL timeout は全ドメインにまたがる曖昧な症状([[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]]) | | 進まないが落ちない(hang) | 集合通信の参加状況 | 全ランクが参加したか / ハングしていないランクが存在するか | ハング 3 類型の切り分けは 2 問で足りる([[@2026__PPoPP__CCL-D - A High-Precision Diagnostic System for Slow and Hang Anomalies in Large-Scale Model Training]]) | | 遅いが落ちない(slow) | 演算か通信か | $P = (T_{max} - T_{min})/(T_{max} - T_{base})$ が 1 に近ければ演算、0 に近ければ通信 | スローのうち演算スローが 81.8%(同上) | | 特定ランクだけ遅い | ノード内の計算・ストレージ・ハードウェア | 他ランクより 1 秒以上ずれて開始/終了しているか | 実運用の判定閾値([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]]) | | 全体が均等に遅い | 分割の不均衡・GC | パイプラインステージ分割、シーケンス長分布、Python GC | 支配的原因はステージ分割 39.3%、シーケンス長 21.4%([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]]) | | 帯域が急に半減して一定 | NIC・リンク障害と透過的リルート | 集合通信ライブラリが黙ってリルートしていないか | 帯域半減 + ステップ時間 +0.3 秒([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]) | | 単独ベンチは健全なのに本番だけ遅い | 操作間の輻輳制御干渉 | AllReduce と AllToAll の混在有無 | 高レートフローが DCQCN を発火させ低帯域フローを抑制([[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]]) | | 初期化・再起動が遅い | 制御プレーン | 通信グループ初期化が規模に対して線形か | 96K 規模で初期化 4 分超が再起動時間を支配([[@2025__arXiv__Collective Communication for 100k+ GPUs]]) | | 損失は下がっているがモデルが怪しい | サイレントエラー | 分散ランク間の重み一致、API 呼び出し順序、引数の一貫性 | 損失は活動を測るが正当性を測らない([[@2026__SREcon26Americas__Beyond Loss and Accuracy - Closing the Observability Gaps in AI Training with TrainCheck]]) | | コード変更後に数%遅くなった | 性能回帰 | 発行遅延分布と空白割合 | スループットという巨視指標には現れない([[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]]) | 判断の順序には根拠がある。ホスト側の致命的障害を先に潰すのが最も効率的であり、分散エラーが 2 ホスト以下なら送信元と宛先のクラスタリングを試みるより隔離して再起動するほうが速い([[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]])。 ### 12.4 隔離と復帰の判断 #### 12.4.1 隔離の粒度と偽陽性の扱い検知から隔離へつなぐとき、精度と速度は交換関係にある。判断は**緩和動作の可逆性と重さ**で決まる。緩和が軽量かつ可逆なら偽陽性を許容できる。Guard は偽陽性率 12.4% を許容し、異常スコアを 0〜1 に写して 3 段階に分岐させる(10% 未満は検証保留、10〜20% は次のチェックポイントまで待って緩和、20% 以上は即座に正常プールから除外)([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])。緩和が重いなら保守的にする。性能回帰の候補は通知にとどめて学習を強制終了しない方針で、偽陽性率 1.9% に抑えた例がある([[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]])。早さを優先して過剰排除する選択もある。起因が解けなければランタイムスタックトレースをクラスタリングし、外れ値が共有する並列グループごと排除する。9,600 GPU ジョブでは 1 グループ 8 マシンなので、実際に壊れているのが 1〜2 台でも 6〜7 台の偽陽性が出る。これを早期隔離の対価として許容している([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。一方で、無差別な隔離はクラスタ利用率を毀損する。訂正可能なシングルビット ECC のように障害を引き起こさないエラーもあるため、致命的エラーの一覧を明示的に持ち、そこに該当するホストだけを直ちに隔離する([[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]])。 #### 12.4.2 復帰までの閉ループ隔離したノードを戻す手順は 5 段階で回す。(1) GPU/ネットワークのエラーを出しているか確認、(2) 出ていれば再起動とドライバ再配備、(3) 継続するなら再プロビジョニング、(4) エラーが消えればノードスイープへ、(5) 通過すれば正常プールへ復帰、失敗すれば交換。経験則として、1 週間以内に 3 回トリアージに入ったノードは恒久的な不良と判定して人手の交換対象に指定する([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]])。この閉ループ全体で、平均故障間隔が 6.6 時間から 16.7 時間へ、人的介入の間隔が 5.6 時間から 0.5 時間へ改善した。修復の粒度をノードでなく GPU 単位まで下げ、頻度ベースの「マルチストライク」判定で過剰なノードドレインを防ぐ設計もある。Aurora(63,744 GPU)では手動保守比で平均復旧時間を最大 84 倍短縮した([[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]])。残る空白も明示しておく。「再起動で直るのか修理が要るのか(後者は数週間から数か月)」はエラー報告だけでは判別できず、効率的な判定方法は未解決である([[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]])。 #### 12.4.3 継続か再起動かネットワーク障害は状態が壊れない障害なので、再起動以外の選択肢がある。チェックポイント間隔 $T_{interval}$、経過時間 $t_{elapsed}$、検知時間 $T_{detect}$、フェイルオーバー時のスローダウン率 $k$ に対し、 $t_{elapsed} > \frac{T_{interval}(k-1) - T_{detect}}{k}$ を満たすときフェイルオーバーが再起動より有利になる。$k=1.5$・$T_{detect}=0$ ならチェックポイント間隔の 1/3 を過ぎていれば継続が勝つ([[@2026__EuroSys__Handling Network Faults in Distributed AI Training]])。この判定はスケジューラに組み込める。ただし利得は規模依存で、64k GPU で約 4.63%、16k GPU で約 1.25%、1k〜4k GPU では 1% 未満にとどまる。小規模では実装の複雑性が利得を上回りうる(同上)。 ### 12.5 変更管理を性能管理に統合する構成変更は障害と同じ経路で性能を壊す。だが検知系は障害向けに作られていることが多く、変更起因の劣化を取りこぼす。 **回帰は巨視指標に現れない**。コード更新や設定ドリフトに由来する持続的な劣化は、スループットを見ていても気づけない。実際、FSDP から Megatron へバックエンドを移行した際、FFN 重みのレイアウト変化が Tensor Core の 128 バイトアラインメント不適合を招き FLOPS が 65.3% 低下した事例がある([[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]])。並列化次元の変更はレイアウトの変更でもある。 **論文どおりに動くとは限らない**。DeepSpeed の ZeRO Stage 2 は既定では reduce-scatter ではなく all-reduce で動作し、`reduce_scatter=true` に加えて `use_multi_rank_bucket_allreduce=false` の設定が要る([[@2025__PMBS__Pretraining LLMs at Scale - Tuning Strategies and Performance Portability]])。設定変更の効果は実測でしか確かめられない。 **推論エンジンのバージョンは学習アルゴリズムの一部である**。事後学習では、vLLM のアップグレードで top-k / min-p フィルタが暗黙に有効化され、ロールアウト分布が真の方策と乖離した結果、5〜10 反復後に性能が劣化した事例がある([[@2025__arXiv__Training Long-Context Multi-Turn SWE Agents with Reinforcement Learning]])。デコーディングパラメータを構成管理下に置く。 **スイッチのソフトウェアイメージも監視対象である**。イメージ変更後のポート間レイテンシを継続監視し、ファームウェア更新とバースト性ジョブの重なりを想定した検証体制を持つ([[@2024__SIGCOMM__RDMA over Ethernet for Distributed AI Training at Meta Scale]])。設定生成側でも、1 件のバグが数千デバイスに波及しうるため、決定論的でステートレスな生成と既存改修・新規構築の同一コードパス化が効く([[@2026__NSDI__Matryoshka - Realizing Hyperscale Data Center Network Design for the AI Era]])。 **変更の適用機会を障害と重ねる**。マシン割り当てを変えない変更(コード・データの修正)は既存のポッド環境を壊さず差し替え、緊急でない変更は次の障害時か既定ウィンドウ(たとえば 24 時間)にまとめて適用する([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。避けられない中断を、更新の適用機会に転用する。 ### 12.6 ジョブ側の最適化を運用に組み込むクラスタ側の最適化とジョブ側の最適化は直交する。一方を改善しても他方は解決しない。低 GPU 利用率の 706 件の問題は、データ操作 46.03%・モデル層 45.18%・ジョブ設定 4.82%・ライブラリ 3.97% に分布し、単一原因では非効率なホスト-GPU 転送 27.90%、バッチサイズ不適切 25.64%、モデルチェックポイント 16.43% が上位を占める。重要なのは、これらの 84.99% が少数のコード修正で解消でき、バッチサイズ拡大・非同期チェックポイント・自動メモリピニングの三修正の組み合わせで BERT 7.52 倍、Swin Transformer 3.95 倍の速度向上が得られた点である([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]])。単価が最も低い投資先はここにある。運用への組み込み方は二つ。第一に、ジョブ投入前の静的解析で問題を検出して修正提案を返す経路を作る(同上)。第二に、ワークロード側の不均衡を自動で均す。貪欲法によるシーケンス再分配だけで 23.9%、全ワーカー同期の計画的 GC で 12.6% のスループット改善が得られている([[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]])。 ### 12.7 成熟度モデル自組織がどの段階にあるかを判定し、次に投資すべき層を決めるための対照表である。各段階の記述はすべて本書で引いた実運用の到達点に対応する。 | 段階 | 可観測性 | 検知 | 復旧 | 指標 | 典型的な症状 | |---|---|---|---|---|---| | L0 反応的 | ハードウェアメトリクスのみ | 利用者からの申告 | 手動再起動 | GPU 割り当て率 | 「動いているはず」と「実は遅い」を区別できない | | L1 計測 | 第 1 層(電力・温度・利用率・ECC)+ ジョブ履歴 | 閾値アラート | 手動、手順書あり | 稼働率・MFU | 低利用率の理由を説明できない | | L2 診断 | + 第 2 層(反復時間・フェーズ・カーネル統計、合計 2% 未満) | ピア比較による自動検知 | 自動リトライ、隔離手順あり | ETTR・GPU 時間ベースの損失内訳 | 検知はできるが起因の層を取り違える | | L3 自動化 | + 第 3 層(非侵入の外部観測)+ 条件付き深掘り | 階層的な自動切り分け、ストラグラーを一級インシデント化 | 高速フェイルオーバー、継続/再起動の自動判定 | SG/RG/PG の三成分分解 | 自動層が構造的に取りこぼす障害クラスを列挙できている | | L4 予防 | + 選択的プロアクティブ検証 | ホスト単位の再発追跡による優先順位付け | 予備プールの自動補充、閉ループのノード復帰 | 計算効率とエネルギー効率の並記 | 残る課題が研究フロンティアと一致する | 段階を飛ばさないことが要点である。L2 の前に L3 の道具を入れても、参照系(ピア群・周期性・履歴)が育っていないため誤検知に埋もれる。逆に、L2 に到達したら次は道具ではなく**指標の移行**が効く。割り当て率から生産性へ、件数から GPU 時間へ、単一指標から層別分解へ(第 XI 部)。 ### 12.8 プレイブックの要点最後に、本部を通じて繰り返し現れた原則を 10 条にまとめる。 1. **測る単位は GPU 時間**。件数ベースの指標は、最も高くつく障害を脇役に見せる。 2. **絶対閾値より相対比較**。ピア群・周期性・履歴を参照系に取れば、ワークロードとハードウェアの異質性に自然に適応し、閾値の調整負荷が消える。 3. **単一の先行指標に賭けない**。751 のメトリクスと 10 種の XID をまたいで常に支配的な単一メトリクスは存在しない([[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]])。 4. **落ちていないことは健全であることを意味しない**。集合通信は障害を隠す。透過的なリルートは帯域を半減させながらジョブを走らせ続ける。 5. **損失曲線は正当性を測らない**。活動の指標と正当性の指標は別に持つ。 6. **単純な手法が大半を片付ける**。直接排除 32.52%、再試行 22.70%、コードロールバック 9.20% で 6 割超が解決し、最も重い機構を要したのは 1.23% にすぎない([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。投資順序をここから決める。 7. **検知は復旧までの時間を決める最初の一手**。独立した目的として最適化しない。検知・隔離・復旧を閉ループで結ぶ。 8. **可観測性は二層に分ける**。常時オンにできる軽い層と、条件を満たしたときだけ起動する重い層。前者が後者を起動する契機を作る。 9. **自動化できない障害クラスを明示する**。パイプライン依存によるマスキング、通信症状に隠れた演算ストラグラー、完全に重なった通信のストールは自動層が構造的に取りこぼす。手動深掘りの導線を用意しておく。 10. **最適化対象は GPU の稼働率ではなく学習の継続性である**。経営に答えるべき問いは「GPU がどれだけ忙しかったか」ではなく「同じ電力と同じ資本で、学習がどれだけ前に進んだか」である。  --- ## 第 XIII 部未解決問題と研究フロンティア本書が引いた文献の多くは、成果と同じ密度で限界を書いている。第 XIII 部はその限界を集めて、この分野がいまどこで詰まっているかを示す。研究者はここを起点に逆引きでき、実務者は「まだ買えないもの」の一覧として読める。 ![[Attachments/llm-training-ch13-frontiers.png]] *図 14. 第 XIII 部の研究フロンティア。観測、診断、予防、設計空間、事後学習、経済性を個別研究と未解決の接続問題に分けて示す。*（Source: [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]], [[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]], [[@2026__Vicinagearth__Efficient Training of Large Language Models on Distributed Infrastructures - A Survey]]） ### 13.1 観測できないものが残っている **GPU 内部の不透明さ**。SIMT 実行モデルの内側——ワープ分岐、メモリ結合、バンクコンフリクト、占有率変動——は、CPU と GPU の境界で計装しても見えない([[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]])。eBPF バイトコードを PTX へコンパイルして稼働中カーネルへ注入する方向は提案されているが、評価は単一 GPU のマイクロベンチマークに留まり、実ワークロードでのエンドツーエンド評価も、verifier が SIMT 実行モデルへどこまで安全性保証を与えられるかも未解決である([[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]])。 **層をまたぐ意味づけ**。各層を個別に計装できることと、そのイベントを学習処理の意味へ帰着させられることは別問題である。GPU ドライバ層・CUDA API 層・GPU 内部層の計装を、順伝播・逆伝播・重み更新・集合通信というスパンへ相関させる手法は現状存在せず、研究開発領域に留まる([[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]])。 **自動層が構造的に取りこぼす障害**。パイプライン依存によるバブル転送と勾配同期のアライメント効果が異常を覆い隠す例、断続的な JIT コンパイルによるストールの例では、5 段階の自動診断が失敗し手動深掘りを要した([[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]])。通信が計算と完全に重なる実装では、通信ストールがクリティカルパスに現れず見落とされる([[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]])。 **観測範囲の穴**。NIC 上の RDMA トラフィック計測は非侵入で細粒度だが、NVLink などのスケールアップネットワークとノード内の計算ストラグラーは監視外に残る([[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]])。スイッチ層からの黒箱診断はテンソル並列がノード内に閉じるため見えず、物理トポロジ情報で間接的に扱うほかない([[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]])。 ### 13.2 検知と箇所特定の残余 **部品種別の同定**。メトリクスの類似性から責を負うマシンを特定する手法はマシン単位までしか降りられず、どの部品が壊れているかの同定は人手に残る。秒単位の粒度では高速伝播する障害(GPU 実行エラー、PCIe のダウングレード)の再現率が落ち、スイッチ再起動で 600 台中 32 台が同時に落ちるような複数同時障害では外れ値の判別が難しい([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])。 **「再起動で直るか、修理が要るか」**。エラー報告だけではこの判別ができず、効率的な判定方法は未解決と明記されている([[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]])。修理は数週間から数か月かかるため、この判別の失敗はそのまま資源の遊休になる。 **しきい値設計の一般解**。ストラグラー判定を厳しくすると重い処理を担うマスターランクを誤検知し、緩めると適合率が下がる。実運用では経験的に 1 秒という閾値へ落ち着いているが、原理的な決め方は示されていない([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])。異種 ASIC 混在環境での動的負荷分散の inactivity-interval にも「常に最良」の値が存在しない([[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])。 **サイレントデータ破損の検知率**。集合通信が破損を全ワーカへ伝播させるため起因の特定が難しく、NVIDIA EUD の再現率は 70% にとどまる。規模拡大とともに SDC の頻度と影響が増し、学習のスケーラビリティを制限すると報告されている([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]])。 **診断ツール自体が障害を生む**。診断のために走らせたツールが周波数ロックを解除して GPU の意図しないダウンクロックを招いた事例がある(同上)。検知機構の副作用を評価する枠組みは整っていない。 ### 13.3 予防と予測の限界 **タイミング予測は成立していない**。数千 GPU 規模の本番クラスタで 5 モデルを横断評価しても、8 時間観測窓の最良 F1 は 0.4837 にとどまる。テレメトリはワークロードを跨ぐと相関がゼロ近傍まで崩壊し、障害前 24 時間と正常時の分布は KL 距離 0.09〜0.10 でほぼ完全に重複する([[@2026__arXiv__Don't Predict, Prioritize - Rethinking GPU Reliability Assessment]])。優先順位付けへの問題設定の組み替えは有望だが、履歴依存の手法が公開クラスタや密モデルから疎な MoE への大幅なアーキテクチャ変更へどう一般化するかは開いている。 **物理劣化と論理症状の接続**。光トランシーバ故障は平均 1.11 日前に予測できる([[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]])が、その物理劣化が輻輳制御の背圧として顕在化する前に劣化リンクを切り離せるか——予防型と反応型を接続する経路は未解決のまま残っている([[@2025__SIGCOMM__Hawkeye - Diagnosing RDMA Network Performance Anomalies with PFC Provenance]])。 **冗長の残量の可視化**。冗長機構が働いている間は劣化が見えない。HBM の row remap 件数や uplink の生存本数といった「残っている冗長」を棚卸ししないと、インシデント間隔が 719.4 時間から 151.7 時間へ漸減していく過程を捕まえられない([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]])。 **障害注入の空白**。AI システムを 6 層に分割して 142 本の論文を体系化したサーベイによれば、フレームワーク層は 6 種のうち 4 種、ツールキット層は 11 種のうち 5 種、プラットフォーム層は 11 種のうち 6 種が障害注入未対応である。とりわけ NCCL 障害・NVLink 障害・InfiniBand 障害という分散学習の基幹通信障害を、既存の障害注入ツールはカバーしていない([[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]])。自クラスタのレジリエンスを能動的に測る道具がまだない。 ### 13.4 設計空間に残る未解決 **異種環境での全対全スケジューリング**。異種クラスタ向けのスケジュール合成と、2 層ファブリック上の全対全スケジューリングは、それぞれ別の前提の下で成立している。両者の交点——異種環境での AllToAllv スケジューリング——は未解決のまま残る([[@2026__NSDI__HeteCCL - Synthesizing Near-Optimal Collective Communication Schedules for Heterogeneous GPU Clusters]], [[@2026__NSDI__FAST - An Efficient Scheduler for All-to-All GPU Communication]])。前者は SMT の直接適用が 64 GPU までで、それ以上は階層合成に依存しポッド境界を越える大域最適性を犠牲にする。 **シャーディング粒度と最適化の相互作用**。活性再計算と注意カーネルの融合実装は、活性メモリ式の同じ項を扱いながら、両者の実装上の相互依存は未整理の課題として残されている([[@2023__MLSys__Reducing Activation Recomputation in Large Transformer Models]])。シャーディング粒度がメモリの上限そのものを左右する以上、この整理は実務的な意味を持つ。 **注意機構の利用率の天井**。テンソルコアが世代ごとに倍増しても非行列積ユニットは据え置かれるため、注意機構の利用率は 70〜75% 付近に収束する。GEMM カーネルの 80〜90% に届かないのは構造的制約であり、アルゴリズム側の工夫だけでは越えられない([[@2026__arXiv__FlashAttention-4 - Algorithm and Kernel Pipelining Co-Design for Asymmetric Hardware Scaling]])。 **次世代トランスポートの収斂と検証**。RoCEv2 の構造的限界は 8 項目に整理され、10 年以内に置き換わるという予測が出ている([[@2023__IEEE Computer__Datacenter Ethernet and RDMA - Issues at Hyperscale]])。独立に開発された次世代方式が、いずれもパケットロス許容・選択的確認応答・パケット粒度のマルチパス負荷分散へ収斂している点は設計コンセンサスを示唆するが([[@2026__SONiC Workshop Japan 2026__SONiC Scale-Up Working Group から探る Scale-Up や Ultra Ethernet 機能の実装方法]])、大規模本番での比較検証はこれからである。 **シミュレーションの適用範囲**。学習固有の反復冗長性を利用した高速化は 3 桁の効果を出すが、パブリッククラウドやマルチテナントのようなランダム性の高いワークロードでは効果が薄れる([[@2026__NSDI__Supercharging Packet-level Network Simulation of Large Model Training via Memoization and Fast-Forwarding]])。設計検証を実機なしで済ませられる範囲には境界がある。 **トレース標準化の規模**。実行トレースの標準化は組織間のワークロード共有を可能にしたが、大規模ワークロードのトレースがギガバイト級に達する問題は未解決で、圧縮や階層索引は今後の課題とされる([[@2026__MLSys2026__MLCommons Chakra - Advancing Performance Benchmarking and Co-design using Standardized Execution Traces]])。 ### 13.5 事後学習・強化学習の未成熟 **自動障害管理はまだ危うい**。強化ファインチューニングの障害管理ベンチマークでは、緩和率が 46.25% に達する一方、severity 変化の中央値は −5.84% であり、失敗した介入が訓練を大きく悪化させうる([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]])。 **信用割当系の障害は見分けがつかない**。5 障害ファミリのうち信用割当系は、粗いテレメトリでは健全ランに近く、検知も診断も全手法で最難である(easy 設定でも 53.17%)。この系統の静かな劣化を捉える指標がまだない(同上)。 **手動介入への依存**。長時間の逐次訓練では、劣化やプラトー時に参照方策とオプティマイザ状態のハードリセットを入れるが、そのタイミングとハイパーパラメータ調整は手動介入に依存しており、自動化されたカリキュラムではないと明記されている([[@2025__arXiv__Scaling Up RL - Unlocking Diverse Reasoning in LLMs via Prolonged Training]])。 **小規模評価の外挿可能性**。少計算での優位が大計算での優位を保証しないという苦い教訓は、レシピ選択の方法論そのものへの問いである([[@2025__arXiv__The Art of Scaling Reinforcement Learning Compute for LLMs]])。 **非同期化のトレードオフ**。同期パイプラインはストラグラーに支配され、非同期化は方策ラグを持ち込む。データキューの上限で偏りを抑える運用は成立しているが、方策ラグの許容量を原理的に決める枠組みはない([[@2025__arXiv__AgentRL - Training Language Model Agents with Reinforcement Learning]], [[@2025__arXiv__Training Long-Context Multi-Turn SWE Agents with Reinforcement Learning]])。 ### 13.6 指標と経済性の未整理 **フリート効率指標の可搬性**。層別の生産性指標は特定のスケジューラとハードウェアの上で定義されており、他のスケジューラ基盤で同じ三成分を定義・測定して組織横断で比較するには、とくに「必要な資源をすべて同時に保有している」の定義を揃える必要がある。指標を移すこと自体が運用プロジェクトになる([[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]])。 **組織横断の数値比較**。復旧時間や故障間隔の改善倍率はいずれも自組織の従来運用に対する比であり、対象規模・ワークロード・既存運用の成熟度という母数が異なる。本書の各表を横並びで読むときも、この制約は外れない。 **計算効率とエネルギー効率の乖離**。新世代アクセラレータが計算スループットで優位でありながらエネルギー効率で劣るという構図は、訓練と推論の双方で独立に観測されている([[@2026__AI__Scalable and Energy-Efficient AI - System-Level Profiling of NVIDIA GPU Clusters for Distributed LLM Training]], [[@2026__IPDPS__Beyond Throughput - Performance and Energy Insights of LLM Inference Across AI Accelerators]])。両者を同時に最適化する調達・配置の枠組みは整っていない。なお当該試算の PUE 値は実測ではなくシナリオ上の仮定であり、電力上限を設定した構成も未評価である。 **規模拡大の経済合理性そのもの**。超大規模クラスタで訓練されたモデルが経済的に破綻して非推奨化された事例を踏まえ、10 万 GPU 級クラスタの価値はパラメータ規模の拡大ではなく速度とリスク低減にあるという整理が出てきている([[@2026__Glenn K. Lockwood Blog__AI doesnt need giant supercomputers after all]])。この整理が正しいなら、インフラ投資の正当化の論理そのものが書き換わる。 ### 13.7 この教科書自身の限界本書は wiki に蓄積された文献に基づいて構成しており、その範囲が本書の範囲である。以下は明示しておくべき偏りである。 - **公開されている運用のみを扱う**。本番運用の詳細を公開する組織は限られており、公開されない失敗は本書に現れない。 - **数値の母数が揃わない**。故障率・復旧時間・改善倍率は、それぞれ異なる規模・期間・定義の下で測られている。第 VII 部の表が示すとおり、指標名が同じでも測定対象が違う。 - **時点が固定されている**。ハードウェア世代とソフトウェアスタックは速く動く。第 IV 部の次世代トランスポート、第 XI 部の世代交代の記述はとくに陳腐化が速い。 - **推論インフラは扱わない**。学習と推論は資源を共有しつつ運用問題が異なる。本書は学習側に絞った。  --- ## 付録 ### 付録 A 用語集本書で繰り返し使う語のうち、部をまたいで登場するものを集めた。定義の出典は初出の部を示す。 | 用語 | 定義 | 主に扱う部 | |---|---|---| | SER | Scalability(拡張性)・Efficiency(効率)・Reliability(信頼性)。LLM 学習インフラを整理する三軸 | 第 I 部 | | MFU | Model FLOPs Utilization。観測スループットを理論ピークフロップスで割った比。走行中の計算効率を測り、停止時間を含まない | 第 I 部 | | ETTR | Effective Training Time Ratio(有効訓練時間比)。生産的実行時間を壁時計時間で割った比 | 第 I 部・第 IX 部 | | MPG | ML Productivity Goodput。スケジューリング・ランタイム・プログラムの三成分の積として生産性を分解する指標 | 第 I 部・第 XI 部 | | 性能可搬性 | 複数プラットフォームにまたがる計算効率の調和平均 | 第 I 部・第 XI 部 | | 3D 並列 | データ並列・テンソル並列・パイプライン並列の組み合わせ | 第 II 部 | | シャーディング係数 | データ並列でモデル状態を何分割するかを表す連続量。1 なら複製、ワーカー数ならフルシャード | 第 II 部 | | 活性再計算 | 順伝播の中間結果を保存せず逆伝播時に再計算し、メモリと計算を交換する手法 | 第 II 部 | | パイプラインバブル | パイプライン並列でステージが待機する空き時間。耐障害の資源として転用もできる | 第 II 部・第 IX 部 | | 集合通信 | AllReduce / AllGather / ReduceScatter / AllToAll などの多対多通信プリミティブ | 第 III 部 | | レール最適化 | サーバ内 GPU N 番の NIC を必ず Leaf N 番へ配線し、同一 GPU 番号間の通信を Leaf 内に閉じる設計 | 第 IV 部 | | ロスレス転送 | パケット損失を許さない L2 転送。RoCEv2 の前提であり PFC と輻輳制御で維持する | 第 IV 部 | | ギャングスケジューリング | ジョブが要求する全 GPU を同時に確保する方式。1 タスクの失敗がジョブ全体の再割当を招く | 第 V 部 | | 共有異常 | 共有クラスタでクォータが十分なテナントが、私有クラスタなら経験しないはずのキューイング遅延を被る現象 | 第 V 部 | | 差分可観測性 | 生データを比較する代わりに、時刻非依存の圧縮表現をワーカー間で比較する観測方式 | 第 VI 部 | | XID | NVIDIA GPU のエラー識別子。ハードウェア・インターコネクト・メモリの各カテゴリに分類される | 第 VII 部 | | SDC | Silent Data Corruption(サイレントデータ破損)。エラーを報告せず学習結果だけを汚染する障害 | 第 VII 部 | | グレイ障害 | 少なくとも 1 つのアプリケーションがシステムを不健全と観測しているのに、内部監視は健全と観測している状態 | 第 VII 部 | | グレーノード | 標準ヘルスチェックを通過しながら実ワークロードでは性能が落ちているノード | 第 VII 部・第 VIII 部 | | ストラグラー | 同期学習で他より遅れて全体を律速するワーカー | 第 VII 部・第 VIII 部 | | fail-stop / fail-slow / fail-hang | 停止する障害 / 遅くなる障害 / 進まないが落ちない障害 | 第 VII 部・第 VIII 部 | | 訓練不変条件 | 正常な学習で常に成立すべき規則。自動推論して実行時に違反を監視する | 第 VIII 部 | | レモンノード | 障害が集中する少数のホスト。全体の 1〜2% が大規模ジョブ失敗の大半に寄与する | 第 VII 部・第 VIII 部 | | インメモリチェックポイント | 共有ストレージでなくホスト CPU メモリへ状態を退避する方式。耐久性は確率で語られる | 第 IX 部 | | 機能的冗長性 | 同一パイプラインステージを担うデータ並列ワーカーが同一パラメータを持つ性質。復旧資源として使える | 第 IX 部 | | 弾性訓練 | ノード数の変動に追従して並列設定を再構成する訓練方式 | 第 IX 部 | | ロールアウト | 強化学習で方策からサンプリングして軌跡を生成する工程 | 第 X 部 | | RLVR | 検証可能報酬による強化学習。報酬モデル用 GPU を不要にする代わりに検証器の CPU 資源を要求する | 第 X 部 | | 方策ラグ | 非同期強化学習で、ロールアウトを生成した方策と更新される方策がずれること | 第 X 部 | ### 付録 B 読書ガイド役割別に、最短経路を示す。 **これから学習クラスタを立ち上げる人**。第 I 部で指標を決め、第 XII 部 12.1〜12.2 で 90 日のロードマップを取り、第 4.10 節の受け入れ検証項目を実施計画へ落とす。並列化の設計は第 II 部 2.9、通信設定は第 3.9 節を参照する。 **既存クラスタの効率を上げたい人**。第 XI 部で損失要因を分解し、投資先を決める。単価が最も低いのはジョブ側のコード修正(第 12.6 節)、次がノード健全性管理(第 VIII 部 8.6)である。指標が割り当て率のままなら、まず第 XI 部 11.1 の指標移行から始める。 **障害対応の当番**。第 12.3 節の判断表から入り、症状に応じて第 VIII 部の該当システム、第 4.7 節(ネットワーク)、第 IX 部(復旧)へ降りる。第 VII 部は「何がどのくらい壊れるか」の相場観として通読しておく。 **可観測性を設計する人**。第 VI 部を通読し、6.3 の計装手法比較表で自環境の制約(責任境界・オーバーヘッド許容量)に合う手法を選ぶ。6.9 の二層構造と指標設計チェックリストが設計の骨格になる。 **事後学習・強化学習の基盤を作る人**。第 X 部から入る。事前学習の常識が通じない箇所(10.1 の比較表)を先に押さえ、10.9 の可観測性チェックリストを最初に実装する。第 IX 部の復旧設計はそのままは適用できない。 **研究者**。第 XIII 部から逆引きする。各項目は本文の該当箇所と一次文献へ繋がっている。 ### 付録 C 数値を引用するときの注意本書の表に並ぶ数値は、そのまま比較できないものが多い。引用の際は以下を確認する。 1. **指標の定義が違う**。MTBE(コンポーネント単位のエラー間隔)、MTTF(ジョブ規模ごとの故障間隔)、MTBI(ノード単位のインシデント間隔)は別物である(第 VII 部 7.1)。 2. **母数が違う**。改善倍率はすべて各組織の従来運用に対する比であり、対象規模・ワークロード・既存運用の成熟度が異なる。 3. **運用期が違う**。バーンイン期を含む数値と定常運用の数値では 10 倍の開きがありうる(第 VII 部 7.3)。 4. **集約規則が違う**。エラーのバースト集約と XID の除外規則を揃えないと、桁が変わる(第 VII 部 7.9)。 5. **前提となるネットワーク品質が違う**。ストラグラーの主因が計算側だという結論は、専用クラスタの広帯域ネットワークが通信ボトルネックを事実上除去していることを前提とする(第 VIII 部 8.6)。 6. **シミュレーションと実測が混在する**。大規模の数値には実測でなくシミュレーションや外挿によるものがある。本文では都度明示したが、表だけを切り出すと区別が失われる。 7. **公開値がマスクされている場合がある**。守秘のため数値軸がマスクされた図から読んだ相対値は、絶対値として扱えない(第 I 部 1.4.3)。 ### 関連 - [[LLM分散学習]] — 分散学習システム全体の地図 - [[並列化戦略]] / [[テンソル並列]] / [[パイプライン並列化]] / [[シーケンス並列化]] / [[混合精度訓練]] - [[集合通信]] / [[データセンターネットワークトポロジ]] / [[RoCE設計課題]] / [[RDMAネットワーク監視]] - [[GPUクラスタ運用]] / [[GPUクラスタスケジューリング]] / [[GPUストレージIOデータパス]] / [[並列ファイルシステム]] - [[LLM学習モニタリング]] / [[GPU観測性]] / [[eGPU]] - [[GPUレジリエンス]] / [[ストラグラー]] / [[グレイ障害]] / [[訓練不変条件]] / [[プロアクティブ障害管理]] / [[障害予測]] / [[障害注入]] - [[耐障害LLM訓練]] / [[チェックポイント]] / [[弾性LLM訓練]] - [[強化学習スケーリング]] / [[エージェント型強化学習]] / [[検証可能報酬による強化学習]] - [[LLMスケーリング則]] / [[計算最適訓練]] / [[GPUエネルギー効率]] - 姉妹編: [[wiki/questions/KVキャッシュ管理の教科書]](推論側のメモリ管理)、[[wiki/questions/インシデント対応の教科書]]、[[wiki/questions/SLI-SLO教科書]]