この記事は「8GB VRAMで何ができるか」の現時点での答え

8GB VRAMのRTX 4060でローカルLLMを3ヶ月以上運用してきた。その過程で量子化の選択を間違え、コンテキスト長を伸ばしすぎてOOMで落ち、エージェントループが5ステップで壊れるのを目撃した。

個別の話はそれぞれ記事にしてきた。この記事はその総集編——8GB環境でローカルLLMを実用水準で動かすために必要な知識を、判断の順序に沿って1本にまとめる。

テーゼは単純だ。8GB VRAMは「足りない」のではなく、「設計条件」だ。 制約を理解して設計すれば、7B〜14Bクラスのモデルを日常的に使える環境が作れる。

前提: llama.cppのCUDA対応バイナリをGitHub Releasesから取得済み、GGUFモデルをHuggingFaceからダウンロード済みの状態を想定。インストール手順自体は公式READMEを参照。

Step 1: モデルサイズの物理的上限を把握する

まず「何が入るか」を計算する。8GBのうち、CUDA文脈とランタイムオーバーヘッドで約0.5〜0.8GBが固定消費される。残り約7.2〜7.5GBがモデル+KVキャッシュの予算。

モデル	Q4_K_M サイズ	全層GPU?	KVキャッシュ余裕
3B (Phi-3 mini等)	~1.8GB	✅	5GB超
7B (Qwen2.5-7B等)	~4.7GB	✅	~2.5GB
9B (Gemma2-9B等)	~5.3GB	✅	~2GB
14B (Qwen2.5-14B等)	~8.7GB	❌	ハイブリッド必須
32B (Qwen2.5-32B等)	~18GB	❌	大半CPU

判断軸: 7Bなら全層GPUオフロードで最速。14Bはハイブリッドで速度が落ちるが品質は上がる。32Bは「動くが遅い」。用途で選ぶ。

Step 2: 量子化を選ぶ — Q4_K_Mが万能ではない

量子化は「精度とサイズのトレードオフ」と説明されることが多いが、実際にはもっと複雑だ。

Q4_K_M  ≈ 4.83 bits/weight (重要レイヤーに高精度を割り当て)
Q5_K_M  ≈ 5.68 bits/weight
Q6_K    ≈ 6.57 bits/weight
Q8_0    ≈ 8.50 bits/weight
IQ4_XS  ≈ 4.25 bits/weight (importance matrix活用型)

Q4_K_MとQ5_K_Mの差は日常会話では分からない。しかしコード生成と論理推論ではQ4_K_MからQ5_K_Mへの差が体感できる。構文のネストが深いコードや、3段以上の推論チェーンで差が出る。

8GBでの現実的な選択:

7Bモデル: Q5_K_Mが入る。精度を優先するならこちら
7Bモデル（速度優先）: Q4_K_Mで全層GPU。速度と品質のバランス最適
14Bモデル: Q4_K_M一択。Q5以上はVRAMに入らない
IQ4_XS: Q4_K_Mよりサイズが小さく品質が近い。7Bなら試す価値あり

Step 3: `-ngl`（GPUオフロード層数）の最適化

llama.cppの-nglパラメータは、モデルの何層をGPUに載せるかを決める。全層載せれば最速だが、KVキャッシュのVRAMが残らない。

Qwen2.5-7B Q4_K_M (28層):

-ngl 28 (全層): モデル4.7GB + オーバーヘッド0.6GB = 5.3GB。KVキャッシュに2.7GB使える → ctx 4096は余裕、8192も可能
-ngl 20: GPUに約3.5GB。KVキャッシュに4GB超 → ctx 16384も可能だが速度低下

Qwen2.5-14B Q4_K_M (48層):

-ngl 48 (全層): 8.7GB → VRAM超過。不可
-ngl 35: GPUに約6.5GB → KVキャッシュに約1GB → ctx 4096が限界
-ngl 30: GPUに約5.5GB → KVキャッシュに約1.7GB → ctx 4096〜8192

最適値は「OOMしない最大値」。これはKVキャッシュ設定（コンテキスト長×量子化）とセットで決まるため、環境ごとの試行錯誤が必要。-nglを1ずつ上げていって落ちる直前が最適。

# 7B全層: 速度最適
llama-server -m qwen2.5-7b-instruct-q4_k_m.gguf -ngl 28 -c 8192 --flash-attn

# 14Bハイブリッド: 品質優先
llama-server -m qwen2.5-14b-instruct-q4_k_m.gguf -ngl 35 -c 4096 --flash-attn -t 8

Step 4: コンテキスト長の「崖」を知る

KVキャッシュはコンテキスト長に比例してVRAMを食う。

KVキャッシュ ≈ 2 × n_layers × n_kv_heads × head_dim × ctx_len × bytes

7B (28層, GQA 4ヘッド, 128dim, FP16):

ctx	KVキャッシュ	7B全層時の残り
4,096	~0.22GB	~2.5GB ✅
8,192	~0.44GB	~2.3GB ✅
16,384	~0.88GB	~1.8GB ⚠
32,768	~1.75GB	~1.0GB 🔴

14B (48層, 8ヘッド, 128dim, FP16):

ctx	KVキャッシュ	ngl35時の残り
2,048	~0.38GB	~0.6GB ⚠
4,096	~0.75GB	~0.25GB 🔴
8,192	~1.5GB	不可 ❌

FlashAttention (--flash-attn) は必須。KVキャッシュのメモリ効率が改善され、同じVRAMでより長いコンテキストが使える。使っていないなら今すぐ有効にすべき。

