Cloudzero on lo0 — Blog Técnico

Kubecost vs OpenCost vs alternativas: qué añade el comercial y cuándo merece pagarlo

Sun, 14 Jun 2026 02:30:00 +0200

Notación: importes en euros (N €), decimales con coma; 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 este artículo

Tercer artículo del track de FinOps (A3). En A2 se vio cómo asigna el coste OpenCost, la base gratis. Este artículo responde la pregunta que viene después: ¿merece la pena pagar por Kubecost o una alternativa comercial, o basta con OpenCost? Es una decisión de build-vs-buy —operar tú la herramienta open source frente a comprar un producto—, y la respuesta depende de tu escala, tu audiencia y tu apetito por operar infraestructura. Sin recomendaciones universales: aquí están los hechos (qué añade cada uno, qué cuesta, cuándo encaja) y, para una plataforma europea, el matiz de soberanía del dato de coste que las comparativas estadounidenses no mencionan.

El eje de la decisión: construir vs comprar

OpenCost es gratis (Apache 2.0), pero “gratis” significa operarlo tú: desplegarlo, configurar el precio del nodo, mantener Prometheus con retención suficiente, construir los paneles de Grafana y las alertas. Kubecost (y las alternativas) cobran por quitarte ese trabajo y añadir capacidades que OpenCost no trae. La decisión, por tanto, no es “gratis vs caro”: es coste de operación propio vs licencia.

Eje	Inclina hacia OpenCost	Inclina hacia comercial
Equipo de plataforma	tienes quien lo opere	no quieres operar nada
Escala (gasto cloud/GPU)	pequeña-media	grande (el ahorro paga la licencia)
Audiencia del informe	ingenieros	finanzas / dirección
Nº de clusters	uno	muchos (multi-cluster)
Necesidad de optimización automática	la haces a mano	la quieres de serie

OpenCost es el núcleo open source; Kubecost es el producto enterprise construido encima de ese núcleo, con features propietarias añadidas; Kubecost fue el desarrollador original del motor antes de liberarlo, e IBM adquirió la compañía (CloudZero · Kubecost vs OpenCost). Es decir: ambos comparten el mismo motor de asignación; lo que se paga es la capa de encima.

Qué añade Kubecost sobre OpenCost

Sobre la asignación (que es común), Kubecost añade una capa de optimización, gobierno y enterprise (CloudZero, Finout):

Capacidad	OpenCost	Kubecost
Asignación de coste (CPU/GPU/mem/PV)	✓	✓ (mismo motor)
GPU vía DCGM	✓	✓ (3.0)
Reconciliación de factura (descuentos, RI, spot)	—	✓
Rightsizing (recomendaciones)	—	✓
Detección de anomalías	—	✓
Alertas de presupuesto	manual	✓
RBAC	—	✓
Agregación multi-cluster	—	✓
Opción hosted (SaaS)	—	✓
Retención larga de histórico	tu Prometheus	incluida
Soporte	comunidad	comercial (IBM)

La reconciliación de factura

La capacidad que más justifica el precio en cloud: OpenCost asigna sobre tarifas de lista; Kubecost reconcilia con la factura real, que incluye descuentos, instancias reservadas y precios spot (Finout). La diferencia puede ser grande: un coste asignado a tarifa de lista puede estar un 30–50 % por encima de lo que realmente pagas tras descuentos. En on-prem esto importa menos (tú declaras el precio real del nodo), pero en cloud o híbrido, la reconciliación es la diferencia entre un coste “teórico” y el coste que aparece en la factura.

Rightsizing y detección de anomalías

Kubecost recomienda redimensionar (rightsizing) recursos infrautilizados —vía la integración con IBM Turbonomic— y detecta anomalías de gasto automáticamente. OpenCost te da los datos para hacerlo a mano; Kubecost lo automatiza. Para una flota de GPU, el rightsizing y la detección de idle anómalo son justo donde está el ahorro de la fase Optimize.

El precio de Kubecost (y la economía build-vs-buy)

El precio de Kubecost arranca en 449 USD/mes para uso business, con opciones enterprise bajo consulta (fuente). La pregunta correcta no es “¿449 USD es caro?”, sino “¿operar OpenCost yo mismo cuesta más o menos que eso?”. El cálculo build-vs-buy:

Coste	OpenCost (build)	Kubecost (buy)
Licencia	0	desde ~449 USD/mes (business)
Tiempo de ingeniería	despliegue + mantenimiento + paneles	mínimo
Retención de histórico	tu coste de Prometheus/Thanos	incluida
Soporte	tu equipo	incluido

Si una persona de plataforma dedica unas horas al mes a operar OpenCost, ese tiempo ya puede superar los 449 USD; si tu cluster es pequeño y el coste de operación es casi nulo (lo montas una vez y rueda), OpenCost gana. La regla de mercado: si el gasto mensual de Kubernetes es inferior a ~10.000 USD, las herramientas nativas del cloud o el open source (OpenCost) suelen bastar; por encima, el ahorro que captura el comercial paga su licencia ([búsqueda]).

Ejemplo trabajado: build-vs-buy

Un cálculo ilustrativo para una plataforma con un cluster de GPU de tamaño medio:

Concepto	OpenCost (build)	Kubecost (buy)
Licencia anual	0	~449 USD/mes × 12 = ~5.400 USD (~5.000 €)
Despliegue inicial	~2–3 días de ingeniería	~medio día
Mantenimiento	~4–8 h/mes (paneles, alertas, upgrades)	mínimo
Coste de operación (a ~60 €/h)	~240–480 €/mes	~marginal
Retención de histórico	coste de Thanos/Mimir propio	incluida

Si el coste de operación de OpenCost ronda 240–480 €/mes, está en el mismo orden que la licencia de Kubecost (~415 €/mes). La decisión, entonces, no la marca el precio sino el valor añadido: si la reconciliación de factura, el rightsizing automático y la UI para finanzas te ahorran o te aportan más que esa diferencia, Kubecost gana; si tu equipo ya opera Prometheus/Grafana y tu audiencia son ingenieros, OpenCost gana. Para un cluster grande multi-cluster, el ahorro que captura Kubecost suele superar con creces la licencia; para uno pequeño y estable, operar OpenCost es casi gratis. El número que decide no es 449 USD, es tu coste de operación frente a ese valor añadido.

Migración y reversibilidad: un argumento a favor de empezar por OpenCost

Una ventaja poco mencionada de que Kubecost esté construido sobre OpenCost: la migración entre ambos es de bajo riesgo. Empezar por OpenCost y, si la escala lo justifica, subir a Kubecost más adelante no obliga a rehacer la asignación —es el mismo motor, los mismos conceptos, la misma instrumentación de Prometheus/DCGM—. Lo que cambia es la capa de encima. Esto reduce el lock-in: no es una apuesta irreversible.

Para una plataforma que arranca, la estrategia de bajo riesgo es clara: montar OpenCost self-hosted primero, conseguir la asignación correcta con el precio del nodo en euros, vivir con ella unos meses, y solo entonces decidir si la reconciliación de factura, el rightsizing automático y la UI para finanzas justifican pagar Kubecost. Empezar por el comercial “por si acaso” es pagar antes de saber si lo necesitas; empezar por OpenCost y subir si hace falta es la opción que mantiene la reversibilidad y descubre el valor real antes de la factura. Y como ambos son self-hosted, ninguna de las dos rutas cede la soberanía del dato.

Las alternativas: CloudZero, Vantage, Finout

Kubecost no es la única opción comercial; hay una categoría de plataformas de coste que operan a un nivel distinto (más cerca del negocio que de Kubernetes):

Herramienta	Enfoque	Diferenciador	Capa
CloudZero	unit economics	coste a feature/producto/cliente	negocio
Vantage	multi-cloud (20+ integraciones)	amplitud (incl. factura OpenAI)	negocio
Finout	multi-cloud	virtual tagging (sin tocar recursos)	negocio
Kubecost	Kubernetes	profundidad intra-cluster + optimización	recurso+optim
OpenCost	Kubernetes	asignación open source	recurso

La distinción clave: Kubecost/OpenCost son herramientas centradas en Kubernetes (profundidad intra-cluster); CloudZero/Vantage/Finout son plataformas de coste de negocio (amplitud multi-cloud, coste a producto). No siempre compiten: muchas organizaciones usan OpenCost/Kubecost para el detalle de Kubernetes y una plataforma de negocio para la vista agregada.

Ficha breve de cada una:

CloudZero — plataforma de cost intelligence con una solución dedicada de visibilidad de Kubernetes para equipos de ingeniería. Su seña es el unit economics: mapear el coste a feature, producto y cliente, respondiendo “¿cuánto me cuesta servir a este cliente?” más que “¿cuánto cuesta este pod?”. Encaja cuando el coste hay que llevarlo al P&L del producto.
Vantage — amplitud de integraciones (más de 20 fuentes: AWS, Azure, GCP, Kubernetes, Snowflake, Datadog y la factura de proveedores de LLM como OpenAI). Es la opción cuando el coste de IA está repartido entre muchos proveedores y quieres una vista única, incluida la factura de las APIs de modelos.
Finout — multi-cloud con virtual tagging: aplica etiquetas de coste sin modificar los recursos, lo que permite asignar gasto mal etiquetado de origen y desplegar rápido. Está entre las herramientas top de optimización de coste de Kubernetes (CloudBolt, Finout).

El patrón habitual de una organización madura: OpenCost/Kubecost para el detalle de Kubernetes y la GPU, y una plataforma de negocio encima para cruzar ese coste con el resto del gasto cloud y llevarlo a producto. No es “uno u otro”: es a menudo “uno y otro”, en capas.

Criterios de decisión

Cinco preguntas que resuelven la elección sin opinión:

¿Cuánto gastas? Bajo ~10k USD/mes, OpenCost basta; por encima, el ahorro paga el comercial.
¿Quién lee el informe? Ingenieros → OpenCost; finanzas/dirección → la UI pulida de Kubecost o una plataforma de negocio.
¿Uno o muchos clusters? Multi-cluster inclina a Kubecost.
¿Quieres operar infraestructura? Si no, comprar; si tienes equipo de plataforma, construir con OpenCost.
¿Dónde puede vivir el dato de coste? La pregunta europea, abajo.

El ángulo europeo: soberanía del dato de coste

Las comparativas estadounidenses omiten un criterio que para una plataforma soberana es de primer orden: dónde acaba el dato de coste y uso. CloudZero, Vantage, Finout y la opción hosted de Kubecost son SaaS, mayoritariamente estadounidenses: les envías tu telemetría de coste, uso, nombres de namespaces, equipos y productos. Ese dato —que describe tu operación con detalle— sale a una jurisdicción sujeta a la US CLOUD Act, con la misma consideración de RGPD que cualquier otro dato sensible enviado a un hyperscaler.

Opción	Dónde vive el dato de coste	Soberanía
OpenCost self-hosted	en tu cluster	total
Kubecost self-hosted	en tu cluster	total
Kubecost hosted (SaaS)	SaaS del proveedor	sujeto a la jurisdicción del SaaS
CloudZero / Vantage / Finout	SaaS (US)	sujeto a US CLOUD Act

Conviene ser justo: el dato de coste no es lo mismo que el dato de los usuarios. Una telemetría de gasto por namespace es menos sensible que el contenido de las inferencias. Pero sí revela la operación: qué equipos existen, qué productos consumen GPU, el tamaño de la plataforma, y —cruzado con nombres de namespace— información que en conjunto puede ser sensible. La mayoría del tooling FinOps SaaS es estadounidense; hay opciones europeas emergentes, pero pocas con la madurez de las grandes. Ante la duda, y para datos sujetos a RGPD, el principio de minimización aconseja no sacar de la UE lo que no hace falta sacar — y la asignación de coste, con OpenCost/Kubecost self-hosted, no hace falta sacarla.

La consecuencia para la propuesta: OpenCost o Kubecost self-hosted mantienen el dato de coste bajo tu control, igual que el cluster mantiene los datos de inferencia. Si la soberanía del dato es un requisito (lo es para datos RGPD, ver controles ENS × 42001 × EU AI Act), las plataformas SaaS estadounidenses entran en el mismo conflicto que un hyperscaler — por muy buena que sea su UI. Para Fibercli y cualquier plataforma soberana, esto inclina la balanza hacia self-hosted, con OpenCost como base y Kubecost self-hosted si se quiere la capa enterprise sin ceder el dato.

Coste de IA: lo que ninguno trae de serie

Un punto que las comparativas generalistas no destacan y que es central para una plataforma LLM: ninguna de estas herramientas da el coste por token de serie. OpenCost y Kubecost llegan al coste del pod (por recurso/uso); CloudZero, Vantage y Finout llegan al coste del recurso o de la factura (incluida la de OpenAI, en el caso de Vantage). Pero el salto de “este pod de vLLM costó X €/hora” a “esta petición de este equipo costó Y” requiere interceptar el tráfico de inferencia con un gateway (LiteLLM) que cuente tokens por petición y por equipo —como se desarrolló en la introducción de FinOps—.

