Entornos productivos con Azure AI Services, puntualmente en este caso vamos a hablar de Azure OpenAI.
Introducción
La intención es compartir mi experiencia, recomendaciones y deploy usando terraform. Ya que el proceso de aprendizaje fue bastante caótico porque no encontré una fuente confiable y fácil de interpretar con lo cual me tocó desarrollar mi propia docuementación.
La aparición de nuevos servicios como Azure OpenAI, nacido de la unión entre OpenAI (compañía creadora de Chat GPT) y Microsoft permite desarrollar unas soluciones de inteligencia artificial sacan partido de la seguridad, escalabilidad e integración de otros servicios proporcionados por la plataforma en la nube de Azure.
Disponibilidad regional
Azure OpenAI Service proporciona acceso a varios tipos de modelos. Algunos modelos solo están disponibles en regiones específicas:
Modelos Disponibles y Funciones
En palabras simples, un modelo de IA es un sistema que se entrena para realizar tareas específicas. Esto significa que el modelo procesa datos de entrada (texto, imágenes, audio, etc.) y genera una respuesta en función de los objetivos para los que fue diseñado. Un modelo de IA puede estar entrenado para responder preguntas, generar imágenes, transcribir audio o hacer predicciones, entre otras muchas cosas.
El modelo pasa por un proceso de entrenamiento, que básicamente es “alimentarlo” con grandes cantidades de datos. A partir de estos datos, el modelo aprende patrones y relaciones, lo que le permite hacer predicciones o generar contenido que tenga sentido. Este entrenamiento es lo que lo hace “inteligente” y capaz de responder a preguntas, comprender texto o generar imágenes, por ejemplo.
No todos los modelos de IA están hechos para hacer lo mismo. Cada modelo tiene su propósito y está diseñado para una tarea particular:
GPT-4o y GPT-4o mini: Modelos avanzados que aceptan texto e imágenes como entrada, ideales para tareas que requieren comprensión multimodal. (Documentación de Microsoft)
GPT-4: Mejora de GPT-3.5, capaz de entender y generar lenguaje natural y código, útil para aplicaciones de procesamiento de lenguaje natural y generación de código. (Documentación de Microsoft)
GPT-3.5: Versión mejorada de GPT-3, especializada en comprensión y generación de lenguaje natural y código, adecuada para chatbots y asistentes virtuales. (Documentación de Microsoft)
Embeddings: Modelos que convierten texto en vectores numéricos, facilitando tareas de similitud semántica y búsqueda de información. (Documentación de Microsoft)
DALL-E: Genera imágenes originales a partir de descripciones en lenguaje natural, útil para diseño gráfico y creación de contenido visual. (Documentación de Microsoft)
Whisper: Transcribe y traduce audio a texto, aplicable en transcripción de reuniones y generación de subtítulos. (Documentación de Microsoft)
Texto a voz (versión preliminar): Sintetiza texto en audio, permitiendo la creación de voces artificiales para aplicaciones como asistentes de voz. (Documentación de Microsoft)
Una de las cosas más interesantes de los modelos es que son adaptables. Esto significa que, con algunos ajustes, pueden personalizarse para cumplir funciones muy específicas dentro de un contexto, como entender lenguaje técnico o aplicarse en un área de negocio particular.
Cuotas y Limites
Azure OpenAI Service asigna cuotas a las suscripciones de Azure en función de la región y el modelo, medidas en Tokens por Minuto (TPM). TPM es una medida utilizada para definir la cuota de uso de los modelos de lenguaje de OpenAI (como GPT-3.5 o GPT-4) dentro de una suscripción de Azure.
Tokens: Un token es una unidad de texto que puede ser una palabra, parte de una palabra o incluso caracteres como signos de puntuación. Los modelos de lenguaje procesan y generan texto en tokens, y cada solicitud consume una cierta cantidad de ellos.
Límite de Velocidad: El límite de TPM en Azure OpenAI impone una cantidad máxima de tokens que una implementación puede procesar en un minuto. Este límite se usa para controlar la carga y optimizar el rendimiento de los modelos.
Distribución: Las suscripciones en Azure pueden tener límites diferentes según la región, el tipo de modelo y el nivel de suscripción. Puedes distribuir los TPM entre diferentes implementaciones o servicios dentro de tu cuenta de Azure.
Pueden consultar el detalle de cuotas y limites aqui
Al crear una implementación de un modelo, hay que asignarle una cantidad específica de TPM, lo que determina los límites de velocidad para esa implementación. Por ejemplo, si tenes una cuota de 240,000 TPM para GPT-3.5-Turbo en la región Este de EE. UU., podes distribuirla en una o varias implementaciones, siempre que el total no supere los 240,000 TPM en esa región.
OpenAI permite la asignación de límites de velocidad a las implementaciones hasta un límite global denominado “cuota”. Esta cuota se asigna a la suscripción por región y por modelo en unidades de Tokens por Minuto (TPM).
Si estás evaluando cómo organizar tus recursos en Azure OpenAI, una buena práctica es crear una suscripción y centralizar todo en una región específica. Esta estrategia, además de ser bastante común, te permite gestionar de forma más eficiente las cuotas y los límites de uso que tengas asignados. Además, facilita el monitoreo y la administración general de tus recursos.
Ahora bien, si tus operaciones requieren una alta disponibilidad o querés contar con respaldo geográfico, podrías considerar distribuir tus recursos en distintas regiones y suscripciones. Este enfoque es especialmente útil para organizaciones con necesidades de redundancia y optimización de latencia. De todos modos, la clave está en entender bien las demandas específicas de tu negocio y armar un plan que maximice tanto el rendimiento como la confiabilidad de los recursos en la nube.
Deploy OpenAi + Private Endpoint usando Terraform
A continuación el código. Los módulos y el código, lo pueden encontrar en mi github
module "resourceGroup2" {
source = "./modules/resourceGroup"
resource_group_name = local.openai1-rg-name
location = local.openai1-location
providers = {
azurerm = azurerm.sub-oaipro001
}
tags = local.default-tags
}
#OpenAI account y Deployment
module "openai" {
source = "./modules/openai"
providers = {
azurerm = azurerm.sub-oaipro001
}
cognitive_openai_name = local.openai1-name
resource_group_name = module.resourceGroup1.resource_group_name
location = local.openai1-location
custom_subdomain_name = local.openai1-endpoint-name # "w2mailz" #Crea un subdominio para el private endpoint
public_access = "true"
deployment = {
deployment1 = {
name = "gpt-35-turbo-0301"
model_format = "OpenAI"
model_name = "gpt-35-turbo"
model_version = "0301"
scale_type = "Standard"
capacity = "10"
}
deployment2 = {
name = "text-embedding-ada-002"
model_format = "OpenAI"
model_name = "text-embedding-ada-002"
model_version = "2"
scale_type = "Standard"
}
}
network_acls = [
{
default_action = "Deny"
ip_rules = [""]
virtual_network_rules = [
{
subnet_id = data.azurerm_subnet.apim-subnet.id #Permite la consulta desde el origen seleccionado
ignore_missing_vnet_service_endpoint = false
}
]
}
]
/* Esto es para utilizar una zona privada ya existente.*/
private_dns_zone = {
name = local.openai1-privateDnsZone-Name
resource_group_name = local.openai1-privateDnsZone-rg-Name
}
private_endpoint = {
pe2 = {
name = local.openai1-pe-name #"${local.FullName}-pe"
vnet_rg_name = local.openai1-pe-rg #local.vnet2-rg
vnet_name = local.openai1-pe-vnet # local.vnet2-name
subnet_name = local.openai1-pe-subnet #local.vnet2-sub1-name
#dns_zone_virtual_network_link_name = local.open "dnslink"
private_dns_entry_enabled = false
private_service_connection_name = local.openai1-pe-service-name #"peservice"
is_manual_connection = false
}
}
tags = local.default-tags
depends_on = [module.resourceGroup1]
}Con esto ya podes comenzar a jugar! =)
Validar funcionamiento con POSTMAN sin librerias
Si bien es posible validar el funcionamiento de nuestra cuenta/modelo de openAi mediante scripts en puython, dejo por aqui el script de ejemplo en python me parece bastante más cómodo y completo hacerlo desde POSTMAN.
Para ello tienen que:
Descargar el cliente de POSTMAN
Generar una nueva consulta, e ingresar la URL, api-version, api-key y deployment-id tal como se muestra a continuación
Estos valores que se ven en la imagen anterior es posible extrarlos desde el deployment dentro de la cuenta de OpenAI
Recomendaciones
Desde la experiencia algunas recomendaciones:
Cuotas y límites: En OpenAi los límites de uso, medidos en TPM, están determinadas por una combinación de suscripción y región. Es recomendable que depliegues una cuenta de OpenAi por suscripción en diferentes regiones. Por ejemplo tu Sub1, con la cuenta OpenAI1 en la región "eastus" y tu "Sub2" con la cuenta "OpenAI2" en la región "weasteurope", de esta forma es posible continuar utilizando la cuenta OpenAI2 en caso de quedarse sin "cuota" disponible en la primera cuanta. Con respecto al balanceo de carga entre ambas es recomendable utilizar Azure Api Management (APIM) para ello, en los próximos blogs lo veremos en detalle.
Bloquear acceso desde internet: No es recomendable exponer el servicio a internet, esto lo controlas desde "Resource Management>Networking" lo mejor es que permitas los origenes específicos desde los cuales vas a consumir el servicio.
Private Endpoint: Utilizar el private endpoint, aunque puede ser más complejo al pricipio es la mejor opción en terminos de seguridad.
Autenticación: Si bien al pricipio, es lógico comenzar usando acceso mediante "Keys and Endpoint" no es una buena práctica, lo recomendable seria deshabilitarlo y usar una entidad para la autenticación. Para desactivarlo via PS: Set-AzCognitiveServicesAccount -ResourceGroupName <yourResourceGroupName> -Name <yourAzureAIResourceName> -DisableLocalAuth $true.
Monitorización: Es recomendable habilitar Diagnostic logs y almacenarlos al menos 1 año en entornos productivos.
Comentarios