Mac 跑 agent 的瓶頸，大部分人搞錯方向了
一開始也是那種感覺：「咦我的 token/s 看起來還好，但為什麼 agent 跑到一半感覺一直在等？」
後來才搞懂，問題根本不在 generation speed。
玩過 agent 的人應該都有這個經驗：單輪問答很快，但 context 一疊起來，每次呼叫前都有一段明顯的等待時間。那段等待就是 prompt processing，也就是把整個 context 重新算一遍。generation 只佔回應時間一部分，那段空白才是大頭。
Mac 的問題在這裡很明顯。unified memory bandwidth 再厲害，一個 7B 模型 8-bit quantization、context 塞到 8k token 以上，prefill 就開始讓你有感了。如果是 32k context 跑 agent loop，每次 tool call 後都要重新 prefill，那個 latency 對即時性場景根本扛不住。
我自己跑過一個測試：同一個 agent task，context 大概 6k token，在 M2 Pro 16GB 上，每次呼叫的 prompt processing 大概要 3-5 秒，generation 反而只要 2 秒不到。也就是說，generation 速度就算再快 50% 對整體體驗根本沒差，瓶頸根本不在那邊。
這讓我重新想了一下本地跟雲端的取捨。
很多人選本地是因為「快」或「省錢」。但如果 agent 場景的主要瓶頸是 prompt processing，那台機器再貴也沒辦法，因為 bandwidth 就是上限。換成 Claude Sonnet 或 GPT-4o 的 API，不只沒有這個問題，latency 很多時候還更短，long context 任務每次 API call 的成本可能比跑本地的電費還值得算。
當然隱私敏感的東西本地是唯一選項，這個沒得爭。但如果只是單純覺得「本地比較快省」，agent 場景這個假設大概率是錯的。
說來有點虧，我當初買機器的原因之一就是「要跑本地模型」。隱私需求是真，但「速度省錢」這個 justification 在 agent 場景根本撐不住。
所以如果你現在也在考慮要加記憶體還是直接用 API，先弄清楚你的 agent 主要 bottleneck 在哪。如果是 prompt processing，加記憶體沒差，因為那是 bandwidth 問題不是 memory size 問題。
去 Activity Monitor 看一下，再看看每次呼叫的實際 latency 分佈，搞清楚卡在哪再決定。
作者：島民No.9527