NVIDIA Vera CPU 评测：2TB/s 内存带宽，x86 架构的真正挑战者

在数据中心的大部分发展历程中，NVIDIA 将 CPU 仅仅视为 GPU 的驱动芯片。其首款服务器处理器 Grace 也遵循了这一模式。它采用了 Arm 现成的 Neoverse V2 内核，主要作为 Grace Hopper 和 Grace Blackwell 超级芯片的 CPU 部分进行销售。这些超级芯片确实引入了该平台的一个重要组成部分：NVLink-C2C，它使 CPU 和 GPU 能够以远高于 PCIe 的带宽相互访问彼此的内存。

Its successor, Vera, is far more ambitious. It is a clean-sheet design built around Olympus, NVIDIA’s custom Arm core. Olympus implements Armv9.2, and each Vera CPU features 88 cores and 176 threads. Alongside the new cores, the memory subsystem is the other highlight. Each CPU supports up to 1.5TB of LPDDR5X on SOCAMM modules, with an advertised peak bandwidth of 1.2TB/s per socket, which gives Vera the power efficiency of mobile-class DRAM while keeping the memory field-replaceable. Across the two sockets in our test server, that rating comes to 2.4TB/s, and we measured 2,073GB/s on STREAM Triad.

这种雄心壮志也体现在 Vera 的部署领域。它目前仍作为 Vera Rubin 系统中的超级芯片的一部分进行销售，但 NVIDIA 也已将其扩展到 BlueField-4 STX 存储平台以及用于代理沙箱的独立 CPU 服务器。Vera 也获得了 OEM 厂商、超大规模数据中心和网络数据中心运营商 (NCP) 的广泛支持：戴尔、HPE 和 Supermicro 已将 Vera 服务器添加到其产品线中，而超大规模数据中心和 NCP 也准备将其打造为主流产品。这种广泛的可用性至关重要，因为正如我们的测试结果所示，Vera 是 x86 架构同类产品的有力竞争者，并且它为企业提供了第三个 CPU 供应商，有助于其供应链多元化。

关键精华

• 所有 x86 系统的内存带宽都增加了一倍以上。 在 STREAM Triad 测试中，两个 Vera 插槽的读写速度持续超过 2TB/s，是我们测试过的最佳 DDR5 服务器的 2.3 倍。即使通过 NVLink-C2C 读取另一个插槽的内存，Vera 的核心带宽也超过了任何 x86 插槽从本地内存获取的带宽，并且在使用大页内存时，本地延迟比 EPYC 9175F 低 13%。
• 一款面向广大中端市场的均衡型芯片。 一颗 3.4GHz 的 Olympus 核心在 7-Zip 压缩测试中比 5.0GHz 的 EPYC 9175F 快 12%，并且在三项单线程 Python 测试中赢得了其中两项。在满载情况下，Vera 仅使用不到一半的核心数，就能达到 EPYC 9965 63% 到 72% 的 7-Zip 吞吐量，在单线程性能上与 AMD 的单核性能专家不相上下，在整个系统吞吐量方面也与之匹敌。
• Vector 和加密技术是其明显的弱点。 六条 128 位 SVE2 管道无法与为其编写的 512 位 AVX-512 代码相媲美。在配置相同的 16 个核心上，Vera 运行 GROMACS benchMEM 的速度仅为 EPYC 9175F 的一半，EPYC 9965 的三分之二；单核 AES-256-GCM 加密的速度约为 9175F 的三分之一。在整个系统中，拥有 384 个核心的 EPYC 9965 在 GROMACS benchPEP 和 AES 测试中均领先约 3 倍。
• 内存密集型高性能计算将带宽转化为速度。 在大型 OpenFOAM 网格上，Vera 的运行速度比 384 核的 EPYC 9965 快 1.44 倍，比 240 核的 Xeon 6978P 快 1.20 倍。在较小的网格上，由于更大的 x86 L3 缓存对性能的影响更大，Vera 位居第二，与 9965 的差距在 12% 以内。
• 数据库和分析技术之间已经存在竞争。 在单路 HammerDB TPROC-C 测试中，88 核 Vera 处理器在 PostgreSQL 数据库上的性能比 192 核 EPYC 9965 处理器高出 26%，在 MariaDB 数据库上高出 8%，但在 MySQL 数据库上落后 19%，在 VillageSQL 数据库上落后 15%；Xeon 6787P 处理器在所有五个数据库引擎上的性能均逊于 Vera 处理器。Vera 处理器在 ClickBench 热测试中完成时间也比 EPYC 9965 处理器快 23%，并且在 256GB Valkey 工作集上处理的请求数量也高出 34%。

规格

规格	NVIDIA Vera CPU
计算与电力
核心优势	NVIDIA Olympus，Armv9.2，支持 SVE2 和 FP8
每个插槽的核心数和线程数	88 个核心，176 个线程（NVIDIA 空间多线程）
时钟速度（实测）	3.41GHz
TDP	可配置功率：250W 至 450W
散热器	空气或液体
缓存
L1 教学	每个核心 64KB
L1 数据	每个核心 96KB，6 路并行
L2	每个核心 2MB，私有
系统级缓存（L3）	每个插槽 164MB，Arm MPAM 分区
面料	第二代可扩展一致性架构，3.4TB/s 二分
内存
类型	每个插槽配备 8 个 SOCAMM2 模块，支持 LPDDR5X 内存。
控制器	8x 128 位（总计 1,024 位）
速度	最高9,600MT / s
带宽	每个插槽最高可达 1.2TB/s（厂商标称值）
容量	每个插槽容量为 256GB 至 1.5TB
I / O
PCIe	第六代，每个插槽 88 条通道（仅限 CPU 平台） x16、x8、x4、x2 分岔
CXL	3.1，第 3 类内存扩展和池化
NVLink-C2C	第二代、1.8TB/s 双向、相干、认证加密
安保防护
机密计算	Arm CCA 域、RME-DA 和 RME-CDA、TDISP、每个虚拟机的密钥

为什么英伟达想要进军CPU行业

要了解 Vera 对 NVIDIA 的重要性，我们需要回顾一下公司的发展历程。NVIDIA 最初围绕 GPU 构建数据中心业务，随后扩展到维持 GPU 运行所需的基础设施。在硬件方面，2020 年收购 Mellanox 带来了连接服务器并在服务器间传输数据的网络技术。在软件方面，CUDA、DOCA 以及更广泛的软件栈进一步拓展了 NVIDIA 在硬件编程和运行方面的影响力。这些优势共同赋予了 NVIDIA 对大部分加速计算平台的控制权。

但该平台仍然需要通用CPU。操作系统必须由处理器来运行，数据必须由处理器来准备，应用程序必须由处理器来管理，并且必须协调发送到加速器的任务。在NVIDIA扩张的大部分时期，英特尔和AMD承担了这一角色。这使得NVIDIA处境尴尬：它虽然可以提供GPU、网络和大部分软​​件，但服务器的核心处理器仍然依赖于另一家公司的处理器。

Grace 的出现是改变这一现状的第一步。它基于 Arm Neoverse V2 内核，为 NVIDIA 提供了一款数据中心 CPU，并通过 NVLink-C2C 技术将该 CPU 与 GPU 更紧密地连接起来。然而，Grace 仍然存在性能差距需要弥补。其内存带宽和效率使其在 AI 主机 CPU 领域具有竞争力，但在大多数其他工作负载中，领先的 x86 处理器仍然保持着显著优势。这种性能上的不平衡限制了 Grace 作为 EPYC 或 Xeon 服务器通用替代品的吸引力。

