8GB VRAM で llama.cpp をどう調整するか: 32K の方が安定しやすく、64K では KV Cache 量子化が重要

8GB の VRAM でローカル LLM をスムーズに動かせるのか、特に長いコンテキストで速度を維持できるのかは、llama.cpp を使う人がよく直面する問題です。

まず覚えておきたいポイントは 3 つあります。

8GB VRAM では、32K コンテキストの方が安定したバランスになりやすい
どうしても 64K を使いたいなら、KV Cache の量子化がほぼ必須になる
フル GPU 推論では、CPU スレッド数をむやみに増やすとかえって遅くなることがある

1. まず、32K・64K・KV Cache とは何か

この手の調整記事で最初につまずきやすいのが、この 3 つの用語です。

32K と 64K はコンテキスト長を意味し、モデルが一度に処理できる token 数の上限を表します。ここでの K は千なので、32K は約 32000 token、64K は約 64000 token です。コンテキストが長いほど、モデルは一度により多くの過去情報を見られるため、長文読解、長い対話、複数段階の分析に向いています。

KV Cache は、連続生成を高速化するためにモデルが保持する中間結果のキャッシュです。すでに読んで計算済みの部分を毎回最初から計算し直すのではなく、重要な中間情報を保存して再利用する仕組みだと考えるとわかりやすいです。K と V は Transformer の Key と Value を指します。

この 3 つがいつも一緒に出てくるのは、次の関係があるからです。

32K と 64K は、一度にどれだけの内容を記憶させたいかを決める
KV Cache は、その記憶を維持するためにどれだけ追加の VRAM が必要かを決める
コンテキストが長くなるほど KV Cache は大きくなり、VRAM の負担も増える

そのため、長コンテキストで速度が落ちる原因は、モデルの計算能力不足というより、キャッシュが大きくなりすぎて VRAM が限界に近づくことにある場合が多いです。

2. なぜ 32K と 64K で速度差が大きくなるのか

たとえば《三体》の約 3 万字を使って負荷テストを行い、32K と 64K のコンテキストを比較すると、文章量が近くても 64K の方が大きく遅くなり、総処理時間もかなり長くなることがあります。

原因はモデルが急に遅くなったからではなく、VRAM の境界にぶつかったからです。

32K では、モデルの重みとキャッシュがまだ 8GB VRAM の中にほぼ収まり、データは主に GPU メモリ帯域の中で処理されます。ところが 64K にするとキャッシュがさらに増え、総使用量が VRAM 上限に近づくか超えてしまい、一部データが共有メモリやシステムメモリに押し出されます。

このとき落ちるのは演算性能そのものではなく、帯域です。

つまり、「コンテキストを倍にしたら急に遅くなった」という現象の本質は、データ経路が VRAM からより遅いメモリへ落ちたことにあります。

3. 64K を使うなら、KV Cache 量子化が重要

8GB VRAM 環境で特に重要なのが、KV Cache の量子化です。

モデル本体を変えず、キャッシュだけを量子化すると、長コンテキスト時のキャッシュ使用量を直接削減できます。すると、もともと VRAM からあふれていた一部のデータを 다시 VRAM 側に戻しやすくなります。その結果、64K は依然として 32K より重いものの、最も遅い領域に落ち込みにくくなります。

要するに、

32K は 8GB VRAM における実用的な標準レンジ
64K も不可能ではない
ただしキャッシュ量子化なしでは、「使える」から「かなり厳しい」へ一気に落ちやすい

長コンテキストを安定して使いたいなら、優先順位は次のようになります。

まず VRAM が上限に近づいていないか確認する
次に KV Cache 量子化を有効にするか判断する
その後で、より攻めたスループット設定を試す

4. GPU 使用率が低くても、GPU が遊んでいるとは限らない

これは直感に反しやすいポイントです。

タスクマネージャーで GPU 使用率が 20% や 30% しか見えないと、多くの人は次のように考えます。

パラメータ設定が間違っているのではないか
モデルが本当に GPU 上で動いていないのではないか
GPU を使い切れていないのではないか

しかし llama.cpp の推論では、ボトルネックがコア演算ではなくメモリ読み書きにあることがよくあります。

