VRAM 8GBで動くのは7Bまで、14B Q4_K_Mには10.4GB必要｜公式GGUFサイズとKVキャッシュから計算し、実測で22.5倍の速度差が出た

本記事には広告(アフィリエイトリンク)を含みます。

「7Bなら8GBで動く」「14Bは12GB必要」──ローカルLLMの必要VRAMは、こういう丸めた言い方で語られがちです。ですが実際に手元のPCで動かすと、載るはずのモデルが載らない、あるいは載っているのに異常に遅いということが起きます。

この記事では、必要VRAMを「重み＋KVキャッシュ＋実行時オーバーヘッド」の3つの足し算として分解し、Qwen2.5シリーズ（3B/7B/14B/32B/72B）について1つずつ数字を出しました。使ったのはHugging Face公式リポジトリのGGUFファイルの実サイズと config.json の構成値、そしてllama.cpp公式の bits/weight 一覧表です。

そのうえで、筆者が自宅のWindows機（VRAM 8GB前提で組んだローカルAI環境）で実際に動かしたOllamaの呼び出しログ182件を持ち出し、計算どおりVRAMに収まるモデルと、収まらないモデルで生成速度が何倍変わったかを突き合わせました。

本記事のVRAM必要量・KVキャッシュ量・分岐点はすべて計算値です。GPU上の実メモリ使用量を計測したものではありません。一方、生成速度と応答時間は実測値（データベースに記録された実際の呼び出しログ）です。この区別は本文中でも都度明記します。

先に結論

• 必要VRAMは 「GGUFファイルのサイズ」＋「KVキャッシュ」＋「実行時オーバーヘッド」。パラメータ数だけでは決まらない。
• 「4bit量子化なら1パラメータ4ビット」は成り立たない。 Qwen2.5-7B の Q4_K_M を公式GGUFの実サイズから逆算すると4.919 bit/paramで、素朴な4.0bit見積もりの123.0%。llama.cpp公式表の 4.8944 ともほぼ一致する。
• KVキャッシュは層数×KVヘッド数で決まる。7Bは56.0 KiB/トークン、14Bは192.0 KiB/トークンで3.43倍。同じ文脈長でもモデルを倍にするとKVは3倍以上になる。
• 筆者の設定（num_ctx=8192）での計算値は、7B Q4_K_M = 5.30 GiB（8GiBに収まる）／14B Q4_K_M = 10.37 GiB（2.37 GiB 超過）。14BはKVを0にしても重みだけで8.87 GiBあり、num_ctxをいくら削っても8GiBには載らない。
• この2モデルを同じPC・同じ設定で回した実測105件では、生成速度の中央値が 7B 18.12 tok/s ／ 14B 0.80 tok/s。22.5倍の差が出た。応答時間の中央値は9.5秒 対 118.6秒。
• 逆に、7B Q4_K_M はモデルの公式上限 32,768 トークンいっぱいで回しても 6.61 GiB（計算値）で8GiBに収まる。8GBのカードで削るべきは文脈長ではなくモデルサイズ。
• VRAM 24GBが必要な階層（32B Q4_K_M＝20.99 GiB）を試すだけなら、時間単位で借りられるGPUサーバーという逃げ道がある。XServer VPS for GPUはNVIDIA L4／VRAM 24GBで150円/時・最大88,000円/月（2026年9月30日 公式サイト確認）。

必要VRAMは3つの足し算に分解できる

llama.cpp／Ollamaでモデルを動かすとき、GPUメモリに置かれるものは大きく3つです。

必要VRAM ＝ ①重み（量子化後） ＋ ②KVキャッシュ ＋ ③実行時オーバーヘッド

• ①重み：GGUFファイルそのもの。全層をGPUに載せる場合はファイルサイズがほぼそのまま必要になる。llama.cpp公式は「現時点ではメモリ要件とディスク要件は同じ」（At the moment, memory and disk requirements are the same.）と書いている。
• ②KVキャッシュ：これまでのトークンのKey/Valueを保持する領域。文脈長に比例して増える。ここを忘れると見積もりを外す。
• ③実行時オーバーヘッド：計算バッファなど。llama.cppもOllamaも公式に数値を明記していないため、本記事では0.5 GiBと仮定して計算しています（仮定値であることを表でも明示します）。

①と②は公開されている数字から正確に出せます。順に見ていきます。

「4bit量子化＝1パラメータ4ビット」は成り立たない

①を見積もるとき、最もよく使われるのが「パラメータ数 × 量子化ビット数 ÷ 8」です。7Bを4bitなら 7×4÷8 = 3.5GB、という計算です。この見積もりは必ず過小になります。

