Plan and manage an Azure AI solution 1.2 Set up AI solutions in Foundry
A gpt-4.1 Global Provisioned deployment serves two workloads.
Study guide skill: Configure model and agent deployments
Question B4-007
A gpt-4.1 Global Provisioned deployment serves two workloads. Only checkout requests should overflow to a matching standard deployment in the same resource when the provisioned capacity can't serve them; reporting requests must never spill over. How should you configure spillover?
Select one answer.
Answer: B
Setting spilloverDeploymentName on the provisioned deployment enables spillover for all requests on that deployment, while the x-ms-spillover-deployment header enables it per request; if a request doesn't set the header, spillover isn't initiated. When both the property and the header are used, the system defaults to the setting of the deployment property, so to spill over only some requests, leave the property unset and send the header only on those requests. The spillover target must be a standard deployment in the same Foundry resource, and spillover is configured on the provisioned deployment.
Deep dive
How it works
Spillover routes overage requests from a provisioned deployment to a standard deployment when the provisioned deployment returns non-200 responses (such as a 429 when PTUs are exhausted). You can turn it on in two ways:
- For all requests: set the deployment property spilloverDeploymentName on the provisioned deployment, naming the standard deployment target.
- Per request: send the x-ms-spillover-deployment request header, naming the standard deployment target. If the header isn't set on a request, spillover isn't initiated for it.
Here only checkout traffic may overflow. Setting the deployment property would enable spillover for every request on that deployment, reporting included. A Note on the page settles the mixed case: if both the property and the header are used, the system defaults to the setting of the deployment property. So leave spilloverDeploymentName unset and add the header only to checkout calls, which is exactly what the Note recommends for per-request-only spillover. Microsoft describes the header approach as giving you the flexibility to control when spillover should or should not happen for a given workload.
Either way, the target must be a standard deployment in the same resource as the provisioned one. Monitoring is per deployment: split Azure Monitor request metrics to see how many requests each deployment served.
The other options, and when you'd use them
- Configure spillover on the standard deployment: Spillover is set on the provisioned deployment and points to a standard deployment, not the reverse.
- Set spilloverDeploymentName and omit the header for reporting: The deployment property enables spillover for all requests on that deployment, so reporting requests could spill over too.
- A standard deployment in a different resource: The target must be in the same resource as the provisioned deployment.
Exam tip
Some requests = header only. All requests = spilloverDeploymentName. The target is always a standard deployment in the same resource.
References
Last reviewed: