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

Ritik Raj, Souvik Kundu, Ishita Vohra, Hong Wang, Tushar Krishna | 2025-11 | https://arxiv.org/abs/2511.00739 Category: agent | Tags: CPU, overhead-analysis, serving, characterization, scheduling Read: 2026-04-20

TL;DR #

首次从 CPU 侧视角系统刻画 agentic AI 的端到端延迟瓶颈：工具执行（检索、摘要、代码执行、分子生成）占 E2E 延迟高达 88%，CPU 并行化效率远低于 GPU 导致吞吐过早饱和。提出 COMB（微批重叠）和 MAS（混合调度）两种调度优化，分别将服务延迟降低 3.9× 和 2.49×。

Core Contribution #

首次从 CPU 侧视角系统刻画 agentic AI workload 的端到端延迟/吞吐瓶颈，揭示工具执行占 E2E 延迟高达 88%，并提出 COMB（同构微批重叠）和 MAS（混合调度）两种调度优化，分别在同构/异构场景下将服务延迟降低 3.9×/2.49×。

Q1: 这篇论文试图解决什么核心痛点？ #

现有 AI 效率优化集中在 GPU kernel 和 KV-cache 管理，但 agentic AI 的工具执行（ENNS 检索、Bash 执行、LexRank 摘要、RDKit 分子生成）大多运行在 CPU 上，CPU 侧瓶颈被系统性忽略。CPU 工具处理占 E2E 延迟高达 88%，且 CPU 并行化效率远低于 GPU，导致吞吐过早饱和——GPU 资源被浪费。

Q2: 作者提出了什么新的方法？ #

两层调度优化：(1) COMB 将大批次拆分为 $B_{cap}$ 大小的微批，避免 CPU core over-subscription，并通过重叠间隔 $s$ 实现 CPU/GPU 流水线并行，构建 P50-P90 Pareto 前沿；(2) MAS 为 CPU-heavy 和 GPU-heavy 请求设置独立弹性队列上限 $E_{cap,CPU}$/$E_{cap,GPU}$ + 共享保留队列 $E_{cap,shared}$，防止主导请求类型垄断准入。

Q3: 最终效果如何？ #

COMB 在开放循环负载下将服务延迟降低 3.9×（P50）/1.8×（P90），吞吐提升 1.7×。MAS 在异构请求混合 $p_{LLM}=0.25$ 时将少数 GPU-heavy 请求的 P50/P90 延迟改善 2.37×/2.49×。在 16 核 CPU 受限平台上 MAS 甚至达到 10.1×/8.8× 的 P50/P90 改善。

Summary #

Agentic AI 将单体 LLM 推理转化为可调用外部工具的自主代理系统，但工具执行大多运行在 CPU 上，现有以 GPU kernel 和 KV-cache 为中心的优化对此无效。本文首先从编译时（orchestrator / path / flow 三轴分类法）和运行时（在 Intel GNR + RTX-6000 Pro 与 Grace + H200 两套系统上的延迟/吞吐/能耗 profiling）两个层面刻画 5 种代表性 agentic workload（Toolformer、SWE-Agent、RAG-Haystack、ChemCrow、Web-Augmented Agent）。

关键发现：CPU 工具处理最高占 E2E 延迟 88%（RAG-Haystack ENNS 检索），CPU 并行化效率远低于 GPU 导致吞吐在 BS=128 时过早饱和（LexRank 延迟翻倍而 GPU 推理几乎不变），GPU 越强则瓶颈越快移向 CPU（Toolformer 推理占比从 Sys1 的 88% 降至 Sys2 的 77%）。

基于此，论文提出两种调度策略：COMB 将大批次拆为 $B_{cap}$ 大小的微批并重叠 CPU/GPU 阶段以平衡利用率，在开放循环负载下服务延迟降低 3.9×（P50）；MAS 对 CPU-heavy 和 GPU-heavy 请求设置独立弹性队列上限并配合共享保留队列，保护少数请求类型在 bursty 到达模式下的尾延迟（P50/P90 改善 2.37×/2.49×）。在 16 核 CPU 受限平台的消融实验进一步验证了方法的泛化性。

