JH5

Posted on Jun 13

oMLX vs Ollama Mac 本地推論Qwen3.5–35B實測

#ai #llm #ollama

同一顆 35B 模型，快 7 倍：oMLX vs Ollama Mac 本地推論完整對決

Mac Studio M2 Max 96GB 上，同一顆 Qwen3.5-35B-A3B 模型的循序盲測比較

Mac Studio M2 Max 跌 Ollama + Qwen3.5-35B，多輪對話延遲是 30 秒。換成 oMLX 同一顏模型，降到 4 秒——不是因為換了更強的模型，而是因為換了推論後端。

這篇就是那次切換的完整測試紀錄。同一台機器、同一顆模型、同樣的 prompt，唯一的變數是推論引擎。

TL;DR

指標	oMLX v0.2.7	Ollama v0.17.6	差距
平均生成速度	41.6 tok/s	30.9 tok/s	oMLX +35%
模型載入時間	20.8s	27.0s	oMLX -23%
多輪對話延遲	4.37s	30.66s	oMLX 快 7x
API 相容	OpenAI + Anthropic	OpenAI + 原生	平手
SSD KV Cache	✅	❌	oMLX 獨有
跨平台	macOS only	Linux/macOS/Windows	Ollama 勝
模型格式	MLX only	GGUF + 多種	Ollama 勝

一句話結論：在 Mac 上跑本地 LLM，oMLX 的 MLX 原生推論比 Ollama 的 GGUF 後端快 35%，多輪對話場景更是快 7 倍。但 Ollama 的跨平台與生態系仍然無可取代。

同模型、同機器、不同引擎：差距從哪裡來

如果你在 Mac 上跑本地 LLM，你大概只會遇到兩個選擇：

Ollama：元老級本地推論工具，基於 llama.cpp / GGUF，跨平台，社群龐大，模型庫超齊全
oMLX：2024 年底崛起的 Apple Silicon 專用推論伺服器，基於 MLX 框架，主打 SSD KV Cache 和 Continuous Batching

兩者都能跑同一顆模型，但底層完全不同：

架構對比	oMLX	Ollama
推論引擎	Apple MLX (Metal)	llama.cpp (GGML → Metal)
模型格式	MLX safetensors	GGUF
KV Cache	Tiered: RAM (Hot) + SSD (Cold)	RAM only
批次處理	Continuous Batching	Sequential
記憶體管理	MLX lazy evaluation + mmap	mmap (GGUF)

核心問題：同一顆 35B 的 MoE 模型，MLX 原生格式 vs GGUF Q8_0，在同一台機器上差多少？

測試環境

硬體：Mac Studio (Mac14,13)
晶片：Apple M2 Max (12-core CPU, 38-core GPU)
記憶體：96 GB unified memory
記憶體頻寬：400 GB/s
SSD：460 GB (Apple 內建)
macOS：15.7.3 Sequoia

模型選擇

項目	oMLX	Ollama
模型名	mlx-community/Qwen3.5-35B-A3B-8bit	qwen3.5:35b-a3b-q8_0
格式	MLX safetensors (8 shards)	GGUF Q8_0
大小	35 GB	38 GB
量化	8-bit (MLX native)	Q8_0 (GGUF)

選 Qwen3.5-35B-A3B 是因為它是 MoE 架構（35B 總參數、3B 活化），在 96GB 記憶體上可以完整載入，同時是目前 oMLX 社群排行榜上最熱門的測試模型。

為什麼循序測試？

兩個模型分別佔 35GB 和 38GB，加上系統開銷，96GB RAM 不夠同時載入。嘗試同時啟動時 Ollama 直接 OOM crash。

解法：Phase 1 先跑 Ollama → keep_alive: 0 卸載 → Phase 2 再啟動 oMLX，確保每個後端都能獨佔記憶體。

測試方法

用 Python 腳本自動化，5 種生成測試 + 3 次快取測試 + 4 輪多輪對話：

TESTS = [
    ("Short → 100 tok",     "Explain DNA sequencing in 3 sentences.",         100),
    ("Medium → 300 tok",    "Write a Python function for FASTQ quality ...",  300),
    ("Long → 500 tok",      "Compare Illumina, PacBio, and ONT ...",          500),
    ("Code gen → 300 tok",  "Write a Python VCF parser class ...",            300),
    ("System+User → 200 tok", [system + user multi-message],                  200),
]

Ollama 用原生 /api/chat endpoint，取 eval_count / eval_duration 精確計算
oMLX 用 OpenAI-compat /v1/chat/completions，Bearer token 驗證，以 usage.completion_tokens / elapsed 計算
每次測試間無暖機偏差（同一 session 內模型已在記憶體中）

