Arm AGI CPU 基准测试令 AMD 承压，但 1.99 倍领先优势基于模型推算

Arm 表示，在七项选定工作负载中，其新处理器每机架可完成的工作量接近 AMD EPYC 9755 的两倍。Arm AGI CPU 基准测试报告称，在基于服务器功耗假设对实测芯片结果进行缩放后，Arm 的平均优势达到 1.99 倍。

这一标题看似意味着 AMD 遭遇决定性失利。但底层结果讲述的是一个更有保留的故事。Arm 单芯片平均领先 1.20 倍，而其大得多的机架优势主要来自于在固定功耗预算内可容纳更多服务器。

Signal65 通过一项由 Arm 委托的分析审查了这些测试。不过，该机构并未在独立硬件上重新运行完整对比。该基准测试评估的也是围绕 AI 智能体的 CPU 工作，而非模型智能或加速器推理能力。

因此，这一结果之所以重要，原因很具体。Arm 正要求基础设施采购方以每机架完成的工作量来评估智能体 AI CPU，而不是将插槽性能视为最终答案。

Arm AGI CPU 基准测试将竞争焦点转向机架

Arm 的核心主张并非每一款 AGI CPU 都能在插槽层面以近两倍性能击败每一款 AMD 处理器。

这项机架规模分析将 Arm 的处理器与 AMD 第五代 EPYC 9755 进行了比较。它覆盖了七项与工具执行、检索、Web 服务、软件工程以及模型服务支持相关的工作负载。

Signal65 报告称，Arm 的机架性能模型推算平均比率为 1.99 倍。视具体工作负载而定，单项机架结果介于 1.43 倍至 3.19 倍之间。

这七项测试包括 MySQL、NGINX、Milvus、Terminal-Bench 2、SWE-bench 回放、fastText 和 vLLM CPU 开销。它们代表了 AI 模型周边软件路径的不同环节。

MySQL 衡量事务型数据库吞吐量。NGINX 覆盖 Web 和 API 请求处理，而 Milvus 则代表智能体记忆与搜索所需的向量检索。

Terminal-Bench 2 考察在沙盒命令行环境中完成的工作。该测试采用 72 种任务类型，并同时运行 128 个副本。

SWE-bench 回放覆盖了 259 项软件工程任务。该基准测试并未要求模型在每次运行中选择不同操作，而是回放固定工作流。

这种回放方式很重要，因为 AI 智能体具有非确定性。即使请求任务相同，不同运行也可能涉及不同命令、远程服务延迟或模型生成的计划。

fastText 测量 CPU 词表示训练性能。vLLM 测试则衡量模型服务期间处理器的开销，同时绕过模型的主要计算工作。

最后这一区别可避免一种常见误读。vLLM 结果并不展示 AGI CPU 相较 GPU 运行大语言模型推理的速度。

Arm 的芯片在七项单芯片对比中赢得五项。它在 Terminal-Bench 中领先 AMD 9%，在 SWE-bench 回放中领先 13%，在 fastText 中领先 97%。

AMD 在两项成熟的基础设施工作负载中保持领先。EPYC 9755 在实测芯片层面的 MySQL 性能快 12%，Milvus 性能快 5%。

NGINX 为 Arm 带来 1.20 倍的比率。vLLM CPU 开销工作负载则给出 Arm 1.16 倍的结果。

在全部七项归一化比率中，Arm 的单芯片平均优势为 1.20 倍。该结果具有意义，但远小于机架层面主张所附带的 1.99 倍数字。

机架模型通过计入额定服务器功耗改变了这项对比。它假定双插槽 Arm 服务器的功耗介于 950 至 1,050 瓦之间，具体取决于 AGI CPU 配置。

AMD 系统获得了 1,700 瓦的额定功耗估算。两项计算均包含内存和其他服务器组件，而不只是处理器热设计功耗。

在为网络和配电预留约 24 千瓦机架预算的 8% 后，该模型可容纳 21 或 23 台 Arm 服务器。在相同预算下，可容纳 13 台 AMD 服务器。

这使得每个模型推算机架中可配置 5,712 至 5,888 个物理 Arm 核心。AMD 机架则包含 3,328 个物理核心。