Key Findings #

• CPU 工具执行最高占 agentic AI 端到端延迟的 88%（RAG-Haystack ENNS 检索），凸显 GPU 优化盲区
• HP GPU 系统将瓶颈从 GPU 迅速转移至 CPU：Toolformer 推理占比从 Sys1 的 88% 降至 Sys2 的 77%
• CPU 并行化（MP/MT）在 BS=128 时因 core over-subscription 和 GIL 限制导致吞吐过早饱和，GPU 并行化效率显著更高
• COMB 通过微批上限 $B_{cap}$ + 重叠间隔 $s$ 构建 P50-P90 Pareto 前沿，开放循环负载下服务延迟降低 3.9×（P50）
• MAS 在异构请求混合下保护少数请求类型：$p_{LLM}=0.25$ 时 GPU-heavy 请求 P50/P90 延迟改善 2.37×/2.49×
• CPU 动态能耗在 CPU-heavy workload 中占系统总动态能耗高达 61%（RAG-Haystack），激励 CPU 侧能效优化

Limitations #

• 仅使用 ≤32B SLM（GPT-J-6B, GPT-OSS-20B, Qwen2.5-Coder-32B），未验证 70B+ 大模型场景下 CPU/GPU 瓶颈比例变化
• COMB 的 $B_{cap}$ 需手动经验调参（$\approx 1-2 \times$ CPU 核心数），缺乏自适应动态调节机制
• MAS 的弹性队列上限为静态配置，未考虑负载自适应
• 未涉及 multi-turn agent 的 KV-cache 状态管理和跨 turn 工具调用调度
• 工具执行本身未优化（如 FAISS 加速、LexRank 算法优化），仅在调度层面寻找改善空间
• 实验仅 2+1 套系统，缺乏云原生多租户场景验证

Infrastructure Impact #

• Algorithm: 揭示 agent 工具执行的 CPU 瓶颈，激励 CPU-efficient 工具替代方案（如 GPU-based ANN 替代 CPU ENNS）的算法研究
• Kernel: CPU 工具执行成为 E2E 延迟主导时，GPU kernel 优化边际收益递减；需关注 CPU 侧 kernel 的向量化和并行优化
• Framework: 直接影响 agentic serving 框架的调度器设计：需要 CPU-aware 的微批调度和异构请求感知准入控制
• LLM: SLM 在 agentic 场景下可匹配更大模型效果，影响 agentic LLM 选型策略
• Agent: 核心直接相关：系统性刻画 agent 系统的 CPU 侧瓶颈分布，为 agent runtime 设计提供量化依据
• Code: COMB 和 MAS 可直接集成到现有 agent serving 框架中

---

Deep Analysis (agent) #

1. Agent Architecture #

本文的分析对象不是单一 agent 系统，而是5 种代表性 agentic workload 的系统级刻画。

Compile-time 三轴分类法（Figure 1）：

1. Orchestrator 轴：LLM-orchestrated（如 ReAct、AutoGPT、Toolformer）vs. Host/Python-orchestrated（如 LangChain、Haystack、LlamaIndex）
2. Agentic Path 轴：Static-path（预定路径，如 Haystack RAG pipeline）vs. Dynamic-path（运行时决定，如 Reflexion、LATS）
3. Repetitiveness 轴：Single-step（单次工具调用，如 RAG 检索）vs. Multi-step（迭代交互，如 SWE-Agent 的多轮代码修改）

Figure 1: Compile-time Characterization #



What it shows: 三维分类法的图示——orchestrator（LLM vs Host）、agentic path（static vs dynamic）、repetitiveness（single vs multi-step）

Why it matters: 这是论文的"灵魂图"，将所有 agentic AI 系统映射到三个正交维度，直接决定了 workload 选择和后续 profiling 策略

Detailed description: 图分三行，每行对应一个分类维度。(a) Orchestrator 维度区分 LLM 控制执行流（左）和 Python 代码控制（右），后者 orchestrator 运行在 CPU 上。(b) Agentic Path 区分 static（预定工具序列）和 dynamic（LLM 动态选择工具分支）。(c) Repetitiveness 区分 single-step（一次工具调用）和 multi-step（迭代循环）。

