# LLM学習モニタリング ## 定義 LLM 学習モニタリングは、長時間・大規模な LLM 訓練の進行中に異常(fail-stop / fail-slow、起因は計算側か通信側か)を**実行時に検知し、責のあるマシンへ局所化する**取り組みと、それを支える計装・計測の総体。訓練の同期的な性質(集団通信による全 rank 同期)ゆえに 1 ノードの異常が連鎖的に伝播し、健全なノードまで巻き込んで観測値を均す——この「連鎖効果(cascading effect)」が箇所特定を難しくする中心問題。([[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]] §1-2, [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]] §2) [[Fault Localization]] の AIOps 4 段階分類における Level 2 を、本番マイクロサービスでなく**訓練クラスタ**で解く下位領域に当たり、根本原因分析(なぜ)は別途オフラインで行う前提が広く共有される。 監視は 3 つの設計軸で整理できる: - **検知信号(何を見るか)**: ハートビート / 自己診断(MegaScale)、ホスト監視メトリクスの異常パターン(Minder)、ネットワークトラフィックのレート(Pulse)、CCL operator の実行情報(Aegis/Holmes/GreyHound)。 - **監視粒度**: OP-level(operator の start/end timestamp と平均スループット)か、sub-OP-level(operator 内部のマイクロ秒級のレート)か。 - **介入度(intrusiveness)**: 訓練コード/CCL を改変する計装依存か、改変不要の非侵入かのいずれか。クラウド事業者は利用者コードに触れないため非侵入が要件。 ## 横断的知見 - **検知信号が「死/劣化/内部の gap」の 3 層に分化し、互いを補完する**: 同じ訓練クラスタ信頼性でも、(1)[[MegaScale]] の頑健な訓練フレームワークは driver–executor の **ハートビート + 自己診断**で「死んだ/無応答」のノードを排除(reactive)、(2)[[Minder]] は停止前の **ホスト監視メトリクスの異常パターン**(per-metric LSTM-VAE + マシン単位の類似度)で「劣化し始めた」slow fault(PCIe downgrading 等)を秒単位で捉え、(3)[[Pulse]] は **ネットワークトラフィックのレート**をマイクロ秒粒度で見て、operator 内部の transmission gap(ストラグラー)まで可視化する。ハートビートは「死んだか」、Minder は「(ホストメトリクスが)劣化したか」、Pulse は「(通信が)内部で詰まったか」を見る——監視は単一機構でなく検知信号の異なる層の積層であり、3 者は同じ信頼性軸を別の解像度で覆う。(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]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **「マイクロ秒監視が要るがオーバーヘッドで未展開」という Minder の宿題に Pulse が別の層で答える**: [[Minder]] は秒単位のホストメトリクス監視ゆえ、高速に伝播する障害(GPU exec error・PCIe downgrading)や複数同時障害(switch reboot で 600 台中 32 台がオフライン)を取りこぼし、ms 単位監視を足せば検出可能だがオーバーヘッドゆえ未展開と述べる(§6.6)。[[Pulse]] はこの要求に **ホストメトリクスでなくネットワークトラフィック**で応える——計測を NIC のマイクロプロセッサに載せパケット処理のクリティカルパスから外す 3 層設計で、2000 flow/NIC・マイクロ秒粒度を訓練性能オーバーヘッドほぼ 0(iter time 不変、latency 1.52us vs 1.53us)で実現する。「細粒度の監視はオーバーヘッドを生む」という Minder の前提を、計測の置き場所(ホストから NIC 上の off-path へ)を変えることで覆した点が要。ただし対象はノード間 RDMA 通信に限られホストメトリクス(ECC/温度等)は見ないため、Minder と置換でなく補完関係にある。(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]]) - **粒度と介入度は独立した軸で、4 系統に展開する**: OP-level × 侵入的(Aegis/Holmes、CCL 改変)、OP-level × 非侵入([[GreyHound]]、function hooking + CUDA event)、sub-OP-level × 非侵入([[Pulse]]、NIC でのトラフィック計測)が実在する。GreyHound が「非侵入だが OP-level」でストラグラーのマシン単位の箇所特定に届かないことは、非侵入化だけでは粒度問題が解けないことを示す。Pulse は 2 軸を同時に満たす点を新規性に据える。OP-level の本質的な限界は「operator 内部の進行が見えずストラグラーと正常な rank が同一の duration を示す」「計算側のオーバーヘッドが通信の duration に織り込まれ両者を弁別できない」の 2 点で、これは粒度の問題ゆえ介入度をいくら下げても解けない。(Source: [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]]) - **検知信号は「死/劣化/内部 gap」に加え「ジョブ全層の計装」と「シミュレーション帰属」という上位の構えへ広がる**: 上記の 3 層(ハートビート/ホストメトリクス/トラフィック)に対し、(1)[[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] はアプリ(NCCL 進捗)・トランスポート(ms 級フロー/RDMA エラー)・ネットワーク(sFlow+INT)・物理(ハードウェアカウンタ)の **4 層フルスタック計装**をクロスホスト・階層相関し、明示ログのない fail-slow/fail-hang まで根本原因に到達して MTTLF を日→分(最大 25 倍)に縮める。(2)[[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] は軽量リアルタイム検知(ハートビート)に**停止時のスタックトレースのデータ駆動クラスタリング**を組み合わせ、起因が解けなくても並列グループ単位に過剰排除して復旧する。(3)[[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]] の SMon は監視を直接計測でなく **What-if シミュレーションによる帰属**(ヒートマップでワーカー障害/ステージ不均衡/シーケンス長不均衡を判別)として実装する。「何を見るか」(信号層)に加えて「どう束ねて起因へ写すか」(全層相関・クラスタリング・反事実シミュレーション)が監視設計の第二の軸として立ち上がる。(Source: [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]], [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]], [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]]) - **EROICA はオンラインのフルスタックプロファイリングという第 5 の検知信号軸を開拓する**: 既存の 4 層(ハートビート・ホストメトリクス・トラフィック・集合通信内部状態)に対し、EROICA は「全ワーカー同時プロファイリング + 関数挙動パターン差分」という観測面を加える。パターンは β(クリティカルパス占有率)・μ(リソース利用率平均)・σ(利用率標準偏差)の 3 次元ベクトルに圧縮され、タイムスタンプ非依存の分散比較を実現する。これによりハードウェアとソフトウェアの複合問題を統一的に診断する初の本番システムを提示し、~100,000 GPU・1.5 年運用で 97.5% の診断成功率を達成している。(Source: [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]]) - **検知信号に「集合通信ライブラリの内部状態」という第 4 層が加わる**: ハートビート(死)/ホストメトリクス(劣化)/ネットワークトラフィック(内部 gap)の 3 層に対し、[[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] は CCL([[集合通信]])内部のフロー単位・チャンク単位の進行状態を計装で露出させる第 4 の信号源を加える。Pulse が NIC 上で RDMA トラフィックの「量/レート」を外から見るのに対し、Mycroft は NCCL を 1,100 行で計装して CUDA kernel 実行・RDMA 送信・完了通知(CQE)の 3 段階のチャンク進行を内側から束ね(GPU_ready/RDMA_transmitted/RDMA_done)、`GPU_ready = RDMA_transmitted > RDMA_done` のような状態差から障害の所在(ローカル/リモート)まで判定する。トラフィック量だけでは「送れているのに遅い」の起因が割れないところを、CCL の内部依存が埋める——監視の検知信号が物理層・ネットワーク層・ホスト層に加えて通信ミドルウェア層へ降りる。ただし可観測性は集合通信層に限られアプリ層全体は見ない(Mycroft 自身の限界)。(Source: [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]]) - 性能回帰(persistent・ソフトウェア起因)はマクロ指標(throughput)では見えず、CPU 起因のマイクロ指標(issue latency 分布・void percentage)で初めて顕在化する。[[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]] はこの粒度を狙い、マシン単位の故障検知([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])とは監視対象の性質が補完的。(Source: [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]]) - [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] はフレームワーク内部(CUDA/Python/PyTorch/NCCL)の関数・オペレータ粒度まで降りる非侵入監視を示し、秒単位ホストメトリクスやマシン単位検出([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]]・[[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]])と補完的。(Source: [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]]) - 同じ CUHK / Huawei Cloud / Platform-X 陣営が、ログベース([[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]])とネットワークフローベース([[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]])で本番 LLM 訓練の監視を相補的に攻める。L4 は障害(failure)診断、LLMPrism は性能(fail-slow)診断と対象劣化が分かれる。(Source: [[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]], [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]]) - 本番 LLM プラットフォームの障害診断は訓練ログに約 90% 依存し、その膨大さ(障害あたり平均 16.92GB)が手動診断のボトルネック(平均 34.7 時間)になる。(Source: [[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]]) - **「LLM を診断器として組み込む」設計は 2024 年の Acme が最初期の本番事例で、後続の L4・LLMPrism と系統が連なる**: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]] の Fault-tolerant Pretraining(§6.1)は Log Agent(LLM)で正規表現フィルタを動的に書き起こし、Failure Agent([[@2023__arXiv__GPT-4 Technical Report|GPT-4]])が Vector Store + Query Engine から原因種別と緩和示唆を生成、診断結果を逆に正規表現へ追加する閉ループを構築し、手動介入を約 90% 削減したと報告する。これは L4 のログ自動分析・LLMPrism のブラックボックス性能診断と同じ「LLM をログ/シグナル要約器として現場に組み込む」流れの上流に位置し、self-consistency 投票による結果の安定化や、メタデータからの既存ルール流用で重複作業を避ける設計を先取りする。一方で評価が粗く(削減率の根拠が薄い)、GPT-4 への依存、偽陰性・偽陽性の定量がないという L4 や LLMPrism が改善対象とした弱点も最初から表れている。(Source: [[@2024__NSDI__Characterization of Large Language Model Development in the Datacenter]], [[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]], [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]]) - **検知信号の選択は heartbeat / host-metric / traffic の 3 信号スペクトルに収まり、近年の本番システムは複数信号の融合へ向かう**: 既存の 3 信号分類(ハートビート / ホストメトリクス / トラフィック)に今回の 3 本を位置づけると、(1)[[FlashRecovery]] は **ハートビート + デバイスプラグインの能動監視**で「死んだ/無応答」を数秒検知する heartbeat 系(Controller / Monitoring Processes / Device Plugins の 3 層、PyTorch 既定の collective ハング 1,800 秒を約 99% 短縮)、(2)[[Guard]] は **DCGM + カスタムサイドカーで 30 秒--1 分間隔スクレイプ**する host-metric 系(GPU 温度/利用率/クロック/消費電力 + ネットワークエラー/転送レート)、(3)[[C4D]] は [[ACCL]] を拡張して **通信/オペレーション/トランスポートの 3 層を監視**し通信遅延行列の行・列偏りから slow connection を特定する traffic・通信系に当たる。重要なのは Guard が単一信号に留まらず **GPU + ネットワーク + ステップ時間のマルチシグナル融合**を採り、ハードウェアエラーカウンタでなく**ユーザ可視の学習ステップ時間を一次シグナル**に据える点で、単一信号(死だけ/メトリクスだけ/トラフィックだけ)を超えて「どの信号が最終的なエンドツーエンド性能を説明するか」へ重心を移す。3 信号は排他でなく、heartbeat は速いが計算/通信ストール中のプロセスを取りこぼし(FlashRecovery 自身の限界)、host-metric はスクレイプ間隔に縛られ、traffic は通信律速ジョブに偏る——融合はこの相補性を束ねる方向である。(Source: [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]]) - **異常判定は「固定絶対しきい値を避ける」点で収束し、相対基準が周期性かピア群かに分岐する**: [[Pulse]] が均質性に基づくマシン単位の類似度を捨てて絶対指標(実通信時間/通信量)で局所化したのに対し、今回の 2 本は逆に相対基準を精緻化する。[[Guard]] は **同一役割のピアノード群を基準にした相対比較**(しきい値レス)でワークロード・ハードウェアの異質性に自然適応し、さらに**時間的フィルタリング**(連続する複数の評価ウィンドウで持続的乖離がある場合のみフラグ)で一時スパイクを抑える。[[C4D]] は **BSP(Bulk Synchronous Parallel)同期点という訓練の周期性**を基準にし、反復ごとの同期点で各 GPU の到達タイミングのずれから異常を読む。「絶対しきい値を置かない」(Guard はピア群、C4D は同期点周期、Pulse は operator 単位の実測)という設計が共通項で、相対の参照系が空間軸(ピア群)か時間軸(同期点周期)かで分かれる。ただし C4D の同期点基準は同期的訓練パラダイムを前提とし、非同期・パイプライン主体構成への一般化はソースからは読めない。(Source: [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]]) - **監視の出力が緩和/復旧に直結し、検知は独立タスクでなく検知--緩和ループの一部に組まれる**: 今回の 3 本はいずれも監視の出力をそのまま介入につなぐ。[[Guard]] は異常スコア(0--1)を **3 段階の段階的緩和**へ写す(<10% は検証保留、10--20% は次チェックポイントで緩和、>=20% は即時除外して代替ノード再起動)——監視結果が深刻度に応じた可逆/不可逆アクションの分岐になる。[[FlashRecovery]] は能動検知をそのまま**数秒での復旧**(限定再作成 + 規模非依存タスク再起動 + チェックポイントフリー 1 ステップ復旧)に直結させ、検知時間を RTO の一項として定量モデルに組み込む。[[C4D]] は検知を**隔離 → タスク再開**に接続し、エラー誘発ダウンタイムを 31.19% から 1.16% へ落とす。Pulse/Minder/XPUTimer が箇所特定までを主目的にするのに対し、これら本番システムは監視を「検知して終わり」でなく検知--緩和(復旧)の閉ループに最初から組み込む点で一線を画す。(Source: [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]]) - **単一の先行メトリクスに賭けず、ピア分布・障害種別・復旧判断をつなぐマルチシグナル設計が必要になる**: [[Minder]] はホストメトリクスのパターンを機械単位で比較し、[[Guard]] はステップ時間を一次シグナルに据える。[[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]] は 751 Prometheus メトリクスと 10 XID 同定 GPU 障害の分析で、NVLink、ECC、bus fault をまたいで常に支配的な単一メトリクスはないと報告する。NVLink + bus fault では interrupt count と runnable process が落ち、ECC では NFS GETATTR response time と page-out が急増するなど、信号は障害種別・発生後処理に依存する。したがって監視の設計は「汎用の単一前兆」ではなく、障害分類、ピア分布からの逸脱、復旧アクション(XID-based branching)を束ねる必要がある。(Source: [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]], [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]) - **サービス提供者の監視は「ユーザーの学習性能」と「プロバイダの資源・障害管理」を分けて始まる**: [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]] は、ユーザー視点の学習処理性能・計算資源利用率と、プロバイダ視点の障害・故障管理・計算資源利用率を分け、前者をワークロード分析、後者をリソース分析として整理する。責任境界によりアプリログ/コード計装ができないため、まず OTel + Grafana で GPU 電力・温度・メモリ、NVLink/NIC スループット、Slurm ジョブ履歴を可視化し、そのうえで深層学習処理スパンや集団通信スパンのトレース化を課題に置く。[[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]] はこの基盤の具体構成を開示した。GPU ノード 100 台上に DCGM Exporter・Node Exporter・Lustre Exporter(GSI-HPC)・IPMI Exporter・RDMA Exporter(自作)・opentelemetry-ebpf-profiler を配し、OTeL Collector Agent → OTeL Collector Gateway → VictoriaMetrics / VictoriaLogs / Pyroscope → Grafana というデータパイプラインを構築する。ダッシュボードは 3 つのビュータイプに分化する: (1) HPE Clusterview パネルプラグインによる**空間ビュー**(ラック→サーバ→GPU の入れ子構造)、(2) メトリクスの**時系列ビュー**(電力・温度・利用率)、(3) Slurm ジョブ履歴を MariaDB から取得し Grafana で表示する**ジョブビュー**(ガントチャート)。一方でログとプロファイルは「有効利用できていない」と述べ、リソース分析がうまくいっていてもワークロード分析には届いていないと率直に認める。これは Astral/Pulse/Mycroft のような研究が目指す「通信・処理過程の意味付き観測」と、クラウド事業者が最初に持てるメトリクス基盤の間に段差があることを改めて示す。(Source: [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]], [[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]], [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]], [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]], [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]]) - **監視は最高性能だけでなく、完走安定性と復旧設計の判断材料になる**: 同 SpeakerDeck の文字起こしでは、64 ノード級ジョブの不安定さが解消後も不安として残り、安定していた 32 ノード構成を選ぶ運用判断が語られる。これは Guard/FlashRecovery/C4D のような「異常検知から緩和へつなぐ」研究と同じく、監視出力が単なる可視化でなく構成選択・代替ノード・チェックポイント復旧の意思決定へ入ることを示す。集団通信中の GPU 即時切替は現実的でなく、固定メンバーで進む集合通信の性質上、チェックポイント復旧とリザーブドノードによる代替が現実的な復旧境界として現れる。(Source: [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]], [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]]) - **ARGUS は「訓練ヒエラルキーに沿った 3 層分解」という第 6 の観測軸を示し、常時稼働×細粒度×リアルタイム cross-rank の 3 要件を初めて同時達成した**: ハートビート(死)/ホストメトリクス(劣化)/NIC トラフィック(内部 gap)/CCL 内部状態/フルスタックプロファイリング(EROICA)という 5 つの観測軸に対し、[[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]] は「訓練コールヒエラルキー（Python 層/フレームワーク層/GPU ランタイム層）に沿って観測を 3 機構に分解し、各機構がそれぞれの層に専念してオーバーヘッド上限を個別設定する」という設計を追加する。CPU コールスタック(py-spy)・フレームワークセマンティクス(CUDA Event)・カーネル実行(CUPTI)の 3 機構はそれぞれ非侵入で動作し合計 2% 未満——「細粒度カーネルトレースは 5〜30% のオーバーヘッドが避けられない」という従来の制約を 10,000 GPU 以上の本番規模で初めて覆した。さらに KDE クラスタリングによる 3,700 倍圧縮（10 MB → 2.7 KB）で cross-rank リアルタイム比較を可能にした。EROICA も CUPTI を活用するが動的計装のオーバーヘッド(2〜25%)を自動マスキングで相殺するのに対し、ARGUS は「必要な観測だけを各層に閉じ込め上限を設ける」という分解戦略でオーバーヘッドを構造的に制御する。(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]]) - **段階的診断（L1〜L5）は「診断スコープの自動絞り込み」という構造を明示化し、既存の 1 段階検知とは設計レイヤーが異なる**: Minder・Guard・Pulse は「検知 → 局所化」を 1 ステップで完結させるのに対し、ARGUS は L1（反復時間異常ウィンドウ）→ L2（ストラグラーランク・ボトルネックフェーズ、秒オーダー）→ L3（劣化カーネル、分オーダー）→ L4/L5（手動深掘り、オンデマンド）という 5 段階を並行稼働させる。各レベルは異なるデータソース・粒度・レイテンシで動作し、診断対象を数万ランクから一桁まで自動に絞り込む。Case 3（パイプラインバブル増幅）・Case 5（通信症状に隠された演算ストラグラー）では L1〜L3 が検知に失敗しており、「自動レベルで確実に検知できない障害クラスには手動 L4/L5 が必要」という限界も明示している。(Source: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]]) ## 未解決の問い - EROICA のプロファイリングベース診断は動的計装(CUDA Cupti Activity API)のオーバーヘッド(2〜25%)を自動マスキングで相殺するが、MoE のような負荷不均衡ワークロードではマスキング精度が劣化するか。 - ハートビート系(MegaScale)・メトリクスパターン系([[Minder]])・トラフィック系([[Pulse]])・CCL 内部状態系([[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]])・先回り型ベンチマーク系(SuperBench)を統合した監視スタックは、各層の検知遅延・捉える障害・オーバーヘッドをどう分担すべきか。Pulse のネットワーク視点と Minder のホストメトリクス視点を融合すると箇所特定の精度・速度は上がるか([[GPUクラスタ運用]]/[[LLM分散学習]] の信頼性に関する知見と接続)。 - [[Pulse]] がマシン単位の類似度を使わない方針(似たマシンからの逸脱でなく、実通信時間/通信量の絶対指標で局所化する)と [[Minder]] の均質性に基づく類似度は、どちらが頑健か。MoE の expert parallelism で負荷が不均質になる構成では、Minder の類似度が崩れる一方で Pulse の operator 単位のメトリクスは耐えるのか(Pulse は Mixtral 8×7B の all-to-all で rank 単位の指標によりストラグラーを識別済み)。 - Pulse はノード間 RDMA 通信のみ可視で、NVLink 等のスケールアップネットワークやノード内の計算ストラグラーは監視外(TP group がノード内に閉じるため計算側の箇所特定はマシン単位止まり)。eBPF 的な GPU カーネルのプロファイリングとの統合(§9 future work)でノード内まで延ばせるか。 - OP-level のベースライン(Aegis/Holmes/GreyHound)はストラグラーに追加のベンチマークを要するが、ベンチマークは時間がかかり異常を再現できないこともある(オフラインツールの限界)。オンラインのトラフィック監視(Pulse)がオフラインベンチマークを本当に不要にするのは、どの障害クラスまでか。 - 診断遅延は Pulse が SOTA より約 0.7 秒高い(1 秒間隔のアップロードが律速)。アップロード間隔の短縮・NIC 上での事前集約で遅延を詰めるとオーバーヘッドとどうトレードオフするか。 - 直接計測系(ハートビート/ホストメトリクス/トラフィック)と、全層相関([[Astral]])・反事実シミュレーション(SMon の What-if)・スタックトレースクラスタリング([[ByteRobust]])という起因写像系は、どの障害クラスでどちらが速く正確か。両系を 1 つの監視スタックに統合したとき、計測コストと診断遅延はどう分担すべきか(→ [[耐障害LLM訓練]])。 - ログ系(L4)・メトリクス系([[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]])・ネットワークフロー系(LLMPrism)・フレームワーク内部トレース系(eACGM)の監視モダリティをどう統合すれば、性能劣化の検知から根本原因同定まで一貫してできるか。 - ARGUS の段階的診断（L1〜L3）は PP パイプライン依存によるバブル転送・grad_sync アライメント効果などの「マスキング機構」で自動検知が失敗するケース（Case 3・4）がある。これらのマスキング機構に対応した自動 L1〜L3 の改善は可能か、あるいは根本的に L4 手動確認が必要なままか。 - ARGUS の KDE クラスタリングは k 事前指定不要・履歴データ不要・線形計算量という要件を満たすが、MoE のエキスパート並列で負荷が高度に不均質な場合や、新規カーネルシーケンスへの適応はどれだけ高速か。 - 履歴依存の回帰検知は、公開クラスタやアーキテクチャ大幅変更(dense→sparse MoE)時にどう一般化するか。 - [[Guard]] のマルチシグナル融合(GPU + ネットワーク + ステップ時間)の重み付けは構成(dense / MoE、並列度、ネットワークファブリック)に依存するか。ピアベース相対比較は MoE のエキスパート並列で負荷が不均質になる構成でも崩れないか([[Pulse]] が均質性に基づく類似度を捨てた論点と接続)。偽陽性率 12.4% を「緩和が軽量・可逆」という前提に依存して許容する設計は、緩和が不可逆になる構成でも成り立つか。 - [[FlashRecovery]] の能動ハートビートは、計算/通信ストール中のプロセスを即座に検知できない盲点(論文が自認)をどう埋めるか。ストール検知に host-metric([[Guard]])や traffic([[Pulse]]/[[C4D]])の信号を重ねれば盲点は塞がるが、能動監視の低オーバーヘッドとどうトレードオフするか。 - スクレイプ間隔 30 秒--1 分([[Guard]])とマイクロ秒級計測([[Pulse]])の粒度差は何を取りこぼすか。Guard の host-metric は高速伝播する障害(GPU exec error、急峻なサーマルスロットリング)や複数同時障害を間隔内に均してしまわないか([[Minder]] の秒単位監視が ms 級障害を取りこぼす §6.6 の論点と同型)。一次シグナルをステップ時間に置く Guard と、operator 内部の transmission gap を見る Pulse は、同じストラグラーを別の時間解像度で見ているのか、別クラスの障害を見ているのか。 - [[C4D]] の BSP 同期点を基準にした周期性駆動の異常検知は、非同期・パイプライン並列主体やオーバーラップの深い構成へどう一般化するか。同期点が疎/不規則になると相対基準としての周期性は弱まるか。 - 30 秒スクレイプの多層メトリクスは XID 前の急峻な変化をどこまで捉えられるか。[[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]] は多くの信号が XID 時点で急に現れると述べる。秒未満のトラフィック監視([[Pulse]])や CCL 内部状態([[Mycroft]])を足すと pre-XID 検知率は上がるか、それとも GPU ドライバ層の急停止には別のテレメトリが必要か。 - OTel + Grafana のリソース分析基盤から、順伝搬・逆伝搬・重み更新・集団通信という学習処理スパンへどう意味づけを引き上げるか。ユーザーコードに入れない事業者環境では、深層学習フレームワーク層の文脈を非侵入に復元する方法が必要になる。([[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]]) ## 関連 - ソース: [[@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]] / [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] / [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]] / [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]] / [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]] / [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]] / [[@2025__IWQoS__eACGM - Non-instrumented Performance Tracing and Anomaly Detection towards Machine Learning Systems]] / [[@2025__ESEC-FSE__L4 - Diagnosing Large-scale LLM Training Failures via Automated Log Analysis]] / [[@2025__DSN__LLMPrism - Black-box Performance Diagnosis for Production LLM Training Platforms]] / [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] / [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]] / [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]] / [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]] / [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]] / [[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]] - 概念: [[Fault Localization]](訓練クラスタの Level 2 局所化) / [[GPUクラスタ運用]] / [[LLM分散学習]](Reliability 軸) / [[ストラグラー]] / [[耐障害LLM訓練]] / [[RDMAネットワーク監視]] / [[変化点検知]] / [[集合通信]] / [[根本原因分析]] / [[分散トレーシング]] - エンティティ: [[Pulse]] / [[Minder]] / [[MegaScale]] / [[Astral]] / [[Seer]] / [[ByteRobust]] / [[SMon]] / [[Aegis]] / [[Holmes]] / [[GreyHound]] / [[BlueField-3]] / [[NCCL]] / [[Yangtao Deng]] - 関連 MOC: [[分散深層学習 - MOC]] / [[HPC - MOC]] / [[異常検知 - MOC]] ## 出典 - [[@2026__NSDI__EROICA - Online Performance Troubleshooting for Large-scale Model Training]](§1 Overview, §2.1 障害分布, §4 設計, §6 評価: 97.5% 診断成功率・~100,000 GPU・1.5 年運用) - [[@2026__ASPLOS__Pulse - Fine-grained and Non-intrusive LLM Training Monitoring via Microsecond-level Traffic Measurement]](§1 Introduction, §2 Anomaly Localization in LLM Training, §6.1 Monitoring Granularity Analysis, §8 Evaluation) - [[@2025__NSDI__Minder - Faulty Machine Detection for Large-scale Distributed Model Training]](§2 Motivation, §6.6 評価, §7 Discussion) - [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]](§4 Fault Tolerance, §5 Troubleshooting) - [[@2025__SIGCOMM__Astral - A Datacenter Infrastructure for Large Language Model Training at Scale]](§3 フルスタック監視・階層相関・Seer) - [[@2025__SOSP__Robust LLM Training Infrastructure at ByteDance]](§3 監視・診断, §4 復旧) - [[@2025__OSDI__Understanding Stragglers in Large Model Training Using What-if Analysis]](§6 SMon) - [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]](CCL 内部状態のフロー/チャンク単位トレース・依存駆動の障害局所化) - [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]](§4.2 ピアベース相対比較 + マルチシグナル融合 + 時間的フィルタリング + 段階的緩和, §7.1 DCGM + サイドカーで 30 秒--1 分スクレイプ・ステップ時間を一次シグナル) - [[@2025__arXiv__FlashRecovery - Fast and Low-Cost Recovery from Failures for Large-Scale Training of LLMs]](アクティブ障害検知=ハートビート + デバイスプラグインで数秒検知, Controller / Monitoring Processes / Device Plugins の 3 層アーキテクチャ) - [[@2025__HPCA__Enhancing Large-Scale AI Training Efficiency - The C4 Solution for Real-Time Anomaly Detection and Communication Optimization]](C4D=ACCL 拡張で通信/オペレーション/トランスポートの 3 層監視, BSP 同期点での異常検知・通信遅延行列) - [[@2026__arXiv__From Detection to Recovery - Operational Analysis on LLM Pre-training with 504 GPUs]](751 Prometheus メトリクス、10 XID 同定 GPU 障害、単一支配メトリクスなし、30 秒スクレイプの多層監視)