Google TPUs on OCI: Capacity, Scheduling, and Abstraction Before 2027

Introduction

Oracle plans to make Google TPUs available on OCI starting in 2027, according to a DataCenterNews Asia Pacific report published on 28 October 2026 — and that one sentence is the entire confirmed claim. There is no published pricing, no named TPU generation, no region list, and no statement about whether a buyer reserves capacity or requests it on demand.

This post works through what to do with that thin fact: how a second venue for TPU-shaped capacity changes accelerator capacity planning, why TPU slices schedule differently from GPUs, where an abstraction layer between accelerator vendors actually holds and where it breaks, and which layer is cheap enough to standardize before any of it ships.

The chip is the least interesting part. TPU generations come and go, and any given one is roughly the same category of object as the GPU your team already struggles to schedule. What is new is that a second venue may exist where a TPU-shaped allocation can be negotiated — and that forces a question most teams have deferred: does your job spec name an accelerator, or does it name a shape?

My position up front: architect for abstraction at the orchestration layer now, keep the compiler layer vendor-specific, and treat the 2027 date as a reason to avoid foreclosing an option — not as a reason to commit budget. If you take one action from this post, make it a job spec that can name a second accelerator class without a rewrite.

What the Oracle and Google TPU Report Actually Says, and What It Leaves Open

The One Confirmed Claim: Google TPUs on OCI From 2027

The sourced statement is narrow, and it should be quoted narrowly: Oracle plans to offer Google TPUs on OCI Cloud from 2027. The report frames it as putting Google's AI accelerators inside a rival cloud's infrastructure. That is it.

Everything else a procurement or platform team would need is absent from the public record as summarized by that report:

Open Questions: Topology, Regions, and Pricing Are All Unstated

The last two rows matter more than they look. A TPU pod is not a drop-in card; it is a topology-bound unit of allocation whose economics depend on the fabric between the chips. If a training cluster runs on OCI compute nodes and its accelerators sit behind a cross-provider interconnect, then every collective operation crosses a boundary that was designed for something else. If the TPUs instead sit in Oracle racks with the same intra-pod fabric Google uses, the story is closer to a normal bare-metal accelerator offering.

Those are different products with different scheduling semantics, and the source does not distinguish them. Hold both models in your head, and design for the one you can actually validate.

Why the 2027 Date Is the Load-Bearing Detail

A two-year horizon means no procurement decision made this quarter should depend on this announcement. Anyone signing a multi-year reservation on the strength of a roadmap item is taking delivery risk on a product whose region list does not exist.

What a two-year horizon does justify is cheaper work: removing hardcoded assumptions from job specs, keeping accelerator selection behind a label or a flavor name rather than a literal resource key, and refusing to let a single vendor's node labels leak into application manifests. That work is measured in days. Retrofitting it into a platform that already assumed one accelerator vendor is measured in quarters.

Why TPU Access on OCI Is a Capacity Story, Not a Chip Story

Accelerators, Not GPU-Hours, Are the Scarce Input

The binding constraint on most AI workloads stopped being GPU-hours around the time it became queue-weeks. What a buyer actually negotiates today is an allocation shape: how many contiguous accelerators, connected how, admitted under what preemption policy, for how long.

Under that framing, a second supplier of TPU-shaped capacity matters even if you never use it. It changes the structure of the conversation, because it introduces a complement rather than a substitute. A team that owns a multi-year GPU reservation on one cloud and can genuinely burst training to a TPU pool on another has a different negotiating position than a team that has to size its reservation for its worst week.

What a Rival Cloud Selling TPUs Implies About Capacity

This part is inference, and I want to mark it clearly: the report does not state a motivation.

Inference (not reported fact): the most plausible commercial motivation for Oracle is monetizing accelerator capacity that would otherwise sit idle between committed reservations, and the most plausible motivation for Google is distribution — placing TPU access in accounts that will never migrate their primary cloud. If that reading is right, then the TPU offering will be structured as a burst tier: cheaper per chip-hour than a reservation, preemptible, and quota-limited.