5 种代表性 workload 选择：覆盖全部三轴组合——Toolformer（LLM/Dynamic/Single）、SWE-Agent（LLM/Static/Multi）、RAG-Haystack（Host/Static/Single）、ChemCrow（LLM/Dynamic/Multi）、Web-Augmented Agent（Host/Static/Single）。工具类型涵盖 API 调用、代码执行、向量检索、文本摘要、分子生成，代表 CPU 上的通用处理模式。

2. Planning & Reasoning #

N/A — 本文不研究 agent 的 planning/reasoning 算法，而是从系统性能视角刻画 agentic workload 的 CPU-GPU 瓶颈分布。论文使用现有 agent 框架（ReAct、SWE-Agent、Haystack）的原始 planning 逻辑，未做修改。

3. Tool & Environment Interface — CPU 侧瓶颈深度刻画 #

核心发现（Figure 2）：

Figure 2: End-to-End Latency Profiling #



What it shows: 5 种 agentic workload 在两套硬件系统上的 E2E 延迟分解（按 CPU 工具 / GPU 推理 / I/O 着色）

Why it matters: 量化了 CPU 工具执行在 E2E 延迟中的主导地位——最高 88%（RAG），揭示了被忽视的系统瓶颈

Detailed description: 横轴为不同 benchmark（NQ、HotpotQA、TriviaQA 等），纵轴为运行时间（秒）。每个 bar 按颜色分解为 LLM inference（GPU）和各种 tool execution（CPU）。Sys1（GNR+RTX6000 Pro）和 Sys2（Grace+H200）对比清晰显示 GPU 升级后 CPU 瓶颈加剧。

各 workload CPU 瓶颈分布：

Workload	CPU 工具	CPU 延迟占比 (Sys1)	CPU 延迟占比 (Sys2)	瓶颈转移
RAG (Haystack)	ENNS 检索 (FAISS, 115GB C4)	82-83%	81-89%	CPU-bound 持续
Toolformer	WolframAlpha API	~12%	~23%	GPU→CPU 转移
Web-Agent (LangChain)	LexRank 摘要	48-55%	40-45%	CPU-bound
SWE-Agent	Bash/Python 执行	25-38%	25-65%	GPU→CPU 显著转移
ChemCrow	RDKit 分子生成	85-88% (heavy)	85-88% (heavy)	CPU-bound 持续

Key Takeaway 2 的系统含义：HP GPU 系统（Sys2: H200）将瓶颈从 GPU 快速转移至 CPU。Toolformer 推理占比从 88%→77%，SWE-Agent Bash 执行占比从 38%→65%。这意味着随着 GPU 越来越强，CPU 侧工具执行将成为 agentic AI 的主要瓶颈。

4. LLM Backbone Requirements #

模型选择逻辑：使用 ≤32B SLM（GPT-J-6B、GPT-OSS-20B、Qwen2.5-Coder-32B）。论文引用 Toolformer 的结论：GPT-J 6B + 工具 > OPT 66B/GPT-3 175B 在知识密集型任务上的表现。这支持 agentic AI 中 SLM + 工具的范式。

推理基础设施：vLLM v0.14.0 作为 LLM serving 后端，PyTorch 2.8.0。GPU throughput 随 batch size 增长但在大 BS 时因 KV-cache 内存/带宽限制而饱和（Figure 3a）。

关键洞察：GPU 推理的并行化效率显著高于 CPU 工具执行。在 BS=64→128 时，H200 GPU 推理延迟仅增加 1.06×，而 LexRank 摘要延迟增加 2.0×，Bash 执行延迟增加 1.94×。

5. Evaluation — COMB 和 MAS 的量化分析 #

Figure 3: Throughput Saturation #



What it shows: (a) GPU-only LLM throughput vs BS；(b) 各 agentic workload throughput vs BS；(c) BS=64→128 时各组件延迟变化

