Provisioned Throughput Endpoint accruing cost with 0 requests

nara_shikamaru — Mon, 22 Jun 2026 16:21:00 GMT

I have a Foundation Model provisioned throughput endpoint with 50 provisioned model units. It is READY but has received zero inference requests. Yet system.billing.usage shows DBUs accruing continuously from creation.

-- Cost is accruing

WITH usage_agg AS (

SELECT usage_date, sku_name, usage_unit,

SUM(usage_quantity) AS total_dbus

FROM system.billing.usage

WHERE workspace_id = '<workspace_id>'

AND usage_metadata.endpoint_id = '<endpoint_id>'

GROUP BY 1, 2, 3

prices AS (

SELECT sku_name, usage_unit,

pricing.effective_list.default AS price_per_dbu

FROM system.billing.list_prices

WHERE price_end_time IS NULL

)

SELECT u.usage_date, ROUND(u.total_dbus, 4) AS total_dbus,

ROUND(u.total_dbus * p.price_per_dbu, 4) AS cost_usd

FROM usage_agg u

LEFT JOIN prices p ON u.sku_name = p.sku_name AND u.usage_unit = p.usage_unit

ORDER BY 1;

-- But zero requests

SELECT COUNT(*) FROM system.serving.endpoint_usage

WHERE served_entity_id = '<served_entity_id>';

-- Reserved capacity not visible in system tables

SELECT endpoint_name,

foundation_model_config.min_provisioned_throughput,

foundation_model_config.max_provisioned_throughput

FROM system.serving.served_entities

WHERE endpoint_id = '<endpoint_id>';

Both fields return null, even though the endpoint is actively provisioned and billing.

Looks like (not sure) it is costing for the minimum tokens (reserved capacity). Where in system tables can I find the reserved capacity (provisioned model units or DBU rate) for a foundation model PT endpoint? How can we attribute it to usage and billing? Any supporting documentation or materials?

Re: Provisioned Throughput Endpoint accruing cost with 0 requests

Louis_Frolio — Thu, 25 Jun 2026 13:28:36 GMT

Hello @nara_shikamaru , I did some digging and here is what I found.

Short answer first: what you're seeing is expected behavior for Provisioned Throughput (PT), not a billing bug.

Let me walk through why, because the two queries you ran measure different things, and that mismatch is the root of the confusion.

How PT billing works

PT gives you dedicated, reserved inference capacity. For newer foundation models, you buy that capacity in model units (PMUs). In your case, that's 50 units. You're billed a DBU/hour rate for the reservation the entire time the endpoint sits in READY, whether or not a single request arrives. Foundation Model Serving prices PT as capacity units in DBU/hour, so it's a reservation charge. Once you see it that way, continuous DBUs with zero traffic is internally consistent.

Why your two queries disagree

They answer different questions:

system.billing.usage is the source of truth for billed DBUs and cost. It reflects the reserved capacity.
system.serving.endpoint_usage records per-request token activity only. Zero rows means zero traffic, not zero cost. It does not represent reserved idle capacity.

So for any interval where billing exists but endpoint_usage is empty, treat that spend as idle reserved PT capacity, not request-driven usage.

On the null min/max values

Don't read the nulls in foundation_model_config.min_provisioned_throughput and max_provisioned_throughput as "no reservation." Those fields are throughput-band (tokens/sec) metadata from the legacy PT model. Newer PT is configured in model units, and the public system.serving.served_entities schema does not document a provisioned_model_units field, even though the PT endpoint config does expose model units (through the Serving API, the UI, and the Terraform databricks_model_serving_provisioned_throughput resource). Today there's no reliable system-table field that surfaces the reserved PMUs directly.

The pattern I'd recommend

For billed cost, use system.billing.usage filtered on usage_metadata.endpoint_id or endpoint_name. Your query is correct here. For attribution, add custom tags to the endpoint. They propagate to system.billing.usage.custom_tags, which you can break out with EXPLODE(custom_tags). Watch the SKU pattern (*_SERVERLESS_REAL_TIME_INFERENCE*).
For request and token attribution, use system.serving.endpoint_usage, but only when traffic exists. Don't expect it to reconcile against billing for PT.
For configured PMUs, read from the Serving REST API (GET /api/2.0/serving-endpoints/{name}) or the UI Edit page, not the system tables.
To get the effective hourly reservation rate, take total DBUs for a full day, divide by 24, and multiply by the rate in system.billing.list_prices.

How to stop the accrual

A READY PT endpoint with a non-zero minimum bills around the clock by design. To stop it, enable scale-to-zero where it's supported, lower the minimum capacity, or delete or downsize the endpoint.

Takeaway: the billing isn't wrong. You're paying for reserved capacity sitting idle, and the two system tables you compared were never meant to reconcile for PT.

Reference docs:

Provisioned throughput Foundation Model APIs: https://docs.databricks.com/aws/en/machine-learning/foundation-model-apis/deploy-prov-throughput-foundation-model-apis
Foundation Model APIs model units: https://docs.databricks.com/aws/en/machine-learning/foundation-model-apis/model-units
Attributing costs in Databricks Model Serving: https://community.databricks.com/t5/technical-blog/attributing-costs-in-databricks-model-serving/ba-p/64818

Cheers, Louis.

topic Provisioned Throughput Endpoint accruing cost with 0 requests in Data Governance

Provisioned Throughput Endpoint accruing cost with 0 requests

Re: Provisioned Throughput Endpoint accruing cost with 0 requests