2026 年最新：Mac mini M4 クラスターのAI 推論性能 詳細ベンチマークレポート

ひとことで：シングル M4 の tok/s が足りているのに、並行リクエストと夜間バッチ処理でキューが溜まり始めたとき——「Mac mini をもう数台買ってクラスターにしたら、スループットは倍になるのか？」と考える人は多い。2/4/8 ノードの拡張曲線、フレームワーク差、実際の ROI を同じ表にまとめて説明している記事は少ない。以下ではテスト環境、シングルマシン基準、クラスター拡張、ボトルネック分解、デプロイチェックリストまで、再現可能な 2026 年版詳細ベンチマークを示す。

テスト結論サマリー

ZavCloud データセンター内で、Mac mini M4（24GB）4 台とCloud Mac M4 インスタンス 4 台を組み合わせた拡張可能テストベッド上で、同一ネットワーク・電源ポリシー下に 2 週間の負荷試験を実施。主な知見は以下の通り。

• リクエスト単位の並行処理はほぼ線形スケール：7B モデル、各ノード独立 Ollama インスタンス + Nginx ラウンドロビン、2/4/8 ノードの集約スループット拡張効率はそれぞれ 95% / 92% / 86%
• 単一の大モデルは「メモリを足し合わせ」できない：32B 以上のモデルは Apple Silicon 上でもシングルノード統一メモリの制約を受ける。クラスターは 24GB→64GB へのアップグレードの代替にならない
• MLX はシングルで速い、Ollama はクラスター運用向き：同一ノードで MLX は Ollama より約 8%–15% 速いが、Ollama の OpenAI 互換 API とホットアップデートはマルチノード編成に適する
• ボトルネックは算力からスケジューリングへ：8 ノード時、ロードバランシングとモデルコールドスタートがエンドツーエンド遅延の 25%–40% を占め、GPU/NPU 自体ではない
• ROI の転換点は並行バッチ処理：RAG 埋め込み、ログ要約などマルチテナントのオフラインタスクでは、4 ノードクラスターの 1,000 回推論あたりコストがシングルマシン比 約 38% 低い（アイドルとキュー待ちの分散）

なぜ「クラスター」を測るのか——シングルマシンだけでは不十分な理由

シングル M4 で 7B を回すのはすでに十分速い——以前のシングルマシン実測では 24GB・Swap なしで約 37 tok/s（qwen3:8b、デスクトップ背景負荷込み）。しかしチームが Ollama を「個人端末のおもちゃ」からプライベート推論サービス層へ昇格させると（Cloud Mac AI Stack L2 参照）、ボトルネックは次のように変わる。

• 複数 Agent / 複数 PR が同時にローカル API を呼び、リクエストがキューに
• 夜間バッチ（embedding、ログ要約）と日中の対話型推論が同一マシンを奪い合う
• SLA 要件：P95 遅延 < 2s で、シングルマシンが持たない

このとき「Mac mini をもう数台買う」は自然な発想。ただし Apple Silicon には NVIDIA 式 NVLink テンソル並列がなく、クラスターがどこまで伸びるかは同一環境・同一モデル・同一負荷の実測で答える必要があり、シングルマシン数値の外挿では足りない。

テスト環境とクラスタートポロジ

シングルマシン基準：M4 Mac mini 推論性能

拡張効率の分母はシングルマシン定常値。以下は今回のテストベッド上のシングルマシン基準（Ollama · Q4_K_M 量子化）。

これらの数値はクラスター拡張の理論上限参照：4 ノードが完全線形なら、7B 集約スループットは 4 × 58 ≈ 232 tok/s に近づくはず。

クラスタースケーリング実測（2 / 4 / 8 ノード）

シナリオ A：7B 対話型 API（並行 32 接続）

各ノードに llama3.2:7b-instruct-q4_K_M を事前ロード。クライアントは LB 経由で独立 prompt を送信し、集約 tok/sと単一リクエスト P95 遅延を計測。

拡張効率 = 実測倍数 / ノード数。8 ノードで 86% まで低下する主因は LB スケジューリングオーバーヘッド、偶発的なノードヘルスチェック除外、非常に高い並行時の入口帯域キュー。

シナリオ B：14B マルチテナント API（並行 16 接続）

シナリオ C：RAG バッチ埋め込み（オフラインスループット）

各ノードで nomic-embed-text を実行。クライアントは 10,000 件のドキュメントチャンクを一括投入し、件/分を計測。

バッチ埋め込みは M4 クラスターで ROI が最も高いシナリオの一つ：タスクは完全分割可能、対話型 TTFT 要件なし、夜間にフル稼働すればよい。

推論フレームワーク比較：Ollama vs MLX

