一、论文档案：谁做的、测了什么、站在什么立场
先交代出处与利益相关，再看数字——这是 CPU 厂商参与署名的测量研究，结论方向与 CPU 侧叙事一致，但全部数据公开且代码可复现。
| 项目 | 内容 |
|---|
| 标题 | Towards Understanding, Analyzing, and Optimizing Agentic AI Execution: A CPU-Centric Perspective |
| 作者 | Ritik Raj、Ishita Vohra、Tushar Krishna（Georgia Tech）；Souvik Kundu、Hong Wang（Intel） |
| 版本沿革 | v1（2025-11-01）题名为《A CPU-Centric Perspective on Agentic AI》，单机（Emerald Rapids + B200），优化方法原名 CGAM / MAWS；v3（2026-04-16）改为现名，扩展为双系统对照，方法更名 COMB / MAS |
| 被测模型 | GPT-OSS-20B、GPT-J-6B、Qwen2.5-Coder-32B（vLLM 0.14.0，PyTorch 2.8.0）——均为 ≤32B 的开源模型 |
| 实验纪律 | 每种负载运行 5 次取统计；到达过程为开环 Poisson + ON/OFF 突发模型；能耗为动态能耗（扣除待机） |
| 自我声明 | 论文称系「首个对异构 CPU-GPU 系统上 Agentic AI 执行的端到端时延、吞吐与能耗瓶颈进行量化分析的工作」 |
| 组件 | Sys 1：强 CPU + 中端 GPU | Sys 2：强 CPU + 强 GPU |
|---|
| CPU | 64 核 Intel Granite Rapids（至强 6 代） | 72 核 NVIDIA Grace |
| CPU 内存 | DDR5 512 GB | LPDDR5 480 GB |
| GPU | RTX PRO 6000 Blackwell（GDDR7 96 GB） | H200（HBM3e 96 GB，GH200 系统） |
| 设计意图 | 两套系统刻意制造 GPU 档差，用于观察「GPU 变强后瓶颈向哪移动」；另有第三平台（16 核 Emerald Rapids + 同款 RTX 6000 Pro）做 CPU 受限消融 |
利益相关提示：五位作者中两位来自 Intel，Sys 1 恰为「Intel CPU + NVIDIA 中端 GPU」组合，其「强 CPU 可打平旗舰 GPU」的结论（Takeaway 1）对 CPU 采购叙事有利。数据本身已开源、方法披露完整，可独立复核——引用时应注明作者构成。
二、编译期刻画：三个正交维度 × 五种代表负载
论文不从「Agent 能力」分类，而从直接影响系统指标的算法结构分类——这是它能落到硬件结论的原因。
维度 1 · 编排者
谁在控制流程
- LLM 编排：模型自己决定调工具还是收尾（ReAct、AutoGPT、CAMEL、MetaGPT）
- 宿主代码编排：Python 控制流决定下一步，LLM 只是无状态推理引擎（LangChain、Semantic Kernel、Haystack、LlamaIndex）
维度 2 · 执行路径
路径是否预先确定
- 静态路径：按预定流水线走（Haystack、LlamaIndex）
- 动态路径：运行时根据中间结果选路（Reflexion、LATS）——编排者握有路径决策权
维度 3 · 重复度
与环境交互几轮
- 单步：一次工具调用即可交差（RAG、单轮 QA）
- 多步：迭代感知-规划-行动循环（WebArena、AgentBench、游戏与机器人）
五种代表负载：覆盖三维组合与 CPU 工具谱系
| 负载 | 编排 | 路径 | 步数 | CPU 侧工具（被画像对象） | 应用与基准 |
|---|
| RAG（Haystack） | 宿主代码 | 静态 | 单步 | ENNS 精确近邻检索，115 GB C4 语料 | 开放域问答：NQ、HotpotQA、TriviaQA |
| Toolformer | LLM | 动态 | 单步 | WolframAlpha API（I/O 型） | 数学：ASDiv、SVAMP、MAWPS |
| Web-Augmented Agent（LangChain） | 宿主代码 | 静态 | 单步 | LexRank 词法摘要（计算密集）＋URL 抓取 | 联网问答（对标主流聊天机器人的搜索功能）：freshQA、QASC |
| SWE-Agent（mini 版） | LLM | 静态 | 多步 | Bash / Python 执行（文件 I/O + 跑代码） | 编程：APPS、BigCodeBench |
| ChemCrow | LLM | 动态 | 多步 | RDKit 构象生成（计算密集）＋反应工具 | 化学研究：中型 / 重型分子基准 |
选样逻辑：既有事实型、编程型、科学计算型任务，又覆盖检索（内存密集）、API（I/O 型）、本地执行（计算密集）三类 CPU 负载形态；Web-Augmented Agent 的吞吐实验用本地缓存 HTML 替代真实 URL 抓取，以剔除网络方差——这一点在解读其数字时必须记住。
三、运行时画像（一）：CPU 工具最高吃掉 88% 的端到端时延
同一份负载在两套硬件上各跑一遍——GPU 升档之后，瓶颈不是消失了，而是搬家了。
CPU 工具占端到端时延比例（%，按论文 Figure 2 与 §3.2 文字数据整理）。RAG 三基准取 NQ/HotpotQA/TriviaQA 区间；Web Agent 取 freshQA/QASC 区间；SWE-Agent 取 APPS/BigCodeBench 区间与 Sys 2 峰值；ChemCrow 取重分子构象生成占比。Toolformer 是唯一 GPU 主导的负载（LLM 占 88%→77%），作为对照列入。
逐负载明细（原文数字，未做平均化处理）
| 负载 | Sys 1（GNR + RTX 6000 Pro） | Sys 2（Grace + H200） | 瓶颈判词 |
|---|
| RAG（ENNS 检索） | NQ 83%、HotpotQA 81%、TriviaQA 82% | 最高 89% | 检索即全部；换 GPU 几乎无收益 |
| Toolformer | LLM 推理占 ≈88%（CPU 工具 ≈12%） | LLM 占 77%（CPU 工具 ≈23%） | 唯一的 GPU 主导对照组 |
| Web Agent（LexRank 摘要） | freshQA 55%、QASC 48% | 40–45% | 剔除网络后方差后，两系统 E2E 持平——限制抓取网站数比换模型更快 |
| SWE-Agent（Bash/Python） | APPS 38%、BigCodeBench 25% | 最高 65% | GPU 越强的系统反而更 CPU 受限 |
| ChemCrow（RDKit 构象） | 重分子 85%；中分子 LLM 占 58% | 重分子 88%；中分子 LLM 占 53% | 重分子下两系统性能几乎相同 |
要点 1 · 强 CPU + 中端 GPU 可以打平旗舰 GPU
在工具主导型负载上，Sys 1（强 CPU + 中端卡）的端到端时延与 Sys 2（H200）相当。对 RAG、联网问答、化学计算这类业务，预算优先给 CPU 与内存，而非追旗舰 GPU——这是论文给出的最直接的成本结构结论。
要点 2 · GPU 升级会把瓶颈「推」向 CPU
当工具时延与推理时延可比时，换强 GPU 只压缩了 LLM 段，CPU 段纹丝不动，占比被动放大（SWE-Agent 25–38% → 65%；Toolformer LLM 占比 88%→77%）。继续加 GPU 的边际收益递减，除非 CPU 侧同步优化。
四、运行时画像（二）：CPU 并行化「早熟饱和」，拖住 GPU 利用率
单请求看时延，批量服务看吞吐——CPU 的并行效率结构性低于 GPU，批还没开大，CPU 先饱了。
GPU 纯推理吞吐（vLLM TPS）随批大小持续增长至 BS=512 仍未完全饱和（论文 Table 4，LangChain 负载 LLM 段，对数横轴）。GPU 侧「还能吃」，问题在 CPU 侧「喂不动」。
批大小从 64 加到 128 时各环节平均时延的膨胀倍数（论文 §3.3.2）：LLM 推理在 H200 上仅 +6%，而 Bash 多进程在 Grace CPU 上 +94%——同一台机器上，CPU 并行先触顶（核心超订、调度竞争、上下文切换）。
CPU 并行策略的选择纪律（论文的实操结论）
| 工具类型 | 并行策略 | 原因 |
|---|
| ENNS 检索（RAG） | 多线程 MT | 内存占用极高，线程共享地址空间 |
| WolframAlpha API（Toolformer） | 多线程 MT | I/O 型负载，创建与切换开销低 |
| LexRank 摘要 / Bash 执行 / RDKit 构象 | 多进程 MP | 计算密集型受 Python GIL 限制，线程拿不到真多核 |
要点 3：CPU 并行化效率结构性低于 GPU——参考数据：双路 Haswell 节点仅用每路 4 个进程就达到 STREAM 峰值带宽的 80% 以上；进程数超过物理核（超订）后，操作系统调度竞争与上下文切换开始主导。Agentic 负载的吞吐因此被 CPU「早熟饱和」封顶，连带拉低昂贵 GPU 的利用率。Sys 2 上 BS=128 时 H200 的 LLM 吞吐是 RTX 6000 Pro 的 1.9–2.8×，但 CPU 段两个系统同样卡壳。
五、优化之一 COMB：给 CPU 设并发上限，微批次间流水重叠
针对同质负载（单一请求类型）——不让 CPU 超订，让 CPU 与 GPU 同时在岗。
机制：三步看懂 COMB
1.65×
独立批处理 P50 提速（Web Agent，BS=128→B_cap=64，Sys 2）；因吞吐增益比 r(128)≈1，微批次高度有效
2.9× / 3.9×
开环 λ=13 req/s 下服务时延 P50 / P90 降幅；总时延同步降 1.6× / 1.8×（N_cap=64 为甜点值）
1.7×
开环负载下系统吞吐提升；N_cap=48 太极端（排队暴涨），82/96 则服务时延变差
有效性判据：先算吞吐增益比 r(BS)
- r ≈ 1吞吐已完全饱和 → 纯微批次最有效，P50 可省约 2×（Web Agent 属此类）
- 1 < r < 1.5部分饱和 → 用带重叠的 COMB，在 P50–P90 前沿上选点（SWE-Agent r(128)=1.15/1.18 属此类，纯微批次反而拖慢 P90 至 0.69–0.72×）
- r > 1.5未饱和 → 微批次无效，直接开大批即可
边界（16 核 Emerald Rapids 消融）：CPU 核心受限平台上，微批次单独即可把首批完成时间从 51.5s 压到 26.4s（1.95×），而 COMB 的重叠（s=16s）因 CPU 争抢反使首批升到 40.1s——CPU 越紧张，重叠窗口越要保守。该方法不是无前提的银弹。
六、优化之二 MAS：混合负载下按类型准入，保住少数派
针对异质负载（CPU 重 + GPU 重混合到达）——真实服务器从来不是单一流量。
机制：两条互补策略
- 按请求类型的并发准入：总预算 N_max=224（贴近两系统 GPU 饱和拐点）切为三块——CPU 重准入上限 E_cap,CPU=64（来自 COMB 开环研究）、GPU 重 E_cap,GPU=128、共享预留队列 32（吸收突发，保持功不空转）
- 轮转排水 + 弱势保护：槽位空出时在等待队列间轮转取请求；无论哪种类型是少数派，都为其保留最低并发，防止一种流量垄断准入
负载模型：Poisson 到达 × 双态 ON/OFF 突发（每 32 个请求切换相位），GPU 重到达概率 p_LLM ∈ {0.25, 0.50, 0.75}，稳态取 1500 请求中的 400 个统计。
实测结果（相对 FCFS 基线）
| 请求混合 | Sys 1（GNR） | Sys 2（Grace+H200） |
|---|
p=0.25
GPU 重为少数派 | GPU 重时延最高改善 2.37× / 2.49×（P50/P90），CPU 重基本不变 | GPU 重最高改善 1.82× / 1.78× |
p=0.50
均衡混合 | — | GPU 重 1.39×/1.18×，CPU 重约 1.1× |
p=0.75
CPU 重为少数派 | — | CPU 重在 λ=24 时改善 2.09× / 2.15×，GPU 重全程持平 |
含义：FCFS 下，CPU 重流量爆发会把 CPU 打满，GPU 重请求排队空等——即使 GPU 是闲的。MAS 用准入隔离把「谁等谁」变成策略问题，而非到达顺序问题。
七、能耗画像：CPU 动态能耗最高占 61%，能效口径必须改写
Sys 2 待机功率已露端倪：Grace CPU 140 W vs H200 GPU 142 W——CPU 从来不是陪衬。
CPU 动态能耗占系统动态能耗比例（论文 Figure 11，动态能耗 = 运行功耗 − 待机功耗；Sys 2 经模块功率与 GPU 功率相减获得 CPU 部分）。RAG 全批次恒定 61%；Web Agent 43–57%（BS=32 达峰）；ChemCrow 峰值 60%（BS=32）；GPU 主导的 Toolformer 与 SWE-Agent 仅 10–18%。
论文结论：CPU 动态能耗在 CPU 中心型负载下占比显著（最高 61%），面向 Agentic AI 数据中心的能耗优化策略必须把 CPU 纳入一等公民。这与本报告体系此前引用的 Agents/MW 口径形成直接对照——后者按机柜功率预算折算 GPU 侧容量，CPU 侧工具容量与能耗均未进入指标。
八、与本报告体系的衔接：这篇论文补上了哪块拼图
① 补上了 AA-AgentPerf 刻意隔离掉的变量
AA-AgentPerf 用「中位 1 秒模拟工具时延」把 CPU 工具执行从评测中隔离（真实工具评测仅列入其后续计划）。本文实测表明，被隔离掉的恰是最大的时延变量之一（最高 88%）——两个结论并读才是完整图景：模型服务级时延看 AA-AgentPerf，工具执行时延看本文。
② 「CPU 厂商在测 Agent」的真实样本
此前 EdgeBench 调查中澄清过：RISC-V 芯片设计只是任务题材，被测的是模型。本文才是真正意义上的「CPU 厂商测 Agent」——Intel 工程师参与署名，测的是 Agent 执行对 CPU 的压力，其竞争力主张是「工具主导负载下强 CPU + 中端 GPU 可打平旗舰 GPU」。引用该结论需同时引用作者构成。
③ 能效指标口径的修正依据
MLPerf Agentic 与 AA-AgentPerf 的 Agents/MW 均以机柜电力预算折算推理侧容量。本文给出反证：RAG 类负载 CPU 动态能耗恒定占 61%。面向检索/工具密集型业务做容量规划时，只按 GPU 口径换算会系统性高估可用容量。
④ 给「业务场景洞察页」的指标补充
S2（对话服务）、S3（知识研究）、S4（流程自动化）三个场景的「并发会话容量」「交付周期」指标，本文提供了机制级解释：容量上限常由 CPU 早熟饱和决定，而非 GPU；调度层优化（COMB/MAS）可在不换硬件的前提下给出 1.7–3.9× 的服务时延空间。
九、如实说明：这些数字的适用边界
引用前请逐条核对：
① 被测模型均为 ≤32B 开源模型（GPT-OSS-20B / GPT-J-6B / Qwen2.5-Coder-32B），作者立场是「SLM 适合 Agentic」；换用前沿大模型后 LLM 段占比会回升，CPU 占比结论的强度随之下降——论文自己的 Toolformer 对照组（LLM 占 77–88%）已说明这一点。
② 工具谱系有限（5 种），不含沙箱/容器启动开销、不含鉴权与外部 API 计费链路；Web Agent 的吞吐实验以本地缓存 HTML 替代真实抓取，网络方差被刻意剔除。
③ 负载为合成开环到达（Poisson + ON/OFF），并非生产流量日志；P50/P90 改善倍数对应特定 λ 与 N_max 配置，不是普适常数。
④ 能耗为「动态能耗」（扣除待机），不含散热与供电损耗；Sys 2 的 CPU 能耗由模块功率减 GPU 功率间接获得。
⑤ 两位作者来自 Intel，且 Sys 1 配置（Intel CPU + NVIDIA 中端 GPU）恰好支撑对 CPU 采购有利的结论；数据与代码已开源（GitHub: ritikraj7/cpu-centric-agentic-ai），建议复核后引用。