Preparing for Google TPUs on OCI in 2027: An Enterprise Readiness Guide

On this page

1. 01 · The Planning Window Before 2027
2. 02 · What Is Known, and What Is Not
3. 03 · The Enterprise AI Estate on OCI Today
4. 04 · Triage: Which Workloads Are TPU Candidates
5. 05 · Data Placement Next to Oracle Databases
6. 06 · A Readiness Runbook From Q4 2026 to 2027
7. 07 · Skills, Cost and Governance
8. 08 · What to Watch For in Oracle's Announcements
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · The Planning Window Before 2027

Readiness guide · Google TPUs on OCI

"TPUs arrive next year. What should we do this quarter?"

Oracle's announcement at Oracle AI World on 27 October 2026 put a new option on every enterprise AI roadmap: Google TPUs available through OCI, the first time Google TPUs are offered on a hyperscale cloud outside Google, with availability in calendar year 2027. Within days, leadership teams start asking whether this changes their GPU commitments, their data strategy or their hiring plans.

The useful answer is that the hardware is a 2027 event but the preparation is a 2026 one. Oracle has not yet published shapes, regions, pricing or a launch date within the year, so nobody can sign a TPU contract today. What you can do is make sure that, when those details appear, you already know which workloads are candidates, whether their code will port, where their data lives and who owns the decision. That work takes months, and it pays off even if you never move a workload to TPUs.

02 · What Is Known, and What Is Not

Answer: Known: TPUs will be offered through OCI in calendar 2027, ramping over multiple years, for large-model training, post-training and production inference, with OCI providing power, cooling and networking. Not known: pricing, regions, shape names, the launch date within 2027, which TPU generations will be offered first, and orchestration or managed services.

A readiness plan starts by separating facts from assumptions. The announcement positions TPUs as an addition to OCI's AI compute portfolio, alongside NVIDIA GPUs and AMD Instinct GPUs, so customers can match each workload to the infrastructure that suits it. Oracle's Mahesh Thiagarajan summed up the premise: "Different AI workloads have different compute needs." The table below is the baseline every planning document should start from.

03 · The Enterprise AI Estate on OCI Today

Answer: Most OCI customers already have the pieces TPUs will plug into: Oracle AI Database 26ai on Exadata or Autonomous with AI Vector Search, Object Storage as a data lake, GPU clusters, OCI Generative AI, and identity and governance controls. Some also run Oracle AI Database@Google Cloud. TPUs will be a new compute option inside that estate, not a separate platform.

The figure below shows a typical enterprise AI estate on OCI, with TPU pods drawn where they would logically sit from 2027. On the data side, Oracle AI Database 26ai on Exadata or Autonomous holds operational data and vector embeddings for AI Vector Search, and Object Storage holds training data, documents and checkpoints. On the compute side, NVIDIA and AMD GPU clusters run today's training and inference. OCI Generative AI provides managed AI services. Identity and governance span every tier, and an interconnect links to applications and Oracle AI Database@Google Cloud on Google Cloud.

The design point is data gravity. Training and retrieval workloads move large volumes of data between storage, databases and accelerators. The closer TPU capacity sits to the Object Storage buckets and databases that feed it, the less you pay in transfer time, egress and duplicated governance work.

04 · Triage: Which Workloads Are TPU Candidates

Answer: A workload is a strong TPU candidate when its code stays at the framework level, it serves through vLLM or SGLang, it is large-scale training or high-volume inference, and its timeline can wait for 2027 capacity. Custom CUDA kernels, CUDA-only libraries, hard deadlines and validated stacks are reasons to stay on GPU for now.

Triage is the step that turns a vague opportunity into a short list. Start from the inventory of AI workloads: every training job, fine-tuning pipeline and inference endpoint, with its framework, dependencies, data sources, monthly spend and business owner. Then score each one against two sets of signals. The scorecard below lists them side by side, so a review board can classify a workload in minutes.

Few workloads score cleanly on one side. A mixed result is still useful: it tells you which blocker to remove first. A PyTorch fine-tuning job with one CUDA-only library is one library swap away from being a pilot candidate. A model with custom kernels in its hot path is a candidate for later, not for 2027.

05 · Data Placement Next to Oracle Databases

Answer: Put the data that feeds AI workloads in OCI, in the same region as the compute you expect to use, governed by the same identity and access controls. For enterprises whose core data already sits in Oracle AI Database 26ai, that means planning how training sets, embeddings and documents flow from the database and Object Storage to accelerators.

Data placement is the readiness task most often left until too late. If your training data sits in another cloud or on premises, every training run on OCI TPUs starts with a transfer. If your retrieval-augmented applications use AI Vector Search in Oracle AI Database 26ai, the inference tier benefits from sitting close to that database. Both arguments point to the same action: consolidate AI data in OCI regions that already host your Oracle databases, and keep it in formats your frameworks can read directly from Object Storage.