Why it matters: 揭示 CPU 并行化在 BS=128 时过早饱和的根因（core over-subscription），直接驱动 COMB 的 $B_{cap}$ 设计

Detailed description: (a) GPU throughput 随 BS 增长呈对数形状，长序列更早饱和。(b) Agentic workload throughput 在 BS=128 时全面饱和，LangChain/SWE-Agent/ChemCrow 因 MP over-subscription，Haystack 因 LLC pressure 和 disk I/O。(c) 详细对比 Web-Agent 和 SWE-Agent 在 BS=64→128 时 CPU 工具延迟 vs GPU 推理延迟的增幅差异。

COMB 效果量化（Table 3 throughput gain ratio $r(BS)$）：

Workload	$r(64)$ Sys1	$r(64)$ Sys2	$r(128)$ Sys1	$r(128)$ Sys2
Web-Agent	1.20	1.15	1.04	1.01
SWE-Agent	1.37	1.34	1.15	1.18

$r(128) \approx 1$ 意味着 BS 翻倍几乎没有吞吐增益，COMB 微批高度有效。

Figure 4: COMB Timeline #



What it shows: 三种策略的时间线对比——(a) 多进程 MP (b) 微批 (c) COMB（微批+重叠）

Why it matters: 可视化了 COMB 如何通过微批拆分避免 CPU over-subscription + 通过重叠实现 CPU-GPU 流水线

Detailed description: (a) MP baseline 将 128 请求全部并发处理，CPU 0-128 并行但 CPU 过载。(b) Micro-batching 分两批（0-31, 32-64），P50=1x 但 P90=2x。(c) COMB 在第一批 CPU 完成后间隔 s 开始第二批，CPU 和 GPU 交替执行，P50=1.2x 而 P90=1.8x。

Figure 5: COMB Standalone Evaluation #



What it shows: COMB 在独立 BS=128 处理和 P50-P90 Pareto 前沿上的效果

Why it matters: 验证 COMB 的 P50-P90 tradeoff 特性——不同 overlap interval $s$ 产生不同的最优点

Detailed description: 左中两组 bar chart 对比 Baseline/Micro-batching/COMB 在两套系统上对 SWE-Agent 和 Web-Agent 的延迟。右侧 Pareto 前沿图以 P90 为横轴、P50 为纵轴，不同 $s$ 值标记为不同颜色，圆圈标记最佳 tradeoff 点。

Open-loop COMB（Figure 6）：

Figure 6: Open-Loop COMB #



What it shows: 在开放循环系统（Poisson 到达率 $\lambda=9-15$ req/s）下，不同 $N_{cap}$ 配置的 service latency vs total latency Pareto 前沿

Why it matters: 证明 $N_{cap}=64$ 是最佳选择——service latency 最低且 queuing delay 可控

Detailed description: 横轴 service latency，纵轴 total latency。各颜色代表不同到达率 $\lambda$。Baseline $N_{max}=256$（菱形）在高负载时 service latency 急剧恶化（CPU $\rho_{CPU}=3.18$）。$N_{cap}=64$（方形）保持 $\rho_{CPU}=0.89-1.13$，service latency 降低 3.9×（P50）、total latency 降低 1.8×（P90）。

MAS 效果量化（$p_{LLM}$ 变化下的改善）：

$p_{LLM}$	受益类型	Sys1 P50/P90	Sys2 P50/P90
0.25	GPU-heavy (minority)	2.37×/2.49×	1.82×/1.78×
0.50	两者均衡	~1.3× average	1.39×/1.18×
0.75	CPU-heavy (minority)	-	2.09×/2.15×

6. Multi-Agent #

N/A — 本文不研究 multi-agent 协作，而是研究 agent serving 系统中 CPU-heavy 和 GPU-heavy 请求的混合调度。MAS 的 "multi" 是指异构请求类型的混合，不是多 agent 间的通信协调。

7. Infrastructure Impact — 对 Serving 框架的直接影响 #

