🙆

【研究ノウハウ】最新AIモデル（SAM3）を回してもGPU利用率が上がらない理由と解決策

に公開
NVIDIA
GPU
中野哲平
SAM 3
並列gpu
tech

大学の研究室で、Metaの「SAM2（Segment Anything Model 2）」のような最新モデルを使って大量のデータ処理を始めたものの、**「GPUサーバーのスペックは高いのに、なぜか処理が終わらない」「nvidia-smiで見ると利用率がガクガク変動している」**という壁にぶつかることはありませんか？

本記事では、SAM2のメモリアーキテクチャを例に、大規模ビデオ処理におけるGPU利用率最適化のリアルを解説します。

1. なぜ最新AIでもGPUは「暇」をしてしまうのか？

ハイスペックなGPU（A100やH100など）を積んでいても、計算リソースを100%使い切るのは実は非常に高度な技術です。SAM2の処理では、以下の3つのコンポーネントが複雑に絡み合っています。

GPU負荷の構造

  1. 画像エンコーダ（重い）: フレームから特徴を抽出する。計算密度が高い。
  2. メモリアテンション（曲者）: 過去のフレーム情報を参照する。計算よりも「データの転送待ち」が発生しやすい。
  3. デコーダ（軽い）: マスクを出力する。一瞬で終わる。

利用率が激しく変動する最大の理由は、「計算（GPU）」と「データ準備（CPU/ストレージ）」の同期が取れていないことにあります。

2. ボトルネックの正体：GPUを「飢え」させる要因

GPU利用率が低いとき、GPU自体が遅いのではなく、**GPUにデータが届くまでの道のり（パイプライン）**に問題があります。

① CPUバウンドな「前処理・後処理」

ビデオを1枚ずつの画像にデコードしたり、結果をXMLやJSONに書き出したりする処理は、通常CPUで行われます。

  • 現状: 「CPUでデコード → GPUで推論 → CPUで保存」を直列で行っている。
  • 結果: CPUが作業している間、GPUは完全に「待ち」の状態（利用率0%）になります。

② VRAM（ビデオメモリ）の蓄積と断片化

SAM2は「過去の記憶」をメモリに溜め込みます。

  • 動画が長くなればなるほど、メモリ消費量は右肩上がりに増えます。
  • メモリが足りなくなる（OOM）のを恐れて、バッチサイズ（一度に処理する量）を小さくしすぎると、GPUの並列演算ユニットがスカスカになり、利用率が上がりません。

3. 実践：GPUをフル稼働させるための3つの戦略

研究を加速させるために、以下の最適化を検討してみましょう。

戦略1：非同期パイプライン（Producer-Consumerモデル）

「データの準備」と「計算」を並列化します。

  • CPUワーカー: 次に使うフレームを事前にメモリにロードしておく。
  • GPUワーカー: 届いたデータをひたすら計算する。
    これにより、GPUのアイドル時間を排除できます。

戦略2：カテゴリ・タスク単位の並列化

8基のGPUがある場合、1つの動画をみんなで分割するよりも、**「GPU 0は人物担当」「GPU 1は背景担当」**のように、モデルの重みを固定して横断的に処理する方が効率的です。

  • キャッシュが効きやすくなり、モデルの初期化オーバーヘッドを減らせます。

戦略3：インテリジェントなメモリ管理

SAM2には、VRAMを節約するための便利な設定があります。

  • offload_video_to_cpu=True: 計算に不要なフレームデータを一時的にメインメモリ（RAM）へ逃がす。
  • 明示的なキャッシュ解放: torch.cuda.empty_cache() を適切なタイミング（動画の切り替わり等）で呼び出す。

4. 研究者としての「システム・ビュー」の重要性

現代のAI研究は、単にモデルの精度（Accuracy）を競うだけでなく、**「いかに効率よく計算リソースを使い、短期間で実験を回すか」**というエンジニアリング能力が求められます。

項目 初級者のアプローチ 研究者・エンジニアのアプローチ
並列化 1つのスクリプトを1つのGPUで回す 複数プロセスを立ち上げ、タスクキューで管理
エラー処理 止まったら手動で再起動 監視スクリプトで異常検知と自動復旧
計測 「遅いな」と感じるだけ nvidia-smi やプロファイラで数値を可視化

