接触 OpenClaw 和 Hermes 有段时间了，总结一下——如果想把 agent 真正用起来，就需要给它越来越多的权限和个人数据。比如自己各种账号的密码，key，个人 email、calendar、联系人、笔记、文档等等。理论上讲，一个 agent 能掌控的数据越多，它能帮你做的事情就越多。
取决于你用的 model，有些情况下 agent 看过的东西跟直接泄露了其实区别不大。隐私还是很重要的！所以最近研究了一下本地运行大模型的方案。
之前 Google Gemma 4 出来的时候用 Ollama 试过，跑的是 4B 的小模型，更多是出于好奇体验一下本地模型到底发展到什么程度了。后来顺着 Ollama 往下研究发现，Ollama 其实更像是一层对 llama.cpp 的包装。真正干活的是下面的 llama.cpp，而 Ollama 做的是模型管理、下载、启动以及 OpenAI API 兼容这些事情。
为什么选择 Rapid-MLX？
研究了一圈之后，我最终选择的是 Rapid-MLX。
原因倒也不复杂。我平时都在用 Mac 生态，而且刚好手里有台 32G 内存的 Mac mini M4，那么直接选择 MLX 生态会更合理一些。
这里顺便说一下 Apple Silicon 为什么特别适合跑本地模型。
很多人第一反应是不是 Apple 的 GPU 很强，但实际上更重要的是 Unified Memory 架构。传统 PC 上，大模型主要受限于显存容量，而 Apple Silicon 上 CPU 和 GPU 共用同一块内存，所以 32GB 内存的机器实际上可以给模型分配二十多 GB 的可用空间。
这也是为什么很多看起来应该需要高端显卡才能运行的模型，在一台 Mac mini 上居然也能跑起来。
Rapid-MLX 的底层是建立在 MLX 之上的。MLX 可以理解成 Apple 专门为 Apple Silicon 设计的机器学习框架，定位有点类似 NVIDIA 生态里的 PyTorch + CUDA，只不过是针对 Apple 自家的硬件。
根据我查到的资料，同样的模型在 MLX 上的推理速度通常会比 Ollama 使用的 GGUF 方案更快一些，Rapid-MLX 号称比 Ollama 快 4.2 倍，如果它像 Shimmy 一样是用 Rust 实现的就更好了！
安装
最开始我是用 Homebrew 安装的，不过后来遇到了一些 Python 环境相关的问题就换成了用之前研究过的 uv 装了，这样也不会污染系统 Python 或 Homebrew 的 Python。
创建虚拟环境：
uv venv
source .venv/bin/activate安装 Rapid-MLX：
uv pip install 'rapid-mlx[vision]'这里不需要先安装 rapid-mlx 再安装 rapid-mlx[vision]，一步到位即可。
安装完成后可以验证一下：
python -c "import mlx_vlm; print('vision OK')"如果能正常输出 vision OK，说明视觉模型相关组件已经安装成功。
列出可用模型：
rapid-mlx modelsRapid-MLX 自带模型索引，可以直接查看支持的模型。
我最开始还以为需要自己到 HuggingFace 找对应的 MLX 版本模型，结果发现常见模型基本都已经收录好了，体验比预想中方便不少。
Qwen
一直听说千问系列是目前本地部署领域口碑最好的模型之一，尤其是在中文场景下，所以就是它了。
启动命令：
rapid-mlx serve qwen3.5-9bRapid-MLX 会自动下载模型，这个 9B 版本的训练数据截止到 2026 年 1 月。实测在我的 Mac mini M4（32GB 内存）上，实际占用不到 10GB 内存，运行起来非常轻松。
后来根据 Rapid-MLX 回吐的模型列表查了一下各种命名的含义最后选了 qwen3.6-35b-ud。
启动命令：
rapid-mlx serve qwen3.6-35b-ud这个模型的完整名称应该是 unsloth/Qwen3.6-35B-A3B-UD-MLX-4bit，它其实并不是传统意义上的 35B Dense Model。
这里包含几个有意思的知识点——首先 A3B 表示这是一个 MoE（Mixture of Experts）模型。35B 是总参数量，但每次推理真正激活的参数量大约只有 3B 左右，因此推理成本会远低于同规模的 Dense 模型。
其次 UD 代表 Unsloth Dynamic Quantization。相比传统量化方式，它会根据不同层的重要程度动态决定量化策略，在尽量减少精度损失的情况下进一步降低内存占用。
实际测试下来，内存占用量在 21GB 到 24GB 之间，对于 32GB 的机器来说刚刚好能撑住。
用 OpenCode 测试了一下写 Python code，速度肯定没法和 Claude 或 GPT 的云端服务相比。第一次对话尤其明显，经常需要等几秒钟才能开始输出，不过后续对话会明显变快。我猜测应该和 KV Cache 有关。因为前面上下文已经完成计算，后续推理可以直接复用缓存结果，所以响应时间会缩短不少。当然我只是根据现象做出的推测。
总体来说 qwen3.6-35b-ud 属于那种“明显不快，但是完全可用”的状态。处理一些日常任务，其实已经能够满足需求，尤其是考虑到隐私这一点。
升级也很简单：
uv pip install -U rapid-mlx由于我们安装了支持视觉模型的 Rapid-MLX，所以也可以用有视觉能力的模型，比如 qwen3-vl-30b。
目前的结论
如果只是想体验一下本地大模型，那么 Ollama 依然是最简单、最成熟的选择。
但如果你的主要设备是 Apple Silicon，并且计划长期使用本地模型，我认为 Rapid-MLX 值得认真看看。
从我的试用体验来看，Qwen 3.6 35B-A3B 已经达到了“可以用于日常工作”的水平。虽然和 Claude、GPT 这些顶级云模型仍然有明显差距，但它最大的价值本来也不是能力，而是可以让数据留在自己的机器上。至少从这次折腾的结果来看，本地大模型已经远不是一个纯粹的玩具了。