Del GPU-hora al coste por token: la métrica que compara on-prem y cloud

Notación: importes en euros (N €), decimales con coma. No se usa el símbolo de dólar (en este sitio es delimitador de fórmula).

Qué cubre este artículo

Cuarto artículo del track de FinOps (A4), y el que cierra la métrica que da sentido a todo el pilar: el coste por token. En A2 vimos cómo OpenCost asigna el coste del hierro (el pod, en €/hora); en A3, qué herramienta usar. Pero el coste del pod no es la métrica que compara on-prem con cloud ni la que entiende el negocio: esa es el coste por token (o por request). Este artículo explica cómo se calcula de verdad —spoiler: para inferencia propia no es un precio de lista, es el €/GPU-hora dividido por el throughput—, cómo se instrumenta con un gateway (LiteLLM), cómo se atribuye por equipo y producto, y cómo se compara contra el cloud europeo. Sin recomendaciones; solo la mecánica y los números.

La identidad: del GPU-hora al token

El coste por millón de tokens (CPM) es el coste del hierro dividido por lo que produce:

$$\text{coste por token} = \frac{\text{coste del hierro (€/h)}}{\text{throughput (tok/s)} \times 3600 / 10^6}$$

Esta es la fórmula del track de FinOps, y tiene una consecuencia que mucha gente no interioriza: para un modelo self-hosted, el coste de un token no existe como precio fijo. Depende de dos cosas que cambian: el coste del hierro (de OpenCost, en €/hora) y el throughput (de tu benchmark, en tok/s). El mismo modelo en el mismo nodo cuesta la mitad por token si doblas el throughput con una optimización —porque el denominador cambia, no el numerador—. El coste por token de inferencia propia es una función de tu eficiencia, no una tarifa.

Esto lo distingue radicalmente de una API externa, donde el precio por token sí es una tarifa fija que te cobra el proveedor. Comparar ambos exige convertir tu coste variable en un número, y ahí es donde se junta el hierro (A2) con los tokens (este artículo).

Las dos mitades del coste por token

El coste por token nace de unir dos mediciones que viven en sitios distintos:

La mitad del hierro la pone OpenCost (artículo A2): el coste por uso del pod de vLLM, en €/hora. La mitad de los tokens la pone el gateway, que intercepta cada petición y cuenta los tokens por modelo y por equipo. Dividiendo, sale el coste por token —y, crucialmente, por equipo, que es lo que habilita el chargeback—.

El gateway: LiteLLM a fondo

El gateway se sitúa entre la aplicación y el motor (vLLM) o el proveedor, e intercepta cada petición. LiteLLM es el de referencia OSS: hace de proxy ante 100+ modelos y rastrea el gasto por claves, usuarios y equipos, registrando el gasto de todos los modelos conocidos automáticamente (LiteLLM · Spend Tracking).

Sus mecanismos clave:

Con la tabla de spend logs (vía el adaptador de base de datos), tienes el detalle de cada petición para construir dashboards de coste (LiteLLM · Logging), y puedes etiquetar cada request con equipo/proyecto/entorno para el análisis por equipo, con notificaciones (Slack) y topes duros para claves que no deben superar un límite. Es, en la práctica, el medidor de tokens y el repartidor de coste de la plataforma.

La trampa del self-hosted: LiteLLM no sabe lo que te cuesta un token propio

Aquí está el punto que casi nadie cablea bien. LiteLLM rastrea el coste con precios de lista de los modelos conocidos (los de las APIs: OpenAI, Anthropic, etc.). Pero para un modelo self-hosted en tu vLLM, no hay precio de lista —tú no le pagas a nadie por token—. Si no le dices nada, LiteLLM no sabe el coste real de tu token propio. La solución es el custom pricing: declararle a LiteLLM el coste por token de tu modelo self-hosted (LiteLLM · Custom Pricing).

¿Y de dónde sale ese número? De la identidad de arriba: el coste del hierro (OpenCost) dividido por el throughput (tu benchmark). Es decir, el flujo correcto es:

1. OpenCost te da el coste del pod de vLLM: ~11 €/hora (A2).
2. Tu benchmark te da el throughput: ~2.800 tok/s (track B).
3. La identidad da el coste por token: 11 ÷ (2.800 × 3.600 / 10⁶) ≈ 1,09 €/1M tok.
4. Ese 1,09 €/1M lo metes como custom pricing en LiteLLM.

Solo así el response_cost de cada petición refleja el coste real de tu inferencia, no un cero o un precio de lista ajeno. Sin este paso, tus dashboards de coste de LiteLLM mienten para los modelos propios. Es la unión explícita de los tres tracks: hierro (FinOps), throughput (benchmarking) y medición (gateway).