Capa	Qué da	Quién la cubre
Coste del recurso/pod	€/hora por pod, namespace, equipo	OpenCost, Kubecost
Coste de la factura cloud/LLM	€/mes por proveedor	CloudZero, Vantage, Finout
Coste por token	€/1M tokens por equipo/modelo	gateway (LiteLLM) + cualquiera de los anteriores

La implicación para elegir herramienta: el coste por token —la métrica que compara on-prem vs cloud— no la resuelve ninguna herramienta por sí sola, sino la combinación de la asignación (OpenCost/Kubecost) con la medición de tokens (gateway). Al evaluar una herramienta comercial, la pregunta de IA no es “¿da el coste del pod?” (todas lo dan de un modo u otro), sino “¿se integra bien con mi gateway para llegar al token?”. Vantage, al ingerir la factura de OpenAI, se acerca por el lado del consumo de APIs externas; para inferencia propia, el gateway sigue siendo imprescindible.

Estado del arte 2026

Consolidación bajo IBM: Kubecost/OpenCost integrados en la FinOps Suite de IBM junto a Cloudability y Turbonomic; OpenCost sigue siendo el estándar CNCF de asignación.
GPU de primera clase: Kubecost 3.0 y OpenCost asignan GPU vía DCGM; el FinOps de GPU deja de ser un caso especial.
Hacia el token y FOCUS: las plataformas fuertes trackean coste a nivel de token, y el estándar FOCUS (v1.3, dic-2025) se extiende a cargas de IA, lo que empujará la interoperabilidad entre estas herramientas.
Categoría de plataformas de coste de IA: emerge tooling específico de AI cost observability que combina recurso, factura y token; conviene exigir compatibilidad FOCUS para no acoplarse a un proveedor.

Checklist de elección

Para decidir sin opinión, en orden:

Paso	Pregunta	Si…
1	¿Tengo equipo para operar OpenCost?	no → comercial / hosted
2	¿Gasto > ~10k USD/mes y multi-cluster?	sí → Kubecost
3	¿El informe es para finanzas/dirección?	sí → UI de Kubecost o plataforma de negocio
4	¿Necesito coste a producto/cliente?	sí → CloudZero/Vantage/Finout encima
5	¿El dato de coste puede salir a un SaaS US?	no → self-hosted (OpenCost / Kubecost)
6	¿Necesito coste por token?	sí → cualquiera + gateway

El paso 5 es el que filtra para una plataforma soberana: si el dato de coste no puede salir de la jurisdicción UE, la lista se reduce a las opciones self-hosted, con OpenCost como base.

Modelos de precio del tooling comercial

Para los que cobran por ahorro o por porcentaje del gasto:

Modelo	Cómo cobra	Rango
Licencia fija (Kubecost)	tarifa mensual	desde ~449 USD/mes (business)
Savings-based	% de los ahorros entregados	15–35 %
Fixed-fee	% del gasto cloud anual	1–3 %

Implicación: en un gasto grande, un fixed-fee del 1–3 % puede superar la licencia fija de Kubecost; en uno con mucho desperdicio, el savings-based alinea incentivos pero puede salir caro si el ahorro es grande. OpenCost, gratis, cambia la ecuación si tienes quien lo opere.

Coexistencia: la realidad es en capas

En organizaciones maduras, estas herramientas no se eligen entre sí, se apilan. El patrón habitual:

Capa	Herramienta	Responde a
Asignación intra-Kubernetes	OpenCost / Kubecost	¿cuánto cuesta cada pod/equipo/GPU?
Medición por token	gateway (LiteLLM)	¿cuánto cuesta cada petición/equipo?
Coste a producto / multi-cloud	CloudZero / Vantage / Finout	¿cuánto cuesta servir este producto/cliente?

Cada capa resuelve una pregunta distinta y se alimenta de la de abajo: el coste del pod (OpenCost) más los tokens (gateway) dan el coste por token; ese coste por token, agregado por una plataforma de negocio, da el coste por producto. Intentar que una sola herramienta cubra las tres capas suele acabar en compromisos: las de Kubernetes no llegan al negocio, las de negocio no llegan al pod, y ninguna llega al token sin el gateway. La arquitectura sana es capas que se integran, no una herramienta que lo hace todo a medias. Y el pegamento entre capas, en 2026, es FOCUS: exigir compatibilidad FOCUS a cada pieza es lo que permite que el dato fluya entre ellas sin reescribirlo.

