llama.cppでVRAM不足（OOM）エラーの解決法｜Gemma 4実行時の原因と対処法を徹底解説

Gemma 4をllama.cppで動かそうとしたら、生成が始まる前にVRAMが枯渇してプロセスが落ちた——この経験をした人は少なくないはずだ。モデルのロード自体は通るのに、推論フェーズに入った途端にOut of Memoryが出る。VRAM使用量を確認すると、まだ何もしていないのに搭載量の9割以上が埋まっている。原因はモデルの重み自体ではなく、Gemma 4が採用しているSliding Window Attention（SWA）のKVキャッシュにある。この記事では、VRAM 16GB〜24GB環境でGemma 4を安定稼働させるための具体的な手順を、原因ごとに整理して解説していく。

このエラーの症状と確認すべき環境情報

このトラブルで典型的な症状は以下の通り。

llama.cppでGemma 4（密モデル）をロードし、プロンプトを入力した直後に “CUDA error: out of memory” や “failed to allocate buffer” といったメッセージが表示される。あるいは、モデルのロード自体は成功するものの、最初のトークン生成が始まる前にプロセスがクラッシュする。タスクマネージャーやnvidia-smiでVRAM使用量を見ると、モデルサイズから想定される量を大幅に超えている。

特に紛らわしいのが、「モデルファイルのサイズ的にはVRAMに収まるはずなのに落ちる」というケース。たとえばQ4_K_Mで量子化されたGemma 4 12Bモデルは約7〜8GBだが、16GB VRAMのGPUでもOOMが発生することがある。この差分の正体が、後述するSWA KVキャッシュの過剰確保だ。

対処前に確認してほしい環境情報:
– OS: Windows 10/11 または Linux（Ubuntu 22.04以降を推奨）
– GPU: NVIDIAのモデル名とVRAM容量（nvidia-smi コマンドで確認可能）
– ドライババージョン: nvidia-smi の出力上部に表示されるDriver Versionの値を控える
– AIソフトとそのバージョン: llama.cppのビルド日時またはコミットハッシュを ./llama-server –version で確認する

なお、Gemma 4の推論性能に関する基本的な情報は、公開済みの「ローカルAI環境：Gemma 4の推論性能を徹底比較｜ローカルLLMの思考トークン効率」（/gemma-llm-comparison/）も参考にしてほしい。

「CUDA out of memory」がモデルロード直後に出る：SWA KVキャッシュの過剰確保

Gemma 4が採用しているSliding Window Attention（SWA）は、通常のFull Attentionとは異なるKVキャッシュの管理方式を持っている。問題は、llama.cppのデフォルト設定ではこのSWA用KVキャッシュがF16（半精度浮動小数点）で確保され、通常のKVキャッシュに適用される量子化が適用されない点にある。

具体的な数値で見てみよう。llama.cppはデフォルトで並列処理数（-np）を1より大きい値に設定している場合がある。サーバーモードでは複数リクエストの同時処理を想定するため、並列スロット数に応じてKVキャッシュがスロット分だけ確保される仕組み。SWAキャッシュはスロットごとにF16で個別確保されるため、スロット数が3なら単純計算でSWAキャッシュだけで3倍のVRAMを消費する。

16GB VRAMのGPU（RTX 4060 Tiなど）でGemma 4 12Bの量子化モデルを動かす場合、モデル本体で約7〜8GB、通常のKVキャッシュで2〜3GB、そしてSWAキャッシュがスロット数に比例して膨らむ。スロット3本で運用すると、SWAキャッシュだけで4〜6GB消費し、合計が16GBを軽く超えてしまう。

対処手順:
1. llama.cppのサーバーまたはCLIの起動コマンドに -np 1 を追加する。例: ./llama-server -m gemma4-12b-q4_k_m.gguf -ngl 99 -np 1 のように指定する
2. 起動後、nvidia-smi を実行してVRAM使用量を確認する。-np 1を指定する前と比較して、SWAキャッシュ分のVRAMが大幅に減少しているはず
3. テストプロンプトを送信し、トークン生成が正常に完了することを確認する

ステップ2の時点でVRAM使用量がGPU搭載量の85%以下に収まっていれば、安定動作が見込める。もし90%を超えている場合は、次のセクションで解説するKVキャッシュの量子化も併用した方がよい。

ちなみに、-np 1 はサーバーモードで同時に処理できるリクエストを1つに制限するだけなので、1人で使う分には処理速度への影響はゼロ。複数人でアクセスする場合にはキューイングが発生するが、個人利用なら気にする必要はない。

「failed to allocate buffer」が出る：KVキャッシュの量子化が無効になっている

-np 1を設定してもまだギリギリという場合、KVキャッシュ全体の量子化設定を見直す価値がある。llama.cppにはKVキャッシュをQ8_0やQ4_0で保持するオプションがあり、VRAM消費を大きく抑えられる。

