2026 年最新：Mac mini M4 叢集的AI 推理效能深度實測報告

一句話導讀：當單機 M4 的 tok/s 已經夠用、但並發請求和夜間批處理開始排隊時，很多人會問：再買幾台 Mac mini 組成叢集，吞吐能不能翻倍？很少有人把 2/4/8 節點的擴展曲線、框架差異和真實 ROI 放在同一張表裡講清楚。下文從測試環境、單機基線、叢集擴展、瓶頸拆解到部署清單，給出一份可重現的 2026 版深度實測。

測試結論速覽

我們在 ZavCloud 資料中心內，用 4 台 Mac mini M4（24GB） 與 4 台 Cloud Mac M4 執行個體 組成可擴展測試床，在相同網路與電源策略下跑了兩週壓測。核心發現如下：

• 請求級並行可接近線性擴展：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 節點叢集的每千次推理成本比單機低 約 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 張量並行，叢集到底能擴展多少，必須用同環境、同模型、同負載的實測回答，而不是 extrapolate 單機數字。

測試環境與叢集拓撲

單機基線：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 作夜間批推理，兩者可共存於同一叢集的不同節點角色。

並發與批處理：三類真實工作負載

① 多 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 停服 → 跑 embed → 晨間恢復）。

③ 內部 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 為例，對比單機與叢集的三年 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 分鐘以上採樣，排除冷啟動干擾。