Louis_Frolio
Databricks Employee
Databricks Employee

‎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.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.