デフォルトではKVキャッシュはF16で保持される。Gemma 4 12Bの場合、コンテキスト長8192でKVキャッシュ全体が約2.5〜3GBになることがある。これをQ8_0に変更すると約半分、Q4_0なら約4分の1まで圧縮可能だ。

ただし注意点もある。KVキャッシュの量子化は出力品質にわずかな影響を与える場合がある。Q8_0であればほぼ劣化を感じないが、Q4_0まで下げると長文生成時にやや一貫性が落ちるという報告がコミュニティでは上がっている。

対処手順:
1. 起動コマンドに -ctk q8_0 を追加して、KVキャッシュのKey側をQ8_0に量子化する
2. 同様に -ctv q8_0 を追加して、Value側も量子化する。完全なコマンド例: ./llama-server -m gemma4-12b-q4_k_m.gguf -ngl 99 -np 1 -ctk q8_0 -ctv q8_0
3. 起動後に nvidia-smi でVRAM使用量を確認する。F16時と比較して1〜1.5GB程度の削減が確認できるはず
4. 生成品質が許容範囲か確認するため、数回のテストプロンプトを試す

Q8_0でもまだ不足する場合は -ctk q4_0 -ctv q4_0 も選択肢になるが、品質面のトレードオフは把握しておくべきだろう。

加えて、コンテキスト長の設定も見直してほしい。デフォルトのコンテキスト長が不必要に大きい場合、-c 4096 のように必要最小限に抑えることでKVキャッシュのメモリ消費をさらに減らせる。

GPUドライバが古い・破損している場合の「CUDA initialization failed」エラー

VRAM関連のエラーではなく、そもそもCUDAの初期化に失敗するケースもある。llama.cppの起動時に “CUDA initialization failed” や “no CUDA-capable device is detected” が表示される場合、ドライバ側の問題を疑うべきだ。

Gemma 4をllama.cppのCUDAバックエンドで動かすには、NVIDIA Driver 535.x以上（CUDA 12.2対応）が必要。古いドライバではCUDAのバージョン不一致が起こり、GPUが認識されていても演算が開始できない。また、Windows Updateやシステムクラッシュの影響でドライバファイルが破損しているケースも珍しくない。

対処手順:
1. nvidia-smi を実行し、現在のDriver VersionとCUDA Versionを確認する。Driver Versionが535未満の場合はアップデートが必要
2. NVIDIAの公式サイトからGPUに対応する最新のGame Ready DriverまたはStudio Driverをダウンロードする
3. 既存ドライバに問題がある場合は、Display Driver Uninstaller（DDU）をダウンロードし、Windowsのセーフモードで起動してから実行する。DDUの画面で「Clean and restart」を選択してドライバを完全に削除する
4. 再起動後、ステップ2でダウンロードしたドライバをインストールする。「カスタムインストール」を選び、「クリーンインストールを実行する」にチェックを入れる
5. インストール完了後、再度 nvidia-smi を実行してDriver VersionとCUDA Versionが正しく表示されることを確認する

Linux環境の場合は、パッケージマネージャ経由でのドライバ更新が安全だ。Ubuntuなら sudo ubuntu-drivers install で推奨ドライバがインストールされる。手動で.runファイルからインストールする場合は、既存のnouveauドライバを無効化する手順が別途必要になる。

GPU温度の上昇によるサーマルスロットリングとクラッシュ

見落としがちだが、GPU温度の問題でパフォーマンスが低下したり、突然プロセスが終了したりするケースもある。LLMの推論はGPUに持続的な負荷をかけるため、ゲームのように負荷が変動する用途とは発熱パターンが異なる。

NVIDIAのGPUは一般的にジャンクション温度が83〜90℃でサーマルスロットリングが始まり、クロック周波数が自動的に引き下げられる。さらに温度が上昇して100℃前後に達すると、保護機能によりGPUがシャットダウンし、アプリケーションはエラーなくプロセスが消滅する。ログに明確なエラーメッセージが残らないため、VRAM不足と誤認しやすいのが厄介な点だ。

対処手順:
1. llama.cppで推論を実行中に、別のターミナルで nvidia-smi -l 5 を実行してGPU温度をリアルタイム監視する（5秒間隔で更新される）
2. 温度が80℃を超える場合は、まずPCケースのエアフローを確認する。ケースファンの追加や向きの見直しで5〜10℃改善することも珍しくない
3. GPU自体のファン設定をMSI AfterburnerやEVGA Precisionで調整する。ファンカーブを積極的に設定し、70℃到達時にファン回転数が80%以上になるよう変更する
4. それでも温度が高い場合は、llama.cppの -t オプションでCPUスレッド数を減らし、GPU周辺の発熱を抑えることも試す価値がある

デスクトップPCなら物理的な清掃も有効で、ヒートシンクやファンに溜まったホコリをエアダスターで除去するだけで10℃近く下がった事例もある。ノートPCの場合は冷却パッドの使用を検討してほしい。

それでも解決しない場合の代替手段

