Azure AI Foundry Model Catalog: Choosing From 10K+ Models for Enterprise Workloads

Microsoft's official documentation says the Foundry Models catalog now contains over 10,000 models, with roughly 50 new ones published every month. That is not a rounding error — it is the combined weight of Azure OpenAI, Anthropic, DeepSeek, Meta, Mistral, Cohere, xAI, Microsoft's own models, and a very long tail of Hugging Face community models, all sitting behind one catalog.

For enterprises, this flips the problem. Two years ago the question was "can we even get access to a good model on Azure?" Today the question is "how do we evaluate 10,000 options without burning a quarter on experiments?" Model selection has quietly become an architecture discipline: the wrong choice costs you 20x on tokens, the wrong deployment type breaks your data residency story, and the wrong lifecycle choice puts a preview model under a production SLA.

This article is the decision framework I use with clients, grounded in what the catalog actually contains today — verified against the Foundry portal, Microsoft Learn, and the Azure Retail Prices API.

What Is Actually in the Catalog

The catalog is split into two tiers, and understanding the split is the first filtering decision:

Foundry Models sold by Azure — Microsoft hosts, sells, and supports these under Microsoft Product Terms. They are billed through your Azure subscription, covered by Azure SLAs, and include all Azure OpenAI models plus selected models from providers like DeepSeek, Meta, Mistral, Cohere, and xAI. Some support fungible provisioned throughput, meaning your reserved capacity flexes across models.

Foundry Models from partners and community — the vast majority of the catalog. Anthropic's Claude family and hundreds of Hugging Face models live here. The provider maintains the model; Azure provides the integration rails. Support and SLA terms vary by provider.

The Foundry portal's publisher tab gives a sense of the curated lineup right now:

One honest observation: the portal's model browser currently enumerates around 4,000 models, while the "10,000+" figure includes the full Hugging Face hub collection available for managed compute deployment. Both numbers are true; they measure different depths of the same catalog. For most enterprise workloads, the curated few hundred are the realistic shopping list.

Current flagship examples, straight from the portal: gpt-5.6-sol / terra / luna (the newest GPT-5.6 series), claude-opus-5 and claude-sonnet-5 (1M-token context, 128k output), DeepSeek-V4-Pro and V4-Flash, grok-4.1-fast-reasoning, Llama-4-Maverick-17B, Phi-4-reasoning-plus, Kimi K2.7-Code, MiniMax M2.5, and a model-router that dispatches across models for you — a signal of where the platform is heading.

A Working Decision Framework

Step 1: Start From the Task, Not the Brand

The catalog's filters are the right first move: inference task (chat completion, embeddings, image generation, speech, OCR), supported features (reasoning, tool calling), deployment options, region, and lifecycle (Preview / GA / Deprecated). There is also a performance leaderboard and side-by-side model comparison — useful starting points, not verdicts.

Rough mapping I use:

Step 2: Choose the Tier by Operational Appetite

Pick sold by Azure when you need Microsoft support, an Azure SLA, and clean procurement. Pick partners and community when you need a specific capability fast — Anthropic models and the newest open models typically land here first. Note that partner models have billing constraints: pay-as-you-go access depends on your Azure subscription's billing account being in a country where the provider offers the model. CSP subscriptions can't purchase third-party model offers at all (a catalog-wide rule), and Anthropic additionally excludes student, free-trial, and credit-only accounts. That catches procurement teams off guard — check before you build.

Step 3: Pick the Deployment Type — This Is Where Cost and Compliance Are Decided

This is the step most teams skip, and it is the one that bites. Serverless API deployments come in several types, each with a SKU code you will see in the CLI and pricing pages:

Two semantics matter enormously for compliance reviews. Data at rest always stays in the designated Azure geography — but inference processing depends on the type: Global Standard may process requests in any Azure region, Data Zone keeps processing inside the US/EU/APAC zone, and Standard stays in the deployment region. Microsoft's own guidance: start with Global Standard (it launches first, is cheapest, and has the broadest coverage), and move only when residency or throughput demands it. New deployment types arrive in a fixed order — Global first, Data Zone next, single-region last with no guaranteed date.

There are also two non-deployment paths worth knowing. Instant access (preview) lets you call supported models by name with zero deployment — currently preview-only and limited to projects in West US 3, but excellent for evaluation. And managed compute (preview) hosts open-source and custom-weight models on dedicated GPUs — but Microsoft explicitly states this preview has no SLA and is not recommended for production. Plan around that.

Step 4: Model the Real Cost

Here is verified retail pricing from the Azure Retail Prices API (Global Standard where noted, USD per 1M tokens, August 2026):

Now run your actual workload through it. For a service doing 100M tokens per month at a 70/30 input/output split:

• On gpt-5.4: ~$625/month
• On gpt-5.4-mini: ~$188/month
• On DeepSeek-V4-Flash: ~$29/month

That is a 20x+ spread for identical token volume. The point is not "buy the cheapest" — it is that the spread is large enough that selection must be driven by your quality evaluation, not by assumption. And for batch-tolerant workloads, Global Batch halves the price again. Total cost of ownership still includes your evaluation effort, fine-tuning data, and operational overhead — but token math is where most budgets leak.

Deploying From the Catalog: The Actual Commands

Forget older tutorials using az ml online-endpoint — that is the previous-generation Azure ML pattern. Foundry Models deployments use the core Azure CLI (2.60+, no extension needed):