由此形成的密度倍增效应，使每一项 Arm 工作负载在机架层面都超过 AMD。即便是单芯片层面有利于 AMD 的 MySQL，也在每机架比较中变为 Arm 1.43 倍的模型推算结果。

Milvus 从单芯片 0.95 倍升至每机架 1.54 倍。SWE-bench 回放则在机架模型下从 1.13 倍升至恰好 2.00 倍。

fastText 产生了最大的比率。其 1.97 倍的实测芯片结果，转化为 3.19 倍的模型推算机架结果。

这些数字支持 Arm 的论点：受功耗限制的数据中心应评估总有效工作量。但它们并未展示两套实际运行的机架在直接测量的墙插功耗下完成这些工作负载的结果。

为什么智能体 AI 让 CPU 工作更显眼

AI 智能体将大量工作转移到加速器之外，使 CPU 容量成为用户可感知体验的一部分。

传统生成式 AI 请求看起来可能以模型推理为中心。生产环境中的智能体则会执行更长的序列，包括规划、检索、工具调用、验证和状态管理。

GPU 或其他加速器仍负责密集的神经网络计算。CPU 则协调周边执行路径的大部分工作，并运行智能体所选择的众多工具。

编程智能体提供了一个实际示例。它可能检查代码仓库、启动沙盒、安装依赖、编译代码、运行测试并分析故障。

每次模型调用都可能触发新一轮 CPU 工作。并发运行数千个智能体，会成倍增加容器、数据库、API、存储和调度系统所承受的需求。

企业智能体形成了不同的工作负载特征。它们可以查询记录、调用内部服务、应用访问策略、序列化响应、更新工作流状态并写入审计日志。

检索会增加索引和向量搜索操作。模型服务则会在加速器周围增加分词、请求调度、批处理、流式传输和缓存元数据管理。

Arm 的评估框架将这些工作划分为智能体框架功能和特定用例工具。它还将组件基准测试与端到端任务测量区分开来。

组件测试有助于隔离处理器行为。端到端测试则显示，更快的组件是否会带来更快或更可靠的任务完成结果。

任何一种方法单独使用都不足够。处理器可能在数据库基准测试中领先，却未必能缩短智能体的整体工作流，尤其是在模型延迟占主导时。

端到端结果同样可能掩盖性能差距的原因。不同的模型、网络、工具或智能体决策，都可能压过底层处理器差异。

Arm 提出可回放的智能体轨迹，作为连接这两种方法的一座桥梁。轨迹记录智能体会话中产生的操作，并在每个系统上执行相同序列。

该技术可减少模型决策造成的波动。它也使比较更具可重复性，因为两款处理器接收到等效的工作流。

不过，回放移除了实时系统的一部分。它衡量的是基础设施执行既定路径的速度，而不是完整智能体栈是否能找到更优路径。

这一边界解释了为何“推理和规划”这一标签需要谨慎看待。相关测试衡量的是 CPU 对这些工作流的支持，而不是机器推理的质量。

同样的谨慎也适用于并发性。如果响应时间在持续利用率下崩溃，能够启动更多智能体环境的服务器并不会自动变得更好。

Arm 的方法论强调在保持响应能力的同时完成有用工作。这一框架将吞吐量与数据中心面临的物理限制联系起来。

供电能力已成为其中一项限制。无论芯片供应情况如何，冷却能力和机架空间同样限制运营商可部署的处理器数量。

在这些条件下，单插槽领先并不总能带来最佳的设施级结果。如果其配套服务器消耗更多功耗，即使处理器略快，也可能在机架规模上落败。

相反，即使在部分芯片级测试中失利，效率更高的服务器也可能创造更大的总容量。Arm 的 MySQL 和 Milvus 结果便在其模型中说明了这种可能性。

Arm 在 Fujitsu、Meta 和 OpenAI 的支持下开发了这一方法论。他们的支持表明业界对更具代表性的 CPU 测量感兴趣，但并不意味着该框架已成为行业标准。

Meta 表示，生产环境智能体需要更清晰地了解工作负载如何使用其下方的基础设施。OpenAI 强调，编排和工具执行是需要具有代表性基准测试的领域。

Fujitsu 将这一工作与其高性能 Arm 架构处理器的开发联系起来。这三种观点都支持改进测量方式，尽管每个组织也都对 Arm 架构基础设施抱有利益诉求。

