2025-11-11T10:10:09.268407

Detecting Anomalies in Machine Learning Infrastructure via Hardware Telemetry

Chen, Chien, Qian et al.
Modern machine learning (ML) has grown into a tightly coupled, full-stack ecosystem that combines hardware, software, network, and applications. Many users rely on cloud providers for elastic, isolated, and cost-efficient resources. Unfortunately, these platforms as a service use virtualization, which means operators have little insight into the users' workloads. This hinders resource optimizations by the operator, which is essential to ensure cost efficiency and minimize execution time. In this paper, we argue that workload knowledge is unnecessary for system-level optimization. We propose Reveal, which takes a hardware-centric approach, relying only on hardware signals - fully accessible by operators. Using low-level signals collected from the system, Reveal detects anomalies through an unsupervised learning pipeline. The pipeline is developed by analyzing over 30 popular ML models on various hardware platforms, ensuring adaptability to emerging workloads and unknown deployment patterns. Using Reveal, we successfully identified both network and system configuration issues, accelerating the DeepSeek model by 5.97%.
academic

機械学習インフラストラクチャにおけるハードウェアテレメトリを用いた異常検知

基本情報

  • 論文ID: 2510.26008
  • タイトル: Detecting Anomalies in Systems for AI Using Hardware Telemetry
  • 著者: Ziji Chen, Steven W. D. Chien, Peng Qian, Noa Zilberman(オックスフォード大学)
  • 分類: cs.PF(パフォーマンス)、cs.AR(コンピュータアーキテクチャ)、cs.DC(分散コンピューティング)、cs.LG(機械学習)
  • 発表日: 2025年10月31日(arXiv v2)
  • 論文リンク: https://arxiv.org/abs/2510.26008v2

概要

現代の機械学習は、ハードウェア、ソフトウェア、ネットワーク、アプリケーションを統合した密結合のフルスタックエコシステムへと発展している。多くのユーザーはクラウドプロバイダーから弾性的で隔離された費用効率的なリソースを利用している。しかし、これらのプラットフォームアズサービスは仮想化を採用しており、オペレータはユーザーのワークロードについての洞察を欠いている。これはリソース最適化を阻害し、費用効率性の確保と実行時間の最小化に不可欠である。本論文は、ワークロード知識なしでシステムレベルの最適化が可能であることを提案する。我々はRevealを提案し、ハードウェア中心のアプローチを採用し、オペレータが完全にアクセス可能なハードウェア信号のみに依存する。30以上の一般的なMLモデルの様々なハードウェアプラットフォーム上での性能を分析することで、異常検知のための教師なし学習パイプラインを開発した。Revealを使用することで、ネットワークおよびシステム構成の問題を成功裏に識別し、DeepSeekモデルを5.97%加速させた。

研究背景と動機

核心的な問題

  1. 可観測性の欠如:クラウドプラットフォームの仮想化は基盤となるハードウェアを隠蔽し、オペレータは高レベルのワークロード情報を取得できず、システムレベルの最適化が困難である
  2. 性能ボトルネック検知の困難さ:MLワークロードは密結合のハードウェア・ソフトウェア特性を持ち、小さな非効率性がシステムレベルの性能低下を引き起こす可能性がある
  3. 既存ツールの制限:アプリケーションレベルの統合が必要、実行時オーバーヘッドが高い(最大90.2%)、カバレッジが限定的である

問題の重要性

  • GPU等の専用アクセラレータは高額である(単一GPUで数万ドル)
  • クラウドAIリソース需要は2030年までに年30%の成長が予測されている
  • わずかな構成エラーでも1.5倍の性能低下を招く可能性がある
  • 分散トレーニングは集合通信に高度に依存し、ネットワーク問題の影響を受けやすい

既存手法の制限

  1. 高レベルの可観測性への依存:ほとんどのツールはアプリケーションレベルの情報を必要とし、仮想化環境では利用不可能である
  2. 高いオーバーヘッド:Plumberは21%のオーバーヘッド、RL-Scopeは90.2%のGPUカーネル起動時間を追加する
  3. ルールベースの検知:ワークロード固有の閾値調整が必要で、移植性が低い
  4. カバレッジの限定:フレームワークアナライザーは通常、アプリケーションとフレームワークランタイムのみをカバーする

核心的な貢献

  1. Revealフレームワークの提案:高い移植性、デプロイ可能性、正確な分析能力を備えたハードウェア中心の分析および異常検知フレームワーク
  2. 重要性能指標の特定:MLワークロードのハードウェア上での動作を表現する低レベルの性能指標セットを特定し、収集したすべてのデータセットをオープンソース化
  3. 教師なし検知パイプラインの開発:コンテナ化されたMLワークロード内の性能問題を成功裏に検知し、システムボトルネックを識別してDeepSeekを5.97%加速

方法論の詳細

タスク定義

入力:ホストレベルのハードウェアテレメトリデータ(CPU、GPU、メモリ、ネットワーク、ストレージ指標) 出力:異常ウィンドウの検知、サブシステムの帰属、根本原因分析レポート 制約:オペレータがアクセス可能なハードウェアレベルの信号のみを使用し、高レベルのワークロード知識は不要