# Create a Foundry (AI services) resource
az cognitiveservices account create \
  -n $accountName -g $resourceGroupName \
  --custom-domain $accountName --location eastus2 \
  --kind AIServices --sku S0

# Discover which models and SKUs are available to you
az cognitiveservices account list-models \
  -n $accountName -g $resourceGroupName \
  | jq '.[] | {name: .name, format: .format, version: .version, sku: .skus[0].name}'

# Deploy a model (Global Standard)
az cognitiveservices account deployment create \
  -n $accountName -g $resourceGroupName \
  --deployment-name Phi-4-mini-instruct \
  --model-name Phi-4-mini-instruct \
  --model-version 1 \
  --model-format Microsoft \
  --sku-capacity 1 \
  --sku-name GlobalStandard

# Verify
az cognitiveservices account deployment show \
  --deployment-name Phi-4-mini-instruct \
  -n $accountName -g $resourceGroupName \
  | jq '.properties.provisioningState'

The same flow works in Bicep via az deployment group create against the AI services deployment template, which is how I deliver it for repeatable environments. Inference then goes through the unified endpoint: https://<resource>.openai.azure.com/openai/v1/, passing your deployment name as the model field.

For instant access prototyping, the new Foundry SDK keeps it clean:

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

project = AIProjectClient(
    endpoint=PROJECT_ENDPOINT,  # https://<resource>.ai.azure.com/api/projects/<project>
    credential=DefaultAzureCredential(),
)
openai = project.get_openai_client()
response = openai.responses.create(model="gpt-5-mini", input="...")

Authentication: use Microsoft Entra ID (keyless) over API keys. For RBAC, Microsoft's current guidance is to use the renamed Foundry roles (Foundry User for inference, Foundry Owner for creating deployments) rather than the older Cognitive Services* roles, and wire the endpoint into your VNet — private networking is supported on serverless deployments.

The Malaysia West Reality Check

This matters to me directly, so I checked it properly. The Azure Retail Prices API currently lists roughly 100 Foundry Models offers purchasable in Malaysia West — and every one of them is Global Standard. The good news: partner and Microsoft-owned models are there, including DeepSeek V4 Flash/Pro, Grok 4.x, Kimi K2.5–K2.7, Mistral Large 3, Llama 3.3/4 Maverick, gpt-oss-120b, Phi-4 family (including reasoning variants), Flux image models, OCR/Document AI, and embeddings.

The honest gap: Azure OpenAI's GPT models show zero presence in Malaysia West in the pricing data. GPT-5.x deployments sit in regions like East US 2, Sweden Central, West Europe, Japan East, Australia East, and Singapore (Southeast Asia). If your workload must run on Azure OpenAI, Singapore is the practical neighbor for Malaysian teams.

One correction worth flagging: MiniMax M2.5 is not purchasable in Malaysia West today (its Data Zone offers live in US/EU regions only), even though it appears in the catalog globally.

The practical guidance for Malaysian enterprises:

1. Global Standard from Malaysia West works for partner models — but remember inference may process in any Azure region. If your regulator asks "where was this prompt processed?", Global Standard's answer is "somewhere in Azure's global network."
2. Data Zone Standard (APAC) is the compliance middle ground — processing stays inside the APAC zone, though you deploy from a region that supports the Data Zone SKU.
3. Single-region Standard deployments are the strict answer, but they arrive last per model and have no guaranteed availability date. Do not promise them to a client without checking current region support.
4. Self-hosting open-weight models (gpt-oss, Llama, Qwen from the community catalog) on your own GPU infrastructure remains the only option that keeps both storage and inference fully in-country — at the cost of owning the serving stack.

Pitfalls I Keep Seeing

1. Benchmark shopping. The catalog's leaderboard measures the vendor's benchmarks, not your documents, your language mix, or your tool-calling patterns. Shortlist from the leaderboard, decide on your own evaluation set.
2. Preview models under production SLAs. Managed compute is preview with no SLA, several frontier models are Preview-labeled, and instant access is preview in one region. Lifecycle is a first-class filter in the catalog for a reason — use it.
3. Ignoring deployment-type semantics. "We deployed in region X" is not a data residency statement if the SKU is Global Standard. Match the SKU to the compliance requirement, not the other way around.
4. Hardcoding one model. The catalog churns — ~50 models a month in, and Azure OpenAI runs a published retirement schedule. Abstract the model behind a deployment name and config, and re-evaluate quarterly.
5. Copying stale deployment tutorials. Anything built on az ml online-endpoint for model catalog work predates the current az cognitiveservices flow. Check the doc date before you trust the snippet.

Key Takeaways

1. 10,000+ models makes selection an architecture decision — filter by task, tier, deployment type, region, and lifecycle before you ever open a playground.
2. The deployment type decides cost and compliance, not just the model. Start Global Standard, escalate to Data Zone or single-region only when requirements demand it.
3. Real pricing shows 20x+ spreads between frontier and economy models on identical token volume — evaluate on your workload, then do the token math.
4. Malaysia West can buy ~100 Global Standard offers today but has no Azure OpenAI GPT presence; Singapore is the nearest Azure OpenAI region for Malaysian teams.
5. Prototype with instant access, productionize with the CLI — and keep models behind deployment names so quarterly re-evaluation doesn't become a rewrite.

Sources: Microsoft Learn — Foundry Models overview, Foundry Models sold by Azure, Models from partners and community, Deployment types, Instant access, Create model deployments (CLI/Bicep); Foundry portal model catalog (accessed August 2026); Azure Retail Prices API (August 2026).