Nueve opciones de deployment, dos ejes de decisión clave (residencia de datos y modelo de facturación) y cero margen para equivocarse en producción. Esto es lo que necesitas saber antes de desplegar.

Figura: Selector de tipo de despliegue en el portal de Microsoft Foundry (fuente: learn.microsoft.com)

El problema que resuelve esta decisión

Cuando despliegas un modelo en Microsoft Foundry hay una pantalla que muchos pasan por alto: la selección del tipo de despliegue. Parece un detalle técnico menor, pero en realidad condiciona tres cosas bastante importantes: dónde se procesan tus datos, cuánto pagas y qué garantías de latencia tienes.

No todos los modelos soportan todos los tipos — conviene revisarlo en la página de disponibilidad antes de diseñar la arquitectura. Y no, no hay una opción ‘correcta’ para todos los escenarios. Depende mucho de si estás en una multinacional con requisitos de residencia de datos en la UE, de si tu carga es predecible o muy variable, o de si simplemente estás evaluando un modelo ajustado antes de llevarlo a producción.

Los nueve tipos se agrupan en dos ejes. El primero es el modelo de facturación: pay-per-token (pagas lo que consumes) frente a capacidad reservada con PTUs (Provisioned Throughput Units). El segundo es el alcance geográfico del procesamiento: global, zona de datos (US o UE), o región concreta. Cruzando estos dos ejes obtienes la mayoría de las opciones disponibles — más el tipo Developer, que es un caso especial.

Global Standard

SKU en código: GlobalStandard. Es el punto de partida natural para casi cualquier carga de trabajo nueva. Usa la infraestructura global de Azure para enrutar el tráfico de forma dinámica a los centros de datos disponibles, lo que se traduce en la cuota por defecto más alta de todos los tipos y en que no tienes que repartir la carga manualmente entre varios recursos.

El precio es pay-per-token, así que solo pagas por lo que consumes. La contrapartida: en volúmenes altos y sostenidos puedes notar más variabilidad de latencia que con los tipos provisionados. Si eso es un problema para tu aplicación, los tipos Provisioned son la alternativa.

Un detalle que vale la pena mencionar: Global Standard soporta procesamiento prioritario (preview), que permite obtener tiempos de respuesta más rápidos en un modelo pay-as-you-go. Los datos pueden procesarse en cualquier región de Azure — sin restricciones geográficas.

Global Provisioned

SKU en código: GlobalProvisionedManaged. Mismo alcance global que el anterior, pero con capacidad reservada. Aquí compras un número fijo de PTUs que garantizan un nivel de procesamiento concreto. El resultado práctico es latencia más baja y más consistente que con Global Standard.

¿Cuándo tiene sentido? Cuando tienes cargas de alto volumen y predecibles — pipelines de procesamiento de documentos, APIs de producción con tráfico estable — y necesitas que la latencia no se dispare en las horas punta. El coste fijo de los PTUs es más alto que el pay-per-token si el volumen es bajo, pero se compensa con creces si el uso es intensivo.

Global Batch

SKU en código: GlobalBatch. Pensado para trabajos asíncronos masivos: en lugar de enviar una petición a la vez, mandas un fichero grande con muchas requests y el servicio las procesa con un plazo objetivo de 24 horas. La ventaja económica es clara: un 50% menos de coste que Global Standard.

Tiene una cuota de tokens encolados separada, lo que evita que los trabajos batch compitan con el tráfico online. Los casos de uso que más encajan son los habituales en este tipo de arquitectura:

• Análisis de grandes volúmenes de documentos en paralelo.
• Generación masiva de contenido — descripciones de producto, resúmenes, traducciones.
• Extracción de información de datos no estructurados a escala.
• Tareas de PLN sobre conjuntos de datos grandes: análisis de sentimiento, clasificación.

Ojo con algo importante: los trabajos batch no tienen SLA de tiempo real. El objetivo son 24 horas, pero pueden tardar más. Si la latencia importa, este no es tu tipo.

Data Zone Standard

