Agentic AI 工作流的架构影响

# Agentic AI 工作流的架构影响
来源：https://arxiv.org/html/2608.04458

###### 摘要

Agentic AI（智能体AI）是一种新兴的数据中心工作负载类别，其中LLM可以自主规划、调用工具，并在多个agent之间协调以解决复杂任务。然而，其架构影响在很大程度上仍未被探索。为了弥补这一空白，我们通过一个分类法来组织agentic工作流，并进行了首次agentic AI架构特征化研究：既包含覆盖我们超大规模云服务商整个集群的生产研究，也包含针对多个代表性开源框架的受控研究。我们的研究表明，agentic执行本质上是碎片化和异构的。每个请求都会扩展为由LLM推理、工具调用和编排决策组成的工作流，并反复跨越CPU–GPU边界。我们的分类法解释了这种碎片化如何转化为资源需求。由于编排和工具运行在主机上，CPU处于关键路径上。执行结构决定了负载随时间的变化模式：长时间的低利用率会被某个阶段释放工具时出现的突发流量打断。模型组合则决定了工作流对GPU使用的均匀程度，常常使某些GPU饱和，而另一些却空闲。任务和工具的多样性进一步扩大了这个范围。这些特征暴露了传统统一服务器的三个架构错配：碎片化执行会导致CPU和GPU容量被闲置，尽管存在突发需求；不同的软件角色使得同质化CPU配置效率低下；最后，将多个agent多路复用共享核心会降低微架构局部性，并增加协调开销。在这些发现的指导下，我们推导出agentic服务器的设计启示，并通过我们的商品服务器原型Agora进行了检验。Agora动态收集空闲CPU核心用于共置的吞吐量工作，同时保护agent的尾部延迟免受工具尖峰的影响。它还通过在每个GPU上放置更多agent来超额使用GPU内存，并预取下一个agent的状态以隐藏交换延迟。为了将机器与异构角色匹配，Agora按角色池化核心，并应用亲和性感知调度来恢复局部性。最后，Agora会根据运行中的工作负载自动调整所有这些机制。这些技术显著提高了CPU和GPU利用率以及每服务器吞吐量，同时保持了agent的尾部延迟。我们的见解还为未来agentic AI的服务器架构指出了关键方向。

## I. 引言

