TPU vs GPU：OpenAI 首次使用谷歌 TPU 推理
OpenAI 正在通过 Google Cloud 租用谷歌自研的 TPU，用于 ChatGPT 等产品的推理运算。这项合作于 2025 年 5 月达成，并在 6 月 27 日由《路透社》首次披露，随后被多家英文媒体确认。OpenAI 并未获得最新一代 Ironwood TPU，而是租用了中等性能型号，仅用于推理任务。
这是 OpenAI 首次在生产环境中使用非英伟达芯片。此前，其训练与部署几乎完全依赖英伟达 GPU 和微软 Azure。本文将围绕这项合作展开观察：
[*]OpenAI 为什么选用 TPU？
[*]谷歌提供了什么？
[*]谁会因此受益，谁的格局被动摇？
在此前文章中，我们讨论了英伟达主导训练，推理正在转向 ASIC， 这一次，OpenAI 的决定让这条趋势落到了真实部署路径上。
01｜OpenAI：走出 GPU 单一依赖的第一步
｜从全面依赖到资源瓶颈过去三年，OpenAI 的训练与推理部署几乎完全依赖英伟达 GPU，主力平台是微软 Azure，主力芯片是 A100 与 H100。随着 ChatGPT 成为公共服务，这一架构开始承压：
[*]推理成本持续上升：H100 单卡价格超过 2 万美元，推理调用高频、多模态模型参数量大，导致单次交互边际成本不断走高；
[*]资源调度冲突频繁：训练任务需要连续计算，推理则要求低延迟，两者共用集群时资源占用不稳定；
[*]替代方案仍不成熟：截至 2024 年底，其他供应商（AMD、谷歌、AWS）虽有布局，但尚无法在生产级别提供 GPU 替代能力。
这些问题没有立即导致架构崩溃，但它们在影响 OpenAI 的服务弹性、成本结构和迭代节奏。
｜多源架构开始成型自 2024 年起，OpenAI 逐步启动 “算力去单一化” 策略，开始拆解其长期依赖的算力供应结构。具体包括：
[*]与微软重谈绑定协议，获得更灵活的资源调度权限；
[*]在 Azure 引入 AMD MI300 测试节点，用于非核心模型的部署验证；
[*]与博通合作研发定制 AI 芯片，预计在 2026 年前落地；
[*]本轮新增动作：首次使用谷歌 TPU，在 Google Cloud 上处理部分推理任务。
这是 OpenAI 首次将核心服务部署在非英伟达芯片上，也是在核心生产路径中首次引入非 Azure 公有云。
｜推理任务为何适合拆分出来？与训练相比，推理在计算特性上有显著差异：
[*]推理任务不涉及梯度计算，只需前向传播，计算图结构固定；
[*]相较于训练对显存带宽的极致需求，推理更注重吞吐率与响应延迟；
[*]推理调用频繁、成本敏感，更适合在标准化硬件上运行。
这意味着推理更容易被 “模块化” 迁出主训练平台，部署到异构硬件上。TPU 的高能效矩阵运算架构，正好适用于这类负载。OpenAI 本轮租用的 TPU 型号尚未公开，但据路透社报道，谷歌并未向其提供最强 TPU（Ironwood）。这说明 OpenAI 更看重部署的成本效益，而非追求峰值性能。此举并不意味着 OpenAI 放弃 GPU 或 Azure，而是明确将算力结构从 “通用统一” 转向 “功能分层”。
02｜谷歌 TPU：为何能成为合格的替代项？
｜为推理而生的架构设计谷歌自 2015 年起自研 TPU（Tensor Processing Unit，张量处理单元），核心目标并非取代通用 GPU，而是优化深度学习模型中的矩阵计算流程。TPU 最关键的结构在于它集成了一块专用矩阵乘法阵列（Matrix Multiply Unit，MXU），可在硬件层面加速大规模张量（tensor）乘法运算。这种计算通常是深度神经网络中最占资源的一步，占据推理过程中 80% 以上的计算量。在此基础上，TPU 还集成以下设计：
[*]高带宽内存（HBM）：即 High Bandwidth Memory，可提升数据加载速度，减少等待时间；
[*]片间互联：通过专有高速网络连接多个 TPU 芯片（即 TPU Pods），支持大规模并行推理；
[*]定制指令路径：比 GPU 更接近 “专用芯片”，运行效率更高但灵活性较低；
[*]能效比优化：功耗控制更好，适合运行在数据中心负载稳定的环境中。
这些架构，使得 TPU 在推理（inference）场景中，特别是高并发、大批量、模型结构固定的任务中，具有高吞吐、低延迟和低能耗的优势。
｜多代产品迭代，打通商用路径
截至 2025 年，谷歌已发布至第七代 TPU。
最新的 Ironwood（TPU v7）单芯片浮点运算性能达 4,614 TFLOPs，并搭载 192GB 高速内存，面向 Gemini 等超大模型训练而设计。
OpenAI 本轮租用的 TPU 型号尚未公开，但据路透社报道，谷歌并未向其提供最强 TPU（Ironwood）。综合公开信息和行业部署节奏判断，OpenAI 此次很可能使用的是 TPU v4（发布于 2018 年）或 v5（发布于 2021 年）这一代产品。
[*]因为谷歌未对外开放最新 Ironwood 资源；
[*]v4/v5 已在 Google Cloud 上量产部署，商用路径更成熟；
[*]推理任务对延迟、能效要求更高，对绝对峰值性能要求反而次要。
TPU v4 支持 4,096 芯片级集群（Pod），可按需调度。v5 支持更密集互联，并提供动态资源分配 API，适合服务侧实时调用。
这意味着，即便不使用最先进版本，OpenAI 仍可借助谷歌稳定、成熟的 TPU 云资源完成大规模推理扩容。
｜TPU 与 PyTorch：兼容问题正在消解谷歌 TPU 原生为 TensorFlow / JAX 框架优化，而 OpenAI 的模型多使用 PyTorch。两者之间存在长期兼容障碍。
过去两年，这一问题已有实质进展：
[*]PyTorch/XLA（Accelerated Linear Algebra，谷歌开发的中间表示框架，用于加速编译优化）项目持续开发，可将 PyTorch 模型转译为 TPU 可运行格式；
[*]Hugging Face、Runway 等平台已提供基于 TPU 的 PyTorch 推理接口；
[*]谷歌官方亦发布 T5、BERT 等多种预训练模型在 TPU 上的 PyTorch 运行示例；
[*]目前 PyTorch/XLA 在 TPU 上的训练支持仍处于持续优化阶段，更成熟的商用路径主要集中在推理任务上。
OpenAI 若采用隔离微服务架构（如将推理层部署为单独 API 接口），可避免主模型迁移，先行在 TPU 上跑子任务或少参数模型。
这使得 TPU 的使用门槛不再像早年那样高，至少在推理侧已具备 “工程可落地” 的能力。
｜部署效率高于 GPU 自建路径TPU 的另一个优势在于可通过 Google Cloud 弹性调用，避免 GPU 自建集群所需的采购、部署、调度、散热、电力管理等成本。相比之下：
[*]OpenAI 若自购英伟达 GPU，需要预留几个月交货周期；
[*]GPU 集群需工程团队完成裸机配置与调度工具安装，涉及驱动版本匹配和服务熔断容错设计；
[*]散热与能耗成本长期存在，不利于短期扩容或动态资源调度。
而通过 Google Cloud，OpenAI 可直接调度已有 TPU Pod 资源，并按使用量付费。这种 “算力即服务” 方式，非常适合推理层的弹性需求。
03｜AI 芯片格局：从单一标准走向多源结构
OpenAI 租用谷歌 TPU，改变的不只是单一项目的部署路径。它打破了 AI 芯片市场长期由英伟达主导的事实标准，也为其他供应商的商业化打开了结构性空间。这一动作已对多家芯片公司产生连锁反应，标志着 AI 推理基础设施正从单芯片垄断走向多源结构。
｜英伟达：地位仍稳，护城河开始被穿透OpenAI 长期是英伟达 H100 的最大采购方之一。其模型训练、API 推理、企业部署服务，几乎全部运行在英伟达 GPU 上。过去三年，“用英伟达” 几乎是行业默认配置。此次合作虽只涉及推理，不影响训练主路径，但标志着核心负载首次迁出英伟达体系。这对市场认知是一次实质性松动。短期来看，英伟达的营收不会立刻受到冲击。训练任务仍需 GB200 和 H100，OpenAI 本体模型也未迁移。但结构性影响已在显现：
[*]更多客户将评估第二供应来源，推动投产多元化；
[*]英伟达的 GPU 定价优势可能面临下调；
[*]需要通过 H20 等推理专用卡、或软件打包服务（如 NIM）来维持客户黏性。
英伟达最大的护城河并不只是性能，而是它围绕 GPU 构建的一整套开发生态：
[*]核心框架 CUDA 与 cuDNN；
[*]推理优化工具 TensorRT；
[*]从模型训练、调试到部署的端到端支持路径；
[*]以及数千个已在平台上调优的模型与工具库。
这套软件栈使得整个 AI 工程体系高度依赖英伟达平台。即便有更便宜或节能的芯片方案，切换成本仍然极高。英伟达真正的竞争壁垒，是 “换掉它” 会触发整个工具链的再适配。这将成为它在多源竞争格局下的关键缓冲。
｜博通：短期受益，角色边界正在变化谷歌 TPU 芯片的底层 ASIC（专用集成电路）部分由博通深度参与设计与代工。自第一代 TPU 起，谷歌与博通的合作已持续多年。因此，OpenAI 大规模租用 TPU，短期看也意味着博通间接受益。部署越多，TPU 背后芯片的出货量就越大。但这一结构存在不确定性：
[*]2024 年底有媒体报道称，谷歌考虑逐步结束与博通的芯片合作，以节省数十亿美元设计与代工成本；
[*]谷歌虽未确认这一变化，但也未承诺长期稳定合作；
[*]与此同时，OpenAI 自身也在与博通合作开发自研芯片，预计 2026 年落地。
当前，博通仍处于 “两头合作” 的有利位置：既为谷歌 TPU 提供设计支持，也服务于 OpenAI 的新芯片项目。但从长期趋势看，随着客户推进 “算力主权”，博通在核心产品设计上的角色可能被边缘化。它未来的价值，可能更多体现在系统集成与工程协同上，而非芯片架构主导。作为非平台型企业，博通需要适应客户主导结构下的新角色。
｜AMD：受限于节奏，但方向正确AMD 近年来持续布局 AI 加速卡市场，推出了 MI200 和 MI300X 系列。MI300X 在内存容量与能效比方面接近 H100，具备大模型推理的基础能力。微软 Azure 已上线 MI300X 云实例，OpenAI 也在其中进行小规模测试部署。不过从 OpenAI 实际选择看，本轮推理扩容仍优先采用谷歌 TPU，而非 MI300。原因可能包括：
[*]AMD 的生态仍偏向 HPC（高性能计算），在 AI 推理部署经验有限；
[*]软件工具链（如 ROCm）尚未达到 CUDA 级别的稳定性与支持广度；
[*]OpenAI 的调用接口依赖成熟的调度与服务层，TPU 在这方面的托管模式更具交付效率。
虽未进入主部署路径，TPU 的落地反而强化了 AMD 的 “追赶正当性”：
它验证了 GPU 并非唯一方案，也说明工程适配是可以解决的问题。这对 AMD 是长期利好。
只要能持续加强开源工具链、降低工程迁移成本、适配主流训练框架，AMD 在下一轮客户多元化周期中仍有可能获得结构性增量。
04｜AI 基础设施的重组逻辑：更快、更便宜、更自主
OpenAI 租用 TPU，不只是一次硬件扩容决策，更反映出其在服务架构上主动拆分任务、重构路径。这一选择建立在对推理成本、交付速度与控制权的重新评估之上。
｜推理正成为主要的成本中心训练是一种集中发生的投入，但推理是一个持续发生的运营成本。对 OpenAI 而言，每一次 ChatGPT 问答、API 请求、代码生成或企业服务调用，都会触发一次推理任务。而推理的成本，在整个模型生命周期中所占比重正在迅速上升。据《The Information》2024 年报道：
[*]每次 ChatGPT 对话的推理成本约为 1–3 美分，这在 API 层面上对大客户尤其敏感；
[*]若使用英伟达 H100，在当前电力价格和资源分配模式下，每张卡的运行功耗约为 700 瓦，每日运营成本在 8–10 美元；
[*]推理任务运行在 H100 上时，其单位计算成本是大模型商业化过程中最大的变动项之一。
谷歌公开的 TPU 性能报告显示：
[*]在 BERT 推理任务中，TPU v4 的单位能耗约比同代 GPU 低 35–40%；
[*]在相同条件下，TPU 的吞吐率可提升 1.5–2 倍，尤其在高并发文本生成任务中表现更为稳定。
这些数据构成了 OpenAI 评估 “是否值得迁移推理任务” 的基础。
｜部署周期与扩容速度：GPU 不再是最快的路径除了运行成本外，部署弹性也是影响 AI 架构的重要因素。英伟达在 2024 年经历严重产能瓶颈，尤其是 H100 与 GB200 系列。行业普遍面临如下问题：
[*]云服务商从下单到交付周期平均为 16–20 周；
[*]自建 GPU 集群还需额外配置基础设施、冷却系统、调度框架，整体上线时间超过 4–6 个月；
[*]在突发流量高峰（如 GPT-4 发布、企业 API 激增）时，这种响应速度难以满足需求。
而谷歌 Cloud TPU 的交付节奏明显快于 GPU 自建路径：
[*]在已部署区域，TPU v4/v5 Pod 可在 24–72 小时内完成资源调度与上线；
[*]谷歌提供统一镜像管理、弹性扩容、负载均衡接口，可直接集成至 OpenAI 的 API 层服务调度中；
[*]相比 GPU 自管，TPU 租用模式更适合短期高峰或试验性功能快速落地。
对于 OpenAI 这样拥有数十个独立产品线与模型分支的组织，这类 “可用即调用” 的架构选择在效率层面意义重大。
｜架构重组的出发点：拆分任务、精配算力在模型开发初期，所有任务都集中在 GPU 上完成。但随着部署规模扩大、调用路径复杂，越来越多的 AI 公司开始将训练、推理、微调等模块分拆部署。OpenAI 也正在这样做：
[*]GPT 模型训练仍基于英伟达 GPU 集群；
[*]API 推理则尝试迁出，交由更低成本的 TPU 处理；
[*]微调任务则可能交给 AMD MI300、Inferentia 或未来自研芯片；
每类芯片都有更适合的任务场景：
芯片类型代表厂商最适合任务优势
GPU（H100, MI300X）Nvidia、AMD训练、微调高并行、高带宽
TPU（v4/v5）Google批量推理吞吐高、能耗低
ASIC（MTIA, Inferentia）Meta、AWS高频小模型推理专用、稳定、低延迟，能效高但用途更窄
注：ASIC（Application-Specific Integrated Circuit）为定制型芯片架构，通常针对特定模型或场景设计，牺牲通用性以换取运行效率。
这类 “异构架构 + 分工部署” 模式，已经在 AWS、Meta、谷歌内部广泛应用。OpenAI 此次引入 TPU，只是它首次将该模式应用到面向公众的大规模商用模型上。
｜服务分发逻辑正在倒逼底层架构变化OpenAI 的服务边界正在迅速扩张：
[*]企业客户使用 GPTs、插件或 API 时，对稳定性和响应时间有明确的 SLA 要求；
[*]ChatGPT Teams、Enterprise 等场景，需要支撑百万级日常并发调用；
[*]Copilot 类插件、嵌入服务、文档分析等嵌入式场景，也对任务调度与资源隔离提出更细粒度的要求。
在这样的服务压力下，单一平台的固定架构已难以支撑多层次负载。OpenAI 需要在推理层具备更快的扩容响应、更强的容错能力与更可控的成本结构。Google Cloud TPU 提供的负载隔离、版本回滚、优先队列等调度机制，恰好匹配这些服务侧的部署需求。这也是 OpenAI 放弃通用路径、走向架构重组的直接动力之一。
05｜OpenAI 的中长期路线图：控制权才是底层逻辑
｜自研芯片：不是替代，而是系统掌控路径的一环
据《The Information》2024 年 10 月报道，OpenAI 正与博通合作开发定制 AI 芯片，预计于 2025 年 H2 流片，2026 年部署。
路透社同期亦指出，该项目意在降低对英伟达的依赖，并提升推理层的资源可控性。
项目结构为：博通提供标准化 IP 模块，OpenAI 定义芯片架构与调度接口。
芯片的目标不是替代英伟达在训练上的主导地位，而是在推理、嵌入、多模型路由等中低负载场景中，建立可控、低成本的运行路径。
其核心策略，是将资源配置方式从 “平台绑定” 转向 “任务匹配”，并构建属于自己的调度系统。
｜谁控制运行方式，谁定义平台结构
OpenAI 多次强调运行系统的重要性。Altman 在 2024 年 Stripe Sessions 上指出，模型本身已不再是瓶颈，挑战转向 “如何定义调用系统与运行环境”。Karpathy 也曾将大模型比喻为操作系统。这类判断的共同指向是：平台的控制力，不再取决于模型大小，而在于能否主导调度逻辑与接口层设计。在 OpenAI 的系统架构中，已逐渐形成如下结构：
[*]模型（如 GPT-4）是系统内核；
[*]GPU、TPU、自研芯片与任务调度器构成执行层；
[*]Function Calling、插件、Assistants API 组成中间接口层；
[*]顶层服务由 ChatGPT、Teams、API 产品对外提供。
在这个结构中，芯片不再只是算力资源，而是运行系统的 “微内核”。控制芯片，就控制路径；控制路径，就决定了部署弹性、成本结构与服务形态。若这些路径仍掌握在其他平台手中，OpenAI 将难以真正构建自己的运行系统。
｜目标：稳定、可控、低成本Altman 曾提出，智能的边际成本应逐步逼近电力成本。表面是成本判断，实质上是对系统架构效率的定义。实现这一目标，需要：
[*]将推理转化为确定性负载；
[*]将芯片设计与任务类型深度耦合；
[*]将服务响应逻辑嵌入调度系统，实现精细分发与定价控制。
TPU 是 OpenAI 多路径拆分中的首个落地组件，自研芯片是下一阶段的延伸。最终目标，是构建一个具备资源调度、自主部署与服务控制能力的系统型平台。OpenAI 正在为此构建它自己的底层。
06｜谷歌的博弈逻辑：开放芯片，但不开放核心
OpenAI 大规模租用谷歌 TPU，为谷歌赢得了一个象征意义极强的合作客户，也使其自研芯片体系首次被纳入竞争对手的大模型部署路径。
在这次合作中，谷歌既是芯片资源的提供方，也是平台资源的调度者。它对外释放了部分算力资源，但核心系统权限依然封闭。这不是一次彻底的开放，而是一次经过设计的结构性释放。
｜TPU 的对外释放，是谷歌的算力调配策略谷歌并未向 OpenAI 提供最新一代 Ironwood（TPU v7），而是提供了更稳定的 v4 或 v5 型号。Ironwood 具备 4,614 TFLOPs 浮点性能与 192GB 高速内存，目前仍专供内部使用。即使对外释放，谷歌也保留了 TPU 的调度优先权与架构封装。这意味着：OpenAI 所调用的，并不是裸芯片资源，而是谷歌按平台逻辑暴露出的 “服务化 TPU”。这种释放策略，让谷歌在提升资源利用率、拓展云客户的同时，也保留了自身模型研发所需的资源保障。
｜Cloud TPU：平台策略的一部分，不只是硬件谷歌并不希望 TPU 成为像英伟达 GPU 那样的通用商品，而是作为 Google Cloud 的平台能力之一，整合进服务调用链路中。Cloud TPU 提供标准化接口（如 JAX、TensorFlow）、统一调度机制、优先队列、IAM 权限管理与版本封装系统。客户所接入的，是谷歌构建的平台服务，而非底层芯片定义权。这也是 OpenAI 无法获得 Ironwood，只能使用 v4/v5 集群的根本原因：谷歌开放的是接口，并非核心资源。
｜谷歌保留训练路径与平台调度权OpenAI 与谷歌的合作仅限于推理层资源。谷歌并未开放其 Gemini 系列训练平台，也未提供芯片级编译优化接口或定制训练框架接入。核心主权始终掌握在谷歌手中：
[*]模型主权：Gemini 仍由 DeepMind 内部团队独立训练；
[*]平台控制权：TPU 调用路径、任务分发逻辑与调度参数，全部封装在 Google Cloud 的平台结构中。
这种合作结构，既满足了 OpenAI 的短期算力需求，也使谷歌能够在不动摇战略控制边界的前提下，释放部分资源、拓展客户群体。
｜TPU 合作的双重含义对 OpenAI 而言，这是一次算力中立的试探；对谷歌而言，是一次结构内嵌的平台策略。OpenAI 获得了成本更优、响应更快的推理路径；谷歌则获得了 TPU 的旗舰级客户和商用验证样本。但这并不代表两家进入深度绑定。谷歌继续封闭训练平台、保留模型主权；OpenAI 仍在推进多平台部署、自研芯片与控制系统建设。TPU 的对外开放，是结构性博弈下的策略妥协——提升平台利用率的同时，不放弃系统定义权。这一逻辑未来或将成为行业共识：资源可以开放，但接口与运行路径，仍掌握在平台方手中。
07｜从模型之争，到系统设计之争
OpenAI 与谷歌之间的这次合作，不只是一次调配算力资源的行为。它释放出一个更深层次的信号：AI 基础设施的主导逻辑正在变化，模型部署路径开始从集中、单一、封闭，转向分层、异构、可调度。
｜从 “谁的模型最强” 到 “谁控制运行路径”过去，行业关注的核心是模型性能：谁拥有更强的训练规模，谁优化得更快，谁上线更早。但进入 2024 年后，随着多模态能力成熟与部署规模扩张，运行路径本身开始成为关键变量：
[*]训练仍依赖大规模 GPU；
[*]推理可以拆出并分布式运行；
[*]微调、嵌入、接口调用等任务对资源有不同需求；
[*]服务层对延迟与稳定性的要求反过来塑造部署方式。
OpenAI 租用 TPU，是在推理架构不断复杂化下，对部署路径的一次主动调整。
｜控制权已成为模型平台化的必要组成部分OpenAI 在过去一年推动的多个基础设施动作（多云部署、芯片自研、接口抽象）共同指向一个方向：运行权要掌握在自己手里。并非为了 “独立”，而是为了在服务多样化、接口复杂化、资源稀缺化的背景下，具备可持续、可定价、可扩容的系统能力。芯片只是其中一环。更关键的是：
[*]谁定义调用路径；
[*]谁拥有调度优先级；
[*]谁控制服务质量的最底层参数。
这决定了模型能否作为 “平台” 运行，而不只是 “一个功能调用”。
｜平台型模型系统的结构正在浮现OpenAI 并不是唯一在走这条路径的公司。谷歌、Meta、微软、AWS 都在尝试通过芯片整合、接口标准化与模型封装，构建具有结构控制力的 AI 系统。可以观察到一种平台型模型系统正在浮现：
[*]有模型（大脑）；
[*]有资源层（芯片 × 云）；
[*]有调度器（异构负载切换）；
[*]有接口层（API × 插件 × 工具）；
[*]有服务封装（客户端产品 + 第三方开发者）；
TPU 合作是 OpenAI 拆分系统路径中，第一个完成工程部署的组件。
｜一种新范式并未完成，但正在被构建
OpenAI 并未放弃 GPU，也未绑定谷歌。它在做的是：为不同任务建立适配的系统路径。
本次合作在短期内提升了推理成本效率与资源弹性，但更重要的是，它为 OpenAI 在未来芯片控制、自主部署与服务架构上的多元化提供了工程基础。
行业正在从 “模型之争” 进入“系统设计之争”。
接下来值得关注的，是 AWS、Meta 是否会将自研芯片（如 Trainium、MTIA）向更广泛的推理负载开放，以及 OpenAI 的自研芯片将在何时落地、承担哪些服务分层。
结构正在松动，博弈仍在继续。
页:
[1]
