1. 这不是又一篇“点开就跑”的AI教程——它是一份能让你在真实项目里调通第一个模型的Vertex AI实操手记

我带过不下二十个刚转行进ML工程团队的新同事，也帮过十几位业务部门的分析师朋友搭过预测看板。他们点开各种“Vertex AI入门”文章后的共同反馈是：前两页讲概念像教哲学，中间突然甩出一串gcloud命令没上下文，最后贴个Jupyter Notebook截图就宣告“大功告成”。结果呢？本地环境配不起来，Cloud Console里找不到那个叫“Endpoint”的按钮，更别说把训练好的模型真正接进自己公司的CRM系统里了。这篇东西，就是为了解决这个断层而写的。它不叫“教程”，我把它当作一份可撕下来的工程备忘录——你不需要从头读完，遇到卡点，翻到对应小节，照着操作三分钟，大概率就能继续往下走。核心关键词全在这里：Vertex AI、Google Cloud、MLOps、AutoML、Custom Training、Model Deployment、Prediction Endpoint。它适合三类人：一是手上有真实业务数据、想用云上工具快速验证想法的产品/运营；二是刚接触云原生ML平台、被GCP控制台里几十个服务名称绕晕的初级工程师；三是需要把模型从实验阶段推进到生产环境、但苦于缺乏端到端链路经验的数据科学家。它不承诺“三天成为专家”，但能确保你在第四天早上，把一个能接收HTTP请求、返回JSON格式预测结果的模型服务，稳稳地跑在自己的项目里。

2. 为什么是Vertex AI？而不是自己搭Kubeflow，或者直接用SageMaker？

2.1 真实场景下的取舍逻辑：省掉80%的基建时间，只为聚焦那20%的业务价值

很多人一上来就问：“Vertex AI和SageMaker比，哪个强？”这个问题本身就有陷阱。就像问“电钻和螺丝刀哪个更好用”——取决于你要装的是宜家书架，还是在给航天器拧紧一颗钛合金螺栓。我在上一家公司做过一个对比实验：用同样一套销售线索评分模型（XGBoost），分别走三条路部署上线。第一路，纯自建：用Terraform在GCP上起K8s集群，手动装KFServing，写Dockerfile打包模型，配置Istio网关，搞TLS证书……从代码提交到API可用，耗时11天，其中7.5天花在环境调试和权限报错上。第二路，SageMaker全流程：创建Notebook Instance，训练Job，Model Registry，Endpoint部署……全程AWS控制台+CLI，6.5天搞定，但有两天卡在VPC对等连接和Security Group策略上。第三路，Vertex AI：用AutoML Tables自动训练，一键部署Endpoint，再用Cloud Functions写个轻量级API Wrapper——从上传CSV到收到第一条curl返回的预测结果，只用了37分钟。这不是吹嘘Vertex AI多“智能”，而是它把那些所有团队都得重复造、但又毫无业务差异性的轮子，焊死在平台底层了。它的核心设计哲学不是“给你最灵活的积木”，而是“给你一套严丝合缝、拧上就能用的工业级接口”。比如，它的训练数据自动版本管理，不是靠你手动打Git tag，而是当你把新数据集上传到Cloud Storage并关联到Dataset资源时，Vertex AI会自动生成一个不可变的dataset_id快照；它的模型监控不是让你自己写Prometheus exporter去抓指标，而是默认开启延迟、错误率、特征偏移（Drift）三大维度的仪表盘，阈值可调，告警能直连PagerDuty。这种“默认即生产就绪”的设定，对中小团队和MVP验证期项目，就是降维打击。你不用再纠结“该不该上Kubeflow”，因为Vertex AI已经把Kubeflow Pipelines的核心能力封装成了可视化Pipeline Editor，拖拽几个预置组件（Data Import、Training、Evaluation、Deploy），导出YAML就能跑，连K8s都不用碰。

2.2 Vertex AI的三层架构：看清它到底在帮你管什么

很多初学者卡在第一步，是因为根本没搞清Vertex AI不是“一个服务”，而是一个分层治理的ML平台操作系统。它像一栋大楼，每层干的事儿截然不同，但楼梯（API）是打通的：

