Google’s Ironwood TPU Pods at Scale: What a 9,216-Chip Pod Means for AI Training Infrastructure

“9,216 chips in a pod” and “42.5 ExaFLOPS” are the two numbers that show up in every headline about Google’s Ironwood TPU, and both are real, confirmed figures from Google Cloud’s own materials. But neither number means much without understanding how those 9,216 chips are actually wired together — because the interesting engineering in Ironwood isn’t the chip itself, it’s the optical switching fabric that lets Google treat a room full of racks as one reconfigurable machine. This is specifically about that pod-and-superpod architecture, not a general tour of the TPU chip (which this site has already covered elsewhere).

At a Glance

Generation	7th-generation TPU (“Ironwood”)
Chips per superpod	9,216 (also offered at 256-chip pod scale)
Compute per full pod	42.5 ExaFLOPS (FP8)
Peak compute per chip	4,614 TFLOPS
HBM per chip	192 GB across 8 HBM3E stacks
HBM bandwidth per chip	7.37–7.4 TB/s
Total shared HBM (superpod)	1.77 PB
Chip-to-chip interconnect (ICI)	1.2 TB/s bidirectional per chip (9.6 Tb/s)
Rack-level topology	64 chips per rack (“cube”), direct 3D torus
Inter-cube fabric	Optical Circuit Switching (OCS)
Superpod footprint	Approximately 10 MW

What a 9,216-Chip Pod Actually Means

Google’s basic building block is a “cube”: 64 Ironwood chips, four chips per physical host, 16 hosts per rack, all connected directly via Inter-Chip Interconnect (ICI) in a 3D torus — meaning every chip has direct links to six neighbors across three axes, rather than a flat switch. A 256-chip pod, Google’s smaller offering, is simply four of these cubes connected together. The full 9,216-chip superpod is 144 cubes (144 × 64 = 9,216), and that’s the detail that explains why Ironwood needed a fundamentally different interconnect than earlier TPU generations: a 3D torus alone doesn’t scale cleanly to 144 racks without either enormous fixed cabling complexity or some way to dynamically rewire connections between cubes. That’s exactly what Google added.

Google states a full superpod provides 1.77 petabytes of directly accessible shared HBM — a figure arrived at simply by multiplying 9,216 chips by 192 GB of HBM3E per chip (8 stacks per chip), with each chip delivering roughly 7.37–7.4 TB/s of HBM bandwidth. The physical footprint of a 9,216-chip superpod runs to nearly 10 MW, which is a useful number for anyone trying to understand why “renting a TPU pod” is a data-center-level commitment, not a server order.

Optical Circuit Switching: The Part That Actually Matters

Within a single 64-chip cube, chips connect directly via ICI. Connecting 144 cubes into one 9,216-chip domain is handled by Optical Circuit Switching (OCS) — a dynamic, reconfigurable optical fabric that sits between cubes rather than inside them. Google describes OCS as giving the superpod fault tolerance that a fixed electrical fabric can’t easily match: if a cube or a link fails, the OCS fabric manager optically routes around the unhealthy unit and establishes new circuits among the remaining healthy cubes, swapping in a designated spare cube to keep the workload running rather than restarting a failed training job from scratch. The same reconfigurability lets Google carve out “slices” of any size from a superpod for different customers or jobs, rather than being locked into fixed-size partitions.

Beyond a single superpod, Google says Ironwood scales further — “into clusters of hundreds of thousands of TPUs” — by connecting multiple superpods over Google’s standard data-center network (the Jupiter network), rather than extending the OCS fabric itself across that distance. In other words, there are effectively three tiers: ICI within a cube, OCS between cubes inside a superpod, and conventional data-center networking between superpods.

Cooling at This Density, and the ExaFLOPS Caveat

Packing 9,216 chips into roughly 10 MW of continuous AI compute load isn’t viable with air cooling, and Google says as much directly: its advanced liquid cooling, paired with the Ironwood board design, is stated to sustain up to 2x the performance of standard air cooling under continuous, heavy AI workloads, using what Google calls third-generation Cooling Distribution Units at the superpod level. Google separately notes that its liquid cooling deployments across its fleet have run at “GigaWatt scale” with roughly 99.999% uptime since 2020 — worth noting that this is a fleet-wide historical claim about Google’s liquid cooling program generally, not an Ironwood-specific reliability figure, and the article treats it accordingly rather than implying it’s a guarantee for any single Ironwood deployment.

One figure worth reading carefully: Google compares a full Ironwood pod’s 42.5 ExaFLOPS to the El Capitan supercomputer’s 1.7 ExaFLOPS rating, framing Ironwood as “more than 24x” larger. That comparison mixes precisions — Ironwood’s 42.5 ExaFLOPS is an FP8 AI-compute figure, while El Capitan’s rating is a traditional FP64 high-precision-computing benchmark (the standard used for supercomputer rankings like the TOP500). FP8 and FP64 measure fundamentally different kinds of arithmetic, so the comparison illustrates scale in a general sense but isn’t an apples-to-apples performance claim, and readers evaluating TPU pods against traditional HPC systems should keep that distinction in mind rather than treating the 24x figure as a literal speed multiple.

