SemiAnalysis深度解讀TPU--谷歌衝擊「英偉達帝國」

 

（來源：網易科技）

2025年的AI芯片市場，正處於一個微妙的轉折點。

一方面，英偉達依然憑藉Blackwell維持着技術和市場份額的絕對領先；但另一方面，谷歌TPU的全面商業化，讓英偉達看似牢不可破的定價權，正在發生松動。

據半導體行業研究機構SemiAnalysis測算，OpenAI僅憑「威脅購買TPU」這一籌碼，就迫使英偉達生態鏈做出了實質性讓步，使其計算集羣的總擁有成本（TCO）下降了約30%。

隨着Anthropic高達1GW的TPU採購細節曝光，谷歌正式撕下了「雲服務商」的面具，轉型為一家直接向外部出售高性能芯片與系統的「商用芯片供應商」。

當OpenAI可以用「威脅購買TPU」來換取30%的折扣，當Anthropic可以用TPU訓練出超越GPT-4的模型，當谷歌願意開放軟件生態並提供金融槓桿時，英偉達高達75%的毛利率神話便不再牢不可破。

對於英偉達來説，那個曾經最大的客户，現在變成了最懂的對手。

(圖表：每百萬輸入和輸出代幣的成本)

谷歌「主動出擊」

長期以來，谷歌的TPU就像其搜索算法一樣，是深藏不露的內部核武器。但SemiAnalysis獲取的供應鏈情報顯示，這一策略已發生根本性逆轉。

最直接的案例來自Anthropic。作為能在前沿模型上媲美OpenAI抗衡的大模型公司，Anthropic已確認將部署超過100萬顆TPU。這筆交易的結構極具破壞力，它揭示了谷歌「混合銷售」的新模式：

在這100萬顆芯片中，首批約40萬顆最新的TPUv7 "Ironwood"將不再通過雲租賃，而是由博通直接出售給Anthropic，價值約100億美元。博通作為TPU的長期聯合設計方，在此次交易中從幕后走向臺前，成爲了這場算力轉移的隱形贏家。

而剩余的60萬顆TPUv7，則通過谷歌雲進行租賃。據估算，這部分交易涉及高達420億美元的剩余履約義務（RPO），直接支撐了谷歌雲近期積壓訂單的暴漲。

這一動作的信號極為明確：谷歌不再吝嗇於將最先進的算力外售。除了Anthropic，Meta、SSI、xAI等頂級AI實驗室也出現在了潛在客户名單中。

面對這一突如其來的攻勢，英偉達罕見地展現出防禦姿態，其財務團隊近期不得不針對「循環經濟」（即投資初創公司購買自家芯片）的質疑發佈長文辯解。這種對市場情緒的敏感反應，恰恰説明谷歌的攻勢已經觸及了英偉達的神經。

成本是硬道理

客户倒戈的理由很純粹：在AI軍備競賽中，性能是入場券，但TCO（總擁有成本）決定生死。

SemiAnalysis的模型數據顯示，谷歌TPUv7在成本效率上對英偉達構成了碾壓優勢。

從谷歌內部視角看，TPUv7服務器的TCO比英偉達GB200服務器低約44%。即便加上谷歌和博通的利潤，Anthropic通過GCP使用TPU的TCO，仍比購買GB200低約30%。

這種成本優勢並非僅靠壓低芯片價格實現，而是源於谷歌獨特的金融工程創新——「超級雲廠商兜底」。

在AI基礎設施建設中，存在一個巨大的期限錯配：GPU集羣的經濟壽命僅為4-5年，而數據中心場地的租賃合約通常長達15年以上。這種錯配讓Fluidstack、TeraWulf等新興算力服務商難以獲得融資。

谷歌通過一種「資產負債表外」的信貸支持（IOU）解決了這一難題：谷歌承諾，如果中間商無法支付租金，谷歌將介入兜底。

這一金融工具直接打通了加密貨幣礦工（擁有電力和場地）與AI算力需求之間的堵點，構建了一個獨立於英偉達體系之外的低成本基礎設施生態。

不僅是芯片，還有系統

如果説價格戰是戰術層面的對壘，那麼系統工程則是谷歌戰略層面的護城河。

之前，業界素有「系統重於微架構」的觀點。如今，這一論斷在TPUv7上得到了驗證。雖然單顆TPUv7在理論峰值算力（FLOPs）上略遜於英偉達的Blackwell，但谷歌通過極致的系統設計抹平了差距。

現在，TPUv7 "Ironwood"在內存帶寬和容量上已大幅縮小與英偉達旗艦芯片的差距。更重要的是，它採用了更務實的設計哲學——不追求不可持續的峰值頻率，而是通過更高的模型算力利用率（MFU）來提升實際產出。

而谷歌真正的殺手鐗，是其獨步天下的光互連（ICI）技術。不同於英偉達依賴昂貴的NVLink和InfiniBand/Ethernet交換機，谷歌利用自研的光路交換機（OCS）和3D Torus拓撲結構，構建了名為ICI的片間互連網絡。

這一架構允許單個TPUv7集羣（Pod）擴展至驚人的9,216顆芯片，遠超英偉達常見的64或72卡集羣。OCS允許通過軟件定義網絡，動態重構拓撲結構。

這意味着如果某部分芯片故障，網絡可以毫秒級繞過故障點，重新「切片」成完整的3D環面，極大地提升了集羣的可用性。且光信號在OCS中無需進行光電轉換，直接物理反射，大幅降低了功耗和延迟。

Gemini 3和Claude 4.5 Opus這兩大全球最強模型均完全在TPU上完成預訓練，這本身就是對TPU系統處理「前沿模型預訓練」這一最高難度任務能力的終極背書。

拆除最后的圍牆：軟件生態的改變

長期以來，阻礙外部客户採用TPU的最大障礙是軟件——谷歌固守JAX語言，而全球AI開發者都在使用PyTorch和CUDA。

但在巨大的商業利益面前，谷歌終於放下了傲慢。

SemiAnalysis報告指出，谷歌軟件團隊的KPI已發生重大調整，從「服務內部」轉向「擁抱開源」。

此前，谷歌「超級隊長」 Robert Hundt已明確宣佈，將全力支持PyTorch Native在TPU上的運行。

谷歌不再依賴低效的Lazy Tensor轉換，而是通過XLA編譯器直接對接PyTorch的Eager Execution模式。這意味着Meta等習慣使用PyTorch的客户，可以幾乎無縫地將代碼遷移到TPU上。

同時，谷歌開始向vLLM和SGLang等開源推理框架大量貢獻代碼，打通了TPU在開源推理生態中的任督二脈。

這一轉變意味着英偉達最堅固的「CUDA護城河」，正在被谷歌用「兼容性」填平。

而這場「硅谷王座」的爭奪戰，纔剛剛開始。

全文翻譯

以下是SemiAnalysis本次報告的全文翻譯部分（由AI翻譯）：

TPUv7：谷歌向王者揮拳

CUDA 護城河的終結？Anthropic 簽下 1GW+ TPU 採購大單；Meta/SSI/xAI/OAI/Anthro 購買的 TPU 越多，節省的 GPU 資本支出（Capex）就越多；下一代 TPUv8AX 和 TPUv8X 將正面對決 Vera Rubin。

當今世界最頂尖的兩個模型——Anthropic 的 Claude 4.5 Opus 和谷歌的 Gemini 3，其絕大部分訓練和推理基礎設施都運行在谷歌的 TPU 和亞馬遜的 Trainium 上。如今，谷歌正打破常規，開始向多家企業直接出售物理 TPU 硬件。這是 Nvidia 統治終結的序章嗎？

