OCP Global Summit 2026 | Google | Sunil Ahluwalia, Jeongkeun "JK" Lee | Inside Google's Virgo Network and the Campus-as-a-Computer

1. A Networking Deep Dive Overshadowed by the Keynote

Google's keynote at this year's summit (Partha Ranganathan) listed Palomar MEMS OCS as one of eight AI system innovations, but gave no details. The session that actually opened up Google's AI network was this one in the AI Clusters track: Group Product Manager Sunil Ahluwalia and Software Engineer Jeongkeun "JK" Lee (introduced by Ahluwalia as the technical lead for Virgo networks).

Ahluwalia split Google's 25 years of networking into four eras: SDN, Jupiter and Apollo in the Internet era; QUIC and TCP BBR in the streaming era; Andromeda, Swift and Falcon in the cloud era; and now the AI era, whose centerpiece is Virgo.

The AI-era requirements are on slide 3:

• In 2026 Google shipped Gemini 3.5, 3.6, 3.7 and 3.8, and customers' direct API use exceeds 22 billion tokens per minute.

• Scale-out network bandwidth per GPU went from under 100 Gbps in 2016, plateaued around 400 Gbps from 2022 to 2024, and jumped to about 1,600 Gbps in 2026 (the curve carries no data labels; this is an STT chart reading).

• Deployments are moving from a single data center to multiple data centers and multiple campuses.

Per-GPU network bandwidth quadrupled in two years; the network can no longer be designed as generic infrastructure.

2. Three Networks, Each Owning One Layer

Google splits its data center network into three independent domains that together form a "campus as a computer":