Layer	Impact
Algorithm	SLM + 工具可匹配大模型效果，激励 CPU-efficient 工具替代方案研究
Kernel	GPU kernel 优化边际收益递减时需关注 CPU 侧 kernel（FAISS flat search、文本处理）的向量化优化
Framework	核心影响：agentic serving 框架需要 CPU-aware 微批调度（COMB）和异构请求感知准入控制（MAS）
LLM	agentic LLM 选型偏向 SLM（≤32B），更小模型 + 更好工具 > 更大模型
Cost	CPU 动态能耗在 CPU-heavy workload 中占 61%，需要 CPU 侧能效优化策略

8. Production Readiness #

可直接应用的部分：

• COMB 的 throughput gain ratio $r(BS)$ 分析方法可直接用于任何 agentic serving 系统的 $B_{cap}$ 选择
• MAS 的弹性队列准入控制可集成到 vLLM/SGLang 调度器中

尚需完善的部分：

• $B_{cap}$ 和 $E_{cap}$ 均为静态配置，缺乏生产环境中的自适应动态调节
• 未考虑 multi-tenant 场景下不同用户 SLO 需求的差异
• 未涉及故障恢复和请求重试机制
• 能耗 profiling 仅在 Sys2（Grace+H200）上完成，缺乏 x86 平台的能耗数据

9. Impact on AI Infra #

对 LLM serving 的思维模式影响：

本文根本性地挑战了"agentic AI 优化 = GPU 优化"的假设。当 GPU 越来越强（H200/B200），CPU 工具执行将成为主导瓶颈。这要求 serving 框架从"GPU throughput 最大化"转向"CPU-GPU balanced utilization"。

推动的特定模型能力：

• 更好的工具调用效率（减少 round-trip 次数，而非加速单次推理）
• SLM 在 agentic 场景的竞争力（GPT-J 6B + 工具 > GPT-3 175B）

新的 kernel 需求：

• CPU 侧的 FAISS/BM25 向量化 kernel
• 低延迟文本处理 kernel（避免 Python GIL 限制）
• CPU-GPU 异步数据传输 kernel

生产部署基础设施需求：

• CPU-GPU 比例需要重新考量：不再是"更多 GPU"，而是"CPU-GPU 平衡"
• 调度器需要 request-type-aware 的准入控制（不同于纯 LLM serving 的 GPU-only scheduling）
• 能耗监控需要覆盖 CPU 动态能耗（当前大多只监控 GPU）

---

作者证明 — Throughput Gain Ratio 分析框架 #

作者证明 类型: empirical sweep matrix + throughput gain ratio 分析 + utilization model

本文的 作者证明 是基于 throughput gain ratio $r(BS) = \frac{T(BS=2^n)}{T(BS/2=2^{n-1})}$ 的经验性分析框架，而非 closed-form analytical model。

Notation:

Symbol	Definition
$T(BS)$	System throughput at batch size $BS$
$r(BS)$	Throughput gain ratio: $T(2^n)/T(2^{n-1})$
$B_{cap}$	COMB micro-batch size cap
$B_{max}$	Baseline maximum batch size
$N_{cap}$	COMB concurrency cap for open-loop
$N_{max}$	Baseline concurrency cap
$\rho_{CPU}$	CPU utilization ratio
$\rho_{GPU}$	GPU utilization ratio
$E_{cap,CPU}$	MAS CPU-heavy admission cap
$E_{cap,GPU}$	MAS GPU-heavy admission cap
$E_{cap,shared}$	MAS shared reserved queue size
$s$	COMB overlap interval (seconds)
$\lambda$	Poisson arrival rate (req/s)
$p_{LLM}$	GPU-heavy request arrival probability

核心 作者证明 推导链:

1. Throughput gain ratio $r(BS)$ 决定 COMB 有效性:
2. $r(BS) \approx 1$ → 微批高度有效（BS 翻倍无吞吐增益，拆分无损）
3. $1 < r(BS) < 1.5$ → COMB 有效（重叠弥补微批拆分的吞吐损失）
4. $r(BS) > 1.5$ → 微批无效（吞吐随 BS 线性增长，拆分有损）
1. $B_{cap}$ 选择: $B_{cap} \approx 1-2 \times \#\text{CPUs}$，经验性避免 over-subscription
1. CPU utilization $\rho_{CPU}$ 与 COMB 的关系: Baseline $N_{max}=256$ 导致 $\rho_{CPU}$ 在高负载时达到 3.18（严重 over-subscription），COMB $N_{cap}=64$ 将 $\rho_{CPU}$ 控制在 0.89-1.13
1. MAS 的准入控制: 弹性上限保护少数请求类型——$E_{cap,CPU}=N_{cap}$ 来自 COMB 分析，$E_{cap,GPU}=N_{max}-N_{cap}-E_{cap,shared}$

模型→数字的一阶映射:

• Web-Agent $r(128)=1.01$（Sys2）→ 微批 P50 speedup 1.65× → COMB P50 speedup ≈ 1.7× ✓
• $\rho_{CPU}$ 从 baseline 3.18 降至 COMB 1.13 → service latency 降低 3.9× ✓
• MAS $E_{cap,CPU}=64$ 保护少数请求 → P50 改善 2.37× ✓

"无 case study 纯 作者证明 防守": 仅凭 $r(BS)$ 分析即可判断：当 $r(BS) \approx 1$ 时，CPU 并行化已完全饱和，任何大于 $B_{cap}$ 的批次都是浪费——拆分微批在数学上零损失但可通过消除 OS scheduling contention 获得延迟收益。

可攻击面:

• $r(BS)$ 是 workload-specific 的经验值，不是通用公式——不同工具、不同 CPU 架构、不同内存层次结构会产生不同的 saturation 点
• $B_{cap} \approx 1-2 \times \#\text{CPUs}$ 是经验法则，缺乏理论推导（为什么不是 $0.5 \times$ 或 $3 \times$？）
• CPU utilization $\rho_{CPU}$ 的定义和测量方法论文未明确说明，可能因不同工具的 CPU 使用模式（compute-bound vs memory-bound vs I/O-bound）而有不同含义
• MAS 的 $E_{cap,shared}=32$ 是经验选择，缺乏理论依据

---

论证链重构 (Argument Chain Reconstruction) #

Step	Premise (引用 §/Table/Fig)	Conclusion	Evidence	Load-bearing?
1	Agentic AI 工具执行大多运行在 CPU 上（§1, Table 2）	存在被忽视的 CPU 侧瓶颈	定性论证 + 文献引用	Load-bearing
2	E2E 延迟 profiling 显示 CPU 工具占 82-89%（§3.2, Figure 2）	CPU 工具执行是 E2E 延迟的主导因素	5 workloads × 2 systems 定量实验	Load-bearing
3	CPU 并行化在 BS=128 饱和，GPU 并行化不饱和（§3.3, Figure 3b/3c）	CPU 过早饱和导致 GPU under-utilization	Throughput curves + per-component latency	Load-bearing
4	Throughput gain ratio $r(128) \approx 1$（§4.1.1, Table 3）	微批拆分在 $B_{cap}$ 处无吞吐损失	定量 $r(BS)$ 计算	Load-bearing
5	COMB 微批 + 重叠 → P50/P90 改善（§5.1-5.2, Figure 5-6）	COMB 有效改善同构 workload 的延迟	独立批处理 + 开放循环实验	Load-bearing
6	MAS 弹性队列准入 → 少数请求类型保护（§5.3, Figure 7-8）	MAS 有效改善异构 workload 的公平性	3 种 $p_{LLM}$ × 2 systems 实验	Load-bearing
7	16 核 CPU 受限平台复现改善效果（§5.4.1, Figure 9-10）	方法泛化至不同 CPU-GPU 比例	Ablation 实验	Decorative (泛化性验证)

论证链特征: 6 个 load-bearing steps 构成 "characterize → quantify bottleneck → derive threshold → optimize" 的完整链路。Step 2-3 是最关键的——如果 CPU 工具执行并非 E2E 瓶颈，整个论文前提崩塌。

---

质疑假设 #

攻击 Step 2 的 premise（CPU 工具执行是 E2E 主导）:

