Gemini Enterprise Agent PlatformAuthorCloudBrum editorial teamLast reviewed28 Oct 2026Reading time~12 minLevelBeginner to advanced

• Notebooks next to your dataWorkbench instances and Colab Enterprise notebooks both reach BigQuery and Cloud Storage with your own identity, so there’s little to set up before you can explore data.
• Custom training without servers to manageDescribe the machines and a container (or a Python script with a prebuilt image) and Vertex AI creates them, runs the job, writes the model to Cloud Storage and removes the machines.
• GPUs, TPUs and cheaper capacityAttach GPUs or TPUs to a job, run on Spot VMs for a discount, or use Flex-start to queue for scarce GPUs until they’re available.
• AutoML and tuningAutoML builds models for tables, images, text and video from labelled data. Hyperparameter tuning, backed by Vizier, runs many trials to find settings that score best.
• Endpoints that scaleDeploy models to an endpoint with a minimum and maximum replica count, split traffic between versions, and use batch prediction when you don’t need an answer straight away.
• Pipelines and a model registryPipelines are written with the Kubeflow Pipelines SDK and run as managed jobs. The Model Registry keeps versions and aliases that deployments can point to.
• Model Garden and GeminiA catalogue of Google, open and partner models you can try, deploy or tune, next to the Gemini models and the agent tools the platform now leads with.
• Watching and explaining modelsModel Monitoring spots skew and drift in live traffic, and Explainable AI shows which inputs pushed a prediction up or down.

Custom job

A training run you define: machine types, replica count, a container or script, and an output location. Vertex AI creates and removes the machines.

Training pipeline

A custom job plus the step that turns its output into a registered model. AutoML uses the same idea.

Prebuilt container

A maintained image for common frameworks (scikit-learn, XGBoost, TensorFlow, PyTorch) for training or prediction, so you don’t build your own.

Model Registry

The place where models and their versions live, with labels, aliases and links to the jobs that produced them.

Endpoint

A URL for online prediction. One endpoint can hold several deployed models with a traffic split between them.

Deployed model

A model version running on machines in an endpoint, with a machine type and a minimum and maximum replica count.

Replica

One copy of a deployed model’s serving container on a machine. Autoscaling moves the count between your minimum and maximum.

Batch prediction

A job that scores a file or table without an endpoint and writes results out, charging only while it runs.

Service account

The identity a job or endpoint runs as. Its roles decide which buckets, tables and secrets the code can touch.

Pipeline

A graph of steps defined with the Kubeflow Pipelines SDK and run as a managed job with caching and lineage.

Workbench

Managed JupyterLab instances for development. They bill while running, and can be set to shut down when idle.

Spot VM

Spare capacity at a discount that Google can reclaim, so training must checkpoint.

Flex-start

A scheduling option that queues a job until the GPU capacity it needs is available.

Model Garden

A catalogue of Google, open and partner models you can try in the console, deploy to an endpoint or tune.

Run your first training job and endpoint in the Google Cloud console

1. Pick a project, enable the API and choose a RegionCreate or choose a project with billing attached, enable the Vertex AI API, and choose a Region near your data and users (Mumbai asia-south1 or Delhi asia-south2 for India). Everything below lives in that Region.
2. Check quotaIn IAM and Admin, Quotas, look at custom training and GPU lines for the Region. A new project may start with low or zero GPU quota, and requests take time.
3. Make a bucket and a service accountCreate a Cloud Storage bucket in the same Region for data, staging and model output. Create a service account for training and give it access to that bucket and to Vertex AI only.
4. Open a notebookStart a Workbench instance or a Colab Enterprise notebook, check the idle shutdown setting, and explore the data. Write a training script that saves its model to the directory in the AIP_MODEL_DIR environment variable.
5. Run a custom training jobUnder Training, create a custom job with a prebuilt scikit-learn or XGBoost container, your script, a small machine type and the service account. Use Spot VMs if the job can restart.
6. Upload the modelImport the model from Cloud Storage into the Model Registry with the matching prebuilt prediction container, and add labels that say where it came from.
7. Deploy to an endpointCreate an endpoint, deploy the model with a machine type, a minimum of one replica and a maximum that fits your budget, and route all traffic to it.
8. Send a test requestUse the console’s test panel or the command line with a body such as {"instances": [[34, 2, 79.5, 1]]}, and check the response and the endpoint’s metrics.
9. Set alarms and clean upAdd alerts on error rate and latency, set a budget, and undeploy and delete test endpoints the same day, since an endpoint bills while its replicas run.

