Mac 本地 AI 怎麼選？M5、M6 的記憶體、頻寬與 Agent 效能

by Rain Chu | 9 月 8, 2026 | Agent, AI, Apple, Mac, 程式開發

買 Mac 跑本地 AI，我會先考慮以下三件事：

模型能不能放進記憶體，送出長篇資料後要等多久，以及開始回答後每秒能生成多少 token。這三件事分別牽涉容量、運算能力與記憶體頻寬，不能只看晶片名稱裡的數字。

同一台電腦，短問短答很順，換成讀程式碼、查工具、反覆執行任務的 Agent 卻很慢，並不矛盾。

聊天介面讓你注意到的是持續輸出的速度，Agent 更容易暴露長輸入、多輪推理與工具等待的成本。

模型載入成功，只代表跨過容量門檻，還不代表這台機器適合你的工作流。

本文於 2026 年 9 月 6 日核對規格。Apple 已公布新款 Mac mini 與 Mac Studio，官方標示 9 月 22 日開始供貨。以下會把官方規格、推理原理與選購判斷分開，未取得的新機實測不會用推估值冒充。供貨資訊可查 Mac mini 公告與 Mac Studio 官網。

先分清 Prefill 與 Decode，才知道慢在哪裡

Prefill，預填充，是模型處理輸入內容、建立後續推理狀態的階段，系統提示詞、聊天記錄、工具定義、檢索文件與程式碼都可能算進輸入，並非只有你剛打的那一句話。長輸入通常有較大的矩陣運算需求。

Decode，解碼生成，則是在已有上下文狀態上逐步產生 token，單一請求、低批次的生成常受記憶體資料搬運限制，所以記憶體頻寬很重要，Token 不是固定的一個中文字，不能把 tokens/s 直接當成每秒中文字數。

觀察體感時，我會同時記錄 TTFT，也就是送出後到第一個 token 的時間，以及生成階段的 tokens/s，TTFT 還可能包含排隊、模型載入與服務端處理，不能把所有等待都歸因於 Prefill，Apple 的 MLX 與 M5 技術說明也分別討論提示詞處理與生成效能，兩個階段應分開比較。

記憶體容量，是門票而不是速度保證

Apple Silicon 的 CPU 與 GPU 共用統一記憶體，跑較大模型時不必完全受限於一張獨立顯示卡的顯存容量，在這規格表上的 32GB 或 128GB 並不等於模型可以獨占同樣的空間，macOS、瀏覽器、開發工具、KV cache 和推理暫存都需要預算。

估算可以從權重開始：參數數量乘上每個參數的位元數，再除以 8，以約 27B 參數、理想化 4-bit 權重計算，純權重約 13.5GB，這只是十進位容量的粗估，還沒加入量化分組資訊、部分高精度權重與執行時開銷。

32GB 能否跑某個 27B 模型，答案是「有機會，但要指定量化檔、上下文長度與框架」。只拿 27B 這個名字，無法保證長上下文與多 Agent 都順暢。先核對實際模型檔大小，再測一個完整任務，會比只看成功載入的畫面更有用。

如果想先理解不同推理工具的定位，可以參考 MLX、llama.cpp、Ollama 與其他本地推理框架比較，格式、核心實作與快取策略都會影響同一台硬體的表現。

記憶體頻寬，影響持續輸出但不是萬用答案

可以把容量想成能放多少資料，頻寬則是每秒能把多少資料送到運算單元。當低批次生成需要反覆讀取大量權重，而硬體運算能力足夠時，頻寬往往成為主要限制。

但「頻寬加倍，速度就一定加倍」只適合當理想化的直覺，實際還有量化解碼、注意力、KV cache 存取、核心效率、批次大小與模型架構，MoE 也不是每個 token 都動用全部專家權重，所以不能把所有模型都套進同一條簡單公式。

M5、M6 規格怎麼看，先看配置再看名稱

以下整理 Mac mini 技術規格與 Mac Studio 技術規格中，和本地模型最直接相關的容量與頻寬。這是規格對照，不是速度排名，也不是實測 tokens/s。

