企業部署 AI 代理時，真正吃掉時間的未必只有模型推論。代理會規劃下一步、呼叫搜尋或程式工具、交換狀態，再把結果送回模型；一次使用者請求因此變成橫跨 CPU、GPU、記憶體與外部服務的動態工作流。這正是 Microsoft Azure 與德州大學奧斯汀分校研究團隊認為，既有「以 GPU 為中心」伺服器設計需要重新檢討的原因。
從單次推論，變成反覆切換的執行圖
來源事實：Network World 報導指出，研究團隊分析 Azure 生產環境遙測，並以開源代理框架進行受控實驗，發現代理請求會在模型推論、工具探索、工具執行與協調邏輯之間反覆切換。報導原文：https://www.networkworld.com/article/4206611/agentic-ai-could-force-a-rethink-of-enterprise-ai-server-design-researchers-say.html
研究團隊公開的 arXiv 預印本進一步交代方法：生產研究採集 24 小時的代理請求軌跡；受控實驗則涵蓋 SWE-Agent、Trae、CORAL 與 Owl 四種框架，使用一台配備 96 核心 AMD EPYC 7V12 與八張 NVIDIA A100 的伺服器，並把並行任務數由 1 提高至 32。論文全文：https://arxiv.org/html/2608.04458
這種負載與聊天機器人的差別，不只是「多呼叫幾次模型」。CORAL 的一次受控執行展開為 580 次 LLM 呼叫與 552 次工具呼叫，CPU 與 GPU 間來回切換數百次；在生產軌跡中，超過 27% 的請求，其工具執行時間可與模型推論相當或更長。Trae 的 CPU 使用率中位數約 11%，卻會在平行建置與測試時逼近滿載。平均使用率低，因而不代表系統還有穩定餘裕。
瓶頸不再是一顆晶片，而是整條工作流
合理推論：傳統 LLM 伺服器通常把 GPU 視為主要生產設備，CPU 負責餵送請求；代理工作負載卻把 CPU 放回關鍵路徑。排程器要派送推論，協調器要管理代理間的狀態與依賴，執行器還要跑程式、查資料或等待網路服務。任何一段延遲，都可能讓昂貴的 GPU 空等；反過來，工具突然大量啟動，也可能讓 CPU 成為瞬間瓶頸。
另一篇由布朗大學研究者提出的獨立預印本，從工具配置角度得到相符結論。他們測試 19 種 AI 工具，只有 11 種明確偏好 GPU，另有四種結果不明顯、一種因 PCIe 傳輸成本而偏好 CPU、三種對裝置選擇不敏感。這不直接驗證 Agora 的效能數字，卻交叉支持「所有工作一律先丟 GPU」並非最佳策略。來源：https://arxiv.org/html/2607.22242
Agora 的商業邏輯：先收回閒置，再保護尖峰
研究團隊提出的 Agora 不是新晶片，而是面向一般商用伺服器的原型執行環境。它採取三種做法：把代理暫時不用的 CPU 核心交給其他吞吐型工作；將可共享模型權重、且活躍時間互補的代理整併到較少 GPU；再依排程、協調與工具執行等角色切分 CPU 核心池，並以工作任務為單位固定核心親和性，降低快取與分支預測狀態被反覆洗掉的成本。
在低負載測試中，CPU 閒置資源回收工作可保有約 95% 的單獨執行吞吐量，同時將代理變慢幅度控制在 3% 以內；高負載時，可回收吞吐量降至平均 53.7%。針對角色活躍度不均的 Owl，GPU 整併可少用三分之一 GPU，生成吞吐量提高 82%、每小時完成任務增加 22%，尾端延遲縮短為原本的四成。
作者觀點：這些結果真正挑戰的是採購指標。若企業仍只比較 GPU 數量、峰值算力或單次 token 成本，就可能買到規格亮眼、但在多步工作流中長時間互等的系統。更有意義的衡量方式應轉向每小時完成任務數、端到端 P95／P99 延遲、CPU 與 GPU 同時有效工作的比例，以及完成一項業務流程所需的能源與成本。
不能忽略的限制
Agora 的亮眼數字不能直接外推到所有代理。它目前仍是預印本中的研究原型，受控測試只有四種框架與特定硬體。更關鍵的是，GPU 回收效果高度依賴工作流形態：CORAL 的代理會平行活躍，實驗中若硬把 GPU 數量減半，生成吞吐量反而下降 71%、每小時任務數下降 55%，尾端延遲惡化 16 倍。這證明「少配 GPU」不是通則；系統必須先知道代理是循序、平行，使用同一模型或多種模型，以及工具偏向運算還是網路等待。
此外，生產資料揭露的是分布與資源特徵，並未公開所有租戶、模型與工具的完整組成。Agora 的預取還仰賴協調器能預告下一個代理；若決策本身由 LLM 動態產生，控制流較難預測，只能採用較保守的反應式策略。效能提升也不等於可靠性、安全性或任務正確率同步提升。
對台灣產業與企業買家的意義
作者觀點：對台灣伺服器與零組件供應鏈而言，機會不只在增加加速卡出貨，而在整機共同設計：CPU 核心配置、主記憶體容量與頻寬、GPU 記憶體交換路徑、網路延遲、電力與散熱，都會影響代理工作流能否保持連續。能提供可調式拓撲、工作負載遙測與軟硬體聯調能力的供應商，價值可能高於單純堆疊規格。
對企業資訊主管而言，較務實的做法是先用自己的客服、軟體開發或研究代理做完整追蹤，再決定採購。應記錄每項任務的模型呼叫次數、工具時間占比、CPU／GPU 尖峰、GPU 記憶體命中與交換、尾端延遲及失敗重試，而不是拿聊天機器人的平均 token 吞吐量代替容量規畫。
後續觀察指標
- Agora 是否在更多硬體世代、模型與企業工具組合上重現成果。
- 雲端業者是否開始提供以完整代理工作流為單位的排程、計價與服務水準指標。
- 企業標案是否由 GPU 數量轉向任務完成率、尾端延遲與每任務能耗。
- 伺服器 CPU、快取、記憶體與互連設計，是否出現針對代理協調與頻繁狀態切換的專用功能。
這項研究尚不足以宣告 GPU 時代退潮；它指出的是更細緻的轉折：GPU 仍不可或缺，但企業 AI 的效能邊界，正從單一處理器轉向整台伺服器、執行環境與工作流能否協同運作。