ローカルLLMの量子化はどれを選ぶか｜Q4_K_M・Q8_0・FP16のVRAMと速度を実測比較

Ollama でモデルを探していると、同じモデル名でもタグがいくつも並んでいることに気づく。たとえば llama3.2:3b を引こうとすると、3b-instruct-q4_K_M や 3b-instruct-q8_0、3b-instruct-fp16 といった具合に、末尾の量子化タグだけが違う候補が出てくる。とりあえず ollama run llama3.2:3b で動きはするものの、「このタグの違いは何なのか」「自分の VRAM だとどれを選ぶのが正解なのか」が分からないまま使っている人は多いと思う。

結論から言うと、量子化タグの違いはモデルの重みをどれくらい粗く丸めるかの違いで、これが「モデルファイルのサイズ」「ロード時に消費する VRAM」「生成速度」「出力品質」の全部にきいてくる。そしてこの 4 つはトレードオフの関係にある。以下では、VRAM 16GB 級のグラフィックボード（例として RTX 5080 16GB）で llama3.2:3b を Q4_K_M・Q8_0・FP16 の 3 段階で実際にロードし、VRAM の増加量と生成速度を測った結果を出していく。さらに 8B クラスの qwen3:8b でも測り、「16GB だとどこまで上の量子化を狙えるのか」の感覚をつかめるようにした。

先に結論

• 迷ったら Q4_K_M を選んでおけば、まず外さない。サイズ・速度・品質のバランスが良く、試しやすい出発点になる。今回扱う llama3.2:3b と qwen3:8b では、Ollama 公式ページ上でタグ省略時（latest）の既定が Q4_K_M に対応している。ほかのモデルでは既定タグが異なる場合があるため、ライブラリのタグ一覧または ollama show で確認してほしい。品質が業務上重要な用途では、後述のとおり同一プロンプトで Q5_K_M / Q6_K / Q8_0 も比較してから決めるのが安全だ。
• VRAM に余裕があり、数値指標の上で品質をもう一段詰めたいなら Q8_0。ただし実測では VRAM 消費が Q4_K_M の約 1.4 倍、生成速度は 6〜7 割に落ちた。llama.cpp の Perplexity 比較では Q4_K_M→Q8_0 の差は小さい傾向があるが、本記事では人手評価は行っていない。
• FP16（無量子化）は、今回の速度・VRAM 実測では Q4_K_M より大きなメモリを使い、生成速度も大きく下がった。3B でも VRAM を 2 倍以上（約 2.4 倍）食い、速度は Q4_K_M の 4 割まで落ちる。本記事では品質比較を行っていないため、そのコストに見合う改善があるかは用途別に確認が必要だ。なお 8B の FP16 はタグサイズだけで約 16GB に達し、KV キャッシュや実行バッファを加えると 16GB カードには通常収まらない。
• 数値は RTX 5080 16GB・Ollama 0.23.3・num_ctx=4096 での結果で、モデル・バージョン・コンテキスト長で変わり得る。考え方は流用できるが、絶対値はご自身の環境で測り直してほしい。

このあと、なぜそうなるのかを順番に見ていく。前提となる用語（VRAM とは何か、Ollama とは何か）に不安があれば、VRAMとは？AI用途で必要な容量の目安とOllamaとは？ローカルLLMを動かす第一歩を先に読んでおくと話が早い。そもそもローカル LLM をなぜ動かすのかという全体像はローカルLLMとは？自分のPCでAIを動かす仕組みでまとめている。

量子化とは：重みを粗く丸めてサイズを縮める仕組み

LLM の中身は、ものすごい数の「重み」と呼ばれる数値の集まりだ。学習が終わった直後のモデルは、ひとつひとつの重みを 16 ビット（FP16 / BF16）や 32 ビットの浮動小数点で持っている。3B モデルなら 30 億個、8B なら 80 億個といったオーダーの重みがあるので、16 ビット（＝2 バイト）で持つだけでも 3B で約 6GB、8B で約 16GB になる。

量子化（quantization）は、この重みをもっと少ないビット数で表現し直してファイルを縮める処理だ。たとえば 4 ビットまで落とせば、単純計算で 16 ビットの 4 分の 1 のサイズになる。重みの精度を落とすぶん、出力品質に影響が出る可能性はあるが、その大きさはモデル・用途・量子化方式によって変わる。Q4_K_M のような 4 ビット級は、現代の量子化手法で誤差を抑える工夫がされており、VRAM と速度を抑えながら品質側も比較したいときの実用的な出発点として広く使われている。