• 最底层：基础设施即服务（IaaS）层。这其实是GCP的底座——Compute Engine虚拟机、Cloud Storage对象存储、Cloud SQL数据库、VPC网络。Vertex AI自己不提供服务器，它只是这些资源的“超级调度员”。当你在Vertex AI控制台点“创建Training Pipeline”，它背后做的第一件事，是自动为你申请一个临时的、按秒计费的GPU实例（比如a2-highgpu-1g），训练完立刻销毁。你不用管这台机器的OS补丁、驱动更新、磁盘扩容，Vertex AI全包了。这层的价值，是把“买服务器”这个采购行为，变成了“调用一个API”。

• 中间层：平台即服务（PaaS）层。这才是Vertex AI的主战场，包含四大核心模块：Datasets（数据集）、Models（模型）、Endpoints（端点）、Pipelines（流水线）。Datasets不是简单的文件夹，它强制要求你定义Schema（字段名、类型、是否标签列），并自动做数据质量扫描（缺失率、异常值分布）。Models资源不单存权重文件，它还绑定训练时的超参、框架版本、甚至原始训练代码的Git Commit ID。Endpoints则是个智能路由网关，它自动处理流量分发、蓝绿发布、A/B测试分流、自动扩缩容（基于QPS或CPU利用率）。这一层，Vertex AI把MLOps里最繁琐的“状态管理”问题，用声明式资源（Declarative Resource）的方式解决了。你声明“我要一个支持100 QPS的Endpoint”，平台就负责保证它永远在线，而不是让你自己写脚本去查Pod状态。

• 最上层：应用即服务（SaaS）层。这就是AutoML系列——AutoML Tables（结构化数据）、AutoML Vision（图像）、AutoML Natural Language（文本）。它们不是黑箱，而是Vertex AI把Google Research最成熟的预训练模型（如BERT、EfficientNet）和自动化调优框架（如Vizier超参搜索）打包成的“傻瓜模式”。关键在于，AutoML训练出来的模型，和你自己用Custom Training写的PyTorch模型，在Vertex AI里是完全平等的“公民”。你可以用同一个Endpoint来服务它们，用同一套Monitoring来追踪它们。这就打破了“AutoML只能玩玩，真项目还得自己写”的迷思。我去年帮一个电商客户做商品图搜，先用AutoML Vision快速出MVP，两周内上线了基础搜索；紧接着，用Custom Training微调ViT模型，把准确率从82%提到91%，整个过程，前端调用的Endpoint URL、请求格式、鉴权方式，一行代码都没改。

提示：别被“Vertex AI”这个名字迷惑。它和Google的“Vertex”系列芯片（TPU）没有直接关系。TPU是硬件加速器，Vertex AI是软件平台。你可以在Vertex AI里指定用GPU训练（更通用），也可以选TPU v3（对特定大模型更快），但平台本身不等于硬件。

3. 从零开始：一次真实的端到端实战——用Vertex AI预测用户流失（Churn）

3.1 环境准备：三步建立“最小可行账户”，避开90%的权限坑

很多教程一上来就让你“打开Cloud Console”，结果卡在“Permission denied”上。这不是你的错，是GCP的IAM（Identity and Access Management）设计太严谨。我们跳过所有花哨配置，直奔“能干活”的最小集合：

1. 创建专用服务账号（Service Account）：不要用你的个人Gmail账号！在Cloud Console左侧菜单，进入IAM & Admin > Service Accounts，点击“CREATE SERVICE ACCOUNT”。名字就叫vertex-ml-dev，描述写“用于Vertex AI开发的最小权限账号”。创建后，立刻进入该账号的“Permissions”页，点击“GRANT ACCESS”。这里是最关键一步：添加两个预置角色（Predefined Roles）：

   • roles/aiplatform.user—— 这是Vertex AI的“操作员”角色，允许你创建Datasets、Models、Endpoints、Pipelines。
   • roles/storage.objectAdmin—— 允许你往Cloud Storage里上传/下载数据（Vertex AI所有数据都存在GCS里）。

   注意：绝对不要加roles/owner或roles/editor！这是GCP里最危险的权限，相当于给了整个项目的“上帝权限”。我见过太多团队因为一个测试账号被误配了Owner权限，导致误删生产数据库。

