FinOps y multi-tenancy del cluster GPU: quién paga qué

Thu, 11 Jun 2026 12:20:00 +0000

Tercera entrega de una serie operativa sobre cómo exprimir un cluster de inferencia LLM on-premise genérico de 4×H100 SXM 80 GB. Las piezas hermanas son Multimodal VLM on-premise con vLLM —servir modelos visión-lenguaje en el mismo cluster— y Acelerar el cold start con Tensorizer —recortar el tiempo de carga del modelo del disco a la HBM—. Este post cierra la pregunta económica que las otras dos dejan abierta: una vez que el cluster sirve varios modelos para varios equipos, ¿quién paga qué?

TL;DR

Un cluster GPU on-premise no tiene la propiedad que hace fácil el FinOps en cloud: no llega ninguna factura mensual que diga cuánto costó cada hora de cómputo. El coste hay que fabricarlo desde el capex y la energía. La unidad correcta es el token, y se deriva en dos pasos. Primero el €/GPU-hora: la amortización del capex repartida sobre las horas de vida útil, más la energía (potencia × PUE × precio_kWh). Para una H100 SXM con un capex supuesto de 30 000 € y 4 años de vida a 90 % de disponibilidad, sale ≈ 1,07 €/GPU-hora (0,95 de amortización + 0,12 de energía a 0,12 €/kWh y PUE 1,4). Segundo, el €/1M tokens: dividir ese €/GPU-hora entre el throughput sostenido. A 2 000 tok/s útiles, ≈ 0,148 €/1M tokens; pero ese número solo vale si la GPU está al 100 % de utilización útil. A 20 % de utilización el mismo token cuesta 4× más (0,74 €/1M), porque el capex y la energía se siguen pagando aunque la GPU esté ociosa. Esa es la tesis central: el objetivo FinOps no es negociar a la baja el precio del token —no hay proveedor con quien negociar— sino subir la utilización útil, que es el único término que mueve el coste por orden de magnitud. La atribución (chargeback / showback) se materializa con claves virtuales de LiteLLM: presupuesto por equipo y por usuario, rate-limit RPM/TPM, spend tracking automático y tags para asignar gasto a centros de coste. El aislamiento entre tenants se consigue con MIG (partición dura de la GPU), namespaces, ResourceQuota y PriorityClass. La regla de la FinOps Foundation que conviene grabar: showback siempre, chargeback solo si la política contable de la organización lo soporta; ninguno de los dos es “más maduro”. Y la métrica de gobierno del cluster compartido no es el €/token sino DCGM_FI_DEV_GPU_UTIL.

El problema que el cloud te oculta y on-premise te obliga a resolver

En cloud, el coste de una GPU es un hecho observable: AWS, GCP o Azure te cobran por GPU-hora y la factura llega desglosada. El FinOps en ese mundo consiste en leer una factura que ya existe y atribuirla. On-premise no existe esa factura. La GPU se compró una vez, hace dieciocho meses, con una orden de compra que ya nadie recuerda; el recibo de la luz llega al edificio entero sin desglosar qué fracción fue del cluster; y el PUE del datacenter es un número que el equipo de instalaciones conoce pero el de IA nunca preguntó.

El primer trabajo de FinOps on-premise, entonces, no es atribuir un coste sino fabricarlo. Hay que construir, desde supuestos explícitos, el equivalente al “precio por GPU-hora” que en cloud viene dado. Y una vez fabricado, hay que entender que ese número no es una propiedad del hardware —como la VRAM o el TDP— sino una función de cómo se usa el hardware. Una H100 ociosa cuesta exactamente lo mismo que una H100 al 100 %: el capex ya está pagado y la energía en idle no es cero. Lo único que cambia es cuántos tokens útiles produjo ese coste fijo. De ahí toda la tesis del post.

La analogía: el coworking con servicios medidos

Un coworking gestiona un espacio físico finito y lo alquila a equipos. El modelo de costes tiene exactamente la estructura del cluster GPU, y la analogía sostiene hasta el último detalle.

