VRAM 16GBでローカルLLMのコンテキスト長はどこまで伸ばせるか｜KVキャッシュ量子化の実測

GPU・グラフィックボード

長文入力でつまずくとき、モデル本体とは別に、コンテキスト側のKVキャッシュがVRAMを食い尽くしているのが主因になっていることがある。前回、VRAM 16GBのGPUでGemma 4 12Bを動かす記事を書いた。モデル本体さえ16GBに収まれば、筆者環境では対話に使える速度で動いた——そこまでは比較的たどり着きやすい。ところが、実際に長い文章を丸ごと要約させたり、ソースコードをファイル単位で貼り付けたり、RAGで大量の参照文書を渡したりすると、急に生成が遅くなったり、モデルが落ちたりする場面に出くわす。

コンテキストを伸ばすと、重みとは別にVRAMを消費する領域（KVキャッシュ）が膨らみ、16GBの枠をあっさり超えてしまう。ここで問われるのは、結局「16GBで、どれくらいの長さの入力まで快適に扱えるのか」という一点だ。本記事では、コンテキスト長を伸ばすとVRAMがどれだけ増えるのか、どこで壁にぶつかるのか、そしてKVキャッシュ量子化でその壁をどこまで後ろにずらせるのかを、16GB級GPU（検証機は前回と同じ RTX 5080 と RTX 5060 Ti）で実測する。なお本記事でいう「快適」は、コンテキストがGPU内に収まり生成速度が大きく落ちない状態を指す。要約や理解の精度といった出力品質、そして各num_ctxいっぱいの長大入力を流したときのプリフィル時間は、今回の測定対象外だ。測ったのは短い同一入力でnum_ctxを確保したときのVRAMと生成部の速度である。

コンテキスト長を伸ばすとVRAMが増えるのはなぜか

LLMが文章を生成するとき、それまでに読んだトークン（単語の断片）ごとに「キー」と「バリュー」と呼ばれる中間データを保持し続ける。これがKVキャッシュだ。次のトークンを予測するたびに過去の全トークンを計算し直すのは無駄なので、一度計算したキーとバリューをVRAMに貯めておき、使い回す。おかげで生成は速くなるが、その代償として、コンテキストが長くなるほどKVキャッシュは大きくなる。

KVキャッシュの大きさは、おおまかに「層の数 × KVヘッドの数（GQAではアテンションヘッドより少ない）× 1ヘッドの次元 × トークン数 × 2（キーとバリュー）× 1要素あたりのバイト数」で決まる。トークン数以外はモデルごとに固定なので、KVキャッシュはコンテキスト長にほぼ比例して増える。たとえば本記事の主役に据えたllama3.1:8b（8B、32層・KVヘッド8・ヘッド次元128。Meta／Hugging Faceのモデル設定ファイルで確認）の場合、標準精度（FP16）では1トークンあたり理論上およそ128KiBを消費する。1万トークンで約1.3GB、10万トークンなら約13GBという計算だ。モデル本体が5GB前後でも、コンテキスト側だけでそれを上回る規模になり得る。

VRAMそのものの基礎はVRAMとは？AI用途で必要な容量の目安で、容量不足の症状はVRAM不足エラーの原因と解決法でそれぞれ扱った。ここで注意したいのは、世間でよく語られる「VRAM不足」の議論がモデル本体の大きさ（何Bのモデルが載るか）に偏りがちなのに対し、長文入力では先にコンテキスト側で詰まる場合があるという点だ。量子化の記事で扱った「重みの量子化」がモデル本体を小さくする手法なのに対し、本記事のKVキャッシュ量子化はコンテキスト側を小さくする手法で、両者は効く場所が違う。

実測①：コンテキスト長とVRAM消費の関係

