为什么 Mac 跑大模型的速度能算出来：拆解 SimulKit 的性能模型
为什么 Mac 跑大模型的速度能算出来：拆解 SimulKit 的性能模型
"这台 Mac 能不能跑得动这个模型"，其实是一道小学算术题——只要你知道该拿哪个数去除哪个数。
在 Apple Silicon 上跑本地模型的人迟早会遇到同一个问题：网上有人晒 M5 Max 跑 70B 模型 13 tokens/s，你自己跑出来只有 8，于是开始怀疑是不是模型选错了、量化选错了、还是该换台机器。这类问题通常靠"买回来试试"回答，代价是一台机器的钱。
SimulKit 的 Mac 本地 LLM 页面 想做的事就是把这个试错提前：它把在售的所有 Mac（从 MacBook Neo 到 Mac Studio）和一批开源模型（gpt-oss、Qwen、Gemma、Llama、DeepSeek……）放在一起，告诉你哪些模型装得下、写出多少 tokens/s、读入多快，免费。
这篇文章拆它的性能模型。有意思的地方不在结论，而在它只用了三个变量就把这件事讲清楚了：内存带宽、算力、和 macOS 允许 GPU 用多少内存。
本文提纲
- 它解决什么问题：把"买回来试试"变成算术
- 第一本账：写出速度由内存带宽决定
- 第二本账：读入速度由算力决定
- 第三本账：模型到底装不装得下
- 两个杠杆：量化与混合专家（MoE）
- 这些常数从哪来，有多准
- 怎么用它做决策，以及模拟器算不出的东西
它解决什么问题：把"买回来试试"变成算术
本地推理的决策链条其实很短：先看装不装得下，再看写得够不够快。 装不下，一切都免谈；装得下但写得太慢（比如 2 tokens/s），交互体验等于没有。
SimulKit 把这个链条做成了一个可查询的表：每台 Mac × 每个模型，给出三件事——能不能装下、decode（写出）速度、prefill（读入）速度。它的价值不是精确到小数点，而是把量级判断从"试错"变成"估算"，让你在花钱之前就知道 M5 Max 跑 70B 是 13 tokens/s 而不是 50。
第一本账：写出速度由内存带宽决定
这是整个模型里最重要的一个认知。原文的表述是：
每生成一个 token，Mac 要把模型所有活跃权重读一遍。所以写出速度（decode）约等于内存带宽除以权重大小。
它之所以成立，是因为自回归生成是访存密集型而不是计算密集型：每生成一个 token，都要把参与计算的权重从统一内存里过一遍，而算力远远没用满。所以决定速度的不是 GPU 有多少核，而是内存带宽能多快把权重喂进去。
一个能直接套的算式：
decode 速度 ≈ 内存带宽 × 效率系数 ÷ 活跃权重体积
# M5 Max 的例子（官方页面的口径）
带宽 = 614 GB/s
稠密 70B 4bit 权重 ≈ 40 GB
理论速度 = 614 ÷ 40 ≈ 15.4 tokens/s
实际（含效率与固定开销）≈ 13 tokens/s三个可以直接用的结论：
- 量化为什么能提速：4bit 把模型体积压到 16bit 的约 3.5 分之一，分母小了，速度就上去了。
- 为什么大模型慢：分母是权重体积，参数越多、比特越高，越慢。
- 为什么同一个模型在不同机器上差距那么大：分母一样，差在带宽。M5 Max 是 614 GB/s，换一台带宽只有一半的机器，速度大致也减半。
效率系数不是 100%。 官方说模拟器在 MLX 下能用到 75% 到 87% 的带宽（取决于量化方式），llama.cpp 要再低约 5 个百分点；此外还要按芯片与模型类型叠加一项"每 token 固定开销"。这就是为什么不能拿 614÷40 直接当答案——理论值 15.4，实际 13，差的那部分就是这些损耗。
还有一笔会随时间增长的账：KV cache。 长对话会越来越慢，因为每生成一个新 token，除了读权重，还要读模型对上下文的记忆（KV cache）。对话越长，这部分要读的数据越多。所以同一个模型，跑 2K 上下文和 32K 上下文是两种速度——很多"跑分作弊"就发生在这里。
第二本账：读入速度由算力决定
生成之前，模型要先读完你的 prompt（prefill），这一步的性质完全不同：它受算力限制，不受带宽限制。
原因是 prefill 可以并行处理整段提示，每个 token 的计算量大约是每个活跃参数 2 次运算，再加上注意力那一项——而注意力随提示长度呈平方增长。这就解释了两件常见现象：
- 长提示的 TTFT（首 token 时间）会突然变难看：不是因为带宽不够，而是注意力项的平方增长开始吃掉算力；
- 短提示时"这机器很快"的错觉：prefill 在短上下文下几乎不是瓶颈。
这里有一个 2026 年的新变量值得单独说：M5 和 M6 芯片的每个 GPU 核心都带一个 Neural Accelerator。 影响是实打实的：
| 运行时 | Neural Accelerator 支持 |
|---|---|
| MLX | 自 macOS 26.2 起使用；prefill 比 M4 快 3.5 到 4 倍 |
| llama.cpp | 自 2026 年 4 月起用于矩阵乘，但尚未用于注意力 |
也就是说：同样的机器、同样的模型，光是因为跑在不同引擎上，读入速度就可能差几倍。这也解释了为什么"同芯片不同软件"的实测结果会互相打架。
第三本账：模型到底装不装得下
装不装得下不是"模型体积 < 内存"这么简单，而是三项之和必须塞进 macOS 允许 GPU 使用的内存：
权重体积 + KV cache + 运行时缓冲区 ≤ GPU 可用内存第一项是固定成本，后两项随上下文长度和运行时实现变化——这就是为什么"模型只有 40 GB，我有 64 GB"仍然可能跑不动长上下文。
而"GPU 可用内存"本身低于机器标称内存，官方给了 macOS 26 / 27 下的比例表：
| 机器内存 | macOS 允许 GPU 使用的比例 | 折算 |
|---|---|---|
| 16 GB / 24 GB | 74% | — |
| 32 GB – 48 GB | 78% | — |
| 64 GB / 96 GB | 81% | — |
| 128 GB | 84% | — |
| 256 GB | 87% | — |
| 512 GB | — | 464 GB |
可以通过 sudo sysctl iogpu.wired_limit_mb 调高这个上限，但重启后失效。
两个容易踩的单位陷阱官方也点明了：Apple 的内存是二进制的（标称 16 GB 实际是 172 亿字节，不是 160 亿），而这里的模型体积按"十亿字节"计，和 Hugging Face 上的展示口径一致。算之前先把单位对齐，否则你会得到"看起来刚好装得下、实际差一点"的结论。
两个杠杆：量化与混合专家（MoE）
量化：把每个权重用更少的比特存。官方给的取舍很直白：
- 4bit 是常规选择——比 16bit 小约 3.5 倍，质量损失很小；
- 8bit 几乎无损；
- 更大的模型配 4bit，通常胜过更小的模型配 8bit。
最后一条是本地部署里最重要的经验：在内存预算固定的前提下，优先保参数规模，再考虑比特数。
MoE（混合专家） 则改变了"活跃权重"这个分母。MoE 每个 token 只用少数几个专家，所以：
- 全部权重必须装进内存（这部分省不掉）；
- 但每个 token 只读活跃的那些，所以它的写出速度像一个小模型。
官方的例子是：gpt-oss 120B 需要 65 GB 内存，写出速度却像一个 5B 模型。 对内存够但带宽有限的机器（比如 Mac），这是目前性价比最高的一类模型。
这个规律在实测里也成立。oMLX 上有一组公开测量：Qwen3.5-122B-A10B（MoE，总 122B、激活约 10B）跑在 M5 Max（40 核）、128 GB、4bit 上，结果是
PP = 911.1 tokens/s # prefill，1k tokens 上下文
TG = 64.3 tokens/s # decode（写出）
TTFT = 1124 ms # 首 token 时间
峰值内存 = 65.6 GB注意这组数字的形状：总参数 122B，但写出速度 64.3 tokens/s——按"活跃约 5 GB 权重 ÷ 614 GB/s"估，量级完全对得上（实际效率约五到六成，剩下的被路由开销、注意力与 KV cache 读吃掉）。Dense 122B 在这种机器上是不可能跑到这个速度的，这就是 MoE 的意义。
这些常数从哪来，有多准
一套能用的估算模型必须交代它的常数怎么来的，官方这点写得很清楚：约 300 组公开测量，来源包括 llama.cpp 的 benchmark 讨论帖、MLX 与 oMLX 的结果、Apple 自己的数据，以及 M5 / M6 Mac 的评测。
精度口径也很诚实：**在相同软件下，估算通常落在实测的 15% 以内。**但——你的速度取决于 app、版本和设置：Ollama、LM Studio 和 llama.cpp 用的不是同一个引擎，量化格式与内核实现也不同。所以正确的用法是"用它判断量级与可行性，用实测确认最终数字"，而不是拿估算值去和别人吵架。
怎么用它做决策，以及模拟器算不出的东西
一个可以照着走的判断顺序：
- 先算装不装得下：权重 + KV cache（按你真实要用的上下文长度）+ 运行时缓冲，对比 macOS 给 GPU 的额度；不够就先降量化或换 MoE 模型，别急着换机器。
- 再看 decode 够不够用：用"带宽 × 效率 ÷ 活跃权重"估算。经验上，对话类应用 10 tokens/s 以上可接受，代码补全这类需要更快的节奏。
- 长文档/长 prompt 场景重点看 prefill：这里决定体验的是 TTFT，受引擎对 Neural Accelerator 的支持程度影响（MLX 与 llama.cpp 差别明显）。
- 长对话记得给 KV cache 留内存：它的体积随上下文增长，是"标称内存够、实际跑不动"的常见原因。
顺手说清它的价格口径，避免误读：页面价格取自所选货币对应的 Apple Store、2026 年 10 月 1 日、基础存储；Apple 已于 2026 年 6 月 25 日涨价；法国版 MacBook、英国版 MacBook Air 与 Pro 不带电源适配器；512 GB Mac Studio 于 2026 年 10 月底出货，价格尚未公布。
最后是边界——模拟器不是 benchmark，它算不出来的有：
- 散热与持续负载降频：跑十分钟和跑一小时是两个成绩，尤其是被动散热的机型；
- 量化格式的实现差异：同样是"4bit"，不同内核效率不同；
- 批处理：
batch > 1时 decode 可能从访存受限转向算力受限，那套"带宽除以权重"的直觉就不适用了； - 训练与微调：整个模型只讲推理；
- 具体应用的开销：上下文管理、KV cache 量化、采样参数都会动数字。
参考链接
- SimulKit：Every Mac, which local LLMs fit, and how fast — 本文主要来源（含带宽、算力、显存上限与量化口径）
- SimulKit 法语版 — 同一页面的法语版本
- oMLX 基准：Qwen3.5-122B-A10B on M5 Max (40c) — 本文引用的实测锚点（PP 911.1 / TG 64.3 tok/s）
- oMLX 基准：Step-3.7-Flash-oQ3.5 on M5 Max (40c) — 另一组 M5 Max 实测
- MLX — Apple 的阵列框架，M5/M6 上使用 Neural Accelerator 的路径
- llama.cpp — 另一条主流本地推理路径，2026 年 4 月起在矩阵乘上启用 Neural Accelerator
- Hugging Face 模型页 — 页面的模型体积口径与此一致（十亿字节）
你在 Mac 上跑本地模型，卡住你的是内存还是速度？评论区聊聊你的配置和实测数字，觉得这套算法有用就点个赞。
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
