この記事は「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キャッシュ