Vertex AI can train models with managed infrastructure, custom containers, selected machine types, GPUs or TPUs, distributed training, logging, and debugging options.
2
Custom containers give teams control over training and serving code, versioning, dependencies, preprocessing, logging, and model artifacts.
3
Vertex AI Pipelines can connect training, container building, model upload, endpoint deployment, experiments, and model lineage without teams managing their own Kubernetes cluster.
Summary
Sascha Heyer gives a hands-on introduction to using Vertex AI across model training, serving, and pipelines. He starts with a training application packaged in a custom container, then shows how to build the image with Cloud Build, push it to the Google Container Registry, and submit a training job through the Vertex AI SDK. The training job can specify machine types and accelerators, while Vertex AI manages the infrastructure. He then explains how to serve a trained model with a pre-built or custom container, including the HTTP health and prediction endpoints required by Vertex AI. The final section turns these steps into a Kubeflow pipeline. Components can train a model, build a serving container, upload the model to the Model Registry, and deploy it to an endpoint. Vertex AI records artifacts, metrics, experiments, and model lineage. Heyer is also direct about limits, including request sizes, model sizes, and the fact that endpoints do not scale down to zero.
Managed training moves teams beyond notebooks without requiring cluster administration
Sascha describes the common path from a notebook proof of concept to larger datasets and production deployment. Vertex AI provisions the infrastructure needed for training, so teams do not have to manage a virtual machine or a Kubernetes cluster themselves. Training jobs can specify machine types and accelerators such as GPUs or TPUs, and distributed training is available for large datasets. The service also provides logging and debugging options. Sascha says the experience is similar to local training, while allowing the workload to run at a larger scale. He recommends moving the implementation into a code repository rather than continuing to train manually from a notebook.
Custom training containers keep code, dependencies, and versions together
Vertex AI needs the training code and its dependencies packaged before it can run a job. Sascha presents two options, a custom Docker container or a Python source distribution stored in Google Cloud Storage. He recommends the custom container because the image is versioned in the container registry and can be used in a CI/CD process. The same image can run in environments that support Docker, which reduces dependency differences between local development and training. Older training versions remain available, so a team can roll back after a bad change. The workflow is to create a Dockerfile, build the image with Cloud Build, push it to the Google Container Registry, and submit the image as a training job.
Training jobs can be sized and inspected through the SDK or other interfaces
For a training job, Sascha defines a region, a display name, a worker pool, a machine type, and an accelerator. His example uses an N1 standard 8 machine with an Nvidia Tesla T4 GPU. Vertex AI provisions the requested hardware and shows the selected machine, container, elapsed time, and CPU and GPU utilization. Those measurements help a team decide whether the machine is oversized or whether more capacity is needed. Jobs can be started through the gcloud command, the Vertex AI SDK, another client library, the Google API, or the user interface. Multiple jobs can run in parallel when the project needs several models or experiments.
Serving requires a model registry entry and an endpoint deployment
After training, Sascha uploads the model to Google Cloud Storage and explains three serving choices: a Google-provided container, a custom container, or a custom prediction routine. The custom container gives control over prediction code, logging, preprocessing such as tokenization, and hosting multiple models at one endpoint. The deployment flow has three steps. First, create an endpoint. Second, upload the model to the Vertex AI Model Registry. Third, deploy the model to the endpoint. Deployment can set the machine type, accelerator, and traffic split. A team can send some traffic to a newer model version while retaining an older version, then change the split after checking the result.
A custom prediction container has a small HTTP contract
A custom serving container must run a Dockerized application that listens for requests, normally on 0.0.0.0 and port 8080. It must expose a health-check path so Vertex AI can determine whether the model is ready, along with a prediction path. Requests and responses use JSON. The rest of the implementation is flexible. Sascha's example uses FastAPI, loads a tokenizer and model, performs preprocessing, runs prediction, and formats the result. He recommends putting model artifacts and tokenizers inside the container. Downloading them when each instance starts can add cold-start time, especially when autoscaling creates several instances.
Vertex AI has practical serving limits that affect architecture choices
Sascha names several limitations as of the workshop. Request and response payloads are limited to 1.5 megabytes, which can matter for large images. He suggests reducing or encoding inputs when necessary. He also describes a model size limit of 15 gigabytes at that time, while newer Transformer models can be larger. Vertex AI endpoints do not scale down to zero, so deploying many models can create a cost problem. Cloud Run or Kubernetes can be alternatives when a project does not need Vertex AI features or needs to work around a specific limit. The choice depends on the team's requirements and its ability to maintain virtual machines or Kubernetes.
Pipelines turn manual training and deployment steps into reusable components
Sascha introduces Vertex AI Pipelines as a managed way to run Kubeflow or TensorFlow Extended pipelines. A pipeline is made from components, and each component performs one step such as preprocessing, training, evaluation, container building, model upload, or deployment. In his example, a Python function becomes a component through a decorator. The pipeline connects outputs from one component to inputs of the next, then a compiler creates a pipeline specification that Vertex AI can run. His larger example trains a model, builds a serving container, and deploys the resulting model. The pipeline can also request a GPU and disable caching for demonstration purposes.
Pipeline metadata supports experiments, lineage, reuse, and rollback
Vertex AI Pipelines records artifacts and metrics that move into and out of components. Sascha uses this metadata to answer which data produced a model and which model came from a particular pipeline run. Pipeline runs can record metrics such as accuracy, and Vertex AI Experiments allows runs and parameter values to be compared. The Model Registry stores multiple model versions, so a team can identify an older version and roll back when needed. Sascha also mentions pre-built components for Google services, reusable component specifications, parameterized pipelines, and scheduled execution through Cloud Scheduler calling a Cloud Function.
