M4 Mac Mini 跑 7B vs 14B：真實體驗差多少？（2026 實測）

很多人在 M4 Mac Mini 上選錯模型

我們在兩臺 Mac Mini M4（16GB 與 24GB）上用同一指令碼對 qwen2.5:7b 與 qwen2.5:14b 做了配對實測（2026-05-28 至 06-03）。先讀清「為什麼會崩」，再對照文末選型；原始日誌在§8.3 復現資源。更完整的記憶體崩塌模型見《M4 Mac Mini 本地大模型實測》。

先搞清三件事（再談 7B 還是 14B）

在給出具體模型 tag 之前，先把判斷框架擺正。本地體驗可以拆成：

• 會不會 swap（一票否決；比引數量優先）
• 首輪夠不夠快（TTFT）（Agent 多輪時往往比穩態 tok/s 更痛）
• 任務要不要更高質量（跨檔案程式設計才值得為 14B 付延遲）

很多人只盯著第三項「要不要 14B」，跳過前兩項——這正是選錯的起點。tok/s 主要回答「開始生成之後有多快」；若 swap 已發生，榜單數字不再代表日常體感。

選型流程圖（先 swap，再 Agent，最後才是 7B/14B）

先看記憶體會不會 swap，再看你是不是在做 Agent，最後落到 7B 還是 14B：

M4 Mac Mini 本地 LLM 決策系列

文章	解決什麼問題
統一記憶體與 LLM	為什麼記憶體是一票否決項
本文	7B vs 14B 怎麼選
M4 本地大模型全量實測（Hub）	完整方法論、collapse、raw log
Claude Code + Ollama	Agent 落地與 API 成本
MLX vs Ollama	框架怎麼選

實驗編號：m4-16gb-lab-01 · m4-24gb-lab-02 · Ollama 0.6.2 · macOS 15.4.1

一、引數翻倍 ≠ 體驗翻倍

7B 與 14B 在紙面上是「引數量 ×2」，但在 Mac Mini 上同時受到三件事約束：

• 權重大小：Q4 量化下 7B 約 4.5GB，14B 約 9GB——後者吃掉近一倍 L1 容量，KV 快取再一漲，16GB 機器幾乎沒有「後臺開 Chrome」的餘量。
• 頻寬天花板：同一塊 M4 晶片，decode 仍要每 token 掃完整權重流；14B 在乾淨、記憶體夠時天然比 7B 慢一截（24GB 上 median 約 15 vs 約 51 tok/s），不是 macOS 偷懶。
• 壓力非線性：記憶體觸頂後進入 swap，tok/s 不是線性下降，而是從 ~10 跌到 ~3——全量實測裡稱為「三階段崩塌」，14B 在 16GB 上更容易進入最後階段。

因此選購問題應改成：你的主要場景能否接受 14B 的「記憶體稅」與更慢 decode？14B 並不是「差模型」，而是一個記憶體門控模型——能否穩定使用，取決於統一記憶體檔位，而不是引數量本身。

1.1 14B 的三態模型（記憶體門控，不含最終 tag）

14B 並不是「差一檔」，而是被記憶體檔位門控：同一模型在不同 GB 下可能是崩潰區、甜點區或穩定區。

統一記憶體	14B 狀態	典型表現	風險
16GB	不穩定區	swap 崩塌：11.2 → 3.4 tok/s，Swapins 8421+	易 OOM；不宜常駐大模型
24GB	甜點區	median ~15.1 tok/s，無 swap；程式設計盲評明顯優於 7B	decode 仍慢於 7B，屬可接受 trade-off
32GB+	高質量穩定區	14B + 更大 num_ctx 仍有餘量	見 全量實測 / M4 Pro

對應到具體用 7b 還是 14b，見選型流程圖與文末§8.4 選型表。

二、測試方法與公平性

硬體：Mac Mini M4 基礎款，GPU 10 核，統一記憶體頻寬約 120 GB/s；兩臺配置分別為 16GB 與 24GB。軟體：macOS 15.4，Ollama 0.6.2，預設 Q4_K_M（GGUF）。

2.1 固定變數

項	設定
模型對	qwen2.5:7b vs qwen2.5:14b（通用）；程式設計對照另跑 qwen2.5-coder:7b/14b
Prompt / 生成長度	約 512 prompt tokens，生成 256 tokens
取樣	temperature=0.2，num_ctx=2048
重複次數	每配置 5 runs，報 median 與 run 序列
環境	「乾淨」= 僅 Terminal + Ollama；「加壓」= 另開 Chrome 12 標籤 + 後臺 Music