El puesto-hora es el capex repartido. El gestor pagó el alquiler del local, los muebles y la reforma —un desembolso único o un coste fijo mensual— y lo reparte sobre las horas-puesto disponibles del mes. Cada puesto tiene un coste base que no depende de si alguien lo usa: las paredes, la mesa y la silla cuestan lo mismo vacías que ocupadas. Esto es la amortización de la GPU: el capex dividido entre las horas de vida útil.

El kWh medido es la energía. Encima del puesto-hora, el coworking mide el consumo eléctrico real —el portátil enchufado, la pantalla, el aire acondicionado de esa sala— y lo factura aparte. Esto es la energía de la GPU: potencia × horas × precio_kWh, multiplicada por el PUE del datacenter, que es el coworking cobrándote también la fracción del aire acondicionado del edificio que enfría tu sala.

El puesto vacío lo paga quien lo reservó. Aquí está el corazón del asunto. Si un equipo reserva diez puestos para todo el mes y solo usa dos, paga los diez igual. El puesto vacío sigue ocupando espacio que el gestor no puede revender, sigue amortizando muebles, sigue contando como capacidad comprometida. En el cluster: una GPU asignada a un tenant que la usa al 20 % cuesta lo mismo que si la usara al 100 %, y el 80 % ocioso es capex desperdiciado que alguien está pagando.

El gestor optimiza ocupación, no tarifa. Un gestor de coworking competente no se obsesiona con bajar el precio del puesto-hora —es un coste hundido, ya pagó el local—. Se obsesiona con la tasa de ocupación: cada puesto vacío es margen perdido para siempre, porque una hora-puesto no vendida no se puede almacenar. El equivalente FinOps: el objetivo no es bajar el €/token, es subir la utilización, porque el €/token cae sólo como consecuencia de que la utilización sube. No hay un proveedor a quien apretar; el único margen está en no dejar GPUs ociosas.

La analogía tiene un límite honesto que conviene nombrar: en el coworking, dos personas no pueden compartir físicamente la misma silla. En la GPU sí se puede —con time-slicing, MPS o MIG (ver Compartir una GPU)—, y esa es justamente la palanca técnica que permite subir la ocupación por encima de lo que el coworking físico permitiría. Pero la economía del coste fijo + medido es idéntica.

El token como unidad de coste

¿Por qué el token y no la GPU-hora, o la request, o el modelo? Porque el token es la única unidad que es comparable entre workloads heterogéneos. Una GPU-hora de Llama 8B y una de Llama 70B producen cantidades de “trabajo útil” radicalmente distintas; una request de RAG con respuesta de 50 tokens y una de generación de un informe de 3 000 no son comparables. El token —concretamente el par (input_tokens, output_tokens)— normaliza todo eso. Es la unidad que LiteLLM contabiliza nativamente, la que aparece en los atributos OTel gen_ai.usage.input_tokens y gen_ai.usage.output_tokens (ver Tracing LLM con OpenTelemetry GenAI), y la que los proveedores comerciales ya usan para cobrar. Adoptar el token como moneda interna hace que el chargeback on-premise sea directamente comparable con la alternativa cloud, que es justo la comparación que la dirección quiere ver.

Las dos métricas derivadas que importan:

Tokens/€ — cuántos tokens útiles compra cada euro de coste total del cluster. Sube cuando la utilización sube. Es la métrica de eficiencia económica.
Tokens/W — cuántos tokens produce cada vatio consumido. Es la métrica de eficiencia energética y, en un datacenter con potencia limitada (lo habitual on-premise), suele ser la restricción dura real: no puedes meter más GPUs porque no hay más kW en el rack, así que cada vatio tiene que rendir.

Modelo de coste de una GPU: del capex al €/token

El coste por hora de una GPU tiene dos sumandos. Pongamos todos los supuestos por escrito, porque —como en el capacity planning— un cálculo de coste sin supuestos escritos es un cálculo desechable.

Amortización (capex repartido)

$$\text{coste amort/h} = \frac{\text{capex}_{\text{GPU}}}{\text{horas vida útil}}$$

donde las horas de vida útil son los años de amortización × 8 760 h/año × la disponibilidad efectiva (la GPU no está disponible el 100 % del tiempo: hay mantenimiento, reinicios, ventanas de actualización). Supuestos explícitos, genéricos (no son cifras de ningún proveedor ni de ninguna compra real):

