🤖 AI

Towards Understanding, Analyzing, and Optimizing Agentic AI Execution: A CPU-Centric Perspective

本文从被忽视的 CPU 视角出发，深入分析了代理 AI（Agentic AI）工作负载的系统瓶颈，并提出了 CPU 感知重叠微批处理（COMB）和混合代理调度（MAS）两种优化策略，显著提升了异构 CPU-GPU 系统的并发利用率并降低了端到端延迟。

原作者： Ritik Raj, Souvik Kundu, Ishita Vohra, Hong Wang, Tushar Krishna

发布于 2026-04-20

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Ritik Raj, Souvik Kundu, Ishita Vohra, Hong Wang, Tushar Krishna

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文就像是在给现在的"AI 智能体”（Agentic AI）做一次全面的身体检查，并开出了两剂“药方”。

为了让你更容易理解，我们可以把AI 智能体想象成一个超级聪明的“项目经理”。这个经理（LLM，大语言模型）非常擅长思考、做计划，但它自己不动手，它需要指挥一群“工人”（工具，比如查网页、写代码、算数据）去干活。

1. 核心问题：经理太聪明，工人太累？

以前的 AI 研究，大家都盯着那个“超级经理”（GPU 上的大模型），觉得只要让经理思考得更快，整个系统就快了。

但这篇论文发现了一个被忽视的大问题：现在的 AI 智能体，大部分时间其实花在“指挥”和“等工人干活”上，而不是经理自己在思考。

比喻：想象一个餐厅。以前我们只关心主厨（GPU）切菜炒菜的快不快。但现在的菜单变了，主厨不再亲自炒菜，而是负责指挥：叫外卖（查网页）、让服务员去仓库找食材（数据库检索）、让学徒写菜单（运行代码）。
发现：论文作者发现，在这个新流程里，主厨（GPU）经常闲着没事干，而负责跑腿和干杂活的“前台/服务员”（CPU）却累得半死，成了整个餐厅的瓶颈。 哪怕你给主厨换了一台世界顶级的（更强的 GPU），如果前台还是那么慢，顾客（用户请求）还是得排长队。

2. 他们做了什么？（诊断过程）

作者们找来了五种不同类型的“智能体”（有的擅长查资料，有的擅长写代码，有的擅长做化学实验），在两套不同的硬件系统上（一套是“普通 CPU+ 普通 GPU"，一套是“顶级 CPU+ 顶级 GPU"）进行了压力测试。

他们发现了三个关键真相：

CPU 是瓶颈：在很多任务中，CPU 处理工具的时间占了总时间的 80% 以上。
越强的 GPU 越尴尬：如果你把 GPU 换得特别快，主厨干活瞬间结束了，但前台（CPU）还是那么慢，结果就是主厨大部分时间在“发呆”，等待前台把东西送过来。
人多反而乱：以前为了追求效率，我们习惯让 CPU 同时处理很多任务（多线程/多进程）。但作者发现，CPU 不像 GPU 那样擅长“人多力量大”，一旦任务太多，CPU 反而会因为“交通堵塞”（上下文切换开销）而变慢，导致整体效率下降。

3. 他们开出了什么药方？（两大优化方案）

为了解决“前台太慢，主厨太闲”的问题，作者提出了两种调度策略：

方案一：COMB（给前台“分批次”干活）

适用场景：所有任务都差不多（比如全是查资料的）。
比喻：以前，前台接到 128 个订单，就一股脑全塞给 128 个服务员去跑，结果走廊挤爆了，大家互相撞来撞去，谁也跑不快。
COMB 的做法：
1. 小批量：把 128 个订单拆成几个小批次（比如每批 64 个），让服务员分批跑，避免走廊拥堵。
2. 流水线重叠：当第一批服务员在跑的时候，第二批服务员已经准备好出发了，同时主厨（GPU）也在处理第一批的后续步骤。
效果：就像优化了餐厅的动线，让服务员和主厨配合得更默契，不再互相等待。结果：速度提升了 1.7 倍到 3.9 倍。

方案二：MAS（给不同客人“分通道”）