2. 生成密钥并配置本地环境：回到服务账号列表，找到刚创建的vertex-ml-dev，点击右侧的三个点，选“Manage keys > ADD KEY > Create new key”，格式选JSON。浏览器会自动下载一个vertex-ml-dev-xxxxxx.json文件。把它放到你电脑的安全位置（比如~/.gcp/目录下）。然后，在终端执行：

   export GOOGLE_APPLICATION_CREDENTIALS="/path/to/your/vertex-ml-dev-xxxxxx.json" gcloud auth activate-service-account --key-file="$GOOGLE_APPLICATION_CREDENTIALS" gcloud config set project YOUR_PROJECT_ID

   YOUR_PROJECT_ID是你在GCP控制台右上角看到的那个一长串字母数字组合（不是项目名！）。执行完这三行，你的本地gcloudCLI就获得了vertex-ml-dev账号的全部权限。

3. 启用必需的API：Vertex AI不是开箱即用的。必须手动启用四个核心API。在Cloud Console，搜索“APIs & Services > Library”，依次搜索并启用：

   • AI Platform (Unified) API（这是Vertex AI的正式名称）
   • Cloud Storage API
   • Cloud Logging API
   • Cloud Monitoring API启用过程需要几秒钟，每个API旁边会显示绿色对勾。漏掉任何一个，后续步骤都会报错，而且错误信息极其晦涩（比如PERMISSION_DENIED: Permission 'aiplatform.datasets.create' denied on resource，其实根源是API没开）。

完成这三步，你就拥有了一个干净、安全、权限精准的Vertex AI开发环境。整个过程，我实测耗时4分32秒。记住，这三步是“地基”，后面所有楼都盖在这上面，地基不牢，后面全是空中楼阁。

3.2 数据准备：不是扔个CSV就行，Vertex AI对数据有“洁癖”

Vertex AI的Datasets模块，对输入数据有非常明确的“契约”（Contract）。它不像本地Pandas那样宽容。假设你要预测用户流失，典型的数据表churn_data.csv应该长这样：

很多人直接把这个CSV上传，然后在Vertex AI里点“Create Dataset”，结果失败。原因有三：

• 第一，文件格式与编码：Vertex AI只接受UTF-8编码的CSV，且必须有表头（Header Row）。如果你的CSV是Excel另存为的，很可能带BOM头，或者用逗号分隔但字段里有逗号（没加引号）。解决方案：用VS Code打开，右下角确认编码是“UTF-8”，然后用Python脚本清洗：

  import pandas as pd df = pd.read_csv("churn_data_raw.csv", encoding='utf-8') # 强制所有字符串字段加引号，避免逗号歧义 df.to_csv("churn_data_clean.csv", index=False, quoting=csv.QUOTE_ALL)

• 第二，数据类型推断陷阱：Vertex AI会自动推断字段类型。user_id如果全是数字，它可能推成INTEGER，但user_id其实是分类特征（Categorical），应该为STRING。is_churned如果是0/1，它会推成INTEGER，但Vertex AI要求二分类标签必须是STRING（"0" or "1"）或BOOLEAN。解决方案：在上传前，用gcloudCLI显式指定Schema。创建一个schema.yaml文件：

  inputs: - name: user_id type: STRING - name: tenure_months type: INTEGER - name: monthly_spend type: DOUBLE - name: support_tickets type: INTEGER - name: is_churned type: STRING

  这个YAML文件，就是你和Vertex AI之间的“数据契约”，它比任何文档都权威。

• 第三，存储位置硬性要求：Vertex AI的Dataset，必须指向Cloud Storage（GCS）里的文件，不能是本地路径，也不能是其他云厂商的存储。所以，先创建一个GCS Bucket：

  gsutil mb -l us-central1 gs://my-churn-bucket-2024/

  然后上传清洗好的CSV和Schema文件：

  gsutil cp churn_data_clean.csv gs://my-churn-bucket-2024/data/ gsutil cp schema.yaml gs://my-churn-bucket-2024/schema/

  上传完成后，在Vertex AI控制台创建Dataset时，“Source”选择“Cloud Storage”，路径填gs://my-churn-bucket-2024/data/churn_data_clean.csv，并在“Schema”部分，粘贴schema.yaml的内容。Vertex AI会立刻校验数据，告诉你哪一行哪一列不符合Schema。这是它最强大的地方——把数据质量问题，拦截在训练之前。

