ローカルLLMで長文を扱うとVRAMはどれだけ増えるか｜16GBでKVキャッシュ膨張を実測し、あふれない設定を探る

KVキャッシュとは、LLMが処理済みトークンの中間状態を保持する作業メモリである。長文を入れるほどこの領域が膨らみ、モデルの重みとあわせてVRAMを圧迫していく。

対応するマザーボードやGPUがあれば、ローカルAI環境は数分で立ち上がるところまで来ました。導入のハードルが下がった一方で、長い仕様書やソースコードを丸ごと貼り付けた瞬間に「VRAMが足りません」と落ちる。この壁にぶつかる人もいるはずです。原因はモデル本体の重みに加えて、入力が長くなるほど膨らむKVキャッシュが上乗せされること。ここを理解すると、16GBのGPUでもどこまで長文を扱えるかを自分で見積もれるようになります。

本記事では、この膨張を推定や計算式ではなく実測で追いました。RTX 5060 Ti 16GB単体でコンテキスト長を4Kから最大64Kまで振り、KVキャッシュ量子化（FP16 / q8_0 / q4_0）を切り替えたときに確保VRAMがどう動き、どこで16GBからあふれるかを測っています。結論を先に言えば、qwen3:14bはFP16のままだと32Kまでしか16GBに載らず、モデル上限の40Kであふれる。ところがKVキャッシュをq8_0に落とすと同じ40Kが11.78GiBで全量GPUに収まる。これがタイトルの「あふれない設定」への実測回答です。

長文を入れるとVRAMが増える理由｜KVキャッシュの仕組み

ローカルLLMを動かすと、VRAMは大きく2つの用途で消費されます。モデルの重み（パラメータ）と、KVキャッシュ。前者はモデルを選んだ時点でほぼ固定ですが、後者は入力する文章の長さに応じて後から膨らんでいきます。長文を扱うときにVRAMが逼迫するのは、この後者が原因。

モデル重みとKVキャッシュ、VRAMを食う2つの塊

モデルの重みは、そのモデルをロードした瞬間にVRAMへ載る「据え置きの塊」です。14Bのモデルなら14B分、量子化していればその圧縮後サイズが目安になります。ここは会話が長くなっても基本的に変わりません。

対してKVキャッシュは、処理済みのトークンごとに生まれる中間状態（Key と Value）を保持しておく領域。次のトークンを予測するとき、過去のトークンを毎回計算し直さずに済ませるためのメモリです。そのサイズは概ね次の要素の積で決まります。

2 × 層数 × KVヘッド数 × ヘッド次元 × トークン数 × バッチサイズ × 1要素あたりのバイト数。

先頭の「2」は Key と Value の2種類ぶんの係数。ここで注目したいのが「トークン数」の項です。ほかの要素はモデル構造で固定なので、KVキャッシュは実質的にトークン数、つまりコンテキスト長に比例して線形に増えていきます。文書を2倍の長さにすれば、KVキャッシュもおおむね2倍。これが「長文を入れるとVRAMが増える」の正体です。

なお式中の「バッチサイズ」は、同時に保持する系列・並列リクエスト数に近い意味です。Ollamaでは OLLAMA_NUM_PARALLEL などの並列設定を上げると、その分だけ確保するKVキャッシュが増えます（本記事の測定は並列1の単一リクエスト前提）。

重要なのは、KVキャッシュがモデルの重みとは別枠で積み増しされる点。重みがVRAMに収まっていても、その上に長文ぶんのKVキャッシュが乗り切らなければ、そこであふれます。なお、近年のモデルの多くはGQA（グループ化クエリアテンション、KVヘッドを間引いてキャッシュを圧縮する仕組み）を採用しており、たとえばKVヘッドを8分の1にすればKVキャッシュも8分の1に縮みます。同じパラメータ規模でも、この構造次第でキャッシュの重さは変わってきます。

num_ctx を上げると何が起きるか

コンテキスト長を決めるレバーが num_ctx です。長い文書を扱いたいからと num_ctx を大きく設定すると、それに比例して確保されるKVキャッシュも増え、必要なVRAMが跳ね上がります。

Ollama では、このコンテキスト長がGPUのVRAM容量に応じて自動で決まる仕組みになっています。

OllamaはGPUのVRAM容量に応じて既定のコンテキスト長を自動決定する。24GiB未満のGPUでは4096トークンが既定値となる。（Ollama公式ドキュメント context-length より要約）