• Pick the machine type from a test. Many tabular models run well on a small CPU machine, and a GPU only pays off when your framework uses it.
• Keep data and compute in one Region, and read from Cloud Storage or BigQuery directly rather than copying files onto every worker.
• For large models, go distributed (multiple workers, TPUs or Ray), and check the network and input pipeline before adding machines.
• Tune hyperparameters with early stopping so poor trials end quickly, and cap the parallel and total trial counts.
• Set endpoint autoscaling on CPU or accelerator use, load-test it, and keep the minimum above zero where first-request delay hurts.
• Send batches of instances in one request when the model allows it.
• Optimised prediction containers and quantised models cut latency and machine size.
• Use batch prediction for large offline scoring rather than looping over an online endpoint.

FinOps is the habit of managing cloud spend together with engineering. These are the FinOps checks that matter most for Gemini Enterprise Agent Platform.

• Run restartable training on Spot VMs with checkpoints, and pick Flex-start when you need GPUs and can wait.
• Undeploy and delete test endpoints the same day. They bill by node-hour while replicas run.
• Set a sensible maximum replica count, and consider a minimum of zero for traffic that comes in bursts, with retries on the client.
• Score on a schedule with batch prediction, so no machines run between jobs.
• Shut down Workbench instances when idle, using the idle shutdown setting, and delete the disks you no longer need.
• Right-size machines from monitoring graphs, and move to a smaller type when the use is low.
• Look at committed use discounts for steady GPU or CPU usage once you know your baseline.
• Try a smaller or tuned model before a bigger one. For generative models, watch token use as its own cost line.
• Keep training data in compact formats such as Parquet and clear out old staging buckets, artifacts and model versions.
• Put labels on jobs, endpoints and notebooks, and build billing reports and budgets per label.

• Run jobs and endpoints as dedicated service accounts, with narrow roles on the buckets, datasets and secrets they use. Avoid the Editor role.
• Wrap Vertex AI, Cloud Storage and BigQuery in VPC Service Controls to limit data exfiltration, and serve predictions over Private Service Connect or private endpoints.
• Turn off external IP addresses on notebooks and training machines where you can, and use Private Google Access.
• Where policy requires it, encrypt models, datasets and endpoints with customer-managed keys (CMEK).
• Grant roles/aiplatform.user on named projects or endpoints, and keep admin roles for the few people who manage them.
• Build custom containers in a pipeline from pinned packages, store them in Artifact Registry and scan them.
• Restrict locations, external IPs and service account key creation with organisation policies.
• Enable Cloud Audit Logs (including data access logs for Vertex AI where needed) and review who created, deployed and called what.
• Monitor models and evaluate them, and keep the results with the registered model version.
• Scan training sets with Sensitive Data Protection to find personal data before it is used.

Use Cloud Audit Logs to see who started jobs and changed endpoints, Cloud Asset Inventory and Security Command Center for configuration and posture, Dataplex for data catalogue and lineage, and the Compliance resource centre for reports. The split of duties is the usual one: Google runs the platform, and you are responsible for the data, how the model behaves, who can access it and how changes are reviewed.

• Train less often, on a schedule that matches how fast your data really changes.
• Try a smaller model, or a tuned small model, before a large one. It costs less and uses less energy.
• Use batch prediction and scale-to-zero settings so accelerators aren’t idling.
• Use Spot VMs and Flex-start, which run on capacity that would otherwise sit unused.
• Choose a Region with lower carbon intensity for training that no one is waiting on. Google Cloud publishes carbon-free energy percentages for each Region.
• Distillation and quantisation shrink the machine every request needs, so do them before deployment.
• Carbon Footprint in the Cloud Console gives account-level estimates. See how it treats Vertex AI before you quote a number from it.

Purchase options

What you actually pay for

• Machine and accelerator time for notebooks, training jobs, AutoML and deployed endpoints, by machine type and hour
• Cloud Storage and BigQuery for data, artifacts and staging
• Artifact Registry for container images
• Network egress between Regions or out to the internet
• Generative model usage, tuning jobs, Feature Store and monitoring, which have their own SKUs

