Models, deployments, and fine-tuning

A model is the engine that turns prompts into answers. A deployment is the named endpoint your app or agent calls to reach one model version with a chosen capacity and billing model. Fine-tuning is optional extra training on your examples when instructions and retrieval no longer close the quality gap. Concept 4 introduced deployment types, keys, and quota; this concept goes deeper on choosing models, keeping them running through retirements, routing traffic across models, and deciding when customization is worth the cost.

Nothing in the catalog runs in production until you deploy it (or, in limited preview cases, use instant access without a deployment). Your deployment name is what production code sends on each request. Model version, region support, deployment type, and lifecycle stage all affect whether that endpoint stays available six months from now.

• Use the Foundry Models catalog to compare capability, price, region, and lifecycle before you commit engineering time.
• Size each deployment against both deployment type rules (where data is processed and how you pay) and subscription quota (shared throughput pools).
• Treat fine-tuning as a measured experiment with evaluation, not a shortcut around good prompts, knowledge, or safety controls.

Open the Microsoft Foundry portal and browse the model catalog. Models are grouped into Foundry Models sold by Azure and Foundry Models from partners and community. That split matters for support expectations, billing, and who publishes retirement dates. Each entry lists versions, supported regions, deployment types, and lifecycle stage labels such as Preview when a model is still experimental.

• Narrow the list by capability you need: chat completion, reasoning, tool calling, embeddings, audio, or industry-specific models.
• Confirm the model version is available in your Foundry project region and supports the deployment type you plan to use.
• Read the provider model card and description in the catalog; you are responsible for lawful use and for understanding documented limits.

Compare candidates in the playground or with benchmarks before you deploy. Concept 8 showed how to score quality with evaluators; reuse those datasets when you swap models so you compare numbers instead of gut feel.

From Discover or Build, select a model, choose Deploy, and pick Default settings unless your organization requires Custom settings. Write down the deployment name; your SDK calls use that name, not the catalog model name. Wait until status shows Succeeded on the Models + endpoints page before you wire production traffic. For serverless API deployments, the deployment type sets where prompts and answers are processed during inference, how you are billed, and what throughput you can expect.

• Stored data stays in your resource geography; live prompt and answer processing follows the deployment type you chose.
• On the Foundry portal Quota page, check the Scope column: Global or Data Zone means subscription-level shared pools for that model version; a region name means per-region quota.
• Not every model supports every deployment type; if deployment fails, pick a supported SKU for that model and region.

Model Router is a single Foundry model deployment that chooses an underlying large language model for each request. You call it like any chat model by passing your router deployment name. By default it uses Balanced routing across the supported model set. You do not deploy most underlying chat models yourself; Model Router invokes them for you. Anthropic Claude models are the exception—you must deploy them from the catalog first if you include them in a custom subset.

• In the model catalog, find model-router, deploy it, and use Custom settings only when you need a subset or non-default routing mode.
• Routing mode or model subset changes can take up to five minutes to apply.
• Benchmark router traffic against a fixed deployment before you move production load; the response includes which underlying model served the request.

Every catalog model sits in a lifecycle stage from preview through retirement. A deployment is pinned to one model version. When that version reaches Retired, inference returns 410 Gone and the deployment stops working, so plan upgrades before the published date. Microsoft publishes overlap windows for generally available replacements so you can test a newer version while the old one still runs. Fine-tuned models follow a separate retirement schedule for training and deployment.

• Pin a version only after evaluation passes, then schedule moves before the retirement date listed on the model retirements schedule.
• Keep a second deployment on the next version and shift traffic after scores match or beat your baseline.
• New models usually appear on Global Standard first; geography-bound types may arrive later as capacity frees up.

Fine-tuning adapts a pretrained model with additional training on your task-specific data by adjusting weights, not by stuffing more examples into every prompt. Microsoft Foundry offers managed fine-tuning (submit data and settings) and interactive training (preview), where you drive a Python training loop on Foundry-managed infrastructure without provisioning GPUs. Benefits are not guaranteed; compare the fine-tuned model to your baseline with held-out evaluation from Concept 8 before you pay for hosting and inference.

Training type (Standard, Data zone, Global, or Developer) decides where the training job runs and how pricing and residency apply. Deployment type decides how you serve the trained artifact afterward—these are separate choices. After training, serverless hosting is the default path; managed compute (preview) and Fireworks on Foundry (preview) offer other serving options with their own deployment type rules.

Example: an online shop wants consistent refund-policy wording. The team first grounds answers with knowledge search and tunes prompts, but evaluators still flag tone drift on long threads. They assemble several hundred supervised examples from approved agent transcripts, run managed SFT with Global training for lower queue cost, deploy to a Global Standard endpoint, and re-run the same evaluation set. Only if scores and cost beat the prompt-only baseline do they promote the fine-tuned deployment to production.

• Choose Standard training when data must stay in the Foundry resource region; choose Data zone when data must stay in the US data zone (the only zone supported today for that training type).
• Use Developer training tier for price-sensitive experiments knowing jobs may be preempted and residency is not guaranteed.
• Confirm the model supports your method, training type, and deployment option in the fine-tuning supported models table before you upload data.
• Interactive training is preview and requires explicit access approval before you create sessions.

• Calling the catalog model name in production instead of the deployment name (unless you deliberately use instant access preview in West US 3 Foundry projects).
• Deploying a model that is Retired or not available in your region, then treating DeploymentModelNotSupported as a transient error.
• Ignoring retirement dates because the playground still works—plan upgrades in the same backlog as product features.
• Fine-tuning on noisy or duplicated data without a held-out test set, then shipping the first checkpoint that looks good on training loss.
• Deploying Claude models into Model Router subsets without deploying those Claude models to the same Foundry account first.

Concept 11 covers agents, identity, workflows, and routines—how a chosen model deployment becomes the base for agents that call tools on behalf of users. Keep deployment names, lifecycle dates, and evaluation baselines documented alongside agent versions so rollouts stay traceable.

• Catalog categories, filters, and model lifecycle overview. What are Foundry Models?
• Lifecycle stages, overlap commitments, and retirement schedules. Foundry Models lifecycle and support policy
• Deploy Model Router, routing modes, subsets, and monitoring. Use model router for Microsoft Foundry
• Training methods, training types, deployment options, and supported models. Fine-tuning in Microsoft Foundry