まず、KVキャッシュを標準精度（FP16）のまま、コンテキスト長だけを変えて測った。測定の前に他の推論プロセスをすべて停止し、GPUを1枚に固定したうえで、Ollamaが報告する必要メモリとnvidia-smiの実測VRAMを毎回突き合わせている。複数の推論サーバが同じGPUを取り合うと数値が汚れるため、数値を比較する測定では推論サーバを1つに絞り、並列数を固定しておくと結果を読みやすい。主役のllama3.1:8b（4ビット量子化版、Q4_K_M。Ollamaのタグ表示は4.9GB、ロード時のGPU占有は約4.6GB）は、長いコンテキストを載せる余地が大きく、KVキャッシュの挙動を見るのに向いている。なお本記事のOllama実測はバージョン0.23.3での単回参考値である。その後の0.30系ではllama.cppの更新やGemma 4対応状況が変わっているため、設定や購入の判断は導入時点の最新版リリースノートで再確認してから行ってほしい。

再現性のため、測定条件を明記しておく。

  • GPU：RTX 5080 16GB（PCIe 5.0 x16）／ RTX 5060 Ti 16GB（Oculink PCIe 4.0 x4）、OSはWindows 11、NVIDIAドライバ 610.47、測定日 2026年6月4日
  • ランタイム：Ollama 0.23.3。llama3.1:8b は Q4_K_M（ダイジェスト先頭 46e0c10c）。Flash Attention 有効、num_parallel 1
  • 生成条件：num_predict 160、temperature 0.7、コンテキスト長は num_ctx で指定。短い同一プロンプトを投入し、num_ctx で確保したときのVRAMと生成部の速度を測っている。各 num_ctx いっぱいの長大な入力を実際に流したときのプリフィル時間や出力品質は別軸で、本記事の測定範囲外だ
  • 表中のGB表記は、各ツール（Ollama / nvidia-smi 等）の表示に合わせた概算値として扱う
  • 手順：測定ごとに別ポートの一時サーバを GPU 1枚に固定して起動し、各 num_ctx の前にモデルを keep_alive:0 でアンロード。生成直後に nvidia-smi（物理インデックス指定）で実VRAM、Ollama の API でモデルの占有メモリを取得して突き合わせた
  • 集計：各条件 1 回の測定値（複数回平均ではない代表値）。速度は生成部分の eval_count ÷ eval_duration から算出した。temperature 0.7・seed 未固定のため、速度は厳密な再現ベンチではなく、筆者環境での傾向を示す参考値として読んでほしい（より厳密に比べたい場合は seed 固定や複数回測定での確認を勧める）

以下はRTX 5080（16GB）での結果だ。表の「必要VRAM」はOllamaが報告する必要メモリ（モデル本体・KVキャッシュ・計算用バッファの合計、GB表記の推定値）で、nvidia-smiで生成直後に確認した実VRAMもほぼ同水準だった。この必要メモリが実際に使える枠を超えると、Ollamaがモデルの一部をシステムRAM側（CPU側）に置く（ollama ps のProcessor列や、Ollamaが報告するGPU占有メモリが必要メモリを下回ることで確認できる）ため、生成が一気に遅くなる。

コンテキスト長 必要VRAM（Ollama推定） 生成速度 検証機の空きVRAM内に収まるか
4,096 5.1GB 128 tok/s 収まる
16,384 7.4GB 128 tok/s 収まる
32,768 10.4GB 129 tok/s 収まる
49,152 13.4GB 124 tok/s 収まる
57,344 15.2GB 34 tok/s あふれる
65,536 16.7GB 26 tok/s あふれる
131,072 29.1GB 13 tok/s あふれる

（上表・以下の表とも、Ollama 0.23.3・Windows 11・NVIDIAドライバ 610.47、各条件1回の筆者環境での参考値。seed未固定のため、速度は厳密な再現ベンチではなく傾向として読んでほしい。数値は num_ctx を確保したときのメモリと短い入力での生成速度で、各コンテキストいっぱいの長文を流したときのプリフィル時間や品質は別軸となる。本記事の測定はOllama 0.23.3で行っており、その後の0.30系では挙動が変わる可能性がある。公開直前にも公式リリースを確認してほしい。）

本環境の単回参考値では、VRAM増加とCPU退避時の速度低下の傾向が明確に見えた。コンテキスト長が4Kから48Kまでは必要VRAMがきれいに比例して増え、生成速度は124〜129 tok/sで安定していた。ところが56K前後を境に必要VRAMが実際に使える枠を超え、速度が34 tok/s、さらに26 tok/sへと急落する。128Kに至っては必要VRAMが29.1GBに達し、半分以上がCPU側に退避して13 tok/s——GPU内で動いていたときの約10分の1まで落ちた。

