今年 6 月，一位刚买了新 MacBook Pro 的用户发现怪事：芯片里有块算力从开机起压根没动过。苹果最新这代芯片在每个图形核心里塞了个小矩阵引擎，专管模型读提示词时的重活；这台机器躺着 40 个，跑模型的应用却把它们全关了。

提示词读进来多花一倍时间，回话速度倒没慢，因为这些引擎只管「读」。修复 9 月初才落地，距芯片上市已过十个月。

一块芯片上的三套引擎

Mac 上能跑大模型的部件全在一块芯片上，共用同一池内存。芯片上躺着三种处理器，出厂年头不同、各管一摊；矩阵单元 M5 才有，M1 到 M4 只有图形核心和神经引擎。

图形核心是全能选手，几千个小单元什么数学都能算，也早就成了默认选项：早在矩阵单元出现前，语言模型就只能往通用核心上搬，各家本地工具也顺着这条路长大。

矩阵单元只干一件事：把一格格数字相乘，速度远超通用核心。但它只在程序按规定格式、经苹果 Metal 4 的 tensor API 开口请求时才会醒；叫法不对也不报错，活儿照算，只是落回通用核心用笨办法慢慢磨。

神经引擎最特别。苹果出货它很多年，每颗 M5 里有 16 个。它为图像和音频而生，数学形状固定、提前可知；文字生成两样都不占，硬按上去多少有点缘木求鱼。

三套引擎共享同一份内存，数据不用来回拷贝，这正是 Mac 能跑大模型的底气。但共享内存不等于活儿会派给对的引擎：做选择的是运行时——应用底下的软件层，模型加载那一刻就替你定了，不问一声。

读得快，写得慢：模型的两个阶段

模型回话分两步，压榨机器的方向完全相反。

第一步是读：提示词一口气全收进来，不停做乘法直到吃透上下文，这步叫 prefill，瓶颈在乘算速度——矩阵单元正是为它生的，所以 M5 比 M4 快 3.33 到 4.06 倍。

第二步是写：吐一个词就得把整套权重从头读一遍，每个词都来一轮，这步叫 decode，瓶颈在内存带宽，同一组对比里只提升 1.19 到 1.27 倍。

权重有体积：Qwen-14B 的 4-bit 版本 9.16 GB，每写一个词，这点数据就得完整过一遍；4-bit 是压缩版，更小，精度略让。稀疏模型能绕开这笔账：30B 的 Qwen 稀疏版占 17.31 GB，但每个词只激活网络一角，所以更大的稀疏模型写起来反而更快。

数据跑多快，取决于你买的哪台 Mac。

614 GB/s 的机器写文本就是比 153 GB/s 的快，矩阵单元多少都改变不了；读则反过来，153 GB/s 的基础款 M5 也能让稠密 14B 首词 10 秒内给出，30B 稀疏模型不到 3 秒。所以单看「每秒多少 token」说明不了问题，先问出自哪个阶段。

一行日志，看穿谁在干活

每次加载模型，Mac 都会决定用不用矩阵单元，结论写进一份你多半没打开过的日志。LM Studio 和 Ollama 都是前台，底下真正跑模型的是 llama.cpp——除非 Ollama 已把模型切到 MLX。它加载时会检查够不够得着矩阵单元，够不着就会看到这一行：

ggml_metal_device_init: the tensor API is not supported in this environment, disabling

够得着的话这行干脆不出现；自己编译的版本打出 has tensor = true。日志位置因应用而异：LM Studio 开 Developer 模式后看 ~/.lmstudio/server-logs，或跑 lms log stream；Ollama 跑 ollama serve 直接打到终端；mlx-lm 启动时打印。搜 tensor 就行。

2026 年 6 月一份公开 bug 报告，在 128 GB 的 M5 Max 上记录了这事：两个模型各灌 2,048 token 提示词。

1,833 是同一模型在上游 llama.cpp（通过检查的构建）上的数字：模型开口前白白多等一秒多，这正是矩阵单元本该省下的；两边写速度纹丝不动，符合带宽瓶颈的推算。

根子在一个编译选项：应用的图形代码拿旧版 Metal 编译，旧版没有 tensor API，成品看不见它；启动时程序问「tensor API 在吗」，得了否定答案就关掉矩阵单元。换新版设置自己编译，同一份代码顺利通过，修复 2026 年 9 月 1 日合入。

MLX 抢在前头：它是苹果自家的机器学习库，早于 llama.cpp 支持 tensor API，后者摸不着矩阵单元时它已用上。Ollama 则在 2026 年 3 月的 0.19 版搬上 MLX：预览性质、只覆盖部分模型、只在 32 GB 以上的 Mac 启用。官方对比长这样：

