Seguimiento de costes de infraestructura por departamento, proyecto, aplicación y cliente

Las empresas pueden rastrear los costes de infraestructura hasta departamentos, proyectos, aplicaciones o clientes vinculando identidades de propiedad estables a las asignaciones de recursos y al consumo de servicios, utilizando después la CMDB y las relaciones de negocio para consolidar esos registros en el nivel organizativo requerido. El material de origen respalda directamente la atribución por proyecto, tenant, modelo y tipo de acelerador, alimentando los informes de costes de proyectos y tenants con horas de tarjeta aceleradora, uso de tokens, energía, almacenamiento y otros consumos.

Para departamentos, aplicaciones o clientes, el origen no define un motor de facturación comercial independiente. El enfoque respaldado consiste en conectar esos objetos de negocio con proyectos, tenants o servicios en el modelo de relaciones, agregando después ese mismo consumo subyacente.

¿Por qué falla la asignación de costes de infraestructura?

La asignación de costes falla cuando existe uso sin propiedad identificada.

El equipo de infraestructura puede saber cuántas horas de GPU se consumieron, cuánto almacenamiento se utilizó, cuánta electricidad se gastó y cuántos tokens se generaron. Si esos registros no van acompañados de la identidad de un proyecto, tenant, servicio o propietario, la organización sigue sin poder responder con fiabilidad quién generó ese gasto.

El modelo de origen soluciona esto conectando personas, activos, actividades, capacidad de computación y objetos de negocio mediante la CMDB y el modelo de datos de eventos. La capa de medición utiliza esas mismas dimensiones de propiedad para la atribución de costes, y todo lo demás se construye sobre esa base.

¿Qué registros de uso deben incluir propiedad?

Cualquier registro de uso susceptible de representar un coste relevante debe incorporar una dimensión de propiedad siempre que el sistema de origen lo permita. El modelo de operaciones de IA del origen contempla:

• Horas de tarjeta aceleradora
• Uso de memoria de acelerador
• Uso de tokens
• Energía
• Uso de almacenamiento
• Modelo
• Proyecto
• Tenant
• Tipo de acelerador

El escenario de costes de proyectos señala concretamente que la plataforma puede agregar horas de tarjeta y ocupación de memoria de aceleradores por proyecto, agregar llamadas de tokens por proyecto, asociar costes de energía y ocupación de recursos, y generar informes de costes de proyectos y tenants. Son capacidades respaldadas directamente por el origen.

El mismo principio puede aplicarse a otros servicios de infraestructura si se dispone del uso y de la propiedad.

¿Por qué conviene exigir la identidad del proyecto desde el inicio?

Reconstruir la propiedad de los recursos tras la finalización de una carga de trabajo resulta mucho más difícil.

El modelo de origen exige que las claves de API estén vinculadas a una etiqueta de proyecto para atribuir el uso de tokens de forma correcta, y lo advierte con claridad: si la clave no está vinculada a una etiqueta de proyecto, el consumo no se puede imputar a dicho proyecto.

La misma lógica se aplica a las tareas de computación. Un trabajo de entrenamiento debe incorporar la propiedad del proyecto en el momento de su envío. Un servicio de modelos debe llevar la propiedad del proyecto o tenant al publicarse, y una reserva de recursos debe identificar a su responsable en el momento de ser aprobada.

No esperes a final de mes para pedir al departamento financiero que intente adivinar qué equipo originó el consumo.

¿Cómo asignar las horas de tarjeta aceleradora?

Las horas de tarjeta aceleradora resultan fáciles de atribuir cuando el planificador conoce qué proyecto es el dueño de la tarea. Un registro simple contiene:

• Identidad del recurso
• Hora de inicio
• Hora de finalización
• Cantidad de tarjetas asignadas
• Tipo de tarjeta
• Tarea
• Proyecto
• Tenant

El modelo de costes de origen agrega después esos registros por proyecto, tenant, modelo y tipo de acelerador. Si una carga de trabajo utiliza ocho tarjetas durante diez horas, produce 80 horas de tarjeta según la definición de asignación simple.

La organización debe documentar si reporta tiempo asignado, tiempo activo o ambos. El origen admite la medición de horas de tarjeta pero no prescribe una fórmula comercial universal, por lo que la definición debe mantenerse coherente en todos los informes.

¿Cómo asignar el uso de tokens?

La capa de servicio de modelos del origen utiliza el API gateway para medir el uso de tokens por tenant, modelo y proyecto. Las claves de API se asocian a etiquetas de proyecto, por lo que cada llamada hereda la propiedad correspondiente.

