FinOps de GPU/LLM: frameworks, métricas y estado del arte (ficha a ficha)
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