3.3 模型训练：AutoML Tables vs Custom Training，怎么选？

这是新手最容易纠结的点。我的经验是：用AutoML Tables启动，用Custom Training迭代。两者不是互斥，而是接力。

• AutoML Tables：15分钟出第一个Baseline
  在Vertex AI控制台，进入Datasets > 你的churn_dataset > START TRAINING。选择“AutoML”选项卡。关键参数设置：

  • Target column:is_churned（必须和Schema里定义的一致）
  • Optimize for:Maximize Precision at Recall = 0.5（对于流失预测，我们更怕把要流失的用户漏掉，所以宁可多召些，精度稍低也行）
  • Training budget:1 hour（预算不是训练时长，是Vertex AI为你分配的算力总成本上限，1小时足够跑出好结果）
  • Feature importance: 勾选，训练完能看到哪些字段对预测影响最大（比如support_tickets权重最高，说明客服体验是关键）。

  点击“Start Training”，Vertex AI会自动做：数据采样、特征工程（自动创建交互特征、分箱）、模型搜索（试XGBoost、TabNet、Ensemble）、超参调优、交叉验证。15-20分钟后，你会看到一个“Model evaluation”页面，里面有一堆指标：Precision、Recall、F1、ROC AUC。重点看“Confusion Matrix”——它直接告诉你，在1000个真实流失用户中，你的模型成功抓到了多少（True Positive）。如果这个数低于700，说明数据或特征有问题，需要回头检查。如果高于850，恭喜，你已经有了一个可以上线的MVP模型。

• Custom Training：当AutoML不够用时，接管控制权
  AutoML的瓶颈很快会出现：比如你需要加入一个外部API调用（查用户最近一次支付是否成功），或者要用一个特定的PyTorch模型结构（比如Graph Neural Network处理用户社交关系）。这时，Custom Training就是你的武器。它本质是：你写一个标准的Python训练脚本（trainer/task.py），Vertex AI负责把它打包成Docker镜像，拉起GPU实例运行。脚本结构非常固定：

  # trainer/task.py import argparse import tensorflow as tf from google.cloud import aiplatform def main(): parser = argparse.ArgumentParser() parser.add_argument('--data-dir', type=str, required=True) # GCS路径 parser.add_argument('--model-dir', type=str, required=True) # 模型保存路径 args = parser.parse_args() # 1. 从GCS加载数据（Vertex AI会自动挂载GCS bucket） train_df = pd.read_csv(f"{args.data-dir}/train.csv") # 2. 构建模型（这里用TF Keras，你也可以用PyTorch） model = tf.keras.Sequential([...]) # 3. 训练 model.fit(train_df.drop('is_churned', axis=1), train_df['is_churned']) # 4. 保存模型到GCS（Vertex AI会自动同步） model.save(args.model-dir) if __name__ == '__main__': main()

  关键点在于：你完全不用管Dockerfile、GPU驱动、分布式训练框架。Vertex AI提供了预置的容器镜像（如us-docker.pkg.dev/vertex-ai/training/tf-gpu.2-12:latest），你只需在控制台创建Training Job时，指定这个镜像、你的脚本路径、以及--data-dir和--model-dir的GCS地址。Vertex AI会自动把你的代码复制进去，运行python task.py。整个过程，你写的代码，和本地Jupyter里调试的，几乎一模一样。这就是“云原生”的威力——抽象掉所有基础设施细节，只留下纯粹的算法逻辑。

3.4 模型部署与推理：让模型真正“活”起来，变成一个URL

训练完的模型，躺在Vertex AI的Models列表里，只是一个“尸体”。让它“活”过来，变成一个能被业务系统调用的API，才是关键一步。Vertex AI的Endpoint，就是这个“生命维持系统”。

1. 创建Endpoint：在Models列表，找到你训练好的模型（无论是AutoML还是Custom Training的），点击右侧的“DEPLOY TO ENDPOINT”。弹窗里，填入：

   • Endpoint name:churn-predictor-v1
   • Machine type:n1-standard-4（4核8G，对大多数表格模型足够；如果模型很大，选a2-highgpu-1g）
   • Minimum number of nodes:1（保证永远有1个实例在线，避免冷启动延迟）
   • Maximum number of nodes:3（当QPS飙升时，自动扩容到3个）

   点击“Deploy”，Vertex AI会启动一个后台任务，大约2-3分钟，Endpoint就创建好了。你可以在Endpoints列表里看到它，状态是Ready。

