ローカルLLMに必要なVRAMの計算方法｜量子化別

先に結論

ローカルLLMの必要VRAMは、モデル名のB数 × 量子化bitだけでは決まりません。GPUへ置く重み、KV cacheを含むcontext、compute buffer、adapter／projector、他process、余裕容量を合計します。
購入前の概算には「実際のGGUFファイル容量」を使い、実行環境ではllama.cppのllama-fit-paramsまたは起動時のmemory breakdownで補正するのが安全です。
Q4_K_Mなどのblock量子化は、scale等を含むため4.00 bit/parameterと一致しません。下の量子化別表は重みだけの理論値で、VRAM容量表ではありません。
運用上の余裕として10〜20％を追加する方法を紹介しますが、これは当サイトの経験則です。公式の保証値ではなく、同じGPUを画面表示や他アプリと共用する場合はさらに余裕が必要です。

確認日時: 2026年8月2日 14:10（Asia/Tokyo）
固定した版: llama.cpp master HEAD 11924d4c17abc27383376a1ac6a24fa3e36c1c0c、GGUF仕様 78de606907c364b76601f734021f76bd29ca5637
検証区分: llama.cppのmemory projection、引数定義、KV cache allocation、GGUF metadata仕様を照合した机上調査です。GPU別の実測値は掲載していません。
単位: 式のGBは10進（10⁹ byte）、llama.cppログのMiB／本記事のGiBは2進です。1 GiB = 1,073,741,824 byteです。
画像: アイキャッチはVRAMの内訳を表した当サイトの要点図解で、実際の計測画面ではありません。

必要VRAMの基本式

単一GPUへ置く容量は、次の足し算で考えます。

必要なデバイスメモリ
≈ GPUへ置くモデル重み
 + GPU上のcontext memory（主にKV cache）
 + compute buffer
 + LoRA・mmproj・draft modelなどの追加要素
 + 同じGPUを使うOS・画面・他process
 + 運用上の余裕

llama.cppの現行memory breakdownも、主な自己使用量をmodel、context、computeへ分けて表示します。公式のfit-params資料には、この3項目とdeviceのfree／unaccountedを分けた例があります。つまり、GGUFの容量だけをVRAM必要量とする計算は、contextと計算領域を落としています。

離散GPUとApple Siliconでは「空き」の意味が違う

NVIDIA／AMDの離散GPUでは専用VRAMを見ます。ただし画面出力や別のGPU applicationも同じ容量を使います。Apple SiliconはCPUとGPUがユニファイドメモリを共有するため、本体の搭載メモリをそのまま「LLM専用VRAM」とは扱えません。macOS、ブラウザ、開発環境などの使用分を引き、memory pressureも確認します。

Macを容量別に選ぶ場合はMacのメモリ別・動かせるローカルLLM一覧を併用してください。

量子化別：重みだけの理論値

パラメータ数をP billion、名目bit数をbとした単純な下限は次です。

重み容量（GB、10進）≈ P × b ÷ 8

例えば8Bを名目4 bitで表すと、8 × 4 ÷ 8 = 4 GBです。ただしGGUFのQ4_K_M、Q5_K_M、IQ系などは、blockごとのscaleや量子化metadata、量子化されないtensorを含みます。モデル名の8B自体も丸めた規模名です。従って次の表は、候補を絞るための理論上の重み量として使います。

規模	名目4 bit	名目5 bit	名目6 bit	名目8 bit	16 bit
7B	3.5 GB	4.38 GB	5.25 GB	7 GB	14 GB
8B	4 GB	5 GB	6 GB	8 GB	16 GB
14B	7 GB	8.75 GB	10.5 GB	14 GB	28 GB
32B	16 GB	20 GB	24 GB	32 GB	64 GB
70B	35 GB	43.75 GB	52.5 GB	70 GB	140 GB

表にKV cacheやcompute bufferは含まれません。「8B・4 bitだから4GB GPUで動く」という読み方はできません。実際のGGUFが手元にあるなら、理論式よりそのlogical file sizeを最初の近似値にします。

MODEL_GGUF="/absolute/path/to/model.gguf"

# macOS / BSD系
stat -f '%z bytes' "$MODEL_GGUF"

# Linux
stat -c '%s bytes' "$MODEL_GGUF"

ファイル容量もGPU上の重みと完全一致はしません。部分offloadでは一部がhost memoryに残り、backendによってrepackや追加bufferがあり、metadataやalignmentも含まれるからです。それでも、名目bitだけから推測するより具体的です。

KVキャッシュを見積もる方法

KV cacheは、過去tokenのkeyとvalueを保持する領域です。標準的なTransformer attentionを単純化すると、1 sequence当たりの概算は次です。