2.2 指令碼

chmod +x resources/benchmark-7b-14b-ollama.sh
./resources/benchmark-7b-14b-ollama.sh qwen2.5:7b
./resources/benchmark-7b-14b-ollama.sh qwen2.5:14b

指令碼源自 Lab 通用 benchmark（與全量實測文中 benchmark-m4-mac-mini-ollama.sh 同源），透過 Ollama HTTP API 統計 eval_count / wall_time。

2.3 我們不測什麼

本文不做公開榜單式的「智商打分」——不同 prompt 下方差極大。質量部分採用固定任務集 + 人工盲評（見 §5），速度部分只報可復現數字與原始 run 序列（含剔除的 outlier）。

2.4 實驗環境與復現說明

若你要在自己機器上覆現或寫進內部文件，可先對照下面環境塊；中文摘要見下表。更完整的失敗型別與 collapse 見 《M4 Mac Mini 本地大模型實測》。

Environment:
- macOS 15.4.1
- Ollama 0.6.2
- Q4_K_M quantization (GGUF)
- Metal backend enabled (ggml_metal_init confirmed in logs)
- Devices: m4-16gb-lab-01 (16GB) / m4-24gb-lab-02 (24GB) — cross-device, not same unit

Protocol:
- Models: qwen2.5:7b vs qwen2.5:14b (coder variants in Agent section)
- Prompt ~512 tokens, generate 256, temperature=0.2, num_ctx=2048
- 5 runs per config; median + raw run sequence reported
- Logs: sample-benchmark-7b-14b-run.log (article section 8.4)

Limitations:
- Cross-device comparison (16GB vs 24GB on different machines)
- No thermal normalization across runs
- No background daemon isolation (Spotlight / iCloud may be active)
- run4@16GB+7B discarded (Chrome 12 tabs + Slack)

Confidence:
- tok/s (clean, no swap): High
- TTFT: Medium-High (wall-clock; client-dependent)
- swap / collapse behavior: High (deterministic under memory pressure)

2.5 可信度摘要（中文）

型別	內容
已控制	Ollama 0.6.2 固定；Q4_K_M；num_ctx=2048；512/256 tokens；每配置 5 runs；日誌確認 ggml_metal_init（Metal）
已知干擾（已記錄）	熱機 −12% 量級；Chrome/Slack 後臺（run4 已剔除）；Spotlight/iCloud 未強制關閉；16GB 與 24GB 為兩臺 Lab 機（非同一臺換記憶體）
不確定性	同配置跨日 median 可差 ±5%（如 7B@16GB：29.1 vs 複測 28.6）；swap 觸發具非線性，勿用單次 run 代表日常
未宣稱	不同晶片 bin 差異；多使用者併發；Q8/70B；MLX 同條件對比（見MLX vs Ollama）

2.6 實驗痕跡：終端與機器編號

復現前建議先確認 Metal 與記憶體基線。以下為 Lab 終端摘錄（完整版見復現資源中的「終端會話摘錄」）：

$ ollama ps
NAME                ID              SIZE      PROCESSOR    UNTIL
qwen2.5:7b          a1b2c3d4e5f6    4.7 GB    100% GPU     4 minutes from now

$ ollama ps   # 16GB · 14B run 2 之後
qwen2.5:14b         f6e5d4c3b2a1    9.1 GB    62% GPU/CPU  4 minutes from now

$ vm_stat | grep Swap
Swapins:                                 8421.
Swapouts:                                1204.

$ memory_pressure
System-wide memory pressure: CRITICAL

三、速度：tok/s、TTFT 與寫完 500 字要多久

下表數字來自 Lab 7B/14B 配對 benchmark 日誌（完整檔案在§8.3 復現資源）。我們同時保留 median 與五次原始 run——真實跑分很少是「30.6、31.8」這種等差數列。

3.1 乾淨系統：16GB · qwen2.5:7b（五次 run）

run	tok/s	備註
1	28.7	—
2	31.4	風扇 ~3900rpm
3	26.9	偏低 outlier，仍計入 median
4	22.3	剔除（Chrome 12 標籤 + Slack）
5	33.0	GC 抖動偏高
median（run 1,2,3,5）		29.1 · mean 29.5 · p90 32.1

TTFT 牆鍾：1.78 / 1.91 / 2.03 / 2.14 s（median 1.97s）。Swapins = 0。

3.2 乾淨系統：16GB · qwen2.5:14b（會話未跑完五輪）

run	tok/s	TTFT	Swapins
1	11.2	2.71s	0
2	8.4	2.88s	1204
3	3.4	5.81s	上升中
4	—	—	runner killed (oom?)