Capex por GPU: 30 000 € — supuesto razonable que incluye no solo la GPU sino su parte alícuota del servidor, fuente, refrigeración, red NVLink/InfiniBand y rack. Una H100 SXM “desnuda” cuesta menos, pero el FinOps honesto reparte el coste del nodo entero entre sus GPUs.
Vida útil contable: 4 años. Es agresivo-realista para GPU de datacenter; algunos amortizan a 3, otros a 5.
Disponibilidad efectiva: 90 %.

$$\text{horas vida} = 4 \times 8,760 \times 0{,}90 = 31,536 \text{ h}$$

$$\text{coste amort/h} = \frac{30,000}{31,536} \approx 0{,}95 \text{ €/GPU-hora}$$

Energía (potencia × PUE × precio_kWh)

$$\text{coste energía/h} = P_{\text{GPU}} \cdot \text{PUE} \cdot \text{precio kWh}$$

Supuestos:

Potencia de la GPU: el TDP de la H100 SXM es 700 W según el datasheet de NVIDIA (H100 datasheet). En carga sostenida de inferencia ronda ese valor; usamos 0,7 kW como potencia media en carga. (En idle baja mucho —60–100 W— pero el FinOps de capacidad reservada razona sobre la potencia en carga, que es la que limita el rack.)
PUE (Power Usage Effectiveness): cuántos vatios entran al datacenter por cada vatio que llega al chip. Un datacenter on-premise modesto bien gestionado está en 1,4; uno malo, en 2,0; los hiperescalares presumen de 1,1. Usamos 1,4.
Precio del kWh: 0,12 €/kWh — supuesto genérico de tarifa industrial; varía enormemente por país y contrato.

$$\text{coste energía/h} = 0{,}7 \cdot 1{,}4 \cdot 0{,}12 \approx 0{,}1176 \approx 0{,}12 \text{ €/GPU-hora}$$

El €/GPU-hora total

$$\boxed{\text{€/GPU-hora} = 0{,}95 + 0{,}12 \approx 1{,}07 \text{ €/GPU-hora}}$$

Dos lecturas importantes de este número. Primero: la amortización domina (89 % del coste); la energía es el 11 %. Esto invierte la intuición de mucha gente, que cree que “lo caro es la luz”. Con estos supuestos, lo caro es haber comprado la GPU, y por eso dejarla ociosa duele tanto. Segundo: el número es per-GPU; para el nodo de 4×H100 son ≈ 4,28 €/hora, y para el cluster genérico completo de 4 nodos (16 GPUs), ≈ 17,1 €/hora ≈ 150 000 €/año de coste fijo que se paga se use o no se use.

De €/GPU-hora a €/token

Ahora dividimos el coste horario entre los tokens que la GPU produce en una hora. Aquí entra el throughput sostenido. Supongamos —cifra de orden de magnitud, validable con vllm bench serve— que una réplica de Llama 70B sobre 4×H100 (TP=4) sostiene 2 000 tokens/s útiles agregados en régimen de buena concurrencia.

$$\text{tokens/hora} = 2,000 \times 3,600 = 7{,}2 \times 10^6 \text{ tok/h}$$

El coste de esa réplica (4 GPUs) es $4 \times 1{,}07 = 4{,}28$ €/hora. Por tanto:

$$\text{€/1M tokens} = \frac{4{,}28}{7{,}2} \approx 0{,}59 \text{ €/1M tokens}$$

Por GPU individual, si tomamos una réplica más pequeña (p.ej. Llama 8B FP8 en 1 GPU a ~2 000 tok/s):

$$\text{€/1M tokens} = \frac{1{,}07 \text{ €/h}}{7{,}2 \times 10^6 \text{ tok/h}} \times 10^6 \approx 0{,}149 \text{ €/1M tokens}$$

Estos números son el suelo teórico al 100 % de utilización. Nadie opera al 100 %. Y ahí está toda la historia.

La utilización es la palanca (con números)

El €/token de la sección anterior asume que la GPU produce 7,2 M tokens cada hora, hora tras hora. En la práctica produce eso solo en las horas pico. El resto del tiempo está parcialmente ociosa: de noche, los fines de semana, entre picos de tráfico. La utilización útil $u$ es la fracción de la capacidad teórica que de verdad se convierte en tokens facturables.

