最近在调整一台推理服务器配置的时候被同事问了一个问题“如果跑 Agent 应用CPU 和 GPU 是不是得按 1:1 配”这个问题的来源很直接。代理 AI、Agent、AI Agent 这些概念被反复讨论很多团队开始把原来的一次性问答改成“模型多轮决策 工具调用 结果汇总”的完整工作流。结果一上线就发现GPU 好像也没有跑满但 CPU 经常报警。于是有人开始怀疑是不是 CPU 核数和 GPU 卡数要按某个固定比例配。这个问题的答案不是“1:1”也不是“不需要 CPU”。更准确地说代理 AI 时代真正改变的不是 CPU 和 GPU 的数量比而是整条算力链路的分配方式。你需要在理解 AI 推理流程的基础上重新判断 CPU 在哪个环节参与、参与多少、瓶颈在哪里、如何观测。这篇文章就是想把这个判断过程讲清楚。1. 一个看似简单的问题背后是算力结构的重新分配“CPU 和 GPU 1:1”这个说法听起来像是一个可以套用的配置公式。但真去落地的人会发现这个比例根本没有统一答案。原因在于不同场景里 CPU 和 GPU 承担的工作完全不同。1.1 CPU 和 GPU 按 1:1 配这是从哪来的问题过去几年大部分 AI 项目停留在“训练模型”和“调用 API”两个阶段。训练模型时GPU 是绝对主角CPU 主要负责数据预处理和数据加载调用 API 时用户基本不关心服务器内部配置反正请求发出去了等结果返回就行。代理 AI 时代不一样。Agent 应用不是“发一个请求、拿一个结果”那么简单。它往往要把一个复杂任务拆解成多个步骤每一步都可能调用一次模型还可能穿插工具调用、搜索结果解析、代码执行、上下文重写等操作。这意味着模型推理次数变多。每次推理可能需要携带更长的上下文。CPU 参与前置处理、调度和后置解析的机会变多。所以很多人才会觉得是不是 CPU 要多配一点才能和 GPU 一起支撑起 Agent 的完整工作流。这个想法有合理的一面但“1:1”这种表达太粗糙了。CPU 和 GPU 不是按“块”对“块”协作的而是按“计算任务”协作的。关键不在于比例而在于工作流里 CPU 的负载到底来自哪里。1.2 训练和推理的计算逻辑完全不一样要理解 CPU 和 GPU 的关系先要区分训练和推理这两个完全不同的阶段。训练阶段数据要反复迭代梯度要同步显存要大量占用GPU 几乎被计算任务占满。CPU 在这里更像一个“后勤部门”负责把数据一批一批送进去再把结果接回来。这时候 CPU 配置够用就行不是瓶颈。推理阶段尤其是 Agent 场景下的多次推理计算模式完全变了。每次请求都需要做文本输入的分词和编码。上下文的管理和截断。模型前向计算。输出结果的后处理。多轮之间的状态保存。这些操作里模型前向计算主要在 GPU 上完成但分词、上下文处理、调度、后处理、多轮状态管理很多都在 CPU 上完成。如果工作流还涉及工具调用、代码执行、搜索结果解析那 CPU 承担的就不再是“后勤”而是核心业务逻辑的一部分。所以代理 AI 让 CPU 真正进入 AI 计算的“主流程”而不是只在旁边辅助。2. 为什么代理 AI 会让 CPU 重新变得重要很多人对 Agent 的理解是“多调几次模型”。从现象上看确实如此但从算力角度看完全不是一回事。2.1 Agent 不只是“多调几次模型”一个普通的问答请求链路很短用户输入 - 模型推理 - 返回结果。一个 Agent 请求链路可能长得多用户输入 - 模型规划 - 调用工具 - 获取结果 - 拼接上下文 - 再次调用模型 - 判断是否完成 - 生成最终回答。每增加一个环节CPU 要处理的工作就多一层。举个例子。假设一个 Agent 要帮用户查天气、订提醒、顺便查一下明天的会议安排。它可能先要调用一次模型理解意图然后分别调用日历接口、天气接口、消息通知接口最后再调用一次模型把所有信息汇总成自然语言。如果中间某个环节需要从文档库里检索资料可能还要处理向量化、检索、排序等步骤。这些步骤本身可能不算复杂但它们都是 CPU 指令。如果请求量大CPU 负载就会快速上涨。再加上每一次模型调用都需要把文本拆成 token都要计算注意力机制的输入这些前置操作同样消耗 CPU 资源。所以Agent 应用不是“多调几次模型”而是“每次调用模型的前后都多了很多 CPU 要做的事”。2.2 tokenize、编排、工具调用CPU 的隐形负担在 Agent 工作流里最容易忽略的 CPU 消耗来自三个环节。第一个是 tokenize。不管是输入还是输出文本都要转成 token。这个操作看起来简单但高频调用下累计开销非常大。尤其当上下文很长时tokenize 的时间会明显拉长。如果模型的 prompt 里塞了大量历史对话、工具说明、检索资料这部分的耗时就会成为每次请求的固定成本。第二个是编排。Agent 的每一步怎么走、调用哪个工具、上下文怎么拼接、结果怎么传给下一步这些逻辑要么写在代码里要么由模型决定但最终都要通过 CPU 执行。如果使用的是 ReAct 这类循环结构每一次循环都意味着新的模型调用和新的调度开销。第三个是工具调用。查询数据库、调用 API、执行代码、读取文件这些操作大多在 CPU 上完成。工具返回的结果还需要清洗、截断、格式化然后拼回 prompt。这个过程如果做得不好要么上下文爆炸要么 CPU 负载居高不下。这三个环节叠加起来就很容易出现一种情况GPU 利用率只有三成但 CPU 已经打满请求响应时间越来越长。2.3 为什么“等等 A100/H100 显卡够了”的直觉不适用过去做推理服务很多人的经验是“显存够就够”。因为单次模型推理的计算瓶颈很明确你只要算好模型占多少显存、并发请求要多少显存然后堆显卡就行。但 Agent 场景不是单次推理而是复合工作流。你没法用一个简单的“显存 并发数 × 单请求显存”公式来评估。因为每个请求的 CPU 耗时不确定GPU 的等待时间也不确定请求处理节奏和传统推理完全不同。简单说Agent 应用的需求不是“算得快”而是“流程跑得顺”。流程里既包含 GPU 计算也包含 CPU 对上下文、工具和状态的持续管理。这时候只盯着 GPU 配置天然会漏掉真正的瓶颈。3. 评估 CPU 和 GPU 比例不应只看“块数”而要看三个维度那到底怎么配更务实的做法是放弃“1:1”这种公式从负载类型、并发模型、模型规格三个维度去判断。3.1 负载类型算力密集型还是交互密集型先分清楚你的 Agent 应用是哪种负载。如果一个请求主要是大段文本生成比如写文章、生成代码、总结长文档那么 GPU 计算是主要矛盾。CPU 配置正常即可优先保证 GPU 算力和显存。如果一个请求主要是多轮交互和工具调用比如让 Agent 操作浏览器、查询多个系统、做复杂编排那么 CPU 可能成为瓶颈。因为每一步工具调用、每一次上下文拼接、每一轮模型调度都需要 CPU 参与。这时候就不能只看 GPU 用了多少还得看 CPU 在同样的时间段里完成了多少调度任务。一个粗糙的判断方式是压测时打开两个监控一个看 GPU 利用率一个看 CPU 利用率。如果 GPU 利用率长期低于 50%而 CPU 已经接近满载那问题多半出在 CPU 侧如果 GPU 利用率很高CPU 也高那说明配置基本匹配如果 GPU 一会儿 100% 一会儿 0%CPU 也不稳定那更可能是调度和并发策略的问题。3.2 并发模型batch 大还是小直接影响 CPU 压力第二个维度是并发模型。传统推理优化经常用动态 batching 把多个请求合并到一起让 GPU 的计算密度更高。这种做法对 GPU 更友好但也会改变 CPU 的负载模式。因为批处理需要把多个请求的输入整理成统一的张量形状要做 padding、mask 等操作这些都是 CPU 开销。Agent 场景有些特殊。由于每个请求的任务链路不同上下文长度差异可能很大有的请求一步就结束有的请求要循环七八步。把它们强行放进同一个 batch可能反而导致效率下降。所以 Agent 推理服务经常采用小 batch 甚至单请求推理这时候 GPU 可能跑不满但 CPU 反而要处理更多调度和并发切换。也就是说Agent 场景下的并发模型会让 CPU 的负担更加凸显。你越追求单请求灵活调度CPU 的压力就越大你越追求 GPU 高利用率就越需要复杂的批处理策略。这中间需要根据响应时间要求和成本预算做取舍。3.3 模型规格和上下文长度决定显存和 CPU 的配合第三个维度是模型规格和上下文长度。模型参数越大显存占用越高单次推理的 GPU 计算量也越大。这时候 CPU 只在准备输入和接收输出时忙碌相对压力占比反而不明显。但模型参数不大、上下文很长时情况就不一样。比如一个小参数模型可能推理只花 200 毫秒但上下文里有 2 万 tokentokenize 和预处理就花掉了 150 毫秒。这种场景下CPU 的开销占比会非常高。所以如果你计划部署一个 7B 或 13B 左右的模型并且要处理长上下文、多轮工具调用那 CPU 核数就不能只按“够用”来配要按“每请求固定开销 × 并发数”来估算。4. 不同场景下的配置思路讨论了原理和判断维度之后落到实际配置上可以按场景给出一些参考方向。这不是“1:1”公式而是一套评估思路。4.1 本地推理和学习场景如果你只是在自己电脑或一台开发机上跑 Ollama、vLLM 这类工具做 Agent 原型验证那 CPU 和 GPU 的比例不用太纠结。常见实践里笔记本或工作站可以先配一颗 8 核以上的 CPU加上一张 12GB 到 24GB 显存的中端显卡跑 7B 到 14B 参数的模型做小规模 Agent 试跑基本够。如果遇到 CPU 负载高优先检查是不是上下文太长、工具调用太频繁再考虑是不是要限制并发。这个阶段的目标是跑通全流程。单次调用能正常返回工具调用能串起来上下文能接上就已经达到目的了。性能优化可以往后放。4.2 服务化推理和 Agent 生产环境到了生产环境就要从整体链路来评估。一个相对可用的起点是先按单台机器的预期并发数估算 CPU 核数。比如你有 8 个并发请求每个请求在 CPU 侧的固定开销按照 1 到 2 个核心来估那 CPU 至少需要 8 到 16 核。再考虑 Agent 的编排和工具调用开销可能需要更多。GPU 数量则取决于模型的推理速度和显存占用。如果你的服务目标是一个请求在 5 秒内返回而模型单次推理需要 1 秒那么单张 GPU 理论上能串行处理几个请求再结合动态 batching 的能力可以算出大致需要几张卡。关键是要先确定“预期并发数”和“可接受延迟”然后再倒推 CPU 和 GPU 的配置。不要先买资源再定指标。4.3 端侧、私有化和边缘场景还有一种场景是端侧部署或边缘节点部署。比如企业私有化项目要求数据不出域只能在一台性能有限的服务器上跑小模型。或者移动端、边缘盒子要跑一个轻量 Agent处理简单的工具调用。这种场景下CPU 和 GPU 的比例其实更接近“优化协同”。因为端侧通常没有太多 CPU 核数也没有大显存 GPU。最终方案往往是小模型 精简上下文 固定工具调用流程把 CPU 消耗压到最低GPU 只负责最核心的生成部分。从这个角度看端侧 Agent 的计算模式不是“把模型做大”而是“把模型做小、把流程做省”。CPU 扮演的角色不再是堆配置而是精细管理资源。5. 工程链路先跑通、再压测、再扩容配置评估不是一次性的而是一个持续调整的过程。我建议按三个阶段推进。5.1 先跑通最小流程再谈扩容第一步不要急着一上来就买一堆 GPU也不要纠结于 CPU 和 GPU 的精确比例。先用一台配置适中的机器把 Agent 的最小工作流跑通。最小工作流可以定义为一个请求进来。Agent 调用一次模型。Agent 调用一个工具。Agent 把结果拼回上下文。再调用一次模型输出最终答案。跑通之后记录每次模型调用的耗时、CPU 占用、GPU 占用、上下文 tokens 数量。这组数据就是你后续调整配置的基准。5.2 压测时要盯的不是显存而是等待时间第二步做压测。压测时要关注的指标不是显存用了多少而是请求响应时间。GPU 利用率的波动情况。CPU 利用率。内存占用。每次 Agent 循环的平均 token 数。工具调用的耗时占比。如果压测发现 GPU 利用率很低但 CPU 已经 90% 以上那说明瓶颈在 CPU 侧。这时候先别加 GPU先看看 CPU 的负载来源是不是 tokenize、编排或工具调用。如果是上下文太长导致的可以优化上下文裁剪策略而不是简单加核。如果 GPU 利用率很高CPU 也高说明机器的算力基本被用满。这时候再考虑增加 GPU 或 CPU 核数同时观察是否出现资源浪费。5.3 日志、监控、重试生产环境的三件套第三阶段是生产化。这时候需要考虑的不只是 CPU 和 GPU 的比例还有稳定性。Agent 应用有一个显著特点步骤多失败率更高。一次请求里可能有多次模型调用和工具调用任何一个环节超时或报错都可能导致整个请求失败。如果失败后直接重跑整个流程那资源消耗会成倍上升。所以在生产环境里有几件事比硬件配置更重要日志记录每一步 Agent 循环的输入、输出、耗时、模型调用参数、工具返回状态。监控对 CPU、内存、GPU、显存、请求并发、错误率做聚合监控。重试策略对工具调用和模型调用设置合理的超时和重试但不要无限重试。有了这三件套你才能回答“CPU 和 GPU 比例到底要不要调”这个问题。否则只能靠猜。6. 实际落地时最常见的坑最后聊几个实操中经常遇到的问题。这些问题看起来和“CPU 与 GPU 比例”无关但往往是最影响资源使用效率的因素。6.1 如何确认 GPU 是否真正生效很多人在本地用 Ollama、PyTorch 或 vLLM 时会遇到一个经典问题代码跑起来了但不知道模型到底跑在 GPU 上还是 CPU 上。常见的做法是查看 GPU 使用率。如果是 Linux 环境可以用nvidia-smi查看显存占用和 GPU 利用率。如果模型加载后显存占用很低或者运行期间 GPU 利用率一直为个位数那就要检查是不是没有走 GPU 推理。在常见实践里Ollama 这类工具会自动检测 GPU但偶尔会因为驱动版本、容器权限、CUDA 环境变量等原因回退到 CPU 模式。WSL 环境里偶尔还会遇到 GPU 访问被系统拦截的报错这类问题通常和 WSL 的 GPU 驱动映射相关。排查路径一般是先看nvidia-smi是否正常再看运行日志是否提示 GPU 不可用然后确认驱动和 CUDA 版本最后再检查应用层有没有打开 GPU 开关。注意模型在 CPU 上跑出来的结果可能完全正确但性能会下降一个数量级。所以拿到一台新机器后第一步不是调 Agent 流程而是确认模型推理是否真正跑在 GPU 上。6.2 CPU 占用高不一定是 CPU 不够许多团队在 Agent 压测时遇到 CPU 打满第一反应是加 CPU 核数。但实际情况里CPU 打满可能来自几个不同原因。第一种是请求并发过高。这种情况 CPU 确实可能不够可以通过限制并发数来验证。第二种是上下文处理开销过大。如果每次请求都带着超长的历史记录tokenize 和注意力计算的前置操作会持续消耗 CPU。优化方式是控制上下文长度而不是堆核心。第三种是某些依赖库只支持 CPU 版本。比如一些向量检索库、文本处理库在未安装 GPU 版本时会把大量张量运算放在 CPU 上完成导致 CPU 利用率飙升。第四种是异常重试风暴。Agent 调用工具失败后如果代码无限重试CPU 会非常忙但 GPU 可能处于空闲状态。所以遇到 CPU 高负载先做排查再决定加不加核。否则只是把问题从“CPU 不足”转移成“CPU 浪费”。6.3 参数调整建议先减并发再观察 CPU 和 GPU 的平衡如果你刚开始调优我建议按这个顺序尝试先限制并发把并发降到一个较小的数值比如原来 16 并发先降到 4。观察单请求响应时间、CPU 利用率、GPU 利用率。如果单请求响应时间正常CPU 和 GPU 利用率都不过分再逐步提高并发。每提高一档记录一次指标变化。找到一个响应时间可以接受、CPU 和 GPU 利用率都比较稳的并发值。这个过程的核心原则是先找到瓶颈再针对瓶颈调整资源。不要一上来就堆显卡也不要盲目加 CPU。大多数情况下Agent 应用的问题是流程设计和资源调度问题而不是硬件数量问题。7. 回到基点你需要的不是 1:1而是一套动态观察和调整机制如果一定要给一个结论我更愿意这样说代理 AI 时代CPU 和 GPU 的关系不是“1:1”而是“按需协同”。CPU 负责流程的编织和调度GPU 负责密集计算。Agent 越复杂、工具调用越多、上下文越长CPU 的角色就越重要。但具体需要多少核、多少卡、什么比例取决于你的负载类型、并发模型和上下文管理策略。真正值得长期投入的不是找到某个固定的资源配置公式而是建立起一套“观察—定位—调整”的机制。你能看到 CPU 在每个环节消耗多少能定位到 GPU 利用率低背后的原因能根据压测数据调整并发和上下文策略。有了这套机制无论未来模型怎么变、Agent 框架怎么变你都能快速判断资源够不够、瓶颈在哪里。先跑通一条最小链路记录一组基础数据再做压测和调优。这比任何“1:1”公式都可靠。