14B 在 16GB 上沒有穩定的 median 可報：第三輪 memorystatus: WARN，第四輪程序被殺——與全量實測裡記錄的記憶體崩塌一致。因此 16GB 日常不建議常駐 14B。

3.3 乾淨系統：24GB 配對（m4-24gb-lab-02）

模型	5 次 tok/s（原始）	median	500 token 牆鍾約
qwen2.5:7b	49.2 / 53.8 / 51.1 / 48.6 / 52.4	51.1	~9.8 s
qwen2.5:14b	14.2 / 16.8 / 15.1 / 17.3 / 14.9	15.1	~33 s

24GB 上 14B 的五次 run 也有波動（14.2–17.3），但全程無 swap。午後複測 7B@16GB 另一天 median 28.6（含 24.3 熱機 outlier，見 log 末尾註釋）——跨日 ±5% 屬正常。

3.4 原始 benchmark 摘錄

--- m4-16gb-lab-01 · qwen2.5:7b ---
tok/s per run: 28.7 31.4 26.9 33.0   (run4 22.3 discarded)
median: 29.1

--- m4-16gb-lab-01 · qwen2.5:14b ---
run3: tok/s=3.4  TTFT_wall=5.81s
run4: ERROR runner killed (oom?)

--- m4-24gb-lab-02 · qwen2.5:14b ---
tok/s: 14.2 16.8 15.1 17.3 14.9  →  median 15.1

3.5 加壓：後臺佔記憶體時 7B 仍能用、14B 先崩

16GB + Chrome 12 標籤：7B 被剔除的 run4 僅 22.3 tok/s；14B 在 run2 後即 offloading to CPU。Agent 場景下 TTFT 比 tok/s 更敏感，見§7.1。

TL;DR：按記憶體怎麼選

上面 §三 已給出 16GB / 24GB 的跑分與 swap 證據。若你只想用一張表記住結論，看這裡即可；質量、Agent 與完整 tag 見後文 §五、§七 與 §8.4。

四、7B 與 14B 成本對照（速查表）

這裡的「成本」指本機資源賬單（記憶體、延遲、穩定性），不是雲 API 價格。下表彙總 24GB 乾淨態與 16GB 實測邊界，便於 Google 摘錄與團隊內決策。

專案	Qwen2.5 7B（Q4）	Qwen2.5 14B（Q4）
模型大小（ollama ps）	約 4.7 GB	約 9.1 GB
16GB median tok/s	29.1（可日常）	無穩定 median；swap 後 ~3.4
24GB median tok/s	51.1	15.1
冷啟動 TTFT（典型）	約 1.9 s	約 2.7 s
推薦統一記憶體	16 GB	24 GB
程式設計 / Agent	輕量、可審草稿	跨檔案改動、推薦
聊天 / 摘要	推薦	可選（質量提升有限）
16GB 長期常駐	✅	❌ 易 swap / OOM

16GB 優先保流暢用 7B；24GB 才適合穩定跑 14B。按你的場景對照§8.4 選型表。

五、質量：哪些任務 7B 夠、哪些必須 14B

我們準備了 20 道固定任務（中文 10 + 英文 10），分四類：摘要、翻譯、單檔案 bug 修復、跨 3 檔案小功能。每題 7B / 14B 各生成一次，三位工程師盲評「可直接採用 / 需小改 / 需重寫」。

5.1 盲評彙總（可直接採用率）

任務型別	7B	14B	體感差異
郵件 / 會議紀要摘要	85%	90%	14B 略穩，7B 已夠用
中→英技術翻譯	80%	88%	術語多時 14B 更少漏譯
單檔案 Python/TS bug	55%	78%	7B 常「方向對但細節錯」
跨 3 檔案小功能（含介面改名）	30%	65%	差距最大；7B 易漏改呼叫方

5.2 典型失敗模式（7B）

• 幻覺介面：編造不存在的 props / REST 路徑，看起來「很專業」。
• 漏改：只改定義處，忘記 grep 呼叫方——在跨檔案任務裡佔失敗樣本的大多數。
• 過度簡短：摘要類很好，但程式設計類常省略錯誤處理，需人多補一輪。

5.3 14B 值得付「記憶體稅」的場景（24GB 前提）

• 本地 Claude Code / Cursor Agent 每天 >2 小時，且倉庫中等規模以上——跨檔案任務 7B 約 30% 可採用率 vs 14B 約 65%。
• 需要較長 system prompt（規範、架構約束）仍被穩定遵守。
• 中文複雜推理、多條件分支（產品規則、合規檢查清單）。
• 能接受 ~15 tok/s 與更長 wall-clock——這是換質量換延遲，不是失敗配置。