まとめ：10倍速い研究サイクルを目指して

GPU利用率を上げることは、単なる「時短」ではありません。「1週間かかる実験が1日で終わる」ようになれば、試行錯誤の回数が7倍になり、それだけ研究の質が向上します。

もし、自分のプログラムを動かしてみてGPU利用率が低かったら、「どこでデータが詰まっているのか？」という視点でコードを見直してみてください。

5. データの「事前準備」でGPUを止めない（DataLoaderの活用）

最も多い失敗が、forループの中で「画像を読み込む→推論する」を愚直に書いてしまうパターンです。これでは画像読み込み（CPU）の間、GPUが遊んでしまいます。

改善前（非効率）

for frame_path in frame_list:
    image = load_image(frame_path)  # CPU処理：ここでGPUが止まる
    result = model.predict(image)   # GPU処理

改善後（マルチプロセス読み込み）

PyTorchのDataLoaderを使い、GPUが計算している間に、裏側のCPUプロセスで次のデータを準備（Pre-fetch）させます。

from torch.utils.data import DataLoader

# num_workersを増やすことで、CPUが裏で先に画像をデコードしておく
dataset = VideoDataset(frame_list)
dataloader = DataLoader(dataset, batch_size=1, num_workers=4, pin_memory=True)

for image in dataloader:
    image = image.cuda(non_blocking=True) # 転送も非同期に
    result = model.predict(image)

Point: pin_memory=True にすると、CPUからGPUへのデータ転送が高速化されます。

6. メモリ不足（OOM）を防ぐ「スマートな解放」

SAM2のようなモデルは、計算グラフやキャッシュがメモリに残り続け、ある日突然 RuntimeError: CUDA out of memory を吐きます。

実装例：動画切り替え時のクリーンアップ

1つの動画が終わるたびに、明示的に「掃除」をする関数を挟みましょう。

import torch
import gc

def clear_gpu_memory():
    # 1. SAM2固有のステートをリセット（これを忘れるとメモリが蓄積する）
    predictor.reset_state(inference_state)
    
    # 2. Pythonの参照を外す
    del inference_state 
    
    # 3. 未使用のメモリをOSに返却
    gc.collect()
    torch.cuda.empty_cache()

# SAM2の初期化時にオフロード設定を入れるのも有効
# predictor.init_state(video_path, offload_video_to_cpu=True)

7. 複数GPUを使い切る「タスク・キュー」方式

「8枚GPUがあるから、スクリプトを8個手動で立ち上げる」というのは、研究効率としては下策です。Pythonの multiprocessing を使い、空いているGPUに次々と仕事を振る仕組みを作ります。

簡易的な並列処理スケルトン

import multiprocessing as mp

def worker(gpu_id, task_queue):
    # 各プロセスが特定のGPUを占有
    torch.cuda.set_device(gpu_id)
    model = load_model() 
    
    while True:
        video_id = task_queue.get()
        if video_id is None: break # 終了信号
        
        print(f"GPU {gpu_id} is processing {video_id}...")
        process_video(model, video_id)

if __name__ == "__main__":
    num_gpus = torch.cuda.device_count()
    tasks = ["video_01", "video_02", "video_03", ...] # 大量のタスク
    queue = mp.Queue()

    for t in tasks: queue.put(t)
    for _ in range(num_gpus): queue.put(None) # 終了フラグ

    # GPUの数だけプロセスを起動
    processes = [mp.Process(target=worker, args=(i, queue)) for i in range(num_gpus)]
    for p in processes: p.start()
    for p in processes: p.join()

9. 最後に：何を計測すべきか？

最適化がうまくいっているかは、感覚ではなく数値で見ましょう。

  • nvidia-smi の GPU-Util: これが常に 80%以上 なら合格です。
  • Memory-Usage: 徐々に増えていって最後に落ちる（リークしている）のではなく、一定の範囲でノコギリ状に推移するのが理想です。

大学の貴重な計算リソースを「18%」しか使わないのはもったいないことです。これらの実装を取り入れて、**「マシンの限界まで使い倒す研究」**を目指してください！

Discussion