﻿# Azure AI Foundry and Microsoft Foundry Models: choosing execution

Distinguish Foundry model categories, deployment modes, project access and complete costs while preserving the familiar Azure AI Foundry search name.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/azure-ai-foundry-models-guide/
Language: en

Azure AI Foundry remains a familiar search name, while official documentation checked on November 1, 2026 uses Microsoft Foundry Models. We preserve both without assuming identical interface changes for every older installation.

Foundry Models supports discovering, evaluating and using models in Azure. Establish the supplier, execution method and applicable conditions rather than choosing from the catalog name alone.

## Distinguish model categories

[Foundry Models overview](https://learn.microsoft.com/en-us/azure/foundry/concepts/foundry-models-overview) separates models sold by Azure from partner and community models. Check support, terms and capabilities for the actual card. Do not treat every catalog entry as the same product.

Preserve source, revision and access method. This links technical decisions to procurement and operating procedures without blending different offers under one brand.

## Select a deployment mode

[Deployment overview](https://learn.microsoft.com/en-us/azure/foundry/concepts/deployments-overview) describes serverless APIs, managed compute and, for supported scenarios, instant access in preview. Verify each path for the model and current documentation.

A team might test quickly and later consider a dedicated resource. The initial trial cost does not estimate the future system. Include preparation, resource mode and ongoing operating duties in that comparison rather than extrapolating directly from a few requests.

## Define project boundaries

Check region, application permissions, networking and required functions. Administrative catalog access and successful production calls are different events. Test as closely as possible to the application's future conditions.

Preserve request format and expected error behavior. Compatible interfaces simplify integration without eliminating checks for tools, streaming and usage. A feature available for one model cannot automatically be expected from the next catalog row.

## Match costs to the task

Define output first: a successful request, document batch or availability period. Show the expense of the chosen execution path. Bring compute-based and API-usage-based alternatives to the same scenario before comparing them.

Keep restrictions beside the financial result. A cheap trial does not solve the task if quality fails or the required configuration is unavailable in the appropriate environment. Preserve that information for the next expansion decision, rather than retaining only the attractive cost figure.

## Implications for GPU owners

We treat Foundry as a cloud model-access and deployment platform. Managed compute does not establish open acceptance of arbitrary independently owned physical GPUs.

Read [the three-cloud comparison](/journal/bedrock-vs-vertex-vs-foundry/) and [the scenario's complete economics](/journal/inference-unit-economics/) for further evaluation.
