Arquitectura Azure — Módulo 7: el LLM gateway y Microsoft Foundry
Séptimo módulo del curso de arquitectura Azure: el punto único hacia los modelos con la carta fuerte de la casa — OpenAI como inquilino de primera parte, servido con contratos, red privada y compliance de Azure — junto al catálogo de Foundry Models, los despliegues con capacidad propia (TPM) que cambian el diseño, y API Management con políticas GenAI como el proxy semi-administrado que las otras nubes no traen.
☰ Índice del contenido
El marco del gateway está cerrado desde AWS y GCP: punto único, routing por gama, fallback digno, y el árbol de tres preguntas que decide si el administrado alcanza o va proxy delante. Azure lo puebla con dos particularidades que cambian respuestas: quién vive en el catálogo, y cómo se compra la capacidad.
| Concepto | En AWS | En GCP | En Azure |
|---|---|---|---|
| Servicio de modelos | Bedrock | Vertex AI | Microsoft Foundry (Models) |
| El inquilino estrella | Claude y cía. | Gemini (de casa) + Garden | OpenAI (primera parte) + Claude y catálogo |
| Unidad de consumo | Modelo on-demand | Modelo on-demand | Despliegue (deployment) con capacidad |
| Capacidad reservada | Provisioned throughput | Provisioned Throughput | PTU (provisioned throughput units) |
| Proxy si hace falta | LiteLLM en ECS | LiteLLM en Cloud Run | APIM con políticas GenAI (o LiteLLM) |
La tesis del módulo
Dos rasgos reordenan el módulo en Azure: los modelos se consumen a través de despliegues — instancias con nombre, versión anclada y capacidad asignada en tokens-por-minuto, lo que vuelve la cuota parte del diseño y no un límite lejano — y API Management trae políticas GenAI nativas (límites de tokens por consumidor, balanceo entre despliegues, registro de uso), convirtiendo al portero del módulo 5 en un proxy de LLM semi-administrado: el punto medio entre “el servicio es el gateway” y “LiteLLM propio” que las otras nubes no ofrecían. Y la pregunta del catálogo tiene aquí su respuesta más famosa: GPT con factura, red y compliance de Azure.
Foundry Models: el catálogo con inquilino estrella
Microsoft Foundry (la evolución de Azure AI Foundry/Azure OpenAI) sirve el catálogo: los modelos de OpenAI como primera parte — el diferencial histórico de Azure: GPT bajo el contrato, la red privada (private endpoints del módulo 4), la residencia y el compliance de tu tenant — junto a un catálogo amplio (Claude de Anthropic — disponible de forma general en Foundry desde mediados de 2026 —, Llama, Mistral, Grok, DeepSeek y compañía; verifica la disponibilidad de proveedor concreto contra la región y el momento — el catálogo es de las cosas que más rápido cambia). Las garantías de datos son las de la serie: tus prompts no entrenan los modelos base.
El rasgo estructural es el despliegue (deployment): en Azure no llamas “al modelo” — llamas a tu despliegue de un modelo: nombre propio, versión anclada, y capacidad en TPM (tokens por minuto) asignada o compartida, con PTU como la compra de capacidad dedicada para volumen sostenido. Consecuencias de diseño:
- La versión se ancla por despliegue — el “el proveedor cambió el modelo bajo mis pies” de la serie tiene aquí su mitigación más explícita: tu agente apunta a un despliegue cuya versión tú migras cuando decides (con evals de regresión mediante, como corresponde).
- La cuota es visible y asignada — el TPM del despliegue del agente es un número que conoces y repartes. El eco del módulo 3 (KEDA no debe escalar más rápido que el TPM) y del freno de capa 1 del módulo 8: en Azure, el tope de consumo del modelo viene incorporado al objeto que despliegas.
- El routing por gama gana un nivel: gamas → despliegues concretos (el “económico” es tal despliegue de tal modelo con tal TPM), y el balanceo entre despliegues equivalentes (multi-región, multi-capacidad) es parte del diseño de disponibilidad.
El gateway: APIM entra al escenario
El árbol de tres preguntas se ejecuta igual, con una opción intermedia nueva. API Management trae políticas específicas para GenAI: límite de tokens por consumidor (no solo peticiones: tokens — la unidad que importa), métricas de uso por consumidor hacia el FinOps, balanceo y failover entre despliegues de backend, y caché semántico en algunas configuraciones. Es decir: buena parte de la lista del proxy — cuotas multi-equipo, fallback, registro — como configuración de un servicio administrado que probablemente ya tienes en la puerta.
La decisión de tres caminos, honesta:
| Camino | Cuándo |
|---|---|
| Foundry directo (+ managed identity + despliegues bien repartidos) | Un equipo, catálogo de Foundry alcanza, routing simple — el “Bedrock es el gateway” de esta casa |
| APIM delante | Multi-equipo con cuotas de tokens, balanceo entre despliegues, registro central — sin operar un proxy propio |
| LiteLLM propio | Modelos fuera de todo catálogo Azure, routing con lógica compleja, o portabilidad multi-nube del gateway como requisito |
EL GATEWAY EN AZURE: UNA PENDIENTE, NO UN SALTO
┌──────────────────┐
│ Foundry directo │ un equipo · catálogo alcanza
│ + managed id. + │ · routing simple
│ despliegues │
└────────┬─────────┘
│ llega el multi-equipo (cuotas, balanceo)
▼
┌──────────────────┐
│ APIM delante │ token limits por consumidor ·
│ (políticas │ balanceo entre despliegues ·
│ GenAI) │ registro central
└────────┬─────────┘
│ la lógica ya no cabe en políticas
▼
┌──────────────────┐
│ LiteLLM propio │ modelos fuera de Azure ·
│ (Container App) │ routing con reglas de negocio
└──────────────────┘Ojo — APIM no es gratis ni infinito: el camino intermedio hereda las advertencias del proxy propio a medias: es una pieza crítica en el camino de cada llamada (dimensionar, monitorear — módulo 11) y sus políticas GenAI cubren los casos típicos, no toda lógica imaginable — la cascada fina con reglas de negocio sigue siendo código, y si la necesitas, LiteLLM vuelve a la mesa. La virtud del camino APIM es que convierte el salto “nada → proxy” en una pendiente: empiezas directo, agregas APIM cuando el multi-equipo llega, y solo construyes proxy si la lógica lo exige.
Las palancas de precio cierran el cuadro sin sorpresas: batch con descuento para lo nocturno, prompt caching para el prefijo repetido, PTU solo con curva de uso medida — tres nubes, tres nombres, una regla. Y la letra pequeña regional de siempre: catálogo, capacidad y variantes de despliegue (global vs. regional, con implicancias de residencia de datos) se verifican contra tu política antes de prometer — el cross-region de Bedrock tiene aquí su primo en los despliegues globales.
Errores comunes
- Tratar el despliegue como detalle de implementación. Es la unidad de diseño: versión anclada, TPM asignado, nombre al que apunta el routing. Ignorarlo es renunciar gratis al mejor control de versión y cuota de la serie.
- Repartir TPM sin mirar los agentes. La capacidad compartida que el agente batch se come en la noche es la latencia del conversacional en la mañana. El reparto de TPM por despliegue sigue al reparto de carga por agente.
- Saltar a LiteLLM sin evaluar APIM. Si ya hay APIM en la puerta y la necesidad es cuotas + balanceo + registro, el proxy propio es operación evitable. La pendiente existe; úsala.
- Encender PTU el día uno. Tercera nube, misma regla: capacidad dedicada con curva medida, jamás con optimismo.
- Despliegue global sin leer residencia. “Global” compra capacidad con letra chica geográfica. Contra la política de datos, antes.
- Routing por marca, última llamada. Gamas por capacidad/precio con despliegues detrás — que cambiar el modelo del “económico” sea editar un despliegue, no reescribir agentes.
La frase para llevarse
“En Azure no llamas al modelo: llamas a tu despliegue — versión anclada, tokens por minuto asignados — y esa unidad te regala el control de versión y el freno que otras nubes te hacían construir. Para el gateway, la pendiente: directo primero, APIM con políticas GenAI cuando llegue el multi-equipo, proxy propio solo si la lógica lo exige.”
Qué viene
Módulo 8: FinOps. Los cuatro eslabones con las piezas de esta casa: tags exigidos por Azure Policy, Cost Management con sus exportaciones, budgets con action groups (el pariente de las budget actions), las cuotas de despliegue como freno de fábrica — y el kill switch en capas cerrando la doctrina en su tercera nube.
Material relacionado
Preguntas sobre este curso
Regístrate gratis para hacer preguntas y guardar tu progreso.
✉ Entérate de lo nuevo
Recibe un aviso cuando publique nuevos cursos, workshops o investigaciones. Sin spam.