用 oMLX 榨乾 Apple Mac M 系列
一句話先講結論
如果場景是 Apple Silicon 上的本地 LLM serving，且重視速度、併發與 agent / API 型工作負載，oMLX 值得優先關注。
目前的 baseline 評測來看，oMLX 相較 Ollama 在 warm latency、token throughput、TTFT (Time To First Token) 與 concurrency 都有明顯優勢。
oMLX 是什麼？
oMLX 可以把它理解成：
專為 Apple Silicon 優化的本地 LLM serving backend
底層建立在 Apple MLX 生態上
目標不是「最容易上手」，而是 把 Mac 上的 serving 效能盡量榨出來
適合拿來接：
OpenAI-compatible API
coding agent / tool calling
本地 inference service
需要多請求處理的 backend 場景
相對地，Ollama 比較像是目前最普及、最容易上手的本地模型執行環境。
所以兩者不是單純誰取代誰，而是：
Ollama：上手快、生態熟、跨平台
oMLX：Apple Silicon 上更偏效能導向的 serving backend
為什麼 oMLX 在 Apple Silicon 上值得看？
oMLX 核心技術 (詳細版) (TBD)
oMLX 值得注意的地方，在於它不是把通用推論框架搬到 Mac 上，而是直接針對 Apple Silicon 與 MLX 生態做原生優化。
它的幾個關鍵特色包括：
MLX 原生整合：專注 Apple Silicon，少掉跨平台抽象層的額外成本，MLX 原生模型格式優先減少不必要的格式轉換與記憶體浪費
Tiered KV Cache：結合 RAM 與 SSD，對長上下文與重複 prompt 更有利
Continuous Batching：多請求下能提升整體吞吐與資源利用率
oMLX v.s Ollama
可以用一句很容易懂的方式介紹：
oMLX 比較像「針對 Apple Silicon 做到更高效的 serving backend」，而 Ollama 比較像「最好上手的本地 LLM 工具」。
差異對照
面向 | oMLX | Ollama |
核心定位 | Apple Silicon 效能導向 serving | 通用型、本地模型入口 |
生態取向 | MLX / mlx-lm / mlx-vlm | GGUF / llama.cpp 生態較成熟 |
長處 | throughput、TTFT、併發、cache 管理 | 上手快、文件多、跨平台 |
比較適合 | API、agent、長駐服務、多模型調度 | 個人使用、快速試模型、跨平台開發 |
格式偏好 | MLX 原生格式更自然 | GGUF 生態最成熟 |
實測數據比較
Apple M1 Max (24c), RAM 32GB
評測模型: Qwen3.5-35B-A3B-4bit / Qwen3.5 35B-A3B Q4_K_M (約 20 GB)
指標 | oMLX | Ollama | 解讀 |
Warm latency（平均 total latency） | 3380 ms | 9463 ms | oMLX 約 2.8x 較快 |
Token throughput（平均 TG tok/s） | 56.8 tok/s | 20.3 tok/s | oMLX 約 2.8x 較高 |
TTFT（平均） | 322 ms | 523 ms | oMLX 少約 201 ms，約低 38% |
Prompt ingest（平均 PP tok/s） | 111.7 tok/s | 68.8 tok/s | oMLX 約 1.6x 較高 |
Concurrency 2（wall time） | 5246 ms | 18884 ms | oMLX 約 3.6x 較快 |
Concurrency 2（aggregate output_tps） | 73.199 tok/s | 20.335 tok/s | oMLX 約 3.6x 較高 |
Concurrency 4（wall time） | 8865 ms | 37557 ms | oMLX 約 4.2x 較快 |
Concurrency 4（aggregate output_tps） | 86.633 tok/s | 20.449 tok/s | oMLX 約 4.2x 較高 |
單請求就有差
warm latency、TG tok/s、TTFT 都是 oMLX 贏
多請求差更大
一進到 concurrency 2 / 4，oMLX 的優勢被明顯放大
作者：Bobson Lin