使用 MLX 在 Mac 上本地运行 AI 智能体
Run local agentic AI on the Mac using MLX
2026年6月10日
一句话判断
这场 Session 最值得关注的一件事是:Apple 把 Mac 变成了完全离线、零 API 费用的 Agentic AI (智能体) 运行时,M5 芯片的 Neural Accelerator (神经网络加速器) 让本地处理几十万 Token 的 Prompt 速度直接翻了 4 倍。
这场 Session 讲了什么
过去一年大家都在玩 AI Agent (智能体),但痛点很明显:跑个完整的代码重构循环,API 费用能让人破产,而且把公司核心代码传到云端总让人心里发毛。以前在本地跑 Agent,模型一遇到长上下文就卡成 PPT,根本没法用于实际生产。
现在 Apple 给出了官方解法:一套四层本地 AI 栈。底层是 MLX 数组框架,往上是 MLX-LM 负责模型加载和量化,再往上是 MLX-LM Server 提供完全兼容 OpenAI 协议的 HTTP 接口,最上面直接对接 OpenCode 或 Xcode 等 Agent 工具。你只需要 pip install 一下,本地就起了一个不用联网的 API 端点。
这对注重数据隐私的开发者、企业内部工具团队,以及想做本地 IDE 插件的创业者影响最大。你不用再担心 API 限流和账单,只要你的 Mac 内存够大,整个 Agentic loop (智能体循环) 都在你的硬盘和统一内存里闭环。
值得深挖的点
M5 Neural Accelerator 吃透了 Agent 的长上下文红利
传统 LLM 聊天是“一问一答”,但 Agentic AI 是“循环执行”。Agent 每次调用工具(比如读代码、跑测试)后,都要把新的执行结果塞进上下文,重新处理整个 Prompt。一个复杂的编码任务跑下来,上下文轻松堆积到几十万 Token。以前本地跑这种任务,Prompt 处理(Prefill 阶段)慢得让人想砸键盘。
Apple 这次明确了 M5 芯片引入的 Neural Accelerator (神经网络加速器) 就是为了解决这个瓶颈。它专门针对矩阵乘法做了硬件级优化,比 M4 快 4 倍。MLX 框架在底层自动调度这些专用内核,开发者不用改一行代码。这意味着 Agent 读取大型代码库或处理冗长工具返回结果的时间被大幅压缩。Apple 这里的硬件刀法很精准:既然云端 API 的延迟受限于网络,那就在本地用专用硅片把 Prompt 处理速度拉到极致,让“本地运行”从“能跑”变成“好用”。
Thunderbolt RDMA 让 Mac 集群变成平民版算力节点
跑 7B 或 14B 的量化模型,单台 Mac 绰绰有余。但如果想跑 DeepSeek 这种千亿参数级别的怪物,单台 Mac 的 192GB 或 512GB 统一内存就不够看了。Session 里提到了一个极其硬核的功能:通过 Thunderbolt (雷雳) 或 ethernet 连接多台 Mac,使用 MLX 的分布式推理把模型切片跑在多台机器上。
这里的关键是 macOS 26.2 引入的 Thunderbolt RDMA (远程直接内存访问) 支持。以前多机通信要走完整的网络协议栈,延迟高且吃 CPU;现在 RDMA 允许 Mac 之间直接读写对方的内存,带宽高且延迟极低。这让 4 台 Mac 组成的集群在分布式推理时速度提升了 3 倍。对于眼馋 H100 集群但预算有限的中小团队,把公司闲置的几台 Mac mini 用雷雳线串起来,就能拥有一个能跑超大模型的本地私有算力池。
代码片段
1. 三步拉起本地 OpenAI 兼容服务器
场景:在本地启动一个支持工具调用的 LLM 服务端,替代云端 API。
# 1. 安装 MLX 语言模型库
pip install mlx-lm
# 2. 启动本地服务器,加载一个支持工具调用的量化模型
# 这里使用 Qwen 的 4B 8bit 版本,适合快速测试
mlx_lm.server --model mlx-community/Qwen-3.5-4B-8bit
# 3. 测试本地端点,和调用 OpenAI API 完全一样
curl -X POST http://127.0.0.1:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"default_model","messages":[{"role":"user","content":"帮我写个 Swift 单例"}]}'
坑:首次运行 mlx_lm.server 会从 HuggingFace 下载模型,如果网络不好会卡住,建议提前配置好 HuggingFace 镜像或手动下载模型到本地缓存。
2. 将 OpenCode 智能体指向本地 MLX 服务
场景:配置流行的终端编码智能体 OpenCode,让它使用本地算力而不是云端 API。
{
"$schema": "https://opencode.ai/config.json",
"model": "mlx/default_model",
"provider": {
"mlx": {
"npm": "@ai-sdk/openai-compatible",
"name": "MLX (local)",
"options": {
// 指向本地启动的 MLX-LM Server
"baseURL": "http://127.0.0.1:8080/v1"
},
"models": {
"default_model": { "name": "Default MLX Model" }
}
}
}
}
坑:Agent 框架通常对模型的 Tool Calling (工具调用) 格式有严格要求,确保你在 mlx_lm.server 启动时选择的模型原生支持 OpenAI 格式的函数调用,否则 Agent 会陷入死循环。
3. 跨多台 Mac 启动分布式推理
场景:单台 Mac 内存不够时,通过雷雳线连接多台 Mac 跑千亿参数大模型。
# 使用 mlx.launch 启动分布式任务
# --hostfile 指定集群节点信息,--backend 指定通信后端
mlx.launch --hostfile hosts.json \
--backend jaccl \
/remote/path/to/mlx_lm.server \
--model mlx-community/Qwen-3.5-122B-A3B-8bit
坑:分布式推理对节点间的网络稳定性要求极高。务必使用 Thunderbolt 直连或万兆以太网,如果用普通的千兆 Wi-Fi 或路由器连接,通信延迟会直接把推理速度拖垮。
最佳实践
- 已有项目的迁移策略:如果你的 macOS 应用目前依赖云端 LLM API 做文本处理或代码补全,现在可以无缝切换到本地。只需在代码里把
baseURL替换为http://127.0.0.1:8080/v1,并在应用首次启动时引导用户通过pip或内嵌 Python 环境拉起mlx_lm.server。这能帮你省下巨额的 API 账单,同时彻底解决隐私合规问题。 - 新项目的采用建议:做本地 IDE 插件或开发者工具时,直接基于 MLX-LM Server 构建。不要自己去写 Metal 渲染或 Core ML 转换,MLX 生态已经处理了量化、KV Cache 管理和 Continuous batching (连续批处理)。把精力放在设计更好的 Agent Prompt 和工具链上。
- 实战中容易踩的坑:Agent 循环会产生极长的上下文。如果你发现本地 Agent 越跑越慢,甚至 OOM (内存溢出),不要盲目换大模型。去检查你的 Agent 框架有没有做上下文截断或摘要,并在启动
mlx_lm.server时合理设置--max-tokens和上下文窗口限制。
还有什么值得关注
- Xcode 原生支持本地模型:Xcode 的 Intelligence 设置里新增了 “Locally Hosted” 选项,可以直接连接本地的 MLX 服务器,这意味着 Xcode 的代码补全和 Bug 修复可以完全断网运行。
- Continuous batching (连续批处理) 落地:MLX-LM Server 现在支持动态合并并发请求,当你同时跑多个 Sub-agent (子智能体) 并行查代码时,GPU 不会排队等待,吞吐量大幅提升。
- 生态大一统:Ollama、LM Studio 和 vLLM 底层都在用 MLX,Apple 实际上已经通过开源框架统一了 Mac 上的本地 AI 运行时标准。