Vertex AI has no single price. The bill is the sum of several usage-based services, and the one that surprises teams the most is prediction endpoints: a deployed model is billed for as long as it is deployed, whether or not a single request hits it. This worksheet turns that into a fill-in estimate, driver by driver, so you can put a number on a Vertex AI build before you commit. It is the same structure we use internally when we size a budget or chase down why a bill grew.
A note on the name: 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.
The full worksheet is right below, free to read and use.
Leave your email if you also want the occasional practical note on cloud cost and AI tooling. No sales call, unsubscribe anytime, and the worksheet stays open either way.
How to use this worksheet
Work through the five drivers below in order. For each one, write down your own numbers in the “your input” prompts. We deliberately do not quote live per-unit rates here: Google adjusts them and they vary by region, so the worksheet captures the shape of each cost and your usage. For the current figures, the source of truth is the official Vertex AI pricing page. Pull the rate for your region, multiply by your inputs, and you have a defensible estimate.
The single most important habit: estimate the always-on parts separately from the usage-based parts. The always-on parts bill whether or not anyone uses them, and at low traffic they usually dominate.
1. Prediction endpoints (the cost that bills while you sleep)
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. Billing is per node-hour, scaled by the machine type and multiplied by the number of nodes (replicas). Autoscaling rarely goes to zero for a standard online endpoint, because a minimum replica count holds capacity ready for low-latency responses.
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.
Your input:
- Number of online endpoints (include every forgotten test deployment): __
- Replicas per endpoint: __
- Machine type per endpoint (and any attached GPU): __
- Hours deployed per month (730 = always-on for the whole month): __
- Rough monthly subtotal (replicas x hours x node-hour rate, summed across endpoints): __
This is usually the biggest line at low traffic. List every endpoint, especially the one a data scientist spun up to test an integration and nobody tore down.
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, but accelerator rates are high, so a long run on GPU or TPU is often the biggest single-event cost on the platform.
Your input:
- Training jobs per month: __
- Average hours per job: __
- Hardware per job (CPU / GPU / TPU and machine size): __
- Rough monthly subtotal (jobs x hours x hardware rate): __
3. Model Garden and generative models (it depends which model)
Model Garden is not one price because it is not one kind of model:
- Google’s own generative models (Gemini family) bill per million input and output tokens. Rates differ by model and change over time.
- Third-party partner models bill 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. That is the same trap as driver 1, so count a self-deployed open model under endpoints, not here.
Your input:
- Model family or models in use: __
- Input tokens per month: __
- Output tokens per month: __
- Any self-deployed open-weight models? If yes, add their node-hours to driver 1: __
- Rough monthly subtotal (token volume x per-token rate): __
Token cost scales linearly with traffic. It is small at low volume and dominant at high volume, which is the opposite of the always-on endpoint.
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.
Your input:
- Batch jobs per month: __
- Node-hours per job: __
- Rough monthly subtotal (jobs x node-hours x rate): __
If any of your driver-1 endpoints exist only to score data on a schedule, ask whether a batch job would do the same work for less.
5. Supporting services (the gap between estimate and invoice)
Feature Store, Vertex AI Pipelines, model and artifact storage, and network egress are each metered on their own. None is large on its own at small scale, but together they are 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.
Your input:
- Feature Store usage: __
- Pipelines runs per month: __
- Storage (artifacts, datasets): __
- Cross-region or out-of-GCP egress: __
- Rough monthly subtotal: __
Spot the overspend
Before you trust the total, run this checklist. Each item is a cost that is easy to leave running with nothing to show for it:
- A forgotten test endpoint still billing node-hours (driver 1).
- A self-deployed open-weight model left deployed after the experiment ended.
- Cross-region egress you did not budget for (driver 5).
- A steady, predictable workload with no committed-use discount applied: for stable usage, Google Cloud committed-use discounts often move the effective rate more than any per-unit list price.
- An always-on online endpoint doing work that a scheduled batch job could do for less (driver 4).
Your monthly estimate
Add the five subtotals. Then split the total into two buckets:
- Fixed (bills whether used or not): always-on endpoints, any self-deployed open models, baseline storage.
- Usage-based (scales with traffic): tokens, training runs, batch jobs, egress.
The split is the real insight. At low traffic the fixed bucket dominates, so your cost per request is high; double the traffic and the fixed bucket stays flat while the usage bucket grows, so cost per request falls. That is why “how much does Vertex AI cost” has no single answer, and why the estimate is only as good as your traffic assumption.
If you want a second pair of eyes on the estimate, or you are seeing a Vertex AI bill grow in a place you cannot explain, our team can help you model the real cost before rollout and find the overspend after it. Start with our Google Cloud consulting, or if the question is cost control across the whole platform, our FinOps work.