AI on Azure: models as a service

Microsoft

Oct 30, 2026

AI on Azure series, Part 2 of 5

An API can make a model easy to call. It does not answer who hosts the model, where requests are processed, what the provider's terms say, or how much of the serving stack your team has to operate.

This article compares the hosted model options in Microsoft Foundry. It focuses on inference, not on training a model or building the full application around it. For those topics, see Part 1: AI on Azure 101, Part 3: Platforms for apps and agents, and Part 4: Managed ML.

Product details were checked against Microsoft Learn on October 29, 2026. Model catalogs, region availability, terms and pricing change. Check the model card and deployment options for the specific model before making a decision.

Figure 1. A shared API surface does not mean every model has the same host, terms, or operating boundary.

1. What "models as a service" means

With a model service, your application sends a request to an endpoint and receives an inference response. You do not provision the GPU machines or patch the inference runtime. You still own the application, model choice, identity and access, evaluation, quota planning, retries, and cost controls.

Microsoft Foundry's Serverless API is the normal starting point for models in its catalog. Microsoft hosts the inference infrastructure and exposes an API. Depending on the model, the catalog may offer a pay-per-token deployment, provisioned throughput, or batch processing.

The model's publisher still matters. Models sold by Azure are billed through Azure meters and have Microsoft support and applicable service terms. Partner and community models can have different license terms, billing arrangements, support paths, and data-processing details. Read the model card and provider terms rather than assuming that a shared endpoint means a shared contract.

2. Choose a deployment type

A deployment type affects where inference data is processed, how capacity is allocated, and how the service bills you. It does not change the model's task or the API contract.

Option	How it works	When to consider it
Global Standard	Pay per token. Requests can be processed in any Azure region where the model is deployed.	A general starting point when broad availability and variable demand matter more than keeping processing in one geography.
Data Zone Standard	Pay per token. Processing stays in a Microsoft-defined data zone, such as the US, EU, or APAC zone.	The workload must stay within a supported data zone but does not need reserved throughput.
Standard	Pay per token. Processing stays within the selected Azure geography. It might use more than one region in that geography for operational purposes.	Geography-level processing requirements and lower or bursty volume, where the model supports this option.
Provisioned throughput	Reserve model capacity using provisioned throughput units (PTUs). Available processing scopes depend on the model and deployment type.	Consistent volume when throughput or lower latency variation is important enough to justify reserved capacity.
Batch	Submit asynchronous work in bulk. Supported batch types target completion within 24 hours, but can take longer and do not provide a real-time SLA.	Large jobs such as document processing when the caller can wait for results.
Developer	A temporary deployment for evaluating selected fine-tuned models. It has no data-residency guarantee or SLA.	Evaluation only, not a production endpoint.

Data at rest remains in the designated Azure geography, but that is different from the location where inference runs. Global deployment can process prompts and responses in any Azure region. Data Zone and Standard deployment types constrain processing differently. Check the current deployment documentation and model availability table against your compliance requirement.

Not every model supports every deployment type. A model card may also have its own lifecycle, region, rate-limit, or feature restrictions. Treat the portal's current deployment choices as part of model selection, not as a detail to check after the design is settled.

3. Azure OpenAI models and partner models

Microsoft Foundry includes Azure OpenAI models as well as selected models from partner and community publishers. The catalog changes over time, so a fixed list of model names ages quickly. Filter the catalog by region, deployment option, lifecycle, task, and features such as tool calling, then test the candidates with representative inputs.

Models sold by Azure are billed through Azure and have Microsoft support, subject to the model's terms and service documentation. Partner and community models may have publisher-specific terms or support. The Foundry catalog and model card identify the applicable deployment choices and license details.

The hosted-model path reduces infrastructure work. It does not remove the need to evaluate output quality, latency, throughput, data handling, and safe use in your own application. Run an evaluation before selecting a model for a customer-facing workload.

4. Where Fireworks on Foundry fits

Fireworks on Foundry gives you access to selected open-weight models through an integration in the Foundry project. Fireworks provides the model-serving infrastructure. The integration supports pay-per-token and provisioned throughput options, and it can also import supported custom model weights to Fireworks' GPU-backed serving infrastructure.

Fireworks may fit when you want a supported open-weight or fine-tuned model without operating its GPU fleet. It is not the same as putting arbitrary weights onto your own virtual machines. Check the current model catalog, supported architectures, deployment types, regions, and import workflow before assuming a model will work.

Fireworks on Foundry is generally available, but an administrator must enable the subscription feature before deployment. Its data handling also has important boundaries: the current Learn documentation says the service is excluded from EU Data Boundary commitments, has not achieved FedRAMP, and is not applicable to PCI DSS workloads. Microsoft does not develop or evaluate the safety characteristics of models served through Fireworks. Your team must review whether the service and model meet your compliance and safety requirements.

LoRA adapters and deploying a model fine-tuned in Foundry through the Fireworks runtime are Preview. Importing full custom model weights is a separate workflow. Check the feature-specific documentation before choosing a path; these preview features are not interchangeable with generally available Fireworks catalog deployments.

5. Match deployment to the workload

Workload need	First option to evaluate
Call a supported model with variable or bursty traffic	Foundry Serverless API with a pay-per-token deployment
Keep inference processing in a data zone or Azure geography	A compatible Data Zone or Standard deployment
Serve a steady, high-volume request pattern	Provisioned throughput, after measuring traffic and sizing
Process a large backlog without a real-time response requirement	Batch, if the model supports it
Try an open-weight model without running its serving stack	A supported Foundry or Fireworks deployment
Serve custom weights with an external managed runtime	Fireworks BYOM, if the model and compliance requirements are supported
Choose your own runtime, GPU shape, or scheduling model	See Part 4: Managed ML and Part 5: Infrastructure

Before deployment, record the model and version, data-processing scope, license and support owner, expected traffic, quota, budget, evaluation results, and fallback behavior. Public pricing pages are estimates, not a quote for a negotiated EA or MCA. Use the Azure pricing calculator and confirm the applicable rates with your account team.