甲骨文首供谷歌 TPU：2027 年上线 8t 与 8i，单芯片 12.6 PFLOPS

一句话结论：2026 年 10 月 27 日在拉斯维加斯举行的 Oracle AI World 大会上，甲骨文宣布将成为谷歌之外首家提供谷歌 TPU 的超大规模云服务商，第八代 TPU 的训练版 8t 与推理版 8i 预计 2027 日历年上线 OCI，单芯片 FP4 算力最高 12.6 PFLOPS，大规模训练 goodput 超过 97%，低延迟服务每美元性能最高提升 80%，这三组数字均出自谷歌自己的口径。

对行业来说这是一次供应格局的位移。谷歌自研的 TPU 十多年来主要服务自家搜索与 Gemini 训练体系，甲骨文是第二家愿意把它放进自己数据中心对外销售的云厂商。而同一天公布的另一组消息更能说明当下的现实：甲骨文同时宣布大规模部署英伟达 Vera Rubin 系统，部署规模达到数吉瓦级，并在基于英伟达芯片的系统里用自研 Acceleron 网络芯片替换掉一部分英伟达网络芯片。一家云厂商在同一场发布会上同时讲四种芯片的故事，本身就说明当前的算力选择已经不再是单一答案。

甲骨文为何要接下谷歌的芯片

甲骨文云基础设施总裁马赫什·蒂亚加拉詹给出的理由很直接，不同的 AI 工作负载对计算资源有不同需求，把多种主流计算架构放进同一个云，客户才能按性能、吞吐和成本效益分别匹配基础设施。这句话听着平淡，但它对应的是甲骨文过去两年最痛的一个问题：它的客户开始要求自己指定芯片。

上个月财报电话会上，甲骨文提到客户正越来越多地自行承担芯片采购费用，预计 2027 财年相关支出将达到约 900 亿至 950 亿美元。这笔支出的性质与甲骨文自己买 GPU 再转售完全不同，它意味着大批大客户带着英伟达订单走进了 OCI 的机房，用甲骨文的电力、冷却和数据中心网络跑自己的机器。如果这些客户连推理侧都想自己指定供应商，那么甲骨文手里只有 GPU 一张牌显然不够看。

谷歌那边给出的动机同样直白。谷歌云的技术负责人在博客里写道，全球对 AI 算力的需求超过了任何单一云服务商的承载范围。对一家自有数据中心选址、电力接入、冷却容量都在快速消耗的公司来说，把 TPU 部署到别人的机房里，是一条不需要自己去找电力和土地的扩容路径。谷歌首席技术官 Amin Vahdat 的说法是，下一代 AI 需要多样化的算力供给。

这构成了一次典型的竞合错位。谷歌云与甲骨文在数据库、企业应用和云服务市场长期正面竞争，但当算力需求涨到单一厂商吃不下的量级时，合作反而成了更经济的选择。类似逻辑在OpenAI 模型进入谷歌云 Model Garden那一步已经出现过一次，不同的是那次是模型上架，这次是芯片本身被搬进了对方的机房。

TPU 8t 与 8i 的分工，以及那三组数字

这次对外供应的是谷歌第八代 TPU，两个架构面向完全不同的任务。8t 面向训练，8i 面向推理，谷歌在描述 8i 时特别点名了多智能体场景，也就是多个智能体在推理过程中反复调用模型、检索数据、执行工具的那种工作负载。

三个数字值得单独看一眼。3 倍指每 pod 计算性能相比上一代的提升，这是训练侧的指标，谷歌的说法是把前沿模型的开发周期从几个月压缩到几周。97% 的 goodput 指集群实际用于有效工作的时间占比，它衡量的不是峰值算力而是长时间训练任务的稳定性，集群因为故障或调度空转损失掉的那部分时间被扣掉了。80% 的每美元性能提升针对低延迟推理场景，口径是同样一美元能买到多少服务吞吐。

这些数字都需要加一层理解。它们出自谷歌自家博客，属于厂商自测口径，尚未有第三方在 OCI 环境下复现的成本数据。更关键的是，谷歌开源 TorchTPU 让 PyTorch 零改动迁移到 TPU这件事在这里的作用比数字本身更大：如果迁移代码的成本足够低，客户才有动力把现有工作负载搬到 OCI 上试一次，否则再好的每美元性能也只停留在对比表里。

基础设施细节：液冷、光交换机与 Acceleron

