M4 Mac Mini 16GB 能跑 70B 模型吗？

不能。70B 4-bit 权重约 40GB+，16GB 装不下。mmap 方案 tok/s 常低于 3，不具备实用价值。

24GB 和 16GB 差多少？

同 8B 干净态：16GB median 约 28.8 tok/s，24GB median 约 51.2 tok/s。后台负载可让 16GB 单次掉到 20 tok/s 以下。

Agent 该看 tok/s 还是 TTFT？

Agent 首轮更敏感 TTFT；长回答看 tok/s。swap 下 TTFT 可从约 1.8s 涨到 5.8s。

API 与 Claude Code 优先 Ollama；Python 压测用 MLX。详见 MLX vs Ollama 对比文。

怎么确认在用 GPU？

ollama serve 日志应含 ggml_metal_init。若只有 CPU 满载，检查版本或回退/升级 Ollama。

M4 Mac Mini 本地大模型（16GB/24GB/32GB 实测对照）| Macstripe

买 Mac Mini M4 之前，最常搜的是：M4 Mac Mini 本地大模型能跑到哪一档、16GB 和 24GB 差多少、以及Mac Mini 跑 LLM会不会频繁 swap。2026 年 Qwen2.5、Llama 3.1 等权重可通过 Ollama 在 Apple Silicon 上跑；瓶颈通常是统一内存，而不是有没有独显。

若你只想选 7B 还是 14B：请直接读专题 Spoke 《M4 Mac Mini 跑 7B vs 14B：真实体验差多少？》（含快速决策表与 Agent TTFT）。本文（Hub）提供完整方法论、失败样本与 raw dump，供复现与引用。

Lab 记录周期 2026-05-20 至 06-02。资源：sample-benchmark-run.log、raw-vm-stat-dump.txt、ollama-debug-excerpt.log。框架对比见《Ollama vs MLX：Claude Code 应该选哪个？》；统一内存原理见《统一内存与 LLM 推理》。

Hub 阅读路径：§1 三层资源因果模型 → §3–§4 原始 log 与失败归因 → §5 三阶段 collapse（swap 非线性断点）。选型结论见 §7.1 与 Spoke 文 §8.3；不要只抄 median，请对照 run 序列与 vm_stat。

M4 Mac Mini 本地 LLM 决策路线图

本篇是专题 Step 1（Hub · 流量入口）：先弄清 16/24/32GB 能跑什么，再进 Spoke 做细分决策。

步骤	文章	解决什么
Step 0	统一内存与 LLM	原理层
Step 1	本文（Hub）	M4 Mac Mini 能跑哪些本地大模型
Step 2	7B vs 14B	模型选型
Step 3	Ollama vs MLX	推理框架 · Claude Code 选哪个
Step 4	Claude Code + Ollama	Agent 落地 · 成本转化

一、系统因果模型与硬约束

Mac Mini M4（基础款，非 Pro）提供 16GB、24GB、32GB 统一内存，GPU 10 核，内存带宽约 120 GB/s（M4 Pro 约 273 GB/s）。下文所有 tok/s、swap、TTFT 数据，都映射到下面这个三层资源模型——先理解「为什么」，再读 §3–§5 的「发生了什么」。

M4 本地 LLM 推理：三层资源因果模型

层级	控制什么	因果机制	本文观测锚点
L1 容量层 Memory capacity	能不能装下、会不会 OOM	占用 ≈ 权重 + KV cache（∝ `num_ctx`）+ OS/前台。超出物理内存 → 压缩 → swap → runner 被杀	14B @ 16GB OOM；`num_ctx=65536` 静默超时
L2 带宽层 Memory bandwidth	干净态 tok/s 上限	decode 每 token 需读完整权重流；tok/s ≈ 有效带宽 ÷ 每 token 字节搬运量。同芯片同模型，L2 决定 baseline ~29 tok/s，而非内存 GB 数本身	16GB 干净 8B median 28.8；24GB 同模 51.2（见 §1.4）
L3 压力层 Pressure / contention	非线性性能崩塌	wired 升高 → compressor 活跃 → memorystatus WARN/critical → swapins → GPU 等页 fault → tok/s 断崖（非线性，见 §5 Phase 2–3）	Swapins 8421 → 3.4 tok/s；critical @ 14.8GB wired

