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 已发生，榜单数字不再代表日常体感。

M4 Mac Mini 本地 LLM 决策路线图

本篇是专题 Step 2（模型选型）。若还没看过 Hub，请先读 M4 Mac Mini 能跑哪些本地大模型。

步骤	文章	解决什么
Step 1	Hub 全量实测	16/24GB · raw log
Step 2	本文	7B vs 14B
Step 3	Ollama vs MLX	Claude Code 应该选哪个
Step 4	Claude Code + Ollama	跑起来 · 省 API

选型流程图（先 swap，再 Agent，最后才是 7B/14B）

先看内存会不会 swap，再看你是不是在做 Agent，最后落到 7B 还是 14B：

系列索引（完整表）

文首 决策路线图 为推荐阅读顺序；下表供跳转。

步骤	文章	解决什么问题
0	统一内存与 LLM	原理
1	Hub	能跑哪些模型
2	本文	7B vs 14B
3	Ollama vs MLX	Claude Code 选型
4	Claude Code + 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 节点复现。