手元のVRAMで動くモデルを見積もる — 量子化とメモリ計算の基礎

モデルをダウンロードした。起動した。落ちた。エラーメッセージにはメモリ不足と書かれているが、では何GB必要なのかは書かれていない。ファイル名には Q4_K_M という記号が付いていて、隣には Q5_K_M や Q8_0 もある。どれを選べばいいのか判断がつかない。ローカルLLMで最初につまずくのは、性能ではなくこの見積もりの問題だ。

幸い、必要量の主要部分は掛け算1つで出る。本記事では、その式と、式に入れる数字の読み方を扱う。公式が実測値を公表している範囲だけを使い、推論で出した数値には概算と明記する。

「起動しない」の原因はほぼメモリで説明がつく

ローカルLLMが起動しない理由の大半は、モデルの重みが載りきらないことにある。そして必要量は、次の3つの足し算で決まる。

1. モデルの重み — 起動した瞬間から占有し、最後まで解放されない
2. KVキャッシュ — 会話が長くなるほど増える
3. 実行時のオーバーヘッド — フレームワークが確保する作業領域

3番目には、計算途中の中間値を置く領域や、複数リクエストを同時に処理するための作業バッファが含まれる。llama.cpp の llama-server には --parallel N でサーバースロット数を指定するオプションがあり、既定値は自動になっている。同時に受けるリクエストを増やせば、その分だけ作業領域も増える。共有サーバーとして立てるなら、この分を見込んでおく必要がある。

このうち圧倒的に大きいのが1番目で、しかも事前に正確に計算できる。まずここを押さえる。

順番も重要だ。重みは起動時に一括で確保されるため、足りなければ即座に落ちる。原因が分かりやすい失敗である。厄介なのは2番目で、起動して少し使えた後に落ちる。しばらく動いていたのだから設定は正しいはずだと考えてしまい、原因の特定に時間がかかる。3番目は環境によって幅があり、事前に厳密な計算をするより余裕を持たせて吸収するほうが現実的だ。

つまりローカルLLMの見積もりとは、確定計算できる部分を先に押さえ、可変部分に残りをどう割り当てるかを決める作業である。全部を厳密に計算しようとすると手が止まる。

重みの大きさは掛け算1つで出る

式はこうだ。

必要バイト数 = パラメータ数 × 1パラメータあたりのビット数 ÷ 8

パラメータ数はモデルカードに書いてある。ビット数は量子化形式で決まる。これだけである。

式が正しいかを、llama.cpp 公式が公表している実測値で確かめておこう。Llama-3.1-8B を Q4_K_M で量子化した場合、公式表の1パラメータあたりのビット数は 4.8944、ファイルサイズは 4.58 GiB とされている。式に入れると、8.03×10^9 × 4.8944 ÷ 8 = 4.913×10^9 バイト、つまり 4.575 GiB。公式実測値と一致する。

Q8_0 でも確かめておく。ビット数 8.5008、公式のファイルサイズ 7.95 GiB。計算すると 8.03×10^9 × 8.5008 ÷ 8 = 8.532×10^9 バイト = 7.945 GiB。こちらも合う。式は信用してよい。

量子化の記号を読む

では Q4_K_M とは何か。分解すると読める。

• Q4 — 基本となるビット数。4ビット
• _K — K-quant と呼ばれる方式。ブロックごとにスケール値を持たせて精度を保つ
• _M — 同じ4ビット系の中でのサイズ違い。S（小）、M（中）、L（大）の順に大きくなる

ここで注意したいのが、Q4 と書いてあっても実際のビット数は4ではないという点だ。公式表の Q4_K_M は 4.8944 ビットで、5に近い。スケール値やブロックごとの補正情報が上乗せされるためである。ファイル名の数字を鵜呑みにして計算すると、2割ほど小さく見積もることになる。

公式の実測表を手元に置く

判断材料として、llama.cpp 公式が Llama-3.1-8B で公表している値をそのまま引く。

この表から読み取れることが2つある。ひとつは、F16 から Q4_K_M に落とすとサイズが約3分の1になること。14.96 GiB が 4.58 GiB になるのだから、載るか載らないかが変わる。もうひとつは、Q4 系と Q5 系の差は 0.75 GiB しかないこと。メモリに余裕があるなら、Q4 に固執する理由は薄い。

