Choosing a Deployment on Azure AI

Part of a series on running AI workflows across model providers — this one is about picking a deployment that fits the task, not the flashiest name in the catalog.

Azure AI's model catalog spans OpenAI's GPT family, Anthropic's Claude models, Meta's Llama models, Mistral, DeepSeek, and others — all deployable inside the same Foundry resource, all callable through the same DNotifier sendAI() pattern. The catalog breadth is genuinely useful, but it also means "which one do I deploy for this task" is a real decision, not a formality.

Start from the task, not the catalog

It's tempting to browse Azure's model catalog and pick whatever looks most capable or most recently released. A better starting point is the opposite direction: define what the task actually needs — reasoning depth, latency tolerance, cost ceiling, whether it needs to handle images or just text — and then look for the smallest, cheapest deployment that clears that bar.

This matters more on Azure than it might on a single-model provider, precisely because the catalog is so broad. Every model family available has a different cost and performance profile, and defaulting to "the biggest name" tends to mean paying for capability a given task doesn't need.

One resource, several model families — the decision is which lane a specific task actually belongs in, not which model sounds most impressive.

Deployment type is its own decision, separate from model choice

Beyond picking a model family, Azure AI adds a second axis this series' other providers mostly don't have as explicitly: deployment type. Standard, Global Standard, Data Zone Standard, and Provisioned Throughput deployments all behave differently — not just in pricing (covered in the next article) but in things like regional data residency, auto-upgrade behavior at model retirement (covered in the previous article), and latency consistency under load.

A task with strict data-residency requirements might need Data Zone Standard regardless of which model family it uses. A latency-sensitive, high-volume production feature might justify Provisioned Throughput even for a mid-tier model. These are genuinely separate decisions from "which model family," and conflating them leads to either overpaying or picking a deployment type that doesn't actually meet a real constraint.

Testing before committing

DNotifier's Prompt Testing Studio works the same way here as with every other provider in this series: point it at multiple deployments — different model families, or the same model family at different tiers — with the same representative prompts, and compare real output quality, latency, and cost before routing production traffic to any one of them.

Testing deployments against real, representative prompts replaces a guess about which model family "should" be enough.

A use case that shows the value of testing rather than assuming

A team building an internal document-summarization tool initially deployed the most capable available model, assuming summarization quality would scale directly with model size. A Prompt Testing Studio comparison against a smaller, cheaper deployment from the same model family showed statistically indistinguishable summary quality for their specific document types — the task simply didn't need the larger model's additional capability. Switching the production deployment to the smaller model cut their per-request cost substantially with no measurable quality change, a decision they wouldn't have made confidently without the side-by-side test.

A practical checklist

Before deploying a new model on Azure for a given task, it's worth working through these in order: what does the task actually require (reasoning depth, multimodal input, context length)? Does it have a hard constraint like data residency that limits deployment type before model choice even enters the picture? Is the expected volume closer to bursty and unpredictable, or sustained and high enough that Provisioned Throughput's economics start to make sense? And finally — has this been tested against a real, representative set of prompts, or is the choice based on which model name is most familiar?

Frequently asked questions

Should every task default to the newest available model?

No — newer often means more capable, but also usually more expensive, and not every task needs the additional capability. Test against the task's actual requirements rather than defaulting to newest.

Can different steps in the same DNotifier workflow use different Azure deployments?

Yes — since each step's model value in sendAI() can point to a different deployment, a single workflow can mix a lightweight deployment for simple steps with a more capable one for complex reasoning steps.

Does deployment type (Standard vs. Provisioned) affect which models are available?

Provisioned Throughput minimums and availability can vary by model and region — check Azure's current catalog for a specific model before assuming every deployment type is available everywhere.

Is it wasteful to test multiple deployments before committing to one?

Not meaningfully — a Prompt Testing Studio comparison takes minutes and typically saves considerably more than that in avoided over-provisioning once a task is live in production.

The Bottom Line

Next in this series: what these deployment choices actually cost, and when Azure's Provisioned Throughput pricing model is worth the commitment.

Read part six: Azure OpenAI Pricing: PAYG vs. PTU. Explore dnotifier.com.