tpu

A Tensor Processing Unit (TPU) is Google's custom machine-learning accelerator, designed around high-throughput matrix multiplication for training and inference in the Google software and cloud ecosystem.\n\n```svg\n\n \n The TPU Systolic Array — Matrix Multiply as Dataflow\n one value read from memory feeds many multiply-accumulates — that reuse is the whole point\n\n \n weights stay resident in each cell (stationary)\n\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n ×+\n \n \n \n \n \n \n \n \n \n \n\n \n activations stream in\n \n partial sums accumulate downward → outputs\n\n \n MXU\n 128×128 (or 256×256)\n real array, not 5×5\n bfloat16\n wide range, low bits\n one memory read\n → many MACs\n\n No register file re-fetch per multiply: operands march through the array, so energy goes to arithmetic, not data movement.\n\n```\n\n**The core is a systolic matrix unit.** Activations and weights stream through a two-dimensional multiply-accumulate array, maximizing data reuse and reducing energy spent moving operands. Vector units and on-chip memory handle the operations surrounding matrix multiplication.\n\n**Why the systolic array is so efficient.** In a conventional processor every multiply re-fetches its operands from registers or memory. In a systolic array a weight is loaded once into a cell and stays put, reused across a whole stream of activations, while partial sums accumulate as they march down the array. One memory read therefore feeds many multiply-accumulates, and that operand reuse is where the energy-per-operation advantage comes from.\n\n**TPUs are systems, not isolated chips.** High-bandwidth memory, fast chip-to-chip interconnects, and pod-scale topology allow large models to span many devices. XLA compiles TensorFlow, JAX, and supported PyTorch workloads into programs matched to that hardware.\n\n**The generations trace a clear arc.** TPU v1 in 2016 was inference-only, with an 8-bit matrix unit on a PCIe card. v2 and v3 added training, HBM, and the bfloat16 numeric format, and organized chips into pods. v4 introduced optically reconfigurable interconnects that rewire the pod topology to the workload, and the later v5e and v5p chase performance per dollar and per watt at very large scale. Throughout, the real differentiator is the pod: thousands of chips wired into a single machine.\n\n**The trade is specialization for efficiency.** TPUs can be highly efficient on well-shaped tensor workloads, while GPUs generally offer a broader programming ecosystem and more flexibility for irregular kernels.\n\n| Generation | Focus | Notable |\n|---|---|---|\n| TPU v1 (2016) | inference only | 8-bit MXU on a PCIe card |\n| TPU v2 / v3 | training and inference | HBM, bfloat16, pod scale |\n| TPU v4 | large-scale training | optical circuit switch interconnect |\n| TPU v5e / v5p | scale and cost | performance per dollar, huge pods |\n\nRead a TPU through an *operand-reuse* lens rather than a *peak-FLOPS* lens: the systolic array wins by getting many multiply-accumulates out of each value it reads from memory, so its efficiency comes from dataflow — how long a weight stays resident and how far a partial sum travels before it is written back — not from clock speed. Every design choice around it, from bfloat16 to pod-scale optical interconnects, is about keeping that array fed without paying to move data.\n

Go deeper with CFSGPT

Get AI-powered deep-dives, save terms, and run advanced simulations — free account.

Create Free Account