Configurar el custom pricing: ejemplo

En LiteLLM, el coste real de un modelo self-hosted se declara en su configuración. Un ejemplo con el coste por token derivado de la identidad (1,09 €/1M ÷ 10⁶ = 0,00000109 €/token):

# config.yaml de LiteLLM — coste real de un modelo self-hosted
model_list:
  - model_name: llama-3.1-70b-onprem
    litellm_params:
      model: openai/llama-3.1-70b           # tu endpoint vLLM
      api_base: http://vllm:8000/v1
      input_cost_per_token:  0.00000109      # €/token (de OpenCost ÷ throughput)
      output_cost_per_token: 0.00000109      # afinar si separas prefill/decode

Con eso, cada response_cost que registra LiteLLM refleja el coste real de tu hierro. La nota operativa: este número hay que actualizarlo cuando cambie el coste del nodo (nueva amortización, otro precio de energía) o el throughput (una optimización del motor). No es una constante; es el output de OpenCost y del benchmark, y se recalcula cuando cualquiera de los dos cambia. Automatizar ese recálculo —del coste del nodo y del throughput medido al custom pricing— es lo que mantiene los dashboards de coste honestos.

El coste por token cambia con el throughput: léelo sobre el sweep

Como el throughput es el denominador, el coste por token no es un punto, es una curva sobre el sweep de concurrencia. Sobre el nodo de ~11 €/hora:

Lecturas importantes: a baja concurrencia el coste por token es altísimo (el coste fijo del nodo se reparte entre pocos tokens); el coste baja al subir la ocupación. Pero ojo a la última fila: si calculas el coste sobre el throughput bruto (3.900) sales con 0,78 €, pero si lo calculas sobre el goodput (2.420, el que cumple el SLO) sales con 1,26 € —y este último es el coste real, porque las peticiones que violan el SLO no cuentan como producción útil—. El coste por token honesto se calcula sobre el goodput, no sobre el throughput de catálogo. Es la unión del track de coste con el de benchmarking: el denominador correcto es el goodput.

Coste por request: no solo por token

El coste por token es la unidad; el coste por request es lo que factura una petición completa. Una request consume tokens de entrada (prompt) + tokens de salida (generación), y ambos cuentan:

$$\text{coste por request} = (\text{tokens entrada} + \text{tokens salida}) \times \text{coste por token}$$

Con matices: en muchos motores el prefill (entrada) y el decode (salida) tienen costes distintos por token (el decode es memory-bound y más caro por token), así que un modelo de coste fino distingue ambos. Para la mayoría de casos, un coste por token medio ponderado vale; para optimizar, conviene separar prefill y decode. LiteLLM registra los tokens de entrada y salida por separado en sus spend logs, así que el dato está disponible para afinar.

El coste por request es el que conecta con el producto: si una feature consume de media 1.500 tokens (1.200 de prompt + 300 de salida) y el coste es 1,09 €/1M, cada uso cuesta ~0,0016 € —la base para fijar el margen, como se vio en la intro de FinOps—.

Coste por modelo y por tier

Una plataforma no sirve un solo modelo. El coste por token varía por modelo y por configuración, y el gateway los distingue. Un 8B y un 70B en el mismo nodo tienen costes por token muy distintos: el 8B da mucho más throughput (más tokens/s) con la misma GPU-hora, así que su coste por token es una fracción del 70B. La consecuencia para el diseño: enrutar cada petición al modelo más barato que cumpla la calidad es una palanca directa de coste —servir un 70B donde basta un 8B es pagar de más por token—.

El gateway, con su custom pricing por modelo, hace visible esta diferencia y permite el routing por coste: clasificar la petición y mandarla al tier adecuado. Conecta con el router L7 del track de serving: el gateway no solo mide el coste, puede decidir en función de él. Y la cuantización (FP16→FP8) aparece otra vez como palanca: el mismo modelo en FP8 sube throughput y baja el coste por token, moviendo el dato sin cambiar de modelo.

Atribución: del coste al equipo y al producto

La razón de poner un gateway no es solo medir el coste total, es repartirlo. Etiquetando cada request con equipo, producto y entorno, LiteLLM construye el reparto por dimensión de negocio:

Con presupuestos por equipo y topes duros por clave, el gateway no solo informa: gobierna. Un equipo que se pasa de presupuesto recibe alerta; una clave con tope duro no puede gastar más. Es la fase Operate del FinOps aplicada al token.

Ejemplo de informe combinado