ここで「16GBあるのに、なぜ15.2GBで早くもあふれるのか」という疑問が出る。理由は、メインで使うGPUはデスクトップ画面の描画にも使われ、検証機では常時2〜3GB前後がそちらに取られていたためだ。16GBのうち、モデルとコンテキストに実際に回せたのは13〜14GB程度だった（この値はヘッドレス運用や、表示を別GPUに任せる構成では変わる）。これがllama3.1:8bでFP16のまま使えるコンテキスト長の上限を、検証機ではおおよそ48K付近に押し下げていた。同じ16GBでもRTX 5080でモデルが起動しないという壁は、コンテキストを伸ばすと容量とは別の形で姿を現す。

実測②：KVキャッシュ量子化で壁を後ろにずらす

KVキャッシュは、重みと同じように精度を落として小さくできる。Ollamaでは環境変数 OLLAMA_KV_CACHE_TYPE でキャッシュの精度を指定でき、標準の f16 に対して q8_0（8ビット）と q4_0（4ビット）が選べる。Ollama公式の説明によれば、q8_0はf16の約2分の1のメモリ、q4_0は約4分の1のメモリになる。なお、KVキャッシュ量子化を有効にするにはFlash Attention（OLLAMA_FLASH_ATTENTION=1）を併せて有効にする必要がある。

同じllama3.1:8bで、4K〜128Kを3種類のキャッシュ精度で測り直した結果が次の表だ。生成速度はGPU内に収まっているときの値で、あふれた場合は急落した速度を載せている。

コンテキスト長 f16（必要VRAM／速度） q8_0 q4_0
4,096 5.1GB／128 tok/s 5.0GB／123 tok/s 4.8GB／141 tok/s
32,768 10.4GB／129 tok/s 8.4GB／143 tok/s 7.4GB／125 tok/s
65,536 16.7GB／26 tok/s（あふれる） 12.5GB／132 tok/s 10.5GB／124 tok/s
131,072 29.1GB／13 tok/s（あふれる） 21.1GB／16 tok/s（あふれる） 17.1GB／19 tok/s（あふれる）

注目すべきは64Kの行だ。FP16では必要VRAMが16.7GBに達してあふれ、26 tok/sまで落ちていたものが、q8_0にすると12.5GBに収まり、132 tok/sへ一気に回復した——速度にして約5倍だ。これはq8_0そのものが常に5倍速いという意味ではなく、必要VRAMがGPU内に収まってCPU退避を避けられたことによる差だ。キャッシュ精度を一段下げるだけで、64Kという長めのコンテキストがGPU内で完結するようになる。q4_0ではさらに10.5GBまで下がり、こちらも124 tok/sを保つ。実用上は、出力品質はいったん措くとして、速度とVRAMの観点でバランスの取れたq8_0が無理のない選択肢で、もう一段メモリを切り詰めたいときにq4_0を検討する、という順序になる。品質への影響はOllama公式によれば「モデルとタスクに依存する」とされ、グループ化アテンション（GQA）のグループ数が多いモデルほど精度低下が出やすいという。重要な用途では、同じ入力をf16・q8_0・q4_0で生成して見比べておくと安心だ。

一方で、正直に書いておかなければならないのは128Kの行だ。q4_0まで落としても必要VRAMは17.1GBで、16GBには収まらなかった。少なくとも本記事の検証機（Ollama 0.23.3・表示用VRAMを含む16GB）では、llama3.1:8bを num_ctx 128Kに設定すると、q4_0でもGPU内に収まらなかった。128Kを本気で使いたいなら、もっと軽いモデルに替えるか、コンテキストを実際に必要な長さまで割り切るか、あるいは次に挙げるアーキテクチャの違うモデルを選ぶことになる。なお、ここで測ったのは速度とVRAMという「測れる軸」であって、q4_0で出力品質がどの程度落ちるかは別の問題だ。品質は今回の測定範囲外で、Ollama公式が品質影響はモデルとタスク次第だと述べている点に留めておく。

壁の位置は「モデルとアーキテクチャ」で動く

