AI Infra Interviews logo
Google · TPU · reviewed 2026-09-12

Google TPU7x (Ironwood)

Ironwood adds a much larger HBM budget and native FP8. Google’s technical name is TPU7x; its two chiplets are visible as two framework devices per chip.

Memory per accelerator
192 GiB

HBM

Memory bandwidth
7.38 TB/s

Published peak, not measured application throughput

Remember this

The comparison table labels capacity as 192 GiB per chip, while the chiplet narrative says 96 GB each. Keep the source’s unit discrepancy in mind and use runtime-reported per-device memory for a real allocation.

When this is a sensible choice

Start here if…

Evaluate it for large supported models, training or decode-heavy serving. Plan sharding against the framework’s chiplet devices rather than treating a whole chip as one undivided allocation.

Choose another configuration if…

A larger nominal memory number does not make a CUDA-only engine portable. Check the exact attention and MoE implementation on TPU7x.

Specifications with their boundaries attached

Architecture
TPU7x (Ironwood)
Memory
192 GiB HBM
Memory bandwidth
7.38 TB/s per accelerator
Peak compute
2,307 TFLOPS BF16; 4,614 TFLOPS FP8
Scale-up interconnect
ICI: specification table lists 1,200 GB/s bidirectional per chip; topology narrative separately says 200 GB/s per axis
Host attachment
Managed TPU host; 3D torus, 9,216-chip pod
Power
Not published in checked per-chip reference
Partitioning
Slice/chiplet allocation; not NVIDIA MIG
Catalogue status
Documented product

Compute figures are theoretical peaks at the stated precision. Dense and structured-sparse rates must not be mixed. Bandwidth labelled bidirectional combines both directions. See the source documents.

Follow the bytes · conceptual topology

Three bandwidths, three different jobs

Local memory192 GiB HBM
Compute enginesExecute kernels on these bytes
① Memory bandwidth: 7.38 TB/s
Chip AOwn local memory
Chip BOwn local memory
ICI inside a slice
ICI: specification table lists 1,200 GB/s bidirectional per chip; topology narrative separately says 200 GB/s per axis
Slice AAccelerators + host
Slice BAnother fabric domain
③ Scale-out: NICs + switches + placement
DCN between slices
A 400 Gb/s NIC has a 50 GB/s raw line-rate equivalent before overhead. A 900 GB/s bidirectional NVLink figure counts traffic in both directions. Neither is the bandwidth at which a GPU reads its own HBM. This diagram explains the boundaries; it is not a wiring diagram for a particular cloud machine.

Where it appears in provider documentation

Documented configurations, checked September 12, 2026. Listing does not guarantee regional stock, quota, allocation size or an on-demand purchase.
Provider / machineNetwork scopeWhat changes the decision
Google Cloud
TPU v7
ICI within a slice; DCN between slicesSelect a documented slice shape and supported region. Chip, chiplet, TensorCore, host and VM counts are not interchangeable.

Model fit and software support

These publisher or serving-engine documents mention this hardware family. They have not been reproduced on our machines.

No model-specific recipe in our reviewed set certifies this exact hardware. The memory calculator can narrow candidates, but it cannot establish software support. Read the model register.

What is the memory floor?

Start with total parameters, then add the memory the workload needs. This arithmetic does not certify a serving configuration. All output sizes below are decimal GB.

Override device capacity with the memory exposed by your allocation, particularly for cloud B300 and partitioned devices. The starting 32 GB budget and 15% reserve are editable teaching assumptions. They are not measurements for the selected model. Mixed-precision tensors, quantization scales, vision encoders and draft models can increase the weight payload.

320 GB

Raw weights only
320B × 8 bits ÷ 8

175.23 GB

Budget per device
206.16 GB × (1 − 15%)

3 devices

Arithmetic lower bound
round up ((weights + 32) ÷ budget)

WeightsCache + runtimeRemaining budget

This assumes perfectly balanced sharding. A result of three does not prove that a three-device parallel layout is supported. Check layer/expert divisibility, actual allocatable memory, precision kernels and the fabric before renting.

320B is the model card’s total; 18B active is not its storage size. The vLLM recipe reports about 306 GiB for the native FP8 checkpoint. Hopper requires BF16 KV for this model; the documented ROCm path targets gfx950, not every Instinct GPU. Read the model source ↗

For full training, also budget gradients, optimizer states, activations and communication buffers. The inference weight estimate above is insufficient.

Tokens per second, TTFT and TPOT are not certified for this hardware in our reference. Use the benchmark checklist to compare an exact model, software revision and workload.

Nearby memory capacities, different tradeoffs

These are comparison candidates selected by memory capacity, not performance rankings or drop-in replacements.

Google TPU 8t

216 GB · 6.53 TB/s

Google’s announced eighth-generation training design. It emphasizes large-scale pre-training, a 3D torus and a new scale-out network.

Google TPU 8i

288 GB · 8.6 TB/s

Google’s announced eighth-generation serving design. Larger SRAM and Boardfly target communication and state movement in reasoning workloads.

Google TPU v5p

95 GiB · 2.77 TB/s

A large-pod training TPU with 95 GiB per chip, much more memory than v5e. The suffix identifies a different design, not a larger v5e VM.

Sources and review scope

Manufacturer and cloud documentation checked 2026-09-12. We reviewed specifications and the stated product boundaries; we did not run training or serving benchmarks on this device. Cloud memory and availability can differ by configuration.

  1. Google TPU7x architecture · checked 2026-09-12

Cite this reference

AI Infra Interviews. Google TPU7x (Ironwood): specifications and workload fit. Reviewed . https://aiinfrainterviews.com/hardware/tpu-v7

Include your access date when citing a changing specification. Link to the specification section for hardware figures or the explanation for a sizing or workload decision.

Research method and limits

We compile manufacturer specifications, cloud documentation, model cards and serving recipes. The reference preserves source units and distinguishes individual devices from nodes and racks. Conflicting figures and unknown fields remain labelled.

Our contribution is the comparison, unit reconciliation, worked arithmetic and workload explanation. Published peaks are vendor specifications. Calculator results are estimates under the displayed assumptions. Neither is a measurement from our own accelerator lab.

For a manufacturer’s specification, consult the original source documents. Cite our page when using its analysis, and retain primary-source attribution for underlying figures. This curated reference does not establish market share, live availability or a universal performance ranking.

Found a discrepancy? Send a correction with the page URL, exact variant, disputed figure and supporting primary document.