谷歌發布TPU 8t Sunfish和TPU 8i Zebrafish。

在 Google Cloud Next 大會上，Google發布了其下一代 AI 加速器：用於訓練的 TPU 8t“Sunfish”和用於推理的 TPU 8i“Zebrafish”，以及全新的 Virgo 資料中心架構。從Google的部落格文章來看，這些晶片顯然是為「智能體時代」而優化的：在數十萬個晶片的規模上訓練前沿的混合專家模型，然後以低延遲和極具競爭力的單代幣價格目標來服務這些模型。 8t 和 8i 是兩款架構不同的晶片，它們共享主機平台和架構，但在記憶體容量、片上 SRAM、互連拓撲和晶片內部功能方面存在差異。 8t 專為大規模密集矩陣乘法 (matmul) 而設計，而 8i 則圍繞矽基鍵值快取和單一代幣集體延遲而建構。

單一 8t 超級加速器可擴展至 9,600 個晶片，配備 2 PB 的 HBM 內存，並提供 121 EFLOPS 的 FP4 運算能力，幾乎是 Ironwood 超級加速器單節點運算能力的 3 倍。 8i 超級加速器在 1,152 個晶片的擴展範圍內，將 288 GB 的 HBM 記憶體與 384 MB 的片上 SRAM（Ironwood 的 3 倍）相結合，並聲稱其 LLM 推理的性價比比 Ironwood 高出 80%。 Virgo 將這兩個晶片系列整合到一個資料中心架構中，該架構以 47 Pb/s 的非阻塞二分頻寬連接超過 134,000 個 8t 晶片，單加速器頻寬最高可達上一代的 4 倍，空載延遲降低 40%。

TPU究竟是什麼？

在深入了解 8 晶片之前，先來了解 TPU 是什麼以及它與 GPU 有何不同，因為只有在這種背景下，這 8 個設計決策才有意義。

張量處理單元 (TPU) 是Google自 2015 年以來一直在迭代開發的客製化 ASIC 晶片。每一代 TPU 都基於相同的核心概念：與 GPU 動態調度數千個小型核心不同，TPU 的核心是少量的大型 MXU（矩陣乘法單元），這些 MXU 由片上軟體管理的 SRAM 暫存區提供數據，並由提前編譯器 (AOT) 驅動。每個晶片都包含少量 TensorCore，每個 TensorCore 都圍繞一個大型脈動陣列 MXU 構建，此外還有一組較小的 SparseCore，專門用於處理推薦嵌入中占主導地位的不規則的收集-分散查找。資料從 HBM 流經暫存區，經過 MXU，返回暫存區，然後再流出，同時還有一個向量處理單元 (VPU) 處理啟動、歸一化和歸約等操作。 TPU 沒有硬體線程束調度器，沒有 GPU 意義上的 L1 或 L2 快取層次結構，也沒有動態調度。

這種設計的優點在於其在稠密線性代數方面的效率。由於預先編譯器會決定每個張量的位置以及每個集合何時觸發，因此不會出現快取未命中抖動，也不會增加執行緒束調度器開銷。當數萬個晶片需要透過集合保持同步時，這一點的重要性遠超想像。對於經過良好調優的訓練工作負載，TPU 上的實際模型 FLOP 利用率往往高於傳統 GPU。缺點是，任何無法清晰地映射到大型稠密矩陣乘法運算的內容，特別是動態形狀、不規則稀疏模式、具有不均勻標記分佈的 MoE 路由或圖神經網絡，都難以高效表達。此外，TPU 歷來每個晶片搭載的 HBM 數量少於 GPU，且框架支援也更為狹窄。 XLA 和 JAX 是一等公民；PyTorch 直到最近才需要一個轉換層；此外，編譯器、運行時、網絡庫和多 pod 軟體棧仍然是 Google 內部的閉源。

稀疏性是GPU和TPU之間理念差異的最鮮明例證，原因在於結構而非行銷。自Ampere架構以來，NVIDIA就在Tensor Core上支援2:4結構化稀疏性，理論上，稀疏工作負載的效能是密集工作負載的兩倍。 Tensor Core本質上是一個調度單元：它需要明確地載入每個MMA指令的操作數，因此，添加一個接受壓縮的2/4塊及其索引元資料的稀疏MMA變體，是對現有指令集的直接擴展。每個週期，硬體只會將非零值及其索引提取到乘法器數組中，而隱式地跳過零值。

