OllamaのKVキャッシュをq8_0・q4_0へ量子化｜12GB GPUでVRAMを実測

Ollamaで長い文書を扱うためにnum_ctxを大きくすると、モデル本体はGPUへ収まっているのにVRAMが足りなくなることがあります。

このとき軽くできるのが、AIが会話中に使う「作業メモ」に当たるKVキャッシュです。

先に結論を言うと、VRAMが足りないときはまずq8_0、それでも足りない場合だけq4_0を自分の文書で再テストする順番が無難です。

RTX 4070 Ti 12GB、64Kコンテキスト、Qwen3.5 9Bで3回ずつ測った結果は次のとおりでした。

ルミィ

難しい名前ですが、見るポイントは「AIの作業メモを軽くして、VRAMに少し余裕を作る設定」です。まずは軽めのq8_0から試せば大丈夫です。

動画で実測の流れを見る

約7分で結果と設定を確認できます

YouTubeで動画を開く

KVキャッシュとは、AIが会話中に使う作業メモ

難しい名前ですが、役割はシンプルです。

• モデル本体：AIの知識が入った参考書
• KVキャッシュ：今読んでいる文章や会話を処理するための作業メモ
• コンテキスト長：作業メモをどこまで広く用意するかという上限

長い文書や長い会話を扱うには、大きな作業メモが必要です。そのためnum_ctxやOLLAMA_CONTEXT_LENGTHを大きくすると、KVキャッシュ用のVRAMも増えます。

モデル本体のQ4と、KVキャッシュのq4_0は別物

ここが最も紛らわしい点です。

Ollamaのモデル名に付くQ4_K_Mは、参考書に当たるモデル本体を軽くする設定です。

この記事で扱うq4_0は、会話中の作業メモに当たるKVキャッシュを軽くする設定です。

「モデル本体がQ4だから、KVキャッシュも自動でq4_0になる」という意味ではありません。

ルミィ

モデル本体は「参考書」、KVキャッシュは「作業メモ」です。どちらにもQ4という名前がありますが、軽くしている場所が違います。

モデル本体のQ4とQ8を比較した結果は、ローカルLLMのQ4とQ8を実機比較で別にまとめています。

実測条件

実入力は約4.7万トークンですが、Ollamaは入力を読む前に64K設定へ合わせた領域を確保しました。そのため、今回のVRAM比較で効いているのは実入力の長さではなく、設定したコンテキスト上限です。

実測結果：q8_0で736MiB、q4_0で1,248MiB減った

比較に使ったのは、Ollamaの/api/psが返すsize_vramです。

これはモデル本体、KVキャッシュ、計算用バッファなどを含むOllamaの読込後VRAM値です。GPUカード全体の使用量や、nvidia-smiが表示する瞬間的な最大値とは同じではありません。

この条件では、q8_0で約0.7GB、q4_0で約1.2GB分のOllama読込後VRAMを減らせました。

なぜVRAM全体は半分・4分の1にならないのか

公式説明どおり、KVキャッシュ部分は大きく減りました。

KVバッファだけを見ると、q8_0はf16の約53％、q4_0は約28％です。公式の「約半分・約4分の1」に近い結果でした。

ただし、モデル本体4,717.38MiBは変わりません。さらに今回の条件では、量子化した2条件の主computeバッファがf16より224.26MiB増えました。

• q8_0：KVを960MiB削減 − compute増加224MiB ＝ 正味約736MiB削減
• q4_0：KVを1,472MiB削減 − compute増加224MiB ＝ 正味約1,248MiB削減

この224MiBは、今回のOllama 0.32.14、モデル、設定で観測した差です。KV量子化では常に224MiB増える、という固定費ではありません。

WindowsでKVキャッシュをq8_0・q4_0へ変更する方法

Ollama公式では、KVキャッシュ量子化を使うにはFlash Attentionが有効である必要があります。対応するバックエンドとGPUでは自動利用されますが、今回は条件を固定するためOLLAMA_FLASH_ATTENTION=1を明示しました。

ルミィ