SKU en código: DataZoneStandard. Variante del Global Standard para quienes necesitan que los datos permanezcan dentro de una zona geográfica definida por Microsoft — ya sea Estados Unidos o la Unión Europea. El tráfico se enruta dinámicamente, pero solo entre centros de datos de esa zona.

La cuota por defecto es más alta que la de los tipos regionales (Standard), aunque algo más limitada que la del Global Standard sin restricciones. Como en su variante global, también soporta procesamiento prioritario (preview) y el modelo de facturación es pay-per-token.

Si tu empresa opera en Europa y el equipo legal exige que las inferencias no salgan de la UE, este tipo — o su variante provisionada — es el camino natural.

Data Zone Provisioned

SKU en código: DataZoneProvisionedManaged. Combina lo mejor de los dos mundos para escenarios con requisitos duros: restricción geográfica a la zona US o UE y capacidad reservada con PTUs para throughput predecible.

Es la opción para aplicaciones de alto volumen en producción que operan bajo normativas de residencia de datos — piensa en servicios financieros, sanidad o administración pública en entornos europeos. El tráfico no sale de la data zone, la capacidad está garantizada y la latencia es más estable que con los tipos Standard.

Data Zone Batch

SKU en código: DataZoneBatch. Funcionalmente idéntico al Global Batch — mismo descuento del 50%, mismo plazo objetivo de 24 horas para los trabajos asincrónicos — pero con la restricción de que el tráfico solo se enruta a centros de datos dentro de la data zone configurada (US o EU).

El caso de uso es el mismo que el Global Batch, con la diferencia de que aquí hay un requisito regulatorio o de compliance que impide usar infraestructura fuera de la zona. Si no tienes esa restricción, Global Batch te da más flexibilidad de enrutamiento.

Standard (regional)

SKU en código: Standard. El tipo más sencillo de los tres geográficos: pay-per-token, procesamiento exclusivamente en la región donde está desplegado el recurso, sin enrutamiento dinámico a otras regiones.

Está pensado para cargas de bajo a medio volumen con picos de tráfico variables. Con volúmenes altos y sostenidos la variabilidad de latencia puede aumentar — la documentación es clara al respecto. Pero para prototipos, entornos de desarrollo o aplicaciones con tráfico moderado es perfectamente válido. Y si tienes un requisito de procesamiento en una región concreta (no solo en una zona), es el tipo adecuado.

Regional Provisioned

SKU en código: ProvisionedManaged. La versión con capacidad reservada del tipo Standard. Aquí especificas la cantidad de throughput que necesitas en PTUs y el servicio asigna la capacidad necesaria, asegurándose de que esté disponible cuando la necesites.

Los requisitos mínimos de PTUs varían por modelo — conviene consultarlos en la documentación de Provisioned Throughput antes de dimensionar. Este tipo tiene sentido cuando tienes requisitos de residencia en una región específica y además necesitas garantías de throughput. Si los requisitos son de zona (US/EU) y no de región concreta, Data Zone Provisioned suele ofrecer más flexibilidad.

Developer (para modelos ajustados)

SKU en código: DeveloperTier. Este tipo es diferente a todos los anteriores en varios aspectos. Está diseñado exclusivamente para evaluar modelos ajustados (fine-tuned) antes de llevarlos a producción — no es para cargas de trabajo generales.

Tres características que lo distinguen del resto. Primero: no incluye garantías de residencia de datos. Segundo: no hay SLA. Tercero — y esto es importante — los despliegues de tipo Developer tienen una vida útil fija de 24 horas; se eliminan automáticamente al expirar.

El modelo de facturación es pay-per-token y el coste es bajo, lo que lo hace ideal para ciclos de evaluación durante el proceso de ajuste fino. Pero en cuanto tengas listo el modelo para producción, migras a uno de los tipos anteriores según tus requisitos de residencia y throughput.

Cómo elegir: dos preguntas que simplifican la decisión

Con nueve opciones sobre la mesa, la parálisis por análisis es real. Pero en la práctica, dos preguntas reducen el espacio de decisión considerablemente.

¿Tienes restricciones de residencia de datos?