ここまではllama3.1:8bという、すべての層が全コンテキストを見る素直な構造（フルアテンション）のモデルで測ってきた。だが、モデルによってKVキャッシュの増え方そのものが変わる。とりわけ前回の主役だったGemma 4 12Bは、まったく違う挙動を見せた。

Googleの公式モデルカードによれば、Gemma 4は近くのトークンだけを見る「局所的な注意（スライディングウィンドウ）」と、全体を見る「大域的な注意」を組み合わせた構造で、最後の層は大域的だとされる。局所層は決まった幅（小型モデルで512、大型で1024トークン。Gemma 4 12BはvLLMのレシピでもスライディングウィンドウ1024トークンとされる）しか見ないため、コンテキストを伸ばしても局所層のKVキャッシュは増えにくく、全体としてキャッシュが膨らみにくいと考えられる（Googleのモデルカードは中型以上で長大コンテキスト対応を案内するが、実際に指定できる上限は配布ファイルやランタイムで異なり、vLLMの12Bレシピでは max_position_embeddings が131072＝128Kとされる。本記事では128Kまでを筆者環境で測定した）。前回動かしたGemma 4 12Bを、コンテキスト長を変えながらVRAM消費を測ると、この差が数字に表れた（Gemma 4は検証機のOllama 0.23.3ではロードできなかったため、LM Studioで測定している。なお公開前に確認したところ、Ollamaはv0.30.3でgemma4-12bへの対応が追加された一方、0.30系ではGemma 4系や一部GGUFモデルの不具合報告も出ているため、Ollamaで動かす場合は利用時点の公式リリースノートとIssuesを確認してほしい）。

コンテキスト長 llama3.1:8b（FP16）の必要VRAM Gemma 4 12B の占有VRAM（LM Studio参考・条件不統一）
4,096 5.1GB 8.1GB
32,768 10.4GB 8.6GB
65,536 16.7GB（あふれる） 9.1GB
131,072 29.1GB（あふれる） 10.1GB

※Gemma 4 12Bは LM Studio（parallel 1）で gemma-4-12b-it（GGUF、Q4_K_M、7.38GB）をRTX 5080 16GB上にロードして占有VRAMを測った参考実測値（各コンテキスト1回測定、公式ベンチではない。このGemma 4の行は筆者環境の参考実測で、上のOllama測定表とはランタイム・量子化・測定手順がそろっておらず、同条件の比較ではない。LM Studioへ全層GPUオフロードでロードし各num_ctx設定後の占有VRAMを読んだ値で、LM Studioのバージョンや個別ファイルのハッシュは測定時に記録しておらず、再現ベンチではない）。Google公式が示す推論メモリの目安は、Gemma 4 12BでBF16（16ビット）26.7GB、SFP8（8ビット）13.4GB、Q4_0（4ビット）6.7GBの概算とされる。このSFP8は本記事で扱うOllamaのKVキャッシュ量子化q8_0とは別物で、表は主に静的な重みのぶん、長文時のKVキャッシュは別途増える。つまり未量子化のGemma 4 12Bは16GBには載らず、ここでは4ビット量子化版を前提にしている。

本記事のLM Studio・GGUF Q4_K_M・短い入力・各条件1回という参考条件では、Gemma 4 12Bはコンテキストを4Kから128Kへと32倍に伸ばしても、占有VRAMの増加は約2GBにとどまった。128Kでも合計10.1GBで、この条件では16GB内に収まっている。num_ctxを128Kに設定した状態での生成部の速度は72.9 tok/sで、4Kのときの73 tok/s（前回測定）とほとんど変わらない（これも短い入力での生成速度で、128Kトークンの長大入力を読み込むプリフィル時間や出力品質は未評価）。VRAMがあふれていないぶん、生成そのものは失速しないわけだ。llama3.1:8bが128Kで13 tok/sまで沈んだのと比べると対照的だ。ただし8Bのllama3.1と12BのGemma 4ではパラメータ数が違ううえ、ランタイム（OllamaとLM Studio）も量子化条件も異なるので、単純な同格比較ではない。大きく効いている要因の一つは、公式モデルカードが示すGemma 4のハイブリッドアテンション（局所＋大域）だと考えられるが、注意機構だけに切り分けた検証ではない。

