# GPU観測性 ## 定義 GPU観測性(GPU observability)とは、GPU 上で実行されるカーネル・メモリ転送・演算子・スケジューリングといった挙動を、性能ボトルネックや異常箇所の特定に足る粒度で外部から可視化する取り組み。ベンダー提供のプロファイラ(NVIDIA の CUPTI・NVBit・Nsight)が高い詳細度を持つ一方で、オーバーヘッドが大きい・稼働中カーネルを中断する侵襲的計装を要する・ベンダーロックインを伴う、という共通の課題を持つ。([[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) これを低オーバーヘッド・非侵襲・ベンダー非依存で代替しようとする系統が近年立ち上がっている。 ## 横断的知見 - **計装の「挿入時点」で 3 系統に分かれ、オーバーヘッドと粒度がトレードオフになる**: (a)**コンパイル時計装** — [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]] は LLVM パスで制御フローを静的に解いてバッファを事前確保し、Rodinia で全体 1.60×(中央値 1.26×)と類似研究比で 1 桁の低オーバーヘッドを得る。(b)**実行時 PTX 注入** — [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] は eBPF バイトコードを PTX に JIT して稼働中カーネルへ中断なしに注入する。(c)**ホスト側 eBPF フック** — [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]・[[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] はランタイム関数(uprobe)や GPU ドライバ呼び出し(ioctl)を傍受し、GPU 内部には踏み込まずホスト側からカーネル実行を再構成する。「先に制御フローを解く(コンパイル時)/稼働中に書き換える(PTX)/外から覗く(ホスト eBPF)」の差がそのままコストと観測対象の差になる。(Source: [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]]) - **ベンダー専用ツール回避が共通の動機**: CUPTI・NVBit・Nsight は eInfer・eGPU・TOPC のいずれもが「高オーバーヘッド/侵襲的/ベンダーロックイン」として明示的な比較対象に置く。eInfer はベンダー非依存で CUPTI に近い精度を、eGPU は NVBit ベースの gpumemtrace より低オーバーヘッドを主張する。(Source: [[@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 内部の死角が残る**: eInfer・eGPU はともに、SM 利用率などの GPU マイクロアーキテクチャ内部情報は依然ハードウェアカウンタ([[ハードウェアカウンタ]])に依存すると認める。eBPF はホスト側(ドライバ・スケジューリング・メモリ操作)の傍受に強いが、デバイス内部の可視性はカウンタや PTX 注入で別途補う必要がある。(Source: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) - **低オーバーヘッドが各系統で実証され始めた**: eInfer <4%、ProfInfer はランタイム速度低下 5% 未満(libbpf 最小 1.19%、token/graph レベルのみなら 0.1%)、TOPC は実行時間 1.5〜1.6×。低オーバーヘッドは「常時プロファイリングに近い本番運用」を可能にする点で各論文が価値とみなす。(Source: [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]], [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]], [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]]) - **観測性は「正しさ検証」の基盤にもなる**: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]](PICKER)は GPU 動的計装(NVBit 系)で全メモリアクセスを追跡し、カーネルの[[べき等性]]検証に用いる。GPU 観測性は性能診断だけでなく耐障害・スケジューリングの正しさ判定にも転用される。(Source: [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) - **全スタックトレースの計装方式で侵入度が分かれる**: [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] はバックエンド(FSDP)へパッチを当てる侵入方式、[[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]] は CPython PyEval_SetProfile + LD_PRELOAD で非侵入・プラグアンドプレイを実現し全スタック性とバックエンド拡張性を両立する。(Source: [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]], [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]]) - **「GPU利用率100%」の誤解は、時間使用率と能力使用率の混同として定式化できる**: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 2 パフォーマンス計測]]は、`nvidia-smi` の GPU Utilization のようにハードウェアのアクティブ時間/全体時間で表される指標を「時間使用率」、SM Activity のように並列性を考慮した活用能力/最大能力で表される指標を「能力使用率」と用語を分けて整理する(§2.3.2)。これは [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] や [[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]] が実測で示す「DCGM/GPU Utilization 100%でもテンソルコア使用率40〜50%」という現象に対し、両者が測っている対象が原理的に異なる指標(時間 vs 能力)であることを明示する用語的な裏づけを与える。既存の実証研究群が「平均値だけでは根本原因を隠す」と経験的に述べてきたのに対し、本書は「そもそも時間使用率は並列性を考慮しない指標である」という定義レベルの説明を提供する。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 2 パフォーマンス計測]] §2.3.2, [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]], [[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]]) - **プラットフォーム標準の GPU メトリクス監視が「平均値のみ」では低利用率の根本原因を隠す**: [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] が対象とした Platform-X は NVIDIA DCGM で GPU 利用率を収集し、平均 GPU 利用率 50% 以下をフィルタリング基準として低利用率ジョブを抽出した。しかし DCGM の平均利用率だけでは「なぜ低いか」——ホスト-GPU 転送待ち(27.90%)、バッチサイズ不足(25.64%)、同期チェックポイントのブロッキング(16.43%)——を区別できず、原因特定には別途コードレベルの人手分析が要った。標準的なプラットフォームメトリクス(DCGM 等)は利用率の閾値アラートには使えるが、根本原因の分類には粒度が不足している。(Source: [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]]) - **Meta の 4 層スタックは「測定→分析→最適化」を組織的に分離している**: [[@2023__SystemAtScale__AI Observability]] は (1)ベアメタルテレメトリ([[Dynolog]])・(2)高度イントロスペクション([[Kineto]]/Strobelight/[[Gpusnoop]])・(3)スケール分析プラットフォーム(自動回帰検知)・(4)フリートダッシュボードという 4 層に役割を分け、ジョブ/ユーザー/モデル/プロダクト別のフリートリソース帰属を実現する。同じ問題を研究論文群(eInfer・eGPU・XPUTimer)は「単一プロファイラをどう低オーバーヘッドにするか」と問うのに対し、Meta は「複数ツールをどうスタックとして組み合わせ組織的に運用するか」と問う。研究視点と産業視点の分断が浮かぶ。(Source: [[@2023__SystemAtScale__AI Observability]]) - **FLOPs/sec と rDevice hour/Byte は「効率」の 2 つの軸を測る**: Meta は FLOPs/sec(計算量/時間)を一次効率メトリクスとし、rDevice hour/Byte を正規化コストメトリクスとして使い分ける。FLOPs/sec は「GPU が計算を速くこなせているか」を評価し、rDevice hour/Byte は「その計算コストがモデル/プロダクト横断で高いか安いか」を評価する。[[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]] でも MFU(Model FLOPs Utilization)が同様の役割を担うが、Meta はコスト正規化指標を別途持つ点が独自。(Source: [[@2023__SystemAtScale__AI Observability]], [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]]) - **GPU 利用率の時系列波形は根本原因の手がかりを持つが、現状の監視スタックはこれを活用していない**: Platform-X のデバッグ手順では、利用率の「断続的なゼロ」はホスト-GPU 転送や分散通信起因、「一定の低水準値」はバッチサイズ不足、「エポック末の急落」はチェックポイントブロッキングという視覚的パターンが観察される([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]])。既存のベンダー専用ツール(DCGM / Nsight)は時系列の収集はできるが、パターンからの根本原因推定は手動。eInfer・eGPU・XPUTimer のような細粒度計装と組み合わせて、DataLoader のピニング有無やチェックポイント呼び出しを GPU 利用率の波形と突き合わせる「原因つき時系列観測」は、現時点では研究提案段階([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]] §5 のコードアドバイザー提案)であり、本番環境での実装は未解決である。(Source: [[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]], [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]]) - **GPU ゼロコード計装が CUDA API 層・ドライバ層・GPU 内部層の 3 階層に整理された**: [[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]]（p.56–57）は GPU ゼロコード計装の最先端を 3 層に整理した。(1) CUDA API 層: uprobes / libcudart.so でメモリ割当・転送・同期・カーネル起動関数をフック。Python プロセスとの紐づけ可能だが非同期や GPU 内部の詳細計測は困難。(2) GPU ドライバ層: tracepoints / kprobes で OS カーネルの範疇を計測。ランキュー深さや XID エラーを計測可能。(3) GPU 内部層: PTX（GPU 中間表現）コードへ eBPF コードを注入する bpftime。非同期でも GPU 内部基準の時刻がわかり、ワープやスレッド単位の粒度で計測できる。さらに p.57 では分散トレーシングへの帰着には各層のイベントを相関させる必要があるが、現状そのようなツールは存在せず研究開発領域であるとする。これは本ページの「ホスト側 eBPF は GPU 内部の死角が残る」知見を 3 層の構造として再確認し、[[eGPU]] の PTX 注入が GPU 内部層に相当することを一般聴衆向けに位置づけた。(Source: [[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) - **クラウド事業者の責任境界が GPU プロファイリングを制約する**: [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]] は、AI スパコンサービスではユーザーのアプリケーションコードを計装できず、アプリケーションログも取得できないため、プロバイダ側の可観測性が GPU/CPU/NIC/ストレージなどのリソース分析から始まることを示す。PyTorch Profiler は順伝搬処理の内訳を見せられるが、ユーザーが有効化する必要があり、報告例では遅延を増やすため、プラットフォーム要件には合わない。これは eInfer/eGPU/XPUTimer 系の「非侵入・低オーバーヘッド」要求が、責任境界から来る運用要件であることを補強する。[[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]] は同じ責任境界の制約を再確認しつつ、PyTorch Profiler のオーバーヘッドを EuroMLSys 2023 から引用して **1.42 倍の遅延増加**と定量化した。GPU 利用率 100% でもテンソルコア使用率 40–50% でようやく良い効率とする運用実感も口頭で補足されており、DCGM の平均利用率だけでは根本原因を区別できないという本ページの既存知見([[@2024__ICSE__An Empirical Study on Low GPU Utilization of Deep Learning Jobs]])を事業者視点で裏づける。(Source: [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]], [[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]], [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) - **CUPTI + NVTX を「回避対象」でなく「正面採用」する設計が、リクエストレベル帰属という eBPF 系にない目的で登場した**: 本ページが蓄積してきた eGPU・eInfer・ProfInfer・ARGUS はいずれも CUPTI/NVBit/Nsight を「高オーバーヘッド・侵襲的・ベンダーロックイン」の回避対象として位置づけてきたが、[[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]](TELLER、ASE '26)は CUPTI アクティビティ/コールバックと NVTX 動的フックをそのまま採用する。TELLER の目的は「低オーバーヘッドで常時計測すること」自体ではなく、「NVTX メッセージにリクエスト ID を符号化し、CUPTI の相関 ID でホスト呼び出しとカーネルを束縛して、GPU カーネルからリクエストへ遡れる意味的アンカーを作ること」にある(§3.2〜3.3)。オーバーヘッドは wall time +9.8%(eInfer <4%・ProfInfer <5%・ARGUS 1〜2% と比べ一桁大きい)だが、リクエスト単位の根本原因帰属という eBPF 系の先行研究が扱ってこなかった目的を達成する点で、「低オーバーヘッド化」と「意味的リクエスト帰属」という 2 つの異なる最適化軸が GPU 観測性研究に併存することが確認できる。(Source: [[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]] §3.2, 表10) - **NVTX の「動的 import 時フック」は、コンパイル時計装(TOPC)・実行時 PTX 注入(eGPU)・ホスト側 eBPF フック(eInfer)に続く第4の計装挿入時点として整理できる**: TELLER は Python レベルで NVTX フックを import 時に動的インストールし、vLLM のようなエンジンではステップレベルのラッパー関数がリクエスト識別子を NVTX メッセージへ符号化する。ソースコード変更・再コンパイル・カーネル中断のいずれも不要な点で eBPF ホストフックに近いが、対象がドライバ/ioctl でなくフレームワーク/エンジンの Python 関数である点が異なる——「どのレイヤーの API をフックするか」という軸(GPU ドライバ層 vs CUDA API 層 vs アプリケーション/エンジン層)が、既存の「挿入時点」の軸(コンパイル時/実行時/ホスト)と直交することを示す。(Source: [[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]] §3.2) - **CPU 側 CUDA API トレースが、GPU 観測性の実装入門として機能する**: [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]] は `libcudart.so` への uprobe により、メモリ割当・転送方向・カーネル起動・ストリーム/イベント同期をリアルタイムに可視化するチュートリアルである。CUDA API 呼び出しあたり約 2 µs のオーバーヘッドで、GPU 利用のライフサイクル(割当→H2D→カーネル→D2H→解放)を再構成できる。この実装は、GPU 内部に踏み込む PTX 注入(eGPU)の前段階として、ホスト側からの非侵襲計装がどのような粒度と限界を持つかを具体例で示す。(Source: [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) - **ARGUS は CUPTI Activity API 単体で「10,000 GPU 以上の本番常時稼働・2% 未満オーバーヘッド」を実証し、「カーネルトレースは高オーバーヘッド不可避」という仮定に反証した**: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]] は eGPU・eInfer・Neutrino のような「eBPF/PTX 注入で既存プロファイラのオーバーヘッドを下げる」方向とは別に、CUPTI Activity API を 3 経路アーキテクチャ（制御パス/収集パス/処理エクスポートパス）に分離することでコールバックのホットパスブロッキングを排除し、カーネルトレーシング単体で 1〜2% のオーバーヘッドを達成した。PyTorch Profiler が 20〜44% の遅延増加で OOM、nsys が常時稼働で訓練を破壊（オブザーバー効果）する実験と比較すると、「既存プロファイラが高コストなのは実装の選択の問題であり、原理的に不可避ではない」ことを示す。さらに KDE クラスタリングで生 10 MB を 2.7 KB に圧縮し、10,000 GPU スケールのリアルタイム cross-rank 比較を可能にした点は、「細粒度データは保存・比較できない」という別の制約も同時に覆す。6 ヶ月以上の本番デプロイはプロトタイプではなく生産システムとしての実証である。(Source: [[@2026__arXiv__ARGUS - Production-Scale Tracing and Performance Diagnosis for over 10,000-GPU Clusters]]) - **eGPU ブログ記事は既存 GPU ツールの制約を 3 類型に整理した**: [[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]] は (1)CPU-GPU 境界トレースツール(黒箱)、(2)ベンダー専用重weightプロファイラ(閉じたイベントモデル・本番不向き)、(3)研究ツール(CUPTI/NVBit/NEUTRINO の高オーバーヘッド・アセンブリ依存)という 3 類型を提示し、eBPF on GPU がそれらの制約をプログラマブル・低オーバーヘッド・ベンダー非依存で解消する方向を示した。これは既存の「ベンダー専用ツール回避」動機を体系化した位置づけにある。(Source: [[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]]) - **Nsight の限界は「クローズドイベントモデル」1 つでなく、独立した 4 つの設計制約に分解できる**: [[@2025__eunomia.dev__bpftime GPU Support - CUDA and ROCm eBPF Attachment]] は Nsight Systems/Compute を、固定イベント集合で任意述語フィルタが書けない点・カウンタ多重化とリプレイで本番常時運用に不向きな点・in-situ フィルタなしで数 GB トレースを全量エクスポートする点・NVIDIA 専用で CPU 側 eBPF インフラと統合できない点の 4 つに分解して批判する。ブログ記事([[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]])の 3 類型整理を「ベンダー専用プロファイラ」カテゴリについてさらに具体化したものであり、eGPU/eInfer 系が主張する「低オーバーヘッド」を、単一の数値ではなく設計上のどの制約を外すことで実現しているかを明確にする。(Source: [[@2025__eunomia.dev__bpftime GPU Support - CUDA and ROCm eBPF Attachment]], [[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]]) - **GPU 内部層の計装は、アタッチ型・専用マップ・ヘルパー関数という具体的な API 面を持つ**: [[@2025__eunomia.dev__bpftime GPU Support - CUDA and ROCm eBPF Attachment]] は eGPU/PTX 注入の実装詳細として、カーネル入口/出口/メモリキャプチャの 3 アタッチ型、GPU メモリ常駐の専用マップ(array/ringbuf)、ナノ秒精度タイマーやスレッドインデックス取得ヘルパー(ID 501-506)を提示する。これにより「GPU 内部層は PTX 注入で観測できる」という既存の抽象的な整理([[@2025__YAPC Fukuoka 2025__SREのためのテレメトリー技術の探究]])に、実際に何を計装できるかという具体的な語彙が加わった。(Source: [[@2025__eunomia.dev__bpftime GPU Support - CUDA and ROCm eBPF Attachment]]) - **計装対象を「コンピュートカーネル」から「通信カーネル」へ拡張すると、計装の挿入時点の議論に新たな軸「クロック同期」が加わる**: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]は本ページが蓄積してきた「コンパイル時計装(TOPC)/実行時PTX注入(eGPU)/ホスト側eBPFフック(eInfer)」のいずれとも異なる第4のケースを提示する。FabricPerfは[[Neutrino]](本ページ未収載のGPUカーネルプロービングツール、OSDI'25)を通信カーネル(送受信コード)向けに拡張し、アセンブリ層の命令(fence、bra、st)へプローブを挿入する点はeGPUのPTX注入に近いが、対象が単一デバイス上のコンピュートカーネルでなく複数GPUにまたがる通信であるため、計装単体では解決しない新たな課題——GPU間のタイムスタンプをどう同期させるか——が生じる。FabricPerfはこれをGPU内蔵デバイスクロックで完結するGPTP(GPU版Precision Time Protocol、intra-kernel jitter 101.8ns)で解き、既存の計装手法の議論には無かった「マルチデバイス間の時刻整合」という次元を GPU観測性の設計空間に追加した。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) - **NIC消失は「ホスト側eBPFの死角」を、GPU内部だけでなくネットワーク全体に拡張する**: 本ページの既存知見「ホスト側eBPFはGPU内部の死角が残る」はGPUデバイス境界の内側を問題にしてきたが、FabricPerfが対象とするScale-upネットワーク(NvLink等)ではNIC自体が存在せずCPU/OSに対して透過的なため、eBPF(eInfer・eGPU等)が依拠するホスト側フック(uprobe・ioctl傍受)がそもそも成立しない。GPU観測性の議論はここで「GPU内部の死角をどう埋めるか」から「ホストが原理的に関与できない通信をどう計測するか」へ一段階進み、計装をGPU内(通信カーネル)に完全収容する設計(FabricPerf)が唯一の選択肢になる。(Source: [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) - **ログベースのモデルテレメトリは、カーネル/ハードウェア計装を代替せず異なるレイヤーの観測を補完する**: 本ページが蓄積してきた計装系(eBPF・PTX注入・CUPTI等)は GPU カーネル実行・メモリ転送・SM占有といったハードウェア層の挙動を対象にするが、[[Meta]] の [[Logarithm]]([[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]])はモデル入出力テンソル・内部状態・勾配等のモデル層テレメトリを型付きログとして収集し、[[TensorBoard]] ダッシュボードをストリーミング API で駆動する。GPU観測性が「ハードウェアが何をしているか」を計装で捉える系であるのに対し、Logarithm は「モデルが何を学習しているか」をログとして捉える系であり、両者は訓練ジョブの異なる断面を覆う([[AI訓練ログデバッグ]])。ログはメトリクス・トレースに比べ書き込みコストが低く高スループットな詳細記録に向くため、GPU計装で捉えにくいモデル層の継続的な状態記録に log-based なアプローチが選ばれている点が対照的である。(Source: [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]]) - **GPU 観測性は単一のプロファイラから、収集・分析・改善提案を含む運用プラットフォームへ拡張される**: [[Zoomer]] は [[Kineto]] の GPU 実行トレース、DCGM の GPU メトリクス、[[Dynolog]] のホストテレメトリ、アプリケーション注釈、集合通信、[[StrobeLight]] の CPU／要求プロファイルを一つの分析パイプラインへ束ねる。従来の研究系ツールが計装方式とオーバーヘッドを主に最適化してきたのに対し、Zoomer はストラグラー、クリティカルパス、メモリ、負荷不均衡を自動分析し、ノートブックや自動修正差分まで出力する本番運用の統合例である。(Source: [[@2025__EngineeringAtMeta__Zoomer - Powering AI Performance at Meta's Scale Through Intelligent Debugging and Optimization]]) - **「ベンダーツールを置き換える」のではなく「複数のベンダーツールをそのまま組み合わせる」という第三の統合戦略がGPUデータベース領域から示された**: 本ページが蓄積してきたeBPF系(eGPU・eInfer・ProfInfer・TOPC)はNsight/CUPTI/NVBitを高オーバーヘッド・侵襲的として明示的に置き換え対象とし、Zoomer・AI Observability(Meta)は複数の自社ツール(Kineto・Dynolog・StrobeLight)を統合する。これに対し[[Valk]]([[@2026__arXiv__Over the Memory Wall, Into the Instruction Wall - The New Bottleneck in GPU Data Processing]])は、[[NVIDIA Nsight Systems]]・Nsight Compute(クロック制御あり/なしの2パターン)という**既存ベンダー製プロファイラをそのまま複数回実行し、後から出力を突き合わせて統合する**という第三の戦略を取る。オーバーヘッドを下げる独自計装は行わず、代わりに各プロファイラの既知の限界(Nsight Computeのend-to-endオーバーヘッド最大4,989倍、クロック固定による時間感度指標の歪み)を実測・文書化した上で、「どの指標をどのプロファイラから採用すべきか」を明示的に設計する。これはGPUデータベースのような専門ドメインでは、汎用計装基盤の開発よりも既存ツールの適材適所の組み合わせの方が実務的という、本ページ既存の産業/研究分断の知見(Meta AI Observabilityの「複数ツールをスタックとして組み合わせる」姿勢)に近い、しかし対象ドメインが訓練ワークロードでなくクエリ処理カーネルである点で新しい実例である。(Source: [[@2026__arXiv__Over the Memory Wall, Into the Instruction Wall - The New Bottleneck in GPU Data Processing]] §4 Valk, §4.1 Profiler Overhead, Table 3・Table 4) - **GPU観測性の対象が「GPU内部」から「GPU間の通信経路上のサーバコンポーネント」へ広がる、Zoomerとは異なる統合の切り口**: 本ページのZoomer(Kineto・DCGM・Dynolog・StrobeLightの統合)は単一サーバ内のGPU実行・ホストテレメトリを束ねる統合だが、[[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]](ICLens)は「GPU-to-GPU通信がCPU・GPU・Root Complex・RNICという複数コンポーネントを経由する」ことに着目し、[[NVIDIA Data Center GPU Manager]](dcgm-exporter)・拡張版Intel pcm・procfsベースRNIC Exporterという異ベンダーのExporterをPrometheusへ統合してTX/RX方向別に可視化する。Zoomerが「一つのGPUで何が起きているか」を掘り下げるのに対し、ICLensは「GPU間通信が経路上のどのコンポーネントで詰まっているか」という横方向の観測を扱う点で、GPU観測性の対象軸に「単一デバイス深掘り」と「通信経路横断」という区別を加える。(Source: [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]], [[@2025__EngineeringAtMeta__Zoomer - Powering AI Performance at Meta's Scale Through Intelligent Debugging and Optimization]]) - **GPU観測性の対象が「GPU間(サーバ内/サーバ間通信)」からさらに「単一GPUパッケージ内部のチップレット間ネットワーク」へ一段深く潜る**: 本ページが蓄積してきた通信観測系(ICLens=GPU-to-GPU経路、[[FabricPerf]]=ノード間scale-upネットワーク)はいずれも複数デバイス・複数サーバをまたぐ通信を対象にするが、[[@2026__SIGCOMM__Understanding and Profiling the Accelerator Chiplet Network Using PingPoint|PingPoint]]は単一GPUパッケージ内部でcompute chiplet・IO chiplet・memory moduleを接続するAccelerator Chiplet Network(ACN)を対象にする。ICLens・FabricPerfがハードウェアカウンタ/GPU通信カーネルへのプローブでノード間・デバイス間の帯域を可視化するのに対し、PingPointはtarget kernelとpingマイクロベンチマークを1つのfused kernelへ融合しCooperative Groupsのgrid-wide barrierで整合させるという、[[Pingmesh]]由来のin-situソフトウェアプロービングをGPU内部ネットワークへ適用した点が新しい。GPU観測性の対象階層は「単一デバイス内部(SM/カーネル実行)」「単一パッケージ内チップレット間(ACN、PingPoint)」「サーバ内GPU間(ICLens)」「ノード間scale-up(FabricPerf)」の4層に整理できる。(Source: [[@2026__SIGCOMM__Understanding and Profiling the Accelerator Chiplet Network Using PingPoint]], [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]], [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]]) - **CU/SM占有率ベースの空間分離だけでは干渉を防げない——チップレットネットワーク経由の輻輳伝播が別の観測対象になる**: 本ページの既存知見はGPUリソース分離をCU/SM占有率やメモリ帯域幅の競合として扱ってきたが、PingPointのCase #3(§5.3)は、非重複CUに配置し完全に空間分離したカーネル同士でも、ACNの共有リンク経由で平均遅延が6.1–6.2×、tail遅延が6.2–10.6×悪化し帯域幅が58–85%低下することを実測で示した。GPUリソース管理研究の多くが前提とする「CU競合ゼロ=干渉なし」という仮定は、チップレット型アクセラレータではACNレベルの輻輳伝播により成立しない。(Source: [[@2026__SIGCOMM__Understanding and Profiling the Accelerator Chiplet Network Using PingPoint]]) - **GPU 観測性には「高忠実度を常時取る」設計と「必要な時だけ高忠実度にする」設計が並立する**: StriaTrace は CUPTI の API 全量を追わずカーネル時刻とメモリ転送に絞り、正常ステップでは集約値だけを保存し、ルーフライン外れ値で詳細トレースを残す。対して TELLER は CUPTI/NVTX を用いてリクエスト ID から GPU カーネルまでの意味的帰属を優先する。前者は常時運用の負荷、後者はリクエスト単位の診断精度を優先する異なる設計点であり、観測対象の選択はオーバーヘッドだけでなく診断の目的関数で決まる。(Source: [[@2026__OSDI__StriaTrace - Efficient Tracing and Diagnosis for Online LLM Inference]], [[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]]) - **GPU ドライバ層は、API 層と GPU 内部層をつなぐ低オーバーヘッドな中間観測面になる**: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]] は DRM スケジューラのジョブ状態、i915/AMDGPU のメモリ処理、vblank、NVIDIA の Xid と ioctl を対象にする。CUDA API uprobe が投入側の意味を、eGPU/PTX 注入が GPU 内部の挙動を担うのに対し、ドライバトレースはキュー待ち・fence・VRAM/GTT 移動・割り込みというホスト側の遅延要因を補う。3 層を分離して考えることで、「GPU 利用率が低い」という同じ症状を、API 投入、ドライバ待ち、GPU 内部実行のどこに帰属するかを整理できる。(Source: [[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]], [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]], [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]]) - [低オーバーヘッド計装 vs ベンダーテレメトリ] NVML v520 で追加された GPM(GPU Performance Monitoring)インターフェースは、DCGM 相当のSM利用率・SM占有率・命令ミックス・NVLink/PCIeデータレートを、常駐サービス無しにアプリケーションプロセスから直接取得できる。eBPF/CUPTIベースの侵襲的計装(eGPU・eInfer 等)とは異なり、ベンダー提供の継続積算カウンタを読むだけの非侵襲アプローチで、DCGMが抱えていた「常駐サービス化」「他プロファイラとの競合」「機械可読出力の制約」という運用コストを回避する。(Source: [[@2026__SCAHPCAsiaWS__Leveraging NVML GPM for NVIDIA GPU Monitoring]]) - [メトリクス意味論の検証] `nvidia-smi`/NVMLのGPU利用率(`GRAPHICS_UTIL`、時間ベース)とGPM/DCGMのSM利用率(`SM_UTIL`/`PROF_SM_ACTIVE`、サイクルベース)は単位が異なり単純比較できず、`SM_UTIL ≤ GRAPHICS_UTIL`という自然な仮説はSMクロック周波数依存のため必ずしも成立しない。4週間・9,468ジョブの実運用データとターゲットベンチマークによる実証で、GPMドキュメントとDCGMドキュメントの記述の間にNVLink/PCIeのプロトコルオーバーヘッド扱いやKiB↔MiB換算誤りなど複数の不正確さを発見した。(Source: [[@2026__SCAHPCAsiaWS__Leveraging NVML GPM for NVIDIA GPU Monitoring]]) - [システムワイドDCGM] [[LDMS]] 経由で収集した多様な DCGM カウンタ(SM/FP/HBM/NVLink/PCIe/エネルギー/温度)を Slurm ジョブへ帰属させると、平均 GPU UTIL だけでなく空間・時間不均衡やパイプ組合せまでジョブ診断に使える。低 UTIL ジョブに不均衡が集中し、4 GPU ジョブの 12% は 3 枚が未使用のまま、という運用可視性が得られる(Source: [[@2026__IPDPS__Characterizing Production GPU Workloads using System-wide Telemetry Data]])。 - **GPU の detachment 系障害(bus からの脱落)は数値テレメトリにほぼ前兆を残さず、支配的な観測可能シグナルはデバイスメトリクスの消失とスクレイプペイロード整合性の劣化という構造的なものである**: GWDG の本番 GPU ノードで処理された 5 件の detachment インシデント全てで、GPU デバイスレベルのメトリクスは t0（scrapeCountDrop によるアラインメント時刻）の直前または直後に部分的・完全に消失し、温度・電力・利用率・クロックなど従来の value-centric なテレメトリは障害直前まで nominal のままだった。分散シフト統計（diffStd）はこのスライスで頻繁にゼロであり、安定した数値前兆のランキング軸を提供しない。既存知見が扱ってきた「高忠実度で常時取る/必要な時だけ取る」計装設計とは異なる軸として、"メトリクスが存在するかどうか自体を第一級シグナルにする"という観点が加わる。(Source: [[@2026__arXiv__When GPUs Fail Quietly - Observability-Aware Early Warning Beyond Numeric Telemetry]]) - **GPU テレメトリと Prometheus 監視パイプライン劣化指標（スクレイプ遅延・サンプル欠損・タイムシリーズギャップ）を joint モデリングすると、GPU 単独テレメトリより早期警告のリードタイムが増大する**: 固定 1% アラート予算のもとで、joint Isolation Forest は平均リード 7 window（GPU 単独 IF は 2 window）、最大リード 29 window を達成した。一方で多くの構成で中央値リードは 0.0 window であり、予算制約付きアラートと保守的な弱イベント定義のもとでは早期警告と単なるイベント検知の境界が曖昧になりうる。(Source: [[@2026__arXiv__When GPUs Fail Quietly - Observability-Aware Early Warning Beyond Numeric Telemetry]]) - **DCGM エクスポータのメトリクス欠損は missing-at-random では説明できず、ドライバ/デバイス状態そのものに起因しうる**: NVIDIA の DCGM ドキュメントはメトリクス可用性がエクスポータの健全性だけでなく現在のドライバ・デバイス状態に依存すると明示しており、エクスポータは稼働し続けながら該当 GPU のメトリクスファミリーだけを静かに落とすことがある。これはデータ品質ノイズとして前処理で捨てられがちだが、本論文はこれを前処理アーティファクトではなく第一級の観測性シグナルとして扱うべきだと主張する。(Source: [[@2026__arXiv__When GPUs Fail Quietly - Observability-Aware Early Warning Beyond Numeric Telemetry]]) - **特定の物理ノードでの GPU detachment 再発は、単発イベントの重大度よりも有用なハザードシグナルである**: GWDG のノード ggpu142 は約 1 か月間に 2 回、ggpu149 は 10 か月間に 3 回の detachment を経験しており、著者らはホスト履歴の集約と再発考慮型スコアリングを異常検知システムに組み込み、ノード隔離・低優先度ワークロードへの再配置・ハードウェアのディレーティング等の能動的介入を可能にすべきだと論じる。(Source: [[@2026__arXiv__When GPUs Fail Quietly - Observability-Aware Early Warning Beyond Numeric Telemetry]]) ## 未解決の問い - GPU ドライバ層のジョブ・メモリ・割り込みイベントを CUDA API の要求や GPU 内部のカーネル実行へ、ベンダー横断かつ低オーバーヘッドで結びつける共通相関 ID は設計できるか。([[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]]) - DRM の共通トレースポイントと NVIDIA proprietary driver の kprobe で、同じ診断指標(投入待ち時間・実行時間・依存待ち)をどこまで同じ意味で定義できるか。([[@2025__eunomia.dev__eBPF Tutorial by Example - Monitoring GPU Driver Activity with Kernel Tracepoints]]) - 正常時の集約メトリクスと異常時の GPU 詳細トレースを、TELLER のリクエスト帰属と組み合わせる最小限の切り替え条件は何か。 - ホスト側傍受(eBPF)だけで GPU 内部の可視性(SM 占有・ワープ実行・キャッシュ挙動)をどこまで補えるか。PTX 注入(eGPU)とハードウェアカウンタ(PMC)の併用が現実解か。 - コンパイル時計装(TOPC)と実行時計装(eGPU/eInfer)の最適な使い分けは。決定的実行を要する正しさ検証は前者、動的・本番常時観測は後者、という分業が成り立つか。 - エッジ/オンデバイス(ProfInfer の Orange Pi・Rubik Pi)とサーバ/分散(eInfer・NCCLX)で得た観測知見は相互に外挿できるか。 - 本 vault の machine-level 箇所特定([[Pulse]]・[[Minder]])やアプリ層 AIOps と、GPU/カーネル/デバイス層の観測はどう統合されるか([[eBPF]] の問いと共通)。 - 選択計装の「重要オペレータのみ」前提は、新規アルゴリズムが minority kernel を増やしたときどこまで死角を残すか。([[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]]) - GPU ドライバ層・CUDA API 層・GPU 内部層を計装できても、それを深層学習フレームワーク層の順伝搬・逆伝搬・重み更新・集団通信スパンへどう帰着するか。講演資料は、分散トレーシングへの帰着には各層イベントの意味づけが必要だが、現状は研究開発領域だと整理する。([[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]]) - ARGUS は CUPTI Activity API を 3 経路分離で 1〜2% まで下げたが、PyTorch Profiler・nsys と比べると「何を取れていないか（SM 占有率・ワープ実行・L2 キャッシュ挙動等）」はどこか。CUPTI Activity API の粒度上限で診断できない障害クラスはあるか。 - FabricPerf の GPTP は intra-kernel jitter 101.8ns まで抑える一方、ノード間の inter-kernel jitter は 35.96µs まで拡大する(クロック drift が原因)。GPU 観測性が要求する「常時稼働・低オーバーヘッド」(ARGUS・eInfer 等)と、マルチデバイス通信を跨いだクロック整合性の維持はどう両立するか。 - eBPF on GPU(eGPU) の verifier が SIMT 実行モデルに対してどの程度の安全性保証を与えられるか。本番常時運用時のオーバーヘッドとサンプリング戦略の最適値は何か。([[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]]) - Valkの「複数ベンダープロファイラを突き合わせる」アプローチは、eBPF系が主張する「低オーバーヘッド・非侵襲」の要求とはそもそも異なる目的(データベースのクエリプラン・演算子統計とハードウェアカウンタの対応づけ)を持つ。両アプローチ(独自計装 vs 既存ツールの突き合わせ)は、GPU観測性の実務においてどのような条件下でどちらが優位か。クエリ処理のような短時間・多数カーネル呼び出しのワークロードでは、Nsight Computeの高いend-to-endオーバーヘッド(既定設定で最大4,989倍)は許容できるのか、それとも本番運用にはeBPF系の低オーバーヘッド計装が必須になるのか。 - NVML GPMの命令ミックスメトリクス(INTEGER/FP64/FP32/FP16_UTIL、DFMA/HMMA/IMMA_TENSOR_UTIL)のクロック依存性は推定に留まる。SM利用率・占有率と同様の後処理補正で検証できるか。 - 運用検証済みカウンタに限定した観測はノイズ耐性を上げる一方、未採用カウンタを足すとジョブ診断の再現率はどれだけ伸びるか。 - detachment 系（構造的メトリクス消失）を弱イベントプロキシとして明示的に定義する方法は何か。本論文は drift 支配型の弱イベント定義しか持たず、detachment 系はインシデントアンカー評価という別経路でしか扱えていない。 - joint Isolation Forest のリードタイム増大（平均 7 window）を常時稼働の本番監視に外挿し、ジョブのチェックポイント・再配置トリガーとして使う場合、アラート断片化（17 run、平均 run 長 4.706）はトリアージ負荷をどこまで悪化させるか。 ## 関連 - ソース: [[@2026__arXiv__Over the Memory Wall, Into the Instruction Wall - The New Bottleneck in GPU Data Processing]] / [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 2 パフォーマンス計測]] / [[@2023__SystemAtScale__AI Observability]] / [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]] / [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]] / [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]] / [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]] / [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]] / [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]] / [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]] / [[@2025__SpeakerDeck__AIスーパーコンピュータにおけるLLM学習処理性能の計測と可観測性]] / [[@2025__O11yConTokyo2025__AIスパコン「さくらONE」のオブザーバビリティ]] / [[@2025__eunomia.dev__bpftime GPU Support - CUDA and ROCm eBPF Attachment]] / [[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]] / [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]] / [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]] / [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]] / [[@2026__SIGCOMM__Understanding and Profiling the Accelerator Chiplet Network Using PingPoint]] / [[@2026__SCAHPCAsiaWS__Leveraging NVML GPM for NVIDIA GPU Monitoring]] / [[@2026__IPDPS__Characterizing Production GPU Workloads using System-wide Telemetry Data]] / [[@2026__arXiv__When GPUs Fail Quietly - Observability-Aware Early Warning Beyond Numeric Telemetry]] - 概念: [[eBPF]] / [[動的計装]] / [[ハードウェアカウンタ]] / [[テレメトリ]] / [[LLM推論]] / [[GPUクラスタ運用]] / [[eGPU]] / [[PTX 注入]] / [[CUDA API トレース]] / [[LLMによる根本原因分析]] / [[AI訓練ログデバッグ]] / [[RDMAネットワーク監視]](ICLensのRNIC計装) / [[GPU占有率(Occupancy)]] / [[GPUエネルギー効率]] / [[HPCワークロード特性化]] - エンティティ: [[NVBit]] / [[CUPTI]] / [[PTX]] / [[bpftime]] / [[hip-analyzer]] / [[eGPU]] / [[eunomia-bpf]] / [[libbpf]] / [[yunwei37]] / [[Neutrino]] / [[FabricPerf]] / [[Logarithm]] / [[Valk]] / [[NVIDIA Nsight Systems]] / [[InterconnectLens]] / [[NVIDIA Data Center GPU Manager]] / [[PingPoint]] / [[AMD]] / [[NVML-GPM-Collector]] / [[LDMS]] / [[Perlmutter]] / [[GWDG]] - 関連 MOC: [[AI Infra Telemetry - MOC]] ## 出典 - [[@2026__arXiv__Over the Memory Wall, Into the Instruction Wall - The New Bottleneck in GPU Data Processing]](§4 Valk、§4.1 Dataset・Profiler Overhead、§4.2 User Interface) - [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 2 パフォーマンス計測]](§2.3.2 時間使用率/能力使用率の定義、§2.5 GPU使用率低下時の原因切り分けチェックリスト) - [[@2026__arXiv__TELLER - Non-intrusive Cross-Layer Root-Cause Analysis for LLM Inference]](NVTX 動的フック + CUPTI コールバック/アクティビティによるリクエストレベル帰属、§3.2〜3.3、トレーシングオーバーヘッド表10) - [[@2025__HCDS__eGPU - Extending eBPF Programmability and Observability to GPUs]](実行時 PTX 注入・NVBit/CUPTI 比較) - [[@2025__eBPF__eInfer - Unlocking Fine-Grained Tracing for Distributed LLM Inference with eBPF]](ホスト側 eBPF 傍受・ベンダー非依存) - [[@2026__MLSys2026__ProfInfer - An eBPF-based Fine-Grained LLM Inference Profiler]](オンデバイス・5% 未満オーバーヘッド) - [[@2024__TOPC__Low-Overhead Trace Collection and Profiling on GPU Compute Kernels]](コンパイル時計装・1 桁削減) - [[@2024__arXiv__Microsecond-scale Dynamic Validation of Idempotency for GPU Kernels]](観測による正しさ検証) - [[@2025__arXiv__XPUTimer - Anomaly Diagnostics for Divergent LLM Training in GPU Clusters of Thousand-Plus Scale]](CPython PyEval_SetProfile + LD_PRELOAD による非侵入・全スタック計装) - [[@2024__NSDI__MegaScale - Scaling Large Language Model Training to More Than 10,000 GPUs]](バックエンド計装による全スタックトレース) - [[@2026__eunomia.dev__CUDA Events - eBPF-based CUDA API Tracing]](CUDA API 層の uprobe トレース実装・約 2 µs オーバーヘッド) - [[@2025__eunomia.dev__The GPU Observability Gap - Why We Need eBPF on GPU devices]](既存 GPU ツールの 3 類型整理と eBPF on GPU の方向性) - [[@2025__eunomia.dev__bpftime GPU Support - CUDA and ROCm eBPF Attachment]](Nsight 限界の4分解・アタッチ型/専用マップ/ヘルパー関数の実装詳細) - [[@2026__SIGCOMM__FabricPerf - Measuring NIC-less Scale-Up Network through GPU Communication Kernel Profiling]](通信カーネル向けアセンブリ計装・GPU内蔵クロックによるマルチデバイス同期GPTP) - [[@2024__EngineeringAtMeta__Logarithm - A logging engine for AI training workflows and services]](ログベースのモデルテレメトリ・TensorBoardストリーミングAPI、GPUカーネル計装とは異なるレイヤーの観測) - [[@2025__PEARC__InterconnectLens - Enhancing Observability of Data Transfers in GPU Clusters]](§2 dcgm-exporter・拡張版Intel pcm・procfsベースRNIC Exporterの3層構成、§3 TCP誤用・GPUDirect RDMA誤設定・イーサネットスイッチ輻輳のコンポーネント別可視化) - [[@2026__SIGCOMM__Understanding and Profiling the Accelerator Chiplet Network Using PingPoint]](§3 ACN特性評価フレームワーク、§4 hoseモデル+Kernel Fusion+DCA、§5.3 空間分離下でのACN輻輳伝播) - [[@2026__IPDPS__Characterizing Production GPU Workloads using System-wide Telemetry Data]](DCGM+LDMS のジョブ帰属と不均衡指標) - [[@2026__arXiv__When GPUs Fail Quietly - Observability-Aware Early Warning Beyond Numeric Telemetry]](GWDG 本番 GPU ノードの detachment 系障害における観測性考慮型早期警告)