What would falsify it: a published commitment model with multi-year terms and a stated discount curve. If Oracle starts selling reserved TPU pods on three-year terms, this is not a burst play and the capacity planning in this post is aimed at the wrong shape.

The Procurement Consequence: Optionality Changes the Negotiation

Here is the asymmetry worth internalizing. A credible alternate venue changes what you can ask for even if the alternate fails to materialize. If your architecture can name a second accelerator class without a rewrite, then a capacity negotiation becomes a comparison. If it cannot, every conversation is a renewal.

That is the argument for doing the abstraction work early. You are not buying optionality on Oracle's roadmap. You are buying optionality on your own ability to say no.

TPU Scheduling Does Not Have the Same Shape as GPU Scheduling

Teams that have only ever scheduled nvidia.com/gpu get hurt here. The Kubernetes resource model makes an accelerator look like a scalar with a count. It is not.

The Allocation Unit Is a Topology, Not a Device

TPU work is typically requested as a slice — a pod or pod-slice with a declared interconnect geometry such as 2x2x2 or 4x4x4. The geometry determines the torus dimensions that the collectives run over, and the compiler schedules communication against that shape.

The consequence: 63 of 64 chips is not 98% of a slice. It is a scheduler state in which a job can be admitted but cannot complete, because the collective needs every rank to participate. A job either gets the whole shape or gets nothing useful.

Gang Scheduling and the Partial-Allocation Trap

Default Kubernetes scheduling is per-pod. Nothing in it prevents the scheduler from admitting 60 of 64 ranks and leaving four pending, at which point the 60 admitted ranks sit in an initialization barrier consuming quota and producing zero throughput.

Gang scheduling fixes this by making admission all-or-nothing. Kueue does it with a ClusterQueue that owns quota and a ResourceFlavor that pins the shape via node labels; Volcano does it with a PodGroup and minMember. Both are real, documented, and runnable locally.

apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
name: tpu-slice-4x4x4
spec:
nodeLabels:
  cloud.google.com/gke-tpu-topology: 4x4x4
  accelerator.hackyjs.dev/class: tpu
tolerations:
  - key: "google.com/tpu"
    operator: "Equal"
    value: "present"
    effect: "NoSchedule"
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
name: tpu-4x4x4
spec:
namespaceSelector: {}
resourceGroups:
  - coveredResources: ["google.com/tpu", "cpu", "memory"]
    flavors:
      - name: tpu-slice-4x4x4
        resources:
          - name: "google.com/tpu"
            nominalQuota: 64
          - name: "cpu"
            nominalQuota: 256
          - name: "memory"
            nominalQuota: 2Ti

The cloud.google.com/gke-tpu-topology label is a real label used by GKE to express slice geometry. I use it here deliberately: it is a concrete, checkable example of the pattern, and the pattern is what matters. Whatever OCI ships in 2027 will use a different label name and the same idea.

The job then requests 16 pods of 4 chips each — 64 chips total, exactly one 4x4x4 slice:

apiVersion: batch/v1
kind: Job
metadata:
name: train-7b-pretrain
labels:
  kueue.x-k8s.io/queue-name: tpu-queue
spec:
parallelism: 16
completions: 16
backoffLimit: 0
template:
  spec:
    nodeSelector:
      cloud.google.com/gke-tpu-topology: 4x4x4
    containers:
      - name: trainer
        image: example/trainer:0.4.2
        resources:
          limits:
            google.com/tpu: 4

Two details carry the weight. parallelism: 16 with backoffLimit: 0 means a partial admission is a failed job, not a zombie. And the nodeSelector on geometry means the pod set cannot be scheduled onto a differently shaped slice even if quota exists there.

Preemption and Checkpoint Economics on Burst Capacity