24GiB未満のGPUで既定4096トークン、24〜48GiBで32768トークン、48GiB以上で262144トークンという段階。16GBのカードは最初のバケットに入るため、何も設定しなければ約4kトークンで動きます。数十ページの文書をそのまま扱いたいなら、この既定値を自分で引き上げる必要があり、その瞬間にVRAMとの綱引きが始まる、というわけです。なお公式ドキュメント自身も、Web検索・エージェント・コーディング用途では64,000トークン以上への手動設定を推奨しています。既定の4kは「とりあえず動く」値であって、長文用途の推奨値ではありません。

KVキャッシュ膨張の実測｜16GBであふれる境界を測る

ここからが本題です。理屈のうえではKVキャッシュはコンテキスト長に比例して増えるはずですが、実際に確保されるVRAMがいくつで、どこで16GBを超えるのかは、そのモデルの構造と量子化設定に依存します。そこでRTX 5060 Ti 16GB単体で、コンテキスト長とKVキャッシュ量子化を振りながら確保VRAMを測りました（測定条件は後述の開示節にまとめています）。

まず主役の qwen3:14b（Q4_K_M。Ollama のモデル設定上の上限 ctx=40960。Qwen 公式はネイティブ32,768・YaRN拡張で131,072と説明しており、40960はOllama側タグの設定値）を、既定のFP16キャッシュで伸ばしていったときの確保VRAMがこちらです。数値は ollama ps が報告する確保サイズで、GPUへの搭載率もあわせて示しています。

読み取れる境界ははっきりしています。qwen3:14bはFP16のままだと32Kまでは13.39GiBで16GBに全量収まりますが、モデル上限の40Kを要求すると必要合計が15.25GiBに達し、GPUへ載るのは89.9%まで。残りはCPUへオフロードされます。実効枠（後述の約14.8GiB）を超えた瞬間にあふれるわけで、FP16キャッシュではこのモデルの40Kは16GB単体では収まらない、というのが実測の答えです。

KVキャッシュ量子化で40Kを全載せに戻す

では同じ qwen3:14b で、キャッシュだけをq8_0・q4_0に切り替えると確保VRAMがどう動くか。FP16と並べたのが次の表です。

FP16であふれた40Kが、q8_0では11.78GiBで100%GPUに載り、q4_0なら10.22GiBまで下がります。FP16の40Kが必要合計15.25GiBだったことを思えば、キャッシュ量子化だけで3〜5GiBの枠を空けている計算です。長文を狙うほど、この差がそのまま「あふれるか全載せか」を分けます。なお q4_0 では 49152 や 65536 を要求しても Ollama がタグ設定上の上限 40960 にクランプするため、確保値は 40K のとき（10.22GiB）と同じになりました。上限を超えるコンテキストはモデル側で頭打ちになる点も、設定を詰めるうえで押さえておきたいところです。

モデルによってKVの増え方はこれだけ違う

KVキャッシュの重さはモデル構造に強く依存します。同じ16GB枠でも、モデルを変えるとコンテキストを伸ばしたときの膨らみ方がまるで異なりました。FP16キャッシュで比較したのが次の表です。

目を引くのが gemma4:12b です。コンテキストを4Kから32Kへ8倍に伸ばしても確保VRAMは7.51GiBから7.85GiBへ、わずか0.34GiBしか増えません。qwen3:14bが4K→32Kで4.4GiB増えたのと対照的です。これは、Gemma 4 が局所的なスライディングウィンドウ注意（sliding window attention）と全体を見るグローバル注意（full global attention）を組み合わせたハイブリッド注意機構を採用し、長文時のメモリ負荷を抑える設計になっているためと考えられます。公式にはグローバル層で共有K/V（unified K/V）と Proportional RoPE を用いると説明されており、長いコンテキストでもキャッシュがほとんど膨らまない挙動につながっています。機構の詳細な断定はここでは避けますが、実測として「長文でVRAMがほぼ増えないモデルが存在する」ことははっきり出ています。qwen3.5:9bも軽く、64Kまで伸ばしても7.63GiBで全量GPUに載りました。長文を常用したいなら、そもそもKVの軽いモデルを選ぶという方向が有効だと数字が示しています。

測定条件の開示

上の数値がどういう条件で得られたかを開示します。読み手が自分の環境と突き合わせられるよう、正直に書いておきます。

