告别 90 秒的等待：oMLX 如何在 Mac 上对 Ollama 实现降维打击
在 Mac 上跑本地大模型，oMLX 还没流行的时候，大多数人靠 Ollama 撑着。然后，你开始盯着进度条发呆。30 秒，没动静。60 秒，屏幕依旧安静。90 秒——第一行代码终于出现了。
这种感觉，就像在自助餐厅门口排队等位：明明餐厅里空空如也，你就是进不去。
Ollama 几乎是 Mac 上跑本地大模型（LLM）的代名词。装上它，选个模型，两行命令就能跑起来，确实简单。但当你想把它接进 Claude Code、Cursor 这类 Agent 工具的时候，问题就来了。
上下文一长，Ollama 的响应就像被按了慢放键。
01 oMLX 出现前，Coding Agent 为什么那么慢？
你可能觉得是模型本身的问题。其实不是。
真正卡住你的，是 Prefill 阶段——在模型开始"说话"之前，它需要先把你的整个上下文（比如 5 万 Token 的对话历史）全部算一遍。
这就像图书馆管理员每次有人来借书，都要先把整栋楼的图书目录重新手抄一遍，哪怕上个月刚抄过。
Agent 工作的时候，这个问题尤其严重。因为 Agent 是循环迭代的——它执行一次工具，拿到结果，再把结果塞回上下文，接着又让模型思考下一步。这个循环往复的过程，意味着 Prefill 要反复发生。
Ollama 的 KV 缓存（用来存储已计算状态的机制）默认只放在内存里。内存不够了？缓存直接清空，下次从头算起。
所以你在等的那 90 秒，模型在做的事情是——把一道已经做过的菜，从洗菜开始重新做一遍。
02 oMLX 的解题思路：给厨师配两个冰箱
oMLX 的核心创新叫 Paged SSD KV Cache，可以理解为"分层的记忆系统"。
它的灵感来自 vLLM 的 PagedAttention，但针对 Mac 的硬件特点做了本地化改造。
想象你家厨房的储存安排：高频使用的食材放在台面上的保鲜盒里（热层，RAM），不常用的放到地下室冰箱里（冷层，SSD）。
oMLX 把 KV 缓存块分成两层：
热层在 RAM 里，读取速度最快，用来保存最近、最常用的计算状态。
冷层在 SSD 上，容量几乎无限，用来存放那些被"挤出去"的缓存块。格式用的是 safetensors——速度快，安全性也高。
关键来了：当 Agent 再次回到之前见过的那段上下文时，oMLX 直接从 SSD 把缓存捞回来用，跳过了 Prefill。
“每个 KV 缓存块都会持久化到磁盘。前缀再次出现时，直接从 SSD 恢复，不需要重新计算。实测 TTFT 从 30-90 秒降到了 1-3 秒。” —— jundot，oMLX 作者
更离谱的是，这个缓存在服务器重启后依然有效。
你今天下班保存的状态，明天打开电脑继续用，Agent 还是秒进状态。
03 真实场景里，这能省多少时间？
算一笔账。
一次 Agent 开发任务，迭代 30 次。用 Ollama，每次 Prefill 耗时 60 秒，总共要等 30 分钟。
换成 oMLX，第一次迭代冷启动 10 秒，后续 29 次迭代每次 2 秒，总共只需要不到 70 秒。
30 分钟变成 70 秒，差了 25 倍。
这才是让 Coding Agent 从"能用"变成"真正值得用"的关键。
04 底层架构：MLX 才是那个隐形功臣
oMLX 跑在 Apple 官方开源的 MLX 框架上，而 Ollama 的引擎是 llama.cpp + GGUF 格式。
两者差别在哪里？
Apple Silicon 有个独特的设计叫统一内存架构（Unified Memory Architecture）——CPU、GPU 和神经网络引擎共享同一块物理内存，没有传统 PC 上"显存"和"内存"之间的拷贝开销。
MLX 数组直接从统一内存分配，CPU 和 GPU 读写同一块数据，不存在跨显存拷贝这回事。
llama.cpp 也支持 Metal 加速，但它是跨平台项目，骨子里还是照着传统 PC 那套思路来的。放到 Mac 上，效率天然矮一截。
直接对比：同样的模型，MLX 的 Token 生成速度通常是 GGUF 的 1.5 到 2 倍。
这不是微优化，是架构层面的天生优势。
05 连续批处理：不是更快，是同时做更多
oMLX 还内置了 mlx-lm 的 BatchGenerator，支持连续批处理（Continuous Batching）。
普通推理服务一次只处理一个请求，其他人得排队。
连续批处理的思想是：把多个请求的 Prefill 和 Generation 阶段穿插在一起，让 GPU 的每个计算周期都不闲着。
实测数据（Qwen3.5-122B，M3 Ultra 512GB）：
| 并发数 | Token 生成速度 | 相对吞吐量 |
|---|---|---|
| 1x | 56.6 tok/s | 1.00x |
| 4x | 135.1 tok/s | 2.39x |
| 8x | 190.2 tok/s | 3.36x |
8 个并发请求同时来，GPU 的实际吞吐量提升到原来的 3.36 倍。
这不是让你一个人跑得更快，是让一屋子人不用排队。
06 Ollama vs oMLX：不是非此即彼
说了这么多 oMLX 的好话，不代表 Ollama 一无是处。
没有绝对的好坏，只有合不合适。
选 Ollama，如果：你只是偶尔用本地模型写写邮件、翻译文字，不需要 Agent 循环，模型库也更丰富。
选 oMLX，如果：你重度使用 Coding Agent，在 Mac 上跑长上下文任务，愿意折腾版本稳定性。
| Ollama | oMLX | |
|---|---|---|
| 硬件 | 全平台 | 仅 Apple Silicon |
| 安装 | brew install ollama | menu bar app 或源码 |
| 模型格式 | GGUF | MLX |
| KV 缓存 | RAM only | RAM + SSD 分层 |
| 吞吐量优化 | 有限 | 连续批处理 |
| 模型生态 | 超大 | mlx-lm 生态 |
| API 兼容 | OpenAI | OpenAI + Anthropic |
两者都支持 OpenAI 兼容的 API，接 Claude Code 或 Cursor 只需要改一行 endpoint。
07 上手有多难？
oMLX 提供原生的 macOS menu bar 应用（基于 PyObjC，不用 Electron），下载安装后点点鼠标就能用。
内置了模型下载器、Web 监控面板（/admin），以及一键配置 Claude Code 等工具的向导。
最低要求 macOS 15+，Apple Silicon M1 起跳，内存建议 64GB 以上。跑 4-bit 量化的 Qwen3.5-122B 这类大模型，32GB 的机器会比较吃力。
本地跑大模型这件事，在 Apple Silicon 上一直有点"食之无味"的感觉——能跑，但体验差。oMLX 把几个核心瓶颈都精准拆掉了：统一内存榨干硬件、SSD 缓存干掉重复计算、连续批处理撑高并发。
对于用 Mac 做 AI 编程的开发者来说，这可能是目前最接近"流畅"的使用体验。
常见问题
oMLX 和 Ollama 哪个更适合普通用户？
Ollama 安装更简单，模型库更大，普通用途选它够用。oMLX 面向重度 Coding Agent 用户，需要一定的折腾意愿。
Mac mini M4 能跑 oMLX 吗？
能跑，但内存建议 24GB 以上。跑 4-bit 量化的 Qwen3.5-122B 这类大模型，内存会非常吃紧，建议 64GB 配置起步。
oMLX 的缓存能在关机后保留吗？
可以。KV 缓存以 safetensors 格式持久化到 SSD，服务器重启后依然有效。不过目前需要手动配置缓存目录。
顺便分享一个我常用的 AI自媒体运营工具 ，覆盖内容排版、素材处理和效率提效，写公众号会更省力。
最近在玩 Claude Code 的新功能，发现官方出了个 Codex 增强版门户 ，把各种智能编程能力整合在一起了，感兴趣可以去看看。
如果你想看到更多这类工具测评和 AI 编程实战，欢迎关注我的公众号「梦兽编程交个朋友」，每周更新。