モデルアーキテクチャ

1. テレメトリコレクタ(Telemetry Collector)

  • perf、procfs、nvidia-smi、標準Linuxツールを使用して約150種類の独特な指標タイプを収集
  • CPUコアとGPUにわたって複製される場合、700以上の時系列チャネルに拡張
  • CPUオーバーヘッドは1.5%以下に維持

2. 指標の再分析と特徴抽出(Metric Reanalysis and Feature Extraction)

  • 指標フィルタリング:相関駆動型の枝刈り、|r|=0.5の閾値で約60%の指標を保持
  • 派生指標:IPC(実行スループット)、分岐予測ミス率、キャッシュミス率などを計算
  • スライディングウィンドウ:3秒のウィンドウ、1秒のステップで統計的および時間的特徴を抽出

3. 異常検知エンジン(Anomaly Detection Engine)

3つの相補的な教師なし手法を採用:

  • Z-スコア:標準化された偏差検知、99パーセンタイルを超えるウィンドウをマーク
  • PCA部分空間内のマハラノビス距離:指標間の相関性とスケール差を考慮
  • 孤立フォレスト(Isolation Forest):ツリーベースのアンサンブル手法、汚染率1%

技術的革新点

  1. ハードウェア中心のアプローチ:完全にハードウェア信号に基づき、高レベルの可観測性への依存を回避
  2. 複数検知器の融合:検知器間の一貫性を通じて誤検知を削減し、検知精度を向上
  3. サブシステム帰属:異常を具体的なハードウェアサブシステム(CPU、GPU、メモリ、ネットワーク、ストレージ)にマッピング
  4. 層間分析:単一の異常ウィンドウが複数の関連信号を含む可能性があり、より強力な異常証拠を提供

実験設定

データセット

  • MLアプリケーション:BERT、BART、ResNet、ViT、VGG、DeepSeek、LLaMA、Mistralを含む30以上の一般的なモデル
  • タスクタイプ:テキスト分類、表形式質問応答、画像分類、意味セグメンテーション
  • データセット:GLUE/SST2、WikiSQL、PASCAL VOC、CIFAR、MNIST
  • 実行回数:統計的信頼性を確保するため、各ワークロードを10回実行

実験環境

  1. HPCクラスタ
    • デュアルノード、NVIDIA Tesla V100 GPU(32GB)、Intel Xeon Platinum 8628 CPU
    • シングルノード、4つのNVIDIA H100 GPU(96GB HBM3)、Intel Sapphire Rapids CPU
  2. ローカルクラスタ
    • 9サーバー、AMD EPYC 7443P CPU(24コア)、256GBメモリ
    • 99コンテナ分散トレーニング設定

評価指標

  • 検知精度:異常ウィンドウ識別の正確性
  • サブシステム帰属:ハードウェアサブシステムへの正確なマッピング能力
  • 性能向上:エンドツーエンド実行時間の改善
  • オーバーヘッド評価:CPU使用率、ストレージ要件、検知器実行時間

実験結果

主要な結果

パフォーマンスオーバーヘッド

  • CPUオーバーヘッド:100msサンプリング間隔で1.2~1.4%、600msで0.6%以下に低下
  • ストレージ要件:フィルタリング前42~43 KB/s/ホスト、フィルタリング後14~22 KB/s
  • 検知遅延:特徴抽出1.46±0.02秒、エンドツーエンド2.26±0.17秒

異常検知効果

  • 指標安定性:99.75%のワークロード・指標ペアが統計的に有意な類似性を示す(p<0.05)
  • 構成間の一貫性:デフォルト対細粒度設定のIoU中央値0.50、ヒット率0.92

ケーススタディ

