Research-backed calculator guide

Vertex AI Provisioned Throughput Cost: GSUs, Spillover and Pay-As-You-Go

Learn how Vertex AI Provisioned Throughput cost is built from GSUs, commitment terms, utilization, and spillover, with a worked monthly estimate and practical sizing method.

What you are actually buying

Provisioned Throughput is capacity for a selected model and location. The overview says that you specify both when reserving throughput, and it positions the product for production applications that need predictable performance or deterministic fixed charges. ^[1] “Deterministic” does not mean every request is free after the reservation. It means the reserved portion has a known commitment price; the treatment of requests beyond that portion is a separate design decision.

A GSU is not a universal token unit that can be moved freely between models or regions. Google’s pricing page points to model-specific throughput and an online estimator, while the product documentation explains that throughput depends on the model. ^[3] In a sizing exercise, begin with the exact deployed model, location, modality, and request shape. A text-only baseline cannot safely size an audio or video workload, and a global endpoint assumption cannot automatically be applied to a non-global endpoint.

The commitment term also matters. The pricing page currently lists one-week, one-month, three-month, and one-year choices for the displayed Provisioned Throughput table, with different global and non-global prices. ^[3] On the page checked on 2026-11-02, the global table displayed $7.14 for a one-week commitment, $3.698630137 for one month, $3.287671233 for three months, and $2.739726027 for one year in the hourly view. The page’s own example expresses the same choices as approximately $1,200 per GSU per week, $2,700 per GSU per month, $2,400 per GSU per month for a three-month term, and $2,000 per GSU per month for a one-year term. Treat those as time-stamped vendor-listed figures, not timeless rates.

A practical Vertex AI GSU pricing formula

Use this worksheet before opening a purchase request:

required GSUs = ceiling(sustained adjusted tokens per second / throughput per GSU)
reservation cost for a term = purchased GSUs × price per GSU for that term
utilized-capacity cost = reservation cost / (purchased GSUs × hours in term × utilization fraction)
spillover cost = PAYG units outside PT × applicable PAYG price
estimated total = reservation cost + spillover cost

“Adjusted tokens” is important. Google’s example converts different modalities into burndown-adjusted tokens before dividing by the per-GSU throughput. For its Gemini 2.0 Flash illustration, 1,000 input text tokens, 500 input audio tokens, and 300 output text tokens at 10 QPS become 57,000 adjusted tokens per second. Dividing by 3,360 adjusted tokens per second per GSU gives 16.96, which rounds up to 17 GSUs. ^[3]

Use a ceiling, not a nearest-integer round. If the result is 16.01 GSUs and the model’s purchase increment is one GSU, buying 16 leaves a measured capacity gap. If the workload is bursty, do not hide the peak inside an arbitrary multiplier. Record the percentile or business event that the reservation is meant to cover, then model what happens to the remainder.

Worked cost example: 17 GSUs, utilization, and spillover

Consider the same 17-GSU workload from Google’s pricing illustration. Assume the following for a transparent planning model:

• The selected model and endpoint match the pricing example.
• A one-month global commitment is used.
• The reservation price is the page’s illustrative $2,700 per GSU per month.
• The month is approximated as 730 hours only when calculating an effective hourly rate.
• No taxes, negotiated discounts, credits, support fees, currency conversion, or unrelated Google Cloud services are included.

The $45,900 figure is a reservation estimate based on the vendor’s published example. The 60% and 90% rows are original analysis: they show why the same invoice produces different economics depending on how consistently the application consumes the reserved capacity. Neither row says that Google bills “unused GSUs” as a separate line; it is an effective-cost lens for capacity planning.

The spillover row deliberately leaves r as a variable. PAYG pricing is model- and modality-specific, and a generic Vertex token price should not be substituted without matching the exact model, endpoint, and units. If you know the applicable PAYG rate, insert it and recompute. If you do not, report a range or omit the total rather than inventing a quote.

How spillover and request headers change the bill

The default behavior is the most important billing trap. Google’s usage documentation says that when a request exceeds the remaining Provisioned Throughput quota, the entire request is processed as on-demand and billed at the pay-as-you-go rate; monitoring surfaces this as spillover. ^[2] A request can therefore be large enough to push the whole request outside the reservation even if only part of its estimated demand exceeds the remaining quota.

If cost control is more important than accepting every request, set the X-Vertex-AI-LLM-Request-Type header to dedicated. Requests that exceed the provisioned order return HTTP 429 instead of silently becoming on-demand traffic. ^[2] This creates an explicit reliability-versus-cost choice: your application needs retry, queue, fallback, or user-facing degradation behavior for the rejected request.