2. 发送第一次预测请求（Prediction）：这才是最激动人心的时刻。Vertex AI提供了两种调用方式：

   • REST API（推荐给业务系统）：它给你一个HTTPS URL，比如https://us-central1-aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/us-central1/endpoints/YOUR_ENDPOINT_ID:predict。调用它需要：

     • 认证：用gcloud auth application-default print-access-token获取短期Token。
     • 请求体（JSON）：格式必须严格匹配你训练时的输入Schema。例如：

       { "instances": [ { "user_id": "U1001", "tenure_months": 12, "monthly_spend": 49.99, "support_tickets": 2 } ] }

     • 发送请求：

       curl -X POST \ -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ -H "Content-Type: application/json" \ https://us-central1-aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/us-central1/endpoints/YOUR_ENDPOINT_ID:predict \ -d @request.json

       成功响应会是：

       { "predictions": [ { "classes": ["0", "1"], "scores": [0.87, 0.13] } ] }

       这表示，模型认为该用户流失概率是13%。

   • Python SDK（推荐给数据分析）：在Jupyter里，用几行代码就能调用：

     from google.cloud import aiplatform aiplatform.init(project="YOUR_PROJECT_ID", location="us-central1") endpoint = aiplatform.Endpoint(endpoint_name="YOUR_ENDPOINT_ID") prediction = endpoint.predict(instances=[{"user_id":"U1001", ...}]) print(prediction.predictions) # 输出同上

3. 关键技巧：如何让这个Endpoint真正融入你的业务？
   直接把GCP的Endpoint URL暴露给前端App？不安全，也不可控。最佳实践是加一层“API Gateway”：

   • 用Cloud Functions写一个轻量函数，它接收业务系统的简单请求（比如GET /api/churn?user_id=U1001），内部调用Vertex AI的Endpoint，再把结果包装成业务友好的JSON（比如{"risk_score": 13, "recommendation": "Send discount coupon"}）。
   • 这个Function可以加API Key鉴权、做请求频率限制、记录日志到Cloud Logging。Vertex AI只负责“预测”，所有业务逻辑和安全策略，由你掌控的Gateway负责。这是我所有客户项目的标配。

4. 生产就绪：监控、更新与成本控制——别让模型在上线后“默默死亡”

4.1 模型监控：不是看“它还在不在”，而是看“它还准不准”

很多团队以为模型部署成功就万事大吉。结果三个月后，发现预测准确率从85%掉到了62%，却没人知道。Vertex AI的监控，核心是解决“数据漂移（Data Drift）”和“概念漂移（Concept Drift）”。

• 数据漂移监控：指输入数据的分布变了。比如，你训练时monthly_spend平均是$49.99，现在新流入的用户，平均消费涨到了$79.99。Vertex AI会自动计算每个特征的统计量（均值、方差、分位数），和训练时的基准做KS检验（Kolmogorov-Smirnov test）。一旦p-value < 0.05，就判定为显著漂移。它会在Model monitoring页面，用红色高亮monthly_spend字段，并给出漂移程度（Drift Score）。这时，你不是立刻重训模型，而是先去查：是不是市场部刚做了个大促活动？如果是，那这就是合理的业务变化，模型暂时“失准”是正常的，等活动结束数据回归常态即可。

• 概念漂移监控：指“输入-输出”的关系变了。比如，过去support_tickets越多，流失率越高；但现在，因为客服系统升级，用户打3次电话就能解决问题，support_tickets反而和流失率负相关了。Vertex AI通过分析“预测结果的分布变化”和“实际标签的分布变化”来检测。如果预测为“1”（流失）的概率，从稳定的15%突然升到30%，而你又没收到任何业务变更通知，那很可能发生了概念漂移。这时，Vertex AI会触发告警，你就可以启动“Retraining Pipeline”，用最新30天的数据，自动重新训练模型。