Vera 通过用 NVIDIA 定制的 Olympus 内核取代 Grace 的 Neoverse V2 内核，并大幅提升内存带宽和容量，从而弥补了这一差距。通过提供具有竞争力的 CPU 以及 GPU、DPU 和网络组件，NVIDIA 可以占据每台服务器更大的市场份额。这也使公司能够更好地掌控其生态系统以及各组件的协同工作方式：CPU 内核、内存子系统、互连和 GPU 可以围绕相同的需求进行设计。Vera 的 CPU 到 GPU 的一致性链路（速率高达 1.8TB/s）正是这种集成的一个具体例证。

提高每个系统的资源利用率只是问题的一部分。强化学习 (RL) 和智能体人工智能 (AI) 为 NVIDIA 提供独立 CPU 系统提供了另一个理由。智能体的功能远不止生成响应。它会调用工具、检索信息、运行代码并检查结果，然后决定下一步操作。大部分执行都在 CPU 上进行，而当下一个模型步骤依赖于 CPU 任务的结果时，执行速度慢会延迟整个序列。因此，单核性能、内存延迟以及负载下的可预测行为对于智能体的响应速度至关重要。

奥林匹斯核心

这些要求与 Vera 的 88 个 Olympus 核心的设计理念高度契合，其核心设计围绕着一个明确的优先事项：确保每个核心都能提供强劲的性能，并在整个插槽繁忙运行时保持这种性能。Olympus 是 NVIDIA 对 Armv9.2 指令集的实现，取代了 Grace 中使用的 Neoverse V2 核心。这种区别至关重要：Arm 定义了处理器运行的指令，而 NVIDIA 则设计了获取、调度和执行这些指令的机制。这种控制权使 NVIDIA 能够根据目标对核心进行调优：在同时运行多个任务的同时，快速完成单个任务。

该目标的前半部分始于每周期指令数 (IPC)：即核心在每个时钟周期内平均完成的指令数量。时钟频率决定了这些周期的发生频率；微架构决定了每个周期内可以完成多少有效工作。NVIDIA 声称其 IPC 比上一代产品提高了 1.5 倍。我们观察到的最高时钟频率为 3.41GHz，但 Vera 的架构强调在每个周期内提取更多工作，并在负载下保持这种效率。这种强调至关重要，因为对于编译器、解释器或数据库操作等具有大量依赖步骤的程序而言，仅仅增加核心数量并不能加快这些步骤的执行速度。

实现高效指令周期 (IPC) 的关键在于持续不断地获取有效指令。Olympus 的前端（即核心中负责获取和解码程序指令的部分）每个周期最多可以解码十条指令。只有当前端持续获得指令时，这种指令宽度才有意义，而当软件频繁地在代码路径之间跳转时，这一点就变得难以保证。因此，Olympus 将神经分支预测器与其他专用预测器相结合，支持每个周期最多执行两个分支。更精准的预测有助于核心获取所需的指令，从而减少执行错误路径和错误后重新开始所花费的时间。

指令获取并解码后，奥林巴斯处理器会采用乱序执行的方式，在之前的指令等待期间寻找可以执行的任务。例如，如果某个操作正在等待内存，那么就可以先执行一个独立的计算。较大的指令窗口为处理器提供了更多找到这类独立任务的机会。

即便如此，某些序列（例如上文所述的依赖链）仍然难以采用这种方法，因为每一步都需要前一步的结果。对于这些序列，Olympus 还采用了值预测技术，让依赖操作从预测值开始，然后在实际结果可用时检查该预测值。正确的预测可以减少这些依赖链上的有效等待时间；而错误的预测则需要修正并重新计算推测性工作。

执行引擎需要足够的容量才能将这些指令转化为已完成的工作。Olympus 将宽广的整数执行资源与专用分支单元、四条加载流水线和两条存储流水线相结合。这些资源满足不同的需求：整数单元处理算术运算、比较和逻辑运算；分支单元解析控制流；加载/存储流水线在核心和缓存之间传输数据。这种平衡至关重要，因为如果指令仅仅因为执行或内存瓶颈而积压，那么更宽的解码器就几乎没有任何意义。

除了这些标量资源外，Olympus 还拥有六条支持 SVE2 的 128 位向量流水线，其中两条流水线还支持 FP8 和加密功能。向量指令可以将操作应用于多个数据元素，因此非常适合数值计算、压缩和数据处理。

奥林巴斯处理器在这方面做出了明显的权衡：其 128 位向量宽度小于竞争对手 x86 处理器通过 AVX-512 指令集提供的 512 位宽度。对于优化的数值内核甚至词法分析器而言，这种差异至关重要，尽管应用程序的性能还取决于特定指令的吞吐量、生成的代码以及数据供应。因此，像 GROMACS 这样的科学应用仍然是对该设计优势的单独考验。

无论是标量还是向量，所有这些执行资源都依赖于数据的及时到达，因此将常用数据保存在靠近执行引擎的位置至关重要。每个核心都拥有一个 64KB 的指令缓存、一个 96KB 的数据缓存和一个 2MB 的私有二级缓存。较小的一级缓存可以快速访问最常用的指令和数据；较大的二级缓存则可以在访问数据需要经过处理器更远的路径之前，保留更多核心的工作集。为每个核心配备充足的私有二级缓存，也是为了实现相同的核心目标：更多的工作可以在本地完成，从而减轻共享缓存和主内存的压力。

预取技术通过在指令请求数据之前将其加载到缓存中，从而对缓存起到补充作用。除了用于常规访问模式的预取器之外，Olympus 还包含一个用于间接访问（例如 A[B[i]]）的图预取器，其中一次查找提供另一次查找的索引。在了解这种关系之后，硬件可以在程序发出请求之前开始获取第二条数据。这有助于解决图处理和其他不规则工作负载中常见的难题：处理器拥有充足的执行能力，但程序的运行取决于能否找到下一条数据。

奥林巴斯架构的最后一部分实现了其目标的另一半：同时运行多个任务。每个核心支持两个硬件线程，因此 Vera 每个插槽可支持 176 个线程。NVIDIA 将其方案称为空间多线程。核心可以将其资源分配给一个活动线程，也可以将资源分配给两个活动线程，从而可以选择将执行能力集中在一个指令流上，还是支持更多并发任务。

NVIDIA 的目标是减少两个线程之间的干扰，从而在两个线程都繁忙时提高性能的可预测性，而这种可预测性正是代理工作负载在高负载下所依赖的。由于这两个线程仍然共享一个物理核心和更大的内存系统，因此资源分区并不能保证应用程序的延迟固定不变。

织物、内存和 I/O

除了单个核心之外，要保持88个宽核心的高效运行，仅仅依靠与DRAM的高速连接是不够的。这些核心还需要交换数据、访问共享缓存以及与外接设备通信。Vera通过NVIDIA第二代可扩展一致性架构（Scalable Coherency Fabric）连接这些资源。Scalable Coherency Fabric是一个内部网状结构，它还能确保共享数据的缓存副本保持一致。核心、Scalable Coherency Fabric和164MB系统级缓存位于同一个计算芯片上，而内存控制器和I/O则位于相邻的芯片组上。NVIDIA将该架构的二分带宽标为3.4TB/s，这是衡量整个网状结构流量容量的指标，与主内存带宽无关。

