Google Cloud Billing 怎么管理，企业如何查看不同项目的真实成本

企业使用 Google Cloud 一段时间以后，最容易出现的问题往往不是不知道云服务花了钱，而是不知道钱到底花在哪里。一个 Cloud Billing Account 下面可能连接几十个甚至几百个 Project，不同项目又可能同时使用 Compute Engine、Cloud Storage、BigQuery、Cloud SQL、网络服务以及 GPU。如果只看每个月的总账单，很难判断某个业务为什么突然变贵，也很难知道哪些成本属于研发、生产、测试或者某个具体客户。

Google Cloud 的成本管理因此不能只靠月底看账单，而应该把 Project、资源标签、Billing Reports、预算、折扣以及详细计费数据结合起来。

第一步通常不是给所有资源强制贴标签，而是先设计合理的资源和项目层级。

Google Cloud 的 Project 本身就是成本分析的重要边界。企业可以按照业务、环境、团队或者客户建立不同 Project，再利用 Folder 和 Organization 形成更高层级的管理结构。Billing Reports 可以按照 Project 或 Project hierarchy 查看成本，因此很多企业完全可以先通过合理的 Project 划分建立第一层成本归属，而不是把所有成本管理都建立在 Label 上。

Label 更适合解决 Project 内部的进一步成本拆分。例如一个 AI 项目可能同时运行训练、推理和测试任务，那么可以设计 workload=training、workload=inference、environment=production 等资源标签。Billing Reports 可以根据这些标签过滤或者分组，Cost Table 也支持按照资源 Label 查看符合条件的成本。

这里有一个经常被忽略的问题：Label 并不是给资源贴上以后就能追溯所有历史成本。如果一个 Compute Engine 实例在 8 月 15 日才增加 environment=production，按照这个 Label 查询时，相关成本通常只能从标签生效之后开始计算。因此企业建立标签体系时，最好在资源创建阶段就通过基础设施即代码、组织策略或者部署流程统一设置，而不是运行几个月以后才补标签。

预算管理则是另外一套机制。

Google Cloud Budgets 的作用主要是监控成本是否接近预定额度，而不是替代 Billing Reports。预算可以设置月度、季度、年度或者自定义周期，并且可以针对整个 Cloud Billing Account，也可以限定到 Organization、Folder、Project、Service 或符合条件的资源 Label。企业可以设置 50%、80%、90%、100% 等不同警戒线，在实际成本或者预测成本达到相应比例时发送通知。

因此，“预算统计是否准确取决于所有资源有没有 Label”并不准确。一个按照 Project 设置的预算，并不会因为某台虚拟机没有 Label 就失去项目成本统计能力。Label 更多解决的是更细粒度的成本归属问题。

如果企业规模较大，单纯使用 Cloud Console 中的图表也可能不够。这时可以开启 Cloud Billing 数据导出到 BigQuery。

Google Cloud 提供 Standard usage cost 和 Detailed usage cost 等导出方式。Standard 数据包含项目、服务、SKU、标签、地区、成本、使用量、折扣和调整等信息；Detailed usage cost 进一步提供资源级别的信息，可以帮助企业定位究竟是哪一台虚拟机、哪一个磁盘或者其他具体资源产生了成本。

这一步对于 AI、数据分析和大型 SaaS 企业尤其重要。企业可以把 Billing 数据与自己的业务数据库结合起来，例如建立“客户—Project—资源—成本”的对应关系。这样管理层看到的就不再只是“这个月 Google Cloud 花了 20 万美元”，而可以进一步回答某个客户贡献了多少收入、消耗了多少云资源，以及某项业务的云计算成本到底占收入多少。

成本分析时还应该把账单中的几个维度区分开。

Project 适合回答“哪个业务或者团队花钱最多”；Service 可以回答“钱主要花在 Compute Engine、BigQuery 还是 Cloud Storage”；SKU 可以进一步回答“具体购买的是什么资源”；Location 可以发现不同地区之间的成本差异；Label 则适合进一步拆分生产、测试、训练、推理等工作负载。Billing Reports 本身就支持这些不同的分析方式。

对于 AI 项目，还不能简单地认为 GPU 就是全部成本。

