オフロードと量子化でメモリに収める

🎓 レベル：標準　|　重要度：A（必須） 📎 前提：コンテキスト長とKVキャッシュ　|　原理：推論の実務（機械学習）

要点（結論先出し）

「VRAMに載らない」を解く3レバー：(1) 量子化を強める（重みを小さく）、(2) 層オフロード（一部をCPUへ）、(3) コンテキスト/KV量子化（KVを小さく）。
いずれも速度や品質との引き換え。優先は「量子化を1段強める → コンテキスト短縮/KV量子化 → 最後にCPUオフロード」（オフロードは遅い）。
目標はVRAMに全層載せること。載りきればCPUオフロード無しで最速。

概念 ── 3つのレバーで予算内に収める

必要VRAM＝重み＋KV＋オーバーヘッド（→ VRAM所要の見積もり）。各項を別々に削れます。

重みを削る：量子化を強める（Q5→Q4→Q3…）。サイズ直減だが品質低下。
KVを削る：コンテキスト長を短く、またはKVを量子化（→ コンテキスト長とKVキャッシュ）。
置き場所を変える：載らない層をCPU/RAMへオフロード（-ngl）。容量は稼げるがその層は遅い。

仕組み ── 層オフロードの効き方

flowchart TD
  NEED["必要VRAM ＞ 手持ち"] --> L1["まず量子化を1段強める"]
  L1 --> CHK1{"収まったか"}
  CHK1 -->|"はい"| DONE["確定（最速はオフロード無し）"]
  CHK1 -->|"いいえ"| L2["コンテキスト短縮・KV量子化"]
  L2 --> CHK2{"収まったか"}
  CHK2 -->|"はい"| DONE
  CHK2 -->|"いいえ"| L3["層オフロード（-ngl を下げる）"]
  L3 --> DONE2["動く（CPU層の分だけ遅い）"]

-ngl を下げるほどCPU担当が増え、VRAMは空くが遅くなる。だからオフロードは最後の手段で、VRAMに収まる最大の -ngl を探すのが定石です（→ llama.cpp）。

計算例 ── 同じ8GBでも収め方が変わる

8GB GPUに8Bモデルを載せたい場合（lab vram_sizing.py の値）：

Q4_K_M(4.47) + KV@8K(1.00) + oh(0.70) = 6.17 GiB  -> 全層GPU可（最速）
Q4_K_M(4.47) + KV@32K(4.00) + oh(0.70) = 9.17 GiB -> 溢れる
  対策: KVを8bit化(2.00) -> 7.17 GiB に収まる
       または ctx を短縮、または一部層をオフロード

量子化とコンテキスト設計だけで「載る/載らない」が反転します。

運用の勘所

手順：量子化を仮置き → vram_sizing.py で概算 → 実機で -ngl を上げて詰める → OOM手前で確定。
全層GPUを最優先。どうしても無理なら、品質を許す範囲で量子化を強める。
長文要件はオフロードで解くよりRAGで入力を畳むほうが速いことも → ローカルRAGの構成

なぜそうするか

ハードを買い替える前に、3レバーで多くの「載らない」は解ける。特に量子化とコンテキスト設計はタダで効きます。オフロードを最後に回すのは、それが唯一「容量を稼ぐ代わりに速度を確実に落とす」レバーだから。順番を守れば、最小の代償で動かせます。

⚠️ よくある落とし穴

いきなり大量オフロード：動くが激遅。まず量子化とKVで削る。
コンテキストを盛ったままオフロードで解決しようとする：KVが主因なら長さ/KV量子化を先に。
品質を確認せず最小量子化：Q2/Q3は最後の手段。用途で評価。
-ngl を当て推量：実測で詰める（OOM手前が最速）。

対応lab

local-llm-study/labs/vram_sizing.py（収まり計算）＋ llama.cpp の lab（-ngl調整手順）。