ローカルLLMのVRAM別モデルサイズ早見：8〜32GBで載る量子化とKVキャッシュ

ローカルLLMが手元のGPUに載るかどうかは、GGUFファイルのサイズに、コンテキスト長に比例するKVキャッシュと1GB強の計算バッファを足した値で決まります。ファイルサイズだけで選ぶと、コンテキストを伸ばした瞬間にVRAMから溢れてCPUオフロードが始まり、速度が一桁落ちます。

この記事では、Hugging Faceに公開されている各モデルのGGUF実ファイルサイズと、NVIDIAの技術ブログにあるKVキャッシュの式を使って、VRAM 8 / 12 / 16 / 24 / 32GB以上の帯ごとに「載るモデルと量子化」を整理します。RTX 3090（24GB）でOllamaに4モデルをロードして ollama ps の実測も取りました。Ollama自体の導入はOllama導入ガイドにまとめています。

見積もりの式：重み + KVキャッシュ + バッファ

重み（GGUFファイルサイズ）

Hugging Face Hubの解説によると、Q4_K は「4.5ビット/重み」、Q5_K は5.5、Q6_K は6.5625、Q8_0 は8ビットです。同じモデルでも量子化でファイルサイズがほぼ比例して変わります。unsloth/Qwen3.6-27B-GGUFのファイル一覧から抜粋すると次の通りでした。

Qwen3.6-27B-Q3_K_M.gguf     13.6 GB
Qwen3.6-27B-UD-Q3_K_XL.gguf 14.5 GB
Qwen3.6-27B-Q4_K_M.gguf     16.8 GB
Qwen3.6-27B-Q5_K_M.gguf     19.5 GB
Qwen3.6-27B-Q6_K.gguf       22.5 GB
Qwen3.6-27B-Q8_0.gguf       28.6 GB

KVキャッシュ（コンテキスト長に比例）

NVIDIAの技術ブログ「Mastering LLM Techniques: Inference Optimization」に、1トークンあたりのKVキャッシュサイズが次の式で示されています。

KVキャッシュ (bytes/token) = 2 × num_layers × (num_heads × dim_head) × precision_in_bytes

先頭の2はKとVの2行列分、num_heads × dim_head は通常hidden sizeに等しい、と同記事にあります。ただし現在の多くのモデルはGQA（Grouped Query Attention）でKVヘッド数がクエリヘッド数より少ないため、ここはKVヘッド数で読み替えます。各値は ollama show <model> --verbose の block_count（層数）、attention.head_count_kv（KVヘッド数）、attention.key_length（ヘッド次元）で確認できます。

qwen2.5:7b の実値は層数28、KVヘッド4、ヘッド次元128でした（Hugging Faceの config.json でも num_hidden_layers: 28 num_key_value_heads: 4）。

2 × 28 × (4 × 128) × 2 bytes = 57,344 bytes ≒ 56 KiB / token
   4,096 tokens →  0.22 GiB
  32,768 tokens →  1.75 GiB

実測と突き合わせると、num_ctx 4096 で ollama ps は4.7GB、32768 で6.6GB。差の1.9GBは、式の差分1.53GiBに計算バッファの増分が乗った値として辻褄が合います。

Gemma 4とQwen3.6は層ごとにKVヘッド数やアテンション方式が違う（head_count_kv が配列で返る、Qwen3.6-35B-A3Bは40層中10層だけがGated Attention）ため、この単純式では過大評価になります。こうしたモデルは実測で見るしかありません。

KVキャッシュを減らす2つの手段

Ollamaの公式FAQには OLLAMA_KV_CACHE_TYPE に f16 / q8_0 / q4_0 を指定できるとあります。q8_0 で上の値は半分になります。もう一つはコンテキスト長そのものを num_ctx（API）や OLLAMA_CONTEXT_LENGTH（環境変数）で抑えることです。FAQには「必要メモリは OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH に比例」ともあり、並列数を上げるならその分もKVキャッシュが増えます。

RTX 3090 での実測

num_ctx を8192に固定して4モデルを順にロードし、/api/ps の size_vram を記録しました。すべて 100% GPU に載っています。

生成速度（eval_count / eval_duration）は gpt-oss:20b が118 tok/s、qwen3.6:35b-a3b が112 tok/s、qwen3-coder:30b が82 tok/s、gemma4:31b が33 tok/s でした。MoE（アクティブ3〜4B）の3本が速く、密な31Bが遅い、という順です。

qwen3.6:35b-a3b は8Kコンテキストで21.72GiBなので、24GBのGPUでは残りが2GiB強しかありません。実際にClaude Codeから qwen3-coder:30b を32Kコンテキストで使ったときは ollama ps が21GBを示しており、8Kとの差3GBは式の見積もり（24,576トークン × 96KiB ≒ 2.25GiB）と概ね一致しました。

VRAM帯ごとの現実解

以下のファイルサイズはHugging Faceの各リポジトリのファイル一覧（2026-09-14閲覧）から引用しています。「余裕」は上の式で32Kコンテキスト程度を想定した筆者の目安です。

8GB（RTX 3060 Ti / 4060 など）

