NVIDIA and Oracle Vera Rubin: What Multi-Gigawatt GPU Capacity Means

On 27 October 2026 NVIDIA and Oracle announced plans to grow Oracle Cloud Infrastructure (OCI) Superclusters with Vera Rubin NVL72 systems to multi-gigawatt scale. The release gives no gigawatt number, no price and no dates for the expansion. It confirms more GPU supply is coming. It does not tell you what you will pay for inference in 2027.

This post separates what the release states from what NVIDIA claims about the hardware, then gives our own, labelled inference about prices and a buying checklist. Nothing here is a price forecast.

What did NVIDIA and Oracle announce?

We read NVIDIA's press release on its newsroom on 9 November 2026. Oracle's own announcement page returned an access error to our fetcher, so everything below comes from NVIDIA's copy.

What the release states:

• Oracle and NVIDIA plan to expand OCI Superclusters "with NVIDIA Vera Rubin NVL72 systems to multi-gigawatt scale", to serve training, inference and agentic AI.
• Vera Rubin NVL72 systems and standalone Vera CPUs are now available on OCI.
• A planned HGX Rubin NVL8 server will have eight Rubin GPUs linked by NVLink on an x86 platform, with two 64-core Intel Xeon 6 CPUs, 4 TB of DDR5 memory and 6.4 Tbps of RDMA networking.
• The Superclusters are described as having "gigawatt-class power and cooling". The release does not say how many gigawatts.
• NVIDIA reports that OpenAI trained and served GPT-6 Astra in Abilene on an OCI Supercluster with more than 100,000 Blackwell GPUs. An OpenAI executive is quoted as saying the company is bringing Vera into production on OCI.

What the release does not state: a dollar figure, a date for the multi-gigawatt build, a price list, or any change in what customers pay. The expansion and the NVL8 server are plans. The NVL72 systems and Vera CPUs are described as available now.

A "$40 billion per gigawatt" figure also circulated in press coverage. It is not in the release. The transcript of NVIDIA's 26 August 2026 earnings call, hosted by NVIDIA, gives it as NVIDIA's revenue opportunity per gigawatt for Vera Rubin. It is a vendor figure about compute investment, not an OCI rental price or the value of this expansion.

What is NVIDIA Vera Rubin?

Vera Rubin is NVIDIA's platform after Blackwell. The two chips are the Vera CPU and the Rubin GPU. NVIDIA's product page for Vera Rubin NVL72, read on 9 November 2026, lists these specifications for one rack:

For comparison, NVIDIA's page for the DGX B300 lists 2.1 TB of GPU memory for an eight-GPU system. That is our basis for a rough sense of scale: one NVL72 rack holds about ten times that (our arithmetic: 20.7 divided by 2.1, about 9.9). The two systems are different shapes, so use that as scale only.

NVIDIA makes cost claims on the same page. It says Vera Rubin NVL72 delivers "one-tenth the cost per million tokens compared to NVIDIA GB200 NVL72", and "up to 10x more tokens per megawatt". Both are vendor claims. NVIDIA's footnote says the comparisons use the Kimi-K2-Thinking model at 32K input and 8K output, and that "LLM inference performance subject to change". That is one model at one shape of workload. We have not seen an independent test.

Our existing post on the March launch, NVIDIA GTC 2026: Vera Rubin and the new AI infrastructure era, covers the platform announcement. This post is about supply.

What does multi-gigawatt AI capacity mean?

A gigawatt is a unit of power, not of compute. Data centre size is quoted in power because power, cooling and grid connection are the scarce inputs. "Multi-gigawatt" means several gigawatts of electrical capacity across the Superclusters. The release gives no count, so we cannot say how many GPUs that is.

We can show the arithmetic for scale, with an assumption stated. Suppose one NVL72 rack draws 100 kW. That is a round number we chose for illustration, not an NVIDIA figure, and the release states none. One gigawatt is 1,000,000 kW, so 1,000,000 divided by 100 is 10,000 racks, or 720,000 GPUs (10,000 x 72). That ignores cooling, networking and other overhead, which would cut the count, and a different rack draw changes it in proportion. Our arithmetic. The point is the order of magnitude: hundreds of thousands of GPUs per gigawatt, on this assumption.

Two things follow. The release says OCI's network "scales across hundreds of thousands of GPUs", which is consistent with that order of magnitude. And capacity at this scale is not a cheap addition. Building it takes years of power, land and equipment. The release does not establish how much additional capacity will be rentable by January 2027, so ask providers for delivery commitments.

Will GPU prices fall in 2027?

We do not know, and neither does anyone else yet. What follows is our inference, with reasons for and against.

Reasons prices could fall.

• More supply in a market that has been short of it. Gigawatt-class build-outs add capacity.
• NVIDIA's claim of a much lower cost per million tokens on the new platform. If even part of it holds on your workload, providers running it have room to cut prices. This is a vendor claim for one model.
• Competition between clouds. Oracle, the other hyperscalers and smaller GPU clouds all compete for the same buyers.
• Our earlier analysis of why frontier prices fell in September found that efficiency gains show up in prices, not only in margins. Our working theory there is unconfirmed.

Reasons they might not.

• Demand growth. Agentic workloads use many times the tokens of chat. If demand grows as fast as supply, prices hold.
• Power and lead times. The scarce input is electricity and finished data centre space, not chips alone. Plans in a press release do not remove that limit.
• Mixed fleets. New hardware arrives alongside older GPUs, and providers price to recover investment.
• Pricing is set per provider and per contract. A cheaper cost per token at the chip does not pass through automatically.