• 有效期窗口: 当工具执行被 GPU 加速（如 GPU FAISS、GPU 文本处理）或被替代（如用 LLM 直接回答而非 RAG 检索）时，CPU 瓶颈可能消失。但当前（2025-2026）生态中 CPU-based FAISS flat search 仍然是 production RAG 的主流选择（GPU 内存放不下 115GB+ 文档库），LexRank 等 CPU 摘要器在 hallucination 控制上仍优于 LLM 摘要器，CPU 工具执行的主导地位短期不会改变。

攻击 Step 3 的 premise（CPU 并行化效率低于 GPU）:

• 论文使用 Python MP/MT 进行 CPU 并行化，Python GIL 是已知限制。如果工具用 C++/Rust 重写（绕过 GIL），或使用 sub-interpreter 等新 Python 并行方案，CPU 并行化效率可能显著提高，$r(128)$ 可能远大于 1，COMB 的有效性将降低。这是一个真实攻击点——工具的实现语言选择影响了 profiling 结论。

攻击 Step 4 的 premise（$B_{cap} \approx 1-2 \times \#\text{CPUs}$ 是通用法则）:

• 不同工具的 CPU 使用模式差异巨大：ENNS 检索是 memory-bound（LLC pressure + disk I/O），LexRank 是 compute-bound（GIL 限制），Bash 执行是 process-bound。统一的 $B_{cap}$ 法则可能对某些工具过于保守、对某些过于激进。

---

设计绑定批判 #

Binding 1（攻击 Step 2-3）: COMB 和 MAS 强绑定 "CPU 工具执行 + GPU LLM 推理" 的二阶段 pipeline 模型。当 agentic workload 包含三个或更多异构阶段（如 CPU 检索 → GPU 推理 → CPU 后处理 → GPU 再推理）时，COMB 的二阶段重叠无法直接适用。当前生态（2025-2026）大多数 agentic pipeline 确实是这种二阶段模式，但随着 multi-step agent 复杂度增加（如 coding agent 的多轮 edit-test-debug 循环），多阶段交错会变得常见。

Binding 2（攻击 Step 4）: $B_{cap}$ 和 $E_{cap}$ 强绑定静态配置。在生产环境中，workload 组成和到达率是动态变化的（白天多 RAG 查询、夜间多代码生成），静态队列上限无法适应。需要 autoscaling 机制——但这不会使核心 insight（CPU-aware scheduling）失效，只是需要从静态参数升级为动态控制器。

Binding 3（攻击 Step 2 的工具选择）: 论文选择的工具（FAISS flat search, LexRank, RDKit, Bash, WolframAlpha API）强绑定 CPU 执行。如果工具本身被 GPU 加速（FAISS GPU、GPU-accelerated text processing），CPU 瓶颈可能消失。但这不是 scheduling optimization 的失效——而是 bottleneck 位置的转移，此时 COMB/MAS 的设计原则（balanced utilization, request-type-aware admission）仍然有效，只是角色互换（GPU-aware scheduling for tool execution）。

---

时代定位 (Era Positioning) #

2025 年 agentic AI 的 low-hanging fruit（如 GPU kernel 优化、KV-cache 管理、continuous batching）已被 vLLM/SGLang 等框架充分采摘。随着 agent 工具调用成为 E2E pipeline 的核心组成部分，系统瓶颈从 GPU 推理转向 CPU 工具执行——但学术界和工业界的优化注意力仍然集中在 GPU 侧。本文代表了一个重要的"转向信号"：agentic AI 的下一代系统优化必须是 CPU-GPU co-optimization，而非 GPU-only optimization。

背景 (Context) #

现有工作要么从 GPU 视角 profiling agentic workload（Kim et al. 2025），要么仅关注外部 API 调用的 orchestration 优化（Asgar et al. 2025），都未暴露 CPU 上的工具处理瓶颈。Quinn et al. (2025) 展示 ENNS 检索占 RAG E2E 延迟 75%+，但未提出系统级调度方案。

约束推导 (Constraint Derivation) #