設定は環境変数を2つ追加して、Ollamaを再起動するだけです。変更後はログまで確認すると、設定できたつもりの事故を防げます。

画面から設定する

1. タスクバーのOllamaを終了する
2. Windowsで「環境変数」と検索する
3. 「環境変数を編集」を開く
4. ユーザー環境変数へOLLAMA_FLASH_ATTENTIONを追加し、値を1にする
5. ユーザー環境変数へOLLAMA_KV_CACHE_TYPEを追加する
6. 最初は値をq8_0にする
7. 保存後、スタートメニューからOllamaを起動する

q4_0を試す場合は、OLLAMA_KV_CACHE_TYPEの値だけをq4_0へ変更し、Ollamaを再起動します。

PowerShellでユーザー環境変数を設定する

軽めの圧縮であるq8_0を設定する例です。

[Environment]::SetEnvironmentVariable(
  "OLLAMA_FLASH_ATTENTION", "1", "User"
)
[Environment]::SetEnvironmentVariable(
  "OLLAMA_KV_CACHE_TYPE", "q8_0", "User"
)

強めの圧縮へ変える場合は、2つ目の値をq4_0へ変えます。

[Environment]::SetEnvironmentVariable(
  "OLLAMA_KV_CACHE_TYPE", "q4_0", "User"
)

設定後は、起動中のOllamaを一度終了して再起動してください。環境変数を保存しただけでは、すでに動いているOllamaへ反映されません。

標準のf16へ戻すなら、値をf16へ変更するか、ユーザー環境変数を削除してOllamaを再起動します。

設定が反映されたか確認する

ollama psで確認できること

モデルを一度実行してから、次を使います。

ollama ps

SIZE、CPU/GPU配置を示すPROCESSOR、CONTEXTを確認できます。PROCESSORが100% GPUなら、モデルはすべてGPUへ読み込まれています。

ただし、ollama psにはKVキャッシュ型やFlash Attentionの状態は表示されません。

/api/psで読込後VRAM値を見る