这种单芯片布局避免了核心间通信或访问共享缓存时，各个计算芯片之间的数据传输。对于软件而言，Vera 还为每个插槽提供一个 NUMA 节点：操作系统将每个插槽视为一组核心和本地连接的内存。这简化了插槽内的组件布局，但这并不意味着网格中每条路径的延迟都相同。双插槽服务器仍然有两个 NUMA 节点，访问另一个插槽的内存与访问本地内存仍然存在差异。

在每个插槽中，共享的系统级缓存（L3）位于前面提到的私有 L2 缓存之上。它使核心有机会在不访问 DRAM 的情况下重用数据，并提供整个插槽共享的缓存容量。其 164MB 的容量相当可观，但一些竞争对手的处理器提供更大的 L3 缓存。当重复访问的工作集对于核心的 L2 缓存来说过大，但可以放入更大的共享缓存时，这一点就显得尤为重要。高 DRAM 带宽有助于数据必须从内存中获取时的性能提升；但这并不能抵消避免直接访问内存所带来的优势。

由于该容量是共享的，Vera 还支持 Arm MPAM，允许系统软件对共享缓存容量进行分区，并管理工作负载之间的内存带宽分配。

当访问请求到达主内存时，Vera 拥有相当大的带宽。八个 128 位 LPDDR5X 控制器提供 1,024 位聚合接口，内存运行速度高达 9,600MT/s，每个插槽的额定容量为 1.2TB/s。内存安装在八个可拆卸的 SOCAMM2 模块上，将 LPDDR5X 与现场可更换模块相结合。这使得 Vera 拥有宽广、高速的内存接口，而无需焊接内存。

原始带宽只是问题的一部分。更有意义的是带宽与共享带宽的核心数量之间的关系。将额定带宽 1.2TB/s 除以 88 个核心，得出每个物理核心约 13.6GB/s 的带宽。这是一种描述处理器带宽平衡的方法，并非每个线程的专用分配或保证。如果增加核心数量而内存带宽没有相应增加，则该比率会降低。

将我们测得的 STREAM 带宽除以物理核心数，得出 Vera 的每个核心带宽为 11.8GB/s，而 240 核 Xeon 6978P 系统仅为 3.8GB/s。这具体体现了 Vera 相对于其计算资源而言，能够提供显著的内存吞吐量。

能效也是这一设计选择的一部分。NVIDIA 估计，满配的 LPDDR5X 内存子系统功耗约为 30W 至 40W，具体数值取决于内存容量。LPDDR5X 的优势在于，它能够在提供如此高带宽的同时，最大限度地降低内存对服务器总功耗的贡献，从而使系统能够将更多的电力和散热资源用于计算。

带宽和效率并不能说明数据容量的大小，容量仍然是一个需要单独考虑的因素。NVIDIA 官方宣称每个插槽最多可支持 1.5TB 的 LPDDR5X 直连内存，或者两个插槽共支持 3TB。对于需要将工作集驻留在内存中的工作负载而言，更高的传输速率无法弥补容量不足的问题。

如果直接连接的内存容量不足，Vera 的 I/O 接口可提供更多扩展途径，并连接各种设备。独立的 CPU 平台每个插槽提供 88 条 PCIe Gen6 通道，用于网络连接、存储和加速器，而 Vera Rubin 配置则提供 96 条通道。在内存方面，CXL 3.1 支持包括 Type 3 内存设备和内存池，允许内存容量扩展到 SOCAMM2 模块之外。扩展后的内存使用与直接连接的 LPDDR5X 不同的访问路径，因此其性能必须单独评估。

最后，在处理器间的通信方面，Vera 采用了第二代 NVLink-C2C 技术，它是 Grace 超级芯片中引入的链路的升级版。该链路可将双路服务器中的两颗 Vera CPU 连接起来，或将 Vera 与超级芯片中的 Rubin GPU 连接起来。该链路可提供高达 1.8TB/s 的双向总带宽，即每个方向 900GB/s，这体现了 NVIDIA 最初进军 CPU 业务时所秉持的 CPU-GPU 紧密集成理念。

MGX Vera C2 参考服务器内部结构

我们评测的样机是NVIDIA的MGX Vera C2，这是一款双路风冷2U参考服务器，NVIDIA的合作伙伴正以此为基础打造他们的首批Vera系统。前面板顶部排列着八个E1.S扩展槽，旁边是四个热插拔Delta电源，其余部分则被蜂窝状进气口占据。由于电源从前面板安装，因此后部空间可以用于机架中的I/O线缆，并留给PCIe转接卡和管理I/O接口。

机箱内部，两颗 Vera CPU 并排安装在被动散热片下方，两侧配有 SOCAMM2 散热模块。机箱中央，硬盘位后方，由六个风扇模块组成的散热墙，将空气吹过两个 CPU 插槽，每对风扇之间都设有泡沫块，用于引导气流。从散热角度来看，这样的布局设计非常合理。

两款处理器均直接安装在PCB板上，没有插槽，这与NVIDIA在其超级芯片中采用Vera架构的方式相同。16个SOCAMM2插槽环绕着这两个处理器，因此即使处理器不可更换，内存仍然可以现场更换；更换CPU则需要更换整个主板。今年夏天，我们还评测了同一款主板的液冷版本，该版本在主板顶部铺设了快速断开式冷却液管路，连接到处理器的散热片，而SOCAMM2内存模块则采用风冷散热。

中间的扩展槽内装有 NVIDIA ConnectX-8 适配器，支持高达 800G 的网络连接；后面板则配备了 USB、DisplayPort 接口以及用于带外管理的专用网络端口。

该平台采用高度模块化设计，支持多种存储和后置 PCIe 配置，但这种灵活性是以增加维护时间为代价的。乍一看，其三个 FHFL PCIe 转接卡似乎易于维护。但在典型的服务器中，更换卡需要松开转接卡，翻出支撑卡扣或拧下螺丝，然后才能将卡滑出。

在 Vera 服务器上，首先要取下风扇罩，移除一个或多个泡沫块，然后断开并取出延长线的电源线和 PCIe 线缆。只有这样，整个延长线组件才能从机箱后部滑出。延长线滑出后，需要将其拆解才能接触到显卡，更换显卡后再重新组装。在普通服务器上只需几秒钟就能完成的工作，在这里每个延长线滑出需要 5 到 10 分钟。

实际上，除非你准备好来回搬动，否则机架内维修是不可能的，因此大多数组件更换都需要将服务器移到工作台上进行维修。

性能和基准

这些基准测试旨在检验 Vera 的设计如何转化为实际性能，涵盖从单个线程到使用整个系统的工作负载。我们的测试包括内存带宽和延迟、科学计算、通用软件和数据库，展示了处理器如何应对其核心和内存系统的不同需求。

测试系统

