MLX

MLX 是一款用于机器学习的开源数组框架，由 Apple ML Research 于 2023 年 12 月在 MIT 许可证下发布。它专为 Apple Silicon 芯片（M1、M2、M3、M4 和 M5）量身定制，并围绕一个核心架构优势构建：Apple 的统一内存（CPU 和 GPU 共享同一个物理 RAM 池）。这种设计消除了在不同处理器类型之间移动张量时导致 PyTorch 等框架速度变慢的数据复制瓶颈。因此，MLX 可以在 MacBook 上比大多数替代方案更快地运行大型语言模型，且无需任何付费云订阅或外部 API。

该框架提供了 Python、C++、C 和 Swift API。Python 接口借鉴了 NumPy 的约定；更高级别的神经网络和优化器层则遵循 PyTorch 的习惯用法，因此熟悉这两者的研究人员都能快速上手。MLX-LM 是用于 LLM 推理和微调的配套包，可处理从 Hugging Face 下载模型、量化（4-bit、8-bit、bf16）、提示词缓存、用于提高内存效率的旋转键值缓存、LoRA 和 QLoRA 微调，以及跨多台 Mac 的分布式推理。只需一条 pip 命令即可完成安装。Hugging Face 上的 MLX Community 托管了数千个开箱即用的预量化模型。截至 2026 年 4 月，MLX 的版本为 0.31.2，共发布了 73 个版本，并由 Apple 工程师积极维护。

MLX 在 2026 年 5 月的实际表现

MLX 是 Mac 上本地 ML 工作负载的推理和训练引擎。在推理方面，MLX-LM 允许您拉取任何 Hugging Face 模型，进行实时量化，并直接从终端运行聊天界面。无需配置服务器，无需 Docker 容器，也无需 GPU 驱动程序栈。在配备 96GB 统一内存的 M3 Max 上，您可以加载 4-bit 的 Llama 70B，并以每秒 10-15 个 token 的速度生成内容。在运行 35B 混合专家（MoE）模型的 M4 Max 上，实际基准测试显示速度约为每秒 130 个 token。M5 芯片将密集型 14B 架构的首个 token 生成时间（TTFT）缩短至 10 秒以内，将 30B MoE 模型缩短至 3 秒以内，这得益于 Apple 全新的 GPU 神经网络加速器提供了专用的矩阵乘法电路，而 MLX 可通过 Metal 4 直接调用这些电路。

在训练方面，MLX 支持通过单条命令进行 LoRA 和 QLoRA 微调。您只需指定模型、JSONL 格式的数据集以及训练时长。在 M2 Max 上使用 5,000 个示例训练 Mistral-7B 大约需要 45-90 分钟，全精度下的峰值内存约为 7GB。在 4-bit 量化模型上进行训练可将内存占用减少约 3.5 倍，且精度损失极小。随后可以将适配器上传到 Hugging Face 并进行分享。对于拥有多台 Apple Silicon 机器的团队，可以通过 mx.distributed 进行分布式训练。

延迟计算意味着数组仅在需要结果时才进行求值。动态计算图会在输入形状发生变化时重建，从而避免了在研究迭代期间缓慢的重新编译过程。Swift API 已经足够稳定，iOS 和 macOS 应用程序开发者可以直接将模型嵌入到应用程序中，而无需依赖云端。在 WWDC 2025 上，Apple 为 MLX 安排了三场专题会议，将其定位为 Apple Silicon 上 LLM 推理的首选框架。2026 年 3 月，Ollama 宣布改用 MLX 作为其推理引擎，在其测试版中实现了 2 倍的响应生成速度提升，这进一步验证了该框架已具备生产级基础设施的实力。

MLX 与 llama.cpp 及 PyTorch MPS 的对比定位

MLX vs. llama.cpp：llama.cpp 使用 GGUF 格式，并在 CPU、Metal、Vulkan、CUDA 等后端上运行。它是真正的跨平台工具：支持 Windows、Linux、macOS 和 Android。而 MLX 仅在 macOS 上运行。对于 14B 参数以下模型的原始吞吐量，MLX 优势明显：在 M2 Ultra 上运行 Qwen-2.5 7B 时，MLX 的速度约为 230 tok/s，而 llama.cpp 为 150 tok/s，领先 53%。在 M4 Max 上运行 0.6B 模型时，MLX 的速度为 525 tok/s，而 llama.cpp 为 281 tok/s。在 27B+ 参数级别，内存带宽成为瓶颈，两个框架的表现趋于一致，性能基本相当。