Si la respuesta es no, empieza por Global Standard o Global Provisioned según el volumen. Si necesitas mantenerte dentro de la UE o de EEUU, ve a los tipos DataZone. Si el requisito es una región concreta de Azure, entonces Standard o Regional Provisioned.

¿El tráfico es predecible o variable?

Tráfico variable o volumen bajo: los tipos Standard (pay-per-token) son más eficientes en coste. Volumen alto y sostenido: los tipos Provisioned dan mejor rendimiento y coste predecible. Trabajos asincrónicos no urgentes: Batch al 50% de descuento, con o sin restricción de zona.

Y si estás en la fase de evaluar un modelo que has ajustado — antes de decidir si va a producción — Developer es la opción obvia: coste mínimo, sin compromisos, con la limitación de las 24 horas.

Referencia rápida

La siguiente tabla resume los nueve tipos con sus características principales tal como aparecen en la documentación oficial de Microsoft Foundry:

Tipo	SKU (código)	Procesamiento	Facturación	Mejor para
Global Standard	GlobalStandard	Cualquier región Azure	Pay-per-token	Cargas generales, cuota máxima
Global Provisioned	GlobalProvisionedManaged	Cualquier región Azure	PTU reservados	Throughput alto y predecible
Global Batch	GlobalBatch	Cualquier región Azure	50% dto., 24h	Trabajos asíncronos masivos
Data Zone Standard	DataZoneStandard	Dentro de la data zone	Pay-per-token	Compliance UE/US, cuota media
Data Zone Provisioned	DataZoneProvisionedManaged	Dentro de la data zone	PTU reservados	Compliance + throughput garantizado
Data Zone Batch	DataZoneBatch	Dentro de la data zone	50% dto., 24h	Batch con restricción de zona
Standard	Standard	Región del despliegue	Pay-per-token	Volumen bajo/medio, región fija
Regional Provisioned	ProvisionedManaged	Región del despliegue	PTU reservados	Compliance regional + throughput
Developer	DeveloperTier	Cualquier región Azure	Pay-per-token	Evaluación de modelos ajustados

Un apunte sobre gobernanza: Azure Policy

Si gestionas varios entornos o equipos, puede interesarte restringir qué tipos de despliegue están disponibles en determinadas suscripciones. Azure Policy permite hacerlo mediante una definición de política sobre el campo sku.name del recurso Microsoft.CognitiveServices/accounts/deployments.

El esqueleto de la regla, sustituyendo GlobalStandard por el SKU que quieras bloquear:

{
«mode»: «All»,
«policyRule»: {
«if»: {
«allOf»: [
{
«field»: «type»,
«equals»: «Microsoft.CognitiveServices/accounts/deployments»
},
{
«field»: «Microsoft.CognitiveServices/accounts/deployments/sku.name»,
«equals»: «GlobalStandard»
}
]
}
}
}

Útil, por ejemplo, para forzar que todos los despliegues de producción en una suscripción UE usen únicamente tipos DataZone.

Antes de desplegar

La elección del tipo de despliegue no es irreversible — puedes cambiarla — pero hacerlo bien desde el principio evita sorpresas en facturación y problemas de compliance que luego son incómodos de justificar.

Lo que sí conviene revisar antes de confirmar: que el modelo que quieres desplegar soporta el tipo elegido (no todos los modelos están disponibles en todos los tipos), y que la región o zona que necesitas tiene capacidad disponible — especialmente relevante para los tipos Provisioned.

La documentación oficial tiene la tabla actualizada de disponibilidad por modelo, tipo y región. Vale la pena consultarla antes de diseñar la arquitectura.

Fuentes

• Documentación oficial: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types
• Precios de Azure OpenAI Service: https://azure.microsoft.com/pricing/details/cognitive-services/openai-service/
• Conceptos de Provisioned Throughput: https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/provisioned-throughput
• Residencia de datos en Azure: https://azure.microsoft.com/explore/global-infrastructure/data-residency/
• SLA de Azure OpenAI Service: https://www.microsoft.com/licensing/docs/view/Service-Level-Agreements-SLA-for-Online-Services