(Invoke-RestMethod http://localhost:11434/api/ps).models |
  Select-Object name, size_vram, context_length

size_vramがOllamaの読込後VRAM値、context_lengthが現在のコンテキスト設定です。

server.logでKV型を確認する

Windows版Ollamaの最新サーバーログは、通常%LOCALAPPDATA%\Ollama\server.logにあります。

Select-String `
  -Path "$env:LOCALAPPDATA\Ollama\server.log" `
  -Pattern "cache-type-k|cache-type-v|flash_attn" |
  Select-Object -Last 20

実際に起動したrunnerのK・V型がq8_0またはq4_0になっているか、Flash Attentionが有効かを確認します。

速度は大きく変わったか

量子化した2条件は3回とも、入力処理がf16より少し遅い方向、生成は少し速い方向でした。

ただし1モデル、各3回、生成51トークンだけの小規模測定です。速度差の統計的な有意性は調べておらず、「q8_0やq4_0の方が速い」と一般化はできません。

回答品質は変わったか

約4.7万トークンの文書から5つの事実を探す質問は、全9回で各回5/5でした。9件の回答全文も完全に一致しました。

一方、文書内の417と27を足す質問は、正解444に対して全9回で484と回答しました。文書には444や484を含む似た管理番号が複数あり、単純な計算ミスなのか、文書中の数字に影響されたのかは特定できません。

この結果は「今回の6問では設定差を検出できなかった」ことを示します。q4_0とf16の品質が同じだと証明したわけではありません。

f16・q8_0・q4_0の選び方

f16を選ぶ人

• VRAMに十分な余裕がある
• 長い文書での品質を優先したい
• まず標準条件を基準として残したい

q8_0を選ぶ人

• 長いコンテキストでVRAMが少し足りない
• まず小さい品質リスクで軽くしたい
• どちらを選ぶか迷っている

q4_0を選ぶ人

• q8_0でもVRAMが足りない
• より長いコンテキストや他のGPU処理へ余地を残したい
• 自分の長文、要約、集計で品質を比較できる

ルミィ

迷ったらf16で基準を取り、足りなければq8_0、まだ足りなければq4_0の順です。設定を軽くするたびに、普段使う文書で答えを比べてください。

自分の環境で確認する3ステップ

1. 実際に使う長文を1つ決める
2. f16、q8_0、必要ならq4_0の順に同じ質問をする
3. 事実の再現、前後を組み合わせる質問、集計、要約を比較する

短い質問だけでは、長いコンテキストで起きる品質差を見つけにくい場合があります。Ollama公式も、モデルの構造やコンテキストの長さによって精度への影響が変わり得ると説明しています。

今回の実験は64Kより先や、12GB GPUで動く最大コンテキストを測っていません。空いた1.2GBで何Kまで増やせるかは、モデルや並列数などにも左右されるため断定できません。

コンテキスト長そのものの選び方は、Qwen3.5 9Bを4K・8K・32K・64Kで実機検証で確認できます。

検証データを確認する

記事で使った集計結果、実測条件、出典台帳は、Ollama KVキャッシュ量子化の検証データとしてまとめています。数値を再確認したい場合や、自分の環境と比較したい場合に利用してください。

ZIPには集計済みのJSON・Markdown、実測条件、公式資料との対応表を収録しています。実在する会社資料や個人情報は含まれていません。

うまく反映されないときの確認項目

• Ollamaを終了してから再起動したか
• OLLAMA_FLASH_ATTENTIONが1になっているか
• OLLAMA_KV_CACHE_TYPEの綴りと値が正しいか
• q8_0やq4_0のアンダースコアを落としていないか
• ollama psのCONTEXTが想定値か
• server.logのK・V型が要求した値か
• 使っているモデルとバックエンドがFlash Attentionに対応しているか

VRAM容量からモデルを選びたい場合は、ローカルLLMの必要スペック｜VRAM 8GB・12GB・16GBの目安も参考になります。

KVキャッシュ以外の原因も含めて切り分ける場合は、Ollamaが遅い・GPUを使わないときの確認手順を参照してください。

よくある質問

KVキャッシュをq4_0にするとVRAM全体が4分の1になりますか？

なりません。約4分の1になるのはKVキャッシュ部分の目安です。今回、Ollamaの読込後VRAM値全体はf16比で17.3％減りました。

q8_0とq4_0はどちらを選べばよいですか？

迷ったらq8_0から試します。公式もf16以外ではq8_0を推奨しており、q4_0はより大きく軽くできる一方、長いコンテキストで精度への影響が目立つ可能性があります。

モデル名のQ4_K_MとKVキャッシュのq4_0は同じですか？

別です。Q4_K_Mはモデル本体、q4_0は会話中のKVキャッシュを量子化します。片方を選んでも、もう片方が自動的に同じ設定になるわけではありません。

設定が反映されたか、ollama psだけで分かりますか？

分かりません。ollama psではSIZE、PROCESSOR、CONTEXTを確認できますが、KVキャッシュ型とFlash Attentionは表示されません。Windowsではserver.logも確認します。

q4_0なら12GB GPUで128Kを使えますか？

この記事の実測だけでは言えません。64Kより先と最大境界は測っておらず、必要VRAMはモデル、コンテキスト長、並列数、バックエンドなどで変わります。

まとめ

• KVキャッシュは、AIが会話中に使う作業メモ
• モデル本体のQ4と、KVキャッシュのq4_0は別設定
• 64K設定ではq8_0で736MiB、q4_0で1,248MiB減った
• 半分・4分の1になるのはKV部分の目安で、VRAM全体ではない
• 迷ったらf16→q8_0→q4_0の順で、自分の長文を使って確認する
• ollama psだけではKV型を確認できず、最終確認はログで行う

Ollamaを初めて使う方は、LM StudioとOllamaの違いとOllamaでGemmaを動かす手順もあわせてどうぞ。

参考資料

• Ollama FAQ v0.32.14
• Ollama Windows
• Ollama Troubleshooting
• Ollama Running models API

この記事は2026年8月21日時点のOllama 0.32.14と、手元のRTX 4070 Ti 12GB環境で確認した内容です。バージョン、モデル、GPU、コンテキスト長によって結果は変わります。