理由は、GGUFの量子化タイプが全層を同じビット数で潰さないからです。Q4_K_M の「M」はmedium混合を意味し、一部の層はより高い精度で残されます。さらに語彙埋め込みのように巨大で量子化が効きにくい行列もあります。

そこで、Hugging Face公式のGGUFリポジトリにある各ファイルの実バイト数（分割ファイルは合算）を、同モデルのsafetensorsのパラメータ総数で割り、実効ビット数（bit/param）を出しました。いずれも2026年9月30日に公式APIから取得した値です。

表1：Qwen2.5-Instruct の実効ビット数（GGUF実サイズ×8 ÷ パラメータ数）※すべて計算値

読み取れることは3つあります。

1. Q4_K_Mは4.0ビットではなく約4.85〜4.92ビット。7Bでは4.919、14Bでは4.868。素朴な4.0bit見積もりの約122〜123%です。7Bを「3.5GB」と見積もっていると、実際は4.361 GiBで、約0.9GiBのずれになります。

2. 独立した2つの情報源が一致する。Qwen2.5のGGUF実サイズから出した値と、llama.cpp公式がLlama-3.1-8Bで実測した bits/weight 表は、モデルも系列も違うのにQ4_K_Mで4.868〜4.919 対 4.8944、Q8_0で8.502〜8.531 対 8.5008とほぼ重なります。量子化タイプごとの実効ビット数はモデルにあまり依存しないので、「実効bpw × パラメータ数 ÷ 8」で他モデルにも当てはめられます。

3. 小さいモデルは実効ビット数が大きくなる。3Bの Q4_K_M は5.457で、7Bの4.919より11%大きい。Qwen2.5の語彙は約152,000で、モデルが小さくなっても埋め込み行列は小さくなりません。その分、量子化が効きにくい部分の比率が上がります。「3Bなら7Bの半分以下」とはならない点に注意が必要です。

KVキャッシュはモデル構成から正確に計算できる

②のKVキャッシュは、公開されている config.json の値だけで計算できます。llama.cppの既定であるf16（1要素2バイト）で保持する場合、1トークンあたりは次のとおりです。

KV/トークン ＝ 2（KとV） × 層数 × KVヘッド数 × ヘッド次元 × 2バイト

ヘッド次元は hidden_size ÷ num_attention_heads で、Qwen2.5では3Bから72Bまで一貫して128です。KVヘッド数（num_key_value_heads）はGQAで削られているため、アテンションヘッド数よりずっと小さくなります。

表2：KVキャッシュの計算値（f16、num_ctxは実際に確保される文脈長）

ここが見積もりを外す最大の落とし穴です。7Bから14Bへ上げると、パラメータ数は1.94倍なのにKVは3.43倍になります。層数が28→48（1.71倍）、KVヘッドが4→8（2倍）で、両方が掛かるからです。

そして文脈長の効き方が非対称です。7Bを32,768トークンで回してもKVは1.75 GiBで済みますが、14Bを同じ32,768で回すとKVだけで6.00 GiB。これは14BのQ4_K_M重み（8.37 GiB）の7割に相当します。

なおOllamaの既定の文脈長は4,096トークンです（公式FAQ：By default, Ollama uses a context window size of 4096 tokens. This can be overridden with the OLLAMA_CONTEXT_LENGTH environment variable.／2026年9月30日確認）。既定のままなら表2の左寄りの列で足りますが、長い指示や資料を投げる用途では既定では足りず、num_ctxを上げた瞬間にKVが膨らみます。筆者の環境は num_ctx=8192 に設定しているので、以降は既定4,096と8,192の両方を出します。

モデル×量子化別の必要VRAM（計算値）

①＋②＋③（0.5 GiB仮定）を合計したのが次の表です。○×は、その容量のカードに理論上収まるかどうかを示します。GPUの表示容量（8GB等）は実際には8 GiBですが、OSや画面出力が一部を使うため、○でも実際には入らない境界があります。あくまで上限の目安です。

表3：必要VRAM（計算値、num_ctx=4,096／Ollama既定）

単位はすべてGiB。

表4：必要VRAM（計算値、num_ctx=8,192／筆者の設定）

単位はすべてGiB。

表3と表4を見比べると、文脈長を既定の4,096から8,192に上げただけで14B Q8_0が16GBに載らなくなり（15.87→16.62）、32B Q4_K_Mは24GBぎりぎり（19.99→20.99）になります。「VRAM何GBで何Bが動くか」は、文脈長を決めないと答えが出ない質問です。

