OpenAI 模型即将登陆 Google Cloud：企业团队切换前应测试什么

OpenAI 正将其前沿模型和 Codex 工作流带到 Google Cloud 的 Model Garden。这一宣布具有战略意义，但实际影响更为具体：部分 Google Cloud 客户可以在已有的云采购、身份管理和治理环境中开始评估 OpenAI 模型。正式发布计划在未来几周内进行，目前的首轮推出仍属于私有预览。

这一点很重要。这不是一次新的 OpenAI 模型发布，也不能证明应用可以在 Gemini、Claude 和 OpenAI 之间迁移而无需工程改造。它改变的是分发方式和运营模式。Google Cloud 客户将能够在同一模型目录中发现 OpenAI 及其他供应商的模型，通过 Google Cloud Marketplace 购买，并使用现有的 Google Cloud 消费承诺支付。OpenAI 表示，Codex 的智能代理工作流也将纳入此次合作。

对企业团队而言，正确的问题不是“哪种模型赢得了这次发布？”而是：“通过我们的云平台购买模型，能否让生产工作流更安全、更便宜，或更容易运营？”答案取决于具体工作负载、所需控制措施，以及周边应用在多大程度上依赖某个特定供应商。

此次究竟宣布了什么

OpenAI 和 Google Cloud 表示，OpenAI 的模型将加入 Google Cloud 的 Model Garden。Google 的配套公告称，GPT-Astra、GPT-6.1 Sol 和 GPT-6 Luna 将在私有预览阶段面向选定的企业客户推出。OpenAI 的公告则更概括地描述了这一安排：客户可以通过 Google Cloud 使用其前沿模型和 Codex 工作流。

客户预计将通过 Google Cloud Marketplace 购买这些模型。拥有 Google Cloud 消费承诺的组织可以将这些承诺用于相关购买。Google 还表示，使用情况会显示在同一张 Google Cloud 账单上，并计入适用于多个模型供应商的 Flexible Savings Plans。对于财务和采购团队已经通过 Google Cloud 管理大部分基础设施的公司来说，这些计费细节可能颇具意义。

这项合作还指向 Google Antigravity 和 Gemini Agent 中的模型访问能力。这表明，双方的协议并不只针对模型端点：OpenAI 模型可能会出现在 Google 更广泛的开发和代理工具中，供用户选择。两家公司并没有把这次宣布描述为一条已经完成、全面可用的迁移路径。OpenAI 表示，正式发布计划在未来几周内进行；Google 则将当前的模型推出称为私有预览。

Microsoft 仍是 OpenAI 的主要云合作伙伴。因此，应将与 Google 的合作理解为分发渠道的扩展，而不是 Azure 的替代方案，也不是 OpenAI 放弃现有云合作关系的声明。

为什么购买决策已经改变

过去，模型访问通常被视为工程团队作出的供应商选择。实际上，企业往往会经过一连串决策，涉及采购、云架构、安全、数据驻留、财务和运营。当模型可以在数据与应用已经所在的云账户中使用时，即使模型本身没有变化，也能减少一部分摩擦。

这里有四个实际影响。

第一，采购流程可能更简单。已经与 Google Cloud 签订协议的团队，有机会利用现有采购关系，而不必再与模型供应商协商一份独立的商业安排。这并不保证价格更低，但会改变费用的审批、承诺、预测和审计方式。

第二，身份与访问管理可能更容易集中。Google Cloud 表示，OpenAI 工作负载将使用其访问控制、经过身份验证的身份、审计日志以及 VPC Service Controls 保护。这些控制措施可以帮助组织回答一些基本的运营问题：哪个服务调用了模型，哪个身份授权了调用，费用由哪个项目承担，以及请求适用哪项策略。

第三，评估可以变得更贴近实际。公司可以在同一个模型发现环境中，将 OpenAI 模型与 Gemini、Claude 及开放模型进行比较。这比比较公开的基准分数更有用，因为组织能够测试自己的提示词、文档、工具调用、延迟要求和故障模式。

第四，云服务商会进一步影响模型选择这一层。Google 将 Model Garden 定位为一个可根据性能、延迟和成本选择、替换模型的工具。这有助于降低过早押注单一模型的风险，但也会让 Google Cloud 在应用架构中扮演更重要的中间层角色。团队应把这种便利视为一种有成本的能力，而不能将其等同于可移植性。

私人预览是第一个警示信号

私人预览适合探索，但不适合作为生产承诺的依据。预览项目可能会更换模型标识符、限制可用区域、文档不完整、配额受限，延迟也可能不稳定；其支持条款还可能与正式发布版本不同。一个原型在预览条件下成功运行，只能证明请求在当时有效，并不能证明上线后同一工作流仍能达到服务级别目标。

评估预览版本时，团队应记录每次测试的具体条件：