系统	NVIDIA MGX Vera C2	戴尔PowerEdge R7725	戴尔PowerEdge R7725	戴尔 PowerEdge R770AP	戴尔PowerEdge R770	戴尔PowerEdge R760
加工厂
中央处理器	NVIDIA Vera	AMD EPYC 9965	AMD 霄龙 9175F	英特尔至强 6978P	英特尔至强 6787P	英特尔至强白金 8592+
套接字	2
每个 CPU 的核心数/线程数	88 / 176	192 / 384	16 / 32	120 / 240	86 / 172	64 / 128
基地时钟	3.4 GHz	2.25 GHz	4.2 GHz	2.1 GHz	2.0 GHz	1.9 GHz
最大时钟	3.4 GHz	3.7 GHz	5.0 GHz	3.9 GHz	3.8 GHz	3.9 GHz
内存
配置	16x 96GB Micron SOCAMM2	24x 128GB		24x 64GB	32x 64GB	16x 64GB
类型/速度	LPDDR5X-9600	DDR5-6400			DDR5-5200	DDR5-4800
总容量	1.5TB	3TB		1.5TB	2TB	1TB
存放
SSD	Solidigm D7-PS1010 7.68TB	Solidigm D7-PS1030 12.8TB	Micron 9550 PRO 7.68 TB	Solidigm D7-PS1010 7.68TB	三星 PM1745 6.4TB	固力D7-P5520 3.84TB
SSD 链接	PCIe Gen5 x4	PCIe Gen5 x2		PCIe Gen5 x4		PCIe Gen4 x4
固件
系统BIOS	NV_SBIOS 06.07.01.06	1.5.3		1.2.1	1.8.5	2.8.2
BIOS配置文件	默认	性能
软件堆栈
OS	Ubuntu的LTS 26.04.1	Ubuntu的LTS 24.04.5
核心	7.0.0-2022-nvidia-bos	6.8.0 142 / 6.8.0-146	6.8.0-147	6.8.0-138	6.8.0 142 / 6.8.0-146	6.8.0 142 / 6.8.0-146
GCC	15.2.0	13.3.0
glibc的	2.43	2.39
打开MPI	5.0.10	4.1.6
OpenJDK的	11.0.32

 

我们将 Vera 与五台配备理想内存配置的戴尔 PowerEdge 服务器进行了比较，并使用相同的测试套件对它们进行了测试，涵盖了 AMD 核心数最高、频率优化的 EPYC 处理器以及当前和上一代 Xeon 处理器。

由于 GCC 15 才首次支持 Olympus 处理器，因此 Vera 运行的软件栈比上述 x86 系统更新。除此之外，所有系统的基准测试版本、输入参数和构建标志均相同。

内存带宽

Vera 与 x86 最大的区别在于内存，因此我们从内存入手进行测试。我们测试了 STREAM Triad，在 16GiB 内存阵列上，每个物理核心运行一个 OpenMP 线程。主测试使用了系统中的所有核心，每个线程的数据都放在同一个插槽上。然后，我们重复测试，这次插槽 0 的核心先读取本地内存，再读取远程插槽的内存，并且每个核心都交替读取两个插槽上的页面。下图显示了每个服务器在关闭 SMT 的情况下，整个系统的 Triad 测试结果。

Vera 的内存吞吐量达到了 2,073GB/s，为其双路 2.4TB/s 额定吞吐量的 86%。最接近的 x86 系统是 Xeon 6978P，其 24 通道 DDR5-6400 内存的吞吐量为 914GB/s，为其 1,229GB/s 理论峰值的 74%，领先 Vera 2.3 倍。两款 EPYC 系统同样采用 24 通道 DDR5-6400 内存，但实际吞吐量却远低于 Vera：32 核的 9175F 为 651GB/s，384 核的 9965 为 634GB/s，仅为峰值的 52%，领先 Vera 3.3 倍。最后，Xeon 6787P 和 8592+ 在运行速度较慢的 DDR5-5200 和 DDR5-4800 时落后于其他处理器，分别达到 479GB/s 和 482GB/s。

EPYC 性能不足的部分原因在于 STREAM 计算流量的方式。该测试套件使用普通的 GCC 编译器构建 STREAM，而 GCC 编译器不会生成流式存储操作，因此，如果存储操作未命中缓存，它会首先从内存中读取目标行。STREAM 不会将这种读取操作计入流量统计，这意味着无论这种读取操作发生在何处，Triad 都会低估实际流量的四分之一。AMD 的 Zen 架构核心会对每次存储操作都进行计算。像 NVIDIA 早期的 Grace 这样的 Arm 架构核心可以检测到整行写入操作并跳过读取操作，而 Intel 最新的 Xeon 处理器在内存负载较高时可以跳过大部分读取操作。

Phoronix 测试套件单独构建的 STREAM 也指向了相同的结果。在关闭 SMT 的情况下，其 Copy 测试结果在 9965 上达到 832GB/s，在 9175F 上达到 873GB/s，约为测试套件构建结果（551GB/s 和 570GB/s）的 1.5 倍，这与 Copy 测试在去除额外读取操作后应有的性能提升相符；在 Xeon 处理器上，两个构建结果的差异在 9% 以内。

扣除未计入的读取次数后，9965 的数据传输速度约为 845GB/s，约为峰值的 69%，Vera 在字节传输量上的领先优势缩小至约 2.5 倍。6978P 的修正量要小得多，因此其 2.3 倍的对比结果在该系列产品中最为保守。

按插槽划分测试结果，可以了解该架构如何处理非本地核心数据。插槽 0 的核心读取本地内存的速度达到了 1,055GB/s，相当于每个插槽 1.2TB/s 额定速度的 88%，超过了测试集中任何一台 x86 服务器。通过 NVLink-C2C 读取另一个插槽的内存时，相同的核心保持了 677GB/s 的速度，相当于本地速度的 64%，而 Xeon 6978P 为 59%，EPYC 9175F 为 45%（远程速度为 148GB/s，本地速度为 327GB/s）。因此，即使工作负载部署在错误的插槽上，也能获得比任何 x86 插槽从本地内存读取数据更高的带宽，而 x86 插槽从本地内存读取数据的速度在 6978P 上最高可达 460GB/s。

作为对 Vera 的最终测试，我们使用 STREAM Triad 交错页跨两个插槽进行了测试，这是非 NUMA 感知应用程序所遇到的情况，结果 Vera 达到了 1,372GB/s，是 6978P 整个系统结果的 1.5 倍。

延迟

带宽只是内存性能的一半。延迟决定了每次缓存未命中时核心的等待时间，对于需要频繁访问内存指针的代码来说，延迟尤为重要。我们使用 tinymembench 来测量延迟，该测试会记录单个线程在 socket 0 上对 1GiB 缓冲区进行随机读取的耗时。EPYC 9175F 是我们测试组中唯一一款有此测试结果的 x86 系统，因此我们选择它作为对比对象。

在读取本地内存时，Vera 的速度比 EPYC 快。使用 2MB 大页时，Vera 的本地读取耗时 99.2ns，而 9175F 则为 114.3ns，Vera 快了 13%；使用标准的 4KB 页面时，两者的读取速度基本持平，约为 135ns。NVLink-C2C 的缺点体现在跨插槽读取数据上。Vera 的远程读取耗时 212.7ns，约为本地读取时间的 2.1 倍，而 EPYC 的远程读取耗时 199.9ns，仅为本地读取时间的 1.75 倍。

Vera 对页面大小也更加敏感。使用 4KB 页面时，由于每次读取都会出现地址转换错误，其本地延迟上升了 37%，远程延迟达到 308.4 纳秒，而 EPYC 的本地延迟仅上升了 18%，远程延迟为 228.6 纳秒。在 Vera 上，我们会运行大页模式。

HPC

