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

前文，評(píng)論區(qū)好幾個(gè)兄弟推薦測(cè)試 oMLX：

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

• 聽(tīng)說(shuō) omlx 比 lm studio 更好用些，占用內(nèi)存更小，有沒(méi)有嘗試部署一下？

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

花半天玩了一下，先看大家最關(guān)心的測(cè)試情況：

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

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

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

安裝后直接進(jìn)入 Perference，自定義模型位置，端口號(hào)

模型位置后面我把他改到了外接移動(dòng)硬盤(pán)

菜單欄確實(shí)方便，一鍵啟停 server、進(jìn)入管理后臺(tái)，進(jìn)入聊天界面

先要進(jìn)入模型 tab 然后點(diǎn)下載器

下面的瀏覽模型可以直接看能否支持當(dāng)前主機(jī)

下載速度極慢，后來(lái)我換成了 modelcope

感覺(jué)也有 bug，直接從上面下載，他會(huì)默認(rèn)下載整個(gè)項(xiàng)目下的不同精度模型，而我只需要 Q4

27B 我也下了

沒(méi)有選擇 Jackrong 原版，主要是被 mlx-community 這句話(huà)吸引了

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

官方測(cè)試數(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)

下載過(guò)程中進(jìn)入設(shè)置頁(yè)

資源管理這里可以控制內(nèi)存占用情況，

下載完畢，可以選擇在設(shè)置 - 模型設(shè)置中啟動(dòng)，剛開(kāi)始居然沒(méi)找到哪里加載

聊天頁(yè)面，很清爽

儀表盤(pán)會(huì)記錄模型運(yùn)行情況

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

它還可以做基準(zhǔn)測(cè)試

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

測(cè)試

TTFT (ms)

TPOT (ms/tok)

pp TPS

tg TPS

端到端延遲

吞吐量

峰值內(nèi)存

pp32768/tg128

187.4 tok/s

11.8 tok/s

185.686s

177.2 tok/s

9.06 GB

單請(qǐng)求 + 批處理能力沒(méi)敢開(kāi)高，tg TPS 20.2 tok/s。輸入拉長(zhǎng)到 4096 token 后 TTFT 從 4.8s 變成 18.8s，tg TPS 還在 19.8 tok/s，幾乎沒(méi)掉，Peak Mem 從 5.66 GB 到 6.40 GB

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

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

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

重新嘗試可以識(shí)別到四次，svg 寫(xiě)的很丑

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

27B 無(wú)法跑起來(lái)

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

我要換 32G 的 Mac 了

但是 LM Studio 就可以用 option 按鍵強(qiáng)跑，只是無(wú)法執(zhí)行任務(wù)，機(jī)器卡死

其他再說(shuō)說(shuō)

看了官方文檔，再說(shuō)幾個(gè) oMLX 的亮點(diǎn)，可是我都沒(méi)嘗試

1. 連續(xù)批處理

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

• 單請(qǐng)求、8k 上下文時(shí)，Prompt 處理速度能到941 tok/s

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

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

• 對(duì)應(yīng)3.36 倍吞吐提升

• 內(nèi)存占用峰值 73 GB

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

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

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

• 加速比來(lái)到4.14 倍

• 內(nèi)存占用峰值 85GB

README 里有一句：

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

官方給出的方向主要有兩個(gè)：

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

• 通過(guò) SSE keep-alive，降低長(zhǎng)時(shí)間 prefill 時(shí)讀超時(shí)的風(fēng)險(xiǎn)

它本身還支持：

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

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

• 工具調(diào)用

• MCP 集成

它在同一服務(wù)里支持：

• 文本 LLM

• VLM

• OCR 模型

• Embedding

• Reranker