ローカルでLLMを動かそうとすると、最初に必ず「自分のマシンで何Bのモデルまで動くのか」という問題に突き当たります。ベンチマーク記事の数字を眺めても、GPUの型番が違えば参考になりません。
この記事では、VRAMの必要量をパラメータ数と量子化ビット数から見積もる方法と、実際に公開されている計測値との照合をまとめます。環境は llama.cpp 系（Ollama / LM Studio を含む）を想定しています。
VRAMの内訳は2つしかない
推論時にVRAMを消費するのは、大きく分けて次の2つです。
- モデルの重み：パラメータ数 × 1パラメータあたりのバイト数
- KVキャッシュ：コンテキスト長に比例して増える作業領域
モデル本体の見積もりは単純な掛け算です。GGUFの量子化方式ごとの1パラメータあたりの目安は以下になります。
| 量子化 | 1パラメータあたり | 7Bモデルの目安 |
|---|---|---|
| FP16 | 2.0 bytes | 約 14 GB |
| Q8_0 | 約 1.0 byte | 約 7.0 GB |
| Q5_K_M | 約 0.67 byte | 約 4.7 GB |
| Q4_K_M | 約 0.60 byte | 約 4.2 GB |
| Q3_K_M | 約 0.50 byte | 約 3.5 GB |
実運用ではこれに KVキャッシュと、フラグメント化や実装上のオーバーヘッドが乗ります。目安として、重みの15〜25%程度を余分に見ておくと安全です。
つまり Q4_K_M の 7B モデルなら 5GB 前後 が現実的な必要量になります。ここから逆算すると、自分のGPUで動くモデル規模が見えてきます。
公開されている計測値との照合
この見積もりが妥当かどうか、複数人の検証動画と突き合わせてみました。Tech With Tim と Syntax は、いずれも次のような目安を出しています。
- 8 GB のメモリ → 3B〜4B モデル
- 16 GB → 7B〜8B モデル
- 32 GB → 14B〜30B モデル
Q4_K_M の係数で検算すると、16GB（実効 13GB 程度）なら 14B が 8.4GB で収まる計算になり、32GB なら 30B が 18GB で収まります。おおむね整合しています。
Syntax は 14B〜35B をスイートスポットだと述べています。品質とハードウェアコストのバランスが良い帯域という判断です。
量子化の効果の大きさは、70B モデルを見るとよくわかります。FP16 なら 140GB 必要なところ、量子化によって 30〜70GB に圧縮されます。Tech With Tim は「量子化こそがコンシューマ機でAIを動かせる根本的な理由」と述べています。
見落としがちなKVキャッシュ
VRAM不足でクラッシュする原因の多くは、実はモデル本体ではなく KVキャッシュです。エージェント的な使い方をするとコンテキストが数万トークンまで伸び、そこで初めて不足します。
Zen van Riel の指摘どおり、コーディング用途ではコンテキストウィンドウを常に埋めたままにする必要があり、チャットのように途中でクリアできません。したがってコーディング用途では、モデル本体の見積もりだけではなく、想定するコンテキスト長ぶんのキャッシュを必ず足しておく必要があります。
スループットの詰め方
1ユーザーが対話するぶんには、ここまでの話で十分です。問題は複数のリクエストを捌く場合で、このときボトルネックはメモリではなくGPUの演算能力になります。Alex Ziskind は Mac Studio で llama server を16インスタンス起動し、並列度64、同時接続1,024という設定で 1,226 tokens/sec を記録しています。前段に Nginx を置いてラウンドロビンで分散させる構成で、1台のサーバーにリクエストが集中するのを防いでいます。
なお、Ollama のようなラッパーを使う場合はオーバーヘッドがあります。Alex Ziskind の計測では、Ollama 経由で 100 tokens/sec、llama.cpp 直接で 124 tokens/sec と、およそ2割の差が出ています。開発時の利便性を取るか、最後の2割を取るかは用途次第です。
ラッパーの内部実装はほぼ llama.cpp です。Tech With Tim も動画内で強調していますが、LM Studio も Ollama も Docker Model Runner も土台は同じで、違いはインターフェースにあります。
まとめ
- モデルの重みは「パラメータ数 × 量子化のバイト数」、Q4_K_M なら約 0.60 byte/param で見積もれる
- そこに KVキャッシュと、重みの15〜25%程度のオーバーヘッドを足す
- 16GB なら 7B〜8B、32GB なら 14B〜30B が現実的な上限
- 複数リクエストを捌くなら、ボトルネックはメモリではなくGPU演算。インスタンスを分割して前段で分散させる
手持ちのマシンのメモリ量がわかれば、動くモデルの上限はこの式でほぼ決まります。ベンチマークを眺めるより先に、ここを押さえておくのが近道でした。