该框架本身承认，它并非一套完成的基准测试套件。它定义了工作负载类别和测量边界，但评分机制和更广泛的共识仍未解决。

这一区别至关重要。Arm 提出了一种构建讨论的方式，随后使用与该提案相符的测试发布了对其有利的结果。

1.99 倍结果来自密度，而非芯片性能翻倍

Arm AGI CPU 的性能叙事更多取决于模型推算的部署密度，而非压倒性的插槽级性能。

由于相同硬件并非适用于每项工作负载，Arm 测试了两种 AGI CPU 配置。Terminal-Bench 2 和 SWE-bench 使用了运行于 2.8 GHz、配备 DDR5-7200 内存的 128 核芯片。

其余五项工作负载使用了运行于 3.2 GHz、配备 DDR5-8000 的 136 核 AGI CPU。AMD 的对比系统使用一个配备 DDR5-6400 的 128 核 EPYC 9755 插槽。

两个平台运行相同的基准测试脚本，但并未运行完全相同的软件环境。

大多数 Arm 测试使用 Ubuntu 24.04 和定制的 Linux 7.1.3 构建版本。SWE-bench 测试使用 Ubuntu 26.04。

AMD 记录的主要配置使用 Ubuntu 24.04 和 Linux 6.8。部分设置也因测试而异。

软件差异可能影响编译器行为、调度、驱动程序和应用性能。这使得将每一项差距完全归因于处理器架构变得更加困难。

服务器功耗模型带来了另一个重要区别。Signal65 和 Arm 使用额定数据，而不是测量满载生产机架。

额定功耗对于容量规划仍有价值。即使典型功耗较低，运营商也不能安装超过机架供电和散热设计能力的设备。

不过，额定功耗可能与特定工作负载下的实际功耗存在差异。一个系统在某项应用中可能远低于额定最大值，而在另一项应用中接近该值。

实际功耗还取决于内存配置、存储、网络、散热、电源、固件和系统管理策略。当服务器数量决定标题结论时，这些变量便具有重要影响。

内存假设改变了报告中的优势。Arm 的主要模型为每个硬件线程分配 4 GB 内存。

AMD 的同步多线程为每个物理核心提供两个硬件线程。Arm 测试的设计则每核使用一个线程。

这一选择使模型推算的 AMD 服务器拥有约 2 TB 内存，而 Arm 服务器约为 1 TB。它为 AMD 内存分配了 336 瓦，为 Arm 内存分配了 192 瓦。

Signal65 还计算了一种按每个物理核心分配内存的情景。在这种替代方案下，AMD 所需的内存功耗更低，Arm 的平均机架优势从 1.99x 降至约 1.81x。

Arm 仍保有显著的建模优势。这一下降表明，合理的容量规划选择能够实质性改变最终结果。

内存容量不只是基准测试中的一个细节。某些智能体部署需要维护大型索引、缓存、状态存储或并发执行环境。

内存更大的服务器可以支持更低容量但密度更高的配置无法高效承载的工作负载。因此，采购方必须比较可用系统容量，而不只是标准化吞吐量。

AMD 的 EPYC 9755 支持 128 个物理核心和 256 个线程。它也属于一个广泛应用于通用计算、数据库、虚拟化和 AI 托管工作负载的服务器平台。

Arm 的 AGI CPU 面向的是更具针对性的价值主张。它将高密度 Arm 核心与面向 AI 基础设施的大量内存带宽和 I/O 相结合。

这种专用化并不意味着任何一种架构在所有场景下都更优。它改变的是哪些约束条件决定了更合适的选择。

面临固定功耗上限的云运营商，可能会优先考虑每机架完成的任务量。数据库采购方则可能更重视单插槽性能、软件成熟度、内存容量或许可证机制。

AI 集群运营商可能更在意让昂贵的加速器保持忙碌。更快的 CPU 侧准备和编排可以减少加速器的空闲时间，但这些测试并未衡量完整的加速器支持工作流。

这使得 Arm AGI CPU 与 AMD 的比较比标题暗示的范围更窄。它比较的是部分 CPU 可见任务和一个建模部署场景。

这并非一项总成本研究。公开结果没有提供采购成本、软件迁移、运维支持、网络或设施变更的完整对比。