VRAM 8GBで実際に何が起きたか（実測）

ここからは実測です。筆者は自宅のWindows機にVRAM 8GB前提で設計したローカルAI環境（Ollama＋自作のマルチエージェント処理）を組み、その呼び出し履歴をSQLiteに記録しています。表4の計算では7B Q4_K_Mは収まり（5.30 GiB）、14B Q4_K_Mは2.37 GiB超過（10.37 GiB）という結果でした。実際の速度はどうだったか。

計測条件（すべて同一）

• 期間：2026年8月22日〜9月3日。記録された呼び出し182件（うちローカル成功105件、ローカル失敗14件、クラウド失敗63件＝APIキー未設定による即時失敗）
• 推論エンジン：Ollama（http://127.0.0.1:11434 の /api/chat）
• 設定：num_ctx=8192、temperature=0.6、timeout_sec=300（同一の設定ファイルから全呼び出しで共通）
• モデル以外の条件は変えていない。同じPC・同じ設定で、モデルだけを差し替えた比較

表5：生成速度の実測（ローカル成功105件、中央値）

出力トークン数はほぼ同じ（108 対 106）なのに、生成速度の中央値は22.5倍、応答時間の中央値は12.5倍の差が付きました。全呼び出しの総出力トークンを総所要時間で割った通算スループットでも、11.06 tok/s 対 1.03 tok/sで約10.7倍です。

この差は「14Bが2倍大きいから2倍遅い」という話ではありません。VRAMに収まるかどうかで、速度は連続的ではなく段差で落ちます。Ollama公式FAQも、モデルが全部GPUに載らない場合があることを前提に、ollama ps のProcessor列で「100% CPU means the model was loaded entirely in system memory」「48%/52% CPU/GPU means the model was loaded partially onto both the GPU and into system memory」と説明しています。

ただし、この実測の限界を明記します。筆者の記録にはGPUへのオフロード率（ollama psのProcessor列に相当する値）を残していないため、14Bがどれだけシステムメモリ側に追い出されていたかは特定できていません。したがって「VRAM超過が原因で22.5倍遅くなった」と因果を断定することはできません。言えるのは、計算上8GiBに収まるモデルと2.37 GiB超過するモデルを同じPC・同じ設定で回したとき、実測で22.5倍の差が出たという事実です。

なお、7Bの生成速度の最小値が0.58 tok/sまで落ちている点も付記します。中央値18.12に対する外れ値で、初回のモデルロードや他プロセスとの競合が混じっていると考えられますが、こちらも原因は特定していません。

Ollamaが配るモデルの実体は公式GGUFと同一だった

表1〜表4はHugging Face公式のGGUFサイズを使っています。では、実際に ollama pull で降ってくるファイルは同じものなのか。Ollama公式レジストリ（registry.ollama.ai）のマニフェストを取得して、model層のサイズを突き合わせました。

表6：Ollamaレジストリのサイズと公式GGUFサイズの一致確認（2026年9月30日取得）

差は数百バイト、比率では0.1 ppm未満。実体は同じQ4_K_Mです。ここから2つ確認できます。

• qwen2.5:7b-instruct のように量子化を指定しないタグの実体はQ4_K_Mである（4.361 GiB＝表1の7B Q4_K_Mと一致）。「なぜか思ったより大きい/小さい」と感じたときは、まずタグがどの量子化を指しているかを確認するとよい。
• Ollamaのサイト表示は十進のGB（4.7GB／9.0GB）だが、VRAMは2進のGiBで考える必要がある。9.0GBという表示を「9GB」と読むと8GiBカードとの差が小さく見えるが、実際は8.371 GiBで、8 GiBを最初から超えている。

8GBのカードで打てる手を数字で並べる

表4の計算から、VRAM 8GBで採れる選択肢を効果の大きい順に並べます。いずれも計算値です。

表7：8GiBに収めるための手段（計算値、14B Q4_K_Mを起点に）

この表がはっきり示すのは、8GBのカードで削るべきは文脈長ではなくモデルサイズだということです。14Bは文脈長を0にしても載らない（8.87 GiB）一方で、7Bはモデルの公式上限である32,768トークンいっぱいまで使っても6.61 GiBで収まります。量子化を落として14Bを押し込む道もありますが、Q3_K_Mでも既定の4,096トークンでは8GiBを超え、num_ctxを3,630まで削らないと入りません。「14BをQ3_K_Mまで潰して文脈を3,630に絞る」より、「7B Q4_K_Mで32,768トークン使う」ほうが、VRAMも速度も有利です。

