入手 Mac Mini M4 之前，開發者最常搜尋的是：M4 Mac Mini 本機 LLM能穩定跑到哪個規模、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，供複現與引用。
本文不是「模型清單式總結」，而是一份含失敗樣本與 raw dump 的 Lab 記錄（2026-05-20 至 06-02）。資源：sample-benchmark-run.log、raw-vm-stat-dump.txt、ollama-debug-excerpt.log。
框架對照見《MLX vs Ollama 實測》；統一記憶體原理見《統一記憶體與 LLM 推理》。
一、系統因果模型與硬約束
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.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.43.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 ~294.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 reallocationWARN，單 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 模型庫已有對應 tag）。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:32b10.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？
活動監視器 → 記憶體 → 看「交換」是否持續成長；或 sysctl vm.swapusage。Swapins >0 且 tok/s 進入 §5 Phase 3（個位數），屬於 E2 壓力崩塌——應換較小模型或加記憶體，而非調整 temperature 等參數。
為什麼 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 / memorystatusresources/ollama-debug-excerpt.log— Ollama verbose + 失敗 sessionresources/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 推理（原理篇）