examlab .net 用最有效率的方法，考取最有價值的證照
支持
本篇導覽 約 36 分鐘

Vertex AI 平台工作流程

7,200 字 · 約 36 分鐘閱讀 ·

掌握 Google Cloud 上的端到端機器學習生命週期：Vertex AI Pipelines、Model Registry、Feature Store、Model Monitoring、Vector Search、Agent Builder 以及架構師的 MLOps 最佳實務。

立即做 20 題練習 → 免費 · 不用註冊 · PCA

Vertex AI 簡介

對於 Professional Cloud Architect 而言，Vertex AI 不只是資料科學家的工具，而是一個用來編排整個機器學習（ML）生命週期的統一平台。它把過去分散的服務（AI Platform、AutoML 等）整合到單一 API 與 UI，讓 **MLOps（機器學習維運）**得以規模化。

Vertex AI 的目標，是把 ML 從「實驗用的 notebook」推進到「正式環境等級的管線」。

Google Cloud 統一的機器學習平台，為 ML 工作流程各階段（資料準備、訓練、部署、監控、治理）提供工具。參考：https://cloud.google.com/vertex-ai/docs/start/introduction-unified-platform

白話文解釋 Vertex AI Workflows

Vertex AI 就像一間專業電影製作片廠。

比喻一 — 整合片廠（Unified Platform）

從前你必須跑一個地方寫劇本、另一個地方拍攝、第三個地方剪輯。Vertex AI 就是整合片廠：裡面有編劇室（Workbench）、攝影棚（Training）、影片檔案庫（Model Registry）以及發行通路（Endpoints）。所有東西都在同一棟建築物裡，共用同樣的保全與後勤。

比喻二 — 汽車組裝線（Vertex AI Pipelines）

Vertex AI Pipelines 就像自動化汽車組裝線。不是讓一個人從頭到尾手工裝一台車，而是定義一連串步驟：「裝輪子」→「裝引擎」→「上漆」。如果你找到更好的上漆方式，只需要替換那一台機器即可。管線確保每台車（每個模型）每次都以一模一樣的方式組裝出來，並完整記錄使用過的每個零件。

比喻三 — 社區共用工具間（Feature Store）

Feature Store 就像社區的共用工具間。與其每家自己買割草機（重複計算同一份特徵，例如「顧客平均消費」），不如大家貢獻最好的工具到共用工具間。要用的人直接從工具間拿。這確保所有人使用同一套高品質工具，省下重複造輪子的成本。

Vertex AI 上的 ML 生命週期

打造 ML 解決方案時，會經過幾個明確的階段：

1. 資料準備與特徵工程

  • Vertex AI Workbench： 託管式 Jupyter notebook，用於探索分析，原生整合 BigQuery 與 Cloud Storage。
  • Vertex AI Feature Store： 集中式儲存庫，用來儲存、分享、提供 ML 特徵；確保訓練時使用的特徵值在即時推論時也能取得相同值，解決「training-serving skew（訓練/服務偏差）」問題。

2. 模型訓練

  • AutoML： 適合沒有深厚 ML 經驗的團隊。你提供資料，Google 自動找出最佳模型架構。
  • Custom Training： 適合想要完整控制權的資料科學家。你提供訓練程式碼（Python、R 等）與容器映像。
  • 分散式訓練： Vertex AI 可自動把訓練擴展到多顆 GPU 或 TPU。

3. 模型管理

  • Vertex AI Model Registry： 集中管理模型版本、metadata 與血緣。
  • Model Evaluation： 自動化工具，視覺化模型效能指標（Precision-Recall 曲線、混淆矩陣）。

4. 模型部署與服務

  • Vertex AI Prediction（線上）： 把模型部署到 Endpoints，提供低延遲即時推論。
  • Batch Prediction： 適合大型資料集、不需要即時回應的場景；離線處理更省成本。

Vertex AI 核心元件深入解析

統一平台底下，大約有 12 個一級服務共用同一個 aiplatform.googleapis.com API。架構師必須清楚知道各元件的職責與邊界。

Workbench（託管式 Notebooks）

Vertex AI Workbench 取代了舊版 AI Platform Notebooks，提供兩種模式：Managed Notebooks（Google 託管 runtime，支援閒置自動關機與 serverless Spark）與 User-Managed Notebooks（你自己管 Compute Engine VM、安裝自訂驅動）。Workbench 透過 %%bigquery magic 原生整合 BigQuery，也能直接寫入 Cloud Storage。Workbench 適合探索與原型開發，不適合正式環境訓練。

Pipelines（KFP / TFX 編排）

