ローカルLLMがVRAM不足？gputaskmanで重みとKVキャッシュを確認

昨日はローカルモデルが問題なくロードされたのに、今日はロード時にクラッシュする、あるいは極端に遅い。変更したのはコンテキスト長だけ。よくある原因はKVキャッシュで、gputaskman という無料のターミナルツールを使えば、当てずっぽうに頼らずにそれを確認できます。

一般的なGPUモニターはVRAMがどれだけ埋まっているかを教えてくれます。それは「何が」であって「なぜ」ではありません。gputaskman のREADME（2026年11月5日確認）は自らを「GPUの中身を見るためのhtop。満杯度だけではない」と称しています。初期段階の実験的プロジェクトでMITライセンスなので、便利なレンズとして扱い、断定とは考えないでください。

実際にVRAMを埋めているもの#

VRAMをスーツケースと考えてみましょう。入るものは3つです。

• 重み: モデル本体。特定のモデルと量子化に対してサイズは固定です。
• KVキャッシュ: 会話に対するモデルの短期記憶。コンテキストが伸びるにつれて増えます。
• 計算バッファ: ランタイムが動作中に必要とする作業領域。

「モデルが収まらない」と言うとき、多くの場合、重みは収まるがその上に要求したキャッシュが収まらなかったという意味です。この区別が対処法を決め、まさに普通のモニターが隠してしまうものです。

gputaskman をインストールしてプロセスごとに見る#

READMEには導入方法が3つあります。ポータブルなWindows ZIP、uv run --locked gputaskman で実行するクローン、Python 3.11+の仮想環境内でのpipです。READMEが説明するプラットフォームは次のとおりです。

• Windows 10/11 64ビットでNVIDIAまたはAMD GPU（x64とARM64のZIPがReleasesページにあります）。
• NVIDIA GPU搭載のLinuxとWSL（glibc 2.35+。WSLはWindowsホストのカウンターを読めます）。
• macOSはApple Siliconのみ、ソースクローンからのみで、ポータブルビルドはありません。

WindowsのZIPは署名されていません。公式リポジトリ github.com/shanselman/gputaskman のReleasesページからのみダウンロードしてください。コマンドはREADMEから正確にコピーしてください。プロジェクトは若く、オプションは変わる可能性があります。

起動したら、この問題では2つのビューが重要です。

1. デバイスビュー: VRAM使用量、GPUアクティビティ、PCIe、温度、電力、クロック、履歴チャート。「何かが急増したか？」に適しています。
2. プロセスビュー: プロセスごとのローカルGPUメモリ、GPUからアクセス可能なシステムRAM、エンジンのアクティビティ、検出されたランタイム（CUDA、HIP、Vulkan、Direct3D、ggml、ONNX Runtime）。

プロセスビューでモデルサーバー（Ollamaなら同梱のランナー）を見つけます。次にリストの残りを確認します。ブラウザやゲームが数ギガバイトを保持していれば、モデルに触れずに答えが見つかったことになります。

重み、KVキャッシュ、バッファ：数値の出どころ#

モデルインスペクターは、利用可能な場合にアーキテクチャ、量子化、バッファサイズを表示します。注意点が1つあります。READMEによれば、重み、KVキャッシュ、計算バッファは、互換性のあるログが有効な場合にランタイムのロードログから取得されます。llama.cppでは、ログ付きで自分の llama-server を起動します（--log-file server.log -lv 4。バッファサイズにはレベル4が必要とREADMEにあります）。Ollamaでは、利用可能であればOllamaの server.log をgputaskmanが使います。そうでなければ、GGUFメタデータとコンテキストサイズから、llama.cpp方式の配置を仮定した推定値になります。単一プロセス内でのモデルごとのKV計算はまだサポートされていません。