带宽和延迟描述的是内存系统本身的特性。科学应用则展示了当内存系统和核心协同工作时会发生什么，而我们的两项高性能计算测试则侧重于CPU设计中截然不同的部分。

GROMACS 是一款分子动力学代码，其大部分时间都用于向量运算，每个 SIMD 通道的宽度都对应着手动编写的热循环。这使得它成为检验奥林巴斯部分所述权衡的最直接方法：即 x86 架构上的六个 128 位 SVE2 流水线与 512 位 AVX-512 单元之间的权衡。OpenFOAM 是一款计算流体动力学求解器，它处理大型稀疏矩阵，并且大部分时间都花费在内存等待上，因此它可以检验上述带宽测量结果是否适用于实际应用。

GROMACS

我们使用 benchPEP 对 GROMACS 2025.3 进行了测试，这是一个包含 12 万个原子的测试用例，在服务器的每个物理核心上运行。该构建在 Vera 系统上使用 ARM_SVE 指令集，在所有 x86 系统上使用 AVX-512 指令集。由于测试套件的输入被固定，并且禁用了 PME 调优，因此每个平台运行的都是相同的任务。

关闭SMT后，Vera在benchPEP测试中取得了1.77纳秒/天的成绩。384核的EPYC 9965以5.36纳秒/天的成绩领先，是Vera的3.0倍；其次是240核的Xeon 6978P，成绩为3.79纳秒/天（是Vera的2.1倍）；172核的Xeon 6787P成绩为2.24纳秒/天（是Vera的1.27倍）。128核的Xeon 8592+也以1.87纳秒/天的成绩领先，只有32核的EPYC 9175F以1.10纳秒/天的成绩落后于Vera。按核心数进行归一化处理后，可以更清楚地看出架构差异造成的性能差距有多大。 Vera 的单核吞吐量为 0.0100 ns/天，而 6787P 为 0.0130，9965 为 0.0140，8592+ 为 0.0146，6978P 为 0.0158，因此与大型 x86 处理器的差距部分在于核心数量，部分在于单核吞吐量。

空间多线程技术弥补了部分性能差距，启用该技术后，Vera 的测试结果提升了 17%，达到 2.07 纳秒/天，最佳布局将所有 352 个硬件线程作为线程-MPI 进程运行。这一提升幅度大于我们之前测试中 Xeon 6978P（3%）或 8592+（11%）启用同步多线程技术后的提升幅度，而 EPYC 9965 启用该技术后性能下降了 3.5%。由于资源在两个线程之间进行划分，每个进程都能获得一部分核心资源，而求解器混合使用的向量运算和内存停顿似乎比单个进程更能有效地利用这些资源。

benchMEM 案例通过在每个平台上使用 16 个物理核心的插槽 0 运行 82,000 个原子的系统来隔离每个核心的差距，因此核心数量不在考虑范围内，结果反映了向量吞吐量、缓存和本地内存。

Vera 的测试成绩为 44.1 ns/天。5.0GHz 的 EPYC 9175F 的成绩是它的两倍，达到 87.8 ns/天，而 EPYC 9965 的成绩为 66.3 ns/天，是 Vera 的 1.5 倍，领先于 Xeon 6787P（57.6 ns/天）、6978P（54.5 ns/天）和 8592+（51.5 ns/天）。

因此，即使16个Zen 5c核心共享一个32MB的L3缓存，而Vera核心可以使用其164MB的系统级缓存，16核Vera核心的Vera处理器也能完成大约三分之二的工作量。这使得我们能够最清晰地衡量出，为512位向量编写的代码在处理128位向量时的性能损失。9175F相对于9965的进一步优势与其时钟频率优势大致相符，分别为5.0GHz和3.7GHz。

OpenFOAM

OpenFOAM 将压力从矢量单元转移到了内存系统。我们在 driverFastback 汽车空气动力学案例上运行 OpenFOAM 13，每个物理核心使用一个 MPI 进程，并采用两种网格尺寸：2.98 万个单元的中等网格和 22.6 万个单元的大型网格。

在 Vera 上，中等大小的网格求解耗时 106.0 秒，而 EPYC 9965 耗时 95.0 秒，Xeon 6978P 耗时 112.7 秒，6787P 耗时 139.0 秒，8592+ 耗时 173.3 秒，32 核的 9175F 耗时 220.6 秒。在这个规模下，拥有 384 个核心的 9965 胜出，Vera 耗时慢了 12%，但排名第二，比拥有 240 个核心的 Xeon 快 6%。由于网格单元只有 3 万个，x86 架构处理器更大的 L3 缓存可能承担了更多的计算任务，因此核心数量才是关键。

大型网格运算顺序颠倒，Vera 仅用时 1,854 秒即可完成，而 Xeon 6978P 耗时 2,227 秒，EPYC 9965 耗时 2,678 秒，6787P 耗时 3,920 秒，8592+ 耗时 4,250 秒，9175F 耗时 4,788 秒。Vera 的速度比 384 核 AMD 服务器快 1.44 倍，比 240 核 Intel 服务器快 1.20 倍。此外，Vera 的单路最大功耗控制在 450W 以内，而 9965 的单路最大功耗为 500W。

分析和内存数据

HPC 测试结果展示了 Vera 的带宽对科学计算求解器的重要性。数据服务对同一内存系统的使用方式不同，我们的两项测试也分别从相反的角度对内存系统进行测试。ClickBench 运行分析查询，扫描并聚合大量数据列，并将每个查询分配到所有核心上，因此它更青睐那些拥有足够带宽来支持多个核心的系统。Valkey 是一种内存键值存储系统，它处理数百万个小型请求，每个请求只读取或写入一个值，因此它更依赖于单个核心处理请求的速度，以及一旦数据超出缓存容量，内存延迟和带宽的重要性。

点击基准测试

我们使用 ClickHouse 26.8 平台，针对一个包含 100 亿行数据的网站分析表，对 ClickBench 进行了 43 次查询测试。其热查询总和（每次查询都从页面缓存读取数据）衡量的是系统能够为列式扫描和聚合操作调配多少核心，以及内存能否有效地满足这些操作的需求。冷查询总和则包含了每次查询首次执行前服务器重启和 SSD 读取操作。

关闭SMT后，Vera以2.09秒的成绩完成了热循环测试，是我们测试组中最快的。EPYC 9965紧随其后，耗时2.70秒，是Vera的1.29倍。Xeon 6787P、EPYC 9175F和Xeon 8592+的成绩则在2.93秒到3.04秒之间，基本持平。这种差异反映了核心数和带宽之间的平衡。拥有384个核心的9965核心数充足，但每个核心的带宽较低；32个核心的9175F则相反；而Vera拥有176个核心，带宽是前两者的三倍以上。

Vera 在冷启动测试中也以 5.70 秒的成绩领先，其次是 9175F（7.12 秒）、6787P（7.86 秒）、8592+（8.68 秒）和 9965（9.61 秒）。冷启动测试更侧重于存储，并且驱动器链路也不同：Vera 和 6787P 使用 Gen5 x4，两个 EPYC 系统使用 x2，而 8592+ 使用 Gen4。

Vera加载15GB数据集的速度也最快，仅需6.4秒，而9965需要7.3秒，其他处理器则需要10.2到16.4秒。Xeon 6978P的热启动时间为9.75秒，冷启动时间为25.47秒，由于我们尚未查明原因，其性能远逊于其他Xeon处理器，因此我们将其排除在排名之外。