• Qwen3.5-9B Q4_K_M 5.68GB（unsloth）。201言語対応をうたうモデルカードで、9Bとしては日本語も期待できる帯。
• Gemma 4 E4B Q4_K_M 4.98GB（unsloth）。実効4.5Bで、コンテキスト128K、音声入力にも対応。
• llm-jp-4-8b-thinking Q4_K_M 5.3GB。日本語向けで、後述の用途別モデル選びでも扱う。
• Gemma 4 12B Q4_K_M（7.12GB）はコンテキストを4K程度に絞れば載る可能性がありますが、余裕はありません。Q3_K_M（5.69GB）に落とすのが無難です。

12GB（RTX 3060 12GB / 4070 など）

• Gemma 4 12B Q4_K_M 7.12GB。KVキャッシュ込みで32K前後まで取れる帯。
• Qwen3.5-9B Q8_0 9.53GB。精度を優先するならこちら。ただしコンテキストは16K程度が上限になる。
• gpt-oss-20b の MXFP4（12.1GB）は12GBには載りません。一部CPUオフロードになります。

16GB（RTX 4060 Ti 16GB / 4080 / 5070 Ti など）

• gpt-oss-20b MXFP4 12.1GB（ggml-org）。モデルカードが「16GBのメモリで動く」と明記しており、実測でも8Kで11.97GiB。
• Gemma 4 12B Q8_0 12.7GB。
• Qwen3.6-27B は UD-Q3_K_XL（14.5GB）でぎりぎり。コンテキストは8K程度で、実用には厳しい。

24GB（RTX 3090 / 4090 など）

• Qwen3.6-27B Q4_K_M 16.8GB（unsloth）。密モデルで、KV 32K分を足しても余裕がある。
• Gemma 4 31B Q4_0 17.7GB（Google公式QAT版、画像用mmproj 1.2GBは別）。実測18.87GiB@8K。
• qwen3-coder:30b Q4_K_M。実測17.95GiB@8K、21GB@32K。
• Qwen3.6-35B-A3B UD-Q4_K_M 22.1GB。実測21.72GiB@8K。載るが、コンテキストを伸ばす余地はほぼない。 3B活性で速い代わりに、この帯では UD-Q3_K_XL（16.8GB）に落として余裕を作る選択もある。
• llm-jp-4-32b-a3b-thinking Q4_K_M 21.4GB も同様に「載るが余裕なし」。

32GB以上（32GB級GPU / 48GB級 / Apple Silicon / Strix Halo）

• 32GB: Qwen3.6-27B Q6_K 22.5GB が余裕を持って載り、Q8_0（28.6GB）はKV分が残らないので実質不可。
• 48GB: Gemma 4 31B Q8_0 32.6GB（ggml-org）、Llama 3.3 70B Q4（Ollamaライブラリで43GB）。
• 64GB以上: gpt-oss-120b（Ollamaライブラリで65GB、モデルカードは「80GB GPU 1枚に収まる」）。128GB統合メモリの小型機についてはRyzen AI Haloの記事で扱っています。

量子化を選ぶ順序

Hugging Faceの解説にあるビット/重みを基準にすると、選び方は機械的に決まります。

1. VRAMがファイルの1.5倍以上あるなら Q8_0（8bit）。 精度劣化が最小で、コンテキストも十分取れる。
2. それ未満なら Q4_K_M（4.5bit）。 現状のデファクトで、Ollamaライブラリの既定タグもほぼこれ。
3. Q4_K_Mでも溢れるなら、Q3系に落とすより1段小さいモデルを選ぶ。 3ビット台は劣化が目立ちやすく、同じVRAMなら「小さいモデルのQ4」の方が安定する。
4. MXFP4（gpt-oss）やQAT版（Gemma 4のq4_0）はモデル側が量子化前提で調整済みなので、同じ4ビットでも通常の事後量子化とは別枠で考える。

どのモデルが用途に合うかは用途別モデル選び 2026に、GPU自体の選び方はローカルLLM GPU選びに分けています。手元のスペックを入れて候補を絞るならローカルLLMレコメンダーが早いです。

まとめ

• 必要VRAM ≒ GGUFファイルサイズ + KVキャッシュ + 1〜1.5GB。ファイルサイズだけで判断しない
• KVキャッシュは 2 × 層数 × KVヘッド数 × ヘッド次元 × 2バイト/トークン。ollama show --verbose の値を代入すれば自分で出せる
• RTX 3090実測: gpt-oss:20b 11.97GiB、qwen3-coder:30b 17.95GiB、gemma4:31b 18.87GiB、qwen3.6:35b-a3b 21.72GiB（いずれも8K）
• 24GBでは27〜35BのQ4が32K前後まで。256Kフルは重みより先にKVキャッシュがVRAMを埋める
• 量子化はQ8_0 → Q4_K_M → 1段小さいモデル、の順で落とす。OLLAMA_KV_CACHE_TYPE=q8_0 でKV分は半分にできる

式と実測の差が1〜2GBに収まることが確認できたので、新しいモデルを試す前に ollama show --verbose の3つの数値を式に入れるだけで、載るかどうかはダウンロード前に分かります。