微信扫码
添加专属顾问
我要投稿
在 Apple Silicon 上本地运行大模型,Rapid-MLX 让速度提升2-4倍,工具调用和提示缓存一步到位,彻底告别卡顿等待。核心内容: 1. Rapid-MLX 在 Apple Silicon 上的性能优势与速度表现 2. MLX 框架如何利用统一内存架构实现高效运算 3. Rapid-MLX 的实际应用场景与支持模型
在 Mac Studio 或者 M 系列 MacBook 上,你敲完代码后想立刻让本地大模型帮你补全、改 bug、甚至调用工具链执行任务,结果等半天第一句回复才蹦出来。或者用着用着就卡在工具调用解析失败上,只能切换云端 API 交智商税。
Rapid-MLX 把这些日常摩擦直接干掉。它用 Apple 自家的 MLX 框架搭了个 FastAPI 服务,提供完整的 OpenAI 兼容 API,在 Apple Silicon 上比 Ollama 快 2-4 倍,缓存续轮 TTFT 能压到 0.08 秒左右,还原生把工具调用和提示缓存做好了。Cursor、Claude Code、Aider、LangChain 直接改个 base_url 就能接上。
我自己之前在 M 系列机器上折腾过不少本地推理方案,Ollama 用着方便但一到大模型或者高并发就喘,llama.cpp 虽然快但生态对接总差一口气。Rapid-MLX 这次给我的感觉是,它把“能跑”和“跑得爽”之间的那道坎抹平了。
普通读者可能觉得,本地跑大模型不就是把参数加载到内存里算吗?其实 Mac 的统一内存架构(Unified Memory)是关键——CPU、GPU、Neural Engine 共享一块内存,数据不用在不同芯片间拷贝。MLX 框架把这个特性吃得死死的,运算直接贴着硬件走。
后果很直接:同样一个 30B 左右的模型,在 Mac Mini / Studio 上生成速度能跑到 100+ tok/s(大致相当于每秒输出上百个词),而很多其他方案容易掉到一半甚至更低。实际用起来就是打字机式输出变成流水线,工具调用时等待感大幅下降。
技术上看,Rapid-MLX 在 KV 缓存(Key-Value cache,模型记住上文用的)上做了裁剪和 DeltaNet 状态快照,续轮推理时只需要处理增量部分。这不是小优化,直接把 Time To First Token(TTFT,第一词出来的等待时间)压到毫秒级。工具调用方面它塞了 17 种解析器,Qwen、DeepSeek、Gemma、GLM 等模型输出的格式乱了也能自动修,量化后输出崩坏的情况容错率高不少。
我以前以为 MLX 生态碎片化会是硬伤,现在看 Rapid-MLX 把服务层补得挺完整。当然,碎片化问题确实还存在,但对性能敏感的本地开发场景,它已经把优势发挥得很极致。
看基准数据,在 Mac Studio M3 Ultra 上,Qwen3.5-122B 能跑到 57 tok/s,DeepSeek V4 Flash 158B-A13B 也能有 31-56 tok/s 区间,128GB+ 内存机器上跑 frontier 级 MoE 模型都可行。
小内存机器也不亏。16GB MacBook Air 跑 Qwen3.5-4B 能到 160 tok/s,日常聊天、轻量编码完全够用。32GB+ 机器上 Nemotron-Nano 30B、Qwen3.6-35B 等都能打出高性价比组合。
除了纯文本,还有视觉和音频多模态支持(额外装对应 extras 包)。推理链分离、云端路由、V 缓存压缩这些特性理论上能进一步降低延迟和内存占用,尤其在长上下文或者多轮对话时有用。
我自己测试类似方案时发现,真正卡人的往往不是峰值速度,而是稳定性。工具调用失败一次,整个 Agent 流程就断掉。Rapid-MLX 在这块花了大力气,100% 工具调用通过率不是随便说的。
安装最简单用 Homebrew:
brew install raullenchai/rapid-mlx/rapid-mlx
或者 pip(推荐 Python 3.10+):
pip install rapid-mlx
启动服务(以 Gemma-4-26B 为例):
rapid-mlx serve gemma-4-26b
第一次会下载模型,下载完看到 Ready: http://localhost:8000/v1 就行了。另一个终端用 curl 测试,或者直接在 Cursor/Claude Code 里把 base_url 改成 http://localhost:8000/v1,api_key 随便填。
这步容易出错的地方是 Python 版本太老(macOS 自带 3.9),报 distribution 错误时先 brew install python@3.12 再用对应 python 装包。
跑完服务后,任何 OpenAI 兼容的客户端都能接。Python 里这样用:
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
response = client.chat.completions.create(
model="default",
messages=[{"role": "user", "content": "Say hello"}]
)
LangChain、PydanticAI 等框架也都有测试通过的集成。
Ollama 的模型库和社区确实更成熟,迁移成本和长期维护是真实问题。但如果你主要在 Apple Silicon 机器上开发,对速度和工具调用体验有强需求,Rapid-MLX 现在已经是很有竞争力的选项。
我之前总觉得本地 LLM 推理“够用就行”,用过之后才发现,0.08 秒的 TTFT 和稳定的工具解析能让工作流从“等待 AI”变成“和 AI 一起干活”。这中间的感受差得不是一星半点。
你现在用哪套本地推理方案?遇到过工具调用解析翻车或者速度卡顿的情况吗?💬
如果你觉得这篇内容对你有启发,欢迎在留言区聊聊你的看法。
关注我,我会持续分享高质量的技术与思考干货。👇
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-05-03
奥特曼:Codex 正在经历 ChatGPT 时刻。这是要起飞了
2026-05-01
永别了,终端!OpenAI疯狂升级Codex,接管Mac人类全程0操作围观
2026-04-30
Karpathy 最新访谈:Vibe Coding 只是开始,真正重要的是 Agentic Engineering
2026-04-30
近4万Star!一个终端把自己变成了AI开发环境,Cursor和Claude Code都沉默了
2026-04-29
Claude Code 的 Memory 系统:让 AI 记住你的偏好
2026-04-29
深入浅出Harness Engineerring之核心模式与理念
2026-04-28
别急着All-in DeepSeek V4,先看看这10位从业者的真心话
2026-04-28
你不知道的 Agent:原理、架构与工程实践
2026-04-15
2026-03-31
2026-03-13
2026-02-14
2026-02-03
2026-02-03
2026-03-17
2026-02-09
2026-03-17
2026-04-07
2026-04-26
2026-04-22
2026-04-18
2026-04-13
2026-04-12
2026-04-07
2026-04-01
2026-03-31