If traffic is experimental or intentionally on-demand, set the same header to shared. That bypasses the Provisioned Throughput order and routes the request to pay-as-you-go. ^[2] Separating development traffic from production reserved capacity prevents tests from consuming the reservation, but it does not make the test traffic free.

The quota is not simply a one-second hard wall. The documentation describes a dynamic enforcement window that varies with model and GSU allocation. It gives examples in which a burst can still count as Provisioned Throughput when the total remains within the applicable window, while a larger burst can exceed the window and fall outside the reservation. ^[2] Model your traffic as a time series or at least as peak windows; average QPS alone can conceal the exact behavior you are trying to price.

Provisioned Throughput versus pay as you go

Choose Provisioned Throughput when a repeatable production baseline, capacity assurance, or predictable performance is worth committing to a term. It is most defensible when the application has a measurable minimum load and the cost of throttling or unpredictable capacity is material.

Choose PAYG when demand is exploratory, highly intermittent, moving between models or regions, or too uncertain to justify a term. PAYG avoids paying for a reservation that sits idle, but it exposes the workload to the provider’s on-demand pricing and capacity behavior. A hybrid is often more realistic: reserve the measured baseline, use dedicated for traffic that must not create an unplanned bill, and route development or flexible work with shared.

For a self-hosted alternative, compare the fully loaded GPU baseline rather than only the cloud token rate. The Self-hosted GPU inference cost calculator can help put GPU rental, utilization, operations, and throughput assumptions beside the reservation estimate. For API alternatives, use the Model pricing comparison to normalize model units before comparing them with a GSU commitment. If your workflow also incurs retrieval and embedding spend, connect the result to the RAG, embedding and vector database cost calculator.

Measurement checklist before committing

Capture at least two weeks of production-like telemetry if the workload permits. Record requests per second, input and output mix, tokens or modality units, p50/p95/p99 bursts, model and region, and the share of traffic that would be classified as dedicated versus shared. Then calculate both a sustained baseline and a peak scenario.

Next, map the scenarios to commercial terms. Show one-month, three-month, and one-year reservation cases if those terms are available for your model. Include the cost of unused reservation at the observed utilization, then add a separate spillover scenario. Do not compare a fixed PT commitment with a PAYG figure that covers different traffic or different endpoint pricing.

Finally, decide what the application should do at quota exhaustion. The cheapest invoice is not necessarily the cheapest production design if a 429 causes lost transactions, manual intervention, or a duplicate retry storm. Document whether the system queues, sheds, falls back, or allows PAYG spillover, and make that policy visible in monitoring.

FAQ

Is Vertex AI Provisioned Throughput billed per token?

The reservation itself is priced by GSU and commitment term, not as a simple per-request token meter. The number of GSUs is derived from model-specific throughput and your request mix. Traffic outside the reservation can then be billed at PAYG rates, so your full bill can contain both a fixed reservation and variable overage components. ^{[1] [2]}

What is the difference between a GSU and a DSU?

The current Google documentation and pricing pages use generative AI scale unit, abbreviated GSU, for Provisioned Throughput. “DSU” appears in some search queries and older or informal discussions, but it should not be silently substituted in a calculation. Confirm the unit name, model, and current estimator for the product version you are purchasing.

Does unused Provisioned Throughput roll over?

Do not assume that it does. Provisioned Throughput is a fixed-term capacity commitment. Your planning model should treat unused capacity as lower utilization and a higher effective cost, not as a bank of tokens that can automatically be carried into a later term. Check the order terms and current product documentation for your exact offer.

How can I prevent spillover from creating a surprise PAYG bill?

Use the dedicated request header when requests that exceed the reservation should fail with a 429 rather than be billed on demand. Add a deliberate queue, retry budget, fallback model, or user-facing error path. If you intentionally want on-demand routing, use shared and monitor it as a separate cost center. ^[2]

Is the one-year term always the cheapest option?

It may have a lower listed monthly-equivalent price per GSU, but that does not make it cheapest for uncertain demand. Compare the term price with expected utilization, the cost of changing models or regions, the risk of peak demand moving, and any spillover. A shorter commitment can have a higher unit price while producing a lower total loss when forecasts are wrong.

Can I use one reservation for every Gemini model and region?

Size and purchase for the model and location supported by the order. Google’s overview says that the model and available location must be specified, and its pricing page directs readers to model-specific throughput information. ^{[1] [3]} Treat a model or region change as a new sizing and commercial check unless the current order documentation explicitly permits the change.