Decenas de despliegues de modelos: ¿quién dice qué modelos hay, de quién son y cuánto cuestan?

Pregunte a un equipo de plataforma de una gran empresa tres cosas: qué modelos de IA están desplegados en toda la organización, quién es dueño de cada uno y cuánto costó cada uno el mes pasado. En muchas empresas la respuesta honesta lleva una semana y una hoja de cálculo, porque los despliegues los crearon equipos distintos en suscripciones y regiones distintas, para proyectos distintos, a lo largo de dos años.

El equipo Mission Critical de Microsoft publicó el 16 de octubre una arquitectura de referencia para responder a esas preguntas de forma continua en Azure. No es un producto nuevo ni sustituye la monitorización dentro de Microsoft Foundry. Es una forma de construir una vista a nivel de grupo de administración o de tenant sobre servicios que la mayoría de los clientes de Azure ya tienen. Sus decisiones de diseño son útiles mucho más allá de Azure.

Cuatro tipos de datos, mantenidos por separado

Cuatro planos de una vista de operaciones de modelos

Inventario

• Azure Resource Graph en todas las suscripciones
• API de despliegues por cuenta
• Modelo, versión, tipo de despliegue, etiquetas de propiedad

Estado actual

Uso

• Métricas y logs de Azure Monitor
• Solicitudes, tokens, errores, utilización de PTU

Series temporales

Coste

• Consultas o exportaciones de Cost Management
• Unidas por ID de recurso y etiquetas

Datos de facturación, pueden llegar con retraso

Cuota

• Por suscripción, modelo y región

Una señal de capacidad, no de gasto

La arquitectura trata estos datos como tipos distintos y no como un único flujo. El inventario sale de Azure Resource Graph, que consulta en todas las suscripciones, combinado con la API de despliegues de cada cuenta: modelo, versión, tipo de despliegue, capacidad, región y etiquetas como propietario, entorno y unidad de negocio. El uso sale de Azure Monitor: solicitudes, tokens, errores, indicadores de latencia y utilización de las unidades de rendimiento aprovisionadas (PTU). El coste sale de las API o exportaciones de Cost Management. La cuota se sigue por separado, porque es un límite de capacidad y no de gasto, y la cuota de Azure OpenAI se aplica por suscripción y no por tenant, así que un resumen ejecutivo puede esconder justo la suscripción que está a punto de tocar su techo.

Los públicos también son distintos. Los ingenieros de plataforma tienen Azure Workbooks para profundizar; el área de finanzas tiene Power BI, con una advertencia: el conector de Cost Management está documentado para clientes con Enterprise Agreement y con contrato directo de Microsoft Customer Agreement, y los demás deberían usar exportaciones. Los responsables de las aplicaciones reciben un cuadro de mando pequeño: sus despliegues, uso, coste, cuota y la siguiente acción necesaria.

Solo metadatos, a propósito

El principio de diseño que subrayaríamos es el que Microsoft enuncia primero: el dashboard no recoge prompts, completaciones, datos de clientes ni otras cargas útiles salvo que un diseño aparte de privacidad y seguridad lo exija. Un equipo central puede ver todos los despliegues, su propietario, su tráfico y su coste sin obtener acceso a lo que alguien preguntó a un modelo. Eso evita que la vista de gobernanza se convierta en una nueva copia de datos sensibles, que es la cuestión de la custodia a la que acaban enfrentándose casi todos los diseños de observabilidad.

La vista de higiene es la vista de gobernanza

De las cinco vistas propuestas (resumen ejecutivo, inventario, operaciones, asignación de costes e higiene de gobernanza), la última es la que conviene construir primero. Enumera los despliegues con etiquetas faltantes, los despliegues sin propietario, las versiones antiguas de modelos y la concentración regional.

Cada uno es un riesgo con fecha. Las versiones antiguas de modelos son las migraciones forzosas del próximo trimestre, del tipo que los avisos recientes de retirada ponen en el calendario. Un despliegue sin propietario es un coste que nadie aprueba y un modelo que nadie va a migrar. La concentración regional es una cuestión de resiliencia y de residencia de datos. Una lista de higiene los convierte en tickets con nombre y apellido.

Microsoft es directa con la condición previa: «Los dashboards no pueden crear responsabilidad si los recursos no llevan metadatos de propietario, aplicación, entorno y centro de coste.» Exija las etiquetas en el momento del despliegue, con Azure Policy o con el pipeline de despliegue, antes de construir cualquier informe encima. Si no, el número más exacto del dashboard será la cuenta de cosas que no son de nadie.

Más allá de Azure

Los cuatro planos no son específicos de Azure. Cualquier nube y cualquier gateway de modelos puede producir una vista de inventario, uso, coste y cuota, y la mayoría de las empresas usan más de una. La arquitectura es una buena plantilla para el inventario de agentes y modelos entre proveedores que los equipos de gobernanza llevan tiempo pidiendo. Merece la pena señalar tres límites: el inventario y los recuentos de tokens no dicen nada sobre si un despliegue produce valor o una salida correcta; algunas métricas de Azure tienen restricciones de exportación; y partes de la guía de monitorización de Microsoft siguen describiendo el portal clásico de Foundry, así que compruebe qué aplica a su entorno antes de estandarizar sobre ello.