なお、品質については触れない。現行の公式ドキュメントには perplexity の測定値が載っていないからだ。ネット上には「Q4_K_M が推奨」という記述が広く出回っているが、現行の公式表に推奨のマークは付いていない。裏付けのない推奨を引き写すより、自分の仕事で試すほうが早い。

もうひとつ、表の下端も見ておきたい。Q2_K は 2.95 GiB まで縮むが、ビット数は 3.1593 で、名前の2からはさらに離れている。極端に小さい形式ほど、名前と実測の乖離が大きくなる傾向がある。小さくしたつもりが思ったほど小さくなっていないという事態は、下端ほど起きやすい。

そして F16 の 14.96 GiB という値には別の使い道がある。これはほぼ量子化していない状態のサイズなので、そのモデルの素の大きさを表す。手元の空きが15GB以下なら、そもそも量子化なしの選択肢は消える。判断の出発点として便利な数字だ。

別のモデルに当てはめてみる

式が使えるかどうかは、別のモデルで試すと分かる。Qwen3-8B の公式モデルカードには、総パラメータ 8.2B、非埋め込みパラメータ 6.95B と記載されている。

これを Q4_K_M 相当で見積もると、8.2×10^9 × 4.8944 ÷ 8 = 5.017×10^9 バイト、約 4.67 GiB。ただしこれは概算である。埋め込み層や出力層は別のビット数で量子化されることが多く、実ファイルは前後する。それでも「8GBのGPUなら重みは載る」という判断には十分な精度だ。

ここで併記されている「非埋め込みパラメータ 6.95B」という数字にも意味がある。総パラメータ 8.2B との差、約 1.25B が埋め込み層にあたる。埋め込み層は語彙数に比例して大きくなる部分で、多言語対応の広いモデルほどここが膨らむ。日本語を扱うモデルを選ぶとき、この層は削りたくない。量子化ツールが埋め込み層を高めの精度で残す設定を持っているのは、そのためだ。

小さい側の実例も見ておきたい。パラメータ数が1B前後まで下がると、単板コンピュータのような小型機でも動く領域に入る。実際にどこまで実用になるかは深く、遅く、賢く。「System 2」を60ドルのRaspberry Pi 5で動かす意味（2026-02-17 公開）で扱った通りで、式そのものは機材の大小に関係なく同じである。

KVキャッシュ — 長い会話が効いてくる場所

重みが載ったのに、会話が長くなると落ちる。この現象の犯人がKVキャッシュである。

生成のたびに、モデルは過去のトークンすべての中間表現を保持する。これがKVキャッシュで、コンテキスト長に比例して増える。構造としてはこうなる。

KVキャッシュ量 ≒ 2 × レイヤー数 × KVヘッド数 × ヘッド次元 × コンテキスト長 × 1要素のバイト数

先頭の2は、KeyとValueの2種類を持つことを表す。Qwen3-8B ならレイヤー数は36である。ヘッド次元はモデルカードに記載がないため、ここで具体的なバイト数は出さない。重要なのは、コンテキスト長が線形に効くという構造のほうだ。

Qwen3-8B のネイティブなコンテキスト長は32,768トークン、YaRN を使うと131,072トークンまで伸びる。4倍に伸ばせば、KVキャッシュも4倍になる。長文を扱いたいという要求は、そのままメモリ要求に化ける。

GQA がメモリを大きく削っている

ここで効いているのが GQA、Grouped Query Attention だ。Qwen3-8B のモデルカードには、アテンションヘッドが「32 for Q and 8 for KV」と記載されている。

Q側は32あるのに、KV側は8しかない。KVキャッシュのサイズを決めるのはKV側の数なので、これは4分の1に削減されているということだ。すべてのヘッドが独立にKVを持つ設計なら、同じコンテキスト長でメモリは4倍要る。

この構造を知っておくと、モデル選びの見方が変わる。長い文脈を扱いたいなら、パラメータ数だけでなくKVヘッド数の比率を見るべきだということになる。

同じパラメータ数のモデルが2つあって、片方が長文で落ちやすいという現象は、この比率の差で説明がつくことが多い。モデルカードのアーキテクチャ欄は、性能を読むためではなくメモリの振る舞いを読むために見るのが実務的な使い方だ。