AI 時代的黎明已至，至關重要的是要理解，AI 驅動的軟件其成本結構與傳統軟件截然不同。芯片微架構和系統架構在這些創新型軟件的開發和擴展中扮演着決定性角色。與早期軟件時代開發人員成本佔比較高的情況相比，AI 軟件運行的硬件基礎設施對資本支出（Capex）和運營支出（Opex）——進而對毛利率——有着顯著更大的影響。因此，爲了能夠部署 AI 軟件，投入大量精力優化 AI 基礎設施變得前所未有的關鍵。在基礎設施方面擁有優勢的公司，在部署和擴展 AI 應用的能力上也必將佔據高地。

早在 2006 年，谷歌就曾兜售過構建 AI 專用基礎設施的理念，但這個問題在 2013 年達到了沸點。他們意識到，如果想要以任何規模部署 AI，就需要將現有的數據中心數量翻倍。因此，他們開始為 TPU 芯片奠定基礎，並於 2016 年投入生產。有趣的是，亞馬遜在同一年也意識到需要構建定製芯片。2013 年，亞馬遜啟動了 Nitro 項目，專注於開發芯片以優化通用 CPU 計算和存儲。兩家截然不同的公司針對不同的計算時代和軟件範式，優化了各自的基礎設施路徑。

我們長期以來一直認為，TPU 是世界上用於 AI 訓練和推理的最佳系統之一，與「叢林之王」 Nvidia 並駕齊驅。2.5 年前，我們寫過關於「TPU 霸權」的文章，這一論點已被時間證明是非常正確的。

TPU 的成績不言自明：Gemini 3 是世界上最好的模型之一，且完全在 TPU 上訓練。在本報告中，我們將深入探討谷歌戰略的巨大轉變——即適當地將 TPU 商業化以供外部客户使用，使其成為 Nvidia 最新且最具威脅的商用芯片（Merchant Silicon）挑戰者。

本報告計劃：

首先，讓我們談談這則新聞對生態系統的影響。TPU 的性能顯然引起了競爭對手的注意。Sam Altman 承認，由於 Gemini 搶了 OpenAI 的風頭，OpenAI 正面臨「倍感壓力（rough vibes）」的局面。Nvidia 甚至發佈了一份令人寬慰的公關稿，告訴大家保持冷靜並繼續前進——聲稱自己仍遙遙領先於競爭對手。

我們理解其中的原因。過去幾個月對於 Google Deepmind、GCP（谷歌雲平臺）和 TPU 綜合體來説是一個接一個的勝利。TPU 產量的大幅上調、Anthropic 超過 1GW 的 TPU 擴建、在 TPU 上訓練的 SOTA（最先進）模型 Gemini 3 和 Opus 4.5，以及現在正在擴大的目標客户名單（Meta、SSI、xAI、OAI）排隊等待 TPU。這推動了谷歌和 TPU 供應鏈的巨大價值重估，而代價是 Nvidia GPU 供應鏈的損失。雖然谷歌和 TPU 供應鏈的「突然」崛起讓許多人感到驚訝，但 SemiAnalysis 的機構產品訂閲者在過去一年中早已預料到了這一點。

(圖表：TPU、Trainium、Nvidia 風險敞口的基礎設施籃子對比)

Nvidia 處於守勢的另一個原因是，越來越多的懷疑論者認為該公司正在通過資助燒錢的 AI 初創公司來支撐一種「循環經濟」，本質上是用額外的步驟將錢從一個口袋轉移到另一個口袋。我們認為這種觀點是有失偏頗的，但這顯然觸動了 Nvidia 內部的神經。財務團隊發佈了一份詳細的迴應，轉載如下。

我們認為更現實的解釋是，Nvidia 旨在通過提供股權投資而不是降價來保護其在**基礎實驗室（Foundation Labs）**的主導地位，因為降價會降低毛利率並引起廣泛的投資者恐慌。下面，我們概述了 OpenAI 和 Anthropic 的安排，以展示前沿實驗室如何通過購買或威脅購買 TPU 來降低 GPU TCO。

(表格：你買的 TPU 越多，你省下的 GPU 費用就越多)來源：SemiAnalysis TCO 模型，Anthropic 和 OpenAI

OpenAI 甚至還沒有部署 TPU，他們就已經在整個實驗室範圍內的 NVIDIA 艦隊上節省了約 30%。這證明了 TPU 的每 TCO 性能優勢是如此強大，以至於你甚至在開啟一臺 TPU 之前就已經獲得了採用 TPU 的收益。

我們的加速器行業模型、數據中心行業模型和核心研究訂閲者在這一消息宣佈併成為市場共識之前很久就看到了行業影響。8 月初，我們與加速器模型客户分享了我們看到供應鏈中 Broadcom / Google TPU 訂單在 2026 年的大規模上調。我們還透露，這些訂單增加的原因是谷歌將開始向多個客户外部銷售系統。9 月初，我們透露其中一個大的外部客户將是 Anthropic，需求至少為 100 萬個 TPU。這在 10 月份得到了 Anthropic 和谷歌的正式確認。我們還在 11 月 7 日指出 Meta 是一個大的 TPU 客户，比其他人早了幾周。此外，我們也討論了其他客户。

結果，我們的機構客户對 AI 交易中迄今為止最大的**性能分化（Performance Dispersion）**有了充分的預期。SemiAnalysis 是第一個披露所有這些見解的公司，因為沒有其他研究公司能夠將從晶圓廠到供應鏈，再通過數據中心到實驗室的點連接起來。

言歸正傳。

谷歌的大規模 TPU 外部化推進與 Anthropic 交易

TPU 堆棧長期以來一直與 Nvidia 的 AI 硬件相媲美，但它主要支持谷歌的內部工作負載。按照谷歌的一貫作風，即使在 2018 年向 GCP 客户提供 TPU 后，它也從未將其完全商業化。這種情況正在開始改變。在過去的幾個月里，谷歌動員了整個堆棧的力量，通過 GCP 將 TPU 帶給外部客户，或者作為商業供應商銷售完整的 TPU 系統。這家搜索巨頭正在利用其強大的內部芯片設計能力，成為一家真正差異化的雲提供商。此外，這與旗艦客户（Marquis Customer）Anthropic 繼續推動擺脫對 NVDA 依賴的戰略相一致。

(圖表：Anthropic FLOP 組合)

Anthropic 的交易標誌着這一推進的一個重要里程碑。我們瞭解到 GCP CEO Thomas Kurian 在談判中發揮了核心作用。谷歌很早就承諾積極投資 Anthropic 的融資輪次，甚至同意放棄投票權並將所有權上限設定為 15%，以將 TPU 的使用擴展到谷歌內部之外。前 DeepMind TPU 人才在基礎實驗室的存在促進了這一戰略的實施，導致 Anthropic 在包括 TPU 在內的多種硬件上訓練 Sonnet 和 Opus 4.5。谷歌已經為 Anthropic 建立了一個實質性的設施，如下所示，這是我們「逐個建築追蹤 AI 實驗室」項目的一部分。

(圖片：數據中心行業模型)

除了通過 GCP 租用谷歌數據中心的容量外，Anthropic 還將在其自己的設施中部署 TPU，這使谷歌能夠作為真正的商用硬件供應商直接與 Nvidia 競爭。

關於 100 萬個 TPU 的拆分：

儘管內部和外部需求巨大，但谷歌未能按其希望的速度部署 TPU。儘管與仍需「討好」 Jensen（黃仁勛）的其他超大規模廠商相比，谷歌對其硬件供應有更多的控制權，但谷歌的主要瓶頸是電力。

當其他超大規模廠商擴大自己的站點並獲得大量託管容量時，谷歌的行動較為緩慢。我們認為核心問題是合同和行政方面的。每個新的數據中心供應商都需要一份主服務協議（MSA），這些是數十億美元、多年的承諾，自然涉及一些官僚主義。然而，谷歌的流程特別慢，從最初的討論到簽署 MSA 通常需要長達三年的時間。

