生成式 AI 改变了云成本的增长方式：一个看似简单的提示词，背后可能触发长上下文推理、Agent 工具调用、容器扩容或大规模查询。请求数相同，并不意味着计算量和账单相同，因此仅观察 QPS、调用次数和月底预算告警，已经不足以控制 AI 工作负载的财务风险。
Google Cloud 在 Billing Console 中增加了两类原生能力：AI 服务早期异常检测负责尽早发现成本偏离，Google Cloud Budgets 支出上限负责在达到阈值后限制继续产生费用的服务用量。两者组合起来，形成“发现、定位、阻断、人工恢复”的闭环。
为什么 AI 成本需要新的监控方式
传统预算告警通常围绕固定金额或账单数据展开，但 AI 工作负载有三个明显差异：
- 单次请求成本差异很大，提示词数量不能直接代表 Token、推理时间或下游调用量。
- Agent、重试循环和自动扩容可以在没有人工操作的情况下快速放大用量。
- 正式账单数据可能需要一段时间才能完成汇总，等到常规告警触发时，费用可能已经继续增长。
因此，有效的成本控制不能只有“月底是否超预算”这一道判断。团队既要识别增长方向是否异常，也要有一条能够自动执行的财务边界。
第一层：用早期异常信号定位增长来源
Billing Console 的 Anomalies 工具会分析项目历史数据，为每日、服务级成本建立包含季节性特征的动态基线。团队不需要先手工设置一个固定异常阈值。
当早期成本信号明显偏离基线时，系统会生成异常记录，并通过根因分析列出推动增长的前三个 SKU。这比只收到“项目费用上涨”更有操作性：值班人员可以直接判断问题来自模型调用、Agent 平台、Cloud Run，还是 Cloud Run Functions。
这类信号适合回答三个问题：
- 当前增长是否超出了项目自身的正常波动？
- 哪个服务和 SKU 是主要贡献者？
- 这是预期实验、流量增长，还是无限循环、错误重试等故障？
早期异常检测本质上是侦测工具，并不等于硬性限额。确认某个高速增长的服务需要明确边界后，还要配置第二层保护。
第二层：用 Spend Caps 阻止继续产生按量费用
Spend Caps 是 Google Cloud Budgets 中的原生支出上限。在公开预览阶段，一个上限面向单个项目中的单项服务，并按固定月度周期计算。累计费用达到设定金额后，Google Cloud 会限制该范围内继续产生费用的用量，而不会删除数据和资源，也不会影响项目内未被该预算覆盖的其他服务。
其关键行为包括：
- 预算达到 50%、80% 和 100% 时，Billing Administrator 与 Project Owner 会收到邮件。
- 达到上限后，使用限制会持续生效，直到管理员在 Budgets UI 中手动解除。
- AI 服务的上限预计在达到阈值后的数分钟内触发，但它不是逐请求、零延迟的计费闸门。
- Committed Use Discounts、Provisioned Throughput 等固定承诺费用仍会继续计费，因为暂停新增按量使用并不会取消合同费用。
目前摘要列出的预览支持范围包括 Gemini API、Agent Platform、Cloud Run 和 Cloud Run Functions。配置前仍应在控制台确认所在区域、项目和具体服务行为是否符合当前预览条件。
可以这样实践：为开发项目建立成本控制清单
Spend Caps 和早期异常检测主要通过 Billing Console 配置。下面的 YAML 不是 Google Cloud 官方配置 API，而是一份可直接纳入代码仓库的团队策略文件：它让额度、负责人和恢复条件接受代码评审，避免控制台配置变成无人维护的隐性状态。
将以下内容保存为 ai-cost-guardrails.yaml，再按项目实际情况修改项目 ID、服务和金额：
version: 1
project: my-ai-sandbox
billing_controls:
anomaly_detection:
enabled: true
review_owner: platform-oncall@example.com
investigation_sla_minutes: 30
require_top_sku_review: true
spend_caps:
- service: Gemini API
monthly_cap_usd: 500
environment: development
lift_requires:
- incident_root_cause_recorded
- projected_month_end_cost_reviewed
- engineering_owner_approved
- service: Cloud Run
monthly_cap_usd: 200
environment: development
lift_requires:
- scaling_configuration_reviewed
- retry_loop_ruled_out
- platform_owner_approved
可以用下面的命令检查文件是否为有效 YAML。运行前需要安装 Python 3 和 PyYAML：
python3 -m pip install pyyaml
python3 - <<'PY'
from pathlib import Path
import yaml
path = Path("ai-cost-guardrails.yaml")
policy = yaml.safe_load(path.read_text())
assert policy["billing_controls"]["anomaly_detection"]["enabled"] is True
for cap in policy["billing_controls"]["spend_caps"]:
assert cap["monthly_cap_usd"] > 0
assert cap["lift_requires"], f"{cap['service']} 缺少恢复条件"
print(f"{cap['service']}: USD {cap['monthly_cap_usd']}/month")
PY
随后在 Billing Console 中执行对应操作：进入 Anomalies 启用并检查早期异常；再进入 Budgets & Alerts，为 YAML 中的每个“项目 + 服务”组合创建 Spend Cap。YAML 负责治理记录，控制台中的原生配置负责实际执行。
落地时不要忽略边界条件
建议先在测试和开发项目中启用支出上限。额度不能简单等于“团队愿意支付的最大金额”，还应预留触发延迟期间可能产生的费用，并考虑固定承诺成本。
生产环境需要更谨慎：如果 Gemini API 或 Cloud Run 位于关键业务链路，触发上限可能直接表现为请求失败或服务不可用。此时应把支出上限与业务降级、调用配额、重试上限和熔断策略一起设计，而不是让财务控制成为唯一的运行时保护。
一套可执行的采用清单是：
- 为高波动 AI 项目启用早期异常检测，并明确告警负责人。
- 根据 RCA 中的前三个 SKU 判断需要设置上限的服务。
- 按“项目 + 服务”设置月度 Spend Cap，先覆盖开发与实验环境。
- 记录 50%、80% 和 100% 告警的处理动作。
- 规定解除上限前必须完成的根因分析和费用预测。
- 单独核算承诺用量与预置吞吐量，因为它们不会随使用限制停止计费。
- 定期演练触发后的业务表现，确认失败模式和恢复流程可接受。
早期异常检测解决的是“尽快看见”，Spend Caps 解决的是“到线即停”。只有把两者与工程侧的配额、重试和降级机制结合起来，AI 团队才能在保持实验速度的同时，把最坏情况下的成本暴露限制在可接受范围内。