つまり、長いコンテキストを多用するなら、モデルのパラメータ数や量子化だけでなく、注意機構の作りまで見て選ぶ価値がある。コードや長文を丸ごと読ませる用途、思考過程を長く吐く推論モデルのような出力でコンテキストを食う用途では、少なくとも本記事のLM Studio・Q4_K_M・RTX 5080という参考条件のかぎりで、Gemma 4のようなハイブリッドアテンション構成のモデルはVRAM増加が小さく、16GB環境で扱いやすかった。逆に、扱う文章が数千〜数万トークンに収まる用途なら、少なくとも速度とVRAMの範囲では、llama3.1:8bのような素直なモデルでも大きな低下は見られなかった（品質や長文のプリフィル、同時実行時の挙動は別途確認したい）。

RTX 5080 と RTX 5060 Ti（Oculink）で速度はどう違うか

検証機にはRTX 5080（PCIe 5.0 x16）に加え、Oculink（PCIe 4.0 x4）で外付けしたRTX 5060 Tiも載っている。どちらも16GBなので、コンテキスト長に対する「壁の位置」はほぼ同じになる（厳密には表示出力や空きVRAMの差で数GB分前後する）。違いが出るのは速度のほうだった。

llama3.1:8bがGPU内に収まっている範囲では、RTX 5080がおおむね125〜143 tok/s、RTX 5060 Tiが一貫して約80 tok/sだった。Oculinkの帯域が狭くても、生成中の計算はGPU内で完結するため、GPU内に収まっている範囲では5060 Ti＋Oculinkでも約80 tok/sを維持した（本記事のllama3.1:8bの生成部で、5080のおおむね6割前後）。ただしGPU自体もRTX 5080とは異なるため、この差はOculink帯域とカード性能差を分離したものではない。約80 tok/sは、筆者の短い対話用途では参考までに待ち時間が気になりにくい水準だった（体感評価であり、長いプリフィルや同時実行を伴う使い方では別途確認したほうがよい）。

差がはっきり出たのは、コンテキストがあふれてCPU側に退避したときだ。128Kでプロンプトを読み込む速度（プリフィル）を比べると、RTX 5080が326 tok/sだったのに対し、RTX 5060 Tiは99 tok/sと約3分の1まで落ちた。あふれた状態ではGPUとシステムRAMの間で大量のデータをやり取りするため、ここで帯域の狭いOculink接続が不利に働いていると考えられる。ただし今回は搭載GPU自体も異なるため、この低下分をOculinkの帯域だけに切り分けた検証ではない（同じGPUで接続だけを変えれば、純粋な帯域の影響を測れる）。本記事のRTX 5060 Ti＋Oculink構成では、コンテキストをGPU内に収めている限り快適で、あふれた局面で大きく低下した。Oculink特有の挙動はOculink接続のGPUがOllamaに認識されない原因でも触れたが、ここでも「いかにGPU内で完結させるか」が効いてくる。二枚目のカードに役割を分けて逃がす構成はデュアルGPUでローカルLLMを動かすで詳しく検証している。

VRAM 16GBでコンテキストをどこまで伸ばすか——速度とVRAMから見た目安

ここまでの実測（速度とVRAM、短い入力でnum_ctxを確保したときの値）をふまえると、16GB級GPUでの目安は次のように整理できる。品質・長文のプリフィル時間・同時実行は別軸で、ここには含まない。

  • 数千〜3万トークン程度：本記事と同程度の空きVRAM・num_parallel 1・llama3.1:8b（Q4_K_M）なら、FP16のままでも速度低下は見られなかった。設定をいじる必要はない。
  • 4万〜6万トークン：FP16では実効VRAMを超え始める。Flash AttentionとKVキャッシュ量子化（q8_0）を有効にすれば、64K前後でも生成部の速度は大きく落ちなかった（ただし64K分の長大入力を実際に読み込むプリフィル時間や品質は未評価）。
  • 10万トークン超：少なくとも本記事のllama3.1:8b（Q4_K_M）の条件では、量子化しても128Kは16GBに収まらなかった。KVヘッド数や注意機構はモデルで異なるため、Gemma 4のようにKVキャッシュが膨らみにくいモデルを選ぶか、より軽量なモデルに替えるのが現実的。

