返回首頁

本機推論

M4 Max 本機 LLM 實測:解碼快於 GB10,但完整回應仍受 prefill 制約

新一輪同價位本機 AI 測試顯示,M4 Max 憑 546GB/s 統一記憶體頻寬,在三款量化模型的逐 token 解碼領先 GB10 與 Strix Halo。GB10 的 prompt prefill 與整體能效仍佔優,單看 tokens/s 會錯估實際回應時間。

极客湾Geekerwan · CC BY 3.0 · Image source
zh-Hant

Tom’s Hardware 7 月 30 日以 `llama.cpp` 比較 Apple M4 Max、Nvidia GB10 與 AMD Ryzen AI Max+ 395,測試 Qwen 3.6-35B-A3B、Gemma 4 12B 及 gpt-oss-120b 的四位元量化版本。受測 Mac Studio 配備 40 核心 GPU、128GB 統一記憶體與 546GB/s 頻寬;測試時價格約 3,699 美元,接近 DGX Spark 的 3,999 美元建議售價,因此比單純比較晶片規格更貼近桌面部署選型。

結果揭示本機 LLM 的兩個瓶頸不能混為一談。Prefill 要平行處理整段提示,運算吞吐、核心與軟體核心最佳化較重要;decode 則逐 token 依序通過模型各層,需反覆從記憶體串流權重,通常更受頻寬限制。M4 Max 在三款模型、不同上下文深度的解碼吞吐均領先另外兩台機器,Qwen MoE 的優勢尤其明顯;但 GB10 在 prompt processing 明顯更快。以 gpt-oss-120b、2,048-token 輸入及 1,024-token 輸出測量完整工作負載時,GB10 因較快完成 prefill,總耗時與耗電反而優於 M4 Max。

這項結果對 RAG、程式代理與長上下文服務尤其重要。短提示、長輸出的聊天工作負載可能偏好高頻寬平台;需要反覆讀取大型程式庫、文件或多輪壓縮歷史的代理,prefill 速度與 KV cache 成長則可能主導延遲。工程團隊應同時量測 time-to-first-token、decode throughput、完整回合耗時、功耗及可容納模型大小,而不是用單一 tok/s 排名採購。限制是這仍是一組媒體自測,量化檔、`llama.cpp` commit、Metal/CUDA 最佳化程度與可用記憶體配置都會改變結果;Apple 目前販售的 M4 Max 記憶體選項也未必與受測 128GB 機器一致。

來源

  1. Exploring Apple Silicon’s local AI performance with the Mac Studio and M4 Max
  2. Performance of llama.cpp on NVIDIA DGX Spark
  3. Run models with llama.cpp on DGX Spark