24GB Mac 跑本地小模型，Ollama、llama.cpp、MLX 哪个更合适

woosley
13 阅读10分钟

24GB Mac 本地小模型实测：3 个推理后端、4 个模型，怎么选

这篇只回答一个问题：

Mac Mini M4 24GB 这台机器，如果要接本地小模型做 Hermes 的辅助任务，应该选哪个推理后端，配哪个模型。

这里的辅助任务指的是 compression、title_generation、session_search 这类高频但不需要超强推理的工作。判断标准也因此比较明确：

  • 输出要稳定，不能频繁空返回
  • 内存占用要可控，不能把 24GB 很快吃满
  • 最好直接提供 OpenAI 兼容 API，便于接入 Hermes
  • 在有限内存下，模型质量、上下文长度和速度要能平衡

先给结论：

  • 推理后端首选 llama.cpp
  • Hermes 辅助模型首选 Qwen3-14B Q4_K_M
  • Ollama 适合快速体验，不适合精细调优
  • MLX 在这台 M4 上没有跑赢 llama.cpp，但这个结论不一定适用于更高配的 Apple Silicon

一、测试环境与测试对象

机器：Mac Mini M4
内存：24GB 统一内存
系统：macOS 15.6
网络：中国大陆
下载方式：hf-mirror.com

这次测试覆盖 3 个推理后端：

  • Ollama
  • llama.cpp
  • MLX（通过 omlx）

实际跑过的模型有 6 个：

  • Ollama + Qwen3:8b
  • Qwen3.5-9B Q4_K_M
  • Qwen3.5-9B MLX 4bit
  • Qwen3-14B Q4_K_M
  • DeepSeek R1-14B Q4_K_M
  • Phi-4-reasoning-plus Q4_K_M

其中，最终做标准化 benchmark 的核心对象是 4 个模型：

  • Qwen3.5-9B
  • Qwen3-14B
  • DeepSeek R1-14B
  • Phi-4-reasoning-plus

二、先说明这三个东西分别是什么

很多人第一次看这类文章，容易把模型和推理后端混在一起。

这里先拆开：

  • 模型：比如 Qwen3-14B、DeepSeek R1-14B，决定回答质量和能力上限
  • 推理后端：比如 Ollama、llama.cpp、MLX，负责把模型加载起来，对外提供服务

这篇对比的重点不是模型本身，而是：在 24GB Mac 上，用哪个后端把模型跑起来更合适。

1. Ollama

Ollama 可以理解成一套封装好的本地模型运行工具。

它把模型下载、启动服务、调用接口这些事情都包起来了。优点是上手快，命令简单，适合第一次体验本地模型的人。

ollama run qwen3:8b

如果只想先把模型跑起来，Ollama 几乎是最简单的入口。

2. llama.cpp

llama.cpp 是更底层的推理引擎。

它主要跑 GGUF 格式模型，参数控制能力更强，适合自己管上下文、KV Cache、GPU offload 和服务启动参数。很多本地部署文章最后都会落到 llama.cpp，本质上就是因为它给的控制权更多。

3. MLX

MLX 是苹果面向 Apple Silicon 的机器学习框架。本文里实际使用的是 omlx 这个服务封装，让 MLX 模型以 API 的方式跑起来。

它的吸引力在于原生吃 Apple Silicon 这套硬件栈，理论上在 Mac 上应该有优势。

三者关系可以这样理解

  • Ollama：更像开箱即用的整机方案
  • llama.cpp：更像可调参数很多的专业工具
  • MLX：更像苹果体系内的原生路线

所以这篇后面比较的不是“谁更先进”，而是：在 Mac Mini M4 24GB 这个约束下，谁更适合拿来跑本地辅助模型。

三、三个推理后端的实际差别

1. Ollama：最快上手

Ollama 的优势很直接：安装简单，拉模型简单，启动也简单。

ollama run qwen3:8b

如果目标只是先把模型跑起来，或者本地聊天体验一下，Ollama 仍然是最省事的入口。

问题也很明确：

  • KV Cache 量化控制空间小
  • 模型来源主要受 Ollama Registry 限制
  • 参数层面的可调性不够

这会直接影响 24GB 机器上的资源利用率。放到 Hermes 这种需要长期稳定跑辅助任务的场景里，控制粒度还是不够。

2. llama.cpp：综合能力最强

llama.cpp 是这次测试里最均衡的方案。