El sistema puede agregar después:

• Uso de entrada y salida conforme a la definición del servicio
• Recuento de peticiones
• Recuento de tokens
• Modelo
• Proyecto
• Tenant
• Período temporal

Esto genera un registro de consumo de servicio directo. En un entorno MaaS, el registro de tokens suele ser la vía más limpia para atribuir el uso de servicios de inferencia a un responsable de negocio.

¿Cómo asignar el coste de energía?

El escenario de costes de proyectos del origen asocia la energía con la ocupación de recursos, y el modelo detallado de energía también contempla la energía de GPU y la energía unitaria por token. El origen no impone un método universal para distribuir cada coste de las instalaciones entre todos los proyectos.

Un enfoque coherente con el origen consiste en utilizar la energía de recursos medida o atribuible siempre que esté disponible y aplicar después la regla de asignación aprobada por la organización. Por ejemplo, la potencia de GPU se mide durante una tarea perteneciente al Proyecto A, y esa energía del acelerador puede vincularse al registro de uso del Proyecto A.

Si la organización aplica recargos por instalaciones generales como el PUE, dicha regla debe documentarse como un criterio de asignación adicional en lugar de mezclarse sin aviso con la energía bruta de la GPU.

Para las fórmulas, cómo un centro de datos puede calcular PUE, WUE, consumo energético de GPU y coste de energía por token explica la parte relativa a la medición.

¿Cómo asignar el coste de almacenamiento?

El escenario de costes de proyectos del origen incluye el uso de almacenamiento como una de las dimensiones de consumo. La asignación requiere una relación de almacenamiento identificable: una tarea de entrenamiento utiliza almacenamiento de datasets, una aplicación usa un volumen, un servicio de modelos carga archivos desde una ruta de almacenamiento, o un proyecto reserva un pool de almacenamiento.

La organización puede decidir qué métrica de almacenamiento determina el coste, ya sea capacidad, rendimiento, IOPS o una tarifa de servicio fija. El origen no define una fórmula universal para tarifar el almacenamiento, y este criterio mantiene claros esos límites. Lo que el origen sí respalda es la capacidad de conectar el almacenamiento con el proyecto e incluirlo en la vista de costes.

¿Cómo encajan los departamentos en el modelo?

El modelo de origen respalda directamente la jerarquía organizativa, personas, tenants, proyectos y relaciones de negocio. No define una "fórmula de asignación de costes por departamento" independiente.

Sin embargo, la consolidación departamental es viable cuando el departamento actúa como entidad principal del proyecto o tenant. Por ejemplo, el departamento de Investigación de IA puede ser titular del Proyecto A, Proyecto B y Proyecto C. Si el uso de cada proyecto se mide de forma coherente, el total departamental equivale a la suma de los proyectos asignados a ese departamento durante el período del informe.

Se trata de una deducción derivada del modelo de relaciones y no de una función especificada por separado en el origen, por lo que depende de un mapeo organizativo estable. Si los proyectos cambian de departamento, el sistema de informes debe registrar el período de vigencia para evitar que los costes históricos se reasignen de manera imprevista.

¿Cómo encajan las aplicaciones en el modelo de costes?

Las aplicaciones pueden convertirse en una dimensión de reporte cuando la topología del negocio conecta los servicios con los recursos y registros de consumo que los sustentan. La CMDB y el modelo de topología del origen vinculan sistema de negocio, aplicación, servicio de modelos, contenedor, recurso de computación, almacenamiento, red y propietario.

Esto permite asociar el uso de infraestructura a una aplicación cuando la relación no deja lugar a dudas. Por ejemplo, el Servicio de Inferencia IS1 respalda a la Aplicación A. IS1 produce 20 millones de tokens y consume una cantidad definida de tiempo de acelerador, registros que pueden consolidarse en la Aplicación A.

El origen no asegura que todo coste de infraestructura compartida pueda imputarse con precisión a una aplicación. Los costes de red e instalaciones compartidas pueden requerir un método de asignación acordado.

¿Cómo encajan los clientes en el modelo?

El material de origen contempla directamente tenants y proyectos. No proporciona un modelo universal de facturación a clientes externos, de modo que la agregación a nivel de cliente depende de cómo represente la empresa a dicho cliente.

Si cada cliente cuenta con un tenant, la medición a nivel de tenant puede funcionar como límite de coste del cliente. Si un único tenant atiende a varios clientes, la relación de servicio o proyecto necesita un identificador de cliente adicional.