量子化を下げる前に、削れるものが2つある

メモリが足りないとき、多くの人は量子化を1段下げようとする。しかし品質に直接触るその手より先に、試すべきものが2つある。

第一に、コンテキスト長を下げること。前節のとおりKVキャッシュはコンテキスト長に比例するので、32,768を8,192に落とせばキャッシュは4分の1になる。実際の仕事で3万トークンの文脈が要る場面は、思うほど多くない。要らない長さのために品質を犠牲にするのは順序が逆だ。

第二に、KVキャッシュ側の精度を落とすこと。重みとキャッシュは別々に精度を設定できる。重みは高い精度のまま、キャッシュだけを圧縮するという配分が取れる。重みを一律に削るより、影響の出方が読みやすい。

この2つを試したうえで足りないなら、そこで初めて量子化を下げる。削る順番を決めておくと、品質劣化を最後の手段にできる。

順番を意識する理由はもうひとつある。コンテキスト長やキャッシュ精度の変更は設定ファイルの1行で、すぐ元に戻せる。対して量子化の変更は、別のファイルを落とし直す作業になる。戻しやすい手から順に試すというのは、切り分け作業の基本でもある。

なお、どうしても載らない場合には、モデルの一部をシステムメモリ側に置く構成も取れる。ただし速度は大きく落ちる。動くことと使えることは別だという線引きは、ここでも変わらない。

実行環境を4つ、機能で比べる

重みとキャッシュの見積もりができたら、次は何で動かすかだ。主要な4つを、公式ドキュメントに記載のある事実だけで並べる。速度は自分で同条件の測定をしていないので、比較軸に入れない。

Ollama について1点補足する。公式ドキュメントは未対応項目を明記しており、chat completions では logprobs、tool choice、logit bias、user、n が対象外だ。埋め込みではトークン配列の入力形式が使えず、画像は base64 のみで URL 指定ができない。これは欠点というより、境界を公表している誠実さと読むべきだろう。他の環境が同じ範囲をすべて満たしているかは、公式記述からは確認できない。

vLLM についても補足しておく。公式ドキュメントは自らを「a fast and easy-to-use library for LLM inference and serving」と説明し、連続バッチング、chunked prefill、prefix caching、そして PagedAttention を機能として挙げている。PagedAttention はKVキャッシュの管理方式で、前節で見たキャッシュの断片化を抑える仕組みだ。複数のリクエストを同時に捌く前提で設計されていることが、機能の並びから読み取れる。

裏を返せば、1人で1つのリクエストを流すだけの用途なら、この設計の恩恵は薄い。自分の使い方が単発なのか同時多発なのかで、選ぶべき環境が分かれる。家庭で1人が使うなら導入の簡単さが効き、チームで共有するなら並列処理の記述がある環境を選ぶことになる。

OpenAI互換という共通言語

4つを並べて見えてくるのは、どれもがOpenAI互換のエンドポイントを提供しているという事実だ。これは実務上きわめて大きい。

既存のクライアントコードは、接続先の指定を差し替えるだけで手元のサーバーに向く。LM Studio の公式ドキュメントはこの点を明示していて、接続先を http://localhost:1234/v1 に変えればよいと書かれている。つまり実行環境の乗り換えコストが低い。

これはローカルLLMを試すうえで効いてくる性質だ。まず導入が簡単なものから始めて、要求が上がったら別の環境に移す。その移動でアプリケーション側を書き直さずに済む。GGUF についても同様で、llama.cpp 系の形式でありながら vLLM も対応形式として公式に列挙している。形式で環境が固定されるわけではない。

見積もりの手順を1つにまとめる

ここまでを実行順に並べ直す。

1. 手元の空きメモリを確認する。搭載量ではなく、他のプロセスが使っていない実際の残量を見る
2. 候補モデルのパラメータ数をモデルカードで確認する。MoE なら総パラメータのほうを使う。メモリには全部載るからだ
3. 量子化形式を仮に決めて、掛け算する。パラメータ数 × ビット数 ÷ 8
4. 残りをKVキャッシュに割り当てる。ここが足りなければコンテキスト長を下げる
5. 実行環境を決める。OpenAI互換なので後から替えられる

