Cloud TPU v4 ICI (inter-chip interconnect), 3D mesh reconfigurable to 3D torus, 4096-chip pod

NO PER-CHIP ICI BANDWIDTH IS PUBLISHED FOR v4, and none is inferred here. Google's v4 page gives pod-level capacity and collective bandwidth (TPU Pod size 4096 chips; all-reduce bandwidth per pod 1.1 PB/s; bisection bandwidth per pod 24 TB/s) and a link COUNT - 'Six interconnect links per chip to enable network topologies that have smaller network diameters' - but no per-chip ICI bandwidth in GB/s. The typed value is deliberately null rather than back-derived from the pod figures: dividing 1.1 PB/s all-reduce by 4096 chips would give a per-chip number that is an artefact of the collective algorithm's overlap, not a link rate, and there is no published link rate to compare it against. The v4 architecture paper (arXiv 2304.01433) is the source for the optical circuit switching between cubes and is cited for topology only. CONSEQUENCE FOR THIS REPO: the previous combined google-tpu-ici record typed a per-direction number taken from v5e and carried v4 in its version string; a reader filtering that record by generation could not tell which generation a number belonged to, so v4 is now its own record with an explicitly absent number.

3D MESH by default, RECONFIGURABLE TO A 3D TORUS - and the distinction is Google's, stated precisely, not an approximation. Google: 'v4 TPUs have a direct connection to the nearest neighboring chips in 3 dimensions, resulting in a 3D mesh of networking connections. The connections can be configured as a 3D torus on slices where the topology, AxBxC, is either 2A=B=C or 2A=2B=C, where each dimension is a multiple of 4', with 4x4x8, 4x8x8 and 12x12x24 given as examples, and 'In general, the performance of a 3D torus configuration will be better than a 3D mesh configuration'. So the topology a v4 job gets is a function of the slice SHAPE: only slices whose dimensions satisfy 2A=B=C or 2A=2B=C (each a multiple of 4) are tori, and other shapes are meshes. That is the concrete reason bisection bandwidth cannot be read off a chip count for v4. Google's own pod-level numbers show the gap: all-reduce 1.1 PB/s against bisection 24 TB/s per pod, a ratio of about 46, the worst all-reduce-to-bisection ratio of any generation in this set - worse than the 32 of v5e and v6e. TWISTED TORUS, supported on v4 and v5p: on supported shapes Google publishes a theoretical bisection-bandwidth increase of ~70% for 4x4x8 and ~40% for 4x8x8 versus the untwisted torus, and reports 1-2 percentage point MFU improvements on the FSDP MaxText model. Larger slices are built from 4x4x4 'cubes' with optical circuit switches between cubes; ICI resiliency routes around OCS and optical faults, and within-cube copper links are unaffected.

ICI is the scale-up fabric and the scale-up domain is the 4096-chip POD - which is two orders of magnitude larger than the 8-GPU NVSwitch domain and two orders larger than v5e/v6e's 256-chip pod. Google's documented boundary is ICI versus DCN rather than 'scale-up'/'scale-out': ICI is 'high speed, low latency internal links that connect TPUs within a TPU Pod'; cross-slice traffic goes 'by transferring data to CPUs (hosts) which in turn transmit the data over the data-center network (DCN)', 'a higher latency, lower-throughput network (when compared with ICI)'. The booleans are this repo's mapping of that boundary. SCALE-OUT: the v4 page publishes NO per-host NIC configuration and NO DCN bandwidth per pod or per chip, unlike v5e, v6e and v5p - the only scale-out figure available for v4 anywhere in this record set is the statement that Multislice permits 'more than 4096 chips in a single run' for v4. The absence is recorded rather than filled: a reader needing v4's DCN rate must go to Multislice, which does not publish a per-chip or per-pod DCN bandwidth for v4 either.

