Oracle Google TPU 合作将于 2027 年把 Google 的 AI 芯片引入竞争对手云平台

Oracle 将于 2027 年通过其云平台提供 Google 的 AI 芯片，成为首家在 Google 之外提供该芯片的超大规模云服务商。10 月 27 日公布的 Oracle Google TPU 合作，将 Google 专为 AI 设计的处理器 Tensor Processing Units 引入 Oracle Cloud Infrastructure（OCI）。这一变化让用户无需选择 Google 作为云基础设施提供商，也能使用 Google 的芯片。

这为 Nvidia 带来了不同的竞争格局。其图形处理器，即 GPU，同样用于训练和运行 AI 模型。Oracle 在延续与 Nvidia 合作关系的同时，正扩大加速器选择。客户将在 OCI 内获得另一种可评估的架构，但双方尚未明确哪些工作负载将从中获益最多。

这一差异对企业买家至关重要。新的芯片选项可以改变基础设施规划，却不一定立即改变应用的经济性。该公告确立了自 2027 年起的部署计划，并将在随后数年持续扩展。可用性、软件兼容性和实测结果，将决定客户最终能获得多大程度的实际选择空间。

Oracle Google TPU 合作究竟改变了什么

Google 的 AI 硬件正获得又一个主要云分发渠道，而 Oracle 则在其基础设施产品组合中增加了一种加速器架构。

双方在拉斯维加斯举行的 Oracle AI World 上宣布了这项安排。Oracle 表示，将提供在 OCI 内部署 Google TPU 所需的电力、冷却和数据中心网络。其 TPU deployment plan 指明将于 2027 日历年启动，并在多年期间逐步增加容量。

这一时间表值得仔细解读。一项服务在某个日历年内启动，并不意味着会立即面向所有区域或客户账户开放。同样，多年扩展描述的是部署过程，而不是已完成的基础设施覆盖范围。买家仍需要了解该公告如何与其所在地区及运营要求相衔接。

“首家提供商”的说法也有明确边界。Oracle 将成为 Google 之外首家提供 Google TPU 的超大规模云服务商。超大规模云服务商运营着极大规模的云基础设施。该公告并不意味着外部机构此前从未使用过这些处理器，也不表示此前每一次部署都要求 Google 拥有客户业务。

眼下的变化在于，机构可通过大型云平台获取这些硬件的地点。这一区别让该公告不同于普通的容量扩张。增加现有处理器的数量，只会提升供应；增加另一种架构，则会改变客户能够做出的技术决策组合。

这里涉及两项独立选择：选择加速器，以及选择云服务提供商。二者往往会通过软件支持、可用基础设施和采购安排相互关联。对于同时关注 Google 处理器和 Oracle 基础设施的客户，这项合作放松了这种绑定关系。

但它并未完全消除这种关联。工作负载仍依赖周边的存储、网络、安全控制和运营工具。更换处理器供应商，并不会让这些依赖消失。实际问题在于，Oracle 能否提供完整的运行环境，使新增架构真正具备实用价值。

双方将大模型训练、推理和智能体应用列为预期用途。训练会调整模型参数；推理则运行训练后的模型以生成输出。智能体是利用模型完成多步骤任务的应用。这些类别界定了拟议范围，而非对特定应用效果的保证。

因此，对客户而言，这一公告应纳入基础设施规划。它让机构有理由审视另一条部署路径。但这尚不足以证明现有工作负载应当迁移，或新项目应当等待。

企业买家获得了不同的议价地位

其商业意义在于，企业可评估另一种加速器，而无需自动将周边应用迁移至另一朵云。

Google 和 Oracle 将其 enterprise data strategy 与在已存储于 OCI 的信息附近部署 AI 处理能力联系起来。双方还描述了将 TPU 容量与 Oracle 网络和基础设施整合的计划。这些是合作伙伴提出的潜在优势，而非针对客户部署的独立实测结果。

以一个回答内部运营记录相关问题的企业应用为例。模型执行只是服务的一部分。该应用还必须检索经过授权的信息、实施访问控制、处理请求并返回有用答案。将模型计算迁往其他地点，可能会在这些环节上引入额外的架构决策。

在现有云中提供另一种处理器，会改变这种评估。机构可以研究该加速器，而无需先将更大范围的云迁移视为前提条件。这是否能改善应用，仍取决于其实际部署情况，包括相关服务和数据所在的位置。