KV bytes
≈ context cells
 × Σ各layer（Kの幅 × K型のbyte数 + Vの幅 × V型のbyte数）

同じK／V幅を持つlayerだけなら、さらに単純化できます。

KV bytes
≈ context cells
 × layer数
 ×（KV head数 × K head次元 × K型byte
   + KV head数 × V head次元 × V型byte）

これは現行llama.cppが各layerのKとVを、n_embd_k_gqa／n_embd_v_gqa、cache size、stream数から確保する実装を、人が見積もれる形へ簡略化したものです。

8K contextの計算例

次は特定製品の公称値ではなく、計算方法を示す仮想例です。

32 layers
KV heads 8
K／Vのhead dimension 128
K／VともF16（1要素2 byte）
context 8,192 cells

1 token当たり
= 32 ×（8 × 128 × 2 + 8 × 128 × 2）
= 131,072 byte

8,192 cells
= 131,072 × 8,192
= 1,073,741,824 byte
= 1 GiB

同じ構造ならcontextを16,384へ倍増するとKV部分は概ね2 GiBへ増えます。一方、重み容量まで2倍になるわけではありません。

ただし、次の条件ではこの簡易式をそのまま使えません。

layerごとにK／V幅が異なるarchitecture
sliding-window attentionとfull attentionを混在するモデル
recurrent、state-space、MLAなど通常のK＋Vと異なるmemory構造
KVを共有・分割するserver構成、複数sequence、speculative decoding
quantized KV cacheのblock overheadやbackend固有alignment

GGUF仕様にはblock_count、attention.head_count_kv、attention.key_length、attention.value_lengthなどのmetadataがありますが、architectureにより使うkeyや解釈が違います。購入判断では手計算を上限保証にせず、次の公式estimatorで確認します。

llama.cppで内訳を見積もる

現行llama.cppには、指定したmodelとcontextからdevice memoryを投影するllama-fit-paramsがあります。buildに含まれていれば、次のようにmodel、context、全layer offload、memory表示を指定します。

MODEL_GGUF="/absolute/path/to/model.gguf"

llama-fit-params \
  -m "$MODEL_GGUF" \
  -c 8192 \
  -ngl all \
  -fitp on

出力のdeviceごとのmodel、context、computeを記録します。実行可能ファイルがPATHにない場合は./build/bin/llama-fit-paramsへ読み替えてください。

自動調整結果が欲しい場合は-fitp onを外します。現行のauto-fitはfree device memoryに収まるよう、未固定のcontextやoffloadなどを調整します。公式資料の固定版ではtarget marginの既定値はdevice当たり1,024 MiBですが、これはあらゆるdesktop・driver・並列負荷を保証する値ではありません。必要なら-fittで運用に合わせたmarginを指定します。

llama-fit-params \
  -m "$MODEL_GGUF" \
  -c 8192 \
  -ngl all \
  -fitt 2048

2048は例であり推奨保証値ではありません。GPUを画面表示や画像生成と共用するか、serverを専用GPUで動かすかによって必要な余裕は変わります。

起動後は投影値ではなく実際のlogを残す

最終確認では、実際に使う引数で起動し、選ばれたdevice、offload layer、memory breakdown、OOMの有無を保存します。

llama-cli \
  -m "$MODEL_GGUF" \
  -c 8192 \
  -ngl all \
  -fa auto \
  -n 64 \
  -st \
  -p "VRAM確認用の短い応答を返してください。" \
  2>&1 | tee llama-memory.log

現行CLIのオプションは変化が速いため、実行前にllama-cli --versionとllama-cli --helpも保存してください。導入から確認したい場合はllama.cppでGGUFモデルを動かす方法、コマンドの組み立てはllama.cppコマンド例10選で確認できます。

実用的な計算例

次は、ある環境のllama-fit-params -fitp onから得たと仮定する説明用の数値です。特定model／GPUの実測ではありません。

項目	例	根拠
model	5.0 GiB	投影されたGPU上の重み
context	1.0 GiB	8K、指定したcache型・sequence条件
compute	0.8 GiB	投影された計算buffer
他process	0.6 GiB	起動前のGPU使用量
運用余裕	1.0 GiB	説明用に設定した余裕
合計	8.4 GiB	上記の合計

この条件では8GB GPUを「入る」と判定できません。contextを短くする、KV cache型を互換性確認後に見直す、GPU offloadを減らしてsystem RAMへ逃がす、または上位容量を選ぶ判断になります。

重要なのは、同じモデル名でも-c 2048と-c 32768、1 sequenceとserver並列、text-onlyとVLMで合計が変わることです。「○Bなら○GB」という表は入口にすぎません。

容量を減らすときの順番

1. 不要に長いcontextを短くする