Vertex AI Pipelines 在 serverless 後端執行 Kubeflow Pipelines v2 YAML 或 TFX 定義。每個步驟是一個容器化元件，Pipelines 會自動把 artifact 血緣寫進 Vertex ML Metadata。

Experiments 與 TensorBoard

Vertex AI Experiments 追蹤跨多次執行的超參數、指標與 artifact。Vertex AI TensorBoard 提供託管的 TensorBoard 介面，並透過 IAM 控管分享權限 — 不必把本機 TensorBoard 暴露給隊友。

Feature Store（線上 + 離線）

有兩代：舊版 Feature Store（Bigtable 後端，對新專案已 deprecated）與新版 BigQuery 上的 Feature Store（離線儲存 = BigQuery table，線上儲存 = Bigtable-backed 優化查詢）。今天才開始選的架構師應該選 BigQuery-backed 版本。

Model Registry

Vertex AI Model Registry 是訓練模型的單一事實來源，支援版本別名（default、staging、production）、附掛 Model Evaluation、以及一鍵部署到 Endpoints；底層容器整合 Artifact Registry。

Endpoints（線上推論）

Endpoints 前置一個或多個部署的模型版本，支援流量切分（例如 90% v1 / 10% v2 做 canary）、依 CPU/GPU 使用率自動擴縮，並可透過 Private Service Connect 提供僅限 VPC 的私有 ingress。

Vertex AI Studio 與生成式 AI

Vertex AI Studio 是基礎模型（foundation models）的主控台與 SDK 入口 — 涵蓋 Gemini 系列（gemini-2.5-pro、gemini-2.5-flash）、用於影像的 Imagen、用於影片的 Veo，以及用於語音的 Chirp。它是 GenAI 領域的 AutoML 對應品。

主要能力

  • Prompt 設計與儲存： 在 UI 上迭代 prompt、把版本存進專案，並匯出成 Python/Node SDK 程式碼。
  • 模型微調（Tuning）： 對 Gemini 變體做監督式微調（SFT）與 RLHF，使用儲存在 Cloud Storage JSONL 的小型標註資料集。Tuning 任務會在同一個專案中產生一個已微調的模型 Endpoint。
  • Grounding： 附掛一個 Vertex AI Search datastore 或 Google Search 結果，讓模型回答時附上引用來源；對受監管產業降低幻覺至關重要。
  • 安全過濾器： 可調整 harassment、hate speech、sexually explicit、dangerous content 各分類的閾值。

何時用 Studio vs Custom Training

當基礎模型已經理解你的領域，只需要 prompt engineering 或輕度微調時，就用 Studio。只有當你真的需要全新架構、或從頭預訓練時，才需要 custom training（PyTorch / JAX on Vertex AI Training） — 對應用團隊來說很罕見。

PCA 情境若提到「打造聊天機器人」、「摘要文件」或「從 PDF 抽取實體」，答案幾乎都是 Vertex AI Studio + Gemini + 透過 Vertex AI Search 做 grounding，不是 custom training。10 題 GenAI 考題裡有 9 題，custom training 都是干擾選項。

Model Monitoring：Skew 與 Drift

Vertex AI Model Monitoring 是正式環境的安全網，偵測已部署模型的輸入或輸出何時偏移到足以傷害預測品質。它以排程任務針對 Endpoint 的預測 log 執行，超過閾值時寄送告警。

Training-Serving Skew（訓練/服務偏差）

Skew 比對服務當下的特徵分布與訓練資料集 baseline。設定時把 Monitoring 指向訓練資料集 URI（BigQuery table 或 Cloud Storage CSV/TFRecord）。觸發條件：服務分布與訓練分布的差異超過設定的 L-infinity（類別型）或 Jensen-Shannon（數值型）閾值。

典型成因：訓練用 notebook 與服務用程式之間的特徵工程管線不一致（例如訓練套了 log-transform、但服務沒有）。

Prediction Drift（預測漂移）

Drift 比對今日服務分布與昨日（或上週）服務分布，不需要訓練 baseline。觸發條件：世界變了 — 新的商品目錄、季節性使用者行為、類似 COVID 的市場衝擊。

Output Attribution Drift（輸出歸因漂移）

針對啟用了 Explainable AI 的表格模型，Monitoring 也會追蹤特徵歸因排序的位移。如果上個月 customer_age 是首要驅動因素、本月變成 account_balance，代表結構性變化值得調查。

維運設定

  • 取樣率：10-100% 的預測請求寫入 BigQuery log table。
  • 監控頻率：每小時至每日視窗。
  • 告警經 Cloud Logging → Pub/Sub → on-call 路由。

