FinOps de GPU/LLM: frameworks, métricas y estado del arte (ficha a ficha)

Sat, 13 Jun 2026 03:00:00 +0200

Notación: importes en euros (N €), decimales con coma. Las referencias son europeas (proveedores y precios de FR/DE/ES), por tratarse de una propuesta soberana; cuando una fuente cita dólares se indica “USD”. No se usa el símbolo de dólar (en este sitio es delimitador de fórmula).

Qué cubre esta introducción

Segundo artículo de la serie de datos, y primer deep dive de pilar. Aquí se inventaría el tooling de FinOps para infraestructura GPU/LLM con el detalle que necesita una decisión de arquitectura: qué métricas maneja cada herramienta, cómo asigna el coste por dentro, qué soporte de GPU tiene, bajo qué licencia y modelo de precio opera, y dónde están sus límites. Es la continuación natural del artículo de apertura, donde se fijó que el coste por token es la unidad que permite comparar on-prem vs cloud. Sin recomendaciones: la elección final se decide en el artículo de síntesis con la tabla de Pareto; aquí solo están los hechos y la metodología.

Por qué el FinOps de GPU es un problema distinto

El FinOps clásico de cloud nació para repartir CPU, memoria y almacenamiento, recursos baratos y elásticos. La GPU rompe tres supuestos a la vez, y por eso necesita su propio tratamiento:

Es cara y discreta. Una H100 cuesta del orden de 2,7 a 7 €/hora en cloud europeo (Scaleway desde 2,73 €/h; OVHcloud algo más), o su capex amortizado on-prem; no es un recurso que se reparta en fracciones triviales. Un error de asignación de un 10 % sobre una flota de GPU es dinero real.
Se infrautiliza con facilidad. A diferencia de la CPU, una GPU consume su potencia aunque esté ociosa, y la ocupación media en clusters sin gobierno es notoriamente baja. El coste del idle —la GPU encendida sin trabajar— es el desperdicio número uno, y es invisible si no se mide.
Es difícil de atribuir. ¿De quién es el coste de una GPU compartida por time-slicing o MIG entre varios pods de varios equipos? Sin una capa de asignación, el gasto de GPU es un agujero negro que nadie reclama y nadie optimiza.

El objetivo del FinOps de GPU es convertir ese agujero negro en una factura atribuida, medida y accionable: saber qué cuesta cada equipo, cada modelo y, al final, cada token.

Las métricas de FinOps

Métrica	Definición	Unidad
CPM (coste/1M tokens)	coste del cluster ÷ tokens producidos	€ / 1M tok
Coste por petición	coste imputado a una request completa	€ / req
€/GPU-hora	coste horario de una GPU (amortizado o alquiler)	€/h
Utilización	fracción de la GPU realmente usada	% (MFU, GPU-hour util)
Coste del idle	GPU encendida sin trabajo útil	€/h desperdiciados
Showback	reportar el coste a cada equipo (sin cobrar)	€ / equipo
Chargeback	imputar/cobrar el coste a cada equipo	€ / equipo
Eficiencia de coste	coste real ÷ coste si estuviera al 100 %	%

La métrica que cierra el círculo con el negocio es el coste por token (o por petición): es la única que se puede comparar entre proveedores, entre modelos y contra el precio de una API externa. Todo el tooling de FinOps de GPU existe para llegar, de una forma u otra, a ese número.

Las tres fases de FinOps (FinOps Foundation)

El marco de la FinOps Foundation organiza el trabajo en un ciclo de tres fases. Aplicado a GPU:

Fase	Objetivo	Acción típica en GPU
Inform	visibilidad y asignación	medir coste por namespace/equipo/modelo/token
Optimize	reducir el gasto	rightsizing, spot, cuotas, apagar lo ocioso, cuantizar
Operate	gobierno continuo	presupuestos, alertas de idle, chargeback automatizado

El error habitual es saltar a Optimize sin haber hecho Inform: se compran GPUs o se ajustan réplicas sin saber dónde se va realmente el dinero. La asignación (fase Inform) es el prerrequisito de todo lo demás, y es donde entra el tooling.

Cómo se asigna el coste en Kubernetes: la mecánica de OpenCost

OpenCost es el estándar de facto, así que conviene entender cómo asigna el coste, porque define lo que cualquier herramienta encima puede y no puede hacer. Es un proyecto vendor-neutral, Apache 2.0, originalmente construido por Kubecost y donado a la CNCF (proyecto en incubación) (OpenCost · GitHub).