流水線陣列的工作方式則相反。每個處理單元 (PE) 在每個週期中都進行計算，操作數透過直接的暫存器到暫存器路徑，以同步的方式從一個 PE 流向下一個 PE。這種確定性的資料流正是其相對於 SIMT 的能效優勢所在：無需重複讀取 SRAM，沒有指令分發開銷，操作數復用率最大化。但這同時也意味著，硬體不能在每個週期跳過一個值為零的元素，否則就會中斷管線。

TPU 仍然可以在 tile 層級利用稀疏性；如果一個 MXU 大小的 tile 全部為零，編譯器就不會調度在其上執行工作。然而，谷歌選擇不為結構化稀疏性添加硬體加速是經過深思熟慮的。在脈動陣列中添加 M:N 結構化稀疏性可以使用多種技術，每種技術都有不同的權衡取捨。其中一種技術需要在 SRAM 和陣列的輸入埠之間放置一個壓縮單元。但脈動陣列是流水線，而不是調度器。它的效率保證來自於操作數以確定的節奏到達，每個處理單元在每個週期都處於忙碌狀態。允許跳過操作數會帶來兩種代價。要么在零值上阻塞流水線，這會抹殺最初促使該架構設計的效率優勢。要么添加專用的解壓縮硬件，在壓縮輸入進入陣列之前重建全寬流，但這會佔用晶片面積並增加延遲。

一些加速器將脈動陣列與硬體稀疏性支援相結合。 AWS 基於 Trainium2 和 Trainium3 內部的 NeuronCore-v3 引擎建構了一個這樣的加速器。此實作展示了硬體稀疏脈動陣列的結構。 NeuronCore-v3 張量引擎是一個 128×128 的脈動陣列，它處理一個靜態權重矩陣和一個流式活化矩陣，其收縮維度與陣列的分區維度對齊。在稀疏模式下，輸入資料路徑從密集 BF16 和 FP16 上的每週期 2×128 個元素擴展到每週期 5×128 個元素，並且靜態端使用權重矩陣的壓縮表示，而不是原始的密集權重。在編譯時，權重張量被處理成 M:N 格式。在收縮維度上，每 N 個連續元素中只保留 M 個，並使用緊湊的位元遮罩編碼來表示非零位置。壓縮緩衝區僅儲存 M 個值，容量縮小了 N/M 倍。當 matmul 指令執行時，硬體讀取壓縮後的權重，並使用位元遮罩將來自固定區塊的相應啟動路由到正確的處理單元。原本乘以零的處理單元不會在該插槽接收工作。由於位元遮罩查找和路由位於向數組提供資料的解壓縮器中，而不是數組本身中，因此管線在處理非零值時保持全速運行，而不會在處理零值時停頓。

TPU 的功能遠遠超過稠密矩陣乘法。幾個世代以來，TPU 除了 TensorCore 之外，還包含一個 SparseCore。 SparseCore 是一個特定領域的引擎，專為推薦模型中不規則的「收集-分散」存取模式而設計。 YouTube 排名模型或搜尋廣告相關性模型與稠密 Transformer 模型截然不同。它們的大部分參數都儲存在嵌入表中，這些表的大小從數百 GB 到 PB 級不等，而它們的大部分計算時間都花費在從這些表中執行小型查找、對檢索到的值進行輕微轉換以及合併結果上。這種存取模式對於 MXU 來說​​是最糟糕的情況，即使對於 GPU 的快取層次結構也只是略好一些。 SparseCore 正是針對這種情況進行了優化：對駐留在 HBM 中的嵌入表執行高吞吐量的“收集-分散”操作，並提供硬體支持，以完成嵌入流水線其餘部分所依賴的去重和合併操作。同樣的硬體也有助於 MoE 專家路由，因為一旦前 k 個選擇生成專家索引，其餘的路由過程（按專家排列標記、將它們分發到晶片上、收集專家輸出並執行加權歸約）都遵循與嵌入流水線相同的收集/分散/歸約模式，而 SparseCore 的步驟支持涵蓋了前 k 個排序本身。

基於以上背景，以下是公告內容。

TPU 8噸“翻車魚”

首款發表的產品是代號為「Sunfish」的TPU 8t，這是一款訓練晶片。與Ironwood相比，TPU 8t在大多數方面都遵循了預期的發展軌跡：更大的記憶體、更高的頻寬以及對更窄資料類型的原生支援。每個晶片都搭載一個TensorCore，由六個12層HBM3e快閃記憶體堆疊供電，總容量為216GB，讀寫速度為6.5TB/s，相比Ironwood的八個堆疊的192GB有了顯著提升。片上Vmem SRAM容量維持在128MB。

