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

3天前

讀畢需時 6 分鐘

1. 一場被 keynote 蓋過去的網路技術場

Google 在本屆的 keynote（Partha Ranganathan）把 Palomar MEMS OCS 列為八項 AI 系統創新之一，但沒有任何細節。真正把 Google AI 網路拆開來講的，是 AI Clusters 分場這場：Group Product Manager Sunil Ahluwalia 與 Software Engineer Jeongkeun "JK" Lee（Ahluwalia 介紹他是 Virgo 網路的技術負責人）。

Ahluwalia 把 Google 二十五年的網路分成四個時代：網際網路時代的 SDN、Jupiter 與 Apollo、串流時代的 QUIC 與 TCP BBR、雲端時代的 Andromeda、Swift 與 Falcon，以及現在的 AI 時代，主角是 Virgo。

AI 時代的需求寫在第 3 頁：

2026 年已推出 Gemini 3.5、3.6、3.7、3.8，客戶透過 API 直接使用的量超過 每分鐘 220 億 token。
每顆 GPU 的 scale-out 網路頻寬從 2016 年不到 100 Gbps，2022 到 2024 年停在約 400 Gbps，2026 年跳到約 1,600 Gbps（投影片曲線未標數值，此為 STT 讀圖值）。
部署範圍從單一資料中心，走向多資料中心、多園區。

每顆 GPU 的網路頻寬兩年翻四倍，網路不能再被當成通用基礎設施設計。

2. 三個網路，各管一層

Google 把資料中心網路切成三個獨立的領域，共同組成「一座園區就是一台電腦」：

Scale-up：GPU 用 NVLink，TPU 用 ICI。JK Lee 口頭描述 TPU 這一層是以 OCS 為基礎的 ICI（投影片未標示；這是 Google 過去已公開的 TPU pod 架構）。
Scale-out 後端（Virgo）：專門連接 pod 與 pod 的加速器後端，GPU 與 TPU 各自一套。
前端（Jupiter）：連接儲存與一般運算資源，同一棟建築的多個 AI 叢集可以共用，也能透過 WAN 做跨園區訓練。

▲ Google 資料中心的三個網路領域：GPU／TPU 的 scale-up、Virgo scale-out 後端、Jupiter 前端與 WAN（圖片來源：Google｜2026 OCP Global Summit 簡報（第 5 頁））

設計原則有三條（第 4 頁）：為整座園區設計、單一鏈路或交換器故障不能讓訓練中斷、盡量減少網路層數與部署材料。JK Lee 補了一句很關鍵的話：Virgo 的部署與維運週期和 GPU／TPU 綁在一起，向下相容不再是重要需求。STT 的解讀是：後端網路會跟著加速器世代整批更換。

3. 拆解細鏈路：用 SerDes 速度當埠速度

Virgo 的拓樸只有兩層（leaf 與 spine），每個平面的控制平面彼此獨立，一個平面的軟體故障不會擴散。能壓到兩層，靠的是細鏈路（skinny link）：從加速器到 leaf、從 leaf 到 spine，每條鏈路都只跑一條 SerDes 通道的速度，目前是 200G。

▲ Virgo 架構：兩層交換、N 個獨立平面、SerDes 級細鏈路，Apollo OCS 只出現在 Jupiter 一側（圖片來源：Google｜2026 OCP Global Summit 簡報（第 7 頁））

平面數 N 約等於每顆加速器的細鏈路數。JK Lee 舉的例子是 NVIDIA Vera Rubin：每顆晶片需要 1.6T，除以 200G 得到 8 個平面。效果有兩個：

可靠度：一個平面、一條網卡鏈路或一台交換器故障，晶片還有 7/8，也就是 87.5% 頻寬；他說先前某些世代單一故障會損失 50% 甚至 100%。
擴展性：晶片頻寬更高就加平面，不必加第三層。

這套做法的數學很直接。兩層無阻塞網路能接的端點數約為交換器埠數的平方除以二。Google 沒有說用哪一代交換器，以下為 STT 以 102.4T 交換器假設的估算：

埠速度	每台埠數	每個平面可接端點
1.6T（粗鏈路）	64	約 2,048
200G（細鏈路）	512	約 131,072

▲ 同一顆 102.4T 交換器，200G 細鏈路讓兩層網路每平面的端點數放大 64 倍，單一平面故障仍保有 87.5% 頻寬（圖片來源：Simple Tech Trend 自製，資料來源 Google 2026 OCP Global Summit 簡報）

差 64 倍，剛好是速度比 8 的平方。依 STT 推論，省掉第三層交換，等於省掉一整層交換器與對應的光模組；JK Lee 的說法是層數少、機櫃與光纖就少，上線更快。

這個方向不是 Google 獨有，JK Lee 也說業界已經大量採用多平面。差別在 Google 把它寫成設計原則：平面數跟著 SerDes 走，而不是跟著光模組規格走。

4. 拆解路由與遙測：封包噴灑之外，還要看得見

細鏈路帶來大量平行路徑，Virgo 用兩種封包級負載平衡把它們用滿：

交換器驅動的自適應路由：交換器彼此協調，對本地壅塞、故障與下游交換器故障快速反應。
SRv6 來源路由：給自帶主機協定堆疊的裸機客戶，自己控制每個封包的路徑。JK Lee 口頭舉的例子是 MRC（逐字稿為自動字幕，此詞未經投影片確認）。

但壅塞永遠會發生，所以第 8 頁是三項遙測技術：