谷歌的變通方案對尋求轉向 AI 數據中心基礎設施的 Neocloud 提供商和加密貨幣礦工具有重大影響。谷歌不直接租賃，而是提供信用兜底（credit backstop），即如果 Fluidstack 無法支付其數據中心租金，谷歌將介入支付，這是一張資產負債表外的「借條（IOU）」。

(圖表：Fluidstack 交易概覽)

像 Fluidstack 這樣的 Neocloud 靈活敏捷，使他們更容易與像「轉型后的加密礦工」這樣的新數據中心供應商打交道。這種機制一直是我們看好加密採礦行業的關鍵——值得注意的是，我們在今年年初股價大幅降低時就點名了包括 IREN 和 Applied Digital 在內的眾多公司。

礦工的機會在於一個簡單的動態：數據中心行業面臨嚴重的電力限制，而加密礦工通過其購電協議（PPA）和現有的電力基礎設施已經控制了容量。我們預計未來幾周和幾個季度將有更多協議達成。

谷歌如何重塑 Neocloud 市場

在 Google/Fluidstack/TeraWulf 交易之前，我們在 Neocloud 市場從未見過任何僅憑資產負債表外「借條」達成的交易。交易之后，我們認為它已成為新的事實上的標準融資模板。這解決了 Neocloud 尋求確保數據中心容量並發展業務的一個關鍵難題：

這種期限錯配使得 Neocloud 和數據中心供應商為項目融資變得非常複雜。但隨着「超大規模廠商兜底」的興起，我們相信融資問題已得到解決。我們預計 Neocloud 行業將迎來新一波增長。查看我們的加速器和數據中心模型以瞭解主要的受益者。這些是 Anthropic 交易背后的方式和原因，現在讓我們進入硬件部分。

此外，擁有 Jensen 作為投資者的 Neocloud，如 CoreWeave、Nebius、Crusoe、Together、Lambda、Firmus 和 Nscale，都有明顯的動機不採用其數據中心內的任何競爭技術：TPU、AMD GPU 甚至 Arista 交換機都是禁區！這在 TPU 託管市場留下了一個巨大的缺口，目前由加密礦工 + Fluidstack 填補。在接下來的幾個月里，我們預計會看到更多的 Neocloud 在追求不斷增長的 TPU 託管機會和確保最新最棒的 Nvidia Rubin 系統分配之間做出艱難的決定。

TPUv7 Ironwood – 為什麼 Anthropic 和其他客户想要 TPU？

答案很簡單。這是一個優秀的系統中的強大芯片，這種組合爲 Anthropic 提供了令人信服的性能和 TCO。2.5 年前，我們寫過關於谷歌計算基礎設施優勢的文章。即使芯片在紙面上落后於 Nvidia，谷歌的系統級工程也允許 TPU 堆棧在性能和成本效率上與 Nvidia 匹敵。

我們當時認為「系統比微架構更重要」，過去兩年的情況加強了這一觀點。Anthropic 的大規模 TPU 訂單是對該平臺技術實力的直接驗證。GPU 生態系統也向前邁進了一步。Nvidia 的 GB200 代表了一個巨大的飛躍，推動 Nvidia 成為一家真正的系統公司，設計完整的服務器而不僅僅是內部的芯片封裝。

當我們談論 GB200 在機架級互連方面的巨大創新時，一個被低估的點是，自 2017 年 TPU v2 以來，谷歌一直在機架內和跨機架縱向擴展（Scaling up）TPU！在報告的后面，我們將對谷歌的 ICI 擴展網絡進行深入分析，這是 Nvidia NVLink 的唯一真正競爭對手。

谷歌最近的 Gemini 3 模型現在被視為最先進的前沿 LLM。像所有早期版本的 Gemini 一樣，它完全在 TPU 上訓練。這一結果為 TPU 能力和谷歌更廣泛的基礎設施優勢提供了具體證明。

今天的注意力通常集中在推理和后訓練的硬件上，但預訓練前沿模型仍然是 AI 硬件中最困難和資源最密集的挑戰。TPU 平臺已經果斷地通過了這一測試。這與競爭對手形成鮮明對比：OpenAI 的領先研究人員自 2024 年 5 月的 GPT-4o 以來尚未完成廣泛用於新前沿模型的成功全規模預訓練運行，突顯了谷歌 TPU 艦隊已成功克服的重大技術障礙。

新模型的一個關鍵亮點包括在工具調用和代理能力方面的顯著提升，特別是在具有經濟價值的長期任務上。Vending Bench 是一項旨在衡量模型在長期內經營業務的能力的評估，通過將它們置於模擬自動售貨機業務的所有者位置，Gemini 3 摧毀了競爭對手。

(圖表：Vending-Bench 資金隨時間變化)

這次發佈不僅帶來了能力的提升，還帶來了新產品。Antigravity，一個源於收購前 Windsurf CEO Varun Mohan 及其團隊的產品，是谷歌對 OpenAI Codex 的迴應，正式讓 Gemini 進入了「直覺式編程（vibe coding）」的代幣消耗戰。

對於谷歌來説，悄悄地介入並在最具挑戰性的硬件問題之一上建立性能領先地位，對於一家核心業務不是——或者我們應該説，曾經不是——硬件業務的公司來説，確實是一個令人印象深刻的壯舉。

微架構仍然很重要：Ironwood 接近 Blackwell

「系統比微架構更重要」的推論是，雖然谷歌一直在推動系統和網絡設計的邊界，但 TPU 芯片本身並不是太具突破性。從那時起，TPU 芯片在最新幾代中取得了巨大進步。

從一開始，谷歌的設計理念相對於 Nvidia 在芯片上就更為保守。歷史上，TPU 的峰值理論 FLOPs 明顯較少，內存規格也低於相應的 Nvidia GPU。

這有 3 個原因。首先，谷歌對其基礎設施的「RAS」（可靠性、可用性和可維護性）給予了很高的內部重視。谷歌寧願犧牲絕對性能來換取更高的硬件正常運行時間。將設備運行到極限意味着更高的硬件死亡率，這對系統停機時間和熱備件方面的 TCO 有實際影響。畢竟，你無法使用的硬件相對於性能來説具有無限的 TCO。

第二個原因是，直到 2023 年，谷歌的主要 AI 工作負載是為其核心搜索和廣告資產提供動力的推薦系統模型。與 LLM 工作負載相比，RecSys 工作負載的**算術強度（arithmetic intensity）**要低得多，這意味着相對於傳輸的每一位數據，所需的 FLOPs 更少。

(圖表：Reco vs. LLM)

第三點歸結為被營銷的「峰值理論 FLOPs」數字的效用以及它們如何被操縱。像 Nvidia 和 AMD 這樣的商用 GPU 提供商希望為其芯片營銷最佳的性能規格。這激勵他們將營銷的 FLOPs 拉伸到儘可能高的數字。實際上，這些數字是無法維持的。另一方面，TPU 主要面向內部，在外部誇大這些規格的壓力要小得多。這具有我們將進一步討論的重要含義。客氣的看法是 Nvidia 更擅長 DVFS（動態電壓頻率調整），因此樂於僅報告峰值規格。

在我們進入 LLM 時代后，谷歌的 TPU 設計理念發生了明顯的轉變。我們可以看到，在 LLM 之后設計的最新兩代 TPU：TPUv6 Trillium (Ghostlite) 和 TPUv7 Ironwood (Ghostfish) 反映了這種變化。我們可以在下面的圖表中看到，對於 TPUv4 和 v5，計算吞吐量遠低於當時的 Nvidia 旗艦產品。TPUv6 在 FLOPs 上非常接近 H100/H200，但它比 H100 晚了 2 年。隨着 TPU v7 的推出，差距進一步縮小，服務器僅晚幾個季度可用，同時提供幾乎相同水平的峰值理論 FLOPs。

(圖表：TPU 與 Nvidia 的 TFLOPs 和系統可用性對比 (BF16 Dense))