Resumen por perfil de organización

Para situarse rápido, qué stack encaja con cada perfil (orientativo, no prescriptivo):

Perfil	Escala	Stack que suele encajar
Equipo pequeño con plataforma	1 cluster, gasto bajo	OpenCost self-hosted + Grafana
Scale-up con varios equipos	multi-equipo, gasto medio	OpenCost + gateway; Kubecost si falta tiempo
Enterprise multi-cluster	muchos clusters, gasto alto	Kubecost + plataforma de negocio
Plataforma soberana (Fibercli)	RGPD, dato en UE	OpenCost/Kubecost self-hosted + gateway; nada de SaaS de coste US

El perfil soberano es el que cambia la respuesta respecto a las guías estándar: por mucho que una plataforma SaaS estadounidense gane en features o en UI, el requisito de mantener el dato de coste bajo jurisdicción UE la descarta para datos RGPD. Para Fibercli, la fila de abajo es la que manda, y por eso el track de FinOps de esta serie se construye sobre herramientas self-hosted.

Límites y trampas (data-driven)

“Gratis” no es gratis. OpenCost tiene coste de operación; cuéntalo en el build-vs-buy o te engañas comparando 0 con 449 USD.
Reconciliación solo importa en cloud. En on-prem puro, declaras el precio real del nodo y la reconciliación de Kubecost aporta menos.
SaaS de coste = dato de coste fuera. Para una plataforma soberana, enviar la telemetría de coste a un SaaS estadounidense reintroduce el problema de jurisdicción que el on-prem evitaba.
Mismo motor, distinta UI. Buena parte de lo que se paga en Kubecost es la capa de presentación y gobierno; si tu audiencia son ingenieros, puede no compensar.
No confundir capas. OpenCost/Kubecost (Kubernetes) y CloudZero/Vantage/Finout (negocio) resuelven problemas distintos; a veces se complementan, no compiten.

Con la decisión de tooling de asignación resuelta, el track de FinOps avanza hacia el coste por token (A4) y el modelo TCO completo (A8). El cimiento es el de A2 y A3: una asignación correcta, con el precio del nodo en euros, en una herramienta que respete la soberanía del dato.

Cierre

La elección OpenCost vs Kubecost vs plataforma comercial se vende como una comparativa de features, y en realidad es una decisión de build-vs-buy con una restricción de soberanía encima. El motor de asignación es el mismo (OpenCost) en los dos primeros; lo que se paga en Kubecost es la capa de optimización, gobierno y presentación, que compensa cuando la escala es grande, la audiencia es financiera o no quieres operar infraestructura. Las plataformas de negocio (CloudZero, Vantage, Finout) resuelven otro problema —el coste a producto, multi-cloud— y a menudo conviven en capas con las de Kubernetes, no compiten. Pero para una plataforma soberana europea hay un criterio que ninguna comparativa estadounidense pone delante y que para Fibercli va primero: dónde vive el dato de coste. Enviar tu telemetría de gasto, equipos y productos a un SaaS estadounidense reintroduce, por la puerta de atrás, el problema de jurisdicción que el on-prem evitaba. La conclusión que sostienen los datos: OpenCost self-hosted como base, Kubecost self-hosted si se quiere la capa enterprise, y el gateway para llegar al token — una pila que mantiene el coste medido, en euros, y bajo jurisdicción UE. Caro o barato es secundario; soberano o no, no lo es.

Fuentes

CloudZero · Kubecost vs OpenCost (2026) — https://www.cloudzero.com/blog/kubecost-vs-opencost/
Finout · Kubecost vs OpenCost (6 diferencias) — https://www.finout.io/blog/kubecost-vs-opencost
Finout · Kubecost: pros/cons, pricing, alternativas (2026) — https://www.finout.io/blog/kubecost-pros/cons-pricing-tutorial-alternatives-2026-guide
CloudBolt · Top Kubecost Alternatives (2026) — https://www.cloudbolt.io/blog/top-kubecost-alternatives/
Amnic · OpenCost vs Kubecost — https://amnic.com/blogs/opencost-vs-kubecost
Clanker Cloud · Best tools for managing GPU usage in Kubernetes (2026) — https://clankercloud.ai/blog/best-tools-managing-gpu-usage-kubernetes-2025-2026-cost-roi

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