Choosing a Model in Foundry Models

The catalogue is where a solution starts

Microsoft Foundry does not hand you one model and ask you to make it fit. It hands you a catalogue — thousands of models, growing by roughly fifty new ones a month — and expects you to narrow it down. For AI-901, that narrowing is the skill being tested. Questions in this area seldom ask which model is best in the abstract. They describe a situation and ask which properties of a model actually matter for it.

The first filter is the kind of model. Foundation models are the large, general-purpose ones. Reasoning models are built to work a problem through in steps. Small language models trade breadth for a smaller footprint. Multimodal models take more than text — images alongside a prompt, for instance. Domain-specific and industry models are shaped for a field such as health, retail or manufacturing. The providers behind them include Microsoft itself, Azure OpenAI, Anthropic, Meta, Mistral, Cohere, DeepSeek, NVIDIA and Hugging Face.

Two collections, and why the split matters

The catalogue is divided into two collections, and that division carries most of the consequences you need to hold.

Models sold by Azure are hosted and sold by Microsoft under Microsoft's own product terms. Microsoft evaluates them, integrates them closely with the rest of Azure, supports them directly, and backs them with enterprise service level agreements. They pass an internal review against Microsoft's Responsible AI standards, and they arrive with documentation and transparency reports describing risks, mitigations and limitations. Some of them share provisioned capacity, so reserved throughput can be moved between them. Billing runs through Azure meters.

Models from partners and community make up the large majority of the catalogue. Third-party organisations, research labs and community contributors publish them. The upside is reach and speed. The trade-off is that the provider, not Microsoft, validates and supports the model, defines the licence terms, sets the price and decides how the model may be deployed at all; billing runs through Azure Marketplace rather than Azure meters.

So the real question inside a scenario is usually this: does the organisation need a guaranteed support path and a contractual SLA, or does it need a niche capability that only a specialist provider ships? That is the axis the answer turns on.

The filters are the decision axes

The catalogue's filters look like a search convenience, but each one encodes a genuine constraint you should be able to reason about.

Collection tells you which of the two groups a model belongs to. Region tells you whether it can be deployed where the workload must run. Deployment options tell you whether it is offered through a serverless API or on managed compute — a model that supports only one cannot be forced into the other — and deployment SKU narrows that to the specific serverless deployment types available. Lifecycle marks preview, generally available or deprecated, which is the difference between something you can put in production and something you cannot. Industry surfaces models trained on a sector's data, supported features covers behaviours such as reasoning or tool calling, and inference tasks covers what the model is for: chat completion, embeddings, audio generation and so on.

Work through those in order and a vague requirement usually collapses to a small handful of candidates.

Reading a model card, then comparing

Each model has a card. Quick facts give the summary; a details section carries the description, version information and supported data types; a deployments section lists what already exists; a benchmarks section shows performance metrics where they exist; and a licence section carries the legal terms.

Beyond the card, the catalogue offers a leaderboard and a side-by-side comparison view, so models can be weighed against each other rather than judged individually. The point Foundry keeps making is that comparison should use realistic tasks and your own data, not published scores alone. Some models can also be fine-tuned on data you supply.

Models do not stay still

Model choice is not permanent. When a newer version or a stronger sibling in the same family arrives, older models can be retired from the catalogue. Some models let you opt into automatic updates; others require a deliberate move. Treat retirement schedules as part of the design, because a model that disappears takes a production feature with it.

Where responsibility sits

Selection carries obligations. You are responsible for complying with the law in how you use a model, reading the model card and the provider's documentation, picking something appropriate to the use case, and adding safeguards — Azure AI Content Safety among them — so the system stays within Microsoft's acceptable use terms. Models from providers other than Microsoft are governed by the terms shipped with them.

What to watch for

Availability has two halves that are easy to conflate: pay-per-token billing depends on the country or region of your Azure billing account, while deployment depends on your project resource sitting in a region where the model is actually offered. Both must line up. And remember that a model's collection determines its support and billing path, not its quality — plenty of excellent models sit on the partner and community side.