パラメータ数で選んだモデルは8GBで使いものにならない
RTX 4060 8GBでローカルLLMを半年間使い倒してきた。Qwen2.5-32B、Qwen3.5-9B/27B/35B-A3B、BGE-M3、様々なモデルをQ4_K_M量子化で押し込んできた結果、一つ確信を持って言えることがある。
パラメータ数はモデル選択の最悪の指標だ。
ネットの比較記事は「32Bならこのくらいの品質」「7Bならこのくらい」とパラメータ数で分類する。ベンチマークもMMLU、HumanEval、MTBenchでモデルサイズごとにランキングを出す。だがそれは潤沢なVRAMが前提の話であって、8GBという制約の中では、パラメータ数から実用体験を予測できない。
この記事では、8GB VRAMでの実測から見えた3つの法則と、それに基づくモデル選択フレームワークを整理する。すべて過去の検証記事のデータに基づいている。
法則1: VRAMに収まることと速く動くことは別の話
8GB VRAMの壁に当たると、まず「VRAM使用量がX GBだから収まる」で判断したくなる。だがVRAM使用量と速度には直線的な関係がない。
Qwen3.5の3モデル比較で明確に出た:
| モデル | VRAM | 速度 | GPU利用率 |
|---|---|---|---|
| 9B | 7.1GB | 33.0 t/s | 91% |
| 27B dense (ngl=24) | 7.7GB | 3.57 t/s | 60% |
| 35B-A3B MoE | 7.6GB | 8.61 t/s | 95% |
VRAM使用量はほぼ横並び（7.1〜7.7GB）。なのに速度は33 t/s vs 3.5 t/s。10倍の差。
差の正体はGPU利用率にある。27Bは58層中24層しかGPUに載らない。残り34層はCPUが処理する。GPUは自分の分が終わってもCPUの完了を待つ。GPU利用率60%とは、40%の時間GPUが遊んでいるということだ。
8GB VRAMでの実効速度の決定要因:
1. GPUに全層載るか → 載らなければ部分オフロードで速度急落
2. 部分オフロードの比率 → ngl/全層数が速度を支配
3. MoEのアクティブパラメータ数 → 35Bでも実質3Bなら全層GPUに載る
実測から導いたルール:
- ngl < 全層数の50% → 使いものにならない（対話的用途では）
- ngl = 全層数 → VRAM使用量が8GB以内なら高速
- MoEモデルはアクティブパラメータ数で判断。35Bでもアクティブ3Bなら8GBに余裕で収まる
法則2: thinkingモデルのctx長は額面通りの意味を持たない
Qwen3.5世代からthinking（推論過程をトークンとして消費する）が入った。これがctx制約下で新しい問題を生む。
通常モデル:
プロンプト → 回答出力
ctx消費 = プロンプト + 回答
thinkingモデル:
プロンプト → thinking(内部推論) → 回答出力
ctx消費 = プロンプト + thinking + 回答
同じctx 8192でもthinkingが入ると実効的な出力可能トークン数が減る。しかもthinkingの長さはタスクの種類で非決定的に変わる。
Qwen3.5-9Bのタスク別thinking消費:
| タスク | thinking行数 | ctx消費 | 結果 |
|---|---|---|---|
| コード生成 | 短い | 余裕 | 完走 |
| 計算問題 | 短い | 余裕 | 完走 |
| 知識要約 | 242行 | 8095/8192 | 薄氷で成功 |
27Bと35B-A3Bは知識要約タスクでctx枯渇して全滅した。知識量が多いモデルほどthinkingが膨らみ、ctxを食い尽くす。9Bだけが生き残ったのは、知識が浅い分thinkingが早く打ち切られたから。
実測から導いたルール:
- thinkingモデル × ctx 8192 = 実効出力枠はタスク依存で大幅に減少（知識要約ではctxの97%を消費した実例あり）
- 知識量の多いモデル(27B+)はctx枯渇リスクが高い
- 長文生成タスクにはthinkingなしモデル or ctx 32K以上が必要
法則3: 遅いモデルの失敗は速度の二乗で高くつく
失敗したときのコストはモデルの速度に反比例する。
Qwen3.5 ctx枯渇までの時間:
| モデル | 速度 | 枯渇までの時間 |
|---|---|---|
| 9B | ~33 t/s | ~4分 |
| 35B-A3B | 7.63 t/s | 20分 |
| 27B dense | 3.21 t/s | 58分 |
全員同じ全滅でも、27Bは58分待ってようやく失敗に気づく。9Bなら4分で再試行できる。
さらに、ctx末期ではattention計算が重くなり速度が劣化する:
- 35B-A3B: タスク1で8.61 t/s → ctx枯渇間際で7.63 t/s（-11%）
- 27B: 3.57 t/s → 3.21 t/s（-10%）
遅いモデルのctx枯渇は、速度の遅さが二重にペナルティとして効く。 失敗に気づくのが遅い上に、失敗直前の速度はさらに遅い。
実測から導いたルール:
- 試行錯誤が必要なタスク → 速いモデル優先（失敗のリカバリが速い）
- 一発で確実に出力したいタスク → 品質優先でもOK
- 推論速度 < 5 t/s は対話的用途には非実用的
モデル選択フレームワーク: 8GB VRAMの意思決定木
3法則を組み合わせた選択フローチャート:
Q1: タスクに長文出力(1000+トークン)が必要か?
├── YES → Q2: thinkingモデルが必要か?
│ ├── YES → ctx 32K以上のモデルを選ぶ。8GBでは非thinkingモデルを代替案に
│ └── NO → Q3 へ
└── NO → Q3 へ
Q3: 対話的に使うか(レスポンス時間が重要)?
├── YES → Q4: 専門知識が必要か?
│ ├── YES → MoEモデル推奨 (35B-A3B系: 8.6 t/s + 高品質)
│ └── NO → 9Bクラス推奨 (33 t/s, 低遅延)
└── NO → バッチ処理なら27B denseも許容(品質>速度)
Q5: RAGやEmbeddingも同時に動かすか?
├── YES → 推論モデル + Embedding でVRAM合計を計算
│ BGE-M3: ~1.5GB, 推論モデル: 残りの6.5GBに収まるか?
│ → 9B (7.1GB) では同時起動不可。5B以下 or MoE推奨
└── NO → 上記Q3-Q4の結果を適用
推奨マトリクス
| ユースケース | 推奨モデル | 理由 |
|---|---|---|
| コード補完・チャット | 9B | 33 t/s、低遅延、失敗時リカバリ4分 |
| 専門タスク（RAGなし） | 35B-A3B MoE | 8.6 t/s、高品質、GPU 95% |
| RAG + 推論同時 | 5B以下 or API分離 | VRAM共有の限界 |
| 長文翻訳・要約 | 非thinkingモデル | ctx枯渇回避 |
| バッチ処理（品質最優先） | 27B dense | 速度不問なら品質を優先できる |
| 絶対避けるべき | 27B dense × 対話的用途 | 3.5 t/s + ctx枯渇 = 最悪のUX |
量子化の選択: Q4_K_M以外を選ぶ理由はあるか
全検証をQ4_K_Mで統一したが、他の量子化との比較も触れておく。
# llama.cppの主要量子化フォーマット (8GB VRAMでの位置づけ)
quant_options = {
"Q2_K": {"bits": 2.6, "quality": "低", "size_ratio": 0.33,
"use_case": "どうしても大きいモデルを動かしたい場合のみ"},
"Q4_K_M": {"bits": 4.8, "quality": "実用", "size_ratio": 0.55,
"use_case": "デフォルト選択。品質と速度のバランスが最良"},
"Q5_K_M": {"bits": 5.5, "quality": "高", "size_ratio": 0.63,
"use_case": "VRAMに余裕があるとき。9BならQ5でも7.5GB程度"},
"Q6_K": {"bits": 6.6, "quality": "最高", "size_ratio": 0.75,
"use_case": "8GBでは7Bクラスまで。品質重視の固定タスク"},
"Q8_0": {"bits": 8.5, "quality": "FP16相当", "size_ratio": 1.0,
"use_case": "8GBでは3B以下のみ。Embeddingモデル向き"}
}
Q4_K_Mからの変更を検討すべきケース:
- 9BをQ5_K_Mに上げる: VRAM 7.1→~7.5GB。収まる。品質改善は微小だが、コスト0で試せる
- 9BをQ6_Kに上げる: VRAM ~8.0GB。ギリギリ。他のプロセスとVRAMを奪い合うリスク
- 35B-A3BをQ2_Kに下げる: 品質低下が大きい。MoEは活性パラメータが少ないため量子化による劣化が相対的に大きい
結論: Q4_K_Mが8GBのスイートスポット。 理由は、品質劣化が無視できるレベルで、かつVRAM使用量が8GBの半分程度に収まるため、大きめのモデルも選択肢に入るから。
この半年で学んだこと
8GB VRAMという制約は、制約であると同時にフィルターだ。
A100 80GBなら何でも動く。選択の必要がない分、モデルアーキテクチャの違いが体験の差として出にくい。8GBは「このモデルをこのタスクにこの設定で使って初めて価値がある」という最適解を強制的に見つけさせる。
パラメータ数で選ぶのは、車を排気量だけで選ぶのに似ている。2.0L直4ターボが3.5L V6 NAより速いケースがあるように、MoE 35B-A3Bがdense 27Bより速いケースがある。制約条件が変わればランキングが変わる。
3法則を再掲する:
- VRAMに収まること ≠ 速く動くこと — GPU利用率とngl比率で判断
- thinkingモデルのctx長は額面通りに使えない — タスクに応じたctx予算を計算
- 遅いモデルの失敗コストは速度の二乗 — 試行錯誤が必要なら速いモデル
スペック表は嘘をつかないが、真実の半分しか語らない。残りの半分は、自分のGPUで動かさないと見えない。
検証環境・過去記事
GPU: NVIDIA GeForce RTX 4060 Laptop GPU 8GB
CPU: AMD Ryzen 7
RAM: 32GB DDR5
推論: llama.cpp (GGUF)
OS: Windows 11