智能体AI算力采购不能只看GPU：如何评估CPU、内存与工具调用链？

智能体AI的算力瓶颈，往往不在模型完成一次矩阵计算需要多少GPU，而在于它能否稳定完成一连串“观察—推理—调用工具—读取数据—再次推理—执行动作”的任务。对企业而言，服务器采购如果只比较GPU型号、显存容量和峰值吞吐，很容易忽略CPU调度、内存访问、网络通信和存储响应带来的端到端延迟。

先看工作流，而不是先看芯片参数

传统AI基础设施通常可以把任务拆成训练、批量推理或高并发在线推理。智能体AI则更像一个持续运行的控制系统：

1. 接收用户请求并拆解任务；
2. 调用检索、数据库、搜索、代码执行或业务系统工具；
3. 读取工具返回结果并整理上下文；
4. 再次请求模型进行判断；
5. 根据结果决定下一步动作；
6. 处理异常、重试、权限校验和结果回写。

其中，GPU主要承担模型推理中的大规模并行计算，但并不负责全部工作。CPU需要处理请求编排、线程调度、协议解析、数据预处理、工具适配、序列化与反序列化、权限控制和日志记录。工具返回的数据还可能经过网络、缓存、内存和存储系统多次搬运，最终才重新进入模型上下文。

因此，采购评估的核心问题应从“GPU每秒能处理多少Token”扩展为：

一个完整的智能体任务，从首次请求到最终结果，平均耗时多少？尾延迟是否可控？在工具调用增多、并发上升或数据规模扩大后，系统是否仍能稳定运行？

为什么“核心数优先”可能失效

CPU核心数多，并不意味着智能体工作流一定更快。原因在于，智能体任务往往同时包含串行阶段和短时突发阶段。

例如，一次工具调用可能依次经历：

• 主线程判断是否需要调用工具；
• CPU生成请求并完成参数校验；
• 网络发送请求；
• 外部服务执行；
• CPU解析返回结果；
• 将结果写入上下文或缓存；
• 再次触发模型推理。

其中一些步骤可以并行，但关键决策、上下文更新和任务编排仍可能存在串行依赖。如果单核性能不足，某个调度线程成为瓶颈，即使服务器还有大量空闲核心，整体响应时间也不会明显下降。

此外，智能体系统通常存在许多短任务。它们的特点不是持续占满CPU，而是频繁唤醒、快速执行、等待外部事件，再次被唤醒。此时，以下指标可能比总核心数更重要：

• 单线程或单核执行效率；
• 线程唤醒与上下文切换开销；
• L1、L2、L3缓存命中率；
• 内存访问延迟；
• 多路CPU之间的数据一致性通信；
• 网络和存储I/O等待时间；
• 高并发下的P95、P99延迟。

这并不意味着核心数不重要。企业知识库、批量文档处理和大规模并发任务仍然需要足够的并行能力。更准确的做法是区分两类负载：一类是可以规模化并行的吞吐型任务，另一类是受串行依赖、数据访问和外部工具响应影响的交互型任务。

CPU与GPU的分工，需要按链路评估

在智能体AI系统中，CPU和GPU不是简单的替代关系，而是协同关系。

采购时，不能只问“这台服务器有多少个CPU核心”，还要问：模型推理和工具编排是否争抢同一组CPU资源？检索服务是否与推理服务共用内存？数据在CPU内存、GPU显存、缓存和存储之间需要复制几次？这些复制是否会成为高并发下的隐性瓶颈？

内存带宽和缓存，决定数据搬运效率

智能体系统的上下文通常会随着多轮工具调用而增长。知识库检索还可能同时读取大量文档片段、索引和元数据。此时，内存容量只是基础条件，带宽和访问延迟同样重要。

可以把服务器内存问题分成三个层次：

容量是否足够

容量不足会导致缓存失效、频繁换页，甚至把本应在内存中完成的数据访问转移到存储系统。对于企业知识库和多租户智能体平台，还要把模型服务、向量数据库、缓存、日志和监控的内存需求一起计算，而不是只按照模型参数规模估算。

带宽是否匹配

当多个CPU线程同时进行文本处理、检索、排序或数据转换时，内存带宽会限制整体吞吐。增加核心数后，如果内存子系统没有同步扩展，新增核心可能只能等待数据，CPU利用率看似不低，实际有效工作量却没有同比增加。

数据是否靠近计算单元

多路CPU或CPU与GPU协同工作时，数据可能需要跨节点或跨互联访问。NUMA布局、内存亲和性和设备拓扑会影响访问延迟。对于频繁交换上下文、检索结果和中间数据的智能体应用，数据放置不合理可能放大延迟。

