“Is this model available in West Europe” is three questions in a trench coat, and the answer to one of them is regularly different from the answer to the other two.
Three separate availability questions
Separate these before consulting any table, because a table that answers one will look like it answers all three.
- Is the model offered in the region at all? This is the region-availability table Microsoft publishes per model, and it is pivoted by deployment type — a model can be present for Global Standard and absent for Standard in the same region.
- Is the specific version offered? Region availability is per model version. A region can have a model at an older version while the newest one is still rolling out.
- Do you have quota and capacity there? Entirely independent of the first two, and subscription-specific. Microsoft is explicit that quota is a policy limit while capacity is the physical serving capability, and that having the first does not guarantee the second.
Nearly every “the docs say it is available but I cannot deploy it” report resolves to the third question. The table is right; your subscription is out of quota, or the region is out of capacity this afternoon.
Why regions diverge
The mechanism is unglamorous and it explains the pattern well. A model version is a specific set of weights that has to be provisioned onto specific accelerator hardware in a specific datacentre. That hardware is finite, unevenly distributed between regions, and already committed to serving the previous version’s traffic. Rolling a new version into a region is therefore a capacity operation, not a configuration change, and it happens region by region as capacity frees up.
Deployment type is the lever that exists because of this. A Global Standard deployment routes requests across Azure’s global fleet rather than pinning them to the region the resource lives in, which is why Microsoft describes it as offering the highest default quota and as removing the need to load-balance across resources. The trade is residency: your tokens may be processed outside the deployment’s region. Data Zone Standard is the middle position, keeping processing within a Microsoft-defined zone such as US or EU.
So a model missing from Standard in your region is often present via Data Zone or Global, and the decision is a compliance one rather than an engineering one. Read it that way round.
Versions move under you
A deployment pins a model version, and what happens at that version’s end of life depends on an upgrade policy set on the deployment. Microsoft documents that a chosen version stays selected until you update it manually or the model reaches its retirement date, at which point the deployment is automatically upgraded to whatever the default version is then.
That is a real behaviour with a real consequence: a deployment you have not touched in a year can change model version without any action from you. The auto-update-to-default policy makes this happen sooner, at each new default rather than at retirement. Neither is wrong, but only one of them is what people assume “I pinned the version” means.
Microsoft also notes that regional gaps do not block this. If the new default version is not yet present in a region holding deployments due for upgrade, Azure rolls that version into the region as part of the upgrade process. Availability tables therefore trail reality during an upgrade window.
Every specific model, version and region combination is omitted from this page on purpose. Those tables change weekly, and a stale list here would be worse than no list. Read Microsoft’s model retirements page for dates and the region availability tables for the current matrix.
Checking it for your subscription
The published tables answer the general question. For the one that actually blocks you, ask the control plane. The Model Capacities API takes a model name, version and format and returns available capacity across every location and deployment type in your subscription at once:
az rest --method get --url \
"https://management.azure.com/subscriptions/$SUB_ID/providers/Microsoft.CognitiveServices/modelCapacities?api-version=2024-10-01&modelFormat=OpenAI&modelName=gpt-4o&modelVersion=2024-08-06"
Each entry gives a location, a properties.skuName and properties.availableCapacity. This is the correct pre-flight check before a scale-up or a regional migration, and it is the only one that accounts for both quota and current capacity together.
One caveat Microsoft states directly: both this API and the Foundry portal still return information for retired models that can no longer be deployed. A healthy-looking capacity figure for a model past its retirement date is not permission to use it.
There is a second distinction the API cannot answer for you, and it is the one that matters in an audit. A deployment’s region is where the resource lives; it is not necessarily where inference runs. On a Global Standard deployment those are different by design, and the region in your resource ID tells a reviewer nothing about where the tokens were processed. If a data-residency commitment is written down somewhere, the deployment type is the control that satisfies it — Standard for a single region, Data Zone for a geography — and the region field on the resource is not. Record which deployment type each workload uses alongside its region, because the second without the first is not an answer.
Designing around it
- Decide the residency constraint first. It selects the deployment type, and the deployment type determines which availability table applies.
- Pick a primary and a secondary region that both carry the model at the version you want, and confirm both with the capacity API rather than the published table.
- Set the version upgrade policy deliberately on every deployment. The default is not the same as pinned, and discovering that during an incident is expensive.
- Keep the model version out of application code. It belongs in the deployment, which is what makes a version change a deployment change.
Running a primary and a secondary region means two endpoints, two sets of quota and two rate-limit budgets, and something has to decide which one a given request goes to and what happens when the first returns a 429 or a capacity error. That decision is worth putting in one place rather than in every service that calls a model; Multigrid is an LLM gateway that holds it, with per-model routing and fallback behind a single key.
Top comments (0)