它的优势主要在这几项：

  • GGUF 模型选择多
  • 支持 KV Cache 量化
  • 支持 Flash Attention
  • 直接暴露 OpenAI 兼容 API
  • 参数可调，便于控制显存和内存预算

代价是配置比 Ollama 复杂，需要自己管启动参数。但如果目标是长期接入本地服务，这个复杂度是值得换的。

3. MLX / omlx：理论上有优势，这台机器上没有体现出来

MLX 最大的预期来自 Apple Silicon 原生优化。

但这轮测试在 Mac Mini M4 24GB 上没有跑赢 llama.cpp。至少在当前机器、当前模型和这组参数下，它不是更优选。

这个结论需要加边界：如果换成 GPU 核心更多的机器，比如 M5 Max，MLX 仍然值得重测。

四、24GB 机器上，真正限制结果的是什么

这类本地部署，瓶颈不只是模型体积。

24GB 内存里真正互相竞争的是三部分：

  1. 模型参数本体
  2. KV Cache
  3. 思考链带来的 token 消耗

前两项比较直观。第三项在辅助任务里影响尤其大。

像 title_generation、compression 这类任务，本身不需要长推理。如果模型把大量预算耗在 <think> 里，最后就会出现两种问题：

  • 返回内容明显变短
  • 直接空输出

聊天场景里，这可能只是变慢或者变啰嗦。放到辅助任务链路里，空输出就是失败。

KV Cache 是这次测试里最关键的变量

以 Qwen3.5-9B 为例，128K 上下文下：

  • f16 KV Cache：大约 16GB
  • Q4 KV Cache：大约 4GB

差距非常大。

如果没有 KV Cache 量化，24GB 机器上想同时保住大上下文和稳定服务，空间非常紧。这也是为什么 Ollama 在这个场景里不占优：关键控制点不够多。

五、安装与启动方式

安装

brew install ollama
brew install llama.cpp
brew install huggingface-cli
brew install omlx

模型下载

在中国大陆直连 HuggingFace 经常超时，镜像更稳：

HF_ENDPOINT=https://hf-mirror.com \
  hf download unsloth/模型名-GGUF 文件名.gguf \
  --local-dir ~/models

实测下载速度大约 7-10 MB/s。

llama.cpp 启动参数

9B 模型：

llama-server \
  -m ~/models/Qwen3.5-9B-Q4_K_M.gguf \
  -ngl 99 -c 131072 -np 1 -fa on \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  --host 127.0.0.1 --port 8081

14B 模型建议把上下文调到 64K：

llama-server \
  -m ~/models/Qwen3-14B-Q4_K_M.gguf \
  -ngl 99 -c 65536 -np 1 -fa on \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  --host 127.0.0.1 --port 8081

关键参数：

  • -ngl 99：尽量把层放到 GPU（Metal）
  • -c：上下文窗口
  • -fa on：Flash Attention
  • --cache-type-k/v q4_0：KV Cache 4-bit 量化

MLX / omlx 启动参数

omlx serve --model-dir ~/.omlx/models \
  --host 127.0.0.1 --port 8000 \
  --api-key "local-test"

这里有一个明显的坑：omlx 默认需要 API key，不加会直接返回 401。

六、后端实测：llama.cpp vs MLX

同一个模型 Qwen3.5-9B，对比结果如下：

指标llama.cppMLX / omlx
首 token 延迟361 ms~2-3 s
生成速度16.5 tok/s~14.8 tok/s
512 tokens 总时间31.4 s34.7 s

这台 M4 上，llama.cpp 全面领先。

这和 Hermes 官方在 M5 Max 上测到的“MLX 更快”并不一致，说明后端选择和机器型号强相关，不能简单照搬别人的结论。

七、标准化 benchmark：4 个模型横评

为了避免只靠主观体感判断，这次补了一套标准化 benchmark，覆盖四类任务：

维度测试数量评分方式
数学推理5 题自动评分
代码生成3 题实际运行测试用例
中文理解3 题自动评分 + 关键词覆盖
Hermes 辅助任务3 题标题生成 / 对话压缩 / 信息提取

每个模型都测试两种模式：

  • THINKING：允许输出思考过程
  • NO_THINK：关闭思考链，更接近 Hermes 辅助任务的真实使用方式

NO_THINK 模式总表

模型数学代码中文 QA速度 (t/s)总耗时综合评价
Qwen3-14B5/53/31/19.4157s最佳
DeepSeek R1-14B5/52/31/110.9662s稳定但偏长
Phi-4-reasoning-plus5/50/31/110.71657s输出循环崩坏
Qwen3.5-9B0/52/31/116.21050s思考链吃光 token

结果

Qwen3-14B

Qwen3-14B 是这轮测试里最稳的模型。

  • 数学 5/5
  • 代码 3/3
  • 中文任务正常
  • 辅助任务输出干净
  • 总耗时 157 秒

关键不是单项最好，而是没有明显短板。对于辅助任务，稳定返回结果比单项跑分更重要。

DeepSeek R1-14B

DeepSeek R1-14B 的主要问题不是答不好，而是输出偏长。

  • 数学 5/5
  • 中文质量也很好
  • token 消耗明显偏高
  • 即使加 /no_think，仍然会输出推理过程

做主模型时，这个问题未必致命。做高频辅助模型时，代价就比较明显了。

Phi-4-reasoning-plus

这次最不推荐的是 Phi-4-reasoning-plus。

  • 数学题能答对
  • 代码生成直接崩
  • 标题生成和对话压缩输出冗长
  • 容易陷入循环重复

benchmark 表面分数不算最低，但真实可用性很差。

Qwen3.5-9B

Qwen3.5-9B 的问题也很典型：速度快，但对这个场景没有帮助。

它经常把预算耗在思考链上，最后 API 返回空字符串。对 Hermes 这种工作流来说，这个问题比慢更严重。

八、最终推荐

按场景拆开，结论比较清楚。

1. 接 Hermes 辅助任务

Qwen3-14B Q4_K_M + llama.cpp。

这是这轮测试里最稳的组合，benchmark 成绩最好，OpenAI 兼容 API 直接可用，KV Cache 也能控制，24GB 内存下可以稳定运行。

2. 更看重推理过程

DeepSeek R1-14B 可以作为备选。

前提是接受更高的 token 消耗，也不把它放进高频辅助链路。

3. 只是本地体验

Ollama 仍然是最省事的入口。

4. 不推荐

  • Phi-4-reasoning-plus：循环重复问题明显
  • Qwen3.5-9B：辅助任务空输出问题明显

九、接入 Hermes 的配置方式

本地模型适合承担这类任务：

  • compression
  • title_generation
  • session_search

配置方式如下：

providers:
  local-llm:
    base_url: http://127.0.0.1:8081/v1
    api_key: ""

auxiliary:
  compression:
    provider: local-llm
    model: Qwen3-14B-Q4_K_M.gguf
    timeout: 120
  title_generation:
    provider: local-llm
    model: Qwen3-14B-Q4_K_M.gguf
    timeout: 30
  session_search:
    provider: local-llm
    model: Qwen3-14B-Q4_K_M.gguf
    timeout: 30

不建议这样用：

  • 替换主模型
  • 跑 vision
  • 跑复杂 web_extract
  • 当 fallback provider

24GB 的本地方案适合承担辅助工作，不适合接所有重任务。

十、踩坑记录

问题原因解决
HuggingFace 直连超时中国大陆网络问题用 HF_ENDPOINT=https://hf-mirror.com
端口 8080 被占用本地已有其他服务改用 8081
omlx 返回 401缺少 API key加 --api-key
Qwen3.5-9B-mlx-lm-mxfp4 下载 401Gated model改用公开的 Qwen3.5-9B-MLX-4bit
Hermes chat 超时本地模型处理大 prompt 较慢Hermes 会对 localhost 放宽超时
DeepSeek R1 输出 <think>模型特性正常行为
Phi-4 输出循环重复reasoning 模式不稳定不建议本地使用

十一、结论

在 Mac Mini M4 24GB 上，本地方案的关键不只是选一个后端、拉一个模型。后端能力、KV Cache 量化、思考链开销、辅助任务类型，都会直接改变结果。

如果目标是给 Hermes 找一个本地辅助模型，这轮测试的结论是：

llama.cpp + Qwen3-14B Q4_K_M 是当前最合适的组合。

原因很简单：

  • benchmark 总成绩最好
  • 输出最稳定
  • OpenAI 兼容 API 直接可用
  • KV Cache 可以自己控制
  • 24GB 内存下资源分配更容易收住

如果只是本地聊天，Ollama 仍然适合快速开始。
如果换成更强的 Apple Silicon，MLX 仍然值得重测。
但按这台机器和这轮结果看，这两条都不是优先选项。

avatar
文章
阅读
粉丝