上个月我把 Ollama 升到 0.19.0，启动后台服务的时候下意识扫了一眼官方仓库的 release notes。3 月 30 日那条 commit 写得非常直白：「Ollama is now powered by MLX on Apple Silicon in preview」。同一天刷出来一堆 benchmark——Qwen3.5-35B-A3B 这个 MoE 模型在 Ollama 老版本（llama.cpp）上是 58 tok/s 的 decode，新版本（MLX）跑到 112，几乎翻倍；prefill 从 1,154 提到 1,810 tok/s。
数字是挺漂亮的。但往下看到一行：「MLX preview requires a Mac with more than 32 GB unified memory」。
我那台基础款 Mac 是 16GB 统一内存。这意味着新引擎跟我这台没关系。
凭什么换引擎
Ollama 切 MLX 不是为了凑热闹。Apple 这套 MLX 框架是 2023 年底开源、专门为 M 系列统一内存架构写的——CPU 和 GPU 共享同一块物理内存，tensor 在两者之间传递是零拷贝的，不走 PCIe 那条总线。这件事对 LLM 推理特别重要，因为现在消费级硬件跑本地模型，决定速度的瓶颈是内存带宽，不是算力。带宽更宽的方向是直接读写同一块内存，不是在 CPU/GPU 之间搬数据。
llama.cpp 是另一个思路：它是 C++ 写的跨平台推理引擎，为了兼顾 NVIDIA、AMD、Intel、Vulkan、Apple Metal 五种后端，在每个平台上都付出一些”翻译税”。Metal 后端在 M3/M4 上对应 MLX 通常慢 20–40%，原因是它把 CUDA 计算图翻译成 Metal shader，没法利用 M5 里塞进 GPU 核心的 Neural Accelerator。
所以 Ollama 这步切换本质上是一句话：在 Mac 上保留一条兼容性 llama.cpp 后路，再开一条原生 MLX 快速路。两路并存，按模型和机器属性自动选。这个设计挺干净的。
但是它在 preview 阶段画了一条硬线：
- Mac 统一内存 ≥ 32GB
- M4 或 M5 系列芯片
- 模型在 MLX/safetensors 格式有正式版
- 模型规模在 14B 以上（14B 以下 MLX 优势不明显）
不符合任意一条就走 llama.cpp Metal 老路。换句话说，我这种 16GB 基础款 Mac 用户，被官方写进了 fallback 一栏。
退回 llama.cpp 之后我看到什么
真去跑的时候，最直观的体感变化倒不是 token 数，而是 启动时间。同一个 35B-A3B 模型，新版本（即使是 fallback 到 llama.cpp 的旧路径）冷启到首 token 出来比之前快了零点几秒。这个我相信是 MLX 路径改了一部分资源调度后，整套 binary 都重编了。
另一个体感变化：GGUF 模型仍然照常工作。比如本地放着的 7B 级别的 Qwen2.5-Coder-Q4_K_M、Qwen3-TTS、gpt-oss-20b 这些 GGUF 文件都没受影响，跑在 30-60 tok/s 之间，没掉速也没崩。
这说明 Ollama 这次切换是双轨制：模型文件是 MLX/safetensors 走 MLX；模型文件是 GGUF 走 llama.cpp。不是一刀切替换，老生态没崩。
Q4_K_M 不是我以为的越大越慢
既然被踢回 llama.cpp Metal，那就把目光转回量化方案选择上。一个反直觉的事情：在 5060 Ti 上量化越小（Q2、Q3）通常意味着模型更小、token 数越高；但在 Apple Silicon Metal 上，正好反过来——Q4_K_M 比 Q2_K、Q3_K_M 都快。
具体数字（来自 Inventive HQ 在 M3 Max 36GB 上跑 Qwen2.5-Coder 7B 的数据）：
- Q2_K：49.9 tok/s
- Q3_K_M：43.5 tok/s
- Q4_K_M：53.5 tok/s（最快）
- Q5_K_M：39.8 tok/s
- Q6_K：42.2 tok/s
- Q8_0：33.8 tok/s（最慢）
原因是 Q4_K_M 的 Metal dequant kernel 优化最狠—— GGUF K-quant 用的是 importance matrix 加权混合精度，给 Metal 写的高频调用路径就是 Q4 这一档。「量化的更小就跑得更快」是 x86 训练出来的直觉，搬到 Apple Silicon 上不成立。
但这个测试用例有个隐患：测试数据基于 Qwen2.5-Coder 一个模型。换其他模型家族（比如 Llama 3、Phi-4）顺序可能略变。Q4_K_M 在 7B–14B 模型上稳坐 Apple Silicon 速度王，比较稳。
llama.cpp 还剩哪几个优势
MLX 不是单选题，几个场景 llama.cpp 仍然更顺手：
长 prefill。比如要把一篇 100K token 的论文塞进去只问一个问题。同一份对比测试里，llama.cpp + FlashAttention 在长 prefill 上比 MLX 快——因为 MLX 的 lazy evaluation 是按小批次设计的，长 prefill 这种一次吃下大块输入的活儿反而不是它的甜点。
非 Apple Silicon 部署。MLX 是 Apple-only。家里那台小主机常年在 Linux 跑着，同样的 GGUF 文件过去就能用，不需要换格式也不需要重新量化。如果是交付一个跨平台产品，llama.cpp 的 GGUF 兼容性是省事的根。
GGUF-only 模型。社区发布模型优先上 GGUF（因为 llama.cpp 用户群更大），safetensors/MLX 版本要等几天。如果想跑新发布的某模型，llama.cpp 路径是唯一选择。
CPU offload。模型太大切不进 GPU 时，llama.cpp 能分层切——一部分在 GPU 一部分在 CPU，Ollama 在 fallback 模式下会接管这事。
我现在的取舍
结论短期内不会换机器。16GB Mac 的本地模型策略基本就是三件事：
- 主用 GGUF + Q4_K_M。Apple Silicon 上这是速度甜点+质量甜点的交集。Q5_K_M 在 7B 模型上可以略微拉高，70B 级别别想，老老实实 Q4。
- 关注发布节奏。新模型出来先等 GGUF 版本，可能要等 1-3 天才能跑上。MLX/safetensors 版本要等 mlx-community 搬运。
- 长 prefill 的活儿用 llama-server 单独跑。FlashAttention 路径在长输入上比 MLX 强。
如果哪天换 32GB 或更大的统一内存，那才是真的开始谈 MLX。否则盯着 Ollama 的 GGUF fallback 路径就好，新引擎是给新硬件准备的，老机器用户没在他们的计划里。
这件事有点别扭。MLX 这个抽象做得越漂亮，基础款 Mac 用户距离这条路径越远——不是因为不能用，是因为新生态默认假设你机器够大。Apple Silicon 一向以「统一内存比 VRAM 灵活」作为优势卖点，结果等到软件生态发达起来的时候，这个优势反过来又卡了一道。
但反过来想，16GB 基础款 Mac 在 M 系列今天这个价位仍然是出货量最大的配置，这个用户群被默认排除在 MLX 之外，这件事迟早得有人解释一下。