Coste de infraestructura de IA por hora de GPU, Token, proyecto, tenant y modelo

Las empresas pueden medir el coste de la infraestructura de IA combinando la medición de recursos y la medición de servicios bajo el mismo modelo de propiedad. Las horas de acelerador miden cuánto tiempo permanece asignado un cómputo costoso, la medición de Tokens evalúa el consumo del servicio de modelos, y los identificadores de proyecto, tenant y modelo explican quién utilizó los recursos y qué generó el gasto.

La aritmética es sencilla; la asignación es donde la tarea se complica. Si el programador de tareas, la API gateway, el sistema energético y la facturación utilizan nombres de proyectos o ventanas de tiempo distintos, una misma carga de trabajo puede arrojar cifras de coste contradictorias. La contabilidad de costes necesita una definición compartida de recurso, propietario, ventana de uso y unidad.

¿Qué es una hora de GPU?

Una hora de GPU es una tarjeta aceleradora asignada o consumida durante una hora según la política de medición establecida. Un cálculo sencillo es:

GPU hours = Number of GPUs × Allocation time in hours

Si un trabajo de entrenamiento utiliza 8 GPUs durante 3 horas:

8 × 3 = 24 GPU hours

Esta métrica mide el tiempo del recurso, pero no mide automáticamente el trabajo útil. Un trabajo puede consumir 24 GPU hours mientras la utilización media se queda en solo un 40 por ciento. La distinción importa porque la capacidad reservada sigue teniendo valor económico aunque la carga de trabajo sea ineficiente, por lo que el sistema de costes debe registrar las horas de GPU y la utilización como métricas separadas.

Las horas de GPU responden a "¿Cuánta capacidad de aceleradores ocupó esta carga de trabajo?". La utilización responde a "¿Qué tan ocupado estuvo el acelerador mientras estuvo asignado?". Al juntar ambas, el coste de inactividad se hace visible.

¿Deben las horas de GPU usar tiempo asignado o tiempo activo?

Usa la definición que responda a tu pregunta de negocio y etiquétala con claridad. Las horas de GPU asignadas cuentan todo el período en el que la tarjeta está reservada para la carga de trabajo. Las horas de GPU activas cuentan únicamente el tiempo que cumple con una regla de actividad determinada.

Para la planificación de capacidad interna, las horas asignadas suelen ser más útiles, ya que el programador no pudo entregar esa misma tarjeta a otro tenant durante ese intervalo. Para el análisis de rendimiento, el tiempo activo muestra qué parte de la reserva realizó realmente trabajo útil. Para la facturación, manda el modelo comercial. Si un tenant reserva una GPU dedicada durante diez horas, cobrar solo por los momentos en que supera un umbral de utilización puede no reflejar la capacidad retenida para ese cliente.

Un modelo de informes práctico puede mostrar las horas de GPU asignadas, las horas de GPU activas estimadas, la tasa de inactividad y la utilización media en paralelo, separando el consumo de capacidad de la eficiencia.

¿Cómo se calcula el coste por hora de GPU?

El coste por hora de GPU es el gasto atribuido a la capacidad de aceleradores dividido entre las horas de GPU durante el mismo período. Una fórmula directa es:

Cost per GPU hour = Allocated accelerator-related cost / GPU hours

El numerador puede ser estricto o amplio. Un modelo estricto puede incluir únicamente la amortización del hardware y la electricidad. Uno más amplio puede abarcar:

• Amortización de aceleradores
• Coste del chasis del servidor
• Electricidad
• Sobrecoste de refrigeración
• Coste de rack o colocation
• Red
• Almacenamiento
• Software
• Mano de obra de operaciones
• Mantenimiento

Ningún numerador es universalmente correcto, pero debe ser coherente. Si llamas al resultado "coste totalmente cargado por hora de GPU", define cada categoría de gasto que incluye. Si lo llamas "coste de energía por hora de GPU", incluye exclusivamente la energía. Y evita comparar dos costes unitarios calculados con perímetros distintos.

¿Cómo encaja la medición de Tokens en el coste de infraestructura?

La medición de Tokens conecta la salida del servicio de modelos con la infraestructura que la produjo. Una plataforma de servicio de modelos puede registrar los Tokens de entrada y salida por proyecto, tenant, clave de API, modelo y ventana de tiempo, mientras que la capa de infraestructura registra las horas de acelerador, la energía y otros recursos consumidos en esa misma ventana.

Con ambos datos disponibles, el sistema puede calcular el coste por 1,000 Tokens, el coste por 1 millón de Tokens, el coste energético por Token, el coste de infraestructura por Token y el desglose de costes por modelo, proyecto y tenant. El coste de la IA deja de ser una cifra de equipamiento y pasa a ser un valor por unidad de servicio.

