cancel
Showing results forย 
Search instead forย 
Did you mean:ย 
Data Governance
Join discussions on data governance practices, compliance, and security within the Databricks Community. Exchange strategies and insights to ensure data integrity and regulatory compliance.
cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Provisioned Throughput Endpoint accruing cost with 0 requests

nara_shikamaru
New Contributor
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;
nara_shikamaru_1-1782144997020.png

 

-- But zero requests
SELECT COUNT(*) FROM system.serving.endpoint_usage
WHERE served_entity_id = '<served_entity_id>';
nara_shikamaru_2-1782145036669.png

 

 

-- 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.
nara_shikamaru_3-1782145069151.png

 

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?
1 REPLY 1

Louis_Frolio
Databricks Employee
Databricks Employee

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

  1. 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*).
  2. 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.
  3. 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.
  4. 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:

Cheers, Louis.