如果 Gemini 应用已经接近上线，默认先留在 Google AI Studio 和 Gemini Developer API 这条开发者路线，除非某个企业控制已经是交付条件。配额、计费、项目归属、付费模型访问或付费数据使用边界通常先用付费 Developer API 解决；只有 IAM、组织策略、区域/数据控制、预留吞吐、Model Garden、MLOps、私有网络、安全审查、企业支持或合规流程变成硬门槛时，才把工作迁到 Gemini Enterprise Agent Platform 这类 Google Cloud 企业路线。
常见说法会把问题压缩成“Google AI Studio 适合原型，Vertex AI 适合生产”。这个判断太快。真正要选的是三条路线：Developer API 负责快速构建和常规应用，付费 Developer API 负责普通生产压力，企业平台负责 Cloud 级控制。价格、速率限制、API 密钥迁移、端点、数据使用、数据驻留和零数据保留都要以当前 Google 文档为准，不要靠旧教程或固定表格定案。
先用三条路线判断
| 当前卡住的事 | 先选哪条路线 | 判断原因 |
|---|---|---|
| 需要快速测试提示词、模型行为、函数调用、结构化输出或后端原型。 | Google AI Studio + Gemini Developer API。 | Google 把 Developer API 定位为大多数开发者的默认路线，除非需要特定企业控制。 |
| 原型已经可用，下一步是配额、计费、项目拥有者、协作者、付费模型或付费数据使用边界。 | 付费 Developer API 项目。 | 这是很多对比文章漏掉的中间路线，不必因为“要生产”就直接迁到企业平台。 |
| 工作负载没有 IAM、组织策略、区域/数据控制、预留吞吐、MLOps、Model Garden、VPC、安全审查、支持或合规就不能上线。 | Gemini Enterprise Agent Platform / Google Cloud 企业路线。 | 这些控制属于平台治理，不是一个更干净的 API Key 就能解决。 |
最容易误判的是把 AI Studio 看成玩具，把 Vertex AI 看成所有生产应用的唯一答案。实际情况更细。一个付费 Gemini Developer API 项目可以承担许多真实生产应用：它有 Google Cloud 项目归属、计费账户、协作者、项目级配额、付费层级和数据使用条款。只要业务风险还是“应用怎么稳定调用模型”，而不是“企业治理怎么验收”，Developer API 路线仍然成立。
第二个误判是把能拿到 AI Studio API Key 当成生产准备完成。密钥只能证明凭据能创建，不能证明项目已经有正确的计费状态、实时速率限制、模型可用性、数据政策、端点选择、日志边界、回滚方式和安全审批。进入生产之前，需要把这些现实问题逐一确认。
把 AI Studio、Developer API 和企业平台分清
不要按“听起来专业不专业”来理解这些名字，要按使用面和责任边界来理解。
| 名称 | 实际承担的角色 | 适合做什么 | 不要误用为 |
|---|---|---|---|
| Google AI Studio | 浏览器里的 Gemini 试验、提示词调试、密钥创建和项目可视化入口。 | 快速试模型、创建 API Key、检查项目、跑第一批请求。 | 每个模型、地区、配额、生产策略都已经被批准。 |
| Gemini Developer API | ai.google.dev 上的直接开发者 API 路线。 | 大多数应用集成、SDK 调用、普通后端、低到中风险生产服务。 | 自动拥有企业 IAM、数据驻留、MLOps、专线网络或合规承诺。 |
| 付费 Developer API | 同一条 Developer API 路线进入付费项目状态。 | 配额、计费、付费模型访问、项目所有权和付费数据使用边界。 | 替代公司级合规架构或 Cloud 治理。 |
| Vertex AI / 企业平台 | 当前 Google Cloud 文档中更接近 Gemini Enterprise Agent Platform 和相关 Cloud AI 服务的企业路线。 | IAM、组织策略、区域/数据控制、预留吞吐、Model Garden、MLOps、支持、合规和采购流程。 | 所有“生产环境”的默认答案。 |
| Gemini Enterprise 应用 | 面向企业用户的应用体验。 | 公司知识、企业用户访问、内部工作流。 | Developer API 路线或所有 Vertex AI API 调用的同义词。 |
Google 当前的 Gemini API 迁移文档把 API 产品分成 Gemini Developer API 和 Gemini Enterprise Agent Platform API，并明确提示多数开发者应使用 Developer API，除非需要特定企业控制。这个判断比“AI Studio 是原型、Vertex 是生产”更有操作价值。
“Vertex AI”这个词仍然有用，因为开发者、旧教程和 Cloud 团队经常用它指企业侧路线。保留这个识别词可以降低理解成本，但不要让它吞掉实际决策：先用 Developer API，普通生产压力先升级付费 Developer API，企业控制成为验收条件时再迁到企业平台。
什么时候留在 Developer API
如果当前任务仍然是构建、测试、集成和交付一个普通 Gemini 应用，而且没有企业平台级义务，就留在 Google AI Studio 和 Gemini Developer API。
适合继续使用 Developer API 的工作包括：
- 提示词、响应格式、结构化输出和函数调用测试。
- 小型或中型后端集成。
- 使用统一 Google Gen AI SDK 的普通应用开发。
- 多模态输入、文件处理或模型行为验证。
- 内部原型和低风险生产服务。
- 团队需要明确 Google Cloud 项目所有者、协作者和计费上下文。
- 可以接受 Developer API 的计费、配额、日志和数据使用边界。
Developer API 不是只能演示的路线。更准确的问题是：未解决风险属于应用运行风险，还是企业治理风险？如果问题是“付费项目的配额够不够”“重试和限流怎么做”“哪个模型行当前可用”“项目谁来付费”，这些都更像 Developer API 内部要解决的问题，而不是马上迁移平台。
这也是相邻支持页面存在的原因。密钥创建、项目归属、首次请求、Key 安全和 403/429 准备度，应该走 Google AI Studio API key setup 这类具体设置路线。模型行是否仍有免费层、项目级限额、429、何时启用计费，应该走 Gemini API free tier limits 这类配额路线。平台选择只处理路线和迁移阈值，不重复写成设置教程。
什么时候先升级为付费 Developer API
付费 Developer API 是很多二列表格忽略的关键中间层。
| 生产压力 | 付费 Developer API 可能足够的情况 | 企业平台开始相关的情况 |
|---|---|---|
| 计费 | 团队需要付费项目、预算归属、更高用量层级。 | 计费必须进入组织采购、企业折扣、支持合同或承诺容量。 |
| 配额 | 应用需要更高或更稳定的 RPM、TPM、RPD 或项目层级。 | 需要预留吞吐、Cloud 配额治理或企业支持承诺。 |
| 数据使用 | 付费 Developer API 的数据使用条款能满足评审。 | 需要特定数据驻留、保留、日志、审计或合同承诺。 |
| 项目归属 | Google Cloud 项目、协作者、计费账户和 Key 策略足够。 | 需要 IAM、组织策略、服务账号、网络控制和集中安全审查。 |
| 模型访问 | 所需模型在 Developer API 路线可用。 | 需要 Model Garden、伙伴模型、托管模型平台或 MLOps 管线。 |
Google 的 Gemini API pricing 页面把 Free、Paid、Enterprise 分开。可发布的结论不是把当前价格复制成静态表格，而是理解每个层级代表什么。Free 适合开发者和小项目，但存在用于改进产品的数据使用边界。Paid 面向需要更高用量或高级能力的生产应用，并说明内容不会用于改进产品。Enterprise 指向企业平台，强调支持、安全/合规、预留吞吐、折扣、MLOps 和 Model Garden。
Billing 文档还提醒一个现实点：速率限制、层级、计费状态和 cap 都是项目或计费账户层面的事。一个项目可以从免费或未计费状态进入付费设置，而不必把每个架构选择都变成 Cloud 企业平台迁移。
所以，不要因为“要上线”四个字就迁移。先写清楚生产压力是什么。如果只是配额、计费、付费模型行、项目拥有者或付费数据使用边界，付费 Developer API 通常应该先被评估。只有当需求明确说出某个 Developer API 无法满足的企业控制，迁移才有充分理由。
什么时候迁移到企业平台
企业迁移不是“更高级”的默认选择，而是控制要求。触发条件应该具体到可验收：
| 触发条件 | 迁移前要问的问题 |
|---|---|
| IAM 和组织策略 | 访问控制是否必须进入 Cloud IAM、服务账号、组织策略或集中安全审查？ |
| 端点和区域控制 | 工作负载是否要求区域端点、全局端点行为或位置相关架构？ |
| 数据驻留和保留 | 是否有文档化的数据驻留、保留、日志或审计要求，Developer API 无法满足？ |
| 预留吞吐 | 流量是否需要保留容量，而不是靠普通层级提升和重试策略？ |
| Model Garden 和 MLOps | 团队是否需要更广的托管模型平台、评估管线、部署治理或伙伴模型？ |
| 网络和安全 | 审查是否要求 VPC、私有连接、集中日志或 Cloud 安全控制？ |
| 支持和合规 | 买方是否需要企业支持、合同审查、合规流程或采购对齐？ |
企业文档尤其重要，因为端点语言很容易被读过头。Google Cloud 的 locations 文档会描述区域和全局端点，但端点本身不等于数据驻留保证，也不等于所有 ML 处理都在某个区域内完成。真正需要驻留时，要看 data residency 文档。需要 zero data retention 时，要看 zero data retention 文档以及客户侧需要完成的具体动作。
迁移说明里不能只写“更安全”或“更企业”。应该写清楚：哪个控制是硬要求，哪个 Google 文档负责这个控制，哪个服务、端点或设置满足它，安全或合规评审需要什么证明。没有这层证明，迁移容易变成复杂度转移，而不是风险降低。
API 密钥和项目归属已经改变旧对比
旧文章经常把 AI Studio 描述成“个人简单 Key”，把 Cloud 平台描述成“严肃身份系统”。现在的 API Key 行为更细。
Google 的 Gemini API key 文档说明 Gemini API 请求可以使用 standard API keys 或 authorization API keys。新 Google AI Studio 密钥默认是 auth keys。文档还说明，不受限制的 standard keys 在 2026 年 6 月 19 日之后会被拒绝，standard keys 需要在 2026 年 9 月前迁移。
这不代表 AI Studio 等于企业平台。它代表 Developer API 路线比旧的“简单 Key”总结更有项目意识。每个 Key 都关联 Google Cloud 项目，项目管理协作者、权限和计费上下文。很多团队只需要这种项目级管理就能上线；但它仍然不能替代组织级 IAM、Cloud 网络控制、数据驻留架构、审计、保留策略或 MLOps 治理。
可以这样拆：
| 问题 | Developer API 的答案 | 企业平台的答案 |
|---|---|---|
| 项目拥有的 Key 能不能支持后端应用？ | 可以，前提是项目、计费、限制、模型和 Key 限制都合适。 | 也可以，但迁移理由应是更广的平台控制，不是 Key 本身。 |
| Key 能不能放在前端代码里？ | 不应该。应放在服务端或托管密钥系统。 | 同样不应该。企业控制不会让公开凭据变安全。 |
| 一个项目 Key 能不能证明生产就绪？ | 不能。还要检查计费、实时限制、数据政策、地区和模型访问。 | 也不能。还要检查 IAM、端点、驻留、保留、支持和发布控制。 |
| 2026 年 6 月和 9 月的 Key 日期是否重要？ | 重要，尤其是旧 standard keys 仍在使用时。 | 重要，但不要把企业迁移当成修复 Key 卫生的捷径。 |
迁移检查清单
迁移前先写一份短决策记录。它要具体到工程、产品和安全评审都能看懂。
- 写明当前路线：AI Studio 原型、免费 Developer API 项目、付费 Developer API 项目，还是已有 Cloud 企业路线。
- 写明未解决阻塞：配额、计费、数据使用政策、地区、IAM、支持、预留容量、MLOps、Model Garden、合规或采购。
- 打开对应 owner 文档：API keys、pricing、billing、rate limits、enterprise locations、data residency、zero data retention。
- 判断阻塞是否能被付费 Developer API 解决，还是必须使用企业平台控制。
- 用同一模型族、请求形态、延迟目标、重试策略和日志边界做一个小试点。
- 在迁流量前确认成本 owner、配额 owner、数据 owner 和支持 owner。
- 保留回滚：旧 Developer API 路线应保持可调用，直到企业路径对被接受工作负载证明相同或更好。
这份记录比大而全的平台对比有用，因为它把决策绑回真实阻塞。只需要配额和计费的团队不该过早吸收企业迁移复杂度。已经有数据驻留、预留吞吐或组织策略要求的团队，也不该继续假装一个快速 API Key 就足够。
设置和配额问题该去哪里
平台选择不应该变成重复的设置教程。
| 具体问题 | 更合适的下一步 |
|---|---|
| 创建 Key、安全保存、第一次请求、403/429 准备度。 | Google AI Studio API key setup |
| 模型是否免费、项目级限制、什么时候开计费、为什么遇到 429。 | Gemini API free tier limits |
| 工作负载是否需要 Cloud 控制，而不是普通 Developer API 生产准备。 | 留在当前路线判断，使用迁移检查清单。 |
这个拆分能减少重复内容。Key 设置任务需要命令、环境变量和错误恢复。配额任务需要活的价格和限制检查。平台选择任务需要命名边界、责任边界和迁移阈值。
常见问题
生产 Gemini 应用应该用 Google AI Studio 还是 Vertex AI？
大多数生产应用可以先用 Gemini Developer API，尤其是阻塞点只是计费、配额、项目归属、付费模型访问或后端集成。只有 IAM、区域/数据控制、预留吞吐、MLOps、Model Garden、支持、合规或采购结构成为硬要求时，才迁移到企业平台。
Google AI Studio 只能做原型吗？
不能这样理解。AI Studio 是浏览器里的试验和 Key 管理入口，Gemini Developer API 才是很多应用可以继续使用的开发路线。重点不是应用是否“真实”，而是未解决需求属于普通应用生产准备，还是企业平台治理。
Gemini 是否一定要通过 Vertex AI 使用？
不一定。Gemini 可以通过不同 Google 面使用。直接开发者路线是 Gemini Developer API；企业 Google Cloud 路线现在更多由 Gemini Enterprise Agent Platform 和相关 Cloud AI 服务承担。很多人仍用 Vertex AI 指企业侧，但实际选择要看 API 路线和控制要求。
什么时候该先付费 Developer API？
当阻塞点是用量、计费、项目归属、付费模型行、付费数据使用边界或更稳定的项目级限制时，先评估付费 Developer API。这些通常不是企业迁移理由，而是原型变成付费项目的信号。
什么时候企业平台值得迁移？
当需求说出明确平台控制时：IAM 和组织策略、区域端点架构、数据驻留、零数据保留工作、预留吞吐、Model Garden、MLOps、私有网络、企业支持、合规审查或采购流程。
2026 年 6 月之后 AI Studio Key 还有迁移问题吗？
旧 standard keys 需要处理。Google API-key 文档说明不受限制的 standard keys 在 2026 年 6 月 19 日之后会被拒绝，standard keys 需要在 2026 年 9 月前迁移。新 AI Studio Key 默认是 auth key。不要靠旧教程判断当前密钥状态。
区域端点是否等于数据驻留？
不等于。Google Cloud 企业端点文档区分端点位置和数据驻留保证。如果数据驻留重要，需要核验 data residency 文档、支持地区、请求路径、日志行为和保留设置，而不是只看端点名称。
能不能同时保留 Developer API 和企业路线？
可以，而且阶段式迁移往往更稳。Developer API 可以继续服务原型、低风险负载或回滚路径；企业路线先用小流量试点验证 IAM、端点、数据、吞吐、日志、支持和成本行为。只有企业路径满足当初触发迁移的控制要求，才移动主流量。