MXU 的原生 FP4 是計算效能大幅提升的主要原因。對於相同的實體陣列，使用 4 位元而非 8 位元運行矩陣乘法運算，每個週期的吞吐量翻倍，這正是 Google 如何將 Ironwood 的 4.6 PFLOPS FP8 效能提升到 8t 的 12.6 PFLOPS FP4 效能的秘訣。混合精度訓練仍保留一份 FP32 權重主副本用於優化器步驟；FP4 縮小了消耗大部分計算時間的工作張量。

互連架構的改進方案很簡單。 ICI頻寬翻倍至每晶片19.2 Tb/s，9,600晶片的超級資料中心聚合了2 PB的HBM和121 EFLOPS的運算能力，並保留了3D環面拓樸結構。環面拓樸結構非常適合訓練，因為前緣任務主要由環面友善的集體操作構成：資料和張量並行性的all-reduce操作、FSDP的all-gather和reduce-scatter操作，以及流水線並行的點對點發送操作。這一切都與環面的軸線完美契合。

Google也保留了自 v4 版本以來每個 TPU 都配備的 SparseCore。它們最初的用途是 DLRM 式的建議模型，這類模型的大部分計算時間都用於對龐大的嵌入表進行不規則的收集-分散操作。同樣的硬體也負責 MoE 路由。 JAX 將不規則的全對全通訊和與之匹配的 ragged_dot 通訊作為一等操作公開，其中每個晶片可以向每個對等節點發送不同大小的資料區塊。這與 MoE 分發的實際形狀相匹配，因為 top-k 路由依賴數據，並且流向每個專家的 token 數量在每個步驟中都會變化。編譯器將不規則通訊和不規則專家矩陣乘法融合到單獨的調度操作中，而 SparseCore 則處理周圍的排序和排列操作。隨著混合專家架構 (MoE) 成為前沿模型的主流架構，該硬體在所有現代訓練任務中都證明了其價值，而不僅僅是其最初設計的廣告和排名工作負載。

這些都是漸進式的變革。更大的變革在於TPUDirect和向基於Axion的主機架構的遷移，這兩項變革都旨在解決只有在前沿規模下才會顯現的瓶頸問題。

TPUDirect RDMA 和 TPUDirect 存儲

先前的 TPU 版本使用主機中介路徑進行網路和儲存 I/O：資料包首先到達主機 DRAM，然後透過單獨的 DMA 將其複製到 TPU HBM。這需要兩次記憶體操作，並且主機 CPU 會參與其中。 TPUDirect RDMA 消除了緩衝緩衝區。網路卡透過 PCIe 點對點連線直接讀寫 TPU HBM，從而將主機從資料路徑中移除。 NVIDIA 多年來一直提供類似的 GPUDirect RDMA 功能，並聲稱其效能比主機中介路徑提升約 10 倍。現在，Google 也在 TPU 方面實現了類似的功能。

TPUDirect Storage 將相同的原理擴展到了持久性儲存。張量直接在 TPU HBM 和 Managed Lustre 之間傳輸，總速率高達 10 TB/s，Google聲稱這比 Ironwood 上的同等路徑快 10 倍。在規模龐大的前沿場景下，檢查點的大小可能達到數百 TB，其區別在於，長達數週的訓練運行能否以線速傳輸檢查點和資料集，還是會因為等待主機 I/O 而導致 MXU 流水線停滯。

臂軸子主機

之前的每一代 TPU 都運行在第三方 x86 主機上。而 8t 是首款採用Google自研 Axion 處理器（基於 Arm Neoverse V2 架構的 CPU）作為系統頭的 TPU。主機 CPU 在 TPU pod 上承擔著繁重的任務，並且在規模不斷擴大時難度也隨之增加：它需要驅動輸入管線、解碼和重排數 PB 等級資料集、管理 JAX/XLA 控制平面、處理檢查點序列化，以及協調數千個晶片上的 SPMD 調度。如果主機故障，MXU 就會閒置。

