gpu-hot: NVMLを直接叩く自前ホスト型GPUダッシュボードの実装と限界
🔥 Real-time NVIDIA GPU dashboard
ひと目でわかる
- これは何？
- gpu-hot は NVIDIA GPU の使用率や温度、電力、プロセスをブラウザから見るためのセルフホスト型ダッシュボードだ。NVML を直接ポーリングする単一プロセス構成で、監視基盤を別途立てずに済む代わりに、GPU ノード側にコンテナを1つ置く前提を受け入れる必要がある。
- 誰に向いている？
- 1台から数十台の GPU サーバーを、監視基盤を組まずにブラウザで眺めたい個人や小規模チームには向いている。Docker と NVIDIA Container Toolkit が入ったノードに ghcr.io/psalias2006/gpu-hot:latest を流し、必要なら NODE_NAME と GPU_HOT_MODE=hub を足すだけで動く。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 22 日前です。
- 何の言語で書かれている？
- 主に JavaScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月16日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
監視スタックを組むほどではないが nvidia-smi を叩き続けたくもない
GPU サーバーを1台か2台持っている程度なら、監視は nvidia-smi のワンライナーで足りる。だが複数ノードになり、学習ジョブがどの GPU を掴んでいるかを横断で見たくなると、SSH を何枚も開く運用が破綻する。Prometheus と Grafana を立てる手もあるが、GPU のためだけに exporter、時系列DB、可視化、アラートルールを揃えるのは、見たい情報に対して重すぎる。gpu-hot が埋めるのはこの隙間だ。README は「Monitor a single machine or an entire cluster with the same Docker image」と書いており、単一ノードと複数ノードを同じイメージで扱う設計になっている。対象読者は、MLOps の専任を置かずに GPU ノードを回している開発者、あるいは検証用の GPU マシンを数台並べているチームである。メトリクスの保持やアラートではなく、いま何が起きているかを即座に見ることに用途を絞っている点が、この道具の性格を決めている。
NVML を直接ポーリングし、WebSocket でブラウザへ押し出す
リポジトリ構成を見ると、コレクタは core/monitor.py にあり、README はこれを「NVML GPU monitoring」と説明している。nvidia-smi のテキストを毎回パースするのではなく、NVML の API から直接メトリクスを引く経路が主で、core/nvidia_smi_fallback.py が古い GPU 向けの代替として用意されている。収集したデータは core/handlers.py の WebSocket ハンドラを通じて配信され、フロント側は static/js/socket-handlers.js で受けてバッチ描画する。HTTP 側には GET /api/gpu-data があり、同じスナップショットを JSON で取れる。つまりデータの流れは、NVML ポーリング、メモリ上のスナップショット、WebSocket ブロードキャスト、Chart.js による描画という一直線の構成で、中間にデータベースもメッセージブローカーも挟まらない。multi-node の場合は core/hub.py と core/hub_handlers.py が追加され、hub が各ノードの URL をポーリングして自前の WebSocket に載せ替える。ノード側のエージェントと hub が別プロセスではなく別モードとして同じコードベースに同居している点は、配布物が1つのイメージで済む利点であり、同時に hub 側の責務が増える要因でもある。
起動は docker run 一発、設定は環境変数に集約されている
単一マシンなら README の例のとおり、docker run -d --gpus all -p 1312:1312 ghcr.io/psalias2006/gpu-hot:latest を実行し、http://localhost:1312 を開く。複数台では各 GPU サーバーで -e NODE_NAME=$(hostname) を付けて同じイメージを起動し、GPU を持たない hub 側で -e GPU_HOT_MODE=hub -e NODE_URLS=http://server1:1312,http://server2:1312 のようにノードを列挙する。hub モードでは NODE_URLS が必須で、カンマ区切りの URL をそのまま解釈する。ポーリング間隔は UPDATE_INTERVAL（既定 0.5 秒、NVML 経路）と NVIDIA_SMI_INTERVAL（既定 2.0 秒、フォールバック経路）で調整でき、どちらも秒単位の小数を受け付ける。ポートは core/config.py の PORT = 1312 で定義されており、環境変数ではなくコード側の定数なので、変更するならコンテナ内のこのファイルに手を入れることになる。GPU の選択は NVIDIA_VISIBLE_DEVICES=0,1 のように指定する。古い GPU で値が出ない場合は -e NVIDIA_SMI=true を足す。プロセス名まで見たい場合は --init --pid=host を付けるが、README 自身が「This allows the container to access host process information」と注記しているとおり、ホストのプロセス情報へのアクセスを許すことになる。ソースから動かす場合は git clone ののち docker-compose up --build で、Dockerfile と docker-compose.yml が同梱されている。前提は Docker と NVIDIA Container Toolkit で、GPU が見えないときは nvidia/cuda:12.1.0-base-ubuntu22.04 の nvidia-smi で切り分ける手順が README に示されている。
クライアントが離れるとポーリングが止まる設計
README には「Polling is paused automatically when no clients are connected, so idle CPU usage stays near zero」とある。監視ツールは常時動き続けるものが多く、その前提でノードのリソースを計算する。gpu-hot は逆で、ブラウザを閉じれば収集も止まる。GPU ノードの CPU を学習ジョブに使いたい現場では素直にありがたい挙動だが、裏返すと、誰も見ていない時間帯のデータは存在しないということでもある。後から「昨夜のスパイクを見たい」と思っても、その時間にダッシュボードを開いていなければ履歴は残っていない。README の Features にある「Historical charts」は、あくまでセッション中に蓄積された系列をブラウザ側で描くものと読める。時系列データベースへの書き出しや保持期間の設定は、少なくとも README とリポジトリ構成からは確認できない。ここは用途をはっきり分けるべき線で、障害調査や課金のための記録が必要なら、この道具は答えを出さない。
hub モードは監視の穴を1つ増やす
マルチノード構成を取ると、hub が単一障害点になる。hub コンテナが落ちれば、ノード側で収集が続いていても画面は止まる。README のトラブルシューティングは「Hub can't connect to nodes」に対して curl http://node-ip:1312/api/gpu-data で疎通確認、sudo ufw allow 1312/tcp でファイアウォール確認という手順を示しており、実際に詰まるのはこの2点だという著者の見立てが読み取れる。加えて、hub は各ノードの HTTP エンドポイントをポーリングする構造なので、ノード数が増えれば hub 側のポーリング負荷が線形に増える。README の Features には「Scale from 1 to 100+ GPUs」とあるが、これは GPU 数であってノード数ではない。100 ノードを1つの hub に集約したときにポーリングが破綻しないかは、この資料からは判断できない。もう1つの制約は、hub とノードの間が平文 HTTP であることだ。NODE_URLS に https を書けるかどうかについての記述はなく、認証ヘッダを付ける仕組みも README には見当たらない。信頼できないネットワークをまたぐ構成は、このままでは取りにくい。
NVIDIA_SMI=true は互換のための逃げ道であって同等ではない
古い GPU でメトリクスが出ないときの回避策として README が挙げるのが -e NVIDIA_SMI=true だ。core/nvidia_smi_fallback.py がこの経路を担う。ただしポーリング間隔が別変数に分かれていること（NVIDIA_SMI_INTERVAL の既定は 2.0 秒で、NVML 経路の 0.5 秒より粗い）からも分かるように、この経路はコマンド実行のオーバーヘッドを前提にした設計になっている。README の Features に列挙されたメトリクス、PCIe 情報、P-State、スロットル状態、エンコーダ・デコーダセッションといった項目が、nvidia-smi の出力からどの程度そのまま取れるのかは明記されていない。フォールバックに切り替えたら、まず GPU カードに出ている項目が減っていないかを確認するべきである。ここを「古い GPU でも同じ画面が出る」と読むのは README の書き方からは行き過ぎで、実際には取れる項目が変わる可能性を織り込んでおきたい。
dcgm-exporter との違いは、押し出しか引き出しかにある
比較対象として素直なのは NVIDIA の dcgm-exporter だ。こちらは GPU メトリクスを Prometheus 形式で公開することを役割にしたコンポーネントで、可視化は Grafana に、保存は Prometheus に、通知は Alertmanager に委ねる。gpu-hot はその逆で、収集から描画までを1つのコンテナに閉じ込め、ブラウザで開いた瞬間に WebSocket で押し出す。この違いは導入の重さに直結する。dcgm-exporter は既存の Prometheus 運用があれば1行のスクレイプ設定で済むが、運用がなければ一式を立てることになる。gpu-hot は一式を立てずに済むが、代わりに保持も通知も持たない。もう1つ見逃せないのは、dcgm-exporter が DCGM を経由するためデータセンター向け GPU の詳細なカウンタに踏み込めるのに対し、gpu-hot は NVML と nvidia-smi の範囲に留まる点だ。逆に gpu-hot が勝っているのは、system メトリクス（CPU、RAM、スワップ、ディスク、ネットワーク）を同じ画面に同居させていることと、プロセス単位の表示を持っていることである。学習ジョブがどの GPU を掴んでいるかを目視したいだけなら、この差は大きい。
MIT ライセンスと、更新に伴う追従コスト
ライセンスは MIT で、リポジトリに LICENSE が置かれている。改変、再配布、商用利用を含めて制約が緩く、社内のダッシュボードに組み込むといった使い方でも条件を読み解くのに苦労しない。ただし MIT は無保証であり、GPU ドライバや CUDA のバージョンアップで NVML の挙動が変わったときに誰かが直してくれる保証はない。この点は法務の話ではなく運用の話で、自前で追う覚悟が要る。更新頻度は比較的高く、直近では v1.9.0 が 2026-05-28、v1.9.1 と v1.9.2 が 2026-07-18 に立て続けにリリースされている。パッチが同日に2本出ているのは、リリース直後の修正が続いたということでもある。コンテナイメージは ghcr.io/psalias2006/gpu-hot:latest を指定する例が README に示されているが、latest は可動タグなので、ノード群を揃えるならバージョン固定のタグを使うほうが事故が少ない。アップグレードはノード側と hub 側の両方でイメージを差し替える作業になり、hub だけ先に上げると API の形がずれる可能性がある。バージョン確認用に GET /api/version が用意されているので、切り替え後にこれを叩いて揃っているかを確かめるのが現実的な手順になる。
編集部の結論
1台から数十台の GPU サーバーを、監視基盤を組まずにブラウザで眺めたい個人や小規模チームには向いている。Docker と NVIDIA Container Toolkit が入ったノードに ghcr.io/psalias2006/gpu-hot:latest を流し、必要なら NODE_NAME と GPU_HOT_MODE=hub を足すだけで動く。逆に、メトリクスを長期保存してアラートを引きたい、Grafana のダッシュボード資産がすでにある、NVIDIA 以外のアクセラレータも同じ画面で見たい、という要件があるなら dcgm-exporter 側を検討したほうがよい。導入前に確認すべきは、対象 GPU で NVML から値が取れるか、取れない場合に NVIDIA_SMI=true で何が欠けるか、そして --pid=host を付けたときにプロセス名をどこまで見せるかだ。
コミュニティノート