ローカルで LLM を動かすうえで量子化が重要になるのは、VRAM が有限だからに尽きる。クラウドの API なら裏側のデータセンターが巨大なメモリを積んでいるが、手元のグラフィックボードは 16GB なら 16GB しかない。量子化でモデルを縮めれば、本来は載らないサイズのモデルが載るようになり、同じモデルでもより長いコンテキストを扱えるようになる。逆に言えば、量子化レベルの選択は「VRAM の予算をどう使うか」という配分の問題でもある。なお Ollama は llama.cpp 系で広く使われる GGUF 形式のモデルを取り込んで実行でき、今回扱う Q4_K_M や Q8_0 といった表記も、その GGUF の量子化タイプに基づいている。

GGUF の主な量子化レベル一覧

Ollama や LM Studio で配布されているモデルの多くは GGUF 形式で、量子化レベルがタグや末尾の文字列で示される。代表的なものを、1 つの重みあたり何ビットになるか（bits-per-weight, bpw）とあわせて並べる。bpw の値は Hugging Face の GGUF 量子化タイプ一覧（huggingface.co/docs/hub/en/gguf）に記載のものだ。

読み解き方のコツは 2 つある。1 つは数字（4 / 5 / 6 / 8）がおおよそのビット数で、大きいほど高精度・大サイズだということ。もう 1 つは末尾の _K が「K 量子化（k-quant）」という比較的新しい方式を表し、その後ろの _S / _M / _L が Small / Medium / Large、つまり同じ K 量子化の中でもどの層をどれだけ高精度に残すかの配合違いを示すこと。一般に Medium（_M）が無難な落としどころとされる。IQ で始まるものは importance matrix（重要度行列）を使ってさらにビットを削った系統で、2 ビット級まで縮められる代わりに品質の低下が見えやすい。

なお Hugging Face のドキュメントでは Q8_0 や Q4_0 は「legacy（現在はあまり広く使われていない）」と注記されている。とはいえ Ollama のライブラリでは Q8_0 タグが現役で配布されており、高精度側の比較対象として実用的なので、本記事でも測定対象に含めた。

実測：llama3.2:3b で 3 レベルを比較

ここからが本題だ。llama3.2:3b を Q4_K_M・Q8_0・FP16 の 3 タグで順番にロードし、VRAM の増加量と生成速度を測った。3B という小さめのモデルを選んだのは、FP16 まで含めて 3 段階すべてが 16GB に余裕で載るサイズで、量子化レベルそのものの影響を CPU オフロードの混入なしに比べられるからだ。

測定条件

測定の公正さのために 2 点そろえた。1 つは、ComfyUI など GPU を使う他のアプリをすべて終了し、GPU0 のベースラインが約 2.3GB（Windows のデスクトップ表示などの常駐分のみ）のクリーンな状態で測ったこと。各タグは順番に測ったが、次のタグをロードする前に前のモデルを keep_alive:0 で解放し、VRAM がベースライン付近へ戻ったことを確認している。そのため、ロード後の総使用量からロード直前の値を引いた増加分が、そのタグをロード・実行するための追加 VRAM（重み＋ KV キャッシュ＋実行バッファ＋ CUDA 関連の確保分）に対応する。もう 1 つは、すべてのタグで ollama ps の PROCESSOR 列が 100% GPU、つまり一部レイヤーが CPU 側に逃げる「partial offload」が起きていないことを確認したこと。FP16 まで含めて全タグが GPU 完結なので、量子化レベル間の比較として条件がそろっている。とはいえ、ここで出す VRAM 値はあくまで RTX 5080・num_ctx=4096・Ollama 0.23.3 での値だ。ご自身の環境では、空き VRAM の状況や他プロセス次第で実際の載り方が変わるので、最後は手元の GPU で ollama ps と nvidia-smi を見て確かめてほしい。

結果

上の数値は、各タグ 3 回分の eval_count・eval_duration（Generate API のレスポンス）、ロード前後の nvidia-smi、ollama ps の PROCESSOR / CONTEXT 表示を記録したうえで算出している。生成速度は目測ではなく API が返した実測トークン数とナノ秒から計算した値だ。いずれも筆者環境での 3 回平均で、生ログ自体は本記事には未掲載のため、最終的な数値はご自身の環境で測り直してほしい。

