1. AI代理浪潮下算力格局的微妙转向过去两年大家聊算力几乎等同于聊GPU。大模型训练要卡、推理要卡、微调还要卡显卡一度成了硬通货。但最近圈子里有个现象挺有意思不少做AI代理的团队在架构评审会上开始重新把CPU摆到桌面上讨论甚至有些场景下CPU的预算占比在往上走。这不是怀旧也不是GPU买不到之后的无奈妥协而是AI代理这类负载本身的结构决定了它跟传统的大模型推理完全不是一回事。先把话说清楚这篇文章聊的不是“CPU要取代GPU”这种标题党结论而是想从实际做AI代理系统的角度拆解为什么CPU在这个阶段重新变得关键它在异构协作里扮演什么角色以及如果你正在搭一套AI代理系统该怎么分配CPU和GPU的资源。适合正在做AI应用落地、算力调度、或者单纯想搞明白“我的代理项目到底该买什么机器”的开发者看。不管你是刚接触AI代理的新手还是已经在调优推理性能的老手这里面的资源分配逻辑和实操细节都能直接参考。核心关键词就几个AI代理、CPU、算力、GPU、异构协作。这几个词之间的关系恰恰是当前算力讨论里最容易被简化、也最值得掰开揉碎讲的部分。2. 为什么AI代理把CPU重新推回舞台中央2.1 AI代理和传统推理的本质区别传统的大模型推理是什么形态你给一个prompt模型吐一段文本结束。整个过程的计算密集部分集中在GPU上的矩阵运算CPU基本就是个“发令员”——把数据搬到显存启动kernel等结果回来再搬出去。这种模式下CPU的利用率低得可怜大家自然觉得它不重要。AI代理完全不是这个逻辑。一个代理要完成“帮我订一张明天去上海的机票并安排会议室”这种任务它内部会发生什么拆解一下首先它要理解意图这一步可能调用一次模型然后它要规划步骤——查航班、比价格、看日历、发确认每一步都可能是一次工具调用工具调用的结果要解析、要判断、要决定下一步走哪条分支中间还可能涉及重试、回退、并行分支合并。整个流程是一个带状态的控制循环而不是一次性的前向计算。这个控制循环跑在哪里跑在CPU上。GPU负责的是循环内部那些“需要模型智能”的节点比如意图理解、结果摘要、异常判断。但循环本身的调度、状态管理、工具调用的编排、上下文的拼接和裁剪全是CPU的活。代理越复杂、工具越多、分支越深CPU侧的开销就越大。2.2 控制流与数据流的分离这里有个很关键的架构认知AI代理系统里控制流和数据流是分离的。数据流是那些张量计算走GPU控制流是“下一步做什么”的决策逻辑走CPU。传统推理里控制流极简——就一条直线。代理里控制流是一张图可能有几十个节点、上百条边。我实测过一个中等复杂度的代理处理一次用户请求平均触发7次模型调用、12次工具调用、3次条件分支判断。GPU侧每次模型调用的计算量其实不大很多是短prompt的轻量推理但CPU侧要维护整个会话状态、序列化反序列化工具参数、处理超时和重试、做结果校验。用性能分析工具一看端到端延迟里CPU侧占比超过40%有些工具调用密集的场景能到60%。这就解释了为什么大家开始重新审视CPU不是GPU不重要了而是代理负载把CPU从“搬运工”变成了“调度中枢”它的性能直接决定整个系统的吞吐和响应。2.3 算力约束下的资源再平衡还有一个现实因素算力约束。GPU资源贵且紧俏如果代理系统里大量轻量级的模型调用也占着GPU利用率其实很低。一个短prompt的意图分类可能GPU跑10毫秒但排队等调度花了200毫秒。这种情况下把一部分轻量推理放到CPU上跑或者用CPU做前置的规则过滤、缓存命中判断反而能提升整体吞吐。异构协作的核心思路就是让合适的硬件做合适的事。GPU做它擅长的批量矩阵运算CPU做它擅长的逻辑控制和轻量计算。代理负载的多样性恰好给了这种分工更大的优化空间。3. 异构协作中CPU与GPU的分工细节3.1 CPU侧到底在算什么拆细一点AI代理运行时CPU承担的计算任务主要有这几类会话状态管理维护对话历史、工具调用记录、中间结果。这些数据要频繁读写、拼接、裁剪全是内存操作和字符串处理CPU的强项。工具调用编排解析模型输出的工具调用意图校验参数合法性序列化成HTTP请求或本地函数调用处理返回结果。涉及大量JSON解析、网络IO、错误处理。上下文构建每次模型调用前要把系统提示、历史对话、工具定义、当前状态拼成一个完整的prompt。这个拼接过程涉及token计数、截断策略、格式转换CPU开销不小。轻量推理与规则判断一些不需要大模型的决策比如“这个结果是否为空”“是否满足重试条件”“走哪个分支”用规则或小模型在CPU上跑就够了。缓存与去重代理经常重复调用相同的工具或模型CPU侧做缓存命中判断能省下大量GPU调用。这些任务单独看都不重但叠加起来在高并发代理场景下就是实打实的CPU瓶颈。3.2 GPU侧的角色变化GPU在代理系统里依然不可替代但它的角色从“全程参与”变成了“按需介入”。具体来说复杂推理节点意图理解、多步规划、结果生成这些需要大模型能力的环节走GPU。批量处理当多个代理请求的模型调用可以批处理时GPU的吞吐优势明显。嵌入计算如果代理用向量检索做记忆或工具选择嵌入模型跑在GPU上更高效。关键变化是GPU不再需要处理代理的“全流程”只需要处理流程中的“智能节点”。这降低了对GPU持续占用的需求也让CPU和GPU的配比有了新的计算方式。3.3 异构协作的典型数据流一个典型的代理请求在异构架构下的流转路径大致是这样请求到达CPU侧初始化会话状态加载历史上下文。CPU做前置判断缓存是否命中是否可以用规则直接响应如果是直接返回不碰GPU。需要模型时CPU构建prompt通过推理框架提交到GPU。GPU完成推理结果回传CPU。CPU解析结果判断是工具调用还是最终回复。如果是工具调用CPU执行工具拿到结果更新状态回到步骤3或步骤5。如果是最终回复CPU做后处理返回给用户。这个循环里GPU只在步骤4被占用其余全在CPU。代理越复杂循环次数越多CPU侧累积的开销就越大。4. 实操代理系统的资源分配与调优4.1 怎么估算CPU和GPU的配比这个问题没有标准答案但有一个估算方法可以参考。先测单次代理请求的CPU时间和GPU时间。用性能分析工具跑一批真实请求统计端到端延迟中CPU侧占比R_cpuGPU侧占比R_gpu平均每次请求的模型调用次数N_model平均每次请求的工具调用次数N_tool然后根据你的并发目标C和延迟要求L反推需要的CPU核数和GPU算力。经验公式大致是CPU核数 ≈ C × (R_cpu × L) / 单核处理能力 GPU算力 ≈ C × N_model × 单次模型调用算力 / (L × R_gpu)这个公式很粗但能帮你判断瓶颈在哪。我试过几个项目代理复杂度中等时CPU和GPU的预算比大概在1:2到1:1之间浮动工具调用特别密集的能到2:1。这跟传统推理时代GPU占绝对大头的情况完全不同。4.2 推理框架的CPU侧配置要点不管你用哪种推理框架CPU侧有几个配置直接影响代理性能线程数CPU推理的线程数不是越多越好。超过物理核数后上下文切换开销会吃掉收益。一般设成物理核数的0.8到1倍比较稳。批处理大小CPU推理的批处理窗口要调小。GPU上批处理能提升吞吐CPU上批处理太大反而增加延迟因为CPU的并行能力有限。内存分配代理系统频繁创建和销毁对象内存分配器压力大。用内存池或对象复用能明显降低CPU开销。NUMA绑定多路CPU的机器上把推理线程绑定到同一个NUMA节点避免跨节点内存访问。这些配置在GPU为主的场景下经常被忽略但在代理系统里CPU侧调优的收益可能比GPU调优还大。4.3 工具调用的CPU优化技巧工具调用是CPU开销的大头几个实测有效的优化异步化工具调用基本都是IO密集的用异步框架能大幅提升CPU利用率。同步阻塞式调用会让CPU空等。连接池HTTP工具调用复用连接省去TCP握手和TLS协商的开销。结果缓存相同参数的工具调用结果缓存起来代理重试或分支回退时能直接命中。参数预校验在提交给模型之前先用规则校验工具参数的合法性避免无效的模型调用和工具调用。超时分级不同工具设不同超时快速失败比长时间等待更省CPU。这些优化叠加起来我见过CPU侧开销降低30%到50%的案例。4.4 一个可参考的部署配置假设你要部署一个中等复杂度的AI代理服务目标支持50并发平均响应时间2秒以内。参考配置组件配置说明CPU16核32线程代理控制循环、工具调用、上下文管理GPU单卡24GB显存模型推理支持批处理内存64GB会话状态、缓存、模型加载推理框架支持CPU/GPU混合轻量调用走CPU重推理走GPU并发框架异步IO工具调用不阻塞CPU这个配置下CPU和GPU的利用率都能保持在合理区间不会出现一方空转一方过载的情况。5. 常见问题与排查实录5.1 代理响应慢到底是CPU还是GPU的锅这是最常被问到的问题。排查思路先看端到端延迟的分解。如果CPU侧占比超过50%优先查CPU。CPU侧重点看上下文拼接是否频繁、工具调用是否同步阻塞、缓存命中率是否低。GPU侧重点看批处理是否合理、显存是否够用、是否有排队等待。用火焰图看CPU热点用GPU profiler看kernel耗时。我踩过的坑有一次代理响应慢第一反应是GPU不够加了卡之后没改善。后来用火焰图一看80%的CPU时间花在JSON序列化上工具调用的结果太大每次都要全量解析。改成流式解析后延迟直接降了一半。5.2 CPU利用率上不去但延迟很高这种情况通常是IO等待或锁竞争。检查工具调用是否同步阻塞了主线程是否有全局锁在保护会话状态内存分配是否频繁触发GC网络IO是否成为瓶颈提示代理系统里CPU利用率低但延迟高九成是IO或锁的问题不是算力不够。5.3 模型调用排队严重如果GPU侧排队严重但GPU利用率不高可能是批处理策略有问题。检查批处理窗口是否太长导致小请求等大请求是否有优先级机制重要请求能否插队模型是否加载了多个实例显存是否够一个实用技巧把轻量模型调用如意图分类放到CPU上跑重推理才走GPU。这样能分流GPU压力整体吞吐反而更高。5.4 常见问题速查表现象可能原因排查方向端到端延迟高CPU占比大上下文拼接频繁、工具调用阻塞火焰图、异步化改造GPU利用率低但排队批处理策略不合理调整批处理窗口、分流轻量调用CPU利用率低但延迟高IO等待、锁竞争检查同步调用、全局锁内存持续增长会话状态未释放、缓存无上限加TTL、限制缓存大小工具调用超时频繁网络问题、工具侧限流连接池、重试策略、超时分级6. 算力约束下的架构选择建议6.1 什么时候该加CPU什么时候该加GPU判断标准很简单看瓶颈在哪。如果代理的控制逻辑复杂、工具调用多、上下文管理重加CPU。如果模型推理是瓶颈、批处理跑不满、显存不够加GPU。但更常见的场景是两者都不够预算有限。这时候优先加CPU因为CPU侧的优化空间往往更大而且CPU资源更便宜、更灵活。把CPU侧理顺了GPU的需求可能反而下降。6.2 本地模型与云端算力的搭配现在很多代理项目会用本地小模型做轻量判断云端大模型做复杂推理。这种搭配下CPU的角色更重本地模型的推理、路由决策、结果融合都在CPU侧。如果本地模型用CPU推理那CPU的算力需求会进一步上升。我的建议是本地小模型如果调用频繁考虑用带核显的CPU或低端GPU加速如果只是偶尔调用CPU推理就够了。关键是算清楚调用频率和延迟要求别为了省GPU把CPU拖垮。6.3 从零搭建代理系统的资源规划步骤明确代理复杂度工具数量、分支深度、平均模型调用次数。压测单请求测出CPU时间和GPU时间的基线。估算并发需求根据业务目标确定并发数和延迟要求。反推资源配比用前面的公式粗算CPU核数和GPU算力。留出余量CPU留30%余量GPU留20%余量应对突发。持续观测上线后盯CPU和GPU的利用率曲线动态调整。这套流程我在几个项目里用过比拍脑袋买机器靠谱得多。最关键的是第2步没有基线数据后面全是猜。6.4 一个容易忽略的点CPU的缓存和内存带宽聊CPU算力时大家习惯看核数和频率但代理系统里缓存大小和内存带宽往往更关键。会话状态、上下文、工具结果都是内存密集型操作L3缓存大、内存带宽高的CPU实际表现会好很多。选机器时别只看核数内存子系统的规格也要关注。另外如果代理系统跑在容器里注意CPU配额的限制。有些环境默认限制很死导致CPU throttling表现就是延迟忽高忽低。用cpu.cfs_quota_us和cpu.cfs_period_us检查一下该放宽就放宽。7. 我个人的一些实操体会做代理系统这段时间最大的感受是别用传统推理的思维来配算力。传统推理是GPU一头沉代理系统是CPU和GPU双头挑。很多团队一开始按GPU为主的思路买机器上线后发现CPU成了瓶颈又回头补CPU折腾不说还耽误了上线节奏。另一个体会是CPU侧的优化往往比GPU侧更容易见效。GPU调优要改kernel、调批处理、搞量化门槛高、周期长。CPU侧把异步化做好、缓存加上、上下文拼接优化一下可能一两周就能看到明显收益。所以我的建议是先把CPU侧榨干再考虑加GPU。最后分享一个小技巧用perf或py-spy定期抓一下代理服务的CPU火焰图看看热点在哪里。很多时候你以为的瓶颈和实际的瓶颈差很远。我见过一个案例团队一直以为是模型推理慢火焰图一拉发现30%的时间花在日志打印上。把日志级别调高、改成异步写入延迟直接降了20%。这种问题不抓火焰图根本发现不了。代理系统的算力优化是个持续的过程没有一劳永逸的配置。业务在变、工具在变、模型在变资源配比也要跟着调。保持观测、保持迭代比一次性买对机器更重要。
AI代理算力新格局：CPU与GPU异构协作实战指南
1. AI代理浪潮下算力格局的微妙转向过去两年大家聊算力几乎等同于聊GPU。大模型训练要卡、推理要卡、微调还要卡显卡一度成了硬通货。但最近圈子里有个现象挺有意思不少做AI代理的团队在架构评审会上开始重新把CPU摆到桌面上讨论甚至有些场景下CPU的预算占比在往上走。这不是怀旧也不是GPU买不到之后的无奈妥协而是AI代理这类负载本身的结构决定了它跟传统的大模型推理完全不是一回事。先把话说清楚这篇文章聊的不是“CPU要取代GPU”这种标题党结论而是想从实际做AI代理系统的角度拆解为什么CPU在这个阶段重新变得关键它在异构协作里扮演什么角色以及如果你正在搭一套AI代理系统该怎么分配CPU和GPU的资源。适合正在做AI应用落地、算力调度、或者单纯想搞明白“我的代理项目到底该买什么机器”的开发者看。不管你是刚接触AI代理的新手还是已经在调优推理性能的老手这里面的资源分配逻辑和实操细节都能直接参考。核心关键词就几个AI代理、CPU、算力、GPU、异构协作。这几个词之间的关系恰恰是当前算力讨论里最容易被简化、也最值得掰开揉碎讲的部分。2. 为什么AI代理把CPU重新推回舞台中央2.1 AI代理和传统推理的本质区别传统的大模型推理是什么形态你给一个prompt模型吐一段文本结束。整个过程的计算密集部分集中在GPU上的矩阵运算CPU基本就是个“发令员”——把数据搬到显存启动kernel等结果回来再搬出去。这种模式下CPU的利用率低得可怜大家自然觉得它不重要。AI代理完全不是这个逻辑。一个代理要完成“帮我订一张明天去上海的机票并安排会议室”这种任务它内部会发生什么拆解一下首先它要理解意图这一步可能调用一次模型然后它要规划步骤——查航班、比价格、看日历、发确认每一步都可能是一次工具调用工具调用的结果要解析、要判断、要决定下一步走哪条分支中间还可能涉及重试、回退、并行分支合并。整个流程是一个带状态的控制循环而不是一次性的前向计算。这个控制循环跑在哪里跑在CPU上。GPU负责的是循环内部那些“需要模型智能”的节点比如意图理解、结果摘要、异常判断。但循环本身的调度、状态管理、工具调用的编排、上下文的拼接和裁剪全是CPU的活。代理越复杂、工具越多、分支越深CPU侧的开销就越大。2.2 控制流与数据流的分离这里有个很关键的架构认知AI代理系统里控制流和数据流是分离的。数据流是那些张量计算走GPU控制流是“下一步做什么”的决策逻辑走CPU。传统推理里控制流极简——就一条直线。代理里控制流是一张图可能有几十个节点、上百条边。我实测过一个中等复杂度的代理处理一次用户请求平均触发7次模型调用、12次工具调用、3次条件分支判断。GPU侧每次模型调用的计算量其实不大很多是短prompt的轻量推理但CPU侧要维护整个会话状态、序列化反序列化工具参数、处理超时和重试、做结果校验。用性能分析工具一看端到端延迟里CPU侧占比超过40%有些工具调用密集的场景能到60%。这就解释了为什么大家开始重新审视CPU不是GPU不重要了而是代理负载把CPU从“搬运工”变成了“调度中枢”它的性能直接决定整个系统的吞吐和响应。2.3 算力约束下的资源再平衡还有一个现实因素算力约束。GPU资源贵且紧俏如果代理系统里大量轻量级的模型调用也占着GPU利用率其实很低。一个短prompt的意图分类可能GPU跑10毫秒但排队等调度花了200毫秒。这种情况下把一部分轻量推理放到CPU上跑或者用CPU做前置的规则过滤、缓存命中判断反而能提升整体吞吐。异构协作的核心思路就是让合适的硬件做合适的事。GPU做它擅长的批量矩阵运算CPU做它擅长的逻辑控制和轻量计算。代理负载的多样性恰好给了这种分工更大的优化空间。3. 异构协作中CPU与GPU的分工细节3.1 CPU侧到底在算什么拆细一点AI代理运行时CPU承担的计算任务主要有这几类会话状态管理维护对话历史、工具调用记录、中间结果。这些数据要频繁读写、拼接、裁剪全是内存操作和字符串处理CPU的强项。工具调用编排解析模型输出的工具调用意图校验参数合法性序列化成HTTP请求或本地函数调用处理返回结果。涉及大量JSON解析、网络IO、错误处理。上下文构建每次模型调用前要把系统提示、历史对话、工具定义、当前状态拼成一个完整的prompt。这个拼接过程涉及token计数、截断策略、格式转换CPU开销不小。轻量推理与规则判断一些不需要大模型的决策比如“这个结果是否为空”“是否满足重试条件”“走哪个分支”用规则或小模型在CPU上跑就够了。缓存与去重代理经常重复调用相同的工具或模型CPU侧做缓存命中判断能省下大量GPU调用。这些任务单独看都不重但叠加起来在高并发代理场景下就是实打实的CPU瓶颈。3.2 GPU侧的角色变化GPU在代理系统里依然不可替代但它的角色从“全程参与”变成了“按需介入”。具体来说复杂推理节点意图理解、多步规划、结果生成这些需要大模型能力的环节走GPU。批量处理当多个代理请求的模型调用可以批处理时GPU的吞吐优势明显。嵌入计算如果代理用向量检索做记忆或工具选择嵌入模型跑在GPU上更高效。关键变化是GPU不再需要处理代理的“全流程”只需要处理流程中的“智能节点”。这降低了对GPU持续占用的需求也让CPU和GPU的配比有了新的计算方式。3.3 异构协作的典型数据流一个典型的代理请求在异构架构下的流转路径大致是这样请求到达CPU侧初始化会话状态加载历史上下文。CPU做前置判断缓存是否命中是否可以用规则直接响应如果是直接返回不碰GPU。需要模型时CPU构建prompt通过推理框架提交到GPU。GPU完成推理结果回传CPU。CPU解析结果判断是工具调用还是最终回复。如果是工具调用CPU执行工具拿到结果更新状态回到步骤3或步骤5。如果是最终回复CPU做后处理返回给用户。这个循环里GPU只在步骤4被占用其余全在CPU。代理越复杂循环次数越多CPU侧累积的开销就越大。4. 实操代理系统的资源分配与调优4.1 怎么估算CPU和GPU的配比这个问题没有标准答案但有一个估算方法可以参考。先测单次代理请求的CPU时间和GPU时间。用性能分析工具跑一批真实请求统计端到端延迟中CPU侧占比R_cpuGPU侧占比R_gpu平均每次请求的模型调用次数N_model平均每次请求的工具调用次数N_tool然后根据你的并发目标C和延迟要求L反推需要的CPU核数和GPU算力。经验公式大致是CPU核数 ≈ C × (R_cpu × L) / 单核处理能力 GPU算力 ≈ C × N_model × 单次模型调用算力 / (L × R_gpu)这个公式很粗但能帮你判断瓶颈在哪。我试过几个项目代理复杂度中等时CPU和GPU的预算比大概在1:2到1:1之间浮动工具调用特别密集的能到2:1。这跟传统推理时代GPU占绝对大头的情况完全不同。4.2 推理框架的CPU侧配置要点不管你用哪种推理框架CPU侧有几个配置直接影响代理性能线程数CPU推理的线程数不是越多越好。超过物理核数后上下文切换开销会吃掉收益。一般设成物理核数的0.8到1倍比较稳。批处理大小CPU推理的批处理窗口要调小。GPU上批处理能提升吞吐CPU上批处理太大反而增加延迟因为CPU的并行能力有限。内存分配代理系统频繁创建和销毁对象内存分配器压力大。用内存池或对象复用能明显降低CPU开销。NUMA绑定多路CPU的机器上把推理线程绑定到同一个NUMA节点避免跨节点内存访问。这些配置在GPU为主的场景下经常被忽略但在代理系统里CPU侧调优的收益可能比GPU调优还大。4.3 工具调用的CPU优化技巧工具调用是CPU开销的大头几个实测有效的优化异步化工具调用基本都是IO密集的用异步框架能大幅提升CPU利用率。同步阻塞式调用会让CPU空等。连接池HTTP工具调用复用连接省去TCP握手和TLS协商的开销。结果缓存相同参数的工具调用结果缓存起来代理重试或分支回退时能直接命中。参数预校验在提交给模型之前先用规则校验工具参数的合法性避免无效的模型调用和工具调用。超时分级不同工具设不同超时快速失败比长时间等待更省CPU。这些优化叠加起来我见过CPU侧开销降低30%到50%的案例。4.4 一个可参考的部署配置假设你要部署一个中等复杂度的AI代理服务目标支持50并发平均响应时间2秒以内。参考配置组件配置说明CPU16核32线程代理控制循环、工具调用、上下文管理GPU单卡24GB显存模型推理支持批处理内存64GB会话状态、缓存、模型加载推理框架支持CPU/GPU混合轻量调用走CPU重推理走GPU并发框架异步IO工具调用不阻塞CPU这个配置下CPU和GPU的利用率都能保持在合理区间不会出现一方空转一方过载的情况。5. 常见问题与排查实录5.1 代理响应慢到底是CPU还是GPU的锅这是最常被问到的问题。排查思路先看端到端延迟的分解。如果CPU侧占比超过50%优先查CPU。CPU侧重点看上下文拼接是否频繁、工具调用是否同步阻塞、缓存命中率是否低。GPU侧重点看批处理是否合理、显存是否够用、是否有排队等待。用火焰图看CPU热点用GPU profiler看kernel耗时。我踩过的坑有一次代理响应慢第一反应是GPU不够加了卡之后没改善。后来用火焰图一看80%的CPU时间花在JSON序列化上工具调用的结果太大每次都要全量解析。改成流式解析后延迟直接降了一半。5.2 CPU利用率上不去但延迟很高这种情况通常是IO等待或锁竞争。检查工具调用是否同步阻塞了主线程是否有全局锁在保护会话状态内存分配是否频繁触发GC网络IO是否成为瓶颈提示代理系统里CPU利用率低但延迟高九成是IO或锁的问题不是算力不够。5.3 模型调用排队严重如果GPU侧排队严重但GPU利用率不高可能是批处理策略有问题。检查批处理窗口是否太长导致小请求等大请求是否有优先级机制重要请求能否插队模型是否加载了多个实例显存是否够一个实用技巧把轻量模型调用如意图分类放到CPU上跑重推理才走GPU。这样能分流GPU压力整体吞吐反而更高。5.4 常见问题速查表现象可能原因排查方向端到端延迟高CPU占比大上下文拼接频繁、工具调用阻塞火焰图、异步化改造GPU利用率低但排队批处理策略不合理调整批处理窗口、分流轻量调用CPU利用率低但延迟高IO等待、锁竞争检查同步调用、全局锁内存持续增长会话状态未释放、缓存无上限加TTL、限制缓存大小工具调用超时频繁网络问题、工具侧限流连接池、重试策略、超时分级6. 算力约束下的架构选择建议6.1 什么时候该加CPU什么时候该加GPU判断标准很简单看瓶颈在哪。如果代理的控制逻辑复杂、工具调用多、上下文管理重加CPU。如果模型推理是瓶颈、批处理跑不满、显存不够加GPU。但更常见的场景是两者都不够预算有限。这时候优先加CPU因为CPU侧的优化空间往往更大而且CPU资源更便宜、更灵活。把CPU侧理顺了GPU的需求可能反而下降。6.2 本地模型与云端算力的搭配现在很多代理项目会用本地小模型做轻量判断云端大模型做复杂推理。这种搭配下CPU的角色更重本地模型的推理、路由决策、结果融合都在CPU侧。如果本地模型用CPU推理那CPU的算力需求会进一步上升。我的建议是本地小模型如果调用频繁考虑用带核显的CPU或低端GPU加速如果只是偶尔调用CPU推理就够了。关键是算清楚调用频率和延迟要求别为了省GPU把CPU拖垮。6.3 从零搭建代理系统的资源规划步骤明确代理复杂度工具数量、分支深度、平均模型调用次数。压测单请求测出CPU时间和GPU时间的基线。估算并发需求根据业务目标确定并发数和延迟要求。反推资源配比用前面的公式粗算CPU核数和GPU算力。留出余量CPU留30%余量GPU留20%余量应对突发。持续观测上线后盯CPU和GPU的利用率曲线动态调整。这套流程我在几个项目里用过比拍脑袋买机器靠谱得多。最关键的是第2步没有基线数据后面全是猜。6.4 一个容易忽略的点CPU的缓存和内存带宽聊CPU算力时大家习惯看核数和频率但代理系统里缓存大小和内存带宽往往更关键。会话状态、上下文、工具结果都是内存密集型操作L3缓存大、内存带宽高的CPU实际表现会好很多。选机器时别只看核数内存子系统的规格也要关注。另外如果代理系统跑在容器里注意CPU配额的限制。有些环境默认限制很死导致CPU throttling表现就是延迟忽高忽低。用cpu.cfs_quota_us和cpu.cfs_period_us检查一下该放宽就放宽。7. 我个人的一些实操体会做代理系统这段时间最大的感受是别用传统推理的思维来配算力。传统推理是GPU一头沉代理系统是CPU和GPU双头挑。很多团队一开始按GPU为主的思路买机器上线后发现CPU成了瓶颈又回头补CPU折腾不说还耽误了上线节奏。另一个体会是CPU侧的优化往往比GPU侧更容易见效。GPU调优要改kernel、调批处理、搞量化门槛高、周期长。CPU侧把异步化做好、缓存加上、上下文拼接优化一下可能一两周就能看到明显收益。所以我的建议是先把CPU侧榨干再考虑加GPU。最后分享一个小技巧用perf或py-spy定期抓一下代理服务的CPU火焰图看看热点在哪里。很多时候你以为的瓶颈和实际的瓶颈差很远。我见过一个案例团队一直以为是模型推理慢火焰图一拉发现30%的时间花在日志打印上。把日志级别调高、改成异步写入延迟直接降了20%。这种问题不抓火焰图根本发现不了。代理系统的算力优化是个持续的过程没有一劳永逸的配置。业务在变、工具在变、模型在变资源配比也要跟着调。保持观测、保持迭代比一次性买对机器更重要。
