對於輝達來說，那個曾經最大的客戶，現在變成了最懂的對手。當OpenAI可以用“威脅購買TPU”來換取30%的折扣，當Anthropic可以用TPU訓練出超越GPT-4的模型，當Google願意開放軟體生態並提供金融槓桿時，輝達高達75%的毛利率神話便不再牢不可破。2025年的AI晶片市場，正處於一個微妙的轉折點。一方面，輝達依然憑藉Blackwell維持著技術和市場份額的絕對領先；但另一方面，GoogleTPU的全面商業化，讓輝達看似牢不可破的定價權，正在發生鬆動。據半導體行業研究機構SemiAnalysis測算，OpenAI僅憑“威脅購買TPU”這一籌碼，就迫使輝達生態鏈做出了實質性讓步，使其計算叢集的總擁有成本（TCO）下降了約30%。隨著Anthropic高達1GW的TPU採購細節曝光，Google正式撕下了“雲服務商”的面具，轉型為一家直接向外部出售高性能晶片與系統的“商用晶片供應商”。當OpenAI可以用“威脅購買TPU”來換取30%的折扣，當Anthropic可以用TPU訓練出超越GPT-4的模型，當Google願意開放軟體生態並提供金融槓桿時，輝達高達75%的毛利率神話便不再牢不可破。對於輝達來說，那個曾經最大的客戶，現在變成了最懂的對手。(圖表：每百萬輸入和輸出代幣的成本)01Google“主動出擊”長期以來，Google的TPU就像其搜尋演算法一樣，是深藏不露的內部核武器。但SemiAnalysis獲取的供應鏈情報顯示，這一策略已發生根本性逆轉。最直接的案例來自Anthropic。作為能在前沿模型上媲美OpenAI抗衡的大模型公司，Anthropic已確認將部署超過100萬顆TPU。這筆交易的結構極具破壞力，它揭示了Google“混合銷售”的新模式：在這100萬顆晶片中，首批約40萬顆最新的TPUv7 "Ironwood"將不再通過雲租賃，而是由博通直接出售給Anthropic，價值約100億美元。博通作為TPU的長期聯合設計方，在此次交易中從幕後走向台前，成為了這場算力轉移的隱形贏家。而剩餘的60萬顆TPUv7，則通過Google雲進行租賃。據估算，這部分交易涉及高達420億美元的剩餘履約義務（RPO），直接支撐了Google雲近期積壓訂單的暴漲。這一動作的訊號極為明確：Google不再吝嗇於將最先進的算力外售。除了Anthropic，Meta、SSI、xAI等頂級AI實驗室也出現在了潛在客戶名單中。面對這一突如其來的攻勢，輝達罕見地展現出防禦姿態，其財務團隊近期不得不針對“循環經濟”（即投資初創公司購買自家晶片）的質疑發佈長文辯解。這種對市場情緒的敏感反應，恰恰說明Google的攻勢已經觸及了輝達的神經。02成本是硬道理客戶倒戈的理由很純粹：在AI軍備競賽中，性能是入場券，但TCO（總擁有成本）決定生死。SemiAnalysis的模型資料顯示，GoogleTPUv7在成本效率上對輝達構成了碾壓優勢。從Google內部視角看，TPUv7伺服器的TCO比輝達GB200伺服器低約44%。即便加上Google和博通的利潤，Anthropic通過GCP使用TPU的TCO，仍比購買GB200低約30%。這種成本優勢並非僅靠壓低晶片價格實現，而是源於Google獨特的金融工程創新——“超級雲廠商兜底”。在AI基礎設施建設中，存在一個巨大的期限錯配：GPU叢集的經濟壽命僅為4-5年，而資料中心場地的租賃合約通常長達15年以上。這種錯配讓Fluidstack、TeraWulf等新興算力服務商難以獲得融資。Google通過一種“資產負債表外”的信貸支援（IOU）解決了這一難題：Google承諾，如果中間商無法支付租金，Google將介入兜底。這一金融工具直接打通了加密貨幣礦工（擁有電力和場地）與AI算力需求之間的堵點，建構了一個獨立於輝達體系之外的低成本基礎設施生態。03不僅是晶片，還有系統如果說價格戰是戰術層面的對壘，那麼系統工程則是Google戰略層面的護城河。之前，業界素有“系統重於微架構”的觀點。如今，這一論斷在TPUv7上得到了驗證。雖然單顆TPUv7在理論峰值算力（FLOPs）上略遜於輝達的Blackwell，但Google通過極致的系統設計抹平了差距。現在，TPUv7 "Ironwood"在記憶體頻寬和容量上已大幅縮小與輝達旗艦晶片的差距。更重要的是，它採用了更務實的設計哲學——不追求不可持續的峰值頻率，而是通過更高的模型算力利用率（MFU）來提升實際產出。而Google真正的殺手鐧，是其獨步天下的光互連（ICI）技術。不同於輝達依賴昂貴的NVLink和InfiniBand/Ethernet交換機，Google利用自研的光路交換機（OCS）和3D Torus拓撲結構，建構了名為ICI的片間互連網路。這一架構允許單個TPUv7叢集（Pod）擴展至驚人的9,216顆晶片，遠超輝達常見的64或72卡叢集。OCS允許通過軟體定義網路，動態重構拓撲結構。這意味著如果某部分晶片故障，網路可以毫秒級繞過故障點，重新“切片”成完整的3D環面，極大地提升了叢集的可用性。且光訊號在OCS中無需進行光電轉換，直接物理反射，大幅降低了功耗和延遲。Gemini 3和Claude 4.5 Opus這兩大全球最強模型均完全在TPU上完成預訓練，這本身就是對TPU系統處理“前沿模型預訓練”這一最高難度任務能力的終極背書。04拆除最後的圍牆：軟體生態的改變長期以來，阻礙外部客戶採用TPU的最大障礙是軟體——Google固守JAX語言，而全球AI開發者都在使用PyTorch和CUDA。但在巨大的商業利益面前，Google終於放下了傲慢。SemiAnalysis報告指出，Google軟體團隊的KPI已發生重大調整，從“服務內部”轉向“擁抱開源”。此前，Google“超級隊長” Robert Hundt已明確宣佈，將全力支援PyTorch Native在TPU上的運行。Google不再依賴低效的Lazy Tensor轉換，而是通過XLA編譯器直接對接PyTorch的Eager Execution模式。這意味著Meta等習慣使用PyTorch的客戶，可以幾乎無縫地將程式碼遷移到TPU上。同時，Google開始向vLLM和SGLang等開源推理框架大量貢獻程式碼，打通了TPU在開源推理生態中的任督二脈。這一轉變意味著輝達最堅固的“CUDA護城河”，正在被Google用“相容性”填平。而這場“矽谷王座”的爭奪戰，才剛剛開始。全文翻譯以下是SemiAnalysis本次報告的全文翻譯部分（由AI翻譯）：TPUv7：Google向王者揮拳CUDA 護城河的終結？Anthropic 簽下 1GW+ TPU 採購大單；Meta/SSI/xAI/OAI/Anthro 購買的 TPU 越多，節省的 GPU 資本支出（Capex）就越多；下一代 TPUv8AX 和 TPUv8X 將正面對決 Vera Rubin。當今世界最頂尖的兩個模型——Anthropic 的 Claude 4.5 Opus 和Google的 Gemini 3，其絕大部分訓練和推理基礎設施都運行在Google的 TPU 和亞馬遜的 Trainium 上。如今，Google正打破常規，開始向多家企業直接出售物理 TPU 硬體。這是 Nvidia 統治終結的序章嗎？AI 時代的黎明已至，至關重要的是要理解，AI 驅動的軟體其成本結構與傳統軟體截然不同。晶片微架構和系統架構在這些創新型軟體的開發和擴展中扮演著決定性角色。與早期軟體時代開發人員成本佔比較高的情況相比，AI 軟體運行的硬體基礎設施對資本支出（Capex）和營運支出（Opex）——進而對毛利率——有著顯著更大的影響。因此，為了能夠部署 AI 軟體，投入大量精力最佳化 AI 基礎設施變得前所未有的關鍵。在基礎設施方面擁有優勢的公司，在部署和擴展 AI 應用的能力上也必將佔據高地。早在 2006 年，Google就曾兜售過建構 AI 專用基礎設施的理念，但這個問題在 2013 年達到了沸點。他們意識到，如果想要以任何規模部署 AI，就需要將現有的資料中心數量翻倍。因此，他們開始為 TPU 晶片奠定基礎，並於 2016 年投入生產。有趣的是，亞馬遜在同一年也意識到需要建構定製晶片。2013 年，亞馬遜啟動了 Nitro 項目，專注於開發晶片以最佳化通用 CPU 計算和儲存。兩家截然不同的公司針對不同的計算時代和軟體範式，最佳化了各自的基礎設施路徑。我們長期以來一直認為，TPU 是世界上用於 AI 訓練和推理的最佳系統之一，與“叢林之王” Nvidia 並駕齊驅。2.5 年前，我們寫過關於“TPU 霸權”的文章，這一論點已被時間證明是非常正確的。TPU 的成績不言自明：Gemini 3 是世界上最好的模型之一，且完全在 TPU 上訓練。在本報告中，我們將深入探討Google戰略的巨大轉變——即適當地將 TPU 商業化以供外部客戶使用，使其成為 Nvidia 最新且最具威脅的商用晶片（Merchant Silicon）挑戰者。本報告計畫：（重新）告訴我們的客戶和新讀者，讓他們瞭解外部 TPU 客戶的商業成功正在迅速增長，從 Anthropic 開始，延伸到 Meta、SSI、xAI 甚至潛在的 OpenAI……展示核心邏輯：你購買的 TPU 越多，你節省的 Nvidia GPU 資本支出就越多！OpenAI 甚至還沒有部署 TPU，就已經通過競爭威脅獲得了約 30% 的計算叢集折扣，從而提高了每 TCO（總擁有成本）的性能。解釋AI 基礎設施的“循環經濟”交易。重訪我們原本的 TPU 深度分析，從晶片到軟體層對 TPU 硬體堆疊進行全面更新。涵蓋開放軟體生態系統方面的積極進展，以及Google使 TPU 生態系統成為 CUDA 護城河的可行挑戰者所缺失的關鍵要素：開源他們的 XLA:TPU 編譯器、執行階段（runtime）和多 Pod“MegaScaler”程式碼。在付費牆內容中，我們將討論這對 Nvidia 護城河的影響，並將 Vera Rubin 與下一代 TPUv8AX/8X（又名 Sunfish/Zebrafish）進行比較。還將涵蓋對 Nvidia 的長期威脅。首先，讓我們談談這則新聞對生態系統的影響。TPU 的性能顯然引起了競爭對手的注意。Sam Altman 承認，由於 Gemini 搶了 OpenAI 的風頭，OpenAI 正面臨“倍感壓力（rough vibes）”的局面。Nvidia 甚至發佈了一份令人寬慰的公關稿，告訴大家保持冷靜並繼續前進——聲稱自己仍遙遙領先於競爭對手。我們理解其中的原因。過去幾個月對於 Google Deepmind、GCP（Google雲平台）和 TPU 綜合體來說是一個接一個的勝利。TPU 產量的大幅上調、Anthropic 超過 1GW 的 TPU 擴建、在 TPU 上訓練的 SOTA（最先進）模型 Gemini 3 和 Opus 4.5，以及現在正在擴大的目標客戶名單（Meta、SSI、xAI、OAI）排隊等待 TPU。這推動了Google和 TPU 供應鏈的巨大價值重估，而代價是 Nvidia GPU 供應鏈的損失。雖然Google和 TPU 供應鏈的“突然”崛起讓許多人感到驚訝，但 SemiAnalysis 的機構產品訂閱者在過去一年中早已預料到了這一點。(圖表：TPU、Trainium、Nvidia 風險敞口的基礎設施籃子對比)Nvidia 處於守勢的另一個原因是，越來越多的懷疑論者認為該公司正在通過資助燒錢的 AI 初創公司來支撐一種“循環經濟”，本質上是用額外的步驟將錢從一個口袋轉移到另一個口袋。我們認為這種觀點是有失偏頗的，但這顯然觸動了 Nvidia 內部的神經。財務團隊發佈了一份詳細的回應，轉載如下。循環融資是一種不可持續的商業行為指控：NVIDIA 參與了一個價值 610 億美元的循環融資計畫，即 NVIDIA 投資 AI 初創公司，初創公司承諾雲支出，雲服務商（CSPs）和初創公司購買 NVIDIA 硬體，NVIDIA 確認收入，但現金從未完成循環，因為基礎經濟活動——產生利潤的 AI 應用——仍然不足。回應：首先，NVIDIA 的戰略投資僅佔 NVIDIA 收入的一小部分，在全球私募資本市場每年籌集的約 1 兆美元中佔比更小。在第三季度和年初至今，NVIDIA 對私營公司的投資分別為 37 億美元和 47 億美元，分別佔收入的 7% 和 3%。NVIDIA 戰略投資組合中的公司主要從第三方融資提供商籌集資金，而不是從 NVIDIA。其次，NVIDIA 對戰略投資完全透明，這些投資在資產負債表中作為長期資產和有價證券報告，在損益表中作為其它收入和支出（OI&E）報告，在現金流量表中作為投資活動的現金流報告。第三，NVIDIA 戰略投資組合中的公司正在迅速增加自己的收入，表明其盈利之路和對 AI 應用的強勁潛在客戶需求。NVIDIA 戰略投資組合中的公司主要從第三方客戶產生收入，而不是從 NVIDIA。我們認為更現實的解釋是，Nvidia 旨在通過提供股權投資而不是降價來保護其在**基礎實驗室（Foundation Labs）**的主導地位，因為降價會降低毛利率並引起廣泛的投資者恐慌。下面，我們概述了 OpenAI 和 Anthropic 的安排，以展示前沿實驗室如何通過購買或威脅購買 TPU 來降低 GPU TCO。(表格：你買的 TPU 越多，你省下的 GPU 費用就越多)來源：SemiAnalysis TCO 模型，Anthropic 和 OpenAIOpenAI 甚至還沒有部署 TPU，他們就已經在整個實驗室範圍內的 NVIDIA 艦隊上節省了約 30%。這證明了 TPU 的每 TCO 性能優勢是如此強大，以至於你甚至在開啟一台 TPU 之前就已經獲得了採用 TPU 的收益。我們的加速器行業模型、資料中心行業模型和核心研究訂閱者在這一消息宣佈並成為市場共識之前很久就看到了行業影響。8 月初，我們與加速器模型客戶分享了我們看到供應鏈中 Broadcom / Google TPU 訂單在 2026 年的大規模上調。我們還透露，這些訂單增加的原因是Google將開始向多個客戶外部銷售系統。9 月初，我們透露其中一個大的外部客戶將是 Anthropic，需求至少為 100 萬個 TPU。這在 10 月份得到了 Anthropic 和Google的正式確認。我們還在 11 月 7 日指出 Meta 是一個大的 TPU 客戶，比其他人早了幾周。此外，我們也討論了其他客戶。結果，我們的機構客戶對 AI 交易中迄今為止最大的**性能分化（Performance Dispersion）**有了充分的預期。SemiAnalysis 是第一個披露所有這些見解的公司，因為沒有其他研究公司能夠將從晶圓廠到供應鏈，再通過資料中心到實驗室的點連接起來。言歸正傳。05Google的大規模TPU外部化推進與Anthropic交易TPU 堆疊長期以來一直與 Nvidia 的 AI 硬體相媲美，但它主要支援Google的內部工作負載。按照Google的一貫作風，即使在 2018 年向 GCP 客戶提供 TPU 後，它也從未將其完全商業化。這種情況正在開始改變。在過去的幾個月裡，Google動員了整個堆疊的力量，通過 GCP 將 TPU 帶給外部客戶，或者作為商業供應商銷售完整的 TPU 系統。這家搜尋巨頭正在利用其強大的內部晶片設計能力，成為一家真正差異化的雲提供商。此外，這與旗艦客戶（Marquis Customer）Anthropic 繼續推動擺脫對 NVDA 依賴的戰略相一致。(圖表：Anthropic FLOP 組合)Anthropic 的交易標誌著這一推進的一個重要里程碑。我們瞭解到 GCP CEO Thomas Kurian 在談判中發揮了核心作用。Google很早就承諾積極投資 Anthropic 的融資輪次，甚至同意放棄投票權並將所有權上限設定為 15%，以將 TPU 的使用擴展到Google內部之外。前 DeepMind TPU 人才在基礎實驗室的存在促進了這一戰略的實施，導致 Anthropic 在包括 TPU 在內的多種硬體上訓練 Sonnet 和 Opus 4.5。Google已經為 Anthropic 建立了一個實質性的設施，如下所示，這是我們“逐個建築追蹤 AI 實驗室”項目的一部分。(圖片：資料中心行業模型)除了通過 GCP 租用Google資料中心的容量外，Anthropic 還將在其自己的設施中部署 TPU，這使Google能夠作為真正的商用硬體供應商直接與 Nvidia 競爭。關於 100 萬個 TPU 的拆分：交易的第一階段涵蓋 40 萬個 TPUv7 Ironwood，價值約 100 億美元的成品機架，Broadcom 將直接銷售給 Anthropic。Anthropic 是 Broadcom 最近一次財報電話會議中提到的第四個客戶。Fluidstack，一家金牌 ClusterMax Neocloud 提供商，將處理現場設定、布線、老化測試（burn-in）、驗收測試和遠端協助工作，因為 Anthropic 將管理物理伺服器的工作外包。資料中心基礎設施將由 TeraWulf (WULF) 和 Cipher Mining (CIFR) 提供。剩餘的 60 萬個 TPUv7 單元將通過 GCP 租賃，我們估計這筆交易的**剩餘履約義務（RPO）**為 420 億美元，佔 GCP 第三季度報告的 490 億美元積壓訂單增加額的大部分。我們相信，未來幾個季度與 Meta、OAI、SSI 和 xAI 的額外交易可能會為 GCP 提供額外的 RPO + 直接硬體銷售。儘管內部和外部需求巨大，但Google未能按其希望的速度部署 TPU。儘管與仍需“討好” Jensen（黃仁勳）的其他超大規模廠商相比，Google對其硬體供應有更多的控制權，但Google的主要瓶頸是電力。當其他超大規模廠商擴大自己的站點並獲得大量託管容量時，Google的行動較為緩慢。我們認為核心問題是合同和行政方面的。每個新的資料中心供應商都需要一份主服務協議（MSA），這些是數十億美元、多年的承諾，自然涉及一些官僚主義。然而，Google的流程特別慢，從最初的討論到簽署 MSA 通常需要長達三年的時間。Google的變通方案對尋求轉向 AI 資料中心基礎設施的 Neocloud 提供商和加密貨幣礦工具有重大影響。Google不直接租賃，而是提供信用兜底（credit backstop），即如果 Fluidstack 無法支付其資料中心租金，Google將介入支付，這是一張資產負債表外的“借條（IOU）”。(圖表：Fluidstack 交易概覽)像 Fluidstack 這樣的 Neocloud 靈活敏捷，使他們更容易與像“轉型後的加密礦工”這樣的新資料中心供應商打交道。這種機制一直是我們看好加密採礦行業的關鍵——值得注意的是，我們在今年年初股價大幅降低時就點名了包括 IREN 和 Applied Digital 在內的眾多公司。礦工的機會在於一個簡單的動態：資料中心行業面臨嚴重的電力限制，而加密礦工通過其購電協議（PPA）和現有的電力基礎設施已經控制了容量。我們預計未來幾周和幾個季度將有更多協議達成。06Google如何重塑Neocloud市場在 Google/Fluidstack/TeraWulf 交易之前，我們在 Neocloud 市場從未見過任何僅憑資產負債表外“借條”達成的交易。交易之後，我們認為它已成為新的事實上的標準融資範本。這解決了 Neocloud 尋求確保資料中心容量並行展業務的一個關鍵難題：GPU 叢集的有用和經濟壽命為 4-5 年。大型資料中心租賃通常為 15 年以上，典型的投資回收期約為 8 年。這種期限錯配使得 Neocloud 和資料中心供應商為項目融資變得非常複雜。但隨著“超大規模廠商兜底”的興起，我們相信融資問題已得到解決。我們預計 Neocloud 行業將迎來新一波增長。查看我們的加速器和資料中心模型以瞭解主要的受益者。這些是 Anthropic 交易背後的方式和原因，現在讓我們進入硬體部分。此外，擁有 Jensen 作為投資者的 Neocloud，如 CoreWeave、Nebius、Crusoe、Together、Lambda、Firmus 和 Nscale，都有明顯的動機不採用其資料中心內的任何競爭技術：TPU、AMD GPU 甚至 Arista 交換機都是禁區！這在 TPU 託管市場留下了一個巨大的缺口，目前由加密礦工 + Fluidstack 填補。在接下來的幾個月裡，我們預計會看到更多的 Neocloud 在追求不斷增長的 TPU 託管機會和確保最新最棒的 Nvidia Rubin 系統分配之間做出艱難的決定。07TPUv7 Ironwood-為什麼Anthropic和其他客戶想要TPU？答案很簡單。這是一個優秀的系統中的強大晶片，這種組合為 Anthropic 提供了令人信服的性能和 TCO。2.5 年前，我們寫過關於Google計算基礎設施優勢的文章。即使晶片在紙面上落後於 Nvidia，Google的系統級工程也允許 TPU 堆疊在性能和成本效率上與 Nvidia 匹敵。我們當時認為“系統比微架構更重要”，過去兩年的情況加強了這一觀點。Anthropic 的大規模 TPU 訂單是對該平台技術實力的直接驗證。GPU 生態系統也向前邁進了一步。Nvidia 的 GB200 代表了一個巨大的飛躍，推動 Nvidia 成為一家真正的系統公司，設計完整的伺服器而不僅僅是內部的晶片封裝。當我們談論 GB200 在機架級互連方面的巨大創新時，一個被低估的點是，自 2017 年 TPU v2 以來，Google一直在機架內和跨機架縱向擴展（Scaling up）TPU！在報告的後面，我們將對Google的 ICI 擴展網路進行深入分析，這是 Nvidia NVLink 的唯一真正競爭對手。Google最近的 Gemini 3 模型現在被視為最先進的前沿 LLM。像所有早期版本的 Gemini 一樣，它完全在 TPU 上訓練。這一結果為 TPU 能力和Google更廣泛的基礎設施優勢提供了具體證明。今天的注意力通常集中在推理和後訓練的硬體上，但預訓練前沿模型仍然是 AI 硬體中最困難和資源最密集的挑戰。TPU 平台已經果斷地通過了這一測試。這與競爭對手形成鮮明對比：OpenAI 的領先研究人員自 2024 年 5 月的 GPT-4o 以來尚未完成廣泛用於新前沿模型的成功全規模預訓練運行，突顯了Google TPU 艦隊已成功克服的重大技術障礙。新模型的一個關鍵亮點包括在工具呼叫和代理能力方面的顯著提升，特別是在具有經濟價值的長期任務上。Vending Bench 是一項旨在衡量模型在長期內經營業務的能力的評估，通過將它們置於模擬自動售貨機業務的所有者位置，Gemini 3 摧毀了競爭對手。(圖表：Vending-Bench 資金隨時間變化)這次發佈不僅帶來了能力的提升，還帶來了新產品。Antigravity，一個源於收購前 Windsurf CEO Varun Mohan 及其團隊的產品，是Google對 OpenAI Codex 的回應，正式讓 Gemini 進入了“直覺式程式設計（vibe coding）”的代幣消耗戰。對於Google來說，悄悄地介入並在最具挑戰性的硬體問題之一上建立性能領先地位，對於一家核心業務不是——或者我們應該說，曾經不是——硬體業務的公司來說，確實是一個令人印象深刻的壯舉。08微架構仍然很重要：Ironwood接近Blackwell“系統比微架構更重要”的推論是，雖然Google一直在推動系統和網路設計的邊界，但 TPU 晶片本身並不是太具突破性。從那時起，TPU 晶片在最新幾代中取得了巨大進步。從一開始，Google的設計理念相對於 Nvidia 在晶片上就更為保守。歷史上，TPU 的峰值理論 FLOPs 明顯較少，記憶體規格也低於相應的 Nvidia GPU。這有 3 個原因。首先，Google對其基礎設施的“RAS”（可靠性、可用性和可維護性）給予了很高的內部重視。Google寧願犧牲絕對性能來換取更高的硬體正常執行階段間。將裝置運行到極限意味著更高的硬體死亡率，這對系統停機時間和熱備件方面的 TCO 有實際影響。畢竟，你無法使用的硬體相對於性能來說具有無限的 TCO。第二個原因是，直到 2023 年，Google的主要 AI 工作負載是為其核心搜尋和廣告資產提供動力的推薦系統模型。與 LLM 工作負載相比，RecSys 工作負載的**算術強度（arithmetic intensity）**要低得多，這意味著相對於傳輸的每一位資料，所需的 FLOPs 更少。(圖表：Reco vs. LLM)第三點歸結為被行銷的“峰值理論 FLOPs”數字的效用以及它們如何被操縱。像 Nvidia 和 AMD 這樣的商用 GPU 提供商希望為其晶片行銷最佳的性能規格。這激勵他們將行銷的 FLOPs 拉伸到儘可能高的數字。實際上，這些數字是無法維持的。另一方面，TPU 主要面向內部，在外部誇大這些規格的壓力要小得多。這具有我們將進一步討論的重要含義。客氣的看法是 Nvidia 更擅長 DVFS（動態電壓頻率調整），因此樂於僅報告峰值規格。在我們進入 LLM 時代後，Google的 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))是什麼推動了這些性能提升？部分原因是Google開始在 TPU 投入生產時宣佈它們，而不是在下一代部署後才宣佈。此外，TPU v6 Trillium 採用與 TPU v5p 相同的 N5 節點製造，矽面積相似，但能夠提供驚人的 2 倍峰值理論 FLOPs 增加，且功耗顯著降低！對於 Trillium，Google將每個**脈動陣列（systolic array）**的大小從 128 x 128 增加到 256 x 256 tiles，翻了兩番，這種陣列大小的增加帶來了計算能力的提升。(表格：Google 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 是下一次迭代，Google在 FLOPs、記憶體和頻寬方面幾乎完全縮小了與相應 Nvidia 旗艦 GPU 的差距，儘管全面上市時間比 Blackwell 晚 1 年。與 GB200 相比，FLOPs 和記憶體頻寬僅有輕微的短缺，容量與 8-Hi HBM3E 相同，當然這與擁有 288GB 12-Hi HBM3E 的 GB300 相比有顯著差距。(圖表：TPU v7 (Ironwood) vs GB200/GB300 比較)理論絕對性能是一回事，但真正重要的是每總擁有成本 (TCO) 的真實世界性能。雖然Google通過 Broadcom 採購 TPU 並支付高額利潤，但這遠低於 Nvidia 不僅在銷售 GPU 上，而且在包括 CPU、交換機、NIC、系統記憶體、布線和連接器在內的整個系統上賺取的利潤。從Google的角度來看，這導致全 3D 環面（3D Torus）配置的每 Ironwood 晶片的全包 TCO比 GB200 伺服器的 TCO 低約 44%。這足以彌補峰值 FLOPs 和峰值記憶體頻寬約 10% 的短缺。這是從Google的角度以及他們採購 TPU 伺服器的價格來看的。(表格：Nvidia vs TPU SKU 每 TCO 性能比較)那麼當Google加上他們的利潤後，對於外部客戶來說呢？我們假設在Google向外部客戶租賃 TPU 7 賺取利潤的情況下，每小時 TCO 仍然可以比 GB200 的成本低約 30%，比 GB300 的成本低約 41%。我們認為這反映了 Anthropic 通過 GCP 的定價。(圖表：每小時總成本比較 (USD/hr/GPU))09為什麼Anthropoiv押注TPU？比較理論 FLOPs 只能說明部分情況。重要的是有效 FLOPs，因為峰值數字在實際工作負載中幾乎從未達到。實際上，一旦考慮到通訊開銷、記憶體停頓、功率限制和其他系統效應，Nvidia GPU 通常只能達到其理論峰值的一小部分。訓練的一個經驗法則是 30%，但利用率也因工作負載而異。差距的很大一部分歸結為軟體和編譯器效率。Nvidia 在這方面的優勢源於 CUDA 護城河和開箱即用的廣泛開源庫，幫助工作負載高效運行，實現高 FLOPs 和記憶體頻寬利用率。TPU 軟體堆疊並不那麼容易使用，儘管這正在開始改變。在Google內部，TPU 受益於優秀的內部工具，這些工具不對外部客戶開放，這使得開箱即用的性能較弱。然而，這只適用於小型和/或懶惰的使用者，而 Anthropic 兩者都不是。Anthropic 擁有強大的工程資源和前Google編譯器專家，他們既瞭解 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 利用率時，從Google的角度來看，每有效 FLOP 的美元成本變得便宜得多，約 15% 的 MFU 是與 30% MFU 的 GB300 的盈虧平衡點。這意味著如果Google（或 Anthropic）設法達到 GB300 FLOPs 利用率的一半，他們仍然能打平。當然，憑藉Google的精英編譯器工程師團隊和對自己模型的深刻理解，他們在 TPU 上實現的 MFU 可能達到 40%。那將是每有效訓練 FLOP 成本驚人的約 62% 的降低！(圖表：不同 MFU 下的 TCO / 有效訓練 Dense FP8 PFLOP ($/hr per Eff PFLOP))然而，當觀察 60 萬個租賃的 TPU 時，當我們將 Anthropic 支付的較高 TCO（即包括Google的利潤疊加）納入此分析時，我們估計 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)10Google在利潤率上穿針引線在為外部客戶定價時，Google需要“穿針引線”，以平衡自身的盈利能力，同時為客戶提供有競爭力的主張。我們對 Anthropic 定價的估計處於我們聽到的外部定價範圍的低端。對於像 Anthropic 這樣的旗艦客戶，他們將為軟體和硬體路線圖提供寶貴的輸入，同時訂購大量產品，我們預計會有優惠定價（sweetheart pricing）。雖然 Nvidia 令人瞠目結舌的 4 倍加價（約 75% 的毛利率）提供了很大的定價靈活性，但 Broadcom 吸走了大量的氧氣。Broadcom 作為 TPU 的聯合設計者，在晶片上賺取高額利潤，這是系統 BOM（物料清單）的最大組成部分。儘管如此，這仍為Google留下了很大的空間來賺取非常可觀的利潤。我們可以通過將 GCP Anthropic 交易與其他大型基於 GPU 的雲交易進行比較來看出這一點。請注意，這是針對正在租賃的 60 萬個 TPU，其餘 40 萬個 TPU v7 晶片由 Anthropic 預付購買。在這些假設下，TPU v7 的經濟效益顯示出比我們觀察到的其他大型基於 GPU 的雲交易更優越的息稅前利潤率（EBIT margins），只有 OCI-OpenAI 接近。即使有 Broadcom 在晶片級 BOM 上的利潤疊加，Google仍然可以獲得比更加商品化的 GPU 交易優越得多的利潤和回報。這就是 TPU 堆疊允許 GCP 成為真正差異化的 CSP（雲服務提供商）的地方。與此同時，像 Microsoft Azure 這樣的人，其 ASIC 計畫正在掙扎，僅限於在僅僅租賃商業硬體的業務中賺取更多平庸的回報。(表格：主要 AI 雲合同對比)11TPU系統和網路架構到目前為止，我們已經討論了 TPU 與 Nvidia GPU 在單晶片規格和不足之處的比較。現在，讓我們回到系統討論，這是 TPU 能力真正開始分化的地方。TPU 最顯著的特徵之一是通過 ICI 協議實現的極大**縱向擴展（Scale-up）**世界規模（World Size）。TPU pod 的世界規模達到 9216 個 Ironwood TPU，大 pod 尺寸早在 2017 年的 TPUv2 就已成為特徵，擴展到完整的 256 個 1024 晶片叢集大小。讓我們從機架等級開始，這是每個 TPU 超級 pod 的基本建構塊。12Ironwood機架架構(圖片：機架子系統)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。Google自 2018 年 TPU v3 以來一直實施液冷 TPU 機架，但中間仍有一些 TPU 代次設計為風冷。液冷和風冷機架的主要區別在於，風冷機架的 TPU 托盤與主機 CPU 托盤的比例為 2 比 1，而液冷機架的比例為 1 比 1。TPU 液冷的一個創新設計是冷卻劑的流速由閥門主動控制。這使得冷卻更加高效，因為流量可以根據每個晶片在任何給定時間的工作負載量進行調整。Google的 TPU 長期以來也採用垂直供電，其中 TPU 的 VRM 模組位於 PCB 板的另一側。這些 VRM 模組也需要冷板進行冷卻。總體而言，TPU 機架設計比 Nvidia Oberon NVL72 設計簡單得多，後者密度更高，並利用背板連接 GPU 以擴展交換機。TPU 托盤之間的擴展連接全部通過外部銅纜或光學器件進行，這將在下面的 ICI 部分解釋。TPU 托盤和 CPU 托盤之間的連接也是通過 PCIe DAC 電纜進行的。13晶片間互連 (ICI) – 擴展 Scale-Up世界規模的關鍵Google TPUv7 的 ICI 擴展網路的建構塊是一個由 64 個 TPU 組成的 4x4x4 3D 環面（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 立方體之間的連接——下一節將詳細介紹。(表格：Google TPU v7 3D 環面連接配比)Google採用軟體定義網路方法來管理通過光路交換機 (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 交換機的單根光纖束，形成雙向鏈路。Google的 ICI 擴展網路獨特之處在於，它允許將多個 64 TPU 4x4x4 立方體以 3D 環面配置連接在一起，以建立巨大的世界規模。TPUv7 具有 9,216 個 TPU 的最大世界規模，但今天，Google支援將 TPU 配置為多個不同的切片大小，從 4 個 TPU 一直到 2,048 個 TPU。雖然Google可以創新地實現令人印象深刻的 9,216 個 TPU 的擴展叢集，但在任何時間點在高達約 8,000 個 TPU 的增量較大塊大小上運行訓練工作負載的好處會減少。這是因為較大的塊大小更容易發生故障和中斷，從而降低切片可用性，切片可用性定義為 ICI 叢集能夠形成連續 3D 環面切片的時間比例。對於可以完全容納在 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+ 側，依此類推。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 永遠無法連接到任何其他立方體的“-”面。讓我們做大一點，看看如何設定 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 連接，它們可能各自位於資料中心完全不同的位置。我們現在將移動到一個更大的拓撲——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 來支援這個最大世界規模。除了可以花費無數小時繪製所有花哨的立方體圖之外，Google獨特的 ICI 擴展網路有什麼好處？世界規模：最明顯的好處是 TPUv7 Ironwood 支援的非常大的 9,216 TPU 最大世界規模。即使由於**有效吞吐量（goodput）**降低的缺點，9,216 的最大切片大小可能很少使用，但數千個 TPU 的切片可以並且經常被使用。這遠大於商業加速器市場和其他定製晶片提供商常見的 64 或 72 GPU 世界規模。可重構性和可替代性：OCS 的使用意味著網路拓撲本質上支援網路連線的重新配置，以支援大量不同的拓撲——理論上有數千種拓撲。Google的文件網站列出了 10 種不同的組合（本節前面的圖片），但這只是最常見的 3D 切片形狀——還有更多可用的形狀。即使是相同大小的切片也可以進行不同的重新配置。在下面圖示的扭曲 2D 環面（Twisted 2D Torus）的簡單示例中，我們看到如何跨越到不同 X 坐標的索引而不是相同 X 坐標的索引，可以減少最壞情況下的跳數和最壞情況下的對分頻寬（bisection bandwidth）。這有助於提高所有對所有的集體吞吐量。TPUv7 叢集將在 4x4x4 立方體等級扭曲。可重構性也為廣泛的多樣化平行性打開了大門。在 64 或 72 GPU 世界規模中，不同的平行性組合通常限於 64 的因子。當涉及到 ICI 擴展網路時，實施拓撲以精確匹配所需的資料平行、張量平行和管道平行組合的可能性是豐富的。OCS 允許人們將任何立方體的任何“+”面連接到任何其他立方體的“-”面的事實意味著立方體具有完全的可替代性。切片可以由任何一組立方體組成。因此，如果有任何故障或使用者需求或使用情況的變化，這不會阻礙新拓撲切片的形成。更低的成本：Google的 ICI 網路成本低於大多數交換式擴展網路。雖然由於使用環形器，所使用的 FR 光學器件可能稍貴，但網狀網路減少了所需的交換機和連接埠的總數，並消除了交換機之間連接產生的成本。(表格：擴展網路成本比較)低延遲和更好的局部性：TPU 之間直接鏈路的使用意味著對於物理位置彼此靠近或重新配置為直接相互連接的 TPU，可以實現低得多的延遲。彼此靠近的 TPU 也具有更好的資料局部性。資料中心網路 (DCN) – 擴展超過 9,216 個 TPU資料中心網路 (DCN) 是獨立於 ICI 的網路，充當典型後端和前端網路的角色。它連接甚至更大的域——在 TPUv7 叢集的情況下為 14.7 萬個 TPU。正如我們在之前關於 Apollo 任務的文章中所討論的，Google提議用 Paloma 光路交換機 (OCS) 取代傳統“Clos”架構中包含電子封包交換 (EPS) 的脊層（spine layer），Google的 DCN 由光學交換的資料中心網路互連 (DCNI) 層組成，該層結合了幾個聚合塊，每個聚合塊連接幾個 9,216 TPU ICI 叢集。2022 年，Google的 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 個聚合塊，但Google DCN 的獨特架構允許在無需大量重新布線的情況下將新的 TPU 聚合塊加入到網路中。通過將 OCS 用於 DCNI 層，DCN 結構的大小可以增量擴展，並且可以**重新條帶化（re-striped）**網路以支援新的聚合塊。此外，聚合塊的頻寬可以升級，而無需更改 DCN 層的構成。這允許現有聚合塊的鏈路速度得到刷新，而無需改變網路本身的基本架構。結構擴展的過程不能無限期地進行下去——在巨大的規模下，重新布線網路變得難以管理。(圖表：使用 OCS 鏈路的 AB 擴展)TPU 軟體戰略 – 另一個巨大的轉變傳統上，TPU 軟體和硬體團隊一直是面向內部的。這帶來了優勢，例如沒有行銷團隊施加壓力來誇大陳述的理論 FLOPs。只面向內部的另一個優勢是 TPU 團隊極大地優先考慮內部功能請求和最佳化內部工作負載。缺點是他們不太關心外部客戶或工作負載。TPU 生態系統中的外部開發人員數量遠低於 CUDA 生態系統。這是 TPU 的主要弱點之一，所有非 Nvidia 加速器也是如此。Google此後修改了針對面向外部客戶的軟體戰略，並已經對 TPU 團隊的 KPI 以及他們如何為 AI/ML 生態系統做出貢獻做出了重大改變。我們將討論 2 個主要變化：在 PyTorch TPU“原生”支援上的大規模工程努力在 vLLM/SGLang TPU 支援上的大規模工程努力通過查看Google對各種 TPU 軟體倉庫的貢獻數量，可以清楚地看到這種外部化戰略。我們可以看到從 3 月開始 vLLM 貢獻顯著增加。然後從 5 月開始，建立了“tpu-inference”倉庫，這是官方的 vLLM TPU 統一後端，從那時起就有一系列活動。(圖表：Google按倉庫每月的貢獻)傳統上，Google僅對 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 月，Google的“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 和Google也已開始致力於支援 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 作為二等公民）。現在Google想要進入 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。Google和 vLLM 聲稱這種下譯到 jax 的路徑不需要對 PyTorch 建模程式碼進行任何更改，但鑑於 vLLM TPU 目前支援的模型很少，我們對此表示懷疑。此外，Google已經開源並將他們的一些 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 在執行排序操作方面很慢，並且核心無法將通訊與計算重疊。為瞭解決這個問題，Google開發人員設計了全融合 MoE（All-fused MoE）。全融合 MoE 一次為每個裝置分發一個專家的代幣，同時重疊 MoE 分發和 MoE 組合通訊，並避免按專家 ID 對代幣進行排序。使用全融合 MoE，Google工程師報告比現有核心有 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 文章中深入描述了這一點，Google在 vLLM 上對單主機分離 PD 提供了實驗性支援，注意他們尚不支援多主機 wideEP 分離預填充或 MTP。這些推理最佳化對於降低每百萬代幣的 TCO 以及提高每美元性能和每瓦性能至關重要。此外，他們尚未將 TPU vLLM 推理支援整合到流行的 RL 框架（如 VERL 等）中。Google在如何接近開放 AI/ML 生態系統方面正慢慢朝著正確的方向前進，特別是對於他們的“原生”TPU 後端。vLLM TPU 基準測試尚不相關本周，TPUv6e 上發佈了一個新的推理基準測試，聲稱 TPUv6e 的每美元性能比 NVIDIA GPU 差 5 倍。我們不同意，主要有兩個原因。首先，這個基準測試是在 TPU 上的 vLLM 上進行的，該版本僅發佈了幾個月，因此尚未具有最佳化的性能。Google內部的 Gemini 工作負載和 Anthropic 工作負載運行在內部自訂推理堆疊上，其每 TCO 性能優於 NVIDIA GPU。其次，Artificial Analysis 的每百萬代幣成本使用的是 TPUv6e 的標價 2.7 美元/小時/晶片。鑑於 BOM 只是 H100 的一小部分，沒有 TPU 的主要客戶會為 TPUv6e 支付接近那麼高的價格。眾所周知，大多數雲都有一個虛高的標價，以便他們的客戶銷售主管可以採用**“汽車推銷員”式的戰術（高標價、大折扣）**，讓客戶認為他們得到了一筆好交易。SemiAnalysis AI TCO 模型跟蹤所有各種合同長度（1 個月、1 年、3 年等）的 TPU 實際市場租賃價格。(圖表：每百萬輸入和輸出代幣的成本)TPU 軟體戰略的關鍵缺失部分Google在軟體戰略上仍然處理不當的一個部分是，他們的 XLA 圖編譯器和網路庫以及 TPU 執行階段仍然沒有開源，也沒有很好的文件記錄。這導致了從高級使用者到普通使用者的各種使用者感到沮喪，無法偵錯程式碼出了什麼問題。此外，他們用於多 pod 訓練的 MegaScale 程式碼庫也不是開放原始碼的。我們堅信，為了加速採用，Google應該將其開源，使用者採用的增加將超過他們將公開和免費的所有軟體 IP。就像 PyTorch 或 Linux 開源迅速增加了採用率一樣，開源 XLA:TPU 和 TPU 執行階段及網路庫也將迅速加速這一點。 (硬AI)
