OCI 上的 NVIDIA Vera Rubin 向多吉瓦规模扩展，CPU 的作用日益突出

NVIDIA 和 Oracle 于 10 月 27 日宣布计划进行多吉瓦规模扩展，同时宣布 NVIDIA Vera Rubin on OCI 正式全面上市。此次公告将新增 GPU 容量与用于处理模型调用间任务的独立 Vera CPU 相结合。其意义不止于更大的集群：客户可随着应用需求变化，分别扩展这些资源。

OCI 是 Oracle Cloud Infrastructure 的简称，正向构建智能体的开发者推介这种灵活性；智能体是调用模型并执行工具的软件系统。这类应用会在生成答案与执行常规计算任务之间交替进行。购买更多模型服务容量，并不会自动加快周边工作。

核心矛盾在于：既要扩大已部署的计算容量，又要保持这些容量的生产效率。Google Cloud 已通过 Ironwood 和 Axion 推广协同的 CPU 与加速器基础设施。Oracle 的公告让这种系统层面的竞争更加清晰，同时也让 NVIDIA 的 CPU 业务在 GPU 业务旁获得更显著的位置。

OCI 上的 NVIDIA Vera Rubin 将现有可用性与扩展计划相结合

即时产品发布与计划中的基础设施扩展代表着不同的里程碑。

在双方联合发布的 Vera Rubin 扩展公告中，NVIDIA 和 Oracle 区分了当前可用性与未来规模。Vera Rubin NVL72 系统和 Vera CPU 已在 OCI 上全面上市。利用这些系统将 OCI Superclusters 扩展至多吉瓦规模，仍是一项既定计划。

这一差异对于解读标题的读者而言很重要。全面上市意味着商业产品已经推出，但并不表示全部计划中的扩展已经安装、通电、预留或开始承载客户工作负载。

吉瓦衡量的是功率，而非已完成的计算工作量。将功率承诺转化为实用的 AI 服务，需要设备、网络、冷却、软件和客户部署。因此，标题描述的是预期的基础设施规模，并未证明已交付相应数量的应用输出。

机架本身提供了更具体的参考。NVIDIA 的 NVL72 规格描述了一种由 72 个 Rubin GPU 和 36 个 Vera CPU 组成的配置。GPU，即图形处理单元，负责模型训练和推理所需的并行计算；推理是生成模型输出的过程。

这些组件在机架内协同工作，但独立 CPU 产品针对的是另一种采购决策。运行工具执行或应用服务的客户，需要模型服务系统之外的计算容量。Oracle 和 NVIDIA 表示，客户可以独立扩展其 CPU 和 GPU 资源。

实际意义在于，客户可以更灵活地组装应用。团队不一定要在某个阶段出现拥塞时扩展所有资源池，而可以评估是模型生成、代码执行、检索，还是其他环节需要额外容量。

这是一种架构选择，而不是自动提升效率的保证。应用仍需借助软件将工作导向合适的资源，并在需求变化时作出响应。独立扩展为运营者增加了一项控制手段；它并不决定运营者应如何使用这一手段。

对买方而言，此次公告带来了关于可用性和交付的独立问题：目前可获得哪些配置？可在哪些地点获得？Oracle 能在其部署周期内承诺多少容量？

这些问题也决定了应对扩展计划赋予多大权重。庞大的未来规模对于长期采购具有参考价值；而具体的资源配额、受支持的配置和部署窗口，则能为工程决策提供更直接的依据。

智能体工作负载对模型调用之间的计算提出压力

此次公告给那些主要通过 GPU 集群衡量 AI 容量的团队带来了压力。

模型响应只是智能体工作的一部分。选择某项行动后，应用必须执行它、检查结果，并决定下一步如何进行。这些阶段带来不同的计算需求和不同的延迟来源。

以一个被要求修复故障应用的示例性编程智能体为例。它会检索项目文件，请求模型提出修改建议，运行测试，再将结果返回以供下一次决策。尽管用户感受到的是一项连续任务，模型和测试运行器执行的却是不同工作。

当生成环节是瓶颈时，增加模型服务容量会有所帮助。但如果测试在等待执行环境，或花费时间编译依赖项，其帮助就有限。关键问题变成了工作流在哪里等待，而非哪个组件的规格最亮眼。

NVIDIA 和 Oracle 明确指出，执行工具、测试代码和检索数据是支持智能体的 CPU 密集型任务。CPU，即中央处理单元，运行通用应用指令，并管理大量这类周边工作。两家公司将独立 Vera 容量定位为分别支持这些阶段的方式。