上記の対処法をすべて試してもOOMが解消しない場合、いくつかの方向から回避策を検討できる。

モデルの量子化レベルを下げる

現在Q4_K_Mを使っているなら、Q3_K_SやIQ3_XXSといったより低い量子化レベルのGGUFを試してみる手がある。Gemma 4 12BのQ3_K_Sなら約5〜6GBに収まり、16GB環境でもKVキャッシュを含めた余裕が生まれる。品質の低下はQ4_K_Mと比較して体感できるレベルだが、タスクによっては十分実用的だ。

GPUオフロード層数の調整

すべてのレイヤーをGPUに載せる -ngl 99 ではなく、一部をCPUに逃がす方法もある。-ngl 20 のように数値を下げると、指定した数のレイヤーだけがGPUで処理され、残りはCPU＋RAM側で処理される。推論速度は低下するが、OOMを回避しながらGPUアクセラレーションの恩恵を部分的に受けられるのがメリット。最適な値はGPUのVRAM容量によって異なるため、数値を変えながらVRAM使用量と生成速度のバランスを探ってみてほしい。

クラウドAPIへの切り替え

ローカル実行にこだわる理由がプライバシーやオフライン利用でなければ、Gemma 4をクラウドAPI経由で利用する選択肢もある。Google CloudのVertex AIやサードパーティのAPIサービスを利用すれば、GPU環境を一切持たなくても推論が可能。特に長文処理や大きなコンテキスト長が必要な用途では、ローカル環境の制約から解放される利点は大きい。

ドライバのロールバック

最新ドライバに更新した後にかえって不安定になった場合は、1〜2世代前のドライバに戻す手段も検討すべきだ。NVIDIAの公式サイトには過去のドライバアーカイブが公開されている。Windows環境では「デバイスマネージャー」→「ディスプレイアダプター」→ 該当GPUを右クリック →「ドライバーの更新」→「コンピューターを参照」から、ダウンロード済みの旧ドライバを指定してインストールできる。

コミュニティへの相談

llama.cppのGitHub Issuesは活発にメンテナンスされており、Gemma 4固有の問題もすでに複数報告されている。自分のGPUモデル・VRAM容量・量子化形式・起動コマンドを添えて投稿すれば、開発者やユーザーから具体的なアドバイスが返ってくることが多い。Redditのr/LocalLLaMAコミュニティも情報交換の場として有用だ。

まとめ

llama.cppでGemma 4を実行した際のVRAM不足エラーは、ほとんどの場合、SWA KVキャッシュの過剰確保が原因。まずは起動コマンドに -np 1 を追加して、不要な並列スロット分のキャッシュ確保を止めること。これだけでSWAキャッシュのVRAM消費が約3分の1に減り、16GB環境でも12Bモデルが動作するようになるケースが大半だ。

それでも足りない場合は、-ctk q8_0 -ctv q8_0 でKVキャッシュを量子化し、-c 4096 でコンテキスト長を必要最小限に絞る。ドライバ起因のエラーならDDUでクリーンインストール、温度問題ならエアフローの改善——と、原因に応じた対処を順番に試していけば、大半のケースは解決に至るだろう。

最も解決率の高い -np 1 オプションの追加を、まず今すぐ試してみてほしい。

よくある質問（FAQ）

Q: VRAM 16GBのGPUでGemma 4 27Bモデルは動かせますか？
A: フル精度では不可能だが、Q3_K_S以下の量子化を使い、GPUオフロード層数を制限すれば部分的に動作する場合がある。ただし実用的な生成速度を得るには24GB以上のVRAMが望ましい。RTX 3090（24GB）やRTX 4090（24GB）であればQ4_K_Mでも動作した報告がコミュニティに上がっている。現実的には、16GB環境ならGemma 4 12Bを量子化して使うのが最もバランスの良い選択になるだろう。

Q: -np 1を指定するとサーバーモードで複数人が同時にアクセスできなくなりませんか？
A: その通りで、同時に処理できるリクエストは1つに制限される。2人目以降のリクエストは1人目の処理が終わるまでキューで待機する形になる。ただし、個人利用や少人数での利用であれば体感上の問題はほぼない。複数人で同時利用する環境では、-np の値を上げつつ、KVキャッシュの量子化やコンテキスト長の短縮で帳尻を合わせるアプローチが現実的だ。

Q: llama.cppのバージョンによってVRAM消費量に差はありますか？
A: ある。llama.cppは頻繁に最適化が行われており、SWAキャッシュの扱いも過去数ヶ月で改善が進んでいる。古いビルドを使っている場合は、最新のリリースに更新するだけでVRAM効率が改善される可能性がある。GitHubリポジトリのリリースノートで「KV cache」や「SWA」に関する変更履歴を確認し、該当する修正が含まれるバージョンへの更新を検討してほしい。ビルドの更新は既存のモデルファイルに影響しないため、気軽に試せる対策の一つだ。

おすすめパーツ 価格まとめ