人類歷史上規模最大的資本開支建設正在展開。從衡量系統真實性能的"goodput"指標，到光路交換網絡、軌道數據中心，再到十年後的算力形態，谷歌AI基礎設施負責人Amin Vahdat在近期一次深度對談中，系統梳理了這場建設背後的技術邏輯與戰略取捨。

谷歌今年資本開支預計超過2000億美元，大部分用於數據中心建設。Vahdat在接受Sequoia Capital合夥人Sonia Huang訪談時表示，長程智能體（long-horizon agent）的崛起正在從根本上改變數據中心的設計邏輯，不僅推高了對加速器的需求，也讓CPU、網絡與存儲的需求同步"暴漲"。他同時透露，谷歌必須大約每六個月將服務側token生成能力翻一倍，而這一增長的主要來源並非硬件本身，而是軟件與模型優化的持續疊加。

對投資者而言，Vahdat的判斷具有直接參考價值：電力是AI基礎設施擴張的最根本瓶頸，而非芯片或製造產能；軟件優化對容量提升的貢獻"很可能不少於硬件"；TPU路線圖上，推理與訓練芯片已於今年首次分拆為獨立產品線，折射出推理市場的快速膨脹。

不是FLOPS，是Goodput：真實故障條件下的問責邏輯

Vahdat將FLOPS定性為"虛榮指標"，認為它只反映單顆芯片的理論上限，而實際工作負載性能取決於數千乃至數萬顆加速器、CPU、網絡和存儲如何協同運作。

"在10萬加速器規模上，總會有東西在壞，一直如此，"他說。一旦同步工作負載中任何一個組件失敗，整個系統可能需要回滾至上一個檢查點重新計算，這部分"無效工功"正是goodput與throughput之間的差值所在。他將其類比為在紙上解題：每次因錯誤回到第一步，過程本身雖然消耗了計算資源，但並不算作有效交付。

故障原因則呈現出典型的長尾分佈。Vahdat坦言，"如果存在某個最常見故障原因，我們早就把它找出來修掉了"，問題來源涵蓋網絡互連、硬件本身、編譯器缺陷、運行時錯誤乃至操作系統問題，每引入一代新產品都會帶來新的故障模式。

Agent時代重塑數據中心架構：CPU與存儲需求同步爆發

Vahdat將長程智能體的興起視為過去一年內影響數據中心設計的最大結構性變量。

在傳統人機交互模式下，用戶讀取模型響應、思考、再次輸入，中間存在數秒乃至數十秒的"人類節拍"，這天然限制了請求頻率。而在智能體場景中，模型無需等待人類，響應延遲可從秒級壓縮至毫秒級，請求密度呈數量級提升。

同時，智能體在推理和編排環節大量依賴CPU：解析上一步響應、判斷下一步行動、從本地DRAM、遠端內存、SSD或HDD中抓取上下文——這些操作均運行於CPU而非加速器之上。"加速計算需求在上升，但CPU、網絡、存儲等傳統數據中心組件的需求也在暴漲，"Vahdat說。

這直接引發了數據中心佈局的兩難：若在GPU/TPU機架旁配置大量CPU機架，將破壞針對加速器的專用化設計；若將兩類機架分置於不同建築，則樓間網絡將引入數百微秒的排隊延遲，並顯著拉升可靠性與成本壓力。

TPU首度拆分推理與訓練：芯片專用化的邊界在哪裏

谷歌今年發布的TPU第8代首次分拆為兩顆獨立芯片：8i用於推理，8t用於訓練。Vahdat將這一決策定性為對推理市場規模預判的直接結果。

在此前的單芯片策略下，一顆芯片需同時兼顧推理與訓練，兩類工作負載均無法得到極致優化。隨着推理在總算力需求中的佔比預計升至50%乃至更高，專門化的邊際收益開始超過專用化帶來的靈活性損失。

不過，Vahdat強調，這次拆分設定了一個關鍵安全閥：8i和8t均保留了執行對方工作負載的能力，只是非專長方向性能有所折損。"如果8i完全不能做訓練，我們就必須提前精準預測六年生命周期內兩類負載各自的需求量，"他解釋道，這將帶來難以承受的預測風險。

在更宏觀的專用化哲學上，Vahdat描述了一條從通用GPU到Transformer原語固化，乃至"將特定模型架構燒入硅片"的連續譜系，並表示已有公司開始探索最後一步。谷歌目前的判斷是：Transformer所依賴的矩陣乘法、softmax等線性代數原語已基本固化於硬件，進一步專用化到具體模型層是"非常非常有趣的方向"，但尚未落地。

光路交換：從MEMS反射鏡到毫秒級故障切換

谷歌約15年前率先將波分複用（WDM）引入數據中心，隨後疊加了光路交換（optical circuit switching）技術——後者在純光域內完成數據路由，繞過了傳統電分組交換逐包查表的電域處理環節。

Vahdat介紹，谷歌最初採用MEMS微機電開關，通過在三維空間內精確控制微型反射鏡的角度，將任意輸入光纖端口的光信號導向指定輸出端口，實現可編程的光域路由。這一技術最初服務於兩個目標：在高頻通信的計算集群與存儲集群之間建立光域捷徑；以及在無需人工移動光纖的前提下，通過軟件控制器動態重構網絡拓撲以實現擴縮容。

在TPU集群中，光路交換還具備關鍵的容錯價值：當某個TPU機架發生故障時，系統可在毫秒級內將光路重新指向備用機架，無需任何物理操作，直接壓縮goodput損失。

Vahdat透露，軌道數據中心場景下，組件間將真正轉向自由空間激光通信——這也是他在地面場景中迴避該方案的原因（衰減損耗與大規模三維對準難度過高），但在太空環境中上述限制大幅弱化。

電力是根本瓶頸：與公用事業共同規劃多年，吉瓦級需求重塑供電模式

被問及AI基礎設施擴張的最大約束，Vahdat的回答直接而明確："電力是我們面臨的最fundamental約束。其他所有問題我們似乎都知道如何在一段時間內解決；電力則是長期binding問題。"

谷歌的首選模式是與公用事業併網，而非自建獨立電源。原因在於統計複用效應：若完全自給，達到99.99%以上可靠性意味着需建設兩倍裝機容量；而通過與公用事業的長期協同，在更大基數上平滑需求波動，雙方均可降低冗餘成本。谷歌承諾自行承擔因其接入所需新增的輸電線路和變電站建設費用，以避免將成本轉嫁至其他用戶。

但供需錯配現實存在。Vahdat舉例：若某年需要1吉瓦，而公用事業當年只能提供700兆瓦，谷歌可能臨時自建太陽能+儲能以填補缺口，並在最熱月份將本地發電回饋電網。

關於單體數據中心的最優規模，他坦承這是"大量爭論的來源"，且高度依賴選址：訓練集群偏向吉瓦級集中部署以最小化網絡延遲；而服務集群需分佈全球貼近用戶，單體規模更小，且因需混合配置存儲與計算，專用化程度相應降低。

