Mac M5 上的本地 LLM：MLX 如今已大幅领先 llama.cpp（数据 2026)

#为何M5对Mac平台上的本地LLM产生重大影响

M5 芯片带来了两项对推理真正重要的改进：每个 GPU 核心都集成了矩阵乘法单元（Neural Accelerators），以及更高的内存带宽。而大语言模型（LLM）的推理首先是一个内存带宽问题——每生成一个 token，都要重新读取模型的全部权重。统一内存越快，token 的生成速度就越快。

正是在这一点上，Apple 的 MLX 框架比 llama.cpp 更有优势。MLX 专门针对 M5 GPU 的这些新型矩阵计算单元编写，能够直接利用它们，而 llama.cpp 的 Metal 路径则更为通用。实际效果是：在相同设备、相同模型和相同量化条件下，MLX 每秒生成的 token 数明显更多。在 M3 上，这一差距很小；到了 M5 上，差距就明显了。

#M5 和 M5 Max 性能测试：2026 年数据

以下是在常见的 4 位量化模型上，使用 MLX 在生成（decode）阶段测得的数量级参考。和本地推理一贯的情况一样，这些生成吞吐量会随上下文长度、模型的具体版本以及机器温度而变化：请将它们视为参考，而不是精确到单个 token 的速度保证。

• MacBook Pro M5 Max 128 GB：本地 AI 真实实测数据（2026 基准测试）

M5（GPU 10核）—— 8B Q4

生成速度约为55–70 tokens/s。8B模型（Qwen 3.5、Granite 4.2、Gemma 4）在基础款芯片上仍能运行得很流畅。

M5 Max — 8B Q4

约230 tokens/s。Max更高的内存带宽在小模型上体现出优势，这类模型的瓶颈从来都不是GPU。

M5 Max — 32B Q4

约 55–65 tokens/s。32B 级别的模型（Qwen 3.8 27B、Devstral）运行速度足以让人舒适地阅读，完全适合交互使用。

M5 Max — 70B Q4

~28 tokens/s。70B 模型在 Q4 量化下，当统一内存达到 48-64 GB 时即可加载并保持流畅，适用于聊天和代码生成。

最引人注目的是，一台没有独立显卡、运行安静且能装进包里的机器，运行 70B 模型时能达到约 28 tokens/s。相比之下，PC 要达到相当的速度，需要一张 RTX 4090 24 GB 显卡（还需要将模型的一部分卸载到 CPU 端运行，因为 70B Q4 模型约占 40 GB，无法完全装入 24 GB 显存），而噪音和功耗都要高得多。

#MLX 与 llama.cpp：差距在哪些方面拉大

MLX 的 30% 至 40% 性能优势并非在所有情况下都相同，而是取决于负载特征。了解这一差距在什么情况下会扩大，有助于判断何时切换到 MLX 确实值得。

生成（解码）

正是在这一环节，MLX 在 M5 上的领先优势最为明显，这得益于它直接使用 GPU 的矩阵单元。对于交互式聊天，这就是您能切身感受到的差距。

提示词处理（prefill）

MLX 仍具优势，但差距略小一些。在超长上下文下，两种引擎都会受到内存限制。

模型支持

llama.cpp 借助 GGUF 格式仍具有更强的通用性；MLX 则要求使用转换为 MLX 格式的版本。热门模型几乎都有现成的转换版本（可在 Hugging Face 的 mlx-community 社区中找到）。

Python集成

MLX 原生支持 Python，使其成为原型开发、轻量微调或自建流程的首选，而 llama.cpp 需通过绑定实现。

#各模型的前置条件及推荐 RAM

安装前，请根据您的统一内存调整模型大小。以下是 M5 和 M5 Max 在 Q4 下的合理配置级别。

16 GB（M5）

3B 至 8B 模型采用 Q4 量化时可以轻松运行。14B 模型也能运行，但留给长上下文的余量很小。

24-32 GB (M5 / M5 Pro)

14B 模型可以轻松运行；内存容量接近该区间上限时，也能运行 Q4 量化的 32B 模型。这是日常多用途使用的理想配置。

48 GB (M5 Max)

32B Q4 模型运行起来很宽裕，70B Q4 则只是勉强够用——如果要运行 70B 模型并为上下文留出空间，最好选择 64 GB 内存。

64-128 GB（M5 Max）

流畅运行带有大上下文的 70B Q4 模型，或同时加载多个模型。这是高级用户的使用范畴。

软件方面，您需要将 macOS 更新到最新版本，并通过以下两种途径之一使用 MLX：LM Studio（当模型有 MLX 版本时，会自动切换到 MLX），或自 2026 年 6 月更新起支持这一功能的 Ollama；这次更新将在下文详细介绍。

#Ollama 的 MLX 引擎（2026年6月）

过去，Ollama 依赖其自研引擎和 llama.cpp，因此在 Mac 上使用 Metal 后端。自 2026 年 6 月更新以来，只要有可用的 MLX 版本，Ollama 就能通过 MLX 在 Apple Silicon 上运行模型——这终于让使用最广泛的本地 AI 工具在性能上追平了 LM Studio 早已通过 MLX 达到的水平。