How This Compares to Nvidia and AWS’s Scale-Out Approach

All three major infrastructure providers solve the same underlying problem — getting more chips to behave as one coherent domain — with different topology philosophies. Nvidia’s approach centers on the NVLink Switch fabric inside a single GB200/GB300 NVL72 rack, creating a fixed 72-GPU domain that then scales out to multiple racks over InfiniBand or Spectrum-X Ethernet networking; the “one giant GPU” abstraction stops at 72 GPUs, with everything beyond that handled by conventional networking. AWS’s Trainium side uses NeuronLink to join four Trn2 servers into a 64-chip UltraServer, then scales further using its Elastic Fabric Adapter (EFA) networking across instances — also a fixed small-scale domain plus conventional scale-out. Google’s superpod design is the most aggressive of the three in pushing the “one coherent domain” boundary outward: by using OCS to dynamically rewire 144 racks’ worth of chips before resorting to standard data-center networking, Google extends the tightly-coupled fabric to 9,216 chips rather than stopping at a single rack. This is a difference in architectural philosophy, not a simple better-or-worse ranking — each approach reflects what each company’s own networking stack (NVLink/InfiniBand, EFA, or OCS/Jupiter) was built to do well.

Who Should Care

Pod-scale architecture matters most to teams training foundation models large enough to need thousands of accelerators working as one job — at that scale, the resilience of OCS (routing around failed cubes without restarting a training run) can be the difference between a training job completing on schedule and one that stalls repeatedly. For teams doing inference serving, fine-tuning, or smaller-scale training, the smaller 256-chip pod configuration (or a fraction of a superpod via Google’s slicing) is the more realistic unit of consumption, and most of what makes a superpod interesting — OCS fault tolerance, 10 MW-scale liquid cooling — is infrastructure Google manages on your behalf rather than something you configure directly.

Bottom Line

The 9,216-chip number is real, and so is the 42.5 ExaFLOPS figure, but the actual engineering achievement is the Optical Circuit Switching fabric that lets Google treat 144 racks as one reconfigurable, fault-tolerant domain rather than a loose cluster of separately-networked machines. That’s a meaningfully different approach from how Nvidia and AWS scale their own flagship systems, and it’s the detail worth understanding if you’re evaluating TPU pods against GPU or Trainium clusters for large-scale training — not the headline multiples by themselves.

FAQ

What does “9,216 chips in a pod” actually mean physically?
It’s 144 racks (“cubes”) of 64 chips each, connected into one domain — 64 chips connect directly via a 3D torus interconnect within a cube, and Optical Circuit Switching links the 144 cubes together.

Is the 42.5 ExaFLOPS figure comparable to supercomputer rankings like the TOP500?
Not directly — Google’s 42.5 ExaFLOPS figure is an FP8 AI-compute number, while supercomputer rankings use FP64 precision. Comparing the two (as Google itself does, against the El Capitan supercomputer) illustrates scale but isn’t a true apples-to-apples performance comparison.

What is Optical Circuit Switching (OCS) and why does it matter?
It’s a dynamic, reconfigurable optical fabric connecting cubes within a superpod. If a cube or link fails, OCS reroutes around it and swaps in a spare, which avoids restarting a large training job from scratch — a major practical advantage at this scale.

How much memory does an Ironwood superpod have in total?
Google states 1.77 petabytes of shared, directly accessible HBM across a full 9,216-chip superpod, based on 192 GB of HBM3E per chip.

Can Ironwood scale beyond a single 9,216-chip superpod?
Yes — Google says multiple superpods connect over its standard data-center network (the Jupiter network) to reach clusters of hundreds of thousands of TPUs, though that tier uses conventional networking rather than the OCS fabric used within a superpod.

How does Ironwood’s scale-out compare to Nvidia’s or AWS’s?
Nvidia and AWS both use a fixed small-scale, tightly-coupled domain (72 GPUs via NVLink for Nvidia’s NVL72 racks, 64 chips via NeuronLink for AWS’s Trainium2 UltraServers) and then rely on conventional networking (InfiniBand/Spectrum-X, or EFA) to scale further. Google’s OCS-based superpod pushes the tightly-coupled domain out to 9,216 chips before switching to conventional data-center networking — a different point on the same basic trade-off.

Sources

• Ironwood TPUs and New Axion-Based VMs for Your AI Workloads (Google Cloud Blog)
• Inside the Ironwood TPU: Codesigned AI Stack (Google Cloud Blog)
• Ironwood: The First Google TPU for the Age of Inference (Google Blog)