【要約】GeForce + Windowsで「誰がVRAM食ってるの？」をプロセス単位で見る（nvidia-smiが[N/A]になる問題） [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
ローカル環境でLLMや画像生成AIを運用するユーザーが、VRAM不足時に原因プロセスを特定できない問題に直面している。\n・背景: WindowsのWDDM（Windows Display Driver Model）がGPUメモリを仮想化して管理している。\n・現象: GeForce環境では、nvidia-smiを実行してもプロセス別のVRAM使用量が[N/A]と表示される。\n・課題: ドライバ側から物理VRAMの使用量を直接取得できないため、犯人プロセスを特定できない。\n・影響: モデルの再ロードやPCの再起動といった、場当たり的な対処を余儀なくされる。
// Approach
筆者はWindowsの性能カウンターを活用し、プロセスごとの専用VRAM使用量を直接取得する手法を採用した。\n・手法: PowerShellの
Get-Counterコマンドを用いて、\GPU Process Memory(*)\Dedicated Usageを取得する。\n・解析: 取得したInstanceNameから正規表現を用いてPIDとLUIDを抽出する。\n・識別: LUIDを解析することで、プロセスがdGPUか内蔵GPUのどちらを使用しているか判別する。\n・ツール化: 可視化、Ollamaのモデル解放、GPU優先設定の自動化を行うツール「VRAMaぴょん」を実装した。// Result
性能カウンターの活用と適切なハードウェア構成により、AI処理へのリソース割り当てを最適化できる。\n・可視化: PID単位でのVRAM使用量と、使用GPUの特定を正確に行えるようになった。\n・解放: Ollamaのモデル解放や画像生成ソフトのアンロードを、プロセスを殺さず実行できる。\n・最適化: モニターをiGPUに接続することで、dGPUのVRAMを約1.5GB解放できる。\n・検証: ただし、モニターをiGPUに繋ぐとゲーム性能が約7%低下するトレードオフが存在する。
Senior Engineer Insight
> OSの仕様（WDDM）による制約を、性能カウンターという別レイヤーのデータで補完するアプローチは極めて合理的だ。単なる可視化に留まらず、API経由でのメモリ解放やレジストリ操作によるGPU割り当て制御まで実装している点は、開発体験（DX）の向上に大きく寄与する。ただし、物理的な接続変更による性能低下（約7%）というトレードオフを理解した上での運用設計が不可欠である。