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

在 Google Cloud Next 大会上，谷歌发布了其下一代 AI 加速器：用于训练的 TPU 8t“Sunfish”和用于推理的 TPU 8i“Zebrafish”，以及全新的 Virgo 数据中心架构。从谷歌的博客文章来看，这些芯片显然是为“智能体时代”而优化的：在数十万个芯片的规模上训练前沿的混合专家模型，然后以低延迟和极具竞争力的单代币价格目标来服务这些模型。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) 是谷歌自 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操作，以及流水线并行的点对点发送操作。所有这些都与环面的轴线完美契合。

谷歌还保留了自 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，谷歌声称这比 Ironwood 上的同等路径快 10 倍。在规模庞大的前沿场景下，检查点的大小可能达到数百 TB，其区别在于，长达数周的训练运行能否以线速传输检查点和数据集，还是会因为等待主机 I/O 而导致 MXU 流水线停滞。

臂轴子主机

之前的每一代 TPU 都运行在第三方 x86 主机上。而 8t 是首款采用谷歌自研 Axion 处理器（基于 Arm Neoverse V2 架构的 CPU）作为系统头的 TPU。主机 CPU 在 TPU pod 上承担着繁重的任务，并且在规模不断扩大时难度也随之增加：它需要驱动输入流水线、解码和重排数 PB 级数据集、管理 JAX/XLA 控制平面、处理检查点序列化，以及协调数千个芯片上的 SPMD 调度。如果主机出现故障，MXU 就会闲置。

谷歌特别指出，8t 平台上的 Axion NUMA 隔离机制能够有效防止主机端抖动影响到同步的集体训练阶段。每个 pod 包含 9,600 个芯片，即使是单个主机上的微小抖动也会累积成可衡量的吞吐量损失。TPUDirect 通过将主机从批量传输中移除来处理数据路径。Axion 则通过为每个 TPU 分配足够的专用 CPU 带宽来处理控制路径，从而确保预处理不会成为瓶颈。此外，谷歌还提高了第八代平台上每台服务器的物理 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，这使得低延迟的长上下文服务成为可能。

主机端也遵循同样的逻辑。谷歌表示，与 Ironwood 相比，8i 版本中每台服务器上的 Axion 物理主机数量有所增加。推理服务器在每个令牌处理过程中，会花费相当一部分时间用于令牌化、采样逻辑、路由、批处理和代理运行时编排。这些开销与并发量而非模型大小成正比，在代理工作负载产生的请求速率下，主机可能会成为瓶颈。增加每个加速器的主机 CPU 是直接的解决方案。

集体加速引擎

另一个主要的芯片内部改动是采用了 Collectives 加速引擎，它取代了 Ironwood 芯片上的四个 SparseCore 核心。SparseCore 核心负责 MoE 路由和嵌入查找，并配备了专用的收集-分散硬件，因此将它们从推理芯片中移除，意味着 8i 芯片针对的是另一个瓶颈进行了优化。

CAE 解决的瓶颈在于集体延迟。每个解码的令牌都需要参与的芯片进行同步：注意力输出必须全部归约，专家路由元数据必须广播，采样令牌必须传播到下一步。在 GPU 上，这种协调是通过 NCCL 在软件中实现的，NCCL 将集体操作调度为一系列内核启动和网络操作。在 8i 上，CAE 是一个专用的硅芯片，位于与 TensorCores 并排的独立芯片上，在硬件层面处理这些同步原语。

谷歌声称其芯片上的集体延迟比 Ironwood 低 5 倍。在训练规模的批次大小下，这种改进会被计算时间所抵消；集体延迟仅占总延迟的一小部分。但在交互式推理的小批次和短单次运算时间窗口下，集体延迟可能会超过单次运算时间，因此 5 倍的降低会体现在每秒运算次数和单次运算价格上。

8i 也从 3D 环面拓扑结构转向了谷歌称之为 Boardfly 的拓扑结构，这是一种受 Dragonfly 启发的分层拓扑结构，它牺牲了环面集体带宽来换取全链路延迟。我们将在下文中详细探讨 Boardfly。

飞板拓扑

8i 使用的拓扑结构与 8t 不同，因为训练和推理的通信模式不同。