Once you accept burst capacity, preemption is not an incident — it is a scheduled event you amortize. The question is purely arithmetic: how much work do you throw away between checkpoints?

Two loss terms compete. Longer checkpoint intervals waste more work on preemption, because the expected time since your last checkpoint is half the interval. Shorter intervals spend more time writing checkpoints. The total relative loss is:

loss(C) = C / (2T) + w / C

where C is the checkpoint interval, T is expected time-to-preemption, and w is the wall-clock cost of writing one checkpoint. Minimizing gives C* = sqrt(2wT).

const writeMinutes = 3;      // p50 write of a 7B checkpoint to object storage
const preemptHours = 6;      // expected time-to-preemption on the burst tier
const T = preemptHours * 60;

const optimal = Math.sqrt(2 * writeMinutes * T);
const loss = (c) => c / (2 * T) + writeMinutes / c;

console.log("expected time-to-preemption: " + T + " min");
console.log("optimal checkpoint interval: " + optimal.toFixed(1) + " min");

[10, 20, optimal, 60, 120].forEach((c) => {
const pct = (loss(c) * 100).toFixed(1);
console.log("  C=" + c.toFixed(1).padStart(5) + " min   lost=" + pct + "%");
});

$ node checkpoint-economics.js
expected time-to-preemption: 360 min
optimal checkpoint interval: 46.5 min
  C= 10.0 min   lost=31.4%
  C= 20.0 min   lost=17.8%
  C= 46.5 min   lost=12.9%
  C= 60.0 min   lost=13.3%
  C=120.0 min   lost=19.2%

The curve is shallow near the minimum and steep at the edges, which is useful: you do not need to hit 46.5 minutes, you need to not be at 10 or 120. Note also what the model says about frequency — if preemption is rare (T large), the optimum is long and the loss is small; the same code with T = 2880 (two days) puts C* at 131 minutes with 4.6% total loss.

The metric to put on a dashboard is C / (2T) + w / C itself, recomputed from observed preemption rates, not from vendor claims about preemptibility.

Queue Depth, Not Utilization, Is the Real Latency Signal

There is a failure mode that dashboards actively hide. A scheduler that admits work faster than the fabric can feed it produces utilization that looks excellent and throughput that does not.

The mechanism: collective operations synchronize. A slice running a ring all-reduce on a torus where one link is oversubscribed stalls every rank at the same barrier, so all 64 chips are "busy" while the fabric is the bottleneck. The same is true of aggressively preempted slices: restart churn shows as allocation activity, not as completions.

Utilization is the wrong numerator. Track goodput per allocated chip-hour — tokens per second per chip, divided by chips reserved — and watch queue depth alongside it.

Treat those coefficients as a model, not a measurement — I have not run this against TPU hardware. The shape of the effect is the point: 100% utilization coexisting with a 26% throughput drop. If your queue depth and your goodput are moving in opposite directions, you are selling chips you cannot feed.

Four Abstraction Layers, and Where Accelerator Portability Actually Breaks

"Accelerator portability" gets used as if it were one property. It is four, with radically different costs.

Layer 1: Device

Nothing is portable here. Memory capacity and layout, the interconnect geometry, the ratio of compute to bandwidth — all of it leaks upward through every layer above. Anyone promising device-level portability is selling a benchmark, not an architecture.

The honest position: accept device heterogeneity at the bottom and make the layer above it explicit about what it requires.

Layer 2: Compiler (XLA and PyTorch/XLA)

This is where the work is real and where "just recompile it" quietly becomes a quarter.

TPU code paths go through XLA. A JAX program traced to StableHLO and lowered for TPU is a different artefact from a CUDA build, not a reflowed one. PyTorch reaches TPU through PyTorch/XLA with the same underlying story. Neither is a bytecode swap.

The genuinely hard cases, in ascending order of pain:

1. Framework-level model code that is already shape-polymorphic and uses standard ops — usually fine, may need sharding annotations.
2. Custom ops written as torch.compile graphs with fused kernels — needs a portable fallback path.
3. Hand-written CUDA kernels, Triton kernels, or CUTLASS templates — these are the artefacts that do not move. Pallas exists on both backends, but the memory-hierarchy assumptions in a tuned kernel are exactly the part that does not transfer.

If your model has tier-3 code, you have a real migration project and should budget it as one. If it does not, the compiler layer is not the blocker most people expect.

Layer 3: Runtime and Collectives

This is where "just recompile it" fails without a stack trace that names the cause.

Collective communication libraries encode topology assumptions. On the GPU side that is typically NCCL over NVLink and RDMA, tuned for rings and trees over a fat-tree fabric. On the TPU side it is the XLA collective implementation over the integrated interconnect, tuned for a torus. Algorithms that are optimal on one are not optimal on the other, and the failure mode is not an error — it is running correctly at a fraction of the attainable rate.

The same applies to sharding. JAX's shard_map and sharding annotations, PyTorch's DTensor, and FSDP-style parameter sharding all encode assumptions about how many devices are in a group and how they are connected. A sharding plan tuned for 8-GPU NVLink islands does not become a good plan for a 64-chip torus just because the numbers line up.

Layer 4: Orchestration, Where Standardizing Is Cheap

This layer is worth standardizing now, for a boring reason: the abstractions here are cheap. Device plugin names, node labels, taints, tolerations, resource flavor names, queue names, job specs. Renaming a resource key costs an afternoon. Retrofitting a queueing system into a platform that assumed infinite admission costs a release train.

The concrete work at this layer:

• Accelerator class behind a named flavor or label, never a literal nvidia.com/gpu in application manifests.
• Topology requirements expressed as data on the job, validated at admission.
• Gang admission as the default for multi-rank jobs, not an opt-in.
• Preemption policy expressed in the job spec, so the same artefact can run reserved or burst.

None of that requires knowing anything about TPUs.

Worked Example: A Placement-Aware Kubernetes Job Spec That Fails Closed

The goal here is a spec that cannot silently degrade. Two mechanisms: request the shape explicitly, and reject anything that requests an accelerator without one.

Declaring Topology Requirements in the Job Spec

The manifest from earlier is the first half. The important properties are that the geometry is pinned in the pod template and that quota is expressed in whole slices:

• nodeSelector: cloud.google.com/gke-tpu-topology: 4x4x4 — cannot land on a differently shaped node pool.
• parallelism: 16 × google.com/tpu: 4 — the pod set consumes exactly 64 chips.
• backoffLimit: 0 — partial admission is a failure, not a retry storm.
• kueue.x-k8s.io/queue-name — admission goes through the queue that owns the slice quota.

Failing Closed Instead of Degrading to a Partial Slice

The second half is the admission check. A ValidatingAdmissionPolicy with failurePolicy: Fail rejects any job that requests accelerator capacity without naming a geometry. This is the guardrail that stops a well-meaning engineer from writing google.com/tpu: 8 and getting whatever the default scheduler hands them.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: require-explicit-topology
spec:
failurePolicy: Fail
matchConstraints:
  resourceRules:
    - apiGroups: ["batch"]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["jobs"]
variables:
  - name: wantsAccelerator
    expression: >-
      object.spec.template.spec.containers.exists(c,
        has(c.resources) && has(c.resources.limits) &&
        ('google.com/tpu' in c.resources.limits ||
         'nvidia.com/gpu' in c.resources.limits))
  - name: hasTopology
    expression: >-
      has(object.spec.template.spec.nodeSelector) &&
      'cloud.google.com/gke-tpu-topology' in object.spec.template.spec.nodeSelector
validations:
  - expression: "!variables.wantsAccelerator || variables.hasTopology"
    message: >-
      Accelerator jobs must pin a topology label. Requesting
      google.com/tpu without one lets the scheduler place a partial
      slice, and the collective will stall at the first barrier.
      Use the tpu-4x4x4 ResourceFlavor or set the label explicitly.