La regla operativa más segura es evitar deducir la titularidad del cliente a partir del uso después de los hechos. Registra o asigna la identidad del cliente en la capa de servicio, proyecto, clave o tenant antes de que se produzca el consumo, lo que hace que los informes de clientes sean trazables.

¿Por qué importan las relaciones de la CMDB para los costes?

La atribución de costes a menudo requiere algo más que mediciones directas. Un registro de horas de GPU puede identificar el proyecto cuando la dirección busca el departamento, y un registro de servicio de modelos puede identificar el proyecto cuando finanzas necesita la aplicación o el cliente. El grafo de relaciones proporciona la ruta de agregación.

La base de datos de origen trata expresamente la CMDB como un cimiento compartido para monitoreo, planificación, medición y análisis de fallos. Por tanto, los costes deben reutilizar esas mismas relaciones de objetos en lugar de mantener una hoja de cálculo de propietarios independiente.

Para el modelo de relaciones, cómo una CMDB puede conectar servidores, GPU, contenedores, aplicaciones, servicios de negocio y propietarios explica cómo se enlazan estos elementos.

¿Cómo deben asignarse los costes compartidos?

Los costes compartidos exigen una regla explícita. El origen mide de forma directa el uso de proyectos y tenants para varios tipos de recursos, pero parte de la infraestructura se comparte entre múltiples usuarios, como el fabric de red, el almacenamiento compartido, los recargos energéticos de las instalaciones, el trabajo de operaciones y el coste de racks.

El origen no establece un método de asignación universal para estos conceptos. La empresa puede emplear un criterio pactado como horas de tarjeta, volumen de tokens, capacidad reservada, capacidad de almacenamiento, cuota de proyecto o una cuota fija.

Sea cual sea el criterio, debe resultar transparente. La asignación de costes compartidos debe identificarse como una regla de asignación y nunca presentarse como una medición directa.

¿Cómo conciliar los informes de costes?

Utiliza las mismas definiciones de propiedad y métricas en el consumo detallado, los informes de proyectos, los informes de tenants y cualquier salida de facturación. El modelo de origen insiste continuamente en la coherencia de las definiciones de datos.

El uso de tokens no debe atribuirse con una etiqueta de proyecto en el gateway y otro nombre de proyecto en finanzas. Las horas de tarjeta no deben emplear tiempo asignado en un informe y tiempo activo en otro sin etiquetas claras.

La conciliación debe revisar:

• Uso bruto total
• Uso atribuido
• Uso no atribuido
• Totales por proyecto
• Totales por tenant
• Totales por modelo
• Coherencia del período temporal

El uso no atribuido debe mantenerse visible. Representa un problema de calidad de datos y no debe camuflarse dentro de la categoría "otros".

¿Cómo pueden showback y chargeback usar los mismos datos?

Ambos enfoques pueden aprovechar el mismo modelo de medición y propiedad; la diferencia radica en el uso que la empresa da al resultado. El showback comunica el coste al responsable para ofrecer visibilidad, mientras que el chargeback aplica ese coste como una asignación financiera interna o externa real.

Los materiales de origen contemplan informes de costes de proyectos y tenants y "salidas de facturación", aunque no emplean expresamente los términos showback y chargeback.

Para profundizar en esta diferencia, qué es showback frente a chargeback en la gestión de costes de infraestructura de TI e IA explica cómo ambos modelos operativos se apoyan en la misma base de medición.

¿Qué debería mostrar un panel de atribución de costes?

Un panel útil puede mostrar:

• Coste total de infraestructura
• Horas de tarjeta aceleradora
• Uso de tokens
• Energía
• Uso de almacenamiento
• Coste de inactividad
• Coste por proyecto
• Coste por tenant
• Coste por modelo
• Coste por tipo de acelerador
• Uso no atribuido
• Consolidación de negocio donde esté mapeada

Cada total debe permitir desglosar hasta el registro de uso que lo originó.

Un ejemplo de plataforma que conecta proyecto, tenant, modelo, tipo de acelerador, horas de tarjeta, uso de tokens y costes es Sensaka.

Si tuviera que implementar la atribución de costes, empezaría por un requisito básico: cada registro de uso relevante debe incorporar una identidad estable de proyecto o tenant en el momento en que se genera. Los departamentos, aplicaciones y clientes pueden consolidarse después mediante el modelo de relaciones del negocio. Si falta la titularidad en el nivel de uso bruto, la asignación a final de mes se convierte en pura especulación.