A fair test of any future price cut is cost per finished task, not per token or per GPU-hour. A cheaper GPU hour that needs more hours per task is no saving. If a provider announces a cut, rerun your own evaluation set on the same workload before and after, record tokens per task, and compare the totals. That is the number your finance team will see.

Our reading: expect the per-token price of serving large models to keep trending down over the medium term, but do not budget on a specific cut by a specific date. A rental price per GPU-hour and an API price per million tokens are different things, and they can move in different directions. We make no price prediction.

Should you reserve GPU capacity or buy on demand?

That depends on how steady your load is. The break-even is simple, and you can compute it from your own quotes.

Let R be the reserved price per GPU-hour, committed for the full term. Let D be the on-demand price per GPU-hour. If you use a fraction u of the reserved hours, the on-demand equivalent costs u x D per reserved hour. Reserving wins when R is less than u x D, which means when u is greater than R divided by D.

A worked example with assumptions stated, all of them illustrative and none a quote from Oracle or anyone else. Suppose R is $2.00 and D is $3.00. The break-even utilisation is 2.00 divided by 3.00, which is 67%. Our arithmetic. If you will keep reserved GPUs busy more than about two-thirds of the time, reserve. Below that, buy on demand. A 40% discount for a commitment sounds large, and it still loses if you use the capacity half the time.

When does capacity planning matter more than price? When availability is the constraint. If your workload needs a large block of new-generation GPUs at a given date, the question is whether any provider can deliver them then, not what they cost. For that case, talk to providers early, ask for delivery dates in writing, and keep a second source.

Our post on why the cluster is rarely the bottleneck is a useful check before you commit. Many teams find that utilisation and serving configuration, not raw GPU count, set their cost.

What does the Vera CPU add for agent workloads?

The release also brings standalone Vera CPUs to OCI. That is easy to skip, and it matters for agents. NVIDIA says the CPU is aimed at the CPU-heavy work agents do, such as running tools, testing code and fetching data, and that it pairs "high single-thread performance with memory bandwidth". It also says customers can scale CPU and GPU resources separately, and that OpenAI had early access.

Our inference: an agent that spends most of its time waiting on tools and tests does not need a GPU for those steps. Separating the two lets you pay for GPU time only while a model is generating. NVIDIA has published no price for this, and we have seen no independent test. The split is a design option, not a saving you can bank.

How do you avoid single-cloud lock-in?

New capacity on one cloud is attractive, and it is also a way to end up tied to that cloud. Five habits keep you portable.

1. Serve behind an OpenAI-compatible endpoint. Your applications then call one interface, whichever cloud runs the model.
2. Ship containers, not instance recipes. Container images improve portability, but verify the target host's CPU architecture, NVIDIA driver, container runtime and required GPU features before moving a workload.
3. Keep model IDs behind an alias. Change the alias, not the application code, when the provider changes.
4. Avoid cloud-specific storage and networking features for core logic. Or wrap them.
5. Keep an evaluation set. You can only move confidently if you can show the new setup gives equal answers.

The cases where open-weight models help are covered in our look at how Revolut cut AI coding costs with a self-hosted model, which also shows why steady utilisation decides whether owning capacity pays. For very large models the memory arithmetic comes first, and our trillion-parameter GPU requirements guide sets it out.

What should buyers do now?

A short checklist.

• Do not wait for lower prices to act. The release gives no date and no price. Plan on today's rates.
• Measure utilisation and tokens per task. These decide whether reserved capacity pays.
• Ask providers about delivery, not only price. Which GPU generation, in which region, from what date.
• Test portability once. Move one workload to a second provider and time it.
• Treat vendor cost claims as hypotheses. Run your own workload before you rely on a one-tenth figure.

Where Swfte sits

Supply growth helps you most if you can move to cheaper capacity when it appears. That is a routing and portability problem.

Swfte Connect offers one API across many providers. You can bring your own keys from any provider, or use Swfte's pooled access. When a provider is out of funds, rate-limited or down, Connect can fall back to another provider in the chain. When a workspace reaches a usage cap, Connect can move its requests to a cheaper model. These are Built. Because applications call one API, changing the provider behind a model is a configuration decision, not a rewrite.

The enterprise deployment generator produces Terraform, Helm and Docker Compose bundles. Generating one requires a licence key, and dedicated deployment is available on request. Built: Connect supports BYOK with an optional base URL, so a custom OpenAI-compatible endpoint, such as your own vLLM server on any cloud, can sit behind its routing, failover, usage caps, cost tracking and audit event stream. Compatibility with your serving setup still needs testing. We do not publish a price or a capacity figure, and we make no claim about running on Vera Rubin hardware.

The decision rule: reserve only what you can keep busy, keep serving portable, and treat the multi-gigawatt headline as a reason to plan, not a reason to wait.

---

Related: NVIDIA GTC 2026: Vera Rubin and the new AI infrastructure era, Why frontier AI got cheaper in September 2026, Why the cluster is rarely the bottleneck, How Revolut cut AI coding costs, GPU requirements for trillion-parameter open models.

Sources: NVIDIA Newsroom, NVIDIA and Oracle expand NVIDIA Vera Rubin to multi-gigawatt scale (27 October 2026) · NVIDIA, Vera Rubin NVL72 · NVIDIA, Q2 FY2027 earnings call transcript (26 August 2026) · NVIDIA, DGX B300 · accessed 9 November 2026.

Method note: we read the NVIDIA pages above on 9 November 2026. Oracle's own announcement page could not be read, so we rely on NVIDIA's copy. Cost and throughput figures for Vera Rubin are NVIDIA's own claims and are not independently reproduced. The rack power, break-even and price figures are illustrative assumptions and our arithmetic, not quotes or forecasts.