El modelo trabaja a nivel de nodo: parte de la capacidad de recursos del nodo (CPU, RAM, GPU, almacenamiento) y de su precio total, y reparte ese precio entre los recursos. Cuando el proveedor no da precios explícitos de CPU/GPU/RAM, OpenCost usa la ratio de unos precios base (las tarifas marginales del proveedor, personalizables) y los normaliza para que la suma de los componentes iguale el precio total del nodo (OpenCost · on-prem). Esto es clave en on-premise: tú defines el coste del nodo (capex amortizado + opex) y OpenCost lo reparte.

La utilización la obtiene scrapeando Prometheus: kube-state-metrics, node-exporter y cAdvisor le dan el consumo real por pod, y con eso asigna el coste por cluster, nodo, namespace, controlador, servicio o pod (OpenCost · exporter). Para la GPU, la señal viene de DCGM (vía el NVIDIA GPU Operator) exportado a Prometheus —la misma base que la observabilidad GPU—. Un patrón habitual de detección de idle: una alerta cuando DCGM_FI_DEV_GPU_UTIL < 10 durante más de 15 minutos, enrutada al equipo dueño del namespace.

Frameworks, ficha a ficha

OpenCost — el estándar de asignación (CNCF, Apache 2.0)

Qué mide: coste asignado de los recursos in-cluster (CPU, GPU, memoria, volúmenes) por cualquier dimensión de Kubernetes. Método: modelo de precio a nivel de nodo + scraping de Prometheus (arriba). GPU: sí, vía DCGM. Licencia: Apache 2.0, gratis. Puede correr como exportador de métricas a Prometheus sin más dependencias. Límite: es la capa de asignación, no trae optimización, gobierno ni unit economics de producto; para eso se le pone algo encima.

Kubecost — el comercial sobre OpenCost (IBM)

Qué mide: lo de OpenCost (está construido sobre él) más capacidades enterprise. Kubecost 3.0 (2025) añadió monitorización de GPU vía NVIDIA DCGM e integración con IBM Turbonomic para rightsizing automático, y amplió el alcance de Kubernetes a coste de servicios cloud. IBM adquirió Kubecost e integró Kubecost/OpenCost en su FinOps Suite junto a Cloudability y Turbonomic (CloudZero · Kubecost vs OpenCost). Diferenciador: rightsizing, gobierno, soporte. Límite: producto comercial; el grueso del valor sobre lo gratis de OpenCost es la capa de optimización y enterprise.

CloudZero — unit economics y coste a producto

Qué mide: mapea el coste cloud a features, productos, equipos y clientes, no solo a recursos. Método: ingiere facturación multi-cloud y la modela en dimensiones de negocio. Diferenciador: la asignación más profunda y el enfoque de unit economics (coste por unidad de negocio). Límite: menos centrado en la mecánica intra-Kubernetes que OpenCost/Kubecost; es la capa de “coste a negocio”.

Vantage — multi-cloud con muchas integraciones

Qué mide: coste multi-cloud con más de 20 integraciones nativas (AWS, Azure, GCP, Kubernetes, Snowflake, Datadog, OpenAI, etc.). Diferenciador: amplitud de fuentes, incluida la factura de proveedores de LLM (OpenAI), lo que lo acerca al coste de IA de extremo a extremo. Límite: la profundidad de asignación intra-cluster es menor que la de herramientas K8s-nativas.

Finout — virtual tagging, despliegue rápido

Qué mide: coste multi-cloud con virtual tagging: aplica etiquetas de coste sin modificar los recursos reales, lo que permite asignar gasto que no estaba bien etiquetado de origen. Diferenciador: despliegue rápido y reasignación flexible sin tocar la infra. Límite: como las otras de su categoría, depende de la calidad de los datos de facturación que ingiere.

Tabla comparativa

Herramienta	Ámbito	GPU	Licencia / modelo	Diferenciador	Capa
OpenCost	Kubernetes	Sí (DCGM)	Apache 2.0 (CNCF), gratis	estándar de asignación	recurso
Kubecost	K8s + cloud	Sí (DCGM, 3.0)	comercial (IBM)	rightsizing, enterprise	recurso+optim
CloudZero	multi-cloud	indirecto	comercial	unit economics a producto	negocio
Vantage	multi-cloud (20+)	vía K8s/proveedor	comercial	amplitud (incl. OpenAI)	negocio
Finout	multi-cloud	vía K8s/proveedor	comercial	virtual tagging	negocio

