On October 27, Oracle and NVIDIA announced general availability of Vera Rubin NVL72 and standalone Vera CPU resources on Oracle Cloud Infrastructure. The companies also described expansion toward multi-gigawatt infrastructure and a future HGX Rubin NVL8 configuration. Availability of the announced services and the planned expansion need to be read separately.
Two kinds of computing work
The joint release specifies 72 GPUs connected through NVLink in an NVL72 rack. The smaller eight-GPU NVL8 configuration is a plan, rather than the same already available offering. These are supplier-provided details; SIExpo has not rented capacity or checked quotas and performance for a particular customer.
The useful architectural idea is the distinction between model computation and the work surrounding it. Generating an answer may be only one part of an agent task. An application can then wait for a tool, execute a test or process retrieved data. Our interpretation is that an end-to-end evaluation should include these stages, rather than reducing the task to token generation speed. Different stages can become limiting factors at different workloads.
Consider a hypothetical software maintenance assistant: it reads a request, proposes a change, starts an isolated check and returns the result for approval. Accelerating only the model response will not remove a slow test. Conversely, adding CPU capacity will not necessarily solve a bottleneck inside inference itself. This is our explanatory example, not a measured implementation running on OCI. Its purpose is to clarify which component a proposed infrastructure change would actually improve.
The contribution of the software layer
A separate Oracle technical blog describes NVIDIA Dynamo for disaggregated inference on Oracle Kubernetes Engine and cuVS for building vector indexes. Oracle also outlines optimization and business application integrations. This adds specific software context to the hardware announcement, but comes from a participant in the same collaboration and is not an independent assessment.
For a team comparing options, relationships between resources matter more than a list of product names. Retrieval might finish promptly while an application waits for an execution environment to become available. A useful workload profile would track incoming tasks, queueing, model work, tools and final confirmation. We propose this as an evaluation method, without attributing untested shortcomings to the new infrastructure. Measuring only one segment could conceal where a user's actual waiting time accumulates.
What the announcement does not establish
Multi-gigawatt scale describes an infrastructure direction, rather than the useful work completed by a particular application. It cannot automatically determine the cost of one successfully resolved request. Similarly, vendor efficiency claims cannot replace comparisons with matching models, answer quality, input lengths and load. Neither aggregate capacity nor hardware generation alone resolves those operational questions.
Our assessment is that prospective customers should establish the exact service, region, quota and agreed parameters before measuring their own scenario. A practical comparison would count completed, verified tasks, including unsuccessful attempts and idle time. These are suggested checks, rather than tests we have performed. The development is a broader choice of CPU and GPU platforms on OCI. Whether it produces lower costs and more predictable operation for an individual team remains a question for workload-specific validation.
*AI illustration: a conceptual editorial image, not a documentary photograph or an actual product screen.*
*Editorial verification: 2026-10-28T07:29:45.233660+00:00.*
