2026.09.29 監視・オブザーバビリティ

nvidia-smiの使い方｜GPU使用率とメモリの見方・CSV記録・DCGMへの移行判断

Q: nvidia-smiをリアルタイムで監視するにはどうしますか？

画面で見張るなら watch -n 1 nvidia-smi 、記録を残すなら nvidia-smi --query-gpu=... --format=csv -l 1 です。GPU単位の推移を1行ずつ流したいときは nvidia-smi dmon が使えます。既定の間隔は1秒で、 -s で電力・使用率・メモリなど出す列を選べる。

nvidia-smiの使い方｜GPU使用率とメモリの見方・CSV記録・DCGMへの移行判断

nvidia-smiは、NVIDIAのドライバと一緒に入るGPUの状態確認コマンドです。引数なしで打てば、ドライバの版、GPUごとの使用率・メモリ・温度・電力、GPUを掴んでいるプロセスが1画面に並びます。この記事では、既定出力の各欄の読み方、--query-gpu とCSVで定期記録するコマンド、dmon・pmon、Pythonからの取得、エラー時の終了コードによる切り分け、DockerとWindowsでの注意点、そしてDCGM ExporterとPrometheusへ移す判断までを、NVIDIA公式のnvidia-smiマニュアルの記述を出典として整理しました。

まとめ：nvidia-smiでGPUの状態を読む手順と監視を常駐型へ移す分岐点

日常の確認は3つのコマンドで足ります。全体を見るなら引数なしの nvidia-smi、記録を残すなら --query-gpu に項目を並べて --format=csv と -l を付ける、どのプロセスが何MiBを使っているかは --query-compute-apps で引く。

読み違えやすい欄が2つあります。GPU-Utilは「直近のサンプル期間に1つ以上のカーネルが動いていた時間の割合」で、GPUの演算器がどれだけ埋まっているかではありません。ヘッダのCUDA Versionはドライバ側が報告する値で、入れたCUDA Toolkitの版とは別物です。

GPUが1〜2台で、人が必要なときに見るならnvidia-smiで十分。複数台のGPUサーバーを常時監視し、しきい値で通知したくなった時点で、dcgm-exporterでPrometheusへ流す構成に切り替えます。

nvidia-smiの既定出力でドライバ版・GPU使用率・メモリ使用量を読む手順

引数なしの出力は上から、ヘッダ（版情報）、GPUごとの状態表、プロセス一覧の3段です。欄の意味を押さえておくと、障害時に見る場所が決まります。

ヘッダのDriver VersionとCUDA Versionが示す値と読み違えの注意点

ヘッダは次の形をしています。NVIDIAのCUDA互換性ガイドに載っている出力例です。

$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 580.65.06    Driver Version: 580.65.06    CUDA Version: 13.0     |

ここに出るCUDA Versionはドライバが扱える側の値です。CUDAのLinuxインストールガイドは、CUDA 13.4以降でToolkitとドライバを別々に入れ、別々に版管理すると明記しています。Toolkitを入れていない機械でもこの欄は表示されるため、コンパイラの版は nvcc --version で別に確かめます。

ドライバの下限も版ごとに決まっています。CUDA Toolkitのリリースノートによると、CUDA 13.x は580以上、12.x は525以上のドライバが要る。ヘッダのDriver Versionがこれを下回っていれば、Toolkitを入れ直しても動きません。CUDAそのものの仕組みはCUDAとは？読み方・仕組み・CUDAコア・バージョン13までNVIDIAのGPU並列計算を解説にまとめています。

GPU-UtilとMemory-Usageの定義をサンプル期間から正しく解釈する

マニュアルは utilization.gpu を「過去のサンプル期間のうち、1つ以上のカーネルが実行されていた時間の割合」と定義し、サンプル期間は製品によって1秒から1/6秒の間だと書いています。定義上、小さなカーネルが1本だけ動き続けても100%になる。GPU-Utilが張り付いているのに処理が遅いときは、バッチサイズや転送待ちを疑う余地が残ります。

もう一方の utilization.memory は、同じ期間にデバイスメモリへの読み書きが行われていた時間の割合です。Memory-Usage欄のMiB表示（容量の使用量）とは別の指標なので混同しない。LLMの推論では容量が先に尽きることが多く、推論エンジン側で詰める方法はTensorRT-LLMとは？NVIDIA GPUでのLLM推論高速化の仕組みと採用判断を解説【2026年版】で扱っています。

Perf欄のP0からP12とPersistence-Mが示す電力状態の読み方

Perf欄はパフォーマンスステートで、P0が最大性能、P12が最小性能です。負荷をかけているのにP8のような数字のままなら、クロックが上がっていません。原因は nvidia-smi -q -d PERFORMANCE の Clocks Event Reasons に並び、SW Power Cap や HW Thermal Slowdown のどれが効いているかで電力制限か温度かを切り分けます。

