【ITニュース解説】How to Monitor GPU Usage and Temperature on a Remote Server

リモートサーバーでGPU（Graphics Processing Unit）を使った計算処理を行う際、その状態を正確に把握することは非常に重要だ。特に、機械学習のトレーニングのような長時間の処理では、GPUが正常に機能しているかどうかの監視が不可欠となる。なぜなら、リモートサーバーでは、自分の手元のPCのようにファンの音や発熱を感じることができないため、目に見えない問題が進行し、貴重な計算時間を無駄にしてしまう可能性があるからだ。

リモートGPUで起こりがちな問題の一つに「熱暴走（Thermal Throttling）」がある。これは、GPUが高温になりすぎた際に、ハードウェアの損傷を防ぐために自動的に性能を落とす現象だ。例えば、GPUの温度が83℃から90℃を超えると性能が低下し始め、95℃を超えると故障のリスクや緊急停止の可能性が出てくる。しかし、リモート環境では、GPUが性能を落としていても、プロセス上は「実行中」と表示され、気づかないうちに処理速度が大幅に低下していることがある。これにより、数日かかるはずの計算がさらに遅れたり、途中で停止したりして、時間と費用を無駄にしてしまう可能性がある。このような事態を避けるために、GPUの使用率と温度を定期的に監視し、問題が発生する前に対応することが求められる。

監視の基本となるのは「nvidia-smi」というコマンドラインツールだ。これはNVIDIA製GPUのドライバーに標準で付属しており、GPUから直接センサーデータを読み取ることができる。このツールを使えば、GPUのインデックス、名前、使用率、メモリ使用量、合計メモリ、温度、消費電力といった詳細な情報を取得できる。例えば、特定のフォーマットで情報を取得したい場合は、nvidia-smi --query-gpu=index,name,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw --format=csv,noheader,nounits のようにオプションを指定することで、スクリプトで扱いやすいCSV形式で出力させることが可能だ。このコマンドの出力例は「0, NVIDIA A100-SXM4-40GB, 87, 38120, 40960, 74, 245.30」のようになり、左からGPUのインデックス、モデル名、使用率（%）、使用済みメモリ（MB）、全メモリ（MB）、温度（℃）、消費電力（W）を示している。この一行のデータで、GPUの健康状態を包括的に把握できるのだ。

まず、リモートサーバーにSSHで接続した際に、GPUの現在の状態を素早く確認する「ワンライナーヘルスチェック」を実行してみると良い。nvidia-smi --query-gpu=index,utilization.gpu,memory.used,memory.total,temperature.gpu --format=csv,noheader | awk -F', ' '{printf "GPU %s: util=%s%% mem=%s/%s MB temp=%s°C\n", $1, $2, $3, $4, $5}' というコマンドは、各GPUの利用率、メモリ使用量、合計メモリ、温度を整形して表示する。もし計算スクリプトが動いているはずなのにGPUの利用率が0%と表示されたら、データ読み込みの問題やプログラムのデッドロックなど、何かしらの異常が発生している可能性が高い。

さらに詳細な履歴データを残すためには、定期的にGPUのメトリクスをファイルに記録する仕組みを構築する。シェルスクリプトを作成し、nvidia-smiから取得したデータをタイムスタンプとともにCSVファイルに追記するように設定するのだ。例えば、/var/log/gpu-metrics.csvのようなファイルに「timestamp,gpu_index,util_pct,mem_used_mb,mem_total_mb,temp_c,power_w」というヘッダを一度だけ書き込み、その後は30秒ごとに新しいデータを追記していく。この定期実行は「cron」という機能を使って設定できる。cronは指定した時刻や間隔でコマンドを自動実行するもので、例えば1分に1回スクリプトを実行する設定を2行記述することで、30秒間隔でのデータ収集を実現できる。これにより、過去のGPUの状態を振り返り、問題の原因を特定するのに役立つデータが蓄積される。

ログデータが蓄積されても、それを見ていなければ意味がない。そこで、異常を検知した際に自動で通知するシステムを導入する。特に重要なのは温度の監視だ。別のシェルスクリプトを作成し、nvidia-smiで取得したGPUの温度が設定した閾値、例えば85℃を超えた場合に、メッセージを生成して外部サービスに送信するようにする。このメッセージ送信には、「webhook」という仕組みを利用できる。webhookは、特定のイベントが発生した際にHTTP POSTリクエストを自動で送信する機能で、SlackやDiscord、PagerDutyといった多くの通知サービスが対応している。スクリプトでは、curlコマンドを使って、JSON形式のメッセージデータをwebhookのURLに送信する。この通知スクリプトもcronで1分ごとに実行することで、GPUの温度スパイクをいち早く検知し、対応できるようになる。

ターミナル上でリアルタイムにGPUの状態を監視したい場合には、「nvitop」というツールが非常に便利だ。これはhtopのようなインタラクティブなTUI（ターミナルユーザーインターフェース）で、GPUごとのプロセス使用状況、メモリ、温度、消費電力をリアルタイムで表示する。SSH経由でも問題なく動作するため、ブラウザベースのダッシュボードがなくても、ターミナルからすぐに詳細な情報を確認できる。複数のサーバーを監視する場合には、nvitop --monitorという非インタラクティブモードでログシステムにデータを流し込むことも可能だ。

GPUの「サイレントキラー」として、温度以外にも注意すべき点が二つある。一つは「メモリリーク」だ。これは、プログラムが不要になったメモリを解放せず、VRAM（GPUメモリ）を徐々に占有していく現象を指す。最終的には「CUDA out-of-memory」エラーが発生し、プログラムが停止してしまう。nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits コマンドでメモリ使用量を定期的に確認し、エポックを重ねるごとにメモリ使用量が単調に増加し続け、一向に減らない場合はメモリリークの可能性が高い。もう一つは「利用率の低下」だ。トレーニングジョブが「実行中」と表示されているにもかかわらず、utilization.gpuが例えば20%以下で1分以上推移している場合、データの読み込みがボトルネックになっているか、プログラムがデッドロックに陥っている可能性が考えられる。GPUの利用率を定期的にチェックし、複数回連続して低い値が続いた場合にアラートを出す仕組みを導入することで、このような無駄な時間を減らせる。例えば、3回連続で利用率が低い場合に通知を出すといったスクリプトを、tmuxなどのセッションマネージャー内でトレーニングジョブと並行して実行することで、長時間の計算が途中で停止するリスクを回避できる。

これらの監視システムは、基本的に四つの要素から成り立っている。一つ目は、nvidia-smiコマンドによる生のデータ取得だ。これがすべての基礎となる。二つ目は、cronによる定期的なCSVロギングで、過去のデータを蓄積し、後からグラフ化したり分析したりできるようにする。三つ目は、webhookを通じた閾値アラートで、問題が発生した際に即座に通知を受け取る。そして四つ目は、nvitopを使ったライブでの状況確認で、詳細なインタラクティブな情報が必要な場合に役立つ。これらのシステムを構築するのに要する時間はわずか15分程度で、追加費用もかからない。しかし、これにより数日間の計算が無駄になることを防ぎ、大幅なコスト削減につながる可能性がある。リモートGPUをレンタルして利用する際には、このような監視体制を事前に整えておくことで、安心して長時間の計算に臨むことができるだろう。