# GPUクラスタ運用 ## 定義 GPUクラスタ運用は、LLM 訓練を含む AI ワークロードを多数の GPU ノード上でスケジューリング・監視・障害対応しながら走らせる取り組みと、その過程で観測される **ワークロード動態**(workload dynamics)——ジョブのサイズ分布・実行時間分布・キャンセル/障害の比率・資源利用率・プロジェクト進行に伴うフェーズ遷移・障害の発生と復旧——の総称。[[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] は単一テナント・単一プロジェクトの LLM 開発(continued pretraining + fine-tuning)を 800 GPU クラスタで排他運用し、Slurm/テレメトリのログからこれらの動態を定量化する(§7)。中心的な観測は「小規模ジョブが件数を支配し、少数の大規模ジョブが GPU 時間の大半を占める」ロングテール構造と、「大規模 CPT → 中規模 fine-tuning」という資源利用のフェーズ遷移である。 ## 横断的知見 - **マルチテナント GPU クラスタのロングテールは LLM 以前から存在する**: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]] は Microsoft [[Philly]] の 75 日・96,260 ジョブで、実行時間が分から週単位まで広がり、0.5% のジョブが 1 週間超、GPU 数が多いジョブほど長く走ると示した(図2)。[[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] は 800 GPU の単一テナント LLM 開発でも「小規模ジョブが件数を支配し、少数の大規模ジョブが GPU 時間を支配する」と報告する。対象は 2017 年 DNN 訓練対 2025 年 LLM 開発、マルチテナント対単一テナントで異なるが、GPU クラスタ運用では「件数」と「GPU 時間」の支配者が分かれる構造が早い段階から観測されていた。(Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **LLM 専用クラスタでは「短ジョブ多数」と「GPU 時間少数支配」が同時に成立する**: [[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]] は [[Acme]] の LLM 専用 4,704 A100 GPU で、GPU ジョブ実行時間中央値が 2 分と短い一方、事前学習が件数 0.9〜3.2% で GPU 時間 69.5〜94.0% を消費すると示す。これは Philly の DNN 訓練クラスタのロングテールと SAKURAONE の単一プロジェクト LLM 開発の中間に位置し、「評価などの短い関連ジョブが件数を増やし、事前学習が GPU 時間を支配する」という LLM 開発固有の二重構造を補う。(Source: [[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]], [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **LLM 世代の研究クラスタでもロングテールは強まり、障害コストは件数でなく GPU 時間に現れる**: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] は [[Meta AI Research SuperCluster]] の 2 クラスタ(RSC-1 16k A100、RSC-2 8k A100)で、90% 超のジョブが 1 サーバ未満だが GPU 時間は 10% 未満、256+ GPU ジョブが GPU 時間の 66% 超(RSC-1)・52% 超(RSC-2)を消費すると示す。さらにハードウェア関連失敗はジョブ件数では 0.2% でも GPU 実行時間の 18.7% に影響し、大規模ジョブの再キューに伴う二次的プリエンプションが障害オーバーヘッドの 16% を占める。Jeon 2019 の DNN 研究クラスタ、Kokolis 2025 の LLM 世代研究クラスタ、SAKURAONE の単一テナント LLM 開発を並べると、件数・GPU 時間・障害コストを分けて測る必要が一貫して見える。(Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **失敗ジョブのコストは件数より GPU 時間で測るべきという原則は Philly から ByteRobust まで連続する**: Jeon 2019 では killed+unsuccessful が件数 30.7% だが総 GPU 時間の約 55% を消費する(表6)。[[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] はインフラ障害が件数 11% でも GPU 時間の 82% を消費すると報告する。障害の種類はユーザー/入力/チェックポイント/MPI と、現代 LLM 訓練のハードウェア/通信障害で異なるが、「低頻度または一部状態が GPU 時間を大きく食うため、運用指標は件数でなく GPU 時間で見る」という測定原則は連続している。(Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **障害分布は規模によって「頻度」と「優勢な型」が動くが、ハードウェア起因が支配的である点は両端で成立する**: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] は中規模(800 GPU・単一テナント)で 3 ヶ月 21 件、GPU 関連 42.9%・interconnect switch 23.8%・NVLink/PCIe 19.0%、大半がノード再起動で数分復旧と報告する。[[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] は超大規模(数千〜10,000 GPU・本番)で**タスクあたり平均 1 日 2 回**の障害、ハードウェア障害 55.8%(うち ECC error 38.9%)・ソフトウェア障害 28.0%(CUDA 14.6%/GPU exec 7.7%)・ネットワーク 6.0% という型別頻度を 7 ヶ月の実データから定量化する(表1)。規模が上がると頻度(1 日数件と月数件)も影響範囲(半千台のアイドル化とノード再起動)も跳ね上がるが、「GPU/ハードウェア起因が最多」という骨格は SAKURAONE 42.9%・Minder 55.8% で連続し、サーベイの LLaMA3 78% とも整合する。(Source: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **障害検知の自動化手法は規模によって分岐する——ノード単位の再起動とメトリクスのパターン検知**: SAKURAONE は中規模ゆえ Slurm drain とモジュール型サーバ設計で影響範囲を封じ、障害は概ねノード再起動で吸収できる(運用が単純)。一方 Minder は数千台規模で「1 件の障害が連鎖して半千台をアイドル化する」ため、停止前に異常なメトリクスのパターンを捉えて責のあるマシン 1 台を特定する専用の検出器を要する。規模が「待って再起動すれば済む」運用を破綻させ、先回り型の障害マシン検知を必須化する閾値が超大規模帯にある。(Source: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **「細粒度の監視はオーバーヘッドを生むから粒度を上げられない」という制約は、計測の置き場所で外せる**: [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] は秒単位のホストメトリクス監視ゆえ高速に伝播する障害(GPU exec error・PCIe downgrading)や複数同時障害(switch reboot で 600 台中 32 台がオフライン)を取りこぼし、ms 単位の監視を足せば検出可能だが **オーバーヘッドゆえ未展開**と明言する(§6.6)。[[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] はこの宿題に、ホストでなく **NIC のマイクロプロセッサ上の off-path** に計測を載せる 3 層設計で応え、マイクロ秒粒度・2000 flow/NIC を訓練性能オーバーヘッドほぼ 0(iter time 不変・latency 1.52us vs 1.53us・PCIe 0.3MB/s)で達成する。運用上の含意は「監視粒度の上限はオーバーヘッドで決まる」のではなく「計測をどこに置くか(ホストの on-path から NIC 上の off-path へ)で動かせる」こと。ただし Pulse が見るのはノード間 RDMA 通信のみで、Minder が捉えるホストメトリクス(ECC・温度・NVLink エラー等)は対象外ゆえ、両者は補完的であり置換ではない。(Source: [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - **「件数は少ないが GPU 時間を食う障害」が運用コストの本体で、ハードウェア物理層がその源泉である**: [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] は 9,600 GPU の本番で**インフラ障害が件数 11% でも GPU 時間の 82% を消費**すると観測する。源泉を物理層から見ると、[[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]] が NCSA Delta(A100/H100)で MMU/NVLink 以外の GPU エラーがほぼ 100% ジョブ失敗につながり 99.9% 可用性に 5% オーバープロビジョニングが要ると示し([[GPUレジリエンス]])、[[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] は超大規模での障害の現れ方を fail-on-start 4%/fail-stop 66%/fail-slow 13%/fail-hang 17% と分類する。さらに [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]] はクラッシュに至らない fail-slow(ストラグラー)だけで全 GPU 時間の 10.4% を浪費すると示す。SAKURAONE(GPU 関連 42.9%)・Minder(ハードウェア 55.8%)が示した「ハードウェア起因が最多」という頻度の骨格に、ByteRobust の「件数より GPU 時間で測れ」・GPU Resilience の「世代で信頼性の床が動く」・Stragglers の「クラッシュしない劣化も大コスト」という運用コストの内訳が重なる。(Source: [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]], [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]]) - **GPU ノード可用性は「nines」だけでなく日次ダウンタイムと node hours で運用負債として見える**: [[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]] は Delta A100 で GPU ノード可用性 99.5% を推定し、これは 1 日 7 分のダウンタイムに相当する。平均復旧時間は 0.88 時間、累計 5,700 node hours が GPU ダウンタイムで失われた。これは [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]] のジョブレベル 99.9% には 5% オーバープロビジョニングが必要という結論の前段であり、[[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] や [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] が示す「失敗の件数より失われた GPU 時間を測る」原則を HPC A100 クラスタでも補強する。(Source: [[@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]], [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **運用診断の対象が「集合通信の内部」と「GPU カーネルの内部」へ深掘りされる**: 障害分布が示す「ハードウェア/通信起因が支配的」という骨格に対し、起因の特定はより内側へ降りる。[[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] はブラックボックスな[[集合通信]]ライブラリの内部状態を露出させ、運用で頻発する「見かけ上のハング」(silent timeout)の原因ランクを 20 秒以内に特定する。一方 [[GPU観測性]] 系([[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]・[[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]])は eBPF でベンダー専用ツールに依存せず GPU/推論の内部を低オーバーヘッドで覗く。運用コストの本体である「件数は少ないが GPU 時間を食う障害」を詰めるには、クラスタ全体の障害分布の把握に加えて、通信ミドルウェアと GPU カーネルの内部可観測化が要る——監視の解像度が物理層からソフトウェア内部へ降りていく。(Source: [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) - **GPU 資源の事前計画(訓練時間予測)と運用時の障害検知・レジリエンスは「高価な GPU 占有を避ける」動機を共有する**: 運用時のレジリエンス研究([[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] の「件数 11% でも GPU 時間 82%」)が高価な GPU 時間の浪費を縮める方向なのに対し、事前計画側の [[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]] は予測を CPU 上で完結させ、サンプリング型(20B/128 A100/60 秒で 2 node-hour)の占有コストを回避する。どちらも「高価な GPU を無駄に占有しない」という同じ運用動機から、片や運用時の障害コスト削減、片や計画時の予測コスト削減へ向かう。(Source: [[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]]) - **LLM 専用クラスタは「GPU 利用率の二極化」と「補助資源の余剰」を同時に持つ**: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]] は [[Acme]] の 4,704 A100 で、SM Activity 中央値 ~40% は PAI の 2 倍、GPU メモリは半数が 75%+(60 GB)を消費する一方、CPU メモリは <50%、CPU・IB の 60% 超がアイドル、IB 帯域は最大 25% 未満しか使われないと示す(図 7)。電力では GPU が 65.7% を占め CPU は 11.2%(図 9)。これは Philly/PAI が見せた「GPU が余り CPU が混む」DNN マルチテナント像の反転で、LLM 専用クラスタでは GPU が殺到・CPU/メモリ/ネットワークが余剰という非対称が定常状態である。資源の余剰は ByteRobust の非同期チェックポイント([[耐障害LLM訓練]])や Acme の Trial Coordinator が活用する設計空間となる。(Source: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]], [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]]) - **Evaluation ジョブが「最短・最低 GPU 需要」にも関わらず「最長キュー遅延」を持つ逆転は、Pretraining 優先の予約構造から不可避に生じる**: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]] は Acme で Pretraining のために大半の GPU を予約し、Evaluation を低優先で余剰資源に流す結果、Evaluation のキュー遅延が他ワークロードより長くなることを観測する(図 6)。Acme の対応は preemption(復旧コスト過大で LLM に不向き)ではなく、Trial Coordinator による (1) モデルロードのノード単位 precursor job 分離、(2) メトリック計算の CPU ジョブ分離、(3) prior-based elastic scheduling で、makespan を 1.3〜1.8× 短縮した(§6.2)。LLM クラスタでは「公平キュー」よりも「ジョブ種別ごとに資源パイプラインを分ける」設計が運用最適に近い。(Source: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]]) - **EROICA の ~100,000 GPU・1.5 年の本番データは性能問題の根本原因分布の新参照点を提供する**: 44.4% がハードウェア起因(GPU/CPU/ネットワーク)、48.2% がアプリケーション層起因(コード/設定)。既存監視では 29.6% しかオンライン診断できず、残り 70.4% はオフライン実験を要するか未診断であった。この数字は「診断スコープが粗粒度監視の届かないアプリケーション層まで及ぶ」ことを定量化した最大規模の本番参照点であり、SAKURAONE(GPU 関連 42.9%)・Minder(ハードウェア 55.8%)の障害分布に「ソフトウェア/設定層が約半数を占める」という新たな次元を加える。(Source: [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]]) - **検知の入口データはドメインで分岐するが、成果は MTTR/MTTF/人的介入間隔という共通の運用指標で測られる**: 同じ「GPU クラスタの故障管理」でも、起因特定の入口に置くデータがドメインで分かれる。HPC 運用の [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]](Aurora 63,744 GPU)は RAS(Reliability, Availability, Serviceability)ログ・ジョブスケジューラログ・環境センサーを集中型メタデータベースに集め、「同じ物理位置で繰り返されるエラー」という相関イベントを判断材料にする。一方 LLM 訓練運用の [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]](Amazon、数千 GPU)は、ハードウェアエラーカウンタを一次シグナルにせず**学習ステップ時間**(ユーザ可視のエンドツーエンド性能)を一次シグナルに据え、ピアノード群との相対比較で集合通信の症状(帯域半減・サーマルスロットリング)を捉える。入口は RAS ログ対ステップ時間と分岐するが、両者が成果を語る尺度は揃う——Fine-grained は MTTR を手動比 最大 84 倍短縮、Guard は MTTF を 2.5 倍・人的介入間隔を 11 倍改善と報告し、MTTR/MTTF/人的介入間隔という運用指標が組織・ドメインを横断する共通の成果尺度になっている。さらに [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]](OptProphet)の「光トランシーバー故障を平均 1.11 日前に予測」は、これら事後対応(検知→緩和)の改善とは別軸の、予防運用(故障前アラーム)への転換を示す。(Source: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **中規模でも予備ノードが少ないと、運用判断がジョブ構成をほぼ固定化する**: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] は単一テナント 800 GPU でフェーズ遷移と障害対応を観測し、[[Minder]]/ByteRobust 系は数千〜万 GPU 規模の障害連鎖を扱う。これに対し [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]] は 63 ノード・504 GPU という中規模本番でも、60 ノード訓練 + 3 予備ノードという余裕の小ささにより、単一ノードセッションを使った意図的隔離が上位除外ノードを固定し、自動リトライの成否を左右することを示す。GPU クラスタ運用では、障害頻度だけでなく「予備ノード数 / 大規模ジョブ要求ノード数」という比率が復旧性の隠れた設計変数になる。(Source: [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]) - **クラスタ単位の GPU 利用率とジョブ単位の GPU 利用率は異なる分析層を要求する**: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]](Jeon ら、Philly)はクラスタ・スケジューラ観点から、局所性制約・ギャングスケジューリング・ジョブ失敗を低利用率の根本原因として特定した。一方 [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] は同じく Microsoft 社内 DL プラットフォーム上のジョブを対象としながら、観点を「個々のジョブのコードロジック」に絞り込み、最多原因がホスト-GPU データ転送の非効率(27.90%)・バッチサイズ不適切(25.64%)・モデルチェックポイント(16.43%)であることを示した。クラスタレベルのスケジューリング最適化と、ジョブレベルのコード品質改善は、どちらも GPU 利用率向上に寄与するが、互いが相手を自動的に解決しない——ギャングスケジューリングを改良しても DataLoader の `pin_memory` 設定ミスは残る。(Source: [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]], [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]]) - **フリート効率の指標設計は「有用な仕事」の定義にまで降りないと利用率の高さが空洞になる**: [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] が「クラスタ利用率は高くてもジョブ単位で GPU が遊んでいる」ことを示したのに対し、[[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]] は同じ問題をフリート規模で体系化し、Capacity・Occupancy・Duty Cycle のいずれも「本当に有用な計算をどれだけ達成したか」を測れないと明言する。MPG(= SG × RG × PG)はその反論として、スケジューリング・ランタイム・プログラムの三層で「生産的な仕事」を定義し直す。GPU 利用率という一枚岩の指標の限界と、多層分解による診断の必要性という観点で、Jeon 2019 のクラスタ層・Empirical Study 2024 のジョブ層・MPG 2026 のフリート横断層は連続している。(Source: [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]], [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]], [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]]) - **ジョブ単位の GPU 利用率低下の原因分布は、ソフトウェアエンジニアリング問題として見るとデータ層が最大である**: [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] の 706 件では 46.03% がデータ操作(ホスト-GPU 転送・リモートデータ読み込み・データ交換など)に起因し、モデル層(バッチサイズ・チェックポイント)の 45.18% と肩を並べる。これは [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]] の約 10 万 GPU・1.5 年本番データでハードウェア起因 44.4%・アプリケーション起因 48.2% という分類と、「ハードウェアとソフトウェアが半々」という点で符合する。ただし EROICA はクラスタ全体の性能問題原因の分布であり、本研究は低利用率ジョブに限った原因の分布であり、比較は参考値に留まる。(Source: [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]], [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]]) - **ハードウェア冗長は劣化を覆い隠し MTBI を漸減させる**: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] は Azure A100 クラスタの MTBI が初回 719.4 時間に対し 20 回目で 151.7 時間まで縮むこと、HBM 行リマップが 10 件超で回帰確率が 5.6%→83.3% に跳ね、ToR の冗長 IB uplink が半分を下回ると 2-node all-reduce 帯域が下振れすることを定量化した(Table 1, Figure 3-4)。SAKURAONE(中規模 21 件)・Minder(超大規模で 1 日数件)が示した「ハードウェア起因が支配的」という骨格に対し、**冗長そのものが劣化漸減を生む**という新しい増悪因子を加える。運用側は冗長の「全部修復」を恒常運用に組み込まなければ MTBI が時間とともに崩れる。(Source: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **プロアクティブ検証は「検証時間」を TCO の一部として最適化することで全検証より勝つ**: SuperBench Selector は Cox-Time 予測 + 貪欲法でベンチマーク部分集合を選び、Azure シミュレーション(30 日、1k ノード)でフルセット検証比 MTBI 1.11×・利用率 1.09×・検証時間 92.07% 削減を実現する([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] Table 4)。これは「件数より GPU 時間で測れ」という ByteRobust の原則(インフラ障害 件数 11%・GPU 時間 82%)を**検証側にも適用した**結果で、検知/緩和の事後対応と[[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]] の予防運用に続く第三の運用軸を提示する。(Source: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]]) - **異種 GPU サーバー混在では NIC-Leaf 配線の対応ズレが Spine 越えトラフィックの原因になる(ソース: [[@2025__JANOG56__AI ML基盤における800GbEスイッチ導入とその挑戦]])**: NVIDIA DGX H100 と DELL XE9680 を同一 Rail-Optimized クラスタに混在させると、GPU/NIC の物理ポート番号体系がベンダーにより異なるため、NIC と Leaf(Rail)の対応がずれて Spine 越えのリングが形成され分散学習性能が劣化する。Full Bisection Bandwidth 時代は帯域余裕で顕在化しなかったが、Oversubscription 構成(7:1 等)では直接性能劣化に繋がる。複数種サーバーでクラスタを構築する場合は NIC/GPU がどのように認識されるかを必ず事前確認・配線設計に反映する必要がある。 - **ML/汎用混在の HPC では ML ジョブがノード比率・投入件数比率を大幅に上回るエネルギーを消費し、冷却設計を脅かす**: [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]] は国家規模の HPC データセンター(SURF Lisa、338 ノード)で ML ジョブがノード数 15%・投入件数 9% に対してエネルギー 39% を消費すると定量化した。GPU ノードのラック合計 TDP(6,650 W)は冷却容量(5,500 W)を常に超過し、GPU 温度が 17.4% の時間で 90% 超えとなる。これは LLM 訓練クラスタ(ByteRobust・Minder 等)が示す「件数より GPU 時間・エネルギーで測れ」という原則を、ML/汎用の**混在 HPC**という異なる文脈で裏付ける。さらにクラスタ全体エネルギーの約 50% が未完了ジョブに費やされるという知見は、LLM 訓練系ソース(ByteRobust: GPU 時間 82% がインフラ障害に)と規模・用途が異なるにも関わらず、「失敗コストは件数でなく消費資源で見る」という測定原則の汎用性を補強する。(Source: [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]]) ## 未解決の問い - **ロングテール構造を同じ指標で比較できるか**: Jeon 2019 は実行時間分布、Kokolis 2025 はジョブサイズ別の件数/GPU 時間と障害オーバーヘッド、SAKURAONE はノード数別の件数/GPU 時間とキャンセル比率を主に報告する。形は接続できたが、テナンシー・スケジューラ・最大ジョブ寿命・プリエンプション方針が違うため、ロングテールを標準化して比較するにはどの単位(ジョブ件数、GPU 時間、goodput、失われた GPU 時間)を揃えるべきか。 - **キャンセル支配は LLM 開発に固有か**: GPU 時間の 73.5% がユーザー起因のキャンセル(損失曲線を見て早期終了する適応的制御)で、FAILED は GPU 時間の 0.3% のみ(§7.2 Obs.1)。これはバッチ指向の伝統的 HPC とは異なる対話的な AI ワークフローの性質とされる。MegaScale 等の本番ランでも同様のキャンセル比率が出るか、スケジューラはこれをどう前提化すべきか(チェックポイントに基づくプリエンプション §8.5)。 - **障害分布の規模依存**: 3 ヶ月 21 件の障害は GPU 関連が 42.9% で最多、大半はノード単位の再起動で数分復旧(§7.2 Obs.6)。これは [[LLM分散学習]] が記録する「LLaMA3 で障害の 78% がハードウェア起因」「Alibaba で 1,000 GPU 規模 84.8%/日」や MegaScale の「数週間で 100 回超の自動復旧」と、800 GPU 規模でどう連続するか。MTTF/MTTR は記録精度不足で SAKURAONE は非報告。 - **フェーズ遷移を前提にした弾力的スケジューリング**: 大規模 CPT → 中規模 fine-tuning の遷移(§7.2 Obs.5)は静的な資源割当の最適性を否定する。フェーズに応じたクラスタ構成の動的再配分を、単一テナントでどう実装するか。 - **障害検知の粒度限界**: [[Minder]] は秒単位監視ゆえ複数同時障害(switch reboot で 600 台中 32 台がオフライン)や高速に伝播する障害(GPU exec error・PCIe downgrading)を取りこぼし、ms 単位監視が要ると述べる(§6.6)が ms 単位はオーバーヘッドで未展開。障害分布のうちどれだけが秒単位で可視か、運用コストに見合う監視粒度はどこか。([[Pulse]] が部分回答: ネットワークトラフィックに限ればマイクロ秒監視をオーバーヘッドほぼ 0 で展開可能。だがホストメトリクスに基づく Minder の監視対象である ECC/温度/NVLink には適用できず、ホストの on-path 監視をマイクロ秒化する別解はまだ無い。) - **熱制約をワークロードスケジューリングに入れるべきか**: [[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]] は Kalos で 7B モデル訓練中にサーバ室温が約 5°C 上昇し、NVLinkError/ECCError が増えたと報告する。冷却増強で頻度は下がったが、GPU アイドル率の低さと季節要因が障害に結びつくなら、スケジューラは GPU/ネットワークだけでなく熱容量・室温・冷却余力をどの粒度で考慮すべきか。 - **ネットワーク監視とホストメトリクス監視の統合運用**: [[Pulse]](ノード間 RDMA トラフィック、マイクロ秒)と [[Minder]](ホストメトリクス、秒単位)は捉える障害が一部重なり一部相補的(PCIe downgrading は両者が捉え、ECC は Minder のみ、マイクロ秒の gap ストラグラーは Pulse のみ)。両者を 1 つの監視スタックに束ねたとき、検知遅延・誤検知・オーバーヘッドをどう最適配分するか。NVLink 等のスケールアップネットワークの per-flow 不可視性(Pulse の制約)をホストカウンタで補えるか(→ [[LLM学習モニタリング]])。 - **検知の入口データ(RAS ログ対ステップ時間)はどこまで相互移植可能か**: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]] の物理位置反復相関(RAS ログ駆動)と [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] のステップ時間一次シグナルは、それぞれ HPC バッチと LLM 訓練の事情に最適化されている。HPC の集中型メタDB に訓練ステップ時間を、LLM 訓練の健全性管理に RAS の位置相関を相互に取り込めば、急性故障と fail-slow を 1 つの入口で捉えられるか。それとも入口の分岐はワークロード固有で統合に利得は無いか。(Source: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]) - **MTTR/MTTF/人的介入間隔の組織横断比較は妥当か**: Fine-grained の MTTR 84 倍・Guard の MTTF 2.5 倍/介入 11 倍は、それぞれ自社の手動比・ベースライン比であり、母数(対象規模・ワークロード・既存運用の成熟度)が異なる。これら運用指標を組織を跨いでベンチマークとして並べるには、何を揃えて測るべきか。事後対応(MTTR 短縮)と予防運用([[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]] の 1.11 日前予測)は同じ指標系で比較できるか。([[障害予測]]) - 性能予測フレームワークをスケジューラに統合し、エネルギー効率も含めた割り当て最適化に使えるか。([[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]]) - ML/汎用混在 HPC での GPU 冷却容量超過は、GPU 配置(物理位置)を考慮したスケジューリングで緩和できるか。SURF Lisa では GPU2 の温度が GPU1 より 9% 高いことがわかっているが、冷却位置の良い GPU を高負荷ジョブに割り当てる GPU-position-aware スケジューリングはどこまで実効的か。([[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]]) - **MPG の 3 成分分解はスケジューラー横断で標準化できるか**: [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]] の SG > 95% は Google TPU + Borg 固有の結果。Slurm・Kubernetes ベースのフリートで同じ 3 成分（SG/RG/PG）を定義・測定し、組織横断で比較するにはどの部分を標準化すればよいか。特に SG の「all-allocated」定義はスケジューラーにより異なる可能性がある。 - 予備ノード数・単一ノード隔離・ギャングスケジューリングの制約を、復旧 SLO からどう逆算するか。[[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]] の 60/63 ノード構成では、予備 3 ノードの占有が自動リトライの失敗要因になる。大規模訓練ジョブ優先のプリエンプション、隔離ノードの再評価、予備ノード増強のどれが GPU 時間コストに対して有利か。 - **冗長修復ポリシーを「全部修復」前提に組み替えられるか**: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] は ToR の IB uplink を「最小本数だけ修復」して問題を閉じる現行運用が MTBI を漸減させると指摘するが、トリアージ優先(早期復旧)と全部修復(長期 MTBI 維持)はトレードオフ。SLA・SRE 工数・部材調達リードタイムを含めた「冗長予算(redundancy budget)」を運用 KPI として扱う設計はあり得るか。 ## 関連 - ソース: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] / [[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]] / [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]] / [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]] / [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] / [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] / [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] / [[@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]] / [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] / [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] / [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]] / [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]] / [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] / [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]] / [[@2025__arXiv__Efficient Fine-Grained GPU Performance Modeling for Distributed Deep Learning of LLM]] / [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]] / [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]] - エンティティ: [[SAKURAONE]] / [[SAKURA Internet]] / [[Meta AI Research SuperCluster]] / [[Meta]] / [[Minder]] / [[ByteDance]] / [[Pulse]] / [[BlueField-3]] / [[Delta]] / [[NCSA]] / [[ByteRobust]] / [[Astral]] / [[Aurora]] / [[Guard]] / [[OptProphet]] / [[Google]] / [[Borg]] / [[Arissa Wongpanich]] / [[Vijay Janapa Reddi]] - 概念: [[LLM分散学習]](Reliability/fault tolerance と重なる) / [[並列化戦略]] / [[オープンネットワーキング]] / [[Fault Localization]](訓練クラスタの machine-level 局所化) / [[LLM学習モニタリング]] / [[GPUレジリエンス]] / [[耐障害LLM訓練]] / [[ストラグラー]] / [[集合通信]] / [[GPU観測性]] / [[ML Productivity Goodput]] - 弱い接点(別ドメイン): [[テレメトリ]] - 関連 MOC: [[HPC - MOC]] / [[分散深層学習 - MOC]] ## 出典 - [[@2024__USENIX login Online__Understanding Workload Characteristics in Large Language Model Development]](Acme 6 か月トレース、Seren/Kalos 4,704 A100、ジョブ中央値 2 分、事前学習 GPU 時間 69.5〜94.0%、インフラ障害 GPU 時間 82% 超、高温障害) - [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]](§2.1 Figure 2: 44.4% ハードウェア起因・48.2% アプリケーション層起因の内訳, §1 オンライン診断率 29.6%) - [[@2019__USENIX ATC__Analysis of Large-Scale Multi-Tenant GPU Clusters for DNN Training Workloads]](75 日・96,260 ジョブ・14 仮想クラスタ、図2 実行時間ロングテール、表6 終了状態と GPU 時間) - [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]](§3 図3/6/8: ジョブ状態・ジョブ規模分布・二次的プリエンプション、§4 レモンノード検知) - [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]](§7 Observations:Obs.1–7, §8.3 Workload Dynamics, §8.4 Temporal Transition, §8.5 Scheduling Implications, §8.6 Positioning) - [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]](§2.1 Negative Impacts, §2.3 Faulty Case Studies + Table 1, §6.1/§6.6 Evaluation) - [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]](§4 Traffic Measurement on NIC Agent, §8.2 Overhead of Pulse) - [[@2025__DSN-W__Characterizing Modern GPU Resilience and Impact in HPC Systems - A Case Study of A100 GPUs]](§5 GPU ダウンタイム、平均復旧 0.88 時間、累計 5,700 node hours、可用性 99.5%) - [[@2025__SC__Characterizing GPU Resilience and Impact on AI - HPC Systems]](§5 ジョブ影響・可用性・オーバープロビジョニング) - [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]](§2.2 障害分布:件数 11%・GPU 時間 82%) - [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]](§3 障害の現れ方分類・根本原因分布) - [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]](§4 ストラグラーによる GPU 時間浪費 10.4%) - [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]](集合通信の運用診断・silent timeout の原因特定) - [[@2025__arXiv__Collective Communication for 100k+ GPUs]](10 万+GPU の通信スタック運用) - [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]](RAS/メンテナンスログ駆動・集中型メタDB・MTTR 手動比 最大 84 倍短縮) - [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]](ステップ時間一次シグナル・ピアベース相対検知・MTTF 2.5 倍/人的介入間隔 11 倍) - [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]](光トランシーバー故障予測・平均 1.11 日前アラーム) - [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]](ML/汎用比較; エネルギー 39%; 未完了ジョブにエネルギーの 50%; NODE_FAIL 相関 0.94/0.75; GPU 温度 17.4% 時間で 90% 超え) - [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]](Google TPU 本番フリート; MPG = SG × RG × PG; SG > 95% 全ジョブサイズ; 非同期チェックポイント・AoT コンパイル・プリエンプション調整; スライド 32 ページ)