Persistence-Mは、クライアントがいない間もドライバをロードしたままにするモードです。マニュアルによればLinux専用で、再起動すると無効に戻る。有効にしておくと、nvidia-smiやジョブを起動するたびに発生するドライバのロード待ちが縮みます。

プロセス一覧でGPUメモリを掴んでいるPIDを特定して止める手順

「CUDA out of memory」が出たのに自分のジョブは1本しか動かしていない。この状況では、前回のジョブやJupyterのカーネルがメモリを握ったまま残っていることが多いものです。一覧をCSVで出すと、止める対象を機械的に拾えます。

nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv
# pid, process_name, used_gpu_memory [MiB]
# 21873, python, 18432 MiB

kill 21873

マニュアルは、このメモリ量を「GPUコンテキストが使っている量」と説明しています。止めても足りない場合は、モデル側でVRAMを減らす手を打つ。4bit量子化で学習時のメモリを抑える手順はQLoRAとは？4bit量子化＋LoRAの仕組み・VRAM目安・実装手順と採用判断を解説【2026年版】にあります。

–query-gpuとCSV出力でGPU使用率を定期記録するコマンドの組み立て

画面を眺めるだけでは、学習が遅くなった時刻に何が起きていたかを後から追えません。記録用途では出力形式を固定し、ファイルへ流します。

–query-gpuで取得する項目を選び–formatでCSVに整える書き方

--query-gpu にはカンマ区切りで項目を並べます。指定できる名前の一覧は nvidia-smi --help-query-gpu で出る。--format は csv が必須で、見出し行を消す noheader と単位を消す nounits を足せます。

nvidia-smi \
  --query-gpu=timestamp,index,uuid,name,pstate,utilization.gpu,utilization.memory,memory.used,memory.total,temperature.gpu,power.draw \
  --format=csv,noheader,nounits \
  -l 5 -f /var/log/gpu_usage.csv

単位を落としておくと、表計算やpandasへそのまま読み込めます。-f は出力先ファイルの指定で、標準出力へのリダイレクトより止め忘れに気付きやすい。uuidを列に入れておけば、GPUを差し替えた後でも同じ個体の記録を追えます。

-lと-lmsの間隔指定とwatchとの違いを記録用途で使い分ける

繰り返しの指定は、秒単位の -l とミリ秒単位の -lms の2つです。watch -n 1 nvidia-smi は画面を毎秒書き換えるだけで何も残らないため、人が見張る場面向け。記録なら -l です。

間隔の目安は用途で決まります。学習ジョブの傾向を見るなら5〜10秒、スパイクを捉えたいなら1秒。GPU-Utilのサンプル期間は最長1秒なので、それより細かく取っても値の解像度は上がりません。

dmonとpmonでGPU単位とプロセス単位の推移を1秒刻みで追う

dmon はGPU単位の推移を1行ずつ流すサブコマンドで、マニュアルでは最大16台まで、既定の間隔は1秒です。-s の文字で出す列を選びます。

-s の文字	出る列
p	消費電力（W）と温度（℃）
u	SM・メモリ・エンコーダ等の使用率（%）
c	プロセッサとメモリのクロック（MHz）
v	電力・温度による制限の発生
m	フレームバッファとBAR1の使用量（MB）
e	ECCとPCIeリプレイのエラー
t	PCIeの送受信スループット（MB/s）

# GPU単位: 電力・使用率・メモリを時刻つきで60回
nvidia-smi dmon -s pum -o T -c 60

# プロセス単位: どのPIDがSMとメモリを使っているか
nvidia-smi pmon -s um -c 10

1台に複数の学習ジョブを載せている環境では、pmon のほうが原因の特定が早い。dmon で全体が落ちた時刻を見つけ、pmon で犯人のPIDを割る順に使います。

-iの番号指定が再起動で入れ替わる問題とUUID指定への切り替え

-i 0 のような番号指定は手軽ですが、マニュアルはデバイスの列挙順が再起動をまたいで一定である保証は無いとし、UUIDかPCI bus IDでの指定を勧めています。複数GPUの機械で監視スクリプトを書くなら、最初に一覧を取り、UUIDで固定する。

nvidia-smi -L
# GPU 0: NVIDIA ... (UUID: GPU-3f1c...)

nvidia-smi -i GPU-3f1c... --query-gpu=utilization.gpu,memory.used --format=csv

番号のまま運用すると、再起動後に別のGPUの値を記録していても気付けません。障害の調査で「温度が高かったGPU」を物理的に特定するときに、この差が効いてきます。

PythonのNVML経由でGPUメモリを取得し学習ジョブの記録に組み込む

学習コードの中で使用量を記録したいなら、nvidia-smiを外から呼ぶより、nvidia-smiの土台になっているNVML（NVIDIA Management Library）を直接呼ぶほうが扱いやすい。