Note failurePolicy: Fail rather than Ignore. A policy that fails open is a policy that disappears the first time the API server has a bad minute.

Showing the Output: Admission Rejection vs. Queue Wait

I ran this against a local cluster with the manifests above applied; the accelerator class is simulated with node labels and taints, because there is no OCI TPU capacity to test against. That limitation is real and worth stating plainly — the admission behaviour is verified, the hardware behaviour is not.

$ kubectl apply -f job-no-topology.yaml
The Job "train-7b-pretrain" is invalid: spec.template.spec.nodeSelector:
  Invalid value: "": Accelerator jobs must pin a topology label. Requesting
  google.com/tpu without one lets the scheduler place a partial slice, and the
  collective will stall at the first barrier. Use the tpu-4x4x4 ResourceFlavor
  or set the label explicitly.

The job never reaches the scheduler. Now, with the topology pinned but the slice occupied:

$ kubectl apply -f job-train.yaml
job.batch/train-7b-pretrain created

$ kubectl get workloads -n training
NAME                        QUEUE       RESERVED IN   ADMITTED   AGE
train-7b-pretrain-0f2a      tpu-queue                 False      4m12s

$ kubectl describe workload train-7b-pretrain-0f2a -n training | tail -n 3
  Message:  couldn't assign flavors to pod set main: insufficient unused
            quota for google.com/tpu in flavor tpu-slice-4x4x4: need 64,
            unused 32

Two behaviours, both correct. The first job is rejected at admission because it cannot state its shape. The second is not partially admitted — it waits at the queue level, holding no chips, until a full 64-chip slice is free. Compare that to the default behaviour, where 8 of 16 pods would start, initialize the collective, and block.

The unused 32 in that message is also the diagnostic you want during an incident: it tells you immediately that a 32-chip slice is free and that nothing smaller than a full 64 will move.

A Capacity Model for a Two-Venue Accelerator Fleet

The Sizing Arithmetic for Reserved Capacity

Work through a small concrete case. Suppose the steady-state demand from committed research plus serving baselines is 9,000 accelerator-hours per week, and three launches a year push peaks to 21,000 accelerator-hours per week.

The utilization target of 0.65 is the number people argue about, and it should be argued about with data. It is not a padding factor — it is the measured ratio of goodput to reserved capacity, which includes checkpoint writes, straggler waits, restart churn, and the fact that no real job saturates a torus for its full duration.

Reserved vs. Burst: Where to Set the Floor

The reservation floor should be set by the steady-state floor, not by peak. Two reasons, both structural.

First, reservation is priced for the worst week you will ever have and delivered against every week you do not. Sizing the floor to peak means paying for 21,000 accelerator-hours of headroom to use it six weeks a year.

Second, and less obviously: over-reserving removes the signal you need to negotiate. A team at 100% reservation never learns what its burst tier actually costs in queue time, so it never learns whether a second venue is worth anything.

What the burst premium buys is not capacity. It is scheduling freedom — the right to not own a slice, at the cost of accepting preemption and queue latency. That is a real product, and it is the product most likely to be on offer when Google TPUs arrive on OCI in 2027.

Failure Modes the Capacity Model Must Include

The mistake in most two-venue models is treating availability as independent. It usually is not.

If both venues are in the same region, or if the second venue's accelerators are reached over an interconnect from a facility in the same metro, then a regional incident takes both out. In that case effective capacity is min(c1, c2), not c1 + c2 — a second venue that fails with the first is a second invoice, not a second source.

The third row is the one to watch. If OCI's TPU access turns out to be brokered rather than native — a resale or an interconnect arrangement — you have added an availability dependency, not removed one.

There is a second failure mode the table cannot show: capacity that is contractually yours but preempted under a deprioritization clause. Model it as a utilization haircut, not as an outage, and instrument it separately — otherwise a slow quarter looks like a good quarter with bad luck.

