Arm 如何评估智能体 AI 的 CPU 性能

赞助内容

Timothy Pricket-Morgan

发布于 2026 年 10 月 29 日星期四 // 09:00 UTC

在从机器学习到聊天机器人再到智能体 AI 的发展过程中，发生了一件有趣的事：六十年来主导商业计算的中央处理器（CPU）曾一度被大规模并行、因而非常擅长处理大量向量和矩阵数学运算的 GPU 和 XPU 所取代，如今又重新回到了核心位置。以至于 CPU 市场预计将从 2025 年的 260 亿美元增长到仅仅五年后的 2460 亿美元，其中大部分增长来自 AI 主机 CPU 以及用于在智能体 AI 工作流中执行工作的智能体 AI 沙箱。

但问题在于：并非所有 CPU 都是生而平等的，超大规模云厂商、云构建商、AI 模型构建商以及新型云、主权 AI 中心和企业都将不得不在两种同样强烈的愿望之间取得平衡：一方面是限制其集群中不同 CPU SKU 数量的愿望，另一方面是让企业工作流的不同部分（如今包括智能体 AI）与支撑所有这些体现其工作流的、由人类编写和 AI 生成的代码的底层硬件实现完美匹配的愿望。

而且别忘了，支撑智能体 AI 的推理本身也在快速变化。

这使得在数据中心工作负载日益复杂的情况下，选购 CPU 比以往更加复杂。在数据中心规模下，问题变成了在一个机架的功耗和散热包络内能完成多少成功任务。这就是为什么 Arm 主张客户必须考察 CPU 在插槽、系统和机架层面的性能，同时关注 CPU 核心的单线程性能以及核心在插槽内、跨系统、跨机架的扩展能力，以聚合可用于并发运行众多 AI 智能体同时满足 SLA 的性能。

这并非 IT 行业第一次不得不应对复杂的多层、多系统工作负载，并试图创建基准测试来模拟这种复杂性，以便企业做出明智的采购决策。例如，TPC-E 基准测试模拟了仓库的运作——那种有叉车的真实仓库，而不是数据仓库——并在数据库、应用和基础设施层运行交互式和批处理混合工作负载。

“多层和有状态计算并不新鲜，现有的云和企业基准测试对于理解系统的各个部分仍然很重要，”Arm 产品管理高级总监 Jeff Defilippi 告诉 The Next Platform。“智能体 AI 带来的变化在于这些组件如何组合。单个任务可以动态地串联模型调用、检索、数据库事务、代码执行、工具调用和状态变更，一步的结果决定下一步发生什么。这使得成功完成任务——而非任何单一组件指标——成为更有意义的性能单位。”

“所以这并不会使现有基准测试变得不那么有用。我们仍然需要组件级测量来理解性能差异来自何处，”Defilippi 继续说道。“但它们需要与端到端测量相连接，以显示系统完成任务的速度和效率，以及随着更多智能体并发运行和整体服务器利用率提高，这种性能如何保持。”

顺便说一句，Arm 并不主张某种黄金标准的智能体 AI 基准测试。相反，Arm 主张一种将既有组件基准测试与智能体工作负载测量和端到端任务评估相结合的方法论。InferenceX 和 TPCx-AI 等基准测试可以代表工作流的重要部分，包括推理服务和机器学习流水线。但智能体系统还包括 CPU 侧的编排、检索、状态管理、工具执行、沙箱、安全以及其他活动，而这些离散基准测试并非为测试这些活动而设计。

“因此，目标是全面审视智能体流程，同时保留组件级测量，让工程师了解性能差异的来源，”Defilippi 说。“Arm 打算对广泛的行为进行表征，从有针对性的组件测试到更高层级的指标，如实际耗时任务完成、智能体密度和效率。该方法论适用于 AGI CPU 系统，但我们是在定义工作负载和测量框架，而不是发布具体的 AGI CPU 集群基准测试。”

当然，Arm 提出的这套方法论不会仅限于 CPU，因为智能体 AI 并不只在 CPU 上运行。不仅需要测量 CPU 的组件级性能，还需要测量 GPU 或其他 XPU 加速器、内存子系统和网络的性能，同时我们还必须密切关注编排、检索以及工具的部署与执行是如何运行的。一套有用的智能体 AI 测试方法论既需要能够暴露单个瓶颈的受控组件测试，也需要衡量用户结果的端到端测试。

在智能体 AI 方面，顺序延迟——这是 CPU 的职责范围，CPU 是一种中等并行度的计算引擎，其缓存层级和时钟频率经过优化，具备很强的顺序处理能力——是智能体循环中任务完成的关键约束。智能体 AI 基础设施中的 CPU 必须等待 GPU 或 GPU 与 XPU 的组合完成预填充 token 处理和解码 token 输出，这些处理驱动着智能体工作流，催生查询、激活工具，并且常常生成代码。

“单线程性能很重要，因为智能体循环的许多部分对延迟敏感，并且位于关键路径上，”Defilippi 说。“但这只是一个维度。智能体基础设施还必须同时支持许多智能体，因此随着并发度上升，核心数量、内存带宽、缓存容量、调度效率以及高利用率下的持续性能变得越来越重要。”