把 TPU 放进别人的机房，物理层面的约束比商务条款更硬。谷歌的 TPU 系统按机架规模直接液冷设计，需要甲骨文的新数据中心按这类负载来建。集群内部的流量由谷歌自己的芯片间互联和光交换机承担，谷歌表示这些光交换机可以在绕开故障点的同时不中断作业，这对长达数周的前沿模型训练是实打实的可靠性差异。

集群与 OCI 其余部分之间的连接由甲骨文的 Acceleron 网络承担，负责把 TPU 集群与甲骨文数据库和存储连起来。这一点是甲骨文真正的差异化落点。谷歌的说法是，跑在 OCI 内部意味着客户可以把模型微调和推理直接放到自己的 Oracle 数据库旁边，不必支付跨云传输的成本。对把核心业务记录放在 Oracle 里的企业来说，这条路径省下的不只有带宽费用，还有数据移动带来的合规审查环节。

从芯片供给的角度看，这套基础设施布局还包含一层战略意味。甲骨文的 OCI Supercluster 组合是 Acceleron 加英伟达 Spectrum-X 以太网网络、Spectrum-6 交换机和 BlueField-4 数据处理单元，未来还要用 Acceleron 去连 TPU 集群与数据库、存储。也就是说，英伟达体系里那个由 Spectrum-X 承担的交换层角色，甲骨文打算用自研芯片逐块接过去。英伟达把 GPU 折旧年限改口到 8 年这件事之所以让市场在意，正是因为自研网络与自研加速器同时推进会改变整机的价值构成结构。

英伟达线同步扩容，Cerebras 与 SambaNova 排队进场

同一天公布的英伟达部分规模并不小。甲骨文与英伟达确认，将在 OCI Supercluster 中大规模部署英伟达最新一代 Vera Rubin AI 服务器，部署规模达到数吉瓦级，具体金额未披露。黄仁勋此前给出的口径是，Vera Rubin 系统每吉瓦的部署规模可为英伟达带来最高 400 亿美元收入。同时，Vera Rubin NVL72 系统与英伟达 Vera CPU 即日起在 OCI 正式全面可用。

Vera CPU 的引入值得单独说一句。GPU 负责模型计算，CPU 负责在模型调用之间执行工具、测试代码、检索数据这类动作，也就是智能体真正跑起来之后的编排开销。甲骨文表示客户可以在 OCI 上独立扩展 CPU 与 GPU 资源，减少闲置容量，这背后是智能体负载把 CPU 需求重新拉起来的现实。相关背景可以参照谷歌 Agent Compute Engine 的微虚拟机挂起恢复机制那篇稿子里的同类问题。

甲骨文还计划引入英伟达 HGX Rubin NVL8 配置，在 x86 服务器配置中通过 NVLink 连接八颗 Rubin GPU，配两颗 64 核英特尔至强 6 处理器、4TB DDR5 内存与 6.4Tbps 高速 RDMA 网络，为训练、微调与推理提供比 72 GPU 的 NVL72 更小规模的部署选项。

推理侧的另外两张牌是 Cerebras 与 SambaNova。甲骨文计划提供 Cerebras Systems 的 Wafer-Scale Engine 推理服务，其架构把计算与内存做在同一块晶圆级处理器上以减少芯片间数据搬运，官方说法是能支撑多步应用的更快 token 生成。英特尔投资的 SambaNova 则以 SambaRack SN50 推理芯片的形式进入 OCI 数据中心。两家的服务同样计划在 2027 年推出，定位都是面向延迟敏感的推理场景。

至此甲骨文的算力牌桌摆成了这样：

甲骨文的账本：6640 亿美元在手订单与 900 亿资本开支

把算力供给讲完，再看支撑这套供给的财务数字。截至 2026 年 8 月 31 日的 2027 财年第一季度，甲骨文云基础设施收入 74 亿美元，同比增长 121%。公司总收入 193 亿美元，同比增长 30%。尚未确认为收入的合同履约义务余额达到 6640 亿美元。单季资本开支约 285 亿美元，而去年同期只有 85 亿美元。

最值得留意的是这个对比：单季资本开支从 85 亿涨到 285 亿，翻了三倍多，公司却维持了 2027 财年 900 亿至 950 亿美元的资本开支指引，没有上调也没有下调。这个指引是在 9 月的财报电话会上给出的，意思是一个季度花掉的 285 亿，在剩下的三个季度里还要再花 615 亿到 665 亿。

单季还交付了 850 兆瓦的新增数据中心容量。硬件缺口部分靠两种方式填平：一是让大客户预付或自己供货，6 月披露的口径是这部分合计 750 亿美元；二是把芯片采购责任推给客户，这正是本次 TPU 合作所处的背景。

