ローカルLLMの必要メモリ（VRAM）の計算方法

1. モデルファイルのサイズ 実測

llama.cpp 系のツールは GGUF ファイルをそのままメモリに載せるので、モデルの重みが使うメモリはファイルサイズとほぼ同じです。 このサイトでは Hugging Face が返すファイルサイズ（バイト単位の実物の値）を使います。 ファイルが -00001-of-00003.gguf のように分割されている場合は、全部の合計です。

2. KVキャッシュ 推定

LLM は文章を1トークンずつ作るたびに、それまでの全トークンの「キー（K）」と「バリュー（V）」を参照します。 これを毎回計算し直さないよう保存しておくのが KV キャッシュで、コンテキスト長（扱うトークン数）に比例して大きくなります。

式に入れる値は、元モデルの config.json から取ります

Qwen3-8B では 1トークンあたり 2 × 36 × 8 × 128 × 2 バイト ＝ 147,456 バイト（144 KiB）。 32K トークン（32,768）なら 4,831,838,208 バイト ＝ 4.83 GB（ちょうど 4.5 GiB）です。 出典：Qwen/Qwen3-8B の config.json（2026-09-26 確認）

3. スライディングウィンドウの層は、窓の分だけ

Gemma 3 や gpt-oss には、直近の一定トークン（窓）だけを見るスライディングウィンドウ注意（SWA）の層があります。 llama.cpp はこの層の KV キャッシュを、コンテキスト長ではなく「窓 ＋ 512」を 256 の倍数に切り上げた長さだけ確保します （512 は一度に処理するトークン数 n_ubatch の既定値）。

Gemma 3 27B（Q4_K_M）：SWA を考えるかどうかで、ここまで変わる

gpt-oss-20b は窓が 128 と小さいため、最大の 131,072 トークンでも KV キャッシュは 3.24 GB（うち SWA 層は 19 MB）、推定必要メモリは 15.8 GB（Q4_K_M、11.6 GB）です。

4. KVキャッシュの量子化（q8_0・q4_0）

llama.cpp では KV キャッシュ自体を量子化して小さくできます（--cache-type-k q8_0 --cache-type-v q8_0）。 量子化した型は 32 要素を1ブロックにまとめて保存するので、1要素あたりのバイト数は次のとおりです。

V キャッシュを量子化するには Flash Attention（--flash-attn on）が必要です。 量子化による精度の変化はモデルによって違い、このサイトでは測っていないため、表では f16 を既定にして q8_0・q4_0 を参考として並べています。

5. 計算バッファと余裕分 推定

6. コンテキスト長ごとの早見表（Qwen3-8B Q4_K_M）

ファイルサイズ 5.03 GB 実測 のモデルで、コンテキスト長と KV キャッシュの型を変えたときの推定必要メモリです。 各モデルのページにも、同じ式で計算した表を載せています。

すべて 推定 の値です。

7. 前提と、合わない場合

この推定は、llama.cpp（b11639・2026年10月時点）の次の設定で動かす場合の値です。llama-server・llama-cli の既定の設定と同じです。

• 1 全層を GPU（Mac は統合メモリ）に載せる 一部の層を CPU 側に置けば GPU の必要量は減り、そのぶん速度が落ちます。
• 2 同時に1つの会話だけを処理する llama-server で並列数（-np）を増やすと、SWA 層の KV キャッシュが並列数に応じて増えます。
• 3 n_ubatch ＝ 512（既定）、Flash Attention が有効 Flash Attention を切ると、長いコンテキストで計算バッファが大きく増えます。
• 4 コンテキスト長は、表の各列で指定した値 Ollama や LM Studio は、使うコンテキスト長をツール側の設定で決めます。自分が使う長さを設定で確かめ、その行の値を見てください。

llama.cpp 本体との突き合わせ

KV キャッシュと、線形注意などの層が持つ一定の状態は、llama.cpp 本体が実際に確保する量とバイト単位で一致することを確かめています。 確かめ方は次のとおりです。掲載しているモデルの config.json を llama.cpp 公式の変換処理で GGUF の設定部分だけに変換し、 llama.cpp に重みを読み込ませずに会話の枠（コンテキスト）を作らせて、確保した量を取り出しています。 コンテキスト長は 4,096・8,192・32,768・131,072 トークンの4通りです。

• ・使った版：llama.cpp b11639（2026年10月14日）。版が上がったら確かめ直します。
• ・確かめていないもの：計算バッファと余裕分（5. の値）。実際に GPU で動かして測るまでは、推定のままです。
• ・SWA の層は、llama-server・llama-cli の既定どおり窓の分だけを確保する前提です（--swa-full を付けると全体を確保します）。

KV キャッシュの持ち方が違うモデル