• Scale-up: NVLink for GPUs, ICI for TPUs. JK Lee described the TPU layer verbally as OCS-based ICI (not labeled on the slide; this is Google's previously published TPU pod architecture).

• Scale-out backend (Virgo): a dedicated accelerator backend connecting pod to pod, with one for GPUs and one for TPUs.

• Front end (Jupiter): connects storage and general compute, can be shared by multiple AI clusters in the same building, and can carry cross-campus training over the WAN.

▲ Google's three data center network domains: GPU/TPU scale-up, the Virgo scale-out backend, and the Jupiter frontend and WAN (Image source: Google | 2026 OCP Global Summit presentation)

There are three design principles (slide 4): design for the whole campus, a single link or switch failure must not crash a training job, and minimize network layers and deployment materials. JK Lee added a key remark: Virgo's deployment and operations lifecycle is tied to the GPU/TPU cluster, so backward compatibility is no longer a strong requirement. STT's reading: the backend network will be replaced wholesale with each accelerator generation.

3. Breaking Down Skinny Links: SerDes Speed as Port Speed

Virgo's topology has only two layers (leaf and spine), and each plane has its own independent control plane, so a software failure in one plane does not spread. What makes two layers possible is the skinny link: from accelerator to leaf and from leaf to spine, every link runs at the speed of a single SerDes lane, currently 200G.

▲ Virgo architecture: two switching tiers, N independent planes and SerDes-level skinny links, with Apollo OCS appearing only on the Jupiter side (Image source: Google | 2026 OCP Global Summit presentation)

The number of planes N roughly equals the number of skinny links per accelerator. JK Lee's example was NVIDIA Vera Rubin: each chip needs 1.6T, and 1.6T divided by 200G gives 8 planes. Two effects follow:

• Reliability: if a plane, a NIC link or a switch fails, the chip keeps 7/8, or 87.5%, of its bandwidth; he said a single failure in some earlier generations could cost 50% or even 100%.

• Scalability: higher chip bandwidth means adding planes, not a third layer.

The math is simple. A 2-layer non-blocking fabric can connect roughly the square of the switch port count divided by two. Google did not say which switch generation it uses, so the following is an STT estimate assuming a 102.4T switch:

Port speed	Ports per switch	Endpoints per plane
1.6T (fat link)	64	~2,048
200G (skinny link)	512	~131,072

▲ With the same 102.4T switch, 200G skinny links raise the endpoints per plane of a two-tier network by 64x, and a single plane failure still leaves 87.5% of bandwidth (Image source: Simple Tech Trend original; data from Google 2026 OCP Global Summit presentation)

The 64x gap is exactly the speed ratio of 8, squared. By STT's inference, dropping the third layer means dropping a whole layer of switches and their optical modules; JK Lee's own words were that fewer layers mean fewer racks and fibers, and faster cluster turn-up.

This direction is not unique to Google, and JK Lee noted the industry is already adopting multi-plane heavily. The difference is that Google made it a design principle: the plane count follows SerDes, not optical module specs.

4. Breaking Down Routing and Telemetry: Beyond Packet Spraying, You Need Visibility

Skinny links create many parallel paths, and Virgo uses two kinds of packet-level load balancing to fill them:

• Switch-driven adaptive routing: switches coordinate with each other and react quickly to local congestion, failures and downstream switch failures.

• SRv6 source routing: for bare-metal customers bringing their own host stack, who control the path of every packet themselves. JK Lee's spoken example was MRC (from auto-generated captions; not confirmed on the slides).

Congestion always happens, so slide 8 lists three telemetry technologies:

• CSIG (Congestion Signaling): an in-band protocol that gives end hosts fine-grained switch congestion signals; the next step is extending it into UEC for sub-RTT congestion control.

• HST (High-speed Switch Telemetry): sub-millisecond port and queue status.

• Firefly: microsecond-level NIC clock synchronization for timestamping and debugging.

The transport layer echoes the collaboration announced in the keynote: Falcon, contributed by Google to OCP in 2023, now extends from NVIDIA ConnectX to BlueField, with full wire-format interop and standard IB Verbs support. Both companies' NICs run the same transport, and applications do not need to change.

5. Where Is OCS: The Most Valuable Two Minutes of Q&A

During Q&A, someone from the optics industry asked directly: the slides show Apollo OCS, so how does it relate to the packet-switched backend?

JK Lee's answer boils down to three points:

• Apollo is an OCS building block used in the Jupiter front end. He did not say Virgo uses no OCS at all, but the Virgo side of the slides shows only 2-layer packet switching.

• OCS is useful for scale-across. For example, you start by connecting two buildings or two campuses and later add a third; to keep utilization high you need to restripe, and OCS's biggest benefit is very fast restriping.

• The cost is upfront capex and deployment time, because another OCS layer has to be added. He called it "a trade-off we are considering right now", and said OCS is not the only option, as new patch panel technologies are coming in (from auto-generated captions; this term is STT's reading).

▲ Where OCS sits in Google's three-tier network: used in TPU ICI (per the speaker) and the Jupiter frontend, not seen on the Virgo backend slides, and being weighed against patch panels for cross-campus scale-across (Image source: Simple Tech Trend original; data from Google 2026 OCP Global Summit presentation and Q&A)

This answer matters. In ECOC2026 | 95% of OCS Shipments Are One Company's Business: Google we wrote about how concentrated the OCS market is. Based on the architecture disclosed in this session, Google's OCS demand sits mainly in TPU ICI and the front end, not in the expansion of the AI backend. If this architecture holds, more Google GPU clusters grow packet switches and 200G links in the backend, not OCS.

6. Risks and Counterarguments

• Scale figures were not disclosed: how many switches per plane, which silicon generation, and how many accelerators per cluster are not on the slides. The 131k endpoints in this article are an STT estimate based on an assumption.

• "No OCS in the backend" is inferred from the slides: the speakers did not explicitly rule out OCS; if there is an undisclosed optical switching layer, this reading needs revising.

• The bandwidth curve is a chart reading: 1,600 Gbps is STT's reading of the chart, consistent with the spoken 1.6T per Vera Rubin chip.

• OCS's role could reverse: if cross-campus connectivity changes often, the value of fast restriping could outweigh the upfront cost, and OCS could extend into the scale-across backend.

• The optical cost of skinny links was not laid out: splitting 1.6T into 8 x 200G scales fibers, connectors and breakouts linearly with the plane count, and Google gave no fiber numbers.

• The Falcon-UEC relationship is still unsettled: Google is pushing Falcon interop while bringing CSIG into UEC; whether they converge into one protocol remains to be seen.

7. What It Means for Taiwan's Supply Chain

The session named no Taiwanese companies, so the following covers product categories only.

• A single 200G lane is the basic unit of the backend. Virgo's port speed follows SerDes, so when the next SerDes generation arrives the whole backend changes with it, and backward compatibility is not required. For switch and optical module suppliers, this means refresh cycles tied to accelerators and concentrated volumes.

• Breakout and fiber management are incremental demand. By STT's inference, splitting 1.6T across 8 planes means each accelerator fans out 8 independent links, so patch cords, breakout cables and fiber cabling scale with the plane count. We covered what it costs when fiber count becomes the bottleneck in It Wasn't Physics That Killed Slow-and-Wide, It Was 60,000 Fibers (in Chinese).

• Incremental OCS supply-chain demand depends on cross-campus decisions. The backend disclosed here shows no OCS, so OCS growth depends on TPU ICI and the front end; if scale-across goes with patch panels, that increment gets split.

• One fewer switching layer means one fewer layer of optics. The 2-layer architecture removes the layer above the spine, which weighs on optical modules per accelerator; optics growth has to come from accelerator counts and SerDes upgrades, not network layers.

8. Conclusion

The key takeaway is a correction: in the architecture Google disclosed this time, OCS is not in the AI backend. Virgo uses 2-layer packet switching, 200G skinny links and 8 independent planes to gain scale, reliability and deployment speed at once; OCS stays in TPU ICI and the Jupiter front end, and the cross-campus layer is still being weighed against patch panels.

Timing has to be read separately. Virgo will launch with Google Cloud's next GPU and TPU platforms; a long-haul RDMA backend for scale-across and bringing CSIG into UEC are next. Over the next 12 months, watch three things: whether multi-campus Virgo expansion uses OCS or patch panels, whether Google discloses Virgo's switch generation and cluster scale, and whether Falcon and UEC converge on one spec.

What grows Google's AI backend is 200G skinny links and two-layer switching, not OCS.

This article is for technology and industry trend analysis only and does not constitute investment advice.