是什麼推動了這些性能提升？部分原因是谷歌開始在 TPU 投入生產時宣佈它們，而不是在下一代部署后才宣佈。此外，TPU v6 Trillium 採用與 TPU v5p 相同的 N5 節點製造，硅面積相似，但能夠提供驚人的 2 倍峰值理論 FLOPs 增加，且功耗顯著降低！對於 Trillium，谷歌將每個**脈動陣列（systolic array）**的大小從 128 x 128 增加到 256 x 256 tiles，翻了兩番，這種陣列大小的增加帶來了計算能力的提升。

(表格：谷歌 TPU 芯片規格)

Trillium 也是最后一個「E」（lite）SKU，這意味着它僅配備了 2 個 HBM3 站點。雖然 Trillium 在計算上縮小了與 Hopper 的差距，但在內存容量和帶寬上遠低於 H100/H200，僅有 2 堆棧 HBM3，而后者分別為 5 和 6 堆棧 HBM3 和 HBM3E。這使得新手使用起來很痛苦，但如果你正確地對模型進行**分片（shard）**並利用所有那些廉價的 FLOPS，Trillium 實現的性能 TCO 是無與倫比的。

(圖表：TPU v6 (Trillium) vs H100 (SXM) 比較)

TPU v7 Ironwood 是下一次迭代，谷歌在 FLOPs、內存和帶寬方面幾乎完全縮小了與相應 Nvidia 旗艦 GPU 的差距，儘管全面上市時間比 Blackwell 晚 1 年。與 GB200 相比，FLOPs 和內存帶寬僅有輕微的短缺，容量與 8-Hi HBM3E 相同，當然這與擁有 288GB 12-Hi HBM3E 的 GB300 相比有顯著差距。

(圖表：TPU v7 (Ironwood) vs GB200/GB300 比較)

理論絕對性能是一回事，但真正重要的是每總擁有成本 (TCO) 的真實世界性能。

雖然谷歌通過 Broadcom 採購 TPU 並支付高額利潤，但這遠低於 Nvidia 不僅在銷售 GPU 上，而且在包括 CPU、交換機、NIC、系統內存、佈線和連接器在內的整個系統上賺取的利潤。從谷歌的角度來看，這導致全 3D 環面（3D Torus）配置的每 Ironwood 芯片的全包 TCO比 GB200 服務器的 TCO 低約 44%。

這足以彌補峰值 FLOPs 和峰值內存帶寬約 10% 的短缺。這是從谷歌的角度以及他們採購 TPU 服務器的價格來看的。

(表格：Nvidia vs TPU SKU 每 TCO 性能比較)

那麼當谷歌加上他們的利潤后，對於外部客户來説呢？我們假設在谷歌向外部客户租賃 TPU 7 賺取利潤的情況下，每小時 TCO 仍然可以比 GB200 的成本低約 30%，比 GB300 的成本低約 41%。我們認為這反映了 Anthropic 通過 GCP 的定價。

(圖表：每小時總成本比較 (USD/hr/GPU))

為什麼 Anthropic 押注 TPU

比較理論 FLOPs 只能説明部分情況。重要的是有效 FLOPs，因為峰值數字在實際工作負載中幾乎從未達到。

實際上，一旦考慮到通信開銷、內存停頓、功率限制和其他系統效應，Nvidia GPU 通常只能達到其理論峰值的一小部分。訓練的一個經驗法則是 30%，但利用率也因工作負載而異。差距的很大一部分歸結為軟件和編譯器效率。Nvidia 在這方面的優勢源於 CUDA 護城河和開箱即用的廣泛開源庫，幫助工作負載高效運行，實現高 FLOPs 和內存帶寬利用率。

TPU 軟件堆棧並不那麼容易使用，儘管這正在開始改變。在谷歌內部，TPU 受益於優秀的內部工具，這些工具不對外部客户開放，這使得開箱即用的性能較弱。然而，這隻適用於小型和/或懶惰的用户，而 Anthropic 兩者都不是。

Anthropic 擁有強大的工程資源和前谷歌編譯器專家，他們既瞭解 TPU 堆棧，也深入瞭解自己的模型架構。他們可以投資定製內核以推動高 TPU 效率。結果，他們可以達到大幅更高的 MFU 和更好的每 PFLOP 性能價格比。

我們相信，儘管營銷的峰值 FLOPs 較低，TPU 可以達到比 Blackwell 更高的已實現模型 FLOP 利用率 (MFU)，這意味着 Ironwood 的有效 FLOPs 更高。一個主要原因是 Nvidia 和 AMD 營銷的 GPU FLOPs 明顯被誇大了。即使在旨在通過 GEMM 最大化吞吐量的測試中（形狀遠非實際工作負載），Hopper 僅達到峰值的約 80%，Blackwell 落在 70% 左右，而 AMD 的 MI300 系列在 50%-60% 之間。

限制因素是電力傳輸。這些芯片無法維持峰值數學運算中使用的時鍾速度。Nvidia 和 AMD 實施動態電壓和頻率縮放 (DVFS)，這意味着芯片的時鍾頻率根據功耗和熱量動態調整，而不是可以實際維持的穩定時鍾頻率。Nvidia 和 AMD 然后選擇可能交付的最高時鍾頻率（即使是非常間歇性的）用於計算峰值理論 FLOPs（每個周期的操作數/ALU x ALU 數量 x 每秒周期數，即時鍾頻率）。

還有其他技巧被使用，比如在零填充張量（zero-filled tensors）上運行 GEMM，因為 0x0=0，晶體管不需要從 0 切換到 1，從而降低了每次操作的功耗。當然，在現實世界中，零填充張量不會相乘。

當我們結合低得多的 TCO 和更高的有效 FLOPs 利用率時，從谷歌的角度來看，每有效 FLOP 的美元成本變得便宜得多，約 15% 的 MFU 是與 30% MFU 的 GB300 的盈虧平衡點。這意味着如果谷歌（或 Anthropic）設法達到 GB300 FLOPs 利用率的一半，他們仍然能打平。當然，憑藉谷歌的精英編譯器工程師團隊和對自己模型的深刻理解，他們在 TPU 上實現的 MFU 可能達到 40%。那將是每有效訓練 FLOP 成本驚人的約 62% 的降低！

(圖表：不同 MFU 下的 TCO / 有效訓練 Dense FP8 PFLOP ($/hr per Eff PFLOP))

然而，當觀察 60 萬個租賃的 TPU 時，當我們將 Anthropic 支付的較高 TCO（即包括谷歌的利潤疊加）納入此分析時，我們估計 Anthropic 從 GCP 獲得的成本為每 TPU 小時 1.60 美元，縮小了 TCO 優勢。我們相信 Anthropic 可以在 TPU 上實現 40% 的 MFU，這歸功於他們對性能優化的關注以及 TPU 營銷的 FLOPs 本質上更現實。這為 Anthropic 提供了比 GB300 NVL72 低驚人的約 52% 的每有效 PFLOP TCO。與 GB300 基準相比，每有效 FLOP TCO 相同的平衡點在於 Anthropic 提取的 MFU 低至 19%。這意味着 Anthropic 可以承受相對於基準 GB300 相當大的性能短缺，而訓練 FLOPs 的性能/TCO 最終仍與基準 Nvidia 系統相同。

(圖表：不同 MFU 下的 TCO / 有效訓練 Dense FP8 PFLOP)

FLOPs 並不是性能的全部，內存帶寬對於推理非常重要，特別是在帶寬密集的解碼步驟中。毫不奇怪，TPU 的每內存帶寬美元成本也比 GB300 便宜得多。有重要證據表明，在小消息大小（如 16MB 到 64MB，加載單層的專家）下，TPU 甚至實現了比 GPU 更高的內存帶寬利用率。

(圖表：TCO / 內存帶寬 ($/hr per TB/s))