一个模型训练项目可能同时产生 GPU、CPU、内存、Persistent Disk、对象存储、网络流量以及日志和监控成本。GPU 虽然通常是计算成本中的大头，但如果训练数据需要频繁跨区域传输，或者模型需要大量数据读写，存储和网络也可能成为重要支出。因此成本优化不能只盯着 GPU 使用率。

更重要的是把“资源价格”和“资源利用率”分开看。

一台 GPU 虚拟机即使每小时价格很低，如果每天只有几个小时真正运行训练任务，其余时间处于闲置状态，仍然可能产生大量浪费。反过来，一台价格较高但长期满负荷运行的机器，单位计算任务成本未必更高。

Google Cloud 提供多种降低 Compute Engine 成本的方式，但这些机制不能简单概括成“预留实例”。

例如 Committed Use Discounts，也就是 CUD，可以通过承诺一定期限的资源使用获得折扣。Compute Engine 当前不同资源和机器类型的 CUD 折扣幅度不同，并不是统一的 40% 到 70%。对于 GPU，部分资源也可以参与相应的 CUD，但具体折扣取决于资源类型、区域和承诺方式。

如果任务可以接受中断，则 Spot VM 往往更适合批处理、模型训练以及其他具备容错能力的工作负载。Google Cloud 当前公布的 Spot VM 折扣最高可达到按需价格的 91%，但这个数字不是固定折扣，Spot 价格会变化，而且虚拟机可能随时被回收。因此不能把 Spot 当成普通生产服务器的廉价替代品。

对于 GPU 任务尤其如此。Spot GPU 可以明显降低计算成本，但训练系统必须能够保存 checkpoint、重新调度任务，并处理实例被回收的情况。如果一个任务被中断以后只能从头开始训练，那么表面上的 GPU 折扣可能很快被重新计算的成本抵消。

自动关机也可以降低开发和测试环境的浪费。例如研发团队可以通过调度机制在夜间停止非生产虚拟机。不过“GPU 利用率低于 30%就自动关闭”并不是一个适用于所有业务的通用规则。某些模型推理任务可能长期保持低 GPU 利用率，却仍然要求稳定在线；某些训练任务则可能因为数据加载、通信或者同步阶段出现短暂低利用率。如果只看单一 CPU 或 GPU 指标自动删除资源，反而可能影响业务。

比较成熟的做法，是把成本指标和业务状态结合起来。例如开发环境超过一定时间没有使用，可以自动停止；训练任务完成后释放 GPU；临时测试项目设置生命周期；生产环境则根据业务需求决定是否允许自动缩容。

企业还需要注意网络成本。跨区域数据传输、互联网出口以及某些服务之间的数据交换，都可能形成计算资源之外的费用。尤其是 AI 系统，训练数据、模型权重、日志和推理结果可能在不同服务之间大量移动。如果存储、GPU 和计算服务分布在不同区域，网络费用和数据访问延迟都应该纳入架构设计，而不能等到月底账单出来以后再处理。

因此，Google Cloud 成本管理比较合理的结构可以分成三个层次。

第一层是 Project 和组织层级，解决“谁负责这笔钱”的问题；第二层是 Service、SKU、Location 和 Label，解决“钱具体花在哪里”的问题；第三层是 BigQuery Billing Export 和企业自己的业务数据，解决“这些成本为什么发生，以及这些成本是否创造了对应业务价值”的问题。

对于小型团队，Cloud Billing Reports 加 Budgets 通常已经能够满足日常管理需要。随着项目增加，可以逐步引入 Label 和统一的 Project 规划。到了多个团队、多客户、多区域或者 AI 大规模计算阶段，再把 Billing 数据导入 BigQuery，建立自己的成本分析体系。

成本管理的目标也不是单纯追求账单越低越好。关闭所有 GPU、压缩所有存储、限制所有网络流量当然可以降低支出，但也可能降低研发效率、延长训练时间或者影响用户体验。企业需要观察的是单位业务产出的云成本，例如每个客户的基础设施成本、每百万次推理的成本、每次模型训练的成本以及每美元云计算支出产生的收入。

当 Cloud Billing 从月底核对账单，进一步变成 Project、资源、工作负载和业务收入之间的成本关系分析时，企业才有可能判断一项云计算支出到底是浪费，还是在支持业务增长。这也是 Google Cloud 成本管理从“看账单”走向 FinOps 的关键一步。