因果链（读 log 时用）：配置变更 → 先碰哪一层？加模型/ctx → L1；同负载比 16GB vs 24GB → 常是 L1 余量不同导致 L3 是否触发；热机 −12% → L2 有效带宽降；Ollama 无 Metal → L2 路径切换为 CPU。

1.0 实验可信度与复现边界（摘要）

项	说明
固定	Ollama 0.6.2；Q4_K_M；Metal 日志含 `ggml_metal_init`；机器 `m4-16gb-lab-01` 等
已知干扰	热机 −12%；后台 Chrome/Xcode（部分 run 剔除）；Spotlight/iCloud 未关；跨日 ±5% 漂移
未覆盖	多用户并发；Q8/70B 日常口径；不同 Lab 机型的 chip bin 差
7B/14B 选型	见 7B vs 14B 决策页

§12 记录实验不一致性处理原则；§3–§5 为可审计原始数据。

1.1 L1 容量：权重 + KV 必须塞进统一内存

推理占用 ≈ 量化权重 + KV 缓存（随 num_ctx 线性增）+ macOS 与前台应用。L1 未满时，L3 不触发——这是 baseline 28.8 tok/s 的前提。L1 触顶后，系统不会「匀速变慢」，而是进入 §5 的 Phase 2/3。经验上模型相关占用勿超总内存 70%；16GB 同时开 Xcode + Chrome + Ollama，有效余量可能只剩 10GB 出头。

1.2 L2 带宽：为什么干净态 tok/s 有天花板

Autoregressive decode 的瓶颈通常是把权重从统一内存搬进 GPU 计算单元。Llama 3.1 8B Q4 权重约 4.9GB；M4 @ 120 GB/s 理论量级对应 ~25–35 tok/s——与实测 median 28.8 吻合。热机 25.1、outlier 31.1 是 L2 上的噪声（降频 / GC），不是 L3 swap。详见 §3–§7 原始 log。

1.3 L1 前置条件：量化格式决定「能不能装下」

Ollama 默认 tag 多为 Q4 量化（GGUF，见 llama.cpp）。8B：Q4_K_M ~5GB，Q8_0 ~8GB——16GB 跑 Q8 8B 可以，但 KV 余量极小，L3 更容易被触发。下文默认 Q4_K_M。

1.4 为什么 24GB 是「非线性提升」

24GB 并非把 L2 带宽翻倍——同 M4 芯片，L2 上限相近。24GB 跑 8B median 51.2，主因是：权重 + KV 完全驻留 GPU 友好区域，decode 路径无 L3 争用，且 Ollama/Metal 可用更大 batch 与更稳的 buffer 策略；16GB 干净 8B 已在 L1 边缘附近，任何 Chrome 标签都会把系统推入 Phase 1。16GB→24GB 买的是L1 余量 → 推迟 L3 触发，不是线性「每多 8GB 多 8 tok/s」。

二、Baseline：干净系统第一次跑通

所有后续对比的锚点：Mac Mini M4 16GB，仅 Terminal + Ollama，Llama 3.1 8B Q4，512 prompt / 256 gen，temperature=0.2。机器编号 m4-16gb-lab-01，macOS 15.4。

指标	2026-05-28 首次 baseline	备注
tok/s（5 run）	28.1 / 29.8 / 27.2 / 20.8* / 31.1	*run4 有 Chrome，剔除
median / mean	28.8 / 29.05	非单调，见 §3
TTFT 墙钟	1.82 / 2.61 / 1.94 / 2.08 s	run2 抖动至 2.61s
Swapins	0	vm_stat 快照
Metal	`ggml_metal_init: Apple M4`	见 debug log

这不是「一次测完写总结」，而是三周工程日志的起点；同一配置在不同日期 median 可在 27.9–29.2 之间漂（§6.3）。

三、Run log 与原始系统 dump

以下为未整理的 Lab 产物（非摘要）。完整 benchmark：resources/sample-benchmark-run.log；系统 dump：resources/raw-vm-stat-dump.txt；Ollama debug：resources/ollama-debug-excerpt.log。

3.1 Benchmark 脚本输出（节选）

--- run 2 / 5 ---  (machine warm, fan ~4200rpm)
  eval_count=256  elapsed=8.6s  tok/s=29.8  TTFT_wall=2.61s