Oracle 的 Vera CPU 部署提出了一项规模声明：初始部署 150,000 个 CPU。Oracle 还描述了早期客户访问，并表示 OpenAI 正将 Vera 投入用于智能体工作负载的生产环境。这些均为通过 Oracle 出版物呈现的供应商和客户声明。

CPU 数量显示了 Oracle 为这一产品赋予的规模，但并未说明某一客户能预留多少处理器、这些处理器的运行负载有多高，或它们能交付多少应用吞吐量。这些区别避免将部署规模替代为运营证据。

直接压力落在基础设施规划者和 AI 应用团队身上。他们需要理解模型请求与这些请求触发的工作之间的平衡。以加速器数量为中心的采购流程，往往未充分审视这一平衡。

这并不意味着每个智能体应用都需要专门的 CPU 部署。有些工作流大部分时间都在等待外部服务。另一些工作流会生成较长的模型响应，但工具执行相对较少。合适的资源组合取决于应用实际的操作序列。

同一原则也适用于知识工作流。搜索 AI 知识库的助手，必须先检索到相关材料，才能给出有用的答案。额外的生成容量无法弥补文档无法访问、权限缺失或检索缓慢的问题。

对企业买方而言，这将基础设施决策与用户体验联系起来。当任务路径中的任一环节停滞时，服务就会显得缓慢。客户很少会区分延迟是来自模型、工具、数据库，还是协调它们的软件。

因此，此次公告鼓励采用更广泛的评估标准。团队应询问基础设施如何支持一项完整任务，包括其间的中间步骤。这正是此次发布带来的压力：解释应用性能与描述已安装硬件同样重要。

独立扩展旨在解决调度问题

只有当应用能有效利用这种分离时，将 CPU 和 GPU 的增长分开才会有所帮助。

从架构层面看，OCI 上 NVIDIA Vera Rubin 背后的机制很直接：在模型需要紧密连接资源的场景中，将这些资源置于一起；为需求模式不同的周边任务提供独立计算容量。

NVIDIA 的 Rubin 平台架构描述了一个围绕协同计算、网络和软件设计的系统。NVLink 是 NVIDIA 在处理器之间提供的高速连接，支持模型计算系统内部的通信。这种内部连接与分配独立的工具执行工作节点池，服务于不同目的。

这一差异避免了一种常见误解。独立扩展并不意味着 NVL72 机架内的每个组件都可独立变化；它描述的是客户如何在其应用基础设施中扩展不同的 CPU 和 GPU 资源。

回到编程智能体的例子。测试活动突然增加时，可能需要更多执行工作节点，而模型需求保持相对稳定。另一类工作负载则可能生成更多模型请求，却不会相应增加编译或测试需求。

固定资源分配可能导致一个资源池未被充分利用，而另一个形成队列。独立资源池让运营者能够调整这种不平衡。收益取决于其软件能否识别瓶颈，并及时配置有用的容量。

这正是调度——将工作分配给可用资源——变得关键的地方。应用需要决定工具在哪里运行、接收哪些数据，以及何时返回结果。如果工作无法高效抵达额外处理器，增加处理器仍是不完整的答案。

数据放置让这一决策更加复杂。工作节点需要访问文件、依赖项、凭据和相关应用状态。将执行工作与模型服务基础设施分离，会形成另一条需要由软件管理的边界。

这条边界本身并非缺点。它可以支持更清晰的资源分配和隔离。不过，买方在评估独立资源池的益处时，应将其运营影响纳入考量。

一种有用的评估方式是跟踪一项代表性任务从提交到完成的全过程，记录生成模型输出、等待工具、运行代码、检索信息及重试失败步骤所花费的时间。目标是识别额外容量会在哪些环节改变结果。

成功完成同样重要。如果更快的执行带来更多失败任务，或需要额外尝试，其价值就会降低。有意义的比较应保持任务和验收标准不变，同时考察所消耗的资源。

这些是评估原则，而非公告中已发布的结果。它们说明什么样的证据能够支持两家公司关于效率的论点。此次发布确立了可用的架构；客户测量结果必须证明其对特定应用的价值。

当工作负载随时间变化时，运营挑战会进一步增加。如今主要回答问题的服务，可能在产品更新后执行更多操作。只要应用能提供运营者所需的信息，独立扩展便能为应对变化留出空间。