谷歌特別指出，8t 平台上的 Axion NUMA 隔離機制能夠有效防止主機端抖動影響到同步的集體訓練階段。每個 pod 包含 9,600 個晶片，即使是單一主機上的微小抖動也會累積成可衡量的吞吐量損失。 TPUDirect 透過將主機從批次傳輸中移除來處理資料路徑。 Axion 則透過為每個 TPU 分配足夠的專用 CPU 頻寬來處理控制路徑，從而確保預處理不會成為瓶頸。此外，Google還提高了第八代平台上每台伺服器的實體 Axion 主機數量比例，從而為編排開銷（該開銷會隨著晶片數量的增加而增加）提供了比 Ironwood 主機配置更大的餘地。

TPU 8i “斑馬魚”

推理晶片與 8t 共享 Axion 主機平台、原生 FP4 和 HBM3e 內存，但其底層晶片針對的是不同的瓶頸。訓練受限於運算能力，而推理解碼受限於記憶體頻寬。 8i 的大部分架構差異都源自於此。

最大的變化在於片上SRAM。 8i擁有384MB的Vmem，是Ironwood的三倍。這之所以重要，是因為KV快取。在長上下文解碼過程中，每個產生的token都需要讀取先前token中累積的鍵值狀態。在大多數加速器上，這種讀取操作來自HBM，這意味著解碼吞吐量受限於記憶體頻寬而非運算能力。 8i的容量設計使得其能夠在矽片上容納足夠大的KV緩存。片上SRAM的頻寬比HBM高出一個數量級，因此每次KV讀取操作都從SRAM而非HBM進行，意味著在相同功耗下，每個token的延遲更低，每秒token處理量更高。

TensorCore 配置是另一項重大改進。 8t 使用單一 TensorCore，算力為 12.6 PFLOPS，而 8i 將計算任務分配到兩個 TensorCore 上，總算力為 10.1 PFLOPS。較低的峰值吞吐量看似是一種降級，但考慮到晶片級推理的實際情況，情況就並非如此了。訓練工作負載以批次為主：大型矩陣乘法運算可以分攤固定開銷，單一大型 MXU 可以維持接近峰值的利用率。推理解碼則恰恰相反。批次大小較小，每個標記的計算視窗較短，晶片的大部分時間都用於集體運算、取樣和路由，而不是純粹的矩陣乘法運算。單一大型引擎在這些不規則的間隙中會停滯不前。將 TensorCore 拆分為兩個 TensorCore 可以讓 8i 更有效地重疊計算階段，每個 TensorCore 由其自身的四個直接連接的 HBM 堆疊供電，整個封裝的總容量為 288 GB，吞吐量為 8.6 TB/s。結果是，在互動式服務實際運行的批次大小下，可以實現更高的持續利用率。

在規模化域層面，Boardfly pod 中的 1,024 個活躍晶片總共擁有約 295 TB 的 HBM 記憶體、384 GB 的片上 SRAM 以及 10.3 EFLOPS 的 FP4 運算能力。 SRAM 的容量對於推理至關重要：整個域內 384 GB 的片上快取足以儲存大量的鍵值狀態而無需動用 HBM，這使得低延遲的長上下文服務成為可能。

主機端也遵循同樣的邏輯。 Google表示，與 Ironwood 相比，8i 版本中每台伺服器上的 Axion 實體主機數量有所增加。推理伺服器在每個令牌處理過程中，會花費相當一部分時間進行令牌化、取樣邏輯、路由、批次和代理執行時間編排。這些開銷與並發量而非模型大小成正比，在代理工作負載產生的請求速率下，主機可能會成為瓶頸。增加每個加速器的主機 CPU 是直接的解決方案。

集體加速引擎

另一個主要的晶片內部改動是採用了 Collectives 加速引擎，它取代了 Ironwood 晶片上的四個 SparseCore 核心。 SparseCore 核心負責 MoE 路由和嵌入查找，並配備了專用的收集-分散硬件，因此將它們從推理晶片中移除，意味著 8i 晶片針對的是另一個瓶頸進行了優化。

CAE 解決的瓶頸在於集體延遲。每個解碼的令牌都需要參與的晶片進行同步：注意力輸出必須全部歸約，專家路由元資料必須廣播，採樣代幣必須傳播到下一步。在 GPU 上，這種協調是透過 NCCL 在軟體中實現的，NCCL 將集體操作調度為一系列核心啟動和網路操作。在 8i 上，CAE 是一個專用的矽晶片，位於與 TensorCores 並排的獨立晶片上，在硬體層面處理這些同步原語。

