Azure AI Foundry Model Router: nuevos modelos y failover automático en marzo 2026
Resumen
En marzo de 2026, el Model Router de Azure AI Foundry incorpora cuatro nuevos modelos —incluyendo versiones actualizadas de GPT, DeepSeek y Claude— y estrena failover automático entre modelos: si el modelo primario no está disponible o supera su cuota, el router redirige la petición al siguiente candidato de forma transparente. Es una capacidad crítica para aplicaciones que necesitan alta disponibilidad en sus llamadas a LLMs sin gestionar lógica de fallback propia.
¿Qué es el Model Router en Foundry?
El Model Router es un endpoint unificado en Azure AI Foundry que recibe una petición de inferencia y decide qué modelo la procesa, basándose en:
- Disponibilidad del modelo (capacidad, cuota disponible)
- Coste por token (puede optimizar por precio)
- Capacidades requeridas (si el prompt requiere visión, búsqueda, etc.)
flowchart LR
APP["Aplicación"] --> MR["Model Router
Azure AI Foundry"]
MR -->|Disponible| M1["GPT-5.2"]
MR -->|Failover| M2["GPT-4o"]
MR -->|Failover| M3["DeepSeek-v3.2"]
MR -->|Especializado| M4["Claude Opus 4.6"]
M1 & M2 & M3 & M4 --> MR
MR --> APP
Nuevos modelos disponibles en marzo 2026
| Modelo | Tipo | Características destacadas |
|---|---|---|
gpt-5.2 |
OpenAI GPT | Mejor razonamiento, contexto 256K |
DeepSeek-v3.2 |
DeepSeek | Open-weights, alta eficiencia en código |
claude-opus-4-6 |
Anthropic | Larga ventana de contexto, seguimiento de instrucciones |
phi-4-mini |
Microsoft | Ligero, bajo coste, ideal para tasks simples |
Failover automático: cómo funciona
Cuando una petición llega al Model Router:
- El router intenta el modelo con mayor prioridad configurada
- Si recibe
429 Too Many Requestso503 Service Unavailable, reintenta automáticamente con el siguiente modelo del grupo de failover - El proceso es transparente para el cliente: recibe una respuesta del modelo alternativo sin errores
Configurar un grupo de failover
Desde Foundry → Model Router → Deployments → Create deployment group:
{
"deploymentGroupName": "production-llm",
"models": [
{
"modelId": "gpt-5.2",
"priority": 1,
"quotaAllocation": 80
},
{
"modelId": "gpt-4o",
"priority": 2,
"quotaAllocation": 60
},
{
"modelId": "DeepSeek-v3.2",
"priority": 3,
"quotaAllocation": 100
}
],
"failoverPolicy": {
"enableAutoFailover": true,
"failoverOnQuotaExhaustion": true,
"failoverOnServiceUnavailable": true
}
}
Llamar al Model Router desde tu aplicación
El endpoint del Model Router es compatible con la API de Azure OpenAI, por lo que no necesitas cambiar el SDK:
from openai import AzureOpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
token_provider = get_bearer_token_provider(
DefaultAzureCredential(),
"https://cognitiveservices.azure.com/.default"
)
client = AzureOpenAI(
azure_endpoint="https://<foundry-resource>.openai.azure.com/",
azure_ad_token_provider=token_provider,
api_version="2025-01-01-preview"
)
response = client.chat.completions.create(
model="production-llm", # nombre del deployment group, no el modelo individual
messages=[
{"role": "user", "content": "Explica qué es el Model Router de Azure AI Foundry"}
]
)
# La respuesta incluye qué modelo respondió efectivamente
print(response.model) # ej: "gpt-5.2" o "gpt-4o" si hubo failover
print(response.choices[0].message.content)
Monitorización del router
Puedes ver qué modelo procesó cada petición en las métricas de Foundry:
# KQL en Log Analytics para ver distribución de uso por modelo
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where Category == "RequestResponse"
| extend ModelUsed = tostring(Properties["model"])
| summarize Requests = count() by ModelUsed, bin(TimeGenerated, 1h)
| render columnchart
Note
El coste se factura según el modelo que efectivamente procesó la petición, no el modelo primario configurado. Si hay failover frecuente a modelos más caros, aparecerá reflejado en la factura. Configura alertas de coste en Azure Cost Management.
Buenas prácticas
- Incluye siempre un modelo de bajo coste como último nivel de failover para evitar que las peticiones fallen por agotamiento de cuota.
- Usa
response.modelpara registrar qué modelo procesó cada petición y detectar patrones de failover excesivo. - No asumas que el modelo alternativo tiene las mismas capacidades que el primario: valida que el output del grupo de failover es aceptable para tu caso de uso.