这对采购假设的影响不亚于对处理器规格的影响。此前仅评估熟悉架构的团队，有理由重新审视这一决定。基础设施供应商必须说明其选项为何适合该工作负载，而不能完全依赖客户既有的部署模式。

当应用拥有可重复的工作内容和可衡量的运营要求时，这种压力最为明显。买家可以比较已完成请求量、响应时间、输出质量和工程投入。没有这些衡量标准，更多的硬件选择可能只会带来更长的供应商演示，而非更好的采购决策。

拥有替代方案与能够使用替代方案之间也存在差别。可信的替代方案需要兼容的软件、可获得的容量，以及能够运维它的人员。已宣布的服务，无法提供与满足机构要求的经验证部署相同的谈判地位。

Oracle Google TPU 合作为达成这一地位开辟了路径。其商业效果取决于有多少客户能够把这条路径转化为可运营的选项。仅对狭小群体开放的专业服务，与广泛可用的基础设施将产生不同后果。

Google 通过与云竞争对手合作，可能获得分发层面的收益。Oracle 则获得了服务考虑采用专用 AI 硬件客户的另一种方式。这些利益可以相互契合，并不意味着两家公司在所有其他市场中都立场一致。

企业买家也应认识到同样的区别。供应商可以在基础设施层面合作，同时争夺应用的其他部分。采购决策需要明确每个组件由哪一方提供，以及完整服务表现不佳时谁仍承担责任。

该公告将采购讨论转向工作负载部署位置。更有价值的问题是，哪种架构能够在客户的运营约束内交付所需结果。这一框架为买家评估扩大的选择空间提供了具体方法。

Google TPU 与 Nvidia 的比较成为 OCI 内的工作负载决策

Oracle 的公告扩大了与 Nvidia 的比较范围，同时保留了 Nvidia 在其云基础设施计划中的位置。

Nvidia 和 Oracle 也在 10 月 27 日宣布扩大合作。双方的 Vera Rubin expansion 包括新增 AI 基础设施的计划，并称 Vera Rubin 系统将在 OCI 上全面可用。这直接使“Oracle 正放弃 Nvidia”的解读难以成立。

竞争格局的变化，是同一供应商内部提供了更广泛的选择。Nvidia 仍是供应商，而 Google 则获得了进入这一环境的渠道。对客户而言，相关比较不再只是判断哪家公司整体芯片更优。

Google TPU 与 Nvidia 的评估需要界定明确的工作负载和双方认可的成功衡量标准。训练团队可能更看重达到可接受模型质量所需的时间。应用团队则可能更重视在预期流量下响应的一致性。这些目标可能导向不同的硬件决策。

软件投入同样重要。现有部署可能包含与当前架构绑定的库、自定义操作、监控工具和流程。若能避免额外的工程工作，保留这一环境本身就有价值。替代方案必须带来足够收益，才能证明其所需变更是合理的。

反过来，启动合适新项目的团队需要保留的历史决策更少。他们可以在建立广泛的运营依赖之前评估可用架构。即便如此，初期的有利结果也无法解决长期支持、可靠性或未来模型变化等问题。

在跨硬件家族运营方面，已有值得参考的客户先例。Anthropic 表示，其 mixed hardware strategy 使用 AWS Trainium、Google TPU 和 Nvidia GPU 来训练和运行 Claude。该声明表明，一家大型模型开发商已将加速器选择视为组合决策。

但这一案例应保持在其适用范围内。Anthropic 的基础设施选择并不能证明每家企业都能以类似方式经济地运营混合架构。模型开发商的工程资源和工作负载规模，可能与普通应用团队存在显著差异。

因此，竞争压力最终要通过证据体现。Nvidia 的产品必须继续在相关工作负载中对替代方案保持吸引力。Google 必须证明其处理器能够通过另一种云环境创造价值。Oracle 则必须让这些替代方案易于使用，而非让客户自行拼凑每一个运营细节。

这些要求都不意味着必须出现一个通用赢家。供应商可以为成熟工作负载保留一种架构，并为不同任务采用另一种架构。客户也可能得出结论：额外复杂性超过预期收益。

真正的变化在于，更多此类评估可以在 OCI 内进行。这让 Google 获得了争取工作负载的另一机会，也让 Oracle 增加了可供展示的选项。Nvidia 的地位将取决于客户成果，而非仅仅取决于公告本身。