AutoML vs Custom Training：決策框架

兩條路徑最終都會把模型放進同一個 Model Registry、從同一個 Endpoints 提供服務。差別在於模型程式碼由誰寫。

AutoML（Google 寫模型）

  • 支援資料型別：表格、影像（分類/物件偵測）、文字（分類/實體擷取）、影片。
  • 訓練時間：表格通常 1-6 小時、影像更久。
  • 計費模式：訓練依 node-hour 計費；服務依 Endpoint 計費。
  • 優勢：零 ML 程式碼、自動超參數搜尋、表格資料自動特徵工程。
  • 劣勢：架構是黑盒、loss function 控制有限、不支援串流/線上學習。

Custom Training（你寫模型）

  • 以容器為基礎：自備 Docker 映像（或使用 Google 預建的 TensorFlow/PyTorch/scikit-learn 容器）。
  • 支援單機 replica、分散式 multi-worker、附 parameter server 的分散式，以及用於 all-reduce GPU 訓練的 reduction server。
  • 超參數調校服務底層採 Bayesian optimization 或 Vizier。
  • 優勢：完整控制、自訂架構、多模態、強化學習。
  • 劣勢：OOM 自己 debug、機器大小自己估。

混合路徑

先用 AutoML 一天內做出 baseline；若達標就上線，若不達標再把訓練管線移植到 custom training。兩條路徑共用 Vertex AI Datasets 作為輸入合約。

常見考題陷阱：情境說「團隊沒有 ML 經驗，但要對零售銷售做預測」。正確答案是 AutoML Tabular Forecasting，不是 BigQuery ML、也不是 custom training。要小心提到「純 SQL」的 BQML 干擾選項 — BQML 很棒，但它無法產出一個支援流量切分的託管 Endpoint。

Batch vs Online Prediction 架構

兩者都從同一個 Model Registry artifact 執行，但成本與維運型態差異很大。

Online Prediction（Endpoints）

  • 延遲目標：p95 通常 50-300 ms。
  • 依最低 replica 數的 node-hour 加上自動擴展量計費。
  • 永遠在線：即使零流量，仍要付 min_replica_count 的費用。
  • 支援模型版本之間的流量切分（canary、A/B）。
  • 可透過 Private Service Connect 設為 Private Endpoints，僅限 VPC 存取。
  • 適合：使用者面向的同步預測（推薦、結帳時的詐欺評分）。

Batch Prediction（BatchPredictionJob）

  • 輸入：BigQuery table 或 Cloud Storage JSONL/CSV。
  • 輸出：BigQuery table 或 Cloud Storage。
  • 依任務運算節點的 node-hour 計費；任務結束即縮到零。
  • 延遲沒有 SLA — 視資料量分鐘到小時。
  • 適合：夜間對整批顧客評分、流失名單、ETL 風格的資料豐富化。

決策法則

若請求由使用者動作觸發且答案需要在該請求中即時回傳，用 Online；若預測由下游管線或儀表板消費、沒有人在等，用 Batch，可省 70-90% 成本。許多正式系統兩者並行：夜間用 batch 處理長尾，active session 用 online。

這兩個服務在考試中常被搞混，它們解決重疊但不同的問題。

Vertex AI Vector Search（前身 Matching Engine）

基於 Google 內部 ScaNN 函式庫的託管近似最近鄰（ANN）索引。你自帶 embedding（通常用 text-embedding-004 或 textembedding-gecko@003 產生）。

  • 輸入：維度 1-1408 的向量，JSONL 格式放 Cloud Storage。
  • 索引類型：Tree-AH（最佳召回率）與 Brute Force（小資料集）。
  • 查詢延遲：對數十億向量約 5-50 ms。
  • 使用場景：RAG、推薦系統、語意搜尋的底層建構模組，且你掌控 embedding 模型與排序。

Vertex AI Search（前身 Discovery Engine / Gen App Builder）

較高階的託管搜尋即服務。你上傳文件（PDF/HTML/Cloud Storage/BigQuery），就得到具備內建語意排序、摘要、以及對 Gemini 開箱即用 grounding 的搜尋 REST API。

  • 不需要做 embedding — Google 處理 chunking、embedding、索引。
  • 內建附引用的答案生成。
  • 使用場景：企業搜尋、客服聊天機器人、內部知識庫；想最快上線時的選擇。

兩者怎麼選

需求 服務
最底層向量原語 Vector Search
開箱即用的文件 Q&A Vertex AI Search
自訂 embedding 模型（例如領域微調） Vector Search
不想自管 chunking/索引 Vertex AI Search

