引言：Mac 已经是一台合格的推理机器

Apple Silicon 的统一内存架构（Unified Memory Architecture）改变了本地大模型推理的格局。当 CPU 和 GPU 共享同一块物理内存，不再需要通过 PCIe 总线搬运数据时，一台 32GB 的 MacBook Pro 就能流畅运行 7B 甚至 13B 参数的量化模型。这在两年前还难以想象。

那接下来的问题就是：推理框架怎么选？

MLX、llama.cpp、Ollama——三个名字在社区里反复出现，各有拥趸。它们的定位不同、设计哲学不同、适用场景也不同。这篇文章从工程实践角度出发，梳理三者的核心差异，帮你做出适合自己的选型判断。

MLX：苹果官方的「原生」方案

MLX 是 Apple 机器学习研究团队在 2023 年底开源的推理与训练框架，专为 Apple Silicon 设计。

核心特点：

• Lazy Evaluation：计算图延迟求值，只有在真正需要结果时才触发计算。这意味着中间张量不会占用额外内存，对显存紧张的场景友好。
• 统一内存原生支持：MLX 的数组可以在 CPU 和 GPU 之间零拷贝共享，充分利用 Apple Silicon 的 UMA 优势。
• NumPy 风格 API：上手门槛低，Python 开发者几乎无学习成本。
• 微调支持：内置 LoRA/QLoRA 训练能力，不只是推理框架。

实测表现（M4 芯片）：

以 Qwen2.5 7B Q4 量化为例，MLX 在 M4 上 decode 速度约 45-55 tok/s，prefill 速度通常更快。内存占用贴近模型文件本身大小，overhead 很小。

局限：

• 生态仍在早期，模型格式（safetensors）的可选范围不如 GGUF 丰富。
• 仅支持 Apple 平台，无法跨平台部署。
• 社区规模相对较小，遇到问题时可参考的资料有限。

适合谁： 在 Mac 上做模型实验和微调的研究者；追求最低内存占用的开发者；希望用纯 Python 生态完成端到端工作流的人。

llama.cpp：社区驱动的跨平台主力

llama.cpp 由 Georgi Gerganov 发起，是目前社区最活跃的本地推理引擎。最初为 LLaMA 模型设计，现已支持几乎所有主流开源模型。

核心特点：

• GGUF 格式生态：HuggingFace 上有海量预量化的 GGUF 模型文件，从 Q2 到 Q8 各种量化级别应有尽有。
• Metal 后端：通过 Apple Metal API 实现 GPU 加速，在 Apple Silicon 上表现优秀。
• 极致的跨平台能力：同一份代码支持 macOS、Linux、Windows，还支持 CUDA、Vulkan 等多种后端。
• C/C++ 实现：启动快、依赖少、资源占用小。
• 活跃的社区：每周都有性能优化 PR 合入，迭代速度极快。

实测表现（M4 芯片）：

Qwen3 7B Q4_K_M 格式，Metal 后端全层 offload 到 GPU，decode 速度约 40-50 tok/s。内存占用略高于 MLX，因为 llama.cpp 的 KV cache 管理策略不同。

局限：

• 编译安装对新手有门槛（虽然 brew install llama.cpp 已经简化了不少）。
• 配置参数较多，首次使用需要理解 n_gpu_layers、context size 等概念。
• 默认命令行交互，没有开箱即用的图形界面。

适合谁： 需要跨平台部署的工程师；对推理性能有极致追求并愿意调参的开发者；需要在服务端和本地使用同一套方案的团队。

Ollama：开箱即用的「Docker for LLMs」

Ollama 将 llama.cpp 包装成了一个用户友好的本地模型管理工具。如果说 llama.cpp 是引擎，Ollama 就是带方向盘和仪表盘的整车。

核心特点：

• 一键安装：brew install ollama 或下载 dmg，无需编译。
• 模型管理：ollama pull qwen3:7b 直接拉取模型，类似 Docker 的体验。
• OpenAI 兼容 API：启动后暴露标准 REST API，现有应用几乎零改动即可接入。
• 自动资源管理：自动检测 GPU、分配内存，用户无需手动指定 offload 层数。
• Modelfile 自定义：支持自定义系统提示词、参数、模板等。

实测表现（M4 芯片）：

底层基于 llama.cpp，推理速度与直接使用 llama.cpp 基本一致。Ollama 的额外开销主要在模型加载阶段，运行时差异可忽略不计。

局限：

• 抽象层带来的代价：无法精细控制量化参数、采样策略等底层细节。
• 模型库虽然丰富但不如直接使用 GGUF 灵活——自定义模型需要额外打包步骤。
• 运行为常驻后台服务，占用一定系统资源。

适合谁： 想快速体验本地模型的开发者；需要为应用提供本地 LLM API 的产品团队；不想折腾编译和配置的用户。

横向对比

维度	MLX	llama.cpp	Ollama
安装难度	pip install mlx-lm	需编译或 brew	一键安装
推理速度（7B Q4, M4）	45-55 tok/s	40-50 tok/s	≈ llama.cpp
内存效率	最优（lazy eval）	良好	同 llama.cpp
模型格式	safetensors	GGUF（最丰富）	基于 GGUF
跨平台	仅 Apple	全平台	macOS/Linux
微调能力	内置 LoRA	不支持	不支持
API 接口	Python 原生	CLI/Server	REST API
上手曲线	低（Python 用户）	中	最低

选型建议

场景一：快速验证想法，给应用加个本地 AI 能力
→ 选 Ollama。五分钟跑起来，REST API 直接对接前端，不折腾。

场景二：做模型研究，需要训练或微调
→ 选 MLX。原生支持 LoRA，Python 生态完整，内存效率最高。

场景三：生产环境部署，需要极致性能和跨平台
→ 选 llama.cpp。细粒度控制、社区迭代快、服务端和本地统一方案。

场景四：不确定选哪个
→ 从 Ollama 开始。当你发现需要更多控制权时再迁移到 llama.cpp，当你需要微调时再看 MLX。三者并不互斥。

框架之上：从「跑得动」到「用得起来」

推理框架解决的是让模型在本地跑起来的问题。在这个基础之上，还有两个方向值得关注：

推理加速层：Cider

如果对 MLX 的推理速度还想进一步压榨，可以看看 Cider——这是明略科技开源的 Apple Silicon 推理加速 SDK，核心做的事情是为 MLX 模型补上激活量化能力，释放 Apple Silicon 的 INT8 硬件性能。实测在 M4/M5 芯片上比原生 MLX 快 1.5-2.2 倍。如果你已经在用 MLX 跑模型，Cider 可以作为一个加速插件直接接入。

👉 https://github.com/Mininglamp-AI/cider

应用层：Mano-P

当本地推理足够快时，开发者需要模型能理解屏幕内容、操作应用界面、完成实际工作流。Mano-P 是运行在 Apple Silicon 上的端侧 GUI Agent，利用本地推理能力（4B 量化模型，prefill 476 tokens/s，decode 76 tokens/s，峰值内存 4.3GB）驱动屏幕理解和操作执行。数据不离开本机，全部推理在设备端完成。在 OSWorld 基准测试中以 58.2% 排名第一。

👉 https://github.com/Mininglamp-AI/Mano-P