它们也没有将 Arm 与所有相关的 x86 处理器进行比较。AMD 还有其他 EPYC 配置，而 Intel 则凭借 Xeon 平台参与企业和云部署领域的竞争。

Nvidia 的 Vera 处理器提供了第二条基于 Arm 的路径。一项独立的 Vera 工作负载研究报告称，在类似智能体的任务中，Vera 相较 EPYC 9755 展现出强劲的每核心表现。

该研究没有测量功耗或整机吞吐量。其范围更窄的结果进一步说明，需要区分每核心、每插槽、每机架和端到端的说法。

AMD 也在宣传 CPU 是智能体 AI 系统的关键组成部分。其自身的 智能体 CPU 论述强调了编排、数据处理、安全性和加速器支持。

因此，真正的分歧并不在于 CPU 是否重要，而在于采购方应如何定义工作负载、标准化系统，并将组件测量结果转化为部署决策。

Arm AGI CPU 性能声明未能证明什么

Signal65 验证了 Arm 的记录和计算，但这一过程并不等同于由独立实验室重新运行测试。

Signal65 远程观察了 Arm 的测试运行。它检查了原始日志、结果文件、脚本和配置记录。

一个独立审查团队使用自己的代码重建了计算过程。根据分析，其在 0.5% 误差范围内复现了全部七项结果。

这项工作提供的审查力度高于未经审核的厂商图表。它检验了报告中的比率是否可由所采集的结果和机架模型推导得出。

不过，Arm 委托了该分析，并提供了受测系统。Signal65 并未采购等效硬件，也没有在自己的实验室中独立重复完整实验。

审查还面临配置缺口。Signal65 只能独立确认一套用于单独沙盒比较的 EPYC 9965 系统的 BIOS 和内存设置。

它无法独立验证 AGI CPU 和 EPYC 9755 系统的每一项 BIOS 与内存设置。这限制了对较小性能差异来源的确定性判断。

这种差异在结果接近时尤为重要。97% 的 fastText 领先优势不太可能因微小设置变化而消失，但 5% 或 9% 的差距则值得更仔细审查。

算术平均数还带来另一项局限。对标准化比率取平均，会让每项工作负载拥有相同影响力，而不管真实部署执行该操作的频率如何。

一家公司可能持续运行数据库事务，却很少训练 fastText 模型。另一家公司则可能运行数千个编程沙盒，而事务基础设施很少。

因此，公开的 1.99x 平均值并不能预测每位采购方的容量增益。每个运营商都需要根据自身执行特征得出经工作负载加权的结果。

测试套件还混合了成熟应用与新兴的智能体代理。MySQL 和 NGINX 历史悠久，而基于回放的智能体基准测试仍相对年轻。

这种组合很有用，因为智能体会调用熟悉的基础设施。但它也存在争议，因为所选的组合决定了哪些内容获得同等权重。

原始报道指出，该结果并不能证明其在智能体 AI 领域的整体领先地位。处理器、工作负载、配置和由 Arm 开发的方法论共同界定了其适用范围。

vLLM 结果中未包含完整的 GPU 推理。推理和规划类别也没有测试模型是否推理得更准确。

机架计算并未纳入直接测量的 24 千瓦部署。它是在为机架基础设施预留容量后，依据额定系统功耗对服务器数量进行建模。

价格并未纳入公开比较。应用许可、迁移工作、员工培训，以及与现有部署工具的兼容性也同样未被纳入。

这些遗漏并不会使该基准测试失效。它们界定了结果所能支持的结论。

Arm 可以合理地表示，其受测系统在有据可查的假设条件下实现了更高的建模机架吞吐量。但它不能将这一说法转化为智能体 AI 领域的普遍领先地位。

AMD 可以合理地指出两项单芯片胜利以及内存假设的影响。这些观点并不能抹去 Arm 在公开模型中的密度优势。

最有建设性的解读介于这两种立场之间。Arm 提出了一个可信的假设，值得在生产硬件上开展更广泛、独立的测试。

这一假设是：机架功耗和持续的智能体工具吞吐量应比传统的插槽比较获得更高权重。1.99x 的结果是支持这一论点的早期案例研究。

