1. 从一场算力失衡说起为什么CPU突然又被重视了过去两年只要聊到AI话题几乎都绕不开GPU。大模型训练要卡、推理要卡、微调要卡连跑个本地小模型都得先看看显存够不够。显卡一度成了硬通货CPU反而像个配角默默在机箱角落里处理那些“杂活”。但如果你最近真正动手搭过Agent项目会发现一个很有意思的反转GPU依然吃香但CPU的调度价值被重新拉回了台面。我自己是从去年开始密集做Agent相关的东西从最简单的工具调用到多轮任务编排再到带记忆和检索的复杂流程踩过的坑基本都和“算力分配”有关。一开始我也觉得Agent嘛核心就是模型模型跑在GPU上CPU能有多大事结果实测下来很多Agent系统的瓶颈根本不在推理速度而在任务调度、状态管理、工具调用、上下文拼接、并发控制这些看起来不起眼的环节。这些活恰恰是CPU的主场。这篇文章想聊的就是标题里那个有点反直觉的现象Agent拯救了CPU。不是GPU不重要了而是在GPU的盛宴里CPU重新找到了自己的位置。我会从Agent的架构特点讲起拆解为什么CPU在Agent场景下变得关键再落到具体的实操配置、参数调优、常见问题排查。如果你正在做Agent开发或者只是好奇为什么最近“CPU智能核心调度”这类词又热了起来这篇应该能给你一些能直接抄作业的东西。适合谁看做AI应用开发的、搭过Agent框架的、被GPU显存和CPU占用同时折磨过的、以及想搞清楚“Agent到底吃哪块硬件”的朋友。不需要你精通底层但最好动手跑过至少一个Agent项目这样看后面的实操会更有感觉。2. Agent到底改变了什么从“单次推理”到“持续编排”2.1 Agent不是一次模型调用而是一套持续运行的系统很多人对Agent的第一印象是“让模型自己调工具”。这个理解没错但太浅了。一个真正跑起来的Agent本质上是一个持续运行的状态机。它要维护对话历史、要决定下一步调哪个工具、要解析工具返回、要判断任务是否完成、要在失败时重试、要在多轮之间保持上下文一致。这些动作里只有“模型推理”那一步是GPU干的其余全是CPU在扛。我拿一个实际场景举例。假设你做一个“自动整理会议纪要并生成待办”的Agent。流程大概是接收录音转写文本 → 调用模型提取关键信息 → 判断是否需要查日历 → 调用日历工具 → 解析返回 → 生成待办 → 写入任务系统 → 回复用户。这一串下来模型可能只被调用了两三次但中间的文本清洗、格式转换、工具路由、异常处理、状态持久化全是CPU在跑。GPU在等CPU在忙。提示如果你用time命令统计过一个Agent任务的耗时分布会发现模型推理往往只占30%到50%剩下的全是CPU侧的编排开销。这个比例在工具调用密集的场景下会更夸张。2.2 GPU负责“想”CPU负责“管”这个分工可以用一个生活化的类比来理解。GPU像一个超级能算的专家你给他一个问题他秒出答案。但专家不负责安排日程、不负责接电话、不负责把答案整理成文档。CPU就是那个助理负责把任务拆好、把材料准备好、把专家的答案接过来、再分发到该去的地方。在传统的大模型推理场景里助理的活很少因为基本就是“问一句答一句”。但Agent场景下助理的活暴增。它要管的东西包括任务队列多个用户请求同时进来谁先谁后怎么并发。上下文窗口历史对话、工具返回、系统提示怎么拼、怎么截断、怎么压缩。工具路由根据模型输出决定调哪个工具参数怎么传超时怎么处理。状态持久化任务进行到哪一步了崩了怎么恢复。重试与降级工具挂了怎么办模型输出格式不对怎么办。这些全是CPU密集型或者IO密集型的活。GPU再快也帮不上忙。这就是为什么很多Agent项目在GPU配置很高的情况下整体吞吐依然上不去——瓶颈在CPU侧的编排逻辑。2.3 为什么“Agent拯救CPU”这个说法成立说“拯救”可能有点戏剧化但逻辑是通的。在纯推理场景里CPU的角色被压缩到极致甚至有人觉得用ARM板子都能跑。但Agent把CPU的价值重新放大了。它让CPU从“数据搬运工”变成了“任务指挥官”。这个转变带来的直接影响是CPU核心数和主频重新变得重要。多核可以并行处理多个Agent会话高主频可以加快单会话的编排速度。内存带宽和容量成为关键。Agent要维护大量上下文和状态内存不够直接OOM。调度策略影响整体吞吐。怎么把Agent任务分配到不同核心怎么和GPU推理排队配合成了新的优化点。我实测过一个对比同一套Agent代码在8核CPU和16核CPU上跑并发10个会话时16核的端到端延迟低了将近40%。GPU是同一张卡模型也是同一个差别全在CPU侧的并发处理能力。这个数据不一定普适但方向是明确的。3. CPU在Agent架构里的四个关键角色3.1 角色一任务调度与并发控制Agent系统通常要同时服务多个用户或任务。每个任务是一个独立的状态机有自己的上下文、工具调用栈和超时计时器。CPU要做的第一件事就是把这些任务合理地分配到线程或协程上。我见过不少项目直接用单线程跑Agent循环结果一个任务卡在工具调用上后面全堵住。正确的做法是用异步IO加线程池把阻塞操作比如HTTP请求、文件读写扔到后台主循环只负责状态推进。Python里可以用asyncio配合run_in_executorGo里直接用goroutineRust里用tokio。核心思想是别让CPU闲着等IO也别让IO堵住CPU。这里有个参数值得注意并发度不是越高越好。我试过把并发调到64结果CPU上下文切换开销暴涨整体吞吐反而下降。后来稳定在“CPU物理核心数×2”左右效果最好。这个值可以用压测慢慢调但起点可以从这个公式开始。3.2 角色二上下文管理与内存操作Agent的上下文窗口是有限的但对话历史和工具返回会不断累积。CPU要负责拼接、截断、压缩、检索这些上下文。每一步都是内存操作而且往往涉及字符串处理非常吃CPU。举个例子一个带RAG的Agent每次用户提问都要先从向量库检索相关文档再把文档片段拼进提示词。检索本身可能是GPU或专用库干的但拼接、去重、排序、截断这些活是CPU干的。如果上下文有几十KB每轮都重新拼接CPU开销很可观。我的经验是能缓存的就别重算。比如系统提示词和固定工具描述可以预先拼好存起来每轮只拼动态部分。再比如历史对话可以用滑动窗口加摘要的方式别每次都把全量历史塞进去。这些优化看着小但在高并发下能省出大量CPU时间。3.3 角色三工具调用与外部交互Agent的核心能力之一是调工具。调工具意味着发网络请求、读写文件、查数据库。这些操作本身不耗CPU但等待和解析耗CPU。尤其是当工具返回是JSON或XML时解析和校验的开销不小。我踩过的一个坑是工具返回的JSON特别大每次都用通用解析器全量解析结果CPU直接飙到100%。后来改成流式解析加字段裁剪只取需要的字段CPU占用直接降了一半。另一个坑是没设超时一个工具挂了整个Agent线程卡死。后来统一加了超时和重试稳定性好了很多。注意工具调用的超时时间要根据工具类型区分。查数据库可以短一点比如2秒调外部API可以长一点比如10秒。别用一个全局超时打天下。3.4 角色四状态持久化与恢复Agent任务可能跑很久中间可能崩可能被重启。CPU要负责把状态存下来崩了能恢复。这个活看着简单但做不好很影响性能。我见过每步都写数据库的IO直接成瓶颈也见过完全不存的崩了全丢。比较稳的做法是定期快照加事件日志。关键状态变更写日志定期做全量快照。恢复时先加载快照再重放日志。这样既保证可靠性又不至于每步都写盘。存储介质用SSD别用机械盘否则IO等待会把CPU拖死。4. 实操搭一个CPU友好的Agent运行时4.1 环境准备与基础依赖这一节我拿Python举例因为生态最全大家也最容易复现。其他语言思路类似。基础依赖包括pip install asyncio aiohttp pydantic fastapi uvicorn如果你要用本地模型再加transformers和torch。但注意模型推理尽量单独进程或单独服务别和Agent编排混在一个进程里否则GIL和显存管理都会让你头疼。我的推荐架构是Agent编排层用Python跑在CPU上模型推理层用独立服务比如vLLM或TGI跑在GPU上两层之间用HTTP或gRPC通信。这样CPU和GPU各干各的互不拖累。4.2 核心循环的写法与参数Agent主循环的伪代码大概是这样async def agent_loop(task): while not task.done: context build_context(task) action await call_model(context) if action.type tool: result await call_tool(action.name, action.args) task.history.append(result) elif action.type finish: task.done True return task.result看着简单但每个await背后都有讲究。call_model要设超时call_tool要设超时和重试build_context要控制长度。我一般会给这几个操作分别设参数操作超时重试备注模型调用30s1次超时后降级到小模型工具调用10s2次指数退避上下文构建无无但要限长状态写入5s3次异步写不阻塞主循环这些值不是固定的要根据你的实际场景调。但有个原则任何可能阻塞的操作都要有超时否则一个慢请求就能拖垮整个Agent。4.3 并发模型的选择Python里做并发绕不开GIL。但Agent场景下大部分时间在等IOGIL的影响没那么大。用asyncio就够了。如果确实有CPU密集的活比如大文本处理可以扔到ProcessPoolExecutor里。我实测下来asyncio加aiohttp的组合在100并发下CPU占用大概60%端到端延迟稳定在2秒以内。换成多线程反而更差因为线程切换开销大。所以IO密集型用异步CPU密集型用多进程这个原则在Agent场景下依然成立。4.4 和GPU推理服务的配合Agent编排层和GPU推理层之间最好用批处理加队列的方式配合。别每个Agent请求都单独调一次模型那样GPU利用率很低。可以攒一批请求一起发给推理服务拿回结果再分发。我一般会在编排层加一个请求队列攒到一定数量或等一定时间就发一批。批量大小和等待时间要权衡批量太大延迟高批量太小GPU吃不饱。我的经验值是批量8到16等待时间10到20毫秒。这个可以用压测调但起点可以从这里开始。提示如果你的推理服务支持连续批处理continuous batching那就不用自己攒批了直接发就行。vLLM和TGI都支持开起来能省不少事。5. 性能调优让CPU和GPU各就各位5.1 先定位瓶颈再谈优化优化最怕瞎猜。我一般先用py-spy或cProfile看CPU时间花在哪用nvidia-smi看GPU利用率。如果GPU利用率低但CPU高说明编排层是瓶颈如果GPU高CPU低说明推理是瓶颈如果两个都低说明IO或锁有问题。我遇到过一个典型情况GPU利用率只有20%CPU也不高但延迟很高。查下来是工具调用的HTTP连接池太小请求都在排队。把连接池从10调到100问题直接消失。所以别只看CPU和GPU网络和IO也要看。5.2 CPU侧的常见优化手段减少上下文拼接能预拼的预拼能缓存的缓存。用更快的序列化JSON换成orjson或msgspec能快好几倍。避免频繁GCPython里大对象频繁创建会触发GC可以用对象池或复用缓冲区。绑定核心在Linux上用taskset把Agent进程绑到固定核心减少上下文切换。调大文件描述符限制高并发下默认的1024不够用调到65535。这些手段看着零散但叠加起来效果很明显。我在一个项目里把这几条都做了CPU占用从90%降到50%延迟降了三分之一。5.3 GPU侧的配合策略GPU这边Agent场景下最重要的是别让GPU等。因为Agent的模型调用是间歇性的如果推理服务启动慢或排队久GPU就会空转。解决办法是保持推理服务常驻别每次调用都冷启动。另外如果模型不大可以用多实例的方式一个GPU上跑多个推理进程提高利用率。还有一个点是模型分级。不是所有Agent步骤都需要大模型。简单的意图识别、格式校验可以用小模型甚至规则引擎。这样能减少GPU调用次数间接减轻CPU的编排压力。我一般会把模型分成两档大模型处理复杂推理小模型处理简单分类。实测下来GPU调用次数能减少40%左右。6. 常见问题与排查实录6.1 CPU占用高但吞吐上不去这是最常见的问题。原因通常有几个一是上下文拼接太频繁二是工具调用没并发三是锁竞争。排查顺序是先看火焰图定位热点函数再看并发模型是不是有串行瓶颈最后看锁是不是有全局锁。我遇到过一次火焰图显示json.loads占了大头。查下来是工具返回的JSON特别大每次全量解析。改成只解析需要的字段后CPU直接降了一半。所以别小看序列化开销在Agent场景下它可能是大头。6.2 GPU利用率低但延迟高这个通常是编排层和推理层配合不好。检查点包括推理服务是不是常驻、有没有批处理、网络延迟大不大、请求队列是不是太长。我一般会先看推理服务的队列长度如果一直有积压说明GPU不够或批处理没开好如果队列空但延迟高说明编排层有问题。6.3 Agent任务卡死或超时卡死多半是没设超时或死锁。检查所有await和锁操作确保都有超时。另外工具调用失败后的重试逻辑要小心别无限重试。我一般设最大重试次数超过就降级或报错。6.4 内存泄漏与OOMAgent跑久了内存涨多半是上下文没释放或缓存没清理。检查全局变量和缓存确保有淘汰策略。Python里可以用tracemalloc看内存分配定位泄漏点。另外如果用了lru_cache注意设maxsize别无限缓存。问题可能原因排查手段解决方向CPU高吞吐低上下文拼接频繁火焰图预拼缓存GPU低延迟高批处理没开看推理队列开连续批处理任务卡死没设超时查await和锁加超时和重试内存涨缓存没淘汰tracemalloc加LRU和清理工具调用慢连接池小看网络等待调大连接池7. 一些个人体会和后续可以折腾的方向做Agent这段时间最大的感受是别把Agent当成一个模型问题它是个系统问题。模型只是其中一环CPU侧的编排、调度、状态管理往往才是决定体验的关键。我见过太多项目在模型上砸钱结果被CPU侧的细节拖垮。另一个体会是优化要有数据支撑。别凭感觉调参数先测再调。我一般会建一个简单的压测脚本模拟并发请求记录延迟和资源占用。每次改动都跑一遍看数据说话。这样调起来有方向也不容易回退。后续可以折腾的方向我觉得有几个一是把Agent运行时做成可观测的加指标和追踪方便定位问题二是探索CPU和GPU的更细粒度协同比如把部分预处理放到GPU上或者把部分推理放到CPU上三是针对Agent场景做专用的调度器而不是用通用的异步框架。这些方向都挺有意思等有新的实践再来分享。最后分享一个小技巧如果你在本地开发Agent可以用nice和cpulimit限制一下资源模拟线上环境。这样能提前发现性能问题别等上线了才抓瞎。