适用场景：任务类型混杂（有的任务全是 CPU 干，有的全是 GPU 干）。
比喻：餐厅里既有“只要点菜”的简单客人（纯 GPU 任务），也有“要查库存、要定制菜单”的复杂客人（CPU 重任务）。如果所有客人都排在一个长队里，一旦来了很多复杂客人，简单客人就要等很久；反之亦然。
MAS 的做法：
1. 分通道：设立两个排队区。一个专门给“简单客人”（GPU 任务），一个专门给“复杂客人”（CPU 任务）。
2. 保底机制：即使“复杂客人”特别多，系统也会强行留几个位置给“简单客人”，防止他们被完全挤掉。
效果：无论哪种客人多，大家都能公平地得到服务，不会出现某类客人被“饿死”的情况。在极端情况下，少数派客人的等待时间减少了 2 倍多。

4. 总结与启示

这篇论文告诉我们：

不要只盯着 GPU：在 AI 智能体时代，CPU（负责逻辑、工具调用）的重要性被严重低估了。
硬件不是万能药：光买更贵的显卡没用，如果调度策略不对，显卡也会“摸鱼”。
未来的方向：我们需要设计更聪明的“调度员”，让 CPU 和 GPU 像一支配合默契的乐队，而不是各吹各的号。

一句话总结：
这篇论文发现现在的 AI 智能体是“CPU 累死，GPU 闲死”，于是他们发明了两种新的“排队和分工”方法，让 CPU 和 GPU 配合得更丝滑，从而让 AI 跑得更快、更稳、更公平。

这篇论文《Towards Understanding, Analyzing, and Optimizing Agentic AI Execution: A CPU-Centric Perspective》（面向理解、分析与优化代理 AI 执行：一种以 CPU 为中心的视角）深入探讨了代理 AI（Agentic AI）系统在异构 CPU-GPU 架构下的性能瓶颈，并提出了相应的优化方案。

以下是该论文的详细技术总结：

1. 研究背景与问题 (Problem)

背景：随着大语言模型（LLM）向代理 AI（Agentic AI）演进，系统不再仅仅是单一的推理任务，而是演变为能够规划、调用工具、进行推理和自适应的自主问题解决者。这些系统通常依赖异构的 CPU-GPU 架构，其中大量的外部工具（如 Bash 执行、Web 搜索、文档检索等）由 CPU 负责执行或编排。
核心问题：
- 被忽视的 CPU 瓶颈：现有的 AI 效率优化主要集中在 GPU 内核和 KV 缓存管理上，忽略了 CPU 在工具执行中的关键作用。
- 端到端延迟主导：研究表明，在检索增强生成（RAG）等任务中，CPU 上的工具处理（如向量检索）可能占据端到端（E2E）延迟的 80% 以上。
- 资源利用失衡：当 GPU 性能提升时，瓶颈会迅速转移至 CPU。然而，CPU 的并行化策略（如多进程/多线程）效率通常低于 GPU，容易导致吞吐量过早饱和，进而造成昂贵的 GPU 资源闲置。
- 异构负载调度困难：在混合负载场景下（既有 CPU 密集型工具调用，又有 GPU 密集型纯推理），传统的调度策略往往导致某一类请求（通常是少数派）因资源被垄断而遭受极高的延迟。

2. 方法论 (Methodology)

论文采用了一套系统的“编译时 + 运行时”分析框架，并基于此提出了调度优化策略。

A. 编译时特征分析 (Compile-time Characterization)

作者提出了三个正交维度来分类代理 AI 工作负载（如图 1 所示）：

编排器 (Orchestrator)：LLM 编排（LLM 决定流程）vs. 主机/Python 代码编排（CPU 决定流程）。
代理路径 (Agentic Path)：静态路径（预定义流程）vs. 动态路径（运行时根据结果调整）。
重复性 (Repetitiveness)：单步（单次调用完成）vs. 多步（多次迭代交互）。

代表性工作负载：选取了 Toolformer、SWE-Agent、RAG (Haystack)、ChemCrow 和 Web-Augmented Agent 五种具有代表性的工作负载进行剖析。

B. 运行时特征分析 (Runtime Characterization)

在两套不同的硬件系统上进行了实验（Sys 1: 高性能 CPU + 低性能 GPU; Sys 2: 高性能 CPU + 高性能 GPU）：