設定自体は難しくない。Flash AttentionとKVキャッシュ精度を環境変数で指定し、Ollamaを立ち上げ直すだけだ。Ollama公式が案内する設定方法はOSごとに違う（バージョンで仕様が変わることがあるため、導入時に公式の最新情報も確認してほしい）。

  • Windows：タスクバーのOllamaを終了し、「環境変数を編集」から OLLAMA_FLASH_ATTENTION=1 と OLLAMA_KV_CACHE_TYPE=q8_0 をユーザー環境変数に追加して、スタートメニューからOllamaを再起動する
  • macOS：launchctl setenv OLLAMA_FLASH_ATTENTION 1 と launchctl setenv OLLAMA_KV_CACHE_TYPE q8_0 を実行してからOllamaアプリを再起動する
  • Linux：systemctl edit ollama.service で [Service] に Environment="OLLAMA_FLASH_ATTENTION=1" と Environment="OLLAMA_KV_CACHE_TYPE=q8_0" を追記し、systemctl daemon-reload と systemctl restart ollama を実行する

OLLAMA_KV_CACHE_TYPE は現時点ではOllamaサーバ全体に効くグローバル設定で、同じサーバ上の他のモデルにも同じキャッシュ精度が適用される点には注意したい（モデルごとに変えたい場合はサーバの起動を分ける）。最新のOllamaにはVRAMに応じた既定のコンテキスト長があり、16GB級では既定が短め（4K程度）になることもある。長文用途では、リクエストごとに num_ctx（またはサーバ全体に効く OLLAMA_CONTEXT_LENGTH）で必要な長さを指定し、ollama ps の CONTEXT と PROCESSOR でGPU内に収まっているかを確認するとよい。コンテキストは長く取るほどVRAMを食うので、「とりあえず最大」ではなく「使う分だけ」確保するのが、16GBを活かすいちばんのコツだ（十分なVRAMがある環境ではOllama公式は最大コンテキスト長の利用も案内しているが、16GBでCPU退避を避けるには必要な長さだけ確保するのが安全だ）。

なお、機密性の高いコードや個人情報を扱うなら、動かしているのがローカルモデルか、クラウド経由のモデルかを確認しておきたい。Ollamaにはクラウドモデルやweb検索の機能もあり、ローカルモデルならプロンプトは手元で処理される一方、クラウドモデルではサービス提供のためにプロンプトと応答が処理される。社外秘の情報を渡すならローカルモデルを使い、必要に応じてクラウド機能やweb検索を無効にすると、Ollamaのクラウドへ送られるリスクを下げられる（公式FAQでは OLLAMA_NO_CLOUD=1 などでの無効化が案内されている）。ただし、Ollamaをネットワークに公開していないか、連携アプリやログに内容が残らないか、社内規程に沿っているかは別途確認したい。ローカルで動かすこと自体の始め方はOllamaの入門記事、そもそもローカルLLMの仕組みから知りたい場合はローカルLLMとはを参照してほしい。

どのGPUを選ぶか

コンテキスト長の観点で言えば、上限を左右する最大の要因はVRAM容量だ。同じ世代なら容量の大きいカードほど、長いコンテキストをGPU内に収められる。ただし実際の上限は、モデル本体の量子化、KVキャッシュ精度、注意機構、同時リクエスト数、表示用に取られるVRAMなどでも動く。今回の16GB級では、llama3.1:8bでFP16なら5万トークン弱、q8_0で6万トークン台が一つの目安だった。

検証に使ったRTX 5080とRTX 5060 Tiは、どちらも16GBを積む。生成速度を重視するならRTX 5080、購入時点でRTX 5060 Ti 16GBの方が安ければ、価格を抑えつつ16GBを確保したいときや外付けで二枚目として足したいときの候補になる。ただしRTX 5060 Tiには8GB版と16GB版があるため、ローカルLLM目的なら型番で16GB版を確認したい。外付けで使う場合は、Oculinkケースや電源・冷却・保証条件も事前に確認しておくとよい。同じ16GBでも価格帯の異なるこの二枚の位置づけはRTX 4070 Super vs RTX 5060 Ti 16GBでも比較した。実売価格は時期で変わるため、購入時点の価格と保証条件を確認してほしい。