DeepMind協同設計：在芯片"飛行途中"攔截架構

Vahdat將與DeepMind的協作描述為"深度合作伙伴關係"，並以"在芯片架構飛行途中做修改"來形容其緊密程度。

谷歌同時推進五至六代TPU：已量產、調試上線、即將tape-out、設計中、概念階段，構成一條橫跨數年的並行流水線。不同階段對應不同深度的協同窗口：對已量產芯片，重點在於共同最大化goodput；對即將tape-out的芯片，若DeepMind提出能帶來重大收益的模型優化，雙方可以緊急評估是否值得推遲tape-out以納入硬件修改——"叫停一次tape-out是大事，但如果機會足夠大，我們絕對會一起努力"；對設計階段的芯片，則進行三至四年維度的模型架構趨勢共預測，依託仿真基礎設施評估不同硬件架構對未來工作負載的適配度。

Vahdat還披露，谷歌目前已在使用Gemini為未來版本的Gemini設計硬件，形成模型輔助芯片設計的自我強化閉環。他和DeepMind的Koray及Demis"每周都會多次交流"。

2036年的超級計算機：單機架多兆瓦，或直接發射入軌

對於十年後算力形態的預判，Vahdat給出了兩條並行路徑。

在地面形態上，他預計集成度將大幅提升，機架將從外部可見的繁複光纖束演變為"只有一小束光纖從機架裏出來"的高度集成單元。單個機架功耗可能達到數兆瓦量級，進場安裝僅需接入電、水、光纖三路即可運行——製造與部署將更趨向模塊化工廠預製。

在軌道路徑上，谷歌已將軌道數據中心列為正式在推進的moonshot項目，核心邏輯在於能源優勢：太空中無大氣衰減使可用功率天然高出約40%；太陽同步軌道可實現98%至100%的日照覆蓋，而地面設施通常僅為28%至35%，疊加後的能量密度優勢可達3至4倍，且無碳排放。

主要挑戰在於冷卻（太空散熱反而更難）、可靠性維修（硬件損壞後維修難度遠高於地面）以及組件間通信（將被迫採用自由空間激光而非光纖）。Vahdat表示，這些問題"沒有根本性showstopper"，並開玩笑稱2036年或許真能"把機架發射升空，由空間站機械臂接住，插進正確模塊"。

以下為訪談全文：

主持人（索尼婭·黃，Sequoia Capital）：歡迎 Amin Vahdat 來到節目。非常感謝你今天加入我們。我也很期待今天的對談。今天的主題讓我非常興奮，因為我們正處在大規模資本開支建設的歷史中心。

阿敏·瓦赫達（Google AI 基礎設施負責人/首席技術官）：能來這裏我也很興奮。今天的話題非常激動人心。

主持人：你正處在這場人類歷史上最大規模的資本開支建設之中。僅 Google 一家，今年預計資本開支就將超過 2000 億美元，其中大部分用於建設數據中心。而你正是這一切的核心人物：去年年底你被任命為 Google AI 基礎設施負責人，正在牽頭人類歷史上資本密集度最高的建設之一之一。所以我非常期待今天和你一起深入聊這件事。

阿敏：這確實是行業層面、也包括 Google 在內都非常重大的一年。老實說，我認為我們以前從未見過類似情況；當然，在 Google 沒有，我甚至覺得在人類歷史上也沒有，無論從建設規模還是轉型速度來看，都令人難以置信。

主持人：在深入之前，先給觀衆快速普及一下：什麼是 AI 數據中心？它和非 AI 數據中心有什麼不同？

是什麼讓數據中心成為「AI 數據中心」

阿敏：這是個很好的問題。AI 數據中心和非 AI 數據中心其實有很多相似之處，並不是截然不同。它們都由混凝土構成，都有一個圍合空間；都有電氣場、機械場、冷卻系統；有成排的電力分配；還有大量網絡基礎設施，也就是把大量計算設備彼此連接起來；數據中心裏也有相當多存儲基礎設施。

我認為 AI 基礎設施最大的區別在於「專門化」。過去建設數據中心時，本質上是在做一個 20、25、30 年期的建築投資。我們會考慮這座建築在 20、25、30 年裏如何演進。裏面可能放服務器，可能放網絡、存儲，也可能放一些加速器，比如 GPU、TPU 或其他芯片；但規劃周期是 25 到 30 年。硬件壽命可能是六年，所以我們必須為許多代硬件做規劃。

而 AI 數據中心往往更像是「為特定目的而建造」。換句話說，我們經常把建築和將要放進其中的硬件做共同設計。比如，我們可能決定不在某棟樓裏放太多存儲。為什麼？因為一個存儲機架可能有 10、20、30、40 千瓦功耗；而把它放在 TPU 機架或 GPU 機架旁邊，那些機架今天輕鬆達到數百千瓦，未來幾年甚至可能更高。設計一棟樓時，如果要在一排裏放 30 個存儲機架，和只放一兩個 AI 機架，是非常不同的設計。你可以從尺寸、功率，以及功率如何在建築內分配等角度去理解這種差異。

網絡也是同理。存儲機架所需的網絡帶寬很小，尤其是機械硬盤存儲，相比 AI 機架更是如此。如果你想讓數據中心在 30 年周期內完全可互換、完全通用，你很可能會把它建得過大、過度設計。AI 數據中心很可能更加專用的，與硬件共同設計，甚至精細到冷卻和配電等環節。也就是說，會有更多共同優化。

主持人：你們交付了一個很大的 Vera Rubin 集群給我的一家被投公司 Ineffable Intelligence，我看到了它出貨時的照片。那真是一個傑作。那簡直就是紀念碑，展示了人類能做出什麼樣的工程。

阿敏：確實。那只是幾個機架，但機架之間的佈線、光纖分配真的非常美。美不美見仁見智，但對我、對你，以及不少聽衆來說，它確實是一件工程之美。我們把這張照片放到社交媒體上，人們非常喜歡 Ineffable Intelligence 正在做的事；那是一個非常出色的團隊，也獲得了很多關注。不過實際上，大家最喜歡的是光纖照片，尤其是光纖那種分形般的結構。那篇帖子成了我們有史以來最受歡迎的帖子之一。所以我們確實很興奮。

主持人：我看到照片時渾身起雞皮疙瘩。

不是 FLOPS，而是 Goodput：當系統每小時都會出故障時，如何問責

主持人：在這場大規模建設中，你們如何衡量自己、如何問責？我們在節目開始前聊到，FLOPS 更像是一個虛榮指標，你更偏好另一個指標。能展開講講嗎？

阿敏：無論 FLOPS，還是你偏好的其他芯片中心指標，本質上都是「理論值」。也就是說，在某種條件下，對於某顆芯片，這是它能交付的最大 FLOPS。但我們最終真正關心的是：某個工作負載實際交付的性能如何。工作負載的性能很少由單顆芯片決定。它可能取決於 FLOPS、HBM、SRAM 容量等，這些因素都非常重要；但它也可能取決於 2、4、8、16、1000、10000 甚至更多顆芯片如何組合在一起。這裏不僅包括加速器，無論 TPU 還是 GPU，還包括給它們喂數據的 CPU，以及把所有設備連接起來的網絡。

