Mac 本地跑大模型的玩家，最近分成两派。一派坚持“拒绝 Ollama，MLX 框架才是终极答案”，另一派说 Ollama 都接上 MLX 引擎了，NVFP4 量化、提速 20%，还有什么必要手动装。加上 8 月初 Ollama 更新到 0.32.5、刚完成 6500 万美元 B 轮融资，势头正猛。
到底信哪边？我把这几个月知乎、小红书、B站的实测、踩坑记录和官方更新都翻了一遍，又逐项核对了官方博客的数据。先说结论：这不是“谁更快”的争论，而是“你的使用场景”和“工具缓存机制”的匹配题。
Ollama 接上 MLX 引擎，到底补上了什么
先捋时间线。今年 4 月初，Ollama 0.19 preview 正式接入 MLX 框架，当时的演示数据就很猛：Qwen3.5-35B 的 NVFP4 量化版，预填充 1851 token/s、解码 134 token/s，体感比旧引擎提速 93%。小红书
更关键的后续在 6 月：MLX 引擎新增 NVFP4 格式支持，Ollama 把云端优化技术搬到了设备端。知乎 Ollama 官方博客公布了 Gemma 4 12B 上的困惑度对比：BF16 为 17.54，NVFP4 为 17.95，q4_K_M 为 18.36——NVFP4 与满精度的差距，只有传统 4-bit 量化的一半左右。Ollama官方博客 翻译成人话：跑得更快，还掉质更少，这在量化世界里是难得的双赢。
还有两件事，是 Mac 用户很难拒绝的。一是 Agent 优化：用 Claude Code、OpenClaw 跑本地模型时，上下文会被反复发送，prefix caching 就是命脉，而工具调用、重试、多 Agent 协作都会让缓存失效，Ollama 新的快照系统能保存模型状态，把缓存尽量留住，0.32.1 又改进了 Gemma 4 的工具调用和多轮推理，顺带修了内存泄漏。二是生态绑定：Claude Code、OpenClaw、Cline、Continue 都原生集成 Ollama，7 月它又完成 6500 万美元 B 轮融资，月活跃开发者接近 890 万。知乎 这意味着“一行命令跑起来”的体验和模型库更新，只会更稳。
所以如果你的需求是“挑个模型、接上编码工具、别让我折腾”，Ollama 现在的版本已经是足够好的答案。那为什么还有人坚持要换？
另一派的三个理由，个个打在痛点上
第一个是裸速度差距。小红书用户的实测反馈：同样 32GB 内存的 Mac，MLX 跑 Qwen2.5-32B 通常比 Ollama 快 15%-30%。小红书 这个差距在预填充阶段最明显，上下文越长越能感知，一次贴进去几万 token 代码的人，等的是“秒回”和“去倒杯水”的区别。
第二个是“新模型先到 MLX”。就看这个月：30B 级 Agent 模型 Muse-Glimmer-30B 发布三天内就有 Mac 本地 MLX 分支实测，约 30 token/s；哔哩哔哩 33B 的视频模型 MiniMax-H3 被社区移植进 MLX，48G 内存的 Mac 生成一段 720p 的 5 秒视频约 30 分钟；知乎 连 284B 的 DeepSeek-V4-Flash 这种 MoE，都被 M3 Ultra 的 512G 统一内存推到 200K 上下文 20 tok/s。哔哩哔哩 mlx-community 的转换模型往往更新最快、参数最激进，Ollama 的模型库对全新架构的跟进，总会有那么一点时间差。
第三个，也是最核心的，是 Agent 场景的体验分水岭。普通工具 KV 缓存失效时，第一句的等待时间（TTFT）能飙到 30-90 秒。知乎 对用 Claude Code、Codex 做长上下文多轮编辑的人来说，这不是“慢一点”，是“工作流能不能续上”的问题。
MLX 生态给出的答案是 oMLX：它把 KV 块持久化到 SSD，下次相同前缀直接从磁盘恢复，TTFT 降到 1-5 秒，甚至跨重启有效。知乎 真实用户的面板上，缓存效率能稳定在 80% 以上，意味着绝大多数 prefill 不用重算。它还给 Claude Code、Codex、OpenCode、OpenClaw 各准备了一行启动命令，API 同时兼容 OpenAI 和 Anthropic 两种格式，摆明了就是为编码 Agent 设计的。
提速数字：先分清哪些是实测，哪些是营销
选之前先泼一盆冷水：社区里流传的“提速 10 倍”“快 2 倍”，很多是缓存命中对缓存失效、官方优化分支对默认参数的对比，不是你在自己机器上换个引擎就能拿到的同条件实测。
真正可复现的数字长这样。把 DeepSeek 投机解码移植到 MLX 的 mlx-dspark，作者基准在 M4 Pro 上：Gemma-4 12B 从 18.4 tok/s 到约 30 tok/s，Qwen3-4B 从 52.9 tok/s 到约 73 tok/s，分别约 1.6 倍和 1.4 倍。知乎 原理也不是魔法：小草稿模型先猜一批 token，目标模型一次验证，通过的直接收下，输出和普通解码逐字节相同。
但同一位作者也承认天花板：在 M 系列芯片上，多 token 验证的成本会随 token 数增长，速度上限不像数据中心 GPU 那么高。知乎
也就是说：投机解码是真的，NVFP4 是真的，SSD KV 缓存也是真的，但它们都不是“装上就起飞”的魔法。每个数字都有前提，前提是你的模型、你的任务、你的内存。别问“谁更快”，要问“你的场景是谁”：开放聊天 DSpark 更稳，结构化的代码和数学输出，DFlash 才能填满更大的块。
谁该选谁，按人群来
直接给判断。
只想跑模型、接上 Claude Code 或 Cline 试试、不想折腾环境的：留在 Ollama 0.32.5，优先挑 NVFP4 或 4bit 量化支持好的模型。一行命令安装、模型库最全，是它至今的护城河，出了问题社区教程也最多。
重度编码 Agent 用户，长上下文、多轮编辑、对第一句等待极其敏感的：换 oMLX（或 Rapid-MLX）。SSD KV 缓存、连续批处理、Anthropic 兼容 API，就是为这个场景做的，一句 omlx launch claude 能省掉你配环境变量的整个晚上。
想第一时间跑最新模型、榨更多速度、或者玩 LoRA 微调的：走 mlx-lm / mlx-vlm 路线。但要做好心理准备，Mac 自带 Python 版本通常是 3.9，而最新 AI 框架强制要求 3.10 以上，知乎 新架构模型要从开发分支安装、冷启动、内存撑爆这些坑，“拒绝 Ollama”派都替你踩过了。
手里一堆 GGUF 模型、想把内存带宽榨到最后一滴的：llama.cpp 依然是性能上限最高、参数粒度最细的选择。
三个继续观察的信号
最后留三个观察点，它们任何一个变化，上面的结论都要重估。
一是 Ollama 的 MLX 引擎会不会从“preview 支持”变成默认引擎，NVFP4 模型库的覆盖速度跟不跟得上——跟上了，两派的裸速度差距会进一步缩小。二是 30B 级 Agent 模型这波潮，会不会继续“MLX 先发”——这决定手动 MLX 是“首发红利”还是“小众刚需”。三是 MLX 的 CUDA 后端后续：今年 5 月 MLX 的 CUDA backend 测试已基本通过，这条线如果真推进下去，“MLX=苹果专属”的定位会变，Mac 本地生态可能迎来新一波流入。
一句话总结：Ollama 把 MLX 的速度交给了不想折腾的人，mlx-lm 和 oMLX 把最后 20% 和最新玩具留给愿意付时间成本的人。先搞清楚自己是哪种人，再决定端哪个碗。