Modelos de precio del tooling comercial

Conviene conocerlos porque el coste de la herramienta de FinOps también es FinOps:

Modelo	Cómo cobra	Rango
Savings-based	% de los ahorros entregados	15–35 %
Fixed-fee	% del gasto cloud anual	1–3 %

(CloudZero · FinOps Tools). Implicación: en un gasto cloud grande, un fixed-fee del 1–3 % puede superar al savings-based; en uno pequeño con mucho desperdicio, el savings-based alinea incentivos. OpenCost, al ser gratis, cambia la ecuación para quien tiene equipo para operarlo.

FOCUS: el estándar de datos de coste

El problema transversal del FinOps multi-fuente es que cada proveedor factura en su propio formato. FOCUS (FinOps Open Cost and Usage Specification) es la especificación técnica abierta que define requisitos para que los proveedores produzcan datasets de facturación uniformes (FOCUS · FinOps Foundation). El comité ratificó FOCUS v1.3 el 4 de diciembre de 2025.

Lo relevante para esta serie: en FinOps X 2026 el foco se ha puesto en extender FOCUS a las cargas de IA, con la economía de tokens empujando la especificación —las peticiones de expansión incluyen workloads de IA, datacenter y SaaS/PaaS (SiliconANGLE). Es decir, el estándar que normaliza el coste cloud se está estirando para cubrir el coste de IA por token. Para una propuesta de arquitectura, apostar por herramientas que emiten y consumen FOCUS es apostar por interoperabilidad futura.

Del recurso al token: coste por token con gateway

La asignación por recurso (OpenCost) llega hasta “este pod de vLLM costó X €/hora”. Para llegar a “esta petición de este equipo costó Y” hace falta interceptar el tráfico de inferencia. Ahí entra el gateway.

Herramientas como LiteLLM se sitúan entre la aplicación y el proveedor/motor de LLM, e interceptan cada petición para registrar tokens, latencia y coste en tiempo real. Capas encima (p. ej. el AI Gateway de OpenLM) generan logs de uso compatibles con FOCUS (v1.0 a 1.3) y mapean el gasto a equipo, producto, cliente o feature, habilitando showback o chargeback (OpenLM · token attribution). Esto enlaza con FinOps y multi-tenancy del cluster GPU, donde el gateway es la pieza que reparte el coste entre inquilinos.

Ejemplo trabajado: chargeback de un cluster multi-tenant

Para ver las dos mitades unidas, un reparto sobre un nodo de ejemplo (4×H100, coste amortizado 12 €/hora) compartido por tres equipos vía namespaces y MIG:

Equipo	GPU-horas asignadas (OpenCost)	Coste hierro (€/h)	Tokens/día (gateway)	Coste/1M tok
A · producto chat	50 %	6,00	8M	~0,75 €
B · batch nocturno	30 %	3,60	3M	~1,20 €
C · experimentación	20 %	2,40	0,5M	~4,80 €

Cómo sale: OpenCost reparte las 12 €/h del nodo según las GPU-horas que consume cada namespace (la mitad para A → 6 €/h). El gateway aporta los tokens por equipo. El coste por millón de tokens de cada uno es su coste de hierro dividido por su producción —y revela algo que ninguna de las dos mitades vería sola: el equipo C paga 6× más por token que A, no porque su modelo sea peor, sino porque su GPU está infrautilizada (mucha GPU-hora asignada para pocos tokens). Ese 4,80 €/1M es la señal de chargeback que dispara una conversación de optimización: o C sube su utilización, o libera la GPU. Sin cruzar asignación y tokens, ese desperdicio queda escondido en una media de cluster.

El coste oculto: la utilización

La palanca de optimización número uno no es cambiar de GPU, es dejar de pagar por GPU ociosa. Como se vio en el artículo de apertura, el coste eléctrico por token a 80 % de utilización es la cuarta parte que a 20 %, y la utilización reparte todo el coste fijo (capex + energía) sobre más tokens. Medir el idle es, por tanto, la acción de mayor retorno de la fase Optimize:

Señal	Fuente	Umbral típico
GPU ociosa	`DCGM_FI_DEV_GPU_UTIL`	< 10 % durante > 15 min
Memoria GPU sin uso	`DCGM_FI_DEV_FB_USED`	reservada pero no usada
Pods sin tráfico	métricas del gateway	0 peticiones, GPU asignada

