Amin Vahdat如何用Jupiter與AI基礎設施網路支撐大模型？

Amin Vahdat如何用Jupiter與AI基礎設施網路支撐大模型？

先看結論

• Amin Vahdat 的核心影響，是把資料中心網路視為 AI 的計算面，而不只是連接 GPU 的管線。
• Jupiter 的價值在於可演進的拓撲、光學交換與軟體控制，讓大模型訓練與推理能在規模化時維持吞吐與可靠度。
• AI 基礎設施必須把網路、客製晶片、資料中心、供應鏈與可觀測性放在同一個治理系統中。

Amin Vahdat 是誰？把資料中心網路視為 AI 的計算面

Amin Vahdat 是資料中心網路、分散式系統與 AI 基礎設施的重要人物。Google Systems and Infrastructure 官方領導頁描述他目前擔任 Google Fellow、資深副總裁與 AI and Infrastructure Chief Technologist，負責的範圍涵蓋客製晶片、資料中心、網路與供應鏈。Google Research 官方人物頁則保存他的研究與 Jupiter 資料中心網路相關成果。

他進入 AI 基礎設施名人堂的理由，是把網路從「連接 GPU 的管線」提升成與計算、儲存同等重要的設計面。大模型訓練與推理會大量交換梯度、activation、KV cache、資料與 checkpoint；若網路的頻寬、延遲、拓撲或路由不適合，昂貴的加速器就會等待。Vahdat 的工作讓團隊理解，AI 叢集的效率必須從整個資料中心的流量與可靠度看，而不是只看單卡峰值。

完整時間線：研究、Google 網路與 AI 基礎設施

• 學術研究：Vahdat 在 UC Berkeley 取得博士，後於 UC San Diego 從事分散式系統與網路研究，建立對廣域與資料中心尺度的視角。
• Google 網路：Google 官方資料記錄他曾任 networking 組織技術領導，並參與 compute、storage 與 network hardware/software 基礎設施。
• Jupiter：Google Research 的 Jupiter Evolving 資料說明資料中心網路如何透過拓撲、光學交換與軟體定義控制持續演進。
• AI and Infrastructure：Google Systems and Infrastructure 官方頁記錄他目前把 custom silicon、data center、network、supply chain 與 AI 服務放在同一個責任範圍。
• 工程治理：National Academy of Engineering 官方資料整理他對資料中心與 planet-scale network 的貢獻。

這條線索顯示網路設計不是一次性的硬體採購。流量型態、模型規模、供應鏈與能源限制都在變，資料中心需要可觀測、可重構、可逐步升級的控制面。當網路與軟體共同演進，平台才能在不中斷服務的情況下增加容量、替換設備並處理新的 AI 流量。

Jupiter 對大型模型的直接啟示

訓練工作需要在大量 GPU 間進行 collective communication。傳統網路若把所有流量當成同一種封包，可能造成熱點、長尾與不公平。資料中心網路可以透過集中式或分散式 SDN 控制、流量工程、路由調整與拓撲演進，把頻寬分配給真正需要同步的工作。對模型平台而言，這代表排程器要知道工作對網路的需求，而不是只把 GPU 數量塞給一個 job。

Jupiter 的工程方法也重視增量部署。網路不必等到整個資料中心換新才改善，可以先在一個 fabric、幾個 pod 或一條高需求路徑驗證，再逐步擴大。AI 平台可以仿照這種方式，先讓新模型或新通訊函式庫在一小部分節點運作，觀察 throughput、tail latency、重試、錯誤與能源，再決定是否推廣。這比一次升級所有節點更容易定位問題與回復。

光學交換與高頻寬互連能降低某些流量的成本，但也引入新的控制與故障面。平台應記錄路由、拓撲、交換器狀態、光纖或鏈路錯誤，以及模型 job 的同步時間。當一次訓練變慢時，工程師才能區分是 GPU kernel、網路壅塞、資料服務或 checkpoint 流量，而不是把問題籠統地歸因於「模型太大」。

AI 基礎設施的四層網路設計

主機層：檢查 NIC、PCIe、GPU 互連、NUMA 與記憶體，確定資料不在主機內來回搬移。

叢集層：依資料平行、張量平行、pipeline 或推理 batching 的需求選擇拓撲、路由與配額，並把 job 的網路需求寫入排程。

資料中心層：用 flow telemetry、交換器計數器、路由事件與容量模型觀察熱點、長尾與故障域；新增容量要能在現有流量下逐步驗證。

控制與治理層：SDN、服務身份、租戶隔離、資料主權、供應商風險與變更批准都要有版本與 audit trail。網路自動化不能成為繞過安全政策的後門。