M5 Max 的 32 核心與 40 核心 GPU 版本不只差核心數，頻寬與可選記憶體也不同，M5 Ultra 的 256GB、512GB 選項綁定更高階晶片配置，升級容量的成本可能同時包含晶片升級。選購時應核對最後的完整配置，不要把某個系列的最高值套到入門款。

供貨時間也要分開看。依 Apple 台灣的新款 Mac Studio 公告，一般配置自 9 月 22 日起供貨，512GB 統一記憶體配置則預計 10 月底推出，需要立即交付工作的團隊，應再確認實際可下單配置與交貨日期。

跑 Agent 為什麼更容易卡在等待

一個程式碼 Agent 可能先讀專案規則，再讀檔案，接著呼叫工具，最後把工具輸出帶回模型繼續判斷，每一輪都可能增加輸入，輸出卻只有一小段指令，讓「先讀懂，再動作」的成本更加明顯。

「每開一個子代理，就一定完整重算一次全部上下文」並不精確，是否能重用相同前綴，取決於服務端的 prompt cache、請求路由、模型支援與上下文是否一致，MLX LM 官方專案就提供 prompt caching 功能，實際 Agent 框架有沒有用到，仍要另外確認。

• 把長期不變的規則放在穩定前綴，減少每輪重新排列內容
• 只提供當前任務需要的檔案與工具，避免把整個專案一次塞進提示詞
• 先測單 Agent，再逐步增加並行數，觀察排隊與記憶體壓力
• 同時記錄模型等待、工具執行與重試時間，避免把外部服務延遲算到 GPU 頭上

如果任務需要很長的推理輸出，Decode 仍可能占大部分時間，真正值得比較的是完成同一項工作要多久、成功率如何，而不只是某個階段的峰值數字。選擇 Agent 模型與本機部署方式時，也應把工具呼叫品質一起放進評估。

M5 的加速器，要配合軟體才能發揮

M5 GPU 的 Neural Accelerators 是 GPU 內的矩陣運算加速能力，不應和晶片上另一個 Neural Engine 混為一談，對長輸入這類運算密集的工作，支援相應路徑的框架與核心可以帶來收益。

買到新晶片不代表任何模型、量化格式和舊版工具都會自動得到相同比例的加速，我會連同 macOS、MLX 或 llama.cpp 的版本一起記錄，並查看執行時使用的後端。Apple 早期公布的 M5 測試可以用來理解方向，但不能直接當成新款 M6 或 M5 Ultra 的實測成績。

MoE 為什麼值得看，但不能只看啟用參數

Mixture of Experts，混合專家模型，會依 token 選用部分專家，降低每步需要參與計算的參數量，它讓「保存很多知識容量」和「每一步動用多少運算」有機會分開，這和大容量統一記憶體的特性很搭。

以 Qwen 官方的 Qwen3-30B-A3B為例，30B 指總參數量，3B 指啟用參數量，不能因為看到 A3B，就用一個 3B 稠密模型的記憶體需求來估算，通常仍要保存更大的整體權重。這是用來解釋命名與架構的例子，不代表它是目前唯一或最適合的選擇。

MoE 的速度還受專家路由、量化、核心最佳化與批次大小影響，也不保證同樣容量下的工具使用品質一定勝過稠密模型，我的做法是準備一組真實任務，用完成品質與總耗時一起決定。

三種使用情境，我會這樣安排預算

主要使用雲端 AI，優先顧好日常工作

如果主要運算都在雲端，Mac 更多是在跑瀏覽器、編輯器與本地工具，無須只為遠端模型購買超大記憶體。16GB 到 32GB 可以作為一般工作起點，但大型專案編譯、虛擬機與剪輯仍可能需要更多。這是用途判斷，不是所有人的最低規格。

本地聊天、寫程式與剪輯混用，先看 48GB 到 128GB 的實際需求

先列出最常用的兩三個模型，再加上平常同時開啟的軟體。M5 Pro 和 M5 Max 各有不同容量與頻寬選項，能否容納模型加上真實工作環境，比只追求最大 GPU 核心數更重要。若以 Agent 為主，要優先找長提示詞與連續工具呼叫測試，而不是只看短聊天跑分。

目標是超大模型，再考慮 Ultra 與多機