Para conocer la arquitectura de servicio que respalda estos registros, qué es MaaS y cómo funcionan juntos los repositorios de modelos, las instancias de inferencia, las API gateway y la medición de Tokens explica toda la cadena.

¿Cómo se calcula el coste por Token?

El coste por Token es el gasto atribuido a un servicio de modelos dividido entre el volumen de Tokens procesados por ese mismo servicio en la misma ventana de tiempo.

Supongamos que a un servicio de modelos se le asignan $600 de coste de infraestructura durante un día y procesa 300 millones de Tokens facturables:

$600 / 300,000,000 = $0.000002 per Token

Eso también se puede presentar como:

$2 per 1 million Tokens

El ejemplo es ilustrativo, y tu resultado dependerá enteramente del perímetro de costes y de la definición de Token elegida. Un sistema en producción debe definir cómo trata los Tokens de entrada frente a los de salida, las peticiones fallidas, los reintentos, los resultados en caché, la asignación de instancias compartidas, la zona horaria, el ciclo de facturación, la versión del modelo y la titularidad de proyectos y tenants. La cifra solo resulta útil cuando esa definición permanece estable.

¿Conviene tarificar por separado los Tokens de entrada y salida?

Es posible hacerlo, sobre todo cuando la generación de salida se comporta de forma muy diferente al procesamiento de entrada en términos de cómputo. Sin embargo, diferenciar precios es una decisión comercial y las operaciones de infraestructura no obligan a ello.

Como mínimo, registra los Tokens de entrada y salida por separado allí donde el sistema de servicio los exponga. Siempre podrás sumarlos después, pero no podrás desglosarlos a posteriori si nunca guardaste la distinción.

Mantener ambos ayuda además a explicar las variaciones de gasto. Supongamos que el número de peticiones no cambia pero la longitud media de salida se duplica. El volumen total de Tokens sube aunque la cantidad de llamadas sea idéntica, lo que puede disparar el cómputo de inferencia y el coste. Un panel que solo contara peticiones ocultaría la causa.

¿Cómo se asigna el coste por proyecto?

Vincula cada reserva de recursos y llamada de servicio a un identificador de proyecto estable. Para el entrenamiento, el planificador o el proceso de envío de tareas debe exigir la identificación del proyecto. Para la inferencia, la clave de API, la ruta de servicio, el tenant o la identidad de la aplicación deben asociarse a un proyecto.

Los recursos dedicados son sencillos de asignar. Los recursos compartidos requieren una regla de asignación documentada, basada en factores como el tiempo de reserva de GPU, el tiempo de ejecución real, el volumen de Tokens, el volumen de peticiones, la cuota de capacidad reservada o la cuota de utilización medida. Elige la regla que mejor refleje cómo se consume el recurso compartido y mantenla invariable entre períodos de notificación.

La plataforma debe conservar además los registros de uso en bruto para que finanzas u operaciones puedan justificar los resultados.

¿Cómo se asigna el coste por tenant?

La asignación por tenant funciona de la misma manera, situando al tenant como la dimensión de propiedad principal. Un tenant puede contener varios proyectos, por lo que el modelo de datos debe admitir una jerarquía. Por ejemplo:

• Tenant A
  • Project A1
  • Project A2
  • Model Service A
  • Training Job A3

Los costes pueden desglosarse entonces en cada nivel sin duplicar el cómputo de uso. Si el Project A1 consume 100 horas de GPU y el Project A2 consume 50, el total del tenant es 150, y el consumo de Tokens se acumula del mismo modo.

Por eso resulta imprescindible un modelo común de propiedad. Evita que el programador de tareas use nombres de departamentos mientras la pasarela usa ID de cuenta y finanzas emplea otro código de proyecto distinto sin ninguna correspondencia entre ellos.

¿Cómo se asigna el coste por modelo?

El coste a nivel de modelo requiere una relación entre la versión del modelo, sus instancias de inferencia y el cómputo que consumen. En instancias de modelos dedicadas esto resulta simple: si el Model X ocupa cuatro GPU durante diez horas, esas 40 horas de GPU se pueden atribuir directamente.

El servicio compartido es más complejo. Si varios modelos comparten un mismo acelerador, la plataforma necesita una regla de asignación basada en tiempo de ejecución, volumen de Tokens, cuota reservada u otro factor medible.

El coste por modelo también debe incluir contexto sobre la calidad del servicio. Un modelo más barato no es mejor automáticamente si no cumple el SLO requerido o si genera resultados con una calidad inaceptable. El coste y la calidad del servicio son dimensiones operativas distintas, y la comparación relevante es el coste al nivel de calidad exigido.

¿Cómo debe incluirse la energía?