Agent Builder 與 RAG 架構

Vertex AI Agent Builder 是 GCP 上打造接地 GenAI 應用的傘狀產品，整合 Vertex AI Search、Conversational Agents（改名後的 Dialogflow CX），以及用於程式碼優先 agent 工作流的 Agent Development Kit（ADK）。

Vertex AI 上的 RAG 參考架構

典型的 Retrieval-Augmented Generation 管線：

  1. Ingestion： 文件放進 Cloud Storage，Cloud Run 服務或 Dataflow 任務擷取文字（PDF 用 Document AI）。
  2. Chunking & Embedding： 文字切成約 500-1000 token 的 chunk，每段 chunk 透過 text-embedding-004 產出向量。
  3. Indexing： Embedding 與 chunk metadata 串流寫入 Vertex AI Vector Search。
  4. 查詢路徑： 使用者問題 → embed query → ANN 查詢 → top-k chunks → 塞入 Gemini prompt → 回傳含引用的答案。
  5. 評估： Vertex AI Evaluation Service 對答案的 groundedness、流暢度、安全性評分。

託管 RAG 捷徑

如果團隊偏好託管而非自建，Vertex AI Search 把步驟 2-4 收進單一 API 呼叫。客製化 RAG 路徑只有在需要領域微調 embedding 模型、自訂 chunking 邏輯（例如尊重法律條款邊界）、或非文字模態時才有意義。

Agent 模式

  • 單一 agent + 工具： 一個 Gemini agent 配合函式呼叫工具（BigQuery 查詢、內部 API）。
  • 多 agent 編排： ADK 的 SequentialAgent、ParallelAgent、LoopAgent 組合多個專業化 agent（研究 agent → 撰稿 agent → 審稿 agent）。

RAG = 把使用者 query 做 embedding + 從 Vector Search 取 top-k chunk + 把 chunk 當 context 接到 LLM prompt 前。Vertex AI Search 是「託管 RAG」；Vector Search 是「DIY RAG」。考題若問「把 LLM 答案接地到私有文件」，優先選 Vertex AI Search，除非題目明確提到自訂 embedding 或領域特定 chunking。

訓練運算：GPU、TPU 與機型選擇

Vertex AI Training 透過訓練任務的 machineSpec 欄位，開放 Google 完整的加速器目錄。

TPU 選項

  • TPU v5e — 為推論與中型訓練最佳化成本。ct5lp-hightpu-{1,4,8}t 機型。對 100 億參數以下的基礎模型微調，最具 price/perf 優勢。
  • TPU v5p — 接續 v4 的高效能版，pod 最大可達 8960 顆晶片，用於前沿規模的預訓練。
  • TPU v4 — 仍廣泛可用，ct4p-hightpu-4t 機型，軟體堆疊（JAX/PAX）成熟。
  • TPU v3 — 舊版；新工作負載請選 v5e。

GPU 選項

  • NVIDIA A100（40GB / 80GB） — a2-highgpu-* 與 a2-ultragpu-* 機型。PyTorch 基礎模型工作的預設選擇。
  • NVIDIA H100 — a3-highgpu-8g 與 a3-megagpu-8g。大型語言模型訓練的頂規。
  • NVIDIA L4 — g2-standard-*。推論、影片與輕量訓練的最佳 price/perf。
  • NVIDIA T4 / V100 — 舊版，仍可用但現在很少是最佳選擇。

機型選擇法則

  • Embedding 微調、BERT 級： 單顆 A100 或 4 顆 L4。
  • 7B-13B LLM 微調： 8 顆 A100 80GB 或 TPU v5e-8。
  • 70B+ LLM 訓練： TPU v5p pod slice 或具 NVLink 的 H100 cluster。
  • 小於 1B 參數的推論： L4 或 TPU v5e-1。

Reduction Server

做 multi-worker GPU 訓練時，啟用 Vertex AI 的 Reduction Server 把 all-reduce 流量從 worker 節點卸載出去，對大型語言模型常能提升 20-40% 吞吐量。

啟動訓練任務時加上 --enable-web-access，就可以用 gcloud beta ai custom-jobs stream-logs 串接 log 並 SSH 進執行中的容器；搭配 Vertex AI Experiments 比較超參數掃描結果 — 別再用試算表手刻多次執行的紀錄。

Vertex AI Pipelines（MLOps 骨幹）