當權重、長上下文或多請求確實超出較小容量，才有充分理由看 256GB、512GB 或分散式部署。先問自己是否需要那個模型能力，以及它能否在可接受時間內完成任務，不要為了「裝得下最大模型」而買一台長期等待的電腦。

AI 生圖與生影片，要另做一份評估

剪輯影片和用生成模型產生影片，是不同的運算工作，ProRes 編解碼能力強，不能直接推論擴散模型也會很快。ComfyUI 官方支援 Apple Silicon，但你的模型、量化與自訂節點是否支援 Mac，以及完整生成一段內容要多久，仍需逐項確認。

若主要目的是高頻率生影片，我會拿實際工作流比較 NVIDIA GPU、本地 Mac 與雲端方案，再把等待時間與每次產出的成本算進去。可從 LTX 2.3 的 ComfyUI 影音工作流理解需要核對哪些模型與節點，不應只拿文字模型的速度替影音生成下結論。

不過可以肯定的是現在要生圖還是首選 Nvidia 畢竟 pyTouch 還沒有完整支援 MAC

DGX Spark 加 Mac Studio，是分工不是魔法加總

EXO 的異質推理示範把 Prefill 放在 DGX Spark，再把 KV cache 傳給 Mac Studio 進行 Decode，並透過逐層傳輸，讓通訊與運算時間部分重疊。這說明不同硬體可以各做擅長的階段。

但 EXO 示範的是特定模型、輸入長度、硬體與網路，不能外推成任何組合都會同倍率變快。兩台 256GB 也不必然優於一台 512GB，模型如何分片、互連頻寬、框架支援與並行方式都會改變結果。多機還增加設定與維護成本，應以整個任務的實測決定。

對多機部署有興趣，可以接著看 雙機 EdgeXpert 與大模型工作負載，把單機容量、網路傳輸和軟體支援一起考慮。

購買前怎麼測，至少分開短提示詞與長提示詞

請測試者提供完整模型名稱、量化檔、框架版本、系統版本、上下文長度與 GPU 配置，相同模型換一種量化，或把長輸入改成一句問候，都足以改變結果。

已有 llama.cpp 與本地 GGUF 模型時，可參照 llama-bench 官方說明使用下列命令。把路徑改成自己已下載的模型，這裡的參數是測試設定，不是我在新機上測出的數字。

llama-bench -m /absolute/path/model.gguf -p 512,8192 -n 128 -r 3 -o json

這會分別測試不同長度的 prompt processing 與文字生成，輸出中的 pp 與 tg 對應不同階段。合成測試適合比較核心效能，不能直接當成真實 Agent 的 TTFT 或任務總耗時。還要補一輪實際工具呼叫流程，並分別記錄冷啟動、快取命中和未命中的狀態。

• 同一份短問答，觀察穩定生成速度
• 同一份長文件，觀察首個 token 等待時間
• 同一個修改程式任務，觀察工具呼叫與完成率
• 同樣的並行數，觀察尖峰記憶體、swap 與排隊
• 若要生圖或生影片，使用完全相同的模型、尺寸、步數與節點

FAQ

32GB Mac 可以跑 27B 模型嗎

部分量化版本有機會，但要加上 KV cache、推理暫存、macOS 與其他程式的需求。能載入不等於長上下文或多 Agent 都能流暢使用。

M6 一定比 M5 Max 適合本地 AI 嗎

不一定。要比較完整配置的容量、頻寬、運算後端與實際工作負載，不能只用世代數字排序。

為什麼聊天很快，Agent 卻很慢

Agent 可能反覆處理長上下文並等待工具，瓶頸不只在生成速度。應同時檢查 Prefill、快取、排隊、工具時間與任務重試。

MoE 的啟用參數少，記憶體也只要那麼少嗎

不是。啟用參數主要描述每步參與計算的部分，通常仍要保存全部專家權重，容量估算不能只看 A 後面的數字。

我的選購順序：先定工作，再定模型，最後選配置

先確定主要工作是在雲端還是本地，再決定模型與上下文需求。容量不足先解決容量，等待第一個字太久就看輸入處理與快取，開始輸出後仍然慢才進一步比較頻寬與生成核心。用這個順序選 M5、M6 或 Ultra，比追規格表上最大的數字更能把錢花在真正的瓶頸上。