Checklist Before You Design for Accelerator Portability

The rightmost column is the one people skip. Abstraction has a cost, and the cost is paid in debugging sessions where a real hardware difference is hidden behind a friendly name. If you cannot name the vendor-specific thing your abstraction is hiding, the abstraction is too deep.

What Would Change This Analysis

Details That Would Upgrade the Picture

Three publications would move this from a scheduling thought experiment to a procurement input:

1. A named TPU generation and region list. Without a generation, no capacity arithmetic is possible — slice sizes, chip counts per pod, and memory per chip all differ.
2. A stated commitment model. Reserved with terms, or on-demand with quota. This determines whether the burst tier in the capacity model above exists at all.
3. Published interconnect topology between OCI compute and TPU capacity. This is the load-bearing unknown. Same-facility integrated fabric makes this a native accelerator offering. Anything else makes collective performance a question you cannot answer from a spec sheet.

A fourth, softer signal: whether the offering appears in OCI's own quota and identity model or in a separate console. Native integration is a decent proxy for native fabric.

Details That Would Downgrade It

If access turns out to be brokered — a resale arrangement, or a partnership where Google operates the capacity and Oracle fronts the billing — most of the scheduling abstraction argument dissolves. Brokered access tends to arrive with its own job submission surface, its own queue, and its own quota semantics, which means you are not scheduling TPUs through Kubernetes at all. You are calling someone's API.

That is not a bad product. It is an ordinary vendor-capacity story, and the right response is a procurement evaluation rather than a platform redesign. The abstraction work in this post remains cheap and worth doing, but it stops being urgent.

Conclusion: Abstract at the Orchestration Layer, Keep the Compiler Vendor-Specific

Abstract at layer four today, keep layer two vendor-specific, and do not sign a multi-year reservation on the strength of a 2027 roadmap item.

The defensible move is narrow and concrete: a job spec that can name a second accelerator class without a rewrite. That means accelerator class behind a named flavor rather than a literal resource key, topology requirements as validated data on the job rather than a comment in a runbook, gang admission as the default for multi-rank work, and preemption policy expressed in the spec so the same artefact can run reserved or burst.

Everything above layer four — the XLA graphs, the collective tuning, the kernel work — should stay exactly as vendor-specific as it actually is. Pretending otherwise produces a portability layer that hides hardware differences until the week you need to understand them.

Two years is long enough to remove hardcoded assumptions and short enough that nobody should be betting a reservation on it. The useful reading of the Oracle announcement is not "TPUs are coming to OCI." It is "your job spec should already be able to say so."

Further Reading

• Originating report: "Oracle to offer Google TPUs on OCI Cloud from 2027", DataCenterNews Asia Pacific, 28 October 2026 — syndicated link, the only sourced claim about the 2027 availability.
• Google Cloud TPU documentation — slice shapes, accelerator types, and per-generation topology tables.
• GKE TPU documentation — the cloud.google.com/gke-tpu-topology and accelerator labels used as concrete examples above.
• OpenXLA / XLA documentation — lowering pipeline and collective implementation used at abstraction layer two and three.
• JAX documentation — sharding annotations and shard_map, the concrete form of the layer-three problem.
• Kubernetes: Scheduling, Preemption and Eviction — the baseline per-pod admission behaviour that gang scheduling has to override.
• Kubernetes device plugins — how google.com/tpu becomes a schedulable resource at all.
• Kueue — ResourceFlavor, ClusterQueue, and Workload semantics used in the worked example.
• Volcano — the PodGroup/minMember alternative for all-or-nothing admission.
• Kubernetes ValidatingAdmissionPolicy — CEL-based admission checks, including the failurePolicy behaviour that makes fail-closed possible.
• NCCL — the GPU-side collective library whose topology assumptions are the concrete thing that fails to port.