# プロアクティブ検証 ハードウェア・ソフトウェアスタックを**インシデント発生前にベンチマーク群で能動的に stress テストし、潜在的な劣化や障害を顕在化させる運用方式**。リアクティブなトラブルシューティング(インシデント発生後に根本原因を追う)、ベンダーによる pre-qualification test(納品前の一回限り)、性能ベンチマーク(MLPerf 等、ランキング目的)とは区別される。 [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] が満たすべき三要件を整理した: 1. **Comprehensive**: ベンダ qualification を通過したクラスタでも実ワークロードでしか出ない劣化を捕える網羅性。 2. **Clear-cut**: 漸減する劣化と自然変動を区別する明確な境界。同じテストの繰り返しで判定がぶれない再現性。 3. **Cost-efficient**: 検証コスト < 期待インシデント損失。検証時間とインシデント被覆の trade-off を明示的に最適化する。 ## 設計問題と主要解決アプローチ([[SuperBench]] 由来) - **基準学習(criteria learning)**: ground truth が無い前提で、経験 CDF の片側距離による類似度クラスタリングで欠陥/正常の境界を引く。平均値や LOF/One-Class SVM のような外れ値検出では境界が不明瞭(Figure 6, 9)。 - **検証部分集合の選択(benchmark selection)**: Cox-Time 生存解析でノードのインシデント確率を予測し、$\Delta p / t_i$(単位時間あたりの確率減少)が最大の順に貪欲選択。NP 困難な 0/1 ナップサックの変種を $O(n^2)$ に近似(Algorithm 1)。 - **検証イベント設計**: (1) ノード追加・firmware アップグレード、(2) ジョブ allocation、(3) 顧客インシデント報告のいずれかをトリガとしてイベント駆動、加えて定期的な regular validation。 - **ネットワーク検証の高速化**: Clos トポロジ性質を利用した Full Scan $O(n)$ と、$k$-tier fat-tree の hop ベース Quick Scan $O(1)$ で、規模に依存しない検証時間を実現。 - **パラメータ自動探索**: ベンチマークの周期を季節分解で推定し、warmup/measurement 長を自己類似度しきい値で最小化(再現性 < 1% 低下で 67.5〜78.3% 時間削減)。 ## 横断的知見 - **トラブルシューティングの限界をデータで示せる**: Azure A100 では 38.1% のインシデントが復旧に 1 日超、10.3% が 2 週間超([[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] Figure 2)。事後対応のみでは平均故障間隔を回復できないという定量根拠が、プロアクティブ検証の経済合理性を支える。 - **「全検証」も最適ではない**: SuperBench の Selector はフルセット検証と比べ MTBI を 1.11×、ノード利用率を 1.09× 改善する(Table 4)。検証自体がノード時間を消費するため、**検証時間も TCO の一部として扱う**設計が鍵。 - **CDF ベースの基準は variation の大きい AI ベンチに強い**: MLPerf でも安定系で ±2.5%、高変動系で ±5.0% の variance がある中、平均比較ではしきい値の意味を保てない。CDF 形状で「全体としてシフトしているか」を見ることでハードウェア起因の漸減を捕える。 - **OSS 化により業界標準化が進む**: microsoft/superbenchmark は AMD Instinct や PyTorch/ROCm ドキュメントで参照され、vendor 共有のベースラインになる(§1)。 - **[[障害予測]] と組み合わせる**: Cox-Time 単独では予測しかしないが、SuperBench は予測を「次に何を検証するか」のアクションに変換した点で価値がある。生存解析の AIOps への落とし込み方として参照可能。 ## 未解決の問い - 推論ワークロード(LLM serving、MoE)や混合ワークロードに対するベンチマーク集合はどう設計すべきか。SuperBench は学習ワークロード中心。 - 検証部分集合選択の被覆率 $\mathcal{C}$ は過去 trace 依存。**未知の故障モード**に対する保険になっていないことを補強する仕組み(active testing、chaos engineering、[[障害注入]])との結合は。 - 「正常」のドリフト(firmware アップデート・ワークロード進化)に追随する基準更新ループは現状オフライン+定期再学習。**オンライン学習化**は可能か。 - マルチクラウド/オンプレ混在環境で、ベンチマーク基準の互換性をどう保つか。SKU・BIOS・ドライバ・ハイパーバイザ依存が大きい。 ## 関連 - ソース: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] - 概念: [[グレイ障害]] / [[プロアクティブ障害管理]] / [[GPUクラスタ運用]] / [[GPUレジリエンス]] / [[障害予測]] / [[障害注入]] - 製品: [[SuperBench]]