For seven generations, Google shipped one TPU and told you it was good at everything. The eighth generation is two chips: TPU 8t for training and TPU 8i for inference. That fork is the most useful piece of information in the whole announcement — more useful than the superpod numbers, more useful than the new network fabric — because it's Google conceding, in silicon, that training and inference are different businesses with different bottlenecks. If a hyperscaler that controls its entire stack can't make one chip serve both anymore, your "AI compute" budget line shouldn't be one number either.
What the two chips actually are
TPU 8t is the training part. A single superpod scales to 9,600 TPUs sharing 2 petabytes of high-bandwidth memory, which is the point where you stop thinking of it as a cluster of accelerators and start thinking of it as one very large accelerator with a scheduler in front of it. Google claims 3x the processing power of Ironwood (the seventh generation) and up to 2x the performance per watt. The second number is the one I'd anchor on. At superpod scale you run out of megawatts before you run out of chips, so a perf/watt doubling isn't an efficiency footnote — it's the difference between fitting a training run in your allocated capacity and not.
TPU 8i goes the other direction. Pods top out at 1,152 chips — small by 8t standards, because inference jobs don't need ten thousand chips coordinating on one problem. The headline spec is 3x more on-chip SRAM than the prior generation. SRAM sits right next to the compute, orders of magnitude faster to reach than HBM, and for serving it's what keeps token latency down when a real user is waiting on the other end. This is a chip designed around the fact that inference is a latency-and-cost problem, not a throughput problem.
Tying it together is Virgo Network, Google's new megascale data center fabric underneath the AI Hypercomputer architecture. Google hasn't published deep specs, but the role is obvious: 9,600 chips sharing 2 PB of memory only behaves like one machine if the interconnect holds up. Past a certain pod size, the network is the computer — the chip specs are almost secondary.
The strange part: Google is also selling NVIDIA racks
Buried in the same announcement: Google Cloud will be among the first providers to offer NVIDIA's Vera Rubin NVL72 rack-scale systems, integrated into AI Hypercomputer, in the second half of 2026.
Sit with that for a second. Google has the most mature custom-silicon program of any hyperscaler, an eighth-generation chip family, and its own fabric — and it's still putting NVIDIA racks on the menu. That's not indecision; it's a read on the customer base. Too many enterprises have years of CUDA tooling, NVIDIA-shaped training pipelines, and NVIDIA-shaped procurement relationships to move, and Google would rather host those workloads than watch them go to a competitor.
The "NVL72" part matters for buyers too. NVIDIA is increasingly selling racks, not chips — GPUs, interconnect, power, and cooling as one deployable unit. When the unit of product is a rack, the unit of procurement becomes a rack, and the conversation with your provider shifts from "how many instances" to power density, facility readiness, and rack-scale reserved-capacity commitments. If you haven't had that conversation yet, H2 2026 is when it arrives.
And it's not just Google spending. Microsoft's $3.3 billion data center campus in Mount Pleasant, Wisconsin just came fully online — a single-site commitment justified almost entirely by AI demand. Every hyperscaler is locking up power, land, and chip supply years ahead of the workloads. You will feel this in availability and pricing whether or not you ever touch a TPU.
What I'd actually do with this announcement
If you're responsible for AI infrastructure spend, five moves follow directly from the specifics above:
Split your training and inference roadmaps — formally. Google just did it in hardware; do it in your budget. Training is bursty, batch-oriented, and superpod-shaped. Inference is steady-state, latency-sensitive, and scales with your users, not your research calendar. They'll have different pricing, different availability, and different negotiation dynamics on Google Cloud, so planning them as one line item means getting both wrong.
Put perf/watt in your TCO model as a first-class term. TPU 8t's up-to-2x perf/watt gain over Ironwood is the kind of number that quietly dominates a three-year cost model, especially if you're paying colo power or running hybrid. If your AI cost model still prices compute-hours without a power term, it's underestimating the cheap options and overestimating the expensive ones.
Keep your stack architecture-portable. Google offering TPUs and Vera Rubin NVL72 side by side means the multi-architecture future is here even inside a single cloud. Don't hard-wire your serving stack or training pipeline to one accelerator family. Frameworks and orchestration layers that abstract the chip (JAX/XLA, PyTorch with sane backend hygiene, portable serving runtimes) cost a little now and buy you real negotiating leverage later. The workloads that can move are the workloads that get discounts.
Watch the Ironwood price window. Every new chip generation pushes the previous one down-market. When 8t and 8i capacity comes online, expect Ironwood-class TPUs — and prior NVIDIA generations — to get cheaper or easier to reserve. Most enterprise workloads are not frontier workloads. Fine-tuning, batch inference, embeddings, internal tools: these run fine on last-gen silicon at next year's prices, and the window opens right when everyone else is distracted by the new thing.
Interrogate the network, not just the chips. Virgo Network is the tell that interconnect is now the differentiator. When a provider quotes you a pod size, ask about cross-pod bandwidth, latency at your actual model scale, and measured scaling efficiency — not the theoretical chip count. A superpod that scales at 60% efficiency for your workload is a smaller superpod than the one on the slide.
The honest caveat
Most of the specifics here are Google's own numbers — "3x Ironwood" and "up to 2x perf/watt" are vendor claims until third-party benchmarks land, and Virgo Network is mostly a name and a promise right now. I wouldn't re-platform anything on this announcement alone. What I would do, this quarter, is restructure the planning: separate training and inference budgets, add power to the TCO model, and write architecture portability into any AI infrastructure contract you're negotiating for 2027. Those moves pay off regardless of whose benchmark numbers survive contact with reality — and if Google's numbers do hold up, you'll be positioned to take advantage instead of starting the analysis the day the capacity goes live.