32GB Mac miniで動くローカルLLMとAgentの実際の限界

32GBのApple Silicon Mac miniでは、ローカルLLMを実用的に動かせます。ただし、モデルを読み込めることと、Agentのバックエンドとして安定して使えることは別です。手軽さを重視するなら8B〜14B、速度と能力を両立したいならA3B系MoEを検討します。

モデルサイズの目安

サイズ	32GB環境での位置づけ	向いている用途
8B〜9B	軽快で扱いやすい	会話、要約、抽出、単純なツール呼び出し
12B〜14B	最も無難な標準	コード補助、RAG、JSON、短いAgent
20B〜32B Dense	条件付きで利用可能	深い分析、低並列の処理
27B〜35B A3B MoE	調整すれば強力	高速なローカルAgent、複雑な単発タスク
70B Dense	日常用途には不向き	実験用

A3Bは、モデル全体のパラメータ数が大きくても、1トークンごとに約3B相当の専門家だけを選択して計算するMoE方式です。計算量と帯域負荷は下がりますが、重み全体を保存する必要があるため、メモリが3Bで済むという意味ではありません。

Apple Siliconでの構成

Ollamaは導入が簡単です。LM Studioはモデル比較、ローカルAPI、MCP連携に向いています。長時間の推論では、Apple Silicon向けのMLX/omlxが有力です。GGUFを扱う場合はllama.cppも選択肢になります。Ollama、MLX、llama.cpp、LM Studio

Qwen3.6-35B-A3Bを速く動かす構成

32GBのM4では、Qwen3.6-35B-A3Bの4bit版をMLX系ランタイムで動かす構成が有力です。ポイントは次の通りです。

1. MoEで1トークンあたり約3Bを計算する。
2. 4bit量子化で重みと帯域の負担を抑える。
3. MLX/omlxで統合メモリとGPUを活用する。
4. 小さなdraftモデルを使ったMTP/DFlash推測デコードを使う。
5. KV Cacheとツール結果の長さを制限する。

M5 32GB環境のテストでは、1Kプロンプトで約38.4 tok/s、4Kプロンプトで約33.1 tok/s、ピークメモリ約19GBという結果でした。これは特定のハードウェアと設定に依存する測定値です。

32GB M4 Mac miniの実使用感

通常の会話はほぼ問題ありません。一方、長いツールループ、Shell実行、エラーからの復旧を含むAgentでは不安定さが出ます。現実的には、ローカルモデルは会話、要約、文書処理、低リスク自動化に使い、プログラムの本格的な自動化はオンラインモデルを中心にする構成が安定します。

テストしたモデルの中では、Qwen3.6-35B-A3B-uncensored-heretic-vision-11mfan46:Q4_K_Mが比較的高速で、画像生成にも使えました。

「A tool message must follow an assistant tool call」のようなエラーは、モデルの能力だけでなく、ツールプロトコル、チャットテンプレート、Parser、Shellのタイムアウト設定が原因になることがあります。

用途別のおすすめ順

用途	おすすめ順
安定した簡単なAgent	Qwen3 14B → Qwen3.5 9B → Gemma 3 12B
速度重視の自動化	Qwen3.6-35B-A3B 4bit → Qwen3-30B-A3B Q4 → Qwen3.5 9B
中国語のツール呼び出しとJSON	Qwen3.6-35B-A3B → Qwen3-30B-A3B → Qwen3 14B
長文・RAG	Qwen3 14B → Gemma 3 12B → Qwen3.6 A3B
深い推論	Gemma 4-26B-A4B → Qwen3.6-35B-A3B → Qwen3 14B
調整なしで使う	Qwen3 14B → Gemma 3 12B → Qwen3.5 9B

結論

調整を減らして安定性を優先するならQwen3 14Bです。MLX/omlx、draft、KV Cache、コンテキスト長を調整できるならQwen3.6-35B-A3B 4bitが有力です。A3Bは計算効率を高めますが、32GB環境のメモリとAgent連携の制約をなくすものではありません。

参考資料

• Apple Mac mini仕様
• Ollama macOSドキュメント
• Apple MLX
• llama.cpp
• LM Studioドキュメント