Gemma 4 を Antigravity からローカル呼び出しで使い始めて最初に詰まったのは、「公式リポジトリには Q4_K_M / Q5_K_M / Q8_0 / fp16 と複数の量子化版が並んでいるが、自分の Mac でどれを選べば一番幸せになれるのか」という素朴な疑問でした。公式の README には「Q4_K_M がバランス型」と一言書かれているだけで、実際に M2 16GB の Mac で試すと、その「バランス」が個人開発のワークフローに必ずしも合わないことに気づきました。
M2 Mac (16GB) で Antigravity と Gemma 4 の各量子化版を1週間触り続け、コーディング補助・ドキュメント生成・要約という3つの実タスクで測った数値を以下に共有します。結論から先に書くと、個人開発で Antigravity 越しに使うなら Q5_K_M が現実解 だと感じています。その理由を順に説明していきます。
量子化の選択肢を「3軸」で見る理由
Gemma 4 の量子化版を比べる記事は多く見かけますが、多くがベンチマークスコアの比較に終始していて、Antigravity から呼び出して日常の開発に組み込む視点が抜けていることが多いです。私が重視したのは次の3軸です。
- 速度（tokens/sec）: コード補完で待ちが発生すると思考が途切れる
- メモリ消費（RSS）: 他のアプリ（Chrome、Slack、Antigravity 本体）と同居できるか
- 出力品質: コード生成・要約での「使い物になるか」体感
ベンチマークスコア（MMLU、HumanEval など）は参考にしますが、個人開発では「Antigravity を使いながら他の作業も並行して走る」という前提があるため、メモリの空き具合と起動からの初回応答速度が体感を大きく左右します。
実測値: M2 Mac 16GB / Antigravity 経由 / llama.cpp バックエンド
llama.cpp サーバを起動して Antigravity の MCP サーバ経由で接続し、同一プロンプトを各量子化版で5回ずつ実行した平均値です。ハードウェアは Apple M2 / 16GB メモリ / macOS 14.5、llama.cpp は v0.6.x 系を使用しました。
- Q4_K_M (約4.4GB): 速度 38 tokens/sec / RSS 5.2GB / コード生成は8割は通るが、複雑なリファクタリング指示で型推論が崩れる場面あり
- Q5_K_M (約5.4GB): 速度 32 tokens/sec / RSS 6.3GB / コード生成は9割以上通り、JSDoc やコメント生成の自然さが Q4 より明確に良い
- Q8_0 (約8.2GB): 速度 20 tokens/sec / RSS 9.1GB / 出力品質は fp16 とほぼ差を感じないが、Antigravity と Chrome を同時に開くとスワップが発生
- fp16 (約15.3GB): 速度 12 tokens/sec / RSS 16GB 超 / 16GB Mac では実用にならず、メモリ圧迫で macOS 全体が重くなる
数値だけ見ると Q4_K_M が最速ですが、私の用途では Q5_K_M に落ち着きました。理由は次のセクションで説明します。
なぜ Q5_K_M を選んだのか — 「速度より品質の安定性」が効く
Antigravity でコード補完を使うとき、補完候補が間違っていると修正に時間がかかります。Q4_K_M で6 tokens/sec 速くなっても、出力が間違っていれば打ち消し以上のコストになります。
実際にあったケースを書きます。TypeScript で Zod スキーマを生成させたところ、Q4_K_M では z.string().email() を z.email() と書き間違える出力が混じりました（これは Zod v4 構文ですが、現プロジェクトは v3 系のため壊れます）。Q5_K_M では同じプロンプトで正しい構文を出力しました。1日に数十回呼び出すコード補完で、こうした「微妙に間違える」頻度が減ることは、tokens/sec の差より体感の生産性に大きく効きます。
# 私が実際に使っている llama.cpp 起動コマンド（Q5_K_M）
./llama-server \
-m ~/models/gemma-4-9b-it-Q5_K_M.gguf \
--port 8080 \
--ctx-size 8192 \
--threads 8 \
--n-gpu-layers 99 \
--host 127.0.0.1
# 期待出力: HTTP server listening on 127.0.0.1:8080
# RSS は起動直後で約 5.8GB、推論中で 6.3GB 前後このコマンドで起動して Antigravity の MCP 設定から http://127.0.0.1:8080/v1/chat/completions を OpenAI 互換エンドポイントとして登録すれば、エディタ内の AI 補完が Gemma 4 ローカルに切り替わります。
Antigravity 側の設定で押さえておくべきこと
llama.cpp 側の量子化選択と並んで、Antigravity 側の設定でも体感を左右するポイントがあります。
第一に、max_tokens を 2048 程度に絞ることです。Antigravity のデフォルトでは 4096 になっていることがありますが、ローカルモデルでは長文出力ほど誤りが累積しやすく、また体感速度も落ちます。コード補完用途なら 1024〜2048 で十分です。
第二に、temperature を 0.2〜0.3 に下げることです。Gemma 4 の Q5_K_M はデフォルト（0.7）だと若干雑な提案を混ぜてくることがあり、コード生成では低温の方が安定します。
// Antigravity の MCP 設定例（settings.json 抜粋）
{
"mcpServers": {
"gemma4-local": {
"url": "http://127.0.0.1:8080/v1/chat/completions",
"model": "gemma-4-9b-it-Q5_K_M",
"maxTokens": 2048,
"temperature": 0.25,
"stop": ["\n```\n", "</answer>"]
}
}
}
// 期待動作: コード補完が安定し、出力末尾の余計な解説が抑制されるstop トークンを設定しておくと、Gemma 4 が「ところで、このコードについて補足すると…」と勝手に解説を続ける挙動を抑えられます。コード補完用途では地味に効きます。
量子化以外で効くもう一つの設定 — --ctx-size とメモリの綱引き
量子化版を選んだあと、次に効いたのが llama.cpp の --ctx-size（コンテキスト長）の値でした。最初は「大は小を兼ねる」と思って 16384 で動かしていましたが、Q5_K_M だと RSS が 9GB を超えて、ビデオ会議中にスワップが発生し macOS 全体がもたつく事象が起きました。
--ctx-size を 8192 に下げたところ RSS は 6.3GB 前後に戻り、実利用での違和感はゼロでした。Antigravity から送るプロンプトの大半は 4k トークン以下なので、最悪ケースに合わせるよりも実際の利用シーンに合わせる方が体感が良くなります。長いファイル全体を読ませたい用途がある場合は、12288 あたりが Q5_K_M とのバランスが取れる中庸値だと感じています。
それでも Q4_K_M を選ぶ場面
Q4_K_M を完全否定したいわけではありません。次の2つのケースでは私も Q4_K_M を選びます。
- 電源のないカフェや移動中 — Q4_K_M は消費電力が少なく発熱も控えめです。長時間のフライトで電源が取れないとき、バッテリーが1時間長持ちする差は無視できません
- README やコメントの一括生成 — 短いドキュメントを大量に生成するバッチ処理では、速度の差が積み上がります。インタラクティブな補完と違って、間違いが混じってもレビュー段階でまとめて修正できるため、品質より速度を優先しても痛手が少ないです
エディタで対話的に使う用途では Q5_K_M、バッテリー最優先や大量バッチ処理では Q4_K_M、という使い分けが私のいまの落としどころです。
「公式は Q4_K_M を勧める」を鵜呑みにしない
公式の量子化選択ガイドは、おそらくサーバ側で多数の同時接続を捌くワーカー視点で書かれています。VRAM が貴重な GPU クラスタで複数モデルを同居させる前提なら、Q4_K_M を選ぶ理由は十分にあります。
しかし個人開発の Mac では、メモリは 16GB あれば Q5_K_M を載せても 10GB 弱が余り、Antigravity・Chrome・Slack を同時に動かしても破綻しません。同じ「バランス型」と言われる Q4_K_M と Q5_K_M でも、運用環境が変わると最適解が変わるという、当たり前のことを実機で確かめてから選ぶ価値はあると感じています。
私自身、最初は公式の推奨に従って Q4_K_M を3日間使っていましたが、コード補完で「ちょっと違う」修正が積み重なり、結果的に Q5_K_M に切り替えてからは打ち消しの回数が目に見えて減りました。
関連トピックへのリンク
ローカル LLM のメモリ運用や Antigravity との接続でさらに深掘りしたい方は、以下の記事も参考にしてみてください。
次に試してほしいこと
もしあなたも 16GB の Mac で Gemma 4 を Antigravity から使っているなら、まず Q5_K_M をダウンロードして llama-server を上記のコマンドで起動し、半日だけコード補完に使ってみてください。Q4_K_M とどちらが「ちょっと違う」修正の頻度が少ないか、実際のプロジェクトのコードベースで比べてみるのが、この選択を自分の手で確かめる一番確かな方法だと感じています。
私自身まだ Gemma 5 のリリース後にどう変わるかを観察している途中ですが、量子化版の選択は「ベンチマークの数字」より「自分の運用環境で1週間使ってみた体感」の方が信用できる、という小さな確信を、共有できたら嬉しいです。