实操心得：监控不是开了就完事。我建议把Vertex AI的监控告警，和你的Slack频道打通。在Cloud Monitoring里，创建一个Alerting Policy，条件设为“Drift Score > 0.3”，通知渠道选“Webhook”，指向你的Slack Incoming Webhook URL。这样，只要模型“身体不适”，你的手机就会响，而不是等老板问“为什么上周的预测全错了”。

4.2 模型更新：无缝切换，零停机

线上模型不能“一刀切”替换。Vertex AI的Endpoint支持多版本部署（Multi-version Endpoints）。你可以同时部署v1（旧模型）和v2（新模型），然后用“Traffic Splitting”功能，把10%的流量导给v2，观察它的表现（延迟、错误率、准确率）。如果v2稳定运行一周，再把流量逐步提升到50%、100%。整个过程，业务系统调用的Endpoint URL完全不变，它只看到一个“服务”，背后的模型早已悄然更新。这比手动删旧Endpoint、建新Endpoint、改DNS，安全一万倍。

4.3 成本控制：Vertex AI不是无底洞，每一毛钱都要算清楚

Vertex AI的账单，主要来自三块：Training（训练）、Hosting（托管）、Prediction（推理）。不加管控，一个月烧掉几万美金很常见。

• Training成本优化：

  • 用Spot VM（抢占式实例）：在Custom Training Job里，勾选“Use preemptible machines”。价格比普通VM便宜60%-70%，且Vertex AI会自动处理中断重试（你的训练脚本需支持断点续训）。
  • 缩短训练时间：AutoML的“Training budget”别设太高。1小时预算通常够用。如果模型还没收敛，说明数据或特征有问题，该优化数据，而不是加钱。

• Hosting成本优化：

  • 动态扩缩容：把Endpoint的“Minimum number of nodes”设为0。这意味着，当没有请求时，所有实例都会被销毁，一分钱不花。但代价是，第一个请求会有30-60秒的“冷启动”延迟。如果你的业务能接受，这是最省钱的方案。
  • 选择合适机型：别一上来就选a2-highgpu-1g。先用n1-standard-4测试，看CPU和内存使用率。如果长期低于30%，说明你买大了，换成n1-standard-2。

• Prediction成本优化：

  • 批量预测（Batch Prediction）：如果你不需要实时返回结果（比如每天凌晨跑一次，给全量用户打分），就别用在线Endpoint。用Vertex AI的Batch Prediction功能，把百万条数据一次性提交，它会用MapReduce方式并行处理，单价比在线推理便宜5-10倍。
  • 缓存高频请求：在你的API Gateway（Cloud Function）里，加一层Redis缓存。对user_id=U1001的请求，缓存结果5分钟。这样，同一用户短时间内多次刷新页面，不会反复调用Vertex AI，省下大量Predictions费用。

5. 常见问题与排查技巧实录：那些官方文档里绝不会写的“血泪教训”

5.1 “Permission denied” 错误：90%的卡点，都源于这一个配置

现象：在控制台点“Create Dataset”，报错PERMISSION_DENIED: Permission 'storage.objects.get' denied on resource 'projects/_/buckets/my-churn-bucket-2024'。
真相：你的服务账号vertex-ml-dev有roles/storage.objectAdmin，但它没有对my-churn-bucket-2024这个Bucket的Bucket-level IAM权限。GCP的权限是分层的：Project-level权限 ≠ Bucket-level权限。
解决：进入Cloud Storage > Buckets > my-churn-bucket-2024 > Permissions，点击“ADD MEMBER”，输入你的服务账号邮箱（vertex-ml-dev@YOUR_PROJECT_ID.iam.gserviceaccount.com），角色选Storage Object Viewer。立刻生效。

注意：objectAdmin角色只赋予“操作对象”的权限，但Bucket本身是个“容器”，访问容器需要额外的Storage Legacy Bucket Reader或Storage Object Viewer权限。这是GCP IAM最反直觉的设计之一。

5.2 “Model failed to deploy”：GPU驱动不兼容的隐形杀手