表を縦に見ると、ビット数の大きいタグほど、今回の実測ではモデルサイズ・VRAM・所要時間が増え、生成速度が落ちるという、予想どおりの一直線の関係が出ている。ポイントは「どれくらい」変わるかだ。

ファイルサイズと VRAM は別物だが、連動して増える。Q4_K_M の 2.0GB に対し FP16 は 6.4GB と、ファイルサイズはちょうど 3.2 倍。VRAM デルタも 2.9GB → 6.85GB と約 2.4 倍に増えている。ファイルサイズと VRAM デルタが一致しないのは、VRAM 側には重み本体に加えて num_ctx=4096 ぶんの KV キャッシュや実行用バッファ、CUDA コンテキストが乗るからだ。クリーン状態で測ると、FP16 の VRAM デルタ（約 6.85GB）はファイルサイズ（6.4GB）をやや上回っていて、KV キャッシュなどの上乗せぶんが素直に出ている。傾向として「量子化を上げると VRAM も増える」ことが押さえられれば、容量計画の出発点には十分だ。

速度差はかなり大きい。Q4_K_M の 276 tok/s に対し、Q8_0 は 186 tok/s（約 67%）、FP16 は 112 tok/s（約 40%）。3B という軽いモデルなのでどれも体感は速いが、ビット数の大きいタグにすると生成速度が目に見えて落ちることがはっきり出た。これは、ビット数が増えるほど 1 トークンあたりに動かすデータ量が増え、メモリ帯域がボトルネックになりやすいためだ。LLM の推論が VRAM の帯域に強く依存するという話は、GPU 選びの観点としてVRAM 16GB GPU を AI 用途別に比較でも触れている。

つまり 3B クラスでは、FP16 を選ぶと VRAM を 2 倍以上払って速度を 6 割捨てることになる。その対価として得られる品質差が見合うかどうかが判断の分かれ目だが、これは後の「品質差」の章で扱う。

VRAM の目安を計算で確認する

実測がいつでも手元にあるわけではないので、ざっくり見積もる計算も持っておくと役に立つ。考え方はシンプルで、必要 VRAM ≒ モデルの重みのサイズ ＋ KV キャッシュ ＋ 実行バッファだ。

重みのサイズは「パラメータ数 × 1 パラメータあたりのバイト数」で出る。バイト数は量子化レベルで決まり、おおよそ次のとおり。

ここに KV キャッシュと実行バッファ、CUDA コンテキストぶんを上乗せする。やっかいなのは、この上乗せ分が「重みの何割」という単純な比例にならない点だ。KV キャッシュはコンテキスト長（num_ctx）に比例するが、CUDA コンテキストや compute バッファはモデルサイズにあまり依存しない固定費に近い。固定費があるぶん、小さいモデルほど重みに対する上乗せの比率が高くなる。実際、今回のクリーン実測では、3B の Q4_K_M は重み概算 1.7GB に対して実測デルタ 2.9GB（約 1.7 倍）だったのに対し、8B の Q4_K_M は重み概算 約 4.6GB に対して実測デルタ 5.3GB（約 1.15 倍）で、割増率がかなり違う。つまり「重みに一定割合を足せば収まる」という単純な目安は置きにくい。確実なのは、Ollama の配布ページ上のモデルサイズを確認したうえで、使う num_ctx と同じ条件で実際にロードし、ollama ps と nvidia-smi で確かめることだ。

この計算でとくに重要なのが FP16 の 8B が約 16GB という行だ。重みだけで 16GB を使い切るので、KV キャッシュと実行バッファを足すと 16GB の GPU には収まらない。「8B を FP16 で動かしたい」場合は、VRAM 24GB 以上のカードを用意するか、複数 GPU に分散するかのどちらかになる。一枚に載らないモデルを 2 枚の GPU に自動分散させる挙動についてはRTX 5080 での MoE モデル実測や、低 VRAM で大型 MoE を動かすRTX 4060 8GB で Qwen3.6 35B MoE を動かす検証でも扱っている。

8B クラスへの展開：qwen3:8b で測ってみる

3B はどの量子化でも余裕で載るので、量子化選びがシビアになるのはもう少し大きいモデルからだ。そこで 8B クラスの代表として qwen3:8b の Q4_K_M を、同じ 16GB 環境（RTX 5080）で測った。