nvidia-ml-pyのpynvmlでGPU使用率とメモリを読む最小コード

公式のPythonバインディングはPyPIのnvidia-ml-pyで、2026年9月時点の最新は13.615系（2026-09-25公開）です。パッケージ名とimport名が違い、importは pynvml になります。

# pip install nvidia-ml-py
from pynvml import (nvmlInit, nvmlShutdown, nvmlDeviceGetCount,
                    nvmlDeviceGetHandleByIndex, nvmlDeviceGetName,
                    nvmlDeviceGetMemoryInfo, nvmlDeviceGetUtilizationRates)

nvmlInit()
try:
    for i in range(nvmlDeviceGetCount()):
        h = nvmlDeviceGetHandleByIndex(i)
        mem = nvmlDeviceGetMemoryInfo(h)
        util = nvmlDeviceGetUtilizationRates(h)
        print(i, nvmlDeviceGetName(h),
              f"{mem.used // 1024**2} / {mem.total // 1024**2} MiB",
              f"gpu={util.gpu}% mem={util.memory}%")
finally:
    nvmlShutdown()

関数の一覧と戻り値の構造はNVML APIリファレンスに載っています。nvmlShutdown() を finally に置き、例外で抜けても後始末が走る形にしておく。

subprocessでnvidia-smiを呼ぶ方式とNVML直接呼び出しの比較

観点	subprocessでnvidia-smi	pynvmlでNVML
追加の依存	なし	nvidia-ml-py
1回の取得コスト	プロセス起動が毎回発生	初期化1回で関数呼び出しのみ
戻り値	文字列（CSVを自前で解析）	数値と構造体
向く場面	シェルからの単発確認・cron	学習ループ内の記録・自作exporter

数秒おきに学習ループから呼ぶなら、NVMLを選びます。cronで5分おきにCSVへ追記する程度なら、nvidia-smiのほうが依存を増やさずに済む。

nvidia-smiがエラーになるときの終了コードとDocker・Windowsでの確認

表示が出ない・値がN/Aになる原因は、ドライバ・権限・コンテナ・OSのどこかにあります。終了コードで層を絞ると調査が短い。

終了コード9のドライバ未ロードと4の権限不足を切り分ける手順

マニュアルのRETURN VALUE節には、0が成功、2が引数の誤り、3が要求した操作をそのデバイスで実行できない、4が権限不足、6が対象が見つからない、9がドライバ未ロードと定義されています。まず echo $? で番号を見る。

nvidia-smi; echo "exit=$?"
# exit=9 -> ドライバが読み込まれていない（カーネル更新後の再ビルド漏れを疑う）
# exit=4 -> 設定を変える操作（-pm や -pl など）を権限なしで実行した

サポートされない項目は、エラーにならずN/Aで表示されるとマニュアルに書かれています。N/Aだけなら故障ではなく、その製品やOSがその値を持たないと読む。

Docker内のnvidia-smi不動作時のContainer Toolkit確認

コンテナの中でnvidia-smiが見つからない、あるいはGPUが0台と出るなら、ホスト側の受け渡しが設定されていません。NVIDIA Container Toolkitのサンプルが、導入確認のコマンドとして次を挙げています。

sudo docker run --rm --runtime=nvidia --gpus all ubuntu nvidia-smi

素のubuntuイメージで表示が出れば、ホストのドライバとToolkitは正常です。自前イメージで出ないなら、--gpus の付け忘れか、コンテナ内CUDAがホストのドライバ下限を超えている。クラウドのGPUインスタンスで最初に打つ確認も同じで、Runpodとは？料金・使い方・支払い方法とGPUの選び方【2026年9月】でもPod起動後の確認に使います。

WindowsのWDDMでプロセスごとのGPUメモリがN/Aになる理由

Windowsではドライバモデルが結果を変えます。マニュアルによるとWindowsのドライバモデルにはTCC・WDDM・MCDMがあり、画面出力を担うWDDMでは、プロセスごとの使用メモリはN/Aになる。メモリをNVIDIAドライバではなくWindowsのカーネルモードドライバが管理しているためです。

GeForceを積んだ開発用PCで数字が出ないのは、この仕様によるもの。同じマニュアルは、TCCが計算用途向けでカーネル起動が速く、WDDMは計算用途に勧めないとも書いています。プロセス単位のメモリを記録しながら学習を回すなら、Linuxの計算サーバーに寄せるのが確実です。

nvidia-smiからDCGM ExporterとPrometheusへ監視を移す基準

nvidia-smiは、手動で確認した時点のGPUの状態、つまり「いま」を見る道具です。複数台を並べて時系列で比べ、しきい値で通知する段になると、常駐して値を出し続ける仕組みが要ります。NVIDIAがそのために出しているのがDCGM（Data Center GPU Manager）とdcgm-exporterです。

