实测：16GB M1 Pro 笔记本跑本地 LLM 能跑多快

我上一篇文章讲的是各家公司发现自己的 AI 账单后开始设置用量上限。对那篇文章的一种合理回应，正是本地 LLM 社区一整年都在给出的建议：别再租用 token 了，开源模型现在已经足够好了，在自己的机器上跑就是了。

但支撑这个建议的基准测试存在一个硬件问题。那些测量各项指标的报道，测试环境都是 Mac Studio 或 128GB 的 M5 Max 笔记本，头条新闻更夸张。DeepSeek V4 Flash "能在 MacBook 上跑"——前提是那台 MacBook 售价约 5000 美元、配备 128GB 内存。Kimi K3 的开放权重需要八张 H100 才能加载完。今年夏天有一篇指南的标题简直就是在说"开放权重，你跑不动"。

我的笔记本是 2021 年的 M1 Pro，16GB 内存。它差不多快五年了，我怀疑它比那些基准测试里的任何机器都更接近普通开发者机器的平均水平。所以我测试了它实际能跑出什么。

我测试了五个模型，全部通过 Ollama 拉取，选取标准都是能塞进 16GB 的：

qwen3.5:4b 和 qwen3.5:9b，阿里巴巴当前的 small 模型系列，两者默认都会先思考再回答

gemma4:e4b-it-qat 和 gemma4:12b-it-qat，Google 当前的 small 模型系列，采用量化感知训练版本

qwen2.5:7b，2024 年底的模型，作为基准，用于验证这一年来的进步在这个参数量级上是否有体现

那些真正被讨论的当前模型都没有上榜，这本身就是一个小发现。glm-4.7-flash 和 qwen3-coder 听起来都很小，但下载体积都是 19GB。qwen3.8-27B，在我测试那周刚发布，需要约 17GB，权重甚至还没开放下载，说是要在这篇文章发布的那周才给。在 16GB 内存的限制下，你能真正跑起来的模型列表比网上讨论的短得多。

测试任务共 21 道，取自数据工程师工作中会遇到的题型，分为六类：针对带种子的数据库写 DuckDB SQL、修复有 bug 的 Python 文件（附有测试不通过的测试套件）、从杂乱文本（如 Airflow 日志和账单邮件）中提取 JSON、预测有陷阱的 Python 代码片段会输出什么、快速问答（这类我通常会去 google 的问题）、以及从一份 7400 token 的运维手册中找到植入的事实。所有评分都是程序自动判定，不是人工阅卷：生成的 SQL 会被执行并逐行与参考查询比对，bug 修复必须通过 pytest，提取任务逐字段校验。每个模型还有一个 temperature 参数控制答案的随机程度，我设为 0 并跑了两遍，所以每个模型共 42 次运行。

有两点让我意外。第一是这些模型的正确率相当高。Gemma 4 的 12B 在整个测试套件中答对了 90%，包括 6/6 的 bug 修复题——这些题必须通过真实的测试套件才能得分，以及 8/10 的 SQL 题——按执行结果评分。2024 年的基准模型在同样任务上只拿了 52%，预测 Python 代码输出的题目 6 道全错，所以模型确实在这一年里取得了进步，至少在这两者之间是这样。

第二点意外是墙上时间（wall-time）列。老的 qwen2.5 飞速跑完整个套件只用了 3 分钟。那些比它成绩更好的模型在同样的 42 次运行上需要一到两个小时，而这之间的差距几乎全部来自推理 token。

整个测试套件的准确率与时间对比。只有 gemma4:e4b 同时做到了又快又准。

当前这一代模型都会先思考再回答，而在笔记本上，那段思考过程消耗了大部分时间。

我第一次运行将每次任务的生成分子顶格在 3072 token，这考虑到 Claude 在单个请求上消耗的 token 数量，其实并不算多。qwen3.5 系列模型在 84 次运行中有 48 次达到了这个上限，把整个预算都花在推理上，最终没有产出答案。两者的得分都在 40-57% 之间。我把预算翻倍到 8192 并重新跑：两者都正好增加了 10 次通过。能力是有的，模型只是需要额外数千个 token 才能到达答案。有些运行还把翻倍后的预算也用爆了。qwen3.5:9b 在一道 SQL 题上花了 8 分钟、输出了 34000 个字符的思考内容，最终还是超出了空间。

