VRAM 32GBのGPUにモデルを載せた。VRAM使用量はまだ余裕がある。なのに数回プロンプトを送っただけでプロセスが強制終了される——原因はGPUではなく、システムRAMの枯渇だった。
海外のRedditコミュニティ（r/LocalLLaMA）で、llama.cppを使ってGemma 4 31Bを実行した際にシステムRAMが異常消費される現象が話題になっている。報告者はVRAM 32GB・システムRAM 64GBという潤沢な環境にもかかわらず、LinuxのOOM Killerによってllama.cppが強制終了されたという。複数のユーザーが同様の現象を確認しており、RTX 5090環境でも再現が報告されている状況。
ローカルLLMの世界では「VRAMが足りるかどうか」が最大の関心事になりがちだが、この事例はその常識に一石を投じるもの。本記事では、この現象の原因を掘り下げ、現時点で取れる対策を整理した。
- llama.cppでGemma 4を長コンテキストで実行すると、VRAMではなくシステムRAMが枯渇してOOMが発生する
- KVキャッシュのチェックポイントがシステムRAM側に蓄積されることが主な原因と考えられている
- コンテキスト長（-c値）の短縮が最も確実な対策。64GB RAMでも100kコンテキストは維持できない
VRAMではなくシステムRAMが枯渇する現象とは
まず、報告されている症状を正確に把握しておきたい。
Reddit投稿者の環境はVRAM 32GB、システムRAM 64GB（DDR5）という構成。Gemma 4 31BのUnsloth量子化モデル（UD_Q5_K_XL）を、コンテキスト長102400（約100kトークン）で読み込んだところ、モデル自体はVRAMに収まり、読み込み直後のVRAM使用量には余裕があった。
問題が顕在化するのはここから。数回プロンプトを送信すると、システムRAMの使用量が急激に上昇し、64GB中63GBに到達。LinuxのOOM Killerがllama.cppプロセスを強制終了するという結果に。
興味深いのは、投稿者がその後128GB RAM（DDR4）を搭載した別のPCでも検証している点。こちらでは即座にクラッシュはしなかったものの、数万トークンのプロンプトを数回処理しただけで80GBまでRAM使用量が上昇し、なお増加傾向にあったという報告。
さらに押さえておきたいのは、量子化レベルを下げても解決しないこと。Q4量子化に切り替えたところVRAM使用量は約23GBに減少したが、システムRAMの異常消費は変わらなかった。この事実は、問題の根がモデルの重みサイズではなく、別のメモリ領域にあることを示唆している。
対処法を試す前に、まず以下の環境情報を確認してほしい。
- OS: Linux（OOM Killerが発動する環境）/ Windows（スワップ肥大化として現れる）
- GPU: モデル名とVRAM容量（nvidia-smiで確認可能）
- システムRAM: 搭載容量と現在の使用量（free -h で確認）
- llama.cpp: ビルド日時またはコミットハッシュ（–version オプションで確認）
- 使用モデル: モデル名・量子化形式・コンテキスト長の設定値
なぜシステムRAMが大量に消費されるのか
VRAMに余裕があるのにシステムRAMが枯渇する——直感に反するこの現象の背景には、llama.cppのメモリ管理構造が関係していると筆者は考える。
KVキャッシュとコンテキスト長の関係
llama.cppでLLMを実行する際、メモリは大きく2つの用途に分かれる。1つはモデルの重み（パラメータ）で、これは主にVRAMに配置される。もう1つがKVキャッシュで、推論中に過去のトークン情報を保持するための領域。
KVキャッシュの消費量はコンテキスト長に比例して増大する。コンテキスト長を100kトークンに設定した場合、そのぶんだけ巨大なKVキャッシュ領域が必要になるという仕組み。
Reddit上のコメントで指摘されているのが「コンテキストチェックポイント」の存在。llama.cppではおよそ8192トークンごとにチェックポイントが作成され、MoEモデルの場合1回あたり約533MB、Denseモデルではさらに大きい可能性があると報告されている。100kコンテキストなら約12回のチェックポイントが発生し、それだけで6GB以上のメモリを占有する計算になる。しかも、これらがVRAMではなくシステムRAM側に蓄積されていく可能性が高い。
Denseと MoE で挙動が異なる可能性
Gemma 4 ファミリーには Dense 系の 31B（本記事の対象）と MoE 系の 26B variant（128 experts のうち 8 を活性化）の 2 系統が存在し、アーキテクチャごとにメモリ挙動が異なる可能性がある。MoEでは入力に応じて異なるエキスパート（サブネットワーク）が活性化される構造のため、推論時にエキスパート切り替えのためのバッファが追加で必要になる。一方 Dense モデルは毎トークン全パラメータを通すため、KVキャッシュ由来のメモリ圧迫が主因となりやすい。
今回Reddit投稿者が使用した Gemma 4 31B は Dense モデルに該当するとされており、MoE特有のエキスパートバッファではなく、KVキャッシュとチェックポイントの蓄積がシステムRAM消費を押し上げた可能性が高い。
ただし、この点については明確な技術文書による裏付けがまだ不十分で、あくまでコミュニティでの推測にとどまっている段階。
再現条件と影響範囲の整理
報告されている条件を表にまとめると、問題の輪郭が見えてくる。
| 環境 | VRAM | システムRAM | 量子化 | コンテキスト長 | 結果 |
|---|---|---|---|---|---|
| PC1 | 32GB | 64GB DDR5 | UD_Q5_K_XL | 102400 | RAM 63GB到達→OOM Kill |
| PC1 | 32GB | 64GB DDR5 | Q4 | 102400 | VRAM 23GB使用、RAM枯渇は改善せず |
| PC2 | 複数GPU | 128GB DDR4 | UD_Q5_K_XL | 102400 | RAM 80GB到達、なお上昇中 |
注目すべきポイントは3つある。
1つ目は、量子化レベルを下げてもRAM消費が改善しないこと。Q5からQ4に変更するとVRAM使用量は約23GBに減少したが、システムRAMの異常消費はそのまま。モデルの重みサイズとは独立した要因が働いている証拠と言える。
2つ目は、複数のマシンで再現すること。報告者は異なるハードウェア構成の2台で検証し、同一の挙動を確認している。特定のハードウェアやドライバの問題ではなく、llama.cpp側のメモリ管理に起因する可能性が高い。
3つ目は、Gemma 4がローカル運用全般でまだ安定していない現状。r/LocalLLAMAでは同時期に、Gemma 4のツールコール機能が正常に動作しないという報告や、推論時に「怠惰な」挙動（必要な外部ツール呼び出しをスキップする等）を示すという指摘も上がっている。RAM枯渇問題と直接の因果関係はないものの、モデルとしての成熟度がまだ発展途上であることを示す状況証拠と筆者は見ている。
現時点で取れる対策
根本的な修正はllama.cppの開発チーム側での対応を待つ必要があるが、現時点でユーザー側で試せる対策はいくつか存在する。
コンテキスト長とRAM搭載量の目安
最も確実な対策は、コンテキスト長（-c オプション）を短縮すること。報告者自身も「VRAMに余裕があってもコンテキストを下げざるを得ない」と述べている。
目安として、以下の数値を参考にしてほしい（あくまで現時点での推定値であり、今後のllama.cppアップデートで変動する可能性がある）。
| システムRAM | 推奨コンテキスト長（30Bクラス） | 備考 |
|---|---|---|
| 32GB | 8192〜16384 | OS・他プロセスの使用分を考慮し控えめに |
| 64GB | 16384〜32768 | 長めのプロンプトもある程度対応可能 |
| 128GB | 32768〜65536 | 100kは依然リスクあり。RAM使用量の監視を推奨 |
100kコンテキストをフル活用したい場合、128GBのシステムRAMでも不足する可能性がある。現実的には、コンテキスト長を32k〜64k程度に抑えるのが安全な運用ラインだろう。
報告者の使用パラメータは -ngl 999 -c 102400 -fa on –cache-type-k q8_0 –cache-type-v q8_0 だった。この中で最も効果が大きいのは -c の値を下げること。まずは -c 32768 や -c 16384 に変更して、RAM消費が安定するか確認してみてください。
llama.cppの設定で試せるオプション
コンテキスト長の短縮以外にも、いくつか試す価値のある設定がある。
- KVキャッシュの量子化レベルを下げる: 報告者は –cache-type-k q8_0 –cache-type-v q8_0 を使用していた。これを q4_0 に変更することで、KVキャッシュのメモリ消費を約半分に削減できる可能性がある。ただし、出力品質への影響はモデルやタスクによって異なる
- バッチサイズの調整: -b（バッチサイズ）や -ub（マイクロバッチサイズ）を小さくすることで、処理中の一時バッファを削減できる場合がある。デフォルト値から -b 512 や -b 256 に下げて様子を見る手もある
- スワップ領域の拡張: 根本解決ではないが、Linuxの場合はスワップファイルを追加することでOOM Killの発動を遅延させられる。ただしスワップへのアクセスが発生すると推論速度は大幅に低下するため、あくまで緊急避難的な措置
なお、llama.cppは活発に開発が続いているプロジェクトで、2026年4月にもb8838（4/18リリース確認済）など複数ビルドが公開されている。macOS、Linux、Windowsの各プラットフォームに加え、CUDA 12/13やROCm 7.2など多様なGPUアクセラレータに対応したビルドが公開されており、開発は精力的に進んでいる状況。今回のRAM枯渇問題についても、llama.cppのGitHub Discussionsで議論が始まっており、将来のバージョンで改善される可能性は十分にあると筆者は考える。
当サイトの検証環境では、Ollamaを通じてgemma4:26b（MoE variant）を実行した際のVRAM使用量は14.8GB、推論速度は36.6 tokens/secを記録している。ただしこれはOllamaのデフォルトコンテキスト長での計測であり、llama.cppで100kコンテキストを設定した場合とは条件が大きく異なる。コンテキスト長を短く保てば、16GB VRAM環境でもGemma 4 MoE variantの推論自体は十分実用的な速度で動作するという参考データになるだろう。なお本記事で議論しているRAM枯渇は Dense 31B の長コンテキスト運用で顕著な事象であり、MoE variant 26B とは発生条件が異なる点に留意してほしい。
ローカルLLM環境でシステムRAMはどれだけ必要か
今回の事例は、ローカルLLMのハードウェア構成を考える上で重要な教訓を含んでいる。「VRAM容量」だけに注目していると、思わぬところでボトルネックに直面するということ。
ローカルLLM環境のメモリは、実質的に3層構造で理解する必要がある。
第1層: VRAM（GPU側） — モデルの重みとKVキャッシュの主要部分を格納する。推論速度に直結する最重要リソース。
第2層: システムRAM（CPU側） — モデルのロード処理、KVキャッシュのチェックポイント、推論中の一時バッファなどに使われる。VRAMからあふれた分のスピルオーバー先にもなる。
第3層: ストレージ（スワップ） — RAMが不足した際の最終的な退避先。速度は桁違いに遅く、ここに頼る時点で実用性は大幅に低下する。
モデルサイズ別のシステムRAM目安（長コンテキスト運用を想定した場合）は以下の通り。これはソース情報と一般的なメモリ消費傾向から筆者が導き出した推定値であり、モデルのアーキテクチャや量子化形式によって変動する点に注意してほしい。
| モデルサイズ | 短コンテキスト（8k以下） | 中コンテキスト（8k〜32k） | 長コンテキスト（32k超） |
|---|---|---|---|
| 7B〜8Bクラス | 16GB | 32GB | 32〜64GB |
| 14B〜26Bクラス | 32GB | 64GB | 64〜128GB |
| 30B超クラス | 64GB | 64〜128GB | 128GB以上 |
AI用PCの構成を検討する際、GPUのVRAM予算だけでなくシステムRAMへの投資も意識すべきだろう。DDR5メモリの価格は下落傾向にあり、2026年4月時点で32GB×2枚（64GB）構成は2万円前後で手に入る。長コンテキストでの運用を視野に入れるなら、最初から64GB以上を搭載しておくのが安心。VRAMの選択についてはVRAMの基礎知識について別記事で詳しく解説しているので、あわせて参考にしてほしい。
NVIDIA側でもVRAM効率化の技術開発は進んでおり、RTX Neural Texture Compressionのような新技術がVRAM使用量の削減に寄与し始めている。ただし、今回のようなシステムRAM側の問題には直接的な効果はなく、あくまでVRAM最適化の文脈での技術という点は区別が必要。
まとめ
llama.cppでGemma 4を長コンテキストで実行した際にシステムRAMが枯渇する問題は、VRAMではなくKVキャッシュのチェックポイントやバッファがシステムRAM側に蓄積されることが主因と考えられている。
対策の優先順位を整理すると、以下の流れになる。
- まずコンテキスト長（-c）を32768以下に短縮して症状が改善するか確認する
- 改善しない場合はKVキャッシュの量子化レベルを q4_0 に下げる
- システムRAMが64GB未満なら128GBへの増設を検討する
- llama.cppの最新ビルドに更新し、今後のバージョンでの修正を待つ
ローカルLLMの環境設計では「VRAMが足りるか」ばかりに目が行きがちだが、システムRAMもまた重要なリソース。特に30Bクラス以上のモデルを長コンテキストで扱う場合、64GB以上のシステムRAMは事実上の必須ラインになりつつある。
あなたの環境ではシステムRAMの使用量を意識したことがあるだろうか。VRAMの次にRAMがボトルネックになる時代が来ているのかもしれない。
よくある質問（FAQ）
Q: この問題はGemma 4だけで起きますか？
A: Gemma 4で顕著に報告されているが、大コンテキスト×大パラメータモデルの組み合わせなら他のモデルでも起こりうる現象。MoEアーキテクチャのモデルは特にチェックポイントのメモリ消費が大きいという指摘があり、同様のアーキテクチャを持つモデルでは注意が必要。
Q: Windowsでも同じ問題が発生しますか？
A: LinuxのようなOOM Killerによる強制終了は発生しないが、RAMの枯渇自体はOS問わず起こりうる。Windowsの場合はスワップファイル（ページファイル）が自動拡張されるため即座にクラッシュはしにくいものの、スワップへのアクセスが増えると推論速度が極端に低下する。タスクマネージャーでメモリ使用量を監視しながら運用するのが望ましい。
Q: llama.cppではなくOllamaを使えば回避できますか？
A: OllamaのバックエンドにはGGML/llama.cppの技術が使われているため、根本的なメモリ管理の挙動は共通する可能性がある。ただし、Ollamaはデフォルトのコンテキスト長が比較的短く設定されているため、100kのような極端な長コンテキストを明示的に指定しない限り、同様の問題には遭遇しにくいと考えられる。
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
本記事は AIハードウェア図鑑 編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