所以問題是：你運行的工作負載是什麼？這個工作負載的性能是多少？一個有意義的度量是 FLOPS 利用率：對於某個特定工作負載，如果你理論上具備某個teraflop/petaflop 能力，你實際交付了其中的多少比例？

這就是 goodput 的一種度量。什麼是 goodput？大家熟知 throughput，即「吞吐」。那是理論上可能的吞吐。但現在要考慮其他因素。一個是工作負載本身固有的 slowdown；另一個非常關鍵的因素是可靠性。

從問責方式上說，如果有一個芯片在同步工作負載中失敗，而這些工作負載——無論訓練、服務還是 agentic 工作負載——往往都是同步的，也就是說許多組件同時協同工作。假設有 1000、10000、100000 個組件同時工作，並且需要在微秒或毫秒級粒度上協調。只要其中一個失敗，就可能讓整套系統停下來，因為每個組件都依賴其他組件完成自己的那部分工作，才能共同回答一個很難的問題。

其中一個組件停了，我們現在必須弄清楚發生了什麼、哪一個停了。我們在之前某個時間點保存的 checkpoint 是什麼？如何恢復這個 checkpoint？如何重啓？最壞情況下，我們可能不得不從頭開始，那就非常糟糕。某些情況下確實可能發生，尤其在推理側更常見。重點是：如果失敗後你必須回頭重做大量計算，如果必須暫停並等待排查故障，這些「工作」都不算真正幫助你得到答案。

就像你在紙上解題：第一步、第二步、第三步、第四步。如果你因為犯錯必須回到第一步，你當然仍在「做功」，那是 throughput；但真正重要的是 goodput，也就是你交付答案所花費的總時間。如果有故障、有故障恢復、有任何打斷工作的因素，這些都會計入問題之中。

所以我們問責自己的方式是：交付的 goodput，而不是理論 benchmark 吞吐，也不是理論上的「 goodness」。對於一個真實工作負載，在真實故障條件下，實際發生了什麼？不幸的是，在 10 萬加速器規模下，我要說的是：在那個規模上，總是有東西在壞。一直如此。而且每一顆這樣的芯片，都是自然界的奇蹟，處於製造能力最前沿。現在這些芯片還不只是一顆芯片，而是由兩個、四個、八個甚至更多 chiplet 組成的封裝，再加上旁邊的 HBM、網絡連接，也許還有共封裝光學。無可指摘，但確實有很多東西可能失敗。而一旦你有 10 萬顆這樣的設備，總會有東西失敗。你必須為此做好準備：近乎實時地檢測，近乎實時地恢復。遙測問題非常龐大，就像持續不斷地在乾草堆裏找針；當然是在秒和分鐘級別持續在線，而對某些任務，甚至是小時、天、周級別持續在線。

我們問責自己的標準，就是數據中心裏真正重要的工作負載交付了多少 goodput。

主持人：goodput 是 Google 內部術語，還是行業術語？

阿敏：這是 Google 術語，但我看到行業裏越來越多的人也開始採用它。

主持人：幫我校準一下：在 10 萬加速器規模，故障頻率大概是多少？每天一次？每小時一次？

阿敏：在這個規模上，肯定是每天多次，取決於具體配置，甚至可能每小時多次。總會有東西失敗。

主持人：最常見故障原因是什麼？

阿敏：問題就在這裏。這確實是個很好的問題。如果存在某個「最常見故障原因」，我們早就把它找出來並修掉了。實際情況是一條不斷髮現新問題的長尾曲線。每當引入新產品，總會有新問題擊中我們。坦率說，很多情況下正因為它處於最前沿，故障可能來自網絡相關，可能來自我們如何以超高速度把這些設備連接在一起，也可能來自硬件本身。這些我們會逐項解決。但很多 issue 也可能是軟件問題。這也是我們問責自己的另一部分。芯片也許具備某個 FLOPS 能力，但如果有編譯器 bug、運行時 bug、模型問題、操作系統問題，那都沒關係——它照樣會影響系統性能。你可能擁有完全可靠、完美的硬件，但仍會被軟件問題拖垮。

每六個月讓 token 產能翻倍，以及增益究竟來自哪裏

主持人：從加速器公司——Nvidia 或 TPU 團隊——那裏，是否存在一個標準參考棧：只要圍繞他們的加速器構建這個最優系統，你就沒問題？還是說，你們在半導體公司提供的方案之上，還必須自己做很多數據中心設計？

阿敏：確實存在參考棧。我想說，Nvidia 是一家非常出色的全系統公司；它顯然是半導體公司，但又不只是半導體公司。他們提供非常強的參考棧。但據我們觀察，大多數客戶會利用這個參考棧，同時許多客戶也會做專門化。也就是說，他們會發現：對於自己的特定用例，存在一個自然出現的優化機會，或者有某些不同需求必須處理，於是他們會去做。TPU 這邊也類似。我們也有參考棧，大多數人會利用它，但很多人也會進一步專門化。

主持人：明白了。再談整體容量：你告訴團隊，Google 必須大約每六個月把服務能力翻一倍，對嗎？

阿敏：需要澄清一下。這裏說的是「有效可用容量」。最終我們看的是服務視角下的 token 生成能力。容量是軟件和硬件的結合。硬件可能有某種所謂「固有」FLOPS 水平。我說的並不是必須每六個月把 FLOPS 數量翻倍；那只是路徑之一。你確實必須每六個月讓硬件生成 token 的能力翻倍。而其中來自軟件的部分，很可能不少於來自硬件的部分。也就是說，收益可能來自模型優化，也可能來自運行時優化。實際上，更可能是數十、數百項單獨優化不斷落地，一次又一次疊加，才讓這一切成為可能。但容量提升的速度確實令人難以置信。

主持人：過去幾年裏，我們已經看到了幾年數據中心建設、模型進步和軟件進步。以「每瓦智能」來衡量容量增長，經驗上分解一下：多少來自硅片本身，多少來自模型，多少來自其他軟件，以及其他大的組成部分？

阿敏：這個問題很好。我沒有精確分解數據，但根據我們的經驗，大部分收益來自模型側改進，也就是模型軟件系統層面的 intelligence per watt。順便說，「每瓦智能」是個非常棒指標。我們更準確的說法是「每瓦 goodput」。之後可以再說為什麼分母必須是瓦。Goodput 本質上可以是「每瓦交付智能」的度量；goodput 本身是工作負載特定指標。但我認為，大部分增益往往來自模型側軟件系統，其次也來自軟件系統其他部分。為什麼？因為它們能確保你已有的硬件被有效利用。

