【要約】GeForce + Windowsで「VRAM食ってる犯人」をプロセス単位で特定する（nvidia-smiが[N/A]問題） [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
ローカルLLMや画像生成を利用するユーザーが、VRAM不足時に原因プロセスを特定できない問題に直面している。WindowsのWDDM仕様により、標準的なツールでは詳細な内訳が取得できないためである。具体的には以下の課題がある。
- ・nvidia-smiを実行しても、プロセス別の使用量が[N/A]と表示される。
- ・タスクマネージャーでは、プロセスごとの詳細なVRAM使用量が見えない。
- ・予約量（Dedicated Usage）と実使用量（Local Usage）の乖離により、誤ったプロセスを犯人と誤認するリスクがある。
// Approach
Windows性能カウンターを活用し、プロセス単位での正確なVRAM使用量を特定する手法を採用している。さらに、物理的な接続構成を変更することで、描画負荷を回避するアプローチも提示している。
- ・PowerShellの
Get-Counterを用い、PIDごとのLocal Usage（実数）を抽出する。 - ・LUID（Locally Unique Identifier）を解析し、プロセスがdGPUかiGPUのどちらを使用しているか判別する。
- ・モニターの接続先をマザーボード（iGPU）に変更し、DWMの描画負荷を内蔵GPUへ逃がす。
// Result
プロセス単位での正確なVRAM監視と、物理的な構成変更によるVRAM容量の最大化を実現した。これにより、AIタスクへのリソース割り当てを最適化できる。
- ・ツール「VRAMaぴょん」により、プロセス別の実数表示とモデルの即時解放が可能になった。
- ・モニター接続の変更により、dGPUのVRAMを約1.5GB確保できることを確認した。
- ・ただし、モニターをマザボへ接続した場合、ゲーム性能はFFXIVベンチで約6.9%低下するトレードオフがある。
Senior Engineer Insight
> WDDM環境における「予約量」と「実数」の乖離を見抜いた点は、オブザーバビリティの観点で非常に重要である。多くのエンジニアが、予約量によるオーバーコミットを実使用量と誤認し、誤ったトラブルシューティングを行うリスクがある。また、ソフトウェア的な解決だけでなく、モニターの物理接続というハードウェア構成の変更によってVRAMを確保するハックは、極限のパフォーマンスを求める現場では極めて有効な手段である。ただし、Present方式による描画遅延や性能低下というトレードオフを、用途に応じて許容できるかの判断が不可欠である。