dcgm-exporterを9400番で起動しPrometheusに取り込む最小構成

dcgm-exporterのドキュメントには、次の起動例と、既定で9400番で待ち受ける旨が書かれています。

docker run -d --rm --gpus all --net host --cap-add SYS_ADMIN \
  nvcr.io/nvidia/k8s/dcgm-exporter:${DCGM_EXPORTER_VERSION}-ubuntu20.04 \
  -f /etc/dcgm-exporter/dcp-metrics-included.csv

curl localhost:9400/metrics
# DCGM_FI_DEV_GPU_TEMP、DCGM_FI_DEV_POWER_USAGE、DCGM_FI_DEV_SM_CLOCK などが並ぶ

GitHubのリポジトリは、exporterをそのリリースと対になるDCGMの版で動かすよう求めています。最新リリースは4.8.4（2026-09-18公開）で、DCGM_EXPORTER_VERSION に入れるタグはリリースとイメージの一覧で合わせてください。取り込む側は scrape_configs に host:9400 を1行足すだけで、基盤の組み方はPrometheusで監視を構築する手順｜exporter設計・PromQL・保持期間の見積りに書きました。

nvidia-smiの定期実行で足りる規模と常駐監視へ移す条件

nvidia-smiのCSV記録で済ませてよいのは、GPUサーバーが1〜2台で、見るのが障害の後だけ、という場合です。cron1行で始められ、依存も増えません。

次のどれか1つに当てはまったら、dcgm-exporterへ移します。GPUサーバーが3台以上に増えた。夜間の学習が止まったことに朝まで気付けなかった。温度や電力の制限で性能が落ちた時刻を、後からグラフで突き合わせたい。この段でCSVをかき集める運用を続けると、集計スクリプトの保守のほうが重くなります。

逆に、GPU1台の検証機にPrometheusとGrafanaまで建てるのは過剰です。ハードウェアの健全性確認が目的なら、DCGMの dcgmi diag が機能概要のとおりレベル1（数秒）からレベル3（約15分）までの診断を持つので、納品前の検収やハード交換後の確認にはそちらを使う。

GPUサーバーの監視設計をAI開発の受託範囲に含めるときの分担

学習や推論のシステムは、モデルが動いた日ではなく、GPUが止まった夜に運用の質が問われます。一創の生成AI開発・AI受託開発では、モデルの実装に加えて、GPUサーバーのドライバ・CUDAの版の固定、nvidia-smiやDCGMでの監視設計、メモリ不足時の量子化や推論エンジンの見直しまでを範囲に含めて引き受けます。監視を後回しにした構成は、止まった原因を追えずに再発するため、構築の段階で記録の形を決めておくのが近道です。

よくある質問

nvidia-smiについて、検索で多い疑問に答えます。

nvidia-smiはどこにインストールされていますか？

NVIDIAのドライバと一緒に入ります。単体で配布されているわけではないため、コマンドが見つからない場合はドライバが入っていないか、パスが通っていないかのどちらかです。CUDA 13.4以降はLinuxでもToolkitにドライバが同梱されなくなったので、Toolkitだけを入れた機械ではnvidia-smiも入っていない点に注意してください。

nvidia-smiのCUDA Versionと実際のCUDAの版が違うのはなぜですか？

ヘッダのCUDA Versionはドライバ側が報告する値で、インストールしたCUDA Toolkitの版ではないためです。Toolkitの版は nvcc --version で確かめます。ドライバが新しくToolkitが古い組み合わせは正常に動く一方、Toolkitがドライバの下限（CUDA 13.xなら580以上）を満たさない組み合わせは動きません。

GPU-Utilが100%なのに学習が遅いのはなぜですか？

GPU-Utilは、サンプル期間中に1つ以上のカーネルが動いていた時間の割合だからです。演算器の埋まり具合は表していません。小さなカーネルが連続しているだけでも100%になるため、バッチサイズ、データローダーの待ち、CPUとの転送を順に疑います。演算器単位の稼働を見たいなら、DCGMのプロファイリング系メトリクスを使う。

nvidia-smiをリアルタイムで監視するにはどうしますか？

画面で見張るなら watch -n 1 nvidia-smi、記録を残すなら nvidia-smi --query-gpu=... --format=csv -l 1 です。GPU単位の推移を1行ずつ流したいときは nvidia-smi dmon が使えます。既定の間隔は1秒で、-s で電力・使用率・メモリなど出す列を選べる。

nvidia-smiの値をPrometheusで監視できますか？

できます。NVIDIAが公開しているdcgm-exporterを起動すると、既定の9400番でPrometheus形式のメトリクスを返すため、scrape_configsに宛先を足すだけで取り込めます。nvidia-smiの出力を自分で解析してexporterを書く方法もありますが、保守を考えると公式のexporterを使うほうが早い。