第一次对 MLX 产生"这东西不一样"的感觉，是在 M4 Max 上跑 Qwen 3.5 35B-A3B 那个 MoE 模型的时候。同一个模型，Ollama 跑出来大概 35 tok/s，切到 MLX-LM 之后直接飙到 65-70 tok/s。提示词处理的差距更夸张，某些场景下快了五倍。
我当时的反应是不太相信，以为是测量方式不同。但反复测了好几次，结果很稳定。后来看到学术界一篇系统性对比论文，在 M2 Ultra 上的数据更明显：MLX 稳态吞吐量约 230 tok/s，Ollama 大概 20-40 tok/s。当然这俩不完全是苹果对苹果的对比——Ollama 的便利性和生态远比 MLX-LM 完善——但性能差距是实实在在的。
这篇文章想把 MLX-LM 这个东西彻底说清楚：它到底是什么、为什么在 Apple Silicon 上能这么快、怎么用它做推理和微调、跟 Ollama 的真实关系是什么、以及苹果在 WWDC 2025 和 M5 发布后给出的战略信号意味着什么。
先把关系理清楚：MLX、MLX-LM、mlx-community
这三个东西经常被混着用，但它们是不同层次的概念。
MLX 是底层数组计算框架，类似于 NumPy/PyTorch/JAX 的定位，由 Apple 机器学习研究团队开发。它不是专门为大语言模型设计的，而是一个通用的机器学习框架——你可以用它做矩阵运算、图像生成、语音处理、科学计算，当然也可以跑 LLM。2023 年底首次发布，MIT 许可证，完全开源。截至 2026 年 3 月最新版本是 0.31.1。
核心开发团队四个人：Awni Hannun、Jagrit Digani、Angelos Katharopoulos、Ronan Collobert，都是 Apple 机器学习研究部门的研究员。
MLX-LM 是建立在 MLX 之上的大语言模型专用包。它提供了一套命令行工具和 Python API，让你不写代码就能做 LLM 推理、量化和 LoRA 微调。pip install mlx-lm 一行命令装好，然后 mlx_lm.generate、mlx_lm.chat、mlx_lm.convert、mlx_lm.lora 这几个子命令覆盖了日常使用的所有场景。
mlx-community 是 Hugging Face 上的一个社区组织，里面存放了大量预先转换和量化好的 MLX 格式模型。你可以直接用 mlx_lm.generate --model mlx-community/Qwen3.5-27B-4bit 来拉取和运行这些模型，省去了自己做格式转换的步骤。目前主流的开源模型（Llama、Qwen、Mistral、Gemma、Phi、DeepSeek 等）几乎都有对应的 mlx-community 版本。
简单说：MLX 是引擎，MLX-LM 是方向盘，mlx-community 是加油站。
为什么 MLX 在 Apple Silicon 上这么快
这是整篇文章最核心的技术问题。理解了这个，后面的所有讨论都有了根基。
统一内存架构：零拷贝的数学意义
Apple Silicon 最大的架构特点是统一内存（Unified Memory）——CPU 和 GPU 共享同一块物理内存。这个设计在消费电子领域是为了降低功耗和成本，但在 AI 推理场景下有一个意想不到的巨大优势。
传统的 NVIDIA GPU 工作流是这样的：模型权重存在系统内存（RAM）里 → 通过 PCIe 总线搬运到 GPU 显存（VRAM）里 → GPU 做计算 → 结果搬回 RAM。这个来回搬运的过程就是所谓的"内存拷贝开销"。
在 Apple Silicon 上，CPU 和 GPU 看到的是同一块内存。MLX 充分利用了这一点——数组创建之后就在共享内存里，CPU 和 GPU 可以直接在上面操作，不需要拷贝。用代码来说就是：
import mlx.core as mx
# 这个数组在共享内存中，CPU 和 GPU 都能直接访问
a = mx.ones((1000, 1000))
# 在 GPU 上计算——不需要搬数据
c = mx.add(a, a, stream=mx.gpu)
# 在 CPU 上计算——也不需要搬数据，操作的是同一块内存
d = mx.multiply(a, a, stream=mx.cpu)
PyTorch 在 Mac 上用的是 MPS（Metal Performance Shaders）后端，虽然也能利用 GPU 加速，但它的内存抽象层没有完全消除 CPU 和 GPU 之间的拷贝开销。Ollama 底层用的 llama.cpp 通过 Metal 后端加速，也面临同样的问题——它的抽象层是为"CPU 内存和 GPU 显存分离"的架构设计的，在统一内存上运行时并没有充分利用"零拷贝"的优势。
具体到数字上：有测评显示，MLX 比 PyTorch MPS 的推理速度快 20-40%，内存使用低 10-20%，原因就在这里。
惰性计算和编译优化
MLX 的另一个设计特点是惰性计算（Lazy Evaluation）——计算不会立即执行，而是构建一个计算图，等到结果真正被需要的时候才一起执行。这让 MLX 有机会在执行前对整个计算图做优化：合并操作、消除冗余计算、优化内存分配。
同时 MLX 支持函数变换组合——自动微分（mx.grad）、自动向量化（mx.vmap）、计算图优化（mx.compile）可以任意组合。这些变换是组合式的，意味着你可以对一个函数同时求梯度并编译优化，MLX 会自动把所有优化叠在一起。
对于 LLM 推理来说，这意味着 MLX 可以把"读 token → 过 attention 层 → 过 FFN 层 → 采样下一个 token"这整个循环编译成一个高度优化的 Metal compute shader，减少 GPU 调度开销。
M5 的 Neural Accelerators：专门为矩阵乘法造的硬件
2025 年 11 月发布的 M5 芯片引入了 GPU Neural Accelerators——嵌入在每个 GPU 核心中的专用矩阵乘法单元。M5 Max 有 40 个 GPU 核心，意味着 40 个 Neural Accelerators 并行工作。
Apple 自己的 MLX 团队做了基准测试，结果很说明问题：M5 MacBook Pro 相比 M4 MacBook Pro，首 token 时间（TTFT）快了 3.3-4 倍。具体来说，一个 dense 14B 模型的 TTFT 在 M5 上低于 10 秒，一个 30B 的 MoE 模型低于 3 秒。这个提升几乎完全来自 Neural Accelerators，因为 TTFT 是计算密集型的（compute-bound）。
token 生成速度（TGS）的提升则相对温和，大约 19-27%，基本跟内存带宽的提升幅度一致（M5 MacBook Pro 153 GB/s vs M4 的 120 GB/s）。这证实了 LLM 推理中 token 生成阶段是内存带宽受限的（memory-bound），再快的计算单元也得等内存把数据喂过来。
重点来了：这些 Neural Accelerator 的优化目前主要通过 MLX 生效。 Ollama 底层的 llama.cpp 虽然也有 Metal 支持，但还没有专门为 Neural Accelerators 做优化。这意味着在 M5 硬件上，MLX 和 Ollama 的性能差距会进一步拉大。Apple 官方在 M5 发布时直接点名 LM Studio（它支持 MLX 后端），而不是 Ollama，这个选择本身就很说明问题。
MLX-LM 实操：推理、量化、微调
推理：两行命令的事
装好之后，最基本的用法就是：
pip install mlx-lm
mlx_lm.generate \
--model mlx-community/Qwen3.5-27B-4bit \
--prompt "用 Python 实现一个快速排序" \
--max-tokens 500
或者用交互式聊天模式：
mlx_lm.chat --model mlx-community/Mistral-7B-Instruct-v0.3-4bit
模型会自动从 Hugging Face 下载到本地缓存。后续运行直接从缓存加载，不需要重新下载。
如果你更喜欢用 Python API（比如集成到自己的应用里）：
from mlx_lm import load, generate
model, tokenizer = load("mlx-community/Qwen3.5-27B-4bit")
response = generate(model, tokenizer, prompt="解释一下什么是 KV cache", max_tokens=500)
print(response)
流式输出也支持，这在做聊天应用时是必须的。
量化：几秒钟搞定
MLX 的量化是内置的，不需要额外的工具。一条命令就能把 Hugging Face 上的模型量化为 4-bit 并保存：
mlx_lm.convert \
--hf-path mistralai/Mistral-7B-Instruct-v0.3 \
-q \
--q-bits 4 \
--upload-repo mlx-community/Mistral-7B-Instruct-v0.3-4bit
这个命令做了三件事：从 Hugging Face 下载原始模型、量化到 4-bit、上传到指定的 Hugging Face repo。整个过程在一个 7B 模型上只需要几秒钟。
支持的量化精度包括 4-bit 和 8-bit，还支持更新的 MXFP4 和 NVFP4 格式（后者对 MoE 模型的 router gate 保持 8-bit 精度，提升路由准确性）。
一个实际的内存估算帮你做选择：
- Llama-7B 全精度：~28 GB
- Llama-7B + LoRA（rank=8）：~14 GB
- Llama-7B + QLoRA（4-bit + LoRA）：~7 GB
也就是说，一台 16GB 内存的 MacBook 用 QLoRA 就能跑 7B 模型的微调，而不只是推理。
LoRA 微调：这才是 MLX-LM 真正的杀手级功能
如果说推理 Ollama 也能做（虽然慢一些），那本地微调是 MLX-LM 真正拉开差距的地方。Ollama 完全不支持训练，它只管推理。MLX-LM 支持 LoRA、QLoRA、DoRA、Full Fine-tuning 多种微调方式。
最常用的 LoRA 微调只需要一条命令：
mlx_lm.lora \
--model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
--data ./my-training-data \
--train \
--batch-size 1 \
--lora-layers 8 \
--iters 1000
训练数据是 JSONL 格式，每行一个训练样本：
{"text": "Below is an instruction...\n\n### Input:\n...\n\n### Response:\n..."}
训练完成后，adapter 权重保存在 adapters.npz 文件中。你可以直接带着 adapter 做推理：
mlx_lm.generate \
--model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
--adapter-path ./adapters.npz \
--prompt "..."
或者把 adapter 融合（fuse）进基础模型，生成一个独立的微调模型用于部署：
mlx_lm.fuse \
--model mlx-community/Mistral-7B-Instruct-v0.3-4bit \
--adapter-file ./adapters.npz \
--save-path ./my-finetuned-model \
--de-quantize
--de-quantize 参数会把量化的权重恢复到全精度再融合，保证最终模型的质量。
一些微调的实操经验：
- 如果 OOM 了，先降
--batch-size到 1，再降--lora-layers到 4 --lora-layers 8适合快速实验，16-32适合正式训练- 当你传入一个量化模型作为
--model，MLX-LM 会自动切换到 QLoRA 模式——基础模型保持量化，只有 LoRA adapter 用全精度 - M2 Ultra 上 Llama 7B 的 LoRA 训练速度大约 475 tokens/s
- 长样本更吃内存。如果你的训练数据有很长的文本，考虑把它们拆成更短的片段
本地服务器：OpenAI 兼容的 API
MLX-LM 也可以跑一个本地的 API 服务器：
mlx_lm.server --model mlx-community/Qwen3.5-27B-4bit
这会在本地启动一个 OpenAI 兼容的接口。不过说实话，这个服务器的功能比 Ollama 差不少——没有自动模型管理、没有多模型切换、没有 Docker 支持。如果你需要一个稳定的 API 服务，Ollama 目前还是更好的选择。MLX-LM 的服务器更适合开发调试和短期实验。
MLX-LM vs Ollama：不是替代，而是互补
这个对比我已经被问过很多次了，我尽量给一个公允的判断。
Ollama 赢在哪里
便利性遥遥领先。 一行命令安装、一行命令拉模型、一行命令跑推理、一行命令启动 API 服务器。模型的下载、缓存、版本管理、加载/卸载全自动。你不需要关心模型格式、量化方式、内存分配这些细节。
生态无可匹敌。 Open WebUI、LangChain、Claude Code、OpenClaw、VS Code Copilot、Continue.dev、Aider——几乎所有 AI 开发工具都原生支持 Ollama。MLX-LM 的生态要小得多。
跨平台。 Ollama 支持 macOS、Linux、Windows。MLX-LM 只支持 Apple Silicon（macOS，以及理论上的 iOS/iPadOS/visionOS）。如果你的工作环境不全是 Mac，Ollama 是唯一的选择。
模型格式通用。 Ollama 用 GGUF 格式，这是目前开源社区最通用的量化格式，几乎所有开源模型都有 GGUF 版本。MLX-LM 用自己的格式（SafeTensors/NPZ），虽然 mlx-community 提供了大量预转换的模型，但覆盖面不如 GGUF。
MLX-LM 赢在哪里
Apple Silicon 上的推理速度。 这是硬优势。一篇学术对比论文在 M2 Ultra 上的测试：MLX 稳态吞吐约 230 tok/s，MLC-LLM 约 190 tok/s，Ollama 约 20-40 tok/s。就算在日常的 M4 Max 上，MLX 跑 Qwen 3.5 35B-A3B 也能到 65-70 tok/s，Ollama 大概 35 tok/s。差距是一倍到几倍。
本地微调。 这是 Ollama 完全不具备的能力。在你自己的 Mac 上用自己的数据做 LoRA/QLoRA 微调，不需要云端 GPU、不需要花钱、数据不离开本地——这对隐私敏感的场景价值巨大。
跟 Apple 生态的深度集成。 MLX 有完整的 Swift API，你可以直接在 iOS/macOS 应用中嵌入 LLM 推理，不需要依赖外部进程。WWDC 2025 专门有两个 session 讲 MLX。Apple 把 MLX 定位为自家 AI 生态的核心框架，未来的 macOS/iOS 系统级 AI 功能（Apple Intelligence）很可能就是建立在 MLX 之上。
跟 M5 Neural Accelerators 的配合。 前面说了，目前只有 MLX 能充分利用 M5 的 Neural Accelerators。在 M5 硬件上，MLX 的 TTFT 比 M4 快 3-4 倍，而 Ollama/llama.cpp 只能吃到内存带宽提升带来的 12-20% 改善。
我的选择建议
如果你只需要跑模型做推理和对话，Ollama 是更好的默认选择——安装简单、生态丰富、足够好用。特别是如果你需要跟各种 AI 开发工具集成。
如果你需要在 Mac 上微调模型，MLX-LM 是唯一的选择。
如果你在 Mac 上追求极致推理性能（比如处理长文档、跑批量推理任务、需要快速的首 token 响应），MLX-LM 值得额外的学习成本。
如果你在开发 Apple 平台的原生应用，MLX 的 Swift API 是正确的路径。
折中方案： LM Studio 现在支持 MLX 后端。这意味着你可以用 LM Studio 的 GUI 和 API 功能，同时享受 MLX 的推理性能。Apple 在 M5 发布时直接点名了 LM Studio，它正在成为"有 MLX 性能的 Ollama"。
苹果的战略信号：MLX 不是实验项目
WWDC 2025 上关于 MLX 的信息量很大，值得仔细解读。
首先，苹果给了 MLX 两个专门的 session："Get started with MLX for Apple silicon" 和 "Explore large language models on Apple silicon with MLX"。这在 WWDC 的语境下意味着苹果把 MLX 当作一个正式的、面向开发者推广的框架，而不是一个内部研究项目。
其次，WWDC 2025 展示的 session 里明确演示了用 MLX 在 M3 Ultra（512GB 统一内存）上跑数百亿参数的模型，实现了"比阅读速度更快"的实时交互。这说明苹果把 Mac 定位为"本地 AI 工作站"，而 MLX 是这个定位的技术基础。
第三，苹果在 2025 年的 Foundation Models 框架——也就是 Apple Intelligence 背后的系统级 AI 能力——跟 MLX 有深度的技术关联。虽然 Apple Intelligence 使用的可能是定制的模型和运行时，但 MLX 的技术路线（统一内存优化、Metal 加速、量化支持）显然是同一条路。
第四，MLX 不仅支持 Mac，还支持 iPhone、iPad 和 Vision Pro。MLX Swift 让你可以在任何 Apple 平台上运行 ML 模型。这意味着 MLX 的长期潜力不只是"Mac 上跑大模型"，而是"所有 Apple 设备上跑 AI"。
再看硬件侧：M5 的 Neural Accelerators 是专门为矩阵乘法设计的硬件单元，而矩阵乘法正是 Transformer 模型推理的核心操作。苹果正在从硬件层面为 MLX 的性能铺路。这不是一个"兼容一下 AI 工作负载"的设计，而是一个"专门针对 AI 工作负载优化芯片架构"的战略选择。
把这些信号综合起来，我的判断是：MLX 正在成为 Apple 生态的 AI 基础设施标准，地位类似于 Metal 之于图形渲染。 它不会替代 Ollama 或 llama.cpp 在跨平台世界中的角色，但在 Apple 生态内部，MLX 会越来越成为默认且最优的选择。
能力边界：MLX-LM 做不到什么
公允起见也要说说局限。
只支持 Apple Silicon。 这是最大的限制。如果你的团队不全是 Mac 用户，MLX-LM 不能作为统一的本地推理方案。Ollama 和 llama.cpp 的跨平台能力在这种场景下不可替代。（2026 年 MLX 开始通过 CUDA 后端实验性地支持 NVIDIA GPU，但远不如原生 Apple Silicon 上的体验。）
不是生产级推理服务器。 MLX-LM 的 server 功能比较原始——没有请求队列、没有并发管理、没有健康检查。如果你需要给多个客户端提供稳定的推理服务，Ollama 或 vLLM 是更好的选择。
生态相对小众。 虽然 mlx-community 在 Hugging Face 上很活跃，模型覆盖面也不错，但跟 GGUF 生态的体量比还是差一截。部分小众模型可能没有现成的 MLX 格式，需要自己用 mlx_lm.convert 转换。
长上下文的内存管理。 MLX 的 KV cache 使用可配置的旋转缓存（默认 4k token），对短到中等上下文（4k-32k）的处理很高效。但对于超长上下文（64k-128k），MLC-LLM 的分页 KV cache 扩展性更好。如果你经常需要处理超长文档，这是一个需要考虑的因素。
学习曲线比 Ollama 陡。 Ollama 几乎零学习成本，装了就能用。MLX-LM 需要你理解 Python 虚拟环境、Hugging Face 模型仓库、量化格式、LoRA 参数这些概念。对于非 ML 背景的开发者来说，入门门槛要高一些。
我的日常工作流
最后分享一下我自己怎么用这些工具，不一定适合所有人，但可以作为参考。
日常编码助手：Ollama + Continue.dev 集成在 VS Code 里。模型用 Qwen3.5 27B。这个组合的便利性无可替代——Ollama 作为后台服务常驻，Continue 自动连接。
需要极速推理的任务（长文档分析、批量文本处理）：切到 MLX-LM 直接跑 Python 脚本。比如我有一个脚本用 MLX-LM 批量处理 API 文档生成摘要，因为要处理几百个文件，Ollama 的速度差距在这种批量场景下会被放大到不可接受。
模型实验和微调：纯 MLX-LM。有时候需要用少量领域数据快速训练一个专用模型（比如公司内部的代码规范检查器），MLX-LM 的 LoRA 在 M4 Max 32GB 上就能跑 7B 的 QLoRA 微调，完全不需要云端 GPU。
给非技术人员展示：LM Studio with MLX backend。它有 GUI、支持 MLX 加速、还有 OpenAI 兼容的 API。给产品经理或设计师展示本地 AI 能力时，LM Studio 比让他们开终端好用太多了。
这四个场景用了三个工具，看起来有点碎片化，但每个工具确实在自己的位置上是最优解。如果非要只选一个——Ollama 的综合性最好。如果能选两个——加上 MLX-LM 覆盖微调和极致性能场景。
怎么开始
如果你有一台 Apple Silicon 的 Mac（M1 及以上），想试试 MLX-LM：
# 创建虚拟环境（推荐）
python3 -m venv mlx-env
source mlx-env/bin/activate
# 安装
pip install mlx-lm
# 跑一个模型试试
mlx_lm.chat --model mlx-community/Qwen3.5-9B-4bit
9B 的 4-bit 模型只需要约 5-6 GB 内存，8GB 的 MacBook Air 就能跑。如果你的 Mac 有 16GB 以上内存，可以直接上 27B-32B 级别的模型。
想试微调的话，MLX 的 GitHub examples 仓库里有完整的 LoRA 教程和 WikiSQL 示例数据集，照着跑一遍大概半小时就能理解整个流程。
苹果的 WWDC 2025 session 录像也推荐看看——"Get started with MLX for Apple silicon" 讲框架基础，"Explore large language models on Apple silicon with MLX" 讲 LLM 推理和微调。Awni Hannun 和 Angelos Katharopoulos 亲自讲解，内容质量很高。
MLX 正在变成 Mac 上做 AI 开发的标配基础设施。现在学的投入，会随着 Apple 生态中 AI 功能的爆发而持续产生回报。
本文基于 MLX 0.31.1 和 MLX-LM 的最新版本（2026 年 3 月）。性能数据引用了 Apple Machine Learning Research 的 M5 基准测试、学术界的多框架对比论文、以及社区的独立评测。如果你有 MLX 的使用经验或性能数据，欢迎在评论区补充。