硬件本身也確實驚人。換句話說，我們正生活在一個年化 2 倍甚至更高性能改進完全可能的時代。硬件確實能夠支撐這一點。如果你想要一個比喻，它像一個「免費乘數」——不是完全免費，但其他所有上層都可以指望它：這是一個逐年把所有人抬升的乘數。

TPU 的賭注：從 2013 年的逆勢判斷，到首次拆分為 8i 與 8t

主持人：我想聊聊 TPU 項目和協同設計。Google 十多年前就開始做定製芯片，這在當時是個逆勢判斷。TPU 項目是如何演變的？

阿敏：變化相當大。項目始於 2013 年，當時確實非常逆勢。很難把你重新放回 2013 年的語境：當時的傳統智慧是，所有最聰明、最有經驗的人都會說，你不該為單一工作負載構建定製加速器。為什麼？因為摩爾定律還在，每 18 或 24 個月性能翻倍還在；你可以利用標準編程模型，你的 C++、Java、Python 等等都能用。這有點像芯片領域的「苦澀教訓」：專門化永遠不會贏。

但在這個特定案例裏，我們有一個應用，或者說少數幾個應用，會從專門化中極大受益，而要支持它們需要難以想象的海量通用 CPU。所以 2013 年它確實是一個賭注，甚至公司內部也有相當多的人不確定它能否成功。結果證明這是一個巨大成功的賭注。

第一代芯片完全圍繞推理。第二代芯片則是：實際上我們可以把同樣思路擴展成訓練芯片。從那以後，越來越多用例開始使用 TPU。大約第二代芯片推出前後，Transformer 被髮明瞭，那是一個重大時刻，也完全改變了 TPU 項目的方向。我們還發現推薦系統在 TPU 上運行得非常好，於是廣告和相關用例也加入了進來。所以這種變化和演進，本質上是範圍和影響力的擴展：它從一個極具影響力的一兩個推理服務用例開始，主要是語言翻譯和語音識別；然後擴展到訓練，再到 Transformer、推薦系統；隨着生成式 AI 時刻到來，又繼續泛化到越來越大、越來越可擴展的系統。

主持人：你提到 Transformer 的出現是一個重要時刻。我很好奇，TPU 是一種特定架構，但並不是專門針對 Transformer 的。你如何在「芯片對負載該有多專門」這條細線上把握平衡？

阿敏：這是個很好的問題，核心在於芯片對特定工作負載的適用性。每一代我們都在思考：是否要進一步專門化？比如說大約兩年多以前，我們面對的問題是：到 2026 年，我們應該做兩顆芯片還是一顆？我們可以做一顆芯片，同時較好地完成推理和訓練；也可以做兩顆芯片：一顆進一步專門化於推理，另一顆進一步專門化於訓練。這個分析和這項工作最終促成今年發布兩顆芯片：8i 用於推理，8t 用於訓練。

最終我們意識到，幾年前情況未必如此，但到 2026 年，我們看到推理和服務真正起飛了。於是一顆在服務上明顯更快的芯片開始變得非常有意義。我們曾估計，推理在其生命周期內可能佔市場的 30%、40%、50%、60%。相比之下，如果我們預計推理只佔市場的 2% 或 5%，即使專門化芯片快 2 倍，也可能沒有意義；因為你反而會偏向一顆通用芯片——它雖然沒有完全優化，但具備統一性等優勢。

所以這確實是一個計算問題：你是否要進一步專門化？這個工作負載有多大？未來兩三年、三四年它預計會有多大？這個工作負載是否能支撐硬件層面的持續增長？正如前面所說，機會在於：你對某個工作負載專門化程度越高，靈活性越低，但硬件會越快、越省電。所以這是一門藝術，也是對設計目標的預判：這個工作負載有多持久？如果它一兩個月、三個月後就消失了，即使這三個月很大，你 interception 的窗口也非常窄。它必須足夠持久，而且你必須能準確預判專門化能帶來多少收益。

主持人：粗略權衡似乎是：支持一個新項目有很高的固定成本。

阿敏：是的。你必須認為，對這個特定項目會有足夠需求來證明成本合理。舉個例子，對於 8i 和 8t 兩顆芯片，兩者其實都能做另一種工作負載，這一點也很關鍵。假如 8i 只能做推理，完全不能做訓練，也就是訓練性能為零；反過來，假如 8t 訓練極強但推理性能為零，那也會是關鍵限制。為什麼？因為我們就必須提前預測，在這顆硬件約六年生命周期裏，各自到底需要多少。現在這樣比較好：兩顆芯片都更擅長自己的專門負載；但如果某個地方有剩餘容量，兩者也都能承擔對方的工作。取決於專門化程度，你可能會把自己搞得過於專門，從而失去靈活性、可互換性。

主持人：既然粗略權衡的一端是項目規模，那我問個挑釁點的問題：現代 AI 市場這麼多東西都基於 Transformer，為什麼不乾脆把 Transformer 架構「燒」進芯片裏？

阿敏：Transformer 確實是基礎，但下一層問題是：Transformer 本質上圍繞向量、矩陣乘法運算，以及 softmax。也就是一系列線性代數原語。我們這些以及其他廠商大致已把這些原語固化進硬件。大家當然都基於 Transformer，但模型架構還有一層：你有多少層？如何在層內前進？如何跨層前進？每個維度上應用什麼形狀的矩陣和向量？你可以進一步專門化，不只是專門化到 Transformer，而是專門化到你的模型。這是下一層專門化。我知道有一些公司在思考這個方向，我也認為這是一個非常非常有趣的方向。

主持人：那麼現在，你的客戶會把 TPU 和 GPU 看作大致可互換的等價物嗎？還是說某些問題更適合其中一種？

阿敏：肯定存在某些問題更適合其中一種。GPU 比 TPU 更通用，這一點很清楚。Google 和 Google Cloud 有非常出色的產品，我們銷售大量 GPU，內部也使用 GPU。但真正要看的是你問題的具體情況。我們的客戶會在兩者重疊的範圍內，評估自己的工作負載和可選方案。我們在 Google 喜歡做的是給客戶選擇權：為他們的需求提供正確解決方案，並儘可能提供最能滿足他們需求的方案。

協同設計的支持與反對理由

主持人：從芯片到網絡再到軟件，協同設計的理由是什麼？反對理由又是什麼？

阿敏：協同設計有巨大的優化機會。可以想象，如果你有一個端到端棧，想自由選擇任意組件——比如你跨多個雲運行，或跨許多硬件、許多軟件運行——你可以設計抽象層，聲明：我能運行在任何硬件上，運行在任何軟件上，運行在任何網絡拓撲上，你給我多少網絡我都沒問題，我的系統會完全自適應。這樣你就獲得很強能力：新容量一夜之間出現，你就能跑起來，因為系統就是按這種方式設計的，可以立刻利用任何資源。你沒有硬編碼，也沒有對任何特定基礎設施做專門化。