这里的“一致性互联”也不应只理解为连接速度。采购方需要关注不同处理器、内存和加速器之间如何共享或同步数据，以及软件栈是否能够利用这种拓扑。理论带宽很高，如果应用仍然频繁复制数据或无法保持合理的数据局部性，实际收益可能有限。

工具调用链可能比模型本身更慢

智能体的工具调用通常跨越多个系统：API网关、身份认证服务、检索系统、数据库、业务系统和消息队列。任何一个环节出现排队或重试，都会反映为用户感知到的整体延迟。

建议把一次任务拆成可观测的时间段：

• 模型首轮推理时间；
• 工具选择与参数生成时间；
• 网络往返时间；
• 工具服务执行时间；
• 数据库或向量检索时间；
• 返回结果解析和上下文拼接时间；
• 后续模型推理时间；
• 重试、超时和错误处理时间。

如果模型推理只占总耗时的一小部分，继续升级GPU未必能解决问题。相反，优化连接池、减少不必要的数据复制、改善索引、压缩工具返回结果、缩短上下文，可能更有效。

工具调用还会放大尾延迟。一次任务只调用一个工具时，单个服务的P99延迟可能尚可接受；当任务需要串行调用多个工具时，任一环节变慢都可能拖累最终响应。因此，测试时不能只看平均值，应记录不同调用深度下的P50、P95和P99延迟。

以Vera架构报道为观察入口，而非性能结论

EEPW于2026年9月9日报道英伟达Vera架构，为讨论下一代AI基础设施提供了一个切入点。但在采购决策中，不宜把单一架构报道直接等同于某种产品性能结论，也不能仅凭芯片名称判断它是否适合某类智能体业务。

更稳妥的做法，是借此重新审视服务器架构的评价维度：

• CPU是否能及时处理大量短任务和调度事件；
• GPU与CPU之间的数据交换是否高效；
• 内存容量和带宽是否匹配上下文及检索负载；
• 多处理器之间的一致性和数据共享机制是否适合应用；
• 网络是否能承受工具调用和数据访问产生的并发；
• 存储系统是否会成为知识库、日志和状态数据的瓶颈；
• 编排框架、驱动、运行时和监控工具是否支持目标拓扑。

换句话说，架构名称只能帮助采购方提出问题，不能替代真实业务测试。尤其不能把厂商或媒体对峰值能力的描述，直接当作企业生产环境中的端到端结果。

三类场景的选型重点

智能体推理服务

如果业务以在线问答、流程助手和自动化决策为主，应优先测试并发请求下的响应时间、首Token延迟、完整任务耗时和尾延迟。CPU重点关注单核性能、调度能力和网络处理能力；GPU则关注显存、推理吞吐和多实例隔离。

企业知识库

知识库场景的瓶颈可能位于文档解析、向量检索、重排、数据库访问或上下文拼接。除了GPU，还应评估内存容量、内存带宽、缓存命中率、存储随机读性能和网络延迟。测试数据应尽量接近真实文档规模，不能只用少量样本验证。

自动化工作流

自动化工作流通常包含多个外部系统和较多异常分支。采购方应重点观察CPU调度、连接管理、消息队列、权限校验和重试机制。此类负载不一定需要最高规格GPU，但往往更依赖稳定的CPU、内存、网络和存储协同。

采购前应提出的十个问题

1. 目标业务的一次完整任务平均包含多少轮模型推理？
2. 每次任务平均调用多少个工具？调用是串行还是并行？
3. 模型推理耗时占端到端耗时的比例是多少？
4. CPU负载是持续吞吐型，还是大量短任务和突发任务？
5. 单核性能、总核心数和线程数，哪一项与实际瓶颈最相关？
6. 上下文、检索结果和中间状态需要在CPU内存与GPU显存之间复制几次？
7. 内存容量、带宽和NUMA拓扑是否与知识库规模及并发量匹配？
8. 网络、数据库、向量检索和存储的P95、P99延迟分别是多少？
9. 多GPU或多路CPU之间的一致性互联，软件栈是否能够实际利用？
10. 是否用真实工具链、真实数据量和真实并发完成过端到端压测？

最后：用业务指标替代单点参数

智能体AI服务器选型的关键，不是找到一颗“最强”的芯片，而是确认整个系统能否在目标任务下稳定完成闭环。GPU决定模型计算能力，CPU承担调度和数据处理，内存影响上下文与检索效率，网络和存储决定工具链的数据往返，而一致性互联则影响不同处理单元之间的协同成本。

对企业采购者而言，最有价值的验收指标应当是单位时间完成的有效任务数、完整任务延迟、失败与重试比例、资源利用率以及高并发下的尾延迟。只有把这些指标与CPU、GPU、内存带宽、网络和存储一一对应，才能判断究竟需要升级主机处理器、扩充内存、优化工具调用链，还是继续增加GPU资源。