两者在架构上具有意义的差异在于内存处理。MLX 通过延迟计算使用真正的零拷贝统一内存。llama.cpp 则通过 -ngl 标志使用 CPU+GPU 层拆分，这意味着您可以通过将层溢出到 CPU RAM 来加载大于 GPU 内存的模型。MLX 没有同等的功能：如果模型无法装入统一内存，它将无法运行。llama.cpp 还支持 10 多种量化格式（Q2_K、Q4_0、Q8_0、IQ 变体），而 MLX 仅支持 4 种。此外，llama.cpp 仅用于推理；而 MLX 原生包含设备端 LoRA 微调功能。对于 Windows 或 Linux 用户，或者需要加载接近或超过其内存上限的模型的人来说，llama.cpp 是务实的选择。对于追求吞吐量且模型能轻松装入内存的 Mac 优先推理场景，MLX 则是赢家。

MLX vs. PyTorch MPS 后端：PyTorch 的 Metal Performance Shaders 后端允许 Mac 用户在 Apple GPU 上运行现有的 PyTorch 代码。在语言模型 token 生成方面，差距非常大：在 M2 Ultra 上进行 LLM 推理时，MLX 的速度约为 230 tok/s；而 PyTorch MPS 仅为 7-9 tok/s。这并非笔误。差异源于统一内存架构：PyTorch 仍然以传统方式在 CPU 和 GPU 之间复制张量，从而产生了 MLX 完全避免的开销。在 M3 Pro 上的一项基准测试发现，对于原始矩阵乘法（128x128，10K 次迭代），PyTorch MPS 比 MLX 快 5.5 倍，这表明 MLX 的优势是专门针对端到端 LLM 工作负载进行优化的，而不是针对每一个基础操作。如果您有一个庞大的现有 PyTorch 训练管道，并希望在不重写代码的情况下在 Mac 上运行它，PyTorch MPS 是兼容之选。如果您从零开始并希望获得最佳的 Mac LLM 性能，MLX 则是正确的基石。

“这令人印象极其深刻，这里所展现的技术提升彻底改变了我对下一个应用程序的构思。” - Nathan Tarbert，开发者，dev.to WWDC 2025 会议讨论帖，2025 年 6 月

“当我第一次运行这段代码，看到屏幕上出现完全在我的笔记本电脑上生成、没有任何 API 调用的文本时，感觉就像是一场小型革命。我的 MacBook 突然变成了一个自给自足的 AI 动力源。” - 开发者评价，willitrunai.com，2025 年

日常开发的真实体验

上手速度确实非常快。使用 pip 将 MLX-LM 安装到虚拟环境中，然后运行一条命令即可启动指向任何 Hugging Face 模型标识符的聊天会话。模型会自动下载并量化。只需更改一个标志，您就可以从 Mistral-7B 切换到 Llama-3-70B。提示词缓存意味着重复的长上下文会话无需在每一轮重新处理完整的上下文，这对于维护长系统提示词的编码智能体来说至关重要。

微调也遵循类似的模式。将数据准备为 JSONL 格式，运行 mlx_lm.lora 并附带模型、数据路径和迭代次数。无需安装 CUDA 驱动程序，无需配置环境变量，也无需查阅兼容性矩阵。一位开发者描述了微调 Mistral-7B 以生成特定格式的 API 文档的过程，在 MacBook Pro 上整个运行过程耗时 45 分钟，峰值内存约为 6.8GB。在 4-bit 量化基础模型上进行训练可将内存占用减少约 3.5 倍，这使得在 24GB 系统上微调 13B 模型成为可能。

