nvidia_gpu_exporter レビュー: nvidia-smi を Prometheus のメトリクスに変換する Go 製エクスポータ
Nvidia GPU exporter for prometheus using nvidia-smi binary OR using NVML
ひと目でわかる
- これは何？
- NVIDIA GPU の監視を、DCGM や GPU Operator を入れずに nvidia-smi の出力をパースして Prometheus 形式で公開するエクスポータ。実験的な NVML バックエンドとデモモードを備え、GeForce やホームラボ、制限された環境を主な対象にしている。
- 誰に向いている？
- GeForce や RTX を載せたワークステーション、小規模な Kubernetes クラスタ、vGPU や MIG スライスのように深いカウンタが取れない環境で、GPU Operator を入れるほどではないが GPU の使用率と温度を見たい場合に向く。データセンターカードを GPU Operator 管理下の Kubernetes で動かしているなら DCGM-exporter の方が適切で、この exporter を選ぶ理由は薄い。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Go です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
nvidia-smi しか情報源がない環境のためのエクスポータ
データセンター向けの GPU 監視は DCGM を前提に組み立てられていることが多い。だが GeForce や RTX を積んだワークステーション、ホームラボの 1 台、vGPU のゲスト、MIG で切り出したスライス、権限を絞ったコンテナといった場所では、DCGM が要求するカウンタやドライバの機能がそもそも露出していない。そこで最後に残るのが nvidia-smi である。README はこの点を明示していて、GeForce/RTX のようなコンシューマ向けとプロシューマ向けの GPU では「datacenter tooling exposes little and nvidia-smi is often the only uniform source of utilization, memory, power and temperature」と述べている。
このエクスポータが解く問題は、その nvidia-smi の出力を Prometheus が読める形式に変換することに尽きる。対象読者は大規模な GPU クラスタの運用者ではなく、GPU を数枚から数十枚持つ個人や小規模チーム、あるいは監視基盤をこれから整えるエッジの運用者である。README の use cases には小規模 Kubernetes クラスタ、エッジ、ホームラボ、混在した旧型と新型のカード、ゲーミング用途まで列挙されている。ゲーム中の GPU 統計をダッシュボードで見たいという用途は、業務監視の文脈からは外れているが、この道具の守備範囲の広さをよく表している。
nvidia-smi を実行してパースする、という素朴な仕組み
アーキテクチャは素朴である。エクスポータは nvidia-smi バイナリを実行し、その出力を解析して Prometheus のメトリクスとして HTTP で公開する。Go で書かれているが C バインディングを必要とせず、README の highlights は「Will work on any system that has nvidia-smi(.exe)? binary - Windows, Linux, MacOS... No C bindings required」と説明している。Linux 専用のドライバライブラリに直接リンクしないため、Windows でも同じバイナリが動く。
メトリクスのフィールドは自動検出される。README は「Auto-discovery of the metric fields nvidia-smi can expose (future-compatible)」と書いており、新しいドライバがフィールドを追加してもエクスポータ側のコード変更なしに拾える設計だと考えられる。収集のタイミングも選べる。既定ではスクレイプのたびに nvidia-smi を起動するが、オプションでバックグラウンド収集を有効にすると、タイマーで nvidia-smi を回し、スクレイプ時にはその結果を返す。スクレイプ間隔が短い環境ではプロセス起動のオーバーヘッドを避けられる。
もう一つの特徴は、監視対象のマシン上で動かす必要がない点である。nvidia-smi コマンドをリモートで実行するよう設定できると README は述べている。SSH 経由で別ホストの nvidia-smi を叩く構成が想定されており、GPU マシンに常駐プロセスを置きたくない場合の逃げ道になる。プロセス単位の GPU メモリ使用量も任意で取得でき、どのプロセスがどれだけ確保しているかを追える。
起動方法: Docker、デモモード、そして NVML 版のタグ
Linux で NVIDIA ドライバと NVIDIA Container Toolkit が入っている場合、README の quick start は次のコマンドを示している。
docker run -d --name nvidia_gpu_exporter --restart unless-stopped --gpus all -e NVIDIA_DRIVER_CAPABILITIES=utility -p 9835:9835 utkuozdemir/nvidia_gpu_exporter:latest
公開ポートは 9835 で、メトリクスは curl http://localhost:9835/metrics で確認できる。NVIDIA_DRIVER_CAPABILITIES=utility を渡しているのは、nvidia-smi の実行に必要なドライバ機能だけをコンテナに公開するためだ。
GPU が手元にない場合、デモモードが用意されている。nvidia_gpu_exporter --collect.backend demo を実行すると、GPU もドライバも Linux すらも不要で合成メトリクスが返る。既定では H200 相当の GPU 2 枚、MIG トポロジ、XID エラーの履歴を模擬し、値は変動する。NVML バックエンド専用のメトリクスファミリも含まれるため、ダッシュボードの表示確認やアラートルールの検証を実機なしで行える。
NVML バックエンドは専用のリリースフレーバーとして配布されている。releases ページから -nvml 付きのアーカイブを取得するか、イメージタグ latest-nvml を使う。README の例はこうだ。
docker run -d --name nvidia_gpu_exporter --restart unless-stopped --gpus all -e NVIDIA_DRIVER_CAPABILITIES=utility -p 9835:9835 utkuozdemir/nvidia_gpu_exporter:latest-nvml
Windows、macOS、パッケージ、Kubernetes、Docker なしでの実行については docs/INSTALL.md に譲ると README は案内している。winget 用のパッケージも用意されている。
実験的な NVML バックエンドが追加するもの
Linux では nvidia-smi を経由せず、NVIDIA ドライバライブラリである NVML から直接メトリクスを読むバックエンドを選べる。README によれば、既定バックエンドが返すすべてのメトリクスは名前、ラベル、値のいずれも同一に保たれるため、既存のダッシュボードとアラートはそのまま動く。互換性を壊さずに情報源だけを差し替える設計である。
その上で、nvidia-smi では取れないファミリが加わる。MIG インスタンス単位のメトリクス、XID エラーカウンタ、累積のエネルギーカウンタ、PCIe スループットの 4 つだ。公式の Grafana ダッシュボードにはこれらに対応するパネルがあり、既定バックエンドでは空のまま、NVML バックエンドで値が入る。MIG を使っている運用者にとっては、スライスごとの状態を追えるかどうかの差になる。
ただし README はこのバックエンドを experimental と位置づけている。理由として挙げられているのは、ドライバのバージョンと GPU の世代にわたる検証が足りていないことだ。試した結果は良いものでも悪いものでも issue として報告してほしいと呼びかけている。実験的というラベルは、機能が未完成というより検証範囲の狭さを意味している。詳細な比較と現時点の制限は docs/CONFIGURE.md の experimental native NVML backend の節にまとまっている。
DCGM-exporter との違いは何を前提に置くかにある
README 自身が代替を名指ししている。データセンター向けのカードを Kubernetes で動かし、すでに GPU Operator が入っているなら DCGM-exporter の方が適しているという。
両者の違いは情報の取り方にある。DCGM-exporter は NVIDIA の Data Center GPU Manager を通じて GPU の内部カウンタにアクセスする。前提としてドライバとユーティリティのスタック、そして多くの場合 Kubernetes 上のオペレータが必要になる。得られる情報は深く、データセンターカードの機能を引き出せる。nvidia_gpu_exporter は逆方向に振っていて、nvidia-smi というほぼすべてのドライバ構成に存在するコマンドの出力だけを頼りにする。取り立てて深い情報は得られないが、Windows でも動き、オペレータを入れずに 1 バイナリで完結し、GPU Operator の管理外にあるマシンでも同じように動く。
どちらが優れているという話ではない。深いカウンタが必要で、そのためにスタックを積む用意があるなら DCGM-exporter を選ぶ。スタックを積めない、あるいは積みたくない環境で、使用率、メモリ、電力、温度という基本項目を揃えたいならこのエクスポータが候補になる。README が use cases で「Mixed fleets of old and new cards that need one exporter that behaves the same everywhere」と書いているのは、この立ち位置の言い換えである。
向かない場面と、維持コストの見取り図
最初に理解すべき制約は、nvidia-smi が返さないものは何も得られないという点だ。MIG 単位のメトリクス、XID カウンタ、エネルギー、PCIe スループットは既定バックエンドでは存在せず、NVML バックエンドに切り替えて初めて現れる。しかもその NVML バックエンドは experimental であり、ドライバのバージョンや GPU の世代によって挙動が変わる可能性が README 自身によって示唆されている。本番のアラートを NVML 固有のメトリクスに依存させるのは、現時点では時期尚早と判断するのが妥当だ。
もう一つは、スクレイプごとに nvidia-smi を起動する既定動作だ。プロセス起動には相応のコストがかかる。スクレイプ間隔が短い、あるいは GPU 台数が多い構成では、バックグラウンド収集を有効にするか、そもそも DCGM-exporter を検討した方がよい。README がバックグラウンド収集をオプションとして用意していること自体、このコストが現実のものだと示している。
保守体制については README の警告が率直である。個人が余暇に維持しているサイドプロジェクトであり、issue や PR の確認に時間がかかるか、まったく手が回らないこともあると明記されている。活発なサポートを前提にした導入は避けるべきだ。
ライセンスは MIT で、商用利用を含めて制限が少ない。同梱される Grafana ダッシュボードは Grafana.com から別途インポートする形で、ID は 14574 が GPU 単位の詳細、25547 が複数 GPU の概要と README に記載されている。ライセンスの解釈については、実際の導入時に自組織の法務確認を経るのが無難である。
導入前に手元で確かめるべきこと
最初に確認するのは、対象ノードの nvidia-smi がどのフィールドを返すかである。エクスポータはフィールドを自動検出するため、ドライバのバージョンによって取得できる項目が変わる。まず curl http://localhost:9835/metrics を実行し、期待する使用率、メモリ、電力、温度のメトリクスが実際に並ぶかを見る。空のメトリクスは、そのノードの nvidia-smi がその項目を出していないという事実を意味する。
NVML バックエンドを試すなら、latest-nvml タグのイメージを別のポートか別のコンテナ名で立ち上げ、既定バックエンドと出力を比較するのが確実だ。README が互換性を約束している以上、差分は NVML 固有の 4 ファミリだけに収まるはずで、それ以外の差が出たならドライバとの組み合わせに問題がある。デモモードはこの比較の予行演習に使える。--collect.backend demo でダッシュボードを読み込ませ、パネルが期待どおりに描画されるかを本番前に確認しておくと、実機投入後の切り分けが減る。
編集部の結論
GeForce や RTX を載せたワークステーション、小規模な Kubernetes クラスタ、vGPU や MIG スライスのように深いカウンタが取れない環境で、GPU Operator を入れるほどではないが GPU の使用率と温度を見たい場合に向く。データセンターカードを GPU Operator 管理下の Kubernetes で動かしているなら DCGM-exporter の方が適切で、この exporter を選ぶ理由は薄い。導入前に確認すべきは、対象ノードで nvidia-smi が期待どおりのフィールドを返すか、そして NVML バックエンドを使うなら -nvml タグのイメージで自分のドライバと GPU 世代の組み合わせが動くかどうかである。
コミュニティノート