En el ecosistema actual de inteligencia artificial como servicio (AIaaS), una de las preguntas más engañosamente simples y a la vez más complejas de responder es: ¿quién usó la GPU? Cuando una plataforma admite múltiples modelos operativos —pods de Kubernetes con GPU completa, instancias MIG porciones temporales, máquinas virtuales con vGPU o paso directo del dispositivo—, la respuesta deja de ser trivial. Un mismo acelerador puede estar ocupado por varios inquilinos, mostrar alta actividad sin generar trabajo útil, o permanecer aparentemente ocioso mientras retiene memoria crítica que impide arrancar otro modelo. Esta ambigüedad hace que un simple gráfico de utilización no sirva para la rendición de cuentas por inquilino.
Para construir un sistema de showback o chargeback defendible, es necesario separar cuatro magnitudes que a menudo se confunden: asignación, utilización, trabajo productivo y consumo financiero. La asignación responde a quién controló o reservó capacidad durante una ventana temporal. La utilización mide lo que el hardware estaba haciendo en intervalos muestreados. El trabajo productivo refleja el resultado del servicio —solicitudes exitosas, tokens generados, pasos de entrenamiento completados—. Y el consumo financiero aplica una política de costes aprobada a esos datos. Mezclarlas conduce a informes incorrectos y disputas entre equipos.
En Q2BSTUDIO, entendemos que la telemetría por inquilino no es solo un problema técnico, sino un pilar para la gobernanza de plataformas de IA empresarial. Nuestra experiencia en desarrollo de aplicaciones a medida y en la integración de servicios cloud (AWS/Azure) nos ha enseñado que la evidencia debe construirse desde la capa de orquestación hasta el ledger financiero, preservando la trazabilidad incluso cuando la atribución es aproximada —como ocurre con el time-slicing o los procesos compartidos de servidores de modelos.
El primer pilar es la asignación: un hecho del plano de control. Para un pod exclusivo, la unidad es una GPU asignada durante tres horas. Para MIG, debe conservarse el perfil (por ejemplo, 1g.10gb). Para vGPU, el perfil y la máquina virtual. Para time-slicing, se declara la política de replicas, no una fracción aislada. La ecuación general es: horas GPU-equivalentes asignadas = integral de la fracción de capacidad asignada sobre el tiempo transcurrido. Esta fracción proviene de un inventario aprobado, no de un porcentaje momentáneo de utilización.
La utilización es comportamiento muestreado del dispositivo. DCGM y DCGM Exporter ofrecen métricas como SM active ratio, memoria usada, potencia, temperatura. Son esenciales para detectar reservas ociosas, saturación, cuellos de botella o throttling térmico. Pero la utilización no es una unidad de facturación universal. Un inquilino puede ser financieramente responsable de una GPU reservada aunque la utilización sea baja, igual que una máquina virtual reservada cuesta aunque su CPU esté en reposo. Una medida derivada como 'horas GPU activas equivalentes' puede ser útil para analítica, pero no debe convertirse automáticamente en factura sin decisión organizativa.
El trabajo productivo es específico de la aplicación. Para inferencia, pueden ser solicitudes exitosas, tokens de entrada y salida, imágenes generadas. Para entrenamiento, pasos completados o muestras procesadas. La misma actividad de GPU puede producir cantidades muy diferentes de trabajo útil según el tamaño del modelo, la precisión, el tamaño de lote, la latencia objetivo. Por eso las métricas de servidor de modelos —tokens por segundo, tiempo hasta el primer token, profundidad de cola— deben acompañar a la telemetría de GPU.
El consumo financiero aplica política a la evidencia. Un modelo de chargeback defendible explicita: cargo del inquilino = cargo por capacidad garantizada + cargo por asignación prestada + cargo variable por servicio o energía + gastos generales compartidos - créditos y ajustes aprobados. Cada término debe ser explicable; un revisor de finanzas debe poder reproducir el resultado mensual; el dueño de la aplicación debe entender por qué una reserva ociosa sigue costando dinero.
Para lograrlo, se necesita una cadena de atribución estable a través de capas: negocio (ID de inquilino, departamento), orquestación (clúster, namespace UID, pod UID), dispositivo (UUID de GPU, perfil MIG), servicio (ID de endpoint, modelo, versión) y solicitud (trace ID). Los identificadores inmutables y la validez temporal son claves. Cuando un pod se elimina o un namespace cambia de propietario, la relación antigua debe seguir siendo consultable para el cierre mensual. Recomendamos mantener un almacén de eventos de asignación independiente del sistema de orquestación en vivo.
Las etiquetas de Prometheus deben limitarse a dimensiones acotadas (clúster, namespace, modelo, clase de GPU, inquilino). Los IDs de solicitud o procesos van a logs o trazas, no a métricas. La arquitectura de referencia separa la recolección (DCGM Exporter, métricas de Kubernetes, telemetría de servidor de modelos), el enriquecimiento de identidad (mediante reglas de grabación de Prometheus), la analítica operativa y el ledger financiero. Un patrón práctico es un exportador de identidad que emite un gauge por cada carga de trabajo activa con etiquetas permitidas, y luego reglas de grabación unen las métricas de GPU normalizadas con esas identidades.
La atribución en MIG es más sólida que en time-slicing porque existe un identificador de instancia aislada. Sin embargo, la fracción de capacidad debe venir del perfil aprobado, no inferirse del uso de memoria. En time-slicing, la métrica del dispositivo físico se replica entre réplicas; la división equitativa es una suposición modelada, no una medición exacta. Por eso recomendamos marcar esos datos con un nivel de confianza explícito. Para vGPU, se necesita evidencia del host (UUID de GPU, perfil, VM) y del invitado (métricas de DCGM dentro de la VM), sin sumar ambos.
Los servidores de modelos compartidos —un solo proceso que atiende a varios inquilinos— requieren contabilidad a nivel de solicitud. El coste por inquilino se basa en tokens o peticiones ponderadas, no en dividir la métrica de proceso. Se calcula una fracción de servicio del inquilino: unidades productivas ponderadas del inquilino / total de unidades productivas del endpoint. El modelo de ponderación debe versionarse y probarse.
La ciberseguridad también juega un papel: la telemetría de GPU y las asignaciones deben protegerse contra accesos no autorizados entre inquilinos. En Q2BSTUDIO integramos prácticas de seguridad en cada capa, desde la autenticación de métricas hasta el aislamiento de dashboards. Además, la integración con servicios cloud como AWS o Azure permite escalar la infraestructura de telemetría de forma segura, y el uso de herramientas de BI como Power BI facilita la creación de informes de showback personalizados para cada departamento.
Los agentes de IA —sistemas autónomos que ejecutan inferencias o entrenamientos— añaden otra capa de complejidad, pues pueden generar cargas de trabajo efímeras que dificultan la atribución. Nuestra aproximación consiste en asignar un identificador de agente a cada sesión y correlacionarlo con la asignación de GPU mediante etiquetas de orquestación.
En resumen, construir telemetría por inquilino para AIaaS exige separar conceptos, mantener una cadena de evidencia estable, y aceptar que algunas atribuciones serán aproximadas pero documentadas. El objetivo no es el dashboard más vistoso, sino un registro operativo que sobreviva a la eliminación de pods, la rotación de procesos, las disputas de inquilinos y el cierre mensual. En Q2BSTUDIO ayudamos a las organizaciones a diseñar e implementar esta arquitectura, combinando desarrollo de software a medida, cloud, ciberseguridad, inteligencia artificial y business intelligence para que la pregunta '¿quién usó la GPU?' tenga una respuesta defendible.
