OCI 上的 Nvidia Vera 让独立 CPU 加入与 Xeon 的竞争

OCI 上的 Nvidia Vera 为 Oracle 客户提供了独立 CPU 选择，而单独的测试报告称，其内存带宽超过双 Xeon 服务器的两倍。Nvidia 和 Oracle 于 10 月 27 日宣布正式商用，同时计划将其 AI 基础设施扩展至数吉瓦规模。两者的区别很重要：处理器现已可独立使用，而扩展仍处于计划阶段。

这项基准测试来自 Tom’s Hardware。该媒体测试的是一台独立 Vera 服务器，而非 Oracle Cloud Infrastructure（OCI）。它为处理器能力提供了证据，但并未说明 Oracle 实例的实际表现。本文分析已发布的证据；不提供原创硬件测试结果。

竞争焦点在于 AI 模型响应之间运行的工作。Intel Xeon 和 AMD EPYC 处理器已经在企业基础设施中承担这些服务。Oracle 的决定为 Nvidia 提供了进入这一市场的另一条路径：除了处理器兼容性，内存数据传输和应用程序执行也将成为采购标准。

OCI 上的 Nvidia Vera 将 CPU 容量与 GPU 采购分离

Oracle 正将 Vera 作为可独立部署的计算能力提供，使这款处理器的角色不再局限于托管 Nvidia 加速器。

CPU，即中央处理器，负责运行应用程序指令并管理通用计算任务。GPU，即图形处理器，执行通常用于训练和运行 AI 模型的并行工作负载。即使客户会一并采购，这些资源仍支持 AI 应用的不同阶段。

两家公司关于独立 CPU 部署的公告明确指出，客户可以独立扩展 CPU 和 GPU 资源。这为软件需要更多应用处理能力、但并不需要相应增加模型容量的组织提供了实际选择。

Vera Rubin NVL72 是与 CPU 同时公布的更大规模机架配置。它通过 Nvidia 用于处理器间通信的互连技术 NVLink 连接 72 块 GPU。独立 Vera 服务则针对另一项采购决策：运行这些模型周边软件的位置。

以一个示例性的编程助手为例。模型提出修改建议，执行服务对其进行测试，应用程序再返回结果，以供模型做出下一次响应。即使模型本身在别处运行，测试服务仍会消耗 CPU 资源。

在繁忙时段，客户可能需要增加执行能力，而其模型服务仍有余量。单独采购这些资源，便有机会让基础设施更贴近实际需求。是否能提高效率，则取决于应用的真实资源使用情况。

Oracle 的可用性公告也应与计划中的实体扩张区分开来。数吉瓦规模描述的是预期的基础设施建设，而非当前正在运行的独立 Vera 容量测量值。它并不能说明客户可以立即预订多少设备。

这种区别会改变买方解读新闻的方式。正式商用意味着一项商业服务已经推出，而部署规模涉及供应、建设和客户采用情况。仅凭任一说法，都无法证明应用性能。

独立服务也改变了 Nvidia 与潜在客户的关系。团队可以先评估其 CPU 是否适合某项服务，而不必先决定部署完整的 Rubin 系统。届时，处理器必须依靠该服务自身的需求来证明价值。

这比决定是否附加加速器带来了更严格的比较。买方可以询问，Vera 是否比现有基础设施更适合运行其应用，包括那些从不直接与 Rubin GPU 通信的工作负载。

由此形成的竞争聚焦于一个熟悉的企业问题：哪种服务器配置能以可接受的运维投入完成所需工作？Nvidia 的 AI 定位会吸引关注，但处理器最终适合何处，仍取决于普通应用程序的实际行为。

压力落在模型调用之间的服务上

独立 Vera 对决定 AI 应用能否快速继续执行的 CPU 服务带来了竞争压力。

AI 智能体是利用模型输出选择并执行操作的软件。其应用可以检索信息、运行程序、检查结果，并请求模型再次响应。每一项操作都会引入依赖关系，而更快的模型本身无法消除这些依赖。

假设一个助手在回答技术问题前必须搜索内部文档。其响应取决于检索完成、权限检查以及结果传递给模型。增加模型容量对检索服务内部的延迟帮助不大。

同样的逻辑也适用于代码执行。模型可以快速生成测试，但应用程序仍可能在等待繁忙的执行环境。当执行延迟在整体任务中占据有意义的比例时，改善该环境才会带来价值。

