Summary

  • Oracle documents a cluster network fabric that can address up to 131,072 GPUs, but the same documentation family says instances are provisioned "subject to host capacity for nodes in the cluster's RDMA network" — the fabric's addressable size and the size a customer can actually schedule are different numbers.
  • The published maximum has moved by GPU generation: an Oracle solution playbook describes 4,096 nodes at 8 GPUs each (32,768 GPUs), while the zettascale design describes a three-tier Clos topology supporting 131,072 GPUs with 400 Gbps nonblocking connectivity per GPU.
  • Latency is tiered rather than flat: Oracle's zettascale disclosure puts the first tier at up to 256 GPUs and 2 µs, the second at up to 2,048 GPUs and 5 µs, and the third at 131,072 GPUs and 8 µs.
  • Oracle reported 850 megawatts of additional datacenter capacity delivered to customers and more than 300,000 GPUs shipped in the quarter it labels Q1 FY27, alongside $664 billion of remaining performance obligations — aggregate figures that say nothing about any single cluster's populated size.

The cluster is a network before it is a number

Oracle Cloud Infrastructure sells large-scale AI capacity as a cluster network: a group of identical bare-metal HPC or GPU instances placed in close physical proximity and joined by a remote direct memory access (RDMA) fabric. Oracle's documentation describes the inter-node RDMA network as providing latency "as low as single-digit microseconds, comparable to on-premises HPC clusters."

That framing matters because it locates the product's real constraint. A GPU cluster is not limited by how many accelerators a vendor has ordered; it is limited by how many of those accelerators can be wired into one low-latency domain with the switches, cabling and host capacity available on the day.

Oracle's published maximum sits on the network side. In its technical description of the zettascale cluster network, Oracle states the fabric "delivers 52 Pbps of nonblocking network bandwidth at 400 Gbps per port" and "is a three-tier Clos topology that supports up to 131,072 GPUs with 400 Gbps nonblocking connectivity to each GPU."

Why "supports up to" is not "you can order it"

The operational documentation is more cautious. In the page describing cluster-network creation, Oracle writes that instances "are provisioned until the required number of instances in the pool are launched, subject to the host capacity for nodes in the cluster's RDMA network." The same page instructs customers to "use the CreateComputeCapacityReport operation" to "determine whether capacity is available for a specific shape before you create a cluster network." The resize page repeats the same constraint.

Three practical consequences follow.

First, the deployment is capacity-gated, not catalogue-gated. A shape can exist in the catalogue and still not be available at the size requested in a given availability domain.

Second, the tenancy defaults are small. Oracle's limits table lists cluster networks at 15 per tenancy for Oracle Universal Credits, with "Contact Us" for pay-as-you-go and trial accounts, and instances per instance pool at 500 region-scoped. Large multi-thousand-node clusters are not a default entitlement; they are a limit increase.

Third, the fabric itself is tiered. Oracle's zettascale description gives stepwise latency budgets: the first tier of switches serves up to 256 GPUs with up to 2 µs unidirectional latency, the second up to 2,048 GPUs with up to 5 µs, and the third up to 131,072 GPUs with up to 8 µs. A job that fits inside one tier behaves differently from one that spans all three.

The ceiling moves with the GPU generation

The maximum cluster has never been a fixed property of OCI. An Oracle solution playbook for deploying a bare-metal GPU cluster frames the ceiling in A100-class terms: "OCI enables the customer to cluster up 4096 Bare Metal nodes, each with 8 GPUs, up to 32768 GPUs," with "RDMA, running over converged Ethernet (RoCE) with less than 10 microsecond latency between nodes."

The zettascale design moves the number to 131,072 GPUs for newer accelerator classes. Both figures are documented; neither is a promise that any customer can bring that many GPUs into one schedulable pool on demand. Trade press covering Oracle's 2024 zettascale announcement immediately questioned whether all 131,072 GPUs would be available at launch, and Oracle has not published a per-cluster delivered maximum.

Aggregate delivery is not cluster size

Oracle's most recent quarterly disclosure gives the aggregate picture. In the quarter it calls Q1 FY27, the company reported 850 megawatts of additional datacenter capacity delivered to customers, cloud infrastructure revenue up 121% year over year, and $664 billion of remaining performance obligations, with more than 300,000 GPUs delivered to AI Cloud customers since the prior quarter and GPU utilisation at 97.9%.

Those are real, dated, company-reported numbers. They are also answerable to a different question than the one a capacity planner asks. 850 megawatts delivered across a fleet, and 300,000 GPUs shipped across customers, do not establish that any single customer holds a fully populated 131,072-GPU cluster. Oracle has not said so, and the operational documentation makes clear it is the host capacity in a specific RDMA network, not the aggregate fleet, that decides what a tenant can schedule.

What to watch

The testable signal is not a larger announced number. It is whether Oracle publishes a per-cluster deployed maximum — the largest GPU count it will commit to provisioning in one cluster network with a stated availability domain — and whether that figure tracks the 131,072-GPU fabric specification or the far smaller service-limit defaults. Until then, treat the zettascale figure as an interconnect design ceiling and the delivered figures as fleet-level accounting, and size training plans against the capacity report, not the announcement.

Sources