VRAM所要の見積もり｜ローカルLLM

🎓 レベル：標準　|　重要度：A（必須） 📎 前提：量子化とVRAM・品質のトレードオフ　|　原理：推論の実務（機械学習）

要点（結論先出し）

必要VRAM はおおよそ 重み＋ KVキャッシュ＋実行時オーバーヘッド。この3項の足し算で「載るか」が決まる。
重み = パラメータ数 x bpw / 8。8B Q4_K_M なら約4.5GiB。
KVはコンテキスト長に比例。長文ほど重みを超えることもある。最初に必ず見積もる癖を。

概念 ── 3つの項を足すだけ

必要VRAM = 重みサイズ + KVキャッシュ + オーバーヘッド
  重みサイズ   = パラメータ数 x (bpw / 8)
  KVキャッシュ = 2 x 層数 x KVヘッド数 x head_dim x (bytes) x コンテキスト長
  オーバーヘッド = 実行時の作業領域（目安 数百MiB〜1GiB・要最新確認）

重みは静的、KVは使う文脈長で動く、オーバーヘッドはエンジンの取り分。この3つを足して手持ちVRAMと比べるのがサイジングの全てです。

計算実証（lab出力・8Bモデル）

対応lab vram_sizing.py より：

重み（量子化別, 8B）
  FP16   -> 14.90 GiB
  Q8_0   ->  7.92 GiB
  Q4_K_M ->  4.47 GiB

合計VRAM（Q4_K_M 8B + FP16 KV + oh0.70GiB）
  ctx= 4096: 重み4.47 + KV0.50 + oh0.70 = 5.67 GiB
  ctx= 8192: 重み4.47 + KV1.00 + oh0.70 = 6.17 GiB
  ctx=32768: 重み4.47 + KV4.00 + oh0.70 = 9.17 GiB

8KコンテキストのQ4_K_M・8Bなら約6.2GiBで、8GB GPUに収まります。32Kに伸ばすとKVだけで4GiB増え、合計9.2GiBで溢れる——コンテキスト長がサイジングを左右する好例です。

仕組み ── 逆算フロー

flowchart TD
  HW["手持ちVRAM（例8GiB）"] --> M["モデル候補とbpwを仮置き"]
  M --> CALC["重み＋KV＋oh を計算"]
  CALC --> J{"VRAMに収まるか"}
  J -->|"収まる"| OK["確定"]
  J -->|"溢れる"| FIX["量子化を強める・ctxを短く・オフロード"]
  FIX --> CALC

運用の勘所

まず重みだけで概算→ KVとオーバーヘッドを足して margin を見る。ぴったりは危険、1〜2割の余裕を。
コンテキスト長を決め打ちせず、用途に必要な分だけ確保する。
載らないときの打ち手は3つ：量子化を強める／コンテキストを短く／オフロード（→ オフロードと量子化でメモリに収める）。

なぜそうするか

OOM（Out of Memory）は起動時または長文入力時に突然起きます。先に足し算しておけば、買う前・動かす前に「載る/載らない」が分かり、無駄な試行錯誤とハード出費を避けられます。サイジングはローカルLLMで最初に身につけるべき計算です。

⚠️ よくある落とし穴

重みサイズ＝必要VRAMと誤解：KVとオーバーヘッドを忘れて長文でOOM。
コンテキスト長を最大で確保：使わない文脈長のKVがVRAMを食い潰す。
ぴったり載せて余裕ゼロ：バッチや一時バッファで溢れる。margin を取る。
製品スペックを古い情報で判断：GPU/メモリは世代で変わる。要最新確認。

対応lab

local-llm-study/labs/vram_sizing.py … 重み・KV・合計VRAMを計算実証（cp932安全）。