Oracle 在其预期的智能体 CPU 工作负载中列出了这些周边服务。示例包括工具执行、检索、分析和运营应用。这些是建议的工作负载适配场景，而非每种部署都会受益的保证。

眼前的压力落在为这些服务选择下一代平台的基础设施团队身上。他们需要确认应用耗时是在计算、移动内存数据、访问存储，还是等待其他系统。每一种瓶颈都指向不同的投资方向。

Intel 和 AMD 仍然重要，因为买方已经拥有围绕其处理器构建的软件、部署流程和运维经验。这些既有投入具有实际价值。竞争性处理器必须带来足够的收益，才能证明引入另一种受支持环境的合理性。

因此，比较不止于基准测试排行榜。需要大幅修改应用的更快服务，与几乎无需调整就能运行现有软件的服务，面临的是不同的采用决策。

Oracle 也有动力仔细区分这些服务。客户需要的是支持其工作负载组合的基础设施，而不是把单一处理器建议套用到每一个应用。更广泛的产品目录会带来更多选择，也带来更多评估工作。

对开发者而言，这会改变优化讨论的起点。在选择硬件之前，团队需要证据表明应用的哪个部分延迟了有用结果。否则，一颗很有前景的 CPU 可能成为对未被识别问题的回答。

对企业买方而言，后果类似。AI 基础设施方案应将应用程序执行与模型服务一并纳入考量。只评估模型，可能会忽略决定用户能否及时获得完整结果的系统。

当这些周边服务已在并发压力下挣扎时，这种压力最为明显；并发意味着许多任务同时运行。在这种情况下，处理器在持续负载下的表现比孤立演示更具参考价值。

Vera CPU 内存带宽瞄准特定瓶颈

Vera 的架构论点始于让 CPU 核心获得充足的数据供应，而非将核心数量视为性能的充分证据。

内存带宽衡量系统在一段时间内从内存传输多少数据。反复处理大型数据集的应用，可能在耗尽算术处理能力之前就达到这一限制。除非数据传输得到改善，否则增加处理资源的帮助有限。

Nvidia 对Vera 内存架构的描述指出，该处理器拥有 88 个核心、176 个线程，以及最高 1.2 TB/s 的内存带宽。线程是执行路径，可让软件将工作分配到可用的处理资源上。

该芯片使用 LPDDR5X，这是一种低功耗内存技术。Nvidia 还描述了第二代一致性互连架构，即维持处理器内共享数据一致性的内部互连。其公布的双向截面带宽为 3.4 TB/s。

这些带宽数据描述的是系统的不同部分。外部内存流量与内部通信具有相关作用，但两者的额定值不能相互替代。任何一项规格都无法直接说明应用完成任务的速度。

当有用工作依赖于反复访问处理器容量较小、速度较快的缓存之外的数据时，Vera CPU 内存带宽便具有意义。缓存将频繁使用的信息保存在执行资源附近，减少从主内存获取数据的需求。

一个示例性的分析服务可能在响应并发请求时反复扫描工作数据集。若这些扫描占满内存传输能力，额外带宽便为提升吞吐量提供了合理路径。吞吐量衡量单位时间内完成的工作量。

另一种应用可能大部分时间都在等待远程存储。同样的内存改进只能解决其延迟中的较小部分。这正是工作负载特征比软件所属类别更重要的原因。

Arm 兼容性也应纳入评估。Arm 是 Vera 支持的处理器指令架构，它定义软件能够执行的指令。现有应用及其依赖项需要兼容的构建版本，其性能才具有比较价值。

即使以可移植语言编写的服务，也可能依赖特定架构的组件。数据库扩展、安全软件和已编译库都值得关注。应用成功启动，并不意味着每项依赖都会走相同的优化路径。

这正是 Nvidia 机会背后的核心机制：提供一款数据传输和执行特性适合高价值服务的处理器。这比替换所有企业 CPU 的主张更具体。

该架构论证为测试 Vera 提供了理由。它并不能决定采购选择，因为软件行为、部署配置和持续利用率决定了用户实际能获得多少这类能力。

Vera 与 Xeon 基准测试确立优势，但边界清晰

Tom’s Hardware 的结果支持 Vera 在其测试配置中具有内存带宽优势，但 OCI 上的应用性能仍未得到测量。

