LLM VRAM 計算ツール

動作のしくみ

• 重みはパラメーター数 × 量子化の実効ビット数で、ビット数は llama.cpp の quantize ツールが示すファイルサイズから取っています。K-quant は一部のテンソルを高い精度のまま残すため、Q4_K_M の平均は 4 ビットではなく 4.9 ビットです。
• KV キャッシュは 2 × レイヤー数 × KV ヘッド数 × ヘッドサイズ × キャッシュするトークン数 × 要素あたりのバイト数なので、Grouped-Query Attention、キャッシュの型、コンテキストがすべて反映されます。Gemma 2 と 3 のスライディングウィンドウ層は、ウィンドウ分しかキャッシュしません。
• オーバーヘッドは、CUDA または Metal のコンテキスト用の 0.5 GB に、llama.cpp のデフォルトである 512 トークンのマイクロバッチで決まる計算バッファを加えたものです。語彙が大きいとメモリが増えるのはこのためです。
• GPU 表では、使用率 90% 未満のカードに ✓、90〜100% に ≈、収まらないカードには ✗ ×N を付け、N でモデルを分割するのに必要な枚数を示します。Mac は、macOS がデフォルトで GPU に使わせるユニファイドメモリの約 4 分の 3 で計算しています。

よくある質問

見積もりはどのくらい正確ですか？

全レイヤーをオフロードした単一 GPU の場合、重みと KV キャッシュは llama.cpp が確保する量と数パーセント以内で一致します。Llama 3.1 8B を Q4_K_M、8,192 トークンで計算すると、重み 4.58 GiB、KV キャッシュちょうど 1 GiB となり、llama.cpp が報告する値と同じです。ドライバー、デスクトップ、ほかのプログラムのために 5〜10% の余裕を残してください。

並列シーケンスとは何ですか？Ollama のコンテキストとの関係は？

サーバーが同時に保持する会話の数で、それぞれが独自の KV キャッシュを持ちます。Ollama では OLLAMA_NUM_PARALLEL、llama-server では -np にあたります。コンテキスト欄はシーケンスあたりの値なので、8,192 × 4 なら 32,768 トークンをキャッシュします。llama-server で言えば -c 32768 -np 4 です。

KV キャッシュは量子化すべきですか？

q8_0 はキャッシュを半分にし、品質の低下は測定が難しいほど小さいので、長いコンテキストでは良い選択です。q4_0 は 4 分の 1 になりますが、品質が目に見えて落ちることがあります。llama.cpp で V キャッシュを量子化するには flash attention が必要で、対応する GPU では自動的に有効になります。この見積もりは常に flash attention を前提としています。

ネイティブコンテキストについて警告が出るのはなぜですか？

どのモデルも一定の長さまでで学習されています。Qwen3 なら 40,960 トークン、Llama 3.1 なら 131,072 トークンです。それを超えてもメモリの見積もり自体は成り立ちますが、そもそも動作させるには YaRN などの RoPE スケーリングが必要で、品質もたいてい落ちます。そのため、その長さを超えたときにツールが知らせます。

別の呼び方

• LLM VRAM 計算
• ローカル LLM 必要 VRAM
• GPU メモリ 計算 LLM
• GGUF VRAM
• KV キャッシュ サイズ
• Ollama VRAM