• 确切的模型标识符和版本；
• 使用的 Google Cloud 区域或端点；
• 请求是否经过区域性或全球性服务路由；
• token 限制、上下文大小和输出设置；
• 工具调用行为和超时规则；
• 安全机制或内容过滤行为；
• 日志记录、保留期限和访问设置；
• 测试所依据的价格来源和计费单位。

这不是官僚流程，而是解释结果、成本或延迟数据为何在之后发生变化所需的最低信息。对于代理工作流，预览访问尤其有风险：工具调用格式或超时行为只要发生细微变化，就可能让一次成功的演示变成不断重试、只完成部分操作的循环。

在迁移真实工作前应测试什么

严肃的评估应使用能代表实际应用的一部分工作，而不是堆砌一批看起来惊艳的提示词。选择能够暴露模型、平台及周边系统如何相互作用的任务。

1. 测试业务结果，而不是模型的文字表达

在比较服务商之前，先定义验收条件。对支持工作流而言，这可能包括正确分流、完整的引用链，以及答案不确定时进行安全升级。对编程任务而言，可能包括通过测试、保持 API 契约不变，并生成可供审查的修改。对文档处理而言，可能包括字段级准确率，以及处理缺失信息的明确方式。

使用固定评估集衡量结果。同时保留一组未见过的样本，降低提示词调优只是过拟合测试案例的可能性。测试中既要包含困难请求，也要包含普通请求；一个只在边缘案例上表现出色的模型，并不一定是最适合生产环境的选择。

2. 比较一项任务的完整成本

Token 价格只是账单的一部分。实际成本模型还应包括输入和输出 token、缓存上下文的行为、重试、工具调用、检索、存储、编排、可观测性以及人工审核。代理任务尤其容易变贵，因为一次用户请求可能触发多次模型调用和上下文重复传递。

计算每项已完成业务任务的成本，而不只是每百万 token 的成本。例如：

每项已完成任务的成本 =
  模型使用费
  + 检索和工具调用
  + 编排与基础设施
  + 重试和失败尝试
  + 人工审核

在不同并发水平下运行同一工作负载。某个模型每分钟处理十个请求时很便宜，但当系统需要大量预留容量、更严格的延迟控制或更激进的重试策略时，它可能就不再划算。还要确认市场平台计费、云折扣和服务商层面的价格是否以相同方式生效。统一账单能让会计处理更容易，却不会自动让底层单位经济变得透明。

3. 将延迟作为分布来测量

不要只报告平均响应时间。应针对完整工作流跟踪中位数、p95 和 p99 延迟，并区分等待模型的时间与检索、工具执行、策略检查及响应渲染所花的时间。

对于代理，还要测量首次产生有用操作的时间和完成任务的时间。一个调用错误工具更少的慢模型，可能比一个需要反复纠正的快模型更早完成任务。反过来，高能力模型用于分类、抽取或常规起草，也可能是一种浪费。

4. 测试故障与恢复行为

最重要的测试，可能正是那个会失败的测试。向系统提供不完整的数据、格式错误的工具响应、不可用的服务、含义模糊的指令，以及超出模型权限范围的请求。观察工作流会停止、请求澄清、安全地重试，还是会继续执行并自行编造假设。

外部副作用必须置于明确的闸门之后。模型不应仅仅因为生成了一个看似合理的下一步，就能够发送电子邮件、修改客户记录、批准交易或部署代码。云端位置不会改变这一要求。集中式日志有助于调查人员在操作发生后了解情况，但不能替代操作发生前的授权。

5. 用证据验证数据边界

Google Cloud 表示，这些工作负载的提示词、上下文和输出将保留在客户指定的数据边界内，也不会用于训练基础模型。Google Cloud 还介绍了隔离的访问边界，并表示零数据保留选项即将推出。这些都是重要的承诺，但买方应核实：具体控制措施究竟适用于哪个预览服务、区域、模型、账户类型和合同。

要求对以下问题作出书面答复：

• 数据由 Google Cloud、OpenAI，还是双方保留？保留多长时间？
• 提示词和输出是否用于滥用监测、调试或改进服务？
• 启用支持或追踪功能后，保留政策是否会发生变化？
• 日志、缓存输入、嵌入和工具输出存储在哪里？
• 出于路由或安全检查，提示词是否会被发送到所选区域之外？
• 哪些控制措施目前已经可用，哪些仍只是计划？
• 请求失败或重试时，数据会如何处理？

“在我们的云中”并不是充分的隐私说明。一个请求可能经过多个托管服务，而每个服务都可能有自己的日志记录、保留期限和管理员访问行为。应把供应商针对实际部署环境提供的文档和合同视为事实依据。

只有当应用能够承受模型差异时，模型选择才有价值

Google 的卖点是模型选择：为每种工作负载使用合适的模型，并在不受架构锁定的情况下更换模型。这是一个有价值的设计目标，但前提是应用与供应商特定的接口之间必须经过有意识的隔离。