El coste horario es fijo (1,07 €/GPU-hora se paga llueva o truene), pero los tokens producidos escalan con $u$:

$$\text{€/1M tokens}(u) = \frac{\text{€/GPU-hora}}{\text{tok máx/hora} \cdot u} = \frac{1{,}07}{7{,}2 \times 10^6 \cdot u} \times 10^6 = \frac{0{,}149}{u}$$

El contraste pedido, trabajado:

Utilización útil $u$	Tokens/h reales	€/1M tokens	Multiplicador vs 80 %
100 %	7,2 M	0,149 €	0,80×
80 %	5,76 M	0,186 €	1,00× (referencia)
50 %	3,6 M	0,298 €	1,60×
20 %	1,44 M	0,744 €	4,00×
10 %	0,72 M	1,488 €	8,00×

Lectura directa: pasar de 20 % a 80 % de utilización divide el coste por token entre cuatro ($0{,}744 \to 0{,}186$). Ninguna negociación de tarifa, ninguna quantization, ningún cambio de hardware da ese factor 4 tan barato. La quantization de BF16 a FP8 puede duplicar el throughput —y por tanto reduce el €/token a la mitad— pero degrada calidad y exige evals (ver Quantization para inferencia); subir la utilización del 20 al 80 % no toca la calidad de un solo token.

Esto reformula el FinOps del cluster GPU en una sola frase: el €/token no es algo que se negocia, es algo que se gana llenando las GPUs. Y subir la utilización es un problema de ingeniería que ya tiene piezas:

Autoscaling que apaga réplicas cuando el tráfico baja, para no pagar GPU ociosa (ver Autoscaling LLM en Kubernetes con KEDA). Apagar una réplica de 4 GPUs ocho horas por la noche ahorra ≈ 34 € diarios de coste real; multiplicado por réplicas y por días, es la diferencia entre un cluster rentable y uno que sangra.
Compartir GPU entre workloads pequeños con MIG o time-slicing, para que dos tenants que individualmente usarían el 30 % llenen juntos una GPU al 60 % (ver Compartir una GPU).
Batch nocturno que llena las horas-valle con trabajo no urgente (re-embeddings, evals, fine-tune ligero) en vez de dejar las GPUs apagadas o al ralentí.
Reducir el cold start para que escalar a cero y volver a arrancar sea barato y, por tanto, viable como estrategia de utilización (ver la pieza hermana Acelerar el cold start con Tensorizer).

El diagrama: la cascada del €/token según utilización

El coste por token no es un número, es una cascada que se multiplica conforme la utilización cae:

Atribuir el coste: claves virtuales de LiteLLM

Fabricado el €/token, falta atribuirlo a quien lo consumió. La pieza que ya está delante de los motores —el router de inferencia L7— es también el lugar natural para contar. LiteLLM Proxy materializa el chargeback con cuatro mecanismos, todos documentados:

Claves virtuales con presupuesto. Cada equipo o usuario recibe una virtual key con un max_budget y un budget_duration. Se pueden definir varias ventanas de presupuesto independientes (p.ej. una de 24 h y otra de 30 d) que se resetean en su propio ciclo (Virtual Keys). Cuando un equipo agota su presupuesto mensual de tokens, el proxy rechaza con error de presupuesto excedido en vez de seguir gastando GPU-horas que nadie va a poder cargar a ningún sitio.

Rate-limit RPM/TPM. Cada clave lleva límites de requests por minuto (RPM) y tokens por minuto (TPM) (Budgets, Rate Limits). Esto no es solo protección anti-abuso: es la herramienta para que un tenant ruidoso no acapare la utilización del cluster a costa de los demás. El rate-limit es la cuota de capacidad; el budget es la cuota de gasto. Son ortogonales y se usan las dos.

Spend tracking automático. LiteLLM contabiliza el gasto de todos los modelos conocidos por clave, usuario y equipo, registrando la API key, el usuario, el team_id, los tags de la request, el end-user, el grupo de modelo y los conteos de tokens (Spend Tracking). Para los modelos self-hosted del cluster, el coste por token se configura con el €/token que fabricamos arriba —ese es el enganche entre el modelo de coste y la contabilidad real—.

