Deploy and consume LLMs, small models, code models, and multimodal models

Deploying a model is two decisions that people habitually collapse into one: which model, and on what deployment type. The second decides cost profile, data residency, and whether capacity is reserved — and it is chosen independently of the first. Consumption then differs by model family in ways the exam tests directly: reasoning models take different parameters, image models take different sizes, and video models take different constraints.

Why This Matters

Deployment type is a separate axis. The same model can be deployed as Standard, GlobalStandard, DataZoneStandard, or ProvisionedManaged. A requirement about residency or predictable latency is answered on this axis, not by choosing a different model.

Model families do not share a parameter surface. Reasoning models reject the techniques that help everything else and use max_completion_tokens rather than a token cap that excludes their thinking. Getting this wrong produces truncated, empty-looking responses.

Capability tiers move. Image generation, video generation, and preview models each carry constraints — fixed sizes, variant limits, access gating — that are examinable precisely because they are arbitrary and must be learned.

Prerequisites

• What a deployment is: a named, addressable instance of a model on a resource.
• The difference between a Foundry resource and an Azure OpenAI resource — the latter serves only /openai/v1.
• Basic token accounting: prompt tokens, completion tokens, and that both are billed.
• TPM and RPM quota concepts from the quota objective.

Learning Objectives

By the end of this lesson you will be able to:

1. Choose a deployment type from a residency, cost, or capacity requirement.
2. Consume reasoning models correctly, including reasoning_effort and token accounting.
3. Apply the constraints of image and video generation models.
4. Reason about when a small or code-specialised model is the right answer.
5. Recognise which endpoint shape a given resource exposes.

Building Blocks

Deployment types. The skuName values are Standard, GlobalStandard, DataZoneStandard, and ProvisionedManaged.

The one-deployment-per-model limit has been removed, so a single model can be deployed several times — for example the same model on Standard for a residency-bound workload and GlobalStandard for a cheaper batch path.

Reasoning models. These generate internal reasoning tokens before answering. The rules:

• Reasoning tokens are billed as output tokens and are never returned in message content.
• They share the budget set by max_completion_tokens / max_output_tokens — so a small cap can be exhausted entirely by thinking, leaving an apparently empty response. Reserve roughly 25,000 tokens for reasoning when starting out.
• reasoning_effort is a per-request parameter with values none, minimal, low, medium, high, xhigh, max.
• Read completion_tokens_details.reasoning_tokens to see what was actually spent.
• Prompt-engineering techniques "aren't recommended for reasoning models"; chain-of-thought prompting is for non-reasoning models — the reasoning model already does it.

Image generation. gpt-image-2 is GA and supports arbitrary resolutions up to 4K, subject to: each edge a multiple of 16px, long edge ≤3,840px, aspect ratio within 3:1, total pixels between 655,360 and 8,294,400. The gpt-image-1 series is limited access preview with fixed sizes — 1024x1024, 1024x1536, 1536x1024. background: transparent requires PNG output and is gpt-image-1 only. input_fidelity is not available on the mini variant.

Video generation. Sora 2 supports text-to-video, image-to-video, and video-to-video where the input video was generated, plus remix. n_variants accepts 1–4, but is disabled at 1080p and capped at 2 at 720p. n_seconds is 5–20. Terminal job states are succeeded, failed, cancelled. It generates audio, and blocks intellectual property and photorealistic depictions of real people.

Deep Dive

Reading a deployment-type question

Almost every deployment-type item hides its answer in one clause.

"Data must be processed within the region" → Standard. "Within the European geography" or "our data zone" → DataZoneStandard, which relaxes region to geography and usually buys better availability. "Minimise cost" or "maximise availability" with no residency clause → GlobalStandard. "Consistent latency at steady high volume" or "guaranteed throughput" → ProvisionedManaged, the only type with reserved capacity.

The trap is answering with a model change — a smaller or faster model — when the requirement is about where or how reliably processing happens. Model choice does not move the residency boundary, and a smaller model on shared capacity still has variable latency under load.

Because a model can be deployed more than once, the answer to a mixed requirement is often two deployments: reserved capacity for the interactive path, GlobalStandard for the batch path.

Reasoning models: the empty-response trap

The most instructive failure in this objective is a reasoning model that returns nothing.

The cause is that reasoning tokens share the completion budget. If max_completion_tokens is set to a value tuned for a non-reasoning model, the model can consume the entire allowance thinking and return an empty or truncated message — while still billing for every one of those tokens as output. Reserving around 25,000 tokens for reasoning is the documented starting point.

reasoning_effort is what you turn when the cost or latency is wrong, and it is per request — the same deployment can serve a cheap minimal classification and an expensive high analysis. The full ladder is none, minimal, low, medium, high, xhigh, max.

The second trap is prompting. Prompt-engineering techniques "aren't recommended for reasoning models", and chain-of-thought prompting is explicitly a non-reasoning technique — instructing a reasoning model to "think step by step" duplicates what it already does and can degrade the result. An option that improves a reasoning model's output by adding CoT instructions is wrong by construction.