缺點是，如果你完全通用，你很可能會把大量性能留在桌上。如果你對任何人的硬件、軟件、網絡、存儲、計算等棧都完全靈活，那麼每一層之間都會出現很大的「阻抗失配」，如果你追求完全通用性的話。每層之間可能有 10%、20%、甚至 2 倍差距。你開始把這些優化機會逐級相乘，最後會剩下一個很大的端到端機會——無論你稱之為每瓦智能，還是每瓦 goodput——都可以利用，甚至一路下探到配電、電力可用性、軟件優化等等。

支持協同設計的一方是：你可以隨時隨地運行，沒有鎖定。反對的一方是：你會把顯著、甚至很可能是顯著數量的性能留在桌上。

主持人：我的理解是，如果看 OpenAI 和 Anthropic：OpenAI 主要構建在相對同構的計算棧上，而 Anthropic 構建在相對更異構的計算棧上。這是否部分解釋了協同設計，也成為傳聞中兩家模型架構非常不同的原因之一？

阿敏：我不能、也不想推測 OpenAI 和 Anthropic 在做什麼。這是一種可能性。但在不知道他們具體做法的情況下，我會想象，他們最終採用不同架構可能有許多原因。

與 DeepMind 並肩作戰：在芯片飛行途中「攔截」架構

主持人：那 Google 呢？我很好奇你的團隊與 DeepMind 的工作關係是什麼樣的：在模型開發的哪個階段，誰會進入同一個房間？你們如何在協同設計上共同決策？

阿敏：這是我在 Google 工作最有趣、也最讓人欣慰的部分之一：有機會與 DeepMind 團隊真正肩並肩地協同設計硬件和模型。還有第三個元素：我們還會把這種協同延伸到消費者服務和雲。這個先放一邊，之後可以回來談。就 DeepMind 而言，這真的是深度合作伙伴關係。

舉過去的例子：他們提出模型優化，可能是針對 Transformer，或針對某個特定數學運算；而那時我們有一顆芯片正在進行中，還沒完成。他們可能會說：「天吶，如果硬件支持這個，我們的端到端訓練或服務可能顯著更快、更高效。現在要改變我們正在執行中的硬件定義，需要付出什麼？」這會促使雙方工程師和研究員密集地聚到同一個房間，待幾天、一周、兩周，討論：「好，我們可以做到。」更常見的情況是，「我們沒法完全做到你想要的，但可以做成另一個版本。」然後也許你也能把模型架構往另一個方向改一點，從而得到你想要的 98%、我們目標的 90%，然後我們再回頭去調整硬件。或者說：「你知道嗎，我們會把 tape-out 推遲一兩周，因為這個收益級別完全值得。」

類似地，當我們規劃路線圖時，任何時間點上都有許多代芯片在並行推進：一代是已經量產的芯片；一代是正在努力投入量產的芯片，已經從製造商回來，我們在調試、讓它工作；一代是處於實現階段、即將 tape-out 並交給製造商的芯片；一代處於設計階段；還有一代處於概念階段。所以從量產到還在腦海裏，真的是一條五六個階段、跨越許多年的流水線。

與 DeepMind 的合作，對已經量產的芯片非常重要，因為我們可以共同最大化「交付智能」或「每瓦交付 goodput」。我們確切知道模型裏發生了什麼，也知道硬件裏發生了什麼，以及兩者之間的一切。我們也可以深度合作那些即將 tape-out 的芯片。為什麼？因為我們可以攔截，並字面意義上在芯片架構「飛行途中」做修改。這如果跨公司邊界會很難，甚至不可能；不是說不可能，但難得多。假如離芯片完成只有幾周或幾個月，再說「天哪，讓我們肩並肩坐到同一個房間，看看是否該打亂項目」，這是可能的，但更難。這是我對跨公司邊界的判斷。

對於那些還在設計階段的芯片，我們可以一起評估許多架構。我們會問 DeepMind 同事：你們認為兩三年後的模型架構會往哪裏走？這是我們能做的一組方案，這是模型架構可能演進的一組方向。我們其實有深入且重大的仿真基礎設施，可以預測工作負載將如何映射到不同硬件架構上。深度而快速的迭代。團隊並不是分開工作的，很多時候就在同一棟樓、同一個房間裏，日常深度互動。我和 Koray、Demis 等人每周都會多次交流。所以這確實是工作裏非常有趣的一面。

主持人：太棒了。最終他們的模型也會幫助芯片設計。

阿敏：我們也在用 Gemini 為未來版本的 Gemini 設計硬件。

主持人：這真的很酷。之後我想再回頭聊合作本身。我猜這裏仍存在一個阻抗失配：硬件周期顯然比 DeepMind 軟件側面對的周期慢，而你們的規劃周期肯定也更靠前。那麼你們實際還有多少調整空間？

阿敏：這是個好問題。毫無疑問，我們會提前兩三年、四年、五年規劃硬件。剛纔聊到我們已經宣佈的 TPU 第 8 代，但你可以想象第 9、10 代，也許還有別的，已經處於概念、執行或其他階段。它們可能還有好幾年纔出來。而如果你默認在做模型架構工作，通常不會提前好幾年思考。

但這也恰恰是公司一起成長起來的偉大之處。Google Research、DeepMind、Transformer 的發明，所有這些也都發生在這些相互重疊的房間裏。也就是說，有一整代研究員已經習慣了能夠影響硬件，也知道硬件按多年周期運轉。他們也知道：如果只是一個能給即將 tape-out 的芯片帶來 1% 或 0.5% 收益的小改動，他們大概不會來找我們，因為他們足夠了解：這不像軟件，你不能提交一個 change list，兩周後就上生產。實際上，叫停一次 tape-out 是大事。但他們也知道，如果真有一個非常大的機會，我們絕對會一起努力，看能否把它放進去。所以收益來源是乘性的。硬件會抬升所有船隻，對吧？

DeepMind 團隊有相當一部分人——我們對此非常感激，那是個令人驚歎的團隊——會認真思考如何影響路線圖，因為那是一個流水線。你兩年前的想法，現在已經在生產裏，並幫助 Google 所有工作負載跑得更快，那是一種很好的感覺。

主持人：完全同意。不過，預測五年後最常見的工作負載、以及會出現什麼算法突破，這看起來幾乎不可能。

阿敏：聽起來確實不可能。我明白為什麼你會覺得不可能。但令人震撼的是——我們其實正在非常詳細地寫這件事，而且寫起來很有意思——TPU 架構在中等細節層面上，自 TPU v1 以來並沒有真正改變。不是說在最高層面上沒變，而是在中等細節層面上。你可以把它類比為 CPU 的指令集架構：你有 load、store、add、subtract、branch。這麼多年軟件在上面做了什麼？TPU 也一樣。我們有一些基本指令和基本原語。當然我們擴展過它，不是說指令集完全沒變；但那些原語，比如專門化的數值格式、非常大的矩陣乘法單元、一個管理向量操作和 scatter/gather 操作的 sparse core 等，真正定義它的就是五六件事。還有一個實際是 load remote/store remote：我們可以通過 ICI 網絡讀寫遠端內存。這些基礎一直在，並且已經擴展到許多代模型、許多代甚至深度神經網絡算法和模型結構。

