vMLX 評測：Apple Silicon 上的多層快取推論伺服器，值得換掉 Ollama 嗎？

它解決的是哪個痛點

在 Apple Silicon 上跑 LLM 推論，最常見的困擾是記憶體頻寬有限，以及重複處理相同 prompt 前綴的浪費。vMLX 的定位就是一個自架的推論伺服器，專門處理這兩個問題。它把 KV cache 拆成兩層：L1 是分頁式快取，放在記憶體裡，用來加速首次生成 token 的時間；L2 是磁碟快取，放在 SSD 上，伺服器重啟後仍然有效。對開發者來說，這意味著你不需要每次啟動都重新計算系統提示詞或長對話歷史。專案描述裡強調「survives restart」，這正是許多本地推論方案做不到的事。目標使用者很明確：在 Mac 上跑服務、需要多個請求並發、而且不想被重複計算拖慢的人。

兩層快取的實際運作機制

L1 分頁快取採用區塊為單位，搭配 content-addressable 的去重。也就是說，相同的 KV 區塊只會存一份，不同的 prompt 若共用前綴，就能直接重用。L2 磁碟快取則是逐區塊持久化，跟分頁快取配對運作。文件描述「Block Disk Cache」是 per-block persistent cache，這表示快取粒度很細，不是整條 prompt 一次寫入。這個設計的好處是，部分重疊的 prompt 也能命中，而不只是完全相同的請求。另外還有 KV cache 量化，可以把快取壓到 q4/q8，省下 2 到 4 倍的記憶體。這對記憶體只有 16 GB 或 32 GB 的機器很重要，因為快取佔用的空間往往比模型權重還大。

安裝與啟動：三種方式

安裝路徑有三條，官方推薦用 uv。命令是 `brew install uv`，然後 `uv tool install vmlx`，最後 `vmlx serve mlx-community/Qwen3-8B-4bit`。pipx 也是同樣的流程，差別在於它隔離在獨立環境。用 pip 的話，macOS 14 以上會碰到 externally-managed-environment 錯誤，所以必須建 venv。啟動後伺服器監聽在 `http://0.0.0.0:8000`，提供 OpenAI 與 Anthropic 相容的 API。用戶端只要把 base_url 指向 `http://localhost:8000/v1`，api_key 隨意填，就能用 openai 或 anthropic SDK 連線。curl 也可以直接打 `/v1/chat/completions`。整個流程確實是一條命令，但要注意，`vmlx serve` 後面接的是 HuggingFace repo 名稱，這代表你必須先有網路下載模型。

混合 SSM 排程與連續批處理

vMLX 支援混合 SSM 模型，像是 Nemotron-H、Jamba、GatedDeltaNet 這些同時有 Mamba 層和 attention 層的架構。文件說它會「correctly handled alongside attention」，這不是小事，因為純 attention 的 KV cache 管理方式不適用於 SSM 層。排程器必須知道哪些層需要快取、哪些層只需要狀態。連續批處理（continuous batching）讓多個請求可以交錯執行，而不是等前一個完成才處理下一個。這對服務多人使用的情境是必要的，否則單一慢請求會卡住整條佇列。不過文件沒有細講排程器的演算法細節，例如搶佔策略或優先權規則，這點在實際部署時需要自己觀察。

模型支援範圍與 JANG 量化

支援清單很長，涵蓋 Qwen、Llama、Mistral、Gemma、DeepSeek、MiniMax 等主流系列，還有視覺模型、語音、甚至 Nemotron-3-Nano-Omni 這種多模態模型。MoE 模型也列了一堆，包括 Laguna 那種 256 個 routed experts 的架構。另外還有 Hybrid SSM 的專門列表，這在其他 MLX 工具裡不常見。比較特別的是 JANG 量化，這是 vMLX 自家的方法，號稱 2-bit 的 JANG_2L 在 MiniMax M2.5 上達到 MMLU 74%，遠高於 MLX 4-bit 的 26.5%。這個數字來自專案自己的測試，200 題的 MMLU 樣本很小，不能當作一般性結論。但它點出了一個真實趨勢：混合精度量化，把重要層保留較高精度，確實可能比統一低 bit 更有效。

加速功能的代價與實驗性質

Speculative decoding 宣稱有 20 到 90% 的加速，但這需要一個小型 draft model 先產生候選 token。這代表你要多下載一個模型，而且 draft model 的品質直接影響加速效果。另一個選項是 Prompt Lookup Decoding，不需要額外模型，靠從 prompt 或 context 裡找 n-gram 重複來加速，文件明說最適合結構化輸出，像是 code 或 JSON。JIT 編譯用 `mx.compile` 做 Metal kernel fusion，但標記為 experimental。這三個功能都不是無腦開啟的，你需要根據自己的工作負載選擇。例如跑自由對話，PLD 幾乎沒用；跑大量 JSON 生成，PLD 可能很有效。文件沒有提供任何基準測試數據來佐證這些加速，所以實際效果得自己測。

真正的限制與不適用的場景

首先，vMLX 只支援 Apple Silicon，因為它依賴 MLX 框架。你不可能把它部署到 NVIDIA GPU 或雲端 CPU 上。其次，L2 磁碟快取雖然能跨重啟，但 SSD 的寫入壽命是有限的，頻繁寫入快取會消耗耐用度。對於快取命中率不高的隨機 prompt，磁碟快取反而是負擔。再者，分散式運算支援「pipeline parallelism across multiple Macs」，但文件沒寫清楚設定方式，這通常需要手動組態網路與模型切分，不是開箱即用。最後，這是一個非常活躍開發的專案，發布頻率幾乎每天一版，例如 v1.6.43、v1.6.44、v1.6.45 接連出現。這代表 API 或行為可能變動，升級時要小心。

與 Ollama 的差異，以及維護成本

Ollama 是另一個常見的本地推論伺服器，它也支援 Apple Silicon，但它不提供 L2 磁碟快取，KV cache 重啟後就沒了。Ollama 的模型格式是 GGUF，而 vMLX 直接吃 MLX 格式，這是一個根本差異。MLX 格式在 Apple Silicon 上通常更有效率，因為它是針對 Metal 最佳化的。但 Ollama 的模型生態比較成熟，HuggingFace 上 GGUF 的數量遠多於 MLX。授權方面，vMLX 是 Apache-2.0，商用沒有障礙，但要注意相依的模型各有自己的授權。維護成本上，因為發布頻率高，你需要追蹤更新；而且文件提到 MLX Studio 這個桌面 App，但那是另一個專案，兩者的關係沒有清楚說明，這對想整合的人來說是個問號。

編輯結論

vMLX 適合已經在 Apple Silicon 上使用 MLX 格式模型、需要多使用者並發或長時間服務的開發者，尤其是那些受夠 Ollama 重複計算 prompt 的人。不適合需要穩定 API 契約或不想碰實驗性功能的團隊，因為 JIT 編譯標記為 experimental，且 speculative decoding 的加速數據來自專案自己的宣稱，尚未有第三方驗證。採用前應先確認你的模型是否落在支援清單，特別是 MoE 與混合 SSM 架構，並用 `vmlx serve` 搭配 `--cache-size` 與 `--disk-cache` 參數實測你的典型 prompt 長度，觀察 L2 快取是否真的能跨重啟命中。若你只需要單機單使用者，Ollama 的簡單度可能更可靠。

官方來源

1. Official documentation
2. Official README
3. Project repository
4. Release notes