次のモデルは、llama.cpp の実装（KV キャッシュの確保のしかた）を確かめたうえで、同じ式を層ごとに当てはめて推定しています。

線形注意を組み合わせたモデル（Qwen3.5・Qwen3-Next など）

KV キャッシュを持つのは通常の注意の層だけです（多くは4層に1層）。残りの線形注意の層は、会話の長さによらない一定の大きさの状態を持ちます。 状態の大きさは 1層あたり ((畳み込みの幅 − 1) × (d_inner + 2 × Kヘッド数 × Kヘッドの次元) + Kヘッドの次元 × d_inner) × 4 バイト で、 推定必要メモリに足しています（d_inner = Vヘッド数 × Vヘッドの次元）。長い会話でも KV キャッシュが通常のモデルの約1/4で済むのが特徴です。

線形注意＋疎な注意（Qwen3.8-Flash-Next など）

上の線形注意のモデルに加えて、通常の注意の層ごとに「どのトークンを見るか」を選ぶための索引用のキャッシュ（1ヘッド × indexer_head_dim、K だけ）を、KV キャッシュと同じ長さだけ持ちます。 また、n-gram の埋め込み（PLE）の畳み込みの履歴として、(ple_conv_kernel_size − 1) × ngram_size × hc_count × hidden_size × 4 バイトの一定の状態を持ちます。

畳み込みを組み合わせたモデル（LFM2 系）

KV キャッシュを持つのは通常の注意の層だけで、畳み込みの層は hidden_size × (conv_L_cache − 1) × 4 バイトの一定の状態を持ちます。

Gemma 4

SWA 層と、コンテキスト全体を保持する層とで、KV ヘッド数と head_dim が違います（config.json の num_global_key_value_heads・global_head_dim）。 層ごとの幅で KV キャッシュを計算しています。また E2B・E4B などは、末尾の層（num_kv_shared_layers）が前の層の KV キャッシュを使い回すため、その層の分は確保されません。 Gemma 3n も同じく、末尾の層は KV キャッシュを確保しません。

DeepSeek V4

専用の KV キャッシュを持ちます。直近 128 トークン分の KV（K だけ）に加えて、層によっては 4 トークンを1つにまとめた K と、そこから読む場所を選ぶための索引用の K を、 別の層では 128 トークンを1つにまとめた K を持ちます。まとめる仕組みのための一定の状態も足しています。 そのため、長い会話でも KV キャッシュは小さく、131,072 トークンでも 1 GB 前後です（多くの必要メモリはモデルファイルそのものです）。

Mamba2 を組み合わせたモデル（Nemotron-H 系）

KV キャッシュを持つのは注意の層だけで、Mamba2 の層は ((conv_kernel − 1) × (d_inner + 2 × n_groups × ssm_state_size) + ssm_state_size × d_inner) × 4 バイトの一定の状態を持ちます（d_inner = mamba_num_heads × mamba_head_dim）。

チャンク注意（Llama 4）

4層のうち3層は、8,192 トークンごとの区切り（チャンク）の中だけを見ます。llama.cpp はこの層に SWA と同じ量（区切りの長さ＋512）を確保するので、同じ式で計算しています。

埋め込みモデル（EmbeddingGemma など）

文章を一度に読んで数値に変えるだけで、続きを生成しないため、KV キャッシュを持ちません。

8. 推定していないモデル

KV キャッシュの持ち方が上の式と違うモデルは、間違った数字を出さないよう推定値を表示しません（モデルのページに理由を書いています）。 元モデルの config.json が取得できない場合（利用に同意が必要なモデル等）も同じです。 ただし、GGUF ファイルの先頭にある設定（llama.cpp が読む値そのもの）を読めたモデルは、そこから推定します。 MLA のモデル（DeepSeek V3・Kimi K2・GLM-5.3 など）は、GGUF の設定で変換の時期（KV の形）を見分けてから推定します。

推定に対応している model_type：llama, mistral, mixtral, qwen2, qwen2_moe, qwen3, qwen3_moe, phi3, qwen3_vl_text, granite, ministral3, hunyuan_v1_dense, qwen2_5_vl, qwen2_5_omni_text, qwen3_vl_moe_text, qwen3_omni_moe_text, glm4, glm4v_text, smollm3, hy_v3, k2_horizon, chatglm, nanbeige, gemma2, gemma3, gemma3_text, gpt_oss, muse_glimmer_text, spark2_5, laguna, cohere2_moe, mellum, afmoe, step3p5, llama4_text, qwen3_next, qwen3_5_text, qwen3_5_moe_text, qwen4_exp_text, gemma4_text, gemma4_unified_text, lfm2, lfm2_moe, embedding_gemma2_text, jina_embeddings_v5, gemma3n_text, mimo_v2, nemotron_h, deepseek_v4

よくある質問