GPU Capacity Planning on OCI: Quotas and Reservations

GPU capacity planning is the unglamorous discipline that decides whether an AI program ships on schedule. It sits awkwardly between procurement, architecture, and finance, which is why it is so often nobody's job until it becomes everybody's emergency. This article, part of our complete guide to AI on OCI, lays out the mechanics OCI gives you and the sequence in which to use them. If you are still choosing which accelerator you need, start with our guide to OCI GPU shapes and come back; capacity planning assumes you know what you are planning for.

Why GPU capacity does not behave like compute capacity

Ordinary compute on OCI is effectively infinite at enterprise scale. You raise a service limit, you launch instances, and the only constraint that matters is your budget. GPU capacity breaks every one of those assumptions. The hardware is expensive, scarce, and allocated in advance; clouds order accelerators quarters ahead of installation, and the install base in any one region is finite in a way that x86 capacity has not been for a decade. Demand is also lumpier. Training jobs want hundreds or thousands of GPUs at once, in one place, on one network fabric, which means a region can be simultaneously full for a 512 GPU cluster request and comfortably empty for single instance inference.

The practical consequence is that GPU access on OCI, as on every cloud, is part self service and part conversation. Small inference footprints can usually be launched on demand. Serious training capacity, particularly the RDMA connected clusters described in our article on building AI training clusters on OCI, is arranged with Oracle ahead of time, with paperwork and lead times attached. Planning is the difference between choosing your terms and accepting whatever is left.

Limits, quotas, and availability: three different things

OCI's vocabulary here trips up even experienced teams, because three separate mechanisms gate whether your launch request succeeds, and only one of them is visible in an error message at a time.

Service limits

Service limits are tenancy level caps set by Oracle: how many cores or instances of a given shape your tenancy may use per region or availability domain. New tenancies start with GPU limits at or near zero, deliberately. A limit increase is a request to Oracle, filed through the console, and for high demand shapes it is reviewed rather than rubber stamped. A granted limit is permission, not inventory. This is the single most misunderstood fact in GPU planning: a tenancy with a limit of 64 H100 GPUs holds no claim whatsoever on 64 physical H100s.

Compartment quotas

Quotas are caps you set on yourself, written as policy statements that restrict what each compartment may consume. They are the rationing tool. A sensible estate gives the research compartment generous GPU quota, gives the experimentation sandbox a small one, and gives everything else zero, so a misconfigured pipeline cannot quietly launch eight accelerated instances in a compartment that was never meant to hold any.

Physical availability

Availability is whether the hardware exists, unclaimed, in the availability domain you are targeting at the moment you launch. It fluctuates with other tenants' behavior and is the constraint you cannot see in advance. An out of capacity error with a granted limit and clean quota means exactly this: the machine you want is currently someone else's.

The four ways to acquire GPU capacity on OCI

The single most common planning error is running a production inference service on the on demand path because it worked during the pilot. It works until the day the region tightens, an instance is lost to maintenance, and the relaunch fails on capacity. Anything customer facing belongs on reserved capacity, full stop. The second most common error is the mirror image: reserving a large block for a training program that slips a quarter, and paying for idle accelerators while the data pipeline is still being argued about.

Capacity reservations in practice

A capacity reservation on OCI pre claims instance capacity in a named availability domain. While unused it bills at a reduced rate, and instances launched against it bill normally. Three practices make reservations earn their cost. First, size them to the steady state, not the peak; let genuinely rare bursts take their chances on demand or, better, queue. Second, pin them deliberately. A reservation is availability domain specific, so it belongs in the same AD as the storage and networking it will serve. Third, review them monthly. Reservations are the easiest line item to set and forget, and an unused one is pure waste of the kind our article on controlling AI workload costs on OCI is dedicated to hunting down.

Reservations also have a disaster recovery role that is easy to overlook. If your inference tier must survive an availability domain failure, the standby AD needs reserved GPU capacity too, because the moment one AD fails is precisely the moment everyone else is trying to relaunch into the survivors. Unreserved DR for GPU workloads is a plan that assumes the emergency will be polite.

Regional reality: check before you commit

Not every GPU shape exists in every OCI region, and the newest accelerators arrive in a handful of regions first. This has architectural consequences that are cheap to handle early and expensive late. If your data residency requirements pin you to one country, confirm the shapes you need actually exist there before the landing zone is designed, not after. If your training data must stay in region but the GPUs are elsewhere, you need either a different region strategy or an explicit decision about moving training data across boundaries, which security and legal must sign, a topic covered in our article on governing AI workloads on OCI. The buyers with the strongest position treat region selection and capacity as one combined question, asked once, in writing, with Oracle's account team on record about what will be available where and when.

The capacity planning framework

The contract angle

For anything beyond modest scale, GPU capacity and the commercial agreement are the same negotiation. Oracle sells committed GPU blocks against Universal Credits, and the leverage points are familiar from every other credits conversation: term length, ramp schedule, and the gap between list and negotiated rates. What is specific to GPUs is capacity language. A spend commitment that does not name shapes, counts, regions, and delivery dates is a commitment on your side only. Buyers who sign large AI commitments should insist the capacity schedule live in the contract with remedies attached, and should size the commitment against the honest forecast from the framework above rather than the vendor's enthusiasm. The wider negotiation playbook, including what happens to oversized commitments, is covered across our pricing cluster, and the strategic context for Oracle's GPU push is in our article on what the NVIDIA partnership means for buyers.

The independent view

GPU capacity planning rewards the boring virtues: forecasting honestly, filing paperwork early, reserving only what will run, and writing capacity into contracts instead of trusting the roadmap slide. None of it is difficult; all of it is easy to skip until the quarter it costs you a launch. We run this exercise as part of our OCI consulting practice, on a fixed Project fee, and the deliverable is the unglamorous thing that matters: a capacity schedule the engineering plan can actually stand on, sized against workloads rather than wishes. Where an existing commitment is already oversized, our Optimization model applies, paid only on verified savings.