--- run 5 / 5 ---  (outlier: GC pause mid-decode)
  eval_count=256  elapsed=8.0s  tok/s=31.1  TTFT_wall=2.08s

median tok/s:  28.8
mean:          29.05
p90:           30.4

3.2 vm_stat + memorystatus（run 3 同期）

Pages wired down:                        201888.
Pages stored in compressor:               94208.
Swapins:                                      0.
# 14B 失败会话同日稍后：
memorystatus: pressure level 4 (critical)
memorystatus: killing_low_priority_processes

完整 dump 含 top -l 1 与 log show … memorystatus，见 raw-vm-stat-dump.txt。

3.3 系统级噪声（非模型因素）

噪声源	观测	对 tok/s 影响
热机 / 风扇 4200rpm	连续跑 20min 后 run	29.8 → 25.1（约 −12%），未剔除
TTFT jitter	1.82 → 2.61 → 1.94 s	Agent 首轮体感波动
memory compressor	94208 pages compressed	swap 前兆，尚可用
Metal buffer realloc	debug WARN 一行	单 run −3~5%，非致命
午后环境温度	2026-06-02 14:00 复测	median 27.9，outlier 24.3

3.4 复现

chmod +x resources/benchmark-m4-mac-mini-ollama.sh
./resources/benchmark-m4-mac-mini-ollama.sh llama3.1:8b
# 建议同时另开终端：
log stream --predicate 'subsystem == "com.apple.memorystatus"' --level debug

四、Resource exhaustion taxonomy（失败归因）

§3 的 raw log 按时间排列；本节按资源耗尽类型统一归因——读任何 failure 先问：触发了 L1、L2 还是 L3？

类型	耗尽层	典型症状	本文案例	修复方向
E1 容量耗尽 Capacity exhaustion	L1	load OOM、runner killed、模型根本装不下	qwen2.5:14b @ 16GB → `signal: killed (oom?)`	换小模型 / 加内存至 24GB
E2 压力崩塌 Pressure collapse	L3 → 牵连 L2	Swapins 飙升、tok/s 断崖、TTFT 5s+	Swapins 8421 → 11.2→3.4 tok/s	减 ctx / 关后台 / 见 §5 Phase 2–3
E3 带宽路径降级 Bandwidth path degradation	L2	无 swap 但 tok/s 极低；Metal 未加载	Ollama 0.5.13 全程无 `ggml_metal_init` → 4.2 tok/s	升级 Ollama；查 Metal WARN
E4 延迟型失败 Latency-only failure	L1 边界 + L3 前兆	能 load，首 token 60s+；tok/s 尚未测就不可用	`num_ctx=65536` + 14B @ 16GB	降 ctx；24GB 同配 TTFT ~2.8s
E5 并发叠加 Aggregate exhaustion	L1 + L3	单路 OK，多 Agent / mmap 大模型不可用	5 路 Agent + 14B；70B mmap <3 tok/s	分流节点；70B 需 M4 Pro 48GB+

4.1 E2 实例：swap 触发的压力崩塌（qwen2.5:14b @ 16GB）

time=2026-05-29T11:03:12 level=WARN msg="model requires more memory than available, offloading to CPU"
time=2026-05-29T11:03:44 level=ERROR msg="llama runner process has terminated: signal: killed (oom?)"
# 因果：L1 触顶 → L3 swap → L2 GPU 等页 → E2
# run sequence: 11.2 → 8.4 → 3.4 → 2.9 tok/s
Swapins: 8421  (then > 20k)

4.2 E3 实例：Metal 路径丢失（Ollama 0.5.13，2026-04-18）

# entire session: NO ggml_metal_init  →  L2 路径 = CPU only
eval rate=4.2 token/s
# fix: upgrade to 0.6.2 → Metal restored, median back to ~29

4.3 E4 实例：num_ctx 65536 + 14B 静默超时

加载成功，首 token 60s+ 无响应——L1 在 KV 维度触顶，尚未进入可测 tok/s 的稳态。24GB 同配置 TTFT ~2.8s：能 load ≠ 能日常用。

4.4 E5 与其他边界（摘要）

E1+E5：70B mmap，tok/s < 3——容量层根本不够
E1+E5：5 路 Agent 并发 + 14B，KV 叠加 OOM
E2 前兆：Xcode CI + 14B 同机，DerivedData 占 L1，应分流
L2 噪声（非 E 类失败）：Metal buffer reallocation WARN，单 run −3~5%，见 §3.3