至少应将模型选择置于内部接口之后。把提示词、模式、工具定义、安全规则和评估结果保存为带版本的工件。统一响应元数据和错误信息。应用还应明确自身所需的能力：结构化输出、视觉、长上下文、代码执行、浏览、计算机操作、工具调用，或某种特定的推理模式。

不要假设兼容 OpenAI 的请求在行为上也具备可移植性。不同供应商在处理系统指令、JSON 模式、流式事件、工具参数、令牌计数、拒答响应、缓存上下文和安全过滤器时，可能存在差异。薄薄的兼容层可以让首次集成变得快捷，却也可能掩盖重要区别。可移植性必须在已完成任务和故障处理的层面进行测试。

一个合格的模型路由器还需要备用策略。如果首选模型不可用，系统应安全失败、改用更便宜的模型、切换到另一家供应商，还是把任务放入人工处理队列？答案取决于业务风险。客户支持摘要或许可以接受备用模型；财务审批或生产部署则未必。

Google Cloud 客户应询问哪些成本问题

能够使用现有云承诺额度很有吸引力，因为它可以把未使用的基础设施支出转化为尝试模型的渠道。但这也可能制造一种虚假的节省感。承诺支出仍然是一项承诺；考虑到利用率、折扣和运营开销后，消耗这笔额度的模型成本可能高于直接购买的替代方案。

至少针对以下三种情景进行比较：

1. 当前供应商和当前架构；
2. 通过 Google Cloud 购买 OpenAI 模型；
3. 通过同一平台运行的第二家供应商或开放模型。

使用相同的工作负载，并计入相同的审核和基础设施成本。比较每项成功任务的实际成本，而不只是宣传的令牌费率。还要计入将数据传入服务、存储追踪记录、运行检索，以及为提高韧性而保留第二家供应商的成本。

还要明确商业关系。Google Cloud 账单可能会简化付款流程，但模型专属支持、配额、事故处理和服务级别条款，仍可能取决于另一家供应商或预览协议。采购团队应明确：模型本身可用、但集成端点发生故障时，由谁负责升级处理。

现在适合尝试的团队

对于已经运行在 Google Cloud 上，并且有明确理由评估 OpenAI 模型、又不想另行建立采购和治理路径的团队，这项预览最有参考价值。例如：

• 平台团队希望在同一企业工作负载上比较 OpenAI、Gemini、Claude 和开源模型；
• 受监管组织需要集中式身份、审计和数据边界控制；
• 开发者工具团队希望在现有代码仓库、构建系统和可观测性设施附近测试 Codex 工作流；
• 财务或采购团队希望了解云承诺能否支撑多模型项目；
• 架构团队正在设计模型路由器，并愿意维护针对不同供应商的测试。

这些团队应从范围受限的评估开始。选择少量工作流，使用合成数据或经过适当批准的数据，设定预算上限，并确定决策日期。目标是了解这项集成是否改变了工作负载的运营成本或控制范围。

适合等待的团队

如果团队需要有保障的区域、稳定配额、正式的服务级别承诺、成熟的合规证明或可预测的定价，就应等到正式发布并获得完整文档。私有预览不适合作为没有备用方案的面向客户依赖项的基础。

没有实际 Google Cloud 使用基础的组织也应重新审视这一前提。如果迁移工作负载的唯一理由是获得 OpenAI 模型，那么增加另一个云控制平面可能会增加而不是减少复杂性。直接接入供应商、使用现有模型网关，或选择另一家云市场，可能更简单。

已经在评估、权限或操作边界方面举步维艰的团队，不应把新的市场入口当作解决方案。合作关系可以整合访问和计费，却无法定义代理允许执行哪些操作，无法判断生成的答案是否正确，也无法补足缺失的业务责任归属。

更大的转变：云平台正在成为模型分销商

这项公告指向企业 AI 的一项更广泛变化。云平台销售的不再只有计算、存储和托管数据库。它们正成为相互竞争的模型供应商的分发层，并围绕模型端点打包采购、身份、可观测性和应用工具。

这对买方可能是好事。企业或许能获得更强的议价能力、更一致的控制平面，以及一种切实可行的比较测试方式。但责任边界也可能因此变得模糊。当模型、云平台、代理框架和数据平台被捆绑在一起时，一起事故可能牵涉多份合同和多套控制措施。

最终胜出的架构，不一定是目录中模型最多的那个，而是能让模型选择保持可逆、衡量已完成工作的成本、记录数据流向，并在负责任的人员或系统批准前暂停高影响操作的那个。

因此，OpenAI 进入 Google Cloud 值得测试，尤其是对现有 Google 客户而言。但眼下应制定的是评估计划，而不是迁移计划：复现真实工作负载，比较每项任务的总成本，核实数据处理方式，演练故障路径，并保留一个可用的替代方案。如果预览通过这些测试，这项合作可能减少企业落地阻力；如果没有通过，单一账单和更大的模型目录也救不了这个项目。