8B の Q4_K_M で VRAM デルタが約 5.3GB。先ほどの 3B・Q4_K_M（2.9GB）と比べると、パラメータ数がおよそ 2.7 倍に対して VRAM デルタは約 1.8 倍の増加にとどまっている。これは前の章で触れたとおり、CUDA コンテキストなどの固定費の比率が大きいモデルほど下がるためだ。生成速度は 128.0 tok/s で、3B・Q4_K_M の 276 tok/s に対しておよそ 46%。モデルが大きくなれば 1 トークンの計算量が増えるので、当然遅くなる。それでも 100 tok/s を超えていて、チャット用途なら十分に快適な範囲だ。

注目したいのは、8B の Q8_0 / FP16 は今回実測していない点だ。FP16 については計算上の理由が大きい。8B モデルの重みだけで約 16GB に達し、16GB のカードには KV キャッシュぶんが乗らず現実的ではない。一方、Q8_0 については話が少し違う。たとえば qwen3:8b-q8_0 は Ollama の公式タグでのサイズが 8.9GB で配布されており（ollama.com/library/qwen3/tags）、num_ctx=4096 程度のデフォルト設定であれば、他の GPU アプリが動いていないクリーンな 16GB 環境ではロードできる可能性がある。ただし長いコンテキスト・並列実行・他プロセスとの共存では余裕が急に減る。本記事で 8B クラスを実測したのは Q4_K_M のみで、Q8_0 の 16GB 環境での動作は環境次第で変わるため、自分の環境で実際に試して確認してほしい。8B をより高い量子化で安定して常用したいなら、より大きい VRAM のカードを選んでおくのが確実だ。VRAM が足りずに CUDA out of memory が出たときの切り分けはVRAM不足エラーの原因と解決法にまとめてある。

品質差はどれくらい気になるか

ここまでの実測で確認したのは、量子化タグによるモデルサイズ、VRAM 使用量、生成速度の違いだ。本記事では、llama3.2:3b や qwen3:8b について、同一プロンプトによる人手評価、Perplexity、KLD の測定は行っていない。だから品質については「実測した数値」としてではなく、参照できる範囲の一般的な傾向として扱う。

量子化による品質劣化は、よく KL ダイバージェンス（KLD）や Perplexity といった指標で測られる。参考として、llama.cpp 公式リポジトリには、LLaMA 3 8B を対象にした特定条件での Perplexity 比較が掲載されている（github.com/ggml-org/llama.cpp perplexity/README）。その結果では、Q4_K_M より Q8_0 のほうが FP16 に近く、高精度側の量子化ほど指標上の差が小さくなる傾向が示されている。

ただし、この結果を llama3.2:3b や qwen3:8b の会話品質、コード生成、長文整合性、推論タスクへそのまま当てはめることはできない。Perplexity はモデルをまたいで直接比較できる指標ではなく、人手評価による生成品質と常に一致するわけでもない（llama.cpp 側も同様の注意を述べている）。品質が重要な用途では、自分が実際に使うプロンプトセットで Q4_K_M・Q6_K・Q8_0 などを比較して判断するのが確実だ。

本記事の実測から確実に言えるのは、Q4_K_M は VRAM と速度を抑えやすい出発点であり、Q8_0 や FP16 は、より大きな VRAM 消費と低い生成速度を受け入れて品質側を検証したい場合の比較候補になる、という範囲だ。品質を 1 段詰めたいときに Q5_K_M や Q6_K が現実的な落としどころになりやすいのは、Q8_0/FP16 より VRAM・速度のコストが軽いからで、品質そのものを保証する話ではない。なお IQ2 など 2 ビット級まで落とすと、一般には文章の一貫性や指示追従の低下が見えやすくなるとされ、VRAM をどうしても削りたいとき限定の選択肢になる。

コンテキスト長との組み合わせ：KV キャッシュ量子化

量子化レベルを決めるとき、見落としやすいのがコンテキスト長との取り合いだ。VRAM の予算は重みだけでなく KV キャッシュも食う。KV キャッシュはコンテキスト長（num_ctx）に比例して増えるので、長いコンテキストを扱いたいほど VRAM を圧迫する。

