Antigravity で Gemma 4 が Out of Memory エラーになる問題の解決法

Gemma 4 を Antigravity に接続して試してみたら、しばらくして画面が固まり GGML_METAL_MAX_BUFFERS や out of memory という見慣れないエラーが出て途方に暮れた、という経験はないでしょうか。私自身、16GB の MacBook で 27B モデルをそのまま動かそうとして、エディタごと何度もフリーズさせてしまいました。個人開発の現場で繰り返しこの問題にぶつかり、試行錯誤するうちに対処の順番が見えてきましたので、整理してお伝えします。

なぜ Out of Memory が発生するのか

Gemma 4 は Google DeepMind が公開したオープンソースモデルですが、バリアントによって必要なメモリ量が大きく異なります。

Gemma 4 2B（fp16）: 約 4GB RAM
Gemma 4 9B（fp16）: 約 18GB RAM
Gemma 4 27B（fp16）: 約 54GB RAM

多くの開発者が「とりあえず Gemma 4」と選んでインストールするのは 27B モデルです。しかし 27B を fp16 精度でそのまま動かすには 54GB 以上のメモリが必要で、一般的な開発用 MacBook（16〜32GB）では完全にメモリ不足になります。

Antigravity の背後で Ollama を使っている場合、このエラーは次のような形で現れます。

Error: model 'gemma4:27b' failed to load: GGML_METAL_MAX_BUFFERS exceeded
llama_new_context_with_model: failed to allocate memory
error: out of memory

エラーメッセージがサイドパネルのチャット欄に出ずに、Antigravity のステータスバーにひっそり表示される場合もあるため、「なんとなく応答が返ってこない」という状態になることもあります。

まず現在のメモリ使用量を確認する

原因を絞り込む前に、実際に何 GB 使われているかを確認してみましょう。

# macOS でメモリ使用量を確認
# アクティビティモニタで「メモリ」タブを見るのが最速ですが、ターミナルでも確認できます
vm_stat | grep "Pages"
# → Pages free, Pages active, Pages wired down の数値から推測できます
 
# Ollama が使用しているメモリを確認
ps aux | grep ollama | grep -v grep

目安として、モデルをロードするには「モデルサイズの 1.2〜1.5 倍」の空きメモリが必要です。27B モデルの Q4_K_M 量子化版（約 17GB）であれば、20〜25GB 程度の空きが必要になります。

Apple Silicon の Mac では、メモリが CPU と GPU で共有される統合メモリ構成になっている点にも注意が必要です。num_gpu_layers で GPU 側にオフロードした分も同じ物理メモリから確保されるため、「GPU に逃がせばメインメモリが空く」という直感は当てはまりません。空き容量は CPU・GPU をまとめた全体で見積もるのが安全です。

解決策 1: 量子化モデルに切り替える

最も効果的な対処法は、fp16（フル精度）ではなく量子化（INT4/INT8）モデルを使うことです。Ollama では以下のコマンドで量子化バリアントを指定できます。

# 推奨: Q4_K_M は精度と速度のバランスが良い
ollama pull gemma4:27b-it-q4_K_M
 
# より小さいメモリで動かしたい場合
ollama pull gemma4:27b-it-q2_K

量子化によって精度は若干下がりますが、コード補完や説明の生成といった Antigravity の主要ユースケースでは、体感できるほどの差はほとんどありません。実際に両方を比較しても、日常的なコード作業では Q4_K_M で十分だと感じています。

解決策 2: Ollama の num_ctx を下げる

コンテキストウィンドウのサイズも大量のメモリを消費する原因になります。デフォルトでは 32768 トークン前後に設定されていることが多く、これだけで数 GB を余分に使います。

Antigravity の設定（ギアアイコン → AI Providers → Ollama）から num_ctx を調整するか、以下のように Modelfile で設定を固定することができます。

# Modelfile を作成して num_ctx を制限する
FROM gemma4:27b-it-q4_K_M

PARAMETER num_ctx 8192
PARAMETER num_gpu_layers 20

# Modelfile から新しいモデルを作成
ollama create gemma4-8k -f Modelfile
 
# Antigravity の接続先モデルをこちらに切り替える

num_gpu_layers はGPU（Apple Silicon の場合 Metal）にオフロードするレイヤー数です。メモリが逼迫している場合は 10〜20 程度に下げると安定しやすくなります。

解決策 3: より小さいモデルバリアントを使う

27B にこだわる必要がない場合、9B を使うと大幅にメモリを節約できます。コード補完の品質は 27B と比べて遜色ない場面も多く、応答速度も速いので、まず 9B で試してみることをおすすめします。

ollama pull gemma4:9b-it-q4_K_M

9B の Q4_K_M であれば必要メモリは約 6〜7GB です。16GB の MacBook でも他のアプリを閉じれば安定して動かせます。

私自身、個人開発で日常的に使うのは結局この 9B です。27B との差を意識する場面は限られていて、応答が速いぶん作業のテンポを崩さずに済んでいます。

参考として、Antigravity で Gemma 4 を Ollama 経由で接続する基本的な手順は Antigravity と Ollama で Gemma 4 をローカル接続する方法にまとめています。また、ローカル LLM のメモリ最適化を含む開発ワークフロー全体については Gemma 4 ローカル開発ワークフロー完全ガイドも参考にしてみてください。

解決策 4: 不要なプロセスを停止してメモリを確保する

Antigravity・Ollama・ブラウザを同時に起動していると、それだけで 8〜12GB 以上のメモリが消費されていることがあります。ブラウザのタブを閉じるだけでも 1〜2GB 空くことがあるので、試してみる価値はあります。

また、Ollama は一度モデルをロードするとメモリに保持し続けます。別のモデルに切り替えたい場合は、以下のコマンドで現在ロードされているモデルを確認・削除できます。

# 現在ロード中のモデルを確認
ollama ps
 
# モデルをアンロードする（Ollama v0.1.24 以降）
ollama stop gemma4:27b

設定変更後の動作確認

OOM 対策の設定をひと通り終えたら、Antigravity を再起動してチャット欄でシンプルなプロンプトを送り、応答が返ってくるかを確認します。

# Ollama が正常に応答しているか curl で確認する
curl http://localhost:11434/api/generate \
  -d '{
    "model": "gemma4:27b-it-q4_K_M",
    "prompt": "Hello, can you respond briefly?",
    "stream": false
  }'
# 期待する出力: {"model":"gemma4:...","response":"Hello! ...","done":true,...}

このコマンドが正常に応答を返せば、Ollama 側の問題はなく、Antigravity の接続設定や URL 設定を見直すほうが先決です。

一般的な CPU/メモリ使用率が高い場合のAntigravity全体の問題については Antigravity の CPU・メモリ使用率が高い問題を解消するも参考になります。

全体を振り返って

Out of Memory エラーへの対処は、この順で試すのが効率的です。

量子化モデル（Q4_K_M）に切り替える
num_ctx を 8192 程度に下げる
モデルを 27B から 9B に変更する
不要なプロセスを停止して空きメモリを確保する

まずは量子化モデルへの切り替えだけで解決するケースが多いので、そこから始めてみてください。