Most coverage of Google’s AI infrastructure focuses on the TPU chip itself — Trillium, Ironwood, their FLOPS and memory bandwidth. But a chip is only as fast as the network connecting it to thousands of others. Google’s answer at the data-center scale is Jupiter, a network fabric built around optical circuit switching (OCS) that Google has been evolving in production since 2015, and which Google’s own TPU documentation says is what lets individual TPU superpods be wired together into clusters of hundreds of thousands of chips. This piece is about that fabric, not the chips themselves.
AT A GLANCE
| Fact | Detail |
|---|---|
| What it is | Google’s data-center network fabric, built on optical circuit switches (OCS) and centralized software-defined networking (SDN) |
| Who makes it | Google (first deployed 2015; evolution published at SIGCOMM 2022 as “Jupiter Evolving”) |
| Primary use case | Uniform, high-bandwidth, low-latency connectivity across tens of thousands of servers and accelerators in a Google data center; at the TPU level, Google states it is what links multiple TPU “superpods” into much larger training/inference clusters |
| Where it fits in the stack | Sits above the TPU-specific interconnect (ICI and in-pod OCS) — Jupiter/the Data-Center Network (DCN) is the layer that connects whole superpods to each other and to the rest of Google’s infrastructure |
| Scale (per Google’s own published figures) | 2015 deployment: 30,000+ servers, 1+ Pb/s aggregate bandwidth. By 2022: 6+ Pb/s of data-center bandwidth, with Google reporting 5x higher speed/capacity, 30% lower capex, and 41% lower power versus the prior architecture |
Short Verdict
Jupiter is one of the least-discussed but most load-bearing pieces of Google’s AI infrastructure. Instead of fixed electrical switches wired into a rigid spine-and-leaf topology, Google uses mirror-based optical switches that can redirect light between any two points in the building without touching a cable. That lets Google reconfigure the network’s shape in software, route around failures in milliseconds, and upgrade link speeds one section at a time instead of ripping out an entire data center’s spine. For TPU training, Google’s own technical blog states plainly that this network — which it calls Jupiter in its 2022 research publication and simply the “Data-Center Network” in its 2025 Ironwood materials — is the layer that stitches individual superpods together into the massive clusters needed for frontier-scale AI training.
What Jupiter Actually Is
According to Google’s own Cloud blog and its peer-reviewed SIGCOMM 2022 paper (“Jupiter Evolving: Transforming Google’s Datacenter Network via Optical Circuit Switches and Software-Defined Networking”), Jupiter is the data-center network fabric connecting the servers, storage, and accelerators inside Google’s warehouse-scale computers. It was first deployed in 2015, built on three ideas: a logically centralized software-defined networking (SDN) control plane managing thousands of switching chips, a Clos (non-blocking, multistage) network topology, and commodity “merchant silicon” switching hardware. At that scale, Google reports more than 30,000 servers in a single deployment, uniform 40 Gb/s per-server links, and more than 1 petabit per second of aggregate bandwidth, guaranteeing sub-100-microsecond latency for arbitrary server-to-server communication.
Why Optical Circuit Switching
The original Clos design had a structural limitation Google’s paper describes directly: the network’s “spine” layer has to be fast enough to match whatever the newest, fastest attached devices need, and every part of the building needs full fanout to that spine. Upgrading link speeds across a live data center meant replacing the entire spine at once — expensive and operationally disruptive. Google’s fix was to insert a layer of MEMS-based optical circuit switches between aggregation blocks. An OCS doesn’t parse or route packets at all; it uses two sets of mirrors that physically rotate to redirect light from an input fiber to an output fiber, which makes it agnostic to data rate and wavelength. That means the optical layer can sit in the building’s infrastructure indefinitely while the electrical switches behind it are upgraded independently, and Google’s centralized Orion SDN control plane can reconfigure which blocks are connected to which — in effect rewiring the building’s logical topology in software, coordinating link drains, routing changes, and OCS reconfiguration together.
Google’s SIGCOMM paper reports that this direct-connect, OCS-based approach achieved roughly 5x higher speed and capacity over a decade of production use, alongside a 30% reduction in capital expenditure and a 41% reduction in power, while being deployed incrementally against live production traffic. About 60% of production traffic takes a direct path between source and destination blocks in this topology, with the rest transiting one additional block, and OCS-based reconfiguration is reported as roughly 3x faster than the patch-panel-based fiber changes it replaced.
How This Differs From the TPU’s Own Interconnect
It’s important to separate two distinct optical-switching layers in Google’s AI stack, both documented in Google’s own materials but at different scopes:
- Inter-Chip Interconnect (ICI) and in-pod OCS: This is the TPU-specific fabric that wires individual chips into a pod and a pod into a superpod. Google’s published TPU v4 research paper describes using 48 MEMS-based “Palomar” optical circuit switches to link 64-chip blocks into a 4,096-chip, 3D-torus supercomputer, letting Google reconfigure the torus topology in software and route around failed hosts rather than requiring near-perfect hardware availability. For the current Ironwood TPU generation, Google’s Cloud blog describes the same OCS pattern operating at the “cube” (64 chips) and “superpod” (9,216 chips, 144 cubes) level, with the OCS fabric manager able to optically bypass a failed cube or link and swap in a spare.
- Jupiter / the Data-Center Network (DCN): This is the general-purpose fabric, described in Google’s 2022 Jupiter paper, that connects whole superpods, and everything else in the data center, to each other. Google’s 2025 Ironwood announcement states explicitly that for the largest-scale systems — into the hundreds of thousands of chips — multiple superpods are connected via this standard data-center network, with other Google materials naming that network Jupiter.
In short: OCS does double duty in Google’s stack, but at two different scales, built by overlapping but distinct engineering efforts — one wires chips into a pod, the other wires pods into a building-spanning, and ultimately campus-spanning, cluster.
Jupiter vs. In-Pod TPU Optical Switching
| Dimension | In-pod/superpod OCS (ICI layer) | Jupiter / Data-Center Network |
|---|---|---|
| Scope | Chips within a cube/pod/superpod (up to 9,216 TPU chips on Ironwood) | Connecting whole superpods and other data-center infrastructure to each other |
| Documented scale | TPU v4: 4,096 chips via 48 Palomar OCSes; Ironwood: 9,216-chip superpods built from 144 cubes | 2015: 30,000+ servers, 1+ Pb/s; 2022: 6+ Pb/s aggregate bandwidth |
| Key benefit cited by Google | Software-configurable torus topology; tolerates 0.1%–1.0% host unavailability without rewiring | 5x higher speed/capacity, 30% lower capex, 41% lower power over a decade of production use (SIGCOMM 2022) |
| Stated role for largest AI clusters | Builds the superpod itself | Connects multiple superpods into clusters of “hundreds of thousands” of chips, per Google’s Ironwood blog |
Trade-offs
| Pros | Cons / Open Questions |
|---|---|
| Software-reconfigurable topology avoids physical rewiring for upgrades or failure recovery | Google’s own published figures for Jupiter mostly predate the current TPU generation (2015/2022); up-to-date bandwidth/latency figures for connecting Ironwood-era superpods specifically are not published in the sources reviewed here |
| OCS is data-rate agnostic, letting link speeds be upgraded incrementally rather than building-wide | All performance figures (5x speed/capacity, 30% lower capex, etc.) are Google’s own claims from its SIGCOMM paper, not independently audited |
| Fault tolerance: can bypass failed hardware optically, in milliseconds, rather than failing the whole topology | Exact bandwidth/latency specifically for the Jupiter layer connecting multiple TPU superpods (as opposed to the in-pod ICI figures) is not broken out in Google’s public TPU materials |
Who This Matters To
Infrastructure engineers and researchers evaluating why Google can plausibly offer TPU training clusters at the scale of hundreds of thousands of chips — the answer isn’t just more chips, it’s a network layer purpose-built to reconfigure itself around those chips in software. It’s also relevant to anyone comparing Google’s approach to Nvidia’s NVLink/InfiniBand/Spectrum-X stack or AWS’s EFA: all three hyperscalers have converged on optical and software-defined techniques for scale-out AI networking, but Google’s OCS-centric approach, deployed for general-purpose data-center traffic since 2015 and later adapted to TPU pods, is the most publicly documented example of reusing a decade-old general networking investment for AI-specific scale-out.
Who Should Look Elsewhere
Readers looking for exact current bandwidth and latency numbers for Jupiter connecting today’s Ironwood-generation superpods specifically won’t find them in Google’s public materials as of this writing — Google’s most detailed published Jupiter figures are from its 2015 and 2022 (SIGCOMM) disclosures, which predate Ironwood and describe general data-center traffic rather than TPU-cluster-to-TPU-cluster traffic specifically. Readers wanting to compare raw chip-level FLOPS or pricing across Trillium, Ironwood, and Nvidia GPUs should look at TPU-chip-focused coverage instead; this piece deliberately stays at the network layer.
Bottom Line
Jupiter is Google’s general-purpose, OCS-based data-center network, in production since 2015 and significantly reworked by 2022 to use direct-connect topologies managed by centralized SDN. It is distinct from, but complementary to, the optical circuit switching Google also uses inside TPU pods and superpods to wire individual chips together. Per Google’s own 2025 Ironwood materials, it’s this outer network layer — not the in-pod interconnect — that lets Google link multiple 9,216-chip superpods into AI clusters reaching into the hundreds of thousands of chips. The chips get the headlines; the fabric is what makes clustering them at that scale possible at all.
FAQ
Is Jupiter the same thing as the optical switching inside a TPU pod?
No. Google documents two separate uses of optical circuit switching: one inside TPU pods/superpods (wiring chips and cubes together, as described in the TPU v4 paper and Ironwood blog), and Jupiter, the broader data-center network that connects whole superpods and other infrastructure to each other.
How big is a Jupiter deployment?
Google’s 2015 disclosure describes a single deployment of more than 30,000 servers with over 1 Pb/s of aggregate bandwidth; by 2022, Google reported more than 6 Pb/s of data-center bandwidth using the evolved, OCS-based architecture.
What is an optical circuit switch, technically?
Per Google’s published description, it’s a switch that uses two sets of MEMS mirrors, rotating in two dimensions, to redirect light from an input fiber to an output fiber without parsing or routing packets — making it transparent to the data rate and wavelength of the signal passing through it.
How many TPU chips can a single Jupiter-connected cluster reach?
Google’s Ironwood materials state that individual superpods reach 9,216 chips, and that connecting multiple superpods via the data-center network (Jupiter) scales to “hundreds of thousands” of chips. Google does not publish an exact maximum chip count for a single cluster in the sources reviewed for this article.
Sources
- Google Cloud Blog: The evolution of Google’s Jupiter data center network
- Google Research: Jupiter Evolving (SIGCOMM 2022 paper)
- Google: TPU v4 — An Optically Reconfigurable Supercomputer for Machine Learning (ISCA 2023 paper)
- Google Cloud Blog: Ironwood TPUs and new Axion-based VMs for your AI workloads
- Google Cloud Blog: Inside the Ironwood TPU co-designed AI stack
Related reading: Google’s TPU Chips Explained and Google’s Axion Arm CPUs Explained.
Discover more from Software Online Review
Subscribe to get the latest posts sent to your email.