与其他工具的集成也在不断改进。LM Studio 现在支持将 MLX 作为后端，为用户提供基于 MLX 推理的图形界面。Ollama 于 2026 年 3 月宣布，它已在 Apple Silicon 上改用 MLX 作为其推理引擎，在不改变任何工作流的情况下为 Ollama 用户提供 2 倍的生成速度。Hugging Face 的 MLX Community 托管了数千个 safetensors 格式的预量化模型，涵盖了大多数通常只会首先以 GGUF 格式出现的架构。希望在 GUI 中运行模型并结合网络搜索或文档工作流的用户，通常会将 MLX 推理与 Ollama 的 REST API 层结合使用，以牺牲适度的吞吐量开销来换取标准化端点带来的便利。

2023 年 12 月的公开发布对 Apple 来说意义重大。该公司于 2023 年 12 月 5 日在 GitHub 上发布了 MLX，没有举行新闻发布会，而同一周 Google 发布了 Gemini。科技媒体的报道几乎全部集中在 Gemini 上。但几天之内，ML 社区就发现了 MLX，初步基准测试显示，在 Apple 硬件上处理某些工作负载时，其性能比 PyTorch 快 30%。MIT 许可证被解读为一个强烈的信号：Apple 并不打算像 CUDA 将 GPU 世界与 NVIDIA 绑定那样来控制生态系统。这种定位加速了那些原本对 Apple 在 AI 领域的认真程度持怀疑态度的研究人员的采用。

MLX 的目标用户群体

对于希望在没有云成本或不将数据发送到设备外的情况下运行或微调大型语言模型的 Mac 端 ML 研究人员和开发者来说，MLX 是正确的选择。对 PyTorch MPS 推理速度感到沮丧的数据科学家会发现 MLX 是一个实质性的升级。无法将数据发送到外部 API 的注重隐私的专业人士有充分的理由采用它：所有的推理和训练都保留在本地机器上。构建带有嵌入式模型的 iOS 或 macOS 应用程序的 Swift 开发者可以使用 MLX 的 Swift API，而无需 Python 解释器层。鉴于 Apple 有意针对 MLX 工作负载进行 M5 硬件优化，长期在 Apple 生态系统上进行构建的团队应将 MLX 视为一项战略依赖。

希望跨平台探索广泛的开放权重模型的用户也应该直接查看 llama.cpp 和 Llama，因为 llama.cpp 的 GGUF 生态系统为新发布的架构提供了更广泛的模型可用性。这两种工具根据任务的不同可以互为补充。

MLX 的局限性

MLX 不是一个跨平台框架。如果您的团队包括 Windows 或 Linux 开发者，或者如果您在 Linux 服务器上部署模型，MLX 无法满足您的需求。llama.cpp 可以在所有三个平台上使用相同的模型文件运行。而 MLX 的 safetensors 模型无法移植。

MLX 无法处理超过统一内存的模型。它没有类似 -ngl 风格的层溢出到 CPU 的功能。如果您的 Mac 拥有 24GB 统一内存，而您想以 8-bit 精度加载 32B 模型，MLX 将拒绝执行。llama.cpp 则可以将该模型拆分到 CPU 和 GPU 上。这对于拥有 M1 或 M2 基础机型（8-16GB）并希望以不错的质量运行大于 7B 模型的用户来说非常重要。

预填充（Prefill）性能是一个真正的弱点。对于简短的聊天交流，MLX 的生成优势可能会被其较慢的提示词处理速度所抵消。在 M1 Max 上处理 650 个 token 的提示词时，据报告有 94% 的时间花在了预填充上，导致有效吞吐量跌至 llama.cpp 之下。M1 和 M2 芯片缺乏原生的 bf16 支持，这使得旧硬件上的问题更加严重。

MLX 不是生产级 LLM 服务平台。它没有内置的请求批处理、速率限制或多用户会话管理功能。基于 MLX 的服务器生态系统（mlx-lm server、Rapid-MLX、vLLM-MLX、oMLX）仍然处于碎片化状态。对于在自己机器上工作的单个开发者来说，这没问题。但对于部署共享内部端点的团队来说，相关工具尚未成熟。

最后，MLX 不是一款适合初学者的工具。Apple 没有直接提供图形界面。主要的入口点是 Python 终端。希望获得精美 GUI 体验的用户应该从 LM Studio 或带有 GUI 前端的 Ollama 开始，无论如何，它们现在在 Apple Silicon 上都在底层使用 MLX，而无需您直接与框架进行交互。