ここで効いてくるのが、Ollama / llama.cpp が持つ KV キャッシュ自体を量子化する機能だ。ただし使うには前提条件がある。まず OLLAMA_FLASH_ATTENTION=1 を設定して Flash Attention を有効にしておく必要がある。その上で OLLAMA_KV_CACHE_TYPE=q8_0 や q4_0 を指定すると、KV キャッシュを 8 ビットや 4 ビットに落とせる。Ollama 公式 FAQ にも「Flash Attention が有効なときに KV キャッシュの量子化が機能する」と明記されている（ollama/docs/faq.mdx）。この設定は Ollama サーバ起動時に指定し、グローバルに全モデルへ適用される点も覚えておきたい。既定は f16 で、量子化すると VRAM 消費が減るので、同じ VRAM のままコンテキスト長を伸ばせる、あるいは伸ばしたぶんの VRAM を捻出できる。

使い分けの考え方はこうだ。たとえば 16GB に 8B・Q4_K_M を載せたあと、num_ctx を大きくしたら VRAM が足りなくなった、というとき。モデルの量子化をさらに落として品質を犠牲にする前に、OLLAMA_FLASH_ATTENTION=1 を確認してから KV キャッシュ側を q8_0 に量子化して様子を見るのが筋がいい。KV キャッシュの量子化は重みの量子化ほど出力品質に影響しにくいとされ、コンテキストを長くしたい用途では費用対効果が高いことが多い。ただしモデルやタスクによっては q4_0 まで落とすと長文の追従が落ちる場合もあるので、まずは q8_0 から試すのが無難だ。なおこの機能は Ollama のバージョンによって対応状況や指定方法が変わり得るので、利用前に使っているバージョンのドキュメントを確認してほしい。

量子化の選び方まとめ

ここまでの実測と一般論を、選び方のフローに落とす。

1. まず Q4_K_M を起点にする。サイズ・速度・品質のバランスが良く、外しにくい。本記事で扱う llama3.2:3b・qwen3:8b ではタグ省略時の既定が Q4_K_M に対応している（他モデルは ollama show で確認）。
2. VRAM に余裕があり、品質を 1 段詰めたいなら Q5_K_M → Q6_K の順に上げる。Q8_0/FP16 まで上げなくても、VRAM と速度のコストを抑えつつ高精度側に寄せられる（実際に品質が足りるかは自分のプロンプトで確認する）。
3. VRAM が潤沢で、量子化による劣化を指標上できるだけ抑えたいなら Q8_0。FP16 はさらにサイズと速度のコストが増えるが、本記事では品質を比較していないため、ローカルで常用する価値があるかは用途別に確認したい。
4. VRAM がどうしても足りないなら、量子化を下げる前に「より小さいパラメータのモデル」や「KV キャッシュ量子化」を先に検討する。それでも足りなければ IQ 系（2〜3 ビット）だが、品質低下は覚悟する。
5. 長いコンテキストを使いたいなら、重みの量子化を落とすより先に OLLAMA_KV_CACHE_TYPE=q8_0 を試す。

VRAM 容量ごとの現実的な狙いどころを表にするとこうなる（num_ctx=4096 前提）。16GB 環境における llama3.2:3b の 3 量子化と qwen3:8b の Q4_K_M は本記事の実測に基づくが、8GB / 24GB 環境、および qwen3:8b の Q8_0 / FP16 は公式タグサイズから見た目安で、本記事では実測していない。実際の可否は num_ctx・他プロセス・Ollama のバージョンによって変わる。

16GB の行を見れば、今回の主題がそのまま要約されている。本記事の 16GB・num_ctx=4096 環境なら、3B は FP16 まで比較的余裕を持って選べる（8GB 環境や他プロセス併用時は要実測）。一方 8B になると 16GB では Q4_K_M が安定した起点になり、Q8_0 は空き VRAM・num_ctx・他プロセス次第で要実測、FP16 はタグサイズだけで約 16GB に達し通常は収まらない。だからこそ「8B 以上を高品質で使いたいか」が、16GB で止めるか上のカードへ行くかの判断材料になる。この境界の話はVRAM 16GB GPU の選び方とあわせて読むと、ハード選びの視点でつながる。

よくある質問

Q. タグを省略して ollama run llama3.2:3b と打つと、どの量子化が入りますか？

本記事で扱う llama3.2:3b と qwen3:8b では、タグを省略したとき（latest）の既定が Q4_K_M に対応している。ただしモデルによって既定は異なるので、ほかのモデルでは Ollama のライブラリ該当ページのタグ一覧を確認するか、ダウンロード後に ollama show <モデル名> で量子化（quantization）の項目を見ると確実だ。

Q. Q4_K_M と Q4_0 はどう違いますか？

