Open the catalog in the Foundry portal and you are looking at more than 1,900 models. Most of the decisions that follow are not about which model you pick. They are about how you deploy it, who sends you the bill, and which rate limit you trip first. Part 3 covered choosing a model. This part is about the two shelves the catalog is split into and the two ways you can put a model into production.

Two model catalogs, one portal

The catalog looks like one long grid of model cards. Underneath, Microsoft splits it into two groups, and the group a model belongs to changes your support story, your billing, and sometimes your legal review. Get this distinction straight before you deploy anything.

Models sold by Azure, which the docs also call Azure Direct models, are hosted and sold by Microsoft under Microsoft Product Terms. Microsoft evaluated them, wrote transparency documentation for them, and stands behind them with enterprise service level agreements. Azure OpenAI models live here. So do a set of partner models that Microsoft resells directly. Some of these share fungible provisioned throughput, meaning a reservation you buy can flex across several of them instead of being pinned to one.

Models from partners and community are the majority of the catalog. Anthropic Claude, the open models from the Hugging Face hub, Mistral, Cohere, Meta Llama, DeepSeek, NVIDIA, xAI, and Stability all sit here. The provider defines the license and sets the price. Microsoft integrates them and, for most, runs the hosting, but support comes from the provider and billing runs through Azure Marketplace. That Marketplace path matters more than it sounds, because it is where the first deployment usually fails.

Managed compute or serverless?

Once you have picked a model, the catalog gives you two ways to run it, and the choice sets your bill, your quota needs, and your ceiling on control. A serverless deployment provisions an API to a model that Microsoft hosts. You send tokens, you get tokens back, and you pay per token. No virtual machine, no GPU quota from your subscription, no patching. This is what people mean when they say Models-as-a-Service.

Managed compute is the other path. The model weights land on dedicated virtual machines in your workspace, and you pay for the virtual machine core hours whether the endpoint is busy or idle. You need GPU quota in your subscription for the specific machine family, and for open models like the Hugging Face hub set you need a hub-based project in the classic portal. You get more control: the machine is yours, the latency is predictable, and nothing leaves for a shared multi-tenant endpoint. You also get the whole operational bill that comes with owning a box.

Here is the part the marketing pages skip. The model provider decides which paths a model supports. Some models are serverless only. Some are managed compute only. Some offer both. So the real sequence is: pick the model, then check the deployment options on its model card, then design around what it actually allows. You do not get to demand managed compute for a model the provider only ships as serverless.

Source: Microsoft Foundry Models overview, deployment options section.

What Models-as-a-Service bills you for

Serverless charges on tokens for inference and on data for fine-tuning. That is the whole meter for a Standard deployment. No VM, no reservation, nothing while the endpoint sits quiet. The catch is who processes the payment, and it depends on the shelf. Models sold by Azure bill through Azure meters as first-party consumption services. Models from partners and community bill through Azure Marketplace, which spins up a SaaS resource behind the scenes the first time your project subscribes to that offer.

The pricing and terms sit on the model card, on the tab you accept before the deployment goes through. Read it there. Do not carry a per-token number from one model to another, because a partner model on Marketplace and an Azure Direct model can price the same task very differently, and fine-tuning has its own meters separate from inference.

Cost tracking follows the same split, and it shapes how you report spend back to finance. When a project subscribes to a Marketplace offer, Azure creates a dedicated resource to track that offer, and separate meters record inference and fine-tuning against it so you can tell training spend from serving spend without guessing. Azure Direct models land on your normal Azure invoice under the resource group instead. The practical consequence is a tagging habit: put a cost-center or environment tag on the project and the resource group up front, because a serverless bill that arrives with no tags is a bill nobody can allocate, and you will spend a Friday reverse-engineering which team ran which model. Set the tags on day one and the monthly cost report reads itself.

Nine serverless deployment types

Serverless is not one thing. It splits into two billing families, standard and provisioned, and each can process your data at global, data zone, or regional scope. Add batch and a developer tier and you get nine named types: Global Standard, Global Provisioned, Global Batch, Data Zone Standard, Data Zone Provisioned, Data Zone Batch, Standard, Regional Provisioned, and Developer. The names read like a mouthful, but they collapse to three questions.

Do you pay per token or reserve capacity? Standard is pay-per-token, provisioned is reserved throughput you pay for up front to hold latency steady. Where is the request allowed to be processed? Global spreads across Microsoft capacity for the best availability, data zone keeps processing inside a geography such as the EU or US for compliance, regional pins it to one region. And is it live or batch? Batch trades latency for a lower rate on work that can wait. Developer is a cheap, no-SLA tier for prototyping, not production.

Not every model exposes every type. The model card lists what it supports.

