I just published AI on Azure, a five-part series on the Startups at Microsoft blog.
I wrote it for developers and engineering teams working through questions like: do we need to train or fine-tune a model? Which services should we use to build the application? How much infrastructure should we manage ourselves?
Those questions lead to different decisions. Calling a hosted model, building an agent, and running a training job involve different parts of the system. The series walks through each layer so you can compare the options and understand what your team would own.
1. Start with the concepts
AI on Azure 101: training, fine-tuning, inference, and where everything lives
The first article explains training and inference, where fine-tuning fits, and how prompting and retrieval differ from changing a model’s weights. A fictional support application ties the concepts together, using a predictive model for ticket priority and a language model to draft responses.
It also maps Microsoft Foundry, Fireworks on Foundry, and Azure Machine Learning to Azure resources. Start here if the service names are familiar but their boundaries are still unclear.
2. Choose a hosted model
AI on Azure: models as a service
A model API leaves you with decisions about who hosts inference, where requests are processed, and which terms apply. This part covers hosted model options in Microsoft Foundry and the deployment choices that affect capacity and billing.
Use it when you want to consume a model without operating the GPU serving stack. It explains what remains your responsibility, including evaluation, access controls, quota planning, and application costs.
3. Build the application around the model
AI on Azure: platforms for apps and agents
The model endpoint is one component. Your application may also need retrieval, tools, identity, and a way to evaluate results.
This article explains how the surrounding services fit together, including Foundry Agent Service, Microsoft Agent Framework, and Azure AI Search. It also discusses when a deterministic workflow is enough and when an agent is worth considering.
4. Train and serve models with managed platforms
For teams that need custom training or model adaptation, this part compares the roles of Azure Machine Learning, Foundry fine-tuning and managed compute, Azure Databricks, Microsoft Fabric Data Science, and Anyscale on Azure.
Training and serving are separate choices. The article looks at which parts of the model lifecycle each platform handles and which responsibilities stay with your team.
5. Decide when to own the infrastructure
AI on Azure: when you own the infrastructure
The final part covers workloads that need control over GPU hardware or the serving stack. It discusses GPU VMs, Kubernetes, Ray, and capacity considerations, along with the operational work that comes with those choices.
Read this when you need to choose the runtime, scheduler, network, or storage yourself. A VM family and a distributed execution framework solve different problems; the article groups the options by their role.
Where to start
If you’re new to AI on Azure, follow the series from part 1. If you already have a project, start with the layer you’re deciding on: hosted inference in part 2, the application in part 3, custom ML in part 4, or infrastructure in part 5.
The articles include documentation links and call out preview features. Model availability, regions, and support terms change, so check the current documentation before committing to a production design.
You can find the series alongside my other publications on the Projects page and in the Activity Log.