Vertex AI Pipelines 讓你能用 **Kubeflow Pipelines（KFP）**或 **TensorFlow Extended（TFX）**編排 ML 工作流，達成自動化、監控與治理。

  • Metadata 追蹤： 每次管線執行，Vertex AI 都自動記錄 artifact（資料、模型、指標）與血緣（哪份資料產生了哪個模型）。
  • 可重複使用： 元件只蓋一次，可在多個管線重複使用。
  • 架構提示： 用 Pipelines 實作 Continuous Training（CT）。BigQuery 有新資料進來時，觸發管線重新訓練並重新評估模型。
  • 觸發方式： Cloud Scheduler → Pub/Sub → Cloud Run → aiplatform.PipelineJob.run()；或用 Eventarc 對 BigQuery table 變更事件觸發。

Vertex AI 安全與 IAM

  • IAM 角色： 給資料科學家用 roles/aiplatform.user、給唯讀稽核者用 roles/aiplatform.viewer、給平台擁有者用 roles/aiplatform.admin。避免使用權限過廣的舊版 roles/ml.admin。
  • VPC Service Controls： 把 Vertex AI 資源放進安全周界，防止資料外洩；對 HIPAA / 金融服務工作負載至關重要。
  • Private Endpoints： 透過 Private Service Connect 讓推論流量留在私有 VPC，不走公開網際網路。
  • CMEK： 用 Cloud KMS 的客戶管理金鑰加密訓練資料、模型 artifact 與 feature store 內容。

成本優化策略

  • Spot VMs（舊稱 Preemptible）： 用於非關鍵、長時間訓練任務，可省下 60-91% 運算成本。記得每 N 分鐘 checkpoint 到 Cloud Storage，被中斷時可恢復。
  • 自動擴展 Endpoints： 設定低 min_replica_count 與高 max_replica_count，在延遲與成本之間取得平衡。注意傳統 Vertex Endpoints 無法縮到零；若需要真正的縮到零，小模型可考慮用 Cloud Run 提供服務。
  • Workbench 閒置關機： 透過 idle-timeout-seconds metadata 旗標，讓 notebook 實例在閒置 N 分鐘後自動關機。
  • Batch 取代 Online： 若延遲不需要即時，batch prediction 通常比常駐 Endpoint 便宜 70-90%。
  • 承諾使用折扣（CUD）： TPU 與 GPU 的 CUD 對多月期工作負載可省 20-55%。

PCA 成本優化情境裡，槓桿最大的手段依序是：(1) 在延遲允許時把 online prediction 換成 batch — 通常省 70-90%；(2) 訓練用 Spot VMs 並把 checkpoint 寫到 Cloud Storage；(3) 加速器選對尺寸（小於 1B 參數的推論用 L4，而非 A100）。預留容量（CUD）只有在 uptime SLA 不允許被中斷時，才會贏過 Spot。

常見問題 — Vertex AI 平台工作流程

Q1. AutoML 與 Custom Training 有什麼差別？

AutoML 是「低程式碼」做法，由 Google 處理模型架構與超參數調校；Custom Training 是「程式碼為主」的做法，你自己提供模型程式碼與訓練容器。

Q2. 為什麼需要 Feature Store？

Feature Store 確保訓練與服務之間的一致性，避免「training-serving skew」 — 也就是正式環境看到的資料與訓練時不同，導致模型表現變差。

Q3. Vertex AI 如何處理模型版本？

Model Registry 讓你儲存同一個模型的多個版本，可以打 tag（如 "production"、"staging"），新版本部署失敗時也能輕鬆回滾。

Q4. Vertex AI Pipelines 可以在地端執行嗎？

Vertex AI Pipelines 是 GCP 上的託管服務，但它與 Kubeflow 相容，Kubeflow 可在地端或 GKE 上執行，因此能採用混合雲 ML 策略。

Q5. Model Monitoring 裡的「Feature Drift」是什麼？

Feature Drift 指輸入資料的統計分布隨時間改變（例如使用者行為出現新趨勢）。Vertex AI 會發送告警，提醒你用新資料重新訓練模型。

想要託管式文件 Q&A、內建 chunking／索引／grounding，用 Vertex AI Search；想要完整掌控 embedding 模型、chunking 策略或非文字模態，用 Vector Search。

架構師最後提醒

PCA 考試請聚焦在 MLOps。理解 Vertex AI Pipelines 與 Model Registry 如何提供企業級 ML 所需的治理能力。情境若提到「可重現性」或「追蹤模型血緣」，答案就是 ML Metadata 與 Pipelines。GenAI 情境預設選 Vertex AI Studio + Gemini + grounding。文件 Q&A 情境預設選 Vertex AI Search。「透明度」或「法規遵循」的關鍵答案是 Explainable AI。

官方資料來源

更多 PCA 主題