gemma 系列模型也会思考，通常少一些，但也不总是如此。在一次运行中，gemma4:12b 在思考"rwxr-xr--" 对应哪种数字 chmod 模式时花了 14 分钟，输出了 19000 个字符的思考内容，然后给出了 750。答案是 754。

在 API 上同样的行为会作为一项单独列出，推理 token 和其他 token 一样被计费。在本地运行则表现为等待的时间。

你还会停止 google 吗？

我真正关心的速度问题：一个快速的事实查询，问本地模型是否比搜索引擎更快？

对非思考模型来说答案是肯定的，至少在延迟上是。以模型已经加载完毕为前提，"Postgres 用什么端口"这个问题从 gemma4:e4b 和 qwen2.5 返回只需 0.6 到 1.1 秒。这比我把查询输入浏览器还快。思考模型在这里没有竞争力：qwen3.5:9b 每个快速问题平均耗时 17 秒，而 4B 平均 38 秒，这比任何搜索引擎都慢。

模型加载完毕后给出快速答案的中间时间。那些慢的模型把时间花在了思考上。

问题在于以这种速度返回的内容。三种模型对 chmod 这个问题给出了三个不同的错误答案：752、744、750。有两个模型对"撤销上次提交但保留更改在暂存区"这个问题建议用 git reset HEAD~ 或 HEAD^，但这恰恰做的是相反的操作——普通的 git reset 才是取消暂存。错误答案返回得和正确答案一样快、一样自信。搜索引擎结果页会给你 Stack Overflow 的投票数和三个可以交叉验证的竞争答案。本地模型给你一个答案，而且没有办法判断它是否正确。

长文档测试

粘贴一份 7400 token 的运维手册并提问，是笔记本硬件暴露真实极限的地方。五个模型都找到了植入的事实，甚至包括埋在很靠后位置的那个，所以能力不是问题。问题是等待时间：第一次提问 gemma4:e4b 需要 32 秒，qwen3.5:4b 需要 84 秒，gemma4:12b 需要 148 秒。我的 M1 Pro 处理输入 prompt 的速度是每秒 130 到 330 token，这就是为什么没人用笔记本模型跑编码类 agent。Claude Code 风格的工具链每次请求会发送数万 token 的系统提示词和上下文。以笔记本的速度，这意味着每次 agent 发请求都要等几分钟答案才会开始出来。

一个令人愉快的意外：针对同一份文档的追问返回很快，17 到 40 秒，因为 Ollama 把已处理的文档保留在内存里。和一份长文档聊天在本地是可行的，但任何每次请求都发送全新上下文的东西都做不到。

这才是我真正为它建这个基准测试的表格。整个套件，210 次运行，共用了 162000 个输入 token 和 412000 个输出 token。按当前的 API 定价，所有这些加起来花费：

整个基准测试，每个模型，每次重跑，按 DeepSeek 的价格只要 14 美分，Meta 如果让你用 prompt 训练他们价格还会更低。相比之下，我的笔记本花了 6.4 小时生成本地答案。电费算下来也就几分钱，所以本地方案技术上比 Opus 便宜。一旦我的时间有哪怕一点价值，这就不是真相了，而按 DeepSeek 的价格，根本没有什么可以省的。当 Uber 把工程师的 AI 账单上限设为每月 1500 美元时，你没有办法把任何有意义的用量转移到一台需要两个小时才能完成 14 美分工作的机器上。

所以在普通笔记本上跑本地模型的真正原因不是钱。而是 API 不是一个选项的场景：数据不能离开机器、离线工作、或者 API 宕机。我还发现了一个意料之外的原因。gemma4:e4b 在套件中每个提取任务都做对了，而且无论我运行多少次都不花一分钱。这和用 API 感觉不一样——每次请求都会计入账单。

我会真正保留哪个

如果有一个模型值得留在我的机器上，那就是 gemma4:e4b-it-qat。它在 30 tokens/秒的速度下通过了套件的 86%，快速问答在 1 秒内完成，整个基准测试在 18 分钟内跑完，而 12B 需要两个小时才能多得 4 个百分点。这就足以让它作为一个离线备份和一个免费的 JSON 提取工具留下来。

其他的都可以不要。12B 在这个硬件上慢到让人等不下去，思考模型花的时间超过了答案本身的价值，2024 年的基准模型很好地提醒了这些小模型在一年内进步了多少——从 52% 到 90%，体积大致相同。

所以回到文章开头那些建议。在我的笔记本上跑本地模型比我预期的要好。但它不会削减 AI 账单，而账单才是尝试这个的初衷。