Google technical article 011
Google Tensor Processing Units
How Google’s eighth-generation TPU 8t and TPU 8i separate large-scale training from latency-sensitive serving through different memory, compute and interconnect designs.What it is
A Google Tensor Processing Unit is a custom accelerator for neural-network computation in Google’s data centres and Cloud AI Hypercomputer. The current eighth generation is split into TPU 8t for large-scale pre-training and TPU 8i for sampling, serving, reasoning, reinforcement learning and mixture-of-experts workloads.
Both are complete systems, not isolated chips. Each chip combines matrix, vector, on-chip memory and high-bandwidth memory resources, then uses an inter-chip interconnect to form pods. Arm Axion CPUs host both variants. As of this article’s verification time, TPU 8t and 8i are announced for upcoming customer availability; seventh-generation Ironwood remains generally available.
Why Google built two TPUs
Training and serving use the same model mathematics but stress hardware differently. Training applies large, regular matrix operations across huge batches and exchanges gradients or parameters at high throughput. Autoregressive serving repeatedly generates a small amount of output, maintains a growing KV cache and may route each token to different experts, making memory capacity and collective latency more important.
Google therefore stopped treating one topology as optimal for both. TPU 8t retains a large 3D torus and SparseCore for training and embedding traffic. TPU 8i increases HBM and on-chip SRAM, adds a Collectives Acceleration Engine and replaces the torus with a lower-diameter Boardfly network.
| Pressure | TPU 8t response | TPU 8i response |
|---|---|---|
| Dense matrix throughput | 12.6 PFLOPS peak FP4; native FP4 MXU path. | 10.1 PFLOPS peak FP4, balanced for serving. |
| Embedding lookups | SparseCore handles irregular access and selected collectives. | CAE replaces prior SparseCores. |
| KV cache and decoding state | 128 MB on-chip Vmem; 216 GB HBM. | 384 MB on-chip Vmem; 288 GB HBM. |
| All-to-all communication | Large 3D torus optimised for training scale. | Boardfly cuts maximum 1,024-chip path from 16 to seven hops. |
Chip and memory architecture
How a model layer executes
- Compile the graph.XLA maps model operations to TPU matrix, vector, memory and collective primitives.
- Shard model and data.JAX or Pathways partitions tensors across chips according to the selected parallelism strategy.
- Stage operands.Weights and activations move from HBM into on-chip Vmem close to execution units.
- Run arithmetic.MXUs process matrix multiplications while VPUs overlap quantisation, softmax, normalisation and other vector work.
- Handle specialised traffic.TPU 8t uses SparseCore for embedding-heavy access; TPU 8i uses CAE for reductions and synchronisation.
- Exchange partitions.ICI carries scale-up collectives inside the pod; the data-centre network and Pathways connect work beyond one pod.
From chip to distributed system
| Level | TPU 8t | TPU 8i |
|---|---|---|
| Chip | Training-oriented tensor, vector and SparseCore resources. | Two Tensor Core dies plus one CAE chiplet die. |
| Local building block | Chips connect into the 3D torus. | Four-chip ring with 16 external links. |
| Pod / superpod | 9,600 chips; 121 exaflops aggregate; about 2 PB shared HBM. | Eight boards per group; 36 groups; up to 1,024 active chips through optical circuit switches. |
| Scale-out | Virgo links more than 134,000 chips with up to 47 Pb/s non-blocking bisection bandwidth. | Cloud network connects serving pools and surrounding services. |
| Host and software | Arm Axion CPU; XLA, JAX and Pathways. | Arm Axion CPU; XLA, JAX, PyTorch preview and vLLM. |
TPU 8t and TPU 8i specifications
| Area | TPU 8t | TPU 8i |
|---|---|---|
| Primary workload | Large-scale pre-training and embedding-heavy models | Sampling, serving, reasoning, RL and MoE |
| Peak FP4 | 12.6 PFLOPS per chip | 10.1 PFLOPS per chip |
| HBM capacity | 216 GB per chip | 288 GB per chip |
| HBM bandwidth | 6,528 GB/s | 8,601 GB/s |
| On-chip Vmem | 128 MB | 384 MB |
| Specialised block | SparseCore and LLM Decoder Engine | Collectives Acceleration Engine |
| ICI topology | 3D torus; twice Ironwood scale-up bandwidth | Hierarchical Boardfly; 19.2 Tb/s ICI |
| Published pod scale | 9,600-chip superpod | Up to 1,024 active chips; 1,152 physical positions cited |
| CPU host | Arm Axion | Arm Axion |
Mechanisms that change utilisation
| Mechanism | Function | Why it matters |
|---|---|---|
| Native FP4 | Processes four-bit floating-point values directly in TPU 8t MXUs. | Reduces operand size and doubles the cited MXU rate relative to a wider path. |
| VPU/MXU overlap | Runs vector operations alongside matrix work. | Avoids serial quantisation, softmax or normalisation stalls. |
| SparseCore | Handles embedding lookups and irregular gather/collective patterns. | Prevents sparse data access from idling dense matrix hardware. |
| CAE | Accelerates reductions and synchronisation on TPU 8i. | Google reports fivefold lower on-chip collective latency. |
| Boardfly | Uses fully connected local groups and optical links between groups. | Reduces maximum 1,024-chip diameter from 16 to seven hops. |
| TPUDirect RDMA / Storage | Moves data between HBM, NICs and managed storage without host-DRAM staging. | Removes CPU and host-memory copies from large transfer paths. |
Terms
- TPU
- Google’s custom Tensor Processing Unit accelerator.
- MXU
- Matrix Multiply Unit for dense tensor arithmetic.
- VPU
- Vector Processing Unit for element-wise and reduction work.
- Vmem
- Fast on-chip SRAM used near the execution units.
- ICI
- Inter-chip interconnect forming the TPU scale-up network.
- CAE
- TPU 8i engine for collective communication operations.
- MoE
- Mixture of experts, routing tokens to selected model sub-networks.
- XLA
- Google’s Accelerated Linear Algebra compiler.
Limits of the evidence
- TPU 8t and 8i are announced systems; Google stated customer availability was upcoming at launch.
- Peak FP4 rates depend on supported operations and numeric format and are not sustained model throughput.
- Pod and fabric figures are aggregate design maxima; application scaling depends on partitioning and communication.
- The cited 1,152-chip Boardfly physical scale and 1,024 active-chip architecture describe different boundaries and are retained separately.
- Google’s comparative performance, cost and energy claims are excluded.
- Detailed cache, clock, power and die-manufacturing specifications are not fully published.
- The embedded videos are explanatory and launch material, not evidence for the specification tables.
- Price and promotional material are excluded.
Sources
- TPU 8t and TPU 8i technical deep diveChip blocks, memory, compute, topology, direct I/O and software.
- Google Cloud AI infrastructure at Next ’26Eighth-generation launch, system scale and availability wording.
- Introducing Virgo NetworkTPU 8t scale-out topology and bisection bandwidth.
- Ironwood TPU general availabilitySeventh-generation deployment context and pod sizes.
- TPU cluster reliabilityDistributed checkpointing, resilience and large-cluster operation.
- Cloud TPU system architectureHost, accelerator, network and TPU VM programming model.
- Google TPU 8t and TPU 8i: Purpose-built for the Agentic EraOfficial Google Cloud overview supplied for this article.
- Introducing eighth-generation TPUsOfficial Google Cloud launch video supplied for this article.
- Scaling AI with Google Cloud’s TPUsGoogle Cloud Tech system-level explainer supplied for this article.
- TPU 8t vs 8i: Why Google Split Its Chip in TwoIndependent explainer supplied for additional context.