所有這些都轉化為訓練和服務模型的高效計算。Anthropic 發佈的 Opus 4.5 繼續其一貫的編碼重點，創下了新的 SWE-Bench 記錄。主要的驚喜是 API 價格降低了約 67%。這種降價加上模型比 Sonnet 更低的冗余度和更高的代幣效率（達到 Sonnet 最佳分數所需的代幣減少 76%，超過其 4 分所需的代幣減少 45%），意味着 Opus 4.5 是編碼用例的最佳模型，並且可以有效地提高 Anthropic 的實際token定價，因為 Sonnet 目前佔代幣組合的 90% 以上。

(圖表：Anthropic API 定價)

(圖表：SWE-Bench 分數 vs 所需總輸出Tokens)

谷歌在利潤率上穿針引線

在為外部客户定價時，谷歌需要「穿針引線」，以平衡自身的盈利能力，同時為客户提供有競爭力的主張。我們對 Anthropic 定價的估計處於我們聽到的外部定價範圍的低端。對於像 Anthropic 這樣的旗艦客户，他們將為軟件和硬件路線圖提供寶貴的輸入，同時訂購大量產品，我們預計會有優惠定價（sweetheart pricing）。雖然 Nvidia 令人瞠目結舌的 4 倍加價（約 75% 的毛利率）提供了很大的定價靈活性，但 Broadcom 吸走了大量的氧氣。Broadcom 作為 TPU 的聯合設計者，在芯片上賺取高額利潤，這是系統 BOM（物料清單）的最大組成部分。儘管如此，這仍為谷歌留下了很大的空間來賺取非常可觀的利潤。

我們可以通過將 GCP Anthropic 交易與其他大型基於 GPU 的雲交易進行比較來看出這一點。請注意，這是針對正在租賃的 60 萬個 TPU，其余 40 萬個 TPU v7 芯片由 Anthropic 預付購買。

在這些假設下，TPU v7 的經濟效益顯示出比我們觀察到的其他大型基於 GPU 的雲交易更優越的息税前利潤率（EBIT margins），只有 OCI-OpenAI 接近。即使有 Broadcom 在芯片級 BOM 上的利潤疊加，谷歌仍然可以獲得比更加商品化的 GPU 交易優越得多的利潤和回報。這就是 TPU 堆棧允許 GCP 成為真正差異化的 CSP（雲服務提供商）的地方。與此同時，像 Microsoft Azure 這樣的人，其 ASIC 計劃正在掙扎，僅限於在僅僅租賃商業硬件的業務中賺取更多平庸的回報。

(表格：主要 AI 雲合同對比)

TPU 系統和網絡架構

到目前為止，我們已經討論了 TPU 與 Nvidia GPU 在單芯片規格和不足之處的比較。現在，讓我們回到系統討論，這是 TPU 能力真正開始分化的地方。TPU 最顯著的特徵之一是通過 ICI 協議實現的極大**縱向擴展（Scale-up）**世界規模（World Size）。TPU pod 的世界規模達到 9216 個 Ironwood TPU，大 pod 尺寸早在 2017 年的 TPUv2 就已成為特徵，擴展到完整的 256 個 1024 芯片集羣大小。讓我們從機架級別開始，這是每個 TPU 超級 pod 的基本構建塊。

Ironwood 機架架構

(圖片：機架子系統)

TPU 機架在過去幾代中採用了類似的設計。每個機架由 16 個 TPU 托盤、16 或 8 個主機 CPU 托盤（取決於冷卻配置）、一個 ToR 交換機、電源單元和 BBU 組成。

(圖表：TPU v7 Ironwood 機架)

每個 TPU 托盤由 1 個 TPU 板組成，上面安裝了 4 個 TPU 芯片封裝。每個 Ironwood TPU 將有 4 個 OSFP 籠用於 ICI 連接，以及 1 個 CDFP PCIe 籠用於連接主機 CPU。

谷歌自 2018 年 TPU v3 以來一直實施液冷 TPU 機架，但中間仍有一些 TPU 代次設計為風冷。液冷和風冷機架的主要區別在於，風冷機架的 TPU 托盤與主機 CPU 托盤的比例為 2 比 1，而液冷機架的比例為 1 比 1。

TPU 液冷的一個創新設計是冷卻劑的流速由閥門主動控制。這使得冷卻更加高效，因為流量可以根據每個芯片在任何給定時間的工作負載量進行調整。谷歌的 TPU 長期以來也採用垂直供電，其中 TPU 的 VRM 模塊位於 PCB 板的另一側。這些 VRM 模塊也需要冷板進行冷卻。

總體而言，TPU 機架設計比 Nvidia Oberon NVL72 設計簡單得多，后者密度更高，並利用背板連接 GPU 以擴展交換機。TPU 托盤之間的擴展連接全部通過外部銅纜或光學器件進行，這將在下面的 ICI 部分解釋。TPU 托盤和 CPU 托盤之間的連接也是通過 PCIe DAC 電纜進行的。

芯片間互連 (ICI) – 擴展 Scale-Up 世界規模的關鍵

谷歌 TPUv7 的 ICI 擴展網絡的構建塊是一個由 64 個 TPU 組成的 4x4x43D 環面（3D Torus）。每個 64 個 TPU 的 4x4x4 立方體映射到一個 64 TPU 的物理機架。這是一個理想的尺寸，因為所有 64 個 TPU 都可以相互電氣連接，並且仍然適合在一個物理機架中。

(圖表：TPU v7 - 64 TPU 4x4x4 立方體邏輯配置)

TPU 以 3D 環面配置相互連接，每個 TPU 連接總共 6 個鄰居——X、Y 和 Z 軸各 2 個邏輯上相鄰的 TPU。每個 TPU 始終通過計算托盤內的 PCB 走線連接到 2 個其他 TPU，但根據 TPU 在 4x4x4 立方體內的位置，它將通過直接連接銅纜 (DAC) 或光收發器連接到 4 個其他鄰居。

4x4x4 立方體內部的連接通過銅纜進行，而 4x4x4 立方體外部的連接（包括環繞回到立方體另一側的連接以及與相鄰 4x4x4 立方體的連接）將使用光收發器和OCS（光路交換機）。在下圖中，我們看到這是一個 3D 環面網絡：TPU 2,3,4（在 Z+ 面上）使用 800G 光收發器並通過 OCS 路由，具有環繞連接回到對面的 Z 軸面 TPU 2,3,1（在 Z- 面上）。

(圖表：TPU 單元連接)

如上所述，除了始終通過 PCB 走線連接的 2 個相鄰 TPU 外，TPU 還將使用 DAC、收發器或兩者的混合連接到 4 個其他鄰居，具體取決於它們在 4x4x4 立方體中的位置。

4x4x4 立方體內部的 TPU 將僅使用 DAC 連接到 4 個其他鄰居，立方體面上的 TPU 將通過 3 個 DAC 和 1 個光收發器連接，立方體邊緣的 TPU 將通過 2 個光收發器和 2 個 DAC 連接，而角落的 TPU 將通過 1 個 DAC 和 3 個光收發器連接。你可以通過查看給定 TPU 有多少個面朝向立方體的「外部」來記住它將使用多少個收發器。

(圖表：4x4x4 立方體內的 TPU 位置)

上圖以及下表總結了 TPU 的各個位置類型的數量，可用於推導出 TPU v7 每個 TPU 1.5 個光收發器的配比。這些收發器連接到光路交換機 (OCS)，從而實現 4x4x4 立方體之間的連接——下一節將詳細介紹。

(表格：谷歌 TPU v7 3D 環面連接配比)

用於 ICI 的光學器件

谷歌採用軟件定義網絡方法來管理通過光路交換機 (OCS) 的網絡路由。NxN OCS 基本上是一個擁有 N 條進軌道和 N 條出軌道的巨大火車站。任何進來的火車都可以轉移到任何出去的火車，但這必須在車站重新配置。火車不能「環回」或送回另一條 N 進軌道，它們必須僅路由到 N 條出軌道之一。

