Vertex AI pricing explained: the five cost drivers and the one that bills while you sleep

Vertex AI pricing explained: the five cost drivers and the one that bills while you sleep

A note on the name before we start: at Google Cloud Next in April 2026, Google renamed Vertex AI the Gemini Enterprise Agent Platform. The pricing page still lives at the Vertex AI URL and the billing mechanics are unchanged, so everything below applies under either name. We cover the rebrand in full in the pillar guide.

Why Vertex AI pricing is hard to read

Most people arrive expecting a per-hour or per-seat number. Vertex AI does not work that way. It is a platform of separate services - training, prediction, Model Garden, pipelines, feature store - and each is metered on its own unit. Your invoice is the sum of whatever you touched, in whatever region you touched it.

That is good news for a proof of concept (you pay for little) and a trap in production (costs accrue in places you forgot you turned on). The rates themselves move too - Google adjusts generative-model token prices periodically, and they vary by region - so this guide deliberately explains the shape of each cost rather than quoting figures that go stale. For live numbers, the source of truth is the official Vertex AI pricing page.

The five cost drivers

1. Prediction endpoints - the cost that bills while you sleep

This is the single most important thing to understand about Vertex AI pricing. When you deploy a custom-trained model to an online prediction endpoint, you pay for every hour the model stays deployed, even if it serves zero requests. Google’s own pricing page is blunt about it: you are charged for each model deployed to an endpoint even if no prediction is made, and you must undeploy the model to stop the charges.

Billing is per node-hour, scaled by the machine type behind the endpoint (and any attached GPUs), multiplied by the number of nodes. Autoscaling can take the node count down, but typically not to zero for a standard online endpoint - there is a minimum replica count holding capacity ready for low-latency responses. So the mental model is not “pay per prediction”. It is “rent a machine that happens to serve predictions”, and the rent runs until you tear it down.

The classic overspend: a data scientist deploys a model to test an integration, the test passes, everyone moves on, and the endpoint quietly bills node-hours for weeks. Multiply that across a team and it is a real monthly line with nothing to show for it.

2. Custom training - pay while the job runs

Training is billed for the compute consumed while the job runs: machine-hours for the VM, plus the hourly rate for any GPUs or TPUs attached, for the wall-clock duration of the job. When the job finishes, the charge stops. This is the intuitive one - it behaves like renting compute by the hour - but GPU and TPU rates are high, so a long training run on accelerated hardware is often the biggest single-event cost on the platform.

3. Model Garden - it depends which model

Model Garden is not one price because it is not one kind of model. Broadly:

• Google’s own generative models (Gemini family) are billed per million input and output tokens. Rates differ by model and change over time, so check the live page.
• Third-party partner models served through Model Garden are billed at the provider’s rate, passed through.
• Open-weight models you self-deploy behave like a prediction endpoint - you pay per node-hour for the hardware they run on, not per token.

The trap here is the same as driver 1: a self-deployed open model is a running machine, not a per-call API.

4. Batch prediction - cheaper for bulk

When you do not need real-time responses, batch prediction runs a job over a dataset and bills per node-hour for the job’s duration, then stops. For large offline scoring it is usually far cheaper than keeping an online endpoint warm, precisely because nothing stays deployed afterwards.

5. The supporting services nobody budgets for

Feature Store, Vertex AI Pipelines, model/artifact storage, and - the perennial surprise - network egress are each metered on their own. None is large on its own at small scale, but together they form the gap between your estimate and your invoice. Egress in particular catches teams moving prediction results or training data across regions or out of Google Cloud.

A worked monthly example

To make the shape concrete, here is one realistic scenario. The figures are illustrative - they show how the bill is composed, not a quote. Verify current rates for your region on the official pricing page before budgeting.

Scenario: a team running one custom-trained model behind an online endpoint 24/7 on a small machine with two replicas; a weekly retraining job on a GPU VM taking ~4 hours; and a Gemini-based feature calling the model API for roughly 50M input and 10M output tokens a month. Plus modest storage and some cross-region egress.

The lesson from the shape: at this profile the always-on endpoint dominates, because it is fixed and runs every hour of the month regardless of use. Double the traffic and the token line grows while the endpoint stays flat - so cost per request falls. Halve the traffic and the endpoint still bills the same, so cost per request rises. This is the inverse of a pure per-token API, and it is why “how much does Vertex AI cost” has no single answer.

How to keep the Vertex AI bill under control

• Undeploy endpoints you are not using. The single highest-leverage habit. An idle deployed model is pure waste. Automate teardown of non-production endpoints out of hours.
• Use batch prediction when latency does not matter. Offline scoring through a batch job avoids keeping an endpoint warm.
• Right-size the node and replica count. The online endpoint cost is machine-type × replicas × hours. Smaller machines and a lower minimum replica count cut the fixed floor directly.
• Apply Committed Use Discounts for steady workloads. If an endpoint genuinely runs 24/7 for the long term, a CUD trades commitment for a lower rate. We cover this in depth in our guide to GCP cost optimisation.
• Watch egress and cross-region traffic. Keep training data, endpoints, and the services calling them in the same region where you can.
• Tag and attribute cost per team and model. You cannot control what you cannot see; per-model labels turn “the Vertex bill went up” into “this endpoint went up”.

When it is worth bringing in a partner

• Endpoint strategy. Deciding what stays online 24/7, what moves to batch, and what autoscales is an architecture decision with a direct monthly cost, not a config toggle.
• Cross-cloud comparison. If you are weighing Vertex AI against AWS, the platforms bill differently enough that a like-for-like TCO needs care - we lay out the comparison in Vertex AI vs SageMaker.
• FinOps on GCP generally. Vertex is one line in a wider bill; CUDs, slot reservations, and egress discipline compound across the account.

Summary

Vertex AI pricing is the sum of separate, usage-based services, not a single rate. Five drivers shape the bill: prediction endpoints (billed per node-hour while deployed, even idle), custom training (per hour while the job runs), Model Garden (per token or per node-hour depending on the model), batch prediction (per job), and supporting services like storage and egress.

Three things to remember:

1. A deployed endpoint is rent, not pay-per-use. It bills until you undeploy it. This is the most common source of waste.
2. The cost shape inverts a pure API. Fixed endpoints dominate at low traffic; token costs dominate at high traffic.
3. The rates move. Treat this guide as the structure and the official pricing page as the live numbers.

Frequently asked questions about Vertex AI pricing

Sizing a Vertex AI budget, or chasing down why the bill grew?

Book a free 30-minute call. We help teams model Vertex AI costs per driver, find the idle endpoints quietly billing node-hours, and decide what belongs online, in batch, or under a Committed Use Discount.

Book a call Send a message