谷歌聲稱其晶片上的集體延遲比 Ironwood 低 5 倍。在訓練規模的批次大小下，這種改進會被計算時間所抵消；集體延遲僅佔總延遲的一小部分。但在互動式推理的小批次和短單次運算時間視窗下，集體延遲可能會超過單次運算時間，因此 5 倍的降低會體現在每秒運算次數和單次運算價格上。

8i 也從 3D 環面拓撲結構轉向了Google稱為 Boardfly 的拓撲結構，這是一種受 Dragonfly 啟發的分層拓撲結構，它犧牲了環面集體頻寬來換取全鏈路延遲。我們將在下文中詳細探討 Boardfly。

飛板拓撲

8i 使用的拓樸結構與 8t 不同，因為訓練和推理的溝通模式不同。

3D 環面非常適合環形集合：每個晶片有六個鄰居，資料在環上循環，沒有晶片可以路由任意流量。訓練過程主要受這些環面友善模式的影響，這也是 8t 保留環面結構的原因。環面全歸約操作完美地對應到單一環面軸上。前緣任務通常將資料並行性放在一個軸上，張量並行性放在另一個軸上，管線並行性放在第三個軸上。拓撲結構與工作負載相符。

為大型 MoE 模型提供服務的推理具有不同的通訊模式。專家節點分佈在多個晶片上，每個解碼的令牌都會觸發一次全對全通訊：令牌必須到達分散在整個網路中的指定專家節點，並且專家節點的輸出必須返回。這不是環路通信，而是任意點對點通信。在一個 1,024 晶片的 3D 環面上，任兩個晶片之間的最壞情況路徑需要 16 跳。 Google為我們詳細解釋了其中的數學原理：「在 3D 環面上，節點排列成網格狀，每個維度都像環一樣環繞。在 8 x 8 x 16（1024 晶片）的配置中，要到達最遠的晶片，封包必須遍歷每個環一半的距離：

三維環面 = 8/2(X) + 8/2(Y) + 16/2(Z) = 16 次跳躍

雖然環面對於密集訓練中常見的鄰居間通訊非常高效，但它會為所有晶片間的通訊模式帶來額外的延遲。在推理模型和迭代優化（MoE）時代，任何晶片都可能需要與其他任何晶片通訊來路由令牌，因此跳數至關重要。

對於對延遲敏感的互動式服務而言，這些額外的跳轉會使每個令牌的延遲超出其服務等級目標 (SLO)。

Boardfly 是一種受 Dragonfly 啟發而設計的層級結構，旨在壓縮其直徑。此結構包含三個層級。其基本建構模組是一個四晶片環，具有 16 個外部連接。八個這樣的建構模組組成一個群組，組內透過銅纜完全連接，每個組有 11 個連結。 36 個群組透過光路交換器連接形成一個節點。最後形成一個 1,152 個晶片的擴展域（其中 1,024 個處於活動狀態），任兩個晶片之間最多只有 7 跳，比環面減少了 56%。谷歌聲稱，對於像 MoE 全連接這樣的通訊密集型工作負載，這可以使延遲降低高達 50%。

更大的擴展域對於專家複製也至關重要。每個 ICI 架構上的晶片數量越多，大型 MoE 中的每個專家就可以被複製更多次，從而平滑路由不平衡，並在令牌分佈不均時保持解碼延遲穩定。 Top-k 路由依賴資料；在任何給定步驟中，某些專家看到的令牌數量會比其他專家多。複製機制可以吸收這種差異。 ICI 頻寬翻倍至每個晶片 19.2 Tb/s，部分原因是為了應對由此產生的流量。

處女座網絡

一個包含 9,600 個晶片的超級節點規模龐大，但前緣訓練運行對規模的要求越來越高。 Virgo 是一種橫向擴展架構，用於連接資料中心內的各個超級節點，並在作業規模超出單一縱向擴展域時，處理節點間的東西向 RDMA 流量。

單一 Virgo 架構可連接超過 134,000 個 8t 晶片，提供 47 Pb/s 的無阻塞雙向頻寬，單加速器頻寬最高可達上一代產品的 4 倍，空載延遲降低 40%。架構採用扁平化的雙層無阻塞拓樸結構，基於高基數交換機，具有多平面設計和獨立控制域。