显然，当单个逻辑操作跨越系统中多个相互依赖的步骤时，基准测试的测量问题就会浮现。一个智能体可能会对任务进行推理、调用工具、等待数据库或 API 响应、更新其状态、返回模型推理，然后决定下一步做什么。由于后续步骤往往依赖于先前步骤的结果，即使底层系统的不同部分可以并行运行，延迟也会在关键路径上累积。

“因此，许多智能体工作流既存在延迟问题，也存在并发问题，”Defilippi 解释道。“对于智能体而言，下一个动作往往要等到前一个依赖完成才能开始，因此 CPU 侧执行、内存访问、模型推理、工具调用和网络延迟都可能影响任务完成时间。缩短该路径中 CPU 可见部分的延迟，可以让智能体更快进入下一个动作，并且在涉及加速器的情况下，也能更快地将工作交还给 GPU 或 XPU。”

“与此同时，基础设施很少只运行一个智能体。当一个依赖正在等待时，其他智能体和流程中相互独立的部分可以继续执行。随着并发度提高，核心数量、内存带宽、缓存容量、调度效率以及利用率下的持续性能变得越来越重要。因此，系统必须在每条依赖链上的响应式执行与足以同时支持许多智能体的总吞吐量之间取得平衡。”

这就引出了在三个层面上评估 CPU 性能的实用方法。在核心层面，测量位于关键路径上的工作的延迟和每线程性能。在系统层面，测量吞吐量、并发度、内存行为以及高利用率下的持续性能。在机架层面，测量基础设施在其功耗、冷却和物理限制内能够维持多少已完成的工作。

组件测量解释了为什么一个平台的行为与另一个平台不同。端到端智能体测量则显示这些差异是否真正提高了任务成功完成率。

在加速器推理属于智能体循环一部分的系统中，CPU 性能还会影响这些加速器的使用效率。CPU 负责请求调度、编排、数据准备、运行时服务以及模型执行周围的其他功能等工作。CPU 侧的延迟会延长整体任务路径，而高效的 CPU 执行可以让工作更快地交还给加速器。因此，基础设施团队应在真实负载和并发条件下评估性能，而不是仅依赖轻负载下的峰值结果。

一如既往，系统的架构必须反映工作负载，并且会根据这些工作负载的性质，在计算引擎、内存、网络和存储方面做出不同的选择。而且，使情况更加复杂的是，很难预测智能体 AI 工作负载在未来几年将如何演变。但在延迟与并发之间存在一些考量，无论智能体 AI 架构在未来四到五年内如何变化，这些考量都将持续存在——而这一时间跨度正好与当今部署在现场的机器仍将运行的时间相符。

Defilippi解释了这种相互作用：“当推理服务成为智能体循环的一部分时，调度、分词、序列化和KV缓存管理等CPU可见的功能可能会给内存子系统带来压力。这使得内存带宽、每核带宽、缓存行为和内存局部性都与系统推进的效率息息相关。”

“等待工具响应则不同。当一个智能体在等待数据库、API或沙箱应用时，CPU可以调度其他工作。在低并发度下，这种依赖关系对单个任务的完成时间有很大影响。在较高并发度下，运行其他智能体的能力使得吞吐量、内存带宽和调度效率变得越来越重要。”

在大规模场景下，这些测量指标最终都归结为机架层面的经济性。数据中心在固定的功耗、冷却和物理限制内运行。相关的问题不再仅仅是单个处理器能提供多少性能，而是基础设施在这些限制内能够维持多少有用的智能体工作。归根结底，机架层面发生的情况——或许在不久的将来，还有行级层面发生的情况——才是那些实施智能体AI的人最关心的。

Defilippi表示：“这就是为什么每机架任务数和每任务能耗等指标与CPU级性能一起变得重要。在相同的机架级功耗范围内完成更多任务，可以直接转化为更好的基础设施经济性和更低的任务成本。热余量还使系统有能力在需求上升时吸收活动突发而不影响性能。不过，我们会用‘调度批次’来限定这一比较，因为某些智能体工作负载本身可能就是面向批处理的。更广泛的观点是，持久、高利用率的智能体服务使得每机架的持续效率、密度和吞吐量变得越来越重要，无论单个任务是交互式还是批处理式的。”

Arm已开始将这一框架应用于其AGI CPU。Arm采用与智能体方法论一致的工作负载，委托一家独立的第三方对AGI CPU在智能体工作流中CPU可见部分（包括工具调用、编排以及推理与规划）的性能与AMD EPYC Turin进行对比评估。

测试以实测的服务器级性能作为机架级建模的基础，结果显示每机架性能约为AMD EPYC 9755的两倍，这证明了为什么机架级性能可以讲述与孤立的单核或单插槽基准测试不同的故事。

归根结底，这可能是IT组织有史以来遇到的最复杂的容量规划工作。他们将需要组件供应商和系统制造商的大量帮助来理清这一切，因为凭感觉行事并寄希望于最好的结果将是一个非常昂贵的选择。

计算