oMLX 走的是 Apple Silicon + MLX 這條路，Windows 和 NVIDIA 這邊的朋友，這篇先看看熱鬧就好

前文，評論區(qū)好幾個兄弟推薦測試 oMLX：

• 博主有時間可以研究一下oMLX這個替代 LM Studio，據(jù)說比 lm 快很多倍。

• 聽說 omlx 比 lm studio 更好用些，占用內存更小，有沒有嘗試部署一下？

• 有大佬做成適合 omlx 跑的 fp8 量化版了，大概 10G，可以試試。同樣機器配置，換用了 oMLX 跑 qwen3.5 9b MLX Q4 版，利落了些，15token 左右吧。雖然回復慢，但還能用。而 ollama 跑就卡頓的很。

花半天玩了一下，先看大家最關心的測試情況：

• oMLX 有很多亮點，UI、菜單欄、管理后臺儀表板，Chat 頁面都很漂亮，底層有 SSD KV 緩存、設置熱緩存、支持 MCP、一鍵對接各種 AI Coding Agent，OpenAI/Anthropic 兼容接口、針對 Claude Code 優(yōu)化等

• 單請求生成速度約 20 token/s，峰值顯存/統(tǒng)一內存占用約 5.7GB

• 無法硬跑 Qwen3.5-27B-Claude-4.6-Opus-Distilled-MLX-4bit，LM Studio 可以強跑，但只能加載，執(zhí)行任務直接徹底卡死

安裝后直接進入 Perference，自定義模型位置，端口號

模型位置后面我把他改到了外接移動硬盤

菜單欄確實方便，一鍵啟停 server、進入管理后臺，進入聊天界面

先要進入模型 tab 然后點下載器

下面的瀏覽模型可以直接看能否支持當前主機

下載速度極慢，后來我換成了 modelcope

感覺也有 bug，直接從上面下載，他會默認下載整個項目下的不同精度模型，而我只需要 Q4

27B 我也下了

沒有選擇 Jackrong 原版，主要是被 mlx-community 這句話吸引了

但是 27B 最低使得 24 GB 及以上統(tǒng)一內存的 Mac 都能運行該模型，且還有足夠空間容納大型上下文窗口，推薦是 32GB

官方測試數(shù)據(jù)：

Metric

Result

Model load time

2.4 seconds

Prompt ingestion

86.5 tokens/sec

Generation speed

15.7 tokens/sec

Peak RAM usage

15.6 GB

Bit-rate

4.501 bits/weight

Final size

14 GB (3 shards)

下載過程中進入設置頁

資源管理這里可以控制內存占用情況，

下載完畢，可以選擇在設置 - 模型設置中啟動，剛開始居然沒找到哪里加載

聊天頁面，很清爽

儀表盤會記錄模型運行情況

現(xiàn)在往下也能把啟動的模型一見接入到 Codex、OpenCode、OpenClaw

它還可以做基準測試

32K 單請求測試，電腦已經(jīng)有點卡了，TTFT 高的離譜，TPS 只有 11

測試

TTFT (ms)

TPOT (ms/tok)

pp TPS

tg TPS

端到端延遲

吞吐量

峰值內存

pp32768/tg128

187.4 tok/s

11.8 tok/s

185.686s

177.2 tok/s

9.06 GB

單請求 + 批處理能力沒敢開高，tg TPS 20.2 tok/s。輸入拉長到 4096 token 后 TTFT 從 4.8s 變成 18.8s，tg TPS 還在 19.8 tok/s，幾乎沒掉，Peak Mem 從 5.66 GB 到 6.40 GB

并發(fā)到 2-4 路時總吞吐提升明顯，但 8 路已經(jīng)接近平臺上限，延遲代價很大。

依舊測試閱讀理解+SVG 代碼生成 + 審美

感覺不穩(wěn)了，需要抽卡

重新嘗試可以識別到四次，svg 寫的很丑

讓其優(yōu)化之后，它的腦回路讓我想笑，它直接設計了模擬人物動作，完全偏離了主題

27B 無法跑起來

改了 N 多配置都不行，有高手可以出出主意

我要換 32G 的 Mac 了

但是 LM Studio 就可以用 option 按鍵強跑，只是無法執(zhí)行任務，機器卡死

其他再說說

看了官方文檔，再說幾個 oMLX 的亮點，可是我都沒嘗試

1. 連續(xù)批處理

它基于mlx-lm的BatchGenerator做并發(fā)處理，首頁給了一組非常直觀的 benchmark，機器是 M3 Ultra 512GB，模型是 Qwen3.5-122B-A10B-4bit：

• 單請求、8k 上下文時，Prompt 處理速度能到941 tok/s

• Token 生成速度大約54.0 tok/s

• 在8x連續(xù)批處理下，總吞吐能到190.2 tok/s

• 對應3.36 倍吞吐提升

• 內存占用峰值 73 GB

另一組我很關注的數(shù)據(jù)是Qwen3-Coder-Next-8bit：

• 8k 上下文時，Prompt 處理速度2009 tok/s

• 8x批處理總吞吐243.3 tok/s

• 加速比來到4.14 倍

• 內存占用峰值 85GB

README 里有一句：

支持在 Claude Code 中使用較小上下文模型的上下文縮放。通過縮放上報的 Token 數(shù)量，讓自動壓縮在合適的時機觸發(fā)，同時提供 SSE keep-alive 防止長時間預填充導致的讀取超時。

官方給出的方向主要有兩個：

• 通過上下文縮放，讓較小上下文模型在 Claude Code 里更容易觸發(fā)合適的自動壓縮時機

• 通過 SSE keep-alive，降低長時間 prefill 時讀超時的風險

它本身還支持：

• OpenAI 兼容接口：http://localhost:8000/v1

• Anthropic 兼容接口：POST /v1/messages

• 工具調用

• MCP 集成

它在同一服務里支持：

• 文本 LLM

• VLM

• OCR 模型

• Embedding

• Reranker