人工智能时代的曙光已然降临，我们一定要认识到，人工智能驱动型软件的成本结构与传统软件存在非常明显差异。芯片微架构和系统架构在这类创新型新软件的开发与规模化应用中，发挥着至关重要的作用。与早期以开发者成本为主要支出的软件相比，支撑人工智能软件运行的硬件基础设施，对资本支出（Capex）和运营支出（Opex）乃至毛利率的影响要大得多。因此，为顺利部署人工智能软件，投入更多精力优化人工智能基础设施就显得很关键。在基础设施领域占据优势的企业，在AI应用的部署与规模化拓展能力上，同样会具备领先优势。
谷歌早在2006年就开始推销构建专门AI基础设施的想法，但问题在2013年达到了临界点。他们意识到，如果想在任何规模上部署人工智能，就必须将现有的数据中心数量翻倍。因此，他们开始为TPU芯片奠定基础，并于2016年投入生产。与亚马逊相比很有趣，亚马逊同年意识到他们也需要制造定制硅片。2013年，他们启动了Nitro项目，专注于开发硅片以优化通用CPU计算和存储。两家截然不同的公司针对不一样时代的计算和软件范式优化了基础设施建设。
早在 2006 年，谷歌就开始宣扬打造AI专用基础设施的理念，但有关问题在 2013 年彻底爆发。当时谷歌意识到，若要实现AI的规模化部署，就必须将其数据中心的数量扩充一倍。为此，谷歌启动了张量处理单元（TPU）芯片的研发筹备工作，该芯片于 2016 年正式投产。有趣的是，同年亚马逊也意识到自身要研发定制化芯片。早在 2013 年，亚马逊就启动了Nitro 项目，该项目专注于研发芯片以优化通用型中央处理器（CPU）的计算性能与存储能力。这两家风格迥异的企业，针对不同计算时代与软件范式的需求，在基础设施领域各自展开了针对性的优化布局。
长期以来，我们从始至终认为张量处理单元（TPU） 是全球最顶尖的人工智能训练与推理系统之一，与行业龙头英伟达不相上下。两年半前，我们曾撰文提出 “TPU 优势论”，如今这一观点已被证实是完全正确的。
张量处理单元（TPU）的实力不言而喻：双子座 3（Gemini 3）作为全球性能顶尖的大模型之一，其训练过程完全基于 TPU 平成。本文我们将探讨谷歌为推动 TPU 对外商业化所做出的重大战略调整 —— 这家科技巨头正借此转型为英伟达在商用芯片领域最新、也最具威胁的竞争对手。
1.面向客户与新读者，重新解读 TPU 对外商用的高速增长态势，案例覆盖从Anthropic（人工智能公司）起步，延伸至元宇宙（Meta）、SSI（半导体创新公司）、xAI乃至潜在客户OpenAI等一众企业……2.论证核心观点：采购的 TPU 越多，节省的英伟达 GPU 资本支出就越多！即便尚未部署 TPU，OpenAI 已借助市场之间的竞争带来的议价优势，将其计算集群成本降低约 30%，实现了单位总拥有成本（TCO）下的性能提升。3.解析人工智能基础设施领域的循环经济合作模式。4.回溯我们此前发布的 TPU 深度分析报告，重新梳理从芯片底层到软件层面的 TPU 硬件技术栈。5.阐述 TPU 在开放式软件生态领域取得的积极进展，同时指出谷歌若想打破英伟达 CUDA 技术壁垒、构建具备竞争力的 TPU 生态，亟待补齐的关键短板 —— 即开源其 XLA:TPU 编译器、运行时环境及多机柜集群 “MegaScaler”（大规模扩展）代码。
首先，我们来谈谈这一消息对行业生态造成的影响。张量处理单元（TPU） 的性能显然已经引起了竞争对手的密切关注。山姆・奥特曼坦言，随着双子座（Gemini） 模型抢占了 OpenAI 的风头，公司未来的发展将面临 “严峻挑战”。英伟达甚至发布了一份安抚性的公关声明，呼吁大家保持镇定、继续前行 —— 并称其在竞争中仍遥遥领先。
我们完全理解其中的缘由。过去数月，谷歌深度思维（Google DeepMind）、谷歌云平台（GCP）与张量处理单元（TPU）业务联合体捷报频传：TPU 的产能规模被大幅上调，Anthropic 公司的 TPU 算力部署规模突破 1 吉瓦，性能达业界顶尖水平（SOTA）的 Gemini 3 和 Opus 4.5 两大模型均基于 TPU 完成训练，如今其目标客户名单还在持续扩容 ——Meta、SSI、xAI、OpenAI（OAI）等企业均在排队采购 TPU。
这一系列动态推动了谷歌及 TPU 供应链的估值大幅上调，而这一变化的代价，则是此前聚焦英伟达 GPU 的供应链估值受到挤压。尽管谷歌及 TPU 供应链的 “异军突起” 令不少市场参与者猝不及防，但半导体分析公司（SemiAnalysis）机构产品的订阅用户，早在一年前就已预判到了这一趋势。
英伟达陷入守势的另一个原因，是慢慢的变多的质疑者齐声指出：该公司正通过为烧钱的人工智能初创公司可以提供资金，构建一种 “循环经济” 模式 —— 这本质上就是多绕几道弯，把钱从一个口袋挪到另一个口袋。我们大家都认为这种观点有失偏颇，但它显然触动了英伟达的敏感神经。其财务团队已发布一份详细回应，内容转载如下。
我们认为一种更贴合实际的解释是：英伟达意在通过股权投资而非降价的方式，巩固其在基础研发实验室领域的主导地位 —— 降价不仅会拉低毛利率，还会引发投资者的普遍恐慌。下文将以 OpenAI 和 Anthropic 的合作协议为例，阐述前沿实验室如何通过采购或威胁采购 TPU的手段，降低 GPU 的总拥有成本（TCO）。
OpenAI 甚至尚未部署张量处理单元（TPU），就已将其整个实验室的英伟达 GPU 集群成本降低了约 30%。这一事实足以证明，TPU 所具备的单位总拥有成本（TCO）性能优势十分显著 —— 即便还未启用哪怕一台 TPU，企业仅凭借采购 TPU 的潜在意向，就能收获成本优化的红利。
长期以来，TPU 技术栈的性能足以与英伟达的人工智能硬件相抗衡，但它此前主要服务于谷歌内部的工作负载。秉持谷歌一贯的风格，即便早在 2018 年就已向谷歌云平台（GCP）客户开放 TPU 的使用权限，该公司也始终未对这项技术进行全面商业化运作。如今，这一局面正开始发生转变。
在过去数月间，谷歌调动全技术栈资源，通过两种方式向外部客户提供 TPU 产品：一是依托谷歌云平台（GCP）进行交付，二是以商用芯片供应商的身份直接销售完整的 TPU 系统。这家搜索巨头正凭借其强大的自研芯片设计能力，转型为一家具备独特竞争优势的云服务提供商。此外，这一战略布局也与头部客户 Anthropic 的诉求相契合 —— 后者正持续推进供应链多元化，以降低对英伟达（NVDA）的依赖。
与 Anthropic 的合作协议，是谷歌推进 TPU 对外商用进程中的一个重要里程碑。据悉，谷歌云（GCP）首席执行官托马斯・库里安在此次谈判中发挥了核心作用。为推动 TPU 的应用场景突破谷歌内部范畴，谷歌很早就采取了积极行动，不仅在 Anthropic 的多轮融资中大手笔投资，甚至还同意放弃投票权，并将自身持股票比例上限设定为 15%。得益于这家基础研发实验室中配备了原深度思维（DeepMind）的 TPU 技术团队，这一战略合作得以顺利推进，最终促成 Anthropic 在包括 TPU 在内的多款硬件平台上，完成了 Sonnet 与 Opus 4.5 两大模型的训练工作。正如我们这份AI实验室建筑追踪报告的截图所示，谷歌已为 Anthropic 建成了一座规模可观的专属算力设施。
除了通过谷歌云平台（GCP）租用谷歌数据中心的算力外，Anthropic 公司还将在自有设施内部署张量处理单元（TPU）。此举将助力谷歌转型为真正的商用硬件供应商，与英伟达展开正面竞争。
1.合作协议的第一阶段涉及40 万个 TPUv7（代号 “Ironwoods”），这批产品将以整机柜形态交付，总价值约 100 亿美元，由博通公司直接销售给 Anthropic。Anthropic 正是博通公司在最新财报电话会议中提及的第四大客户。金牌级 ClusterMax 混合云服务提供商Fluidstack公司将负责现场安装、布线、老化测试、验收测试以及远程协助运维等工作 —— 这是因为 Anthropic 将物理服务器的管理工作进行了外包。数据中心基础设施则由泰拉沃尔夫公司（TeraWulf，股票代码 WULF）与西弗矿业公司（Cipher Mining，股票代码 CIFR）联合提供。
2.剩余的60 万个 TPUv7将通过谷歌云平台（GCP）进行租赁，我们估算这笔订单对应的长期未交付订单金额（RPO）高达 420 亿美元，占谷歌云平台第三季度公布的 490 亿美元未交付订单增量的绝大部分。
3.我们大家都认为，未来几个季度，谷歌与 Meta、OpenAI（OAI）、SSI 及 xAI 等企业达成的新增合作，有望为谷歌云平台带来更多长期未交付订单收入及硬件直售收入。
尽管目前对内、对外的 TPU 需求均十分旺盛，但谷歌仍未能按预期速度完成 TPU 的部署。相较于其他仍需仰仗黄仁勋的超大规模云服务商，谷歌对自身硬件供应链的掌控力本就更强，但其当前面临的主要瓶颈是电力供应。
尽管其他超大规模云服务商早已扩张自有数据中心场地，并锁定了大量主机托管算力资源，谷歌的行动却相对迟缓。我们认为，核心问题出在合同流程与行政管理层面。每新增一家数据中心供应商，都需要签订一份《主服务协议》（Master Services Agreement，MSA）；这类协议涉及数十亿美元规模、长达数年的合作承诺，自然会伴随繁琐的行政流程。而谷歌的审批流程尤为拖沓，往往从初步接洽到最终签署协议，耗时可长达三年。
谷歌采取的这一权宜之计，对那些寻求转型人工智能数据中心基础设施领域的混合云服务商与密码货币矿企，产生了重大影响。谷歌并未直接向数据中心供应商租赁场地，而是提供了信用担保—— 这是一种表外 “欠条” 机制（off-balance sheet），一旦Fluidstack公司无力支付数据中心租金，谷歌将介入兜底。
Fluidstack这类混合云服务商灵活敏捷，能够更便捷地与转型后的密码货币矿企等新兴数据中心供应商展开合作。密码货币矿企的转型机遇，源于一个简单的行业动态：数据中心行业正面临严峻的电力资源瓶颈，而加密货币矿企早已凭借其电力购买协议（PPA）和现有电力基础设施，牢牢掌握了充足的电力容量。我们预计，在未来数周至数个季度内，将会涌现出更多类似的合作协议。
在谷歌/Fluidstack/TeraWulf的合作协议达成之前，混合云市场从未出现过仅凭表外 “欠条” 机制就敲定的合作案例。而在该协议落地后，我们大家都认为这种模式已成为混合云领域事实上的全新融资标准模板。这一模式恰好解决了混合云服务商在获取数据中心算力资源、拓展业务过程中面临的一大痛点：
一份大型数据中心租赁合同的期限通常长达 15 年以上，项目投资回收期约为 8 年。
这种期限错配问题，曾让混合云服务商与数据中心供应商在为项目融资时面临重重阻碍。但随着超大规模云服务商兜底模式的兴起，我们大家都认为融资难题已迎刃而解。混合云行业有望迎来新一轮增长浪潮。以上便是 Anthropic 合作协议背后的运作逻辑与深层原因，接下来我们将聚焦硬件层面展开分析。
此外，对那些有黄仁勋投资背景的混合云服务商 —— 例如 CoreWeave、Nebius、Crusoe、Together、Lambda、Firmus 及 Nscale 等企业而言，它们显然存在强烈的动机，不会在自家数据中心采用任何竞争性技术：无论是 TPU、AMD 图形处理器，甚至是 Arista 交换机，均被划入禁止使用的范畴！这就给 TPU 托管业务留下了巨大的市场空白，而当前填补这一空白的主体，正是密码货币矿企与Fluidstack公司的联合体。未来数月，我们预计会有更多混合云服务商面临两难抉择：究竟是抓住蒸蒸日上的 TPU 托管机遇，还是争取获得英伟达最新的Rubin系统配额。
答案很简单：这款性能强劲的芯片，搭载于一套精良的系统之中，二者的组合为 Anthropic 带来了极具吸引力的性能表现与总拥有成本优势。两年半前，我们就曾撰文探讨谷歌在计算基础设施领域的优势。即便在纸面参数上，其芯片性能落后于英伟达，但谷歌凭借系统级工程优化，依然让 TPU 技术栈在性能与成本效益两方面，均能与英伟达的产品相匹敌。
彼时我们就提出过一个观点 ——“系统的重要性远超微架构”，而过去两年的行业实践，进一步印证了这一论断的正确性。Anthropic 下达的巨额 TPU 订单，便是对该平台技术实力的直接佐证。与此同时，GPU 生态也在同步向前演进。英伟达的 GB200 芯片堪称一次重大技术飞跃，推动英伟达朝着真正的系统级企业转型 —— 其业务范畴不再局限于芯片封装设计，而是延伸至完整服务器的研发生产。
谈及 GB200 在机柜级互联技术上的重大突破，有一个极易被忽视的事实：早在 2017 年推出第二代 TPU（TPU v2）时，谷歌就已实现了机柜内部及机柜之间的 TPU 算力扩展！在本报告的后续章节中，我们将深入剖析谷歌的ICI 扩展网络技术—— 这项技术也是目前唯一能与英伟达 NVLink 互联技术相抗衡的方案。
谷歌最新发布的 Gemini 3 大模型，如今已被公认为业界顶尖的前沿大语言模型。与此前所有版本的 Gemini 模型一样，它的训练过程完全基于 TPU 平成。这一成果，为 TPU 的性能优势以及谷歌在整体基础设施领域的领头羊，提供了确凿的实证。
当前市场的关注点往往集中在推理和训练后阶段的硬件技术上，但事实上，前沿大模型的预训练环节，才是人工智能硬件领域难度最高、资源消耗最大的核心挑战。TPU 平台已凭借实力，稳稳通过了这一严苛考验。反观其竞争对手，二者的表现形成了鲜明反差：自 2024 年 5 月 GPT-4o 发布以来，OpenAI 的顶尖研发团队始终未能成功完成一次全规模预训练，并将其成果大范围的应用于新一代前沿大模型的部署。这一现状，恰恰凸显出谷歌的 TPU 算力集群已经攻克了何等艰巨的技术难关。
这款新模型的核心亮点之一，在于其在工具调用能力和智能体能力上实现了显著提升，尤其在执行具有经济价值的长周期任务时表现更为突出。“自动售货机基准测试”（Vending Bench）是一项专门用于评估模型长期运营能力的测试 —— 该测试会将模型设定为模拟自动售货机业务的经营者，以此衡量模型的长期业务管理上的水准。在这项测试中，Gemini 3 的表现远超所有竞品。
此次发布不仅实现了功能升级，更推出了全新产品。Antigravity这款产品脱胎于谷歌对帆板科技（Windsurf）前首席执行官瓦伦・莫汉（Varun Mohan）及其团队的收购式招聘，是谷歌对标 OpenAI 代码生成模型 Codex 的重磅之作，标志着 Gemini 正式入局竞争非常激烈的交互式代码生成算力消耗大战。
对谷歌而言，其核心业务过去并非（或者说，原本并非）硬件领域，却能低调发力，在硬件领域最具挑战性的难题之一上建立性能一马当先的优势，这着实是一项令人赞叹的成就。
“系统的重要性远超微架构” 这一论断的必然推论是：尽管谷歌一直在突破系统与网络设计的边界，但早期的 TPU 芯片本身并非具有颠覆性的创新。而自那时起，TPU 芯片不断迭代升级，最新几代产品已实现了跨越式发展。
从一开始，相较于英伟达，谷歌在芯片设计理念上就趋于保守。回顾历史，同代 TPU 芯片的峰值理论浮点运算性能与内存规格，均明显低于对应的英伟达 GPU。
背后存在三方面原因：第一，谷歌在内部格外的重视基础设施的可靠性、可用性与可维护性（RAS）。为了换取更高的硬件正常运行时间，谷歌宁愿牺牲一定的绝对性能。将硬件性能压榨到极限，会导致硬件故障率升高 —— 这会直接影响总拥有成本（TCO），具体体现在系统停机时间增加、热备份备件消耗增多等方面。毕竟，无法投入到正常的使用中的硬件，其单位性能对应的总拥有成本相当于无限高。
第二，在 2023 年之前，谷歌的核心人工智能工作负载是支撑其搜索与广告主营业务的推荐系统模型。与大语言模型（LLM）的工作负载相比，推荐系统的运算密度要低得多，这在某种程度上预示着每传输 1 比特数据，所需的浮点运算次数也更少。
第三个原因，与厂商宣传的 “峰值理论浮点运算性能”这一数据的实际效用及其可操控性有关。英伟达、AMD 这类商用 GPU 供应商，总是希望为自家芯片宣传尽可能亮眼的性能参数，这就促使它们将对外宣传的浮点运算性能数值拉升到极致。但在实际应用中，这些峰值性能根本没办法长时间维持。反观 TPU，由于其此前主要供谷歌内部使用，在对外夸大性能参数方面承受的压力要小得多。这一点背后暗含着诸多重要影响，我们将在后续展开深入探讨。往客观的角度看，英伟达在动态电压频率调节（DVFS）** 技术上更为领先，因此它们也乐于只公布峰值性能参数。
随着大语言模型时代的来临，谷歌的 TPU 设计理念也发生了显著转变。这种转变，在大语言模型时代之后研发的两代最新 TPU 产品上体现得淋漓尽致 —— 分别是TPUv6Trillium (Ghostlite)与TPUv7Ironwood (Ghostfish)。从下方图表中能够准确的看出，TPUv4 与 v5 的计算吞吐量，远低于同期英伟达的旗舰产品。TPUv6 的浮点运算性能已经很接近 H100 与 H200，但它的推出时间比 H100 晚了两年。而到了 TPUv7 这一代，其与英伟达旗舰产品的差距进一步缩小：不仅峰值理论浮点运算性能几乎持平，服务器产品的上市时间也仅比竞品晚了几个季度。
是什么推动了这些性能提升？部分原因主要在于，谷歌调整了 TPU 的发布策略 —— 如今它会在产品量产爬坡阶段就对外公布，而非等到下一代产品已经部署后才披露有关信息。此外，TPUv6 Trillium与 TPUv5p 采用相同的N5 工艺节点制造，芯片面积也相近，但前者的峰值理论浮点运算性能却实现了惊人的两倍提升，同时功耗还明显降低！针对 “延龄草”，谷歌将每个脉动阵列的规模从 128×128 核扩充至 256×256 核，整整扩大了三倍，而阵列规模的提升正是实现算力增长的关键所在。
Trillium“延龄草” 同时也是最后一代 “E”（精简版）型号产品，这在某种程度上预示着它仅配备了 2 组第三代高带宽内存（HBM3）。尽管 “延龄草” 在算力上拉近了与 “霍珀” 架构产品的差距，但在内存容量与带宽上，它却远不及 H100 与 H200—— 前者仅搭载 2 组 HBM3，而后两者则分别配备了 5 组 HBM3 与 6 组第三代增强型高带宽内存（HBM3E）。这一点让新手用户在使用时颇为棘手，但只要你能对模型做到合理分片，并充分的利用这些成本低廉的浮点运算算力，Trillium “延龄草” 所能实现的单位总拥有成本（TCO）性能优势便是无可匹敌的。
TPU v7 Ironwood “铁木” 作为新一代产品，在浮点运算性能、内存及带宽这三项核心指标上，几乎已完全追平同期英伟达的旗舰级 GPU，只是其正式上市时间比 “布莱克韦尔” 架构产品晚了一年。相较于 GB200，TPUv7 “铁木” 的浮点运算性能与内存带宽仅存在小幅差距，二者的内存容量处于同一水平，均搭载 8 层高带宽内存第三代增强版（8-Hi HBM3E）；当然，与配备 12 层高带宽内存第三代增强版（12-Hi HBM3E）、总容量达 288GB 的 GB300 相比，TPUv7 “铁木” 的内存规格仍存在非常明显差距。
理论绝对性能只是一方面，真正关键的是单位总拥有成本（TCO）下的实际性能表现。
尽管谷歌需通过博通采购 TPU，且需支付不菲的利润分成，但这笔成本远低于英伟达从相关业务中赚取的利润 —— 英伟达的利润来源不仅包括 GPU 芯片销售，还涵盖了CPU、交换机、网卡、系统内存、线缆及连接器在内的整套系统。从谷歌的视角来看，采用全三维环面网络（3D Torus）配置的 “铁木” 芯片，其全流程总拥有成本，相较 GB200 服务器低了约 44%。这一成本优势，足以抵消其在峰值浮点运算性能与峰值内存带宽上约 10% 的差距。上述结论，均基于谷歌的采购视角以及其 TPU 服务器的实际采购价格。
那么，当谷歌在成本基础上叠加自身利润、将 TPUv7 租赁给外部客户时，情况又会如何呢？我们测算，即便谷歌在对外租赁 TPUv7 的定价中计入自身利润，其每小时总拥有成本仍可比 GB200 低约 30%，较 GB300 低约 41%。我们大家都认为，这一数据也恰好反映了 Anthropic 通过谷歌云平台（GCP）采购 TPU 时的实际定价水平。
仅对比理论浮点运算性能，只能反映出部分情况。真正关键的是有效浮点运算性能，因为峰值性能数据在实际在做的工作负载中几乎从未被真正达到过。
在实际应用中，一旦计入通信开销、内存延迟、功耗限制以及其他系统层面的影响因素，英伟达 GPU 通常只能发挥出其理论峰值性能的一小部分。对于模型训练场景，一个普遍的经验数值是30%，但实际利用率也会因工作负载的不同而产生巨大差异。而造成这一性能差距的很大一部分原因，要归结于软件与编译器的效率差异。英伟达在这方面的优势，源于其构建的 CUDA 生态壁垒，以及丰富的开箱即用开源库 —— 这些工具能帮助各类工作负载高效运行，实现较高的实际浮点运算性能与内存带宽利用率。
TPU 的软件技术栈使用门槛原本相比来说较高，但这样的一种情况如今已慢慢的出现转变。在谷歌内部，TPU 能够依托完善的自研工具链发挥出优异性能，而这些工具并未向外部客户开放，这就导致 TPU 面向外部用户的开箱即用性能相对逊色。不过，这一问题仅对小型用户或不愿投入精力优化的用户构成困扰，而 Anthropic 显然不属于这两类用户。
Anthropic 不仅拥有强大的工程研发实力，还聘请了一批出身谷歌的编译器专家 —— 这些专家既精通 TPU 技术栈，又对 Anthropic 自身的模型架构了如指掌。他们可以通过开发定制化内核，大幅度的提高 TPU 的运行效率。因此，Anthropic 得以实现更高的模型浮点运算利用率（MFU），以及更出色的每千万亿次浮点运算成本效益。
我们认为，尽管 TPU 对外宣传的峰值浮点运算性能数值相比来说较低，但其实际达成的模型浮点运算利用率，反而能够超过英伟达的 “布莱克韦尔” 架构产品 —— 这也代表着 TPUv7 “铁木” 可以在一定程度上完成更高的有效浮点运算性能。其中一个重要原因是，英伟达与 AMD 对外宣称的 GPU 峰值浮点运算性能数值，存在很明显的夸大成分。即便在那些为最大化吞吐量而设计的测试中（测试所用的矩阵乘运算与真实工作负载相去甚远），英伟达 “Blackwell” 架构产品也仅能达到峰值性能的约 80%，“布莱克韦尔” 架构产品在 70% 多的水平，而 AMD 的 MI300 系列新产品则仅能达到 50% 至 60%。
造成这一现象的限制性因素是供电能力。这些芯片无法长时间维持峰值性能计算所需的时钟频率。英伟达与 AMD 均采用了动态电压频率调节技术（DVFS），这在某种程度上预示着芯片的时钟频率会根据功耗与温度动态调整，而非维持在一个稳定可持续的固定频率。但在计算理论峰值浮点运算性能时，英伟达与 AMD 会选取芯片所能达到的最高时钟频率 —— 哪怕这个频率只能以极短暂的间隙性方式运行 —— 再通过公式（每运算周期每算术逻辑单元的操作数 × 算术逻辑单元数量 × 每秒运算周期数，即时钟频率）计算得出峰值数值。
除此之外，厂商还会采用其他一些 “技巧” 来美化数据，例如使用全零张量进行矩阵乘运算测试。由于 0 与 0 相乘结果仍为 0，晶体管无需进行 0 到 1 的状态切换，因此能大幅度降低单次运算的功耗。当然，在真实的应用场景中，是不可能会出现全零张量相乘这类情况的。
当我们将更低的总拥有成本与更高的有效浮点运算性能利用率相结合来看，站在谷歌的角度，每单位有效浮点运算性能的成本会一下子就下降 —— 当 TPU 的模型浮点运算利用率达到约 15% 时，便能与模型浮点运算利用率为 30% 的 GB300 实现成本持平。这在某种程度上预示着，即便谷歌（或 Anthropic）只能将 TPU 的浮点运算利用率做到 GB300 的一半，二者的成本效益也不相上下。当然，凭借谷歌顶尖的编译器工程师团队，以及对自研模型的深度理解，TPU 的模型浮点运算利用率有望达到 40%。如此一来，每单位有效训练浮点运算性能的成本将实现惊人的约 62% 降幅！
然而，在分析这 60 万个租赁型 TPU 时，若将 Anthropic 需要承担的更高总拥有成本（即计入谷歌叠加的利润）纳入考量，我们估算 Anthropic 通过谷歌云平台（GCP）租用每个 TPU 的小时成本为 1.6 美元，这会缩小 TPU 的总拥有成本优势。
我们认为，得益于 Anthropic 对性能优化的持续投入，以及 TPU 对外宣传的浮点运算性能数值本身就更贴合实际水平，该公司能够将 TPU 的模型浮点运算利用率（MFU）提升至 40%。这将使 Anthropic 在每单位有效千万亿次浮点运算性能的总拥有成本上，较英伟达 GB300 NVL72 系统实现惊人的约 52% 降幅。
而与 GB300 基准系统相比，二者每单位有效浮点运算性能的总拥有成本达到平衡的临界点，对应的是 Anthropic 仅需实现 19% 的模型浮点运算利用率 —— 这一数值要低得多。这在某种程度上预示着，即便 Anthropic 的 TPU 在性能上较 GB300 基准系统存在非常明显差距，其训练场景下的浮点运算性能成本比最终仍能与英伟达基准系统持平。
浮点运算性能并非决定性能的唯一重要的条件，内存带宽对于推理环节至关重要，尤其是在对带宽要求极高的解码阶段。因此，TPU 的每单位内存带宽成本最终远低于 GB300，也就不足为奇了。大量证据说明，在处理 16MB 至 64MB 的小数据量任务（例如加载单层网络的专家模块）时，TPU 的内存带宽利用率甚至要高于 GPU。
所有这一些因素，最终转化为更高效率的模型训练与推理算力方案。Anthropic 发布的 Opus 4.5 模型延续了其一贯对代码生成能力的侧重，创下了 SWE-Bench 基准测试的全新纪录。最令人意外的是，该模型的 API 调用价格直接下调了约 67%。
在面向外部客户的定价策略上，谷歌需要精准拿捏尺度，在保障自身盈利空间的同时，为客户提供具备竞争力的方案。我们对 Anthropic 合作定价的估算值，处于市场传闻的外部定价区间下限。对于 Anthropic 这类旗舰级客户 —— 其不仅会为谷歌的软硬件路线图提供宝贵反馈，还会下达海量采购订单 —— 我们大家都认为谷歌非常有可能给出优惠协议价。
英伟达凭借高达 4 倍的加价幅度（对应约 75% 的毛利率），拥有极大的定价操作空间，但这一空间特别大程度上被博通压缩。作为 TPU 的联合设计方，博通在芯片这一系统物料清单（BOM）中占比最大的核心部件上，赚取了丰厚的利润。即便如此，谷歌仍有充足空间，实现可观且合理的利润率。
这一点，我们仅需对比谷歌云平台（GCP）与 Anthropic 的合作，以及其他大型 GPU 云服务合作项目的经济效益便可明晰。需要说明的是，本分析聚焦的是 Anthropic 通过 GCP 租赁的 60 万个 TPU，剩余 40 万个 TPUv7 芯片则由 Anthropic 直接预付采购。
基于上述假设条件，TPUv7 相关业务展现出的息税前利润（EBIT）率，优于我们观察到的其他大型 GPU 云服务合作项目，仅有甲骨文云基础设施（OCI）与 OpenAI 的合作能与之接近。即便芯片层面的物料清单中叠加了博通的利润分成，谷歌仍能实现远超同质化 GPU 业务的利润率与投资回报率。这正是 TPU 技术栈的价值所在 —— 助力谷歌云平台成为一家真正具备差异化竞争力的云服务提供商（CSP）。
反观微软 Azure 等企业，其自研专用集成电路（ASIC）项目进展不顺，只能局限于商用硬件租赁这一业务领域，赚取相对微薄的回报。
截至目前，我们围绕 TPU 与英伟达 GPU 的对比展开了讨论，重点聚焦于芯片级参数及二者的短板。接下来，我们回归到系统层面的探讨 —— 这正是 TPU 的性能优势真正拉开差距的领域。TPU 最具辨识度的特性之一，便是通过ICI 协议实现了超大规模的算力扩展规模。一个 TPU 算力集群（Pod）可集成多达 9216 颗 “铁木”（Ironwood）TPU 芯片；事实上，早在 2017 年推出的第二代 TPU（TPUv2）就已具备大规模集群部署的能力，当时其集群规模便已扩展至完整的 256 组、每组 1024 颗芯片的配置。我们不妨从机架层面切入 —— 机架正是每个 TPU 超级算力集群（Superpod）的基本组成单元。
过去几代 TPU 机架的设计均较为相似。每个机架由16 个 TPU 托盘、16 个或 8 个主机 CPU 托盘（具体数量取决于散热配置）、1 台机架顶交换机（ToR Switch）、若干电源供应单元以及电池备用单元（BBU）组成。
每个TPU 托盘包含 1 块TPU 板卡，板卡上搭载有 4 个TPU 芯片封装组件。每颗 “铁木” TPU 均配备 4 个OSFP 光模块插槽，用于实现 ICI 协议互联；同时配备 1 个CDFP 标准 PCIe 插槽，用于与主机 CPU 建立连接。
谷歌自 2018 年推出第三代张量处理单元（TPU v3）起，便开始采用液冷式 TPU 机架方案，但在此后的数代 TPU 产品中，仍有部分机型采用风冷式设计。
液冷机架与风冷机架的核心不同之处在于TPU 托盘和主机 CPU 托盘的配比：风冷机架的配比为2:1（即 2 个 TPU 托盘对应 1 个主机 CPU 托盘），而液冷机架的配比则为1:1。
TPU 液冷系统的创新设计在于，冷却液的流速可通过阀门实现主动控制。这样一来，系统便能根据任意时刻各芯片的工作负载量调节流速，以此来实现远高效的散热效果。谷歌的 TPU 还很早就采用了垂直供电架构，即将 TPU 的电压调节模块（VRM）布置在印刷电路板（PCB）的另一侧。这些电压调节模块同样需要配备冷板来辅助散热。
总体而言，TPU 机架的设计要比英伟达的Oberon NVL72 架构简洁得多。后者的硬件密度要高得多，并且需要借助背板来连接 GPU 与扩展交换机。TPU 托盘之间的扩展互联则完全通过外置铜缆或光缆实现，这一点将在下文的 ICI 协议部分展开说明。而 TPU 托盘与 CPU 托盘之间的连接，则是通过 PCIe 直连铜缆（DAC）完成的。
谷歌 TPUv7 芯片间互联（ICI）扩展网络的基本组成单元，是一个由 64 颗 TPU 构成的 4×4×4 三维环面拓扑结构。每组含 64 颗 TPU 的 4×4×4 立方体拓扑，均对应一个可容纳 64 颗 TPU 的物理机架。这是一种非常理想的结构尺寸设计，既能让机架内的 64 颗 TPU 实现全电连接，又能完整适配物理机架的空间布局。
这些 TPU 以三维环面拓扑结构互联，每颗 TPU 共与 6 个相邻节点建立连接 —— 在 X、Y、Z 三个坐标轴上，每个轴向上均连接 2 个逻辑相邻的 TPU。
在计算托盘内部，每颗 TPU 都会通过印刷电路板（PCB）走线 颗 TPU 相连；而根据该 TPU 在 4×4×4 立方体拓扑中的具置，它还会通过直连铜缆（DAC）或光模块，与另外 4 个相邻节点实现互联。
4×4×4 立方体拓扑内部的互联采用铜缆；而拓扑外部的互联（既包括环回连接至立方体另一相对侧的链路，也包括与相邻 4×4×4 立方体拓扑的互联），则需采用光模块及光电路交换机（OCS）。从下方示意图中能够正常的看到，作为一个三维环面网络，位于 Z + 平面的 TPU（2,3,4）会通过一个 800G 光模块建立环回连接，并经由光电路交换机（OCS）完成路由，最终与位于 Z - 平面的 TPU（2,3,1）互联。
如上所述，除了始终通过印刷电路板（PCB）走线 个相邻 TPU 外，其余 4 个相邻节点的连接方式需根据该 TPU 在 4×4×4 立方体拓扑中的具置而定，可单独采用直连铜缆（DAC）、光模块，或二者混用。
位于 4×4×4 立方体拓扑内部的 TPU，与其余 4 个相邻节点的连接全部采用直连铜缆；位于立方体表面的 TPU，采用3 根直连铜缆 + 1 个光模块的组合方式互联；位于立方体棱边的 TPU，采用2 个光模块 + 2 根直连铜缆互联；而位于立方体顶角的 TPU，则采用1 根直连铜缆 + 3 个光模块互联。你可以通过观察某一 TPU 有多少个侧面朝向立方体的外部，来判断它需要用多少个光模块。
上图及下表汇总了不同位置类型的 TPU 数量，据此可推算出每颗 TPUv7 的光模块配置比例为 1.5 个。这些光模块均与 ** 光电路交换机（OCS）** 相连，而光电路交换机的作用是实现不同 4×4×4 立方体拓扑之间的互联 —— 关于这一点，下一节会展开详述。
谷歌采用软件定义网络的方式，通过光电路交换机（OCS）对网络路由来管理。一台 N×N 规格的光电路交换机，本质上就像一座大型火车站，配有 N 条输入线路与 N 条输出线路。任何输入线路接入的信号，都可以被转接至任意一条输出线路，但这一转接操作需要在交换机上重新配置路由。必须要格外注意的是，信号没办法实现 “环路回传”，也不能被发送至另一路输入线路，只能被路由至 N 条输出线路中的其中一条。
这种技术方案的优点是，网络能够基于 ICI 网络层中理论上最大支持的 9216 颗芯片规模，为不同的工作负载划分出更小的逻辑 TPU 切片。通过对大型集群进行切片划分，并围绕网络故障点重新规划 ICI 传输路径，集群的可用性能获得有效提升。
与电子分组交换机（EPS）（例如 Arista Tomahawk 5 系列交换机）不同，电子分组交换机的总带宽是固定的，且需要被进一步分配至多个小带宽端口；而光电路交换机允许任意带宽的光纤直接接入其端口。此外，光电路交换机的延迟明显低于电子分组交换机 —— 原因主要在于进入光电路交换机的光信号，仅需从输入端口直接传输至输出端口即可；而光信号进入电子分组交换机时，必须先完成光电信号转换，这也是光电路交换机通常比电子分组交换机能效更高的关键原因。二者的另一不同之处在于：电子分组交换机支持数据包在任意端口间自由路由，而光电路交换机仅支持将信号从某一 “输入” 端口路由至任意一个 “输出” 端口。
光电路交换机（OCS）的端口仅能传输单股光纤信号。这对标准双工光模块而言是一项技术挑战 —— 因为双工光模块的带宽需通过多股光纤传输，这会降低光电路交换机的有效端口数与带宽。
为解决这一问题，谷歌采用FR 光模块，将所有波长的信号整合到单股光纤中，再接入光电路交换机的单个端口。阿波罗项目通过两步创新方案实现了这一目标：
1.借助粗波分复用技术（CWDM8），将 8 个波长的信号（每个 100G 通道对应 1 个波长）进行复用，仅用1 对光纤即可传输 800G 带宽，而无需传统方案中的 8 对光纤；
2.在波分复用（WDM）光模块中集成光环行器，实现全双工数据传输，从而将光纤需求从 1 对进一步缩减至单股光纤。
光环行器通过在光模块端将发射（Tx）和接收（Rx）光纤合并为单股光纤并接入光电路交换机（OCS），以此构建一条双向链路。
谷歌的 ICI 扩展网络具有独特性，其能够将多组由 64 颗 TPU 组成的 4×4×4 立方体，以三维环面拓扑结构可以进行互联，从而构建出超大规模的算力集群。TPUv7 标称的最大算力集群规模可达 9216 颗 TPU，但目前谷歌支持的 TPU 集群切片配置灵活多样，规模范围覆盖从 4 颗 TPU 到 2048 颗 TPU 不等。
尽管谷歌凭借技术创新，能够搭建起规模达 9216 颗 TPU 的超大型算力集群，但在实际运行训练任务时，将单次运算的集群块规模逐步提升至 8000 颗 TPU 左右后，其性能收益会呈现递减趋势。这是因为集群块规模越大，出现故障和运行中断的概率就越高，进而导致切片可用性下降。切片可用性的定义为：ICI 集群能够组建出完整三维环面拓扑切片的时间占比。
对于可完全容纳在单个 4×4×4 立方体拓扑内的算力切片，我们只需借助机架内的铜缆互联，以及立方体表面 / 棱边 / 顶角处的光模块，即可从该立方体中划分出这类切片；必要时，还可通过环回连接完成三维环面拓扑的构建。
要理解环回连接与跨立方体连接的实现方式，我们不妨先从如何在 4×4×4 拓扑中构建一个 64 颗 TPU 的算力切片说起。我们大家可以直接采用一个对应单台 64 颗 TPU 物理机架的 4×4×4 立方体拓扑单元来搭建该结构。
4×4×4 立方体拓扑内部的全部 8 颗 TPU，均可通过铜缆实现与 6 个相邻节点的全互联。若某颗 TPU 在某一坐标轴方向上没有内部相邻节点，则会通过环回连接与立方体相对侧的另一颗 TPU 互联。
例如，TPU（4,1,4）在 Z 轴正方向（Z+）上没有内部相邻节点，因此它会通过一个 800G 光模块接入分配给 Z 轴的光电路交换机（OCS）；经该光电路交换机（OCS）配置路由后，这条链路会被导向立方体的 Z 轴负方向（Z-）侧，最终与 TPU（4,1,1）建立连接。同理，TPU（1,1,1）会在 Y 轴负方向（Y-）上通过光模块接入 Y 轴对应的光电路交换机（OCS），进而与位于 Y 轴正方向（Y+）侧的 TPU（1,4,1）实现互联。
4×4×4 立方体的每个表面，都会通过16 立的光电路交换机（OCS）实现互联 —— 即表面上的每颗 TPU 对应一台光电路交换机。
举个例子，如下图所示：在 X 轴正方向（X+）表面，TPU（4,3,2）会接入光电路交换机 X,3,2 的输入端。这台光电路交换机 X,3,2 的输入端，还会与 9216 颗 TPU 集群中全部 144 个 4×4×4 立方体的 X 轴正方向（X+）表面上，同一编号（4,3,2）的 TPU相连。随后，该光电路交换机 X,3,2 的输出端，会与集群内所有立方体上同一编号的 TPU建立连接，但这一次连接的是这些立方体的X 轴负方向（X-）表面—— 也就是说，它会与集群内 144 个立方体上的 TPU（1,3,2）互联。下图展示了立方体 A 的 X 轴正方向（X+）表面上的全部 16 颗 TPU，如何通过 16 台光电路交换机，与立方体 B 的 X 轴负方向（X-）表面上的16 颗 TPU实现互联。
这类连接使得任意立方体的任意 “+” 方向表面，都能与其他任意立方体的 “-” 方向表面互联，从而在划分算力切片时，实现立方体资源的完全灵活调度。
第一，同一表面上同一编号的 TPU，无法直接与不同编号的 TPU建立连接 —— 例如，TPU（4,3,2）永远不能被配置为与 TPU（1,2,3）互联。
第二，由于光电路交换机本质上相当于一个配线架，接入其输入端的 TPU，无法 “环路回传” 至同样接入该光电路交换机输入端的其他任何 TPU—— 举例来说，TPU（4,3,2）永远不能与 TPU（4,3,3）互联。
因此，任意立方体 “+” 方向表面上的 TPU，都无法与其他任意立方体 “+” 方向表面的 TPU 互联；同理，任意立方体 “-” 方向表面上的 TPU，也无法与其他任意立方体 “-” 方向表面的 TPU 互联。
接下来我们逐步扩大规模，看看4×4×8 拓扑结构该如何搭建。在这种配置下，我们通过沿Z 轴互联两个包含 64 颗 TPU 的 4×4×4 立方体，来扩展算力切片的规模。此时，光电路交换机（OCS）会对 TPU（4,1,4）所连接的光端口进行重新配置，使其转而连接 TPU（4,1,5），而非像在独立的 4×4×4 拓扑中那样，环回连接至 TPU（4,1,1）。以此类推，这两个 4×4×4 TPU 立方体的 Z 轴负方向（Z-）和 Z 轴正方向（Z+）表面，各自会延伸出 16 条光连接链路，最终总计 64 股光纤会接入 16 台 Z 轴对应的光电路交换机（OCS）。
需要提醒读者的是，下图所示的立方体 A 和立方体 B，不一定在物理位置上彼此相邻。二者是通过光电路交换机（OCS）实现互联的，实际上它们能分别部署在数据中心内完全不同的区域。
接下来，我们将进一步拓展至更大规模的拓扑结构 ——16×16×16 拓扑，该结构的算力规模可达4096 颗 TPU。在这一拓扑中，我们共需使用48 台光电路交换机（OCS），来实现对64 组 4×4×4 立方体的互联（每组立方体包含 64 颗 TPU）。如下图所示，每个彩色立方体均代表一组由 64 颗 TPU 构成的 4×4×4 立方体。以位于右下角的这组 4×4×4 立方体为例 —— 它正是通过光电路交换机，实现了与 Y 轴方向相邻立方体的互联。
而9216 颗 TPU 的最大算力集群规模，则是由144 组 4×4×4 立方体搭建而成。每组立方体需要占用96 个光端口，整个集群的端口总需求量因此达到13824 个。若将这一总端口需求量除以288（即每台光电路交换机配备 144 个输入端口和 144 个输出端口），便可得出：要支撑这一最大算力集群规模，我们共需部署48 台 144×144 规格的光电路交换机。
谷歌这套独特的 ICI 扩展网络，除了能画出各种复杂精美的立方体拓扑图、让人花费数小时钻研之外，究竟还有哪些突出优势？
算力集群规模：最显而易见的优势，是 TPUv7 “铁木” 所支持的9216 颗 TPU超大算力集群规模。尽管受有效吞吐量下降的弊端影响，9216 颗 TPU 的最大切片规模可能极少被实际启用，但数千颗 TPU 级别的切片不仅具备可行性，且已得到普遍应用。这一规模远超商用加速芯片市场及其他定制芯片厂商普遍采用的 64 颗或 72 颗 GPU 集群配置。
可重构性与灵活调度性：光电路交换机（OCS）的采用，使得该网络拓扑天然具备网络连接重构能力，可支持多达数千种拓扑结构（理论上）。谷歌官方文档仅列出了 10 种不同的拓扑组合（即本节前文出现的拓扑图），但这些只是最常用的三维切片形态，实际可配置的拓扑方案远不止于此。
即便是相同规模的算力切片，也能通过不同方式完成重构。以下方的扭转二维环面拓扑这一简单案例来说明：我们大家可以看到，将链路环回至不同 X 坐标编号的节点，而非相同 X 坐标编号的节点，能够减少网络的最坏情况跳数与最坏情况对分带宽。这一优化有助于提升集群的全对全集合通信吞吐量。TPUv7 集群的拓扑扭转操作，正是在 4×4×4 立方体层级上完成的。
可重构性还为多样化的并行计算模式开辟了广阔空间。在 64 颗或 72 颗 GPU 的集群规模下，不同并行计算模式的组合方式通常局限于 64 的因数范围。而在 ICI 扩展网络中，可以在一定程度上完成与目标数据并行、张量并行及流水线并行组合精准匹配的拓扑方案不胜枚举。
光电路交换机（OCS）支持将任意立方体的任意 “+” 方向表面与其他任意立方体的 “-” 方向表面互联，这一特性意味着立方体资源具备完全灵活调度的能力。算力切片可由任意一组立方体构成。因此，即便出现硬件故障、客户的真实需求或使用情况出现变化，也不会阻碍新拓扑算力切片的构建。
成本更低：谷歌的 ICI 网络相比大多数交换式扩展网络，具备更低的部署成本。尽管因集成光环行器，所使用的 FR 光模块成本略高，但这种网状网络架构减少了所需交换机与端口的总数量，同时省去了交换机之间互联产生的相关成本。
低延迟与更优数据局部性：TPU 之间采用直连链路的设计，使得物理位置邻近或被重新配置为直连状态的 TPU，可以在一定程度上完成更低的传输延迟。位置相互邻近的 TPU，还会具备更优的数据局部性。
数据中心网络（DCN）是一套独立于 ICI 的专用网络，兼具传统后台网络与前台网络的双重功能。它能够覆盖更庞大的算力域 —— 以 TPUv7 集群为例，其可实现对14.7 万颗 TPU的互联。
正如我们在先前关于阿波罗计划的文章中所阐述的，谷歌提出用帕洛玛光电路交换机（OCS），替代传统 “胖树（Clos）” 架构中包含电子分组交换机（EPS）的核心层。基于这一理念，谷歌的数据中心网络由一个光交换式数据中心网络互联层（DCNI）构成，该互联层整合了多个聚合块，每个聚合块又分别与多个 9216 颗 TPU 规模的 ICI 集群相连。
2022 年，谷歌阿波罗计划曾提出一套数据中心网络架构，其中提到为 4096 颗 TPU 规模的 TPUv4 计算单元，配备 136×136 规格的光电路交换机。当时，数据中心网络互联层的光电路交换机被划分为 4 个阿波罗区域，每个区域最多部署 8 个机架，每个机架配备 8 台光电路交换机，总计 256 台。而针对 “铁木”（TPUv7），为了在同一网络中支撑多达 14.7 万颗 TPUv7，我们推测谷歌会选择将光电路交换机的端口数量提升近一倍，而非单纯增加光电路交换机的最大部署数量。
下图展示了一个可行的“铁木”数据中心网络架构方案：该方案采用 32 个机架，共部署 256 台 300×300 规格的光电路交换机。假设每个聚合块的核心层之间不存在带宽超配，那么该数据中心网络最多可连接 16 个 ICI 计算单元 —— 具体为 4 个聚合块，每个聚合块连接 4 个 ICI 计算单元，对应的 TPU 总数达147456 颗。
数据中心网络互联层承担着连接 4 个聚合块的作用，在下图中表现为最顶层的架构。与 ICI 网络一致，该层同样采用FR 光模块与光电路交换机相连，以此最大化每台光电路交换机的单端口带宽。
尽管当前的 “铁木”（Ironwood）集群可能仅配备 1 至 2 个聚合块，但谷歌数据中心网络（DCN）独特的架构设计，允许在无需大规模重新布线的前提下，向网络中新增 TPU 聚合块。
通过在数据中心网络互联层（DCNI）部署光电路交换机（OCS），数据中心网络架构的规模可实现增量扩展，同时网络可重新配置链路，以适配新增的聚合块。此外，聚合块的带宽能够独立升级，而不必改动数据中心网络层的整体架构。这在某种程度上预示着，现有聚合块的链路速率可进行更新迭代，且不会改变网络本身的核心架构。当然，网络架构的扩展并非无上限 —— 当规模达到一定量级后，重新布线的操作将变得难以管控。
传统上，TPU 的软件与硬件团队均以对内服务为导向。这种模式具备一定优势，例如不会受到经营销售团队的压力，去夸大标称的理论浮点运算性能（FLOPs）。
仅聚焦对内服务的另一大优点是，TPU 团队能够将工作重心高度放在响应内部功能需求与优化内部负载任务上。但相应的弊端也十分明显：团队对外部客户及外部负载的关注度极低。这直接引发 TPU 生态中的外部开发者数量，远低于 CUDA ECO。而这一点，也是 TPU 与其他所有非英伟达（Nvidia）加速器共同存在的核心短板。
此后，谷歌调整了面向外部客户的软件战略，并对 TPU 团队的关键绩效指标（KPIs）以及其参与人工智能 / 机器学习（AI/ML）生态建设的方式，做出了重大调整。我们将重点探讨其中两项核心变革：
1.投入大量工程资源，实现 PyTorch 框架对 TPU 的原生支持2.投入大量工程资源，为 vLLM 与 SGLang 大模型推理框架提供 TPU 支持
观察谷歌在各 TPU 软件代码仓库的贡献量，其对外开放战略的推进路径清晰可见。我们也可以发现，自 3 月起，谷歌针对 vLLM 的代码贡献量出现明显地增长。随后在 5 月，官方推出了 “tpu-inference” 代码仓库，作为 vLLM 框架的 TPU 统一后端；自此之后，该仓库的开发活跃度便进入了快速地增长阶段。
这就导致了一个问题：对那些习惯在 GPU 上使用 PyTorch CUDA 原生后端、如今尝试切换到 TPU 的外部用户而言，他们要面对体验欠佳的非原生开发环境。
10 月，谷歌 “王牌技术带头人” 罗伯特・亨特在 XLA 代码仓库中低调宣布，团队将摒弃非原生的惰性张量后端，转而开发一款原生 TPU PyTorch 后端。该后端默认支持即时执行模式，同时可与ile、DTensor 以及torch.distributed等编程接口实现集成。这项技术将基于PrivateUse1 TorchDispatch 功能键来构建。
开发该原生后端的首要目标客户是元宇宙公司（Meta）—— 该公司近期重新燃起了采购 TPU 的兴趣，但并不打算迁移至 JAX 框架。此外，这一举措也能让那些偏好 PyTorch、却不适应 JAX 的开发者，顺利用上 TPU。
早在 2020 年至 2023 年间，元宇宙公司旗下的 FAIR 实验室已有多个团队重度使用基于 TPU 的 PyTorch XLA 方案，但该方案始终未能实现广泛推广。最终，元宇宙公司管理层于 2023 年终止了相关合作协议。究其原因，基于 TPU 的 PyTorch XLA 使用体验确实不尽如人意。更值得一提的是，当时元宇宙 FAIR 团队在谷歌云平台（GCP）上运行 TPU 时，采用的是 SLURM 调度系统，而非 TPU 技术栈中常见的 GKE、Xmanager 或 Borg 等工具。
这款全新的 PyTorch-TPU 原生适配方案，将为习惯在 GPU 上使用 PyTorch 的机器学习科学家们，提供更顺畅的迁移路径，助力他们切换至 TPU 平台运行 PyTorch 代码，并充分的发挥 TPU 更高的单位总拥有成本性能优势。
Pallas 是一门专用于为 TPU 编写自定义算子的内核开发语言（功能类似 cuTile、Triton 或 CuTe-DSL）。元宇宙公司（Meta）与谷歌也已启动相关合作，致力于将 Pallas 算子纳入 Torch Dynamo/Inductor 编译栈的代码生成目标范畴。这一举措将实现 TPU 与 PyTorch 原生pile 接口的深度集成，同时允许终端用户将自定义的 Pallas 算子注册到 PyTorch 框架中使用。
除了核心的 PyTorch 原生内置编程接口外，相关团队还在幕后推进一项工作 —— 将 TPU Pallas 算子语言整合为Helion 的代码生成目标。你可以将 Helion 理解为一种高级编程语言，能够用高级语法编写性能优良的算子。由于其设计与 PyTorch 原生 Aten 算子的契合度极高，用户都能够将 Helion 视作底层 Aten 算子，而非 Triton、Pallas 这类高级算子开发工具。
CUDA ECO的另一项非常大的优势领域，在于开源生态推理场景。从历史来看，vLLM 与 SGLang 均将 CUDA 列为一等支持对象（而将 ROCm 视作二等支持对象）。如今，谷歌也希望入局 vLLM 与 SGLang 开源推理生态，并已宣布通过一种极具 “独特性” 的集成方案，推出面向 vLLM 与 SGLang 的 TPU v5p/v6e 测试版支持。
谷歌与 vLLM 声称，这种向 JAX 转换的实现路径无需对 PyTorch 模型代码进行任何修改，但考虑到目前 vLLM TPU 支持的模型数量寥寥无几，我们对此说法存疑。
此外，谷歌已将部分自研 TPU 算子开源并集成至 vLLM 中，例如经过 TPU 优化的分页注意力算子、支持计算 - 通信重叠的矩阵乘法算子，以及若干量化矩阵乘法算子。不过，其暂未推出适配机器学习加速器（MLA）的 TPU 算子。需要我们来关注的是，待 Inductor Pallas TPU 代码生成集成方案更为成熟后，能否将算子融合与模式匹配功能整合进 vLLM 现有的Pass 管理器中。与此同时，SGLang 也在研究实现一个基于torch.compile的 Pass 管理器，以更便捷地管理多模型场景下的算子融合流程。
在非规整分页注意力 V3的实现上，TPU 的解决方法与 vLLM GPU 版本截然不同。vLLM GPU 版本采用类虚拟内存与分页的技术来管理键值缓存（KV Cache），但该技术需要获取动态地址并执行散乱操作，而这两项操作恰好是 TPU 的短板。为此，TPU 算子转而采用细粒度操作流水线的设计思路。具体而言，TPU 的分页注意力算子会预先抓取下一个序列的查询（Query）与键值（KV）数据块，以此来实现内存加载与计算过程的并行执行。
在现有的 vLLM 混合专家模型（MoE）算子中，其执行流程为：先按专家 ID 对令牌（Token）进行排序，再将令牌分发至搭载对应专家网络的设备，执行分组矩阵乘法运算，最后将各专家网络的计算结果汇总回原设备。然而，该算子性能表现不佳，问题大多有两点：一是 TPU 的排序操作效率低下；二是该算子没办法实现计算与通信的并行化。
为解决这一问题，谷歌研发人员设计了全融合混合专家模型（All-fused MoE）。该方案采用 “单设备单次调度单个专家网络令牌” 的策略，同时实现了混合专家模型调度与结果汇总阶段的通信并行化，并规避了按专家 ID 排序令牌的操作。谷歌工程师透露，相比现有算子，全融合混合专家模型算子的性能提升了 3 至 4 倍。
此外，TPU 中还搭载了另一款硬件单元 ——稀疏计算核心（SparseCore，简称 SC），其作用是加速嵌入层的查找与更新操作。稀疏计算核心包含一个标量子核心稀疏计算核心序列器（SparseCore Sequencer，简称 SCS），以及多个矢量子核心稀疏计算核心运算单元（SparseCore Tiles，简称 SCT）。
与 TPU 张量核心（TensorCore）512 字节的加载粒度相比，SCT 支持以 4 字节或 32 字节的更精细粒度执行本地及远程直接内存访问。这一特性使得稀疏计算核心能够在与张量核心运算并行执行的同时，完成聚合 / 分散（gather/scatter）操作以及 ICI 通信。
在 JAX 开发者实验室（JAX DevLabs）的交流中我们不难发现到，稀疏计算核心的可编程性目前仍处于开发完善阶段。我们大家可以期待 TPU 自定义算子编译器 Mosaic 未来将以 ** 多程序多数据（MPMD）** 模式完成编译工作 —— 在该模式下，SCS 与 SCT 可执行不同的算子，不同的稀疏计算核心也能够运行各自独立的程序。我们推测，一旦稀疏计算核心的可编程性达到成熟水平，TPU 的混合专家模型（MoE）算子将有望实现与 GPU 类似的调度和结果汇总操作，而无需再通过专家 ID 来分发令牌数据。
在解耦式预填充 - 解码技术方面（我们已在《AMD 2.0》一文中进行过深入阐述），谷歌目前在 vLLM 框架上仅实现了单主机解耦式预填充 - 解码的实验性支持，尚未支持多主机级的宽弹性处理器（wideEP）解耦式预填充或多张量处理（MTP）技术。这些推理优化手段对于降低每百万令牌的总拥有成本（TCO）、提升每美元算力性能及每瓦算力性能至关重要。此外，谷歌还未将 TPU 的 vLLM 推理支持整合至 VERL 等主流强化学习框架中。总体而言，在布局开放式人工智能 / 机器学习生态，尤其是打造 TPU “原生” 后端的战略方向上，谷歌正缓步推进并走在正确的道路上。
本周有一项针对 TPUv6e 的全新推理基准测试结果公布，该结果宣称 TPUv6e 的每美元性能较英伟达 GPU 低 5 倍。我们对此结论持反对意见，根本原因有两点：
其一，该测试基于刚推出仅数月的 TPU 版 vLLM，其性能尚未经过充分优化。而谷歌内部的 Gemini 模型负载以及 Anthropic 公司的模型负载，均运行在自研的定制推理栈之上，该推理栈的每总拥有成本性能表现优于英伟达 GPU。
其二，该分析机构（Aritifical Analysis）在计算每百万令牌成本时，采用的是TPUv6e 每小时每芯片 2.7 美元的标价。但考虑到 TPUv6e 的物料清单成本（BOM）仅为 H100 芯片的极小一部分，没有一点一家 TPU 大客户会以接近该标价的价格采购 TPUv6e。众所周知，大多数云服务供应商都会刻意抬高公开标价，这样其销售负责人就能采用类似 “汽车销售” 的策略，为客户提供大幅折扣，让客户产生 “占了大便宜” 的错觉。而半导体行业分析机构（SemiAnalysis）的人工智能总拥有成本模型，追踪的是不同合同周期（1 个月、1 年、3 年等）内 TPU 在市场上的实际租赁价格。
