你一开始大概率会问错这个问题
如果你刚开始在 Mac 上跑本地大模型，很容易进入这个问题：
「Ollama 和 MLX 哪个更好？」
或者更具体一点：哪个更快？M4 Mac Mini 用哪个？要不要直接上 MLX？
这个问题看起来很合理。但我们在 M4 Mac Mini（16GB / 24GB / 32GB）上跑了一段时间之后，慢慢发现：
这个问题本身，其实有点「问偏了」。
真正的现实是：大多数人根本不需要选
在 Mac 本地 LLM 这件事上，一个更接近现实的结论是：
默认用 Ollama，除非你明确知道自己为什么需要 MLX。
不是因为 Ollama 在 benchmark 里永远最快，也不是因为 MLX 不够好。而是因为大多数时候，你卡住的问题根本不在框架——而在内存够不够、模型是不是太大、前台是不是已经占满了统一内存。
换句话说：框架选型往往是「你已经把内存和模型理顺之后」才值得讨论的第二层问题，而不是第一步。
30 秒结论
在 Mac 上跑本地大模型：
- 👉 默认：Ollama
- 👉 例外：MLX / llama.cpp
但关键是：80% 的人永远不会进入「例外区」。
快速对照
| 场景 | 默认选择 | 真实问题 |
|---|---|---|
| Claude Code / Cursor 接本地模型 | Ollama | MLX 会不会更快 |
| 第一次跑通 LLM | Ollama | 要不要研究底层 |
| 团队共享推理 | Ollama | 要不要上更复杂方案 |
| 日常聊天 | Ollama / LM Studio | 哪个更专业 |
| 压测 / benchmark | MLX | 能不能用于开发 |
| 微调 / LoRA | MLX | Ollama 能不能做 |
为什么最后大多数人都会回到 Ollama
不是因为它「最强」，而是因为它刚好解决的是最现实的问题。
① 它让你先跑起来
在 Mac 上跑模型，第一关其实不是性能，而是：能不能 5 分钟内跑通。
brew install ollama
ollama run qwen2.5:7b没有 Python 虚拟环境、没有手动编译 Metal backend、没有先搞懂 llama.cpp 参数。这一步非常关键——它降低的是「失败率」，不是「理论性能」。
② 它刚好适配 Agent 时代
现在很多人用本地模型，不是为了聊天，而是为了 Claude Code、Cursor、Continue、Open WebUI。这些工具真正需要的是一个稳定的 HTTP 接口，而不是多 5% 的 tok/s。
Ollama 默认提供 127.0.0.1:11434 和 OpenAI 兼容 API。所以它本质上变成了 Mac 本地 LLM 的「USB 接口」——插上就能用。接入步骤见 Claude Code + Ollama 实测。
③ 真正卡住你的不是框架
我们在 M4 Mac Mini 上最常见的情况是：16GB 内存、跑 14B 模型、同时开 IDE + 浏览器。结果是 swap 上升、tok/s 下降、Agent 变慢。
这时候换 MLX——基本不会改变结果。 因为瓶颈在内存 + 模型大小 + 系统负载，不在推理引擎的名字。内存档位见 M4 Mac Mini 能跑哪些模型；7B / 14B 取舍见 实测差距。
那 MLX 到底什么时候才重要？
这里是关键分界线。MLX 不是「更好的 Ollama」，而是少数情况下才需要的底层工具。
你只有在这些场景才需要 MLX
1. benchmark / 性能测试
你只关心真实 tok/s，不要任何 runtime 干扰。👉 MLX / llama.cpp CLI
2. CI / 研究复现
你需要固定 prompt、固定 batch、固定量化。👉 MLX 更可控
3. LoRA 微调 / 训练
Ollama 不属于这个领域——它是推理运行时，不是训练框架。
4. 自研推理系统
比如多模型路由、API 网关、SLA 控制。👉 MLX + 自建服务 才合理。个人开发者接 Claude Code，不要为此换栈。
5. 论文级实验
新量化方法、speculative decoding、kernel tuning。👉 直接 llama.cpp。架构差异见 MLX vs llama.cpp 深析。
压测时 MLX 快多少？Llama-3.1-8B 4-bit、干净态：16GB 上 Ollama 约 27–31 tok/s，MLX 约 28–32 tok/s——差距约 3%–12%，只存在于测量层，不改变日常默认规则。运行时对比见 Ollama vs MLX。
一个关键认知纠正
很多人会直觉认为：MLX 更快 → 应该用 MLX。
但现实是：
MLX 的优势主要体现在「测量层」，不是「使用层」。
它更像实验仪器，而不是日常工具。Agent 全链路里，框架级 tok/s 差异往往占总延迟的很小一部分；你更在意的是 HTTP 稳不稳、模型会不会 OOM、多轮 tool loop 会不会超时。
一个非常真实的场景
你一定见过这种组合：
- M4 Mac Mini（16GB）
- Ollama + 14B 模型
- Chrome 十几个 tab
- VS Code + Claude Code
然后发生：swap 8GB+、响应变慢、Agent timeout。
这时候很多人第一反应是：「是不是 Ollama 不行？」
但真实答案是：
- ❌ 不是 Ollama 的问题
- ✔ 是系统资源已经到极限了
换 MLX？结果基本一样。 原理见 统一内存与 LLM 推理。
Mac 本地 LLM 的真实结构（很重要）
可以简单理解为三层：
- 应用层：Claude Code / Cursor / Chat UI
- 运行时层：Ollama（HTTP）
- 计算层：MLX / llama.cpp
你大多数时间在「运行时层」，不是「计算层」。
本地 LLM 的体验 = 能不能不 swap × 首轮够不够快（TTFT） × 任务要不要更高参数量质量。tok/s 对多轮 Agent 往往是第二优先级。
一个更现实的规则（核心）
先用 Ollama，只有当你明确知道不够时，再切 MLX。
同一台 Mac 可以同时装两者：白天 ollama serve 接 Agent，夜间用 MLX 跑 benchmark。它们服务不同层，不冲突。团队共享推理节点见 私有 AI 服务器 Mac Mini 集群。
终极结论
Mac 本地 LLM 的问题，本质不是工具选择，而是：你有没有进入需要控制底层的阶段。
- 默认路径 Ollama = 80% 用户的终点
- 例外路径 MLX = 少数工程 / 研究 / 压测场景
关键变量不是框架，而是内存与模型大小。
一句话总结
Mac 本地大模型默认使用 Ollama，MLX 仅用于需要底层控制的少数场景；真正瓶颈通常是内存与模型大小，而不是推理框架。
如果你只想记一个判断标准
没有明确理由，就用 Ollama。
FAQ
Mac 本地大模型用 Ollama 还是 MLX？
默认 Ollama。MLX 只用于离线压测、CI 复现、LoRA 微调、自研推理系统或极限参数实验。日常 Claude Code、Cursor 接本地模型应走 Ollama :11434。
MLX 更快，是不是应该用 MLX？
benchmark 中可能快约 3%–12%，但 Agent 场景瓶颈在内存与稳定性，不在 tok/s。MLX 的优势在测量层，不在使用层。
本地大模型慢，该换 MLX 吗？
先查 Activity Monitor 有没有 swap、ollama serve 日志有没有 ggml_metal_init、模型是否过大。16GB 跑 14B 加 IDE 和浏览器，换框架通常解决不了。
一台 Mac 能同时装 Ollama 和 MLX 吗？
可以。白天 Ollama 接 Agent，夜间 MLX 做压测，两者服务不同层，不冲突。