這種方法的好處是，網絡可以組裝較小的邏輯 TPU 切片（slices）——針對不同的工作負載，從 ICI 網絡層中 9,216 個芯片的理論最大值中切分。通過切分更大的集羣，圍繞網絡中的故障重新路由 ICI 路徑，集羣可用性得到提高。

與電子數據包交換 (EPS) 交換機（如 Arista Tomahawk 5，其中固定的總帶寬進一步拆分為幾個較小帶寬的端口）不同，OCS 允許任何帶寬的光纖連接到其端口。OCS 的延迟也比 EPS 低，因為進入 OCS 的光信號只是從輸入端口反彈到輸出端口。對於 EPS，光信號在進入交換機時必須轉換為電信號——這是 OCS 通常比 EPS 更節能的一個關鍵原因。EPS 還允許將數據包從任何端口路由到任何端口，而 OCS 僅允許你將「輸入」端口路由到任何其他「輸出」端口。

(圖片：OCS 內部結構)

OCS 端口僅路由單根光纖束。這對於標準雙工收發器來説是一個挑戰，因為帶寬是通過多根光纖束傳輸的，這降低了 OCS 的有效基數（radix）和帶寬。爲了解決這個問題，使用 FR 光收發器將所有波長整合到一根光纖束上以連接到 1 個 OCS 端口。Apollo 項目通過兩個步驟創新地實現了這一點。首先，8 個波長——每個 100G 通道 1 個波長——通過粗波分複用 (CWDM8) 複用，通過單對光纖傳輸 800G，而不是 8 對光纖。其次，**光環形器（optical circulator）**集成在波分複用 (WDM) 收發器上以實現全雙工數據流，將需求從 1 對光纖減少到僅 1 根光纖束。

(圖片：環形器原理)

環形器通過將收發器處的 Tx 和 Rx 光纖束組合成發送到 OCS 交換機的單根光纖束，形成雙向鏈路。

連接多個 64 TPU 立方體

谷歌的 ICI 擴展網絡獨特之處在於，它允許將多個 64 TPU 4x4x4 立方體以 3D 環面配置連接在一起，以創建巨大的世界規模。TPUv7 具有 9,216 個 TPU 的最大世界規模，但今天，谷歌支持將 TPU 配置為多個不同的切片大小，從 4 個 TPU 一直到 2,048 個 TPU。

(表格：支持的配置)

雖然谷歌可以創新地實現令人印象深刻的 9,216 個 TPU 的擴展集羣，但在任何時間點在高達約 8,000 個 TPU 的增量較大塊大小上運行訓練工作負載的好處會減少。這是因為較大的塊大小更容易發生故障和中斷，從而降低切片可用性，切片可用性定義為 ICI 集羣能夠形成連續 3D 環面切片的時間比例。

(圖表：有效吞吐量 (Goodput) vs CPU 主機可用性 有/無 OCS)

對於可以完全容納在 4x4x4 立方體內的切片，我們可以簡單地使用機架內的銅互連以及立方體面/邊緣/角落上的光收發器來切出這些切片，以便在需要時環繞並完成 3D 環面。

爲了瞭解環繞和立方體間連接是如何進行的，讓我們看看我們如何在 4x4x4 拓撲中創建一個 64 TPU 切片。我們可以使用對應於一個物理 64 TPU 機架的 64 TPU 單位 4x4x4 立方體來構建此拓撲。4x4x4 立方體內部的所有 8 個 TPU 都可以使用銅纜完全連接到所有 6 個鄰居。如果 TPU 在給定軸上沒有內部鄰居，它將環繞並連接到立方體另一側的 TPU。例如，TPU 4,1,4 在 Z+ 方向上沒有內部鄰居，因此它將使用一個 800G 光收發器連接到分配給 Z 軸的 OCS，並將 OCS 配置為將此連接引導到立方體的 Z- 側，連接到 TPU 4,1,1。在 Y- 方向上，TPU 1,1,1 將使用光收發器連接到 Y 軸 OCS 以鏈接到 TPU 1,4,1 的 Y+ 側，依此類推。

(圖表：TPU v7 - 64 TPU 切片 4x4x4 拓撲)

4x4x4 立方體的每個面將通過 16 個不同的 OCS 連接——每個面上的每個 TPU 一個 OCS。

例如，在下圖中，在 X+ 面上，TPU 4,3,2 連接到 OCS X,3,2 的輸入側。OCS X,3,2 的輸入側也將連接到 9,216 TPU 集羣中所有 144 個 4x4x4 立方體的 X+ 面上的相同 TPU 索引 (4,3,2)。OCS X,3,2 的輸出側隨后將連接到集羣中每個立方體的相同 TPU 索引，只是這次是在 X- 面上——因此它將連接到集羣所有 144 個立方體上的 TPU 1,3,2。下圖說明了立方體 A X+ 面上的所有 16 個 TPU 如何通過 16 個 OCS 連接到立方體 B X- 上的 16 個 TPU。

這些連接允許任何立方體的任何「+」面連接到任何其他立方體的「-」面，從而在形成切片時實現立方體的完全可替代性。

有兩個限制需要簡要指出。首先，給定面上一個索引的 TPU 永遠不能直接連接到不同的索引——因此 TPU 4,3,2 永遠無法配置為連接到 TPU 1,2,3。其次，由於 OCS 本質上充當配線架——連接在輸入側的 TPU 不能「環回」連接到也連接在 OCS 輸入側的任何其他 TPU——例如，TPU 4,3,2 永遠無法連接到 TPU 4,3,3。因此——任何「+」面上的 TPU 永遠無法連接到任何其他立方體的「+」面，任何「-」面上的 TPU 永遠無法連接到任何其他立方體的「-」面。

(圖表：TPU v7 連接到 OCS)

讓我們做大一點，看看如何設置 4x4x8 拓撲。在此配置中，我們通過沿 Z 軸連接兩個 64 TPU 4x4x4 立方體來擴展切片。在這種情況下，OCS 將重新配置 TPU 4,1,4 連接的光端口，使其現在連接到 TPU 4,1,5，而不是像獨立 4x4x4 拓撲那樣環繞回 TPU 4,1,1。以此類推，我們將有 16 個光連接從兩個 4x4x4 TPU 立方體的 Z- 和 Z+ 面延伸，總共 64 根光纖束連接到 16 個 Z 軸 OCS。

重要的是要提醒讀者，下面描繪的立方體 A 和立方體 B 不一定物理上位於彼此旁邊。相反，它們通過 OCS 連接，它們可能各自位於數據中心完全不同的位置。

(圖表：TPU v7 - 128 TPU 切片 4x4x8 拓撲)

我們現在將移動到一個更大的拓撲——16x16x16 拓撲，這將我們帶到 4,096 個 TPU。在這個拓撲中，我們總共使用 48 個 OCS 來連接 64 個各含 64 TPU 的立方體。在下圖中，每個多色立方體代表一個 64 TPU 4x4x4 立方體。以右下角的 4x4x4 立方體為例——這個立方體通過 OCS 連接到沿 Y 軸的相鄰立方體。

9,216 個 TPU 的最大世界規模是使用 144 個 4x4x4 立方體構建的，每個立方體需要 96 個光連接，總需求為 13,824 個端口。將此總端口需求除以 288（每個 OCS 144 個輸入和 144 個輸出端口）意味着我們需要 48 個 144x144 OCS 來支持這個最大世界規模。

(圖表：TPU v7 4,096 TPU 切片 16x16x16 拓撲)

為什麼要使用谷歌的 ICI 3D 環面架構？

除了可以花費無數小時繪製所有花哨的立方體圖之外，谷歌獨特的 ICI 擴展網絡有什麼好處？