そのため、推定の内訳は「おおよそ」、ログベースの内訳は「ランタイムが報告したもの」として読んでください。Ollamaについては、同梱ランナーが検出され、GGUFブロブはOllamaのマニフェストから命名され、利用可能な場合は server.log が使われるとREADMEにあります。LM Studioのサポートは部分的です。モデルはそのフォルダから命名され、ローカルAPI経由でプローブされますが、これはフィクスチャ応答でテストされたもので、エンドツーエンドではありません。

2つのスナップショットをJSONとして保存し、diff コマンドで比較することもできます。「4Kから16Kコンテキストに変えたとき何が変わったか？」に答えるきれいな方法です。スナップショットを1つ取り、設定を変え、リロードし、もう1つ取ります。

どのつまみを回すか#

内訳を読むことで、単なる絵ではなく判断が得られます。

重みが大きな部分を占める場合。 より小さい量子化かより小さいモデルに移ってください。重みを縮める唯一のレバーです。その背後にあるメモリ計算を知りたい場合は、125Bモデルは16GB GPUで動くか？ を参照してください。

KVキャッシュが大きな部分を占める場合。 コンテキストを短くしてください。Ollamaではセッション内ですぐに試せます。

ollama run <your-model>
>>> /set parameter num_ctx 8192

8192 はあくまで例の値です。タスクが本当に必要とするものを選んでください（コマンドはOllamaのドキュメントに準拠、2026年11月5日確認）。

後でllama.cppで量子化キャッシュを使ったプロンプト処理に奇妙な遅さが出る場合は、q5_1 KVキャッシュ向けのこの修正 が次の一手です。コンテキストウィンドウがそもそも何を保持するかについては、コンテキストウィンドウとは？ を読んでください。

別のプロセスが大きな部分を占める場合。 それを閉じるか、内蔵GPUで実行してください。モデル側で変える必要は何もありません。

うまくいかない場合#

• 内訳がおかしい。 推定値かどうか（互換性のあるロードログがない）を確認してください。llama.cppでは、--log-file server.log -lv 4 付きで llama-server を起動し、モデルをリロードしてください。Ollamaでは、存在すればgputaskmanは server.log を使います。そこでは推定値ラベルは正常です。
• LM Studioの詳細が少ない。 上記のとおりサポートは部分的です。
• NVIDIAまたはAMD GPUがない。 このツールはローカルGPUワークロードのみを対象とし、CPUのみ、NPUのみ、クラウドのワークロードは対象外です。
• macOS。 ソースクローンから実行してください。ポータブルビルドはありません。

ホスト型モデルの方が簡単な場合#

大きなドキュメントの要約など、あるタスクに長いコンテキストが必要で、GPUには短いコンテキストでしかモデルが収まらないとします。調整を続けることもできますが、VRAMを問題から外すこともできます。そうしたタスク向けにCheapTokensは DeepSeek-V4-Flash を提供しています。380Kコンテキスト、回答あたり最大32,768出力トークン、時間帯を問わず一律価格、OpenAI互換API経由です。GLM-5.3-Flashは390Kコンテキストと最大8,192出力トークンを持ちます。

呼び出しは通常のOpenAI形式です（キーは環境変数に入れてください）。

curl https://api.cheaptokens.dev/v1/chat/completions \
  -H "Authorization: Bearer $CHEAPTOKENS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-ai/DeepSeek-V4-Flash-0731", "messages": [{"role": "user", "content": "Summarize this document: ..."}]}'

セットアップの詳細はドキュメントにあります。判断の目安として、タスクがカードに収まる以上のコンテキストやより大きなモデルを必要とし続け、プロセスビューでVRAMがすでにかなり使われているなら、そのタスクはAPIに送り、小さく速いジョブはローカルに残してください。DeepSeekをローカルで動かすかAPIを使うか？ がトレードオフをより深く掘り下げています。

100個の大きなドキュメントを要約し、それぞれ60,000入力トークンと1,000出力トークン（380Kウィンドウに十分収まる）だとします。今日のコストは次のとおりです。

この数値では、1ドキュメントあたり $0.001 がそうした1回の呼び出しの実勢価格で、入力と出力を合計した総額はOpenRouterを下回ります。