傳統的 Clos 架構會在較高層級進行超額分配，以控制連接埠數量和成本。當大部分流量為南北向時，這種方式效果良好，這也是通用雲端的典型模式：客戶端存取負載平衡器，負載平衡器存取應用伺服器，應用伺服器存取儲存。而 AI 訓練工作負載幾乎完全是東西向的，在整個架構中逐晶片傳輸，資料聚合主要依賴二分法。任何層級的超額分配都會直接影響訓練步驟的耗時。 Virgo 採用扁平化的雙層設計，並使用高基數交換機，透過建造每個 ASIC 擁有足夠連接埠的交換機，將架構中相當一部分流量在兩跳內完成，從而消除了脊椎層瓶頸。

在如此大規模的應用中，可靠度工程至關重要，並且高度依賴Google基於MEMS的光路交換機（OCS）。 OCS讓Google能夠在作業之間重新配置實體拓撲結構，而無需重新佈線，更重要的是，它還能在運行過程中繞過故障晶片或連結。當偵測到故障時，OCS可以在幾毫秒內重新映射受影響的拓撲結構，從而無需人工幹預。亞毫秒級的遙測資料用於自動偵測掉鍊和掛起。快速檢測和基於OCS的重新路由相結合，優化了100,000萬多個晶片規模下的平均中斷間隔時間（MTBI）和平均恢復時間（MTTR），在這個規模下，持續數週的運行中出現故障的機率接近100%。 Google為8t級Pod設定的97%的吞吐量目標正是基於此基礎設施。同樣的OCS技術貫穿整個TPU堆疊：它在ICI層將立方體拼接成超級Pod，並在8i級擴展層連接Boardfly組，並在Virgo層處理Pod間的流量。

在134,000萬個晶片的情況下，總運算能力約為1,690 EFLOPS（FP4），或約1.7 ZFLOPS。谷歌表示，該架構支援單一邏輯訓練叢集中多達一百萬個晶片的近線性擴展，但目前的部署尚未達到這一上限。

木星和多數據中心規模

Virgo負責處理資料中心內的東西向加速器流量，但它並非架構的最頂層。 Jupiter是Google現有的南北向網路架構，目前已發展到第五代，負責處理前端流量以及對分散式儲存和運算資源的存取。 Jupiter並未在Cloud Next大會上發布；它是第八代架構所依賴的現有基礎架構。

最新一代的 Jupiter 架構，每棟資料中心大樓可提供 13 Pb/s 的雙向頻寬，可用性高達 99.999%。它採用 Apollo MEMS OCS 交換機，每個 OCS 的功耗約為 108 瓦，而同等規格的電交換機則需要約 3,000 瓦。正是這套架構將Google的資料中心與外部世界以及彼此連結起來。

對於超出單一資料中心處理能力和空間限制的訓練運行，Jupiter 能夠實現跨多個站點的擴展。此組合採用分層架構：單一 pod 內使用 ICI，同一站點內不同 pod 之間使用 Virgo，站點之間使用 Jupiter。 Google 的 Pathways 軟體堆疊可以將跨這些多資料中心域的工作負載作為一個邏輯叢集來處理。

單一 Virgo Fabric 的表現約為 1.7 ZFLOPS，是目前已公佈的最大 AI 訓練群集。多個 Virgo Fabric 透過 Jupiter 連接，可以支援超過一百萬個 TPU 晶片，這正是Google的目標規模，儘管目前的部署尚未達到這一目標。

產量和利用率

原始浮點運算次數（FLOPs）的重要性遠不及其中產生有效計算的浮點運算次數所佔的比例。谷歌為8噸超級算力伺服器設定了97%的有效吞吐量目標，這意味著97%的實際運行時間都用於高效計算，而不是用於恢復、停頓或協調開銷。這個數字取決於上文提到的基於OCS的容錯機制和亞毫秒遙測技術。

模型浮點運算利用率 (MFU) 是另一個變數。 MFU 衡量的是晶片在實際工作負載下實際能夠達到的理論峰值浮點運算能力的百分比。 SemiAnalysis 估計，當 TPU MFU 達到 40% 時，與 GB300 NVL72 相比，每次有效訓練浮點運算的成本將下降約 62%，損益平衡點約為 TPU MFU 15%。 Anthropic 公開揭露的 TPU 經濟效益表明，其營運成本遠高於損益平衡點。高吞吐量（保持晶片持續運行）和具有競爭力的 MFU（確保晶片在運行時保持高負載）的結合，使得 TPU 的總體擁有成本 (TCO) 能夠在規模化應用中保持優勢。

