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 分钟以上采样，排除冷启动干扰。