長程智能體改變數據中心形態

主持人：說到工作負載變化，過去一年左右最大的變化之一——我認為其實是從今年日曆年年初開始——是長程智能體（long-horizon agent）的崛起。我猜這種工作負載和過去幾年那種快速輪轉的 LLM 對話形狀很不一樣。這對數據中心需求意味着什麼？

阿敏：我認為有兩個巨大方面。第一，它不再是「人——加速——交互」的模式。換句話說，當你在網頁瀏覽器或手機上輸入 prompt 時，當然，響應你的 prompt 會發生大量計算；但當響應返回後，你必須讀它、思考它，然後也許纔有 follow-up。這中間通常是多秒級的交互時間。現在，在長程智能體中，沒有人在環路里，自然不會限速模型收到請求的速度。過去以秒計、也許幾十秒計的交互時間，現在可能進入毫秒級：我一拿到響應，就可以解析它、對它做一點推理，並判斷下一個請求是什麼。

第二個大變化是：所有這些推理和解析大概率發生在 CPU 上。而這個 CPU 接下來必須思考：為了生成下一個 prompt，我還需要收集哪些其他狀態？換句話說，我從這個響應中學到了東西，我要採取下一步；但我其實需要去抓取一些上下文，可能來自本地 DRAM，可能來自另一台 CPU 上別人的 DRAM，可能在 SSD 上，也可能在別處的 HDD 上。所以現在還需要進行大量編排。

因此，設計正在發生相當顯著的變化：加速計算需求在上升，但 CPU、網絡、存儲等傳統數據中心 CPU 等需求也在暴漲。

主持人：這意味着你們要在 GPU 機架旁放更多 CPU 嗎？是 GPU/TPU 機架嗎？

阿敏：這是關鍵問題。回到優化和專門化的問題：如果我們開始在 GPU 和 TPU 旁邊放很多 CPU 機架——這確實是個問題——那就意味着我們無法完全按 TPU 機架相對於 CPU 機架的密度和網絡需求來做專門化。TPU 機架密度會高於 CPU 機架，可能也需要比 CPU 機架更多網絡。換句話說，我們的建築設計會發生變化。

另一個選擇是保持均勻性：把 TPU 或 GPU 全放在一棟樓裏，隔壁樓放 CPU；也許順便說，硬盤必須放在另一棟樓，因為硬盤又有另一套要求。現在你需要在這些樓之間建立相當可觀水平的網絡。一旦離開一棟樓，網絡複雜性會從可靠性、成本角度顯著上升；延遲大概仍可接受，但現在組件之間可能出現數百微秒，甚至更多排隊延遲。所以考慮因素會以非常有趣的方式變化。

主持人：你的工作很難。

阿敏：很難，但也很有趣。

光路交換與網絡現狀

主持人：網絡側發生了什麼？我聽說 Google 一直站在最新網絡技術前沿，包括光網絡。能講講光網絡現狀嗎？

阿敏：大約十五六年前，Google 就是最早把波分複用（WDM）引入數據中心的廠商之一。我們可以在單根光纖中放入多個信號，並把它用於機架之間的所有通信。同時，我們還引入了一項與波分複用一起使用的技術，叫光路交換（optical circuit switching）。本質上，光路交換與傳統電分組交換相反：它完全在光域內傳輸和移動數據。

可以這樣理解底層技術。在分組交換機裏，你會拿到一個帶頭部的分組，在電域裏查看它，根據頭部判斷它要去哪裏；頭部可能有 IP 地址，於是你查表：對於這個目的地，該從哪個端口轉發？基本上每秒有數十億、甚至數萬億個分組以超高速通過並被轉發。而光路交換說的是：我不在電域裏觸碰這些比特。我要做的是，對一個輸入端口，決定把光送到哪個輸出端口。實現方式有多種，我們最初用的是 MEMS 開關：微機電馬達在三維空間裏控制反射鏡。於是我們可編程地控制一個可能有 128 個端口、256 個端口或類似數量的盒子，把進入每根光纖的每個輸入端口映射到某個輸出端口，然後改變反射鏡角度，讓光真的照射到這些鏡子上，並反射到正確的輸出端口。

最初我們做這個有兩個原因。第一，是在機架組之間創造局部性。假設我有一個計算集群和一個存儲集群，共同支持——打個比方——搜索。我們知道這兩個集群會頻繁通信，於是配置反射鏡，在兩者之間 purely optically 創建捷徑，連接兩個機架集群。第二，我們希望能在不實際移動任何光纖的情況下擴展和收縮網絡。這裏不展開細節，我可以在白板上畫出來。光路交換允許你重構網絡 spine，從而擴展或收縮它，而不需要人類做任何事，只需要一個控制器來管理。

快進到 TPU。TPU 有 Taurus 拓撲，把所有 TPU 直接連在一起。前面我聊過吞吐和 goodput。我們能做的一件事是：如果一個 TPU 機架故障，可以用另一個 TPU 機架替換它，而無需移動任何光纖。這裏也得揮揮手或畫白板；但本質上，我們可以說始終保持有一個備用機架，當一個機架故障時，把光重新指向新機架，這可以在毫秒級完成。

主持人：那為什麼還要光纖？為什麼不直接全用自由空間光？

阿敏：問得好。衰減損耗和帶寬會急劇下降。而且在一個非常大的建築範圍內，不靠光纖把所有東西在三維中連接起來，要對準所有光路會非常困難，甚至可能不可能。我們討論過，也確實有過一些非常有趣的討論。但是的，主要還是通過光纖；當光進入光路交換後，本質上光會直接照射到這些微小芯片上。這是網絡的一個大方向。但還有很多可說，網絡在數據中心裏的能力和需求 frankly 都在爆發。

主持人：太酷了。我們完全可以就這個話題單獨聊一整期。

阿敏：是的，非常酷。回到 Ineffable 那張照片，抓住大家眼球的正是那些線纜。而最終其中一些線纜會接入我們數據中心裏的光路交換。

電力是約束條件：公用事業、吉瓦，以及數據中心規模

主持人：明白了。我想轉向電力。你一直在講每瓦 goodput、其他各種「每瓦」指標，這讓我覺得「每瓦」意味着電力在某種意義上是約束條件、稀缺條件或昂貴條件。

阿敏：我經常被問：我們面臨的最大約束是什麼？現實是，並不存在單一的「最大約束」。所有約束都是約束，都超級難，而且會不斷變化。但如果必須從根本上回答，我會說電力是我們面臨的最 fundamental 約束。其他所有問題似乎我們都知道如何在一段時間內解決；電力則是長期 binding 問題。當然，核能或許會帶來豐富清潔能源，到時能解決很多問題；當它何時、以多大規模發生，仍然未知。

