Azure's AI infrastructure has matured rapidly. Between Azure OpenAI Service, the Model Catalog, and GPU compute options, enterprises now have multiple paths to production AI. The challenge isn't access to models—it's building the infrastructure patterns that make AI applications reliable, secure, and cost-effective.
The AI Application Stack
Production AI applications require more than a model endpoint. They need retrieval systems, guardrails, observability, and integration patterns that connect AI capabilities to business processes.
Figure 1: Complete AI application infrastructure on Azure
Azure OpenAI vs. Model Catalog vs. Self-Hosted
The first architectural decision is where your models run. Each option trades off simplicity against control and cost.
| Factor | Azure OpenAI | Model Catalog (MaaS) | Self-Hosted (vLLM) |
|---|---|---|---|
| Setup complexity | Minimal | Low | High |
| Model selection | OpenAI models only | Llama, Mistral, Phi, etc. | Any HuggingFace model |
| Data residency | Regional deployment | Varies by model | Full control |
| Cost model | Per token | Per token | GPU compute time |
| Throughput control | PTU or TPM limits | Rate limits | Full control |
| Fine-tuning | Supported | Some models | Full flexibility |
| Best for | Most enterprise apps | Open-source preference | High volume, special reqs |
Start with Azure OpenAI for most enterprise applications. The operational simplicity, enterprise agreements, and content filtering integration make it the fastest path to production. Reserve self-hosted options for specific requirements around cost optimization at scale, specialized fine-tuning, or air-gapped deployments.
Open-Source Models on Azure
When Azure OpenAI isn't the right fit—whether for cost, licensing, or customization reasons—Azure's Model Catalog and self-hosted options provide alternatives.
Llama 3.1 / 3.2
Strong general-purpose performance. Available in 8B, 70B, and 405B variants.
Mistral Large / Nemo
Excellent reasoning, efficient inference. Strong code generation.
Phi-3 / Phi-4
Small but capable. Great for edge deployment and cost-sensitive workloads.
DeepSeek Coder V2
Specialized for code. Strong performance on programming benchmarks.
Self-Hosting with vLLM
For high-volume workloads or specialized requirements, self-hosting with vLLM on Azure provides maximum flexibility. vLLM's PagedAttention algorithm delivers 2-4x better throughput than naive implementations.
# Deploy vLLM with Llama 3.1 70B on NC A100 nodes
apiVersion: apps/v1
kind: Deployment
metadata:
name: vllm-llama
spec:
replicas: 2
template:
spec:
containers:
- name: vllm
image: vllm/vllm-openai:latest
args:
- "--model=meta-llama/Llama-3.1-70B-Instruct"
- "--tensor-parallel-size=4"
- "--max-model-len=32768"
- "--gpu-memory-utilization=0.9"
resources:
limits:
nvidia.com/gpu: 4
ports:
- containerPort: 8000
nodeSelector:
accelerator: nvidia-a100
tolerations:
- key: "sku"
operator: "Equal"
value: "gpu"
effect: "NoSchedule"
GPU Instance Selection
Azure offers multiple GPU SKUs. Selection depends on model size, required throughput, and budget.
| VM Series | GPU | VRAM | Best For | ~Cost/hr |
|---|---|---|---|---|
| NC A100 v4 | A100 80GB | 80GB per GPU | Large models (70B+), training | $3.67+ |
| NC H100 v5 | H100 80GB | 80GB per GPU | Maximum throughput, latest models | $5.12+ |
| NC A10 v3 | A10 24GB | 24GB per GPU | Medium models (7B-13B), inference | $1.12+ |
| NC T4 v3 | T4 16GB | 16GB per GPU | Small models, development | $0.52+ |
| ND A100 v4 | 8x A100 80GB | 640GB total | 405B models, multi-node training | $27.20+ |
Key Takeaway
For inference workloads, NC A10 v3 offers the best price/performance for models up to 13B parameters. For 70B+ models, NC A100 v4 with tensor parallelism across 4 GPUs is the practical minimum.
RAG Architecture on Azure
Retrieval-Augmented Generation connects your models to enterprise data. Azure AI Search provides the foundation, with vector search, hybrid retrieval, and semantic ranking.
Figure 2: RAG pipeline with hybrid search and semantic reranking
Vector Database Options
| Option | Strengths | Considerations |
|---|---|---|
| Azure AI Search | Hybrid search, semantic ranking, integrated skills | Cost scales with index size |
| Cosmos DB (vCore) | MongoDB API, global distribution, integrated vector | Requires MongoDB knowledge |
| PostgreSQL + pgvector | Familiar SQL, cost-effective, flexible | Self-managed scaling |
| Azure Cache for Redis | Sub-millisecond latency, vector search preview | Memory-bound capacity |
Guardrails and Content Safety
Production AI applications need multiple layers of safety controls. Azure AI Content Safety provides the foundation, but enterprise applications typically need additional guardrails.
Figure 3: Multi-layer guardrails for enterprise AI applications
Guardrails Are Not Optional
Every production AI application needs guardrails. Azure AI Content Safety provides baseline protection, but regulated industries require additional controls: PII handling with Presidio, topic restriction enforcement, and comprehensive audit logging. Build these into your architecture from day one.
Model Context Protocol (MCP)
MCP provides a standardized way to connect AI models with external tools and data sources. Rather than building custom integrations for each capability, MCP creates a unified interface.
from mcp.server import Server
from mcp.types import Tool, TextContent
from azure.identity import DefaultAzureCredential
from azure.mgmt.resource import ResourceManagementClient
server = Server("azure-resources")
@server.tool()
async def list_resource_groups(subscription_id: str) -> list[TextContent]:
"""List all resource groups in an Azure subscription."""
credential = DefaultAzureCredential()
client = ResourceManagementClient(credential, subscription_id)
groups = [rg.name for rg in client.resource_groups.list()]
return [TextContent(type="text", text=f"Resource groups: {', '.join(groups)}")]
@server.tool()
async def get_resource_group_resources(
subscription_id: str,
resource_group: str
) -> list[TextContent]:
"""List resources in a specific resource group."""
credential = DefaultAzureCredential()
client = ResourceManagementClient(credential, subscription_id)
resources = client.resources.list_by_resource_group(resource_group)
resource_list = [f"{r.name} ({r.type})" for r in resources]
return [TextContent(type="text", text="\n".join(resource_list))]
Observability for AI Applications
AI applications require specialized observability beyond traditional APM. You need visibility into model performance, token usage, latency distributions, and content safety events.
Key Metrics to Track
- Latency: Time to first token (TTFT), total generation time, retrieval latency
- Throughput: Requests per second, tokens per second, concurrent users
- Quality: User feedback, retrieval relevance scores, hallucination detection
- Cost: Token consumption by model, cost per conversation, cost per user
- Safety: Content safety triggers, guardrail blocks, escalation events
Azure Monitor and Application Insights capture baseline telemetry. For AI-specific metrics, integrate with Prompt Flow's tracing or build custom instrumentation using OpenTelemetry.
Getting Started
Building production AI infrastructure is iterative. Start with the simplest architecture that meets your requirements:
- Prove the concept with Azure OpenAI and a basic RAG setup using AI Search
- Add guardrails before any production deployment—Content Safety at minimum
- Instrument everything—you can't optimize what you can't measure
- Iterate on retrieval—chunking strategy and reranking often matter more than model choice
- Consider self-hosting only when you've hit the limits of managed services
The goal is production AI that's reliable, secure, and cost-effective—not the most sophisticated architecture possible.





