oMLX 0.4.5.dev1 讓長上下文更快
oMLX 0.4.5.dev1 為 GLM-5.2 和 MiniMax M3 加入自訂 kernel，長上下文 prefill 明顯加速，也修掉 cache 與 benchmark 載入問題。
oMLX 0.4.5.dev1 針對 GLM-5.2 和 MiniMax M3 加速長上下文推論，還修掉 cache 與 benchmark 載入問題。
oMLX 這版很直接。它不是加一個花俏功能，而是把推論速度拉上來。官方數據顯示，在 Mac Studio 的 M3 Ultra、512 GB unified memory 上，GLM-5.2-oQ4 在 32k context 的 prefill 從 87.7 tok/s 拉到 174.4 tok/s。這種數字，不是小修小補。
MiniMax-M3-oQ3 也很兇。64k context 的 prefill 從 158.8 tok/s 提到 307.7 tok/s。講白了，就是長 prompt 越長，這版越有感。對本機跑 LLM 的人來說，這比多一個設定選單實際太多。
| Model | Context | Baseline PP | oMLX 0.4.5.dev1 PP | Change |
|---|---|---|---|---|
| GLM-5.2-oQ4 | 32k | 87.7 tok/s | 174.4 tok/s | +98.9% |
| GLM-5.2-oQ4 | 16k | 128.1 tok/s | 178.9 tok/s | +39.7% |
| MiniMax-M3-oQ3 | 64k | 158.8 tok/s | 307.7 tok/s | +93.8% |
| MiniMax-M3-oQ3 | 32k | 228.1 tok/s | 327.1 tok/s | +43.4% |
這版的重點，就是自訂 kernels
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這次最有料的地方，是 GLM-5.2 和 MiniMax M3 的自訂 kernel。oMLX 加進了 GLM MoE DSA、Sparse MLA，還有 MiniMax M3 的 sparse-attention 加速與 adaptive long-prefill sizing。意思很簡單。它不再只跑通用路線，而是直接針對模型內部結構下刀。
這種做法很務實。因為在推論世界裡，真正拖慢速度的，常常不是算力不夠，而是路徑太通用。尤其是 prefill。你只要把 context 拉到 32k 或 64k，任何小浪費都會被放大。
官方數據也很誠實。GLM-5.2-oQ4 在 32k context 從 87.7 tok/s 跳到 174.4 tok/s。MiniMax-M3-oQ3 在 64k context 從 158.8 tok/s 到 307.7 tok/s。這不是「有變快」，而是接近翻倍。
- GLM-5.2-oQ4：32k prefill 提升 98.9%
- MiniMax-M3-oQ3：64k prefill 提升 93.8%
- GLM-5.2-oQ4：16k prefill 提升 39.7%
- MiniMax-M3-oQ3：32k prefill 提升 43.4%
cache 和 benchmark 修正，才是能不能信的關鍵
很多人只看速度。老實說，這很危險。因為 benchmark 如果載入錯了，數字再漂亮也沒用。oMLX 0.4.5.dev1 修了 hybrid cache restore 之後的 cache 處理，也修了 chunked prefill insertion 的問題。這代表結果比較不會被 cache 狀態搞歪。
它還修掉 benchmark loading 的路徑問題。原本 VLM MTP 可能會被硬塞進 LM-only loading。這種錯誤很陰。你表面上看到的是「能跑」，實際上跑的路徑根本不對。對做測試的人來說，這比當機更煩。
還有幾個修正也很實用。像是 head_dim=256 的長上下文 prefill OOM，現在會走 tiled SDPA256 path。VLM 的 preflight 也改成算實際 image tokens，不再一律用 max-pixels ceiling。這些都不是裝飾品，是避免你在真實工作負載裡踩雷。
“The point of APIs is to hide the mess,” said John Ousterhout. “If you expose the right interface, the rest becomes easier.”
這句話放在這版很貼切。oMLX 不是只追求快。它也在整理介面，讓資料、cache、benchmark 的邏輯比較一致。這才是能拿來做工具的底子。
模型 profiles 和 preset，讓整合少掉很多鳥事
這版還加了 API 可見的 model profiles。它可以出現在 /v1/models，也能透過同一個 loaded engine 對外提供。對 OpenAI-compatible client 來說，這種資訊很重要。因為 client 會先看你到底載了什麼，再決定怎麼送請求。
如果 serving layer 跟實際 engine 名稱對不起來，問題就會很煩。前端或 agent 可能以為某個 model 可用，結果後端根本不是那個 profile。這種錯不會立刻爆炸，但會讓整套系統很難 debug。
oMLX 也更新了 global presets，包含 MiniMax-M3 和 GLM-5.2。對開發者來說，這代表少寫一些手動配置，也少猜一些參數。
- profiles 可透過
/v1/models暴露 - 同一個 engine 可提供 profile 資訊
- 新增 MiniMax-M3 與 GLM-5.2 預設值
- 更適合 OpenAI-compatible client 串接
跟其他本機推論方案比，這版很偏務實
如果你有碰過 llama.cpp、MLX，或是各種包裝過的本機 serving 工具，你會知道一件事。速度只是第一關。真正麻煩的是長上下文、cache、一致性，還有 API metadata。
oMLX 這版的方向很明確。它不是去搶「誰的短 prompt 最快」。它是在長 context 上做文章。這很合理，因為現在很多應用都不是單輪聊天，而是文件摘要、RAG、agent trace、程式碼分析。這些場景一拉長，差距就出來了。
從數據看，短 context 的提升沒那麼戲劇化。像 GLM-5.2-oQ4 在 1k context，prefill 只從 186.8 tok/s 到 187.7 tok/s。可是一拉到 32k，就直接接近翻倍。這代表 kernel 的價值不是平均分散，而是集中在高壓場景。
- 1k context 的提升小，32k 和 64k 才是主戰場
- 長上下文更接近真實 RAG 與 agent 工作負載
- API metadata 修正，對整合比純速度更重要
- Apple Silicon 本機推論更吃 cache 與 memory 行為
這版透露出一個很清楚的方向
oMLX 的路線不是做一個什麼都能包的通用殼。它比較像是在 Apple Silicon 上，認真把幾個熱門模型跑順。這種選擇很現實，也很對開發者胃口。因為你真的不會想在本機 serving 裡，一直跟 cache 和 metadata 打架。
如果你現在就在用 Mac 跑模型，這版值得試。特別是你手上有長 prompt、長文件，或是多輪 agent 流程。它修的不只是速度，還有那些會讓 benchmark 跟真實工作負載脫節的地方。
我自己的判斷很簡單。接下來如果 oMLX 能把這種 kernel 策略再擴到更多模型，Apple Silicon 的本機推論體驗會更像「能拿來幹活」，而不是「只能 demo」。你如果在做 local AI 工具，這版很適合先跑一次基準測試，再決定要不要升。
下一步很明確：拿你自己的 16k、32k、64k prompt 直接測。不要只看短測資。長上下文才會告訴你，這版到底有沒有真的幫上忙。