La asignación (OpenCost) localiza de quién es la GPU ociosa; el scheduling y la co-residencia (compartir GPU: time-slicing, MPS y MIG) la recuperan. FinOps cierra el bucle: medir → atribuir → optimizar → gobernar.

Optimize: las palancas de ahorro (con datos)

Una vez asignado el coste (Inform), la fase Optimize tiene un repertorio acotado de palancas. Ordenadas por retorno típico:

Palanca	Ahorro típico	Mecanismo	Coste/riesgo
Recuperar idle	el mayor	apagar/compartir GPU ociosa	requiere medir utilización
Cuantización (FP8/INT4)	sube throughput, baja VRAM	más tokens por GPU-hora	posible coste de calidad
Compromiso reserved	20–40 % sobre on-demand	reservar capacidad	menos elasticidad
Spot/preemptible	el descuento más profundo	capacidad interrumpible	hay que tolerar cortes
Rightsizing	variable	ajustar tipo/nº de GPU al SLO	requiere benchmarks
Autoscaling (HPA/KEDA)	variable	escalar réplicas con la demanda	tunear métricas

Sobre el compromiso, los datos de cloud de 2026 son contundentes: los planes reserved dan 20–40 % de ahorro frente a on-demand, y spot el descuento más profundo a cambio de interrumpibilidad; el precio de la H100 cayó 64–75 % entre Q4 2024 y principios de 2026 (Spheron · GPU Cloud Pricing). El rightsizing y el autoscaling conectan con el scheduling del cluster: encajar la carga en la GPU correcta y escalar réplicas con la demanda son, a la vez, palancas de rendimiento y de coste. La cuantización aparece aquí porque sube el throughput —y, por la identidad del artículo de apertura, baja el coste y la energía por token al mismo tiempo.

Madurez del FinOps de GPU

Un modelo simple para situar dónde está una organización, y qué le falta:

Nivel	Estado	Lo que falta para subir
0 · ciego	factura agregada, sin atribución	instrumentar OpenCost + DCGM
1 · visibilidad	coste por namespace/equipo	medición por token (gateway)
2 · unit economics	coste por token y por producto	alertas de idle y presupuestos
3 · optimización	idle recuperado, commitment, rightsizing	chargeback automatizado
4 · gobierno	chargeback + presupuestos + FOCUS	mejora continua

La mayoría de las organizaciones con GPU están en el nivel 0 o 1: ven una factura grande pero no saben de quién es cada euro. El salto de valor está en llegar al nivel 2 —el coste por token y por producto—, que es justo donde el tooling de este artículo deja de ser opcional. El track de FinOps de la serie recorre esa escalera hasta el modelo TCO completo y el coste/token comparable que sostiene la propuesta de arquitectura.

El stack mínimo para llegar al nivel 2

Reunir las piezas anteriores en un toolchain concreto, todo open source, que lleva de la ceguera (nivel 0) al coste por token y por producto (nivel 2):

Pieza	Función	Alternativa
NVIDIA GPU Operator + DCGM	exporta métricas de GPU (uso, memoria, potencia)	—
Prometheus	almacena las series de uso y coste	VictoriaMetrics
OpenCost	asigna el coste por recurso y dimensión	Kubecost (comercial)
Gateway (LiteLLM)	cuenta tokens por equipo/modelo	OpenLM AI Gateway
Grafana	paneles de coste, utilización e idle	—

Es, deliberadamente, infraestructura que muchos clusters ya tienen para observabilidad (DCGM, Prometheus, Grafana); el FinOps de GPU reutiliza esa base y le añade OpenCost y el gateway. No es un producto nuevo, es una capa sobre lo existente.

KPIs a vigilar

KPI	Qué indica	Objetivo típico
Utilización media de GPU	desperdicio	>70–80 % sostenido
Coste por 1M tokens (por modelo)	eficiencia económica	comparar vs alquiler cloud
% de GPU-horas en idle	dinero tirado	minimizar (<10–15 %)
Coste por equipo/producto	atribución	reparto justo, sin sorpresas
Desviación sobre presupuesto	gobierno	alertar antes de superarlo

Estos cinco KPIs son los que convierten el FinOps de GPU de un panel bonito en una herramienta de decisión: si los vigilas, sabes en todo momento qué cuesta cada cosa y dónde está el desperdicio.

Estado del arte 2026

