11.3 Model Versioning and Production Deployment Strategies

Model Versioning and Production Deployment Strategies

Quick Answer: Pin a dated model version in production. Standard SKUs can auto-update (OnceNewDefaultVersionAvailable or OnceCurrentVersionExpired) or refuse (NoAutoUpgrade). Provisioned deployments are not auto-upgraded. Roll out with a second deployment (canary) or an in-place PTU migration. Use spillover from PTU to Standard for overflow. Developer tier is a 24-hour fine-tune eval SKU with no SLA — not production.

Domain 3 asks you to implement model versioning and production deployment strategies. Sections 11.1 and 11.2 chose Serverless versus managed compute and picked a model family. This section decides how that deployment behaves when Microsoft publishes a new snapshot, when you cut traffic, and when PTUs run out.

Two version numbers appear on every call path. The model version is the dated snapshot of weights (gpt-4.1 version 2025-04-14). The API version is the HTTP contract (api-version on REST, or the SDK generation). A new model version does not always require a new API version. Pin both in production configuration; do not treat either as latest in application code.

Also keep family, version, and variant distinct. A family is a generation (GPT-4o, GPT-5). A version is a dated release inside that family. A variant is a size or capability tier (gpt-5-mini, gpt-5-nano). Partner models sometimes publish a new model ID instead of a new date (Meta-Llama-3-70B-Instruct versus Llama-3.3-70B-Instruct). Read the card; do not assume a silent swap.

Pin versus auto-update on Standard SKUs

For Global Standard, Data Zone Standard, and Standard (and Priority Processing, which follows the Standard upgrade path), you set versionUpgradeOption on the deployment:

Azure notifies customers at least two weeks before a new version becomes the default. Auto-upgrades of Standard SKUs roll region by region even if the new version is not yet offered as a standalone SKU in that region. You cannot extend a retirement date.

Production default: pin the dated version and set OnceCurrentVersionExpired or NoAutoUpgrade only if the release train will migrate before retirement. Do not leave a customer-facing copilot on OnceNewDefaultVersionAvailable unless product has accepted silent behavior change.

Lifecycle stages on the card are Preview, GA, Legacy (optional), Deprecated, and Retired. Preview can change weights and schema and is not recommended for production; when Microsoft retires a preview, deployments are force-upgraded or terminated with at least 30 days of notice. GA models sold by Azure typically live 18 months from launch (deprecated to new customers at 12 months; replacement in Global Standard about 90 days before retirement; provisioned replacement about 30 days before). Anthropic, DeepSeek, Fireworks, and Mistral GA models follow a 12-month lifecycle. Retired inference returns 410 Gone. Subscription owners with active deployments get email at least 60 days before a GA retirement; Azure Service Health advisories use the Azure OpenAI Service product name.

Provisioned deployments are not auto-upgraded. You migrate them. Two supported patterns:

• In-place migration. Change the model version or even the model family on the same provisioned deployment name and PTU size. Azure shifts traffic over about 20 to 30 minutes. The deployment shows provisioning state Updating, then Succeeded. Version updates can use the portal; family changes use REST or Azure CLI. Capacity must exist for the target.
• Side-by-side (multi-deployment). Create a second provisioned (or Standard) deployment, shift traffic yourself, watch Azure Monitor until the old deployment shows no requests for 5 to 10 minutes, then delete the old one. This is the canary. You need quota for both deployments during the overlap.

Batch deployments also move side-by-side: deploy the new model, resubmit jobs, retire the old deployment.

Canary, swap, spillover, and Developer

Foundry Serverless deployments do not use the Azure Machine Learning online-endpoint traffic map from Domain 2. You still canary by creating a second deployment:

• Give the candidate a new deployment name and the new model version.
• Point a fraction of application traffic, a preview slot, or an evaluation suite at the candidate. Azure API Management or application configuration can split, but the two deployments must be the same model and version if you fail over or round-robin — mixing versions causes surprising answers.
• Promote by swapping the name your production code calls (or swapping gateway backends). Keep the previous deployment until rollback is no longer needed.
• Delete the old deployment only after metrics are quiet. On PTU SKUs, unused hours still bill until delete.

Spillover is the overflow strategy for provisioned Azure OpenAI deployments. You pair a PTU deployment with a Standard deployment of the same model and version in the same Foundry resource. When the PTU path is full or unhealthy, the service redirects the request:

• HTTP 429 when PTUs are exhausted
• HTTP 400 for some long-context requests that PTU cannot serve (for example GPT-4.1 provisioned context under 128,000 tokens)
• HTTP 500 or 503 server errors

Configure spillover for every request with spilloverDeploymentName on the provisioned deployment, or per request with the x-ms-spillover-deployment header. If both are set, the deployment property wins. Response headers x-ms-spillover-from-deployment, x-ms-deployment-name, and x-ms-spillover-error tell you a spill happened. Spilled tokens bill at Standard input, cache, and output rates; PTU hours do not double-charge those requests. All Azure OpenAI models that support provisioned throughput support spillover. Some other Foundry Models (Azure DeepSeek, Meta Llama) do not currently. Microsoft recommends enabling spillover on global and data zone provisioned deployments so bursts do not surface as user-facing 429s.

Developer (DeveloperTier) is easy to misuse on the exam. It exists so you can evaluate a fine-tuned model cheaply. Properties that make it illegal for production:

• 24-hour lifetime, then automatic deletion
• No SLA
• No data-residency guarantee (processing may use any Azure region)
• Pay-per-token, but that does not make it a cheap Global Standard clone

Put fine-tuned production traffic on Standard, Data Zone, or Provisioned SKUs that support the fine-tuned model. Chapter 16 covers promotion of fine-tuned models; this section only needs you to refuse Developer as a production SKU.

Exam scenario

Checkout chat runs on a Global Provisioned gpt-4.1 deployment pinned to version 2025-04-14. A new default version is two weeks from becoming default. Create a second provisioned or Standard deployment on the new version, run Domain 4 evaluations, and canary a slice of traffic. Keep versionUpgradeOption off auto-default on the live PTU deployment. Enable spillover to a Standard deployment of the same version so Black Friday 429s become Standard tokens instead of failed checkouts. Do not point spillover at a different version. Do not host the canary on Developer.

Common trap

Setting Standard production to auto-update to default and calling that pinning. Pinning is a dated model.version plus OnceCurrentVersionExpired or NoAutoUpgrade. Another trap: failing over from version X to version X+1 inside a load-balancer or spillover pair. A third: expecting provisioned SKUs to auto-upgrade at retirement the way Standard SKUs do — they do not; you migrate. A fourth: using Developer for a week-long staging environment. A fifth: applying Azure Machine Learning traffic percents to Foundry Serverless deployments as if they were managed online endpoints.