ケース1:NUMA異常(メモリサブシステム)

  • 検知:ウィンドウ118~123でIPC低下とL3ミス周期の増加を観察
  • 分析:ソケット間メモリとPCIeトラフィックが遅延を増加
  • 修復:NUMA認識バインディング、プロセスを単一NUMAノードにバインド
  • 効果:DeepSeek-7B微調整が1823.4±46.1秒から1714.6±70.0秒に改善(5.97%向上

ケース2:NCCL-QP構成エラー(ネットワークサブシステム)

  • 検知:CPU Busy%増加、ib0 TX/RXトラフィック急増、GPU電力低下
  • 分析:単一QP構成が完了処理のボトルネックを引き起こす
  • 修復:1QPから2QP構成に増加
  • 効果:実行時間が1825.4±46.1秒から1769.3±16.7秒に改善(3.1%向上

ケース3:IRQ不均衡(CPUサブシステム)

  • 検知:CPU Busy%分散とIRQカウンタの異常
  • 修復:irqbalanceサービスを有効化して割り込み負荷を自動分散
  • 効果:TCP再送異常が6.07%から3.51%に低下

ケース4:HugePages構成エラー(メモリサブシステム)

  • 検知:ノード間メモリ使用量の異常
  • 分析:事前割り当てされた1GiB HugePagesが「使用済み」メモリとして報告される
  • 修復:デフォルト2MiB HugePages割り当てに構成

ケース5:パケット損失注入テスト(ネットワークサブシステム)

  • 検知能力:ワークロード固有の再送とエラー引き起こされた再送を区別
  • 分析の深さ:トランスポート層カウンタからCPU IRQ急増とGPU停止まで、層間コンテキストを提供

異常パターン分析

  • HPCクラスタ:CPU側信号(Bzy_MHz、IRQ)が支配的で、異常特徴の50%以上に貢献
  • ローカルクラスタ:異常はメモリおよびI/Oサブシステムに集中、ライトバック急増とダーティページ蓄積が出現
  • 環境間:TCP再送は両環境で出現し、通常はNCCL不均衡に関連

関連研究

既存監視手法の比較

論文のTable 1に基づき、既存手法は3つのカテゴリに分類される:

  1. アプリケーションレベルアナライザー:TensorFlow Profiler、PyTorch Profiler - コード計測が必要
  2. システムツール:AWS SageMaker、Prometheus - ルールベースの検知
  3. 低レベルトレース:BCC/eBPFツール、RL-Scope - オーバーヘッドが高いまたはカバレッジが限定的

Revealの利点

  • 計測不要:完全にホストレベルのテレメトリに基づく
  • 全サブシステムカバレッジ:CPU、GPU、メモリ、ネットワーク、ストレージ
  • 自動異常検知:教師なしML手法
  • ハードウェア帰属:異常を具体的なハードウェアコンポーネントにマッピング

結論と考察

主要な結論

  1. ハードウェア中心のアプローチの実現可能性:ハードウェア信号のみを使用してMLワークロード異常を効果的に検知可能
  2. 教師なし検知の有効性:3つの検知器の組み合わせが複数の異常タイプを正確に識別可能
  3. 実際の性能向上:構成問題の特定と修復に成功し、顕著な性能改善を達成
  4. 高い移植性:91%のコードがプラットフォーム間で再利用可能

制限事項

  1. 静的構成:現在、固定サンプリングレートとウィンドウサイズを使用し、ワークロード動的性に適応できない
  2. 受動的検知:異常を検知できるのみで、問題を自動的に解決できない
  3. 手動修復:問題修復にはオペレータの手動介入が必要

将来の方向性

  1. 適応的サンプリング:ヒューリスティックに基づいてサンプリング周波数を調整
  2. 自動修復:IRQ再バランスの自動トリガーなど、軽量なランタイム介入を研究
  3. 検知器の拡張:より多くの教師なし異常検知手法を探索

深い評価

利点

  1. 革新性が高い:純粋なハードウェア信号によるML異常検知の初の提案で、クラウド環境の可観測性問題を解決
  2. 実験が充分:複数のハードウェアプラットフォーム上で30以上のモデルをテスト、豊富なデータセット
  3. 実用価値が高い:低オーバーヘッド(<2% CPU)、高い移植性(91%のコード再利用)
  4. 結果の説得力が強い:5.97%の実際の性能向上が手法の有効性を証明
  5. オープンソース貢献:完全なデータセットとツールキットを提供

不足点

  1. 検知遅延:2.26秒のエンドツーエンド遅延はリアルタイムアプリケーションに不適切な可能性
  2. 特徴エンジニアリング:指標選択と特徴抽出プロセスが比較的複雑で、専門知識が必要
  3. 評価範囲:主に学術環境でテストされ、本番環境の複雑性が新たな課題をもたらす可能性
  4. 根本原因分析の深さ:サブシステムへの帰属は可能だが、具体的な根本原因分析には人的介入が必要

影響力

  1. 学術的貢献:ML システム性能監視のための新しい研究方向を提供
  2. 実用的価値:ユーザー環境への非侵襲的な監視ソリューションをクラウドサービスプロバイダーに提供
  3. 再現可能性:オープンソースコードとデータセットが研究の再現と拡張をサポート

適用シーン

  1. クラウドサービスプロバイダー:ユーザーワークロードにアクセスせずに性能最適化が必要な場合
  2. HPCセンター:MLワークロード性能問題の監視と診断が必要な場合
  3. エッジコンピューティング:リソース制約環境での軽量な監視
  4. 研究機関:ML システム性能分析と最適化研究

参考文献

論文は77篇の関連文献を引用し、以下をカバーしている:

  • ML性能分析ツール:Hotline、RL-Scope、Plumberなど
  • 異常検知手法:孤立フォレスト、PCA、マハラノビス距離など
  • システム監視:Prometheus、AWS CloudWatchなど
  • MLフレームワーク:PyTorch、TensorFlowなど

総合評価:これは高品質なシステム研究論文であり、革新的なハードウェア中心の異常検知手法を提案し、クラウド環境下のMLワークロード監視の実際的な問題を解決している。実験設計が充分で、結果に説得力があり、学術界と産業界の両方に重要な価値を持つ。