12GBに収まったのにQwen3:14bなどが遅くなっていく？〜Intel Arc B580ローカルLLM 第4話
第3話で Intel Arc B580 のサイズ別速度を測ったとき、1つだけ説明のつかない結果が残りました。本体が12GBに収まるはずの14Bモデルが、より大きい12Bモデルより3倍以上も遅かったのです。
本記事では、その原因を追いました。結論を先に書きます。原因はモデル本体の大きさではなく「文脈の長さ（一度に扱える入力の量）」でした。文脈を長く設定すると、その作業メモリがVRAMを食い潰し、あふれた分がCPUに落ちて急激に遅くなります。しかもこの起きやすさはモデルによって大きく違いました。
測定は デスクトップPCの PCIe スロットに直挿しした B580 のみを使い（比較用の RTX 3090 はこの実験では一切使っていません）、Vulkan と Ollama で計測しました。2026年7月時点の実測です。
前回の記事はこちら
はっきり分かれました。qwen3:14b は文脈長を上げるほどCPUの割合が増え、36 → 9 tok/s まで落ちます。文脈32,768での 9.00 tok/s は、第3話で出た 9.14 tok/s とほぼ一致しました。あの遅さは、モデルが大きいからではなく、既定の文脈長が大きくてCPUにあふれていたためだったと確定します。
【追記 2026-07-31】この記事で測ったのは文脈長32,768までです。その後さらに伸ばして測り直したところ、32,768を超えると落ち続けず、頭打ちになりました。B580では65,536で7.86、131,072で8.03 tok/s。別のGPU（RTX 3060をThunderboltで接続）でも同じ形で、32,768で20.09、65,536で17.87、131,072で18.07 tok/s でした。CPUへ回る割合が飽和するためで、伸ばすほど際限なく遅くなるわけではありません。
注目すべきは、文脈を短く（2,048）すればフルにGPUへ載り、36 tok/s と gemma4-12b（30.5）を上回った点です。14Bモデルが12Bより速いこと自体は、収まってさえいれば普通に起こります。
対照の gemma4-12b は、文脈を32,768まで上げても 100% GPU のまま 30.5 tok/s で一定でした。同じ12GBのカードでも、モデルによってあふれやすさがまったく違います。
https://kimono-oyaji.com/arc-b580-size-speed-power/目次
使用した機器の概要
使用したデスクトップは、下記のとおりです。このPCにIntel Arc B580を追加しました。| CPU | Ryzen 9 3950X |
| マザーボード | X570 |
| メモリー | 64GB |
| GPU | RTX 3090、Intel Arc B580（今回追加） |
| OS | Ubuntu |
スポンサーリンク
目的：収まっているのに遅い謎を解く
第3話の測定で、qwen3:14b（本体のVRAM使用量 5.9GB）の decode（文章を生成する速さ）が 9.14 tok/s しか出ませんでした。同じ表で gemma4-12b（6.9GB）は 29.95 tok/s です。より小さくVRAMに収まっているはずの14Bが、大きい12Bの3分の1以下という、順序の逆転が起きていました。 このときの配置検証は「RTX 3090 側に載っていないこと」しか確認できておらず、CPUへのあふれを見ていませんでした。そこで、あふれを直接観測できる形で測り直しました。実験内容：文脈長を変えて速度と配分を見る
Ollama のnum_ctx（一度に扱える文脈の長さ）を 2048 から 32768 まで4段階で変え、それぞれで次を測りました。
- decode（tok/s）… 文章生成の速さ
- GPU と CPU の処理配分（Ollama が報告する割合）… どれだけCPUに落ちたか
スポンサーリンク
結果：qwen3:14b は文脈長とともにCPUへ落ちた
| モデル | 文脈長 | decode | GPU / CPU 配分 |
|---|---|---|---|
| qwen3:14b （本体5.9GB） | 2,048 | 36.11 | 100% GPU |
| 8,192 | 28.64 | 93% GPU / 7% CPU | |
| 16,384 | 13.83 | 82% GPU / 18% CPU | |
| 32,768 | 9.00 | 67% GPU / 33% CPU | |
| gemma4-12b （本体6.9GB・対照） | 2,048 | 30.54 | 100% GPU |
| 8,192 | 30.51 | 100% GPU | |
| 16,384 | 30.50 | 100% GPU | |
| 32,768 | 30.57 | 100% GPU |
Intel Arc B580・Vulkan(Mesa 26.1.5)・Ollama・デスクトップPCに直挿し・B580のみ使用。2026年7月時点の実測。
qwen3:14b の decode 速度（文脈長を上げるほど遅くなる・tok/s）
文脈2,048（100% GPU）
36.11 tok/s
文脈8,192（7% CPU）
28.64 tok/s
文脈16,384（18% CPU）
13.83 tok/s
文脈32,768（33% CPU）
9 tok/s
文脈長を上げるとKVキャッシュがVRAMを圧迫しCPUへあふれる。gemma4-12bは全文脈長で100%GPU・約30.5 tok/s一定。
考察：12GBは「本体サイズ」だけでは語れない
VRAMを使うのはモデル本体だけではありません。文章を読み進めるほど増えていく作業メモリ（KVキャッシュと呼ばれる、これまで読んだ内容を覚えておく領域）も、文脈が長いほど大きくなります。 qwen3:14b と gemma4-12b で差が出たのは、モデルごとにこの作業メモリの太さが違うためです。gemma4 系は作業メモリを小さく保つ設計（近い範囲だけを見る仕組みなどを持つ）で、長い文脈でも溢れませんでした。qwen3:14b は作業メモリが太く、文脈を伸ばすと早々に12GBを超えます。 この作業メモリを圧縮すれば解決するのか、も試しました。結果を先に書くと、Ollama 0.30系では設定が効きませんでした。OLLAMA_KV_CACHE_TYPE を f16 / q8_0 / q4_0 と変えても速度が完全に一致し、内部のログを見ると指定が llama-server 側へ渡っていませんでした。圧縮が効かないのではなく、設定そのものが無視されています。試すなら llama.cpp を直接動かして --cache-type-k / --cache-type-v を指定する必要があります。
あふれ方には2種類あることも分かりました。1つは今回の文脈であふれる型。もう1つは、そもそも本体が12GBに入らない本体であふれる型です。第3話で測った nemotron-3-nano:30b は後者で、本体が入りきらず大半がCPUに載っても 14 tok/s を保ちました。これは実際に働く部分だけを小さく持つ設計（MoE）のおかげで、あふれても実用速度が残る例でした。
スポンサーリンク
まとめ
Intel Arc B580 のような12GBのカードでローカルLLMを選ぶときは、モデル本体のサイズだけを見ても足りません。実際に使う文脈の長さと、そのモデルの作業メモリの太さ次第で、収まるはずのモデルがCPUにあふれて何倍も遅くなります。 実用上の対策はシンプルです。Ollama ならnum_ctx を必要な長さまで絞れば、あふれずにGPUへ載ることがあります。今回の qwen3:14b も、文脈を 2,048 にすれば 36 tok/s で快適に動きました。長い文脈がどうしても要る用途では、gemma4 系のように作業メモリを小さく保つモデルを選ぶ、という判断もできます。
本記事の数値は2026年7月時点・当環境（B580直挿し・Mesa 26.1.5・Ollama）のものです。
参考にしたサイト
検証に使用した機材
スポンサーリンク