该媒体的服务器内存基准测试将 Vera 与双 Intel Xeon 6980P 系统进行比较。其报告称，Vera 在 STREAM triad 中的带宽超过两倍；这是一项使用数组操作测量持续内存传输的基准测试。

经测试的 Vera 系统使用了 LPDDR5X-9600 内存。Xeon 对比系统使用了 MRDIMM，这是一种为更高传输速率设计的内存模块，运行速度为每秒 8,800 兆次传输。这些配置细节有助于界定结果的适用范围。

Tom’s Hardware 还报道称，线程放置对 Vera 的带宽有显著影响。其使用了 OpenMP spread 策略，即将并行执行线程分布到各处理资源上的设置。该媒体表示，更完整的测试配置细节将随即将发布的评测一并提供。

这些发现之所以重要，是因为它们展示了超出厂商规格说明的实测优势。然而，这项测量回答的问题，比 Vera 是否能让整个应用速度提升一倍要更为狭窄。

一项服务可能会将内存处理与存储访问、网络通信和串行执行结合在一起。串行执行是指必须按顺序完成的工作。改进其中一个组件，并不会消除其余组件的影响。

这一区别对智能体尤为相关。一个工作流可能短暂执行一次内存密集型操作，随后等待外部工具更长时间。无论处理器在基准测试中的表现如何，其总完成时间都会反映这两个阶段。

Vera 与 Xeon 的对比还涉及完整配置。实测结果反映了处理器、内存、软件和调优协同工作的表现。买家不应将全部差异归因于某一项架构特性。

线程放置也为检查运行环境提供了另一项理由。实验室中有利的放置策略，在生产环境中可能需要显式配置。虚拟机将物理服务器划分为彼此隔离的软件环境，也增加了一层需要评估的部署因素。

公平的比较应允许每个平台进行合理调优。若让竞争产品处于不合适的设置下，测量到的将是配置选择与硬件差异的混合结果。反过来，如果维持某一结果需要非常规的维护，也会引入值得记录的运营负担。

已发布的基准测试并未确立能效排名。这需要在系统执行可比工作时测量实际功耗。仅凭带宽结果，无法揭示完成一项应用任务会消耗多少能源。

它同样未能确立数据库、编译或应用服务器场景下的普遍胜者。不同工作负载会给不同资源施加压力，即便它们使用相同的语言或部署框架也是如此。

因此，在所报告的配置中，Vera CPU 内存带宽作为一项已验证的优势值得关注。下一步需要的证据，是将这一优势转化为买家实际可部署服务中可重复的应用结果。

Oracle 的部署为 Intel 留出空间，也要求进行部署验证

Oracle 在引入 Vera 的同时，仍为 Rubin 系统保留基于 Intel 的路径，这使按工作负载选择的说法比全面替代的叙事更可信。

计划中的 HGX Rubin NVL8 配置将八个 Rubin GPU 与两颗 64 核 Intel Xeon 6 处理器及 4TB DDR5 内存结合。DDR5 是广泛使用的一代服务器内存技术。该计划中的产品在 Vera 之外保留了 x86 应用路径。

X86 是本文讨论的 Intel 和 AMD 服务器处理器所采用的指令架构。即使另一种处理器在特定测试中表现更强，保留这一选项对于有既有软件要求的应用仍然重要。

Oracle 更广泛的infrastructure roadmap还提到将继续与 AMD 和 Intel 合作。其中列出了计划推出的 AMD EPYC E7 实例以及基于 Intel Diamond Rapids 的 X14 产品。这些仍属于路线图项目，而非本次公告所确认的已交付替代方案。

因此，竞争格局比 Nvidia 进入、现有 CPU 退出更复杂。Oracle 正在扩展可用的处理器与加速器组合。买家可以将应用兼容性与模型服务硬件的选择分开考虑。

可用性本身也需要仔细解读。Oracle 详细的Vera 实例规格描述了裸金属和 Flex 虚拟机产品。裸金属让客户直接使用一台物理服务器，而非经过虚拟化分配的一部分资源。

所述的双处理器配置提供 176 个核心、352 个线程和 1TB 系统内存。这些实例细节必须与单颗处理器的规格区分开来。