Deploy DeepSeek-R1 as a serverless endpoint

Here is the whole flow from the command line for a partner model. The one detail that trips people is the model id: you copy it without the version suffix, because a serverless deployment always pulls the latest version. Copy azureml://registries/azureml-deepseek/models/DeepSeek-R1 and drop the trailing /versions/1.

# install and update the Azure ML CLI extension
az extension add -n ml
az extension update -n ml

# point the CLI at your project
az account set --subscription <subscription>
az configure --defaults workspace=<project-name> group=<resource-group> location=eastus2

# endpoint.yml (no version in model_id)
# name: DeepSeek-R1-qwerty
# model_id: azureml://registries/azureml-deepseek/models/DeepSeek-R1

az ml serverless-endpoint create -f endpoint.yml
az ml serverless-endpoint get-credentials -n DeepSeek-R1-qwerty

Expected: the endpoint reaches provisioning state Succeeded and returns a Target URI plus a primary key you call from your app.

Failure mode: a 403 AuthorizationFailed on the Marketplace subscription step means the account is missing MarketplaceOrdering or SaaS rights on the subscription. The endpoint object never gets created. Add the role, then rerun the same create command; it is idempotent on the name.

Keep the endpoint off the public internet

A serverless endpoint is reachable over the public internet by default, and for a lot of teams that is the first thing security flags in review. The control is not on the endpoint itself. It follows the public network access flag of the Foundry hub that owns the project. Disable that flag on the hub, put a private endpoint in front of it for inbound traffic, and the serverless deployments in that hub stop answering the open internet. You set it in the Azure portal under the hub, Settings, then Networking, and changes take up to five minutes to propagate, so do not panic when the first test after a change still connects.

Two edges catch people. If a hub had a private endpoint created before July 11, 2024, new serverless deployments in it will not inherit the hub networking, and you have to create a fresh private endpoint and redeploy so they pick up the config. And Azure OpenAI On Your Data does not work with serverless deployments inside a private hub, because the hub has public access switched off. Plan the retrieval design around that if you are locking the hub down. On the content side, serverless language models ship with a default set of Azure AI Content Safety text filters that screen for hate, self-harm, sexual, and violent content. Those filters bill separately and you can toggle them off per endpoint, but turning them off on a production endpoint that faces users is a decision to make on purpose, not by accident. Embedding and time series models do not get content filtering at all, which is expected, not a bug.

Rate limits will surprise you

A serverless deployment is not an unlimited firehose. Each one caps at 200,000 tokens per minute and 1,000 API requests per minute, and you are limited to one deployment per model per project. That ceiling is fine for a chat app with human users. It is not fine for a batch job fanning thousands of documents through a model, and teams find out in load testing, not in design review.

How I pick a deployment path

My default is serverless Standard. It starts in minutes, costs nothing when idle, and needs no quota fight with your subscription. For most applications that is the right answer and you should not talk yourself out of it. I move off it only when a real number forces the move.

I reach for provisioned throughput when volume is steady and tail latency has to stay flat, because a Standard deployment shares capacity and its latency wanders under load. I reach for managed compute in two cases: a compliance requirement that the model cannot run on shared multi-tenant infrastructure, or an open model I want to customize and pin to a specific machine. Both cost more in money and in operations, so I make sure the requirement is written down before I sign up for the quota request and the utilization dashboard.

When NOT to use each is the part people skip. Do not use managed compute for bursty low-volume traffic; you will pay for idle VMs. Do not use Standard serverless for a job that has to sustain more than 200,000 tokens per minute on one model in one project; the cap will stop you. Do not use the Developer tier for anything a customer touches, because it carries no SLA. Validate the deployment options on the model card first, because the provider may have already made the choice for you. If you want the same catalog decision on the AWS side, the Bedrock model catalog part covers the equivalent split there.

Serverless is where most teams should start

The catalog gives you two shelves and two paths, but the practical recommendation is short. Start on serverless Standard, deploy the model you chose in Part 3, and let the pay-per-token meter and zero idle cost carry you until a measured limit says otherwise. Move to provisioned when latency demands it, and to managed compute when compliance or customization demands it. Do not start at the complicated end because a slide told you managed compute is more enterprise. It is more work, and work is a cost too.

Next, we get into deployment types in depth: Standard against provisioned throughput units against batch, and how to size a reservation without overbuying. Before you read it, go deploy one serverless endpoint from the catalog and note the pricing on the model card. That number is the anchor for everything the sizing part covers. [AUTHOR: add anecdote about a first serverless deployment that hit the 200k cap in load testing.]

References

• Microsoft Foundry Models overview
• Deploy models as serverless API deployments
• Foundry Models product page

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts