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

MageshS — Wed, 29 Jul 2026 10:02:33 GMT

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

Re: Traffic split behavior when traffic_percentage values across served entities sum to more than 10

emma_s — Fri, 31 Jul 2026 16:48:07 GMT

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:

The Model Serving concepts page shows all examples with percentages summing to exactly 100.
The Serve multiple models page demonstrates traffic splits of 50/50 and 60/40.
The AI Gateway traffic splitting docs explicitly state: "Percentages must sum to 100%."

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,