这让 CPU 产品不只是 GPU 发布的附属品。它为 NVIDIA 和 Oracle 参与应用基础设施提供了另一个切入点。客户能否从中受益，取决于该基础设施与其实际执行工作的匹配程度。

云计算竞争对手正围绕完整的 AI 应用展开竞争

Oracle 的公告属于一场围绕协同系统的竞争，其中包括支持 AI 模型的通用计算能力。

Google Cloud 提供了一个有价值的对照案例，因为它明确将加速器和 CPU 的发展联系起来。其 Ironwood 和 Axion 公告讨论了智能体工作流所需的协同。Ironwood 是 Google 专为机器学习打造的 TPU，而 Axion 则支持通用计算。

其相关性在于架构层面。Google 将模型加速与围绕模型所需的应用服务、数据准备及其他工作一并描述。Oracle 和 NVIDIA 现在正通过 Rubin 系统以及可独立获取的 Vera CPU 强调类似的需求。

这并不意味着产品或性能具有同等水平。这些平台在处理器、软件环境、服务供给和部署安排方面各不相同。不过，它们的公告都指向一个共同的采购问题：完整系统对应用的支持能力究竟如何？

对 Oracle 而言，独立的 Vera CPU 将讨论范围拓展到 NVIDIA 加速器的获取之外。该公司可以推介用于模型服务及其周边执行工作的资源。这让客户在决定智能体应在何处运行时，多了一种可评估的配置。

对 NVIDIA 而言，该公告将其 CPU 的商业重要性扩展到集成机架内部角色之外。如果客户将 Vera 用于独立的执行服务，NVIDIA 便能参与其更大范围的计算架构。

这一机会不应被误解为普遍适用的迁移理由。现有应用存在既定依赖和运维实践。团队必须权衡新配置与采用和维护它所需的工作。

竞争压力同样延伸至传统服务器部署。考虑使用 Vera 的买家会希望将其与当前运行其工具和应用服务的系统进行比较。熟悉的基础设施提供了实用基线，因为团队了解它在自身工作负载下的表现。

因此，最有力的比较应从客户的现有应用出发。它需要考察改变执行平台是否能改善任务完成情况、响应速度、资源消耗或运行可靠性。组件层面的优势只覆盖这一决策的一部分。

软件连续性同样重要。拥有成熟模型服务环境的公司，会考虑新配置如何融入其部署和支持流程。忽略这些流程的硬件评估，会低估采用所需的工作量。

这正是竞争叙事应与缺乏依据的“赢家”论断保持分离的原因。Oracle 的发布扩展了其可提供的选择。Google 的 CPU 和加速器战略提供了相关背景。两项公告都无法证明哪个平台能为每一种智能体工作负载带来最佳结果。

更广泛的变化在于供应商要求客户评估的内容。加速器规格仍然重要，但配套的执行环境正越来越多地进入同一场讨论。基础设施提供商必须说明其组件如何在整个任务过程中协同工作。

对于关注 OCI 上 NVIDIA Vera Rubin 的读者而言，这是最有用的竞争框架。头条所涉及的是更大规模的基础设施投入。采购决策所关心的则是，特定的服务组合是否能比现有方案更有效地支持应用。

可用性和处理器数量仍留下重要问题

该公告确立了产品和计划，但并未证明客户生产率会普遍提升。

第一个不确定性涉及正式发布与实际可用性之间的联系。公开发布并未明确每位客户的资源配额、部署地点或交付时间表。买家需要这些细节，才能将公告转化为实施计划。

第二个问题涉及规划中的多吉瓦规模。公告描述了扩张，但仅凭标题无法提供完整的交付时间表。随着更多信息披露，读者应区分计划规模与实际运营容量。

第三个问题涉及应用结果。大规模 CPU 部署和新一代 GPU 本身，并不能量化智能体完成有用工作会快多少。这需要明确的工作负载，以及与清晰基准的比较。

Oracle 的发布内容包含性能声明，但除非有可独立评估的方法论支持，否则这些仍只是公司主张。买家应审视任何宣传中的改进背后所采用的配置、软件、工作负载和测量边界。

这一边界对智能体尤其重要。衡量处理器的执行速度，不同于衡量包含模型调用和外部服务的完整任务。某一阶段的改进，并不能证明整个工作流也有同等改进。