现象：Custom Training训练成功，模型也注册进去了，但部署Endpoint时失败，日志里出现NVIDIA driver version not found或Failed to load libcuda.so。
真相：你训练时用的容器镜像是tf-gpu.2-12（TensorFlow 2.12 + GPU支持），但Vertex AI部署Endpoint时，默认用的是CPU镜像。GPU模型无法在CPU环境加载。
解决：部署时，必须显式指定GPU机器类型，并勾选“Use GPU”。在Deploy弹窗里，Machine type选a2-highgpu-1g，然后下方会自动出现“GPU type”和“GPU count”选项，选nvidia-tesla-a100和1。千万别漏掉这一步。

实操心得：我踩过三次这个坑。后来养成习惯，只要训练脚本里import了tensorflow-gpu或torch.cuda，部署时第一反应就是检查GPU选项是否勾选。Vertex AI的UI设计在这里有点坑——GPU选项是“懒加载”的，只有选了GPU机型才会出现，很容易被忽略。

5.3 “Prediction returns empty array”：Schema不一致的静默失败

现象：调用predictAPI，返回{"predictions": []}，没有报错，但也没有结果。
真相：你的请求体（instances）里的字段名，和训练时Dataset的Schema定义不一致。比如Schema里定义的是tenure_months，但你请求时写了tenure。Vertex AI不会报错，它会把不认识的字段直接过滤掉，导致传进去的instances变成空对象{}，模型自然无法预测。
排查：在Vertex AI控制台，进入Models > 你的模型 > View details，找到“Input schema”部分，逐字核对。最保险的方法，是用Python SDK的endpoint.predict()，它会在本地做Schema校验，如果字段不匹配，会直接抛出ValueError，提示你哪个字段错了。

提示：永远不要手写JSON请求体。用Python字典构造，然后json.dumps()，这样能避免拼写错误和引号问题。

5.4 “Cost exploded overnight”：未关闭的Endpoint正在悄悄烧钱

现象：月初看账单，发现Vertex AI Hosting费用高达$2000，而你只部署了一个小模型。
真相：你部署Endpoint时，把“Minimum number of nodes”设为了1，并且忘了它。这个Endpoint 24/7都在运行，即使一整天都没有一个请求进来。
解决：立即进入Endpoints > 你的Endpoint > EDIT，把Minimum nodes改为0，保存。然后，去Billing > Reports，创建一个自定义报告，筛选service = "Vertex AI API"，sku = "Online prediction"，这样下次就能一眼看出是哪个Endpoint在烧钱。

经验：我给自己定了个铁律——所有用于开发测试的Endpoint，Minimum nodes必须为0；只有经过压测、确认QPS稳定的Production Endpoint，才设为1。并且，每周五下午，我会用gcloud ai endpoints list命令扫一遍所有Endpoint，检查它们的minReplicaCount，确保没有“孤儿Endpoint”在后台吃钱。

5.5 “AutoML accuracy is low”：不是模型不行，是数据在说谎

现象：AutoML Tables训练完，AUC只有0.65，远低于预期。
排查清单（按优先级排序）：

1. 检查标签泄露（Label Leakage）：is_churned这个字段，是不是包含了未来的信息？比如，你的数据截止到2024-06-30，但is_churned是根据2024-07-15的用户状态标记的。这会导致模型学到“作弊特征”。正确做法：is_churned必须基于训练数据截止日期之前的用户行为定义（例如，“过去30天无登录”）。
2. 检查时间序列污染（Time Series Contamination）：训练集和验证集，是不是按时间随机划分的？必须按时间顺序切分！比如，用2024-01到2024-04的数据训练，2024-05的数据验证，2024-06的数据测试。随机切分会让模型看到“未来”，成绩虚高。
3. 检查类别不平衡（Class Imbalance）：如果is_churned=1的样本只占1%，AutoML默认会优化Accuracy，而Accuracy会被99%的0主导。这时，必须在AutoML设置里，把“Optimize for”改成Maximize F1 score或Maximize Precision at Recall = 0.5，强制模型关注少数类。

这张表总结了最常遇到的5个问题及其“一招毙命”的解法：

6. 写在最后：Vertex AI不是魔法，它是你工程能力的放大器

我第一次用Vertex AI部署模型时，也觉得它像个黑箱。直到我把它的每一个API调用，都用curl -v抓包，把返回的JSON一层层展开，才明白它背后没有玄学，只有精密的工程设计。它把过去需要一个5人MLOps团队半年才能搭好的CI/CD流水线，压缩成控制台里几个点击和