炒股就看金麒麟分析师研报，权威，专业，及时，全面，助您挖掘潜力主题机会！

（来源：网易科技）

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 运行时及网络库也将迅速加速这一点。