• ・測定系: RTX 5060 Ti 16GB 単体 / Ollama 0.30.7 / CUDA / 専用serve（port 11437）
• ・Flash Attention 有効。KVキャッシュ量子化は serve の環境変数 OLLAMA_KV_CACHE_TYPE で切替
• ・各点は単発測定（3回平均ではない）。数値には測定ごとの揺れが乗りうる
  ・各点の測定前に全モデルをアンロードし、GPU使用量がベースライン（0MiB）へ戻ったことを確認してから次点をロード
  ・OLLAMA_NUM_PARALLEL=1 / OLLAMA_MAX_LOADED_MODELS=1 の単一リクエスト前提（並列処理や複数モデル常駐では必要VRAMが増える）
  ・生成リクエストは think=false（thinking無効）で統一
  ・使用タグとdigest（2026-07-04時点）: qwen3:14b=bdbd181c33f2 / gemma4:12b=4eb23ef187e2 / qwen3.5:9b=6488c96fa5fa
• ・GPU実載は ollama ps の onGPU% と nvidia-smi で確認
• ・本測定環境では、指定した num_ctx に応じた確保VRAMがロード時点の ollama ps に反映された（＝ロード時にKV枠が確保される挙動）。本測定はこの「確保されたVRAM」を測る方式。長文を実際に流し込んで生成中に増えていく様子を測ったものではない
• ・測っていない次元: 長文での生成品質・速度低下・実プロンプト投入時の挙動は本記事では未評価

16GBでどこまで伸ばせるか｜重みとKVキャッシュの取り合い

公称16GBといっても、全部が使えるわけではありません。OSやドライバに取られる分を引くと、当サイトの実運用での実効枠はおよそ14.8GiBです。公称の「16GB」は十進表記で、nvidia-smi 基準の2進（GiB）換算では約14.9GiB。そこからOS・ドライバの予約分を引いた残りが実効枠になります。本記事の実測系はすべてGiB表記で統一しています。この枠にまず重みが載り、残った容量が長文のKVキャッシュに回せる予算になります。

モデル別・16GBに対する重みの占有

次の表は、上のKVカーブと同じ RTX 5060 Ti 16GB で、代表的なモデルをロードしたときのVRAM使用量を測ったものです（2026年6月計測、各3回計測の中央値、既定コンテキスト長）。数値は nvidia-smi の memory.used、つまりGPU全体の使用量です。KVカーブが ollama ps の確保VRAM基準だったのに対し、この表は nvidia-smi のGPU全体使用量基準なので、測り方が違う両表の数値をそのまま足し引きはできませんが、同じ16GBカード上での重みの目安として読めます。

読み取れるのは、規模帯ごとの余力の違いです。14B級は約10GiBで収まり、14.8GiBの枠に対して4〜5GiB弱の空きが残ります。この空きが長文のKVキャッシュに回せる領域。22B級以上になると約13.7〜14.5GiBまで埋まり、枠をほぼ使い切ります。KVキャッシュに回せる余地はごくわずか。さらに27B以上のdense型は、量子化の強度しだいで挙動が分かれます。通常のQ4_K_M量子化（たとえば gemma3:27b-it-q4_K_M は約17GB）だと重みだけで16GBの実効枠を超え、CPUオフロード前提の動作になります。一方でQAT（量子化対応学習）版のint4のように、より攻めた量子化なら重みが16GBに収まる例もあります（それでもKVキャッシュに回せる余地はごくわずかです）。この27B帯は本記事の実測表には含めておらず、公表サイズからの見積もりです。

残り容量が長文コンテキストの上限を決める

ここまでの数字を一言でまとめると、16GB級では「重みで埋まった残りが、そのまま長文に使えるコンテキスト長の上限になる」という関係です。14B級なら残枠に余裕があるので num_ctx を伸ばしやすく、22B級以上では重みだけで手一杯になり、既定の4kから増やす余地が乏しくなります。

では枠を超えたらどうなるか。VRAMに収まらない分はシステムRAM側（CPU）へ退避され、そのぶん処理がGPU完結でなくなって速度が落ちます。当サイトのデュアルGPU構成（RTX 5080 + RTX 5060 Ti）で確認した例では、Qwen3.5-35B-A3B（Ollamaタグ表記で約24GB、ollama ps 上の常駐サイズ約22GiB）を主GPU（5080）1枚だけで動かすと重みの37.8%がCPUへあふれ、生成速度は65.99 tok/sまで低下しました。2枚目を足して全量をVRAMに収めると125.87 tok/s、約1.9倍まで回復しています。これはKVキャッシュではなくモデル重みがあふれた事例ですが、「VRAMからあふれた瞬間に速度が犠牲になる」という構図は長文のKVキャッシュでも同じです。

あふれさせない設定｜量子化・num_ctx・KVキャッシュ量子化

16GBで長文を扱うには、限られた枠の中で「重みを削る」か「キャッシュを削る」かを選びます。効くレバーは主に3つ。

