1.2.2. Models as Deployments, Not Endpoints You Build
💡 First Principle: You consume models by deploying a catalog model and calling the platform-provided endpoint — you never train or host the base model yourself. The choices that matter are which model, which version, which deployment type (serverless vs. managed compute), and how much quota. Everything downstream (cost, latency, throughput) flows from those four choices.
The Foundry model catalog holds first-party models (Azure OpenAI in Foundry Models — the GPT-4o / GPT-4.1 / GPT-5 family, embedding models) and partner/open models (Llama, Mistral, and others). Deploying is a configuration act, not an engineering one: you select the model, pick a deployment type, name it, and set quota. From the developer's side, the difference between models is mostly the endpoint name and capabilities; from the planner's side, the deployment-type choice has cost and performance consequences covered in the planning domain.
| Choice | What it controls | When it bites you |
|---|---|---|
| Model | Capability, modality, context window | Picking a text-only model for a vision task |
| Version | Behavior, deprecation timeline | Pinning to a version that gets retired |
| Deployment type | Cost model, throughput, latency | Serverless under sustained heavy load; managed compute for spiky low traffic |
| Quota (TPM) | Requests you can sustain | One app throttling another |
⚠️ Exam Trap: Don't confuse model version with deployment type. Version is which iteration of the model's behavior you pin; deployment type is the hosting/billing mode (serverless pay-per-token vs. managed dedicated compute). A scenario about predictable high-volume latency is a deployment-type question; a scenario about reproducible behavior over time is a version question.
Reflection Question: An app has low, bursty traffic during business hours and near-zero overnight. Which deployment type fits, and what would make you reconsider?
