Google Cloud 为 Gemini Enterprise 添加了新的计费灵活性和成本管理工具，使 AI 支出控制更接近于构建和运行代理的团队。
这一变化很重要，因为代理工作负载的行为与传统 SaaS 席位不同。编码代理、支持代理或工作流代理可以调用多个模型、重复调用工具，并跨用户、项目和环境生成可变的使用情况。这使得事后更难解释成本。 Google 现在将该问题视为 Gemini Enterprise 及其开发者生态系统内的产品表面，而不是完全将其留给标准云计费导出。
根据 Google Cloud 的说法，Gemini Enterprise 订阅中包含的开发者工具配额现在集中在 Google Cloud 项目级别。该公司还描述了 Gemini Enterprise 和开发人员工具（包括 Gemini Enterprise 和 Android Studio 中的 Google Antigravity）对代理工作负载的扩展计费灵活性。另外，Google Cloud 文档介绍了一个 AI 成本摘要代理，该代理可以分析 Gemini 使用情况，包括 Gemini API 和 Vertex AI 的支出，并按 API 密钥细分 AI 支出。
发生了什么变化
最具体的运营变化是与 Gemini Enterprise 订阅相关的开发人员工具配额的项目级池。组织可以在项目级别管理包含的配额，而不是仅考虑个人用户消耗单独的配额。对于工程团队来说，这更接近人工智能工作的实际组织方式：按产品、环境、团队、应用程序或面向客户的工作流程。
AI 成本摘要代理是另一个值得注意的部分。谷歌将其描述为一种用于分析 Gemini API 和 Vertex AI 的 Gemini 使用情况和 AI 支出的工具。该文档称，它可以按 API 密钥细分支出，这是现代人工智能系统的关键归因级别。 API 密钥通常映射到服务、内部工具、实验、租户或代理工作流程。当账单上涨时，有用的问题很少只是“哪种型号贵？”它是“哪个工作负载、密钥、应用程序或团队导致了更改？”
这种区别对于代理工作负载尤其重要。单个用户请求可能会触发计划、检索、工具调用、推理步骤、代码执行或后续模型调用。如果没有归属，财务团队会看到账单，工程团队会看到日志，而双方都无法清楚地了解所发生的情况。
为什么这对代理平台很重要
人工智能计费正在成为一项具有竞争力的功能。在第一波 API 采用期间，模型访问和基准性能主导了购买对话。随着使用进入生产，未解决的问题变得更加平凡和昂贵：预算、发票、归属、缓存核算、项目限制、异常检测和提供商比较。
谷歌的举动是一个信号，表明超大规模平台期望买家直接在人工智能产品内部要求这些控制。 Gemini Enterprise 不仅仅被定位为使用模型的地方。它越来越成为管理大规模使用模型的运营后果的地方。
这改变了市场其他部分的预期。如果云原生人工智能套件可以通过项目和 API 密钥来解释支出，那么多模型平台和网关将有望在跨提供商之间至少发挥同样的作用。通过一个应用程序堆栈运行 OpenAI、Anthropic、Google、AWS 托管模型和开放式部署的团队不能单独依赖一个云的 FinOps 层。它需要对整个资产的使用、模型选择和成本有一个标准化的看法。
对于 Model Gate 和类似的 OpenAI 兼容网关，实际连接是直接的。统一计费和人工智能使用分析不再是后台的便利。它们是控制平面开发人员和企业主用来决定哪些模型应该可用、哪些团队可以使用它们以及工作负载何时变得过于昂贵而无法按设计运行的一部分。
谁受到影响
使用 Gemini API 或 Vertex AI 的企业开发人员是最直接的受众。拥有多个 API 密钥、服务帐户、环境或内部代理的团队应该能够更好地了解 Gemini 相关支出的来源，假设他们采用新工具并干净地组织项目。
财务和采购团队也受到影响。人工智能成本可能很难预测，因为使用量会随着任务量和代理行为而变化，而不仅仅是与员工人数有关。项目级配额池和 API 密钥级报告可以减少内部退款、预算审查和续订规划对手动电子表格工作的依赖。
构建人工智能功能的产品团队有一个不同的担忧：利润。如果面向客户的代理过于频繁地使用高级模型，或者后台工作流程重试次数过多，则成本可能会悄然超过该功能所带来的收入。更好的归因可以帮助团队在发生结构性损失之前抓住这些模式。
代理机构、经销商和托管服务提供商也应该注意。客户不仅越来越多地询问人工智能功能是否有效，而且还询问其使用是否可以受到监管。对于在多模型 API 之上构建服务的合作伙伴来说，按客户、项目、API 密钥和模型进行的成本报告正在成为产品的一部分。
Google 方法的局限性
悬而未决的问题是这些工具在实践中减少了多少人工智能总支出。谷歌关于避免人工智能“贴纸冲击”的信息是可以理解的，但节省的成本取决于客户的行为：团队是否设定预算、对异常情况采取行动、改变模型选择、修复低效的代理或重新设计工作流程。可见性是必要的，但它与优化不同。
还有一个锁定问题。原生云成本工具在自己的生态系统中很有用，但许多公司故意将人工智能工作负载分散到提供商之间。 Gemini 特定或以 Google Cloud 为中心的视图可能无法解释在其他地方调用 OpenAI 兼容端点、使用 Bedrock 进行区域路由或私下运行开放权重模型的应用程序的全部成本。
这就是网关仍然可以增加价值的地方。云提供商可以公开其自己的服务的丰富细节。网关可以规范模型提供商、API 密钥、团队、应用程序和客户之间的使用和计费。越多的云供应商让 AI FinOps 变得可见，就越多的买家会要求他们使用的每个模型都具有相同的可见性。
开发者现在应该做什么
使用 Gemini Enterprise 的团队应检查项目和 API 密钥的结构。如果在太多应用程序或环境中共享密钥，则 API 密钥级支出报告的用处将会降低。清洁归因始于将生产与开发、面向客户的服务与实验、以及高风险代理与普通交互使用分开。
开发人员还应将成本数据视为工程信号。模型支出的激增可能会揭示低效的提示、失控的代理循环、意外的重试、过多的上下文窗口或不再与任务匹配的模型选择。成本可观察性属于延迟、错误率和质量评估，而不是损坏发生后的每月发票审核。
Google 的公告不仅仅是又一次结算更新。它反映了人工智能基础设施的更广泛转变：随着代理变得更加自主，API 使用变得更加多变，解释和控制支出的能力正在成为核心平台要求。