oMLX 效能調校 KV Cache 與Concurrent Batching

#ai #security #nvidia #llm

oMLX 效能調校 KV Cache 與Concurrent Batching

上一篇 oMLX vs Ollama Mac 本地推論Qwen3.5–35B實測踹完之後，一直很好奇介紹中提到的 KV Cache 與 Concurrent Batching 跟過去理解的有什麼差異？

印象中，大多數本地推論伺服器的 KV Cache 活在 RAM 裡，重啟就消失，每次送一樣的 prompt 都要從頭算。

oMLX 做了兩件反直覺的事：

把 KV Cache 持久化到 SSD — — 重啟後 warm/hot prompt 可以跳過重算，直接讀 disk
Continuous Batching — — 同時處理多個請求，而不是讓它們在 queue 裡排排坐

聽起來都很美好，但實際效果如何？

實測一：SSD KV Cache A/B 比較

同一個 prompt，分別在 Cache ON 和 Cache OFF 模式下跑，每次生成 200 tokens：

Cold 和 Short 場景 Cache ON 反而慢，原因是 SSD cache lookup 本身有 overhead。當生成量很小或 context 全新時，這個 overhead 大於省下的計算量。

Warm/Hot/Partial 場景 Cache ON 快 5~13%，原因是 oMLX 把先前計算過的 KV 狀態持久化到 SSD，重送相同 (或部分相同) 的 context 時可以直接從 disk 恢復，跳過 prefill 重算。

以我自己大多數是拿來做 coding assistant / agent 相關的應用，建議應該是可以打開這個設定。

# 開啟 SSD Cache（適合多輪對話、coding agent）  
omlx serve --model-dir ~/models --paged-ssd-cache-dir ~/.omlx/cache  

# 外接 SSD（推薦：分離 model storage 和 cache）  
omlx serve \  
  --model-dir /Volumes/ExternalSSD/models \  
  --paged-ssd-cache-dir /Volumes/ExternalSSD/omlx-cache

實測二：Concurrent Batching 壓測

同時送多個請求，測量聚合吞吐量（aggregated tok/s），每次生成 100 tokens。

不知道是不是老M2 Ma的記憶體頻寬問題，跑2X 設定大概有1.6x的提升，不過設定到4X會一直出現 timeout，看起來肚子內應該是炸掉了ＱＱ

# 推薦啟動指令  
omlx serve \  
  --model-dir /Volumes/ExternalSSD/models \  
  --paged-ssd-cache-dir /Volumes/ExternalSSD/omlx-cache \  
  --max-concurrent 2

oMLX 的這兩個功能都有明確的使用場景邊界：

SSD Cache：多輪對話和 agent 場景加速 5~13%，一次性查詢略慢
Concurrent Batching：M2 Max 的甜蜜點是 2~3 個，超過就崩

比起 Ollama 完全不支援 SSD Cache、Sequential 排隊的架構，oMLX 在 Apple Silicon 上已經領先太多了，也讓地端的部署稍稍看得到雲端體驗的車尾燈ＸＤ。

# ai # llm # nvidia**13 views

DEV Community

oMLX 效能調校 KV Cache 與Concurrent Batching