cancel
Showing results for 
Search instead for 
Did you mean: 
Machine Learning
Dive into the world of machine learning on the Databricks platform. Explore discussions on algorithms, model training, deployment, and more. Connect with ML enthusiasts and experts.
cancel
Showing results for 
Search instead for 
Did you mean: 

Traffic split behavior when traffic_percentage values across served entities sum to more than 100%

MageshS
New Contributor II

Hi all,

I'm configuring a Model Serving endpoint with two served entities and ran into some unexpected behavior while testing different traffic_config splits.

When I set traffic_percentage to 100 for each of the two served entities (so the total sums to 200%, not 100%), the configuration is accepted and saves successfully — both through the Serving UI and the REST API. I expected this to be rejected, since traffic percentages across routes should normally sum to 100.

Config used:

 
json
"traffic_config": {
  "routes": [
    { "served_model_name": "model-A", "traffic_percentage": 100 },
    { "served_model_name": "model-B", "traffic_percentage": 100 }
  ]
}

What I'm trying to understand:

  • Is there backend validation that should reject a traffic_config where the values don't sum to 100? If so, why does this particular config get accepted?
  • If it is accepted, how does routing actually work here — are the values treated as relative weights and normalized (e.g., 100/100 effectively becomes 50/50), or is there some other fallback logic?
  • Is this documented anywhere, or is it more of an edge case / bug that hasn't been addressed?

I ran a batch of test requests afterward and saw roughly a 50/50 split across the two entities, which lines up with the "weights get normalized" theory — but I'd rather get confirmation from someone who knows the internal routing logic than rely purely on my own testing.

Environment: AWS Databricks 

1 ACCEPTED SOLUTION

Accepted Solutions

emma_s
Databricks Employee
Databricks Employee

Hi,

 

Just been looking into this for you. All the docs I found suggested it would reject to I tried testing it myself. I tried setting traffic_config with various percentage combinations that don't sum to 100, on both Azure and AWS:

Config (A / B)

Sum

Result

75 / 25

100

Accepted (valid baseline)

100 / 100

200

Rejected

150 / 50

200

Rejected

60 / 20

80

Rejected

200 / 50

250

Rejected

90 / 30

120

Rejected

In my case, every non-100% configuration was rejected with a validation error on both clouds. So I wasn't able to reproduce what you're describing.

What the docs say

The docs are consistent with what I saw:

A few thoughts on why yours might have been accepted

I don't doubt you saw it work, but here are some things worth checking:

  • Check what the API actually persisted. Use GET /api/2.0/serving-endpoints/{name} and look at the traffic_config in the response. It's possible the UI normalised the values before saving them (so it might show 50/50 even though you entered 100/100).
  • It could be a timing thing. If you tested this a while back, validation may have been tightened since then. The current API (as of July 2026) rejects it consistently for me.
  • If it genuinely is still being accepted in your environment, that sounds like a bug worth reporting. I'd suggest filing a support ticket with the workspace ID, endpoint name, and the exact config you used. That way the engineering team can check whether there's a validation gap specific to your region or workspace.

On the 50/50 routing question

Your observation of a 50/50 split from 100/100 does make sense if the values were being treated as relative weights (100/(100+100) = 50% each). That's a common pattern in load balancers. But since the API is supposed to reject the config outright, the routing behaviour is somewhat academic unless you can still reproduce the acceptance.

If you do manage to reproduce it, an asymmetric test like 150/50 would be the way to confirm whether it's true proportional normalisation (which would give 75/25) or just a fallback to equal distribution (which would give 50/50).

References

Hope that helps!


Thanks,


Emma

View solution in original post

1 REPLY 1

emma_s
Databricks Employee
Databricks Employee

Hi,

 

Just been looking into this for you. All the docs I found suggested it would reject to I tried testing it myself. I tried setting traffic_config with various percentage combinations that don't sum to 100, on both Azure and AWS:

Config (A / B)

Sum

Result

75 / 25

100

Accepted (valid baseline)

100 / 100

200

Rejected

150 / 50

200

Rejected

60 / 20

80

Rejected

200 / 50

250

Rejected

90 / 30

120

Rejected

In my case, every non-100% configuration was rejected with a validation error on both clouds. So I wasn't able to reproduce what you're describing.

What the docs say

The docs are consistent with what I saw:

A few thoughts on why yours might have been accepted

I don't doubt you saw it work, but here are some things worth checking:

  • Check what the API actually persisted. Use GET /api/2.0/serving-endpoints/{name} and look at the traffic_config in the response. It's possible the UI normalised the values before saving them (so it might show 50/50 even though you entered 100/100).
  • It could be a timing thing. If you tested this a while back, validation may have been tightened since then. The current API (as of July 2026) rejects it consistently for me.
  • If it genuinely is still being accepted in your environment, that sounds like a bug worth reporting. I'd suggest filing a support ticket with the workspace ID, endpoint name, and the exact config you used. That way the engineering team can check whether there's a validation gap specific to your region or workspace.

On the 50/50 routing question

Your observation of a 50/50 split from 100/100 does make sense if the values were being treated as relative weights (100/(100+100) = 50% each). That's a common pattern in load balancers. But since the API is supposed to reject the config outright, the routing behaviour is somewhat academic unless you can still reproduce the acceptance.

If you do manage to reproduce it, an asymmetric test like 150/50 would be the way to confirm whether it's true proportional normalisation (which would give 75/25) or just a fallback to equal distribution (which would give 50/50).

References

Hope that helps!


Thanks,


Emma