まず重みの量子化。本記事で使った qwen3:14b タグはQ4_K_M量子化で、この重み量子化がモデルを圧縮して枠を空ける第一手です。より軽いフォーマットを選べば残枠は増えますが、削りすぎると出力品質に影響が出る領域に入ります。

次に num_ctx。長文を扱う用途に「足りる最小」へ設定するのが基本です。128k相当を確保しても、実際に使うのが数千トークンなら、確保したKVキャッシュぶんのVRAMが無駄に押さえられるだけ。用途に合わせて絞ります。

3つめがKVキャッシュ量子化。キャッシュそのものを圧縮する手で、Ollamaでは既定のFP16に対し、q8_0でメモリを約半分、q4_0で約4分の1まで削減できます。これを使うにはFlash Attention の有効化が前提です。前掲の実測でいえば、qwen3:14b の40Kは FP16 では必要合計15.25GiBであふれましたが、q8_0にすると11.78GiB、q4_0なら10.22GiBで全載せに戻りました。つまりこのモデルで40K分のKV枠を16GB単体に確保するなら、キャッシュ量子化を効かせるのが直接の解になります（確保VRAMの実測であり、長文投入時の生成速度・品質は本記事では未評価）。

# 環境変数は「Ollamaサーバーの起動時」に効かせる必要がある
# （設定方法はOS/導入形態で異なる: Windowsはシステム環境変数に設定して
#   Ollamaを再起動、macOSアプリ/Linux systemdは公式FAQの手順。
#   以下はLinuxでserveを手動起動する例）
OLLAMA_FLASH_ATTENTION=1 OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

# コンテキスト長を用途に足りる最小へ（ollama run の対話中に変更する例）
/set parameter num_ctx 8192

ソフト側の導入手順そのものは、姉妹サイトのローカルLLM入門（Ollama × Gemma 4）で解説しています。ハード側の見積もりと合わせて読むと、環境構築の全体像がつかめます。

重みを削るか、コンテキストを削るか

3つのレバーは「どこを我慢するか」の選択でもあります。重みの量子化を強めれば大きいモデルを載せられますが品質は下がりうる。num_ctx を絞れば安全ですが扱える文書長が短くなる。KVキャッシュ量子化はキャッシュ側を狙い撃ちで圧縮できるので、長文を扱いたいときに効きやすい選択肢です。

KVキャッシュ量子化とCPUオフロードの効き方

KVキャッシュ量子化は、コンテキスト長を伸ばしたいのに残枠が足りない場面で効きます。FP16のキャッシュをq8_0にすれば、同じVRAMでおおむね倍のトークンを保持できる計算。実測でも qwen3:14b の32Kが FP16 の13.39GiBから q8_0 で11.08GiB、q4_0で9.83GiBまで下がりました。ただし、あふれた分をCPUへ逃がすオフロードは速度低下と引き換えです。前掲の40K・FP16は搭載率89.9%まで落ちてCPUへオフロードが発生しており、「収まらないから逃がす」より「収まるように削る」ほうが速度維持には有利と考えられます（KVオフロード時・KV量子化時の実生成速度は本記事では未測定）。

16GBで足りないとき｜上位VRAM帯か、2枚目でオフロードか

削り切ってもなお足りない。そうなったときの選択肢は2つの方向に分かれます。

ひとつは上位のVRAM帯へ移ること。ここで押さえておきたいのは、上のクラスに行って変わるものの中身が用途で違う点です。LLM単体なら、より大きいVRAMで主に変わるのは「速度」（あふれずにGPU完結で回せるかどうか）。一方でComfyUIのような画像・動画生成では、VRAMが増えると「できること」自体が広がる傾向があります。噂される上位SKUの具体的な容量やスペックは公式発表がなく、本記事では断定しません。

もうひとつが、2枚目のGPUを足してVRAMを実質的に増やす方向。前述の通り、当サイトではあふれ状態を2枚目で解消して約1.9倍の速度回復を確認しています。デュアルGPU構成の実測は別記事で扱っているので、単体16GBの壁を越えたい場合の現実的な選択肢として検討する価値はあります。長文を常駐で回すブラウザエージェント的な使い方など、コンテキストを保持し続けるタスクほどVRAMの圧迫は効いてくるので、早めに方針を決めておくと後戻りが減ります。

まとめ

16GB級でローカルLLMに長文を扱わせるとき、鍵になるのは「重みで埋まった残りがKVキャッシュの予算であり、それが実効コンテキスト長の上限を決める」という関係です。14B級なら残枠に余裕があり長文を伸ばしやすい。22〜26B級は重みでほぼ埋まり、27B以上のdense型は量子化しだい——通常のQ4級では16GB単体に載り切らないことが多い一方、QAT版int4のように攻めれば載る例もあります（この帯は本記事では未実測の見積もり）。あふれればCPUへ退避して速度が落ちる。

