超小模型在超低配 MacBook 上的运行性能实测

低配机器的本地模型,绕不开一个矛盾:模型越小跑得越快,但能力也越弱。在一些不具备大显存独显的设备上,"超小模型"(参数低于 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=Falsethink=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