对采购方而言，这套方法可能会和当前胜者一样具有影响力。一套通用且透明的测试套件将使运营商能够在相同边界条件下比较 Arm、AMD、Intel 和 Nvidia。

这样的测试套件需要测量系统功耗、等效软件、已记录的固件、工作负载级别的加权，以及可重复的端到端验证。

它还应报告多个视角，而不是将一切压缩为一个比率。每核心、每插槽、每瓦、每机架和每美元结果回答的是不同的运营问题。

任务成功率和延迟应与基础设施吞吐量分开衡量。如果模型或网络延迟占主导地位，一个完成更多回放操作的系统未必能带来更好的智能体结果。

三个信号将决定 Arm 的机架声明能否成立

生产硬件、更广泛的竞争对手测试以及客户部署将决定 Arm 的建模优势能否转化为实际运营优势。

第一个信号是在最终量产版 AGI CPU 系统上进行独立测试。Signal65 表示，当前结果反映的是早期系统，并计划开展更广泛的后续工作。

一项有说服力的后续研究应测量每项工作负载期间的完整服务器功耗。它应采用可比的操作系统、编译器设置、内存容量、固件和散热条件。

最有力的测试将部署多台服务器，并通过实验验证机架计算。这将展示密度、网络、散热和持续利用率是否如模型所示。

如果量产测试仍接近 1.99x 的平均值，Arm 的立场将大幅增强。若出现明显下降，则表明额定功耗建模高估了可部署容量。

第二个信号是与更广泛处理器阵容的比较。AMD EPYC 9755 很重要，但一款 x86 处理器无法代表整个市场。

AMD 更新、核心数更高的选项可能会改变密度计算。Intel 在 Web 服务、数据库、检索和工具执行方面的表现也可能不同。

Nvidia Vera 也值得直接比较，因为它使用 Arm 兼容核心，但通过不同的系统设计瞄准 AI 基础设施。它的加速器连接能力提供了另一条部署路径。

更广泛的测试应采用相同工作负载和透明评分。厂商特定的基准选择会让采购方只能比较互不兼容的声明。

如果 Arm 在多个竞争对手面前仍保有机架优势，其方法论的可信度将超越某一组有利配对。如果领先地位变化显著，工作负载选择就会成为更重要的故事。

第三个信号是真实客户采用情况及公开的运营数据。Arm 已将 AGI CPU 定位为面向超大规模云厂商和其他大型 AI 基础设施运营商的产品。

公开部署应报告迁移前后的已完成工作量、延迟、功耗和利用率。它还应说明为适配 Arm 架构所需的软件变更。

运营证据可以揭示基准测试未能捕捉的问题，包括依赖项兼容性、可观测性、容器镜像可用性、工作负载放置、故障恢复和管理员工作量。

当客户结果覆盖持续的生产流量时，其意义最大。短期演示无法复现数千个持续运行智能体的需求模式。

2026 年 10 月的 Arm 基准测试公告明确主张应以机架规模评估基础设施。它也指出，随着智能体架构变化，方法论必须演进。

这一承认是恰当的。智能体软件仍在快速变化，今天具有代表性的工具序列，明天可能就会成为过时的代理指标。

基础设施团队应将 Arm AGI CPU 基准测试视为审视自身瓶颈的理由，而不是普遍适用的采购结论。

首先追踪智能体的时间消耗所在。将模型推理与检索、沙盒启动、工具执行、数据库访问、编排和验证区分开来。

然后将这些阶段映射到实际约束条件。一个集群可能面临功耗上限、内存容量限制、加速器饥饿，或不可接受的任务延迟。

这一过程可以将宽泛的厂商声明转化为可测试的本地问题。它也防止一个基准平均值取代针对具体工作负载的容量规划。

评估智能体基础设施的工程团队可以在可搜索的知识库中保存基准测试笔记、配置记录和部署发现。当软件或硬件变化使先前比较失效时，这些记录将变得极具价值。

Arm 已确立了开场立场：其处理器在七项精选工作负载中平均实现了每芯片 1.20x 和每建模机架 1.99x 的表现。AMD 仍赢得了两项芯片级测试，而多项假设塑造了更大的比率。

下一个决定将由独立测试人员和基础设施采购方作出。实测的生产机架能否重现 Arm 的密度优势，还是实际工作负载会缩小这一差距？