Google TPU7x (Ironwood)

Per-CHIP figures. TPU7x is the first release in the Ironwood family, Google's seventh-generation TPU, and the current-generation part in this repo. Google positions it as the large-pod training/inference part: 9216 chips per pod, sharing 'many similarities' with v5p. Named for a metal, like Trillium (v6e); the two codenames are DIFFERENT GENERATIONS and are not interchangeable - see gotcha w7x-gotcha-ironwood-is-tpu7x-not-trillium. WHAT GOOGLE DOES PUBLISH, per generation, for a multi-host deployment: HBM 192 GiB per chip at 7380 GB/s; ICI 1200 GBps bidirectional per chip, DCN 100 Gbps per chip; pod scale 9216 chips. The topology section additionally publishes 'bi-directional bandwidth of 200 GBps per axis for communication between chips within a pod' on a 3D torus - that per-axis figure and the 1200 GBps per-chip aggregate are different quantities on different axes of the same table and must not be substituted for one another. Beyond the pod, multislice extends connectivity over the DCN. Four chips per TPU7x VM, 224 vCPUs and 960 GB RAM per VM, 2 NUMA nodes. THE DUAL-CHIPLET ARCHITECTURE IS THE HEADLINE AND THE MAIN SCOPE TRAP. Every earlier Google part here is a single logical core (a 'MegaCore'); TPU7x is composed of two chiplets, each with its own TensorCore, two SparseCores and its own 96 GB of HBM, connected by a die-to-die interface that Google states is six times faster than a 1D ICI link. CONSEQUENCE FOR EVERY FIGURE ABOVE: vram_gb 192 and memory_bandwidth_gbps 7380 are per CHIP and are the SUM of two independent 96 GB memories. The two are NOT one address space - Google states this is 'a departure from the unified memory space of the MegaCore architecture'. This is the ONLY Google accelerator in this repo with unified_memory=false, and a reader who treats it as unified will size a sharding plan wrong by 2x. (Across the whole repo false is the majority value for this field, so the flag alone will not flag TPU7x as unusual - it is unusual only RELATIVE to its own four predecessors, which are all true.) JAX exposes each chiplet as a separate 'device' (two devices per chip) and adds a fourth dimension to the topology tuple to select chiplets. VERIFIED NEGATIVE - TDP. tdp_w is null. Google's TPU7x page publishes no power row at all - not TDP, not measured min/mean/max, unlike v3 and v4 which carry measured figures and v2 which carries a paper TDP. No figure was carried across from another generation; for reference the v5p/v6e rows in the same comparison table carry no power column either, so there is no in-family value to infer from. VERIFIED NEGATIVE - PROCESS NODE AND BUS WIDTH. Both null: the TPU7x page publishes no process node and no memory bus width, and none was estimated or back-computed from 7380 GB/s. COMPUTE-TO-BYTE, and why this part is different in kind from the ones before it: 2307e12/7380e9 = 313 FLOP/byte BF16. That is below v6e's 560 (google-tpu-v6e), so on a pure per-chip arithmetic-intensity comparison TPU7x is LESS compute-dense per byte than the smaller inference part. What changes is the absolute envelope - 192 GiB per chip and 9216 chips per pod - and Google's own framing that 'despite its size, HBM can still be a bottleneck, particularly for memory-bound vector operations'. The memory hierarchy is HBM -> Vector memory (VMEM, on-chip SRAM scratchpad whose size is a tunable parameter for Pallas kernels) -> host memory over PCIe, with host offload of activations or optimizer states as the documented pressure valve. SparseCore count is 4 per chip, same as v5p, versus 2 on v6e. COMPARISON-TRAP, recorded because this table is the first place a reader will make the error: Google's own TPU7x table prints v5p FP8 = 459, identical to v5p BF16 = 459. That is the contested figure in google-tpu-v5p, and here it sits in the same row as TPU7x's own clean 2x doubling, which makes the v5p non-doubling look like an error rather than what google-tpu-v5p records it as. It is a documentation inconsistency in the vendor's own comparison table, not a transcription error.