---
title: "Del GPU-hora al coste por token: la métrica que compara on-prem y cloud"
url: https://blog.lo0.es/posts/coste-por-token-y-por-request/
markdown: https://blog.lo0.es/posts/coste-por-token-y-por-request/index.md
lang: es
date: 2026-06-14
lastmod: 2026-06-17
author: "José Manuel Román"
description: "Deep dive de datos: cómo se calcula el coste por token y por request de inferencia propia, por qué no es un precio de lista sino el €/GPU-hora dividido por el throughput, cómo se instrumenta con el gateway LiteLLM (spend logs, response_cost, custom pricing, atribución por equipo) y cómo se compara on-prem vs cloud europeo. Con fuentes."
tags: ["finops","coste-por-token","litellm","gateway","opencost","chargeback","soberania","serie-datos"]
translations:
  en: https://blog.lo0.es/en/posts/gpu-hour-to-cost-per-token-on-prem-vs-cloud/index.md
---

# 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:

> **Diagrama:** Las dos mitades del coste por token: el coste del hierro de OpenCost y el conteo de tokens del gateway, que al dividirse dan el coste por token — [verlo en la versión HTML](https://blog.lo0.es/posts/coste-por-token-y-por-request/)

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](https://docs.litellm.ai/docs/proxy/cost_tracking)).

Sus mecanismos clave:

| Mecanismo | Qué hace |
|---|---|
| `response_cost` | el coste de cada respuesta, accesible en el logging (`kwargs["response_cost"]`) |
| **Spend logs** | una fila por petición con tokens, modelo, usuario, clave y coste (SQLite/PostgreSQL) |
| **Tags** | etiquetar cada request por equipo, proyecto, entorno y *tier* de modelo |
| **Budgets** | presupuestos y rate limits por equipo o usuario |
| **Custom callbacks** | loggers a medida para clave/usuario/modelo/tokens/coste |

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](https://docs.litellm.ai/docs/proxy/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](https://docs.litellm.ai/docs/proxy/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):

```yaml
# 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:

| Concurrencia | Throughput (tok/s) | Coste por 1M tokens |
|---|---|---|
| 1 | 350 | **~8,73 €** |
| 8 | 2.100 | **~1,46 €** |
| 16 | 3.330 (goodput) | **~0,92 €** |
| 24 | 3.900 bruto / 2.420 goodput | ~0,78 € bruto / **~1,26 € sobre goodput** |

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—.

| Modelo (ejemplo, mismo nodo) | Throughput relativo | Coste por token relativo |
|---|---|---|
| 8B | alto | bajo |
| 70B FP8 | medio | medio |
| 70B FP16 | bajo | alto |

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:

> **Diagrama:** Atribución del coste por token: el gateway etiqueta cada peticion por equipo y producto, agrega el gasto y produce el chargeback con presupuestos y topes — [verlo en la versión HTML](https://blog.lo0.es/posts/coste-por-token-y-por-request/)

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:

| Equipo | Tokens/mes | Coste por token aplicado | Coste imputado |
|---|---|---|---|
| A · chat-prod | 240M | 1,09 €/1M (70B FP8) | ~262 € |
| B · batch | 90M | 0,40 €/1M (8B) | ~36 € |
| C · experimentación | 15M | 1,09 €/1M (70B) | ~16 € + idle |

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:

| Control | Qué hace | Cuándo |
|---|---|---|
| **Presupuesto blando** | alerta (Slack) al superar un umbral | seguimiento de equipos |
| **Rate limit** | limita peticiones/tokens por minuto | evitar picos de coste |
| **Tope duro (hard cap)** | la clave no puede gastar más | claves que nunca deben pasarse |

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:

| Opción | Coste por 1M tokens | Notas |
|---|---|---|
| On-prem amortizado (8×H100, 2.800 tok/s) | **~1,09 €** | tu hierro, tu soberanía |
| Cloud europeo Scaleway (8×H100, on-demand) | **~2,17 €** | UE, sin operar hierro |
| API externa (modelo propietario) | tarifa del proveedor | sin soberanía del dato |

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):

| Opción | Coste/1M tok | Soberanía | Cuándo encaja |
|---|---|---|---|
| On-prem amortizado, alta utilización | **~0,7–1,1 €** | total (UE) | volumen alto y sostenido |
| On-prem amortizado, baja utilización | **~2–4 €** | total (UE) | malo: el idle dispara el coste |
| Cloud europeo (Scaleway, on-demand) | **~2,2 €** | UE | volumen variable, sin operar hierro |
| Cloud europeo (reserved/comprometido) | **~1,5–1,8 €** | UE | volumen medio comprometido |
| API externa propietaria | tarifa del proveedor | **no UE** | prototipo / sin requisito de soberanía |

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](https://blog.lo0.es/posts/chargeback-showback-multitenancy-gpu/index.md) — repartir el coste por equipo (OpenCost + LiteLLM + Kueue) una vez tienes el coste por token.
- [La utilización de GPU como palanca FinOps](https://blog.lo0.es/posts/utilizacion-gpu-como-finops/index.md) — por qué el coste por token depende de la ocupación: el coste del idle.
- [Cloud GPU: comparativa de precios, compromiso y neoclouds soberanos](https://blog.lo0.es/posts/cloud-gpu-commitment-spot-neoclouds/index.md) — 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](https://blog.lo0.es/posts/tco-on-premise-gpu-cluster/index.md) — 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/