それでも14B以上を試したい場合、選択肢は「VRAMの大きいGPUを買う」か「借りる」のどちらかになります。GPUの購入判断は別途、VRAM単価と電気代で計算する必要があります（この点は自宅PCの24時間稼働とVPSの損益分岐を計算した記事で、消費電力1Wあたり月32.16円という単価を出しています）。

借りる側の相場として、XServer VPS for GPUを公式サイトで確認しました（2026年9月30日時点）。

• GPU：NVIDIA L4 Tensorコア GPU ×1枚、VRAM 24GB
• vCPU 24コア／メモリ 120GB／SSD 150GB（RAID10）／OS Ubuntu 22.04 LTS
• 料金：150円/時、最大88,000円/月。初期費用無料
• 公式の注記：「サーバー停止中も課金されます。利用しない場合は解約してください」

VRAM 24GBは、表4でいえば32B Q4_K_M（20.99 GiB）と14B Q8_0（16.62 GiB）が入る階層です。8GBのカードでは絶対に届かない範囲を、買わずに確かめられます。

時間課金と月額の分岐点も出しておきます。88,000円 ÷ 150円/時 = 586.7時間。つまり月の稼働が約587時間（30日なら1日約19.6時間）を超えると月額上限のほうが安くなり、それ未満なら時間課金のほうが安いという計算です（公式掲載料金からの計算値）。常時稼働させるなら30日で720時間＝時間課金なら108,000円相当ですが、上限の88,000円で止まります。「1日2〜3時間、量子化の違いを確かめるだけ」なら、時間課金は月額の1割以下で済みます。

なお同社のVPSでもFX自動売買専用やWindows Serverの各プランにGPUは搭載されていません（XServer VPS for FX、XServer VPS for Windows Server）。ローカルLLMの推論を速くする目的でこれらを契約しても効果はありません。GPUが要る処理はGPUサーバー、24時間止めたくない常駐処理（EAやスケジューラ）はCPUのVPS、という切り分けになります。

再現手順と、この記事で使った数字の出どころ

本記事の計算はすべて1本のPythonスクリプトにまとめ、主要な結論を assert で検証しています。手元で確かめる場合の手順は次のとおりです。

1. パラメータ総数：https://huggingface.co/api/models/<repo> の safetensors.total。
2. GGUF実サイズ：https://huggingface.co/api/models/<repo>-GGUF?blobs=true の siblings[].size。分割ファイル（-00001-of-0000N）は必ず合算する。合算を忘れると数分の1に見誤る。
3. 実効ビット数：サイズ×8 ÷ パラメータ数。
4. KV/トークン：config.json から 2 × num_hidden_layers × num_key_value_heads × (hidden_size ÷ num_attention_heads) × 2。
5. Ollamaの実体確認：registry.ollama.ai/v2/library/<model>/manifests/<tag> を Accept: application/vnd.docker.distribution.manifest.v2+json で取得し、application/vnd.ollama.image.model 層の size を見る。
6. 自分の環境の実測：ollama ps でProcessor列（CPU/GPUの配分）を確認する。本記事の実測ログにはこの値が無く、それが本記事の弱点になっている。これから計測するなら、生成速度と一緒にオフロード率を必ず残しておくことを勧めます。

スクリプトと出力CSV、および実測の元データ（呼び出しログ182行）は手元に保存しています。検算内容は、Q4_K_Mの実効ビット数が全モデルで4.0を超えること、Q8_0が公式表8.5008の±1%に入ること（7B以上）、7Bの計算値が8 GiB未満かつ14Bが8 GiBを超えること、Ollamaレジストリと公式GGUFのサイズ差が0.01%未満であること、実測の速度比が20倍を超えることの5点です。

まとめ：VRAMは「パラメータ数」ではなく「ファイルサイズ＋文脈長」で決まる

• 必要VRAM＝GGUF実サイズ＋KVキャッシュ＋実行時オーバーヘッド。パラメータ数×量子化ビット数だけの見積もりは約22%過小になる。
• Q4_K_Mの実効ビット数は約4.85〜4.92 bit/param（llama.cpp公式表は4.8944）。3Bのような小さいモデルでは5.457まで上がる。
• KVは層数×KVヘッド数で決まり、7B→14Bで3.43倍。「何GBで何Bが動くか」は文脈長を決めてからでないと答えが出ない（Ollamaの既定は4,096トークン）。
• VRAM 8GBの実用解は7B Q4_K_M。計算値5.30 GiB（num_ctx=8192）／6.61 GiB（32,768）で、文脈長を削らずに収まる。
• 14B Q4_K_Mは重みだけで8.87 GiBで、num_ctxをどう削っても8GiBには載らない。同じPCでの実測では生成速度が0.80 tok/s（7Bの1/22.5）だった。
• 14B以上を確かめたいなら、VRAM 24GBを時間単位で借りるのが最も安い検証手段になりうる（150円/時・最大88,000円/月、分岐点は約587時間/月）。

