Reserved provisioned throughput Foundation Model APIs
This page explains reserved provisioned throughput for Foundation Model APIs and how to create and manage an endpoint that uses it.
What is reserved provisioned throughput?
Reserved provisioned throughput is a capacity option for Databricks Foundation Model APIs. Instead of paying per token as you go, you reserve a fixed pool of model units on a single foundation model for a set term. Databricks backs that pool with dedicated capacity for the length of the reservation.
If your traffic exceeds the reserved pool, the overflow is served automatically on priority pay-per-token and billed accordingly. See Spillover behavior.
Databricks recommends reserved provisioned throughput when you need to power a business-critical application or agent with guaranteed, reliable throughput and latency, and your traffic is predictable.
Supported models
Reserved provisioned throughput is available on supported foundation models. Databricks curates eligibility per model, and the create flow shows only the models that you can reserve.
Reserved provisioned throughput is available for the following models:
Key concepts
Term | What it means |
|---|---|
Model unit | The unit of provisioned capacity. More model units means more guaranteed throughput. Use the model units estimator to size your pool from your expected traffic. |
Reservation | One prepaid grant of model units and a term on an endpoint. An endpoint can hold several reservations at once, each with its own model units and term-end date. |
Term | The length of a reservation: 1 month or 3 months. A longer term carries a lower per-unit rate. |
Coverage | The total model units that your endpoint's active reservations add up to. |
Spillover | Traffic above your coverage. It is served automatically on priority pay-per-token instead of being rejected, bounded by your pay-per-token limits. Spillover is enabled automatically. |
Reserved provisioned throughput compared to pay-per-token
Reserved provisioned throughput and pay-per-token are complementary, not either-or. A reserved provisioned throughput endpoint uses priority pay-per-token automatically for any traffic beyond its reserved pool. The following table shows where each option fits.
Capability | Pay-per-token | Reserved provisioned throughput |
|---|---|---|
Pricing basis | Per token, as used | Reserved capacity, billed for the full term |
Capacity guarantee | Shared pool, best-effort | Dedicated pool, reserved for you |
Latency under load | Can vary with shared demand | Consistent for reserved capacity |
Reservation | None | 1 or 3 months |
Best for | Spiky, internal, or exploratory traffic | External, business-critical applications or agents in production |
How pricing works
Reserved provisioned throughput bills on the capacity you reserve, not on the requests you send. You are billed for the entire reservation for its full term, regardless of whether you use the reserved capacity.
What happens | How it's billed |
|---|---|
Traffic within your reserved capacity | Billed as reserved capacity for the full term. |
Spillover above your reserved capacity | Priority pay-per-token on the overflow only. |
Traffic after a reservation expires | Priority pay-per-token. The endpoint keeps serving, with no reserved pool. |
- A longer term carries a lower per-unit rate than a shorter one.
- When an endpoint holds reservations of different terms at once, each is priced independently at its own rate.
- Specific rates depend on the model and term.
Before you start
Requirement | Detail |
|---|---|
Model permission | You need |
An eligible model | You can create reserved provisioned throughput only on eligible models. See Supported models. |
Create a reserved provisioned throughput endpoint
You create reserved provisioned throughput from the Serving page.
- Go to the Serving page and start creating an endpoint.
- Add a served entity and select an eligible foundation model. When the model supports reserved provisioned throughput, the Reserved provisioned throughput option appears.
- Set your model units. Use the model units estimator to size the pool: enter your expected request shape — the average input and output tokens per request, the number of concurrent requests you expect, and your expected cache hit rate — and the estimator returns the model units you need.
- Pick a reservation term: 1 month or 3 months.
- Create the endpoint. Databricks provisions the dedicated capacity.
An endpoint's capacity type is fixed when you create it. You can't convert an existing endpoint to reserved provisioned throughput later. Create a new reserved provisioned throughput endpoint instead.
View and monitor
The endpoint detail page shows an Active configuration section headed Reserved provisioned throughput that lists your reserved model units and each reservation's term, expiry date, and status. When an endpoint holds multiple stacked reservations, from scale-ups or upgrades, they appear as a list.
The Metrics tab shows the usual serving telemetry, including requests per minute, error count, latency (p50, p90, p95, and p99), token counts, and time-to-first-token, so you can watch usage and decide when to scale.
Scale up capacity
To add capacity, open Edit > Add capacity, enter the number of model units to add, and choose a term. This creates a new reservation stacked on top of your existing ones. It does not modify or interrupt what you already have. The detail page then lists each reservation, expiring on its own schedule.
Expiry
- At expiry, the reserved pool lapses and the endpoint keeps serving on priority pay-per-token. This is a fallback, not an outage.
- To keep reserved capacity after a term ends, create a new reservation before the current one expires. See Scale up capacity.
- Expired reservations stay visible with an Expired badge and are retained, not deleted.
Spillover behavior
Spillover is enabled automatically; there is nothing to configure. When traffic exceeds your reserved capacity, whether from a burst or because a reservation has expired, those requests are automatically served on priority pay-per-token instead of being rejected with a rate-limit error. Your workload keeps running, and you only pay per-token for the overflow. Spillover requests are bounded by pay-per-token rate limits.
Limitations
- You can create one reserved provisioned throughput endpoint per model, per workspace, in the current release.
- Reservations are prepaid and run for their full term. You can't cancel a reservation partway through.
- You can't delete an endpoint that has an active reservation until the reservation ends.
- Users without
MANAGEon the model see read-only views.
For more Foundation Model APIs limits, see Foundation Model APIs limits and quotas.