启用空间多线程后，Vera 的热机运行时间变为 2.31 秒，冷机运行时间变为 6.09 秒，热机运行时间增加了 10%。将每个核心的资源分配给两个线程，对 ClickHouse 的扫描来说，弊大于利。

瓦尔基

Valkey 在单个主线程上执行命令，I/O 线程只能在一定程度上提供帮助，因此部署规模的扩大是通过增加分片来实现的，因为给单个实例增加更多核心数收效甚微。因此，我们从两个方面考察 Valkey：单个分片在匹配的核心数下的性能表现，以及每个分片在插槽中满载时的性能表现。在这两个测试中，客户端都运行在同一台机器的另一个插槽上，因此不涉及网卡。

单分片测试在每个平台上都为一台 Valkey 服务器分配了九个物理核心。它先以每次发送一个请求的方式处理一个包含 3 万个键的数据集，然后以每次 10 个请求的批次进行处理，最后以每次 16 个请求的批次处理一个 256GB 的数据集（该数据集过大，任何缓存都无法容纳）。由于每次发送的请求都是逐个发送的，因此每个请求都必须完成往返才能发送下一个请求，而这正是 Vera 的弱点所在。它的分片每秒处理 385,000 万个 GET 请求，仅优于 Xeon 6978P，而 EPYC 9965 则以每秒 692,000 万个请求领先。Vera 的 p99 延迟也更高，为 1.76 毫秒，而 9965 的延迟为 1.08 毫秒。

批量处理大大降低了往返成本，Vera 的性能因此脱颖而出。在 10 个请求的批量处理下，其分片每秒处理 2.45 万个 GET 请求，比 9965 高出 13%，远超所有 Xeon 处理器。256GB 的数据集进一步拉大了差距。几乎所有请求都加载到内存中，Vera 每秒处理 1.59 万个 GET 请求，比 9965 高出 34%，而其他处理器的处理速度则在 0.53 万到 0.92 万之间。两次测试中，SET 请求的结果也呈现出相同的趋势。

Socket 模式将 0 号插槽配置为相同的四核或八核分片，所有分片同时处理流量，这更接近于专用 Valkey 主机的运行方式。在 8 核分片和 16 个分片的批次处理下，每个 Vera 分片每秒可处理 2.07 万个 GET 请求，高于 9965 的 1.92 万个，约为 Xeon 6787P 和 8592+ 的 1.6 倍，但其 p99 延迟上升至 2.2 毫秒，而 9965 的 p99 延迟约为 0.5 毫秒。

在较小的四核分片测试中，AMD 表现更佳：9965 每个分片的 GET 请求数为 1.26 万，而 Vera 为 95 万，尽管 Vera 仍然领先于所有 Xeon 处理器。在每次发送一个请求的情况下，无论分片大小如何，9965 的分片速度都比 Vera 快 1.5 到 1.7 倍，而 6787P 和 8592+ 在八核分片测试中也领先于 Vera。

密度决定了插槽总数：Vera 插槽可容纳 11 个八核分片，每秒处理 22.8 万个 GET 请求；而 9965 的 192 个核心可容纳 48 个四核分片，每秒处理 60.3 万个请求。Vera 在每个分片拥有八个或更多核心且请求批量处理时，能够提供我们测试组中最快的分片速度，但 9965 的插槽可容纳的分片数量是 Vera 的两倍多。

单线程和吞吐量

Valkey 和 ClickBench 对内存系统的依赖程度与对核心的依赖程度相当。本节将重点介绍核心本身，以及之前提到的 Olympus 架构的两个目标：快速完成单个任务，并在整个插槽繁忙时保持速度。7-Zip、OpenSSL 和 Python 分别作为绑定到单个核心的单线程运行，展示了 Olympus 核心的独立性能。然后，7-Zip 和 OpenSSL 在系统的每个线程上再次运行，展示了当所有核心都在争用相同的缓存和内存时，单核速度还能保持多少。

7-ZIP

7-Zip 的 LZMA 压缩是分支密集的整数代码，内存访问不可预测，这正是 Olympus 的 10 宽前端和图形预取器所擅长的工作。

在单线程测试中，Olympus 是我们测试的所有处理器中压缩速度最快的。它的压缩率达到了 9,537 MIPS，比 5.0GHz 的 EPYC 9175F（本次测试中速度最快的 x86 核心）高出 12%，并且远超 EPYC 9965 和所有 Xeon 处理器。解压缩测试中，两者不分伯仲：Vera 为 6,016 MIPS，9175F 为 6,000 MIPS，其他系统均落后 20% 以内。

逐条线程运行可以显示，当整个系统繁忙时，有多少领先优势得以保留。

在所有线程都处于繁忙状态的情况下，EPYC 9965 的 768 个线程以 1,527 GIPS 的压缩速度和 2,081 GIPS 的解压缩速度位居榜首。Vera 的 352 个线程以 957 GIPS 和 1,496 GIPS 的压缩速度和解压缩速度位居第二，领先于所有 Xeon 处理器，而 6787P 以 907 GIPS 和 931 GIPS 的成绩紧随其后。从每个物理核心的性能来看，Vera 的表现也相当出色。其每个核心的压缩速度为 5.4 GIPS，与 6787P 和 8592+ 持平，并优于 9965 的 4.0 GIPS；其每个核心的解压缩速度为 8.5 GIPS，比 9965 高出 57%，并且优于所有 Xeon 处理器。只有 32 核的 9175F（每个插槽共享缓存和内存的核心数量远少于 Vera）在压缩和解压缩两项指标上都优于 Vera。

OpenSSL的

在 OpenSSL 的 AES-256-GCM 测试中，Vera 的表现最为逊色。Olympus 的六个 128 位 SVE2 管道中只有两个可以执行加密指令，而 x86 部分则可以使用 VAES 在 512 位寄存器上运行 AES 算法。

在单线程测试中，差距最为明显。Olympus 的单核加密速度为 6.2GB/s，约为 EPYC 9175F 的 19.3GB/s 的三分之一，远低于 EPYC 9965 的 14.6GB/s 和 Xeon 6978P 的 13.5GB/s。

在每个线程中，x86 系统按核心数排列，这表明每个核心的不足之处让 Vera 处于什么位置。

在所有 352 个线程都处于忙碌状态的情况下，Vera 的读写速度达到了 1.26TB/s，与 128 核的 Xeon 8592+ 持平（1.28TB/s），仅领先于 32 核的 EPYC 9175F。EPYC 9965 以 3.96TB/s 的速度领先，约为 Vera 的三倍，其次是 Xeon 6978P（2.57TB/s）和 6787P（1.86TB/s）。

Python

Python 是 NVIDIA Vera 所针对的智能体沙箱的核心，pyperformance 提供了三个针对 Python 的单线程测试：go（一个对象密集型游戏树搜索）、regex_compile（编译正则表达式）和 nbody（一个浮点物理模拟）。这里存在一个软件差异：Vera 运行的是 Ubuntu 26.04 上的 Python 3.14.4，而 x86 系统运行的是 Ubuntu 24.04 上的 Python 3.12.3，较新的版本带来了解释器速度的提升。