世界規模：最明顯的好處是 TPUv7 Ironwood 支持的非常大的 9,216 TPU 最大世界規模。即使由於**有效吞吐量（goodput）**降低的缺點，9,216 的最大切片大小可能很少使用，但數千個 TPU 的切片可以並且經常被使用。這遠大於商業加速器市場和其他定製芯片提供商常見的 64 或 72 GPU 世界規模。

可重構性和可替代性：OCS 的使用意味着網絡拓撲本質上支持網絡連接的重新配置，以支持大量不同的拓撲——理論上有數千種拓撲。谷歌的文檔網站列出了 10 種不同的組合（本節前面的圖片），但這只是最常見的 3D 切片形狀——還有更多可用的形狀。

即使是相同大小的切片也可以進行不同的重新配置。在下面圖示的扭曲 2D 環面（Twisted 2D Torus）的簡單示例中，我們看到如何跨越到不同 X 座標的索引而不是相同 X 座標的索引，可以減少最壞情況下的跳數和最壞情況下的對分帶寬（bisection bandwidth）。這有助於提高所有對所有的集體吞吐量。TPUv7 集羣將在 4x4x4 立方體級別扭曲。

(圖表：常規 vs 扭曲 2D 環面)

可重構性也為廣泛的多樣化並行性打開了大門。在 64 或 72 GPU 世界規模中，不同的並行性組合通常限於 64 的因子。當涉及到 ICI 擴展網絡時，實施拓撲以精確匹配所需的數據並行、張量並行和管道並行組合的可能性是豐富的。

OCS 允許人們將任何立方體的任何「+」面連接到任何其他立方體的「-」面的事實意味着立方體具有完全的可替代性。切片可以由任何一組立方體組成。因此，如果有任何故障或用户需求或使用情況的變化，這不會阻礙新拓撲切片的形成。

(圖表：TPUv4 電路交換可重構性)

更低的成本：谷歌的 ICI 網絡成本低於大多數交換式擴展網絡。雖然由於使用環形器，所使用的 FR 光學器件可能稍貴，但網狀網絡減少了所需的交換機和端口的總數，並消除了交換機之間連接產生的成本。

(表格：擴展網絡成本比較)

低延迟和更好的局部性：TPU 之間直接鏈路的使用意味着對於物理位置彼此靠近或重新配置為直接相互連接的 TPU，可以實現低得多的延迟。彼此靠近的 TPU 也具有更好的數據局部性。

數據中心網絡 (DCN) – 擴展超過 9,216 個 TPU

數據中心網絡 (DCN) 是獨立於 ICI 的網絡，充當典型后端和前端網絡的角色。它連接甚至更大的域——在 TPUv7 集羣的情況下為 14.7 萬個 TPU。

正如我們在之前關於 Apollo 任務的文章中所討論的，谷歌提議用 Paloma 光路交換機 (OCS) 取代傳統「Clos」架構中包含電子數據包交換 (EPS) 的脊層（spine layer），谷歌的 DCN 由光學交換的數據中心網絡互連 (DCNI) 層組成，該層結合了幾個聚合塊，每個聚合塊連接幾個 9,216 TPU ICI 集羣。

2022 年，谷歌的 Apollo 項目提出了一個 DCN 架構，描述了為 TPUv4 pod 使用 136x136 OCS 交換機，pod 大小為 4,096 個 TPU。DCNI 層的 OCS 交換機被組織成 4 個 Apollo 區域，每個區域包含最多 8 個機架的 8 個 OCS 交換機，總共 256 個 OCS 交換機。當涉及到 Ironwood 時，爲了在同一網絡上支持多達 147 個 TPUv7，我們假設 OCS 上的端口數量將幾乎翻倍，而不是增加 OCS 交換機的最大數量。

下圖說明了使用 32 個機架容納 256 個 300x300 OCS 交換機的 Ironwood DCN 網絡可能是什麼樣子。假設每個聚合塊的脊層之間沒有超額訂閲，DCN 中最多可以連接 16 個 ICI pod，其中 4 個聚合塊各連接 4 個 ICI pod——總共 147,456 個 TPU。

DCNI 層連接 4 個聚合塊——在下圖中描繪為頂層。與 ICI 一樣，FR 光學器件用於連接到 OCS 以最大化每個 OCS 端口的帶寬。

(圖表：147,456 DCN 拓撲)

雖然現有的 Ironwood 集羣可能只有 1 或 2 個聚合塊，但谷歌 DCN 的獨特架構允許在無需大量重新佈線的情況下將新的 TPU 聚合塊添加到網絡中。

通過將 OCS 用於 DCNI 層，DCN 結構的大小可以增量擴展，並且可以**重新條帶化（re-striped）**網絡以支持新的聚合塊。此外，聚合塊的帶寬可以升級，而無需更改 DCN 層的構成。這允許現有聚合塊的鏈路速度得到刷新，而無需改變網絡本身的基本架構。結構擴展的過程不能無限期地進行下去——在巨大的規模下，重新佈線網絡變得難以管理。

(圖表：使用 OCS 鏈路的 AB 擴展)

TPU 軟件戰略 – 另一個巨大的轉變

傳統上，TPU 軟件和硬件團隊一直是面向內部的。這帶來了優勢，例如沒有營銷團隊施加壓力來誇大陳述的理論 FLOPs。

只面向內部的另一個優勢是 TPU 團隊極大地優先考慮內部功能請求和優化內部工作負載。缺點是他們不太關心外部客户或工作負載。TPU 生態系統中的外部開發人員數量遠低於 CUDA 生態系統。這是 TPU 的主要弱點之一，所有非 Nvidia 加速器也是如此。

谷歌此后修改了針對面向外部客户的軟件戰略，並已經對 TPU 團隊的 KPI 以及他們如何為 AI/ML 生態系統做出貢獻做出了重大改變。我們將討論 2 個主要變化：

通過查看谷歌對各種 TPU 軟件倉庫的貢獻數量，可以清楚地看到這種外部化戰略。我們可以看到從 3 月開始 vLLM 貢獻顯着增加。然后從 5 月開始，創建了「tpu-inference」倉庫，這是官方的 vLLM TPU 統一后端，從那時起就有一系列活動。

(圖表：谷歌按倉庫每月的貢獻)

傳統上，谷歌僅對 Jax/XLA:TPU 堆棧（以及 TensorFlow/TF-Mesh，安息吧）提供一等支持，但將 TPU 上的 PyTorch 視為二等公民。它依賴於通過 PyTorch/XLA 進行的惰性張量圖捕獲（lazy tensor graph capture），而不是擁有一流的急切執行（eager execution）模式。此外，它不支持 PyTorch 原生分佈式 API (torch.distributed.*) 或支持 PyTorch 原生並行 API (DTensor, FSDP2, DDP 等)，而是依賴於奇怪的樹外 XLA SPMD API (torch_xla.experimental.spmd_fsdp, torch_xla.distributed.spmd 等)。這導致了對於習慣於 GPU 上的原生 PyTorch CUDA 后端並試圖切換到 TPU 的外部用户來説，非原生體驗不佳。

(代碼示例：XLA)

10 月，谷歌的「Captain Awesome」 Robert Hundt 在 XLA 倉庫中悄悄宣佈，他們將從非原生惰性張量后端轉向「原生」TPU PyTorch 后端，該后端將默認支持急切執行，並與 torch.compile、DTensor 和 torch.distributed API 等集成。他們將通過使用 PrivateUse1 TorchDispatch 鍵來做到這一點。這主要是爲了 Meta 做的，Meta 對購買 TPU 重新產生了興趣，並且不想轉移到 JAX。這也將使喜歡 PyTorch 而不喜歡 JAX 的人也可以使用 TPU。

