Google Vertex AI Overview

Vertex AI is a platform, not a single service

Newcomers often expect Vertex AI to be one endpoint you call. It is closer to a product suite: a collection of related services on Google Cloud that share a project, an API surface and a set of IAM roles, covering everything from calling a hosted model to training a custom one and running the pipeline that produced it.

That breadth is the reason a tour is useful. Two teams can both say they use Vertex AI and have almost no components in common, one living entirely in the generative model APIs and the other in custom training and batch prediction.

Everything begins with a Google Cloud project. You enable the Vertex AI API on it, attach a billing account, and grant roles. The project and billing relationship described in Google Cloud projects and billing accounts is the container for all of it, and resources are created in a specific region within that project.

Model Garden and the generative surface

Model Garden is the catalog. It lists Google's own model families, including the Gemini text and multimodal models, Imagen for images and Veo for video, alongside partner models and a large set of open weight models published by third parties.

Models in the catalog are offered in more than one shape. Some are consumed as a managed API where Google runs the serving. Others are offered for deployment onto an endpoint in your own project, which puts the serving infrastructure under your control and your quota. A few are simply source and weights you take elsewhere.

Vertex AI Studio is the interactive front end to that catalog: a place to draft prompts, adjust parameters, compare outputs and export working code. It is a prototyping surface rather than a production one, but exporting from it is the fastest route from an idea to a first API call.

Grounding deserves a mention here. The generative APIs support grounding responses in Google Search or in your own data sources, which attaches citations and reduces reliance on whatever the model absorbed during training.

Endpoints, batch prediction and reserved capacity

When you bring a model rather than call a hosted one, the unit of deployment is an endpoint. You upload a model to the Model Registry, deploy it to an endpoint backed by a machine type you choose, and optionally attach accelerators. Traffic splitting across deployed model versions is built in, which makes a gradual rollout straightforward.

Batch prediction covers the opposite need. You submit a large input set from Cloud Storage or BigQuery, Vertex AI runs it asynchronously, and results are written back. Nothing stays warm between jobs, so it suits scheduled scoring rather than user facing requests.

For the managed generative APIs, Google offers Provisioned Throughput as an alternative to pay as you go consumption. You reserve a level of capacity for a term and get predictable service in return, which is the same bargain reserved capacity offers everywhere in the cloud.

Custom training, tuning and pipelines

Custom training jobs run your own container or a prebuilt framework container on machines you specify, including multi node configurations with accelerators. The job pulls data, writes checkpoints to Cloud Storage, and exits. Hyperparameter tuning runs many such jobs under a search strategy.

For the generative families, supervised tuning adapts a base model on labeled examples without you managing any training infrastructure. Distillation and other adaptation methods appear in the catalog for particular models. The resulting tuned model is registered and deployed through the same endpoint mechanism as anything else.

Vertex AI Pipelines ties the steps together. Built on Kubeflow Pipelines and TFX, it runs a directed graph of containerized steps with artifact tracking, so a retrained model is reproducible rather than the result of someone running notebooks in the right order. Experiments and metadata services record what ran and what it produced.

Workbench provides managed Jupyter instances for the interactive half of this work, which is one flavor of the pattern described in cloud development environments.

The data side: Feature Store and Vector Search

Two data oriented components come up constantly and are easy to miss in the catalog.

Feature Store manages the features that models consume, serving the same definitions to training and to online prediction so the two do not drift apart. Its current form is built on BigQuery, which keeps feature engineering in the query language teams already use.

Vector Search, previously known as Matching Engine, is Google's managed nearest neighbor service. You supply embeddings, it builds and serves an index, and queries return the closest matches with optional metadata filtering. It is the natural retrieval layer for a grounded application on this platform, and it sits alongside the alternatives surveyed in vector databases in the cloud.

Permissions, quotas and regions

Access is granted with IAM roles at the project level. Predefined roles cover the common shapes, from a broad platform user role down to narrower ones for viewing or for specific subservices, and custom roles exist when those do not fit. The principles in cloud IAM fundamentals apply unchanged.

Quotas are enforced per project and per region, and generative model usage is metered separately from training and prediction capacity. Accelerator quota in particular starts restricted and is requested through the standard quota process rather than granted automatically.

Region choice affects three things at once: which models are offered, where data is processed, and what accelerator types you can attach. Google exposes both regional endpoints and a global endpoint for some generative APIs, and the difference is meaningful when data residency is a requirement, as discussed in data residency and sovereignty.

When this platform is the right answer

Vertex AI fits best when the gravity is already on Google Cloud. If your data sits in BigQuery and Cloud Storage, keeping training and serving in the same project removes transfer, latency and permission problems that otherwise consume real engineering time.

It also fits teams that want the full lifecycle in one place rather than a model API alone. Registry, pipelines, monitoring and tuning under one set of permissions is a genuine operational advantage once more than one person maintains the system.

It fits less well when you only need a single hosted model call and have no other Google Cloud footprint, where the surrounding platform is overhead you are not using. Working through that decision is the subject of choosing a cloud for AI development, and the AWS and Google Cloud comparison covers the wider platform question. Access starts with a project, which is what a Google Cloud account provides.

Key takeaways

• Vertex AI is a suite sharing one project, one API surface and one set of IAM roles, not a single endpoint.
• Model Garden covers Google models, partner models and open weight models, consumed either as a managed API or deployed to your own endpoint.
• Endpoints serve online traffic and bill for allocated machines; batch prediction handles bulk work with nothing left running.
• Pipelines, Model Registry and Experiments are what turn ad hoc training into something reproducible.
• Quota, model availability and accelerator types all vary by region, so pick the region before the architecture.
• The Vertex AI documentation is the current reference for models, regions and quota behavior.