※以下にはAmazonアソシエイトのリンクを含みます。

まとめ

コンテキスト長を伸ばすとKVキャッシュがほぼ比例してVRAMを食い、16GBのGPUでは思ったより早く壁に当たる。検証機のllama3.1:8bでは、FP16のまま快適に使えたのは実効的に48K前後までで、それを超えるとCPU側への退避で速度が10分の1近くまで落ちた。KVキャッシュ量子化（q8_0）を使えば、Ollama公式の説明どおりKVキャッシュ部分をf16比で約半分に抑えられ（モデル本体やバッファを含む総VRAMが半分になるわけではない）、本記事の測定では、短い入力・num_ctx確保の条件で64K前後でも生成部の速度は大きく落ちなかった（64K分の長大入力のプリフィル時間や品質は未評価で、q8_0の品質影響もモデル・タスク次第とされる）。ただしllama3.1:8bのようにKVキャッシュがコンテキスト長に大きく比例する構成では、128K級は量子化しても検証機の16GBには載らなかった。128K級を狙うなら、本記事の参考条件でVRAM増加が小さかったGemma 4 12Bのようなハイブリッド注意機構のモデルを候補にするか、コンテキストを実際に必要な長さまで削るのが現実的だ（ランタイムや量子化条件で挙動は変わる）。16GBで長文を扱うなら、速度とVRAMを優先する用途では品質を同じ入力で確かめたうえで「Flash Attention + q8_0」を基本候補にしつつ、コンテキストは必要な分だけ取る——この二点を押さえておきたい。なお本記事のOllama測定は0.23.3での単回参考値で、最新の0.30系ではllama.cppの更新などにより速度や必要VRAMが変わる可能性がある。

よくある質問

KVキャッシュ量子化で生成は遅くなりませんか？

GPU内に収まっている範囲では、むしろ速くなる場合がある。今回の測定でも、q8_0やq4_0はf16と同等かやや速い結果だった。ただし速度差はモデルやGPU、Ollamaのバージョン、Flash Attentionの実装に左右されるため、量子化そのものが常に高速化するとは限らない。今回の測定で大幅な速度低下が出た条件では、主因はKV量子化そのものではなく、必要メモリがVRAMを超えてCPU側に分割ロードされたことだった。

q8_0とq4_0、どちらを使うべきですか？

まずf16とq8_0を同じ入力で見比べて、品質差が許容できればq8_0を使うのが無難だ。f16の約半分のメモリで済む。品質への影響はOllama公式によればモデルとタスクに依存し、GQAのグループ数が多いモデルほど精度低下が出やすいとされる。q4_0はさらにメモリを節約できるが、その分だけ品質低下のリスクも上がるため、メモリがどうしても足りないときの選択肢と考えるとよい。出力品質そのものは今回の測定対象外なので、重要な用途ではf16・q8_0・q4_0を同じ入力で見比べてから決めてほしい。

コンテキスト長を最大にしておけば安心ではないですか？

逆効果になりやすい。コンテキストは設定した長さ分のKVキャッシュ領域を確保するため、最大にすると使っていなくてもVRAMを大きく取られ、壁に当たりやすくなる。実際に渡す文章の長さに合わせて指定するのが、16GBを無駄なく使うコツだ。ただしこれはCPU退避を避けたい16GB級での話で、VRAMに十分な余裕がありあふれない環境なら、Ollama公式が案内するように最大コンテキスト長を使う選択もある。

システムRAMが多ければコンテキスト不足は補えますか？

容量としては補えるが、速度は犠牲になりやすい。必要メモリがVRAMを超えると、Ollamaではモデルが CPU と GPU に分割してロードされることがあり（ollama ps のPROCESSOR列で確認できる）、この状態では今回のように生成速度が数分の1から10分の1まで落ちる。システムRAMは「とりあえず落ちずに動かす」助けになる場合はあるが、速度を取り戻す手段ではない。快適さを求めるなら、コンテキストをGPU内に収める設計が前提になる。

参考資料

タイトルとURLをコピーしました