這四層也適用於 Agent。一次 agent task 可能先查詢向量資料庫，再呼叫模型、工具與外部 API；每一跳都會增加延遲、資料分類與故障風險。平台應用 correlation id 串起請求、網路路徑、模型版本與工具 policy，讓使用者與稽核者都能理解一次輸出的完整上下文。

從 Jupiter 到 supply chain 與客製晶片

現代 AI 基礎設施不只需要 GPU，也包含 TPU、NIC、交換器、儲存、電力、冷卻與資料供應。客製晶片的選擇會影響編譯器、通訊函式庫、模型支援與供應商依賴；資料中心的設計則決定這些元件能否穩定運作。Vahdat 所代表的整合視角，要求平台把硬體 roadmap、網路容量、資料主權與模型需求放在同一張規劃表。

供應鏈風險也應進入 AI 評估。設備的 firmware、驅動、光模組與容器都需要來源、版本、簽章與漏洞狀態；訓練資料與模型 artifact 則要有 digest、授權與刪除流程。當供應商撤回一個元件或發現漏洞，團隊才能快速列出受影響的 job、節點與服務，並沿著已批准的替代路徑回復。

能源與成本是網路設計的一部分。跨區域同步可能增加傳輸與碳成本，過度保守的容量又會留下昂貴閒置。平台可以用每個有效 token 或每次訓練 step 的 GPU 秒數、網路 bytes、功耗與延遲建立基線，並將低優先批次排到合適的時間與區域。成本訊號若能與品質和可靠度一起看，團隊才不會以削減網路帶寬的方式換來更差的模型服務。

資料中心網路也必須面對租戶與資料治理。不同公司的模型、內部資料與工具請求不能只靠 VLAN 名稱隔離；身份、加密、路由與儲存 policy 要在每一跳被驗證。當一個 agent 請求跨越區域或供應商時，平台應先確認資料主權、保留期限與合約，再選擇路徑。網路遙測不能記錄敏感內容，但要保留足夠的 metadata 供容量與事故分析。

可靠度設計則要把故障域畫清楚。NIC、交換器、pod、區域、電力與供應商的故障影響不同，模型 job 需要知道哪些錯誤可重試、哪些要換節點、哪些必須停止。checkpoint 與資料重建應避開同一故障域，路由切換要有冷卻與回復機制，避免短暫抖動引發全叢集重試風暴。這些細節讓網路的可擴展性不會以更大的爆炸半徑為代價。

最後，網路團隊與模型團隊要共享容量預測。模型上下文長度、batch、embedding 維度與工具使用率都會改變流量；網路升級也會改變模型可採用的平行策略。以季度或版本為單位共同檢視 workload trace、容量、成本與品質，才能提前發現瓶頸，而不是等到新模型上線才發現同步時間已經超過服務 SLO。

在訓練與推理之外，網路也承載資料準備、模型註冊、checkpoint、監控與安全掃描。這些背景工作若和線上同步共用一條未分級的路徑，流量尖峰就可能互相干擾。平台應將控制流、資料流、同步流與觀測流分開量測，對不同流量設定優先權、速率限制與失敗處理，讓一個低優先批次不會拖垮即時回答。

網路可觀測性要保留足夠的歷史，才能發現長期趨勢。單次 dashboard 只能看到當下，無法回答某個模型版本是否讓跨節點 bytes 增加、某個區域是否逐漸出現熱點，或某種工具流量是否造成尾端延遲。把 flow telemetry 與模型、資料、租戶、區域和版本 metadata 對齊，平台才能在容量不足前提出具體的改造方案。

這種設計也支持安全的自動化。SDN controller 可以根據批准的 policy 調整路由，但高風險的跨區域資料搬移、租戶隔離修改或供應商切換仍需要人工確認。每次自動變更都要留下前後拓撲、觸發原因、影響範圍與回復指令；當 agent 代表人執行基礎設施操作時，這條證據鏈尤其重要。

容量規劃還要考慮模型生命週期。訓練、微調、評估、蒸餾與線上推理的流量曲線不同，若只用高峰推理流量估算整個資料中心，會造成閒置；若只看平均值，又會在新模型上線時爆滿。平台可以把 job queue、模型 release、資料刷新與網路容量放在同一個時間線，預先安排區域、配額與降級，讓突發需求有可驗證的處置順序。

網路延遲也會影響模型品質與安全。當檢索超時，agent 可能使用較少來源回答；當工具重試，可能重複寫入副作用；當跨區域路由切換，資料分類可能被錯誤套用。服務契約應把網路失敗轉成明確的模型上下文，例如要求拒答、改用唯讀快取或請人批准，而不是讓模型自行猜測外部工具是否成功。