The same churn example on Google Cloud: a CSV in Cloud Storage, a custom job, the registry, then an endpoint. The gcloud and Python tabs run each step with the scikit-learn prebuilt containers; the Terraform tab builds the supporting pieces (a service account, a bucket and an empty endpoint), and the C# tab calls the deployed endpoint. The container tags change, so check the current list of prebuilt containers first. Undeploy and delete the endpoint when you’ve finished, because it bills while deployed.

# Names are examples. Mumbai is the example Region; the commands expect an authenticated gcloud.
PROJECT=my-project
REGION=asia-south1
BUCKET=acme-ml-my-project
SA=trainer@$PROJECT.iam.gserviceaccount.com
# Prebuilt containers: check the current tags in the Vertex AI docs
TRAIN_IMAGE=us-docker.pkg.dev/vertex-ai/training/sklearn-cpu.1-0:latest
PREDICT_IMAGE=us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-5:latest

gcloud services enable aiplatform.googleapis.com --project=$PROJECT

# 1. Train: src/train.py reads --data and saves model.joblib under --model-dir (both are gs:// paths)
gcloud ai custom-jobs create --project=$PROJECT --region=$REGION \
  --display-name=churn-train \
  --service-account=$SA \
  --worker-pool-spec=machine-type=n1-standard-4,replica-count=1,executor-image-uri=$TRAIN_IMAGE,local-package-path=src,script=train.py \
  --args=--data=gs://$BUCKET/churn/train.csv,--model-dir=gs://$BUCKET/churn/model

# 2. Put the model in the registry (training wrote it to gs://$BUCKET/churn/model/)
gcloud ai models upload --project=$PROJECT --region=$REGION \
  --display-name=churn-model \
  --artifact-uri=gs://$BUCKET/churn/model/ \
  --container-image-uri=$PREDICT_IMAGE

MODEL_ID=$(gcloud ai models list --project=$PROJECT --region=$REGION \
  --filter="displayName=churn-model" --format="value(name)" | head -n 1 | xargs basename)

# 3. An endpoint, then deploy the model to it
gcloud ai endpoints create --project=$PROJECT --region=$REGION --display-name=churn-ep
ENDPOINT_ID=$(gcloud ai endpoints list --project=$PROJECT --region=$REGION \
  --filter="displayName=churn-ep" --format="value(name)" | head -n 1 | xargs basename)

gcloud ai endpoints deploy-model $ENDPOINT_ID --project=$PROJECT --region=$REGION \
  --model=$MODEL_ID --display-name=blue \
  --machine-type=n1-standard-2 --min-replica-count=1 --max-replica-count=3 \
  --traffic-split=0=100

# 4. Score one customer
echo '{"instances": [[34, 2, 79.5, 1]]}' > request.json
gcloud ai endpoints predict $ENDPOINT_ID --project=$PROJECT --region=$REGION --json-request=request.json

# 5. Stop the meter: undeploy everything, then delete the endpoint
DEPLOYED_ID=$(gcloud ai endpoints describe $ENDPOINT_ID --project=$PROJECT --region=$REGION \
  --format="value(deployedModels[0].id)")
gcloud ai endpoints undeploy-model $ENDPOINT_ID --project=$PROJECT --region=$REGION --deployed-model-id=$DEPLOYED_ID
gcloud ai endpoints delete $ENDPOINT_ID --project=$PROJECT --region=$REGION --quiet

# Supporting pieces: a service account, a bucket and an empty endpoint. Assumes the google provider version 5 or later.
# Training, model upload and deployment are done with the gcloud or Python tabs.
variable "project" { type = string }
variable "region"  { default = "asia-south1" }

provider "google" {
  project = var.project
  region  = var.region
}

resource "google_project_service" "aiplatform" {
  service            = "aiplatform.googleapis.com"
  disable_on_destroy = false
}

resource "google_service_account" "trainer" {
  account_id   = "trainer"
  display_name = "Vertex AI training and serving"
}

resource "google_project_iam_member" "trainer_vertex" {
  project = var.project
  role    = "roles/aiplatform.user"
  member  = "serviceAccount:${google_service_account.trainer.email}"
}

resource "google_storage_bucket" "ml" {
  name                        = "acme-ml-${var.project}"
  location                    = var.region
  uniform_bucket_level_access = true
  public_access_prevention    = "enforced"
}

# Read and write objects in this bucket only
resource "google_storage_bucket_iam_member" "trainer_objects" {
  bucket = google_storage_bucket.ml.name
  role   = "roles/storage.objectAdmin"
  member = "serviceAccount:${google_service_account.trainer.email}"
}

