NVIDIA 已经发布了一份 45 页的白皮书，介绍了 Vera：https://nvdam.widen.net/s/nmw5vblpqd/nvidia_vera_cpu_architecture_whitepaper?nvid=nv-tblg-543584，这是公司首款基于自家 Olympus 核心的服务器 CPU。在纸面上，Vera 是一款令人着迷的芯片，拥有 88 核单片计算芯片，Olympus 是一个 10 宽度的 Arm v9.2 核心，具备值预测、图形预取器、每核 2 MB 的私有 L2 缓存、164 MB 的共享最后级缓存，以及八个 LPDDR5X 内存接口，提供高达 1.2 TB/s 的带宽。
不幸的是，NVIDIA 也花了大量篇幅试图将这些有趣的设计选择转化为关于 x86 的道德故事。传统的同时多线程被描绘为时间片切分，可配置的 NUMA 拓扑被呈现为无法避免的 32 节点迷宫，四个 SPEC 组件被称为“有代理的基准测试”，未定义的性能计数器比率被推崇为因果证据，而一个无标签的图标被解读为 1.8 倍强化学习结果。
令人沮丧的是，Vera 并不需要这些帮助，早期独立测试表明 Olympus 实际上非常强大。白皮书最有力的论点是硬件；最薄弱的部分是围绕它的故事，所以让我们来拆解这个故事。
在拿出刨肉工具之前，先谈谈好的一面。Olympus 是一款非常宽的乱序 Arm 核心：https://nvdam.widen.net/s/nmw5vblpqd/nvidia_vera_cpu_architecture_whitepaper?nvid=nv-tblg-543584
其前端可以每周期解码十条指令，并处理每周期最多两条已执行分支。NVIDIA 描述了神经分支预测、值预测、内存重命名、大指令窗口、六个 128 位 SVE 管道、四个加载管道、两个存储管道、96 KB 的 L1 数据缓存，以及对 2 MB 私有 L2 缓存约 10 周期的访问延迟。这 88 个核心位于 3.4 TB/s 的一致性互连和 164 MB 分布式系统级缓存之后。
仔细观察核心，值预测是 Olympus 的一个比较独特的新增功能。这一直是一个长期研究的领域，而值预测使 Olympus 能够做到的是，如果核心正确预测了一个结果，依赖的指令可以继续执行，而不是在长延迟操作后堆积。研究人员发现，Apple 在其核心中使用了值预测：https://www.usenix.org/system/files/usenixsecurity25-kim-jason.pdf，而 AMD 也谈到在 Family 17h（Zen 1 和 2）中，他们可以预测某些浮点指令的值：https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/1924930.pdf。然而，AMD 的 Family 17h 实现相当有限，而 Olympus 似乎有一个更广泛的值预测实现，更接近 Apple 的方式。
然而，图预取器并不是 NVIDIA 独有的。Intel 有一个类似的机制，称为数据依赖预取器（Data-Dependent Prefetcher），至少从 2022 年开始就在出货的硅片上。Intel 最新的数据中心 CPU Granite Rapids 也有一个指针数组预取器：https://www.intel.com/content/www/us/en/content-details/671488/intel-64-and-ia-32-architectures-optimization-reference-manual-volume-1.html，它将“为固定步长加载预取的数据视为指针，并可能向对应指针值的内存地址发出预取请求”。这在根本上与 NVIDIA 所描述的图预取器的生产者-消费者理念相同。Intel 的实现相当受限，因此 NVIDIA 的实现可能能够处理比 Intel 更复杂的链。因此，尽管 Vera 的图预取器可能是一个可以处理更多工作负载的实现，但生产者-消费者预取并不是一个新概念。
“神经分支预测器”也不是一个新概念。早在2012年，AMD就在Piledriver微架构中实现了感知器分支预测器：https://web.archive.org/web/20120517123516/http://www.anandtech.com/show/5831/amd-trinity-review-a10-4600m-a-new-hope，并在Zen 1中继续使用基于感知器的分支预测器：https://www.amd.com/en/newsroom/press-releases/2016-12-13-amd-takes-computing-to-a-new-horizon-with-ryzen-tm.html。然而，从Zen 2开始，AMD仅将感知器BPU用于初始方向预测，并由TAGE预测器覆盖它，因为后者在错误预测方面减少了30%：https://www.computer.org/csdl/magazine/mi/2020/02/09000513/1hx2FVM4mUo。截至Zen 5，AMD很可能已经完全采用TAGE预测器：https://hc2024.hotchips.org/assets/program/conference/day2/24_HC2024.AMD.Cohen.Subramony.final.pdf，如果它尚未在Zen 3或Zen 4中完成这一转变。
在SoC方面，由于Olympus核心的强大性能，NVIDIA为Vera配备了同样强大的内存子系统。Vera配备八个SOCAMM2 LPDDR5X模块，容量最高可达1.5 TB，带宽可达1.2 TB/s。NVIDIA声称，该内存子系统的功耗仅约为50瓦特。传统的EPYC或Xeon平台可以提供更高容量且更易更换的DIMM，但这种灵活性需要在电路板空间和功耗上付出代价。
最重要的是，我们不仅有NVIDIA的测试结果可参考。今年5月，Phoronix的Michael Larabel在早期Vera系统上对比了现有的Arm和x86服务器。在NVIDIA允许的测试集上，Vera的几何平均值比5 GHz EPYC 9575F高10%：https://www.phoronix.com/review/nvidia-vera-benchmarks/11，比Xeon 6980P高1.55倍，比Grace高1.63倍，这使得Vera成为我们公开测试中见过的性能最强的Arm服务器CPU。测试存在重大注意事项，例如NVIDIA选择了允许的工作负载范围，并且不允许进行频率或功耗监控。Phoronix测试的系统为预生产版本，测试窗口仅为一天，这对其测试范围设定了相当严格的限制，无论NVIDIA设定了什么限制。因此，更广泛的覆盖测试将不得不等到Vera在实际应用中出现，而不仅仅是在NVIDIA实验室中。
尽管如此，结果仍然足够强大，使我们能够否定NVIDIA白皮书中图表全是虚构的解释。Olympus似乎是一个快速的CPU核心，因此现在我们可以问，白皮书是否证实了NVIDIA所声称的内容。
这是文档中的第一个重大技术错误。
图5对比了“传统SMT（x86）”与NVIDIA的空间多线程。x86部分描绘了分支预测器、解码、执行、加载/存储和内存阶段在两个线程之间交替进行。图注称，Vera通过在其两个硬件线程之间划分资源，避免了“机会时间共享”。
NVIDIA的图表给人一种误导性的印象，即SMT通常是如何实现的，无论是在x86-64还是其他ISA上。SMT实现：https://cs.ucr.edu/~bhuyan/cs203A/hyperthreading.pdf 通过每个周期选择一个线程来处理或以与线程无关的方式共享执行流水线的各个阶段。取指、解码和分配通常按每个周期为线程提供服务，而执行和内存访问阶段则与线程无关，可以在同一周期为两个线程的微操作提供服务。线程仲裁的阶段在两个线程都可以供给时不会像NVIDIA图表所示那样留下未使用的资源。静态分区和每周期选择在没有线程级停顿的情况下，将为两个线程提供相同的平均吞吐量。如果存在停顿，每周期选择可以将原本未使用的吞吐量分配给未停顿的线程。
同样的理念也适用于与线程无关的阶段，如执行和缓存访问。每个线程可以使用它能够供给的所有执行单元或缓存端口。相比之下，正如NVIDIA所建议的静态资源分配可能导致某个线程受计算限制，无法使用核心一半的执行资源，因为这些资源被预留给另一个线程。
NVIDIA论文中的文本强调“确定性、隔离性和服务质量”作为NVIDIA空间多线程方法的优势。性能显然没有被特别指出。对于NVIDIA的目标市场来说，QoS可能比吞吐量更重要，而空间多线程可能并不是一个糟糕的设计点。但NVIDIA的图表让人觉得纵向空间代表时间，这给人一种误导性的印象，即空间多线程旨在比传统SMT带来更大的性能提升。
通过减少线程之间的资源干扰，相对于传统SMT方法，空间多线程提高了确定性、隔离性和服务质量。结果是一个可以在保持更稳定的延迟和吞吐量的同时运行大量并发代理任务的CPU架构。——NVIDIA Vera白皮书
当然，Vera的实际SMT性能未知，而且SMT增益涉及很多变量，除了在取指、解码、执行和内存访问时的分区策略。诸如乱序资源（如重排缓冲区、寄存器文件和内存排序队列）可以被复制、静态分区、使用水印或竞争共享。分区的结构在多线程模式下分配给两个逻辑处理器，并在单线程模式下重新组合为一个线程，这在2002年已有文档记录：https://www.intel.com/content/dam/www/public/us/en/documents/research/2002-vol06-iss-1-intel-technology-journal.pdf。各种SMT实现对每个结构使用不同的策略，这些选择可能对SMT增益产生显著影响。
另一个需要注意的点是，显然Olympus核心需要10000个周期：https://lore.kernel.org/all/20260804151324.918020-1-arighi@nvidia.com/ 才能在该核心上的兄弟线程完成后切换回单线程模式。这意味着软件在启动Olympus核心的第二个线程时必须非常谨慎，因为不仅分区方案带来的惩罚，还有切换回单线程的延迟。
看看Vera会使用什么策略来划分其乱序资源，以及其SMT性能如何与其他现代核心相比，这将会很有趣。NVIDIA的白皮书对此没有提供任何信息。它所做的只是展示了一张具有误导性的图表，暗示传统SMT容易导致资源未被使用，而实际上它可能比NVIDIA的空间多线程（Spatial Multithreading）更擅长保持核心的高负荷运行。
接下来，NVIDIA告诉我们，大型双插槽x86系统可以暴露“多达32个NUMA域”，而Vera每个插槽只呈现一个。这个数字不是凭空捏造的。在多芯片EPYC系统中，管理员可以将缓存局部区域作为单独的NUMA节点来暴露。如果你将每个局部性调节旋钮调到最大粒度，节点数量就会变得很大。
NVIDIA没有提到的是，这个是可配置的，AMD的调优指南列出了NPS4、NPS2、NPS1，甚至NPS0模式：https://docs.amd.com/v/u/en-US/58479_amd-epyc-9005-tg-hpc。可选的“LLC作为NUMA”设置可以单独暴露每个最后一级缓存域。因此，“32个NUMA节点”并不是芯片级CPU用户体验中不可避免的结果，它只是局部性控制光谱的一端。NVIDIA将一种可选的高粒度配置呈现得好像是x86系统不可避免的现实。
Vera每个插槽一个域简化了调度和内存布局，而多个域则允许经过调优的软件利用物理局部性。Vera选择了更简单的呈现方式，而NVIDIA可以自由地辩称这更符合其预期的软件栈。但一个操作系统可见的NUMA节点只是一个抽象，而不是虫洞。Vera仍然有88个核心、分布式缓存和主节点、大芯片上的内存控制器以及分组交换一致性结构。一个平坦的软件拓扑可以使这些大规模单片计算芯片周围的距离更加一致，但不能使它们不存在。
论文中的核心间热图本来是量化这种优势的好地方。但是，NVIDIA提供的只是带颜色的方块，没有核心身份信息，没有最小值/中位数/最大值表格，没有分布数据，也没有测量程序。“最高50%降低”体现的是NVIDIA的最佳结果，而不是Vera的典型行为。
每个插槽一个 NUMA 节点确实更简单，但白皮书将其与可选的 32 域 x86 配置进行了比较，并将该极端情况作为基线。这里的反观点是英特尔拥有像 Vera 一样的 Mesh NoC。这两种配置之间的真正区别在于，EPYC 的集群设置在集群之间的延迟很高，但在单个集群内延迟很低，而 Vera 和 Xeon Mesh 设置的延迟则均匀且平均；不同的配置只是工程上的权衡。
基准测试部分是白皮书，本来是关于 CPU 的，开始戴上它在地板上捡到的 AI 会议徽章的地方。
NVIDIA 选择了四个 SPEC CPU 2026 整数工作负载：CPython、GCC、LLVM 和 Cppcheck，并称它们为“智能体基准”。SPEC 官方描述它们：https://www.spec.org/cpu2026/Docs/ 为 Python 解释器、两个优化编译器和一个 C/C++ 静态分析器。这些都是合法的 CPU 程序。它们会对大型指令集、分支密集型代码、内存分配和依赖链进行压力测试。智能体完全可以调用类似的程序。
但它们不是智能体：没有模型在提供 token，没有智能体运行时在选择工具。没有沙箱启动、阻塞 I/O、检索上下文、评估答案或将观察结果反馈到策略中。这些工作负载可能是智能体流水线中代码密集部分的有用替代。把它们称为“智能体基准”，然而，将这种部分重叠变成了它们代表完整端到端工作负载的声明。
论文正确地将 SPEC 结果标记为估算值，因为运行时 Vera 的参考硬件尚未普遍可用。图 15 显示了在充分加载的双插槽系统下，基于每个物理核心的四个选定组件具有 1.7 倍到 1.8 倍的优势。翻到配置页，完整的估算 SPECrate 2026 整数基准总分为双 Vera 插槽 925，双 EPYC 9755 插槽 898，相当于系统吞吐量有 3.0% 的优势。
两个数字都可以成立。Vera 在两个插槽中使用 176 个物理核心，而 EPYC 系统使用 256 个。将每个得分除以物理核心数量，Vera 在整个整数率测试套件中每核速度约快 50%，选定测试可达到 70% 到 80%.
还有另一个术语冲突。NVIDIA 在描述完全加载的系统时，将图 19 称为“单线程 IPC”。
已发布的配置在 176 个 Vera 核心上运行 352 个副本，在 256 个 EPYC 核心上运行 512 个副本，每个物理核心两个副本。也许 NVIDIA 在一个逻辑线程活跃时采样了另一个线程，也许它汇总了计数器后进行了除法，论文中没有说明。SPEC 的结果是有用的，并且 Vera 的每核性能确实很强。然而，将这些测试表述为智能代理工作负载并强调归一化数据，会让优势显得比披露的结果更加广泛。
NVIDIA 将 Olympus 报告的 IPC 提升归因于四个计数器组。根据选择的工作负载，Vera 假设每周期可实现多达 2.3 倍的分支预测、3.5 倍的已采取分支、2.4 倍的指令获取操作和 4.3 倍的后端操作。
这听起来技术性很强，但如果没有 PMU 事件名称和定义、原始计数、采样间隔、时钟频率等信息，是无法进行审计的。更不用说，一条 Arm 指令与一条 x86 指令并不是同一单位的工作。内部的后端操作甚至更不可移植：一种微架构可能将一条指令拆分为多个微操作，而另一种则保持其融合。
当结合已退役指令数、时钟频率和代码分析时，跨 ISA IPC 仍然具有参考价值。但它不能单独作为性能指标。两个二进制文件在相同时间内完成相同任务，却可能报告非常不同的 IPC。因为其中一个可能只是执行了更多指令，而每条指令完成的工作更少，那么你还必须考虑可能截然不同的时钟频率。IPC 描述的是核心运行一段代码的行为，而不是衡量有用工作的普遍标准。
查看分支预测器的结果，每个周期更多的分支预测可能表明预测器能力强，或者也可能意味着Arm二进制文件包含更多分支，基准测试在代码中运行得更快，或者NVIDIA的事件计数了EPYC事件未计数的推测预测。每个周期更多的后端操作可能与性能相关，但对引起这种结果的具体特性告诉我们很少。要隔离值预测、图形预取或神经预测器的作用，我们需要开/关实验，或者至少需要事件定义和未命中率差异。虽然Vera对比Turin的IPC优势可能是真实的，但NVIDIA白皮书中的图表并未提供足够细化的结果以显示这一点。
内存部分包含了NVIDIA最强的成果以及其最弱的结论之一。
与论文中双路EPYC 9755系统相比，Vera在NVIDIA的负载延迟图中达到大约1.1 TB/s，而Turin则稳定在约400 GB/s。Vera的每核带宽也显示为12.7 GB/s，而Turin为3.1 GB/s。这些结果与我们对Turin CPU的测试不一致。
在我们对Turin的测试中，通过12通道DDR5-6400内存子系统，我们能够获得大约570 GB/s的Turin带宽。这与NVIDIA的结果直接矛盾，后者的内存带宽最多约为400 GB/s。这也对每核内存带宽数据提出了质疑，假设EPYC 9755的每核带宽提高到约4.5 GB/s。
Vera仍然领先，但我们的Turin测试结果大幅改变了这种优势的大小。将Vera的大约1.1 TB/s与我们测出的570 GB/s对比，NVIDIA的带宽优势应为1.9倍，而不是白皮书中显示的近3倍。如果将EPYC 9755的每核结果从3.1 GB/s修正为大约4.5 GB/s，同样将Vera的优势从4.1倍减少到大约2.8倍。如果我们看AMD实际作为AI头节点推荐的SKU，即EPYC 9575F，则每核结果为Vera的12.7 GB/s对比9575F的约9 GB/s，对于Vera约为40%的提升。这依然是Vera不错的数值，但讲述的故事明显不那么戏剧化。
从理论数据来看，AMD将Turin的12个DDR5-6400通道限制为614 GB/s。我们的570 GB/s结果约达到理论极限的93%。Vera的八个LPDDR5X-9600接口提供1.2 TB/s，而NVIDIA测得的1.1 TB/s约占该数值的92%。换句话说，两个处理器将理论内存带宽的比例转换为持续带宽的比例非常接近。Vera 之所以获胜，是因为它拥有大约是 Turin 插槽峰值带宽的两倍，且竞争的核心更少，而不是因为 Turin 在利用可用内存带宽方面异常差。
尽管如此，白皮书反复将Vera的单片计算芯片归功于其开发，并将其与“传统的芯片组CPU”进行对比。单片芯片可能减少织物遍历并改善加载延迟，但我们的Turin结果直接削弱了带宽差异的解释。基于芯片组的EPYC 9755达到理论极限的约93%，显然并未被芯片组拓扑所限制。Vera 带宽优势的主要来源于连接处理器的内存接口。
这种比较也几乎立刻显得过时。NVIDIA 于 7 月 21 日发布了技术博客和白皮书，而 AMD 两天后发布了第六代 EPYC。96核EPYC 9686F更接近Vera的88核，提供16个内存通道，支持DDR5-8000或MRDIMM-12800，每个插槽速度为1,024或1,638 GB/s，最高MRDIMM速度为Venice在总内存带宽和每核内存带宽上都比Vera更宽，具体取决于你关注的SKU类型。
新的EPYC规范和我们的Turin测试所显示的，比NVIDIA声称的“比最新x86 CPU多3×内存带宽”更窄，这取决于Turin的结果，而该结果并不代表我们从同一代处理器中提取的带宽。相比我们的结果，Vera约为1.9×总带宽，2.8×每核带宽，这仍是一个令人印象深刻的平台成绩，但这并不证明单片Arm处理器相较于基于芯片组的x86处理器在带宽上有优势。
NVIDIA 报告称其 PageRank 性能比 EPYC 9755 高 2.6 倍，并显示 Vera 的扩展几乎线性达到 32 核，而 EPYC 在 32 核时仅提升到 10 倍。NVIDIA 将这一相对于 Turin 的改进归因于单片计算芯片以及其高带宽可扩展一致性互连（Scalable Coherent Fabric）、Vera 拥有的 1.2 TB/s 内存带宽，以及 Olympus 核心内的图预取器。
然而，虽然论文提到了 GAP 基准套件，但没有说明 NVIDIA 使用了哪些变量，而这些变量对测试的执行方式非常重要。扩展图仅显示到 32 核，尽管这些机器每个插槽有 88 和 128 核。尽管 2.6 倍的结果很有趣，但如果没有 NVIDIA 使用的变量，这一结果很可能无法复现。
在 ClickHouse 测试中，NVIDIA 直接链接到 Phoronix 的结果：https://www.phoronix.com/review/nvidia-vera-benchmarks/10，在对一个 1 亿行的数据集进行三轮测试中，Vera 在被测处理器中领先。白皮书中的 1.2 倍图表仍然具有选择性，因为未使用 9575F 的结果，但外部测试者使用可识别的工作负载生成了基础结果。
然后我们看到图 24，“Vera 在强化学习训练中提升 1.8 倍”，图中是一排小的已完成任务方块。没有模型、环境、CPU/GPU 分配、框架、批量大小、电力测量、重复次数或误差线。我们甚至不知道这些方块代表的是样本、步骤，还是 Nvidia 总部某种随机布局的瓦片。
这并不是一个糟糕的基准，它根本就不是基准。
周围的文字解释了为什么更快的 CPU 可以通过更快的环境步骤和奖励计算来提升强化学习的执行速度，从而更快地为加速器提供数据，但图 24 甚至没有试图测量这一点。
经过 45 页，我对 Vera 的看法比对白皮书的看法更积极。
Olympus 看起来像一个严肃的核心，拥有 10 宽的固定长度解码器、大型私有缓存、值预测、激进的分支处理、图感知预取以及单片 88 核芯片，这些选择都指向一个非常高性能的 CPU 核心。内存配置也毫不逊色，LPDDR5X 子系统提供高达 1.2 TB/s 的内存带宽，这对于内存带宽密集型的服务器工作负载非常友好，而且早期独立基准测试表明，这块硅至少在某些方面能够兑现白皮书中的承诺。
然而，论文的竞争论点就不那么稳固了，它误解了 x86 SMT，将可选的 NUMA 配置变成默认负担，将标准 CPU 测试重新标记为智能工作负载，隐瞒了两插槽情况下 3% 的领先优势，而用 1.8 倍每核柱状图掩盖，比较未定义的跨 ISA 计数器，将内存接口胜利归因于单片芯片的优点，以及将一张插图作为性能数据呈现。
这些都不会让 Vera 变慢，只是让 NVIDIA 的实际证明比 NVIDIA 营销文案显得小。
下一轮的 Vera 测试应该很直接。向独立评测人员提供无限制的生产硬件，这样我们就可以发布频率、封装功耗和整机功耗数据，同时测试空间多线程开/关的结果，当然也可以在 Vera 上运行任何我们想要的基准测试或工作负载。如果 Vera 如其架构所暗示的那样出色，这些测试将比将 x86 SMT 画成一个微小的双车道红绿灯更具说服力。照目前的情况来看，NVIDIA 的营销有可能损害 Vera 的形象。NVIDIA 在这里已经构建了足够的 CPU，不需要再从营销管道中借取性能。
单个单片计算芯片上 88 个核心 -> 在我看来，这像是迄今为止为服务器级 CPU 制造的最大计算芯片块/瓷砖？让我想到它们从 TSMC 芯片厂获得的良率。
它有助于核心间延迟图（没有悬崖式下降的情况），但那会使 SoC 互连变得庞大。更多金属布线（在最低金属层，M0, M1）不会限制最大加速时钟吗？
这两种配置之间的真正区别在于，EPYC 的集群式配置在集群之间的延迟较高，但在单个集群内部的延迟较低，而 Vera 和 Xeon Mesh 的配置具有均匀的平均延迟；不同的配置只是工程上的权衡。
对于云虚拟化工作负载 -> 更“分散”的网状结构效果更好（因为租用集群中的核心大多是独立工作的）
对于 AI（训练+推理），由于该工作负载需要更多核心间的通信，更大的互联结构效果更好以降低延迟？即使如此大的网格必须以“非核心”频率运行。
NVIDIA has published a 45-page whitepaper explaining Vera ：https://nvdam.widen.net/s/nmw5vblpqd/nvidia_vera_cpu_architecture_whitepaper?nvid=nv-tblg-543584 , its first server CPU built around the company’s own Olympus core. On paper, Vera is a fascinating chip with an 88-core monolithic compute die, Olympus being a 10-wide Arm v9.2 core that has value prediction, a graph prefetcher, 2 MB of private L2 per core, 164 MB of shared last-level cache, and eight LPDDR5X memory interfaces promising 1.2 TB/s.
Unfortunately, NVIDIA also spends a good part of the paper trying to turn those interesting design choices into a morality play about x86. Traditional simultaneous multithreading is drawn as time-slicing, a configurable NUMA topology is presented as an unavoidable 32-node maze, four SPEC components become “agentic benchmarks,” undefined performance-counter ratios are promoted as causal proof, and an unlabeled pictogram becomes a 1.8x reinforcement-learning result.
The frustrating part is that Vera does not need this help, with early independent testing suggesting Olympus is genuinely formidable. The whitepaper’s strongest case is the hardware; its weakest case is the story wrapped around it, so let’s pull that story apart.
Before getting out the cheese grater, let’s talk about the good stuff. Olympus is a very wide out-of-order Arm core. ：https://nvdam.widen.net/s/nmw5vblpqd/nvidia_vera_cpu_architecture_whitepaper?nvid=nv-tblg-543584
Its front end can decode ten instructions per cycle and handle up to two taken branches per cycle. NVIDIA describes a neural branch predictor, value prediction, memory renaming, a large instruction window, six 128-bit SVE pipes, four load pipes, two store pipes, a 96 KB L1 data cache, and roughly 10-cycle access to a 2 MB private L2. Eighty-eight of those cores sit behind a 3.4 TB/s coherency fabric and a distributed 164 MB system-level cache.
Looking closer at the core, the value prediction is one of the more unique additions that Olympus has. This has been a research area for a long time and what value prediction allows Olympus to do is if the core correctly predicts a result, dependent instructions can keep moving instead of piling up behind a long-latency operation. Researchers have discovered that Apple uses value prediction ：https://www.usenix.org/system/files/usenixsecurity25-kim-jason.pdf in their cores and AMD talked about how in Family 17h (Zen 1 and 2) they could predict the value of some floating point instructions ：https://www.amd.com/content/dam/amd/en/documents/resources/bulletin/1924930.pdf . However, AMD’s Family 17h implementation was quite limited, while Olympus appears to have a broader value-prediction implementation closer to Apple’s.
However, the graph prefetcher is not unique to NVIDIA. Intel has a similar mechanism called Data-Dependent Prefetcher that has been in shipping silicon since at least 2022. Intel’s newest datacenter CPU, Granite Rapids, also has an Array of Pointers prefetcher ：https://www.intel.com/content/www/us/en/content-details/671488/intel-64-and-ia-32-architectures-optimization-reference-manual-volume-1.html which “treats the data prefetched for a constant stride load as a pointer and may issue prefetch requests to the memory addresses corresponding to the pointer’s value.” This is fundamentally the same producer-consumer idea that NVIDIA describes for its graph prefetcher. Intel’s implementation is fairly constrained, so NVIDIA’s implementation may be able to deal with more complex chains than Intel’s implementation. So while Vera’s Graph Prefetcher may be an implementation that can deal with more workloads, producer-consumer prefetching is not a new idea.
Nor is a “neural branch predictor” a new idea. Back in 2012, AMD implemented a perceptron branch predictor ：https://web.archive.org/web/20120517123516/http://www.anandtech.com/show/5831/amd-trinity-review-a10-4600m-a-new-hope in the Piledriver microarchitecture and continued to use a perceptron-based branch predictor in Zen 1 ：https://www.amd.com/en/newsroom/press-releases/2016-12-13-amd-takes-computing-to-a-new-horizon-with-ryzen-tm.html . However, starting with Zen 2, AMD used a perceptron BPU only for its initial direction prediction, with a TAGE predictor overriding it because it delivered a 30% reduction in mispredictions ：https://www.computer.org/csdl/magazine/mi/2020/02/09000513/1hx2FVM4mUo . With Zen 5, AMD has likely fully committed to TAGE predictors ：https://hc2024.hotchips.org/assets/program/conference/day2/24_HC2024.AMD.Cohen.Subramony.final.pdf , if it had not already done so with Zen 3 or Zen 4.
Moving to the SoC side, with how beefy the Olympus core is, NVIDIA has given Vera an equally beefy memory subsystem. Vera pairs eight SOCAMM2 LPDDR5X modules with up to 1.5 TB of capacity and 1.2 TB/s of bandwidth. NVIDIA claims the populated memory subsystem only consumes approximately 50 watts. A conventional EPYC or Xeon platform can offer higher-capacity DIMMs which are easier to replace, but it pays for that flexibility in board area and power.
Most importantly, we have more than NVIDIA’s results to look at. In May, Michael Larabel at Phoronix ran an early Vera system against current Arm and x86 servers. Across the NVIDIA-permitted test set, Vera’s geomean was 10% ：https://www.phoronix.com/review/nvidia-vera-benchmarks/11 above a 5 GHz EPYC 9575F, 1.55x a Xeon 6980P, and 1.63x Grace which makes Vera the most performant Arm server CPU we have seen in public testing. There are major caveats with the testing, such as NVIDIA choosing the permitted workload scope and not allowing frequency or power monitoring. The system that Phoronix tested was pre-production and the test window was one day which puts a fairly hard limit on what they could test irrespective of the limits NVIDIA placed. This means that broader coverage will have to wait until Vera can be found in the wild rather than just in NVIDIA’s labs.
Still, the result is strong enough that we can reject the explanation that the charts in NVIDIA’s whitepaper are all fantasy. Olympus appears to be a fast CPU core, so now we can ask whether the whitepaper proves what NVIDIA says it proves.
Here is the first major technical error in the document.
Figure 5 contrasts “Traditional SMT (x86)” with NVIDIA’s Spatial Multithreading. The x86 side depicts the branch predictor, decode, execution, load/store, and memory stages alternating between two threads. The caption says Vera avoids “opportunistic time-sharing” by partitioning resources across its two hardware threads.
NVIDIA’s diagram gives a misleading impression of how SMT is usually implemented, both on x86-64 and other ISAs. SMT implementations ：https://cs.ucr.edu/~bhuyan/cs203A/hyperthreading.pdf share various stages in the execution pipeline by either selecting a thread to service every cycle, or by behaving in a thread-agnostic manner. Fetch, decode, and allocate typically service threads on a per-cycle basis, while the execute and memory access stages are thread agnostic and can service micro-ops from both threads in the same cycle. Stages that threads arbitrate for do not leave resources unused when both threads can be fed, as NVIDIA’s diagram suggests. Static partitioning and per-cycle selection would provide the same average throughput to both threads in the absence of per-thread stalls. If there are stalls, per-cycle selection can give otherwise unused throughput to the un-stalled thread.
The same idea applies to thread agnostic stages like execute and cache access. Each thread is permitted to utilize as many execution units or cache ports as it can feed. In contrast, statically partitioning resources as NVIDIA suggests could lead to one thread being compute bound and unable to use half of the core’s execution resources because they’re reserved for the other thread.
Text in NVIDIA’s paper emphasizes “determinism, isolation, and quality of service” as advantages for NVIDIA’s Spatial Multithreading approach. Performance is conspicuously not called out. QoS may be a more important consideration than throughput for NVIDIA’s target market, and Spatial Multithreading may not be a bad design point. But NVIDIA’s figure makes it look like vertical space represents time, and gives a misleading impression that Spatial Multithreading is meant to give larger performance gains than traditional SMT.
By reducing resource interference between threads, Spatial Multithreading improves determinism, isolation, and quality of service compared to traditional SMT approaches. The result is a CPU architecture that can run large numbers of concurrent agent tasks while maintaining more consistent latency and throughput. - NVIDIA’s Vera whitepaper
Vera’s actual SMT performance is unknown of course, and a lot of variables go into SMT gains besides partitioning strategies at fetch, decode, execute, and memory access. Out-of-order resources like the reorder buffer, register files, and memory ordering queues can be duplicated, statically partitioned, watermarked, or competitively shared. Partitioned structures were split between the two logical processors in multi-threaded mode and recombined for one thread in single-thread mode, which was documented in 2002 ：https://www.intel.com/content/dam/www/public/us/en/documents/research/2002-vol06-iss-1-intel-technology-journal.pdf . Various SMT implementations use different strategies for each structure, and those choices can have significant implications for SMT gains.
Also something to note is that it apparently takes 10,000 cycles for an Olympus core：https://lore.kernel.org/all/20260804151324.918020-1-arighi@nvidia.com/ to transition back to the single-thread mode once the sibling thread on that core is done. This means that software will have to be very aware about launching a second thread on an Olympus core due to the penalties incurred not only from the partitioning scheme but also from the delay of swapping back to a single thread.
It’ll be interesting to see what strategy Vera uses to partition its out-of-order resources, and how its SMT performance compares to that of other modern cores. NVIDIA’s whitepaper gives no information on that. What it does do is present a misleading diagram that suggests traditional SMT is prone to leaving resources unused, when it may actually be better at keeping the core fed than NVIDIA’s Spatial Multithreading.
NVIDIA next tells us that a large two-socket x86 system can expose “as many as 32 NUMA domains,” while Vera presents one per socket. The number is not invented. On a many-chiplet EPYC system, an administrator can expose cache-local regions as separate NUMA nodes. If you turn every locality knob toward maximum granularity, the node count gets large.
What NVIDIA leaves out is that this is configurable with AMD’s tuning guide listing NPS4, NPS2, NPS1, and even NPS0 modes ：https://docs.amd.com/v/u/en-US/58479_amd-epyc-9005-tg-hpc . The optional “LLC as NUMA” setting can expose each last-level-cache domain separately. So “32 NUMA nodes” is not the inevitable user experience of a chiplet CPU, it is one end of a locality-control spectrum. NVIDIA presents an optional high-granularity configuration as though it were an unavoidable reality of x86 systems.
Vera’s one domain per socket simplifies scheduling and memory placement, while multiple domains let tuned software exploit physical locality. Vera chooses the simpler presentation, and NVIDIA is free to argue that this better matches its intended software stack. But an OS-visible NUMA node is an abstraction, not a wormhole. Vera still has 88 cores, distributed cache and home nodes, memory controllers around a large die, and a packet-switched coherency fabric. A flat software topology can make those distances around the large monolithic compute die more consistent, but it cannot make them nonexistent.
The paper’s core-to-core heatmaps would be a good place to quantify that advantage. Instead, NVIDIA provides colored squares with no core identities, no minimum/median/maximum table, no distribution, and no measurement procedure. “Up to 50% lower” captures NVIDIA’s best result, not Vera’s typical behavior.
One NUMA node per socket is genuinely simpler, but the whitepaper compares it against an optional 32-domain x86 configuration and presents that edge case as the baseline. The counterpoint here is that Intel has a Mesh NoC just like Vera has. The difference really between these two setups is that the clustered setup of EPYC has high latency between clusters but within a cluster the latency is low, whereas Vera and Xeon Mesh setup has uniformly average latency; the different configurations are just engineering tradeoffs.
The benchmark section is where the whitepaper, ostensibly about a CPU, starts wearing an AI conference badge it found on the floor.
NVIDIA selects four SPEC CPU 2026 integer workloads, CPython, GCC, LLVM, and Cppcheck, and calls them “agentic benchmarks.” SPEC itself describes them ：https://www.spec.org/cpu2026/Docs/ as a Python interpreter, two optimizing compilers, and a C/C++ static analyzer. Those are legitimate CPU programs. They stress large instruction footprints, branch-heavy code, allocation, and dependency chains. Agents can absolutely invoke programs like them.
But they are not agents: no model is serving tokens, no agent runtime is choosing tools. No sandbox is starting, blocking on I/O, retrieving context, evaluating an answer, or feeding observations back into a policy. These workloads may be useful proxies for the code-heavy portions of an agentic pipeline. Calling them “agentic benchmarks,” however, turns that partial overlap into a claim that they represent the complete end-to-end workload.
The paper does correctly label the SPEC results as estimates, because the Vera reference hardware was not generally available at the time of the run. Figure 15 shows a 1.7x to 1.8x advantage for the four selected components, normalized per physical core under a fully loaded two-socket system. Flip to the configuration pages and the full estimated SPECrate 2026 Integer Base totals are 925 for two Vera sockets and 898 for two EPYC 9755 sockets which is a 3.0% system-throughput advantage.
Both numbers can be true. Vera uses 176 physical cores across two sockets, while the EPYC system uses 256. Divide each score by physical-core count and Vera is about 50% faster per core across the full integer-rate suite with the selected tests reaching 70 to 80%.
There is another terminology collision. NVIDIA calls Figure 19 “single thread IPC” while describing a fully loaded system.
The published configuration runs 352 copies on 176 Vera cores and 512 copies on 256 EPYC cores, two copies per physical core. Maybe NVIDIA sampled one logical thread while its sibling was active, maybe it aggregated counters and divided, the paper does not say. The SPEC results are useful, and Vera’s per-core performance is genuinely strong. However, framing those tests as agentic workloads and emphasizing normalized figures makes the advantage appear broader than the disclosed results justify.
NVIDIA attributes Olympus’s reported IPC lead to four counter groups. Depending on the selected workload, Vera supposedly achieves up to 2.3x more branch predictions per cycle, 3.5x more taken branches per cycle, 2.4x more instruction-fetch operations per cycle, and 4.3x more backend operations per cycle.
That sounds technically specific, but it is impossible to audit without the PMU event names and definitions, raw counts, sampling intervals, clock frequencies, etc. Not to mention that an Arm instruction is not the same unit of work as an x86 instruction. An internal backend operation is even less portable: one microarchitecture may split an instruction into several micro-operations while another keeps it fused.
Cross-ISA IPC can still be informative when paired with retired-work counts, clock frequencies, and code analysis. It cannot stand alone as a performance metric. Two binaries can complete the same task in the same amount of time while reporting very different IPC. For one may simply retire more instructions that are doing less work per instruction, then you have to factor in clock frequency which could be wildly different. IPC describes the behavior of the core running a piece of code, not a universal measure of useful work.
Looking at the branch predictor results, more branch predictions per cycle could indicate a capable predictor or it could also mean the Arm binary contains more branches, the benchmark moves through code faster, or NVIDIA’s event counts speculative predictions that the EPYC event does not. Higher backend operations per cycle may correlate with performance while telling us little about which feature caused it. To isolate value prediction, graph prefetching, or the neural predictor, we need on/off experiments or at least event definitions and miss rate deltas. While the IPC advantage of Vera over Turin may be real, the charts in NVIDIA’s whitepaper don’t provide enough granularity of the results to show it.
The memory section contains NVIDIA’s strongest result and one of its weakest conclusions.
Against the dual-socket EPYC 9755 system in the paper, Vera reaches roughly 1.1 TB/s in NVIDIA’s loaded-latency plot while Turin levels off near 400 GB/s. Vera also shows 12.7 GB/s per core versus 3.1 GB/s per core for Turin. Those results do not line up with our testing of Turin CPUs.
In our testing of Turin, we were able to get approximately 570 GB/s out of Turin with the 12 channel DDR5-6400 memory subsystem. This is in direct contradiction to NVIDIA’s results which top out at ~400 GB/s of memory bandwidth. This does also throw the per-core memory bandwidth numbers into dispute with the per-core bandwidth increasing to ~4.5GB/s for the EPYC 9755.
Vera still comes out ahead, but our Turin result substantially changes the size of that advantage. Comparing Vera’s roughly 1.1 TB/s against the 570 GB/s we measured gives NVIDIA a 1.9× bandwidth lead rather than the nearly 3× lead shown in the whitepaper. Revising the EPYC 9755’s per-core result from 3.1 GB/s to approximately 4.5 GB/s similarly reduces Vera’s advantage from 4.1× to roughly 2.8×. And if we look at the SKU that AMD actually puts forward as the SKU for AI head nodes, the EPYC 9575F, then the per-core result becomes 12.7 GB/s vs the 9575F’s ~9 GB/s which is about 40% improvement for Vera. Those are still good numbers for Vera, but they tell a considerably less dramatic story.
Looking at the theoretical figures, AMD lists Turin’s limit at 614 GB/s from its 12 DDR5-6400 channels. Our 570 GB/s result reaches approximately 93% of that theoretical limit. Vera’s eight LPDDR5X-9600 interfaces provide 1.2 TB/s, while NVIDIA’s measured 1.1 TB/s reaches roughly 92% of that figure. In other words, both processors convert a remarkably similar percentage of their theoretical memory bandwidth into sustained bandwidth. Vera wins because it has approximately twice the peak bandwidth of one Turin socket and fewer cores competing for it, not because Turin is unusually poor at using its available memory bandwidth.
Despite that, the whitepaper repeatedly credits Vera’s monolithic compute die while contrasting it with “traditional chiplet-based CPUs.” A monolithic die may reduce fabric traversal and improve loaded latency, but our Turin result directly weakens that explanation for the bandwidth difference. A chiplet-based EPYC 9755 reaching approximately 93% of its theoretical limit is clearly not being held back by its chiplet topology in this case. The bulk of Vera’s bandwidth advantage comes from the memory interfaces attached to the processor.
The comparison also aged almost immediately. NVIDIA published its technical blog and whitepaper on July 21, while AMD launched 6th Gen EPYC two days later. The 96-core EPYC 9686F, which is much closer to Vera’s 88-core count, provides 16 memory channels supporting DDR5-8000 or MRDIMM-12800 for 1,024 or 1,638 GB/s per socket with the top MRDIMM speed giving Venice more theoretical bandwidth than Vera both in total memory bandwidth and per-core memory bandwidth depending on what SKU you look at.
What the new EPYC specifications and our Turin testing demonstrate is narrower than NVIDIA’s claim of “3× more memory bandwidth than the latest x86 CPU” depends on a Turin result that does not represent the bandwidth we could extract from the same processor generation. Against our result, Vera delivers approximately 1.9× the total bandwidth and 2.8× the bandwidth per core, that remains an impressive platform result but it is not evidence of a bandwidth advantage for monolithic Arm processors over chiplet-based x86 CPUs.
NVIDIA reports a 2.6x PageRank advantage over EPYC 9755 and shows Vera scaling almost linearly to 32 cores while EPYC flattens to just a 10X performance increase at 32 cores. NVIDIA attributes this improvement over Turin as down to the monolithic compute die with their high-bandwidth Scalable Coherent Fabric, the 1.2 TB/s of memory bandwidth that Vera has, and the graph prefetcher inside the Olympus core.
However, while the paper links GAP Benchmark Suite, it omits what variables NVIDIA used which are important factors on how this test runs. The scaling plot stops at 32 cores even though the machines have 88 and 128 cores per socket. While the 2.6x result is interesting, without the variables that NVIDIA used, the result is likely irreproducible.
For the ClickHouse testing, NVIDIA links directly to Phoronix’s result ：https://www.phoronix.com/review/nvidia-vera-benchmarks/10 where Vera led the tested processors across three passes over a 100-million-row dataset. The whitepaper’s 1.2x chart is still selective due to not using the 9575F results, but an outside tester produced the underlying result with a recognizable workload.
Then we reach Figure 24, “Vera drives 1.8x for RL training,” with the figure being a row of little completed-task squares. There is no model, environment, CPU/GPU allocation, framework, batch size, power measurement, repetition count, or error bar. We do not even know whether the squares represent samples, steps, or some random layout of tiles at NVIDIA HQ.
This is not a bad benchmark, it simply is not a benchmark at all.
The surrounding text explains why a faster CPU could improve reinforcement-learning rollouts with faster environment steps and reward computation can feed accelerators more quickly however Figure 24 does not even pretend to measure it.
After 45 pages, my position on Vera is more positive than my position on the Vera whitepaper.
Olympus looks like a serious core with a 10-wide fixed-length decoder, large private caches, value prediction, aggressive branch handling, graph-aware prefetching, and a monolithic 88-core die all being choices pointing to a very high-performance CPU core. The memory setup is no slouch either with the LPDDR5X subsystem delivering up to 1.2 TB/s of memory bandwidth that memory bandwidth-hungry server workloads will love, and early independent benchmarks say the silicon can cash at least some of the checks that the whitepaper writes.
However, the paper’s competitive argument is much shakier, with it mischaracterizing x86 SMT, turning an optional NUMA configuration into a default burden, relabelling standard CPU tests as agentic workloads, hiding a 3% two-socket rate lead behind 1.8x per-core bars, comparing undefined cross-ISA counters, attributing a memory-interface win to monolithic virtue, and presenting an illustration as performance data.
None of that makes Vera slow, it simply makes NVIDIA’s proof smaller than NVIDIA Marketing’s prose.
The next round of Vera testing should be straightforward. Give independent reviewers unrestricted production hardware so that we can publish frequency, package power, and wall power figures along with testing Spatial Multithreading on/off results and of course running whatever benchmark/workload we wish on Vera. If Vera is as good as its architecture suggests, those tests will be much more persuasive than drawing x86 SMT as a tiny two-lane traffic light. The way things stand, NVIDIA’s marketing risks tarnishing Vera. NVIDIA has built enough CPU here, it can stop borrowing performance from the marketing pipeline.
88 cores on a single monolithic compute die -> That looks to me like the biggest compute chiplet/tile made so far for a server class CPU? Makes me thing about the yield they getting out from TSMC fabs.
It helps with core-to-core latency graph (no cliff dive scenario), but that would make the SOC interconnects massive. More metal wiring (at the lowest metal region, M0,M1), wouldn't that hold back max boost clocks?
The difference really between these two setups is that the clustered setup of EPYC has high latency between clusters but within a cluster the latency is low, whereas Vera and Xeon Mesh setup has uniformly average latency; the different configurations are just engineering tradeoffs.
For cloud virtualization workload -> having a more "dis-aggregated" mesh works better (since cores in a rented cluster works in isolation, mostly)
For AI (Training+Inference), since that workload needs more communication across/between cores, bigger interconnect setup works better to bring down latency? Even though a mesh that big has to run at the "Uncore" frequency.
扫码直达文章详情