Antigravity のローカル LLM 連携が落ち着いてきたので、5 月の連休に自分の環境を一度整理しました。Ollama、LM Studio、Gemma 4 の素の MLX 直叩き、と 3 通り併存していて、Mac mini M5 のディスクと RAM を取り合っていたためです。整理した結果と、その判断軸を残しておきます。
ローカル LLM の用途は、外に出したくない記事メモの下書きと、AdMob 関連の数値ログの整形が中心です。クラウド API に投げないぶん、機密性の高い内部処理を任せられるのがローカルを残す最大の理由でした。
整理を始めた動機
3 通り併存した状態は便利でしたが、次の問題が無視できなくなりました。
- モデルファイルが各ツールに重複保存され、Mac mini のディスクを 80 GB ほど食っていた
- どれかが起動していると他が動かない、というポート/メモリの取り合いが起きていた
- Antigravity からの呼び出し設定を 3 通り抱えていて、設定ミスの頻度が上がっていた
5 月の連休に、これを「何を残し何を捨てるか」決める時間に当てました。
判断軸 3 つ
私が採用した判断軸は次の 3 つです。
- 起動コストとアイドル時のメモリ占有
- Antigravity から見たエンドポイントの素直さ
- モデル更新の頻度と入手のしやすさ
これらに沿って 3 ツールを点数化し、勝者を 1 つ残しました。
1. 起動コストとアイドル時のメモリ占有
- Ollama: バックグラウンド常駐で 500 MB 前後、モデルロード時に 8 〜 14 GB
- LM Studio: GUI を立ち上げないと API が動かず、立ち上げただけで 1.5 GB
- Gemma 4 を MLX で直叩き: 自分でプロセスを管理する分シンプル、ただし設定が冗長
Mac mini M5 の 28 GB を 4 つの壁紙アプリ開発と共有しているので、アイドル時に動かないメモリは 1 GB でも惜しい状況でした。
2. Antigravity から見たエンドポイントの素直さ
Antigravity の localModels 設定にエンドポイントを書く際、Ollama は http://localhost:11434 に統一されていて挙動が予測可能でした。LM Studio はモデル切り替えのたびに UI で読み込み直す必要があり、自動化との相性が悪かったです。MLX 直叩きはサーバーを自分で書く必要があり、これだけで 1 時間取られます。
3. モデル更新の頻度
5 月時点で Ollama レジストリは Gemma 4 含む主要モデルがほぼ揃っており、ollama pull gemma-4:9b のような形で 1 コマンドで入手できます。LM Studio は MLX 最適化版が早めに来る利点があり、Apple Silicon ネイティブの推論速度では LM Studio のほうが速いケースもありました。
28 GB に何を載せるか — 量子化の選び方
28 GB の統合メモリで詰まりやすいのは、モデルそのものより「同時に開いている開発ツール」とのメモリ競合です。私は Gemma 4 を次の基準で量子化版ごとに使い分けました。
- 9b / Q4_K_M: 約 5.8 GB。常用。Xcode と Antigravity を開いたまま動かしても破綻しない
- 9b / Q8_0: 約 9.8 GB。精度がほしいときだけ。これを常駐させると Xcode のビルドで swap が走り始める
- 27b / MLX 4bit: 約 15 GB。LM Studio 側で長文整形のときだけ。これを開くなら他のモデルは必ず unload する
Ollama のロード済みモデルは ollama ps で確認できます。PROCESSOR 列が 100% GPU でなく CPU 混在になっていたら、それはメモリが足りずに CPU へこぼれているサインで、推論が一気に遅くなります。28 GB 機では「Q4 を常用、Q8 以上は単発」という線引きが、結局いちばん安定しました。
私が残したものと捨てたもの
3 つの軸を比較した結果、私は Ollama を default、LM Studio を補助 として残し、MLX 直叩きはひとまず捨てました。
具体的な構成は次の通りです。
Antigravity localModels:
- name: "gemma-4-9b-instruct (default)"
endpoint: "http://localhost:11434/v1"
model: "gemma-4:9b"
- name: "gemma-4-27b-mlx (heavy)"
endpoint: "http://localhost:1234/v1"
model: "lm-studio-loaded-model"通常は Ollama 経由の 9b を使い、推論精度がほしい長文整形だけ LM Studio の 27b MLX 版に切り替える運用です。LM Studio は使うときだけ手動で立ち上げる、というルールにしてアイドル時のメモリ占有を回避しました。
ポート競合をすぐ見分ける
3 ツール併存時にいちばん時間を溶かしたのが、「Antigravity からつながらない」ときの原因切り分けでした。Ollama は 11434、LM Studio は 1234 を使いますが、過去に立ち上げた別プロセスが居座っていることがあります。私は次の 1 行で先に犯人を特定するようにしました。
lsof -nP -iTCP:11434 -sTCP:LISTEN出てきた PID が ollama 以外なら、それが競合の正体です。Antigravity 側の設定を疑う前にこれを打つだけで、切り分けが数分で済むようになりました。エンドポイントが生きているかは curl -s http://localhost:11434/api/tags で、ロード可能なモデル一覧が JSON で返るかを見れば確認できます。
MLX 直叩きを捨てた理由
MLX 直叩きは技術的に面白く、私自身、最初の 2 週間は楽しんでいました。ただ、mlx_lm.server を自分で起動するスクリプトを書いて、ポートとログを管理し、リスタートを自前で書き、というオーバーヘッドを、個人開発の運営時間に乗せ続けるのは合理的ではないと判断しました。
複数の壁紙アプリと 4 つの Lab サイトを 1 人で見ていると、「自分で書いて自分で守るインフラ」は 1 つでも少ないほうがよい、というのが現実です。MLX 直叩きの推論速度メリットは、Ollama も内部で MLX を呼ぶようになって以降は実質縮小しており、現状は捨てる判断で問題ありませんでした。
アイドル時のメモリを OLLAMA_KEEP_ALIVE で締める
Ollama を default にしたあと、もう一段の効きどころが常駐モデルの保持時間でした。デフォルトでは最後の推論から 5 分間モデルをメモリに残しますが、私は記事を 1 本書く合間にしか呼ばないので、この 5 分が地味にメモリを握り続けていました。次の設定で保持時間を 60 秒に縮めています。
launchctl setenv OLLAMA_KEEP_ALIVE 60s
# 即時アンロードしたいときは
curl http://localhost:11434/api/generate -d '{"model":"gemma-4:9b","keep_alive":0}'これでアイドル時の占有が読めるようになり、Xcode のビルドとローカル推論が時間帯でぶつかっても swap に落ちにくくなりました。「常駐させるか、都度ロードするか」は機種の RAM 量で答えが変わるので、28 GB 機では短めに倒すのが私の結論です。
5 月のディスク削減実績
整理の実績は次の通りです。
- 重複モデルファイルの削除: 約 52 GB の解放
- LM Studio のキャッシュクリア: 約 8 GB
- MLX 直叩き用ファイルの削除: 約 18 GB
- 合計: 約 78 GB
Mac mini の SSD 残量が 30 GB ほど増えました。これで Xcode の derived data や Crashlytics の dSYM を気にせず置けるようになり、副次的な恩恵も大きかったです。
切り替え後の運用で感じた予期せぬ恩恵
整理後の運用で、当初想定していなかった恩恵が 2 つありました。ひとつは「Antigravity の動作が安定した」ことです。3 ツール併存時はポート競合の検出に時間を取られていましたが、Ollama だけに集約してからその時間がほぼゼロになりました。1 日あたり 10 分程度の小さな時間ですが、月で見れば 5 時間ほどの差になります。
もうひとつは「Mac mini の発熱が下がった」ことです。LM Studio を常駐させない運用にしたところ、アイドル時の CPU 温度が 5 度ほど下がり、Mac mini のファンが回る頻度が体感半分になりました。これは集中して記事を書く時間帯の作業環境としても地味に効きます。
個人開発で AI ツールを増やしていくとき、こうした「物理的な作業環境の質」も評価軸に入れるべきだ、というのが 5 月の整理で得た学びでした。ベンチマークの数字だけでツールを選ぶと、長く付き合ううちに見えない疲労として蓄積されます。
私の現状の運用
5 月末時点の構成は「Ollama (default) + LM Studio (重い処理時のみ)」のシンプルな 2 段構成で、壁紙アプリ群の機密ログ整形と、4 つの Lab サイト用の下書きメモにこの構成を使っています。Antigravity 側の localModels 設定はこれ以上増やさない、というルールも自分に課しています。
これからローカル LLM を Antigravity と組み合わせ始める個人開発者の方には、最初から 3 ツール並走をしないことをお勧めします。1 つだけ入れて 1 週間運用し、不足が見えてから 2 つ目を足す進め方が、結果的に時間とディスクの節約になります。
ツールを増やすことより、ツールを 1 つ「捨てる」判断のほうが、個人開発の運営では難しく価値があると感じます。共に学んでいけたら嬉しいです。