这周 Mac AI 圈基本被一个模型刷屏：Qwen3.8-27B。但评论区一翻，同一个模型的众生相差别极大。有 M5 Max 用户把它跑到 70 tok/s。小红书也有 M2 Max 用户裸跑 Q8_0 量化，只有 11.9 tok/s。小红书还有位 M4 Pro 48G 的朋友，跑着跑着机器直接死机重启了。
硬件差距是一部分原因，但还有一半差异来自一个很多人没意识到的变量：你装的"运行器"是哪个。同一份模型权重，塞进不同的运行框架里，速度、内存占用、稳定性完全不一样。现在市面上能在 Mac 上跑本地大模型的运行器，已经打到了至少 6 个：Ollama、LM Studio、oMLX、Rapid-MLX、MTPLX，还有官方的 mlx-lm。今天把它们一次捋清楚。
先说一个能帮你少走弯路的判断：这 6 个工具，本质上是两大引擎阵营的壳。
一边是 MLX，苹果官方的机器学习框架，统一内存原生优化，Mac 上的"亲儿子"路线：mlx-lm 是官方命令行，oMLX、Rapid-MLX、MTPLX 都是基于它做的第三方服务，Ollama 从 0.19 版本开始也接上了 MLX 引擎。小红书另一边是 llama.cpp 带起来的 GGUF 路线，跨平台、量化格式多——Unsloth 的 Dynamic 量化就把 Qwen3.8-27B 压到过 9GB 出头（UD-Q2_K_XL），让 16G 丐版 MacBook 都能把它跑起来，走的正是这条路。
关键的分叉点在这里：模型格式决定你能用什么工具。你在 Hugging Face 上下载 xxx-MLX 权重，就只能给 MLX 系运行器用；下 xxx-GGUF，就走 llama.cpp 系。Ollama 和 LM Studio 是少数"两栖"选手，两种都能吃，所以成了大多数人的第一站。
下面逐个说。
Ollama：开发者的稳妥默认值。 生态最全、社区教程最多，接 API、连编程工具的资料一搜一大把。今年 4 月 0.19 版本接上 MLX 引擎之后，6 月那轮优化让 MLX 引擎又提速 20%。知乎它还支持了质量损失更小的 NVFP4 4-bit 量化，上了快照系统改善 prefix caching，这轮 Qwen3.8 也支持了 MTP 投机解码，M4 Max 128G 上已经有整套实测。缺点是功能节奏跟着官方走，不会给你最激进的速度。
LM Studio：怕命令行的人直接选它。 纯图形界面，模型市场里搜索、下载、运行一条龙，这周的 Qwen3.8 教程很多就是拿它做的，GGUF 和 MLX 权重都支持。哔哩哔哩还有个容易被忽略的优点：稳。有用户在实测帖评论区说得直白，自己用 oMLX 和 MTPLX 频繁死机重启，换 LM Studio 从来没出过这种问题。小红书求稳的新手，它是风险最低的答案。
oMLX：为编程 Agent 场景准备的那一个。 它是 macOS 菜单栏应用加本地服务器的组合，真正的杀手锏是分层 KV 缓存：高频上下文常驻内存，冷数据落到 SSD，同样的前缀不用重复计算。小红书Claude Code、Codex 这类编程工具每轮都要发送完整上下文，这个设计正好打在痛点上，社区里"用 oMLX 接 Claude Code/Codex"的实战帖已经攒了不少。它还有自家的 oQ 量化体系，0.6.1 版本这周把 Qwen3.8-27B 和 NVFP4 支持补齐了。
更激进的是，0.6.0 版本上了实验性的多 Mac 集群。有人用一台 M4 Pro 64G 带一台 M4 16G，两台机器协同跑一个 35B 量化模型，小 Mac 也能当 worker 分到几层计算。小红书坑也不少：节点必须设 Headless、带 MTP 头的模型会死锁、分布式暂时只支持纯文本模型。要泼的冷水还有：它宣传的"提速30倍"，其实是 GLM-5.2 单个模型家族在 M3 Ultra 上的融合 prefill 场景，不是通用速度。小红书另外目前社区里的死机反馈，也集中在它和 MTPLX 身上。
Rapid-MLX：5 月风光过的速度派。 上过 GitHub Trending，主打比 Ollama 快 2-4 倍，OpenAI 兼容接口、工具调用、推理链分离都齐，还能接 Cursor、Claude Code 这类开发工具。还有个很实用的设计：本地预填明显变慢时（比如超长上下文），自动把请求路由给云端模型。但注意：它 README 里的跑分，是在 Mac Studio M3 Ultra 256GB 上测出来的，比如 Phi-4 Mini 14B 跑到 180 tok/s。知乎普通机型要打折理解；5 月之后社区声量也小了不少，追新之前建议先看看最近的更新节奏。
MTPLX：这周刚冒头的 MTP 专精引擎。 专门给 Apple Silicon 做 MTP 投机解码，有用户在 M2 Max 64G 上把 Qwen3.8-27B 跑到 20.9 tok/s，比裸跑快 75%，首字延迟不到 1 秒，上下文直接给到 256K。小红书但它太新了，量化包要靠 HF 上的第三方制作，评论区也有人说它速度不如 oMLX 稳，现阶段只适合爱折腾的人尝鲜。
mlx-lm：官方参考实现。 苹果自己维护，研究、微调、跑论文首选，但服务化功能朴素，截至 MLX 0.32.1 连 MTP 都还没跟上，纯聊天跑模型不用优先考虑它。
那到底怎么选？按场景对号入座：
纯新手、只想聊天玩玩：LM Studio，GUI 一键搞定，先跑个 4-bit 的 9B 以下模型找感觉；
开发者、要 API 和教程：Ollama，稳妥默认值，Qwen3.8 的 MTP 提速它也吃得到；
接 Claude Code / Codex / Cursor 写代码：优先试 oMLX，分层缓存对高频重复上下文是真刚需，但轻量任务用 A3B 这类 MoE 小模型反而体验更好；
极限压榨 Qwen3.8 速度：先用 Ollama 的 MTP 打底，稳；oMLX 的 oQ4e-mtp 和 MTPLX 上限更高，但死机和翻车风险也更高；
8G / 16G 小内存：别硬上 MLX 系大模型，走 llama.cpp / LM Studio + Unsloth Dynamic 量化更现实。参考一个极限案例：16G 丐版 M1 用 UD-Q2_K_XL 量化包（9.15GB）能跑 Qwen3.8-27B，但只有 4 tok/s 出头——能跑和能用是两回事；
两台 Mac 想拼一个更大的模型：oMLX 0.6 的集群是目前唯一现成方案，实验性质，踩坑清单很长，别抱生产级期待。
这里再多算一笔编程场景的账。有人拿 M4 Max 128G 实测本地结对编程，结论很扎心：编程工具每读一个新文件就要重新 prefill 一遍，等待会把省下的 API 钱吃回去，“它帮你省下的每一秒，都会被 Prefill 消耗得一干二净”。知乎同一台机器上，A3B 这类 MoE 小模型 4-bit 能跑到 300+ tok/s 的处理速度，日常辅助够用；27B 稠密模型只有 80+ tok/s，读个大文件要等好几分钟。所以本地编程助手这条路能走，但要按任务类型算账，别拿它硬扛重度 Agentic 编程。
最后三句冷水，帮你管理预期：
第一，Mac 跑大模型的天花板是内存带宽，不是软件。Q8 量化的 27B 每生成一个 token 要搬 28GB 权重，物理定律摆在那，运行器之间的差距是百分之几十，不是几倍。老款 M1 带宽只有 68 GB/s，跑 9GB 出头的量化包，4 tok/s 就已经榨干物理带宽的六成。小红书
第二，宣传数字要看清口径。"提速 30 倍"是单模型单场景，"比 Ollama 快 2-4 倍"的跑分机器是 M3 Ultra 256GB 顶配。评论区里 48G 机器跑出 6 tok/s 的翻车案例，往往是下错了量化版本——有人拿到的包名字里带 FP16，权重根本没压缩，自然跑不动。小红书
第三，别指望一个工具用三年。这个赛道现在的节奏是按月迭代的，oMLX 几个月前还没什么影子，现在已经在搞多机集群了。
值得继续盯的信号：mlx-lm 什么时候补上 MTP（补上之后官方路线的性价比会重估）、oMLX 集群的稳定性和 VLM 支持、以及苹果自己的 Core AI 和 MLX 的分工演化——目前的格局是 Core AI 主攻产品级端侧推理和更灵活的模型格式，MLX 继续当研究和训练的地基，两边都不至于消失。知乎
如果你正卡在"装哪个"上，我的建议很朴素：先装 LM Studio 或 Ollama 把模型跑起来，确认自己的真实场景和内存够不够，再决定要不要换更专精的方案。跑起来，比跑得快重要。
