智能体算力采购不能按“GPU单价×数量”估算。与传统批量推理不同，智能体一次任务往往包含多轮模型推理、工具调用、数据读取、上下文拼接、权限校验和异常重试。真正需要核算的，是完成一个有效任务的全链路成本，而不是某个芯片的峰值吞吐。
先建立端到端成本模型
可以把总成本拆成四层：
固定资本成本包括服务器、GPU、CPU、内存、网络和存储设备的采购投入。运行成本包括设备折旧、能源、机房资源以及软件运行所需的基础设施。任务执行成本则与模型推理次数、工具调用次数、数据搬运和检索负载直接相关。最后还要计入失败成本，例如超时、重试、权限校验、异常处理和人工介入带来的额外消耗。
其中，任务执行成本通常不是由GPU单独决定。CPU负责请求编排、线程调度、协议解析和结果处理；内存承担上下文、缓存和检索数据访问；网络与存储影响工具链的往返时间。如果模型推理只占完整任务耗时的一小部分，继续增加GPU资源，可能只提高局部吞吐，却无法降低单位任务成本。
更合理的指标是：
单位有效任务成本 = 总基础设施成本 ÷ 成功完成的有效任务数
“有效任务数”必须排除失败请求、重复重试和只完成部分动作的任务。否则，表面上的高吞吐可能掩盖了较高的错误与补偿成本。
采购时看成本结构，而非单点参数
智能体推理服务应重点评估并发下的完整任务耗时、首Token延迟和尾延迟；企业知识库还要核算内存容量、内存带宽、缓存、检索和存储访问；自动化工作流则要关注工具调用链、连接管理、重试和状态回写。
测试中应记录模型推理、网络往返、工具执行、数据库或向量检索、上下文拼接以及异常处理分别耗时多少。只有明确成本集中在哪个环节，才能判断是扩充GPU、升级CPU、增加内存，还是优化数据访问链路。
采购决策还应比较不同负载下的资源利用率：核心数很多但大量时间等待外部工具，可能意味着CPU投入过剩；GPU利用率较高但任务仍被检索和网络拖慢，则继续堆叠加速器并不经济。最终验收应围绕单位时间完成的有效任务数、完整任务延迟、失败与重试比例，以及高并发下的尾延迟展开。能把硬件投入对应到这些业务指标，才是真正可执行的算力成本模型。