つまり、GPU コアはあるバッチの計算をすぐ終えても、次の重みやキャッシュデータが届くまで待たされる、という状態です。

その結果、

コア使用率はそれほど高くない
それでも全体の速度は伸びない

という現象になります。

これは GPU が怠けているのではなく、データ経路が狭いだけです。

そのため、ローカル LLM の速度を見るときは GPU Usage だけで判断してはいけません。VRAM 容量、メモリ帯域、キャッシュのあふれ方の方が重要なことが多いです。

5. スループット関連パラメータは効くことがあるが、VRAM 余裕が前提

GPU コアが完全には埋まっていないなら、スループット関連の設定を上げて一度に処理するデータ量を増やし、GPU の並列性をもっと引き出せるのではないか、という考え方があります。

これは実際に速度向上につながることがあります。

ただし前提条件があります。VRAM にまだ余裕があることです。

スループット関連の設定を上げると、VRAM 使用量も増えることが多いからです。すでに 64K、大きなキャッシュ、VRAM ぎりぎりという状態でさらに押し上げると、次のような結果になりがちです。

そのままクラッシュする
クラッシュしなくても、より遅い共有メモリモードに落ちる

したがって、より安全な順番は「最初に全部最大化する」ことではなく、

まず VRAM の境界を守る
次にスループット最適化を試す
変更のたびに速度と安定性を確認する

という流れです。

6. CPU スレッドは多ければ多いほどよいわけではない

これも覚えておきやすい落とし穴です。

スレッドが多いほど速いはずだ、と考えるのは自然です。しかし、モデルがすでに主に GPU で動いている場合、CPU スレッド数を無理に増やすとかえって性能が落ちることがあります。

理由は単純です。

フル GPU 推論では、CPU は主力の計算機というより、スケジューラや前処理補助の役割に近くなります。この状態でスレッドを増やしすぎると、CPU 側のスレッド競合、スケジューリング負荷、コンテキストスイッチのコストが大きくなり、本来スムーズであるべきデータの流れを乱してしまいます。

結果として、

CPU はより忙しそうに見える
それでも全体は遅くなる

ということが起きます。

この種の構成では、デフォルト設定や低めのスレッド数の方が、全部を最大化するより安定しやすいです。

7. 8GB VRAM 向けの、より実用的な考え方

ここまでの結論を実行しやすい形にまとめると、だいたい次のようになります。

1. まず 32K を標準目標にする

8GB GPU なら、最初から 64K を狙いにいかない方が無難です。32K の方が、速度・安定性・メモリ使用量のバランスが取りやすいことが多いです。

2. 64K を使いたいなら、まずキャッシュを見る

「あと少し速くできるか」より先に、KV Cache が量子化されているか、VRAM がすでに限界付近ではないかを確認すべきです。

3. GPU 使用率だけで判断しない

使用率が低いからといって設定ミスとは限りません。単にメモリ帯域が本当のボトルネックかもしれません。

4. スループット最適化は有効だが、VRAM 境界を越えない

これらの設定は確かに効くことがありますが、前提は VRAM に余裕があることです。

5. CPU スレッドは保守的に始める

モデルがほぼ GPU 上で動いているなら、CPU スレッド数は高ければよいわけではありません。まずはデフォルトか低めで試し、必要なら少しずつ調整します。

結論

この話の価値は、いくつかのベンチマーク数字そのものより、ひとつの見落とされがちな事実をはっきりさせてくれる点にあります。

ローカル LLM の調整で本当に大事なのは、すべての設定を最大にすることではなく、ボトルネックが演算性能なのか、VRAM 容量なのか、メモリ帯域なのか、それとも CPU のスケジューリングなのかを見極めることです。

8GB VRAM ユーザーにとって、より安全な方針は「最長コンテキストを無理に追う」ことではなく、まず VRAM の境界を守り、そのうえでどこまで伸ばすかを判断することです。

ひとことでまとめるなら、こうです。

32K は 8GB VRAM でより安定しやすい作業レンジであり、64K も不可能ではないが、その前提として KV Cache と VRAM 使用量をしっかり管理できている必要がある。