Provisioned Throughput Endpoint accruing cost with 0 requests
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2026 09:21 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-25-2026 06:28 AM
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.usageis the source of truth for billed DBUs and cost. It reflects the reserved capacity.system.serving.endpoint_usagerecords 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.usagefiltered onusage_metadata.endpoint_idorendpoint_name. Your query is correct here. For attribution, add custom tags to the endpoint. They propagate tosystem.billing.usage.custom_tags, which you can break out withEXPLODE(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-fou...
- 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-...
Cheers, Louis.