Target: Towards Understanding, Analyzing, and Optimizing Agentic AI Execution: A CPU-Centric Perspective (Raj et al., 2025-11) Category: agent
本文首次从 CPU 侧系统性刻画 agentic AI 的端到端延迟瓶颈，揭示 CPU 工具执行占 E2E 延迟高达 88%，并提出 COMB 和 MAS 两种调度优化 [2511.00739]。以下 8 篇论文从不同角度处理 agent serving 的效率问题，构成本文的对话群体。
| Paper | 关系 | 核心关联 |
|---|---|---|
| PASTE (2603.18897) | 最直接相关 | 同样观察到 tool 执行是 E2E 延迟主导（35–61%），但用投机执行重叠 tool 与 LLM 思考时间，而非 CPU-GPU 微批调度 [2603.18897] |
| SAGA (2605.00528) | 互补：GPU 集群 vs CPU 单机 | workflow-atomic 调度 + AEG 预测 KV cache 复用，优化 GPU 侧（KV regeneration 占 38% 时间），与本文的 CPU 侧优化正交 [2605.00528] |
| Continuum (2511.02230) | 互补：GPU 显存 vs CPU 调度 | KV cache TTL 解决多轮 agent tool-call 间隙的排队气泡（占延迟 58.2%），是 GPU 侧的等价问题 [2511.02230] |
| Paper | 关系 | 核心关联 |
|---|---|---|
| SideQuest (2602.22603) | 正交：上下文压缩 vs 调度 | 用辅助 LRM 线程做语义级 KV cache eviction（56–65% token 降幅），优化 GPU 显存而非 CPU 利用率 [2602.22603] |
| PBKV (2605.06472) | 正交：缓存预测 vs CPU 调度 | GraphSAGE 多步预测驱动分层淘汰 + 保守预取，针对 GPU 端缓存命中率（27%→69%），不涉及 CPU 工具执行 [2605.06472] |
| Paper | 关系 | 核心关联 | ||
|---|---|---|---|---|
| Claude Code 解剖 (2604.14228) | 验证性上游 | 源码分析揭示 "1.6% 决策逻辑 + 98.4% 确定性基础设施" 范式——大量基础设施代码（tool dispatch, context compaction, permission）运行在 CPU 上，验证了本文 CPU 瓶颈论点 [2604.14228] | ||
| Structured Graphs (2604.11378) | 理论框架 | 将 agent 执行统一为 scheduler 模型，多就绪单元并行（$\ | \mathcal{U}\ | \geq 1$）意味着更多并发 tool 执行→更大 CPU 压力，本文的 CPU 饱和分析为此提供量化基础 [2604.11378] |
| CMV (2602.22402) | 弱相关：应用层 | DAG 会话状态管理 + 三遍裁剪，在 prompt/context 层操作，与 CPU 系统调度层距离较远 [2602.22402] |
在整个 related cluster 中，本文是唯一从 CPU 侧量化 agentic workload 瓶颈的工作。其余 7 篇（除 CMV 外）均聚焦 GPU 侧资源管理：
本文的核心 delta 是 throughput gain ratio $r(BS)$ 分析框架：当 $r(BS) \approx 1$ 时，batch size 翻倍几乎没有吞吐增益，微批拆分在数学上零损失 [2511.00739]。这个度量为 COMB 的 $B_{cap}$ 选择提供了经验性但可操作的决策依据——cluster 中无其他论文提出等价工具。
本文与 GPU 侧论文的发现构成一个互补但有张力的图景：
矛盾调和：两者在各自实验范围内都正确。SAGA 的 38% KV regeneration 发生在多轮 agent 的 GPU serving 层（tool-call 间隙的 cache churn），而本文的 88% CPU 瓶颈发生在 tool 执行本身（FAISS 检索、LexRank 摘要等）。差异根源在于 workload 选择和测量层次：SAGA 测量的是 GPU serving 内部的效率损失，本文测量的是包含 CPU 工具在内的端到端延迟分布。两者攻击不同层次的瓶颈。
| 系统 | 调度单元 | 调度维度 | 静态/动态 |
|---|---|---|---|
| 本文 (COMB) | micro-batch | CPU-GPU pipeline | 静态 $B_{cap}$ |
| 本文 (MAS) | 请求类型 | CPU-heavy vs GPU-heavy 准入 | 静态 $E_{cap}$ |
| SAGA | workflow (AEG) | 跨 worker session affinity + fairness | 动态 WA-LRU + AFS |
| Continuum | program (multi-turn) | KV cache TTL | 动态 $\tau^*$ |
| PASTE | tool call | 投机执行 pipeline | 动态 pattern matching |
| PBKV | 缓存节点 | $K$-step 预测评分 | 动态预测 |
本文的调度粒度（micro-batch / 请求类型）是最粗的——SAGA 到工作流、Continuum 到单请求、PASTE 到单 tool call、PBKV 到单缓存节点。粗粒度换来了实现简单性，但限制了对个体请求特征的适应能力。
本文的核心发现——CPU 并行化效率远低于 GPU [2511.00739]——高度依赖实验中使用 Python MP/MT 的实现选择。论文自身在附录 B 指出 MT 比 MP 慢 1.8× [2511.00739]。如果工具用 C++/Rust 重写（绕过 GIL），或使用 Python sub-interpreter 等新并行方案，$r(128)$ 可能远大于 1，COMB 的有效性将显著降低。
反驳：当前（2025-2026）主流 agent 生态中，FAISS、LexRank、RDKit 等工具的 Python 绑定是事实标准。论文测量的是 _工程现实_，而非理论极限。但这意味着结论有明确的时效窗口——随着工具生态向 native 并行迁移，CPU 瓶颈的严重程度会降低。
88% 的极端 CPU 占比来自 RAG-Haystack 的 FAISS flat search over 115GB C4 corpus [2511.00739]。这是一个 _worst-case_ 配置——生产环境通常使用 FAISS IVF/HNSW（更快的 CPU 索引）或 GPU-FAISS。同样，ChemCrow 的 RDKit 分子生成（85–88% CPU）是一个高度特化的 workload。
论文的 5 个 workload 覆盖了极端光谱：Toolformer（仅 12% CPU，Sys1）到 RAG（89% CPU）。但论文主要叙事围绕高 CPU 占比场景展开，对 Toolformer 这种 GPU-dominant 场景的 COMB/MAS 收益讨论不足。
$B_{cap} \approx 1-2 \times \#\text{CPUs}$ 和 $E_{cap,shared} = 32$ 均为经验选择，缺乏理论推导 [2511.00739]。在生产环境中：
对比 SAGA 和 Continuum：SAGA 的 WA-LRU 权重虽然也需要校准，但 Table 9 显示 <8% TCT 变化的鲁棒性 [2605.00528]。Continuum 的 TTL 是从工具延迟分布动态计算的 [2511.02230]。本文的静态参数方案在 adaptiveness 上落后于同期工作。
仅使用 ≤32B SLM（GPT-J-6B, GPT-OSS-20B, Qwen2.5-Coder-32B）[2511.00739]。当模型增大到 70B+：
本文不涉及 multi-turn agent 的 KV-cache 状态管理和跨 turn 工具调用调度 [2511.00739]。而 Continuum 的实验显示排队气泡占总延迟 58.2%（multi-turn 场景）[2511.02230]，SAGA 测量到 38% KV regeneration [2605.00528]。本文的分析限于 single-turn 或 batch 处理，在真实 multi-turn agent serving 中 CPU 和 GPU 瓶颈的交互可能更复杂。
本文代表了 agentic serving 优化从 "GPU-only" 到 "CPU-GPU balanced" 的范式转向起点 [2511.00739]。在以下演化路线中，本文处于 Phase 2：
Phase 1 (2023-2024): GPU kernel 优化 + KV cache 管理 (vLLM, SGLang, continuous batching)
Phase 2 (2025): CPU 瓶颈暴露 + CPU-aware scheduling (本文, PASTE)
Phase 3 (2025-2026): Workflow-level co-optimization (SAGA, Continuum, PBKV)
Phase 4 (future): 端到端 heterogeneous scheduling (CPU + GPU + tool-specific accelerator)
本文的独特价值在于 在 Phase 2 提供了第一个系统性的 CPU 瓶颈量化。PASTE 同期（2026-03）也观察到 tool 执行占 35–61% [2603.18897]，但 PASTE 的回应是投机执行（时间维度优化），而非系统调度（资源维度优化）。两者的共存表明 CPU 瓶颈是真实且多面的。
本文的 COMB/MAS 可与 cluster 中其他系统在不同层叠加使用：
Application Layer: CMV (context trimming) / Claude Code (5-layer compaction)
Agent Framework: SGH (DAG scheduling) / PASTE (speculative tool execution)
Serving Layer: Continuum (KV TTL) / SAGA (workflow-atomic scheduling)
CPU Scheduling: COMB (micro-batch) / MAS (heterogeneous admission) ← 本文
GPU Cache: SideQuest (semantic eviction) / PBKV (prediction-based eviction)
本文是唯一占据 "CPU Scheduling" 层的工作，与上下层方案不冲突。
COMB 的微批调度（CPU 侧）和 Continuum 的 TTL 管理（GPU 侧）[2511.02230] 可以联合优化：在 COMB 微批重叠的间隙（CPU 阶段）精确设定 KV cache TTL，避免 GPU 等待 CPU 完成时 KV cache 被过早驱逐。目前两者独立设计，不感知对方的调度决策。
本文的 $B_{cap} \approx 1-2 \times \#\text{CPUs}$ 是全局静态值 [2511.00739]。PBKV 的分层设计思路（确定性护栏 + 概率评分）[2605.06472] 可迁移到 CPU 调度：per-tool-type 的 $B_{cap}$ 基线（从历史 $r(BS)$ 学习）+ 全局内存压力信号的动态调整。退役工作流检测（PBKV 的 lifecycle-aware eviction）类比到 CPU 侧：已完成的 tool 进程立即释放 CPU core quota。
PASTE 的投机 tool 执行 [2603.18897] 和本文的 COMB 可以 co-design：PASTE 预测下一个 tool 并在 LLM 思考期间投机执行，COMB 确保投机执行不会 over-subscribe CPU cores。目前 PASTE 的投机调度仅考虑 slack 资源预算（Eq. 1），不感知 CPU 并行化饱和点 $B_{cap}$。融合两者需要把 $r(BS)$ 纳入投机调度的资源约束。
SAGA 的 Agent Execution Graph [2605.00528] 编码了每个 tool 的类型和延迟分布。这些信息可用于 CPU-GPU 资源比例的 capacity planning：给定 AEG 的 tool-type 分布，预测 CPU-heavy vs GPU-heavy 请求的到达比例 $p_{LLM}$，动态调整 MAS 的 $E_{cap,CPU}$/$E_{cap,GPU}$。本文的 MAS 使用静态 $p_{LLM}$ 假设，AEG 可以提供 workload-aware 的动态信号。
本文预测 "随着 GPU 越来越强，CPU 侧工具执行将成为主要瓶颈" [2511.00739]。但另一条演化路径是 工具本身迁移到 GPU（GPU-FAISS、GPU text processing）。此时瓶颈从 CPU 转回 GPU，但 COMB/MAS 的设计原则（balanced utilization, request-type-aware admission）仍然有效——只是角色互换为 "GPU tool execution scheduling"。SideQuest 的 KV cache eviction [2602.22603] 此时需要与 GPU tool execution 竞争显存，创造新的资源冲突。这个 "GPU tool vs KV cache" 的显存竞争尚无人探索。
本文发现 CPU 动态能耗在 CPU-heavy workload 中占系统总动态能耗高达 61% [2511.00739]。将 COMB 的微批调度与 CPU DVFS（动态电压频率调节）结合——在 GPU 阶段降低 CPU 频率、在 CPU 阶段全速运行——可能实现显著的能效改善。cluster 中无其他论文触及能效维度。