导读工具执行跟不上模型推理时，CPU 也可能成为 Agent 的速度瓶颈。模型写完代码，后面还有运行、测试和反馈；多轮调用也可能增加模型自身的计算量。沿着英特尔白皮书的两个测试，本文解释 CPU、GPU 和内存怎样配合，以及为什么不能直接套用“一颗 CPU 配一颗 GPU”。
模型写完代码，任务还没结束
让 AI 编写读取 CSV 文件的程序，算出每个月的销售额，并运行测试。代码生成了，任务却还没完成：它能否正确读取数据、通过测试，还要实际跑一遍。
英特尔的《Agentic AI Requires More CPUs》白皮书关注的就是这段工作。它讨论的是，当 CPU 处理能力不足、拖慢工具执行和任务编排时，怎样通过补足 CPU 资源减少昂贵加速器的等待。
大语言模型，也就是 LLM，可以根据要求生成代码。这里的推理，是模型利用已有参数处理输入、生成输出。如果只要求它写出代码，输出结束时，这次调用就完成了。
在这个 Agent 任务里，程序还要将代码写入文件，启动 Python，读取数据并运行测试；测试报错，再把错误信息交给模型，让它判断如何修改。模型可以决定下一步调用哪个工具，执行环境负责实际运行工具、收集结果。
LLM 是 Agent 系统中的模型组件，Agent 还包括围绕它运行的程序、工具和任务状态。因而，比较“LLM 和 Agent 的资源需求”，更准确地说，是比较一次模型调用与包含模型调用的完整任务。
模型推理之外，还有工具调用、执行和结果返回；图中编排指组织这些步骤的程序逻辑
来源：Intel《Agentic AI Requires More CPUs》，第 2 页图 2，局部裁切
图中的 CPU 和 GPU 表达职责分工，没有规定它们必须位于不同设备。模型推理与工具程序可以同机部署，也可以由不同服务器提供服务。
如果电脑上的 Agent 调用远程模型 API，模型推理的算力和显存需求主要在服务端；电脑承担本地程序和实际在本地执行的工具。讨论英特尔的数据中心配比时，需要把这套服务涉及的资源放在一起看。
CPU、GPU 和内存怎样接力？
沿着写代码的例子，在 GPU 或加速卡承担模型推理的部署中，工作大致这样分配：
每一轮修改仍要再次调用模型。与只生成一份代码相比，反复修改可能增加模型推理的总计算量，同时增加工具执行的工作量。CPU 变得更重要，并不意味着 GPU 的工作变少了。
模型权重，是训练得到的参数。模型处理上下文时，还会产生可复用的中间状态，例如 KV Cache：它保存注意力计算所需的键和值，让后续生成复用前面的计算。
系统内存与显存需要分别核算。常见的 GPU 推理部署把模型权重和 KV Cache 放在显存中；工具进程、文档和测试数据则占用系统内存。具体放置还取决于实现，例如 Transformers 支持将部分 KV Cache 卸载到系统内存，用额外搬运换取显存空间。
Agent 持续工作时，如果把更多工具输出纳入上下文，模型需要处理的输入会增加，缓存占用也可能增加。并发启动更多测试进程，又会增加系统内存需求。保存在文件或数据库中的长期记忆，与模型推理时的 KV Cache 是不同的存储对象，不能混在一起估算。
容量决定数据能否容纳；带宽影响数据送到计算单元的速度。即使放得下，反复搬运仍可能拖慢任务。CPU 核数、GPU 算力、内存容量与数据传输，要对应具体环节分析。
而且，CPU 在普通模型服务中本来就在工作。以 vLLM 为例，服务程序处理请求，调度器组织模型执行，GPU 工作进程运行模型。Agent 增加的是工具执行等工作，并非从此才需要 CPU。
本地大模型跑得快不快，算力和内存分别决定什么？
能并行，为什么还会等待？
对同一项任务，模型要看到测试报错，才能据此修改代码。这是输入依赖：结果尚未产生，下一步就缺少必要信息。
但任务甲等待测试时，GPU 可以处理任务乙的模型请求。多个独立测试也可以分给不同 CPU 核心执行，模型服务还可以把多个请求组织成批次。
因此，单项任务存在先后依赖，与整套系统能否并行，是两个问题。Agent 没有让大语言模型失去并行计算能力。
对并发服务，还要看各环节的处理能力是否匹配。这里的吞吐，指单位时间能完成多少工作；它与单项任务要等多久，需要分别看。
假如模型不断生成待测试的程序，而 CPU 执行测试的速度跟不上，测试队列就会增长。需要测试结果的任务无法及时发起下一轮推理；如果又没有足够的其他就绪请求，GPU 就可能空闲。
增加独立任务有时能填补等待，但也会增加工具进程、系统内存和模型缓存的压力。并发量继续增加，可能先碰到 CPU、内存或显存的限制。
英特尔关心的是工具和编排能否跟上模型推理，进而维持整套系统的处理能力。至于某次等待是否由 CPU 不足造成，还需要看它到底在计算、读写，还是等待外部服务。
英特尔的两个测试测到了什么？
白皮书的编程测试采用 Llama 3.1 8B Instruct，使用双路 Xeon Platinum 8568Y+ 系统和一张 Gaudi 3 加速卡。它从 DS-1000、BigCodeBench 取出 2140 道题，先生成代码，再在 CPU 上通过并行子进程执行验证；这种受限执行环境被称为沙箱。
2140 道题各阶段实际经过的时间；橙色为模型生成，蓝色为 CPU 工作，图中 GPU 标签对应本测试的 Gaudi 3 加速器
来源：Intel《Agentic AI Requires More CPUs》，第 4 页图 5
图中，模型生成代码耗时 62.81 秒，沙箱执行阶段为 63.96 秒。这是整批问题的阶段耗时，既不是每道题的用时，也不是所有 CPU 核心耗时的总和。
在该配置和题集下，即使测试已经并行，执行验证仍与模型生成处在相近的耗时量级。只提升生成速度，整项工作仍可能受验证阶段约束。不过，这张图没有直接展示并发服务中的 GPU 利用率，不能把两根柱子读成 GPU 空闲时间的测量。
另一项测试围绕金融申报文件展开：CPU 加载和整理数据、获取文件，模型规划补充搜索并生成分析。结果图中，网络搜索补充环节约需 100 秒，超过了模型生成分析的耗时。
这个例子说明模型之外的工作可能占据大量时间，但网络搜索经过的时间包含外部响应等等待。它不等于 CPU 连续计算了约 100 秒，也不足以单独证明换更强 CPU 就能消除这段等待。
两个案例都说明，有必要把模型之外的工作纳入计时。若要进一步判断增加多少 CPU 能带来多少收益，还需要具体服务的并发、资源占用和调整前后的对照数据；白皮书展示的阶段耗时没有把这些问题全部回答。
配比要回到整项任务来判断
白皮书给出约 1:1 至 1.4:1 的 CPU／GPU 配比建议，并说明模型大小和硬件代际会改变需求。这里讨论的是处理器数量配比，不是核心数相等，也不是两者承担相同运算。
还有一处需要留意：前面两个案例展示的是 Xeon 8568Y+ 与 Gaudi 3；配比建议段落写的是 Xeon 6767P 与 NVIDIA B200，文中没有展开后一组配置的完整测试过程。因而，不能拿前面的两个阶段耗时接近，直接推导出后一组芯片的数量配比。
我更愿意把这份白皮书读成一个明确的提醒：评估 Agent，要同时看模型能多快地产生下一步行动，以及执行环境能多快地完成行动、返回结果。
模型负责产生下一步行动，执行环境负责把行动完成并交回结果；两部分都可能限制任务速度。瓶颈在 CPU 计算或调度时，补 CPU 才可能改善相应环节；若主要在等网络、读写或模型推理，就要处理对应的约束。
我会先看整项任务在哪一步等待，再看那一步缺的是计算、空间、带宽还是外部响应。这样，才能判断“需要更多 CPU”在自己的任务里是否成立。
参考资料 上下滑动
•Intel，Agentic AI Requires More CPUs: Avoiding GPU Idle Time in Modern Inference Pipelines： https://www.intel.com/content/www/us/en/content-details/916705/agentic-ai-requires-more-cpus.html•Anthropic，Building effective agents： https://www.anthropic.com/research/building-effective-agents•Hugging Face Transformers，Cache strategies： https://huggingface.co/docs/transformers/kv_cache•vLLM，Architecture Overview： https://docs.vllm.ai/en/latest/design/arch_overview/
文章仅做学术分享，如有侵权请联系删除，非常感谢！