具体来说，这意味着您无需改变现有使用习惯，就能获得 MLX 带来的性能提升：Ollama 守护进程仍默认使用 11434 端口，命令不变，兼容 OpenAI 的 API 也不变。引擎会在适用时选择 MLX，否则回退到原有运行路径。

#使用 MLX 安装并运行模型

根据您对终端操作的熟悉程度，有两种选择。想无需配置就试用 MLX，最直接的方式是 LM Studio；想集成到技术栈中，最方便的是 Ollama。

1. 01
   1. 更新工具

   请安装最新版本的 Ollama（2026 年 6 月或更新版本）或 LM Studio。这是使用 MLX 运行路径的前提条件。
2. 02
   2. 选择带有 MLX 版本的模型

   在搭载 Apple Silicon 的设备上，LM Studio 的搜索会优先提供 MLX 版本。在 Ollama 中，拉取一个常见模型：如果存在转换后的版本，引擎就会切换到 MLX。
3. 03
   3. 启动并检查吞吐量

   提出一个长问题并查看 tokens/s 显示值。可对比相同模型的 GGUF 版本，以测量在您设备上的实际性能差异。
4. 04
   4. 必要时调整量化

   如果模型占满了您的统一内存，请将量化等级降低一档（Q5 → Q4_K_M），而不是更换工具：限制来自内存，而非推理引擎。

# Vérifier la version d'Ollama (le support MLX date de juin 2026)
ollama --version

# Lancer un modèle : Ollama emprunte MLX quand une version MLX existe
ollama run qwen3:8b

# Le daemon expose l'API compatible OpenAI sur le port par défaut
curl http://localhost:11434/api/tags

在 Python 中，可以直接为 MLX 编写脚本，便于进行基准测试或将推理集成到自建流水线中：

# Installer les outils MLX pour LLM (framework Apple, natif Python)
pip install mlx-lm

# Générer avec un modèle converti au format MLX (hub mlx-community)
mlx_lm.generate --model mlx-community/Qwen3-8B-4bit \
  --prompt "Explique la mémoire unifiée du M5 en trois phrases"

#用于 120B+ 模型的 Thunderbolt 5 集群

单台 Mac，即使是配置较高的 M5 Max，也受限于其统一内存。为了突破这一限制——例如运行 120B+ 或大型 MoE 模型——2026 年的做法是通过 Thunderbolt 5 连接多台 Apple Silicon 机器，并在它们之间分配模型。Thunderbolt 5 提供的带宽远高于 Thunderbolt 4，这使得节点间激活值的交换在推理场景中终于变得可行。

原理是：模型按层划分成多个部分，每台机器在内存中存放一部分权重，每生成一个 token，激活值就从一个节点传递到下一个节点。这样就能汇集多台 Mac 的统一内存，加载任何一台单独都装不下的模型。

能实现什么

Q4 量化的 120B 及以上模型，甚至超大型 MoE 模型，例如将两台配备 128 GB 内存的 M5 Max 设备组合使用，使可寻址内存接近 256 GB。

权衡取舍

节点间延迟会降低每秒生成的 token 数：与一台能容纳同一模型的机器相比，集群更慢。选择集群是因为没有任何一台机器能单独容纳该模型，而不是为了提高速度。

接线

Thunderbolt 5 是关键：其带宽使激活数据的传输开销处于可接受的范围。使用 Thunderbolt 4 或以太网时，互连又会成为瓶颈。

#技巧与故障排除

“MLX 并不会更快”

请先确认您确实在使用 MLX 执行路径（工具版本已更新，且实际加载的是模型的 MLX 变体）。通过 Metal 路径加载的 GGUF 模型无法获得 MLX 的优势。

几分钟后吞吐量急剧下降

这是过热导致的降频，尤其容易出现在 MacBook Air（无风扇）上。在长时间持续负载下，MacBook Pro 或 Mac mini/Studio 能保持更稳定的吞吐量。

模型无法加载

统一内存已满。请换用小一档的模型，或将量化位数降低一档；关闭占用大量 RAM 的应用程序。

长上下文导致卡顿

非常长的提示在预填充（prefill）阶段会消耗大量内存。如果不需要这么大的上下文窗口，请将其缩小；否则就接受首个 token 的等待时间更长。

#深入了解

这些指南进一步拓展了您刚刚阅读的内容，涵盖深入对比到具体部署：

MLX与llama.cpp的详细对比

《Mac M 系列上的 MLX 与 llama.cpp：2026 年谁更胜一筹？》深入比较了两者在模型支持、量化和 Python 集成方面的差异，而不只关注 M5 的性能数据。

在 macOS 上安装 Ollama

《在 macOS（Apple Silicon）上安装 Ollama》介绍了逐步安装方法和统一内存的利用方式，这是转向 MLX 之前必不可少的基础。

选择量化方案

《选择量化方式（Q4、Q5、Q8、FP16）》解释了质量与内存占用之间的权衡——这才是让模型装得进您的统一内存的关键。