TPU 8t 和 TPU 8i 面向 AI 需求的不同部分

Google 最新一代 TPU 区分了训练与推理设计，进一步凸显了应比较完整工作负载而非仅看处理器标签的必要性。

Google 推出了第八代 TPU 系列，并采用差异化架构：TPU 8t 面向训练，TPU 8i 面向推理。其 TPU 架构细节介绍了不同的内存配置和芯片通信设计。该公司将这些差异定位为服务于模型开发和运行的不同需求。

该系列的存在并不能确定客户将获得的确切 OCI 配置。合作公告提及了这些处理器，但买家仍需要服务文档来说明可用型号和部署安排。产品架构与云服务可用性是相关事实，但其所需的证据标准不同。

这种设计分化有助于解释此次合作的时机。训练模型与运行应用服务对基础设施提出了不同目标。前者涉及通过反复计算产出有用模型，后者则涉及在应用的流量、响应速度和质量要求下交付结果。

智能体应用还增加了另一项考量，因为模型调用只是更长流程的一部分。应用可能检索信息、生成建议操作、执行工具，并评估结果。改进模型执行会影响这条流程，但整体结果也取决于其他阶段。

例如，一个假设中的客服智能体可能会花费大量时间等待外部业务系统。更快的模型处理只能改善其完成时间的一部分。另一种模型计算时间更长、外部延迟更少的应用，则会呈现不同的评估结果。

因此，评估推理硬件应依据应用的运行模式。平均响应时间可能掩盖令用户沮丧的慢请求。高处理吞吐量在必须依赖应用无法接受的延迟才能实现时，其价值可能较低。

训练也存在自身的衡量难题。处理器宣传的计算能力并不直接等同于完成一个有用模型所需的时间。准备工作、通信、中断和评估都会影响已完成的任务。买家需要能够反映其目标成果的测量指标。

同样的推理也适用于能效声明。针对处理器或系统报告的改进，并不会自动反映整个已部署应用的情况。存储、网络、利用率和辅助计算仍是运行环境的一部分。

Google 的架构说明为研究这些硬件提供了理由，但不能替代客户自身的测量。当 Google 环境中的规格出现在有关未来 OCI 服务的讨论中时，这一区别尤为重要。

一项有说服力的部署结果应明确模型、工作负载、软件环境和质量目标，并说明哪些内容发生了变化、哪些条件保持可比。这样，其他组织才能评估该结果是否适用于自身应用。

因此，这种架构分化加强了选择性采用的理由。各组织有理由考察其 AI 工作的哪些阶段适合每种选择，但没有足够理由期待单一处理器系列能够解决所有基础设施限制。

软件可移植性仍是一个悬而未决的运营问题

当应用在迁移后能够保持行为一致且仍易于管理时，使用另一种加速器才真正有价值。

Google 介绍了 TPU 软件支持方面的改进，包括对常见开发工具的支持。这些努力回应了一项重要的采用要求。熟悉的接口可以减少开发人员需要修改的应用代码量。

不过，保留熟悉的工具并不能证明其在不同硬件环境中具有完全一致的行为。库、数值计算和执行模式可能产生不同的交互。一个能够成功启动的程序只是通过了初步门槛，准确性和运营适配性仍需进一步检验。

最近一项 GPU 到 TPU 迁移研究说明了这一区别。研究人员考察了十个机器学习研究项目中由编程智能体辅助完成的迁移。其中八个满足其项目目标标准，但作者也报告了未产生任何错误提示的失败案例，以及一个训练行为发生变化的案例。

该研究有重要局限。它考察的是一个规模较小的研究样本，而非已宣布的 OCI 服务。其结果不能确立企业部署的失败率，也无法预测 TPU 8t 和 TPU 8i 在 OCI 上的性能。

它的方法论意义在于：仅仅成功执行不足以证明迁移成功。组织需要验证预期硬件确实完成了工作、模型保持可接受的行为，以及应用满足其运营要求。

对于推理，这包括在检查响应时间和处理能力的同时验证输出质量。如果答案变得不那么可靠，更快的部署价值有限。为使工作负载适应不同环境而调整设置时，同样适用这一原则。

对于训练，团队需要检视最终模型，而不仅是训练任务是否完成。差异可能在长时间执行后出现，也可能源于与辅助软件的交互。因此，验证应纳入评估预算。