回避の手は、重みの量子化・num_ctx を用途に足りる最小へ・KVキャッシュ量子化（q8_0で約半分、q4_0で約4分の1）の3つ。なお量子化形式はモデルタグごとに異なるため、手元のモデルは ollama show かモデルページで確認してください。実測でも、qwen3:14b の40Kは FP16 ではあふれる一方、q8_0で11.78GiB・q4_0で10.22GiBと16GBに全載せへ戻せました。gemma4:12b のようにそもそも長文でKVがほとんど増えないモデルを選ぶ手もあります。ここで挙げた実測値は特定バージョン（Ollama 0.30.7、2026年7月4日測定）でのスナップショットです。測定時点での最新は v0.31.1〈2026-06-30公開〉で、0.30.7との間には0.30.8〜0.30.12系（RC/Pre-releaseを含む）の複数版があります（本測定はやや前の版を使用）。新しい版では確保VRAMが変わりうる点にご注意ください。各点は単発測定で、量子化による品質への影響は本記事では未評価です。本記事の数値は ollama ps の確保VRAMを中心に見たスナップショットであり、実際の長文プロンプト投入時の prefill 速度・生成速度・品質・context shift の挙動までは評価していません。まず自分がどれくらいの長さの文書を、どのモデルで扱いたいかを決め、上の表で膨張と重みの占有を確認したうえで、残枠に合わせて num_ctx とKVキャッシュ量子化を詰めてみてください。

よくある質問

Q. 16GBのGPUで長文を扱うのは無理ですか？

無理ではありません。実測では qwen3:14b が FP16 キャッシュのまま32K（13.39GiB）まで16GBに全載せでき、num_ctx を用途に足りる最小へ絞り、KVキャッシュ量子化（q8_0）を併用すればモデル上限の40Kでも11.78GiBで全載せに収まりました。既定の4kより長いコンテキストは十分現実的です。22B級以上は重みで枠を使い切るため、長文を狙うなら軽いモデルを選ぶのが近道になります。

Q. num_ctx はどこまで上げていいですか？

上限は「重みを載せた残りのVRAMにKVキャッシュが収まる範囲」です。数値はモデル構造で変わるため一律には言えません。大きく設定するほどKVキャッシュのVRAMが増えるので、実際に扱う文書長に合わせて段階的に上げ、あふれない値を探るのが確実です。

Q. KVキャッシュ量子化で品質は落ちますか？

KVキャッシュ部分の削減効果は算術的にはっきりしていて、q8_0でFP16比約半分、q4_0で約4分の1です。実測でも qwen3:14b の32Kが FP16 の13.39GiBから q8_0で11.08GiB、q4_0で9.83GiBへ下がりました。一方、出力品質への影響は本記事では未評価で、タスクによって感じ方が変わります。まずq8_0から試し、問題が出なければq4_0を検討する、という順で確かめるのが安全です。

Q. qwen3:14b を16GBで長文（40K）に使いたいのですが、どう設定すればあふれませんか？

実測では、FP16のままモデル上限の40K（正確には40960、Ollamaが上限にクランプ）を要求すると必要合計が15.25GiBに達し、GPU搭載率89.9%でCPUへあふれました。KVキャッシュ量子化を OLLAMA_KV_CACHE_TYPE=q8_0 に切り替えると同じ40Kが11.78GiBで全載せに戻り、q4_0なら10.22GiBまで下がります。40Kを狙うならq8_0以上を効かせるのが実測に基づく回答です。なお32Kまでで足りるなら、FP16のままでも13.39GiBで全載せできます。

Q. VRAMがあふれるとどうなりますか？

収まらない分がシステムRAM側（CPU）へ退避され、その処理がGPU完結でなくなって生成速度が落ちます。当サイトの実測では、重みがあふれた状態から全量をVRAMに収めることで約1.9倍まで速度が回復しました。あふれを避けること自体が、速度を保つうえで最も直接的な対策です（この1.9倍は重みオフロード解消の実測で、KVあふれ時の速度は未測定）。

参考資料

• Ollama 公式ドキュメント: Context Length（既定コンテキスト長とVRAMの関係）
• NVIDIA 公式: GeForce RTX 5080 – 仕様
• NVIDIA 公式: GeForce RTX 5060 ファミリー – 仕様
• Qwen3-14B – Model Card（Hugging Face）
• Codestral 22B – Model Card（Hugging Face）
• Google 公式: Gemma ドキュメント

当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。