vllm-mlx：在 Apple Silicon 上同時提供 OpenAI 與 Anthropic 介面的推論伺服器
High-performance OpenAI and Anthropic compatible LLM inference server for Apple Silicon. Native MLX, continuous batching, multimodal models, MCP tool calling, and Claude Code support.
秒懂
- 它是什麼？
- 它把連續批次、分頁 KV 快取與前綴快取帶進 MLX 生態，並用單一 process 同時服務 /v1/chat/completions 與 /v1/messages。判斷重點在於你是否真的需要併發吞吐，以及能否接受它只跑在 Apple Silicon 上。
- 適合誰用？
- 如果你手上有 M 系列 Mac、需要同時服務多個併發請求，或想讓 Claude Code 直接接上本機模型，vllm-mlx 值得先做一次 bench-serve 實測再決定。若你的部署環境是 NVIDIA 或 Linux 伺服器，這個專案從設計上就不適用，請直接選 vLLM。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 10 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它填補的是 MLX 缺少伺服器層的那個缺口
在 Mac 上跑本地模型，過去兩條路：Ollama，或直接用 mlx-lm。兩者都能跑，但都不太像一個推論伺服器。README 的說法很直接：與 Ollama 或直接使用 mlx-lm 不同，它內建連續批次、分頁 KV 快取、前綴快取與 SSD 分層快取，並在同一個 process 內同時暴露 OpenAI 的 /v1/* 與 Anthropic 的 /v1/messages。
目標讀者因此相當明確。一種是想在本機跑 agent 工作流的人：Claude Code 只認 Anthropic 的 messages 端點，把 ANTHROPIC_BASE_URL 指向本機就能把模型換成自己機器上的權重。另一種是需要多人共用一台 Mac 做推論的團隊，單一請求的 decode 速度不是瓶頸，併發排程才是，這時候連續批次才有意義。
如果你只是偶爾跑一次單輪對話，這些機制幾乎不會被觸發，直接用 mlx-lm 更省事。
連續批次與三層快取如何分攤記憶體壓力
從 README 列出的機制看，它的資料流大致是：請求進來後由排程器組成批次，KV 快取以分頁方式配置，前綴快取則用 trie 結構跨請求共用。這三層是互相配合的。分頁 KV 快取讓不同序列的記憶體不必連續配置，前綴共用才可能實現；trie 前綴快取讓多個請求共用同一段系統提示時不必重算；當前綴快取超出記憶體時，--ssd-cache-dir 把它溢寫到磁碟，對長上下文 agent 這種反覆帶同一段前綴的場景特別有用。
--warm-prompts 則是啟動時先把熱門前綴載入，README 標示可帶來 1.3 到 2.25 倍的 TTFT 改善。這個數字來自專案自己的文件，不是獨立驗證的結果，實際效益取決於你的前綴命中率。
另外兩個機制值得注意。--moe-top-k 針對 MoE 模型做專家縮減，文件標示在 Qwen3-30B-A3B 上有 7 到 16% 的增益，代價是可能犧牲部分品質。--spec-prefill 則是基於注意力的稀疏 prefill，用來降低 TTFT。兩者都屬於用準確度換速度的旋鈕，不建議在沒量測的情況下預設開啟。
啟動指令與真正需要調整的參數
安裝與啟動最短的路徑是兩行：
pip install vllm-mlx vllm-mlx serve mlx-community/Llama-3.2-3B-Instruct-4bit --port 8000 --continuous-batching
OpenAI SDK 端只要把 base_url 指向 http://localhost:8000/v1，api_key 填任意字串即可，模型名稱用 default。要接 Claude Code 則設定兩個環境變數：ANTHROPIC_BASE_URL=http://localhost:8000 與 ANTHROPIC_API_KEY=not-needed，然後直接執行 claude。
其餘常用旗標包括 --reasoning-parser qwen3（讓推理內容出現在 message.reasoning 欄位）、--embedding-model 指定獨立的嵌入模型、--metrics 開啟 /metrics 的 Prometheus 端點，以及 --ssd-cache-dir 與 --warm-prompts。音訊功能需要額外安裝 pip install vllm-mlx[audio]，非英語 TTS 還需要 brew install espeak-ng。
結構化輸出透過 response_format 傳入 JSON Schema，底層使用 lm-format-enforcer。內建 benchmarker 是 vllm-mlx bench-serve，可搭配 --concurrency、--prompts 或 --workload 與 --repetitions，輸出 CSV 或 JSON。要驗證連續批次是否在你的機器上有效，這是最直接的入口。
硬體邊界與幾個不明確的地方
最硬的限制寫在標題上：Apple Silicon only，M1 到 M5，透過 MLX 走 Metal kernel。沒有任何 CUDA 路徑，也沒有 Linux 或 x86 macOS 的支援。如果你的部署目標是雲端 GPU 機器，這個專案從架構上就不適用，討論它的其他優點沒有意義。
第二個限制是模型供給。它吃的是 MLX 格式的權重，實務上等於依賴 mlx-community 這類社群轉換的模型。你要用的模型如果沒有現成的 MLX 版本，得自己轉換，這是採用前最該先確認的一件事。
第三，README 對 Anthropic 相容層的覆蓋範圍寫得比較概括，只列出 streaming、tool use 與 system prompts 三項。Anthropic 的 messages API 還有其他欄位與行為細節，文件沒有逐一說明支援到什麼程度。同樣地，MCP 工具呼叫寫的是 19 種 parser，但沒有列出各 parser 的解析邊界在哪裡，遇到非預期的工具呼叫格式時會怎麼退化，文件沒有交代。這些屬於文件偏薄的地方，需要自己用實際請求驗證。
還有一個設計取捨值得指出。reranker 的 forward path 支援 gelu、gelu_new/gelu_fast、relu 與 silu/swish 這幾種 hidden_act，其他啟動函數會明確失敗。文件把這寫成刻意的行為，理由是避免靜默地用錯啟動函數。這個選擇是對的，但代價是自訂架構的 reranker 需要自己寫 adapter，不能直接拿來用。
與 vLLM 的差異不只是平台
最自然的對照是 vLLM。兩者都提供 OpenAI 相容端點，都做連續批次與分頁 KV 快取，專案名稱也刻意對齊。差別在執行層：vLLM 針對 NVIDIA GPU 與 PagedAttention 的 CUDA 實作設計，vllm-mlx 則把同一組概念重新實作在 MLX 與 Metal 上，並利用 Apple 的統一記憶體，README 強調不需要模型轉換步驟。
這個差異帶來的是部署形態的分歧，而不是效能高低的比較。vLLM 適合多卡伺服器與需要水平擴展的場景；vllm-mlx 適合單機、記憶體就是上限、且機器本身就是開發者工作站的情境。128 GB 的 M4 Max 能塞進 Qwen3-30B-A3B-4bit，README 標示約 18 GB 記憶體與 127.7 tok/s 的單流解碼速度，但這台機器同時也是你的工作環境，推論佔用的記憶體會直接排擠其他工作。
另一條路是繼續用 Ollama。Ollama 的模型管理與使用者體驗成熟得多，但它的排程策略與快取層不是為高併發設計的。如果你的瓶頸是併發吞吐，這是兩者最實際的分野。
版本節奏與授權成本
授權是 Apache-2.0，寬鬆條款，允許商用與修改，沒有 copyleft 傳染性。這部分沒有什麼需要特別評估的，但實際使用前仍應自行確認依賴樹中其他套件的授權，尤其是模型權重本身的授權與程式碼授權是兩件事，MLX 社群轉換的模型各自沿用原始模型的條款。
維護成本的觀察點在版本節奏。從 release 記錄看，v0.4.0rc1 在 2026 年 5 月，v0.4.0 在 6 月，v0.4.1 在 8 月，最後一次 push 是 2026 年 9 月。節奏穩定但不算密集，且這個專案同時要追 MLX 上游的 API 變動與 OpenAI、Anthropic 兩套介面的規格演進，這兩條線都會帶來被動的升級壓力。實際導入時，把 mlx 的版本上限釘住會比完全放開安全。
另一個成本是功能面廣帶來的依賴膨脹。多模態、TTS、STT、embeddings、rerank 各自對應不同的模型與額外套件，audio 需要額外 extras，非英語 TTS 還需要系統層的 espeak-ng。只用到文字推論的話，不需要安裝這些。
編輯結論
如果你手上有 M 系列 Mac、需要同時服務多個併發請求，或想讓 Claude Code 直接接上本機模型，vllm-mlx 值得先做一次 bench-serve 實測再決定。若你的部署環境是 NVIDIA 或 Linux 伺服器，這個專案從設計上就不適用，請直接選 vLLM。導入前先確認三件事：你要跑的模型是否在 MLX 社群已有對應轉換版本、--continuous-batching 在你的併發量下是否真的提升吞吐、以及 audio 與 TTS 需要的 espeak-ng 是否已安裝。
社群筆記