Utiliza la potencia medida del servidor o acelerador donde esté disponible, con una regla transparente para los consumos generales de la instalación. A nivel de acelerador, integra la potencia a lo largo del tiempo para obtener kWh. A nivel de servidor, recurre a la telemetría del equipo. Para estimar la energía atribuible a la instalación, puedes aplicar un factor documentado como una medición pertinente de PUE, siempre que lo indiques como método de asignación. Aplica después la tarifa eléctrica correspondiente a esa ventana temporal.

Esto cobra importancia cuando el precio de la electricidad varía a lo largo del día. Un trabajo de entrenamiento flexible que se ejecuta en horas valle puede costar menos en energía a pesar de utilizar el mismo número de horas de GPU.

Para consultar las fórmulas, cómo un centro de datos puede calcular PUE, WUE, consumo de energía de GPU y coste de energía por Token detalla el procedimiento completo.

¿Cómo se mide el coste de inactividad?

El coste de inactividad es el gasto de la capacidad asignada o en propiedad que no produce la cantidad esperada de trabajo útil, según la propia definición de la organización. Por tanto, empieza por definir qué es inactividad. Una tarjeta sin asignar es un tipo, una tarjeta asignada a una tarea con un 5 por ciento de utilización es otro, una tarjeta a la espera de almacenamiento es un tercero, y un pool fragmentado con tarjetas libres que no bastan para atender ninguna tarea en cola es otro más.

Estas causas no deben agruparse en un número único para culpar a los usuarios. Clasifica el motivo de la inactividad donde te sea posible, por ejemplo:

• Falta de demanda
• Restricción de cuota
• Fragmentación
• Cuello de botella de red
• Cuello de botella de almacenamiento
• Carga de datos
• Hardware degradado
• Solicitud de recursos sobredimensionada

Calcula después las horas de acelerador y la energía vinculadas a cada causa. Un indicador de tasa de inactividad se transforma así en una lista de trabajo para optimizar.

¿Cómo deben asignarse los costes de infraestructura compartida?

Los costes compartidos, con la red y el almacenamiento como ejemplos típicos, deben apoyarse en un criterio de asignación estable, comprensible y difícil de manipular. Los criterios posibles incluyen el ancho de banda consumido, la capacidad de almacenamiento reservada, el volumen de E/S, las horas de GPU, la cuota por proyecto o un cargo base fijo complementado con uso variable.

No existe un método óptimo único. Lo fundamental es si la asignación ayuda a tomar una decisión. Si el coste de almacenamiento es mínimo frente al de las GPU, una asignación compleja basada en IOPS puede generar más carga administrativa que beneficio real. Si el almacenamiento representa un gasto significativo y ciertos proyectos consumen una cuota desproporcionada de ancho de banda, una regla más minuciosa estará justificada. Empieza de forma simple y añade precisión solo cuando el resultado altere una decisión real.

¿Cómo deben conectarse los datos de coste con las cuotas?

Las definiciones de coste y cuota deben compartir el mismo modelo de recursos. Si un tenant dispone de una cuota de ocho GPU con memoria alta, el sistema de medición debe identificar exactamente los mismos recursos de forma coherente. Si el sistema de cuotas trata una GPU particionada como un recurso completo mientras facturación la computa como una fracción, documenta la conversión, ya que las definiciones divergentes generan disputas.

El modelo operativo de origen subraya esto expresamente: las horas de acelerador, el consumo de energía y la medición de Tokens necesitan criterios de asignación alineados para que los distintos módulos no produzcan datos discordantes. Eso convierte el problema tanto en un asunto de gobernanza del dato como de facturación.

¿Qué debe mostrar un panel de costes de IA?

Un panel de costes eficaz presenta de forma conjunta el gasto, el uso, la eficiencia y la propiedad. Como mínimo:

• Total de horas de acelerador
• Capacidad disponible frente a capacidad asignada
• Tasa de inactividad
• Coste por hora de GPU
• Volumen de Tokens
• Coste por Token
• Consumo de energía
• Clasificación de proyectos
• Clasificación de tenants
• Clasificación de modelos
• Tipo de recurso o modelo de acelerador
• Tendencia en el tiempo

Cada dato de resumen debe permitir profundizar hasta los registros de uso que lo originaron.

Un ejemplo de plataforma que emplea un modelo de medición compartido entre proyectos, tenants, modelos y aceleradores es Sensaka.

Si tuviera que diseñar la contabilidad de costes de IA, empezaría con una sola regla: cada hora de GPU y cada Token deben incluir un propietario y un intervalo de tiempo. Una vez asegurado eso, informar por proyecto, tenant y modelo es un problema de agrupación. Sin esa base, hasta el panel de costes más vistoso será poco más que una estimación.