Mac StudioのローカルLLMサーバーとMac miniのOpenClawをつないだイメージ

Article

Mac StudioでローカルLLMサーバーを立てて、OpenClawから使ってみた話

2026年4月3日
6 min read
#LLM#MLX#Mac Studio#OpenClaw#Gemma#Qwen

手元のMac Studio上でローカルLLMを動かし、それを別マシンのOpenClawからOpenAI互換APIとして呼び出す構成を試してみた。

やりたかったのはシンプルで、ローカルでそこそこ賢いモデルを常用できるかを確かめることだ。API課金を気にせず使えるし、手元で完結する安心感もある。もし実用レベルなら、普段のエージェント運用の幅がかなり広がる。

今回試したのは、Mac Studio M4 Max 64GBをモデルホストにして、Mac Mini M1上のOpenClawからアクセスする構成。結論から言うと、軽いチャット用途ならかなり有望だった。一方で、OpenClawのようにコンテキストが重いクライアントと組み合わせると、64GBではやや厳しいというのが正直な感想だ。

今回の構成

構成はこんな感じ。

[Mac Mini M1] ── 192.168.11.2:8080 ──▶ [Mac Studio M4 Max 64GB]
  OpenClaw                                mlx_lm.server
  （クライアント）                         （モデルホスト）

Mac Studio側では mlx_lm.server を立て、Mac Mini側のOpenClawからOpenAI互換APIとして呼び出す。OpenAI互換になっているおかげで、接続自体はかなり簡単だった。

サーバー起動コマンドはこんな感じ。

uvx --from mlx-lm mlx_lm.server \
  --model <model> \
  --host 0.0.0.0 \
  --port 8080

OpenClaw側では models.providers.mac-studio にOpenAI互換プロバイダーとして登録すればよい。つまり、やっていることは「自宅内に自分専用のLLM APIサーバーを生やす」感じに近い。

まず試したのはQwen3.5-35B-A3B

最初に試したのは Qwen3.5-35B-A3B。MoE（Mixture of Experts）系で、総パラメータ数のわりに軽く動かせるのが魅力だ。

結果をざっくりまとめるとこうなった。

量子化 メモリ 速度 品質 印象
8bit 43.7GB 普通 △ メモリがかなりタイト
4bit 18.4GB 速い ✕ 品質が伸びきらない

4bitは確かに軽かった。ただ、実際に応答を見ていると、品質のムラが気になる。特に日本語で使ったときに、「悪くはないけど、これを常用したいかというと微妙」という感触が残った。

MoEらしい軽さは魅力だったものの、今回は実用性重視で停止という判断になった。

Gemma 4 31Bは、かなり良かった

次に試したのが、2026年4月2日に出たばかりの Gemma 4 31B Dense。

これがかなり良かった。

量子化 メモリ 速度 品質 印象
8bit 約34GB 速い ◎ 品質はかなり良い
4bit 約20GB 遅い ○ 安定だが速度は落ちる

使っていてすぐ分かったのは、Qwenとは出力の安定感がかなり違うということだった。日本語も自然で、Denseモデルらしく変なムラが少ない。オープンモデルの中で高評価なのも納得感がある。

しかもApache 2.0ライセンスなので、用途面でも扱いやすい。個人的には「ローカルで常用する候補」として、一気に本命になった。

でも、OpenClawと組み合わせると64GBでは厳しかった

ここが今回いちばん大事なポイントだった。

Gemma 4 31B 8bit自体は、Mac Studio 64GBでも動く。軽いチャットUIから使うぶんには、体感もかなり良い。ところが、OpenClawからつなぐと話が変わる。

理由は単純で、OpenClawが送るコンテキストがかなり重いからだ。

新規セッションでも、実際には以下のようなものが毎回積まれる。

  • システムプロンプト
  • メモリ
  • ツール定義
  • 直近の会話履歴

その結果、こちらが contextWindow: 16384 のつもりでいても、実際には26,000トークン超のリクエストが飛んでくることがあった。

そして31Bクラスのモデルでは、この長いコンテキストがそのままKVキャッシュの巨大化につながる。