本番提案：Ollama をオンライン API 層、MLX を夜間バッチ推論。同一クラスター内でノード役割を分けて共存可能。

並行処理とバッチ：3 つの実ワークロード

① マルチ Agent コーディングアシスタント（ピーク 8–12 QPS）

24/7 AI Coding Agent 型アーキテクチャ：Claude API が Diff を生成し、ローカル Ollama がログ要約とコード検索埋め込みを担当。シングル 16GB はピークで Swap 深刻；2 ノード 24GB クラスターで P95 を 4.2s から 2.1s に短縮。

② プライベート RAG サービス（日 50 万 token 埋め込み）

4 ノードで夜間インデックス再構築を 9 時間から 2.6 時間に短縮。日中の対話 7B クエリは 2 ノードを確保し、残りノードは夜間バッチモードへ切替（cron で stop → embed → 朝 restore）。

③ 社内 API ゲートウェイ（複数チーム共有）

チームごとに独立 API Key + レート制限、LB は least_conn で振り分け。8 ノードで約 35–40 並行対話（7B）を支え、超過時はキューまたは 429。

クラスターのボトルネックはどこか？

1. モデルコールドスタート：ノード再起動後の初回リクエスト TTFT は 8–15s（重みを統一メモリへロード）。緩和：ウォームアップスクリプト + ヘルスチェック通過後に LB プールへ参加
2. 統一メモリはクロスノード共有不可：GPU クラスターのようなテンソル並列は不可。各ノードがモデル完全コピーをロードする必要あり
3. 入口帯域：8 ノード集約 400 tok/s 時、インターネット 1Gbps がボトルネックになりうる（約 1.6 MB/s テキストストリーム、通常は十分；embedding ベクトル返送時は監視）
4. スケジューリング偏り：round_robin はリクエスト長が不均だとノード負荷が偏る。least_conn 推奨
5. 運用複雑度：N 台の macOS 更新、Ollama バージョン、モデル同期——Infrastructure as Code（Ansible / カスタムスクリプト）推奨

コストと ROI 分析

4 ノード × M4 Mac mini 24GB を例に、シングルマシンとクラスターの 3 年 TCO（電気代、運用人件費按分込み）を比較。

ROI 転換点：並行バッチ処理でシングルマシンのアイドルが < 40%、または対話 P95 が持続 > 3s のとき、2 台目は通常 6–9 か月で増分コスト回収（Cloud Mac 従量レンタル比）。4 ノード以上は明確なマルチテナントまたは SLA 要件が前提。

デプロイと運用の要点

最小可用クラスター（2 ノード）デプロイチェックリスト：

# 1. 安装 Ollama 并拉取模型
brew install ollama
ollama pull llama3.2:7b-instruct-q4_K_M
OLLAMA_HOST=0.0.0.0:11434 ollama serve &

# 2. 预热（加入 LB 前必须完成）
curl http://localhost:11434/api/generate -d '{"model":"llama3.2:7b-instruct-q4_K_M","prompt":"warmup","stream":false}'

# 3. 健康检查端点
curl -s http://localhost:11434/api/tags | jq '.models | length'

# /etc/nginx/conf.d/ollama-cluster.conf
upstream ollama_backend {
    least_conn;
    server 10.0.1.11:11434 max_fails=2 fail_timeout=10s;
    server 10.0.1.12:11434 max_fails=2 fail_timeout=10s;
}
server {
    listen 443 ssl;
    location / { proxy_pass http://ollama_backend; proxy_read_timeout 300s; }
}

• 監視：各ノードで ollama ps、Memory Pressure、Swap、tok/s（カスタム exporter）をエクスポート
• ローリング更新：ノードごとに drain → pull → warmup → join。全クラスターコールドスタートを避ける
• セキュリティ：API 入口に mTLS または API Key。Ollama はデフォルト無認証、インターネットへの無防備公開禁止
• CI と時間帯分離：Runner ビルドピーク時に LB プールから推論ノードを一時除外（メモリスケジューリング特集参照）

選定意思決定マトリクス

再現スクリプト

任意の M4 ノードでシングルマシン基準を再現し、必要に応じて LB バックエンドを拡張：

# 并发 32 · 每请求 256 token · 持续 5 分钟
wrk -t4 -c32 -d300s -s ollama_bench.lua http://lb.internal:443/

# 采样聚合 tok/s（解析 wrk 输出 + Ollama metrics）
python3 scripts/cluster_aggregate_tps.py --nodes 4 --duration 300

完全な benchmark 定義と指標口径は M4 Ollama シングルマシン実測 · 再現付録 を参照。クラスター拡張効率は定常 5 分以上サンプリングし、コールドスタートを除外することを推奨。