# Leveraging NVML GPM for NVIDIA GPU Monitoring > [!abstract] 概要(abstract の日本語訳) > 機械学習の研究と応用が拡大を続ける中で、GPUは現代の計算環境において至る所で使われるようになった。これらの計算資源を効率的に利用するために、監視は本番運用のデプロイメントにおいてしばしば中心的な構成要素となる。nvidia-smiは基本的な利用率データを提供できる一方、NVIDIAのData Center GPU Manager(DCGM)が提供する追加のメトリクスは、実際の利用度合いへのより正確な洞察を可能にする。しかし、既存の監視スタックへのDCGMの統合は、出力とデプロイメントのオプションが限定的であることに起因する独自の課題をもたらしうる。そこで本論文は、正確で洞察に富むGPUメトリクスの低敷居なデータ収集を可能にする、NVIDIA Management Library(NVML)のGPU Performance Monitoring(GPM)メトリクスを調査する。我々は4週間分のジョブデータおよび標的を絞ったベンチマークによってGPMメトリクスを検証し、メトリクスの解釈を明確化するとともにドキュメントの不正確さを明らかにする。3つのケーススタディが、GPUカーネルのアプリケーションレベルSM利用率とSM占有率の判定、GPUエネルギー消費のモデル化、およびクラスタワークロードの分析という点でGPMメトリクスの有用性を示す。 ## 論文情報 - 著者: [[Christian Wassermann]]、[[Tobias Dollenbacher]]、[[Christian Terboven]]、[[Matthias S. Müller]](いずれも [[RWTH Aachen University]]) - 会議: SCA/HPCAsiaWS 2026(Supercomputing Asia and International Conference on High Performance Computing in Asia Pacific Region Workshops)、2026年1月26–29日、大阪、日本。ACM刊行、pp.59–68。 - DOI: [10.1145/3784828.3785156](https://doi.org/10.1145/3784828.3785156) - ライセンス: Creative Commons Attribution 4.0 International - 成果物: [[NVML-GPM-Collector]](GitHub: `RWTH-HPC/NVML-GPM-Collector`)としてオープンソース公開 ## 概要 NVIDIA GPU の性能監視は、`nvidia-smi`(基本的な利用率のみ)と [[NVIDIA Data Center GPU Manager]](DCGM、SM 利用率・SM 占有率・メモリ帯域・命令ミックスなど追加メトリクス)の二択が一般的だったが、DCGM は継続稼働するバックグラウンドサービスを要求し、他のプロファイリングツールと競合したり機械可読な出力形式に乏しいなど、HPC 監視スタックへの統合コストが高い。本論文は、NVML v520 で新たに導入された GPU Performance Monitoring(GPM)インターフェースが、DCGM 相当のメトリクスをより軽量に収集できることに着目し、(1) GPM メトリクスの意味論を DCGM ドキュメントと突き合わせて検証し、(2) クロック依存メトリクスの後処理手法を提案し、(3) カーネル性能解析・エネルギー消費モデリング・クラスタワークロード分析の3つのケーススタディでその実用性を示す。 ## 問題設定 - `nvidia-smi`/NVML の GPU 利用率(`GRAPHICS_UTIL`)は「過去サンプル期間中に何らかのカーネルが実行されていた時間の割合」としてのみ定義され、サンプル間の空白(blind spot)があり、実際の利用度を過大評価しやすいことが複数の先行研究([[GPU観測性]]文脈で頻出する Yousefzadeh-Asl-Miandoab et al.、Elvinger et al.、Maloney et al. 等)で指摘されている。 - DCGM はハードウェアカウンタベースの SM 利用率・SM 占有率・命令ミックス・メモリ帯域メトリクスでこの限界を補うが、追加のシステムサービスを要求し、他のプロファイラ(Nsight Compute 等)との競合や、コンテナ/Kubernetes 前提の `DCGM-Exporter` に起因する機械可読出力の制約という運用上の課題がある(Weakley et al. の指摘)。 - NVML v520 で追加された GPM インターフェースは、DCGM 相当の指標をシステムサービス無しに(アプリケーションプロセスから直接)取得できるが、そのメトリクスの意味論・精度・ドキュメントの正確性は本論文以前には体系的に検証されていなかった。 ## 提案手法 - **収集ツール**: `nvmlGpmSampleGet` で2時点のサンプル(`nvmlGpmSample_t`、`std::unique_ptr` で RAII 管理)を取得し `nvmlGpmMetricsGet` でメトリクスを算出する軽量なコレクタを実装([[NVML-GPM-Collector]])。GPM サンプル間の最小間隔は 100 ms。出力は InfluxDB line protocol で、監視エージェント [[Telegraf]] の `execd` 入力プラグインに統合できる。NaN 値は `-1` のセンチネル値に置換する。LeakSanitizer で GPU/MIG あたり 176 B のメモリリークを検出したが、初回の `nvmlGpmSampleGet` 呼び出し限定であり NVML 内部のリークと推定している。 - **クロック依存メトリクスの後処理モデル**(§5.1): SM 利用率・SM 占有率は SM クロック周波数に依存するため、raw な `utilraw = ticksutil / tickstotal` を、非活性時(`freqinactive`)・活性アイドル時(`freqactive idle`)・活性負荷時(`freqactive load`)の3つのクロック周波数モデルで補正し、`freqavg` と各区間の時間比 `p_x` から `utilkernel` を導出する。`nvidia-smi` のクロック周波数サンプルから `p_inactive`(閾値 1000 MHz)・`p_active idle`・`freqactive load` を推定する。 ![[_attachments/Leveraging-NVML-GPM-for-NVIDIA-GPU-Monitoring/fig01-gpu-util-vs-sm-util-occupancy.png]] **Figure 1: GPU利用率・SM利用率・SM占有率の散布図比較** (Figure 1. CLAIX-2023 クラスタの4週間分・分単位監視データを用いた散布図。Figure 1aはGPU利用率とSM利用率の関係を示し、赤破線は x=y、オレンジ線は理論上の最大乖離境界(1980 MHz⇔345 MHz瞬時切替を仮定)、緑線は実測から求めた妥当な境界(アイドルクロック750 MHz相当)である。Figure 1bはSM利用率とSM占有率の関係を示し、SM_OCCUPANCY ≤ SM_UTIL の仮説を支持する。) ## 新規性 - NVML GPM は NVML v520(Hopper 世代以降)で追加された新しいインターフェースであり、本論文が GPM メトリクスの意味論・精度をドキュメントおよび DCGM の対応メトリクスと初めて体系的に突き合わせて検証した。 - クロック周波数依存性を補正する後処理モデルを新規に定式化し、Nsight Compute のカーネルレベル参照値に対する誤差を実証的に大幅改善した(SM利用率: 28.35%pt→2.31%pt、SM占有率: 8.74%pt→0.95%pt)。 - NVLink・PCIe の GPM データレートに KiB↔MiB 換算の誤り(1024 ではなく 1000 を使うべき)を発見し、DCGM ドキュメントとの意味論的な相違(ヘッダ・プロトコルオーバーヘッドの扱い)を指摘した。 ## 実験設定 Table 1 は検証に使った CLAIX-2023 GPU パーティションとジョブデータセットの主要な特性をまとめたものである。 | 項目 | 値 | |---|---| | ノード数 | 52 | | ノードあたりGPU数 | 4 | | GPUアーキテクチャ | NVIDIA H100 SXM5 | | GPUメモリ | 94 GB HBM2e | | NVMLバージョン | v570 | | 期間 | 2025-09-01〜2025-09-28 | | ジョブ数 | 9,468 | | 最小ジョブ実行時間 | 30分 | | サンプリング間隔 | 1分 | (Table 1. 本論文の著者自身のジョブは前処理で除外している。2025-09-09は監視システム更新のため10時間分のメトリクスが不完全だが、観測結果への影響は軽微と見積もられている。) - クラスタ: RWTH Aachen University の CLAIX-2023 GPU パーティション(52ノード、ノードあたり4基のNVIDIA H100 SXM5、GPUメモリ94GB HBM2e、NVML v570)。 - 監視データ: 2025-09-01〜2025-09-28 の4週間、9,468ジョブ、サンプリング間隔1分、最小ジョブ実行時間30分(2025-09-09の10時間分は監視システム更新により不完全データ)。 - ケーススタディ5(カーネル性能解析)のベンチマーク: NVIDIA HPC-Benchmarks 24.09 の HPL、SPEChpc2021 1.1.8 の tiny OpenACC ベンチマーク一式(lbm・soma・tealeaf・clvleaf・miniswp・pot3d・sph_exa・hpgmgfv・weather)、および分光シミュレーション用の密度汎関数理論コード VeloxChem。各アプリケーションは単一GPUで実行し、Nsight Compute のカーネルレベル参照値(`sm__cycles_active.avg`/`sm__cycles_elapsed.avg` など)と比較するため CUPTI でカーネル実行をシリアライズした。データスパース性の実験では、繰り返し実行間に 1/2/5/10/30/60 秒の遅延を挿入した。 - ケーススタディ4(NVLink/PCIe検証): 1,000,000 KiB の送信操作を `nvidia-smi -gt` のデータ/生カウンタと比較。PCIeは10,000,000 KiBのホスト→GPU転送をNsight Computeの`pcie__read_bytes.sum`と比較。 ## 実験結果 - **§4.1 GPU利用率 vs SM利用率**: `SM_UTIL ≤ GRAPHICS_UTIL` という仮説は必ずしも成立せず(Figure 1a右下の領域)、これはブロック数不足でSM分散が不十分なアプリケーションを識別する。ANY_TENSOR_UTILもGPU利用率を上回るケースが観測され、他の命令ミックスメトリクス(INTEGER/FP64/FP32/FP16_UTIL、DFMA/HMMA/IMMA_TENSOR_UTIL)も同様にクロック依存と推定される。 - **§4.2 SM利用率 vs SM占有率**: `SM_OCCUPANCY ≤ SM_UTIL` は常に成立(Figure 1b)。ランダムアクセスのコピーカーネルでSM利用率・占有率とも99%超を記録し、データ転送によるストールがどちらのメトリクスにも含まれることを確認した。 - **§4.3 DRAM利用率**: H100 SXM5は単一のDRAMクロック周波数(1593 MHz)しか持たないため、DRAM利用率はアイドル状態の影響を受けない。連続アクセスとランダムアクセスの2種のコピーカーネルで、ストールサイクルはDRAM利用率にカウントされないことを確認した。GPMとDCGMのドキュメントの間には、レイテンシ起因のストールサイクルの扱いに関する記述の不一致が残る。 - **§4.4 NVLink/PCIeデータレート**: KiB→MiB換算に1000を使うと`nvidia-smi`/Nsight Computeの参照値と整合し、1024を使うと超過する。GPMのNVLink/PCIeメトリクスはプロトコルオーバーヘッドを含まないと推定される(アイドル時にGPMは正確に0 MiB/sを報告するが`nvidia-smi`の生カウンタは増加し続ける)。 - **§5.3 カーネル性能解析の検証**: 後処理適用でSM利用率の平均誤差は28.35%ptから2.31%pt、SM占有率は8.74%ptから0.95%ptへ改善(Figure 2)。非活性時間割合が20%以下であれば、pot3dの外れ値を除きほぼ全ケースで絶対誤差10%pt未満を達成(Figure 3)。 ![[_attachments/Leveraging-NVML-GPM-for-NVIDIA-GPU-Monitoring/fig02-nsight-compute-validation.png]] **Figure 2: raw/後処理後GPM値とNsight Compute参照値の比較** (Figure 2. 11種のアプリケーションについて、raw GPM値・後処理後GPM値・Nsight Compute参照値の SM利用率(左)とSM占有率(右)を比較した棒グラフ。後処理により全アプリケーションで精度が改善する。) ![[_attachments/Leveraging-NVML-GPM-for-NVIDIA-GPU-Monitoring/fig03-sparse-sampling-effect.png]] **Figure 3: データ疎性がSM利用率推定精度に与える影響** (Figure 3. 繰り返し実行間の遅延(データ疎性)がSM利用率推定精度に与える影響。非活性時間割合が増えるほど誤差が拡大し、20%以下では緑破線枠内(絶対誤差10%pt未満)にほぼ収まる。pot3dの4回の実行は外れ値として除外して回帰した。) - **§6 エネルギー消費モデリング**: `nvmlDeviceGetTotalEnergyConsumption` による電力消費との線形相関は、`nvidia-smi`のGPU利用率が0.79(MAPE 32.27%)と最も弱く、NVML GPMのGPU利用率0.86(MAPE 24.65%)、SM利用率0.95(MAPE 15.40%)、SM占有率0.84(MAPE 26.07%)。SM利用率が最も電力消費と強い線形関係を持ち、電力消費はアクティブなワープ数よりアクティブなSM数により強く依存することを示唆する。 ![[_attachments/Leveraging-NVML-GPM-for-NVIDIA-GPU-Monitoring/fig04-power-consumption-correlation.png]] **Figure 4: GPU性能メトリクスとGPU電力消費の関係** (Figure 4. 9,468件の本番ジョブについて、`nvidia-smi`のGPU利用率・NVML GPMのGPU利用率/SM利用率/SM占有率の4指標とGPU電力消費の関係を示す散布図。`nvidia-smi`(左端)は整数値の分解能の粗さから白い縦縞のギャップが生じている。赤線は各パネルの最小二乗線形フィット。) - **§7 クラスタワークロード分析**: 同一9,468ジョブの命令ミックスでは、IMMA利用はゼロ、DFMAはほぼ6%未満。HMMAがテンソルコア利用を支配するが平均で20%未満にとどまる。CUDAコアではFP16・FP64がほぼ5%未満、FP32が最多(約95%のGPU時間で20%以下)、最も広く使われる命令型はINT(ループ・アドレス計算用のインデックス計算に起因すると推定)。PCIe/NVLinkのデータ転送量では、単一GPUジョブのPCIe D2Hが0.21 TB/GPU時に対しH2Dは0.82 TB(3.92倍)、マルチGPUジョブではD2H 0.49 TB対H2D 1.44 TB(2.97倍)、NVLinkは平均1.68 TB/GPU時でPCIe D2HとH2Dの中間に位置する。 ![[_attachments/Leveraging-NVML-GPM-for-NVIDIA-GPU-Monitoring/fig05-cluster-workload-ecdf.png]] **Figure 5: クラスタジョブ監視データのECDF曲線** (Figure 5. 9,468件の本番ジョブ監視データのECDF曲線。Figure 5aはテンソルコア(破線)とCUDAコア(実線)の命令タイプ別の平均利用率分布、Figure 5bは単一GPU/マルチGPUジョブ別のPCIe(H2D/D2H)・NVLinkのGPU時間あたりデータ転送量分布である。) ## 考察 - GPM メトリクスは DCGM や `nvidia-smi` と意味論的に等価でありながら、収集の簡便さと精度の両面で優れる。継続積算カウンタに基づくため、サンプル間の情報損失(blind spot)が少なく、電力消費モデリングのような用途で `nvidia-smi` より高い相関を示す。 - 後処理手法はSM利用率・SM占有率に限らず、他のクロック依存メトリクス(命令ミックス系)にも同様に適用できると期待される。 - 命令ミックスの測定は、低精度演算やテンソルコアを十分活用していないジョブの特定に使え、PCIe対NVLinkのデータ量比は冗長なデータ移動の指標になりうる。 - ジョブ効率分析ポータルへの組み込みにより、後処理済みSM利用率・SM占有率をユーザーへのチューニングヒントとして直接提供できる可能性を指摘している。 ## 強み / 弱点・課題 - 強み: 4週間・9,468ジョブという実運用規模のデータと、狙いを定めたマイクロベンチマークの両輪で検証しており、単なる文書の記述に留まらず実測でDCGMドキュメントとの相違・誤りを具体的に指摘している。オープンソースツール([[NVML-GPM-Collector]])を公開し再現性を確保している。 - 弱点・課題: 検証は NVIDIA H100 SXM5(単一GPU世代)・単一クラスタ(CLAIX-2023)に限定されており、他アーキテクチャへの一般化は未検証。後処理モデルの妥当性はNsight Computeとの比較に依存するため、Nsight Compute自体がアプリケーションの実行特性に影響を与える可能性(§5.3で報告されたHPLの`freqactive load`乖離)への言及はあるが、根本原因は未解明のまま残されている。命令ミックスメトリクスのクロック依存性は「推定」段階であり、SM利用率・占有率のような直接検証はされていない。