Vahdat 的方法最後回到一個簡單原則：把不可見的基礎設施行為變成可觀測、可審查、可回復的狀態。當每個模型、網路與供應鏈變更都有版本、指標與 owner，團隊才能在追求速度時保留控制力，並把一次故障變成下一輪容量與架構設計的資料。

這也是為什麼資料中心網路不只是硬體專案，而是持續交付的產品。路由、容量、韌體、控制器與模型排程都需要測試與版本化；每次變更都要能在小範圍停下來，讀回實際狀態，再決定是否擴大。對 AI 平台而言，這套節奏能把大規模風險拆成可理解的小步驟。

當網路設計與模型需求以同一種證據語言溝通，團隊才能在性能、成本與安全之間做出可解釋的取捨。這也讓每次容量升級都能留下可重用的工程知識。

清楚的紀錄讓下一次升級可以從證據出發，而不是重新猜測。

這是可持續運作的基礎。

AI 網路與基礎設施檢查表

• 每種模型平行方式都有對應的拓撲、頻寬、延遲與同步基線。
• 主機、GPU、NIC、交換器、路由、儲存與供電都有版本和健康 inventory。
• 流量、長尾、重試、錯誤域與 job trace 能互相對照。
• 網路與硬體變更採增量 canary、明確批准、回滾與事故演練。
• 供應鏈 artifact 有來源、digest、授權、漏洞與替代路徑。
• 成本、能源、資料主權、服務品質與安全一起納入容量決策。

常見問題

Jupiter 為什麼對大模型重要？

大模型訓練與推理會交換梯度、activation、KV cache、資料與 checkpoint；Jupiter 代表一種把拓撲、頻寬、路由與控制面一起設計的資料中心網路方法，能減少加速器等待。

Amin Vahdat 在 Google AI 基礎設施中的角色是什麼？

本文依 Google 官方人物與基礎設施資料，將他的工作放在網路、分散式系統、客製晶片、資料中心與供應鏈的共同責任範圍中，而不是只當作單一網路產品的代言人。

AI 網路和 GPU 的分工有什麼不同？

GPU 負責大量平行計算，網路負責讓資料、梯度與模型狀態在節點間有效移動；任一側出現瓶頸，都可能讓整個 AI 服務的延遲、吞吐或成本惡化。

官方圖片、來源與延伸閱讀

圖片使用 Google Systems and Infrastructure 官方領導頁的 Amin Vahdat 照片。研究與 Jupiter 脈絡參考Google Research 官方人物頁與National Academy of Engineering 官方資料；網路與 AI infrastructure 的現職描述只以 Google 官方頁為準。

站內延伸閱讀可連到 Bill Dally、David Kirk與Ian Buck，形成從可程式化 GPU 到資料中心網路的加速運算主題路徑。

延伸閱讀

若想把資料中心網路、客製晶片與 AI 加速器平台放在同一個系統視角，可以接著閱讀黃仁勳如何把 GPU 變成 AI 權力中心，對照網路拓撲、硬體、供應鏈與開發者工具。

結語：讓網路成為 AI 的可觀測控制面

Amin Vahdat 的名人堂價值，在於把資料中心網路、客製晶片、供應鏈與 AI 服務視為同一個系統。大模型的速度與可靠度不只由 GPU 決定，也由資料如何移動、故障如何被隔離、容量如何增量交付以及成本如何被量測決定。當網路擁有清楚的 telemetry、可重構控制面與回復路徑，AI 基礎設施才能在規模化時保持可理解、可治理與可持續。

增量：AI 網路的瓶頸常在資料移動與故障邊界

Amin Vahdat 的 Jupiter 與 AI 基礎設施脈絡可以用三個工程問題補強：網路是否能把 GPU／TPU 的資料供應起來，拓撲與排程是否能在規模擴大時維持利用率，以及故障是否能被隔離、觀測和回復。單一鏈路速度或峰值頻寬不能直接代表模型服務效能。

• 供應：量測資料搬移、集合通信、擁塞與尾端延遲。
• 擴展：比較單機、多機與跨區域工作負載的有效利用率。
• 韌性：檢查慢節點、鏈路故障與重新排程對服務的影響。
• 治理：把 telemetry、容量、功耗與成本放進同一個控制面。

這讓 AI 網路不只是「更快的管線」，而是模型、加速器、資料中心與營運團隊共享的可觀測系統。任何效能結論都應附上拓撲、工作負載、精度、批次與故障條件。