资源利用率与客户价值之间也存在区别。繁忙的处理器可能在处理有成效的工作、重试，或不必要的计算。只有当高活跃度有助于产出被接受的结果时，它才具有意义。

反过来，一些闲置容量也服务于运维目标。应用可能需要保留余量，以应对突发流量、故障或响应时间要求。评估应区分可避免的浪费与为履行服务承诺而保留的容量。

独立扩展也将决策转移给应用运营方。团队必须确定何时增加容量、保留多少容量，以及在依赖项故障时如何应对。灵活性很有价值，但它也引入了需要测量和运维判断的选择。

安全性增加了另一层考量。执行生成代码的智能体需要对其环境和访问权限进行控制。沙箱这一隔离执行环境可限制代码能够触及的范围，但其有效性取决于周边实现。

客户应将执行权限、数据处理和故障隔离与吞吐量一并评估。一个访问权限不当却速度更快的工作进程，并不会造就更好的生产系统。当智能体检索专有信息或通过已连接的企业工具执行操作时，这一点尤为重要。

迁移则是另一个独立问题。将应用迁移到不同的 CPU 环境，需要检查软件依赖和部署兼容性。相关工作量取决于应用本身，因此一项广泛发布的公告无法为每位客户解决这一问题。

这些不确定性并不否定此次发布。它们指出了准确判断该发布所需的证据。两家公司宣布了一项具有明确架构逻辑的基础设施选择；其带来的运营收益仍取决于工作负载。

因此，谨慎的解读应当具体明确。独立的 CPU 和 GPU 资源为客户提供了另一种应对需求不匹配的方式。该选择是否能减少浪费或改善响应速度，必须通过应用层面的结果来证实。

关注容量获取、客户测量结果和执行软件

接下来的证据应将已宣布的基础设施与可获得的容量及已完成的客户工作负载联系起来。

第一个信号是更具体的访问信息。在未来数月，客户应关注受支持的配置、部署地点、分配条款和扩张里程碑。这些细节将说明已宣布的产品如何转化为实际可用的容量。

更具体的交付信息将增强这样一种判断：扩张能够支持客户的近期规划。如果持续强调总体规模，却没有相应的访问细节，故事的这一部分仍将缺少答案。

这一信号对 GPU 系统和独立 CPU 分别都很重要。采用其中一种的客户，不一定与采用另一种的客户有相同需求或时间表。单独的可用性信息将使独立扩展的主张更易于评估。

第二个信号是客户对完整工作流的测量。有用的证据应说明应用、此前的配置、变更后的资源以及验收标准，还应解释任务完成情况和资源消耗发生了怎样的变化。

例如，对编程智能体的评估应包含执行和测试，而不能止步于模型生成。检索应用应包括对其底层信息的访问。当比较遵循用户任务并跨越这些边界时，结论会更有说服力。

如果证据表明额外的 Vera 容量消除了可测量的执行瓶颈，将支持此次发布的核心论点。如果结果显示大部分延迟发生在其他环节，则会缩小相关使用场景。无论哪种结果，都将帮助买家作出更明智的决策。

第三个信号是让独立资源池更易运营的生产软件。关注应用如何处理工作进程分配、数据访问、执行状态和故障。这些能力决定独立资源能否作为协调服务运行。

这一信号值得关注，因为硬件选项不会自动形成可用的应用架构。运营方需要足够的可见性来理解工作在哪些环节等待，也需要足够的控制能力来应对。更好的协调将强化效率论据，而无需每个组件都实现同等提升。

这些信号共同提供了一种扎实的方式，用于持续关注 OCI 上的 NVIDIA Vera Rubin。容量披露关乎交付。客户测量关乎价值。执行软件则关乎连接可用组件所需的实际工作。

对开发者而言，该公告是审视自身智能体工作流将时间花在哪里的理由。对企业买家而言，这是要求获得应用层面证据的理由。对用户而言，相关结果仍是能够可靠完成有用工作的服务。

在投入新的基础设施配置之前，应让一个具有代表性的任务贯穿整个系统，并识别其真正的约束。要求供应商区分可用容量与规划扩张，以及组件主张与实测应用结果。在评估中纳入执行、检索、故障和恢复。比较不同方案时，保持工作负载和验收标准的一致性。这种方法能对 OCI 上的 NVIDIA Vera Rubin 作出公正评估，同时让采购决策始终围绕客户需要完成的工作。额外的 CPU 或 GPU 容量会改善应用的哪个阶段，什么测量能够证明这种改善？