智能体基础设施的压测，不能沿用单一模型推理的测试方法。一次智能体任务通常包含推理、检索、工具调用、数据库访问和多智能体协同，压力会在不同环节之间传递。真正需要验证的，不是某个芯片的峰值性能，而是整条任务链在并发上升、调用变长和数据访问变复杂时，是否仍能保持稳定响应。
先分层，再定位瓶颈
第一层是智能体运行时，重点观察任务编排、上下文管理和工具调用是否造成额外等待。压测不能只发送固定问题，而应覆盖短任务、长任务、连续调用和多智能体协同等负载，记录端到端响应时间、任务完成率以及异常重试带来的放大效应。
第二层是计算与内存系统。智能体工作负载并非全部由加速器承担，CPU需要处理数据面任务、任务调度和外部工具交互。测试时应分别观察CPU利用率、内存带宽、缓存命中情况与加速器使用率，判断瓶颈究竟来自计算能力不足，还是来自数据搬运和任务编排。如果CPU或内存系统已经饱和，继续增加加速器资源通常无法改善整体性能。
第三层是互连与数据访问。检索、数据库访问和工具调用会把任务延伸到外部服务，网络延迟、带宽竞争和数据返回速度可能成为关键约束。这里应将计算压力与数据访问压力组合测试，避免只在理想的本地数据条件下评估系统。
第四层是部署位置与软件连续性。智能体任务可能横跨云端、边缘和物理终端，压测需要比较不同节点之间的响应差异、资源弹性和故障转移表现。Arm强调统一计算平台和软件基础，正是为了降低跨层部署时的适配成本；企业应把应用迁移难度、工具链成熟度和运维复杂度纳入结果判断。
压测结果最终应形成“工作负载—资源层—瓶颈类型”的对应关系，而不是一个孤立的峰值数字。Neoverse CSS N4强调内存带宽和PCIe Gen 7互连，Arm AGI CPU则面向高并发、数据密集和工具调用频繁的智能体场景。对企业而言，合理的评估顺序应是先拆解任务链，再逐层施压，最后验证整链路稳定性。只有这样，基础设施选型才不会被单点算力指标误导。