Why model choice is a planning skill
The AI-103 study guide's first bullet under Plan and manage an Azure AI solution is: "Choose an appropriate model for each task, including large language models (LLMs), small language models, multimodal models, and Foundry Tools." The guide is Microsoft's own document and is free on Microsoft Learn. This course is independent of Microsoft and not endorsed by it, and it can't promise you a pass.
Think of it like picking a vehicle. You wouldn't send an articulated lorry to deliver one letter, and you wouldn't send a bicycle to move a house. Models work the same way. The strongest model is often the wrong pick, because cost, latency and data rules count as much as raw capability.
The four options
| Option | What it is | Reach for it when | Trade-off |
|---|---|---|---|
LLM (e.g. gpt-4.1) |
Large general-purpose model | Multistep reasoning, complex instructions, agents planning tool calls | Highest cost per token, slower |
SLM (e.g. Phi-4-mini-instruct, about 3.8B parameters) |
Small language model | High-volume, narrow, latency-sensitive text tasks like classification, routing and short extraction | Weaker on open-ended reasoning |
Multimodal model (e.g. Phi-4-multimodal-instruct: text, vision and speech input) |
Takes more than text as input | The input is an image, a chart, audio or a mix | Usually costs more than text-only models of the same size |
| Foundry Tool (e.g. Azure Translator, Azure Content Understanding) | Prebuilt, task-specific service (formerly Azure AI services) | The task is a well-defined commodity: translation, OCR, field extraction, speech | Less flexible, but predictable output and pricing |
Rule of thumb from production: start with the smallest thing that meets your quality bar. Move up a tier only when evaluation shows you need to.
Walkthrough 1: comparing models in the Foundry portal
The model catalog covers foundation, reasoning, small, multimodal, domain-specific and industry models. It splits them into Foundry Models sold by Azure (Microsoft support, enterprise SLAs) and Foundry Models from partners and community (for example Anthropic and Hugging Face, supported by their providers).
To shortlist models:
- Open Models in the Foundry portal and use the filters. Useful ones include Inference tasks (chat completion, embeddings…), Supported features (reasoning, tool calling), Deployment options, Region, Lifecycle (Preview / Generally available / Deprecated) and Collections.
- Open a model card. Check Quick facts, then the Details tab (description, version, supported data types), Benchmarks, License and Deployments (your existing deployments of that model).
- Select View leaderboard. The model leaderboards rank LLMs and SLMs on quality, safety, cost and throughput. Trade-off charts plot two metrics against each other (for example quality versus cost), and leaderboards by scenario match benchmarks to a use case.
- Select Compare models to see your shortlist side by side.
Gotcha: public benchmarks are a starting filter, not a verdict. Always run your own prompts and data before you commit.
Walkthrough 2: check the deployment types before you fall in love
A model you can't deploy the way you need is the wrong model. All deployment types run the same inference, but billing, scale and data processing differ:
- Global Standard: pay per token. Requests can be processed in any Azure region.
- Data Zone Standard / Data Zone Provisioned: processing stays inside a Microsoft-defined data zone (US, EU or APAC).
- Provisioned types: reserved capacity, giving guaranteed throughput and steadier latency.
- Global Batch / Data Zone Batch: large asynchronous jobs at a 50% discount.
- Developer: a cheap way to evaluate fine-tuned models, with no data residency.
If a scenario says "EU data must stay in the EU", a model that only offers Global Standard drops off your shortlist.
Walkthrough 3: same code, different model
On the v1 API, swapping models means changing the deployment name, so A/B testing an LLM against an SLM costs very little:
from openai import OpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
# Keyless auth: Entra ID token, refreshed automatically
token_provider = get_bearer_token_provider(
DefaultAzureCredential(), "https://ai.azure.com/.default"
)
client = OpenAI(
base_url="https://YOUR-RESOURCE.openai.azure.com/openai/v1/", # note the /openai/v1/ suffix
api_key=token_provider,
)
ticket = "My invoice was charged twice this month."
for deployment in ["gpt-4.1", "gpt-4.1-nano"]: # your deployment names
r = client.responses.create(
model=deployment,
input=f"Classify as billing, technical or other. One word.\n{ticket}",
)
print(deployment, "->", r.output_text)
# gpt-4.1 -> billing
# gpt-4.1-nano -> billing <- same answer, a fraction of the cost and latency
If the small model matches the big one on a few hundred real tickets, ship the small one.
Walkthrough 4: when a Foundry Tool beats prompting
Say you need to translate 40,000 product descriptions into German. You could prompt an LLM. Azure Translator in Foundry Tools is a dedicated neural machine translation service with real-time and batch translation across 100+ languages, plus language detection:
curl -X POST "https://api.cognitive.microsofttranslator.com/translate?api-version=3.0&to=de" \
-H "Ocp-Apim-Subscription-Key: $TRANSLATOR_KEY" \
-H "Ocp-Apim-Subscription-Region: westeurope" \
-H "Content-Type: application/json" \
-d '[{"Text": "Waterproof hiking boots with steel toe cap."}]'
# [{"detectedLanguage":{"language":"en","score":1.0},
# "translations":[{"text":"Wasserdichte Wanderschuhe mit Stahlkappe.","to":"de"}]}]
There's no prompt to maintain, no chatty preambles to strip out, and the output shape is the same every time. In the same way, Azure Content Understanding in Foundry Tools pulls structured content out of documents, images, audio and video, which saves you hand-writing OCR-plus-prompt pipelines.
Pick a Foundry Tool when the task is standard, high-volume and needs a predictable output shape. Pick a general model when the task needs open-ended reasoning, tone or domain judgement that a fixed API can't express.
What the exam asks about this
Expect short scenarios with a hidden constraint. The scenario names a requirement, such as lowest latency, minimise cost, image input, data residency or no custom prompt maintenance, and the right answer is the option that meets that constraint. The most powerful model is a common wrong answer. Know the catalog vocabulary as well: model card tabs, leaderboards, trade-off charts, Compare models and the deployment-type names.
Key takeaways
- LLMs are for complex reasoning, SLMs for cheap, fast, narrow tasks, multimodal models for non-text input, and Foundry Tools for standard commodity tasks.
- Shortlist with catalog filters, inspect model cards, then compare using leaderboards, trade-off charts and Compare models.
- Check the supported deployment types (Global, Data Zone, Provisioned, Batch) early, because residency and throughput needs can rule a model out.
- Benchmarks narrow the field. Your own evaluation decides.
- On the exam, the right answer is whatever meets the scenario's stated constraint, which is often not the biggest model.