Vera 在两项基于分支繁多、对象密集型代码的测试中均胜出。Go 语言的运行时间为 58.1 毫秒，比本次测试中最快的 x86 核心 EPYC 9175F 快 15%，比其他所有测试处理器快 1.6 到 2.1 倍。regex_compile 测试的优势更为明显，运行时间为 53.1 毫秒，比 9175F 快 25%，比 EPYC 9965 快 1.7 倍。由于 Vera 还使用了较新的 Python 版本，因此请将这两个优势视为性能上限。

没有人采取相反的做法，因为其短浮点循环和小工作集往往有利于高时钟频率，5.0GHz 的 9175F 以 42.2 毫秒的成绩胜出，比 Vera 的 58.8 毫秒快了 39%。即使 Vera 使用了更新的 Python 程序，Xeon 6978P 和 EPYC 9965 的成绩也优于 Vera，分别为 54.3 毫秒和 56.7 毫秒。

Web 服务、JVM 和调度器延迟

最后一组测试涵盖了应用程序周围的软件：Web 堆栈、Java 虚拟机、Linux 调度器和编译器工具链。这些结果不仅取决于每个核心的运行速度，还取决于每个系统运行的线程数，因此它们对 Olympus 本身的描述不如前面的章节那么深入，但它们展示了 Vera 服务器在日常服务器软件环境下的运行情况。

NGINX

NGINX 向运行在同一台机器上的 wrk 负载生成器提供 HTTPS 请求，因此客户端和服务器竞争相同的核心，结果更多地反映了 TLS 和 HTTP 协议栈，而不是原始的核心数。

启用S​​MT后，Vera在1,000个连接下每秒处理306,000个请求，在4,000个连接下每秒处理292,000个请求，性能处于中等水平，介于Xeon 6978P的263,000到Xeon 8592+的402,000之间。EPYC 9965达到354,000，Xeon 6787P达到337,000，关闭SMT后，Vera的性能提升至330,000。Vera的网络协议栈与x86系统相比毫不逊色。

再生

Renaissance 使用 OpenJDK 11 运行 Java 工作负载。其 Finagle HTTP 测试用于测试 Scala 网络协议栈，Akka 测试用于测试 Actor 模型并发框架。这两个测试都将工作负载分配到 JVM 可识别的每个逻辑 CPU 上，因此我们分别在启用和禁用 SMT 的情况下运行了它们。

Finagle 算法在线程数较少的情况下运行速度更快。关闭 SMT（同步多线程）后，线程数减半，Vera 的运行时间从 9.8 秒缩短至 4.3 秒，而配置更高的 x86 系统也获得了类似的 2.3 倍至 2.5 倍的提升。而原本线程数就较少的 32 核 EPYC 9175F 处理器，无论采用哪种方案，运行时间都约为 3 秒。

Akka 测试中，Xeon 8592+ 表现最佳，无论 SMT 是否开启，其完成时间约为 18 秒；Vera 在开启 SMT 的情况下耗时 40.5 秒；而配置最高的两款系统 EPYC 9965 和 Xeon 6978P 则表现最慢，分别耗时 101.7 秒和 119.8 秒。第三项 Renaissance 测试（遗传算法）中，除 6978P 外，所有系统在开启 SMT 的情况下均在 1.6 至 2.6 秒之间完成，Vera 的耗时为 2.6 秒。

施本奇

schbench 测量 Linux 调度器唤醒工作线程的速度，在 4 个消息线程的情况下，每个逻辑 CPU 大约运行一个工作线程；在 32 个消息线程的情况下，每个 CPU 大约运行八个工作线程。由于工作线程数量会随着系统规模的增长而增长，更大的服务器会执行更多的工作，因此这些结果描述的是每台机器满负荷运行时的延迟，而不是同等条件下的比较。

Vera 拥有 4 个消息线程，其唤醒延迟中位数为 221 微秒，p90 延迟为 396 微秒，高于除 Xeon 6978P（536 微秒和 878 微秒）之外的所有系统。最小的机器唤醒线程的速度最快，其中 32 核 EPYC 9175F 为 19 微秒，128 核 Xeon 8592+ 为 61 微秒。

由于消息线程数超过 32 个，Vera 的性能排名下滑至中游。其 5.0 毫秒的中位数响应时间和 16.1 毫秒的 p90 响应时间与 Xeon 6787P 和 8592+ 持平，优于 Xeon 6978P 和 EPYC 9965（后者 p90 响应时间为 27.5 毫秒）。只有 9175F 的速度明显更快，分别为 3.0 毫秒和 9.7 毫秒。

Linux 内核构建

本节中，我们没有对 Linux 内核 allmodconfig 构建结果进行排名。Vera 编译的是 arm64 内核树，其包含的模块和驱动程序与其它系统构建的 x86-64 内核树不同，因此我们没有尝试交叉编译。

Vera 在关闭 SMT 的情况下构建树耗时 180.7 秒，开启 SMT 后耗时 196.4 秒，因此额外的线程反而减慢了构建速度。在所有 x86 系统中，构建原生树所需的时间从 EPYC 9965 关闭 SMT 时的 146.2 秒到 32 核 EPYC 9175F 的 382.2 秒不等。

锤子数据库

为了进行数据库测试，我们邀请了 HammerDB 的创建者和维护者 Steve Shaw。Shaw 在 Vera 服务器、配备 EPYC 9965 处理器的 Dell PowerEdge R7725 服务器以及配备 Xeon 6787P 处理器的 PowerEdge R770 服务器上运行了 HammerDB 的 TPROC-C 工作负载。TPROC-C 是一种 OLTP 基准测试，源自 TPC-C，但与已发布的 TPC 结果不具有可比性。他在每台服务器上测试了五种开源数据库引擎：MariaDB 12.3.3 和 13.0.2、MySQL 26.7.0、VillageSQL 0.0.7 以及 PostgreSQL 18.6。数据库规模随核心数量的增加而扩展，每个物理核心最多可运行 16 个数据仓库，单个 Vera 服务器插槽最多可运行 1,408 个数据仓库。

每个引擎分别在单路和双路插槽上运行，单路运行时第二个插槽的 CPU 会被离线。所有系统在单路运行下的性能都优于双路运行，这符合数据库性能的典型特征。在所有 15 对测试中，增加第二个插槽使峰值吞吐量降低了 23% 到 47%，在 Vera 上降低了 29% 到 45%。Shaw 长期以来发现，开源数据库在耗尽核心数之前就会达到扩展极限。超过这个极限后，在两个插槽上保持缓存一致性所需的成本将超过额外核心带来的成本。因此，我们重点关注单路运行的结果，如下图所示。

在单个插槽上，88 核 Vera 在五个引擎中的三个上都领先。PostgreSQL 18.6 为 Vera 带来了最大的优势，在 128 个虚拟用户下，每分钟新订单数 (NOPM) 达到 3.31 万，而 192 核 EPYC 9965 插槽和 86 核 Xeon 6787P 的成绩分别为 2.62 万和 2.45 万。MariaDB 的两个版本也都领先于 Vera，分别为 2.68 万和 2.67 万，而 EPYC 的成绩分别为 2.48 万和 2.47 万。AMD 在 MySQL 26.7.0 上保持领先，成绩为 2.51 万，而 Vera 为 2.03 万；在 VillageSQL 上，成绩为 3.00 万，而 Vera 为 2.54 万。Xeon 在所有五个引擎上都落后于 Vera，成绩为 2.45 万，比 Vera 低 1.21 万，其 MariaDB 的成绩不到 Vera 的一半。