大语言模型（LLM）的部署方式正在改变。传统上，LLM服务系统将每次模型调用优化为独立请求：系统接收提示词并产生响应[74 (https://arxiv.org/html/2608.04458#bib.bib22),39 (https://arxiv.org/html/2608.04458#bib.bib23),16 (https://arxiv.org/html/2608.04458#bib.bib24),47 (https://arxiv.org/html/2608.04458#bib.bib19),84 (https://arxiv.org/html/2608.04458#bib.bib26),53 (https://arxiv.org/html/2608.04458#bib.bib20),3 (https://arxiv.org/html/2608.04458#bib.bib25),81 (https://arxiv.org/html/2608.04458#bib.bib21)]。然而，越来越多的应用现在将一个或多个模型嵌入到迭代控制循环中。在每一步中，应用使用模型推理来解释当前状态、选择下一步动作（例如调用工具或委派子任务）、观察结果，并继续直到任务完成。这种*agentic*（智能体）执行模式驱动着软件工程[22 (https://arxiv.org/html/2608.04458#bib.bib27)]、深度研究[13 (https://arxiv.org/html/2608.04458#bib.bib55)]、科学发现[50 (https://arxiv.org/html/2608.04458#bib.bib49)]和企业自动化[29 (https://arxiv.org/html/2608.04458#bib.bib37)]等领域的应用。预测表明，它将成为未来几年数据中心容量增长最快的消耗者之一[18 (https://arxiv.org/html/2608.04458#bib.bib38)]。尽管很流行，但agentic AI对服务器架构的影响仍未得到充分探索。研究人员一直在为传统的、以CPU为中心的服务优化服务器，如Web服务、键值存储和数据分析和推理[63 (https://arxiv.org/html/2608.04458#bib.bib30),64 (https://arxiv.org/html/2608.04458#bib.bib33),61 (https://arxiv.org/html/2608.04458#bib.bib32),49 (https://arxiv.org/html/2608.04458#bib.bib31),37 (https://arxiv.org/html/2608.04458#bib.bib47),15 (https://arxiv.org/html/2608.04458#bib.bib46),27 (https://arxiv.org/html/2608.04458#bib.bib41),60 (https://arxiv.org/html/2608.04458#bib.bib45),62 (https://arxiv.org/html/2608.04458#bib.bib43),32 (https://arxiv.org/html/2608.04458#bib.bib40),33 (https://arxiv.org/html/2608.04458#bib.bib39),30 (https://arxiv.org/html/2608.04458#bib.bib44),21 (https://arxiv.org/html/2608.04458#bib.bib34),66 (https://arxiv.org/html/2608.04458#bib.bib35),24 (https://arxiv.org/html/2608.04458#bib.bib61)]，以及更近期的单个整体式LLM推理，其中加速器上的密集张量计算占主导地位，而主机只是为其提供数据[53 (https://arxiv.org/html/2608.04458#bib.bib20),81 (https://arxiv.org/html/2608.04458#bib.bib21),3 (https://arxiv.org/html/2608.04458#bib.bib25),70 (https://arxiv.org/html/2608.04458#bib.bib1),42 (https://arxiv.org/html/2608.04458#bib.bib2),35 (https://arxiv.org/html/2608.04458#bib.bib3),41 (https://arxiv.org/html/2608.04458#bib.bib4)]。Agentic执行与这两者都不同。一项任务不再映射为单个张量计算或请求-响应服务。相反，它展开为一个数据依赖图，包含许多模型调用、工具调用和由编排软件在主机上组装的控制决策。因此，执行跨越加速器和多个主机侧组件（CPU、内存系统、网络和运行时），并随着应用增加agent并深化协调而变得复杂。尽管一些初步的系统工作已开始构建agentic框架[75 (https://arxiv.org/html/2608.04458#bib.bib79),36 (https://arxiv.org/html/2608.04458#bib.bib15),31 (https://arxiv.org/html/2608.04458#bib.bib16),10 (https://arxiv.org/html/2608.04458#bib.bib80),11 (https://arxiv.org/html/2608.04458#bib.bib9)]，但我们仍缺乏对这类工作负载如何实际使用硬件，以及为上述两种旧目标设计的服务器是否足够的基础架构理解。为了系统性地推理这种高度多样化的负载，我们首先沿着agentic AI的平台相关维度开发了一个分类法：agent如何编排、工作流如何结构化、模型如何组合。在分类法的指导下，我们通过覆盖超大规模云服务商*Microsoft Azure*整个集群的生产研究，以及覆盖多个用例的多样化开源框架受控研究，首次对agentic AI进行了架构特征化。我们的主要见解是，agentic AI产生了高度碎片化的执行，而分类法中的维度决定了这种碎片化如何表现为异构资源需求。由于主机侧编排和工具将连续的模型调用分隔开，CPU进入关键路径，每个任务反复跨越CPU–GPU边界。编排机制控制着控制权如何在agent之间传递。执行结构塑造了主机负载的模式：长时间的低利用率可能会被工作流阶段释放工具调用组时的突发饱和所打断。模型组合决定了工作流利用加速器池的均匀程度，可能使某些GPU饱和，而另一些空闲。即使在同一个分类法类别中，工作负载在提供的负载和所解决的任务上也存在显著差异，进一步扩大了资源需求的范围。因此，传统的、统一配置的服务器在三个方面不适合agentic AI。首先，碎片化导致资源被闲置：CPU和GPU平均利用率不足，却会经历短暂的接近饱和的突发，在突发之间留下大量空闲容量。其次，三种主机角色（调度器、编排器和运行器）表现出截然不同的资源画像，因此单一同质核心池无法高效服务所有角色。第三，在共享核心上多路复用多个agent会降低微架构局部性，因为它们互相驱逐缓存线和分支预测器状态，增加流水线停顿。由于这些低效问题的性质和严重程度随工作流、负载和任务而变化，没有一种静态配置适合所有情况；服务器必须适应每个工作负载。在这些发现的指导下，我们得出了运行agentic AI的服务器三个设计原则。我们通过*Agora*（我们的商品服务器原型）中的案例研究逐一检验。首先，在主机侧，服务器应回收碎片化执行留下的时间缝隙。Agora收集空闲CPU核心用于共置的吞吐量工作，同时保护agent免受突发工具调用的影响。其次，在加速器侧，服务器应回收空闲容量，而不是将独占GPU访问权固定分配给特定agent。Agora通过将agent整合到更少的GPU上来实现这种回收，利用共享模型状态或从不同时活跃的agent，从而平衡繁忙与空闲设备。第三，主机核心应按软件角色划分，并通过调度保持任务局部性，而不是作为单一同质池管理。Agora隔离并调整控制平面和突发运行器池的大小，并在运行器池内固定任务以保持缓存和分支预测器局部性。我们在开源agentic框架上实现了这三个案例研究，并在真实硬件上对比静态、与工作负载无关的配置进行了评估。CPU回收恢复了共置工作负载单机吞吐量的95%，并将主机CPU利用率提高了30%，同时将agent延迟影响限制在3%以内。GPU回收释放了三分之一的GPU，同时将生成吞吐量提高了82%，并将尾部延迟降低了2.5倍。角色感知池化将工具的CPU需求降低了最多46%，最坏情况工具延迟降低了13%，同时保持了99%的服务吞吐量。除了当前的硬件，我们的见解还为未来硬件提出了优化方向。专用支持可以将频繁的调度和上下文管理操作从主机核心上卸载。CPU核心还可以进一步将硬件能力与不同主机角色匹配，将能效核心用于轻量级协调，将高性能核心用于计算密集型工具执行。总之，本文做出以下贡献：

- 首次对agentic AI进行生产环境架构特征化，测量覆盖超大规模云服务商整个集群。
- 一个分类法，沿着平台相关轴组织异构的agentic AI工作负载空间，并对其各类的真实用例进行特征化。
- 三个服务器设计启示，通过Agora案例研究探索：收集空闲CPU核心、通过整合agent回收空闲GPU容量、以及按角色和任务局部性管理主机核心。

## II. 背景与动机

参见图1：agentic AI工作流执行示例。

表I：agentic工作流分类法，包含不同类别中的示例及其对平台设计的影响。

| 维度 | 选项 | 当前语料库中的示例 | 对平台设计的影响 |
|------|------|-------------------|------------------|
| 编排方式 | 主机编排 | MetaGPT[25 (https://arxiv.org/html/2608.04458#bib.bib60)]; MAGE[82 (https://arxiv.org/html/2608.04458#bib.bib73)]; Paper2Code[59 (https://arxiv.org/html/2608.04458#bib.bib72)] | 主机将控制流暴露给运行时，支持调度和预取。 |
| 编排方式 | LLM编排 | OWL[26 (https://arxiv.org/html/2608.04458#bib.bib6)]; ToolOrchestra[65 (https://arxiv.org/html/2608.04458#bib.bib68)]; AOrchestra[58 (https://arxiv.org/html/2608.04458#bib.bib69)] | 模型在运行时选择或创建agent，增加了推理驱动的控制决策。 |
| 执行结构 | 串行 | AlphaEvolve[50 (https://arxiv.org/html/2608.04458#bib.bib49)]; Trae Agent[67 (https://arxiv.org/html/2608.04458#bib.bib8)]; AccelOpt[77 (https://arxiv.org/html/2608.04458#bib.bib70)] | 依赖步骤形成关键路径；一个步骤停滞会延迟整个工作流。 |
| 执行结构 | 并行 | ReConcile[12 (https://arxiv.org/html/2608.04458#bib.bib74)]; CORAL[56 (https://arxiv.org/html/2608.04458#bib.bib5)]; DeLM[45 (https://arxiv.org/html/2608.04458#bib.bib71)] | 独立agent产生并发推理和工具突发，增加批处理和负载。 |
| 模型组合 | 同构 | 大多数框架默认使用相同的基础模型 | 共同的基础模型支持共享驻留和更大的跨agent批处理。 |
| 模型组合 | 异构 | ToolOrchestra[65 (https://arxiv.org/html/2608.04458#bib.bib68)]; AOrchestra[58 (https://arxiv.org/html/2608.04458#bib.bib69)]; AccelOpt[77 (https://arxiv.org/html/2608.04458#bib.bib70)] | 工作流中必须保持多个模型类型可用，使负载均衡复杂化。 |

### A. Agentic AI 工作流

传统LLM服务将模型调用视为执行的主要单元。服务引擎向模型提供上下文提示词，自回归解码输出token，然后返回响应[74 (https://arxiv.org/html/2608.04458#bib.bib22),68 (https://arxiv.org/html/2608.04458#bib.bib18)]。主机负责准备、调度和分发请求，而加速器（如GPU）执行模型计算[39 (https://arxiv.org/html/2608.04458#bib.bib23),51 (https://arxiv.org/html/2608.04458#bib.bib28),83 (https://arxiv.org/html/2608.04458#bib.bib14)]。一个*agent*将LLM置于控制循环中。给定一个目标，