Google 把答案寫進 13.4 萬顆 TPU：Virgo Network 揭曉的，是一場 OCS 的勝利
- 6月5日
- 讀畢需時 5 分鐘
當大家還在爭論 CPO（共封裝光學，Co-Packaged Optics）哪一年量產，Google 在 2026 年 Cloud Next 上直接把一整代答案攤在桌上。它的名字叫 Virgo Network——一張能把 13.4 萬顆 TPU 黏成「一台機器」的網路，而真正撐起這張網路的，不是什麼前衛封裝，而是一個 Google 自己默默做了六年的東西：光路交換（Optical Circuit Switch，OCS）。 Virgo 是 Google 隨第八代 TPU 8t 一起推出的 scale-out 資料中心 fabric。單一 fabric 可連 13.4 萬顆 TPU、47 Pb/s 非阻塞雙向頻寬，再靠 Pathways 把多張 fabric 拼成超過 100 萬顆 TPU 的邏輯訓練集群。它對光通訊供應鏈最關鍵的訊號是：受惠的是「海量可插拔光模組 + 自研 OCS」，CPO 這一局還沒輪到上場。
1. 百萬卡訓練真正卡住的，從來不是算力
訓練一個前沿模型，瓶頸早就不在單顆晶片夠不夠快。當你要把幾萬顆加速器同時餵飽、讓它們像一顆晶片一樣同步運算，問題會變成一個很樸素的工程題：晶片跟晶片之間的資料，到底要繞幾層交換機、走幾跳（hop）、塞不塞得下、會不會某一顆壞了就拖垮全場。
這就是「scale-out」要解的事。它跟「scale-up」是兩件事，市場常常混為一談：scale-up 是在一個 pod 內部、用超高頻寬把鄰近晶片黏成一個大記憶體域（TPU 走的是 ICI、GPU 走的是 NVLink）；scale-out 則是橫向把一個個 pod、一座座機房串成一個邏輯集群。Virgo 管的，是後者。
Google 之所以要為 TPU 8t 另起一張新網路，是因為新晶片的胃口大到舊網路餵不動——Virgo 把每顆加速器的資料中心網路（DCN）頻寬一口氣拉到上一代的 4 倍。網路不升級，再強的晶片也只是被網路餓著。
2. Virgo 是什麼：把網路「壓扁」的一張 fabric
用一句話說：Virgo 是一張扁平、兩層、非阻塞（non-blocking）的網路。
傳統資料中心網路像一棟很多層的大樓，封包要上上下下爬好幾層樓梯才能到對面。Virgo 換成 high-radix（高基數）交換機——簡單講就是「每台交換機的孔位變多」，一台能接的對象變多，於是整張網路需要的樓層就變少。樓層少，延遲自然低：Virgo 的 unloaded fabric latency 比上一代低了 40%。對動輒同步上萬顆晶片的訓練任務來說，延遲的「可預測性」比峰值頻寬更值錢。
它還是 multi-planar（多平面）設計，把網路切成多個彼此獨立的控制域。白話說，就是不要把雞蛋放同一個籃子——一個平面出事，不會整張網拖下水。
3. 三個你該背起來的數字
13.4 萬顆 TPU／單一 fabric。一張 Virgo fabric 可以連超過 134,000 顆 TPU 8t。（順帶更正一個常見口誤：是 134K，不是 13,440，這兩個差一個量級。）再往上，靠 Pathways／JAX 軟體棧，可以把多張 fabric 跨資料中心拼成超過 100 萬顆 TPU 的單一邏輯集群。
47 Pb/s 非阻塞雙向頻寬。「非阻塞」是重點——意思是理論上任意一半晶片要跟另一半全速對打，網路都塞得下、不會打架。這是衡量一張訓練網路「夠不夠格」的硬指標。
7 跳（從 16 跳砍到 7）。透過 OCS 把最多 36 個 group（每個 group 最多 1,024 顆 active chip）串成一個完整 pod，任意兩顆晶片之間最多只要 7 跳就能溝通，比舊架構的 16 跳少了 56%。跳數，就是延遲與故障風險的直接來源。
一個要小心的數字：算力規格各家寫法不一（有 1.6M ExaFlops，也有寫 1.7K ExaFlops 的），很可能是精度（FP8 vs BF16）或「整 fabric vs 單 pod」口徑不同。對外引用前最好把精度標清楚，別丟一個裸數字。
4. 真正的暗線，是 Apollo OCS
Virgo 的新聞稿把鎂光燈打在頻寬和拓樸上，但 可以看的是底下那條暗線：光路交換。
OCS 不是把光轉成電再交換，而是直接用 MEMS 微鏡把一束光「打」到另一個出口——光進、光出，中間不落地成電。它的價值有兩個：一是省掉大量光電轉換的能耗與延遲；二是當某顆晶片或某個機櫃壞掉，OCS 可以自動重組光路繞過故障，全程不需要人工介入。對一個要連續跑好幾週、上百萬顆晶片的訓練任務，「壞了能自己繞過去」這件事，等於把整機櫃級的故障在網路層就吃掉，有效算力不會被尾延遲拖垮。
關鍵在於，這套 OCS（Google 內部代號 Apollo）是自研、不外採。從 2020 年的 TPU v4 開始，OCS 就一直是 Google 資料中心相對於 Nvidia／Broadcom（NVLink + Ethernet/InfiniBand）體系最難被對標的結構性差異。Virgo 不是這條路的轉彎，而是它的延伸與放大。
5. 對光供應鏈：受惠的是模組與上游，不是 CPO
很多人一看到「光交換、百萬卡」就直覺聯想 CPO。但 Virgo 的架構恰恰相反——high-radix 扁平拓樸要餵的是海量的 800G／1.6T 可插拔光模組，加上 Google 自研的 OCS 光開關（MEMS 微鏡 + 環形器 + 波長選擇開關 WSS）。也就是說，這一代真正吃量的，是光模組本體與其上游：EML／DML 雷射、DSP、各式光器件。CPO 仍然站在門外。
而且 Apollo 是 Google 自研，對第三方 OCS 廠商而言，它帶來的是「示範效應」而非「直接訂單」——它證明了光交換在資料中心規模可行，但訂單未必落到外部供應商手上。這個區別，決定了你在追蹤受惠標的時該往哪裡看。
換個角度說：市場一直在等 CPO 那位主角登場，而 Google 用 Virgo 告訴大家，在通往百萬卡的這條路上，可插拔光模組與自研 OCS 的組合，現在就已經夠用、而且更可控。
6. 風險與反面論點
別把這篇讀成 Virgo 無敵論。幾個該保留的問號：
第一，ICI 那層還沒講清楚。Virgo 是 scale-out，但 pod 內部 scale-up 的 chip 對 chip 互連（ICI）這次官方著墨不多。如果 8t 的 pod 內互連改走 LPO／LRO，那對光元件用量的影響會是另一條完全不同的故事。
第二，47 Pb/s 與百萬卡是兩個層級。多數資料寫的是「單一資料中心內的 single fabric」，跨 DC 的百萬卡是再上一層的軟體拼接，兩者不該混著講，否則容易把規格灌水。
第三，自研＝護城河，也＝不可複製的個案。Google 能玩 OCS，是因為它從晶片到網路到軟體全垂直整合。這條路對其他雲廠（甚至對外部供應鏈）的可複製性有限，不能直接外推成整個產業的走向。
總結
Virgo Network 真正宣告的，不是「Google 又有一張更大的網」，而是一種路線選擇被驗證了：在百萬卡時代，把網路壓扁、用海量可插拔光模組鋪滿、再用自研 OCS 把故障自動繞過去，這套組合現在就跑得動。CPO 仍是未來，但 Virgo 證明它還不是現在的答案。
如果你在追光通訊的受惠線，這篇給你的行動點很清楚：先盯 800G／1.6T 光模組與其上游（EML、DSP、光器件）的拉貨節奏，把 OCS 當成「方向確認」而非「訂單來源」，並把 TPU 8t 的 ICI 互連方式列為下一個必查項目。誰餵飽了 Virgo，誰就站在這一輪 scale-out 的正確一邊。
Virgo Network 應該用專屬 NIC、高基數交換器 (High-radix EPS Switch)，而不是OCS。