Tags para centros de coste. Los tags permiten rastrear gasto y poner presupuestos por etiqueta, categorizando costes por proyecto, departamento o centro de coste (Setting Tag Budgets). Un tag se adjunta al crear la clave y toda request hecha con esa clave hereda el tag automáticamente; el proxy aplica el presupuesto de la etiqueta. Así el chargeback se mapea limpiamente sobre la jerarquía contable de la organización sin que cada equipo tenga que recordar etiquetar a mano.

Un fragmento de catálogo declarativo —encaja en el litellm-config del post del router— que materializa el coste fabricado y dos tenants:

litellm_settings:
 # €/token fabricado en este post para el modelo self-hosted.
 # input/output en €/token (no por 1M); 0,186 €/1M = 1.86e-7 €/token a u=80%.
 model_cost_map:
 llama-70b-onprem:
 input_cost_per_token: 0.000000186
 output_cost_per_token: 0.000000186

# Claves virtuales por equipo (vía API /key/generate o config):
# equipo-datos: max_budget=500 €/mes, tpm_limit=200000, tags=["cc-datos"]
# equipo-soporte: max_budget=150 €/mes, tpm_limit=60000, tags=["cc-soporte"]
# El proxy cuenta tokens, multiplica por model_cost_map, descuenta del budget,
# y atribuye el gasto al tag → showback por centro de coste, sin tocar el motor.

El flujo completo de atribución, de la request al informe por equipo:

Showback vs chargeback: la distinción que la FinOps Foundation insiste

Las dos palabras se confunden constantemente y la diferencia es de formalidad contable, no de tecnología:

Showback — dar a cada equipo visibilidad de lo que consumió y su coste, sin facturarlo de verdad a su presupuesto. El informe llega, el equipo lo ve, pero el dinero no se mueve entre centros de coste.
Chargeback — transferir de verdad el coste al presupuesto del equipo o producto, poniéndolo en su P&L. El gasto deja de ser un coste central de IT y pasa a ser un coste imputado.

La FinOps Foundation es explícita en dos puntos que conviene grabar (Invoicing & Chargeback, Chargeback vs Showback). Primero: el showback es requisito de cualquier práctica FinOps; el chargeback depende de la política contable de la organización. No todas las organizaciones pueden o quieren mover dinero entre departamentos por consumo de GPU; el showback siempre se puede. Segundo, y contraintuitivo: ninguno de los dos es “más maduro” que el otro. La narrativa de que el chargeback es la versión “adulta” del showback es falsa según el propio framework. La recomendación práctica: empezar por showback —dar visibilidad—, luego construir la asignación de costes alineada a la jerarquía organizativa, y solo entonces, si la política contable lo soporta, activar chargeback.

Para el cluster GPU on-premise esto significa: la máquina de LiteLLM (claves, tags, spend tracking) produce siempre el showback. Convertirlo en chargeback es una decisión de la dirección financiera, no del equipo de plataforma. El equipo de plataforma garantiza que los números son correctos y reproducibles; quién paga de verdad es una decisión de gobierno.

Aislamiento: que el coste sea atribuible de verdad

El chargeback solo es honesto si el consumo es aislable. Si dos tenants comparten una GPU sin partición y uno satura la HBM, el otro sufre degradación que no causó pero que contamina su atribución de coste. El aislamiento tiene dos planos.

Aislamiento duro de la GPU: MIG. Multi-Instance GPU particiona físicamente una H100 en hasta 7 instancias con memoria y SMs dedicados; en partición 7-way cada instancia tiene ~10 GB de HBM3 y SMs propios. MIG da el aislamiento más fuerte: el tenant A en su instancia MIG no puede tocar el rendimiento del tenant B, y la atribución es trivial porque cada instancia es contable por separado (ver Compartir una GPU para el detalle de MIG vs time-slicing vs MPS). El coste: las instancias MIG son fijas, no se redimensionan en caliente, y si quedan vacías es capex fragmentado y desperdiciado —el puesto de coworking subdividido en cabinas que nadie alquila—.

