A model is not an off-the-shelf service. Before Nordlicht Reisen builds a helper, three questions need answering: Which capability does the task need? How is the model deployed, and where is the data processed? And with which settings does it run? The AI-901 exam asks all three. Model choice with C# examples is shown by the AI track (AI track, T1.3), and so are Foundry projects and deployments (AI track, T10.1). This lesson stays with the overview. It runs nothing against Azure; the details come from Microsoft Learn.
The model catalog
Microsoft Foundry ("Foundry") is the platform where you find, compare and deploy models. The model catalog in the Foundry portal is the starting point. According to Learn, it contains more than ten thousand models, in two groups:
- Models sold by Azure (Foundry Models sold by Azure): Microsoft runs and sells them itself, with Microsoft support. These include all Azure OpenAI models and selected models from other providers.
- Models from partners and community: They come from other providers, and those providers remain responsible for support and maintenance. As examples, Learn names Anthropic and open models from the Hugging Face hub.
The catalog offers filters, for example for region, deployment option, lifecycle (preview, generally available, deprecated), supported capabilities such as reasoning or tool calling and the task type (chat, audio, embeddings). Each model has a model card with key facts, benchmarks and license. Learn points out that you are responsible for choosing a suitable model yourself and should read the model descriptions.
Choosing models by capability
| Capability | What the model does | Nordlicht example |
|---|---|---|
| Chat and text | understands instructions and generates text | draft reply to a customer request |
| Reasoning | solves tasks step by step, with more thinking effort | check a travel plan with many conditions |
| Multimodal | accepts text and images | describe an uploaded room photo |
| Embeddings | turns text into lists of numbers so that similarity can be measured | find hotel descriptions that match a question |
| Image generation | generates images from text | motif for a travel catalog |
| Speech and audio | speech to text, text to speech, translation | transcribe a hotline recording |
For the models sold by Azure, Learn lists: chat and reasoning models of the GPT series, embedding models, models for image generation (for example gpt-image-1), audio models for speech recognition, translation and speech output, and a model for video generation. Whether a model accepts images as input is stated on its model card. Names and versions change quickly; read the list on the day of the decision.
Decision for Nordlicht: The helper in customer service needs a chat model, and the deployment is named reise-chat. As the model behind it, Learn names gpt-5-mini, for example. Whether it is available in the desired region and deployment option is open and is checked in the portal before creating it.
The limits of a model are in the model list: the context (how many tokens a model processes per request) and the maximum output. Input, output and, with reasoning, also the reasoning tokens share the space. More input means less room for the answer. The output limit is an upper bound, not a promise.
Deploying: first a deployment, then a call
You use a model through a deployment, a named access point to the model in your Foundry resource. The call names the deployment, not the model identifier. According to Learn, Foundry knows three deployment options:
| Option | In short |
|---|---|
| Serverless API | Microsoft hosts the model; you pay per use, usually per token. Learn calls it the preferred and most capable option. |
| Managed compute (preview) | open and custom models on dedicated GPU capacity, billed by accelerator hours |
| Foundry Local on Azure Local (preview) | suitable models run on your own connected infrastructure |
There is also "instant access" (preview): supported models can be called by name without a deployment. That is not a deployment option.
Deployment types of the serverless API
The type determines where your data is processed, how you pay and how performance and latency behave:
| Type | Processing | In short |
|---|---|---|
| Global Standard | in any Azure region | Learn: starting point for most tasks, latest models first, broadest regions |
| Data Zone Standard | only within a data zone (US, EU or Asia Pacific) | per token, when processing should stay in the zone |
| Standard | within the specified Azure geography | per token, for small volumes |
| Provisioned (global, data zone, regional) | as the respective type | reserved capacity for consistent response times |
| Batch (global, data zone) | as the respective type | large volumes without hurry, target 24 hours |
Not every model supports every type. Availability per model and region is on Learn and in the portal.
Decision for Nordlicht, the data location: Customer data should be processed in the EU where possible. Learn defines the behavior like this: Stored data stays in the chosen Azure geography. Inputs and answers are processed in any region with Global types, only in the data zone with Data Zone types and within the geography with Standard. The EU data zone follows Azure's EU Data Boundary, which according to Learn can also include EFTA countries such as Norway and Switzerland. Microsoft can add regions without advance notice. For Nordlicht this means: Data Zone Standard in an EU region, if the chosen model exists there (open until it is checked in the portal). That is why the case says "where possible". Which geographies exist for the Standard type is open here.
Parameters: setting the behavior
Every request carries settings. The most important ones, as Learn describes them for chat models of the Azure OpenAI interfaces:
| Parameter | Effect |
|---|---|
| System message | instruction that sets the role and limits of the model; see lesson 2.2 |
| temperature | randomness of the selection. Higher values (Learn names 0.8) make the output more random, lower ones (0.2) more focused and predictable. |
| top_p | alternative to temperature, "nucleus sampling": only tokens from the most probable portions count. 0.1 means: the top ten percent of the probability. |
| max_completion_tokens | upper limit for the generated tokens, with reasoning models including the reasoning tokens. The Responses API calls it max_output_tokens. |
| stop | character sequences at which the output ends |
| presence_penalty, frequency_penalty | slow down new topics and repetitions respectively |
| stream | send partial answers continuously instead of at the end |
| seed | attempt to answer the same inputs the same way; according to Learn no guarantee |
Learn advises changing temperature or top_p, not both. The exam uses the parameters with these English names. A customer service that is supposed to answer in a uniform way fits a low value better, ideas for travel destinations a higher one.
Reasoning models are the exception. According to Learn, they often do not support temperature, top_p and the two penalty parameters. Set max_completion_tokens generously, because reasoning tokens and answer count together. Which parameters a model supports is stated on its model card.
Exercise 1
Decide for Nordlicht, each with a one-sentence justification:
- Which capability does the job "record hotline calls as text" need, and which does "find similar hotel descriptions for a customer question" need?
- Which deployment type fits if customer data should stay in the EU data zone and costs arise per use?
- The helper is supposed to phrase answers in a consistent and matter-of-fact way. Which parameter do you lower, and what do you leave alone?
- The chosen model is a reasoning model, and the answers are cut off. What do you check first?
Solution 1
- Calls as text: audio model for speech recognition (see lesson 1.5). Similar hotel descriptions: embeddings, because they make texts comparable by meaning.
- Data Zone Standard in an EU region: processing stays in the zone, and billing is per token. The model's availability there must be checked beforehand.
- Set temperature lower and leave
top_punchanged, because Learn advises changing only one of the two. max_completion_tokens: reasoning tokens and answer share the limit, so it is probably too small.