Module 1 — Vertex AI: components and vocabulary
Course 20 laid the MLOps ground rules — versioned data, reproducible training, staged deployment, monitoring. This course applies them on Vertex AI, Google Cloud's unified ML platform. Before writing a single line of training code we settle the vocabulary and the wiring, because every later mistake in the course can be traced back to something set up sloppily in this module.
What "unified" actually means
Before Vertex AI (announced in 2021), Google Cloud ML was a collection of separate products: AI Platform Training, AI Platform Prediction, AutoML, Notebooks, Pipelines. Vertex AI is the umbrella that unifies them under one API surface, one Model Registry, one metadata store for lineage, and one IAM permission set starting with aiplatform.*.
Concretely that means: the same Model object comes out of a CustomTrainingJob, an AutoML run, an upload from a notebook, or a Model Garden fine-tune, and can be deployed to the same Endpoint. This unification is what makes the KFP pipeline of module 9 possible without gluing four incompatible services together.
The building blocks the rest of the course will use
| Component | What it is | Where it appears |
|---|---|---|
| Project | Billing and IAM boundary; everything belongs to one project | Every module |
| Region | Physical location of compute, storage and endpoints | Every module |
| Service account | Non-human identity Vertex assumes to run jobs | Modules 4, 7, 9 |
| Cloud Storage bucket | Model artifacts, training data, pipeline outputs | Modules 3, 4, 6, 9 |
| Managed dataset | Vertex's typed wrapper around your data | Module 3 |
| CustomTrainingJob | A container run on a Vertex-provided VM | Module 4 |
| Model | An entry in the Model Registry, versioned | Module 6 |
| Endpoint | A network address serving one or more model versions | Module 7 |
| BatchPredictionJob | An offline scoring run reading and writing GCS or BigQuery | Module 8 |
| PipelineJob | A KFP DAG execution with artifacts and lineage | Module 9 |
Do not memorise the list; recognise these names when they appear later.
The project: one boundary for billing and access
A GCP project is the atomic unit for billing, quotas, IAM and API enablement. Everything Vertex AI creates — a training job, a model, an endpoint, a pipeline run — lives inside exactly one project.
The convention that keeps costs and blast radius under control is one project per environment: fraud-detection-dev, fraud-detection-stg, fraud-detection-prd. A mistake in dev cannot delete a production endpoint, and the monthly bill separates itself along the same axis the team already reasons about.
gcloud config set project fraud-detection-dev
gcloud services enable \
aiplatform.googleapis.com \
storage.googleapis.com \
bigquery.googleapis.com \
artifactregistry.googleapis.com \
notebooks.googleapis.com
Enabling APIs is not automatic. A first-time CustomTrainingJob that fails with PERMISSION_DENIED: aiplatform.googleapis.com has not been used means exactly what it says — the API was never enabled. Enable, wait ten seconds, retry.
The region: not a detail
Vertex resources are regional. A model in us-central1 cannot be deployed to an endpoint in europe-west1; a training job cannot read a bucket in another region without egress charges.
Pick one region for the whole course — europe-west1 for a European team, us-central1 for a US team — and put every bucket, dataset, training job, model and endpoint there. Latency, cost and residency all point the same way.
from google.cloud import aiplatform
aiplatform.init(
project="fraud-detection-dev",
location="europe-west1",
staging_bucket="gs://fraud-detection-dev-vertex-eu",
)
That single init call sets the defaults for every subsequent SDK object. Forget it and the SDK silently falls back to us-central1, cross-region-charges you for a year, and confuses everyone who reads the console filtered on Europe.
Service accounts: the identity Vertex uses on your behalf
When a CustomTrainingJob runs, it does not run as you. It runs as a service account — a non-human identity Vertex assumes to read data, write artifacts and record metadata. Two accounts appear repeatedly:
- Default Vertex AI service account (
service-<projectNumber>@gcp-sa-aiplatform.iam.gserviceaccount.com): the identity Vertex itself uses for platform operations. - Custom service account you attach to a job (recommended):
vertex-training@fraud-detection-dev.iam.gserviceaccount.com, with the minimum roles the job actually needs.
For the red thread that means the training service account needs at least roles/aiplatform.user, roles/storage.objectAdmin on the artifacts bucket, and roles/bigquery.dataViewer on the transactions dataset — nothing else.
Left to itself, a training job runs as the default Compute Engine service account, which is roles/editor on the whole project. This is a well-known GCP footgun: a rogue notebook can delete every resource. Always attach an explicit, least-privileged service account to a training job and pipeline.
The Vertex service map, in one paragraph per family
Data. Cloud Storage buckets carry files. BigQuery carries tables and lets you query them in SQL. Vertex managed datasets add a typed wrapper (image, text, tabular, video) and a split scheme — the SDK still reads from GCS or BigQuery underneath. Module 3 develops the choice.
Compute. Workbench and Colab Enterprise for interactive work. CustomTrainingJob, CustomContainerTrainingJob, HyperparameterTuningJob and BatchPredictionJob for scheduled work. AutoML for a codeless training path we do not use in this course. Modules 2, 4, 5 and 8 cover each.
Model management. Model Registry stores versioned model artifacts, Endpoints serve them online, Batch prediction serves them offline. Metadata records lineage across every step. Modules 6 and 7.
Orchestration. Vertex AI Pipelines runs KFP or TFX DAGs on serverless infrastructure and stores every artifact under a run ID. Module 9.
Foundation models. Model Garden lists Google's PaLM, Gemini, Imagen and open-source models like Llama and Mistral, with a call-and-pay-per-token interface and managed tuning. Module 10.
Per-second billing you can read
Vertex bills training and prediction per second of VM time, per accelerator second, and per GB of stored artifacts. The console under Billing → Reports, filtered on service Vertex AI, breaks the bill down by SKU: Custom training, Online prediction, Batch prediction, Pipelines, Managed notebook. Read it weekly.
Two habits keep the bill sane. First, tag every job with a label — env=dev, team=fraud, experiment=xgb-v3 — so the report groups by what you already reason about:
job.run(
...,
labels={"env": "dev", "team": "fraud", "experiment": "xgb-v3"},
)
Second, look at the estimated cost before you press run for anything using an accelerator. An n1-standard-8 with one NVIDIA_TESLA_T4 sits around $0.60 an hour; a n1-highmem-8 with two NVIDIA_TESLA_V100 sits around $5. The 10× is easy to miss when clicking through a dropdown.
In summary
- Vertex AI unifies training, tuning, registry, serving and pipelines under one project, one region, one IAM model — that unification is what the course exploits from module 6 onward.
- One project per environment, all APIs enabled explicitly with
gcloud services enable; a first call that returnsPERMISSION_DENIEDalmost always means the API was not enabled. - Pick one region for the whole course and pass it to
aiplatform.init; cross-region resources charge egress and confuse the console. - Attach a least-privileged service account to every training job and pipeline; the default Compute Engine identity is
roles/editoron the project, which is the wrong default.
Next module: opening the notebook that will drive every experiment in the course — Vertex AI Workbench, with idle shutdown and direct BigQuery access.