[分享] Mac 本地跑大模型实测： 54 tok/s，一年省下 API 费 ≈ 一台 Mac mini

分类走本地部署的决策模型效率还能更高点

你这个需求，搞一下国内免费的模型多搞几个号，负载均衡不就免费搞定了吗，速度还更快

理论上是没问题，我用一台 16G 的 M1 Mac Mini 试了一下，用 Ollama 和 LM Studio 分别能跑 qwen2.5-coder:7b 和 qwen3.5-9b ，都比你这个模型还大点，前者是两年前的模型了，3.5-9b 是 2026 年的。

但是在任何一个 Agent 编程客户端中，几乎完全是灾难，用不了的水平：
Prefill 耗时极长，且每家客户端的系统提示词和工具定义都找不到修改的地方（也不建议修改，因为这可能会影响其他模型的行为），也就是在这些客户端中（我自己试的是 DeepSeek Harness 和 OpenCode ），你提问任何一个简单问题，都要花费 1 分钟以上才能给出回复（这里不排除我这台电脑确实配置太拉了的原因）。

不过自己写裸模型调用，速度方面要好得多，tok/s 甚至看起来略接近主流网页版对话模型的速度了。
至于模型质量就不深度评价了，知识截止日期都比较老，不能联网搜索，简单的事实类问题提问回答幻觉也很严重。

总结下来，简单的小活儿肯定是能用的。上下文不超限的前提一下，做一些翻译、内容总结，单页面编写和修改之类的，或者通过裸模型调用，包装成通用 API 。

补几个自己做端侧推理时踩过的坑，都是和这笔账直接相关的：

1 ） 2000 次/天其实不一定需要实时。一旦能排成批处理，瓶颈就从延变成吞吐，单流 54 tok/s 这个数字就没有决策意义了，应该看一天能吞多少 token 。llama-server 开多个 slot 并行跑收益很大，但统一内存跑小模型的限制在内存带宽，slot 加到某个数量之后每个都会变慢，拐点得自己实测。

2 ）分类和字段抽取的固定 system prompt 是一笔重复开销。每次调用都把同样的提示词重新 prefill 一遍，长 prompt 下 prefill 能吃掉相当一部分时间。提示词固定下来、复用带 prompt cache 的 slot ，比换个更快的模型划算。

3 ） 3B 模型最容易翻车的不是答得不好，是不按格式答。字段抽取只要 JSON 少个括号，整条链路就得重试。上结约束解码（ GBNF / grammar ）把输出锁在 schema 上之后，解析失败会少非常多；这步不做，线上会很难看。

4 ）建议留一层兜底。小模型拿不准的结果回落到大模型，全量替换往往不如分层路由：小模型吃掉大部分量，剩下那一小部分才是真成本，也是调提示词的人力所在。算账时把这部分一起算进去，再决定要不要省这台 Mac mini 。

至于上面说的 agent 客户端 prefill 灾难，我这边同样的感受：agent 的系统提示词加上大段工具定义，每次请求都是几千 token 的 prefill ，小模型在这种场景下不是能力不行，是用方式压根没为它设计。