ざっくり言うと、

  • モデル本体：31B 8bitで約34GB
  • KVキャッシュ：11GB超まで膨らむ
  • 合計：45GB超

という感じで、64GBの統合メモリをかなり強く圧迫する。結果として、OpenClawとの併用ではOOMで落ちることがあった。

4bitなら動くけど、今度は遅い

では4bitにすればいいかというと、これも簡単ではなかった。

メモリ的にはかなり楽になる一方で、Apple Siliconでは4bit化したほうが必ずしも速くならない。むしろ今回の環境では、デクォンタイズのオーバーヘッドが目立ってしまい、体感速度は落ちた。

これは少し直感に反するけれど、Apple Siliconは統合メモリ帯域がかなり速いので、単純に「軽量化 = 高速化」にならない場面がある。

つまり今回の感触としては、

  • 8bit: 品質も速度も良いが、OpenClawではメモリが厳しい
  • 4bit: 動きはするが、速度面で気持ちよさが下がる

というトレードオフだった。

さらに、Gemma 4対応がまだPRブランチだった

もうひとつ現実的な問題があった。試した時点では、mlx-lm の公式版はまだGemma 4に完全対応しておらず、PR #1099 のブランチを使っていた。

そのため、複数リクエストを投げているとKVキャッシュまわりでshape mismatchが起きて、クラッシュすることがあった。

つまり今回の不安定さは、単純にハードウェア性能だけの問題ではなく、ソフトウェア側がまだ完全に追いついていないという要素も含まれている。

この点は、公式マージ後にかなり改善する可能性が高い。

64GB Mac Studioで見えた現実

今回の検証をざっくり整理するとこうなる。

シナリオ 判定
Gemma 4 31B 8bit + 軽いチャットUI ○ かなり有望
Gemma 4 31B 8bit + OpenClaw ✕ OOMで厳しい
Gemma 4 31B 4bit + OpenClaw △ 動くが遅い

つまり、64GBのMac Studioは「ローカルLLMを試す」にはかなり良いけれど、「重いエージェント基盤を常用する」には一歩足りないという印象だ。

逆に言えば、単体のチャットUIや軽いローカルアプリ用途なら、Gemma 4 31B 8bitでも十分に面白い。今回作った軽量なWeb UI経由では、かなり手応えがあった。

今後どうするか

次のアクションとして考えているのはこのあたり。

  1. mlx-lm 公式のGemma 4対応マージを待つ
  2. マージ後にもう一度同じ構成で再検証する
  3. もし本格運用するなら、128GB以上のMacを視野に入れる

特に3つ目は大きい。31Bクラスを8bitで余裕を持って常駐させつつ、OpenClawの重いコンテキストも受け止めるなら、やはり64GBでは少し心もとない。

まとめ

今回の検証で分かったのは、ローカルLLMの品質自体はもうかなり実用に近いということだった。特にGemma 4 31Bは、日本語も自然で、ローカルで回すモデルとしてかなり魅力がある。

ただし、実運用を考えるとモデル単体の性能だけでは足りない。クライアント側がどれだけ重いコンテキストを投げるかまで含めて考えないと、快適にはならない。

Mac Studio 64GBは、ローカルLLMのお試しや軽量チャット用途にはかなり良い。けれど、OpenClawのようなエージェント基盤と組み合わせて本気で常用するなら、もう少し上のメモリ容量が欲しくなる。

ローカルLLMは「もう使えるのか？」という問いに対しては、今回の答えはかなりYes寄りだった。

ただし、「どんな使い方でも余裕か？」と聞かれると、まだそこまではいかない。そんな、ちょうど面白い過渡期にいる感じがする。

おまけ：今回使った主な要素

  • モデルホスト: Mac Studio M4 Max 64GB
  • クライアント: Mac Mini M1 + OpenClaw
  • サーバー: mlx_lm.server
  • 試したモデル: Qwen3.5-35B-A3B / Gemma 4 31B
  • 通信方式: OpenAI互換API

このへんは、もう少し環境が安定してきたら設定例込みで別記事にまとめてもよさそう。

他の記事も読む