KVキャッシュ量子化 (--cache-type-k q4_0 --cache-type-v q4_0) を使えばさらに圧縮できるが、長文推論の精度が落ちるリスクがある。短文応答中心なら有効。

Step 5: VRAMが足りなくなる前にnvidia-smiを読む

「動いているのに遅い」の原因の多くはVRAM不足によるCPUフォールバック。nvidia-smiの読み方を知らないと気づけない。

+-------------------------+
| NVIDIA-SMI   575.64     |
| GPU  Name: RTX 4060     |
| Memory-Usage: 7834MiB / 8188MiB |  ← 使用率95%超 → OOM間近
| GPU-Util:        89%    |  ← 100%に近いほどGPUが仕事している
+-------------------------+

注目すべき数値:

Memory-Usage: 7.5GB超 → KVキャッシュかコンテキスト長を減らすべき
GPU-Util: 50%以下なのに遅い → GPU-CPUデータ転送がボトルネック（-nglが低すぎる）
Power: 推論中に定格TDP近く → 正常。アイドル時に高い → バックグラウンドプロセスを確認

Step 6: 推論速度の理論限界を理解する

トークン生成（decode）はメモリ帯域律速。速度の大まかな見積もりは帯域÷モデルサイズで出せる。

def estimate_tokens_per_sec(bandwidth_gbs, model_size_gb):
    """帯域律速時の速度目安（実測はこの60-100%程度）"""
    return bandwidth_gbs / model_size_gb

# RTX 4060 (272 GB/s)
print(f"7B Q4 (~4.7GB):  {estimate_tokens_per_sec(272, 4.7):.0f} tok/s目安")  # → 57 tok/s
print(f"14B Q4 (~8.7GB): {estimate_tokens_per_sec(272, 8.7):.0f} tok/s目安")  # → 31 tok/s (全層GPU時)

この見積もりは簡易的なもので、KVキャッシュ読み込みやアテンション計算のオーバーヘッドを含まない。実測値はモデルやバッチサイズで変動する。Qwen2.5-7B Q4_K_M全層GPUの公開ベンチマークでは60-75 tok/s程度が報告されている。14Bハイブリッドでは10-15 tok/sまで落ちる（CPU経由のレイヤーがボトルネック）。

M4 Macとの比較: M4は帯域120 GB/sだがユニファイドメモリでデータ転送ロスが少ない。7Bクラスでは帯域差でRTX 4060が勝つが、14B以上ではM4のメモリ容量が有利。用途が違う。

Step 7: エージェントループは5ステップで壊れる

Step 6で見た帯域限界は、エージェント設計を直接制約する。14Bハイブリッドで10-15 tok/sということは、ツール呼び出し1回に数秒かかり、ループが長いほどKVキャッシュが膨張して速度がさらに落ちる。

理由は2つ:

KVキャッシュ蓄積: ツール呼び出し1回で約900トークン蓄積。10回で約11,200トークン → KVキャッシュ0.6GB消費
Context Rot: 7Bモデルは6,000〜8,000トークンを超えると情報再現精度が急落。直前のツール結果を無視し始める

迂回策:

短ループ×コンテキストリセット: 5ステップで区切り、要約のみ持ち越し。KVキャッシュ消費を1/4に
動的ツール選択: 全ツールを常時定義しない。タスク種別で5ツールに絞る
Persistent KV Cache: ディスクにQ4量子化で保存、タスク切り替え時にロード

エージェントの性能を決めるのはコンテキストの長さではなく、コンテキストの品質。

Step 8: ファインチューニングは推論の8倍メモリを食う

Step 1-7で「8GBでも推論は実用になる」と示した。ではカスタマイズ（ファインチューニング）はどうか。結論: 推論とは別世界の話だ。

推論時のVRAM: モデル重み + KVキャッシュ + オーバーヘッド
学習時のVRAM: モデル重み + 勾配 + オプティマイザ状態 + 活性化値 + オーバーヘッド

フルパラメータ学習の場合、FP16の勾配（重みと同サイズ）に加え、AdamWオプティマイザはFP32で第1・第2モーメントを保持する（重みの4倍）。7Bモデルのフル学習には最低84GB以上のVRAMが必要（活性化値を含めると100GB超）。8GBでは物理的に不可能。

8GBで可能なのは:

QLoRA: 量子化モデル + 低ランクアダプタ。7B Q4LoRAで~6GB。8GBに収まる
LoRA rank 16-32: rank=16で学習可能パラメータは全体の0.1%程度

Step 9: この記事を読んだ後にやること

--flash-attnを確認: 未使用なら追加。即座に効果がある
nvidia-smiを見る習慣: 「遅い」と感じたらまずVRAM使用率を確認
用途で分ける: 速度重視→7B全層GPU、品質重視→14Bハイブリッド。同時に使い分ける
コンテキスト長を用途別に設定: 会話用は4096で十分。長文解析時だけ8192に上げる
エージェントは5ステップ単位: 長いタスクは要約持ち越しの短ループ設計

8GBの壁は、理解すれば工夫の出発点になる。

関連記事

本記事で触れた各トピックの詳細は個別記事で深堀りしている。@plasmon のプロフィールから一覧を参照:

llama.cppの設定で8GBの性能が5倍変わる — 主要オプションの最適値
推論では余裕の8GBが、ファインチューニングでは即死する — 学習時VRAM消費の分解
8GBでLLMエージェントを回したら何ステップで壊れるか — エージェントのKVキャッシュ限界
nvidia-smiの数字を読み間違えると、LLMのボトルネックを見誤る — GPU使用率の正しい読み方
128Kコンテキストは8GBでも入る。だが入れても意味がなかった — コンテキスト長とKVキャッシュ