Image and video: constraints worth memorising

These are arbitrary numbers, which is exactly why they are asked.

For images, the discriminator between the two families is flexibility against availability. gpt-image-2 is GA with arbitrary resolutions to 4K under the edge, aspect, and pixel-count rules. The gpt-image-1 series is limited access preview with three fixed sizes. So a requirement for a non-standard aspect ratio points at gpt-image-2; a requirement for a transparent background points the other way, because background: transparent is gpt-image-1 only and additionally requires PNG output.

For video, n_variants is the memorable one: nominally 1–4, but disabled at 1080p and limited to 2 at 720p — the higher the resolution the fewer the variants, which is the direction people guess wrong. Duration is 5–20 seconds. Video-to-video only accepts a generated input video, so a scenario feeding in real camera footage is describing something unsupported.

Small and code-specialised models

A small language model is chosen for a cost, latency, or footprint reason — high-volume classification, routing, extraction, or an edge or container deployment where a frontier model is not viable. The model catalog exposes these alongside frontier models, and the deployment mechanics are the same.

Code models are chosen for generation, completion, and transformation of source. The examinable distinction is against the Code Interpreter tool: a code model writes code, while the tool executes it in a sandbox. A scenario requiring a computed answer from data needs execution, not a better code model.

Worked Examples

Example 1 — residency plus a cheap batch path. An interactive assistant must process data within the European geography; an overnight batch job has no residency constraint and must be as cheap as possible.

Two deployments of the same model: DataZoneStandard for the interactive path (geography-level residency) and GlobalStandard for the batch path (lowest cost, best availability). The per-model deployment limit was removed, so this is straightforward. Changing model would address neither requirement.

Example 2 — the reasoning model that returns nothing. A team moves a summarisation workload to a reasoning model, keeps its existing token cap, adds "think step by step" to the prompt, and gets empty responses at full cost.

Reasoning tokens are billed as output and share max_completion_tokens — the cap was consumed by reasoning, leaving no room for the message. Raise the cap, reserving about 25,000 tokens, and tune reasoning_effort per request. Remove the chain-of-thought instruction: it is a non-reasoning technique.

Example 3 — product images on a transparent background. Marketing needs generated product shots with transparent backgrounds for compositing, and separately wants a wide banner at an unusual aspect ratio.

Transparency requires background: transparent, which is gpt-image-1 only and needs PNG output — and that family is limited access preview with fixed sizes. The unusual aspect ratio needs gpt-image-2, which is GA and supports arbitrary resolutions to 4K within the edge, aspect, and pixel bounds. The two requirements land on different models.

Visual Explanations

The two independent axes:

Where a reasoning model's budget goes:

Common Mistakes

Answering a residency question with a model change. Residency is a deployment-type axis.

Assuming GlobalStandard is always best. It is cheapest and most available, and wrong under a residency constraint.

Expecting ProvisionedManaged to be about a model's speed. It is about reserved capacity and predictable throughput.

Reusing a non-reasoning token cap on a reasoning model. Reasoning shares the completion budget.

Adding chain-of-thought to a reasoning model. Explicitly a non-reasoning technique.

Treating reasoning_effort as a deployment setting. It is per request.

Assuming transparency works on any image model. background: transparent is gpt-image-1 only and requires PNG.

Guessing that higher video resolution allows more variants. It allows fewer — none at 1080p, two at 720p.

Practice Exercises

1. Map each to a deployment type: strict regional residency; geography-level residency; lowest cost; guaranteed throughput.
2. A reasoning model returns empty messages at full cost. Give the cause and two fixes.
3. Which image model supports transparent backgrounds, what output format is required, and what is its availability status?
4. State the n_variants rule for Sora 2 across resolutions, and the duration range.
5. Why can an existing Azure OpenAI resource not host an agent?

Summary & Concept Map

Deployment is two independent choices. Model answers the capability question — reasoning, code, multimodal, image, video, or a small model chosen for cost and footprint. Deployment type answers residency, cost, and capacity: Standard for a region, DataZoneStandard for a geography, GlobalStandard for cost and availability, ProvisionedManaged for reserved throughput — and a model may be deployed more than once to serve both. Consumption then follows the family: reasoning models bill thinking as output inside max_completion_tokens, take per-request reasoning_effort, and reject chain-of-thought prompting; gpt-image-2 is GA with arbitrary resolutions while transparency is gpt-image-1 with PNG; Sora 2 allows fewer variants at higher resolution and 5–20 seconds. And an Azure OpenAI resource, serving only /openai/v1, cannot host any of the project or agent surface.

Sources and freshness

Written against current Microsoft Learn documentation for the AI-103 skills measured (16 April 2026), reviewed 2026-08-20. Microsoft Learn controls every changing product contract — availability, preview status, quotas, limits, regional support, naming, and retirement dates all move independently of this lesson. Where a scenario turns on a specific number or a GA/preview boundary, confirm it against the product's own page before relying on it.