この順序なら、落ちてから原因を探す時間がなくなる。特に2番目でMoEを扱うときは注意したい。Qwen3.6-35B-A3B のようにアクティブパラメータが3Bでも、メモリには35B分を載せる必要がある。計算量とメモリ量を混同すると、見積もりが1桁ずれる。

この取り違えは実際によく起きる。「3Bなら軽い」と考えて落とし、35B分のメモリを要求されて落ちる。アクティブパラメータが効くのは生成速度のほうであって、載るか載らないかを決めるのは総パラメータだ。MoE は速度の工夫であって、メモリの工夫ではないと覚えておくと間違えない。

オープンウェイトのモデルは大型化が進んでおり、総パラメータが兆の単位に届くものも登場している。この動きがどこまで来たかはKimi K3が投げ込んだ2.8兆パラメータ（2026-08-13 公開）で整理したが、手元で回す話とモデルの大きさの話は、この見積り式を挟むと接続する。式に数字を入れれば、自分の機材で扱える上限がすぐ出る。

小さい側から始めたほうが速い

最後に、選び方の実務的な原則を1つ。上限に近いモデルから試さないことだ。

Qwen3 シリーズには 0.6B / 1.7B / 4B / 8B / 14B / 32B の密モデルと、30B-A3B・235B-A22B の MoE が揃っている。この幅は、段階的に試すためにある。小さいほうから始めて、自分の仕事で何が足りないかを具体的に掴んでから上げていく。そのほうが、結果的に短時間で適正なサイズに着地する。

gpt-oss-20b のように、公式モデルカードが「16GBのメモリで動く」と明記しているモデルから入るのも堅実な選択だ。総パラメータ21B、アクティブ3.6B、ライセンスは Apache 2.0。必要量が公式に書かれているモデルは、最初の1本として不確実性が少ない。

小さいモデルから始める利点は、メモリ以外にもある。ダウンロード時間が短いので試行の回転が速く、期待外れだったときの損失も小さい。加えて、小さいモデルで足りる仕事がどれかを先に把握できるという効果が大きい。分類や書式変換のような定型作業は、想像よりずっと小さいモデルで通ることが多い。そこを知らないまま大きいモデルを常用すると、生成のたびに待たされ、電気代も余分にかかる。

逆に、小さいモデルで明確に足りない仕事も見えてくる。複数の条件を同時に満たす設計判断や、長い文脈を踏まえた一貫した文章生成。ここで詰まったなら、初めてサイズを上げる根拠が手に入る。根拠を持ってサイズを上げるのと、最初から最大を選ぶのとでは、到達点が同じでも掛かる時間が違う。

なお、クラウド側の単価と手元のコストをどう比較するかはクラウドAIの請求書を見てローカルAIを考え直す（2026-08-24 公開）で整理している。移設の判断そのものは、見積もりができてからのほうが正確になる。

まとめ — 掛け算1つと、3つの足し算

本記事の要点を整理する。

• 必要バイト数はパラメータ数 × ビット数 ÷ 8 で出る。この式は公式実測値2件で一致を確認できる
• Q4_K_M の実ビット数は 4.8944 で、名前の4より2割ほど大きい
• F16 から Q4_K_M で約3分の1、Q4 と Q5 の差は 0.75 GiB
• 品質劣化の定量値は現行の公式ドキュメントに存在しない。推奨マークもない
• KVキャッシュはコンテキスト長に比例する。GQA の KV:Q 比が効く
• メモリが足りないときは、コンテキスト長とキャッシュ精度を先に削る。量子化を下げるのは最後
• 実行環境はどれも OpenAI互換なので、後から替えられる

ローカルLLMを扱ううえで、この見積もりは一度身につければ何度でも使える。モデルが新しくなっても、パラメータ数とビット数という2つの数字は必ず公表される。見積もりは、動かす前に紙の上で終わる。それを済ませてからダウンロードすれば、最初の1本で止まることはなくなる。

出典・参考

• llama.cpp「quantize README」（量子化形式ごとのビット数とファイルサイズ）
• llama.cpp「llama-server README」（OpenAI互換ルートと –parallel）
• OpenAI「gpt-oss-20b」モデルカード（21B総/3.6B活性・16GBで動作）
• Qwen「Qwen3.6-35B-A3B」モデルカード（35B総/3B活性のMoE）

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.