Vertex AI 生产环境为什么必须用企业账号体系：账号、权限与成本治理

先讲一个我最近遇到的真实场景客户反馈 Vertex AI Pipeline 突然读不到 GCS 桶里的数据训练任务跑一个挂一个。我排查了半天最后发现根因不在代码、不在服务账号而是这个 Pipeline 所在的项目是某位离职同事用个人 Gmail 账号开通的。人一走权限跟着自然人账号一起停用整个项目立刻变成半残废状态。这事情听起来像段子但在企业里一点都不少见。所以今天想认真聊一个话题Vertex AI 这种平台级服务为什么必须放在 Google Cloud 的企业账号体系里跑。这里说的企业账号体系不是单纯注册个企业邮箱而是指完整的组织节点Organization Node、文件夹、项目、IAM、结算账户和配额治理这套底座。缺了这套底座模型实验阶段也许还能凑合一旦进入多人协作、生产推理、成本管控和审计合规阶段个人账号和散装项目一定会成为最大的隐患。这篇文章适合正在用个人账号跑 Vertex AI 的算法工程师也适合准备把模型从实验推向生产的架构师和平台负责人。1. Vertex AI 为什么离不开企业级资源边界1.1 平台服务的每一层都在吃云资源权限很多人以为 Vertex AI 就是一个 API调一下就能训练模型。实际上它是由一堆子服务组成的自定义训练任务CustomJob / TrainingPipeline、Vertex AI Pipelines、模型注册表Model Registry、在线推理端点Endpoint、特征存储Feature Store、实验跟踪Experiments、TensorBoard 等等。这些组件全部依赖同一个 Google Cloud 项目里的底层资源GCS 桶存数据集和模型产物、Artifact Registry存容器镜像、Cloud Run / Cloud Functions跑流水线组件、VPC网络隔离、Secret Manager存密钥、KMS加密密钥。你跑一个训练任务至少会触发这几件事创建一批短暂计算资源、读写 GCS 中的训练数据、把日志和指标写入 Metadata Store、可能还要从 Artifact Registry 拉取自定义镜像。任何一个环节的权限出了岔子任务就卡住。我用生活类比解释一下个人账号玩法像在自己家厨房做饭锅碗瓢盆都是私人的企业账号体系则是中央厨房有独立的进货、仓储、消防和门禁制度。Vertex AI 这种带客人来做年夜饭的场景没有中央厨房的规范和隔离后厨一定会乱。单个模型实验可以容忍混乱但十几个模型、几十条 Pipeline、多个团队共用一套训练平台时没有企业级资源边界互相踩脚是必然的。1.2 个人账号的隐形成本所有权、凭据与账单个人账号系统跑 Vertex AI表面上是免费试用或者先跑通再说实际上隐含三个大坑。第一是所有权跟着自然人走。算法同学用自己的 Gmail 创建项目公司既不拥有这个项目也无法在员工离职后接管。更麻烦的是项目里可能还躺着训练数据快照、未发布模型、客户相关特征数据。公司对这些资产没有任何控制权。第二是凭据没有边界。个人账号一旦被攻破或者 API Key 泄露风险不局限于单个项目还会波及其他绑定在同一账号下的 Google 服务。对于需要满足内部安全审计的企业来说这属于不可接受的风险敞口。第三是结算和身份混在一起。个人账号绑定的往往是个人信用卡成本无法归集到部门预算告警无从谈起。月底财务问这个月 Vertex AI 花了多少钱你只能拿一张个人账单去报销这种体验我相信踩过的人都懂。1.3 一个典型的翻车实例再讲一个更常见的场景某团队按照快速开始文档顺手在个人项目里创建了 Endpoint把模型发布成在线推理服务。三个月后负责部署的同学转岗公司收回他的个人账号所有端点全部 503没有任何人能接管。要恢复的唯一办法是拿到该账号的登录权限——在企业环境里这种事基本做不到。这类案例我几乎每次和客户聊都能听到一两例。所以我对团队的建议很直接模型实验阶段个人环境随便折腾一旦涉及训练数据导入、多人协作、在线推理立刻迁到企业账号体系下。别等到模型准备上线时再迁移那是最贵的时间点。2. 组织节点、文件夹、项目账号体系的三层骨架2.1 Organization Node 才是公司的所有权根Google Cloud 企业账号体系最底层是 Organization Node组织节点一般通过 Cloud Identity 的专属域名创建。它代表的是这家公司本身是资源层次结构的根节点。公司所有的项目都挂在这个根节点下面员工离职后项目的权限、数据、模型依然属于组织不会被个人账号绑走。这才是企业账号体系和个人账号散装项目最本质的区别。控制台里的资源层次大致是Organization Node 文件夹部门 / 环境 项目产品 / 业务单元 资源GCS 桶、Vertex AI 模型、端点等如果公司没有组织节点所有项目都是孤立项目standalone project别人想从组织层面做统一安全策略也找不到抓手。Google Cloud 的很多企业级能力比如 VPC Service Controls 的服务边界、组织级统一审计策略、跨项目资源搜索都是建立在组织节点之上的。所以搭建账号体系第一步就是要先拥有一个真实的组织节点而不是急着开项目。2.2 Folder 的三种常见用法组织节点之下是文件夹Folder主要用来分层管理项目。我见过最常用的三种分法按环境分dev / staging / prod 三个文件夹然后通过 IAM 和组织策略严格控制生产文件夹的权限范围。按业务线分推荐团队、搜索团队、风控团队各一个文件夹团队成员只在各自的文件夹内有权限。按成本中心分每个预算单位一个文件夹账单归属一目了然财务对账时省很多功夫。在 Vertex AI 场景里我倾向于至少把项目拆成实验和生产两类分别挂到不同文件夹下。实验项目的权限可以放得松一些生产项目则严格要求审批、审计和最低权限。文件夹的好处是权限和策略可以继承你不需要在每个项目上重复配置。2.3 项目最小的权限和结算边界在 Vertex AI 语境里项目是最小隔离单元。我推荐的项目拆分方案是至少分成三类数据项目存放原始数据、特征表、训练数据集权限只开放给数据工程师和受控服务账号。训练项目跑训练 Job、Pipeline输出模型工件到模型仓库。推理项目部署 Endpoint做在线或批量预测访问控制最严格。这种拆法的好处很直接训练项目出问题不会影响推理项目数据项目的权限可以收紧到只有数据相关角色成本也能精确分摊到各个业务方。如果所有东西堆在一个项目里任何一个测试脚本误删数据都可能导致生产推理服务遭殃。2.4 组织策略把规则的锁提前上好账号体系建好之后还要配置 Organization Policy 防止日后被绕过。我常用的几条包括iam.disableServiceAccountKeyCreation禁止创建长期有效的 Service Account Key强制团队改用短期凭证或 Workload Identity Federation。resourcemanager.limitProjectCreation限定只有特定文件夹下的管理员可以创建新项目避免野项目遍地开花。针对 Vertex AI 的 VPC-SC 服务边界策略把 AI 平台的访问限制在企业内部网络范围内。这些策略看起来和训练一个模型没有直接关系但没有它们账号体系会随着时间被各种快捷操作慢慢腐蚀。比如某个工程师为了本地调试图省事创建了一把长期 Key然后随手提交到 Git 仓库——这类问题不是靠自觉能解决的只能靠组织策略从机制上禁止。3. IAM把谁能建训练任务、谁能删端点落到最小权限3.1 Vertex AI 的原生角色已经切得够细Google Cloud 的 IAM 里Vertex AI 原生提供了多个预制角色比如roles/aiplatform.admin、roles/aiplatform.user、roles/aiplatform.customCode、roles/aiplatform.viewer。这些角色的粒度基本能满足大多数团队的需求。我常用的配套方式如下算法工程师给roles/aiplatform.user可以创建和管理训练任务、发布模型、部署端点再叠加 IAM Condition 限制只能操作 dev 或 staging 环境。数据工程师通常只给 Storage 对象查看/读写权限让他们管理数据集但不接触在线端点。运维 / 安全人员给 Vertex AI 只读角色加上日志查看权限方便排查问题但不修改配置。如果你把 Enterprise 级别的需求带进来光给roles/owner或者roles/editor肯定是不行的。前者权限过大后者几乎等于裸奔。我见过太多团队为了省事直接给算法工程师绑了editor角色结果一次误删操作把 Artifact Registry 里的镜像全清了这种情况在 Vertex AI 生产环境里非常致命。3.2 服务账号任务的临时身份Vertex AI 底层有两类服务账号很多人分不清楚。第一类是 Google 托管的 Vertex AI Service Agent形如service-PROJECT_NUMBERgcp-sa-aiplatform.iam.gserviceaccount.com由平台自动创建负责访问项目内的默认资源比如写日志、读元数据。这个服务账号原则上不需要用户手动干预也不应该去改它的权限。第二类是自定义服务账号Custom Service Account是你在训练任务或批量预测时通过--service-account参数或 SDK 显式指定的账号。这个账号决定了你的训练脚本到底能访问哪些数据桶、哪些 Artifact Registry 仓库。实际经验里最坑的是自定义服务账号权限少写一两个任务不会在启动时报错而是跑到一半才失败。比如训练脚本读取 GCS 文件时突然 403。所以我对团队的要求是自定义服务账号从最小权限开始先只给roles/storage.objectViewer列表和读取确认任务能跑通再按需逐步加权限。尽量不要一上来就给roles/storage.admin。3.3 IAM Condition把权限约束到资源级别光有角色还不够。同一个角色绑定到所有资源等于没有做隔离。好用的武器是 IAM Condition也就是在权限绑定时加一个条件表达式。比如可以限定某个成员只能操作名称以manual-*开头的端点resource.name.startsWith(projects/_/locations/us-central1/endpoints/manual-)这样即便某位工程师在某个角色下拥有管理端点的权限他也只能操作符合条件的端点。对抗权限漂移、防止误删生产资源这种方法比反复开会强调大家小心一点有效得多。3.4 Service Account Key 的典型坑我自己踩过的一个典型坑是为了在本机跑 Vertex AI SDK图方便创建了服务账号 JSON Key然后不小心提交到了 Git 仓库。几天后安全团队提示Key 已经被外部扫描器抓到被迫紧急轮换所有相关权限。这个问题的教训不是下次小心而是从机制上禁用长期 Key。正确做法是本机开发用gcloud auth application-default login让 SDK 使用你自己的身份去访问资源CI/CD 里用 Workload Identity Federation把 GitHub Actions 或其他 CI 系统的身份直接映射到 Google Cloud 服务账号组织策略里打开iam.disableServiceAccountKeyCreation从源头禁止。这一步做得好账号体系的安全性才算是真正闭合。4. 结算账户与配额成本失控前的最后防线4.1 Billing Account 与项目的关系一个完整的企业账号体系里所有项目都要挂到企业结算账户Billing Account上而不是个人支付方式。这样 Vertex AI 的训练费用、端点费用、GCS 存储费用才能统一结算也才能使用预算和告警功能。预算告警的配置建议按月设置固定预算阈值设 50%、90%、100%通知渠道至少有两个比如邮件加 webhook。触发后自动发消息到内部群相关人员当天就能看到。我见过最多的一类成本失控事故是实验做完了Endpoint 忘记删除每小时按节点计费跑了一整周月底账单直接多出好几万。预算告警本身不能替你删资源但它能让你在第二天早上就发现成本异常上涨及时止损。4.2 Vertex AI 的配额体系Vertex AI 相关的配额分散在多个维度每分钟请求数RPM、并发训练任务数、每个区域的端点和大模型配额等。在控制台的 Quotas 页面搜索aiplatform.googleapis.com就能看到。如果训练并发一上来就报Quota exceeded通常不是代码 bug而是配额没有提前申请。配额申请一般要求写明预估用量和持续需求这时候企业账号体系的优势就体现出来了项目归属清晰历史消费记录客观配额审批通过率会比个人账号高很多。如果你用的是个人账号Google Cloud 很难判断你是真实企业配额卡住的概率也大。4.3 此结算账户已关闭、暂停或信誉不佳的排查链路Google Cloud 用户在兑换赠金credits时经常会看到这样一段提示google cloud 兑换赠金显示此结算账户已关闭、暂停或信誉不佳。请在云控制台中查看。我帮人排查过几次基本链路如下确认当前登录账号有该结算账户的 Billing Account Viewer 或 Editor 权限。进入 Cloud Console 的 Billing 页面选择目标结算账户查看 Overview 里的状态。状态一般有 Active、Closed、Suspended、Disabled。如果是 Suspended大概率是支付验证没过账单地址不完整、绑定的银行卡被拒、或者赠金兑换触发了风控。按界面提示补全信息必要时点 Reactivate 走重新验证流程。如果显示信誉不佳通常是系统根据历史付款结果做的风险标记比如之前有过支付失败或退款争议。处理方式是更新有效的支付方式并按照官方支持流程提交验证材料。等状态恢复为 Active 之后再回到 Offers / Credits 页面重新 redeem。这条提示也说明了另一个问题企业账号体系里的结算账户要提前养好。正式账号做实名认证、绑定公司支付方式、开启预算告警平时基本不会遇到这类临时状态异常。等到需要用赠金或提额度时才发现账户被冻结才是最被动的。4.4 成本治理的实用三板斧除了预算告警Vertex AI 的成本治理还有几个实用手段可容错的训练任务用 Spot 节点价格远低于按需节点在线端点设置最小/最大副本数并开启自动扩缩容避免常驻高配节点为模型版本设置生命周期保留策略过期版本自动下线。这些手段不需要很高的实施成本但对账单金额的影响非常大。我把它们列为企业账号体系的一部分是因为没有统一的账号和项目级治理这些优化很难落地——你会不知道哪些任务用了 Spot哪些模型版本还挂在线上浪费钱。5. 从零落地的实操清单照着这个顺序建基本不会错5.1 第一步初始化组织节点如果公司还没有 Cloud Identity先注册一个专属域名并完成 DNS 验证然后启用 Cloud Identity。组织节点创建完成后用管理员账号执行gcloud organizations list会看到一个组织形式如organizations/123456789012的 ID记录它后续的资源创建和管理都基于这个组织节点。这一步容易忽略的是初始管理员账号必须是企业管理员而不是某个员工的个人账号。否则后面组织节点的所有权又会落到个人头上重蹈覆辙。5.2 第二步规划文件夹与项目命名我建议的 Folder 层级是公司名 / 环境dev、staging、prod或者公司名 / 业务线 / 环境。项目命名建议带前缀区分用途比如gcloud projects create vertex-prod-001 \ --folderFOLDER_ID \ --labelsteamml,envprod创建后绑定结算账户gcloud billing projects link vertex-prod-001 \ --billing-accountXXXXXX-XXXXXX-XXXXXX如果项目之前已经创建但没有挂在组织节点下可以使用gcloud projects update迁移到目标文件夹。迁移前一定要梳理现有 IAM 绑定防止文件夹层级的继承策略和原有权限冲突导致某些成员意外失去权限或获得过多权限。5.3 第三步创建预算和告警在 Cloud Console 的 Billing 页面创建预算。建议用固定金额模式比如每月 10 万然后添加 50%、90%、100% 三档告警阈值。通知渠道配置邮件加 webhook不要只设邮件——邮件可能被邮箱规则归档webhook 直接推给内部群更保险。如果你用 Terraform 或 Cloud Deployment Manager 管理基础设施也可以用 Billing Budget API 自动化创建预算这样每个新项目上线时都会自动带上告警配置不依赖人工操作。5.4 第四步为 Vertex AI 建立服务账号链这是账号体系里最关键的环节。先创建训练服务账号gcloud iam service-accounts create vertex-trainer \ --display-nameVertex Trainer SA \ --projectvertex-prod-001然后给服务账号绑定 Vertex AI 用户角色以及访问数据项目桶的只读权限gcloud projects add-iam-policy-binding vertex-prod-001 \ --memberserviceAccount:vertex-trainervertex-prod-001.iam.gserviceaccount.com \ --roleroles/aiplatform.user gcloud projects add-iam-policy-binding data-project-id \ --memberserviceAccount:vertex-trainervertex-prod-001.iam.gserviceaccount.com \ --roleroles/storage.objectViewer最后在使用 Vertex AI SDK 初始化时指定这个服务账号训练任务就会以该身份运行from google.cloud import aiplatform aiplatform.init( projectvertex-prod-001, locationus-central1, staging_bucketgs://vertex-prod-artifacts, )在创建 CustomJob 或 PipelineJob 时把service_account参数传进去即可。这段逻辑很多人容易漏的是只给服务账号绑了 AI Platform 角色却忘记给数据桶授权导致任务能创建但跑起来立刻 403。5.5 第五步验证权限完全符合预期权限体系配置完不能直接说应该没问题一定要验证。我的做法是用最小权限账号实际跑一次空训练任务观察是否能正常创建和退出。尝试读取没有授权的另一个数据桶确认返回 403说明权限边界确实生效。让安全团队导出项目的 IAM Policy确认没有人持有roles/owner或roles/editor这类过宽角色。这一步很容易被跳过但恰恰是最有价值的。权限系统不是写完就算完验证阶段往往能发现一堆配置错误。6. 那些在 Production 阶段才暴露的隐患与我的应对6.1 服务 Agent 和自定义服务账号不要搞混我见过不少人为了安全加固把 Vertex AI Service Agent 的权限改得很低结果底层组件无法写 Artifact Registry训练任务报出莫名其妙的 internal error排查起来非常痛苦。反过来也有人图省事所有任务共用一个高权限自定义服务账号一旦账号泄露整个项目的数据都暴露了。正确做法是Service Agent 是平台组件默认权限不要乱动自定义服务账号严格按任务最小化。两者职责分离训练脚本要什么数据就给对应的自定义服务账号加什么权限而不是一味加宽。6.2 审计日志要提前开启别等出事再补Vertex AI 涉及的训练数据和模型工件敏感度很高建议至少开启 Cloud Audit Logs 里的 Admin Activity 和 Data Access 日志。Admin Activity 默认开启但 Data Access特别是对象读取默认不记录需要在组织层面单独配置。很多企业是在合规审核前才想起来开审计日志结果发现历史操作记录完全缺失审核无法通过。正确做法是在账号体系搭建的中期就把日志导出到独立的日志存储项目长期保留。等到真正需要追溯某个模型版本是谁部署的、谁删除过数据集时你才能拿出可信记录。6.3 CMEK 与 VPC-SC 是完整支撑的另一半企业账号体系搭建好以后权限、配额、结算都到位了还差两块加密和网络边界。Google Cloud 上可以用 CMEK 给 Vertex AI 的训练数据和模型工件做企业自带密钥加密密钥由 Cloud KMS 统一管理。VPC Service Controls 则把 Vertex AI 的访问限制在指定服务边界内防止数据通过公网或非授权路径流出。很多企业一开始不上这两套方案等合规审核过不了才补补的时候牵一发动全身。从账号体系落地第一天就规划好 CMEK 的密钥环和 VPC-SC 的服务边界后边会少很多麻烦。6.4 我在实际操作中最大的体会跑了这么多 Vertex AI 落地项目最深的体感是模型训练代码往往不是瓶颈账号体系、权限边界、结算配额治理才是最容易被低估的部分。哪家团队先把企业账号体系搭对了后面模型上线基本是水到渠成哪家贪图方便用个人账号跑后面一定会在最忙的时候被权限问题卡住。如果你正在评估 Vertex AI我的建议很简单先别急着写训练代码花两三天把 Organization、Folder、Project、IAM、Billing 这五层铺好再开始跑第一个 Pipeline。前期多花的时间会在后面每一次上线、每一次排障、每一次财务对账时加倍还给你。