3D 环面非常适合环形集合：每个芯片有六个邻居，数据在环上循环，且没有芯片可以路由任意流量。训练过程主要受这些环面友好模式的影响，这也是 8t 保留环面结构的原因。环面全归约操作完美地映射到单个环面轴上。前沿任务通常将数据并行性放在一个轴上，张量并行性放在另一个轴上，流水线并行性放在第三个轴上。拓扑结构与工作负载相匹配。

为大型 MoE 模型提供服务的推理具有不同的通信模式。专家节点分布在多个芯片上，每个解码的令牌都会触发一次全对全通信：令牌必须到达分散在整个网络中的指定专家节点，并且专家节点的输出必须返回。这不是环路通信，而是任意点对点通信。在一个 1,024 芯片的 3D 环面上，任意两个芯片之间的最坏情况路径需要 16 跳。谷歌为我们详细解释了其中的数学原理：“在 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 拥有足够端口的交换机，将架构中相当一部分流量在两跳内完成，从而消除了脊柱层瓶颈。

在如此大规模的应用中，可靠性工程至关重要，并且高度依赖于谷歌基于MEMS的光路交换机（OCS）。OCS使谷歌能够在作业之间重新配置物理拓扑结构，而无需重新布线，更重要的是，它还能在运行过程中绕过故障芯片或链路。当检测到故障时，OCS可以在几毫秒内重新映射受影响的拓扑结构，从而无需人工干预。亚毫秒级的遥测数据用于自动检测掉链和挂起。快速检测和基于OCS的重新路由相结合，优化了100,000万多个芯片规模下的平均中断间隔时间（MTBI）和平均恢复时间（MTTR），在这个规模下，持续数周的运行中出现故障的概率接近100%。谷歌为8t级Pod设定的97%的吞吐量目标正是基于这一基础设施。同样的OCS技术贯穿于整个TPU堆栈：它在ICI层将立方体拼接成超级Pod，在8i级扩展层连接Boardfly组，并在Virgo层处理Pod间的流量。

在134,000万个芯片的情况下，总计算能力约为1,690 EFLOPS（FP4），或约1.7 ZFLOPS。谷歌表示，该架构支持单个逻辑训练集群中多达一百万个芯片的近线性扩展，但目前的部署尚未达到这一上限。

木星和多数据中心规模

Virgo负责处理数据中心内的东西向加速器流量，但它并非架构的最顶层。Jupiter是谷歌现有的南北向网络架构，目前已发展到第五代，负责处理前端流量以及对分布式存储和计算资源的访问。Jupiter并未在Cloud Next大会上发布；它是第八代架构所依托的现有基础设施。

最新一代的 Jupiter 架构，每个数据中心大楼可提供 13 Pb/s 的双向带宽，可用性高达 99.999%。它采用 Apollo MEMS OCS 交换机，每个 OCS 的功耗约为 108 瓦，而同等规格的电交换机则需要约 3,000 瓦。正是这套架构将谷歌的数据中心与外部世界以及彼此连接起来。

对于超出单个数据中心处理能力和空间限制的训练运行，Jupiter 能够实现跨多个站点的扩展。这种组合采用分层架构：单个 pod 内使用 ICI，同一站点内不同 pod 之间使用 Virgo，站点之间使用 Jupiter。Google 的 Pathways 软件栈可以将跨这些多数据中心域的工作负载作为一个逻辑集群来处理。

单个 Virgo Fabric 的性能约为 1.7 ZFLOPS，是目前已公布的最大 AI 训练集群。多个 Virgo Fabric 通过 Jupiter 连接，可以支持超过一百万个 TPU 芯片，这正是谷歌的目标规模，尽管目前的部署尚未达到这一目标。

产量和利用率

原始浮点运算次数（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（密集型GPU性能15 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 优先的服务堆栈首先在 NVIDIA 上实现；TPU 上的原生 PyTorch 仍处于预览阶段）。

这两个平台都有市场需求。据报道，Meta正在洽谈一项价值数十亿美元的交易，计划从2027年开始在其数据中心部署谷歌TPU，并可能最早在2026年就开始租用云端TPU。与此同时，谷歌云发布了基于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 的讨论表明，市场已经开始将这一优势纳入考量。