Aislamiento lógico de Kubernetes. Sobre el cluster:

Namespaces por tenant — frontera de RBAC, NetworkPolicy y cuotas.
ResourceQuota — limita cuántos nvidia.com/gpu (o nvidia.com/mig-1g.10gb) puede pedir un namespace. Es la cuota de capacidad GPU a nivel de scheduler: el tenant no puede reclamar más GPUs de las que su cuota le concede, lo que acota su coste máximo por construcción.
PriorityClass — define qué workloads pueden expulsar a otros bajo presión. El batch nocturno de re-embeddings corre con prioridad baja y cede ante la inferencia interactiva; así llena los valles de utilización sin arriesgar el SLO del tenant de pago. Es la pieza que hace que “subir la utilización con batch” no canibalice la calidad de servicio.

La combinación que funciona en el cluster genérico: MIG para particionar las GPUs entre tenants que necesitan aislamiento duro y atribución limpia, ResourceQuota por namespace para acotar el coste de cada tenant, y PriorityClass para que el trabajo de relleno suba la utilización sin tocar a los tenants prioritarios.

Aplicado al cluster genérico 4×H100

Bajemos todo al cluster de la serie: 4 nodos × 4×H100 SXM 80 GB, 16 GPUs, ≈ 17,1 €/hora de coste fijo (≈ 150 000 €/año). Tres equipos lo comparten: Datos (RAG productivo, tráfico de oficina), Soporte (asistente de tickets, picos diurnos) y Plataforma (batch de evals y re-embeddings, sin urgencia).

Reparto del coste. El coste fijo del cluster (150 000 €/año) se reparte vía el spend tracking de LiteLLM en proporción a los tokens consumidos por cada equipo, valorados al €/token fabricado. Si en un mes Datos consumió 1 700 M tokens, Soporte 480 M y Plataforma 320 M, a 0,186 €/1M el showback es ≈ 316 € / 89 € / 60 €. El residuo —el coste fijo de las GPUs que nadie usó porque la utilización media fue, digamos, del 45 %— es el coste de ociosidad, y la decisión de gobierno es si se reparte entre los tenants (penaliza a todos por igual) o se imputa a Plataforma como “coste de capacidad no vendida” (incentiva a Plataforma a subir la utilización). La FinOps Foundation diría: hazlo visible primero (showback del coste de ociosidad), decide el reparto después.

Cuotas por tenant. Cada equipo tiene su namespace con ResourceQuota: Datos puede reclamar hasta 8 GPUs (2 réplicas TP=4), Soporte hasta 4, Plataforma hasta 4 pero con PriorityClass baja —cede sus GPUs cuando Datos o Soporte las necesitan en pico—. En LiteLLM, cada equipo tiene su clave virtual con max_budget mensual y tpm_limit que refleja su cuota de capacidad.

MIG para aislar y atribuir. Para los modelos pequeños (embeddings, reranker, un Llama 8B de utilidad), una H100 partida en MIG 7-way da siete instancias atribuibles por separado: tres para embeddings de Datos, dos para el reranker de Soporte, dos libres para relleno. Cada instancia es un “puesto” contable independiente; el showback por tenant sale directo del scheduler.

La métrica de gobierno es la utilización, no el €/token. Aquí cerramos el círculo. El KPI que el responsable del cluster debe mirar a diario no es “cuánto cuesta el token” —ese número solo baja como consecuencia— sino DCGM_FI_DEV_GPU_UTIL, la métrica del DCGM exporter que indica qué fracción del tiempo la GPU no está ociosa (DCGM exporter). Y con un matiz crítico que ya aparecía en capacity planning: DCGM_FI_DEV_GPU_UTIL mide “no idle”, no mide trabajo útil. Una GPU puede marcar 100 % de GPU-util con la HBM saturada y la SM occupancy baja, produciendo pocos tokens. Por eso el FinOps serio cruza tres señales: DCGM_FI_DEV_GPU_UTIL (¿está la GPU ocupada?), DCGM_FI_PROF_SM_OCCUPANCY y DCGM_FI_PROF_GR_ENGINE_ACTIVE (¿está haciendo trabajo real?), y vllm:gpu_cache_usage_perc (¿está la HBM bien aprovechada?). La métrica económica de gobierno es tokens útiles por GPU-hora, y se vigila desde el panel de observabilidad GPU con DCGM.