Juntando el hierro (OpenCost) y los tokens (gateway), el informe mensual de coste por token por equipo sobre el nodo de ejemplo:

Lo que revela: A consume mucho pero a coste eficiente (FP8, alta utilización); B usa un modelo barato (8B) para su carga; C consume poco pero, como vimos en A2, arrastra el coste de idle de su GPU infrautilizada. El informe por token más el de hierro de OpenCost dan la imagen completa: quién gasta, en qué modelo, con qué eficiencia. Es el chargeback que ninguna de las dos mitades produciría sola. Y la cifra por equipo es la que se lleva a la conversación de presupuesto: no “el cluster cuesta X”, sino “tu equipo consumió Y millones de tokens a Z €/millón”.

Gobernar el gasto: presupuestos, topes y alertas

Medir sin gobernar es un panel; el valor está en cerrar el bucle. LiteLLM permite tres niveles de control sobre el gasto:

El patrón sano: presupuestos blandos con alerta para los equipos (que ajusten su consumo), rate limits para suavizar picos, y topes duros solo en claves críticas (un servicio que no debe dispararse). Con esto, el coste por token deja de ser un dato a posteriori y se convierte en un control en tiempo real: la fase Operate del FinOps, aplicada a la inferencia.

Comparación on-prem vs cloud europeo (el porqué de todo)

El coste por token existe para responder una pregunta: ¿sale más barato servir en mi hierro o alquilar? Con la identidad y datos europeos:

El coste por token es lo que hace comparable lo incomparable: tu coste variable (hierro ÷ throughput) frente a la tarifa fija de un proveedor. Y deja ver la palanca: si una optimización sube tu throughput de 2.800 a 4.200 tok/s, tu coste on-prem baja a ~0,73 €/1M —ampliando la ventaja sobre el alquiler—. Por eso el benchmarking (track B) es, indirectamente, la herramienta que más mueve el coste por token: cada mejora de goodput se traduce en este número.

Del coste por token al precio del producto

El coste por token cierra el círculo con el negocio cuando se convierte en coste por unidad de producto. La cadena: coste por token (de la identidad) × tokens por uso de una feature = coste marginal de esa feature. Con eso, tres decisiones de negocio quedan respaldadas por datos:

1. Fijar precio. Si servir una feature cuesta 0,0016 € por uso, el precio al cliente tiene que cubrirlo con margen; el coste por token es el suelo del pricing.
2. Detectar features ruinosas. Una feature que consume muchos tokens (prompts largos, mucha salida) puede costar más de lo que aporta; el coste por request lo revela antes de escalar.
3. Comparar build vs buy a nivel de producto. El coste por token on-prem frente a la tarifa de una API, para esa carga concreta, decide si conviene servir en propio o consumir externo.

Esta es la razón última de todo el track de FinOps: no es contabilidad de infraestructura, es la base cuantitativa de las decisiones de producto y de arquitectura. Un coste por token medido y atribuido convierte “¿esto es rentable?” de una intuición en un cálculo.

Comparación detallada: on-prem, cloud europeo y API

Ampliando la comparación con escenarios, para el mismo trabajo (1M tokens):

La tabla deja ver dos cosas. Primero, el on-prem solo gana si la utilización es alta —a baja ocupación, el idle lo hace más caro que el cloud—, lo que conecta el coste por token con el scheduling y la utilización (el idle de A2). Segundo, la API externa, por competitiva que sea su tarifa, pierde la soberanía del dato —un eje que para datos RGPD no es negociable—. El coste por token es la métrica que pone los tres primeros en la misma escala; la soberanía es la restricción que descarta el último para según qué datos.

Caché de prompts y el coste efectivo

Un matiz que afina el coste por token real: el prefix caching. Cuando muchas peticiones comparten el mismo prefijo (un system prompt largo, un contexto repetido), el motor cachea su cómputo de prefill y no lo recalcula en cada petición. Eso significa que los tokens de entrada cacheados cuestan casi cero la segunda vez y siguientes, así que el coste efectivo por token de una carga con alto hit rate de caché es menor que el coste nominal. Las APIs externas ya lo reflejan con un precio reducido para tokens cacheados; en self-hosted, el efecto está en que el throughput sube (menos prefill que recomputar), lo que por la identidad baja el coste por token.

La implicación para el modelo de coste: si tu carga tiene prefijos compartidos (RAG sobre el mismo corpus, agentes con el mismo system prompt), el coste por token real es inferior al que da el cálculo ingenuo, y conviene medir el hit rate de prefix caching para no sobreestimar el coste. Y al revés: una carga de prompts únicos e irrepetibles no se beneficia de la caché, y su coste por token es el nominal completo. El coste por token, una vez más, no es una constante: depende del modelo, la precisión, la utilización, el goodput y del patrón de reutilización de la carga. Medirlo sobre tu tráfico real, no sobre un benchmark sintético sin caché, es lo que da el número que de verdad pagas.