主持人：實踐上這是怎麼運作的？你要新建一個數據中心，需要 1 吉瓦電力。我想象你不能直接打電話給 PG&E 說：「嘿，請送 1 吉瓦電過來。」配電實際上是什麼樣？你是否必須一路垂直整合，甚至自己造渦輪機？你們如何解決電力瓶頸？

阿敏：這又是一個大問題、重要問題。我們在 Google 的首選模式始終是接入公用事業、接入電網。所以確實相當於給你數據中心所在地的「最喜歡的公用事業公司」打電話——當然，要非常禮貌——而且當然要提前很多年通知。換句話說，如果談的是吉瓦規模，你不能說「我明天就要 1 吉瓦，什麼時候開始計費？」這是我們一起多年共同規劃的事情。對我們而言，我們也非常重視一點：與這些公用事業合作時，要把基礎設施成本覆蓋掉。這個話題可以聊很久。由於計費機制，理論上公用事業為我們建設容量，可能會導致其他人費率上升；我們確保的是，比如需要建設/升級的輸電線、額外公用事業變電站等，這些費用由我們支付。

所以這是一個長期規劃過程。絕對可能出現這種情況：假設我們在一個我隨手編的年份 2028 年需要 1 吉瓦，而公用事業能在 2029 年給我們 1 吉瓦，2028 年只能給我們比如 700 兆瓦。這時我們可能就面臨如何覆蓋那 300 兆瓦的問題。一個答案是等；另一個答案是，研究如何自己產生其中一部分電力，也許是太陽能，也許配電池作為備份，也許來自其他來源。然後我們再次與公用事業合作。也可能是組合方案：我們在本地保留一定的發電能力，即使公用事業後來完全上線，比如達到吉瓦級，我們實際上還能把電回饋電網。也就是說，在他們需要時回饋電網。比如一年中最熱的兩周，住宅需求巨大；如果我們有本地發電，就可以把電回饋電網。

所以這確實是與公用事業多年合作的過程。為什麼你更傾向這樣做，而不是自己垂直整合？

主持人：正是。

阿敏：主要原因是靈活性和雙方 uplift。可以這樣看：統計複用，或者大數定律。如果我們需要 1 吉瓦電力，並且希望以 99.99% 以上可靠性獲得，可能意味着必須建 2 吉瓦電力。在那個水平——99.99 或 99.999——你必須有 1+1 冗餘，這會很貴。而且還要確保它 ideally 是清潔能源，最好就在數據中心旁邊，這也很有挑戰。現在如果我們與數據中心合作——也許我們自帶一部分，可以在他們需要較少時給電網，也可以取用他們的電——通過在大得多的基數上做統計複用，實際上所有人都是贏家：我們贏，電網贏，居民也贏。我們偏好這種方式。極少數情況下我們也會 behind the meter 做，但即便那樣，也是在假設我們會與公用事業合作、比如一年後併網的前提下做。所以這對我們是 uplift，對電網也是 uplift。

主持人：有道理。你如何決定把一個數據中心建多大？

阿敏：這是一門藝術，也是大量爭論的來源。記得十多年、十五年前，Google 內部甚至有場大辯論：要不要把所有東西放進一個數據中心？那時那會是 1 吉瓦，在如今看來算「簡單年代」的笑了。

其中一個明顯擔憂是單點故障。如果你從 30 年視角看，這是巨大擔憂。另一方面，如果談今天的訓練工作負載，越大越好；從網絡角度看，你確實希望事物儘可能集中在更小距離內。但接着又有兩個問題：單點故障，以及電力可用性。吉瓦在 10 或 15 年前很大，但還能想象；而現在，要把 Google 的全部需求建在一個地方，在這個國家或世界上任何地方都不可能。那最優尺寸是多少？我們確實有模型、仿真器等。但這也取決於地點：有些地方我們會在網絡邊緣，或位於一個國家裏，可能只有幾十兆瓦；我們甚至與 ISP 合作，可能是在伊拉克。好吧，這不是訓練集群。訓練集群可能更接近吉瓦級。其他站點可能是幾百兆瓦，等等。

訓練與服務集群、七歲高齡的 TPU，以及開放標準

主持人：很有意思。我想理解你如何做組合生命周期管理。我猜最大的最新集群用於訓練最新前沿模型，然後回收舊設備跑推理。這個框架對嗎？你們是否也建設推理專用集群？這一切如何運作？

阿敏：你的框架非常合理，也確實有意義。但我會說，推理需求大到我們不能只依賴那些不再被訓練完全佔用的舊訓練集群來作為推理基礎。再想想，我們可能會在某一年把訓練集群集中到少數幾個大站點；讓它們之間的網絡距離保持很小有好處。所以無論它們位於世界何處，在特定年份裏，它們可能位於同一大陸，甚至同一大陸的同一區域。於是其他大陸可能就沒有足夠服務能力。這時我們就必須去建設專門的推理集群，分佈到世界各地。所以你的直覺很準，但不完全。確實必須是：這裏是訓練集群；是的，幾年後它們大概率會用於服務；但我們同時也必須建設服務集群。

主持人：你的服務集群和訓練集群不同嗎？更小嗎？每兆瓦更便宜嗎？

阿敏：不一定更便宜，因為服務更需要把計算、網絡和存儲放在一起，於是又回到無法完全專門化的問題。訓練時可以做大密度、均勻部署等；而服務需要存儲、計算和加速器混合。此外，服務還有一個很有意思的方面——可以以後再展開——就是你其實不希望在同一個地方放太多服務負載；你希望從全球各地為用戶服務工作負載提供服務。但現在我們擁有單個模型 endpoint，實際上可能是模型的不同變體，於是還必須把這些模型分佈到全球，同時考慮 locality。所以服務集群會更小， infant 側可能垂直整合程度也更低。

主持人：非常有意思。如果你五年前建了一個數據中心，當時最先進的加速器跟今天相比完全不同，效率低得多。你們真的會回去更換舊數據中心裏的芯片嗎？我知道這關係到一個持續爭論：芯片實際有效壽命到底是多少？

阿敏：是的。我之前公開說過這句話，而且我有點驚訝它引起這麼大反響：我們七八年前的 TPU 仍然保持 100% 利用率。我的本意並不是要發表什麼重大聲明，但顯然它成了有意義的聲明。我們較老的 TPU——以及 GPU——但我們的老 TPU 確實仍在被高度使用。最終我們還是會替換它們。問題是：一旦折舊壽命大約六年結束，並且考慮到新一代的能效等，替換升級確實有意義。並不是說我「更換芯片」，而真的是更換系統。換句話說，我們按 pod 思考。比如一個 TPU 8 pod 可能是 9600 顆芯片，約 140 多、152 個機架等。於是我們會說，要把這個 pod 拉出來，換成 TPU 12 或 13 或 14 pod。新 pod 佔地未必和舊 pod 空缺完美匹配，所以我們必須考慮這一點，研究如何改造。我們無法提前規劃這個，因為我們不知道那麼多代 TPU 會是什麼樣。所以這又是一門藝術，並且要實際做很多艱苦工作，弄清楚如何分解舊系統，然後儘快用新 TPU 替換。