CSIG（Congestion Signaling）：頻內協定，讓端點主機看到交換器的細粒度壅塞訊號，下一步延伸到 UEC 做低於一個 RTT 的壅塞控制。
HST（High-speed Switch Telemetry）：次毫秒級的埠與佇列狀態。
Firefly：微秒級網卡時鐘同步，用於時間戳與除錯。

傳輸層則和 keynote 宣布的合作呼應：Google 在 2023 年貢獻給 OCP 的 Falcon，已從 NVIDIA ConnectX 延伸到 BlueField，線路格式完全互通，並支援標準 IB Verbs。兩家網卡跑同一套傳輸層，應用程式不必改。

5. OCS 在哪裡：Q&A 裡最有價值的兩分鐘

問答時一位光學業者直接問：投影片上有 Apollo OCS，它和封包交換的後端是什麼關係？

JK Lee 的回答可以整理成三點：

Apollo 是用在 Jupiter 前端的 OCS 元件。他沒有說 Virgo 完全不用 OCS，但投影片的 Virgo 一側只畫了兩層封包交換。
OCS 在 scale-across 有用。例如一開始只連兩棟建築或兩個園區，之後要加第三個，為了維持高利用率必須重新佈線（restripe）；OCS 的最大好處是重新佈線非常快。
代價是初期資本支出與部署時間，因為要多加一層 OCS。他說這是「現在正在考慮的取捨」，而且 OCS 不是唯一的選項，還有新的 patch panel 技術（逐字稿為自動字幕，此詞為 STT 判讀）。

▲ Google 三層網路中 OCS 的位置：TPU ICI（講者口述）與 Jupiter 前端使用，Virgo 後端投影片未見 OCS，跨園區 scale-across 則在 OCS 與 patch panel 之間評估（圖片來源：Simple Tech Trend 自製，資料來源 Google 2026 OCP Global Summit 簡報與現場問答）

這段回答很重要。我們在 ECOC2026｜OCS 出貨的 95% 是 Google 一家的生意寫過 OCS 市場的集中度。就本場揭露的架構，Google 的 OCS 需求主要落在 TPU ICI 與前端，而不是 AI 後端的擴張。如果這套架構不變，Google 越多 GPU 叢集，後端長出來的是封包交換器與 200G 鏈路，不是 OCS。

6. 風險與反面論點

規模數字沒有公布：Virgo 每個平面多少台交換器、用哪一代晶片、單一叢集多少加速器，投影片都沒寫。本文的 13 萬端點是 STT 依假設的估算。
「後端沒有 OCS」是從投影片推論：講者沒有明確排除 OCS，若有未揭露的光路交換層，本文判讀需修正。
頻寬曲線是讀圖值：1,600 Gbps 是 STT 讀圖結果，和 Vera Rubin 每顆 1.6T 的口述一致。
OCS 的角色可能反轉：跨園區連線若常變動，快速重新佈線的價值會蓋過初期成本，OCS 可能延伸進 scale-across 後端。
細鏈路的光學成本沒有攤開：1.6T 拆成 8 條 200G，光纖、連接器與 breakout 數量隨平面數線性增加，Google 沒有給光纖數。
Falcon 與 UEC 的關係仍未定：Google 一邊推 Falcon 互通，一邊把 CSIG 帶進 UEC，是否收斂成一套協定仍待觀察。

7. 對台灣供應鏈的意義

本場沒有點名任何台灣廠商，以下只談產品類別。

200G 單通道是後端的基本單位。Virgo 的埠速度跟著 SerDes 走，下一代 SerDes 升級時整個後端會一起換，而且不要求向下相容。對交換器與光模組供應商，這代表換代週期跟加速器綁在一起、批量集中。
breakout 與光纖管理是增量。依 STT 推論，1.6T 拆成 8 個平面，每顆加速器要分出 8 條獨立鏈路，跳線、扇出線材與光纖配線的數量會隨平面數放大。光纖數量變成瓶頸的代價，我們在殺死慢而寬的不是物理，是六萬條光纖拆過這個問題。
OCS 相關供應鏈的增量要看跨園區決策。本場揭露的後端沒有 OCS，OCS 的成長取決於 TPU ICI 與前端；scale-across 若選 patch panel，這塊增量會被分走。
少一層交換，就少一層光模組。兩層架構省掉 spine 之上那一層，對「每顆加速器配幾顆光模組」是壓抑因素；光模組的增量要看加速器數量與 SerDes 換代，不是網路層數。

8. 總結

這場最值得帶走的是一個修正：就 Google 這次揭露的架構，OCS 不在 AI 後端。Virgo 用兩層封包交換、200G 細鏈路與 8 個獨立平面，同時換到規模、可靠度與部署速度；OCS 則留在 TPU ICI 與 Jupiter 前端，跨園區那一層還在和 patch panel 比。

時間要分開看。Virgo 會隨 Google Cloud 下一代 GPU 與 TPU 平台上線；跨園區的長距離 RDMA 後端與 CSIG 進入 UEC 是下一步。接下來 12 個月應觀察三件事：多園區 Virgo 擴充用 OCS 還是 patch panel、Google 是否公開 Virgo 的交換器世代與叢集規模、Falcon 與 UEC 是否走向同一套規格。

讓 Google 的 AI 後端長大的，是 200G 細鏈路和兩層交換，不是 OCS。

本文僅供技術與產業趨勢分析，不構成任何投資建議。