8號座位

將 TPU 8 與 NVIDIA 目前及即將推出的平台進行比較時，需要仔細注意單位。 NVIDIA 標稱的 NVLink 頻寬為雙向聚合頻寬；例如，B200 的 NVLink 5 頻寬為 1.8 TB/s，單向頻寬為 900 GB/s。 NVIDIA 的標稱 FLOPs 通常為 2:4 稀疏浮點運算，而密集浮點運算的 FLOPs 則只有稀疏浮點運算的一半。谷歌的 TPU 數據是密集雙向的。在閱讀任何比較資料時，請務必確認頻寬是單向還是雙向，以及 FLOPs 是密集還是稀疏的。

 

單晶片FP4性能方面，8t架構的密集型GPU性能為12.6 PFLOPS，介於GB200的稀疏型GPU性能10 PFLOPS（密集型GPU性能5 PFLOPS）和GB300的稀疏型GPU性能20 PFLOPS（密集型GPU15 PFLOPS）之間。單晶片效能比較接近，但規模經濟面則不然。一個GB300 NVL72機架在一個NVLink域中可容納72個GPU。而一個8t超級伺服器則在一個3D環面中容納9,600個晶片。這意味著在單一集群域中，晶片數量是GB300的133倍，這正是區分前緣訓練平台效能差距的關鍵。

NVIDIA並未止步不前。 Vera Rubin將於2026年下半年上市，每個封裝擁有50 PFLOPS的NVFP4推理能力（儘管SemiAnalysis質疑該數據是否基於自適應壓縮），配備288 GB的HBM4顯存，讀寫速度為22 TB/s，以及雙向3.6 TB/s的NVLink 6接口。 Rubin Ultra將於2027年下半年上市，採用四片光刻晶片拼接而成，每個封裝最高可達100 PFLOPS的FP4推理能力和1 TB的HBM4e顯存。 Kyber NVL576可以將576個Rubin Ultra GPU整合在一個機架中，實現15 EFLOPS的FP4推理能力。這開始縮小谷歌在規模化方面的優勢，儘管576個GPU的體積仍然比8噸超級機箱小一個數量級。

其中 8 的優點在於：擴展域規模（9,600 個晶片對比 72 個 GPU，或 Kyber 之後的 576 個），單結構規模（47 Pb/s 時超過 134,000 個晶片），靜態 XLA 調度帶來的確定性延遲，以及符合 TPU 模型的工作負載的 TCO。

8 號晶片的優點在於：每個晶片的 HBM 容量（216 GB 對比 Rubin 的 288 GB HBM4）、稀疏性（NVIDIA 有 2:4 的硬體路徑，而 Google 沒有）以及生態系廣度（CUDA、cuDNN、TensorRT-LLM 和 PyTorch 優先的服務廣度（CUDA、cuDNN、TensorRT-LLM 和 PyTorch 優先的服務廣度（CUDA、4DNN、TensorRT-LLM 和 PyTorch 優先權仍處於預覽階段）。

這兩個平台都有市場需求。據報道，Meta正在洽談一項價值數十億美元的交易，計劃從2027年開始在其數據中心部署谷歌TPU，並可能最早在2026年就開始租用雲端TPU。同時，Google雲端發布了基於NVIDIA Vera Rubin NVL72架構的A5X實例，單一站點可擴充至80,000萬個Rubin GPU，多站點部署可擴充至960,000萬個GPU。谷歌正在大規模部署這兩項服務。

總結

第八代 TPU 由兩顆晶片組成，而非一顆，其設計初衷是為了應對當前大規模訓練和智慧推理的需求，而非通用 AI 工作負載。 8t 將每個超級節點 (superpod) 的向上擴展能力提升至 9,600 顆晶片，並將每個 Virgo 架構的橫向擴展能力提升至 134,000 顆以上晶片。 8i 則以集體加速晶片取代了 SparseCores，並以 Boardfly 架構取代了 3D 環面，以滿足大規模混合專家服務所需的延遲目標。 NVIDIA 的路線圖，包括 Vera Rubin、Rubin Ultra 和 Kyber，將在 2026-2027 年期間縮小部分差距，但就目前而言，其在向上擴展方面的優勢仍然存在。對於在數十萬顆晶片上運行混合專家模型的尖端實驗室而言，8 代是 Grace Blackwell 的一個可靠替代方案，而 Meta 的討論表明，市場已經開始將這一優勢納入考慮。