Consolidación en Kubernetes: OpenCost es el estándar CNCF de asignación; Kubecost (IBM) el comercial de referencia, ya con GPU vía DCGM y rightsizing por Turbonomic.
Del recurso al token: las plataformas fuertes de 2026 trackean el coste a nivel de token y de GPU, combinando asignación por recurso (OpenCost) con medición por gateway (LiteLLM); es la única vía para un coste/token comparable on-prem vs cloud.
FOCUS v1.3 (dic-2025) como capa de interoperabilidad, extendiéndose a IA en FinOps X 2026: el estándar de coste cloud absorbe la economía de tokens.
GPU FinOps maduro: la instrumentación se apoya en DCGM (misma base que la observabilidad), y la detección de idle por umbral de utilización es práctica común.

Coste por token: el puente con la decisión de negocio

Todo el tooling anterior existe para producir un número que el negocio entienda: el coste por token (o por petición). Es el que permite responder a las tres preguntas que sostienen una propuesta de arquitectura:

¿Construir o comprar? El coste/token on-prem (capex amortizado + opex, a la utilización real) frente al precio de una API externa o de alquiler cloud. Por debajo del umbral de volumen (~2M tokens/día) suele ganar comprar; por encima, construir.
¿Cómo poner precio a un producto? Si una feature consume N tokens por uso y cada millón cuesta C, el coste marginal por uso es N·C/10⁶ — la base de cualquier margen.
¿Dónde está el desperdicio? El coste/token por equipo (el ejemplo de chargeback) señala quién infrautiliza la GPU antes de que la factura agregada lo esconda.

La trampa: comparar coste/token entre escenarios sin fijar los supuestos (utilización, precisión, modelo de propiedad). Un coste/token on-prem calculado al 80 % de utilización no es comparable con uno al 20 %, ni un FP16 con un FP8. Por eso la asignación (Inform) no es un fin en sí mismo: es la materia prima de un modelo de coste con supuestos explícitos, que es lo que el artículo de síntesis convierte en el argumento de “construir vs comprar” con números defendibles. El FinOps de GPU no es contabilidad; es la base cuantitativa de la decisión de arquitectura.

Límites y trampas (data-driven)

Asignación ≠ medición por token. OpenCost reparte el coste del recurso; sin gateway no llegas a la petición. Son dos mitades que hay que unir explícitamente.
Precios base mal puestos = asignación mal puesta. En on-prem, OpenCost reparte el coste que tú declaras del nodo; si el capex/opex amortizado está mal, todo el reparto lo está. La calidad del dato de entrada manda.
Idle invisible. Sin DCGM exportado a Prometheus y sin alertas de utilización, el desperdicio número uno no aparece en ningún panel.
Coste de la herramienta. Un fixed-fee del 1–3 % sobre un gasto grande es dinero; compara el coste del tooling con el ahorro que entrega (es FinOps sobre el FinOps).
Formatos propietarios. Herramientas que no emiten/consumen FOCUS te atan a su modelo de datos; en 2026 la apuesta robusta es la interoperabilidad FOCUS.

El siguiente artículo de la serie (A2) entra en OpenCost a fondo; este fija el mapa. Con la asignación resuelta, el resto del track de FinOps construye el modelo TCO y el coste/token que la propuesta necesita.

Fuentes

OpenCost · GitHub (CNCF, Apache 2.0) — https://github.com/opencost/opencost
OpenCost · documentación on-prem (modelo de precio por nodo) — https://opencost.io/docs/configuration/on-prem/
OpenCost · exporter de Prometheus — https://opencost.io/docs/integrations/opencost-exporter/
CloudZero · Kubecost vs OpenCost (2026) — https://www.cloudzero.com/blog/kubecost-vs-opencost/
CloudZero · FinOps Tools: Definitive Guide (2026) — https://www.cloudzero.com/blog/finops-tools/
FOCUS · especificación (FinOps Foundation) — https://focus.finops.org/focus-specification/
SiliconANGLE · FOCUS y la economía de tokens de IA (FinOps X 2026) — https://siliconangle.com/2026/06/08/focus-specification-ai-cost-accountability-finopsx/
OpenLM · atribución de tokens en tiempo real (LiteLLM + FOCUS) — https://www.openlm.com/enable-ai-finops-with-real-time-token-attribution/
Finout · Best AI Cost Observability Tools (2026) — https://www.finout.io/blog/best-ai-cost-observability-tools-in-2026

Focus on lo0 — Blog Técnico