DEV Community

JH5
JH5

Posted on • Originally published at Medium

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

#ai #security #llm #ollama

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

oMLX

應該很多人會有這個經驗，用 Ollama 接本地模型當 coding assistant，每次等回應要盯著轉圈圈等個 2-30 秒，WTF？

我之前用 Ollama 跑 Qwen3.5–35B 時就是這個感覺，這陣子換了 oMLX 試試，同一顆模型的多輪對話延遲從 30 秒降到 4 秒 — — 不是因為換了更強的模型，而是因為換了推論後端。

讓我認真的開始考慮有一些手邊的地端小玩具是不是應該把底層轉到oMLX。

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

  • Ollama：元老級本地推論工具，基於 llama.cpp / GGUF，跨平台，社群龐大，模型庫超齊全

  • oMLX：2024 年底崛起的 Apple Silicon 專用推論伺服器，基於 MLX 框架，主打 SSD KV Cache 和 Continuous Batching

於是我就小小的好奇，同一顆 35B 的 MoE 模型，MLX 原生格式(mlx-community/Qwen3.5–35B-A3B-8bit) vs GGUF Q8_0 (qwen3.5:35b-a3b-q8_0)，在同一台M2 Max上差多少？

選 Qwen3.5–35B-A3B 是因為它是 MoE 架構（35B 總參數、3B 活化），同時是目前 oMLX 社群排行榜上最熱門的測試模型。

測試方法 

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),  
]
Enter fullscreen mode Exit fullscreen mode

小幫手幫我寫了 Python 腳本自動化，5 種生成測試 + 3 次快取測試 + 4 輪多輪對話

  • Ollama 用原生 /api/chat endpoint，取 eval_count / eval_duration 精確計算

  • oMLX 用 OpenAI-compat /v1/chat/completions，Bearer token 驗證，以 usage.completion_tokens / elapsed 計算

結果一：生成速度

結果一：生成速度

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

  • MLX 的 Metal kernel 是針對 Apple Silicon 的 unified memory 架構從頭設計的

  • llama.cpp 的 Metal 後端是通用設計，需要額外的 GGUF → Metal 轉換層

在模型載入時間，oMLX 的首次載入大概花了20s, Ollama 大約27s，oMLX 快 23%，主要是因為MLX 的 safetensors 直接 mmap 進 unified memory，而 GGUF 需要額外的格式解析步驟。

結果二：Cache / 重複 Prompt

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

結果二：Cache / 重複 Prompt

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

結果三：多輪對話

像 coding assistant 一樣的連續來回。設計了 4 輪遞增 context 的 coding 對話：

結果三：多輪對話

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

原因應該是因為瓶頸不在生成，而在 prefill + 排程：

  • oMLX：MLX 的 lazy evaluation 讓 prefill 和 decode 可以高效串接，Metal shader dispatch 開銷極低

  • Ollama：llama.cpp 的 GGUF decode 路徑有較高的 per-token overhead，即使 prefill 本身很快（224 tok/s @378tok），整體管線延遲較大

目前 Ollama 原生 API 提供 prompt_eval_duration 指標，Prefill 速度隨 prompt 長度線性增長 ，不過目前oMLX沒有揭露相關的數據，看來在E2E內部MLX整合的很順暢。

在 Mac 上跑本地 LLM，oMLX 的 MLX 原生推論比 Ollama 的 GGUF 後端快 35%，多輪對話場景更是快 7 倍，Apple 自家的 MLX 框架在自家晶片上就是更快。

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

brew tap jundot/omlx https://github.com/jundot/omlx && brew install omlx
Enter fullscreen mode Exit fullscreen mode

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

# ai# llm# ollama**2 views

Top comments (0)