どちらも 4 ビット級だが、Q4_K_M は「K 量子化」という新しい方式で、層ごとに精度の配分を変えて品質を保っている。Q4_0 は古い方式（Hugging Face のドキュメントでも legacy 扱い）で、同じ 4 ビットなら基本的に Q4_K_M を選んでおけばよい。

Q. VRAM が足りているのに生成が遅いです。量子化のせいですか？

量子化タグによって生成速度が変わることは今回の実測でも確認できたが、遅さの原因はそれだけではない。まず ollama ps の PROCESSOR 列を確認し、100% GPU になっているかを見る。GPU/CPU 混在（partial offload）になっていたら、モデルサイズ・num_ctx・他プロセスの VRAM 使用量を確認してほしい。複数の推論サーバや別の GPU 負荷が併存している場合も、切り分け対象に含めるとよい（Ollama FAQ: How can I tell if my model was loaded onto the GPU?）。

Q. ファイルサイズと VRAM 使用量が一致しないのはなぜですか？

VRAM には重み本体に加えて、コンテキスト長に応じた KV キャッシュと実行用バッファが乗るためだ。num_ctx を大きくするほど KV キャッシュぶんの VRAM が増える。逆に、メモリ確保の単位やレイヤーの扱いの最適化で、見かけ上ファイルサイズより VRAM デルタが小さく出ることもある。配布サイズはあくまで目安として、実際の容量計画は少し余裕を持たせるのが安全だ。

Q. ローカルで動かせば、入力したデータは絶対に外部へ出ないと考えていいですか？

Ollama でローカルのモデルだけを使い、外部連携機能を使っていなければ、推論そのものは手元で完結する。ただし「絶対に出ない」と言い切るのは正確ではない。ツールやフロントエンドによっては Web 検索・外部 API 連携・テレメトリ送信などの機能を持つ場合があり、設定や使い方次第で外部通信は発生し得る。機密データを扱うなら、使うモデルがローカルであることに加えて、外部連携を無効化し、通信やログの設計まで含めて確認するのが筋だ。Ollama のクラウド機能を明示的に切りたい場合は、起動前に OLLAMA_NO_CLOUD=1 を設定し、起動ログに「Ollama cloud disabled: true」が出るか確認すると確実だ。

まとめ

• 量子化タグの違いは「重みを何ビットで持つか」の違いで、サイズ・VRAM・速度・品質のすべてに連動する。これらはトレードオフの関係にある。
• クリーン環境（他の GPU アプリを終了、全タグ 100% GPU）の実測（RTX 5080 16GB・Ollama 0.23.3・num_ctx=4096）では、llama3.2:3b で Q4_K_M=276 tok/s / VRAM デルタ約 2.9GB、Q8_0=186 tok/s / 約 4.0GB、FP16=112 tok/s / 約 6.85GB。ビット数の大きいタグほど VRAM が増え速度が落ちる、という関係がはっきり出た。
• 品質そのものは本記事では測っていない。参照した llama.cpp の Perplexity 比較では高精度側ほど FP16 との指標差が小さくなる傾向だが、これは特定モデルの結果だ。迷ったら Q4_K_M、品質を確実に詰めたいなら自分のプロンプトで Q5_K_M / Q6_K / Q8_0 を比較するとよい。
• 8B の Q4_K_M は VRAM デルタ約 5.3GB・128.0 tok/s で 16GB に余裕で載るが、8B の FP16 はタグサイズだけで約 16GB に達し、KV キャッシュや実行バッファを加えると単一 16GB GPU には通常収まらない。8B をより高い量子化で常用したいなら上の VRAM を検討する。
• コンテキストを伸ばしたいときは、重みの量子化を下げる前に OLLAMA_FLASH_ATTENTION=1 を有効にした上で OLLAMA_KV_CACHE_TYPE=q8_0 を試すのが費用対効果が高い（Flash Attention が前提条件）。
• 数値は特定の構成・バージョンでの結果であり、モデル・Ollama のバージョン・コンテキスト長で変わり得る。考え方を持ち帰りつつ、最終的な絶対値は自分の環境で測ってほしい。

関連して、前提知識はVRAMとは？・Ollamaとは？・ローカルLLMとは？、実行エンジンの中身はllama.cppとは？、VRAM が足りないときの対処はVRAM不足エラーの解決法、GPU の選び方はVRAM 16GB GPU を AI 用途別に比較を参照してほしい。大型 MoE をローカルで動かす個別ガイドはQwen3.6-35B-A3B のローカル実行ガイドもどうぞ。