生成速度：oMLX 快 35%，關鍵在 KV Cache 實作

測試項目	oMLX (tok/s)	Ollama (tok/s)	差距	勝出
Short → 100 tok	41.2	31.4	+31.1%	oMLX
Medium → 300 tok	42.7	30.7	+39.0%	oMLX
Long → 500 tok	41.8	31.0	+34.7%	oMLX
Code gen → 300 tok	41.6	31.1	+34.0%	oMLX
System+User → 200 tok	40.9	30.1	+36.1%	oMLX
平均	41.6	30.9	+35.0%	oMLX

oMLX 在所有測試中都贏，且差距穩定在 +31% ~ +39% 之間。這反映的是底層推論引擎的根本差異：

MLX 的 Metal kernel 是針對 Apple Silicon 的 unified memory 架構從頭設計的
llama.cpp 的 Metal 後端是通用設計，需要額外的 GGUF → Metal 轉換層

模型載入時間

	oMLX	Ollama
首次載入	20.8s	27.0s

oMLX 快 23%。MLX 的 safetensors 直接 mmap 進 unified memory，而 GGUF 需要額外的格式解析步驟。

結果二：Cache / 重複 Prompt

同一個 prompt 連續跑 3 次，看快取效果：

次數	oMLX tok/s	oMLX 延遲	Ollama tok/s	Ollama 延遲
Cold (第 1 次)	40.7	2.46s	31.4	26.87s
Warm (第 2 次)	35.7	2.80s	30.6	27.61s
Hot (第 3 次)	40.3	2.48s	31.1	27.09s

兩者 tok/s 都沒有顯著變化（因為生成量固定 100 tok），但端到端延遲差距驚人：oMLX 始終在 2.5s 完成，而 Ollama 需要 27s — 相差 10 倍以上。

結果三：多輪對話（重頭戲）

這才是真實使用場景——像 coding assistant 一樣的連續來回。設計了 4 輪遞增 context 的 coding 對話：

輪次	Prompt tok	oMLX 延遲	oMLX tok/s	Ollama 延遲	Ollama tok/s	oMLX 快幾倍
Turn 1	323	4.29s	35.0	27.73s	30.7	6.5x
Turn 2	342	4.27s	35.1	31.46s	31.1	7.4x
Turn 3	360	4.63s	32.4	32.46s	30.9	7.0x
Turn 4	378	4.30s	34.9	30.92s	31.3	7.2x

oMLX 在多輪對話中快 7 倍。

每一次 Ollama 回應都要等 ~30 秒，而 oMLX 只需 ~4.3 秒。如果你用本地模型當 coding assistant，這個差距會直接影響工作效率——每一次補全都少等 26 秒。

為什麼差距這麼大？

純 tok/s 生成速度差只有 35%，但端到端延遲差了 7 倍。這說明瓶頸不在生成，而在 prefill + 排程：

oMLX：MLX 的 lazy evaluation 讓 prefill 和 decode 可以高效串接，Metal shader dispatch 開銷極低
Ollama：llama.cpp 的 GGUF decode 路徑有較高的 per-token overhead，即使 prefill 本身很快（224 tok/s @378tok），整體管線延遲較大

Ollama 的 Prefill 速度（獨有指標）

Ollama 原生 API 提供 prompt_eval_duration，可以單獨測量 prefill：

Prompt tokens	Prefill tok/s
19	15.4
32	23.4
33	25.1
40	32.5
64	48.7
378 (multi-turn)	224.1

Prefill 速度隨 prompt 長度線性增長（batch parallelism 發揮作用），378 token 可達 224 tok/s。oMLX 不暴露這個指標，但從端到端延遲來看，MLX 的完整管線整合更優。

功能面比較

速度只是一部分。選推論伺服器還要看功能生態：

┌─────────────────────────┬──────────┬──────────┬──────────┐
│ 功能                    │   oMLX   │  Ollama  │  評語    │
├─────────────────────────┼──────────┼──────────┼──────────┤
│ 生成速度 (tok/s)        │ 41.6     │ 30.9     │ oMLX +35%│
│ 模型載入                │  20.8s   │  27.0s   │ oMLX -23%│
│ 多輪延遲                │  4.37s   │  30.66s  │ oMLX 7x  │
│ SSD KV Cache            │    ✅    │    ❌    │ oMLX 獨有│
│ Continuous Batching     │    ✅    │    ❌    │ oMLX 獨有│
│ Admin Dashboard         │    ✅    │    ❌    │ oMLX 獨有│
│ Tool Calling + MCP      │    ✅    │    ✅    │ 平手     │
│ OpenAI API 相容         │    ✅    │    ✅    │ 平手     │
│ Anthropic API 相容      │    ✅    │    ❌    │ oMLX 獨有│
│ 跨平台                  │ macOS    │ 全平台   │ Ollama 勝│
│ 模型庫數量              │ ~50 MLX  │ 數千 GGUF│ Ollama 勝│
│ 社群規模 (Stars)        │ 2,800+   │ 130K+    │ Ollama 勝│
│ Modelfile 自訂          │    ❌    │    ✅    │ Ollama 獨│
│ Docker / K8s 部署       │    ❌    │    ✅    │ Ollama 獨│
└─────────────────────────┴──────────┴──────────┴──────────┘

