大部分人拿 Mac 跑本地模型，裝的第一個東西是 Ollama。

這很合理。Ollama 名氣大、社群活躍、一行指令就能跑。但它有一個你可能沒注意到的問題：它不是為 Apple Silicon 設計的。Ollama 底層跑的是 llama.cpp，那是一個 C++ 推理引擎，主要針對 CPU 和 CUDA GPU 優化。在 Mac 上用，等於你開了一台跑車，但引擎裝的是腳踏車的變速器。

Rapid-MLX 走的是完全不同的路線。它直接站在 Apple 自家的 MLX 框架上，所有計算走 Metal GPU kernels，而且完全利用 Apple Silicon 的統一記憶體架構——CPU 和 GPU 看到的是同一塊記憶體，不需要來回搬資料。結果就是：同一台 Mac、同一個模型，推理速度快 2 到 4 倍。

這幾層的關係其實很簡單，但混在一起看會暈。

想像一間餐廳。MLX 是廚房裡的爐具——Apple 做的底層機器學習框架，專門替 Apple Silicon 的 Metal GPU 和統一記憶體優化過。mlx-lm 是廚師，負責把模型載進來、跑 tokenizer、生成文字。Rapid-MLX 是整間餐廳——它在廚師外面包了一層 HTTP 伺服器，加上點餐系統（OpenAI 相容 API）、排隊管理（continuous batching）、常客優惠（prompt cache）。

你裝好 Rapid-MLX，啟動它，任何吃 OpenAI API 的工具——Cursor、Claude Code、Aider、LangChain——都能直接接上來用。不改程式碼，不花 API 費，資料不出你的裝置。

裝好到可以用，三分鐘

1
2
3
4
5
# Homebrew（推薦，自動搞定 Python 版本）
brew install raullenchai/rapid-mlx/rapid-mlx

# 啟動伺服器（首次會自動下載模型）
rapid-mlx serve qwen3.5-9b --port 8000

qwen3.5-9b 是內建的 model alias，Rapid-MLX 有 46 個以上的短名稱。下完模型之後，開另一個 terminal：

1
2
3
4
5
6
7
8
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": "用一句話解釋 MLX"}],
)
print(response.choices[0].message.content)

就這樣。如果你用 Cursor，把 API base URL 改成 http://localhost:8000/v1。用 Aider，加個 --openai-api-base 參數。不管哪個工具，它看到的就是一個標準的 OpenAI API endpoint，不知道也不在乎背後跑的是本地模型。

Tool Calling：跟 Ollama 拉開最大差距的地方

你可能想過拿本地模型跑 AI Agent——讓它呼叫函式、查資料庫、操作檔案。在 Ollama 上做這件事，你會踩一整排的坑。大部分 Ollama 的 tool calling 實作要你自己處理 JSON 解析、格式修正、跟模型特定的 chat template 對齊。

Rapid-MLX 內建 18 種 tool parser。Hermes 格式、DeepSeek 格式、Llama 格式、Qwen 格式、Gemma 4 格式——全部自動偵測。更實用的是：量化模型有時候會輸出壞掉的 tool call（JSON 語法錯誤、key 名稱跑掉），Rapid-MLX 有自動修復機制，會嘗試把壞掉的呼叫重新整理成結構化格式。

這不是錦上添花。這是「能不能真的在本地跑 Agent」的分水嶺。

Prompt Cache：讓多輪對話不再越聊越慢

多輪對話有一個結構性問題：每次你送新訊息，前面所有歷史訊息都要重新算一遍。對話越長，等待越久。

Rapid-MLX 用兩種策略解決。標準 transformer 模型用 KV Cache Trimming——跨 request 保留 KV cache，已經算過的 token 不重新算。Qwen3.5 這種混合 RNN 模型用 DeltaNet State Snapshots——在 system prompt 邊界做 state 快照，恢復只要 0.1 毫秒。

效果是 TTFT（Time To First Token）提升 2 到 30 倍。你打完問題到看到第一個字的等待時間，從「耐心等」變成「幾乎即時」。

Cloud Routing：聰明的成本控制

不是所有 prompt 都適合在本地跑。一個 500 token 的快問快答，本地處理又快又免費。一個塞了 50K token context 的程式碼分析，本地跑會非常慢。

Cloud Routing 讓你設定一個閾值：短 prompt 走本地（零成本、低延遲），超過閾值的自動路由到 GPT-5 或 Claude。底層用 litellm 實作，切換對上層工具完全透明。

這個設計背後有一個很清楚的判斷：本地推理跟雲端 API 不是二選一的關係，它們是互補的。個人開發者一天可能送 200 次 prompt，其中 80% 是短的——如果這 80% 全走本地，API 帳單直接砍掉一大截。

什麼時候不該用

Rapid-MLX 是 Apple Silicon 的原生選手。如果你的推理環境是 Linux server 或 Windows 機器，它幫不了你——去看 Ollama、llama.cpp、vLLM。

它也不做圖片生成。沒有 Stable Diffusion、沒有 DALL-E。它支援圖片「理解」（VLM），但不支援圖片「產生」。

推理速度受限於記憶體頻寬。M1 是 68 GB/s，M3 Ultra 是 800 GB/s。你的硬體天花板決定了 tok/s 上限，軟體再怎麼優化也突破不了物理限制。

首次啟動要下載模型（幾 GB 到上百 GB）加上 Metal shader 編譯，會比較慢。後續啟動有 warmup 加速。

適合的使用情境

隱私敏感場景——公司內部程式碼、客戶資料、任何不能丟上雲端的東西。所有推理在本地完成，資料不離開你的 Mac。

AI Coding Agent 後端——搭配 Cursor、Claude Code、Aider。tool calling 加 reasoning 分離是做 Agent 的核心需求，Rapid-MLX 原生支援。

混合推理——Cloud Routing 讓短 prompt 走本地、長 context 走雲端。一天省下來的 API 費用，一個月就很有感。

離線開發——飛機上、咖啡廳沒網路、或是單純不想依賴外部服務。模型下載一次，後面完全離線。

回到最開頭的問題。你的 Mac 能不能跑本地 LLM？可以。但「能跑」跟「好用」之間，差距大得驚人。

這中間的差距不是模型品質，是工程基礎設施。一個好的推理伺服器需要做到三件事：效能（走對的硬體加速路線）、相容性（讓所有工具都能直接接）、以及生產級功能（tool calling、prompt cache、concurrent batching）。Rapid-MLX 三件事都做了，而且做得很明確——它不試圖跨平台，它只做 Apple Silicon，做到最好。

如果你有一台 M 系列晶片的 Mac，而且你在做任何跟 LLM 有關的開發工作，值得花三分鐘試一下。

參考來源：Rapid-MLX — GitHub