主持人：你公開寫過關於開放標準的文章。能講講嗎？

阿敏：我們前面談過互操作問題。對我們來說，雖然支持垂直整合，也允許你盡情榨取性能，但非常重要的一點是：不強制鎖定，不強制端到端的「圍牆花園」。舉個例子，在 Google，我們開發了一個模型開發框架叫 JAX。我們很喜歡它，認為它非常好，內部大量使用；而我們很多客戶喜歡 PyTorch。一種做法是我們說：「嘿，如果你想在 TPU 上跑，就必須用 JAX，因為它最好。」我這是半開玩笑；也許它確實最好，但這不是唯一選擇，不能因為它「很好」就只給這個選擇。另一種做法是：如果你喜歡 JAX，我們也喜歡 JAX，你可以用；如果你喜歡 PyTorch，我們有 Torch TPU，你未修改的模型等也可以跑。

歷史上我們見過很多這樣的例子。我用過 IP 的例子：為什麼互聯網協議贏了？其實在 70 年代和 80 年代初，IP 有很多競爭協議。IP 贏是因為它是開放標準，是沙漏形結構中的「細腰」：任何軟件都可以跑在它上面，任何硬件都可以跑在它下面。開放、可互操作；任何帶來 IP 的設備都能插進路由器端口，立刻成為互聯網一部分。它很美，也讓互聯網得以在全世界爆炸式增長、擴展。所以我們真的相信這些開放標準，相信插件式接入點。如果你想接入高度專門化的東西，也可以；如果你認為有更好的東西接入我們的框架，你絕對可以。但我們希望真正支持開放標準，理想情況下還有圍繞它的開源。這次建設太大、太重要了，不能成為任何一家廠商的封閉專有棧。我們真的相信這一點，必須是選擇。這也是為什麼，比如我們完全支持並擁有 TPU、GPU、其他加速器等等。

主持人：AI 如何改變你團隊的日常工作？它在哪個層面對你們職能改變最大？

阿敏：最容易的回答是軟件工程側。這一點外部已經有很多記錄。我認為 Google 以及我的團隊都在非常有效地用它提升軟件開發能力，也 frankly 用於測試發布，甚至幫助設計等。但在硬件側，也許外部報道較少，也發生了顯著變化。換句話說，我的硬件工程師——我今天早些時候剛看了數據——使用 AI 的程度和軟件工程師一樣多。你可以看 token 數，這不是最好的指標，但仍然是個指標。硬件工程師使用 AI 的量已經和軟件工程師相當。生產率也上升了。從設計啓動到 tape-out 的時間在縮短；bringup 時間也在縮短。另一個生產率顯著上升的地方，也許是較意想不到的變化：數據中心設計方式也顯著改變了。也就是我們如何做數據中心設計、如何評估——你剛纔提到，我們是建 1 吉瓦單體樓，還是 100 兆瓦園區、200 兆瓦園區？過去這會是非常細緻、非常電子表格驅動、由人驅動流程；現在仍在某種程度上如此，但已經有大量 AI 參與，真正精簡了規劃和開發流程。

主持人：有意思。是推理模型嗎？

阿敏：還不能完全說是推理模型。它沒有取代人類判斷，但確實讓把必要信息彙集到一處、 basically 把正確信息放到做決策的人面前，變得容易得多。

軌道數據中心與 2036 年的超級計算機

主持人：最後我用兩個有點「放飛」但好玩的問題收尾。第一個：軌道數據中心。我看到 Google 對此相當認真。你想讓我評論一下。人們認真計算軌道計算這件事本身，是否意味着地球上存在嚴肅的約束條件？你怎麼看軌道數據中心？

阿敏：這是一個令人興奮的方向。我們確實在推進，並且毫不調侃地把它稱為一個 moonshot，是我們非常樂意投資的大項目之一。回到對話前面你正確提出的部分：從根本約束看，能源和能源生產是關鍵挑戰。根本上說，在太空中，由於沒有大氣衰減等因素，可用功率大約多 40%。也就是說，僅僅日照容量就是 1.4 倍。這是其一。但在太陽同步軌道上，你的太陽能電池可獲得 98% 到 100% 的日照覆蓋，而陸地上可能只有 28%、30%，也許 35%。也就是說，能量極其充沛： obviously，你拿到 1.4 倍，再乘上每天日照小時數的 3 到 4 倍，並大體把電池從等式中移除，現在就有可能得到真正可觀的東西。當然，它無碳，有很多好處，也有很多挑戰。

挑戰確實很多。比如冷卻：你可能天真地以為太空中冷卻更容易，實際上更難。可靠性：我們剛聊過這些設備有時會壞。維修在太空中變得更難——不是不可能，但更難。你剛纔關於自由空間光學的 pre question 現在會成真：我們大概不會在這些組件之間拉光纖，所以真的會是自由空間光，激光指向接收器並實時校準。這裏沒有什麼「根本性 showstopper」。

主持人：最後一個問題。我腦子裏一直裝着你們為 Ineffable 建的超級計算機畫面。所以問題是：十年後，最前沿的超級計算機會是什麼樣子？

阿敏：天哪。十年正好處於那個邊界上。我要非常誠懇地說：可能有些人已經在想 2036 年的計算機會是什麼樣。我們可能也有少數人想得那麼遠。但那裏的不確定性錐實在太寬了。看趨勢的話，集成度將會非常驚人。我們看到了為 Ineffable 組裝的 VR200 機架裏漂亮的光纖。我的猜測是，它會更加集成，光纖更少。我不會說 2036 年沒有光纖，但我認為從機架視角看，機架會顯得更緊密集成，可能只有一小束光纖從機架裏出來。然後從模塊化製造角度看，2036 年的這些機架很可能會集中製造。無論裏面是 72、144、288，還是——既然聊到 Ineffable 案例，可能是 576、1152 個，隨便選一個 GPU 的倍數；TPU 也一樣——GPU/TPU 都深度集成進機架。一個機架會是多兆瓦嗎？我們不知道具體如何，但 2036 年我們可以想象：單個機架可能達到數兆瓦。這時你引入水、引入電、引入光纖，把這個機架推進來，插上這三樣東西，就出發去跑了。

主持人：所以到 2036 年，它不會是一個漂浮在太空中的大異形球體？

阿敏：我不會說 2036 年不可能把它直接發射到太空，然後由空間站機械臂接住，插進正確模塊。也許 2036 年就會那樣。

主持人：想想就開心。我非常享受這場對話。這是歷史上最 intense、規模最大的資本開支建設，但我也認為這是一場技術革命，而且是一件美的事物。你對技術之美、約束條件以及如何平衡這一切有非常深刻的把握。Google 交給你很好。謝謝你抽時間分享你們正在做的事。

阿敏：非常開心。非常感謝。這是一場很棒的對話。我們有機會親歷這一切，並且有機會定義它。謝謝你。