# The endpoint name must be numeric (up to 10 digits) when you choose it yourself
resource "google_vertex_ai_endpoint" "churn" {
  name         = "4100000001"
  display_name = "churn-ep"
  description  = "Churn model endpoint"
  location     = var.region

  labels = {
    owner = "data-science"
  }

  depends_on = [google_project_service.aiplatform]
}

# pip install google-cloud-aiplatform
from google.cloud import aiplatform

PROJECT = "my-project"
REGION = "asia-south1"
BUCKET = "acme-ml-my-project"
SA = "trainer@my-project.iam.gserviceaccount.com"
TRAIN_IMAGE = "us-docker.pkg.dev/vertex-ai/training/sklearn-cpu.1-0:latest"        # check current tags
PREDICT_IMAGE = "us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-5:latest"

aiplatform.init(project=PROJECT, location=REGION, staging_bucket=f"gs://{BUCKET}")


def train():
    """Run src/train.py on a managed machine. The script saves model.joblib to AIP_MODEL_DIR."""
    job = aiplatform.CustomJob.from_local_script(
        display_name="churn-train",
        script_path="src/train.py",
        container_uri=TRAIN_IMAGE,
        requirements=["pandas"],
        machine_type="n1-standard-4",
        replica_count=1,
        base_output_dir=f"gs://{BUCKET}/churn",
    )
    job.run(service_account=SA, sync=True)


def register():
    """Add the trained artifact to the Model Registry with a matching prediction container."""
    return aiplatform.Model.upload(
        display_name="churn-model",
        artifact_uri=f"gs://{BUCKET}/churn/model/",
        serving_container_image_uri=PREDICT_IMAGE,
    )


def deploy(model):
    """One endpoint, one deployed model that scales between one and three replicas."""
    endpoint = aiplatform.Endpoint.create(display_name="churn-ep")
    model.deploy(
        endpoint=endpoint,
        deployed_model_display_name="blue",
        machine_type="n1-standard-2",
        min_replica_count=1,
        max_replica_count=3,
        traffic_percentage=100,
    )
    return endpoint


if __name__ == "__main__":
    train()
    endpoint = deploy(register())
    try:
        # tenure, support calls, monthly charge, contract type
        print(endpoint.predict(instances=[[34, 2, 79.5, 1]]).predictions)
    finally:
        # Undeploying and deleting is what stops the billing
        endpoint.undeploy_all()
        endpoint.delete()

// Program.cs: score one row on a deployed Vertex AI endpoint
// NuGet package: Google.Cloud.AIPlatform.V1
// Credentials come from Application Default Credentials (gcloud auth application-default login, or the service account the code runs as)
using Google.Cloud.AIPlatform.V1;
using ProtoValue = Google.Protobuf.WellKnownTypes.Value;   // Vertex has its own Value type, so alias the protobuf one

const string project = "my-project";
const string location = "asia-south1";
var endpointId = Environment.GetEnvironmentVariable("VERTEX_ENDPOINT_ID")
    ?? throw new InvalidOperationException("Set VERTEX_ENDPOINT_ID to the endpoint's numeric ID");

// Regional service address: the location must match the endpoint's
var client = new PredictionServiceClientBuilder
{
    Endpoint = $"{location}-aiplatform.googleapis.com"
}.Build();

// One row: tenure, support calls, monthly charge, contract type
var row = ProtoValue.ForList(ProtoValue.ForNumber(34), ProtoValue.ForNumber(2), ProtoValue.ForNumber(79.5), ProtoValue.ForNumber(1));

var request = new PredictRequest
{
    EndpointAsEndpointName = EndpointName.FromProjectLocationEndpoint(project, location, endpointId),
    Instances = { row }
};

PredictResponse response = await client.PredictAsync(request);
foreach (var prediction in response.Predictions)
{
    Console.WriteLine($"Prediction: {prediction}");
}

Short walkthrough videos for this service are being prepared. They will appear here and load only when you press play. Until then, follow CloudBrum on YouTube for new videos.

The platform sits beside simpler options. If your data already lives in BigQuery and the model is a standard one, BigQuery ML trains it with SQL and no separate platform. For quick wins with no training, the Google Cloud AI APIs cover vision, speech and language, and training data for custom work usually starts in Cloud Storage.