Estado del arte 2026

• El gateway como estándar: LiteLLM (y alternativas) se consolidan como la capa que mide tokens, atribuye coste y gobierna presupuestos en el stack LLM.
• FOCUS para tokens: capas sobre el gateway generan logs compatibles con FOCUS, integrando el coste de IA con el resto del gasto cloud (intro de FinOps).
• Custom pricing como puente: la conexión OpenCost→gateway vía custom pricing es la forma estándar de dar coste real a los modelos self-hosted.
• Coste por token como KPI de negocio: cada vez más, el coste por token (y por producto) es la métrica que el negocio exige, no el coste del pod.

Límites y trampas (data-driven)

1. Custom pricing olvidado. Sin declararle a LiteLLM el coste real de tu token self-hosted, el response_cost de tus modelos propios es cero o un precio ajeno. Cierra el puente OpenCost→gateway.
2. Throughput estático. El coste por token cambia con el throughput; si optimizas el motor pero no actualizas el custom pricing, el coste reportado se desfasa.
3. Olvidar el prefill/decode. Un coste medio por token vale para reportar; para optimizar, separa entrada y salida.
4. Medir sin gobernar. Spend logs sin presupuestos ni topes son un panel bonito; el valor está en cerrar el bucle con alertas y caps.
5. Comparar tarifas con costes sin igualar supuestos. Tu 1,09 €/1M asume una utilización y un throughput; la tarifa del proveedor, no. Fija los supuestos antes de comparar.

Con el coste por token resuelto, el track de FinOps tiene su métrica central; los artículos siguientes (A5 chargeback multi-tenant, A8 modelo TCO) construyen sobre ella. La cadena completa —hierro (OpenCost) ÷ throughput (benchmark) = coste por token, medido y atribuido por el gateway— es lo que convierte el coste de la IA en un número defendible, en euros y por equipo.

Cierre

El coste por token es la métrica que reconcilia los tres tracks de la serie en un solo número, y su lección de fondo es contraintuitiva: para inferencia propia, el coste de un token no es un precio, es el reflejo de tu eficiencia. Sale de dividir el coste del hierro (OpenCost) por el throughput útil (el goodput de tu benchmark), y se hace visible y gobernable con un gateway (LiteLLM) que cuenta los tokens, los atribuye por equipo y aplica presupuestos. El error que invalida todo el ejercicio es dejar el custom pricing a cero y creerse que la inferencia propia es “gratis”; el acierto es cerrar el puente OpenCost→gateway y mantener el número actualizado cuando cambie el coste del nodo o el throughput. Hecho así, el coste por token responde con datos a la única pregunta que el negocio repite —¿sale a cuenta servir esto en mi hierro?— y lo hace en euros, por equipo y por producto, comparable contra el cloud europeo y contra cualquier API. Para una propuesta de arquitectura soberana, es la columna del cuadro de mando que traduce toda la ingeniería de coste en la frase que cierra una reunión de presupuesto: este es el coste por token, así se mide, y aquí está el banco para reproducirlo.

Ver también

• Chargeback y showback de GPU — repartir el coste por equipo (OpenCost + LiteLLM + Kueue) una vez tienes el coste por token.
• La utilización de GPU como palanca FinOps — por qué el coste por token depende de la ocupación: el coste del idle.
• Cloud GPU: comparativa de precios, compromiso y neoclouds soberanos — el €/GPU-hora alternativo: precios on-demand, spot y reserved de los proveedores cloud europeos frente al on-premise.
• TCO del cluster GPU on-premise: amortización, energía e infraestructura — el €/GPU-hora de referencia en infraestructura propia: CAPEX, energía, red y personal con la hoja de cálculo completa.

Fuentes

• LiteLLM · Spend Tracking — https://docs.litellm.ai/docs/proxy/cost_tracking
• LiteLLM · Custom Pricing (modelos self-hosted) — https://docs.litellm.ai/docs/proxy/custom_pricing
• LiteLLM · Logging — https://docs.litellm.ai/docs/proxy/logging
• LiteLLM · documentación general — https://docs.litellm.ai/docs/
• Statsig · LiteLLM cost tracking — https://www.statsig.com/perspectives/litellm-cost-tracking
• StackPulsar · LiteLLM production monitoring (2026) — https://stackpulsar.com/blog/litellm-production-monitoring/