# 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」という資源利用のフェーズ遷移である。 ## 子概念 - [[LLM分散学習]] ## 横断的知見 - **GPUクラスタ運用の前史には、専用計算機と遠距離データ通信を一体で設計する視点がある**: [[@2017__YouTube__平木敬教授 最終講義「計算機を創る」]]は、計算機の製作工程を構想・設計・製造・試験・デバッグまで連続した作業として示し、[[Data-Reservoir]]では遠距離研究データ共有のTCP性能問題を取り上げる。[[GPUクラスタ運用]]の現代的な障害・スケジューリング研究がクラスタ内部の GPU、通信、ジョブを分離して扱うのに対し、両者を同じシステムの境界条件として捉える視点を補う。(Source: [[@2017__YouTube__平木敬教授 最終講義「計算機を創る」]], [[@2004__SC__GPU Cluster for High Performance Computing]]) - **マルチテナント 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 がどのように認識されるかを必ず事前確認・配線設計に反映する必要がある。 - **Optics 劣化の運用対応は「予測型アラーム」と「事後の BER/FEC 切り分け」の二段構えになる**: [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]](OptProphet)が光トランシーバー故障を平均 1.11 日前に予測する予防運用を示す一方、[[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]] は実際の障害発生後、Pre-FEC/Post-FEC の BER と FEC Symbol Error Bins を見て劣化リンクを切り分ける事後対応の実務手順を示す。さらに短距離区間では光 Optics の代わりに AEC(Active Electrical Cable)を採用することで、Optics 特有の劣化モードそのものを一部区間で回避する設計判断も示される。予測(故障前アラーム)・事後診断(BER/FEC)・回避(AEC 採用)の三段は、光トランシーバー起因の障害という同一問題領域に対する異なる対応レイヤーとして整理できる。(Source: [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]], [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]) - **ハードウェア障害の物理的復旧作業は「液冷」という新しい変数を運用に加える**: SAKURAONE・Minder 等が示す GPU/NVLink/PCIe 起因の障害はセンサー・カウンタで検知できる論理層の話が中心だが、[[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]] は液冷(Direct Liquid Cooling)構成の NVL72 ラックにおける物理的なコンポーネント交換手順を示す——CDU/Manifold からの冷媒漏れリスクを避けるため、トレイ交換時に満水確認・水温監視・水圧監視という手作業のチェックが必須になる。GPU クラスタ運用が「検知の自動化」を志向する一方で、液冷という物理層は依然として手作業の慎重な手順に依存しており、障害復旧の MTTR に検知精度だけでなく物理作業の安全確認時間も加わることを示す。(Source: [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]) - **AI 研究クラスタのストレージは本番学習と異なりメタデータ IOPS が過半を占め、継続的ベンチマーク（CI）による性能退行検知が必須となる**: Meta FAIR の 8K GPU クラスタにおける 18 か月間の運用観測([[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]])では、共有 POSIX ストレージ（NAS/Lustre）においてメタデータ IOPS が全体の過半を占め、90 日間で容量が 125% 急増するバースト的な特性が示された。さらにストレージベンダーのファームウェア更新に伴い、同時アクセス時の `openat` ロック競合（5 秒ポーズ）によって FSDP チェックポイントレイテンシが最大 8 倍悪化する深刻な性能退行が発生した。合成 I/O ツールではなく、実際の PyTorch 操作を実行するベンチマークスイート（PRISM）を CI として組み込むことで、この退行を即座に検知・特定し修正パッチの検証が可能となった。GPU クラスタ運用において、コンピュート・ネットワークだけでなく共有ストレージ層も CI 駆動の適格性評価の対象に含めるべきであることを示す。(Source: [[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]]) - **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]]) - **障害箇所特定における「新規メトリクスへの day-one 対応」は、GPU クラスタ運用の保守コストを下げる独立した設計目標として明示化されつつある**: TSLoc([[@2026__KDD__TSLoc - Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters]]、KDD 2026)は、特定メトリクスと障害型の事前定義された関係に依存しない設計により、新規監視メトリクス追加時にモデル全体の再訓練を不要にし、MoE のダウンストリームエキスパート重みが自動適応すると報告する。これは [[Minder]] の決定木がメトリクス追加のたびに優先順位を学習し直す必要がある点と対照的であり、700 台超の本番クラスタで数ヶ月運用された実証を伴う。同時に、サンプリング間隔が 60 秒(Host 関連メトリクス)と粗いメトリクスでは検出時に情報が失われ Acc@5 が低下する(§5.5)ことも報告しており、「メトリクス追加への柔軟性」と「サンプリング粒度の限界」が別次元の課題であることを示す。(Source: [[@2026__KDD__TSLoc - Self-Supervised Faulty Node Localization Framework in Large-scale Training Clusters]]) - **大規模 GPU クラスタの運用境界は GPU ノードからネットワークのライフサイクル全体へ広がる**: 既存研究はジョブ失敗、ストラグラー、GPU・光トランシーバー障害の検知・復旧を中心に扱う。[[@2026__SIGCOMM__Networking for Meta's Gigawatt-scale AI fleet]] は、同じ運用問題をスケールアップ・スケールアウト・スケールアクロスのネットワーク領域へ展開し、障害リンクの迂回、稼働中更新、物理コンポーネント交換までを長時間訓練ジョブの継続条件として扱う。GPUクラスタ運用では、ジョブ層のレジリエンスとネットワーク層の保守可能性を別々に最適化できない。(Source: [[@2025__HPCA__Revisiting Reliability in Large-Scale Machine Learning Research Clusters]], [[@2025__APNET__Forewarned is Forearmed - Joint Prediction and Classification of Optical Transceiver Failures in Large-Scale LLM Training Clusters]], [[@2026__SIGCOMM__Networking for Meta's Gigawatt-scale AI fleet]]) - **ワークロード動態はスケジューラだけでなくネットワーク設計の入力になる**: 既存の GPU クラスタ研究はジョブサイズ・実行時間・障害分布からスケジューリングや予備資源を論じる。[[@2026__SIGCOMM__Networking for Meta's Gigawatt-scale AI fleet]] は、訓練・推論・ポストトレーニングなどの通信特性が異なるため、建設期間中も変化するワークロードを前提にベンチマークと適応可能性を設計要件とする。ワークロードカードをスケジューラだけで消費せず、ネットワークのトポロジ・容量・更新計画へ渡す必要がある。(Source: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]], [[@2026__SIGCOMM__Networking for Meta's Gigawatt-scale AI fleet]]) - **GPU クラスタ運用の性能限界は、計算資源の規模ではなく通信の非重複部分として現れる**: 2004 年の Stony Brook Visual Computing Cluster は 32 GPU ノードで LBM を実行し、28 ノードまではネットワーク通信を計算へ重ね合わせたが、28 ノード以上では非重複通信が増えて効率が 66.8% まで低下した。現代の大規模 LLM クラスタでも、ノード数・並列化方式・ネットワークトポロジの増加が通信クリティカルパスを作るため、GPU 利用率だけでなく隠蔽済み/未隠蔽通信を運用メトリクスとして分ける必要がある。(Source: [[@2004__SC__GPU Cluster for High Performance Computing]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]], [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - **クラスタ規模のスケール則は、同一問題サイズを保つかサブドメインサイズを保つかで反転する**: Fan ほかは各ノードの `80^3` サブドメインを固定すると 32 ノードで 49.2M セル/秒を得た一方、問題サイズを固定してノードだけを増やすと通信比率が悪化し、4 ノードから 16 ノードで GPU/CPU 高速化率が 5.3 倍から 2.4 倍へ低下した。現代の GPU クラスタで報告される「大規模化による効率低下」も、固定ワークロードの弱スケーリングと、問題サイズを増やす強スケーリングを区別して解釈する必要がある。(Source: [[@2004__SC__GPU Cluster for High Performance Computing]], [[@2024__ICPADS__Generic and ML Workloads in an HPC Datacenter]], [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]]) - **GPUクラスタ運用は物理構築の作業設計から始まる**: [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]]は、ラック納品、GPUラックの対向配置、End of Rowラックの中央配置、ケーブリングツールによって、少人数での構築・運用負荷を抑える実例を示す。[[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]が扱う液冷トレイ交換やOptics切り分けと合わせると、GPUクラスタ運用はジョブスケジューラや障害検知だけでなく、搬入・配線・排熱・安全作業まで含む。(Source: [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]], [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]]) - **追加投資を伴わない運用改善(自動キャンセル・GPU分割)は、複数大学が独立に到達する共通の実践知として蓄積されている**: 既存の知見が大規模専用クラスタ(SAKURAONE等)や超大規模フリート(Meta等)のワークロード動態・障害を扱うのに対し、[[@2026__PEARC__Getting the Most Out of Your GPUs]]は大学の共有HPCクラスタという異なる運用スケールで、[[自動ジョブキャンセル]](9大学で確認)と[[GPU多重化(MPS・MIG)|MIG変換]](実効GPU数15%増)という具体的な運用レバーを提示する。ジョブ単位メトリクス収集基盤([[Jobstats]]等)があれば、大規模専用クラスタでなくても定量的な容量最大化判断が可能である点は、GPUクラスタ運用の議論をハイパースケーラ以外の中規模組織にも拡張する。(Source: [[@2026__PEARC__Getting the Most Out of Your GPUs]]) - **ジョブ単位メトリクス収集とスケジューラDB(Slurm AdminComment)連携による軽量な長期効率追跡**: [[@2023__PEARC__Jobstats - A Slurm-Compatible Job Monitoring Platform for CPU and GPU Clusters]] は、時系列DB(Prometheus)の短期間保持(数ヶ月)と長期ジョブ会計を両立させるため、ジョブ完了時に要約JSONをgzip圧縮+Base64化してSlurm DBの `AdminComment` に格納するアーキテクチャを示した。これにより、Prometheusへの継続的高負荷クエリを避けつつ、`jobstats` や `job defense shield` が `sacct` 経由で即座に過去ジョブのCPU/GPU利用効率やメモリ浪費を評価できる。この軽量なジョブ単位サマリ基盤が、後の [[@2026__PEARC__Getting the Most Out of Your GPUs]] における自動ジョブキャンセルやMIG分割推奨などの運用自動化を支えるデータ的土台となっている。(Source: [[@2023__PEARC__Jobstats - A Slurm-Compatible Job Monitoring Platform for CPU and GPU Clusters]], [[@2026__PEARC__Getting the Most Out of Your GPUs]]) - [命令ミックスによるワークロード特性化] RWTH Aachen大学CLAIX-2023クラスタの9,468本番ジョブ(H100 SXM5、4週間)のNVML GPM命令ミックスを分析すると、IMMA利用はゼロ、DFMAは6%未満、HMMA(単精度/半精度テンソル演算)がテンソルコア利用を支配するが平均20%未満に留まり、CUDAコアではFP32が最多(約95%のGPU時間で20%以下)、INTが最も広く使われる命令型(ループ・アドレス計算に起因)である。(Source: [[@2026__SCAHPCAsiaWS__Leveraging NVML GPM for NVIDIA GPU Monitoring]]) - [PCIe/NVLinkデータ転送量によるジョブ特性化] 同データセットで、単一GPUジョブのPCIe H2D転送量(0.82 TB/GPU時)はD2H(0.21 TB/GPU時)の3.92倍、マルチGPUジョブではH2D 1.44 TB対D2H 0.49 TB(2.97倍)であり、H2D優位は学習データのエポック単位転送に対応すると解釈される。NVLink転送量(平均1.68 TB/GPU時)はPCIe D2HとH2Dの中間に位置し、PCIe対NVLinkのデータ量比は冗長なデータ移動の指標になりうる。(Source: [[@2026__SCAHPCAsiaWS__Leveraging NVML GPM for NVIDIA GPU Monitoring]]) - [チケット紐づきテレメトリのハードウェア/環境/ソフトウェア障害構成比] ByteDanceの1,000台超GPUクラスタのメンテナンスチケットコーパスは、ハードウェア障害41.05%、設備/環境障害12.98%、ソフトウェアスタック障害45.96%で構成される。このうちGPU固有・十分な事前障害テレメトリを持つ・妥当な前兆を示す4種(GPU Power Unknown Error、GPU Remapping Failure、GPU Temperature High、GPU Uncorrected Error Over ByteDance Limit)のみを予測対象として選定しており、チケット全体のうち予測可能な部分集合は限られることを示す。(Source: [[@2026__ISSRE__From Noisy Telemetry to Actionable Warnings - GPU Failure Prediction in Industrial Clusters]]) - **電力制約下のクラスタ運用では、未見ジョブの周波数キャップをスイープなしで決める需要がある**: [[@2026__POMACS__Minos - Systematically Classifying Performance and Power Characteristics of GPU Workloads on HPC Clusters]] の Minos は既定クロック 1 回のプロファイリングで最近傍を探し、PowerCentric/PerfCentric のキャップを予測してプロファイリング時間を約 89–90% 削減する。失敗ジョブや障害検出中心の運用知見に、電力スパイクと性能 SLO の同時制約という運用レバーを追加する。(Source: [[@2026__POMACS__Minos - Systematically Classifying Performance and Power Characteristics of GPU Workloads on HPC Clusters]]) ## 未解決の問い - 専用計算機を設計・製作する研究の工程管理と、現代の GPU クラスタでのジョブ・障害・ネットワーク運用を、同じライフサイクル指標(設計変更、試験、復旧、再利用)で比較できるか。([[@2017__YouTube__平木敬教授 最終講義「計算機を創る」]]) - **TSLoc の「障害検知の粒度限界」は Minder の ms 単位監視の必要性という既存の未解決の問いに定量的な裏付けを加える**: TSLoc は 60 秒サンプリングの Memory Usage で OOM 障害が他ノードへ伝播しきり、ノード間差異がほぼ消失して検出不能になる具体事例を報告した(§7)。これは下記「障害検知の粒度限界」の問いに対し、「どの程度の粗さで検出限界に達するか」の一事例を与えるが、TSLoc・Minder ともに ms 単位監視への移行コストの定量評価は示していない。 - **ロングテール構造を同じ指標で比較できるか**: 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/ネットワークだけでなく熱容量・室温・冷却余力をどの粒度で考慮すべきか。 - [[@2026__PEARC__Getting the Most Out of Your GPUs]]が示す大学共有クラスタの[[自動ジョブキャンセル]]・MIG変換という実践知は、SAKURAONE等の単一テナント専用クラスタの「ワークロード動態」観測とどう接続するか。専有クラスタでも、キャンセル率・低利用率ジョブの割合を同様の閾値設計(ウィンドウ平均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 として扱う設計はあり得るか。 - 異なるワークロードの通信パターンを、GPU ジョブのスケジューリングだけでなく、スケールアップ／スケールアウト／スケールアクロスの容量配分へどう翻訳すべきか。 - 長時間訓練ジョブを止めないネットワーク更新・物理交換の実装を、MTTR・失われた GPU 時間・訓練 goodput の共通指標でどう評価するか。 - LBM のような規則格子アプリケーションで確立された弱スケーリング/強スケーリングの区別を、現代の訓練・推論クラスタの運用ダッシュボードへどう標準化するか。 - ラック納品・ケーブリング・騒音・SFP相互運用性といった物理運用の指標を、MTTR、失われたGPU時間、訓練goodputなどのクラスタ運用指標へどう接続するか。 - AI 研究クラスタにおいて、開発環境（小規模 I/O 主体）とプロジェクト（大容量チェックポイント・データセット主体）でファイルシステムを分離する設計において、テナント間の I/O 干渉を最小化するためのストレージ QoS 制御ポリシーはどうあるべきか。 - Falconのピア相対特徴(同一IP・同一タスクを実行する最大8台のGPU群を基準とするz スコア・ランク)は、ジョブ配置がより疎な、あるいはピア群を構成しにくいクラスタ構成(異種混在ノード、単一GPUジョブ主体等)でも同等に有効か。 - Lonestar6 のように利用者に周波数制御権限がない共有クラスタで、Minos 相当のキャップ方針を誰が・どの API で適用すべきか。 ## 関連 - ソース: [[@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]] / [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]] / [[@2026__arXiv__PRISM Evaluating POSIX Storage Systems for AI Research Workflows]] / [[@2026__SCAHPCAsiaWS__Leveraging NVML GPM for NVIDIA GPU Monitoring]] / [[@2026__ISSRE__From Noisy Telemetry to Actionable Warnings - GPU Failure Prediction in Industrial Clusters]] / [[@2026__POMACS__Minos - Systematically Classifying Performance and Power Characteristics of GPU Workloads on HPC Clusters]] - エンティティ: [[SAKURAONE]] / [[SAKURA internet Inc]] / [[Meta AI Research SuperCluster]] / [[Meta]] / [[Minder]] / [[ByteDance]] / [[Pulse]] / [[BlueField-3]] / [[Delta]] / [[NCSA]] / [[ByteRobust]] / [[Astral]] / [[Aurora]] / [[Guard]] / [[OptProphet]] / [[Google]] / [[Borg]] / [[Arissa Wongpanich]] / [[Vijay Janapa Reddi]] / [[ソフトバンク株式会社]] - エンティティ: [[Actapio]] / [[AI Cloud Platform (ACP)]] / [[立見 祐介]] - 概念: [[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 ページ) - [[@2026__JANOG58__Rack-Scale GPUサーバーのNW設計と運用までの苦悩]](NVL72 Rack-Scale GPU の Optics BER/FEC トラブルシュート・AEC 採用・液冷トレイ交換の物理運用手順) - [[@2026__SIGCOMM__Networking for Meta's Gigawatt-scale AI fleet]](ワークロード適応、三つのネットワーク領域、障害迂回・無停止更新・物理交換を含むライフサイクル運用) - [[@2025__LY Corporation__AIインフラ革命 ─ 米国データセンターとGPUを支える技術基盤（Rethinking AI Infrastructure Part 1）]](ラック納品、400Gbps RoCEv2 Clos、排熱、配線、騒音、SFP相互運用性)