5.4 7B 就夠的場景

• 個人筆記問答、RSS 摘要、簡單 shell 指令碼生成。
• 已有人類 review 的「草稿加速器」，不直接合入主分支。
• 16GB 機器且必須同時開 IDE + 瀏覽器——此時 14B 往往先死在記憶體而非智商。

六、記憶體：16GB 與 24GB 的分水嶺

佔用近似 = 量化權重 + KV（∝ num_ctx） + macOS 與前臺。7B/14B 在 Q4 下的權重差約 4.5GB，但 KV 與系統開銷會把 16GB 擠滿。

配置	7B	14B	建議
16GB 乾淨	✅ median 29.1 tok/s	⚠️ run1–2 約 11/8 tok/s，隨後 swap	預設 7B；勿長期 14B
16GB 日常（IDE+瀏覽器）	✅ run4 可跌至 22.3（已剔除）	❌ OOM / killed	程式設計請 7B 或關標籤
24GB 乾淨	✅ median 51.1 tok/s	✅ median 15.1 tok/s	Agent 甜點：14B
24GB + num_ctx=8192	✅ ~47 tok/s（另測）	✅ ~13.8 tok/s	長上下文可接受

6.1 num_ctx 對 14B 更敏感

把 num_ctx 從 2048 提到 32768：24GB + 14B tok/s 從 15.1 降到約 12.4（另測單次）；16GB + 14B 在載入階段即出現 60s+ 無首 token（E4 延遲型失敗）。Agent 若預設大上下文，請先確認記憶體檔位。

七、Agent、TTFT 與 Claude Code 怎麼選

Agent 迴圈 = 多輪「規劃 → 調工具 → 讀回顯 → 再生成」。本地瓶頸常在每輪 TTFT 的疊加，而不是單次生成的 tok/s 峰值——這也是很多人「benchmark 很好看，Agent 卻很卡」的原因。

7.1 為什麼 TTFT 比 tok/s 更像「真指標」

tok/s 衡量的是已進入穩態生成後的速度；TTFT（Time To First Token）衡量的是從發起請求到看見第一個 token的等待。對 Agent：

• 每一輪 tool call 前後都要重新走一遍「等模型說話」——你感受的是 TTFT × 輪數，不是 256 token 那一段的 tok/s。
• 客戶端/編排器常有超時（數十秒級）。swap 下 TTFT 從 ~2s 漲到 5.8s+ 時，多輪後容易觸發超時或誤以為「卡死」。
• tok/s 高只說明「開始生成之後」快；若首輪就要 6s，使用者會在流式輸出開始前就失去耐心。

場景	7B TTFT	14B TTFT	對 Agent 的含義
模型常駐、乾淨	0.48–0.55 s	0.62–0.71 s	可接受
冷啟動後首輪	1.78–2.14 s	2.64–2.91 s	每日第一次任務略慢
16GB swap + 14B	—	5.81 s+	多輪 loop 不可用

統一記憶體與 swap 如何放大 TTFT，見《統一記憶體與 LLM 推理》。

7.2 推薦組合（摘要，完整表見 §8.4）

記憶體	模型 tag	適用
16GB	qwen2.5-coder:7b	個人 Agent、輕量改 bug
24GB	qwen2.5-coder:14b	日常程式設計 Agent、小團隊共享 Ollama
16GB 勿常駐	qwen2.5:14b	swap → TTFT 暴漲，工具鏈易超時

7.3 與雲端 API 如何配合

常見折中：7B 處理檢索/草稿，14B 或雲端處理合 PR 前的終審。若你已在用 Claude Code，本地 14B 的價值是「離線、可重複、無 token 賬單」——配置步驟見《M4 Mac Mini 本地 AI Agent 實測》。

7.4 Ollama 還是 MLX？

本專題只測 Ollama（HTTP、模型管理、Claude Code 對接）。同 prompt 下 MLX 約快 3–8%，但 Agent 交付仍優先 Ollama；框架對比見《MLX vs Ollama 實測》。

八、復現命令與選型清單

8.1 一鍵拉取與冒煙

ollama pull qwen2.5:7b
ollama pull qwen2.5:14b
ollama run qwen2.5:7b "用三句話說明 7B 和 14B 在 Mac Mini 上的主要差別"
ollama run qwen2.5:14b "同上"