該選哪個？

選 oMLX 如果你：

主力機是 Mac，不需要跨平台
用本地模型當 coding assistant / agent（Claude Code / Continue.dev / OpenClaw）
在意 每一次回應的延遲（7x 差距在 agent 場景累積很大）
需要 Anthropic API 相容
想要 Admin Dashboard 一站式管理

選 Ollama 如果你：

需要 Linux / Windows / Docker 部署
需要從海量 GGUF 模型庫中選模型
想用 Modelfile 自訂系統 prompt / 參數
已經有基於 Ollama 的 現有工具鏈
重視 社群支援 和文件完整度

兩者並存？

可以，但 不能同時載入大模型。96GB RAM 塞不下兩個 35GB+ 模型。建議：

日常開發用 oMLX（速度優勢明顯）
特定模型 / 跨平台需求時切換 Ollama
用腳本管理啟停（先 ollama stop 再 omlx serve，反之亦然）

與社群排行榜對照

硬體	模型	oMLX tok/s	記憶體頻寬
M4 Max 40c 128GB	Qwen3.5-35B-A3B 8bit	80.1	546 GB/s
M4 Pro 20c 64GB	Qwen3.5-35B-A3B 8bit	55.1	273 GB/s
M2 Max 96GB（本次）	Qwen3.5-35B-A3B 8bit	41.6	400 GB/s

我們的 M2 Max 結果和記憶體頻寬比例一致：400/546 = 73%，41.6/80.1 = 52%。差距大於頻寬比是因為 M4 Max 的 GPU core 數（40 vs 38）和更新的 Metal 架構也有貢獻。

測試腳本

自動化比較腳本的核心邏輯如下（原始腳本為一次性 benchmark 用途，測試結果已記錄於 OMLX_COMMUNITY_EXPERIMENTS_REPORT.md）：

自動啟停 Ollama / oMLX
5 種生成測試 + 3 次快取測試 + 4 輪多輪對話
JSON 結果匯出 + 終端機友善的比較表
RAM 互搶保護（循序執行）

結語

在 Apple Silicon 上，框架選擇比模型量化更重要。同一顆 Qwen3.5-35B-A3B 在 8-bit 量化下：

MLX (oMLX)：41.6 tok/s，多輪 4.3s
GGUF (Ollama)：30.9 tok/s，多輪 30.7s

差距不是微調，是結構性的。Apple 自家的 MLX 框架在自家晶片上就是更快。

如果你是 Mac 用戶，正在考慮本地推論方案，建議先試 oMLX。裝起來只要一行：

brew tap jundot/omlx https://github.com/jundot/omlx && brew install omlx

啟動後在 Admin Dashboard（http://localhost:8000/admin）下載模型、一鍵 benchmark、確認你的硬體夠不夠用。

Ollama 不是不好——它在跨平台和生態系上依然是最佳選擇。但如果你只在 Mac 上工作，oMLX 讓你用同樣的等待時間做更多事。

延伸閱讀

這篇是 oMLX 實測系列的一部分：

篇	主題	核心發現
—	oMLX 社群調查 + 本機 Benchmark	28.8→41.6 tok/s，6/6 API 通過
—	SSD Cache A/B 測試	Warm/Hot +5~13%，多輪對話建議開啟
—	Concurrent Batching 測試	2x 併發 1.66x 擴展，4x+ 崩潰
—	VLM 多模態測試	Qwen2.5-VL-3B，影像+文字 85 tok/s
—	Tool Calling 測試	3/3 通過，single tool 3.39s
—	Qwen3-Coder-Next 極限測試	51.7 tok/s，HumanEval Pass@1 91.5%
本篇	oMLX vs Ollama 面對面	+35% 速度，7x 對話延遲差

如果這篇對你有幫助，或你在其他硬體（M3 Max / M4 / M4 Pro）上有不同結果，歡迎留言分享你的數據。Mac 本地推論的效能上限，很大程度取決於我們這些實際測試的人願意公開多少數據。

測試日期：2026-03-12 | oMLX v0.2.7 vs Ollama v0.17.6 | Mac Studio M2 Max 96GB | Qwen3.5-35B-A3B 8bit

DEV Community