Oracle 的 CPU 文章宣布已正式上市，但也表示这些实例将在本季度进入部分区域。这种表述留下了一个实际问题：特定客户何时才能在所需地点获得合适的容量。

对于有数据驻留要求的组织而言，区域承诺十分重要。其他地区可用的处理器，无法解决部署受限于特定司法辖区的问题。容量还必须足以支撑目标服务，而不只是可供评估。

Oracle 还表示，将在其各区域提供首批 150,000 颗 CPU。该公告没有提供按区域划分的分配情况，也没有证据表明列出的每个单元都已在承载客户工作负载。

其性能主张也需要作类似区分。Oracle 引用了 Nvidia 关于智能体 CPU 性能最高快 80% 的说法，同时明确这些结果属于平台基准测试，而不是 OCI 实例层面的测量。

这一披露限制了买家将该说法转化为服务预测时的可信程度。恰当的做法是将目标实例、应用构建版本和运行设置结合起来测试。

迁移工作也应纳入这项评估。团队在迁移关键服务之前，需要具备兼容的依赖项、部署镜像、监控和恢复流程。这些要求并未削弱硬件的价值；它们界定了可靠使用硬件所需完成的工作。

最有说服力的采用理由，是应用收益与可控运营变更的结合。能经受这些检验的处理器优势，比只在客户无法复现的条件下可见的优势更有分量。

三个信号将表明独立的 Vera 是否能赢得更广泛采用

接下来的证据应证明可获得的容量、可复现的应用性能，以及超越早期评估的持续使用情况。

第一个信号是更明确的区域可用性。在未来数月内，买家应关注其应用所需地点是否有已记录的实例访问能力。支持可重复部署的推广，将增强 Vera 作为实用基础设施选项的说服力。

容量信息应说明客户实际可以获得什么，而非仅说明 Oracle 打算部署什么。预留访问、服务限制和配置文档，有助于将发布公告与运营决策联系起来。

第二个信号是可由独立方复现的 OCI 应用测试。这类测试应比较使用兼容软件构建、执行等价工作的服务，并清晰记录设置。最有价值的结果将展示持续并发下的已完成工作量和响应时间。

接近饱和时的响应时间尤其值得关注。服务器可能报告出有吸引力的平均吞吐量，但少数请求的等待时间可能长得多。这些延迟会影响依赖每次工具调用都完成的用户工作流。

对于 Vera 与 Xeon 的问题，等价工作比相同的营销类别更重要。测试应说明内存配置、软件调优和资源分配。否则，读者无法判断结果能否适用于测试配置之外的环境。

若有证据表明所报告的带宽优势能够改善内存密集型服务，将加强这一架构论点。若结果主要受无关瓶颈支配，则会缩小该论点适用的应用范围。

第三个信号是具有已披露工作负载结果的持续生产采用。客户参与很有价值，但仅有一个具名部署，对于性能或运营投入提供的证据有限。对应用及其测量行为的说明会更具参考价值。

有用的案例应说明服务为何迁移、部署后发生了哪些变化，以及仍存在哪些限制。它们还应区分处理器影响与软件、存储或应用设计同时发生的变更。

在合适服务中的更广泛采用，将支持 Nvidia 在云基础设施中建立独立 CPU 业务的主张。若采用集中在一小部分专门部署中，则表明其角色更为有限。这两种结果都可以与强劲的内存基准测试成绩并存。

对于开发者而言，眼下的行动是测量应用中已经存在的依赖 CPU 的阶段。识别执行在哪些地方停滞，保留具有代表性的工作负载，并记录运行环境。这会在评估另一种处理器前建立有用的基线。

团队可以将这些发现整理到一个可搜索的知识库中，使配置说明与应用结果保持关联。其目的，是在后续比较得出不同结果时保留上下文。

当内存流量或 CPU 执行已经限制有效工作时，值得在 OCI 上评估 Nvidia Vera。应从瓶颈已被测量的服务开始，然后在具有代表性的负载下比较完整部署。明确记录应用版本、调优选择和资源分配。询问任何收益是否能在繁忙时段持续，以及团队能否可靠地运营该服务。在将可用性视为既定事实之前，应要求提供区域容量证据。将厂商主张与独立测量分开，并保留每项结果的局限性。有价值的采购问题很具体：在团队能够复现的条件下，这款处理器是否改善了应用实际执行的工作？