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が発生する
- 報告例で有力な要因はllama-serverのコンテキストチェックポイント。Gemma 4では、特定の31B系GGUF・設定で1回約3.6GiBに達したログもあり、既定設定のままではシステムRAMを大きく消費しうる
- 最も直接的な対策は
--ctx-checkpointsを0/1に、--parallel（-np）を1に絞ること。コンテキスト長（-c）短縮やRAM増設はその次 - llama-server利用時は、ホストRAM上のプロンプトキャッシュも使用量に関わる。
--cache-ram（既定 8192 MiB）はRAM側キャッシュ容量の上限で、0でその容量を無効化できる。プロンプトキャッシュ機能そのものを止めるには--no-cache-promptを使う
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プロセスを強制終了するという結果に。このとき Linux では Killed とだけ表示されてプロセスが落ち、dmesg に Out of memory: Killed process … llama が残る。ただし out of memory という文言だけでは VRAM 不足か RAM 不足かは断定できない——cudaMalloc failed や failed to allocate CUDA0 buffer のようにデバイス名が付くならGPU側、CUDA_Host・pinnedメモリ・LinuxのOOM Killerログならホスト側を疑う。nvidia-smi・free -h・dmesg -T | tail を同時に確認して切り分けたい。
興味深いのは、投稿者がその後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キャッシュ領域が必要になるという仕組み。
このRAM消費の有力な要因が、llama-serverのコンテキストチェックポイントだ。llama-serverはスロットごとに会話の途中状態をホストRAMへ保存して再利用する仕組みを持ち、保存数は --ctx-checkpoints（既定32／スロット＝最大数）、最小間隔は --checkpoint-min-step（既定256トークン）で制御される。Gemma 4は、Qwen 3.5のようなrecurrent stateを持つモデルと比べるとチェックポイントが大きくなりやすいという報告がある。llama.cppのGitHub Discussion #21480では Gemma 4 26B A4B（Q8 KVキャッシュ）で1チェックポイントが約531MiB、Issue #21690 のログでは Gemma 4 31B系の特定設定で 8,192トークン時点のチェックポイントが約3.6GiB（3600.054 MiB）と記録された例がある。同じ約3.6GiBの状態が最大32個まで保持されると仮定した単純計算では100GiBを超えうるが、これは特定ログに基づく理論上限だ（チェックポイントは最大数まで・最小間隔ありで、256トークンごとに必ず作られるわけではない）。実際の消費量はチェックポイントのサイズ・作成数・保持/破棄の挙動・スロット数・モデル・KVキャッシュ形式で大きく変わるため、固定値として見積もるべきではない。なおコンテキスト長とKVキャッシュ量子化の関係はコンテキスト長とKVキャッシュ量子化の解説も参照。
free -h で監視したい。Gemma 4 の Dense と MoE
本記事で扱う大型の Gemma 4 には、31B Dense と 26B A4B MoE（128 experts のうち 8 と共有 expert を活性化）がある（ファミリーには E2B / E4B、2026年6月案内の 12B Unified なども含まれる）。モデル構造やKVキャッシュ、チェックポイントのサイズは同一ではない。
ただし、今回のホストRAM増加を「MoE特有のエキスパート切り替えバッファ」のように、どちらか一方の構造だけで説明できる公的な技術資料は見つかっていない。むしろ前述の観測値では、26B A4B MoE の約531MiBに対し 31B Dense は約3.6GiBと、Denseのチェックポイントの方が大きい例もある。実際の消費量は、モデル・量子化・コンテキスト長・スロット数・llama.cppのバージョンをそろえて測る必要がある。
再現条件と影響範囲の整理
報告されている条件を表にまとめると、問題の輪郭が見えてくる。
| 環境 | 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到達、なお上昇中 |
注目すべきポイントは2つある。
1つ目は、量子化レベルを下げてもRAM消費が改善しないこと。Q5からQ4に変更するとVRAM使用量は約23GBに減少したが、システムRAMの異常消費はそのまま。モデルの重みサイズとは独立した要因が働いている証拠と言える。
2つ目は、複数のマシンで再現すること。報告者は異なるハードウェア構成の2台で検証し、同一の挙動を確認している。特定のハードウェアやドライバの問題ではなく、llama.cpp側のメモリ管理に起因する可能性が高い。
現時点で取れる対策
この挙動には未確認の不具合報告がある一方、Qwen 3.5との差はモデル構造によるものという開発側の説明もあり、すべてを「修正待ちのバグ」と断定できる状況ではない。利用中のビルドと設定で実測しながら、チェックポイント数やスロット数を調整するのが現実的だ。現時点でユーザー側で試せる対策を挙げる。
最優先——チェックポイントとスロットを絞る（llama-server）
llama-server で使うなら、最も直接的なのはチェックポイントの数とスロット数を絞ることだ。Issue #21690 の再現例では、Gemma 4 31B系を16K前後の文脈で使うと既定設定では生成のたびにRAMが数GB単位で増え続けてOOMに至った一方、--ctx-checkpoints 1 -np 1 または --ctx-checkpoints 0 -np 1 でRAM使用量が大きく抑えられたと報告されている（単一報告であり全環境への保証ではないが、主題に最も近い直接的な回避策）。--ctx-checkpoints はスロットあたりの保存数（既定32）、-np（--parallel）はスロット数だ。チェックポイントを減らすと、過去プロンプトを再利用できる範囲が狭まり、後続リクエストでのプロンプト再処理時間やTTFT（最初のトークンが返るまでの時間）が悪化することがある。まずは安定性を優先した診断・回避策として使うとよい。
切り分けの順番は——①--ctx-checkpoints 0（または1）＋--parallel 1 で再現性を確認 → ②--cache-ram 0 でRAM側キャッシュの寄与を確認し、プロンプトキャッシュ機能そのものも切りたい場合は --no-cache-prompt を追加して比較 → ③それでも不足するなら -c／--ctx-size を下げる → ④さらにKVキャッシュ量子化やRAM増設、が現実的だ。
コンテキスト長とRAM搭載量の目安
チェックポイントとスロットを絞ったうえで、さらに効くのがコンテキスト長（-c オプション）の短縮。報告者自身も「VRAMに余裕があってもコンテキストを下げざるを得ない」と述べている。
目安として以下を参考にしてほしい。ただしこれは互換性保証や必要容量の算定式ではなく、計測の開始点となる保守的な値だ。llama-serverではスロット数・チェックポイント数・プロンプトキャッシュ・KVキャッシュ形式・画像入力の有無で消費量が大きく変わる。実際 Issue #21690 では、64GB RAM環境でも約16Kの完全プロンプト処理を数回繰り返すとRAMが尽きた報告があり、容量だけでは安全性を決められない。特にGemma 4の長コンテキスト運用では、起動直後と複数リクエスト後の両方を測定したい。
| システムRAM | 保守的な上限の目安（30Bクラス） | 備考 |
|---|---|---|
| 32GB | 8192〜16384 | OS・他プロセスの使用分を考慮し控えめに |
| 64GB | 16384〜32768 | 長めのプロンプトもある程度対応可能 |
| 128GB | 32768〜65536 | 100kは依然リスクあり。RAM使用量の監視を推奨 |
100kコンテキストを使う場合、128GBのシステムRAMでも不足する可能性がある。まずはチェックポイント数とスロット数を絞ったうえで、16k〜32k程度から実測を始め、必要に応じて64kへ広げるのが安全だ。起動直後の使用量だけで判断せず、複数リクエストを処理した後もRAM使用量が増え続けないか確認したい。
報告者の使用パラメータは -ngl 999 -c 102400 -fa on --cache-type-k q8_0 --cache-type-v q8_0 だった。llama-serverで今回のように生成ごとにRAMが増え続ける場合は、まず --ctx-checkpoints 0（または1）と --parallel 1 でチェックポイントとスロットの影響を切り分ける。そのうえで、なおRAMが不足するなら -c の値を下げる。まずは -c 32768 や -c 16384 から試し、複数リクエスト後もRAM使用量が安定するか確認したい。
llama.cppの設定で試せるオプション
コンテキスト長の短縮以外にも、いくつか試す価値のある設定がある。
--cache-ramでプロンプトキャッシュの上限を絞る: サーバーはリクエスト間でプロンプトのプレフィックス状態をホスト RAM にキャッシュして再利用する。その上限が--cache-ram（-cram）で、単位 MiB・既定 8192（＝8 GiB）、-1で無制限、0で無効。これは前述のコンテキストチェックポイントとは別の調整項目で、代替関係ではない——Issue #21690 では-cramの有無で顕著な差は出なかったとの記述もあり、--cache-ram 0を付けてもチェックポイントの作成自体は止まらないとの報告もある。なお--cache-ram 0はキャッシュ「サイズ」の無効化で、プロンプトキャッシュ機能そのものの有効/無効は--cache-prompt／--no-cache-prompt（既定は有効）で制御される。Linux ではメモリのオーバーコミットと上限が噛み合わず、画像入りプロンプトの多用時に OOM Kill に至ったという報告（Issue #22629、現在は not planned としてクローズ）もある。--ctx-checkpointsと--cache-ramは現行の llama-server・llama-cli 双方で案内されており、--parallel（スロット数）はサーバー向け設定のため、本記事の「--ctx-checkpoints 0/1＋--parallel 1」の切り分けは主に llama-server 運用を対象にする- KVキャッシュの量子化レベルを下げる: 報告者は
--cache-type-kq8_0--cache-type-vq8_0 を使用していた。これを q4_0 に変更すると、K/V を保存する領域そのものは小さくできる。ただしチェックポイントやプロンプトキャッシュ、各種バッファも絡むため、プロセス全体のホスト RAM が半分になるとは限らない。出力品質への影響もモデル・文脈長・タスクで変わり、特に長文脈では小さな量子化誤差が蓄積しうるため実タスクで確認したい - バッチサイズの調整（補助策）: -b（バッチサイズ）や -ub（マイクロバッチサイズ）を小さくすると、処理中の一時バッファを減らせる場合がある（-b 512 や -b 256 など）。ただしリクエストごとに増え続ける RAM に対する主因の対策ではなく、あくまで補助的な手段
- スワップ領域の拡張: 根本解決ではないが、Linuxの場合はスワップファイルを追加することでOOM Killの発動を遅延させられる。ただしスワップへのアクセスが発生すると推論速度は大幅に低下するため、あくまで緊急避難的な措置
なお、llama.cppは更新頻度が高く、Gemma 4向けのチェックポイント・キャッシュ・マルチモーダル関連の挙動も版によって変化しうる。記事を読んだ時点では、使用中ビルドのコミット、GitHub Releases、Gemma 4関連のIssue（#21690 など）を確認し、ここで挙げた回避策が現在も必要かを検証してほしい。RAM枯渇問題はGitHub上で継続的に議論されており、2026年6月時点でも普遍的に修正済みとは言えない。
当サイトの検証環境では、Ollamaを通じてgemma4:26b（MoE variant）を実行した際のVRAM使用量は14.8GB、推論速度は36.6 tokens/secを記録している（計測条件: RTX 5060 Ti 16GB / i7-14700F / RAM 96GB / Ollama 既定コンテキスト長・短プロンプト / 2026年4月時点。生ログ未掲載の参考値）。ただしこれは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側） — CPU側に配置されるテンソル、ホスト側プロンプトキャッシュ、コンテキストチェックポイント、推論中の一時バッファ、メモリマップされたモデルファイルなどに使われる。GPUメモリが不足した際に必ず自動退避する領域ではなく、設定やバックエンドによってはGPU側の確保失敗として処理が止まる点には注意。
第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メモリの価格は変動が大きいため、購入時点の実売価格を確認したい。長コンテキストでの運用を視野に入れるなら、最初から64GB以上を搭載しておくと安心だ。VRAMの選択についてはVRAMとは｜AI用途で必要な容量の目安で詳しく解説しているので、あわせて参考にしてほしい。
まとめ
Gemma 4をllama-serverで長コンテキスト運用した際のホストRAM枯渇は、単純に「VRAM不足の代わりにRAMへあふれた」話ではない。コンテキストチェックポイント、スロット数、ホスト側プロンプトキャッシュ、KVキャッシュ形式、画像入力などが重なり、GPUの空きとは別にRAM使用量が増えることがある。特にGemma 4では、コンテキストチェックポイントが大きくなる報告が出ている。たとえば31B系の特定GGUF・設定では、1回約3.6GiBのチェックポイントが記録された。ただし、実際の使用量はモデル・量子化・コンテキスト長・スロット数・llama.cppのビルドによって大きく変わる。
対策の優先順位を整理すると、以下の流れになる。
- llama-serverなら、まず
--ctx-checkpoints 0（または1）＋--parallel 1で症状が改善するか確認する --cache-ram 0でRAM側キャッシュを切り分け、プロンプトキャッシュ自体を無効化して比較する場合は--no-cache-promptを使う- それでも不足するならコンテキスト長（-c）を 32768 以下に下げる
- さらにKVキャッシュ量子化（q4_0）、バッチサイズ、RAM増設を検討する
- llama.cppの最新ビルドとGemma 4関連Issueを確認し、回避策が現在も必要か検証する
ローカルLLMの環境設計では「VRAMが足りるか」ばかりに目が行きがちだが、システムRAMもまた重要なリソース。ただし64GBや128GBという容量だけで安全性を判断せず、モデル・実行バイナリ・コンテキスト長・スロット数・チェックポイント設定を含めてRAM使用量を実測したい。
ご自身の環境でシステムRAMの使用量を意識したことはあるだろうか。VRAMの次にRAMがボトルネックになる時代が来ているのかもしれない。
よくある質問（FAQ）
Q: この問題はGemma 4だけで起きますか？
A: Gemma 4で目立つ報告があるが、長コンテキスト・複数スロット・ホスト側キャッシュを組み合わせるllama-server運用では、他モデルでもホストRAMが問題になりうる。必要量はモデル名だけで決まらず、コンテキスト長・KVキャッシュ形式・スロット数・チェックポイント・プロンプトキャッシュ・画像入力の有無で変わる。
Q: Windowsでも同じ問題が発生しますか？
A: LinuxのようなOOM Killerによる強制終了は発生しないが、RAMの枯渇自体はOS問わず起こりうる。Windowsでは、システム管理のページファイルが有効で十分なディスク空き容量があれば、ページファイルが拡張されて即時終了を避けられる場合がある。ただしコミット上限やディスク空き容量に達すれば、アプリ側の確保失敗や停止は起こりうる。いずれにせよスワップへのアクセスが増えると推論速度は極端に低下するため、タスクマネージャーでメモリ使用量を監視しながら運用するのが望ましい。
Q: llama.cppではなくOllamaを使えば回避できますか？
A: OllamaはGGML系ランナーを利用するが、独自のバージョン・既定設定・実行経路を持つため、llama.cppを直接実行する場合と完全に同じ挙動とは限らない。OllamaはVRAM量に応じて既定コンテキスト長が決まり、24GiB未満で4K、24〜48GiBで32K、48GiB以上で256Kが案内されている。100K超の文脈長を明示設定しなければ今回のような条件には入りにくいが、長文脈・複数リクエスト・画像入力・キャッシュ設定次第ではホストRAMが問題になる可能性は残る。
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。
本記事は AIハードウェア図鑑 編集部 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。
参考資料
- llama.cpp Discussion #21480: Gemma 4 のコンテキストチェックポイントが大きい理由（26B A4B で約531MiB）
- llama.cpp Issue #21690: Gemma 4 のチェックポイントが異常な RAM を消費し llama-server が OOM（回避策 –ctx-checkpoints / -np 1）
- llama.cpp Issue #22629: Linux の overcommit で –cache-ram の上限が効かず OOM（マルチモーダル・not planned でクローズ）
- llama.cpp 公式: llama-server README（–cache-ram / –ctx-checkpoints / –parallel の仕様）
- Ollama 公式ドキュメント: Context length（VRAM 量別の既定コンテキスト長）
- Hugging Face 公式: Google Gemma 4 31B-it モデルカード（31B Dense・26B A4B MoE などファミリー構成）