第二列要看仔细：decode 差不多翻倍——受内存带宽限制的阶段，换什么引擎都不可能翻倍；多出的一半来自同次更新里换掉的压缩格式，跟引擎无关。

更干净的对照来自独立测试：一台机器、一套权重。64 GB 的 M3 Max 跑 4-bit 的 Qwen3.6-35B，mlx-lm 写出 163 token/秒，Ollama 只有 47；M3 Max 没有矩阵单元，差距纯粹是运行时拉开的。

快引擎也有输的时候

MLX 赢在读，也赢短对话。可对话一长它就开始掉队，原因跟算力快慢毫无关系。

你说过的话都会随新消息重新发给模型，这一整摞就是上下文，模型得弄清每个词与其余所有词的关系。这步叫 attention，所需内存随 token 一路上涨；过了临界点，光搬数据就比算数学费时间。

llama.cpp 有解法叫 flash attention：把活儿切块，让处理器少跑内存。MLX 没有对应实现：2025 年 12 月有人提过（mlx issue 2955），issue 关了，东西没影；提案引用的社区 Metal 内核曾把 30B 4-bit 模型的吞吐抬高约 77%，路子是通的，只是没进 MLX。

两边孰强孰弱的分界点，在 256 GB 的 M3 Ultra 上跑 4-bit 的 Minimax-m2.1 测出：

这些是写速度，两个长度下读依然是 MLX 赢；到 146,000 token，它写速度只剩 llama.cpp 的一半。注意机器：M3 Ultra 没有矩阵单元，这跟 M5 无关，纯粹是软件缺口，换新 Mac 也补不上。提示词动辄整份文档、整个代码库的话，决定运行时选择的就是这条。

被冷落的神经引擎

苹果在每台设备里都塞了颗专门的神经处理器，还当 AI 硬件宣传；装机超 20 亿台，却没有一台在上面跑语言模型，妥妥的名不副实。

一部分原因是先天不合：它为形状固定、提前可知的活儿而造，逐词往外蹦的文字生成恰好相反，大量时间耗在干等上。更关键的是你说了不算：Core ML 把硬件选择当建议、并非承诺，点名要神经引擎，来的可能是 CPU 也可能是 GPU，还查不了是谁在干活；有研究团队为了测它，只能绕开它走私有接口。

硬让它跑语言模型，速度拿不出手：头号开源项目 ANEMLL 在 8B 模型上约 9 token/秒，MLX 用图形核心能到 93 以上；换来的是功耗和内存——约 2 W 对 20 W，占用 98 到 230 MB 对 390 到 4,376 MB。

等回复的活儿交给图形核心；全天候挂后台、靠电池续命的小任务才轮得到神经引擎——前提是调得动。

怎么选，看机器也看用途

没有万能答案，要考虑的只有三件事：芯片（矩阵单元只有 M5 有）、提示词长度（决定 MLX 是帮忙还是帮倒忙）、内存（模型得和对话一起装得下）。

提示词长度恰恰最容易被搞错，因为压根没人数它：大家盯着模型和内存，真正影响选型的长度反倒没人看，本末倒置。参照一下：30,000 token 约是一份长设计文档，或几千行代码。

表里 32 GB 门槛来自必须同时装下的东西：Qwen-14B 的 4-bit 权重 9.16 GB、30B 稀疏模型 17.31 GB，对话记录还得另占一块且逐字增长。8 GB 的 Mac 连 14B 都装不下；24 GB 装得下，对话一长就被拖进硬盘交换，比文里任何事都慢。Ollama 把 32 GB 设为下限，留的就是这块余量。

还有一点：那组交叉点测于修复前的 M3 Ultra，之后没人复跑过。提示词动辄超 30,000 token，有人补上实验之前，llama.cpp 仍是更稳的选择。

这个选择题的下一步

这道选择题之所以存在，是因为三块硬件背后站着三套工具，苹果想亲手了结它。

2026 年 6 月苹果公布 Core AI，接替服役 9 年的 Core ML：一个接口调度三套引擎、替你分配活儿，覆盖 3B 视觉模型到 70B 推理模型。真成了，你要操心的只剩「选哪个模型」。

硬件也在往前赶：Mac Studio 9 月 22 日开卖，M5 Ultra 带来 1.2 TB/s，约为最快笔记本两倍，512 GB 配置据称 10 月底跟上。

Core ML 当年的教训是「硬件选择只是建议」；目前看不出 Core AI 改了这一条，哪天文档写明能把执行钉死在某套引擎上，你才算真正知道活儿去了哪。

在那之前，选择还是你自己做，而答案早躺在机器日志里。打开它，搜一下 tensor——见微知著，一行字就够。

原文链接：
https://medium.com/data-science-collective/your-mac-is-running-local-llms-on-the-wrong-engine-443b2539247a