VRAM 計算実践：モデル規模 × 量子化から VRAM 需要を正確に見積もる
VRAM 計算実践：モデル規模 × 量子化から VRAM 需要を正確に見積もる
前回の記事は「VRAM でカードを選ぶ」を扱いました。この記事はその数学を開きます。なぜ同じモデルが異なるコンテキスト長で数 GB も余分に必要なのか？「27B が動かない」のは重みの問題か KV cache の問題か？GPU オフロードのレイヤー数をどう決めるか？公式と測定方法を明確にすれば、購入前に正確に見積もり、デプロイ後に精密に調整できます。
30 秒でわかる要点
VRAM ＝ 重み ＋ KV cache ＋ ランタイムオーバーヘッド。重み ＝ パラメータ数 × ティア別バイト係数（Q4_K_M は約 0.6 バイト/パラメータ）。KV cache はコンテキスト長に比例して増加し、長文脈では重みの半分を超えることも。実行後、nvidia-smi と llama.cpp の起動ログでキャリブレーション — 公式より実測が正確です。
公式 1：重みサイズ
重みサイズ ＝ パラメータ数 × パラメータあたりバイト数。ティア別の経験的係数：
| ティア | バイト/パラメータ（約） | 7B | 27B | 70B |
|---|---|---|---|---|
| Q8_0 | 1.05 | 7.4GB | 28GB | 74GB |
| Q6_K | 0.85 | 6.0GB | 23GB | 60GB |
| Q5_K_M | 0.72 | 5.0GB | 19GB | 50GB |
| Q4_K_M | 0.60 | 4.2GB | 16GB | 42GB |
| Q3_K_M | 0.48 | 3.4GB | 13GB | 34GB |
| Q2_K | 0.35 | 2.5GB | 9.5GB | 25GB |
なぜ「約」なのか
モデルによって埋め込み層や出力層のサイズが異なるため、同じパラメータ数でも実際の GGUF ファイルサイズには 5〜10% の差があります。カード購入前にモデルカードの実際のファイルサイズで確認する方が、係数を盲目的に適用するより確実です。
公式 2：KV cache
KV cache は履歴トークンの K/V マトリックスを保存するもので、長文脈デプロイの隠れた大きな項目です。1 リクエストあたりの推定式：
KV cache ≈ 2（K と V）× レイヤー数 × KV ヘッド次元の合計 × コンテキスト長 × 2 バイト（fp16）
正確な公式を覚える必要はありません。2 つの法則を押さえてください。
- コンテキスト長に線形で増加 — 8K から 32K で約 4 倍
- バッチサイズに比例 — 4 同時リクエストで約 4 倍
実務的な参考値（fp16、単一リクエスト）：
| モデル規模 | 8K コンテキスト | 32K コンテキスト |
|---|---|---|
| 7B クラス | ~0.5-1GB | ~2-4GB |
| 27B クラス | ~1-2GB | ~4-8GB |
| 70B クラス | ~2-4GB | ~8-16GB |
長文脈では KV cache が重みの半分を超えることがある
27B モデルの Q4 で重みが約 16GB、32K コンテキストの KV cache は 4-8GB に達する可能性があります。VRAM の 1/4 から 1/2 が「履歴を記憶する」ことに使われる計算です。長文脈デプロイを計画する際は、KV cache を独立した項目として計算してください。
公式 3：ランタイムオーバーヘッド
CUDA コンテキスト（約 0.3-0.5GB）、推論エンジンのキャッシュ、メモリ断片化 — 通常さらに 1-2GB。マルチ GPU の場合、各カードが独自のオーバーヘッドを持ちます。
完全な計算例
ケース 1：Qwen3.8-27B、Q4_K_M、8K コンテキスト、単一ユーザー
- 重み 16GB + KV cache 約 1.5GB + オーバーヘッド 2GB ≈ 19.5GB → 24GB カードで実行可能
ケース 2：同じ、ただし 32K コンテキスト
- 重み 16GB + KV cache 約 6GB + オーバーヘッド 2GB ≈ 24GB → 24GB カードは境界線上。32GB かティアを下げるのが安全
ケース 3：Hunyuan 4B（hy4）、Q4_K_M、8K コンテキスト
- 重み 約 2.5GB + KV cache 約 0.5GB + オーバーヘッド 2GB ≈ 5GB → 8GB カードで余裕
MoE モデルの計算方法
35B-A3B などの MoE：重みは総パラメータ 35B で計算（Q4 で約 21GB）、KV cache は実際のアーキテクチャのレイヤー/KV ヘッドで計算、速度は活性化の 3B で体感。つまり MoE の VRAM 需要は 35B dense モデルに近いが、速度は 3B モデルに近い — これこそがローカルデプロイに適する理由です。
GPU オフロードレイヤーの設定方法
llama.cpp の -ngl（n_gpu_layers）が VRAM に置くレイヤー数と RAM に残すレイヤー数を決定します。設定方法：
- 全レイヤーを試す：
-nglを総レイヤー数に設定（起動ログに表示）し、OOM するか確認 - OOM したら減らす：4-8 レイヤーずつ減らしてロードできるまで調整
- 速度のトレードオフ：RAM に残すレイヤーが多いほど生成が遅くなる — 同じプロンプトで token/s を測定し「ロードできて速度が許容範囲」のバランスを見つける
オフロードはタダではありません
一部のレイヤーが RAM に残ると、生成されるトークンごとに PCIe を通じてデータを移動する必要があり、速度が数分之一に落ちる可能性があります。半分以上のレイヤーをオフロードする必要があるなら、より小さいモデルか低い量子化ティアに切り替えた方がはるかに良い体験になります。
実測によるキャリブレーション
公式は「購入前の見積もり」に使い、実測は「デプロイ後の調整」に使います：
VRAM 使用量を確認：別のターミナルで nvidia-smi を実行し、推論中のピーク使用量を観察します。
KV cache の割り当てを確認：llama.cpp の起動ログに実際の KV cache 割り当てが表示されます（llama_kv_cache: ... MiB のような形式）。これであなたの推定係数を校正できます。
断片化を確認：ピーク使用量が公式の計算より 2GB 以上高い場合、-c（コンテキスト）やバッチパラメータが必要以上に大きくないか確認してください。
# llama-server を起動する際、ログで KV cache 割り当てを観察
./llama-server \
-m ./models/Qwen3.8-27B-Q4_K_M.gguf \
-ngl 40 \
-c 8192 \
--host 127.0.0.1 --port 8080
バッチ推論による VRAM の倍増
ローカルでマルチユーザー対応する場合に注意：KV cache は同時実行数に比例して倍増します。1 ユーザー 8K で 1.5GB の場合、4 同時で約 6GB — 重みとオーバーヘッドを加えると、24GB カードで 27B + 4 同時は厳しくなります。
対策：同時実行数を制限する（llama-server の parallel 設定）、並列用に VRAM を確保する、または高並行シナリオをクラウド API に渡します。
FAQ
実際の VRAM 使用量が公式の計算より高いのはなぜ？
KV cache は圧縮できますか？
27B は Q4_K_M と Q3_K_M どちらを使うべき？
-ngl はいくつに設定すべき？
MoE モデルの VRAM はどう計算する？
公式の計算結果がカードの容量とちょうど同じですが、動きますか？
関連記事
- ローカル LLM のための GPU 選びガイド — VRAM でカードを選ぶ
- ローカルデプロイ完全プレイブック — ハードウェアからワークフロー統合まで
- ローカル計算コストモデル — 購入 vs レンタル vs API
- Qwen GGUF ローカルデプロイ入門 — デプロイの基礎
- Qwen KV cache と長文脈 — KV cache の仕組み