Mac Studio M5 Max 128GB 和 Qwen3.8 Flash-Next的一些測試
-
-
-
最近在剛到手的Mac Studio M5 Max 128GB 上測 Qwen3.8 Flash-Next，主要用途是 Hermes / coding agent，所以我比較在意的不是單純短 prompt 的最高 tok/s，而是長 context、prefill、decode、tool calling，以及實際 agent workload 下的穩定性。
這幾天剛好完成一輪 MTPLX Optimized-Speed 和 uncensored oQ5e 的測試，整理一些數據供參考。
這不是嚴格的模型能力 benchmark，主要是記錄同一台機器上不同 runtime / quant 的實際表現。
測試環境
硬體：
- Mac Studio M5 Max
- 128GB unified memory
目前比較的兩套配置：
MTPLX Optimized-Speed
Qwen3.8-Flash-Next- context：131072
- MTP depth：3
- 目前日用 baseline
Uncensored oQ5e
mlx-community/Qwen3.8-Flash-Next-Uncensored-oQ5e-mtpruntime：
oMLX 0.7.0.dev2- context：131072
- concurrency：1
- MTP OFF / ON 都有測試
- native model memory 約 94.65GB
所有長 context 測試都有實際檢查答案或 tool arguments，不是只確認 HTTP 200。
oQ5e MTP OFF 長 context
Case Prompt / completion Wall time Result 32K retrieval 32704 / 18 26.90s PASS 64K retrieval 65472 / 18 43.75s PASS 128K retrieval 131007 / 18 102.69s PASS Near-128K tool 130862 / 44 103.41s PASS 15K assistant-less tool history 15131 / 57 14.07s PASS 第二次 128K retrieval 與 near-128K tool case 都是 0 cached prompt tokens。
Near-128K tool call 最後正確回傳：
report_probe(value=7)所以至少在這台機器與這個 runtime 上，oQ5e 的 128K retrieval / tool calling 本身沒有出現明顯 correctness 問題。
MTPLX Optimized-Speed 128K
這次也順便補了之前沒有正式測過的 MTPLX 128K。
128K retrieval
- prompt：131007 tokens
- completion：19
- wall time：70.80s
- TTFT：69.30s
- prefill：1900.4 tok/s
- decode：49.36 tok/s
- correctness：PASS
Near-128K structured tool call
- prompt：約 130.9K
- completion：26
- wall time：74.51s
- prefill：1816.4 tok/s
- decode：54.81 tok/s
- tool call：PASS
相同級別的 near-128K tool workload，oQ5e MTP OFF 是 103.41s。
Optimized-Speed 的長 context 表現蠻讓人驚訝的，至少 128K 下的 prefill 仍維持約 1.8K～1.9K tok/s。
oQ5e + Lightning MTP
其中 near-128K tool case 的 native log：
- accepted drafts：29 / 29
- acceptance：100%
- tokens / cycle：2.81
- depth 1：13 / 13
- depth 2：12 / 12
- depth 3：4 / 4
但實際 matched wall time：
MTP OFF MTP ON Near-128K tool 103.41s 104.39s Result PASS PASS MTP ON 反而慢約 0.9%。
另外 32K / 128K retrieval 的 MTP ON 測試有大量 prompt cache，因此沒有拿那些數字當成有效的 MTP speedup 證據。
檢查 oMLX native log 後，找到：
Qwen4-Exp PLE forced to SSDruntime 顯示：
- estimated resident requirement：135.0GB
- memory ceiling：115.4GB
- mmap model：約 94.7GB
所以 PLE 沒辦法完整 resident。
oMLX 同時警告：
Decode will be roughly 2.5x slower than a resident load.應該就是 MTP 的 draft acceptance 還滿好的，但實際 wall-time 沒什麼變化
目前的使用定位
MTPLX Optimized-Speed
目前繼續當 daily baseline。
128K 實測大約：
- prefill：1800～1900 tok/s
- decode：50～55 tok/s
- retrieval：PASS
- structured tool calling：PASS
Uncensored oQ5e
uncensored 內容專屬
目前已確認：
- 32K PASS
- 64K PASS
- 128K PASS
- near-128K tool PASS
- assistant-less tool history PASS
但在 128GB unified memory 上，約 95GB model memory 加上 PLE SSD offload，整體資源壓力與長 context latency 都比較高。
oQ5e + Lightning MTP
不打算作為 daily 配置。開MTP也沒有明顯好處
正在測的版本：mixed 4/8 + mlx-serve
去審查當然要又準又快啊
ARC4NUM/Qwen3.8-Flash-Next-Uncensored-MLX-Serve-4bit這個版本我對比了一陣子，4bit本身會快一點 ，另外 precision allocation：
- routed experts：4-bit
- attention / shared expert / GDN 等：8-bit
- router / gate / 1D tensors：BF16
- MTP 保留
- n-gram / PLE：4-bit mmap
- runtime：mlx-serve
作者在 M5 Max 128GB 上公布的數據約：
- serial：55.7 tok/s
- MTP：60.3 tok/s
- resident memory：約 68GB
如果實際 RAM占用真的落在 68～70GB 左右，我認為這對 128GB Mac 的意義比單純多幾個 tok/s 還大。
因為這代表除了模型本身之外，還能留更多 unified memory 給：
- KV cache
- Hermes
- ASR
- JEV(每天都有新的超熱鬧...)
- 其他 agent / local services
262K context 也可能因此比目前的 Q5 更實際。
下一輪預計測：
- raw decode
- MTP OFF / ON
- 128K retrieval
- near-128K structured tool calling
- 約 256K retrieval
- resident memory / swap
- 實際 coding / agent task
如果有人也在 M5 Max 128GB 上跑過這個 ARC4NUM mixed 4/8 + mlx-serve 版本，也很歡迎分享 prefill、decode、RAM 使用量，以及長 context / tool calling 的實際表現。
-
-
-
M4 Max 128GB / MLX / Qwen3-30B-A3B-4bit Benchmark
测试环境
- 芯片：Apple M4 Max
- 统一内存：128GB
- Runtime：MLX /
mlx_lm.server - 模型：
mlx-community/Qwen3-30B-A3B-4bit - API：OpenAI-compatible API
- 测试 Context：8K / 32K / 64K / 128K
- 最大输出：512 tokens
- 输出统计：Qwen3
reasoning+content - Prefill 计算方式：
Prompt Tokens / TTFT
注意：这里的 Prefill 是根据端到端 TTFT 计算的近似值，包含 API / Server 等额外开销，并非 MLX runtime 内部的纯 prompt-processing throughput。
Benchmark Results
Context Prompt Tokens Server Prompt Tokens TTFT Approx. Prefill Output Tokens Decode Time Decode 8K 8,000 8,015 6.560 s 1,219.5 tok/s 328 4.316 s 75.8 tok/s 32K 32,000 32,016 46.180 s 692.9 tok/s 332 7.937 s 41.7 tok/s 64K 64,000 64,016 137.716 s 464.7 tok/s 429 21.786 s 19.6 tok/s 128K 128,000 128,016 575.329 s 222.5 tok/s 512 41.661 s 12.3 tok/s Raw Results
8K Prompt tokens : 8,000 Server prompt : 8,015 TTFT : 6.560 s Approx prefill : 1,219.5 tok/s Output tokens : 328 Decode time : 4.316 s Decode : 75.8 tok/s 32K Prompt tokens : 32,000 Server prompt : 32,016 TTFT : 46.180 s Approx prefill : 692.9 tok/s Output tokens : 332 Decode time : 7.937 s Decode : 41.7 tok/s 64K Prompt tokens : 64,000 Server prompt : 64,016 TTFT : 137.716 s Approx prefill : 464.7 tok/s Output tokens : 429 Decode time : 21.786 s Decode : 19.6 tok/s 128K Prompt tokens : 128,000 Server prompt : 128,016 TTFT : 575.329 s Approx prefill : 222.5 tok/s Output tokens : 512 Decode time : 41.661 s Decode : 12.3 tok/s -
-
-
-
@fanweng-code 这套配置下来得4万块人民币吧， 感觉还是太贵了， 性价比这块还是要皱皱眉头。
@johnnybegood
是有點貴啦，但想想硬體漲價的速度，現在可能還是最低點 -
性价比不高呀，还是nv卡合适
@Nina-Chowdhry
看你要怎麼做取捨了，我有另外一台PC用來處理建模跟渲染，全速運轉時兩台的音量有天壤之別，MAC studio幾乎沒有聲音使用起來的體驗真的是非常好。 -
更新一下前面提到的
ARC4NUM/Qwen3.8-Flash-Next-Uncensored-MLX-Serve-4bit。目前已經測完，結果不錯，現在它已經取代 MTPLX Optimized-Speed，成為我日常 Hermes / coding agent 的主力模型。
環境：
- Mac Studio M5 Max 128GB
- mlx-serve 26.9.5
- context：262144
- MTP：depth 6
- uncensored mixed 4/8-bit
簡單整理實測結果：
項目 結果 Serial decode 65.24 tok/s MTP decode 154.23 tok/s 128K retrieval PASS near-128K tool call PASS 251K retrieval PASS 128K prefill ~2165 tok/s 251K prefill ~2128 tok/s 154 tok/s 是短 decode isolation、MTP acceptance 很高時的結果，但大多時候MTP都能維持在3左右；目前確認這版的 MTP 確實有很明顯的實際加速。
我自己比較在意的是長 context。
251K prompt 下 retrieval 仍然正確，prefill 還維持在約 2.1K tok/s，而且測試期間沒有看到 swap 增長或明顯 memory pressure。
另外這顆相較之前測的 uncensored oQ5e，最大的優勢其實是記憶體餘裕比較大。
runtime 對 weights 的估計約 70GB 級，而 Q5 先前光 model memory 就接近 95GB，甚至因為 PLE 無法完整 resident 被迫 SSD offload。
對 128GB Mac 來說，這差異滿重要。
因為我不只想跑一顆主模型，之後還會同時放一些 JEV-like / router / verifier / ASR 之類的輔助模型。主模型少吃二、三十 GB unified memory，整套 Agent system 就好配置很多。
Apple Silicon 這邊還有另一個優勢：小型輔助模型如果有合適的 Core ML / ANE runtime，可以把部分計算放到 ANE，不必全部跟主 LLM 搶 GPU compute。當然權重還是會占 unified memory，但至少 compute 資源可以分流。
目前我的配置方向大概就是：
ARC4NUM mixed 4/8 + mlx-serve + MTP
→ 主 LLM / HermesJEV-like / ASR / classifier
→ 小模型，能走 ANE 的盡量走 ANE這也是我最後決定留下 mixed 4/8，而不是追更高 bit quant 的主要原因：對我來說，整台 Mac 能同時跑多少個有用的元件，比單顆模型多一點 benchmark 分數更重要。
目前實際 coding / agent 使用也沒有遇到明顯問題，所以先把它當主力繼續用。
如果後續長任務、tool calling 或 200K+ context 出現新的問題，我再回來更新。
-
，系统 取消固定了此主题
-