运营责任同样重要。客户需要明确的问题诊断路径，涵盖应用代码、执行软件和云基础设施。一次虽然获得了亮眼指标、却需要持续专业人员介入的迁移，可能带来沉重的支持负担。

这些顾虑是要求证据的理由，而不是否定此次合作的理由。硬件采用始终附带条件。明确这些条件有助于区分适合的工作负载与那些需要投入超过回报的工程工作项目。

团队还可以通过可检索的技术知识库保留其评估背景。记录软件版本、工作负载设置、观察到的失败情况和已接受的结果，会让后续比较更有价值，也能降低将旧测量结果视为已变化部署证据的风险。

值得质疑的问题是，在完成这些工作之后，新增的架构是否会成为一个可靠选择。答案会因应用而异。在服务发布前，关于可移植性的笼统表述无法为每位客户解决这一问题。

对于 Oracle Google TPU 合作而言，软件准备程度和运营清晰度将影响已宣布的硬件选择能够在多大范围内转化为实际采用。

三个信号将显示 2027 年计划是否会成为可用基础设施

下一批有意义的证据将涉及服务可用性、可比的客户结果，以及持续的生产使用。

第一个信号是具体的服务文档。在未来几个月，买家应关注已命名的区域、支持的配置、访问要求，以及更精确的发布时间表。这些细节将把按日历年度作出的承诺与实际部署规划联系起来。

区域信息尤其有用，因为企业工作负载具有地点要求。位于不合适区域的容量，并不能与靠近相关应用和数据的容量提供同等选择。买家需要评估他们实际能够获得的服务。

文档还应明确合作双方责任的边界。客户需要了解受支持的软件环境，以及基础设施问题将如何处理。清晰的答案将加强这样一种判断：该公告正在成为客户能够运营的服务。

如果这些细节仍然缺失，战略方向依然清晰，但实际规划仍只能是暂定的。组织应区分已宣布的供应商关系与可供实施决策采用的基础设施选项。

第二个信号是包含足够细节、可供审查的工作负载对比。有用的结果应描述模型质量、完成的工作、响应行为和软件配置。它们还应纳入迁移和运营工作量，而非仅展示孤立的处理器指标。

对于训练，对比应证明最终模型达到等效目标。对于推理，对比应证明输出要求和流量条件具有可比性。否则，不同结果可能反映的是不同任务，而非有意义的基础设施优势。

独立客户的测量结果将具有特别的分量。客户同时说明其收益和剩余限制，比缺乏部署背景的主张更具决策价值。可复现的细节也有助于识别 TPU 选择不适用的场景。

如果公平比较显示，在投入工程工作后收益有限，此次合作的重要性就会收窄。它可能仍适用于特定工作负载，而不会成为 OCI 中的常规选择。这仍代表真实的市场发展，只是其范围更为具体。

第三个信号是持续的生产采用。试点证明团队能够在评估条件下让某项工作运转起来。持续使用则能更有力地证明，部署满足了反复出现的业务和运营需求。

关注客户披露他们保留了哪些工作负载、遇到了哪些问题，以及是否扩大了使用范围。这些说明将揭示容量、软件支持和应用要求能否在初步演示之外真正协同运作。

仅靠供应商公告无法回答这一问题。未披露部署性质的客户数量同样无法回答。反复完成有用工作的证据将加强这样一种论点：OCI 已获得一种持久的加速器替代方案。

对于开发人员，眼下的行动是识别一个具有代表性的工作负载，并保留其当前的质量和性能测量结果。对于企业买家，则是将未来选择与可用于当前承诺的容量区分开来。这两种做法都为在细节到来时评估该服务奠定基础。

在作出架构承诺前，请通过这些里程碑跟踪 Oracle Google TPU 合作。阅读服务文档，审查可比的工作负载结果，并关注是否有客户在试点之外持续运营。在每次比较中，都应将应用质量和工程工作量与硬件性能并列考量。如果你的团队已在 OCI 上运行，请识别另一种加速器能够解决哪些已测量的限制。如果尚未使用 OCI，则应在评估处理器的同时考察周边云服务要求。有价值的结果，是作出一项由与你的工作具体相关的证据支持的部署决策。哪一种工作负载最能让你的组织清晰检验这项新增选择是否真正带来价值？