KV cacheが支配的なら効果が見えやすい方法です。実際の入力tokenと生成tokenが収まる範囲で-cを下げます。モデルの最大contextを常に確保する必要はありません。

2. より小さいGGUFまたは低い量子化帯を選ぶ

重みが支配的なら、実ファイル容量の小さいquantを選びます。ただし低bit化には品質とのトレードオフがあり、architectureやimportance matrixで差が変わります。容量だけで同名のQ4を同一品質とみなさないでください。

3. KV cache型を見直す

現行CLIはK／V cache型を-ctk／-ctvで指定でき、既定はF16です。Q8_0やQ4系も選択肢にありますが、V cache量子化ではFlash Attentionなど追加条件がある場合があります。手元の--help、backend対応、出力品質を確認し、変更前後を同じpromptで比較します。

4. GPU offloadを減らす

-nglを減らすと一部の重みをsystem RAMへ置けます。VRAM不足を回避できても、CPU／GPU間の転送やCPU計算が増え、速度は低下し得ます。llama.cppが遅い原因と高速化設定とGPUバックエンド比較を参考に、同じGGUFをllama-benchで測ります。

5. 並列数と追加モデルを減らす

llama-serverのparallel sequence、speculative decodingのdraft model、VLMのmmproj、LoRA adapterは、単純なtext-only・1 requestの計算へ含まれていません。server運用ではcontinuous batching設定を確認し、想定する同時request数で負荷試験します。

購入前チェックリスト

使用する正確なmodel repositoryとGGUF filenameを決める
実ファイル容量と配布元のmodel cardを確認する
context長、cache型、parallel数、VLM／adapterの有無を決める
全layerをGPUへ置くか、部分offloadを許容するか決める
llama-fit-params -fitp onでmodel／context／computeを投影する
現在のGPU使用量と、他applicationの最大使用を加える
当サイトの出発点として10〜20％の余裕を加え、実負荷で検証する
容量を満たす候補をローカルLLM向けGPUのVRAMコスパ比較で比較する

起動時にload errorが出る場合、すべてをOOMと決めつけずGGUFが読み込めないときの対処法でmagic、shard、architectureも切り分けてください。

よくある質問

8BのQ4はVRAM 4GBで動きますか？

4GBは8B × 4 bitの理論的な重み量です。block metadata、非量子化tensor、KV cache、compute bufferを含まないため、4GB VRAMへ収まる保証にはなりません。実GGUF容量とmemory projectionで判断します。

GGUFの容量＝必要VRAMですか？

いいえ。全offload時の重みに近い出発点にはなりますが、contextとcompute、他process、余裕が加わります。部分offloadやbackendのrepackでも一致しません。

contextを2倍にすると必要VRAMも2倍ですか？

標準attentionで他条件が同じならKV部分は概ね比例しますが、モデル重みは増えません。合計VRAM全体が2倍になるわけではなく、sliding-windowやrecurrent系では挙動も異なります。

Q8_0のGGUFならKV cacheも8 bitですか？

いいえ。model weightの量子化とKV cache型は別設定です。現行llama.cppのK／V cache既定はF16で、変更する場合は-ctk／-ctvを明示します。

MacのユニファイドメモリはVRAMと同じ計算ですか？

内訳の考え方は使えますが、物理的にはCPU、GPU、OS、applicationが同じmemory poolを共有します。搭載容量からOS等の使用分を除き、memory pressureと実測を合わせて判断します。

余裕は10％あれば十分ですか？

保証できません。10〜20％は本記事で候補を絞るための経験則です。画面共有GPU、desktop application、driver、並列request、長時間運用で変動するため、最悪条件の負荷試験が必要です。

まとめ

必要VRAMは「重み＋context＋compute＋追加要素＋他process＋余裕」で求めます。量子化bitの式は重みの理論値しか示さないため、実際のGGUF容量を入口にし、llama-fit-params -fitp onのdevice別内訳で補正してください。

そして、購入判断と起動確認は別です。容量表で候補を選んだ後、実際のbackend、context、parallel、VLM／adapter条件を固定し、起動logと最大負荷時の空き容量まで確認して初めて運用可否を判断できます。

参考資料

llama.cpp：fit-paramsとmemory breakdown（commit 2026年8月2日・日本時間）
llama.cpp：llama-cli引数表（commit 2026年8月2日・日本時間）
llama.cpp：KV cache allocation実装（commit 2026年8月2日・日本時間）
llama.cpp：context／compute memory実装（commit 2026年8月2日・日本時間）
llama.cpp：llama-bench出力項目（commit 2026年8月2日・日本時間）
ggml：GGUF metadata・量子化仕様（commit 2026年7月31日、確認日 2026年8月2日）