此前從 2020 年到 2023 年，Meta FAIR 的幾個團隊大量在 TPU 上使用 PyTorch XLA，但並未被廣泛採用，因此 Meta 領導層最終在 2023 年取消了合同。TPU 上的 PyTorch XLA 不是一種有趣的體驗。當時的 Meta FAIR GCP TPU 甚至使用 SLURM 運行，而不是你在 TPU 堆棧上通常會找到的任何東西，如 GKE/Xmanager/borg 等。

(圖片：GitHub RFC)

這種新的 PyTorch <> TPU 將為習慣於 GPU 上 PyTorch 的 ML 科學家創造一個更平滑的過渡，以切換到 TPU 上的 PyTorch 並利用 TPU 上更高的每 TCO 性能。

Pallas 是用於為 TPU 編寫自定義內核的內核創作語言（類似於 cuTile 或 Triton 或 CuTe-DSL）。Meta 和谷歌也已開始致力於支持 Pallas 內核作為 Torch Dynamo/Inductor 編譯堆棧的代碼生成目標。這將允許與 PyTorch 的原生 torch.compile API 進行原生 TPU 集成，並允許最終用户將自定義 pallas 操作註冊到 PyTorch 中。

除了核心的樹內 PyTorch 原生 API 外，幕后還有關於將 TPU pallas 內核語言集成為 Helion 的代碼生成目標的工作。你可以將 Helion 視為一種用於用高級語言編寫性能尚可的內核的高級語言。用户可以將 Helion 視為低級 Aten 算子，而不是高級 Triton/Pallas，因為它與原生 PyTorch Aten 算子的相似性更接近。

CUDA 生態系統至高無上的另一個領域是開放生態系統推理。歷史上，vLLM 和 SGLang 支持 CUDA 作為一等公民（ROCm 作為二等公民）。現在谷歌想要進入 vLLM 和 SGlang 開放推理生態系統，並宣佈通過非常「獨特」的集成對 vLLM 和 SGLang 提供 beta 版 TPU v5p/v6e 支持。

vLLM 和 SGLang 目前通過將 PyTorch 建模代碼**下譯（lowering）**到 JAX 並利用現有的成熟 JAX TPU 編譯流程來做到這一點。未來一旦 PyTorch XLA RFC #9684（即原生 TPU PyTorch 后端）實施，vLLM 和 SGLang 計劃評估是否切換到使用該后端，而不是通過 TorchAX 將建模從 PyTorch 翻譯到 JAX。

谷歌和 vLLM 聲稱這種下譯到 jax 的路徑不需要對 PyTorch 建模代碼進行任何更改，但鑑於 vLLM TPU 目前支持的模型很少，我們對此表示懷疑。

此外，谷歌已經開源並將他們的一些 TPU 內核集成到 vLLM 中，例如 TPU 優化的分頁注意力內核、計算-通信重疊 GEMM 內核以及其他幾個量化 matmul 內核。他們還沒有 MLA 友好的 TPU 內核。一旦 Inductor Pallas TPU 代碼生成集成更加成熟，看看是否可以將內核融合和模式匹配集成到現有的 vLLM PassManager 中將會很有趣。SGLang 也在考慮實施 torch.compile PassManager，以使許多模型的內核融合管理更易於維護。

對於參差分頁注意力（Ragged Paged Attention）v3，TPU 的處理方式與 vLLM GPU 截然不同。vLLM 使用類似於虛擬內存和分頁的技術管理 KV 緩存。然而，這種技術需要獲取動態地址並執行**分散（scatter）**操作，這是 TPU 不擅長的。因此，TPU 內核利用細粒度的操作流水線。具體來説，TPU 的分頁注意力內核預取下一個序列的查詢和 KV 塊，因此內存加載與計算重疊。

在現有的 vLLM MoE 內核中，我們按專家 ID 對代幣進行排序，將代幣分發到具有相應專家的設備，執行組矩陣乘法，並將來自專家的代幣組合回原始設備。然而，該內核表現不佳有兩個原因：TPU 在執行排序操作方面很慢，並且內核無法將通信與計算重疊。

爲了解決這個問題，谷歌開發人員設計了全融合 MoE（All-fused MoE）。全融合 MoE 一次為每個設備分發一個專家的代幣，同時重疊 MoE 分發和 MoE 組合通信，並避免按專家 ID 對代幣進行排序。使用全融合 MoE，谷歌工程師報告比現有內核有 3-4 倍的加速。

(圖表：時間步長示意圖)

此外，TPU 中的另一個硬件單元是 SparseCore (SC)，用於加速嵌入查找和更新。SC 配備標量於核 SparseCore Sequencer (SCS) 和多個矢量子核 SparseCore Tiles (SCT)。SCT 支持以更細粒度的 4 字節或 32 字節粒度進行本地和遠程直接內存訪問，相比之下 TPU TensorCore 為 512 字節加載。這使得 SC 能夠執行**收集/分散（gather/scatter）**操作和 ICI 通信，同時與 TensorCore 操作重疊。

在 JAX DevLabs，我們瞭解到 SparseCore 的可編程性正在進行中。我們可以期待 Mosaic（TPU 自定義內核編譯器）以 MPMD 方式編譯，其中 SCS 和 SCT 執行不同的內核，不同的 SparseCore 可以運行不同的程序。我們懷疑一旦可編程性趕上，TPU MoE 內核將能夠以類似於 GPU 的方式執行分發和組合操作，而不是按專家 ID 分發。

(圖表：SparseCore 結構)

在**分離式預填充解碼（disaggregated prefill decode）**方面，我們在 AMD 2.0 文章中深入描述了這一點，谷歌在 vLLM 上對單主機分離 PD 提供了實驗性支持，注意他們尚不支持多主機 wideEP 分離預填充或 MTP。這些推理優化對於降低每百萬代幣的 TCO 以及提高每美元性能和每瓦性能至關重要。此外，他們尚未將 TPU vLLM 推理支持集成到流行的 RL 框架（如 VERL 等）中。谷歌在如何接近開放 AI/ML 生態系統方面正慢慢朝着正確的方向前進，特別是對於他們的「原生」TPU 后端。

vLLM TPU 基準測試尚不相關

本周，TPUv6e 上發佈了一個新的推理基準測試，聲稱 TPUv6e 的每美元性能比 NVIDIA GPU 差 5 倍。我們不同意，主要有兩個原因。首先，這個基準測試是在 TPU 上的 vLLM 上進行的，該版本僅發佈了幾個月，因此尚未具有優化的性能。谷歌內部的 Gemini 工作負載和 Anthropic 工作負載運行在內部自定義推理堆棧上，其每 TCO 性能優於 NVIDIA GPU。

其次，Artificial Analysis 的每百萬代幣成本使用的是 TPUv6e 的標價 2.7 美元/小時/芯片。鑑於 BOM 只是 H100 的一小部分，沒有 TPU 的主要客户會為 TPUv6e 支付接近那麼高的價格。衆所周知，大多數雲都有一個虛高的標價，以便他們的客户銷售主管可以採用**「汽車推銷員」式的戰術（高標價、大折扣）**，讓客户認為他們得到了一筆好交易。SemiAnalysis AI TCO 模型跟蹤所有各種合同長度（1 個月、1 年、3 年等）的 TPU 實際市場租賃價格。

(圖表：每百萬輸入和輸出代幣的成本)

TPU 軟件戰略的關鍵缺失部分

谷歌在軟件戰略上仍然處理不當的一個部分是，他們的 XLA 圖編譯器和網絡庫以及 TPU 運行時仍然沒有開源，也沒有很好的文檔記錄。這導致了從高級用户到普通用户的各種用户感到沮喪，無法調試代碼出了什麼問題。此外，他們用於多 pod 訓練的 MegaScale 代碼庫也不是開源的。

我們堅信，爲了加速採用，谷歌應該將其開源，用户採用的增加將超過他們將公開和免費的所有軟件 IP。就像 PyTorch 或 Linux 開源迅速增加了採用率一樣，開源 XLA:TPU 和 TPU 運行時及網絡庫也將迅速加速這一點。