TPU vs GPU：OpenAI 首次使用谷歌 TPU 推理

hdy

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 的自研芯片将在何时落地、承担哪些服务分层。

结构正在松动，博弈仍在继续。