延迟分析：发现工具主导的工作负载中，CPU 处理占据了 E2E 延迟的绝大部分（最高达 88%）。
吞吐量分析：揭示了 CPU 并行化（多进程/多线程）存在效率天花板。当 Batch Size 增加时，CPU 吞吐量会过早饱和（由于 GIL 锁、上下文切换或内存带宽限制），导致 GPU 利用率下降。
能耗分析：在 CPU 为中心的代理 AI 中，CPU 的动态能耗贡献显著（最高达 61%），表明 CPU 是主要的能耗来源之一。

3. 关键贡献 (Key Contributions)

基于上述分析，论文提出了两种针对不同类型负载的调度优化策略：

1. 感知 CPU 的重叠微批处理 (COMB - CPU-Aware Overlapped Micro-Batching)

适用场景：同构负载（Homogeneous Workloads，即单一类型的代理任务）。
核心思想：
- 微批处理 (Micro-batching)：将大 Batch 分割为受限制的小微批（ $B_{cap}$ ），避免 CPU 核心过载（Oversubscription）。 $B_{cap}$ 根据 CPU 并行效率设定（通常约为 CPU 核心数的 1-2 倍）。
- 重叠执行 (Overlapping)：在微批之间引入重叠间隔（Overlap interval），使得当前微批的 GPU 推理阶段与下一个微批的 CPU 工具执行阶段并行进行。
目的：解决 CPU 和 GPU 执行阶段的相位不平衡，最大化并发利用率，减少尾延迟。

2. 混合代理调度 (MAS - Mixed Agentic Scheduling)

适用场景：异构负载（Heterogeneous Workloads，即 CPU 密集型与 GPU 密集型请求混合）。
核心思想：
- 感知请求类型的并发准入：为 CPU 密集型请求和 GPU 密集型请求分别设置独立的执行队列上限（ $E_{cap, CPU}$ 和 $E_{cap, GPU}$ ）。
- 共享预留队列：设置一个共享的预留队列，用于处理突发流量，防止某一种请求类型完全垄断系统资源。
目的：在混合负载下保护“少数派”请求（Minority Request-type），防止其因资源被“多数派”请求阻塞而产生高延迟，同时维持整体吞吐量。

4. 实验结果 (Results)

实验在两种硬件系统上验证了 COMB 和 MAS 的有效性：

COMB 效果：
- 在同构负载下，相比基线（最大 Batch 处理），COMB 将 P50 延迟降低了 1.7 倍。
- 在开环负载（Open-loop load）下，服务延迟降低了 3.9 倍，总延迟降低了 1.8 倍。
- 吞吐量提升了 1.7 倍。
- 在 CPU 受限的消融实验中（16 核 CPU），虽然重叠效果减弱，但微批处理本身仍能显著降低 P50 延迟。
MAS 效果：
- 在异构负载下，MAS 显著改善了少数派请求的延迟。
- 对于 CPU 密集型少数请求，P50/P90 延迟降低了 2.37 倍 / 2.49 倍。
- 对于 GPU 密集型少数请求，延迟降低高达 1.82 倍 / 1.78 倍。
- 在资源受限（16 核 CPU）的极端场景下，MAS 仍能保护 GPU 密集型请求，使其 P50 延迟降低 10.1 倍，证明了该策略的通用性。
能耗：实验表明，在 CPU 密集型代理任务中，CPU 消耗了系统总动态能耗的 40%-60%，强调了针对 CPU 进行优化的必要性。

5. 意义与影响 (Significance)

视角转变：这是首个从CPU 为中心的视角量化并分析代理 AI 执行中端到端延迟、吞吐量和能耗瓶颈的工作。它纠正了以往仅关注 GPU 优化的片面性。
设计原则：提出了“最优的 CPU-GPU 并发利用率”应作为下一代代理 AI 服务系统的关键设计原则。
实际价值：
- 成本效益：证明了在工具主导的任务中，使用高性能 CPU 配合中低端 GPU 即可达到与高端 GPU 系统相当的 E2E 延迟，有助于降低部署成本。
- 系统优化：提出的 COMB 和 MAS 策略为现有的推理框架（如 vLLM）提供了重要的扩展方向，特别是在处理复杂的 Agent 工作流时。
- 公平性：MAS 解决了混合负载下的资源公平性问题，确保不同服务等级（SLA）的请求都能获得可接受的延迟。

综上所述，该论文通过深入剖析 CPU 在代理 AI 中的瓶颈作用，提出了一套从特征分析到调度优化的完整解决方案，为构建高效、低延迟且公平的下一代 AI 代理系统奠定了重要基础。