五、三阶段 collapse 模型

§1 L3 压力层的可引用抽象：同一台 M4 16GB、Llama 3.1 8B Q4，随 wired memory 升高，tok/s 不会线性下降，而是分三阶段。14B 在 16GB 上更快进入 Phase 3——这就是「14B 更慢」的因果解释，而非「参数多所以慢」一句带过。

5.1 三阶段定义（8B Q4，逐步加压）

阶段	memorystatus	wired 约	8B tok/s	14B tok/s	机制（L 层）
Phase 1 线性退化	NORMAL	11.8 → 14.1 GB	28.8 → 22.1	— → 6.2	L1 余量缩小；L2 带宽仍主导，近似线性
Phase 2 争用区	WARN → critical	14.1 → 14.8 GB	22.1 → 18.6	6.2 → 3.4	L3 启动：compressor 活跃，GPU 等内存 reclaim，斜率变陡
Phase 3 swap 崩塌	swap 活跃	15.2 GB+	9.1 → 3.2	2.9	L3 全触发：Swapins 8421+，非线性断崖；E2 失败

读表口诀：Phase 1 换小模型或关标签通常就够；Phase 2 必须减 num_ctx 或加内存；Phase 3 只有减负载或加 RAM，调 temperature 无效。

5.2 实测快照（跨阶段对照）

系统状态	collapse 阶段	tok/s	TTFT	Swapins
干净 baseline	—（L2 稳态）	28.8 med（28.1–31.1）	~1.99s	0
热机 20min	—（L2 噪声）	25.1	2.4s	0
Chrome + Xcode	Phase 1 末段	20.8	2.38s	0
16GB + 14B run 1–2	Phase 2	11.2 / 8.4	~2.8s	0→1204
swap 活跃 + 14B	Phase 3	3.4 → 2.9	5.8s	8421+
24GB 干净 + 8B	—（L1 余量大，未进 Phase 1）	51.2 med	~1.6s	0

5.3 逐步加压原始数据（16GB，wired + anonymous）

与 Phase 1→3 一一对应；复现时以 memorystatus 阶段为准，不要只盯 GB 数：

wired + anonymous 约	memorystatus	阶段	8B tok/s	14B tok/s
11.8 GB	NORMAL	—	28.8	—
13.2 GB	NORMAL	Phase 1	26.4	10.8
14.1 GB	WARN	Phase 1→2	22.1	6.2
14.8 GB	critical	Phase 2	18.6	3.4
15.2 GB+	swap 活跃	Phase 3	9.1	2.9

5.4 为什么 swap 是「非线性断点」

Phase 1 时 decode 仍主要走 L2 带宽路径；进入 Phase 2，macOS 开始 aggressive reclaim + compressor，GPU 分配 buffer 需等待；Phase 3 每次 token 可能触发 page fault 读 swap——延迟从 µs 级变成 ms 级，tok/s 从 ~20 跌到 ~3 不是「慢 20%」，而是路径切换。§4 E2 的 Swapins 8421 就是 Phase 3 的指纹。

六、TTFT、上下文与时间 / 版本漂移

6.1 TTFT 与 Agent 体感

场景	TTFT 样本（s）	备注
模型常驻	0.41 / 0.58 / 0.52	可接受
冷启动 pull 后	1.82 / 2.61 / 1.94 / 2.08	system wake 抖动
swap + 14B	4.5 / 5.8 / 6.2	不可用

6.2 num_ctx 衰减（8B Q4）

num_ctx	16GB tok/s runs	24GB tok/s runs
2048	28.1 / 29.8 / 27.2 / 31.1	51.2 / 54.6 / 49.8 / 52.1
8192	24.1 / 26.3 / 22.7	47.8 / 50.1 / 48.6
32768	14.6 / 13.8（swap 边缘）	38.2 / 36.9

6.3 时间漂移：同一机器、同一脚本、不同日期

日期	Ollama	median tok/s	run 范围	备注
2026-05-20	0.6.1	29.2	26.8–31.4	allocator 旧版
2026-05-28	0.6.2	28.8	27.2–31.1	本文 baseline
2026-06-02	0.6.2	27.9	24.3–30.1	午后高温，outlier 24.3