The generation to point a reader at for the torus argument, because its 46:1 all-reduce-to-bisection ratio is the starkest in this set and because its topology is genuinely conditional - mesh or torus depending on slice shape - which is a trap for anyone who reads '3D mesh' as the whole story. HOST PACKING AND SMALL SLICES: v4 slice names are TensorCore-based, so v4-8 is 4 chips, v4-16 is 8, v4-32 is 16, v4-64 is 32, and larger slices come in 64-chip increments (v4-128 = 64 chips at 4x4x4, up to v4-4096 = 2048 chips at 8x16x16). Reading a v4 slice name as a chip count overstates it by 2x, which then corrupts any model-fit arithmetic done from the name. V4 HAS NO 'Chips per host' ROW on its spec page - unlike v5e and v6e, which both publish it - so v4 host packing cannot be read from the sheet and is not recorded here. FIT DECISION: the 4096-chip pod x 32 GiB HBM is the scale-up-domain ceiling, and the practical sharding boundary for anything larger is Multislice over DCN; within one pod the constraint is the slice shape, since only certain shapes give a torus. CONTRAST WITH v5p: v5p is a 3D torus by default with an 8960-chip pod, whereas v4 is a 3D mesh that becomes a torus only on conforming shapes, so 'v4 and v5p are both 3D tori' is wrong. Sources: asic-tpu-v4-specs for every pod-level figure, the 3D mesh/torus conditions, the twisted-topology table and the six-links-per-chip statement; asic-tpu-v4-paper for optical circuit switching between cubes; w7c-google-tpu-multislice-overview for the ICI/DCN definitions. === THE HALVING IS NOT AN ASSUMPTION — CONFIRMED 2026-10-08 (w8-reverify) AGAINST GOOGLE'S OWN POD-LEVEL FIGURES. === Wave 7 recorded Google's ICI figures as bidirectional aggregates with the typed value being the per-direction half. That is a halving decision, and a halving decision is only defensible if something OUTSIDE the spec table forces it. Two independent things do. (1) Google's own row label, verbatim on both the v5e and v6e spec tables: 'Bidirectional inter-chip interconnect (ICI) bandwidth (per chip) 400 GBps' / '... 800 GBps'. The word 'Bidirectional' is Google's, and the table gives the port count beside it ('ICI ports per chip 4'), so the figure is an aggregate per chip, not per port and not per direction. (2) THE CLOSING ARITHMETIC, which is the real proof and is reproduced here so it does not have to be re-derived: Google publishes the all-reduce bandwidth per pod for the same generations. v5e: 'All-reduce bandwidth per Pod 51.2 TB/s' with a 256-chip pod; 256 x 200 GB/s per direction = 51.2 TB/s, EXACTLY. v6e: 'All-reduce bandwidth per Pod 102.4 TB/s' with a 256-chip pod; 256 x 400 GB/s per direction = 102.4 TB/s, EXACTLY. Both close on the HALVED figure and both would be 2x too high on the unhalved one. So an all-reduce over 256 chips at the per-direction rate reproduces Google's published pod collective bandwidth to the digit - the halving is what Google's own numbers require, not a convention this repo imposed on them. (3) A unit trap in the same table, recorded so it is not re-fallen-into: Google writes 'GBps' for the ICI row and 'Gbps'/'Tbps' for the DCN and NIC rows of the SAME table, so the units are mixed within one sheet and ICI figures are gigabytes. WHAT WAS ALSO VERIFIED AND IS CORRECT: v4 has no per-chip ICI bandwidth published (Google gives six links per chip and pod-level 1.1 PB/s all-reduce / 24 TB/s bisection but no per-chip GB/s), so its typed null is the honest value and not a gap to fill by dividing 1.1 PB/s by 4096 - that would be an artefact of the collective algorithm's overlap, not a link rate. v5p's 1200 GBps -> 600 per-direction is labelled 'Bidirectional inter-chip interconnect (ICI) bandwidth per chip' on the live v5p table and carries no port count, so no per-port figure is derivable and none is recorded. 2026-10-10: set null_bandwidth=sourcing. The record's own bandwidth_basis already says this; the field only names the case. No number changed. Same as v3: pod all-reduce 1.1 PB/s and a link count of six, but no per-chip GB/s, and the basis refuses the division. Aggregate published, per-link rate not.