这也解释了甲骨文为什么愿意接下非自研芯片的多供应商策略。资本开支指引已经锁定在 900 亿到 950 亿这个量级，在这个约束下，让客户自己指定芯片并自己承担采购，比甲骨文自己压货再去消化库存要安全得多。甲骨文与 OpenAI 同日推出的四款企业产品里那句 1.2 万美元 OCI 额度年配，与这次芯片侧的多样化，指向的都是同一件事：把算力资产的持有成本往外移。

落地之前需要盯的四件事

第一是价格。谷歌和甲骨文都没有公布 TPU 在 OCI 上的定价、可用区域和首批客户名单，容量规模也没有披露。在这些数字出来之前，所谓每美元性能提升 80% 无法换算成任何一张账单。

第二是 2027 这个时间点带来的执行风险。谷歌说的是 2027 日历年上线并在此后多年逐步扩大规模，对应的硬件交付窗口、机房改造周期和软件适配节奏都还没细化成时间表。同时 OCI 内部还有英伟达体系、Cerebras、SambaNova 几条线并行推进，一套数据中心要同时容纳四种不同的加速器、互连方案和运维流程，这对工程能力是实打实的考验。

第三是软件迁移成本。TPU 的性能优势是在谷歌自己的软件栈里测出来的，TorchTPU 降低了 PyTorch 侧的门槛，但 JAX 生态、推理服务框架、第三方算子库的覆盖度，以及多智能体框架在 TPU 上的实际表现，目前都没有公开的完整评估。谷歌把 TPU 送进轨道的 Project Suncatcher 项目处理的是散热极限，而甲骨文机房这一侧要解决的是运维复杂度。

第四是这批 TPU 在 OCI 上究竟服务谁。甲骨文的既有优势是企业数据库与行业应用，最直接的受益方是数据本来就在 Oracle 体系里的客户，而不是从 Google Cloud 迁移过来的训练型客户。这条路径能不能走通，取决于 OCI 的定价体系、计费模型和实例形态是否对这类企业足够友好，而目前这些都还没公布。

常见问题

甲骨文什么时候能买到谷歌 TPU

谷歌云博客的说法是 2027 日历年开始在 OCI 部署 TPU 容量，甲骨文新闻稿的表述是 2027 日历年提供并在此后多年逐步扩大规模以满足客户需求。目前没有公布价格、可用区域和首批客户名单。

TPU 8t 和 8i 应该怎么选

8t 面向训练，官方口径是每 pod 计算性能相比上一代接近 3 倍，可把前沿模型开发周期从几个月压到几周。8i 面向推理，特别针对多智能体这类反复调用模型与工具的工作负载，低延迟服务的每美元性能最高提升 80%。简单说，训练选 8t，线上服务选 8i。

在 OCI 上用 TPU 是不是比用英伟达 GPU 更划算

现在无法回答，因为价格未公布。可比较的只有硬件侧指标：单芯片 FP4 算力最高 12.6 PFLOPS、大规模训练 goodput 超过 97%、低延迟服务每美元性能最高提升 80%。真正的成本差要看实际实例定价、可用区域与迁移成本，而这三点目前都还是空白。

小结

这次公告的实质，是一场算力供给的重新分工。谷歌用甲方的机房和电力换自己芯片的更广泛落地，甲骨文用多供应商策略降低自己在 900 亿至 950 亿美元资本开支指引下的资产风险，客户则多了一个在英伟达之外做算力比价的选择。3 倍 pod 算力、97% goodput、80% 每美元性能提升这三个数字值得关注，但它们全部来自谷歌自己的口径，且要等到 2027 年才会在 OCI 上变成可以下单的服务。对甲骨文来说，真正的考验是把四种加速器塞进同一套数据中心之后，能不能让客户选起来简单、用起来不踩坑。

相关阅读

• 谷歌开源 TorchTPU：PyTorch 零改动迁移 TPU，CUDA 十年护城河首现裂痕
• 谷歌 TPU 首次进入太空：Project Suncatcher 原型卫星入轨，挑战 15 分钟散热极限
• 甲骨文联手 OpenAI 推 4 款企业产品：1.2 万美元额度与 13 万用户
• OpenAI 模型上谷歌云：GPT-6 Astra 等 3 款进 Model Garden
• 英伟达 GPU 寿命改口 8 年：残值 158% 与 1194 基点 CDS 分歧