Enterprises with a footprint on Google Cloud have an additional option to consider. Oracle and Google already partner on Oracle AI Database@Google Cloud, which runs Oracle databases inside Google Cloud data centers. If part of your estate lives there, map which data each AI workload needs and where it will run, rather than copying everything everywhere. Oracle has not published how TPUs on OCI will interact with the Database@Google Cloud service, so treat any cross-cloud design as illustrative until it does.

06 · A Readiness Runbook From Q4 2026 to 2027

Answer: Run seven steps in four phases: inventory and triage now, portability tests, data placement and capacity planning before launch, a pilot when TPUs reach OCI in 2027, and scaling as Oracle ramps capacity over the following years. Gate every commitment on Oracle publishing shapes, regions and pricing.

The runbook below lays the work out over time. The first two steps are cheap and can finish this quarter. The middle three take most of the effort and run in parallel until launch. The pilot depends on Oracle's launch date, which is not yet published, and scaling follows the multi-year capacity ramp Oracle described. The red tags are the gate: until Oracle publishes those items, no step should turn into a contract, a budget line tied to a price, or a promise to a business unit about dates.

Notice that five of the seven steps happen before any TPU is available on OCI. That is the point of the runbook: by launch, the pilot should be a planned event with a chosen workload, ready code, data in place and agreed success criteria.

1. Inventory AI workloads. List every training, fine-tuning and inference workload with its framework, dependencies, data sources, monthly spend and owner.
2. Triage each workload. Score it against the readiness scorecard and record whether it is a TPU candidate, a later candidate or GPU-only for now.
3. Run portability tests. For candidates, remove CUDA-specific code, move serving to vLLM or SGLang, and benchmark on any TPU capacity you can access.
4. Place the data. Consolidate training data, embeddings and checkpoints in the OCI region you expect to use, under existing governance.
5. Plan capacity and budget. Model expected demand, but tie budgets to ranges until Oracle publishes pricing and shapes.
6. Pilot at launch. Run one training or inference workload with clear success criteria: accuracy, throughput, latency and cost per unit of work.
7. Scale with the ramp. Move proven workloads in waves as capacity grows, keeping GPU capacity for everything that is not ready.

07 · Skills, Cost and Governance

Answer: Prepare three things alongside the technical work: skills in JAX, TorchTPU and XLA-aware performance tuning; a cost model that compares cost per unit of work across accelerators rather than hourly rates; and governance that applies the same identity, data access and audit rules to TPU workloads as to GPU workloads.

Skills are the easiest gap to underestimate. Most ML engineers know PyTorch on CUDA well. Fewer know how to shard a model across a TPU pod, read XLA compilation behaviour or tune batch sizes for TPU memory. Google says TPU 8i offers 288 GB of HBM per chip and pods of 1,152 chips, and TPU 8t superpods scale to 9,600 chips; designs at that scale need people who understand sharding. Start with one or two engineers on a real workload rather than broad training.

Cost needs a new yardstick. Comparing an hourly TPU rate with an hourly GPU rate is misleading when the chips do different amounts of work per hour. Google claims up to 80% better performance per dollar for inference on TPU 8i compared with Ironwood. Treat that as a hypothesis to test with your own models, measured as cost per million tokens served or per training step.

The winners in 2027 will not be the teams that move fastest, but the teams that already know which workloads to move.

08 · What to Watch For in Oracle's Announcements

Over the coming months, Oracle will publish the details that turn this guide from preparation into action. Track these items and update your plan as each one lands:

1. Shapes and TPU generation. Which TPU chips OCI offers first, and in what slice and pod sizes.
2. Regions. Where TPU capacity will be deployed, and whether it sits in the same regions as your Oracle databases and Object Storage.
3. Pricing and commitments. On-demand, reserved and committed-use options, and how they relate to existing Universal Credits agreements.
4. Orchestration. Whether TPUs will be scheduled through OKE, a managed training or inference service, or another mechanism.
5. Integrations. How TPU workloads connect to Object Storage, OCI Generative AI, Oracle AI Database 26ai and Oracle AI Database@Google Cloud.
6. Launch date and ramp. When capacity becomes available in 2027 and how quickly it grows.

09 · Key Takeaways

1. TPUs on OCI are a 2027 event; readiness is a 2026 task. Inventory, triage and portability work can start now without any TPU contract.
2. Separate facts from assumptions. Pricing, regions, shapes, launch date and orchestration are not yet published; gate commitments on them.
3. Triage with a scorecard. Framework-level code, vLLM or SGLang serving and large-scale workloads point to TPU; CUDA kernels and deadlines point to GPU.
4. Data placement decides speed. Put AI data in the OCI region next to your Oracle databases and under existing governance.
5. Measure cost per unit of work. Compare accelerators on cost per token or per training step, using your own benchmarks.

10 · Frequently Asked Questions