本記事のVRAM必要量・KVキャッシュ量・分岐点は公開仕様とファイルサイズにもとづく計算値であり、GPU上の実メモリ使用量を計測したものではありません。生成速度は筆者の1台の環境での実測値で、GPUの型番・ドライバ・同時実行数・OSの設定によって大きく変わります。GPUへのオフロード率を記録していないため、速度差の原因をVRAM超過に断定することはできません。また、量子化タイプごとの実効ビット数やOllamaの既定値は今後のバージョンで変わる可能性があり、過去に取得した数値が将来も同じであることを保証しません。料金は確認時点の公式掲載値で、キャンペーンや改定で変動します。

この記事の検証環境

• 実測に使ったPC：Windows機1台。GPUはVRAM 8GB前提で構成（設計方針として「VRAM 8GB 前提 ＝ 7B級モデルが実用速度で動く上限」と自分の設計文書に明記しているもの）。GPUの型番・ドライバ版・CPU・メモリ容量は計測時に記録しておらず、本記事では特定していません
• 推論エンジン：Ollama（/api/chat、http://127.0.0.1:11434）。KVキャッシュはf16（llama.cpp既定）を前提に計算
• 使用モデル：qwen2.5:7b-instruct（実体はQ4_K_M、4.361 GiB）、qwen2.5:14b-instruct-q4_K_M（8.371 GiB）
• 推論設定：num_ctx=8192／temperature=0.6／timeout_sec=300（全呼び出しで共通）
• 実測データ：SQLiteに記録した呼び出しログ182行（2026-08-22〜2026-09-03）。ローカル成功105件のみを速度集計に使用。GPUオフロード率は未記録
• 検算：Python 3 のスクリプト1本で計算し、主要な結論5点を assert で検証。出力はCSVに保存
• VRAM 24GBを借りる場合の参照先：XServer VPS for GPU（NVIDIA L4 Tensorコア GPU 1枚／VRAM 24GB／vCPU 24コア／メモリ120GB／SSD 150GB／Ubuntu 22.04 LTS。150円/時・最大88,000円/月、初期費用無料。2026年9月30日 公式サイト確認）
• GPUを使わない常駐処理の参照先：XServer VPS for FX プレミアム（Premiumプラン 月額32,000円／1ヶ月契約、メモリ48GB・vCPU 8コア、SLA 月間稼働率99.99%以上、2026年9月30日 公式サイト確認）、XServer VPS for Windows Server、ConoHa VPS、お名前.com デスクトップクラウド。いずれもGPUは搭載されていないため、LLM推論の高速化には使えません

出典（いずれも2026年9月30日確認）

• Qwen2.5-Instruct 各モデルの config.json（層数・hidden_size・アテンションヘッド数・KVヘッド数）：7B／14B（32B・72B・3Bも同形式）
• Qwen2.5-Instruct-GGUF 各ファイルの実サイズ：Hugging Face Hub API https://huggingface.co/api/models/Qwen/Qwen2.5-14B-Instruct-GGUF?blobs=true（リポジトリ）
• llama.cpp 公式 量子化ドキュメント（bits/weight 一覧、「memory and disk requirements are the same」の記述）：https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md
• Ollama 公式FAQ（既定の文脈長4,096トークン、OLLAMA_CONTEXT_LENGTH、ollama ps のProcessor列の意味）：https://docs.ollama.com/faq
• Ollama 公式レジストリのマニフェスト：https://registry.ollama.ai/v2/library/qwen2.5/manifests/7b-instruct／.../14b-instruct-q4_K_M
• XServer VPS for GPU 公式ページ（NVIDIA L4・VRAM 24GB・150円/時・最大88,000円/月・停止中も課金の注記）：https://vps.xserver.ne.jp/gpu.php
• XServer VPS for FX 公式ページ（Premium 月額32,000円／1ヶ月契約、SLA 月間稼働率99.99%以上）：https://vps.xserver.ne.jp/fx/

同じPCの作業環境についてはモニタ構成を変えた記録にも書いています。