[分享] 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 ，小模型在这种场景下不是能力不行，是用方式压根没为它设计。

@skallz 免费额度个人玩玩没问题。不过我们是要在公司生产环境里跑的：多账号轮换基本都要注册主体的手机号，另外客户数据过第三方 API 这关，做 ToB 业务的都知道怎么回事。所以最后还是选了数据不出本机的方案——省的不只是 API 费，还有合规解释的成本。当然如果只是个人项目，你这个思路完全成立。

@gangsta 是这样的，Agent 客户端（ DeepSeek Harness / OpenCode ）系统提示词+工具定义动辄几千 token ，每次请求全量 prefill ，小模型的 prefill 速度撑不住这个开销——不是模型不行，是这类客户端压根没为 3B 级别设计。裸调用快得多是因为 prompt 短、且可以精简到任务本身。

另外你这个「 qwen3.5-9b 在 16G 机器上的对比数据」对我来讲挺有价值的，正好和我 32G 跑 3B 的数据形成互补（内存带宽是共同瓶颈）。方便的话给一下 prefill t/s 具体数字？

@panghu960 这条回复质量太高了，四条都是真金白银的实战经验，逐条回应：

1. 吞吐 vs 延迟：完全同意。我们场景 2000 次/天其实 80%是夜间报表摘要，完全可以 batch 跑——当时只看了单流 54tok/s 就下了结论，确实是决策模型不对。
2. promptcache：这条我不知道，受教了。固定 systemprompt+slot 复用，马上去试，如果数据好会更新到博客版（注明来自你的回复）。
3. GBNF 约束解码：真实踩坑。字段抽取 JSON 少括号导致重试，一度让我们怀疑模型能力——原来加 grammar 就能锁 schema ，这个直接解决我们的线上痛点。
4. 分层路由：对，全量替换确实是懒人方案。小模型吃量、大模型兜底，成本和质量的平衡点还是得算细账。

准备把这四条都补进博客版教程（会注明来自本帖讨论），这种「评论区比正文专业」的时刻就是发帖的意义。多谢！

@spike0100 对，分类这块确实还有空间。现在我们是「每条工单单独调一次」，其实完全可以攒够 N 条或每 30 秒 batch 一次再推理——下面 @panghu960 提到的 slot 并行也验证了这个方向，吞吐还能再往上抬一截。准备把 batch 化也补进来，谢谢提醒。