为何不可仅优化 GPU？ 因为 CPU 工具执行最高占 E2E 延迟 88%——GPU kernel 再快，E2E 延迟改善上限也只有 12%。

为何不可用更大 batch size 提高 CPU 并行化效率？ 因为 CPU 在 BS=128 时已 over-subscribe 所有核心，OS scheduler contention 和 context switching 导致延迟翻倍而吞吐不增（$r(128) \approx 1$）。

为何不可用多线程（MT）替代多进程（MP）？ 因为 Python GIL 限制 MT 无法在 CPU-compute intensive 工具上实现真正多核并行（Appendix B: MT 比 MP 慢 1.8×）。

破局 (Insight) #

"aha moment"：CPU 并行化的效率天花板远低于 GPU。当 batch size 超过 CPU 核心数时，CPU 吞吐饱和但 GPU 还在线性增长——这个不对称性创造了微批拆分 + 重叠执行的设计空间。就像餐厅的厨房（GPU）可以同时做 128 份菜，但服务员（CPU）只能同时端 64 份——解决方案是让服务员分两趟端，而不是让厨房等服务员端完。

核心技术壁垒 (Core Technical Barrier) #

Throughput gain ratio $r(BS)$ 的精确测量和 $B_{cap}$ 的 workload-specific 校准。COMB 的有效性完全取决于 $r(BS)$ 是否真的接近 1——这需要在具体硬件 + 具体工具 + 具体 workload 上进行精确 profiling。$r(BS)$ 不是通用常数，而是 workload-system 特异性的经验值。任何试图复现此工作的团队都必须重新测量自己系统上的 $r(BS)$ 才能选择正确的 $B_{cap}$。

实践上下文 (Deployment Context) #

• 适用场景: 任何 agentic serving 系统中 CPU 工具执行占 E2E 延迟 >30% 的场景
• COMB 最适合: 同构 workload（全是 RAG 或全是 Web-Agent），throughput gain ratio $r(BS) < 1.5$
• MAS 最适合: 异构 workload 混合（部分请求有工具调用、部分纯 LLM 推理），bursty 到达模式
• GPU 架构影响: GPU 越强（H200 vs RTX-6000 Pro），CPU 瓶颈越严重，COMB/MAS 的收益越大
• 与现有框架集成: 可集成到 vLLM/SGLang 的 scheduler 层，不需要修改 GPU kernel 或 LLM serving 逻辑

生态影响追踪 (Ecosystem Influence) #

• Sutradhara (2601.12967): 同样关注 agentic workload 的调度优化，但从 KV-cache 复用和 orchestrator-engine co-design 角度出发，与本文的 CPU-centric 视角互补
• PASTE/Act While Thinking (2603.18897): 通过 speculative tool execution（在 LLM 推理的同时预测性执行工具）减少 E2E 延迟，与 COMB 的 CPU-GPU 重叠思想有设计空间上的交集
• AgentOpt (2604.06296): 从 agent 架构层面优化工具调用效率，与本文的系统调度层面优化互补
• 本文的 "CPU bottleneck" 观察: 正在被 2025-2026 年的多篇 agentic serving 论文引用和验证（如 HEXGEN-FLOW、Justitia、ThunderAgent），逐渐成为 agentic serving 社区的共识

拆解 (Deconstruction) #

1. 输入: 混合 agentic workload 请求流（含 CPU-heavy 和 GPU-heavy 类型）
2. Compile-time 分类: 按 orchestrator/path/flow 三轴映射 workload 类型
3. Runtime profiling: 在目标硬件上测量 E2E 延迟分解 + throughput saturation 曲线
4. $r(BS)$ 计算: 确定 CPU 并行化饱和点
5. $B_{cap}$ 选择: $B_{cap} \approx 1-2 \times \#\text{CPUs}$
6. COMB 部署: 微批拆分 + 选择 overlap interval $s$（Pareto 前沿分析）
7. MAS 部署: 设置 $E_{cap,CPU}$, $E_{cap,GPU}$, $E_{cap,shared}$
8. 输出: CPU-GPU balanced 的 agentic serving 系统，service latency 和 fairness 显著改善