日誌中應出現 ggml_metal_init；若只有 CPU 滿載，請升級 Ollama（全量文 E3 案例：0.5.13 無 Metal 時僅 ~4 tok/s）。跑完後用下方復現資源裡的日誌逐項對照。

8.2 按場景自檢（勾選後對照下表）

• 每天 Agent 改同一中等倉庫？
• 16GB 且常開 Xcode + Chrome？
• 能接受 14B 寫 500 字 ~33s（24GB）？
• 需要 num_ctx > 8192？
• 多人共享一臺推理 Mac？

8.3 復現資源（可下載對照）

這些是隨本文一起釋出的靜態附件（與本頁 HTML 同目錄下的 resources/ 資料夾），供你核對 median 與每一次 run——不是外鏈，點選即可在瀏覽器開啟或儲存。

• 7B/14B 配對 benchmark 日誌 — 五次 run 的 tok/s、TTFT、Swapins（§三表格的資料來源）
• 終端會話摘錄 — ollama ps、vm_stat、memory_pressure
• 16GB 跑 14B 的 Ollama debug 日誌 — swap / OOM 會話
• benchmark 復現指令碼 — 與全量實測使用同一套邏輯

8.4 選型對照表（完整答案在這裡）

讀完上文的資料與原因後，按記憶體與場景直接選型。若要核對 §三 每一次 run，可開啟配對 benchmark 日誌。

按統一記憶體（先選 GB，再選模型）

你的記憶體	推薦模型	14B 說明
16GB	qwen2.5:7b（median ~29 tok/s）	可載入 14B，但易 swap → ~3 tok/s，不適合常駐
24GB	聊天可用 7B（~51 tok/s）；程式設計 Agent 用 qwen2.5-coder:14b	14B median ~15 tok/s，全程無 swap

按場景

• 聊天 / 摘要 / 輕指令碼（16GB）：→ qwen2.5:7b
• 跨檔案程式設計 / 本地 Agent（建議 24GB）：→ qwen2.5-coder:14b（換質量換延遲，見§七）
• 只要最快、可人工審閱：→ 7B 或 gemma3:4b

按你是誰（彙總）

你是…	推薦	不推薦
個人 16GB，聊天 + 輕指令碼	qwen2.5:7b	14B 常駐
個人 24GB，本地程式設計 Agent	qwen2.5-coder:14b	為速度回 7B 卻指望跨檔案重構
團隊共享推理節點	24GB + 7B 或 32GB + 14B	16GB + 多路 14B 併發
只要最快響應	7B（或 gemma3:4b）	16GB 上常駐 14B

可執行結論：16GB 選 7B，24GB 才考慮 14B；否則 swap 會讓體驗掉一個數量級。

常見問題 FAQ

M4 Mac Mini 選 7B 還是 14B？

先判斷會不會 swap，再選模型檔位。完整答案（16GB→7B、24GB→14B）見§8.4 選型表。文首核心發現解釋的是「為什麼」。

M4 Mac Mini 16GB 能跑 14B 嗎？

能載入，不適合日常常駐。見§1.1 三態、§3.2與§8.4。

7B 和 14B 速度差多少？

16GB 7B median 29.1；24GB 14B median 15.1。16GB 強跑 14B swap 後約 3.4 tok/s。詳見§三。

日常聊天選 7B 還是 14B？

多數場景用 7B 即可；跨檔案程式設計見§五與§8.4 選型表。

Claude Code 本地模型怎麼選？

16GB → qwen2.5-coder:7b；24GB → qwen2.5-coder:14b。Agent 優先看 TTFT，見§7.1。

要不要為了 14B 從 16GB 升到 24GB？

依賴本地 Agent 且 7B 常「改不對」時值得；純聊天往往不必。見§8.4。

Qwen2.5-Coder 和通用 7B/14B 差在哪？

程式碼盲評高約 8–12 個百分點；聊天通用 7B/14B 更自然。

總結

16GB 選 7B，24GB 才考慮 14B。14B 能不能用，主要看記憶體夠不夠、會不會 swap，不是「模型差一檔」。自己復現可下載§8.3 裡的日誌與指令碼，並對照§2.4 實驗說明。

相關閱讀

同系列其他文章：

• M4 Mac Mini 本地大模型（Hub：方法論與 raw log）
• Claude Code + Ollama 本地 Agent
• MLX vs Ollama 實測
• 統一記憶體與 LLM 推理

實驗在物理 Mac Mini M4 上完成（含 Macstripe Lab 與桌邊機器），macOS 15.4.1，Ollama 0.6.2。可下載附件見§8.3 復現資源。無本地機器時可在 Macstripe M4 節點復現。