Gemma 4 の VRAM 最適化

Reddit r/LocalLLaMA / 2026/4/3

💬 オピニオンDeveloper Stack & InfrastructureTools & Practical Usage

要点

  • Gemma 4 の密なモデルは、Sliding Window Attention (SWA) の KV キャッシュにより、起動直後に大量の VRAM を消費することがあります。この SWA 用 KV キャッシュは F16 で確保され、他の KV キャッシュと同様に量子化できない場合があります。
  • 直近の llama.cpp の変更によって、KV キャッシュ量子化を有効にしていても SWA 部分が一時的に未量子化になる不具合がありましたが、すぐに元に戻されたため、利用者は最近のビルドを実行してください。
  • ソロで実行している場合、llama.cpp の起動コマンドに `-np 1` を追加すると、SWA キャッシュの VRAM 使用量をおおよそ 3 分の 1 に削減できます(例:26B モデルで ~900MB→~300MB、31B モデルで ~3200MB→~1200MB)。
  • `-ub`(ubatch サイズ)を調整すると、SWA バッファのメモリ使用量に大きく影響します。VRAM が限られている場合は、速度向上のために増やすよりもデフォルトの `-ub 512` を維持することを推奨します。
  • 16GB GPU で密な 31B モデルを動かす場合は、OOM を避けるために、より低い量子化レベル(例:IQ3/Q3_K)にすることや、vision/mmproj のメモリを削減して 30K+ のコンテキストを達成できるようにする必要がある場合があります。

TLDR: あなたが唯一のユーザーなら、llama.cpp の起動コマンドに -np 1 を追加すると、SWAキャッシュのVRAM使用量が即座に3分の1になります

私は Gemma 4 をいじっていて気づいたのですが、密なモデル(dense model)は、何かを生成する前から大量のVRAMをゴッソリ消費します。16GB環境だとOOMになって、なぜだろうと思うかもしれません。

原因は SWA(Sliding Window Attention)の KV キャッシュです。これは F16 で確保され、他の KV キャッシュのように量子化(quantize)されません。数日前に ggerganov が PR をマージしたのですが、これによってさらに悪化してしまいました。つまり、KV キャッシュの量子化を有効にしていても SWA 部分が非量子化のまま保持されるようになったのです。これはここ https://github.com/ggml-org/llama.cpp/pull/21332 で約2時間後に元に戻されたので、最近のビルドを使っているか確認してください。

実際にVRAMを減らすのに役立つことがいくつかあります:

SWA キャッシュのサイズはおおむね(スライディングウィンドウサイズ × 並列シーケンス数)+ マイクロバッチサイズ で計算されます。つまり、サーバーがデフォルトで並列4スロットになっているなら、単一ユーザー構成と比べてメモリを3倍払っていることになります。チャットを一人でしているだけなら、起動コマンドに -np 1 を追加すると、26B モデルでは SWA キャッシュが 約900MBから約300MB になります。また、31B の dense モデルでは 3200MBから1200MB に減ります

さらに -ub(ubatch size)にも注意してください。デフォルトは512で問題ありません。もしあなたが、あるいは誰かのガイドが「速度のために -ub 4096 にしろ」と言っていたなら、それは SWA バッファを大幅に膨らませます。VRAMに余裕がない限り、デフォルトのままにしておいてください。

16GB 環境で dense 31B モデルを使う場合でも、IQ3 または Q3_K の量子化ならそこそこ良いコンテキストで動かせますが、30K+ のコンテキスト(fp16)にしたいなら mmproj(ビジョン)を落とす必要が出てくるでしょう。-np 1 にして、デフォルトの ubatch のままなら、かなり扱いやすくなります。

submitted by /u/Sadman782
[link] [comments]