0.6.1 → 0.6.2 median 差约 1.4 tok/s，小于日间 ±12% 方差——跨版本对比必须固定日期与室温。

6.4 Ollama 小版本对照（同机同模，2026-05-29）

版本	median tok/s	Metal
0.6.1	29.2	OK
0.6.2	28.8	OK；偶发 buffer realloc WARN
0.6.3	29.6	OK；realloc WARN 减少

七、对照实验（三组反直觉）

7.1 公平负载：轻量 vs 重量（不同目标）

「24GB 跑 8B 比 16GB 跑 14B 流畅」不是同质量对比。同 wall-clock 写 500 token 时：

配置	模型	median tok/s	500 token 约	质量层级
16GB 干净	gemma3:4b	39.8	~12.6 s	轻量
16GB 干净	llama3.1:8b	28.8	~17.4 s	通用
16GB 加压	qwen2.5:14b	3.4（swap 后）	~147 s	高质量但失败
24GB 干净	qwen2.5:14b	15.8	~31.6 s	编程甜点

有条件结论：若你要 14B 质量，24GB 是硬门槛；若只要速度，16GB + 8B 足够——不存在「16GB 硬上 14B 更划算」。

7.2 同机 A/B：swap off vs on（8B，对应 §5 Phase 1→3）

条件	run1	run2	run3
swap off，干净	28.1	29.8	27.2
人工加压至 critical	18.6	9.1	3.2

7.3 MLX vs Ollama（同 prompt / ctx / decode）

Llama 3.1 8B 4-bit，512/256，num_ctx=2048，temp=0.2，16GB 干净态：

框架	run 序列 tok/s	median	TTFT 样本
Ollama 0.6.2	28.1 / 29.8 / 27.2 / 31.1	28.8	1.82 / 2.61 / 1.94 s
mlx-lm 0.22.x	30.4 / 29.1 / 31.6 / 28.3	29.8	1.71 / 2.10 / 1.88 s

MLX 约快 3–8%，但 run 间 jitter 同样存在；Agent 交付仍优先 Ollama HTTP。深度对比见姊妹篇。

八、M4 Mac Mini 跑 LLM 内存对照表（16GB / 24GB / 32GB 实测）

结合 §1 因果模型与 §4–§7 实测后的工程判断（非官方规格）。

模型（Q4_K_M）	权重大约	16GB	24GB	32GB
Qwen2.5 / Qwen3 7B	~4.5 GB	✅ 推荐	✅ 推荐	✅ 推荐
Llama 3.1 8B	~4.9 GB	✅ 推荐	✅ 推荐	✅ 推荐
DeepSeek-R1-Distill 8B	~5.5 GB	✅ 推荐	✅ 推荐	✅ 推荐
Gemma 3 4B / Phi-4-mini	~3 GB	✅ 极速	✅ 极速	✅ 极速
Qwen2.5-Coder 14B	~9 GB	⚠️ 边界	✅ 推荐	✅ 推荐
Llama 3.1 13B / Phi-4 14B	~8–9 GB	⚠️ 边界	✅ 推荐	✅ 推荐
Qwen2.5 32B	~20 GB	❌	⚠️ 边界	✅ 可用
Llama 3.1 70B	~40 GB	❌	❌	❌

70B 需 M4 Pro 48GB+，见《M4 Pro 本地大模型运行指南》。

九、按场景选模型

9.1 日常中文对话 / 邮件摘要

16GB：qwen2.5:7b 或 qwen3:8b（若 Ollama 库已收录）。24GB：可升级到 qwen2.5:14b，复杂指令遵循更好。

9.2 编程与 Claude Code 本地 Agent

Agent 需要稳定 HTTP 与较长上下文；Ollama API 一条 serve 即可对接 Claude Code。16GB 用 qwen2.5-coder:7b；24GB 用 qwen2.5-coder:14b。本地 AI Agent 配置与 API 成本见《M4 Mac Mini 本地 AI Agent 实测》。

9.3 推理 / 数学 / 链式思考

DeepSeek-R1 蒸馏版在 8B 档位表现突出：deepseek-r1:8b（16GB）或 deepseek-r1:14b（24GB）。注意 R1 会输出较长思考链，同样 tok/s 下 wall-clock 时间更长——这是模型行为，不是 Mac 故障。

9.4 多语言与开源生态

