这篇文章是SemiAnalysis最新重磅分析报告，国内一些公号好像已经翻译了，但可能他们没有订阅，发的不是完整版。我们把完整版呈现给读者。
TPUv7：谷歌向王者发起挑战
CUDA护城河的潜在终结？Anthropic 超 1GW TPU 采购、TPU 买得越多（你省的 GPU Capex 越多）、下一代 TPUv8AX 与 TPUv8X 对比 Vera Rubin
世界上最好的两个模型——Anthropic 的 Claude 4.5 Opus 和 Google 的 Gemini 3——其大部分训练和推理基础设施都运行在 Google 的 TPU 和 Amazon 的 Trainium 上。现在，Google 正将 TPU 实体出售给多家企业。这是 Nvidia 统治时代的终结吗？
AI 时代的黎明已经到来，重要的是要理解 AI 驱动的软件在成本结构上与传统软件有显著不同。芯片微架构与系统架构在这些创新软件的开发与可扩展性中发挥关键作用。AI 软件运行的硬件基础设施在资本开支（Capex）和运营开支（Opex）中的影响明显更大，从而进一步影响毛利率；这与传统软件时代研发人员成本占比更大的结构完全不同。因此，为了能够部署 AI 软件，企业必须更加重视优化 AI 基础设施。谁在基础设施上占优势，谁在 AI 应用的部署与扩展上也就占优势。
Google 早在 2006 年就开始宣扬为 AI 构建专用基础设施的理念，但真正的“爆点”出现在 2013 年。他们意识到，如果要在任何规模上部署 AI，就必须把现有数据中心数量翻倍。于是开始为 TPU 铺路，并于 2016 年正式投入生产。对比一下 Amazon，在同一年，也意识到他们需要构建自研芯片。Amazon 在 2013 年启动了 Nitro 计划，专注于打造用于优化通用 CPU 计算与存储的定制芯片。两家完全不同的公司，在不同的计算时代与软件范式下把研发方向引向了不同的基础设施优化。
我们长期以来一直认为 TPU 是世界上最优秀的 AI 训练与推理系统之一，与这片丛林的王者 Nvidia 旗鼓相当。两年半前我们写过 TPU 霸权（TPU supremacy）的文章，事实证明这个论断完全正确。
TPU 的结果已经说明一切：Gemini 3 是世界上最好的模型之一，并且是完全基于 TPU 训练的。在这篇报告中，我们将讨论 Google 改变战略、正式将 TPU 商业化卖给外部客户的巨大变化，以及它如何成为 Nvidia 迄今为止最具威胁性的“商用芯片挑战者”。
我们计划：
重新向客户和新读者介绍外部 TPU 客户飞速增长的商业成功，从 Anthropic 延伸至 Meta、SSI、xAI，甚至潜在的 OpenAI……
展示：你买的 TPU 越多，你省下的（Nvidia GPU Capex）就越多！OpenAI 甚至还没部署 TPU，就已经因为竞争威胁让其整体算力 TCO 降低了约 30%
解释 AI 基础设施中的“循环经济”式交易结构。
回顾我们最初的 TPU 深度解析，从硅片到软件层，对 TPU 硬件栈进行复习。
介绍开放软件生态的积极进展，以及 Google 若想真正让 TPU 生态成为 CUDA 护城河的可行挑战者所缺失的关键一环：开源他们的 XLA:TPU 编译器、运行时，以及多 Pod 的 “MegaScaler” 代码。
在付费区里，我们将讨论 Nvidia 护城河的影响，并比较 Vera Rubin 与下一代 TPUv8AX / 8X（代号 Sunfish / Zebrafish）。
也会讨论对 Nvidia 的长期威胁。
首先，让我们看看这条新闻对生态的影响。TPU 的表现显然已经引起竞争对手的注意。Sam Altman 承认 OpenAI 前方将有“rough vibes”（粗糙/不太妙的氛围），因为 Gemini 抢走了 OpenAI 的风头。Nvidia 甚至发布了一条安抚性质的公关声明，告诉大家继续保持冷静——我们仍然遥遥领先。
我们理解 Nvidia 的紧张。这几个月对 Google DeepMind、GCP 和 TPU 集团来说可谓是连环胜利：TPU 产量预期大幅上修、Anthropic 超 1GW TPU 建设、SOTA 模型 Gemini 3 与 Opus 4.5 均在 TPU 上训练、以及正在瞄准（Meta、SSI、xAI、OAI）的一长串潜在客户。这推动 Google 与 TPU 供应链实现巨大重估，而 Nvidia GPU 供应链却遭到挤压。虽然 Google 与 TPU 供应链的“突然崛起”让很多人措手不及，但 SemiAnalysis 的机构级读者在过去一年里其实已经提前预见这些趋势。
另一项让 Nvidia 处于防御姿态的原因，是越来越多的质疑者认为公司正在支撑一个“循环经济”。他们认为 Nvidia 通过向烧钱的 AI 初创公司投资，把钱从一个口袋挪到另一个口袋，只不过多走了几步。我们认为这种观点并不准确，但它显然已经触动了 Nvidia 内部的神经。财务团队发布了一份详细回应，全文如下。
我们认为更现实的解释是：Nvidia 希望保护自己在基础模型实验室的主导地位，所以选择以股权投资的方式取代降价。降价会压低毛利率，并在投资者中引发广泛的恐慌。下面，我们将概述 OpenAI 与 Anthropic 的安排，以说明前沿实验室是如何通过购买（或威胁购买）TPU 来降低 GPU 的 TCO。
OpenAI 甚至还没有部署 TPU，却已经在其整个实验室范围内的 Nvidia 集群上节省了约 30%。这表明 TPU 在性能/TCO 上的优势非常强大，以至于你在真正开启 TPU 之前就已经获得了收益。
我们的加速器产业模型、数据中心产业模型和核心研究订阅者在这些消息发布并成为市场共识之前，就已经看到行业影响。八月初，我们向加速器模型客户分享：我们看到 Broadcom / Google TPU 针对 2026 年的供应链订单出现了大幅上修。我们还透露，订单增加的原因是 Google 将开始向多个外部客户出售系统。九月初，我们进一步披露其中一个大型外部客户将是 Anthropic，需求至少为 100 万颗 TPU。这个消息在十月被 Anthropic 和 Google 正式确认。十一月七日，我们又提前几周点名 Meta 将成为大型 TPU 客户。此外我们也讨论了其他客户。
因此，我们的机构客户在 AI 交易史上最大的一次“表现分化”来临前已获得充分预警。SemiAnalysis 是第一家披露所有这些洞见的机构，因为没有其他研究机构能够从晶圆厂、供应链、数据中心一路把线索串到模型实验室。
让我们进入这笔交易本身。
Google 大规模推进 TPU 外部化与 Anthropic 交易
TPU 硬件栈长期以来都能与 Nvidia 的 AI 硬件抗衡，但主要用于 Google 内部工作负载。典型的 Google 风格，即便在 2018 年向 GCP 客户开放 TPU 之后，也从未真正将其完全商业化。这种情况正在改变。过去几个月中，Google 动员完整技术栈，开始通过 GCP 或作为商用硬件卖家来向外部客户提供完整 TPU 系统。这个搜索巨头正利用其强大的内部硅设计能力，成为真正差异化的云服务提供商。此外，这与大客户 Anthropic 希望摆脱对 Nvidia 的依赖、实现供应链多元化的战略高度一致。
Anthropic 的这笔交易是 Google 推动 TPU 外部化的一个重要里程碑。我们了解到，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 的分配：
1、第一阶段交易包含 40 万颗 TPUv7 Ironwoods，价值约 100 亿美元的成品机架，由 Broadcom 直接卖给 Anthropic。Anthropic 是 Broadcom 最近一次财报电话会议中提到的第四个客户。Fluidstack（一个 ClusterMax 金牌评级的 Neocloud 提供商）将负责现场部署、布线、老化测试、验收测试，以及远程维护工作，因为 Anthropic 将物理服务器的管理外包出去。数据中心基础设施将由 TeraWulf（WULF）和 Cipher Mining（CIFR）提供。
2、剩余的 60 万颗 TPUv7 将通过 GCP 以租赁方式提供，我们估算这笔交易的 RPO 为 420 亿美元，占据了 Google 在第三季度报告中 490 亿美元 GCP 积压订单增长的大部分。
3、我们认为与 Meta、OAI、SSI 和 xAI 的新增交易，在未来几个季度可能为 GCP 带来更多 RPO + 直接硬件销售。
尽管内部与外部需求都极为旺盛，Google 的 TPU 部署速度仍然无法达到其目标。即便相比仍需讨好 Jensen 的其他超大规模企业，Google 对硬件供应链有更高的控制力，但其主要瓶颈是电力。
其他超大规模企业在扩建自有场地并获得大量托管容量方面进展迅速，而 Google 的动作更慢。我们认为核心问题出在合同与行政流程。每一家新的数据中心供应商都需要一份主服务协议 MSA，这些是涉及数十亿美元、跨多年期的合同，自然会带来大量官僚流程。然而，Google 的流程尤其缓慢，从最初接触到签署 MSA 通常要长达三年。
Google 的替代方案对希望转向 AI 数据中心基础设施的 Neocloud 提供商与加密矿企具有重大影响。Google 并不直接租赁，而是提供信用担保，即一种表外“IOU”，在 Fluidstack 无法支付数据中心租金时承担付款义务。
像 Fluidstack 这样的 Neocloud 企业更敏捷灵活，因此更容易与“转型后的加密矿企”等新型数据中心供应商合作。这一机制是我们对加密挖矿行业保持看多观点的关键原因之一——特别是在今年年初我们指出多家企业包括 IREN 和 Applied Digital 的投资机会时，当时股价远低于现在。
矿工的机会基于一个简单事实：数据中心行业正面临严重的电力短缺，而加密矿工已经通过其 PPA 与现有输电基础设施掌握了大量电力容量。我们预计未来数周与数季度会有更多类似协议达成。
Google 如何重塑 Neocloud 市场
在 Google / Fluidstack / TeraWulf 交易之前，我们从未见过在 Neocloud 市场中仅以一份表外“IOU”（欠条式担保）达成的交易。该交易之后，我们认为它已经成为新的事实标准融资模板。这解决了 Neocloud 在争取数据中心容量、扩张业务时的一项核心难题：
GPU 集群的经济寿命通常是 4–5 年。
而大型数据中心租约通常是 15 年以上，典型回本周期约 8 年。
这种期限错配让 Neocloud 与数据中心供应商在为项目筹集资金时极其困难。但随着“超大规模厂商背书”（hyperscaler backstop）的兴起，我们认为融资问题已经得到解决。我们预期 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。
两年半前，我们写过 Google 计算基础设施的优势。当时即便从纸面规格上 TPU 的硅片落后于 Nvidia，但 Google 的系统级工程能力让 TPU 整体栈在性能与成本效率上都能与 Nvidia 匹敌。
当时我们就指出：“系统比微架构更重要”，过去两年进一步巩固了这一观点。Anthropic 的巨大 TPU 订单正是对该平台技术实力的直接验证。
GPU 生态自身也在前进。Nvidia 的 GB200 是一次重大跨越，推动 Nvidia 向“完整系统公司”转变，而不仅仅是设计芯片封装。
谈到 GB200 在机架级互连中的巨大创新，有一点常被忽视：Google 自 2017 年的 TPU v2 起就在单机架与跨机架大规模扩展 TPU！在本文后面部分，我们将深入介绍 Google 的 ICI 扩展网络——唯一真正能与 Nvidia NVLink 抗衡的技术。
Google 最近的 Gemini 3 现在被视为最新的前沿 LLM。与早期所有版本一样，它完全在 TPU 上训练。这一结果提供了 TPU 能力与 Google 基础设施优势的直接证据。
如今的讨论往往聚焦在推理与后训练硬件，但预训练前沿模型仍是 AI 硬件中最难、最耗资源的任务。TPU 平台已经在这一点上通过了最关键的考验。
这与竞争对手形成鲜明对比：OpenAI 的核心研究人员自 2024 年 5 月 GPT-4o 以来，没有成功完成过一次全规模、面向新前沿模型的完整预训练运行，这凸显了 Google TPU 集群跨越的重大技术门槛。
新模型的一大亮点是工具调用与 agent 能力的显著提升，尤其在长周期、具有经济价值的任务上。Vending Bench 是一种评估方法，用来衡量模型在长期经营中能多好地运行一个模拟自动售货机业务，而 Gemini 3 完全击溃了竞争对手。
此次发布带来的不仅是能力提升，还有新产品。Antigravity——来自被收购团队 Windsurf 前 CEO Varun Mohan 的产品——成为 Google 给 OpenAI Codex 的回应，正式把 Gemini 带入“氛围编码 + token 吞噬大战”之中。
对于一个核心业务并非硬件、或者说曾经不是硬件的公司来说，能悄然进入并在最具挑战性的硬件问题上建立性能领先，是极为惊人的成就。
微架构仍然重要：Ironwood 逼近 Blackwell
“系统比微架构重要”的推论是：尽管 Google 在系统与网络设计上不断推进边界，TPU 硅片本身过去并不算激进。但从最新世代开始，TPU 的硅片已取得巨大进步。
Google 一直以来在硅片设计上比 Nvidia 更保守。历史上 TPU 的峰值理论 FLOPs 与内存规格显著低于对应代的 Nvidia GPU。
原因有三：
第一，Google 内部极度重视基础设施的 RAS（可靠性、可用性、可维护性）。Google 宁愿牺牲绝对性能，也要确保硬件运行时间最大化。把硬件推到极限会导致更高的硬件死亡率，而这会在系统停机与热备件方面带来真实的 TCO 成本。毕竟，不能用的硬件，其性能相对于 TCO 是“无限成本”。
第二，直到 2023 年之前，Google 的主要 AI 工作负载是推荐系统模型，用于其核心搜索与广告业务。RecSys 工作负载的算术强度远低于 LLM，这意味着相对每一比特数据的转移需要更少的 FLOPs。
第三，与被营销的“峰值理论 FLOPs”数字本身相关，以及这些数字如何被操纵。像 Nvidia 与 AMD 这样的商用 GPU 供应商必须向外部市场展示尽可能好的性能规格，这激励它们把 FLOPs 数字尽量“抬到高处”。但实际上这些数字是无法持续的。而 TPU 主要面向内部使用，外部夸大指标的压力小得多。这将带来重要影响，我们稍后讨论。宽松地说，就是 Nvidia 更擅长 DVFS，因此乐于报告高峰值规格。
进入 LLM 时代之后，Google 的 TPU 设计理念出现了明显变化。两个最新、在 LLM 之后设计的世代——TPUv6 Trillium（Ghostlite）和 TPUv7 Ironwood（Ghostfish）——反映了这一点。从图中可以看到 TPUv4、v5 的计算吞吐明显低于当时的 Nvidia 旗舰。TPUv6 在 FLOPs 上几乎追平 H100/H200，但比 H100 晚了两年。TPU v7 的差距进一步缩小，服务器仅在之后几个季度即可供应，同时提供几乎相同的峰值理论 FLOPs。
这些性能提升的驱动因素是什么？部分原因是 Google 开始在量产爬坡阶段公布 TPU，而不是等下一代部署后才公布。
此外，TPUv6 Trillium 尽管使用与 TPUv5p 相同的 N5 工艺、相似硅面积，却能在功耗更低的情况下提供高达 2 倍的峰值理论 FLOPs！Google 把每个脉动阵列的尺寸从 128×128 翻倍到 256×256，而这正是计算能力提升的来源。
Trillium 也是最后一代“E”（lite）SKU，只有两组 HBM3。虽然 Trillium 在计算性能上追上 Hopper，但在内存容量与带宽上远不及 H100/H200，只有 2 叠 HBM3，而后者分别有 5 和 6 叠 HBM3/HBM3E。这使得 Trillium 对新手来说极其难用，但只要你能正确 shard 模型、吃满这些廉价 FLOPs，其性能/TCO 比率是无人能敌的。
TPU v7 Ironwood 是下一代迭代，Google 在 FLOPs、内存与带宽上几乎完全追上对应代 Nvidia 旗舰 GPU，尽管其普遍供应时间比 Blackwell 晚一年。与 GB200 相比，FLOPs 和内存带宽只有轻微差距，容量相同（8-Hi HBM3E），当然与拥有 288GB 12-Hi HBM3E 的 GB300 相比仍有显著不足。
理论峰值性能是一回事，真正重要的是 现实中的 TCO 性能比。
Google 通过 Broadcom 采购 TPU，需要支付不小的利润，但这仍显著低于 Nvidia 在 GPU、CPU、交换机、NIC、系统内存、布线与连接器等整机上的利润。从 Google 的角度来看，在完整 3D Torus 配置中，每颗 Ironwood 芯片的综合 TCO 比一台 GB200 服务器低 约 44%。
这完全抵消了其在峰值 FLOPs 与峰值内存带宽上约 10% 的不足。以上是从 Google 的采购价格视角出发。
那当 Google 在其上叠加利润后，外部客户的情况如何？我们假设，在 Google 对外出租 TPU v7 并赚取一定利润的情况下，其每小时 TCO 依然可以比 GB200 低约 30%，比 GB300 低约 41%。我们认为这反映了 Anthropic 通过 GCP 获得的实际定价。
为什么 Anthropic 押注 TPU
比较理论 FLOPs 只能讲一部分故事。真正重要的是有效 FLOPs，因为峰值数据在真实世界负载中几乎从未被完全达到。
在实际中，Nvidia GPU 在考虑通信开销、内存 stall、功率限制以及其他系统效应后，通常只能实现其理论峰值的一小部分。一个训练任务的经验法则是约 30%，但利用率严重受工作负载变化影响。大量差距来自软件与编译器效率。Nvidia 在这方面的优势来自 CUDA 护城河，以及默认附带的开源库生态，帮助工作负载更高效率运行，实现更高的实际 FLOPs 与带宽。
TPU 的软件栈并不如 GPU 易用，不过现在正在改善。在 Google 内部，TPU 拥有优秀但不对外开放的内部工具，使得开箱性能较弱。然而这只影响小规模且/或懒惰的用户，而 Anthropic 两者都不是。
Anthropic 拥有强大的工程资源，以及能够理解 TPU 栈与自家模型架构的前 Google 编译器专家。他们可以投资构建自定义 kernel 来推动 TPU 的高效率。因此他们能实现明显更高的 MFU，以及更好的 $/PFLOP 性能。
我们认为，尽管 TPU 宣传的峰值 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 操作 × ALU 数量 × 每秒周期数，即频率）。
还有其他技巧，例如用全 0 tensor 运行 GEMM，因为 0×0=0，晶体管无需从 0 切换到 1，从而降低功耗。但真实世界中不会将全 0 tensor 相乘。
当我们把更低 TCO 与更高的有效 FLOPs 利用率结合起来，从 Google 的视角，每单位有效 FLOP 的成本远低得多。以约 15% MFU 为与 GB300 在 30% MFU 时持平的点。意味着即使 Google（或 Anthropic）只达到 GB300 FLOPs 利用率的一半，他们依然不吃亏。当然，有 Google 的顶尖编译器团队，以及对自家模型的深刻理解，他们在 TPU 上实现 40% MFU 是完全可能的。这将使有效训练 FLOP 成本下降约 62%。
然而，当考察 60 万租用 TPU 时，把 Anthropic 支付的更高 TCO（即包含 Google 叠加利润）纳入考量，我们估计 Anthropic 支付给 GCP 的成本是 每 TPU 小时 1.60 美元，缩小了 TCO 优势。我们认为 Anthropic 可以在 TPU 上实现 40% MFU，因为其高度专注性能优化，以及 TPU 宣传 FLOPs 更为真实的特性。相比 GB300 NVL72，这使 Anthropic 的每有效 PFLOP TCO 降低了惊人的约 52%。
当 Anthropic 提取 MFU 只有 19% 时，其每单位有效 FLOP 的 TCO 才会与 GB300 基线持平。意味着 Anthropic 可以承受相对 GB300 相当大的性能短板，但训练 FLOPs 的性能/TCO 仍能与 Nvidia 系统基线相同。
FLOPs 不是性能的全部，尤其对于推理，内存带宽极为重要，特别是在带宽密集的 decode 步骤中。TPU 在每单位带宽成本上也显著低于 GB300。在 16MB–64MB 的小消息规模（如载入单层专家）下，有证据显示 TPU 的内存带宽利用率甚至高于 GPU。
所有这些意味着训练与服务一个模型时计算更高效。Anthropic 的 Opus 4.5 发布继续保持对编码的聚焦，刷新了 SWE-Bench 纪录。最大惊喜是 API 价格下降约 67%。价格下降叠加模型相比 Sonnet 的更低冗余与更高 token 效率（达到 Sonnet 最佳分数所需 token 少 76%，要超 4 分则少 45%），意味着 Opus 4.5 是编码场景最佳模型，并且能有效提高 Anthropic 的实际 token 定价，因为 Sonnet 目前占 token mix 的 90% 以上。
Google 在利润率上的“穿针引线”
对外定价方面，Google 需要在自身盈利与为客户提供具竞争力的产品之间穿针引线。我们估计的 Anthropic 定价位于外部定价区间的下侧。对于像 Anthropic 这样的旗舰客户，既能在软件与硬件路线图上提供宝贵反馈，又会下超大订单，自然会获得更优定价。
虽然 Nvidia 令人咋舌的 **4 倍加价（约 75% 毛利）**提供了巨大定价空间，但 Broadcom 抢走了不少氧气。作为 TPU 的共同设计方，Broadcom 在硅片（系统 BOM 中最大部分）上赚取高额利润。然而，这仍为 Google 留下大量空间来获得完全可以接受的高利润。
从 GCP–Anthropic 的交易对比其他大型基于 GPU 的云交易可以看出这一点。注意这是看租用的 60 万颗 TPU；剩余 40 万颗 TPUv7 由 Anthropic 直接购买。
在这些假设下，TPUv7 的经济性显示，其 EBIT 利润率优于我们观察到的其他大型 GPU 云交易，只有 OCI–OpenAI 略接近。即使有 Broadcom 在芯片 BOM 中叠加的高利润，Google 在 TPU 上仍能实现远高于 GPU 的利润与回报。这正是 TPU 栈使得 GCP 成为真正差异化 CSP 的原因。而 Azure 这类 ASIC 项目受挫的公司，只能在出租商用硬件的业务中获得平庸回报。
TPU 系统与网络架构
我们已经讨论了 TPU 与 Nvidia GPU 的对比，重点关注单芯片规格和不足之处。现在回到系统讨论，这正是 TPU 能力真正开始分化的地方。TPU 最显著的特性之一，就是其通过 ICI 协议实现的超大规模扩展世界规模（world size）。一个 TPU pod 的世界规模达到 9216 颗 Ironwood TPU，而从 TPUv2 时代起，大型 pod 一直是 TPU 的特性，规模最高可扩展到完整的 256×1024 芯片集群。
让我们从 rack 级别开始，这是每个 TPU superpod 的基本构建单元。
Ironwood 机架架构
在过去的几代产品中，TPU 机架的设计基本保持一致。每个机架包含：16 个 TPU Tray、16 个或 8 个 Host CPU Tray（取决于散热配置）、一台 ToR 交换机、电源模块，以及 BBU。
每个 TPU tray 包含一块带有 4 个 TPU 封装的 TPU 板。每个 Ironwood TPU 配备 4 个用于 ICI 连接的 OSFP cage，以及 1 个用于连接 Host CPU 的 CDFP PCIe cage。
自 2018 年 TPU v3 开始，Google 一直在部署液冷 TPU 机架，但中间仍有一些 TPU 世代是设计为空气冷却。液冷机架与风冷机架的主要区别在于：风冷机架采用 2 TPU tray 对 1 CPU tray 的比例，而液冷机架采用 1:1 的比例。
TPU 液冷的一项创新设计是：冷却液流量由阀门主动调控。这样可以更高效散热，因为流量可以根据每颗芯片在任意时刻的工作量动态调整。Google TPU 还长期采用垂直供电方式，即 VRM 模块位于 PCB 板的另一侧，这些 VRM 模块也需要冷板进行散热。
总体来看，TPU 机架设计比 Nvidia Oberon NVL72 的设计简单得多。后者密度更高、并使用背板连接 GPU 至扩展交换机。TPU tray 之间的扩展连接全部通过外部铜缆或光模块实现，会在下方的 ICI 部分解释。TPU tray 与 CPU tray 之间的连接同样采用 PCIe DAC copper cable。
Inter-Chip Interconnect（ICI）——扩展 Scale-Up World Size 的关键
Google 用于 TPUv7 的 ICI scale-up 网络的基本构建单元是一个 4×4×4 的三维 Torus，包含 64 颗 TPU。
每个 4×4×4 立方体对应一个实际机架，容纳 64 颗 TPU。这是理想尺寸，因为所有 64 颗 TPU 都可以通过电连接互相连通，并且仍然能放进一个物理机架中。
TPU 以三维 Torus 结构互连，每颗 TPU 共连接 6 个邻居——在 X、Y、Z 三个轴上各有两个逻辑相邻的 TPU。
每颗 TPU 永远通过 PCB 走线连接到其他 2 颗 TPU；但根据其在 4×4×4 立方体中的位置，会使用 DAC copper 或光模块与另外 4 个邻居互连。
4×4×4 立方体内部的连接使用铜缆；而外部连接（包括绕回另一侧的 wrap-around 连接、以及连接到其他 4×4×4 立方体）使用光模块和 OCS。
在下图示例中，由于这是一个 3D Torus：位于 Z+ 面的 TPU (2,3,4) 使用一个 800G 光模块并通过 OCS，wrap-around 回到 Z− 面对应位置的 TPU (2,3,1)。
如前所述，除了通过 PCB traces 永远连接的两个邻居外，TPU 会根据其在立方体中的位置，通过 DAC、光模块或两者混合连接另外 4 个邻居。
位于立方体内部的 TPU：用 4 根 DAC
位于立方体面的 TPU：3 根 DAC + 1 个光模块
位于立方体边缘的 TPU：2 个光模块 + 2 根 DAC
位于立方体角落的 TPU：3 个光模块 + 1 根 DAC
判断一颗 TPU 使用多少光模块的方法很简单：看它有多少侧面“面向外部”。
上图与下表总结了 TPU 在各位置的数量，并可用于推导 TPUv7 的 attach ratio，为 每颗 TPU 平均 1.5 个光模块。
这些光模块连接到 Optical Circuit Switch（OCS），使得 4×4×4 立方体之间得以互连——下一节会展开。
ICI 的光学设计（Optics for ICI）
Google 采用软件定义网络方式，通过 Optical Circuit Switch（OCS）管理网络路径。
一个 NxN OCS 本质上是一座巨型火车站，有 N 条入轨、N 条出轨。任何进站的列车都可以被切换到任何一条出轨线上，但必须在车站进行重新配置。列车不能被“回环”到另一条入轨线上，只能被路由到出轨之一。
这种方式的优势在于，网络可以根据任务将 TPU 分片，形成较小的逻辑 TPU slice，而无需总是使用 ICI 层理论最大规模的 9,216 颗 TPU。通过在大集群内重路由 ICI 路径绕过故障点，可以提升集群可用性。
与电子交换机（EPS）如 Arista Tomahawk 5 不同，EPS 有固定总带宽，再分配到多个端口；而 OCS 的任意端口可接任意光纤带宽。OCS 相较 EPS 延迟更低，因为光信号进入 OCS 后只是在输入端口与输出端口之间反射。而 EPS 则必须在进入交换机时将光信号转换为电信号——这是 OCS 通常比 EPS 更节能的关键原因之一。EPS 可以把数据包从任意端口路由到任意端口，而 OCS 只能将“输入端口”路由到任意一个“输出端口”。
OCS 端口只能路由单根光纤，这对标准 duplex 光模块造成挑战，因为其带宽分布在多根光纤上，减少了 OCS 的有效 radix 与带宽。
为解决该问题，FR 光模块用于把所有波长整合到一根光纤上，由此连接到 1 个 OCS 端口。
Apollo Project 通过两步实现创新：
将 8 个波长（每个 100G lane 一个波长）通过 CWDM8 复用，在 单对光纤 上传输 800G（否则需要 8 对光纤）。
在 WDM 模块上集成光环行器，使其支持全双工数据流，将需求从 1 对光纤进一步缩减为 单根光纤。
光环行器通过在模块侧将 Tx 和 Rx 光纤合并成单根光纤并送向 OCS，从而形成双向链路。
将多个 64 TPU 立方体连接在一起
Google 的 ICI scale-up 网络的独特之处在于，它允许将多个由 64 颗 TPU 组成的 4×4×4 立方体，以三维 Torus 结构互连，从而形成巨大的 world size。TPUv7 的最大 world size 为 9,216 颗 TPU，但目前，Google 支持将 TPU 配置成从 4 颗 TPU 到 2,048 颗 TPU 之间的多种不同 slice 大小。
虽然 Google 可以创新性地实现高达 9,216 TPU 的极大规模集群，但在任何时间点上，将训练任务运行在超过大约 8,000 TPU 的更大 block 上，其收益会下降。这是因为更大的 block 更容易发生故障和中断，从而降低 slice 可用性——slice 可用性定义为 ICI 集群能够形成连续三维 Torus slice 的时间占比。
对于完全能放进单个 4×4×4 立方体的 slices，我们只需利用机架内部的 copper interconnects，以及立方体面/边/角上的光模块进行 wrap-around（如有必要），即可在该立方体中 carve 出这些 slices。
要理解 wraparound（环回）与跨立方体连接如何实现，我们先从一个 4×4×4 拓扑中创建 64 TPU slice 的方式开始。我们可以用一个物理 64 TPU 机架对应的 64 TPU 立方体来构建这个拓扑。立方体内部的 8 颗 TPU 可以通过所有 6 个方向使用铜缆完全互连。如果 TPU 在某个方向上没有内部邻居，它会 wrap-around 到立方体另一侧。例如 TPU (4,1,4) 在 Z+ 方向没有内部邻居，因此会使用一个 800G 光模块连接到 Z-axis 的 OCS，由 OCS 配置，将其连接到 Z− 面的 TPU (4,1,1)。在 Y− 方向，TPU (1,1,1) 会使用一个光模块连接到 Y-axis 的 OCS，从而与 Y+ 面的 TPU (1,4,1) 相连，依此类推。
4×4×4 立方体的每个面都通过 16 个 OCS 连接——每个面上的每颗 TPU 对应一个 OCS。
例如，在下图中，在 X+ 面上，TPU (4,3,2) 连接到 OCS X,3,2 的输入侧。OCS X,3,2 的输入侧也会连接 9,216 TPU 集群中 全部 144 个 4×4×4 立方体上 相同 index 的 TPU (4,3,2)。然后 OCS X,3,2 的输出侧将连接到集群中所有立方体的 X− 面上的相同 TPU index——即所有 144 个立方体的 TPU (1,3,2)。下图展示了：立方体 A 的 X+ 面上的 16 颗 TPU 如何通过 16 个 OCS 连接到立方体 B 的 X− 面上的 16 颗 TPU。
这些连接允许任意立方体的“+”面连接至任意立方体的“−”面，从而在形成 slices 时实现立方体之间完全可互换性（fungibility）。
有两个约束需要指出。
第一，一个立方体某一面上的某个 TPU Index 绝不可能直接连到不同 Index 的 TPU——例如 TPU (4,3,2) 永远不能连到 TPU (1,2,3)。
第二，OCS 本质上是一个 patch panel——连接在 OCS 输入侧的 TPU 不能“loop back”接到输入侧的另一颗 TPU。例如 TPU (4,3,2) 不能连到 TPU (4,3,3)。因此，“+”面上的 TPU 永远不能连到其他立方体的“+”面，“−”面同理不能连到其他立方体的“−”面。
构造更大的拓扑：4×4×8现在我们构造一个更大的 4×4×8 拓扑。此时，我们沿 Z 轴把两个 64 TPU 的 4×4×4 立方体连接起来。在这种情况下，OCS 会重新配置 TPU (4,1,4) 所连接的光端口，使其不再 wrap-around 回 TPU (4,1,1)，而是连接到 TPU (4,1,5)。以此类推，在两个立方体的 Z− 与 Z+ 面上分别有 16 个光连接，总共形成 64 根光纤连接至 16 个 Z-Axis OCS。
需要提醒读者：下图中的立方体 A 与 B 并不一定物理相邻。它们是通过 OCS 连接的，因此在数据中心中可以位于完全不同的位置。
更大的拓扑：16×16×16（4,096 TPU）现在我们进入更大规模拓扑——16×16×16，共 4,096 TPU。在此拓扑中，需要使用 48 个 OCS 来连接 64 个 64-TPU 立方体。下图中，每个多颜色立方体代表一个 64-TPU 的 4×4×4 立方体。以右下角的立方体为例——它通过 OCS 与 Y 轴方向上的相邻立方体相连。
9,216 TPU 的最大 world size 是由 144 个 4×4×4 立方体构建的。每个立方体需要 96 条光连接，总端口需求是 13,824 个。将 13,824 除以 288（每个 OCS 的 144 输入端口 + 144 输出端口），说明要支持最大 world size 需要 48 台 144×144 的 OCS。
为什么使用 Google 的 ICI 三维 Torus 架构？
那么，Google 这个独特的 ICI scale-up 网络，除了可以画无数炫酷的立方体图之外，有什么厉害之处？
1. World Size（规模）
最明显的优势是 TPUv7 Ironwood 支持高达 9,216 TPU 的 world size。虽然完整 9,216-TPU slice 因 goodput 下降而不常使用，但由数千 TPU 组成的 slices 非常常见。
这远大于商用加速卡市场中典型的 64 或 72 GPU world size，也超过其他定制芯片供应商的规模。
2. 可重构性与完全可互换（fungibility）
使用 OCS 意味着网络拓扑可以被重构，从而支持大量不同拓扑——理论上可达数千种。Google 文档中列出了 10 种常见组合（此段前的图），但仅是常见的三维切片形状，还有更多可能性。
即使相同大小的 slices，也可被重构为不同拓扑。在下面简单例子中的 Twisted 2D Torus，通过跨越连接到不同 X 坐标的 index，而不是相同 X 坐标，可以减少最坏情况下的 hops 数量与最坏情况下的 bisection 带宽，从而提高 all-to-all collective 吞吐。TPUv7 会在 4×4×4 立方体层面进行 twist。
可重构性也带来了广泛的并行策略组合。在 64 或 72 GPU world size 中，平行方式通常受限于 64 的因子。但 ICI scale-up 网络允许构建匹配数据并行、张量并行、流水线并行任意组合的拓扑，可能性极为丰富。
因为 OCS 允许任意立方体的“+”面连接任意立方体的“−”面，立方体之间完全可互换。Slices 可以由任意立方体组合构成。如果发生故障或用户需求变化，都不会阻碍新拓扑 slice 的形成。
更低成本：
Google 的 ICI 网络相比大多数基于交换机的 scale-up 网络成本更低。尽管由于使用环行器（circulator），FR 光模块本身略贵，但 mesh 网络减少了所需交换机和端口的总体数量，并消除了交换机之间互联带来的成本。
低时延与更好的局部性：
TPU 之间使用直连链路意味着：对于物理上彼此接近，或被重配置为直接互连的 TPU，可以实现更低的时延。彼此接近的 TPU 也拥有更好的数据局部性。
Datacenter Network（DCN）——扩展到 9,216 TPU 之外
Datacenter Network（DCN）是一个独立于 ICI 的网络，兼具典型后端与前端网络的角色。它连接的范围更大——在 TPUv7 集群中可覆盖 147k 颗 TPU。
正如我们在此前关于 Mission Apollo 的文章中所讨论的，Google 提出用 Paloma Optical Circuit Switch（OCS）取代传统“Clos”架构中 spine 层的 Electronic Packet Switch（EPS），Google 的 DCN 包含一个光交换的 Datacenter Network Interconnect（DCNI）层，将多个聚合块连接起来，每个聚合块再连接多个 9,216 TPU 的 ICI 集群。
在 2022 年，Google 的 Apollo 项目提出一套 DCN 架构，描述了在 pod 规模为 4,096 TPU 的 TPUv4 pods 中使用 136×136 OCS 交换机的设计。DCNI 层的 OCS 被组织成 4 个 Apollo 区，每个区最多包含 8 个机架、每个机架 8 台 OCS，总计 256 台 OCS。
对于 Ironwood，为在同一网络中支持最多 147k TPUv7，我们推测：与其增加 OCS 的数量，不如将单台 OCS 的端口数量几乎翻倍。
下图示例展示了一种 Ironwood DCN 设计：使用 32 个机架承载 256 台 300×300 OCS 交换机。假设各聚合块 spine 层之间不存在 oversubscription，则 DCN 中最多可以连接 16 个 ICI pod：4 个聚合块，每个聚合块连接 4 个 ICI pod，总计 147,456 颗 TPU。
DCNI 层负责连接这 4 个聚合块——在下图中被描绘为最上层。与 ICI 一样，这里使用 FR 光模块连接 OCS，以最大化每台 OCS 的端口带宽。
虽然当前的 Ironwood 集群可能只有 1 或 2 个聚合块，但 Google DCN 独特的架构允许在无需大量重新布线的情况下，把新的 TPU 聚合块加到网络中。
通过在 DCNI 层使用 OCS，DCN fabric 的规模可以渐进式扩展，网络也可以“重条带化”（re-striped）以支持新的聚合块。此外，还可以在不改变 DCN 层总体结构的前提下，升级聚合块的带宽。这使得升级既有聚合块的链路速率成为可能，而无需改变网络的基本架构。当然，fabric 的扩张不可能无限进行——规模到达某个程度后，重新布线将变得不可管理。
TPU 软件战略——又一次巨大转向
传统上，TPU 的软硬件团队主要面向内部。这带来了一个好处：他们不必承受市场团队“虚标理论 FLOPs”的压力。
仅面向内部的另一个好处是：TPU 团队可以高度优先满足内部需求、优化内部工作负载。缺点是：他们几乎不关心外部客户或外部工作负载。TPU 生态中的外部开发者数量远低于 CUDA 生态。这是 TPU ——以及所有非 Nvidia 加速器——的主要弱点之一。
Google 现在已经针对外部客户调整了软件战略，并对 TPU 团队的 KPI 和其对 AI/ML 生态的贡献方式做出了重大改变。我们将讨论两项重要变化：
对 PyTorch TPU“原生”支持的大规模工程投入
对 vLLM / SGLang TPU 支持的大规模工程投入
通过观察 Google 各个 TPU 软件仓库贡献数量的变化，可以清楚看到这个“外部化战略”。我们可以看到，从 3 月开始，vLLM 的贡献明显增加。到了 5 月，官方创建了 “tpu-inference” 仓库，作为 vLLM 的 TPU 统一后端，此后相关活动便非常频繁。
传统上，Google 只为 JAX / XLA:TPU 栈（以及已经 RIP 的 TensorFlow/TF-Mesh）提供一等公民支持，而把 PyTorch on TPU 视作二等公民。它依赖 PyTorch/XLA 进行 lazy tensor 图捕获，而不是提供一等公民的 eager 执行模式。此外，它也不支持 PyTorch 原生分布式 API（torch.distributed.*）及原生并行 API（DTensor、FSDP2、DDP 等），而是依赖一些“树外”（out-of-tree）的 XLA SPMD API（如 torch_xla.experimental.spmd_fsdp、torch_xla.distributed.spmd 等）。
这为习惯于 PyTorch CUDA 原生后端、又想迁移到 TPU 的外部用户带来了糟糕的非原生体验。
在 10 月，Google 的 “Captain Awesome” Robert Hundt 在 XLA 仓库中低调宣布：他们将从非原生 lazy tensor 后端转向“原生”的 TPU PyTorch 后端，该后端将默认支持 eager 执行，并与 torch.compile、DTensor、torch.distributed 等 API 集成。他们将通过 PrivateUse1 TorchDispatch key 来实现。这主要是为 Meta 而做，后者重新对 TPU 产生兴趣，同时不想迁移到 JAX。它也将让那些喜欢 PyTorch 而不喜欢 JAX 的人更容易使用 TPU。
此前在 2020–2023 年间，Meta FAIR 的几个团队大量使用 PyTorch XLA on TPU，但整体采用率并不高，因此 Meta 管理层在 2023 年取消了合同。PyTorch XLA on TPU 并不是一种愉快体验。那时 Meta FAIR 的 GCP TPU 甚至是通过 SLURM 运行，而非使用 GKE / Xmanager / Borg 等 TPU 栈中典型的调度工具。
新的 PyTorch <> TPU 集成将会为习惯在 GPU 上使用 PyTorch 的 ML 科学家提供更平滑的迁移路径，让他们能够迁往 TPU 上的 PyTorch，并利用 TPU 上更高的性能/TCO。
Pallas 是一个用于为 TPU 编写自定义 kernel 的内核创作语言（类似 cuTile、Triton 或 CuTe-DSL）。Meta 与 Google 也已经开始合作，将 Pallas kernel 作为 Torch Dynamo / Inductor 编译栈的 codegen 目标。这将允许 PyTorch 原生 torch.compile API 原生接入 TPU，并允许最终用户在 PyTorch 中注册自定义 pallas ops。
除了 PyTorch 内核树中的原生 API 外，Google 也在幕后推动把 TPU Pallas kernel 语言作为 Helion 的 codegen 目标。可以把 Helion 视作用于在高层语言中编写高性能 kernel 的更高层语言。鉴于其更接近 Native PyTorch Aten ops，而不是 Triton/Pallas 那样的高层 DSL，用户可以将 Helion 理解为“低层 Aten 运算符”，而不是“高层 Triton/Pallas”。
另一个 CUDA 生态明显占优的领域是开放推理生态。历史上，vLLM 与 SGLang 都是将 CUDA 视作一等公民（而 ROCm 是二等公民）。现在 Google 希望加入 vLLM 与 SGLang 的开放推理生态，并宣布通过一种非常“独特”的集成方式，为 vLLM 与 SGLang 提供 TPU v5p / v6e 的 beta 支持。
目前 vLLM 与 SGLang 的做法是：把 PyTorch 的建模代码 lower 到 JAX，再利用现有成熟的 JAX TPU 编译流程。未来，一旦 PyTorch XLA RFC #9684（即原生 TPU PyTorch backend）落地，vLLM 与 SGLang 计划评估是否改为使用该原生后端，而不是通过 TorchAX 把 PyTorch 模型翻译到 JAX。
Google 与 vLLM 声称，这条 lower 到 JAX 的路径不需要对 PyTorch 建模代码进行任何修改，但考虑到目前 vLLM TPU 支持的模型数量极少，我们对此表示怀疑。
此外，Google 已经开源并集成了一些 TPU kernel 到 vLLM 中，比如 TPU 优化的 paged attention kernel、compute–comms 重叠的 GEMM kernel 以及若干量化 matmul kernel。目前他们还没有 MLA-friendly 的 TPU kernel。很有意思的一点是：一旦 Inductor–Pallas TPU codegen 集成成熟，是否可以把 kernel fusion 与 pattern matching 集成到现有 vLLM 的 PassManager 中。SGLang 也在考虑实现一个 torch.compile PassManager，以便更可维护地管理多模型的 kernel fusion。
对于 Ragged Paged Attention v3，TPU 的处理方式与 vLLM GPU 完全不同。vLLM 使用类似虚拟内存与分页的技术维护 KV cache。然而这需要动态地址访问与 scatter 操作，而这并不适合 TPU。为此，TPU kernel 使用细粒度算子流水线。具体来说，TPU 的 page attention kernel 会预取下一序列的 query 与 KV blocks，使内存加载与计算重叠。
在现有 vLLM 的 MoE kernel 中，流程是：按 expert ID 对 tokens 排序，将 tokens 分发到包含相应 expert 的设备上，进行分组矩阵乘法，然后再将来自各 expert 的 tokens 合并回原设备。然而这个 kernel 表现欠佳，原因有二：TPU 在排序操作上很慢，而且该 kernel 无法将通信与计算重叠。
为绕开这一问题，Google 开发者设计了 all-fused MoE。all-fused MoE 一次在每个设备上仅为一个 expert 分发 tokens，同时重叠 MoE dispatch 与 MoE combine 通信，并避免按 expert ID 对 tokens 排序。使用 all-fused MoE 后，Google 工程师报告相较现有 kernel 提升了 3–4 倍的性能。
此外，TPU 中另一个硬件单元是 SparseCore（SC），用于加速 embedding 查找与更新。SC 包含一个标量子核 SparseCore Sequencer（SCS）和多个向量子核 SparseCore Tiles（SCT）。与 TPU TensorCore 的 512-byte 加载相比，SCT 支持在更细粒度（4-byte 或 32-byte）上进行本地与远程直接内存访问。这使得 SC 能执行 gather / scatter 操作以及 ICI 通信，同时与 TensorCore 运算重叠。
在 JAX DevLabs 上，我们了解到 SparseCore 的可编程性仍在完善中。我们可以预期 Mosaic（TPU 自定义 kernel 编译器）会以 MPMD 方式进行编译，即 SCS 与 SCT 分别执行不同 kernel，不同 SparseCore 可以运行不同程序。我们推测，一旦可编程性跟上，TPU 的 MoE kernel 将能像 GPU 一样执行更灵活的 dispatch 与 combine，而不是只能按 expert ID 进行分发。
在 disaggregated prefill decode 方面（我们在 AMD 2.0 的文章中有详细描述），Google 在 vLLM 上对单主机 disagg PD 提供了实验性支持，但尚未支持多主机 wideEP disagg prefill 或 MTP。这些推理优化对降低每百万 token 的 TCO、提升 perf per dollar 与 perf per watt 至关重要。此外，他们还尚未将 TPU vLLM 推理支持集成到 VERL 等流行 RL 框架中。Google 正在缓慢朝正确方向推进其对开放 AI/ML 生态的态度，尤其是在“原生” TPU backend 上。
vLLM TPU 基准测试目前不具备参考意义
本周，有一个基于 TPUv6e 的新推理基准发布，宣称 TPUv6e 在性价比上比 Nvidia GPU 差 5 倍。我们主要基于两点不同意这一结论。
第一，这个基准是基于 vLLM on TPU，而 vLLM on TPU 只是几个月前才发布，目前尚未完成性能优化。Google 内部的 Gemini 工作负载与 Anthropic 的工作负载运行在内部定制的推理栈上，其 TCO 性能优于 Nvidia GPU。
第二，Artificial Analysis 所给出的每百万 token 成本，是基于 TPUv6e 的“标价”：2.7 美元/小时/芯片。没有任何大型 TPU 客户会支付接近这个价格，因为 TPUv6e 的 BOM 仅为 H100 的一个小分数。众所周知，大多数云厂商都喜欢把标价订得很高，以便其客户经理可以像“车行销售”一样给出巨额折扣，让客户误以为自己捡了大便宜。
SemiAnalysis 的 AI TCO Model 跟踪了 TPUs 在各种合约期限（1 个月、1 年、3 年等）下的实际市场租赁价格。
TPU 软件战略中关键缺失的一块
在软件战略上，Google 依然做错的一点是：他们的 XLA 图编译器、网络库和 TPU runtime 仍未开源，也没有良好文档。这导致从高级用户到普通用户的整个光谱都非常挫败——大家都无法搞清楚自己代码出问题时到底发生了什么。此外，他们用于多 pod 训练的 MegaScale 代码库同样没有开源。
我们强烈认为：如果 Google 想加速 TPU 的采用，就应该开源这些东西，而用户采用度的提升将远大于他们免费公开的软件 IP 所“损失”的价值。就像 PyTorch 或 Linux 一样，通过开源大幅加速了自身的普及，开源 XLA:TPU、TPU runtime 和网络库，也会同样极大加速这一进程。
这对 Nvidia 意味着什么？
现在 Google 已经把 TPU 这套东西理顺，并开始对外销售，让客户可以把 TPU 放进自己的数据中心——这对 Nvidia 的业务意味着什么？Nvidia 终于有了一个能在市占率和利润率上真正威胁到它的对手吗？在付费墙后，我们会分享我们对这对 Nvidia 的意义的看法，并进一步披露 TPU 路线图。
尽管 Ironwood 已经是 Blackwell 的一个正面竞争对手，Nvidia 又用 Vera Rubin 进行了反击。Vera Rubin 将在算力、内存和网络方面带来巨大的性能飞跃，而 TPU v8 的提升则小得多。
第 8 代 TPU 将在 2027 年可用，直接对标 Nvidia Vera Rubin。TPU v8 会有两个版本，但这和第 4、5 代时期的 “P”（full）和 “E”（lite）SKU 不同。新的方式是双路线：一个 SKU 与 Broadcom 联合设计（TPU 8AX，代号 “Sunfish”），一个 SKU 与联发科联合设计（TPU 8X，代号 “Zebrafish”）。
TPU 8AX 和 Ironwood 非常相似，甚至仍停留在同样的 N3E 逻辑工艺节点上，并保持类似布局：2 颗 compute die、1 颗 I/O chiplet 和 8 堆 HBM3E。内存从 8-high 堆叠升级到 12-high 堆叠，并采用来自 SK Hynix、速率最高达 9.6Gbps 的引脚速度，使其内存带宽相比 TPU v7 提升约 30% 以上。
TPU v8X 只有一颗 compute die、一颗 I/O die 和 6 堆 12-high 的 HBM3E。TPU v8X 的 compute die 使用的是 N3P，而不是 N3E。Google 选择与联发科合作背后的策略，是为了降低向硅设计合作伙伴（特别是 Broadcom）支付的利润。Broadcom 按整套 System in Package 向 Google 收费，并在其上叠加相当可观的利润，其中包括 HBM。
尽管如此，在芯片的计算部分上，无论前端还是后端设计，主要责任仍在 Google，而 Broadcom 提供的是各种 PHY（尤其是其顶级 SerDes）和控制器。Google 希望转向一种模式——让其硅合作伙伴只对自己真正增值的部分收费，并在硅成本上更接近 BOM 成本。
这里就是联发科发挥作用的地方——它在定制硅模式方面灵活得多。借助联发科，Google 正在向 “Customer Owned Tooling” 模式演进，即最终客户拥有并负责从头到尾的完整设计。这是定制硅真正实现垂直一体化的标志，也是所有 hyperscaler 的终极目标。这当然非常激进，因为这要求 hyperscaler 拥有类似一流芯片设计公司那样的端到端硅设计能力。
在 TPU V8X 上，Google 在计算部分依然由联发科协助，由联发科负责在台积电 tapeout，并向 Google 工程团队提供自家的 3nm 设计库。在没有 Broadcom 扶着手的情况下，这颗芯片的 tapeout 过程比预期漫长许多，但最终在本季度完成了。
联发科在设计上的重要贡献体现在 I/O chiplet，其上集成了联发科自家的 224G SerDes。联发科负责的另一块是封装设计，这本来就是更偏芯片设计方的领域。真正改变游戏的是：通过联发科，Google 可以直接从 SK Hynix 等厂商采购 HBM，而不必经过一家硅供应商的成本结构再被叠加利润。鉴于 HBM 往往是封装级 BOM 中占比最大的部分，这一点非常关键。
虽然 TPU V8 的重大变化在于：Google 同时与两家设计公司合作，但工程资源显然被大量投入到了适应这种新模式，以及与联发科的合作爬坡上。我们是第一家披露这条“双路线”方案的机构，并持续在我们的 Accelerator Model 中更新 TPUv8 项目的状态，因为这对 Broadcom 和联发科有重大影响。
结果就是：与 Nvidia 计划中 Rubin 的算力与内存升级相比，TPUv8 的代际性能提升要温和得多。对外部客户而言，每单位有效 FLOP 的 TCO 仍有优势，但相较于 Ironwood 对 Blackwell 的优势，这一差距收窄了许多。
在每单位内存带宽成本上，对外客户仍有轻微优势，但远不如之前那样显著。根本原因在于 Rubin 单芯片带宽暴涨到 20TB/s，采用 HBM4、引脚速率约 10Gbps，而 TPU 8 仍然使用 HBM3E，TPU v8AX 的带宽只有 9.8TB/s，大约 Rubin 的一半。
随着 Nvidia 再次把相对 TPU v8 的性能差距拉回来，这也是 Anthropic 需要重建与 Nvidia 合作关系的原因。
尽管 TPU（以及 Trainium）在性能/TCO 上为 Anthropic 找到了非常微妙的平衡点，但 Nvidia 一直在以近乎“光速”的节奏奔跑，不断推出创新，强大到几乎不可能被忽视。正如下图所示，在已出货 FLOPs 方面，Nvidia 依然是主导者。
Nvidia 最初为 Rubin 设定的目标要保守得多，但他们把功耗从 1800W 拉高到 2300W，以提升 FLOPs，并将 HBM 带宽从 13TB/s 拉到 20TB/s。这在很大程度上是出于 Nvidia 的“偏执”以及来自 AMD 与 Google 的竞争压力。Nvidia 正在以光速全力冲刺。
如果 Nvidia 在 Rubin 上这波激进的“最后一刻” FLOPs 与内存带宽提升顺利落地，那么 Google 的 TPU 就会从对外“具竞争力”滑向 TPUv8 上“缺乏竞争力”，原因就是他们在设计选型上过于保守。
历史上 TPU 在 TCO 上对 GPU 有显著优势，但这可能不会永远持续。Google 在 TPUv8 上不仅在硅方面有延迟，还存在从晶圆厂到整机机架再到数据中心运行负载这一整条供应链上的缓慢问题。
此外，Google 对 TPUv8 的设计也太“温吞”，在 TSMC 的 2nm 或 HBM4 上的推进速度远远不够，特别是结合它的上市时间点来看。Nvidia 已经在 3nm 与 HBM4 上，而在同一时间窗口里，AMD 也在冲 2nm + HBM4。Google 即便付高价买 Broadcom 的 SerDes，也要到 2027 年才上 224G。
Google 正在把大量 TCO 优势拱手让给 Rubin。我们最终可能会看到这样一个世界：对于许多 Google 内部工作负载而言，Rubin 在 Kyber 机架上的 TCO 甚至可以与 Google 的 TPUv8 打平甚至更优。
牌已经由 Google 摊在桌面上，现在轮到 Nvidia 去执行，才能继续作为这条食物链顶端的狮子。Nvidia 一向以“光速”推进，但如果 Rubin Oberon 和 Rubin Kyber 出现延期，或者性能不达标，它们就有被拉下王座的风险。