AI 基礎設施
Azure 實測代理工作流暴露 CPU–GPU 碎片化，Agora 回收閒置算力仍保住尾延遲
Microsoft Azure 研究顯示，代理在模型推論、工具與協調器之間反覆切換，使 CPU 重新進入關鍵路徑，GPU 卻經常閒置。原型系統 Agora 可依工作流型態回收算力，但錯誤壓縮平行代理的 GPU 配置反而會讓尾延遲惡化 16 倍。
代理服務不能再被視為一串彼此獨立的 LLM 請求。[Microsoft Azure 團隊的研究](https://arxiv.org/abs/2608.04458)分析 24 小時正式環境軌跡，並在配備 96 核心 AMD EPYC 7V12、八張 NVIDIA A100 的伺服器上重現 SWE-Agent、Trae、CORAL 與 Owl。每個任務會在推論、工具執行及協調邏輯間來回跨越 CPU–GPU 邊界；Trae 的主機 CPU 使用率中位數只有 11%，但建置與測試同時啟動時接近 100%。四套框架的平均 GPU SM 活性均低於 55%，顯示低平均負載不代表沒有瞬時瓶頸。
團隊據此製作 Agora，在一般伺服器上動態回收閒置核心、依排程器／協調器／工具執行器分池，並把多個代理合併至共享推論實例。低負載時，CPU harvesting 可交付共置工作原有效能的 95%，代理只慢 2.8%；角色感知分池則最多減少 46% 工具 CPU 用量。對啟動時間錯開的 Owl，GPU 記憶體超額配置、狀態預取與共享模型權重可少用三分之一 GPU，同時將生成吞吐提高 82%、尾延遲縮短 2.5 倍。[Intel 的技術材料](https://www.intel.com/content/www/us/en/content-details/916705/agentic-ai-requires-more-cpus.html)也指出，增加主機端運算可降低餵不飽 GPU 的成本。
不過這不是通用的「少配 GPU」處方。CORAL 的代理會平行活動，抽走一半 GPU 後吞吐下降 71%，尾延遲惡化 16 倍。Agora 尚未見公開實作，正式環境資料亦無法獨立重播。工程團隊接下來應先量測角色、突發工具負載與代理重疊率，再決定是否合併實例或回收裝置。