oMLX 國外社群實測整理 & 本機實測計畫
調查日期：2026-03-11 | 來源：Reddit r/LocalLLaMA, r/ClaudeAI, r/openclaw, GitHub Issues/Discussions, omlx.ai/benchmarks
一、oMLX 是什麼？
oMLX（v0.2.7，2,800+ stars）是專為 Apple Silicon 打造的開源 LLM 推論伺服器，核心特色：
| 特色 | 說明 |
|---|---|
| Tiered KV Cache (Hot+Cold) | RAM 為 hot tier，SSD 為 cold tier，KV cache 持久化到 SSD，重啟不遺失 |
| Continuous Batching | 支援多併發請求，透過 mlx-lm BatchGenerator |
| Claude Code / OpenClaw 優化 | 原生 Anthropic API (/v1/messages)，context scaling，SSE keep-alive |
| Multi-Model Serving | 同時載入 LLM + VLM + Embedding + Reranker，LRU eviction |
| macOS 原生 App | PyObjC menubar app（非 Electron），DMG 安裝或 brew install omlx
|
| Tool Calling | 支援 Llama/Qwen/DeepSeek/Gemma/GLM/MiniMax/Mistral/Kimi 等格式 + MCP |
| 內建 Benchmark | Admin Dashboard 一鍵跑基準測試，v0.2.6+ 可上傳至社群排行榜 |
二、國外論壇實測整理（近 4 週）
實測 1：M3 Ultra 512GB 三大模型 PK（r/LocalLLaMA, 38↑, 29 comments）
作者 @cryingneko（oMLX 開發者）在 M3 Ultra 512GB 上實測三款模型：
| 模型 | 量化 | pp TPS (1K) | tg TPS (single) | tg TPS (8x batch) | Peak Mem |
|---|---|---|---|---|---|
| Qwen3-Coder-Next | 8bit | 1,461.7 | 58.7 | 243.0 | 80 GB |
| MiniMax-M2.5 | 8bit | 588.0 | 34.0 | 126.3 | 227 GB |
| GLM-5 | 4bit | 187.0 | 16.7 | 60.3 | 392 GB |
社群結論：
- Qwen3-Coder-Next-80B 是本地編碼之王，速度 + 品質可媲美商業服務
- MiniMax-M2.5 prefix caching 加速後 TTFT 顯著下降，「surprisingly usable」
- GLM-5 速度不快但搭配 continuous batching + persistent KV cache，翻譯 + 大量 system prompt 場景實用
實測 2：Claude Code 本地化（r/ClaudeAI, r/LocalLLaMA）
痛點： Claude Code 的工作流會持續改變 prompt prefix → 每次都要重算 30-100K tokens 的 KV cache → 每個回應 20-90 秒
oMLX 解法： SSD 持久化 KV cache → TTFT 從 20-90s 降至 3-5s
用戶回饋精選：
- @slypheed (M4 Max 128GB): 「Claude Code is actually usable with Qwen3-Coder-Next 6bit」「SSD caching makes a massive difference」「gave up on agentic CLI locally until oMLX」
- @whallsey (M4 Pro 64GB): 「Qwen3.5-35B-A3B-4bit + oMLX + Claude Code has been awesome」
- @Creepy-Bell-4527: 「an absolute beast for claude code」「can have both MLX speeds and caching」
- @Kuane: 「replaced LM Studio〞qwen3-coder-next responds A LOT faster due to prompt caching」
實測 3：M4 Max 128GB — Qwen3.5 MoE（omlx.ai/benchmarks + Reddit）
@slypheed 在 M4 Max 128GB 實測：
| 模型 | 量化 | pp TPS (1K) | tg TPS | Peak Mem |
|---|---|---|---|---|
| Qwen3.5-27B | 6bit | 231.4 | 20.7 | 22 GB |
| Qwen3.5-122B-A10B | 6bit | 490.6 | 45.7 | 94 GB |
評價： Qwen3.5 是第一個在 Claude Code 下「actually successfully used」的本地模型
實測 4：OpenClaw 整合（r/openclaw）
- SSD caching 將 OpenClaw 回應時間從 30-90s 降至 5s
- 用戶報告取代 Ollama/LM Studio 做為 OpenClaw 後端
實測 5：社群 Benchmark 排行榜（omlx.ai/benchmarks）
v0.2.6+ 內建一鍵 benchmark 上傳，目前已累積 5,521 筆 社群基準測試結果：
| # | 晶片 | RAM | 模型 | pp TPS | tg TPS |
|---|---|---|---|---|---|
| 1 | M4 Max 40c | 128GB | Qwen3.5-35B-A3B 8bit | 1,654 | 80.1 |
| 2 | M4 Pro 20c | 64GB | Qwen3.5-35B-A3B 8bit | 893 | 55.1 |
| 3 | M3 Ultra 80c | 512GB | Qwen3.5-122B-A10B 8bit | 843 | 39.0 |
| 4 | M4 10c | 16GB | Qwen3.5-4B 4bit | 412 | 38.5 |
| 5 | M4 10c | 16GB | Qwen3.5-9B 4bit | 225 | 21.4 |
實測 6：vs LM Studio / Ollama 比較
社群普遍共識：
- vs Ollama: Ollama 不支援 SSD KV cache，prefix shift 時必須重算。oMLX 在 coding agent 場景完勝
- vs LM Studio: LM Studio 的 KV cache 在 Mac 上「seems buggy」，oMLX 更輕量且 SSD caching 穩定
- 共存技巧: oMLX 可直接讀取 LM Studio 的模型目錄，不用重複下載
三、本機硬體評估
Mac Studio (Mac14,13)
├── Chip: Apple M2 Max
├── Memory: 96 GB
├── macOS: 15.7.3 (Sequoia) ✅ 符合 macOS 15.0+ 需求
└── Free Disk: ✅ 88 GB（清理 TM snapshots 後，模型已下載就位）
96GB M2 Max 可跑的模型
| 模型 | 量化 | 估計 VRAM | 適合場景 | 社群推薦度 |
|---|---|---|---|---|
| Qwen3.5-35B-A3B | 4bit | ~12-15 GB | 編碼/通用，MoE 速度快 | ⭐⭐⭐⭐⭐ |
| Qwen3.5-35B-A3B | 8bit | ~20-25 GB | 編碼/通用，品質更好 | ⭐⭐⭐⭐⭐ |
| Qwen3-Coder-Next | 8bit | ~80 GB | 專業編碼，96GB 勉強可載入 | ⭐⭐⭐⭐ |
| Qwen3.5-9B | 4bit | ~5 GB | 輕量快速測試 | ⭐⭐⭐ |
| Devstral Small 2 | 4-8bit | ~12-24 GB | Mistral 編碼模型 | ⭐⭐⭐ |
| GLM4.7 Flash | MXFP8 | ~30 GB | 工具呼叫佳 | ⭐⭐⭐ |
⚠️ 磁碟空間問題
目前只有 17.9 GB 可用空間，而：
- 模型下載需要 5-80 GB / 每個模型
- SSD KV cache 建議預留 50-100 GB
- 建議：外接 SSD 或清理空間至少到 100 GB+
四、建議實測計畫
Phase 1：安裝 + 最小模型驗證（需先清出磁碟空間）
# 方案 A: Homebrew 安裝
brew tap jundot/omlx https://github.com/jundot/omlx
brew install omlx
# 方案 B: DMG 安裝（從 GitHub Releases 下載）
# 啟動
omlx serve --model-dir ~/models
Phase 2：Qwen3.5-35B-A3B 實測（首推）
社群最推薦的 M2 Max 96GB 模型組合：
- 從 Admin Dashboard 下載
mlx-community/Qwen3.5-35B-A3B-8bit - 跑內建 benchmark（pp1024/tg128, pp4096/tg128）
- 上傳結果到 omlx.ai/benchmarks 社群排行榜
- 用 Admin Chat 對話測試
Phase 3：Claude Code / OpenClaw 整合
# Claude Code 整合（需要 claude CLI）
# oMLX Admin 有一鍵 Claude Code config 生成器
# API 端點
# OpenAI: http://localhost:8000/v1
# Anthropic: http://localhost:8000/v1/messages
Phase 4：SSD Cache 效能對比
- 關閉 SSD cache 跑 benchmark → 記錄 TTFT
- 開啟 SSD cache 跑同樣 benchmark → 比較 TTFT
- 多輪對話測試（模擬 coding agent prefix shift）
# 啟用 SSD cache
omlx serve --model-dir ~/models --paged-ssd-cache-dir ~/.omlx/cache
# 外接 SSD （建議）
omlx serve --model-dir /Volumes/ExternalSSD/models --paged-ssd-cache-dir /Volumes/ExternalSSD/omlx-cache
Phase 5：Multi-Model Serving 測試
96GB 可以同時載入：
- Qwen3.5-35B-A3B 8bit (~25 GB) — 主力 LLM
- BGE-M3 (~2 GB) — Embedding
- 合計約 27 GB，仍有大量 headroom 給 KV cache
五、社群熱門議題 & 待解問題
| 議題 | 狀態 | 相關 Issue |
|---|---|---|
| M5 Ultra 支援（WWDC 2026 後） | 等待 | 社群討論中 |
| Qwen3.5 thinking 開關失效 | Open | #120 |
| 8GB RAM 裝置 auto 記憶體計算錯誤 | Open | #137 |
| GPU 99% stuck | Open | #131 |
| OpenClaw 複雜任務 crash | Open | #133 |
| /responses API 相容性 | Open | #138 |
| Windows 支援 | 不支援 | Apple Silicon only |
| 多機分散式推論 | 未支援 | 社群多人詢問 |
六、與現有 Post 的關聯
| 現有 Post | oMLX 關聯角度 |
|---|---|
| MedGemma 變異解讀 | oMLX 可做為 MedGemma MLX 版的推論後端 |
| DeepVariant GPU 測試 | 本地 LLM 輔助 VCF 報告解讀 |
| AI Security (Patching Agent) | oMLX + local LLM 做為無 API 費用的安全修補 Agent |
| Gemini 3.1 Flash-Lite 實測 | oMLX 做為本地替代方案的成本對照組 |
七、本機實測結果（2026-03-11 實際跑完）
環境
| 項目 | 值 |
|---|---|
| 硬體 | Mac Studio M2 Max 96GB |
| macOS | 15.7.3 Sequoia |
| oMLX | v0.2.7（Homebrew 安裝） |
| 模型 | mlx-community/Qwen3.5-35B-A3B-8bit（35 GB, 8 shards） |
| SSD Cache | 已啟用 (~/.omlx/cache) |
| 內部 SSD 可用 | 88 GB（清理後從 18 GB 回收） |
模型載入
- 首次載入 35 GB → RAM：~23 秒
- 後續推理無需重新載入
Benchmark 結果
| 測試案例 | Prompt tok | Generated tok | 耗時 | 吞吐量 |
|---|---|---|---|---|
| Short prompt → 200 tok | 21 | 200 | 7.2s | 27.8 tok/s |
| Medium prompt → 500 tok | 44 | 500 | 16.6s | 30.2 tok/s |
| Long system prompt → 200 tok | 164 | 200 | 7.3s | 27.3 tok/s |
| Cache hit (same prompt) → 200 tok | 21 | 200 | 6.7s | 29.9 tok/s |
| Code generation → 300 tok | 42 | 300 | 10.4s | 28.8 tok/s |
| 平均 | 28.8 tok/s |
與社群排行榜比較
| 硬體 | 模型 | tg tok/s | 來源 |
|---|---|---|---|
| M4 Max 40c 128GB | Qwen3.5-35B-A3B 8bit | 80.1 | omlx.ai 排行榜 |
| M4 Pro 20c 64GB | Qwen3.5-35B-A3B 8bit | 55.1 | omlx.ai 排行榜 |
| M2 Max 96GB（本機） | Qwen3.5-35B-A3B 8bit | 28.8 | 本次實測 |
M2 Max 的記憶體頻寬（400 GB/s）約為 M4 Max（546 GB/s）的 73%，速度比例合理。
API 相容性測試
| 端點 | 結果 |
|---|---|
| GET /v1/models | ✅ |
| POST /v1/chat/completions (OpenAI) | ✅ |
| POST /v1/completions (legacy) | ✅ |
| Streaming SSE (32 chunks) | ✅ |
| Admin Dashboard (/admin) | ✅ |
| POST /v1/messages (Anthropic) | ✅ |
| 總計 | 6/6 通過 |
8. oMLX vs Ollama 面對面比較
測試日期: 2026-03-12 | 同機、同模型、循序執行（避免 96GB RAM 互搶）
測試設計
| 項目 | oMLX | Ollama |
|---|---|---|
| 版本 | v0.2.7 | v0.17.6 |
| 模型 | Qwen3.5-35B-A3B-8bit (MLX, 35 GB) | qwen3.5:35b-a3b-q8_0 (GGUF Q8_0, 38 GB) |
| 量化方式 | MLX 原生 8-bit | GGUF Q8_0 |
| API | OpenAI-compat /v1/chat/completions
|
原生 /api/chat
|
| 執行順序 | Phase 2（先卸載 Ollama 釋放 RAM） | Phase 1（先跑，跑完 keep_alive: 0 卸載） |
生成速度比較
| 測試項目 | oMLX (tok/s) | Ollama (tok/s) | 差距 | 勝出 |
|---|---|---|---|---|
| Short → 100 tok | 41.2 | 31.4 | +31.1% | oMLX |
| Medium → 300 tok | 42.7 | 30.7 | +39.0% | oMLX |
| Long → 500 tok | 41.8 | 31.0 | +34.7% | oMLX |
| Code gen → 300 tok | 41.6 | 31.1 | +34.0% | oMLX |
| System+User → 200 tok | 40.9 | 30.1 | +36.1% | oMLX |
| 平均 | 41.6 | 30.9 | +35.0% | oMLX |
模型載入時間
| 指標 | oMLX | Ollama |
|---|---|---|
| 首次載入 (warmup) | 20.8s | 27.0s |
oMLX 載入快 23%，MLX safetensors 格式比 GGUF 更適合 Apple Silicon 記憶體映射。
Cache / 重複 Prompt 測試（同一 prompt 跑 3 次）
| 次數 | oMLX (tok/s) | oMLX 延遲 | Ollama (tok/s) | Ollama 延遲 |
|---|---|---|---|---|
| Cold (第 1 次) | 40.7 | 2.46s | 31.4 | 26.87s |
| Warm (第 2 次) | 35.7 | 2.80s | 30.6 | 27.61s |
| Hot (第 3 次) | 40.3 | 2.48s | 31.1 | 27.09s |
兩者在重複 prompt 上都沒有顯著的 cache 加速（100 token 生成量固定），但 oMLX 的端到端延遲始終低 10x 以上。
多輪對話延遲（4 輪連續 coding 對話）
| 輪次 | oMLX 延遲 | oMLX tok/s | Ollama 延遲 | Ollama tok/s | oMLX 快幾倍 |
|---|---|---|---|---|---|
| Turn 1 (323 prompt tok) | 4.29s | 35.0 | 27.73s | 30.7 | 6.5x |
| Turn 2 (342 prompt tok) | 4.27s | 35.1 | 31.46s | 31.1 | 7.4x |
| Turn 3 (360 prompt tok) | 4.63s | 32.4 | 32.46s | 30.9 | 7.0x |
| Turn 4 (378 prompt tok) | 4.30s | 34.9 | 30.92s | 31.3 | 7.2x |
多輪對話場景 oMLX 快 7x！ Ollama 每輪回應需 ~30s，oMLX 僅 ~4.3s。這是因為 Ollama 的端到端延遲包含了較高的 GGUF decode overhead，而 MLX 後端的 Metal kernel 調度更高效。
Ollama 獨有指標：Prefill 速度
Ollama 原生 API 提供 prompt_eval_count / prompt_eval_duration，可單獨量測 Prefill 速度：
| 測試 | Prompt tokens | Prefill tok/s |
|---|---|---|
| Short (19 tok) | 19 | 15.4 |
| Medium (32 tok) | 32 | 23.4 |
| Long (33 tok) | 33 | 25.1 |
| Code gen (40 tok) | 40 | 32.5 |
| System+User (64 tok) | 64 | 48.7 |
| Multi-turn T4 (378 tok) | 378 | 224.1 |
Ollama 的 prefill 速度隨 prompt 長度上升（batch parallelism），378 token 可達 224 tok/s。oMLX 不暴露此指標，但其整體延遲更低表明 prefill + decode 管線整合更優。
總結
┌─────────────────────┬──────────┬──────────┬──────────┐
│ 指標 │ oMLX │ Ollama │ 差距 │
├─────────────────────┼──────────┼──────────┼──────────┤
│ 平均生成速度 │ 41.6 t/s │ 30.9 t/s │ +35.0% │
│ 模型載入時間 │ 20.8s │ 27.0s │ -23% │
│ 多輪對話延遲 (avg) │ 4.37s │ 30.66s │ 7.0x 快 │
│ API 相容性 │ OpenAI+ │ OpenAI+ │ 平手 │
│ │ Anthropic│ 原生API │ │
│ SSD KV Cache │ ✅ │ ❌ │ oMLX 獨有│
│ Admin Dashboard │ ✅ │ ❌ │ oMLX 獨有│
│ 生態系統 / 社群大小 │ 小 │ 大 │ Ollama 勝│
│ 模型數量 / 格式支援 │ MLX only│ GGUF+多種│ Ollama 勝│
└─────────────────────┴──────────┴──────────┴──────────┘
結論：在 Apple Silicon 上跑 MLX 專用格式，oMLX 速度比 Ollama 快 35%，多輪對話延遲更是快 7 倍。如果你的主要平台是 Mac 且關注推理速度，oMLX 是更好的選擇。但 Ollama 的跨平台能力、社群規模、模型庫多樣性仍是其不可忽視的優勢。
9. 整體結論
- oMLX 41.6 tok/s vs Ollama 30.9 tok/s — MLX 原生格式在 Apple Silicon 上有顯著速度優勢
- 多輪對話場景差距更大（oMLX 4.3s vs Ollama 30.7s），適合 coding assistant / agent 使用
- oMLX 的 SSD KV Cache + Admin Dashboard 是差異化功能
- Ollama 的生態系統更成熟，模型選擇更多，跨平台更強
- 建議：Mac 上追求速度選 oMLX，需要跨平台或多格式模型選 Ollama，兩者可共存（但不能同時載入大模型）
- 後續可加測 Qwen3-Coder-Next 8bit（~80 GB，M2 Max 96GB 剛好可塞入）
10. 進階測試：SSD KV Cache A/B 比較
測試模型：Qwen3.5-35B-A3B-8bit | 每次生成 200 tokens
| 場景 | Cache ON (tok/s) | Cache OFF (tok/s) | 差異 |
|---|---|---|---|
| Cold（首次請求） | 28.5 | 33.3 | -14.4% ⚠️ |
| Warm（同 prompt 重送） | 37.0 | 32.7 | +13.1% ✅ |
| Hot（完全相同請求） | 35.2 | 33.3 | +5.7% ✅ |
| Partial（部分重複） | 35.7 | 32.3 | +10.5% ✅ |
| Short（50 tok） | 36.6 | 44.9 | -18.5% ⚠️ |
結論：SSD Cache 對 warm/hot/partial 場景有 5~13% 加速效果，但對 cold 和短請求反而略慢（cache lookup overhead）。多輪對話、coding assistant 等重複 context 場景適合開啟；一次性短查詢可考慮 --no-cache。
11. 進階測試：Concurrent Batching 併發能力
測試模型：Qwen3.5-35B-A3B-8bit | 每次 100 tok
| 併發數 | Wall Time | 聚合吞吐 (tok/s) | 擴展係數 | 狀態 |
|---|---|---|---|---|
| 1x | 4.41s | 22.7 | 1.00x | ✅ 正常 |
| 2x | 5.32s | 37.6 | 1.66x | ✅ 近線性 |
| 4x | 180s+ | ~2.2 | — | ❌ Timeout |
| 8x | 180s+ | ~4.4 | — | ❌ 500 errors |
結論：M2 Max 96 GB 跑 35B MoE 模型時，2 併發可獲得 1.66x 近線性加速，但 4x 以上會超出 Apple Silicon 的記憶體頻寬瓶頸。實務應用建議控制在 2~3 併發。
12. 進階測試：Tool Calling（函數呼叫）
測試模型：Qwen3.5-35B-A3B-8bit | 生物資訊工具定義
| 子測試 | 結果 | 延遲 | 說明 |
|---|---|---|---|
| 單一工具呼叫 | ✅ | 3.39s |
get_variant_info(BRCA1, p.Arg1699Gln) — JSON 格式正確 |
| 多工具呼叫 | ✅ | 4.99s | 同時呼叫 get_variant_info + calculate_frequency
|
| 完整 round-trip | ✅ | 6.95s | 工具結果回傳 → 模型摘要（308 字） |
結論：oMLX 的 tool calling 完全可用，支援 Qwen 格式的 function call 及 multi-tool。延遲在可接受範圍，可搭配 MCP / coding agent 使用。
13. 進階測試：社群排行榜上傳（官方 Benchmark）
透過 Admin Dashboard API
/admin/api/bench/start執行
| Prompt Length | Generation (tok/s) | Processing (tok/s) | TTFT (ms) |
|---|---|---|---|
| 1024 | 43.5 | 605.2 | 1,692 |
| 4096 | 47.9 | 699.3 | 5,857 |
| 8192 | 46.9 | 681.0 | 12,030 |
-
Bench ID:
bench-4d9315c888d1 - 預填充處理速度：605~699 tok/s（M2 Max 400 GB/s 頻寬的效益）
- Generation 穩定性：43.5~47.9 tok/s，比 chat API 的 41.6 tok/s 更高（benchmark 模式無網路 overhead）
- 已自動上傳至 omlx.ai 社群排行榜 ✅
14. 進階測試：VLM 多模態推論
模型：Qwen2.5-VL-3B-Instruct-4bit（2.9 GB）
| 測試 | 延遲 | 速度 (tok/s) | 說明 |
|---|---|---|---|
| 純文字 | 2.79s | 11.8 | 基線文字能力 |
| 影像描述 | 1.79s | 31.2 | Base64 PNG 色塊辨識 |
| 醫學/基因體情境 | 2.09s | 83.4 | 基因體圖表相關提問 |
| 結構化 JSON 擷取 | 1.53s | 85.4 | 從圖像提取 JSON 數據 |
結論：oMLX 的 Multi-Model Serving 可同時載入 LLM + VLM，無需重啟。3B VLM 在影像+文字組合下速度可達 85 tok/s，但視覺精準度受模型大小限制。適合輕量級圖表解讀 / QC 報告自動檢測等場景。
15. 極限測試：Qwen3-Coder-Next-4bit（42 GB）
目前 HuggingFace 上最大的 MLX 社群 Coder 模型之一（原始參數量推估 70B+，4-bit 量化）
硬體吃緊程度
| 指標 | 數值 |
|---|---|
| 模型大小 | 42 GB |
| 系統 RAM | 96 GB |
| 模型載入後剩餘 | ~0.6 GB free |
| RAM 使用率 | ~70%（含 OS + oMLX server） |
| SSD 剩餘 | ~18 GB（460 GB 中） |
效能實測
| 測試 | 延遲 | tokens | 速度 (tok/s) |
|---|---|---|---|
| 模型載入（cold start） | 14.4s | — | — |
| 短生成（100 tok） | 1.70s | 79 | 46.5 |
| 程式碼生成（VCF parser, 800 tok） | 12.56s | 680 | 54.2 |
| 長生成（500 tok） | 9.18s | 500 | 54.4 |
| 多輪 Turn 1（GC content） | 3.82s | 200 | 52.4 |
| 多輪 Turn 2（sliding window） | 8.01s | 400 | 50.0 |
| 多輪 Turn 3（pytest tests） | 11.13s | 500 | 44.9 |
程式碼品質
- ✅ VCFParser class — 結構完整，包含
__init__,parse(),filter_by_quality() - ✅ Type hints — 正確使用 Python type hints
- ✅ Pytest tests — 生成 5+ 測試案例，coverage 涵蓋 edge cases
- ✅ 多輪連貫性 — 3 輪對話能正確延續 context，逐步增強程式碼
與 Qwen3.5-35B MoE 比較
| 指標 | Qwen3.5-35B-A3B-8bit | Qwen3-Coder-Next-4bit | 差異 |
|---|---|---|---|
| 模型大小 | 35 GB | 42 GB | +20% |
| 平均生成速度 | 41.6 tok/s | 51.7 tok/s | +24% |
| 多輪平均速度 | — | 49.1 tok/s | — |
| 載入時間 | ~7s | 14.4s | +106% |
| 程式碼品質 | 通用型 | Coder 專精 | — |
結論：Qwen3-Coder-Next-4bit 雖然是 42 GB 巨型模型，在 M2 Max 96 GB 上依然能 穩定跑出 51.7 tok/s，甚至比 35 GB MoE 模型更快（4-bit 量化的矩陣運算效率更高）。Cold start 14.4 秒可接受。但 RAM 幾乎被吃光（僅剩 0.6 GB free），不建議同時開其他大型應用程式。
如果你有 96 GB+ Apple Silicon 且主要用途是 coding，這個模型是極佳選擇：51.7 tok/s 的本地 Coder 模型，完全離線，零成本。
16. 六項進階測試總結
| # | 測試項目 | 關鍵發現 | 推薦程度 |
|---|---|---|---|
| 1 | SSD Cache A/B | warm/hot +5~13%，cold 略慢 | ⭐⭐⭐⭐ 對話場景開啟 |
| 2 | Concurrent Batching | 2x 近線性，4x+ 崩潰 | ⭐⭐⭐ 控制 2~3 併發 |
| 3 | Tool Calling | 3/3 測試通過，延遲 <7s | ⭐⭐⭐⭐⭐ 完全可用 |
| 4 | 官方 Benchmark | gen 43~48 tok/s，已上傳排行榜 | ⭐⭐⭐⭐⭐ 公開驗證 |
| 5 | VLM 多模態 | 3B 模型 85 tok/s，精度受限 | ⭐⭐⭐ 輕量用途 |
| 6 | Coder-Next 極限 | 51.7 tok/s，RAM 幾乎滿載 | ⭐⭐⭐⭐⭐ Coding 神器 |
整體結論：oMLX v0.2.7 在 Mac Studio M2 Max 96 GB 上展現了出色的完整性——從 SSD Cache、多併發、Tool Calling、VLM 到極端大模型，都能穩定運作。最亮眼的是 Qwen3-Coder-Next-4bit 跑出 51.7 tok/s，驗證了 Apple Silicon + MLX 的上限極具潛力。
17. Coder-Next 深度測試：HumanEval Pass@1
使用 OpenAI HumanEval benchmark（164 題 Python coding problems），temperature=0, Pass@1
| 指標 | Qwen3-Coder-Next-4bit |
|---|---|
| Pass@1 | 150/164 = 91.5% |
| 平均延遲 | 5.0s / 題 |
| 總耗時 | ~14 分鐘 |
進度曲線
| 區間 | 累計通過率 |
|---|---|
| 1-20 | 95.0% |
| 1-40 | 95.0% |
| 1-60 | 95.0% |
| 1-80 | 93.8% |
| 1-100 | 93.0% |
| 1-120 | 94.2% |
| 1-140 | 92.1% |
| 1-164 | 91.5% |
結論：91.5% Pass@1 對一個 42 GB 4-bit 本地量化模型來說非常出色。作為參考，GPT-4 的 HumanEval Pass@1 約為 67%（2023），Claude 3.5 Sonnet 約為 92%（2024）。Qwen3-Coder-Next-4bit 在本地離線環境下達到了與頂級雲端模型相當的程式碼生成能力。
18. Coder-Next 深度測試：Thinking Mode（內部推理）
Qwen3 系列支援
/think和/no_think控制內部推理鏈。測試 30 題 HumanEval subset。
| 模式 | 通過/總題 | Pass Rate | 平均延遲 |
|---|---|---|---|
Thinking OFF (/no_think) |
25/30 | 83.3% | 4.4s |
Thinking ON (/think) |
26/30 | 86.7% | 4.8s |
| 差異 | +1 | +3.3% | +0.4s |
逐題對比（僅列差異題）
| 題目 | OFF | ON | 說明 |
|---|---|---|---|
| HumanEval/10 | ❌ | ✅ | Thinking 修正了 palindrome 邏輯 |
| HumanEval/50 | ❌ | ✅ | Thinking 修正了 encode_shift |
| HumanEval/65 | ✅ | ❌ | Thinking 過度思考反而出錯 |
結論：Thinking Mode 帶來 +3.3% 準確率提升，延遲增加僅 +0.4s（微乎其微）。在較困難的題目中 Thinking 能幫助修正邏輯錯誤，但偶爾會過度推理。建議在複雜程式任務中開啟 Thinking Mode。
19. 模型對比：Coder-Next vs Qwen3.5-35B MoE
同樣 30 題 HumanEval，相同 system prompt 和 extraction 邏輯
| 指標 | Qwen3-Coder-Next-4bit | Qwen3.5-35B-A3B-8bit | 差異 |
|---|---|---|---|
| Pass@1 (30 題) | 83.3% | 56.7% | +26.6% |
| 平均延遲 | 4.4s | 18.4s | 4.2x 更快 |
| 模型大小 | 42 GB | 35 GB | +20% |
| 量化 | 4-bit | 8-bit | — |
分析
- Coder-Next 在程式碼生成勝出 +26.6 個百分點，這是 coding-specific fine-tuning 的明確效益
- Qwen3.5-35B 作為通用型 MoE 模型，程式碼輸出較冗長（容易混入解釋文字），提取困難度較高
- Coder-Next 延遲僅 4.4s vs MoE 18.4s（4.2 倍差距），4-bit 量化的矩陣運算更高效
- MoE 模型的優勢在多領域通用推理，Coder 模型的優勢在程式碼精準度
結論：如果主要用途是 coding（code completion / generation / review），Coder-Next 在速度和準確度都大幅勝過通用 MoE 模型。但在需要多領域知識的綜合推理場景，Qwen3.5-35B 仍有其價值。
20. Coder-Next 深度測試：長 Context 程式碼理解
輸入 500 行真實 Python 程式碼（
nsight_gpu_profiling_test.py），測試 4 種理解能力
| 測試 | 延遲 | 輸出 tokens | 回答品質 |
|---|---|---|---|
| Q1 架構總覽 | 45.4s | 500 | ✅ 正確辨識 phase-based 架構、NVTX range nesting |
| Q2 Bug/問題分析 | 12.3s | 500 | ✅ 發現 silent failure、missing error handling |
Q3 函數深度解析 (phase_env) |
10.6s | 400 | ✅ 正確描述 GPU warmup 和 env detection 邏輯 |
| Q4 重構建議 | 18.6s | 800 | ✅ 建議 NVTX context manager、config class、retry decorator |
- 總輸出：2,200 tokens，平均 21.7s/問
- 4/4 問題全部正確回答，且能引用具體函數名和程式邏輯
- 500 行 Python 輸入（估計 ~8,000 tokens）完全在 context window 內
結論：Coder-Next 對 500 行真實程式碼的理解能力極佳。能正確分析架構、找出潛在問題、深入解釋函數邏輯、並提出有建設性的重構建議。非常適合作為本地 code review / code understanding 工具。
21. 四項深度測試總結
| # | 測試 | 關鍵數據 | 結論 |
|---|---|---|---|
| 1 | HumanEval Pass@1 | 91.5%（164 題） | 接近 Claude 3.5 Sonnet 水準 |
| 2 | Thinking Mode | OFF 83.3% → ON 86.7% (+3.3%) | 複雜題目建議開啟 |
| 3 | vs MoE 對比 | Coder 83.3% vs MoE 56.7%，速度快 4.2x | Coding 場景完勝 |
| 4 | 長 Context | 500 行 4/4 全答對，avg 21.7s | Code review 好幫手 |
最終評價：Qwen3-Coder-Next-4bit 在 Apple Silicon M2 Max 96 GB 上，以 51.7 tok/s 的生成速度 + 91.5% HumanEval Pass@1，展現了驚人的本地 coding 能力。搭配 oMLX 的 SSD Cache 和 Tool Calling，完全可以作為離線、零成本的 coding assistant。
報告更新：2026-03-12 | oMLX v0.2.7 | Mac Studio M2 Max 96GB | Coder-Next 四項深度測試完成
Top comments (0)