Un detalle de montaje end-to-end —LibreChat sobre LiteLLM con RAG, que cierra el flujo de tenant a coste— se trata en el artículo (en preparación) sobre el asistente soberano end-to-end; aquí basta saber que el punto de cobro es siempre el proxy, nunca el motor.

Cuatro trampas del FinOps GPU on-premise

Trampa 1 — comparar el €/token on-premise con el de la API comercial al precio de lista. La API comercial tiene márgenes, SLA y escala que el cluster on-premise no, pero el on-premise tiene el coste de ociosidad que la API te esconde (ellos llenan sus GPUs con miles de clientes). La comparación honesta es on-premise a su utilización real vs API a precio real negociado, no la fantasía de on-premise al 100 %.

Trampa 2 — olvidar el coste de ociosidad en el showback. Si solo cargas a los equipos los tokens que consumieron, el coste de las GPUs ociosas desaparece del informe y nadie lo ve. Ese coste existe y alguien lo paga. Hacerlo visible es el primer paso para reducirlo.

Trampa 3 — confundir GPU-util alto con eficiencia. Una GPU al 100 % de DCGM_FI_DEV_GPU_UTIL con la HBM saturada y poca SM occupancy gasta capex sin producir tokens proporcionales. El objetivo no es “GPU al 100 %”, es “tokens útiles por euro”. Cruzar siempre util con SM occupancy y throughput real.

Trampa 4 — chargeback antes que showback. Activar chargeback —mover dinero— antes de que los equipos confíen en que los números son correctos genera disputas que queman el programa FinOps entero. Primero visibilidad, luego confianza en los datos, luego —si la política contable lo permite— el dinero.

Ver también

Multimodal VLM on-premise con vLLM — pieza hermana: servir modelos visión-lenguaje en el mismo cluster compartido cuyo coste aquí atribuimos.
Acelerar el cold start con Tensorizer — pieza hermana: recortar el tiempo de carga del modelo hace viable escalar a cero, que es la palanca de utilización más directa.
Capacity planning para inferencia LLM on-premise — el throughput sostenido del que sale el €/token se calcula allí; el FinOps lo monetiza.
Compartir una GPU: time-slicing, MPS y MIG — la partición que permite aislar tenants y subir la utilización combinando workloads pequeños.
El router de inferencia LLM: la centralita L7 — el lugar donde vive LiteLLM y donde se cuenta y atribuye cada token.
Autoscaling LLM en Kubernetes con KEDA — apagar réplicas ociosas es la palanca número uno para subir la utilización útil y bajar el €/token.
Observabilidad GPU para inferencia LLM con DCGM — de dónde sale DCGM_FI_DEV_GPU_UTIL, la métrica de gobierno del cluster compartido.

Referencias

NVIDIA — H100 Tensor Core GPU Datasheet (TDP 700 W, HBM3 3,35 TB/s): resources.nvidia.com/en-us-gpu-resources/h100-datasheet-24306.
LiteLLM — Virtual Keys (docs.litellm.ai/docs/proxy/virtual_keys), Budgets & Rate Limits (/docs/proxy/users), Spend Tracking (/docs/proxy/cost_tracking), Setting Tag Budgets (/docs/proxy/tag_budgets), Team Budgets (/docs/proxy/team_budgets).
FinOps Foundation — Invoicing & Chargeback Capability (finops.org/framework/capabilities/invoicing-chargeback/) y Data Analysis and Showback (finops.org/framework/previous-capabilities/analysis-showback/).
CloudZero — Chargeback vs. Showback: Cloud Cost Allocation Models Explained (cloudzero.com/blog/chargeback-vs-showback/).
NVIDIA — DCGM Exporter (docs.nvidia.com/datacenter/dcgm/latest/gpu-telemetry/dcgm-exporter.html): DCGM_FI_DEV_GPU_UTIL, DCGM_FI_PROF_SM_OCCUPANCY, DCGM_FI_PROF_GR_ENGINE_ACTIVE.

Chargeback on lo0 — Blog Técnico