低配机器的本地模型,绕不开一个矛盾:模型越小跑得越快,但能力也越弱。在一些不具备大显存独显的设备上,"超小模型"(参数低于 2B)几乎是唯一能跑得顺畅的选择。本文把当前 Ollama 里安装的全部生成模型按统一标准测一遍速度,重点看超小模型这一档的真实表现。
测试方法
- 硬件:MacBook Air M4,16G 统一内存
- 推理引擎:Ollama 0.32.9
- 测速方式:300 token 长文本生成,
temperature=0、关闭思考,充分预热后取 5 次平均值 - 生成速度单位:token/s(每秒生成 token 数)
测速用长文本生成而非短回复,是因为短回复测的是"首 token 延迟",长文本才反映持续生成的吞吐,更贴近实际使用。
完整速度表
当前 Ollama 里共 8 个生成模型(另有 5 个 embedding 模型,不参与生成速度对比),按参数规模排列:
| 模型 | 参数量 | 体积 | 量化 | 生成速度 |
|---|---|---|---|---|
| granite4:350m-h | 340M | 366 MB | Q8_0 | 30.2 tok/s |
| qwen3.5:0.8b-mlx | 0.8B | 1.2 GB | mxfp8 | 30.0 tok/s |
| lfm2.5-thinking | 1.2B | 731 MB | Q4_K_M | 26.3 tok/s |
| smollm2:1.7b | 1.7B | 1.8 GB | Q8_0 | 12.9 tok/s |
| qwen3.5:2b-mlx | 2B | 3.1 GB | mxfp8 | 11.0 tok/s |
| qwen3.5:4b-mlx | 4B | 4.0 GB | nvfp4 | 9.7 tok/s |
| qwen3.5:9b-mlx | 9B | 8.9 GB | nvfp4 | 5.1 tok/s |
| omnicoder-2-9b | 9B | 5.7 GB | Q4_K_M | 4.4 tok/s |
速度随参数量递减,但曲线并非线性——从 340M 到 1.2B 这一档,速度几乎持平在 26-30 tok/s;从 1.7B 起,速度降到 13 tok/s 以下。这个"分界"值得注意。
三个观察
340M 与 800M 速度相同,提示小模型受固定开销拖累。 granite4:350m-h 只有 340M 参数,是 qwen3.5:0.8b(800M)的 42%,但两者的生成速度完全一致(30.2 vs 30.0 tok/s)。参数少了 2.35 倍,速度却没有提升——这说明瓶颈可能不在"读取权重"(内存带宽),而在 Metal 引擎的固定开销:kernel 调度、内存延迟这类与参数规模无关的成本。当然,这只是本次样本的观察,未测更小的模型,不能据此断言存在某个绝对的速度上限。所谓 hybrid 架构(SSM 融合)在 Metal 后端上也未体现出速度优势。granite4:350m-h 的真正价值在于"能力密度"(此前工具调用评测通过率 67.4%,是所有模型里最小而最强的),而非推理速度。
qwen3.5:0.8b 的 30 tok/s 需要预热。 首次运行只有 6 tok/s,要到第 3 次才稳定到 27-32 tok/s。这是 Metal kernel 首次编译缓存导致的冷启动开销,其他模型同样存在,只是小模型更容易被掩盖。实际使用中,第一次对话明显偏慢,属正常现象。
lfm2.5-thinking 的"思考"开关似乎没有生效。 分别用 think=False 和 think=True 各测 5 次,速度都是 26.3 tok/s,没有差异。它此前在工具调用评测中耗时 668 秒(是 granite 的 10 倍),但那是"每步先思考再行动"累积的结果,而非生成速度慢。纯生成场景下,它的速度并无劣势。
超小模型这一档的取舍
把速度数据与之前的能力评测(智力、知识、代码、工具调用)合并起来看:
| 模型 | 速度 | 工具调用 | 特点 |
|---|---|---|---|
| granite4:350m-h | 30.2 | 67.4% | 最小最强,hybrid 架构 |
| qwen3.5:0.8b | 30.0 | 63.0% | 全功能,含视觉/思考 |
| lfm2.5-thinking | 26.3 | 76.1% | 工具调用最高,但"思考"存疑 |
| smollm2:1.7b | 12.9 | 76.1% | 工具调用并列最高 |
四项里没有单项通吃的赢家:granite4 体积最小、能力密度最高,lfm2.5 和 smollm2 工具调用更强,qwen3.5:0.8b 胜在功能全面(视觉、思考、工具调用都支持)。
简单总结
在 16G 内存的低配 MacBook 上,超小模型(<2B)的价值在于"常驻可用"——30 tok/s 的速度足以支撑日常对话和文本翻译之类的简单任务,366MB 的 granite4:350m-h 甚至可以一直挂在内存里随叫随到。但它们的上限也明确:一旦任务需要真正的代码生成或多步推理,就必须跨过 2B 这条线,接受速度的降低。
超小模型解决的是"有没有得用",不是"用得好不好"。前者在低配机器上,恰恰是最重要的。
- 要最小体积、常驻内存:granite4:350m-h,366MB 几乎无感,速度与其他超小模型持平(30 tok/s),简单工具调用够用。
- 要全功能、对付着用:qwen3.5:0.8b,视觉/思考/工具调用都支持,速度同样 30 tok/s,代价是体积略大。
- 要工具调用准确率:lfm2.5-thinking 或 smollm2:1.7b,前者更小更快,后者更稳。
- 要真正能写代码/复杂推理:越过 2B 这一档,上 qwen3.5:4b(9.7 tok/s,代码能力跃升),这是超小模型之外的第一个"甜点"。
- 不在乎速度:那还是 qwen3.5:9b 或者 omnicoder-2-9b(各种能力都强力提升),虽然速度相对慢了,但能力提升显著。
附录:模型拉取命令
文中涉及的模型均可通过以下命令拉取:
# 超小模型(参数 < 2B)
ollama pull granite4:350m-h
ollama pull qwen3.5:0.8b-mlx
ollama pull lfm2.5-thinking:latest
ollama pull smollm2:1.7b
# 小模型(2B - 4B)
ollama pull qwen3.5:2b-mlx
ollama pull qwen3.5:4b-mlx
# 9B 模型
ollama pull qwen3.5:9b-mlx
ollama pull carstenuhlig/omnicoder-2-9b