这种差异很可能与各个引擎的扩展性有关。PostgreSQL 的进程/连接模型和 MariaDB 的 InnoDB 都将工作负载分散到多个核心上，并处理大量的共享内存流量，这充分发挥了 Vera 处理器在 STREAM 测试中每个插槽超过 1TB/s 的本地带宽优势。MySQL 和 VillageSQL 则更早遇到内部锁争用，因此它们的测试结果更多地取决于每个核心清除临界区的速度，而这正是 9965 的优势所在。在 10 月份的测试之后，Shaw 认为 Arm 是整体速度最快的平台，并表示 Arm“无疑已经成为具有竞争力的数据库服务器”，但他补充说，他之前测试过的一款单路 96 核 EPYC 处理器可能略胜一筹。

在 144 个虚拟用户的相同负载下，尾延迟也呈现出相同的分布情况。Vera 的 PAYMENT p99 延迟在 PostgreSQL 上为 1.92 毫秒，在 MySQL 上为 2.98 毫秒。EPYC 9965 在 MySQL、VillageSQL 和 PostgreSQL 上的延迟在 1.33 毫秒到 1.40 毫秒之间，比 Vera 低 29% 到 53%，但在 MariaDB 13.0.2 上的延迟为 3.13 毫秒，低于 Vera 的 2.92 毫秒。Xeon 6787P 的 MariaDB 尾延迟分别为 14.4 毫秒和 17.1 毫秒，比两者高出数倍，这与其在相同负载下较低的吞吐量相符。引擎内部的锁交接可能是导致 Vera 尾延迟较高的原因，这与 Valkey 的结果相呼应，在 Valkey 的测试中，一次发送一个请求也有利于 AMD。

11 月的测试验证了 Shaw 的预判。他分别在 AMD 新款 256 核 EPYC 9996 和 96 核 EPYC 9686F 处理器的单路插槽上运行相同的工作负载，Vera 的插槽也参与了对比。9996 和 Vera 互换了数据库引擎，Vera 继续运行 PostgreSQL 和 MariaDB，而 EPYC 在尾延迟方面领先，96 核处理器在 PostgreSQL 上略胜 Vera 一筹。完整测试结果请参阅我们的AMD EPYC Venice 评测。

“开源数据库在 NVIDIA Vera 上的表现确实让我印象深刻。很高兴看到 Arm 能够在数据库性能的高端领域占据一席之地，并为企业市场带来极具吸引力的替代方案，”HammerDB 的创建者和维护者 Steve Shaw 在融资结束后表示。

结语

Vera并非在所有类别中都是最快的处理器，因为AMD针对市场的不同需求分别推出了专用产品。频率优化的EPYC 9175F专为单核速度而设计，即使在对时钟频率要求较高的工作负载下也能胜任，例如Python的nbody算法、单线程AES以及一次只能处理一个Valkey请求的任务。EPYC 9965则专注于吞吐量，在那些与核心数量成正比的任务中表现出色，包括GROMACS、全线程7-Zip和AES，以及单个插槽可容纳的Valkey分片数量。

Vera 的独特之处在于其均衡性，以及它在各个领域与专业处理器之间的出色表现。在单线程测试中，Vera 在整数运算和三个 Python 测试中的两个上与 9175F 性能持平甚至更优，在 7-Zip 压缩速度上提升了 12%，运行 go 和 regex_compile 的速度分别提升了 15% 和 25%，但在浮点运算和加密方面略逊一筹。

在整个系统范围内，Vera 的全线程 7-Zip 速度达到了 9965 的 63% 到 72%，在中等大小的 OpenFOAM 网格测试中，其速度与 9965 的差距仅为 12%。在内存接管后，Vera 在大型网格测试和 ClickBench 测试中都超越了 9965。Vera 能够在单线程测试中保持如此接近单核领先水平，并在全系统吞吐量测试中保持领先水平，这正是它成为如此强大的通用处理器的原因。对于那些希望在不牺牲太多性能的高端或低端市场需求的中端平台用户来说，Vera 是一个极具吸引力的选择。

Vera 的内存带宽远超我们测试过的任何 x86 系统。在 STREAM Triad 测试中，两个 Vera 插槽的内存带宽稳定在 2,073GB/s，是本次测试中性能最佳的 DDR5 服务器的 2.3 倍。此外，NVLink-C2C 技术还能确保跨插槽的内存带宽保持稳定：Vera 的核心可以以 677GB/s 的速度读取另一个插槽的内存，比任何 x86 插槽读取本地内存的速度都高。

内存密集型工作负载测试结果如下：大型 OpenFOAM 网格的求解速度比 EPYC 9965 快 1.44 倍；ClickBench 热测试耗时 2.09 秒，而 EPYC 9965 为 2.70 秒；256GB Valkey 工作集的运行速度提升了 34%；在单路插槽上，Vera 在 PostgreSQL 和两个 MariaDB 版本上均领先于 HammerDB。链路成本体现在延迟上：远程读取耗时约为本地读取的 2.1 倍，而 EPYC 9175F 的这一倍数为 1.75 倍，因此 NUMA 感知内存布局和巨页内存仍然对 Vera 至关重要。

这些弱点出乎意料地轻微，而且直接源于设计本身。六条 128 位 SVE2 通道与为其编写的代码中 512 位 AVX-512 单元并不匹配，因此 Vera 的 16 核芯片运行 GROMACS benchMEM 的速度只有 9175F 的一半，9965 的三分之二。如果只使用其中两条通道处理加密，那么单个 Olympus 核心对 AES-256-GCM 进行加密的速度大约只有 9175F 的三分之一。

Vera 的最终发展很大程度上取决于 OEM 合作伙伴。戴尔的PowerEdge R8822服务器已于 10 月开始出货，M9882 Vera CPU 机架预计将于 2027 年第一季度上市；HPE 的ProLiant Compute DL394 Gen12将于今年秋季推出；Supermicro 的 256 核 Vera 机架已开始接受报价，产品线中包含风冷 1U 和 2U Vera 系统；华硕、华擎、QCT、技嘉、微星、仁宝、富士康、和硕、纬创和联想都已展示了 Vera 设计。Oracle Cloud 的 Vera 实例已正式发布，CoreWeave、Nebius、Lambda 等其他云服务商也将陆续推出Vera 实例。

Vera 是我们测试过的首款能够与 x86 旗舰级通用处理器相媲美的 Arm 服务器处理器，也是首款将 2TB/s 内存带宽集成到风冷双路处理器中的处理器。对于广大中端市场而言，它目前是一个可靠的选择，NVIDIA 也凭借其独有的内存子系统进军 CPU 市场。然而，对于向量密集型高性能计算 (HPC) 和加密密集型服务，x86 处理器仍然占据领先地位。我们将对 OEM 系统进行与实验室相同的测试，首先测试 NVIDIA 为这款处理器量身打造的代理沙箱环境。

自本次评测以来，AMD 的 EPYC Venice 已经抵达我们的实验室，我们在对AMD EPYC Venice SP7和Dell PowerEdge R9825 的评测中，将 256 核 EPYC 9996 与 Vera 进行了相同的测试，Vera 使用的是最新的固件。

排行榜： NVIDIA Vera 在我们的最佳服务器排行榜上名列最佳 Arm 实现榜首。

NVIDIA Vera CPU 产品页面