今天翻到 dev.to 上 9 月 1 日那篇讲旧 Intel Mac 不适合本地推理的文章，我是隔了几天才看到的。作者手上那台 2020 款 Intel MacBook Air，8GB 内存，没有风扇，拿它跑推理基本没戏；真正干活的是另一台 Dell 笔记本，11 代 i5、集成显卡、16GB 内存。就在这台集显机器上，他用 Ollama 加一个 7B 编程模型和一条 RAG 流水线，做了一个面向非洲开发者工具链的离线编程助手。评论区比预想的热闹，从硬件一路吵到「本地 AI 到底值不值」。
那场路线之争我不打算记，这里只记一个更具体的问题：判断手上这台机器能不能跑，该按什么顺序拆开看。顺序对了，能省下不少冤枉钱。
先算容量，这是整条链里唯一能用算式算清楚的环节：
权重占用 ≈ 参数量(B) × 量化位数 / 8
7B Q4 ≈ 4 GB 上下
14B Q4 ≈ 8–9 GB
27B Q4 ≈ 16–20 GB
注意这只是权重，KV cache 和运行时开销另算，上下文拉到几万 token 时那部分并不小。8GB 的机器扣掉系统和常驻进程，能稳稳装下的只有 3B–4B 那一档。所以多数情况下「能不能跑」其实等于「装不装得下」，跟芯片是 Intel 还是 M 系列关系没那么大。装不下的时候去比模型质量，顺序就反了。
再确认它实际被放在了哪：
ollama ps
输出里有一列写着模型是在 GPU 上、CPU 上，还是按比例分片。看到 100% CPU 或者大比例分片，速度掉一个数量级是常事；这一步该解决的是放哪儿，不是换个更小的模型凑合。
MoE 那条顺带记一下：容量和带宽的压力在它身上表现不一样。总参数决定占多少内存，激活参数决定每次要读多少权重，所以同样容量的机器上，MoE 往往比同总参数量的稠密模型跑得舒服，代价是仍然得把全部权重装进内存。评论区有人把 4B、7B、9B 和 MoE 一起列进测过的清单，这个方向比笼统说「本地模型慢」有用得多。
装得下之后，下一个瓶颈是带宽，不是算力。这一点我一开始也搞反过，盯着 TFLOPs 和核心数看了很久，后来才想明白：生成阶段每吐一个 token，都要把权重完整读一遍，token/s 的上限基本由带宽定，算力排在第二位。统一内存的带宽优势也只在 Max 和 Ultra 层级明显，基础款 M 和 M Pro 跟 DGX Spark 那一类是接近的。原文作者打算换 M4 Pro 或者 24GB 的 Mac mini M4 来「比较舒服地跑 27B」，这个判断我会在后面打个问号——装得下和跑得舒服之间，隔着带宽这一层，也隔着上下文长度这一层。
测速别只看最好看的那一次：
ollama run qwen2.5-coder:7b --verbose
# 输出里找 eval rate，单位是 tokens/s
💡 小技巧：同一个 prompt 连着跑三轮，重点看第三轮。第一轮有缓存和预热的加成，通常最好看；第三轮更接近你日常连续用一小时的实际情况。
最后是热和电，比跑分更容易被忽略的一项。这里我得先收回一句差点写偏的话：我本来想吐槽作者拿 8GB 没风扇的 Air 去评估本地 AI，写到一半觉得不对，他真正有价值的动作恰恰是拿那台机器先把「不能跑」判了出来，而不是一上来就换机器。持续推理是长时间满载，热和电决定的不是能不能跑一次，而是能不能连着跑一小时不掉链子。没有风扇的机器，满载久了会降频，那种跑分只能当参考，不能当你日常体感的预期。
划重点：第一，先算容量，装不下就别去比模型质量，那是后面的事；第二，装得下之后用 ollama ps 看它被放在了哪一块，再谈带宽和 token/s；第三，热和电管的是能不能连续用，测速记得看第三轮的数字。你可以拿手上这台机器照着这个顺序过一遍，卡在哪一步，基本就是那一步的问题，不用急着换机器。