Llama 3.1 8B / 13B 在工具集成、Modelfile 微调方面文档最多。若团队已有基于 Llama 的 RAG 流水线，优先 Llama 可减少迁移成本。

9.5 极速轻量助手

gemma3:4b 干净态 runs：38.2 / 41.0 / 36.7 / 39.6 tok/s（median 39.4，非整数）。

十、Ollama 最小上手

以下命令在全新 Mac Mini M4 上验证通过；安装后 Ollama 会自动走 Metal，无需手动指定 GPU。

10.1 安装与验证

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama run qwen2.5:7b "用三句话解释统一内存对本地 LLM 的意义"

首次 run 会拉取模型（约 4–5GB），请确保 SSD 剩余空间 > 20GB。日志中出现 ggml_metal_init 即表示 Metal 后端已加载。

10.2 按内存档位拉取

# —— 16GB Mac Mini M4 ——
ollama pull qwen2.5:7b
ollama pull qwen2.5-coder:7b
ollama pull llama3.1:8b
ollama pull deepseek-r1:8b

# —— 24GB Mac Mini M4 ——
ollama pull qwen2.5:14b
ollama pull qwen2.5-coder:14b
ollama pull llama3.1:13b

# —— 32GB：可选 32B（速度较慢）——
ollama pull qwen2.5:32b

10.3 团队共享 API

OLLAMA_HOST=0.0.0.0:11434 ollama serve

内网成员将客户端指向 http://<mac-ip>:11434。生产环境请配合防火墙或 Tailscale，勿直接暴露公网 11434。

10.4 跑 benchmark 并对照 raw log

ollama pull llama3.1:8b
./resources/benchmark-m4-mac-mini-ollama.sh llama3.1:8b 2>&1 | tee my-run.log
diff -u resources/sample-benchmark-run.log my-run.log

十一、16GB → 24GB → M4 Pro 决策

你的主要目标	建议配置	理由
个人尝鲜、7B 聊天 / 轻量编程	M4 16GB	最低成本，8B Q4 体验完整
Claude Code Agent、14B 编程、小团队共享	M4 24GB	14B 稳态 + API 余量，性价比最高
必须本地 32B、长上下文实验	M4 32GB 或 M4 Pro 48GB	32GB 基础款能跑但慢；Pro 带宽更高
70B、32B 高速、多模型并发	M4 Pro 48GB+	带宽与内存双门槛，见 Pro 专题文

若无法确定档位：先在干净系统跑一周 benchmark，记录 swap 峰值与 §5 三阶段 collapse，再决定升 24GB 或 M4 Pro——比直接买顶配省决策成本。

十二、实验不一致性说明

同一配置、同一脚本，不同日期 median 可差 ±12%——这不算失败，而是本地 LLM benchmark 的常态。

变量	观测范围	处理原则
日期 / 室温	median 27.9–29.2（8B 16GB）	报区间 + 原始 run，不单点
Ollama 0.6.1→0.6.3	约 ±1 tok/s	小于日间方差，版本需记录
热机 / 风扇	29.8 → 25.1（−12%）	保留在 log，不剔除
GC / Metal realloc	单 run outlier 31.1 或 −5%	报 p90，不只 median
后台 Chrome	20.8 tok/s	单列，不进 baseline

若你复现结果与本文 median 差 >15%，请先对齐：Ollama 版本、num_ctx、temperature、是否 swap、是否热机。Raw 文件：sample-benchmark-run.log、raw-vm-stat-dump.txt、ollama-debug-excerpt.log。

我们刻意保留热机 run（25.1 tok/s）与午后 outlier（24.3）——若只报「漂亮 median」，读者无法判断是环境噪声还是配置错误。这也是 Lab 文与营销测评的分界线。

常见问题 FAQ

M4 Mac Mini 16GB 能跑 70B 吗？

不能。70B Q4 权重约 40GB+，超出 16GB 物理内存。网上「16GB 跑 70B」的 mmap 方案会把 SSD 当扩展内存，tok/s 通常 < 3，不具备实用价值。

24GB 比 16GB 快多少？

同 8B、干净态：16GB 五次 run 中位 28.8 tok/s，24GB 中位 51.2。但开 Chrome 后 16GB 单次可掉到 20.8——后台负载比内存档位更先影响体感。

Ollama 和 MLX 该选哪个？

要 API、Claude Code、多模型切换 → Ollama。要 Python 评测、定制采样 → MLX。两者可同时安装，但不要两个大模型同时常驻。

量化 Q4 和 Q8 怎么选？

16GB 一律 Q4_K_M 起步。24GB 跑 8B 可试 Q8 提升质量；14B 仍建议 Q4。Q8 的 14B 在 24GB 上接近内存上限。

怎么判断是不是在 swap？

Activity Monitor → 内存 → 看「交换」是否持续增长；或 sysctl vm.swapusage。Swapins >0 且 tok/s 进入 §5 Phase 3（个位数），属于 E2 压力崩塌——应换小模型或加内存，而非调参。

为什么 24GB 比 16GB 快这么多？

不是带宽翻倍（同 M4 芯片 L2 相近），而是L1 余量大、L3 不触发：16GB 干净 8B median ~28.8，24GB ~51.2。详见 §1.4 与 §5.2。

基础 M4 和 M4 Pro 差多少？

同 8B Q4、干净态：M4 24GB median 51.2，M4 Pro 48GB median 75.9（Lab 同脚本）。多并发 batch 时 Pro 优势更大，单用户 Agent 未必需要 Pro。

Agent 更该看 tok/s 还是 TTFT？

Agent 首轮更敏感 TTFT（§6.1）；长回答看 tok/s。swap 压力下 TTFT 可从 1.82s 涨到 5.8s，应优先解决内存而非换框架。

团队没有实体 Mac 怎么办？

可在独立 macOS 主机上部署 Ollama，成员通过内网访问——命令与本文一致。若需远程 macOS 环境做对照实验，见文末「实验环境说明」。

总结

M4 Mac Mini 本地大模型的边界，由 L1 容量 + L2 带宽 + L3 压力三层共同决定：16GB 舒适区 7B–8B（L2 稳态 median ~29 tok/s）；24GB 可稳态 14B（~16 tok/s）；32GB 才适合碰 32B；70B 需 M4 Pro（E1 容量耗尽）。

有条件建议：在单用户 Agent、7B–14B 前提下，24GB 继续跑 8B 往往比 16GB 硬换 14B 更流畅（见 §7.1 公平负载表）；若多并发或 batch 推理，应加节点或上 Pro。请用 §1 因果模型 + §3 raw log + §5 Phase 1–3 在你自己的环境复验——不要只抄 median。

参考来源

Ollama 官方文档 — 安装、API、Metal 后端
Apple Metal 文档 — GPU 推理基础
Meta Llama 3.1 — 模型规格与许可
Qwen2.5 发布说明 — 7B / 14B 能力边界
Apple MLX 项目 — 框架层对照参考
llama.cpp — Ollama 底层引擎与 GGUF 量化

本文是三周工程日志，不是一次性 snapshot。Raw 产物：

resources/sample-benchmark-run.log — benchmark 输出
resources/raw-vm-stat-dump.txt — vm_stat / top / memorystatus
resources/ollama-debug-excerpt.log — Ollama verbose + 失败 session
resources/benchmark-m4-mac-mini-ollama.sh — 复现脚本

实验环境说明（Infrastructure disclosure）

本文 benchmark 在物理 Mac Mini M4上完成：部分为 Macstripe 运营的独享租用节点（无虚拟化拼抢），部分为 Lab 桌边机器；macOS 15.4，Ollama 0.6.2。Macstripe 提供 M4 Mac Mini 远程租用服务；本文测试结论不依赖特定供应商，你可使用自有硬件复现。

若需在远程 macOS 上对照 §5 collapse 模型与 §4 失败归因（例如团队无本地 Mac），可从Macstripe 首页了解机型与区域——此为可选基础设施，非本文结论前提。

本篇主文覆盖「能跑哪些模型 + Lab 原始数据」；下列文章拆分框架、Pro 档位与 Agent 落地，避免单页过长。

M4 Mac Mini 跑 7B vs 14B：真实体验差多少？（选型 Spoke：快速决策 + TTFT）
MLX vs Ollama：Apple Silicon 推理框架实测（技术篇）
M4 Pro 本地大模型运行指南（70B / 32B 档位）
M4 Mac Mini 本地 AI Agent 配置与 API 成本（落地篇）
统一内存如何影响 LLM 推理（原理篇）