---
title: "Coste, rendimiento y energía: los tres ejes de la inferencia LLM y la identidad que los une"
url: https://blog.lo0.es/posts/tres-ejes-coste-rendimiento-energia-inferencia-llm/
markdown: https://blog.lo0.es/posts/tres-ejes-coste-rendimiento-energia-inferencia-llm/index.md
lang: es
date: 2026-06-13
lastmod: 2026-06-17
author: "José Manuel Román"
description: "Artículo de apertura de la serie de datos sobre FinOps, benchmarking de LLM y benchmarking de energía, con referencias EUROPEAS (Francia, Alemania, España) y en euros. Las métricas de cada eje, la identidad del throughput que los une, un ejemplo trabajado de unit economics, sensibilidad y datos 2026. Sin opiniones: solo datos y metodología."
tags: ["finops","benchmarking","energia","inferencia","coste-por-token","tco","throughput","soberania","serie-datos"]
translations:
  en: https://blog.lo0.es/en/posts/cost-performance-energy-three-axes-llm-inference/index.md
---

# Coste, rendimiento y energía: los tres ejes de la inferencia LLM y la identidad que los une


> Notación: importes en **euros (N €)**, decimales con coma. Las referencias de coste y
> energía son **europeas** (Francia, Alemania, España), porque el objetivo es defender una
> arquitectura **soberana europea**; cuando una fuente cita precios en dólares se indica
> como "USD". No se usa el símbolo de dólar (en este sitio es delimitador de fórmula).

## Qué es esta serie

Esta es la primera entrega de una serie de **28 artículos de datos** (no de opinión)
sobre las tres dimensiones que deciden si una plataforma LLM **soberana europea** es
sostenible: **coste (FinOps)**, **rendimiento (benchmarking)** y **energía**. El objetivo
es disponer de un cuerpo de cifras verificables, con su metodología, para sostener
decisiones de arquitectura con números y no con intuición. Este primer artículo fija el
marco: qué mide cada eje, **cómo se enlazan entre sí**, un ejemplo trabajado de extremo a
extremo con datos europeos y las referencias de 2026 que se usarán de base.

La tesis cuantitativa, en una frase: los tres ejes **no son independientes**. El throughput
(tokens por segundo) es el denominador común de coste por token y energía por token, y la
energía es, además, entre el **30 % y el 50 %** del propio coste. Optimizar uno mueve los
otros dos. Y en Europa, **dónde** se ubica el cluster (Francia, Alemania, España) cambia a
la vez el coste eléctrico y el carbono por token.

---

## Los tres ejes y sus métricas

| Eje | Pregunta | Métricas clave | Unidad | Familia de herramientas |
|---|---|---|---|---|
| **Coste (FinOps)** | ¿Cuánto cuesta cada unidad de trabajo? | coste/1M tokens (CPM), coste/petición, €/GPU-hora, utilización | €/1M tok, €/h | OpenCost, Kubecost, CloudZero |
| **Rendimiento** | ¿Cuánto trabajo por segundo y con qué latencia? | TTFT, TPOT/ITL, throughput, goodput, P50/P99 | tok/s, ms | GuideLLM, AIPerf, LLMPerf, MLPerf Inference |
| **Energía** | ¿Cuántos vatios por unidad de trabajo? | energía/token, potencia media, PUE, carbono | J/tok, Wh, kWh, gCO₂ | Zeus, CodeCarbon, MLPerf Power, Kepler |

Cada eje tiene su artículo de introducción en profundidad en esta misma tanda; aquí solo
importa cómo encajan. Conviene desglosar un poco más cada uno antes de cruzarlos.

### Detalle del eje de coste

| Métrica | Definición | Por qué importa |
|---|---|---|
| **CPM** (coste/1M tokens) | coste del cluster ÷ tokens producidos | la unidad comparable on-prem vs cloud |
| Coste por petición | coste imputado a una request completa | factura por uso real |
| €/GPU-hora | coste horario de una GPU (amortizado o alquiler) | base de cualquier cálculo |
| Utilización | fracción de la GPU realmente usada | la palanca que mueve todo lo demás |
| Coste fijo vs variable | capex amortizado vs energía/operación | define el punto de equilibrio |

### Detalle del eje de rendimiento

| Métrica | Definición | Fase que domina |
|---|---|---|
| **TTFT** | latencia hasta el primer token | prefill |
| **TPOT / ITL** | tiempo entre tokens de salida | decode |
| **Throughput** | tokens o peticiones por segundo del sistema | ambas |
| **Goodput** | throughput que cumple el SLO (no el bruto) | el número honesto |
| **P95 / P99** | percentiles de latencia (no la media) | la experiencia real |

### Detalle del eje de energía

| Métrica | Definición | Unidad |
|---|---|---|
| Potencia media | consumo instantáneo promedio | W |
| **Energía por token** | energía por token generado | J/token |
| Energía total | integral de potencia en el tiempo | Wh, kWh |
| **PUE** | overhead del datacenter (refrigeración, pérdidas) | ratio ≥ 1 |
| Carbono | energía × intensidad de red | gCO₂eq |

---

## La identidad que une los tres ejes: el throughput

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

$$\text{CPM} = \frac{\text{coste del cluster por hora}}{\text{throughput (tok/s)} \times 3600 / 10^6}$$

La **energía por token** tiene exactamente la misma forma, con la potencia en el
numerador:

$$\text{energía por token (J)} = \frac{\text{potencia media (W)}}{\text{throughput (tok/s)}}$$

Las dos comparten el **mismo denominador**: el throughput. De ahí la consecuencia operativa
clave: **toda mejora de rendimiento que suba tokens/s baja a la vez el coste por token y la
energía por token**. No son tres optimizaciones separadas; el throughput las mueve juntas.
Por eso el benchmarking de rendimiento (eje 2) es, en el fondo, también una herramienta de
FinOps y de eficiencia energética.

La relación CPM↔throughput es directa: a mayor throughput, menor CPM. Es la identidad sobre
la que se construye todo el análisis de coste de la serie.

---

## Ejemplo trabajado: unit economics de un nodo 8×H100 en Europa

Para ver la identidad en acción, un cálculo de extremo a extremo sobre un nodo de ejemplo
(**8×H100 SXM**, Llama 3.1 70B FP16 servido con vLLM), con precios **europeos**. Cifras de
orden de magnitud; la metodología es lo importante.

**Datos de partida:**

| Parámetro | Valor | Fuente |
|---|---|---|
| Alquiler cloud europeo (Scaleway, por H100) | 2,73 €/h | [Scaleway](https://www.scaleway.com/en/h100/) |
| → nodo 8×H100 on-demand | ~21,84 €/h | 8 × 2,73 |
| Coste on-prem amortizado (estimación) | ~10–13 €/h | capex 24–36 meses + opex |
| Throughput | 2.800 tok/s | benchmark de referencia |
| Potencia por H100 (TDP) | hasta 700 W | [NVIDIA](https://www.nvidia.com/en-us/data-center/h100/) |
| PUE de referencia | 1,4 | típico de datacenter |

**Coste por millón de tokens.** Con 2.800 tok/s, el throughput horario es
2.800 × 3.600 / 10⁶ = 10,08 millones de tokens/hora. Por tanto:

$$\text{CPM (cloud)} = \frac{21{,}84}{10{,}08} \approx 2{,}17 \text{ €/1M tok}$$

Con el coste on-prem amortizado (~11 €/h) baja a **~1,09 €/1M tok** — la diferencia entre
alquilar a un proveedor y amortizar hierro propio.

**Energía por token.** La potencia de las 8 tarjetas es 8 × 700 = 5.600 W (solo placa).
Sobre 2.800 tok/s:

$$\text{energía por token} = \frac{5.600}{2.800} = 2 \text{ J/token (placa)}$$

Sobre un millón de tokens son 2 × 10⁶ J = 0,56 kWh (solo GPU). Aplicando el PUE 1,4: ~0,78
kWh por millón de tokens. A precio mayorista francés (~0,058 €/kWh) eso son ~0,045 € de
electricidad por millón de tokens; en Alemania (~0,091 €/kWh), ~0,071 € — un 57 % más, por
la red, no por el modelo.

**El enlace.** Si una optimización de serving subiera el throughput de 2.800 a 4.200 tok/s
(+50 %), el CPM caería a ~1,45 €/1M tok **y** la energía por token a ~1,33 J — los dos a la
vez, por el mismo denominador. Esa es la identidad, con números.

---

## La energía está *dentro* del coste

El segundo enlace: la energía no es un eje aparte del coste, es **un componente grande de
él**. Datos de referencia 2026:

| Dato | Valor | Fuente |
|---|---|---|
| Electricidad sobre el TCO (5 años) | **30–40 %** (>50 % en alta densidad 24/7) | [Spheron](https://www.spheron.network/blog/ai-inference-power-electricity-cost-2026/) |
| Mayorista day-ahead Francia (mar-2026) | **~58 €/MWh** (0,058 €/kWh) | [TradingEconomics](https://tradingeconomics.com/france/electricity-price) |
| Mayorista day-ahead España | **~54 €/MWh** (0,054 €/kWh) | [TradingEconomics](https://tradingeconomics.com/spain/electricity-price) |
| Mayorista day-ahead Alemania | **~91 €/MWh** (0,091 €/kWh) | [TradingEconomics](https://www.tradingeconomics.com/germany/electricity-price) |
| Coste eléctrico/token a 80 % util | **¼** que a 20 % util | [Spheron](https://www.spheron.network/blog/ai-inference-power-electricity-cost-2026/) |

Aviso de método: el **mayorista** (day-ahead) no es lo que paga una empresa; el **retail
industrial** añade peajes de red e impuestos (aproximadamente ×1,5–2). Pero el orden
relativo se mantiene: **Francia y España, baratas; Alemania, cara.**

El tercer enlace, la **utilización**, cierra el triángulo: la potencia se consume aunque la
GPU esté ociosa, así que repartir el coste fijo (energía incluida) sobre más tokens —más
throughput, más ocupación— **baja los tres ejes a la vez**. El coste eléctrico por token a
80 % de utilización es la cuarta parte que a 20 %.

> **Diagrama:** Los tres ejes (coste, rendimiento, energía) enlazados por el throughput en el centro; la energía es además un componente del coste — [verlo en la versión HTML](https://blog.lo0.es/posts/tres-ejes-coste-rendimiento-energia-inferencia-llm/)

---

## Análisis de sensibilidad: qué mueve el coste por token

Cuatro palancas dominan el CPM, y conviene conocer su elasticidad antes de defender
cualquier cifra:

| Palanca | Cambio | Efecto en el CPM | Mecanismo |
|---|---|---|---|
| **Throughput** | +50 % tok/s | −33 % CPM | denominador directo |
| **Utilización** | 20 % → 80 % | hasta −75 % en la parte eléctrica | reparte coste fijo |
| **Ubicación (energía)** | Alemania → Francia | baja la parte eléctrica (~37 % menos €/kWh) | mayorista FR < DE |
| **Amortizar vs alquilar** | 21,84 → 11 €/h | −50 % CPM | quita el margen del proveedor |
| **Cuantización (FP8/INT4)** | +throughput, −VRAM/KV | baja CPM y J/token | misma identidad |

Lectura: el CPM **no es un número, es una función** de utilización, throughput, ubicación
(precio de energía) y modelo de propiedad. Cualquier comparativa on-prem vs cloud que no
fije esos supuestos no es comparable — y ese es justo el trabajo del artículo de síntesis.

---

## Modelo TCO simplificado (on-premise)

El coste real on-premise no es la GPU sola: es **capex amortizado + opex**, sobre un ciclo
de hardware de 24–36 meses. Estructura de referencia de un nodo de inferencia:

| Componente | Tipo | Peso típico | Notas |
|---|---|---|---|
| GPUs | capex | el grueso | amortizar a 24–36 meses |
| Servidor, red, BMC | capex | medio | NICs, switching, gestión out-of-band |
| Electricidad | opex | **30–50 % del TCO** | según país (FR/ES baratas, DE cara) y PUE |
| Refrigeración | opex | dentro del PUE | PUE 1,2–1,6 típico |
| Mantenimiento y soporte | opex | medio | repuestos, contratos, RMA |
| Personal y operación | opex | variable | el coste oculto que el alquiler cloud incluye |

La diferencia entre el alquiler cloud (21,84 €/h en el ejemplo) y el coste real amortizado
(~10–13 €/h) es este desglose: el proveedor cobra un margen por absorber capex,
refrigeración y operación. El punto de equilibrio aparece cuando el volumen sostenido
supera **~2M tokens/día**, con amortización típica en **6–12 meses**
([Spheron](https://www.spheron.network/blog/ai-inference-cost-economics-2026/)). Por debajo
de ese umbral, alquilar suele ganar; por encima, amortizar. El artículo A8 desarrolla el
modelo completo y la síntesis S3 lo conecta con el sizing.

---

## Referencia: precio de la GPU-hora en cloud soberano europeo

El otro lado del comparativo on-prem es el precio de **alquilar** la GPU. Para una
plataforma soberana europea, lo relevante no son AWS/GCP/Azure (sujetos a la **US CLOUD
Act**), sino los proveedores europeos:

| Proveedor | H100 (€/hora) | Ubicación | Soberanía |
|---|---|---|---|
| **Scaleway** | desde **2,73** | París, Varsovia | jurisdicción UE, **exento US CLOUD Act** |
| **OVHcloud** | +40–45 % vs Scaleway | Francia, Alemania | jurisdicción UE, **exento US CLOUD Act** |
| Hyperscalers (referencia) | 3–7 USD | global | sujetos a US CLOUD Act |

Datos: Scaleway ofrece la H100 desde **2,73 €/h** en datacenters europeos (París, Varsovia),
con modelos y datos bajo jurisdicción UE, inmunes a regulación extraterritorial; OVHcloud la
sirve desde Francia y Alemania, ~40–45 % más cara que Scaleway a marzo de 2026. Ambos están
**exentos de la US CLOUD Act**, el requisito fundacional de soberanía para datos sujetos a
RGPD ([Scaleway](https://www.scaleway.com/en/h100/), [DeployBase](https://deploybase.ai/articles/ovhcloud-gpu-pricing)).

Implicación para la propuesta: el comparativo no es solo coste, es **coste + soberanía**. Un
cluster on-prem propio o un cloud europeo mantienen los datos bajo jurisdicción UE; un
hyperscaler estadounidense, no — por barato que salga la GPU-hora. Esa es la pata que el
eje de coste por sí solo no captura, y que la síntesis S2 cuantifica.

---

## Referencia de energía y carbono: Francia, Alemania, España

Aquí la elección de país europeo cambia **a la vez** el coste eléctrico y el carbono por
token. Es la tabla más importante para una propuesta soberana:

| País | Mayorista (€/MWh, mar-2026) | Carbono red (gCO₂/kWh) | Perfil |
|---|---|---|---|
| **Francia** | **~58** | **~20–60** | nuclear: barata y muy limpia |
| **España** | **~54** | **~150–170** | renovable + gas: barata, carbono medio |
| **Alemania** | **~91** | **~363** (media 2024) | carbón/gas + renovables: cara y sucia |

Fuentes: precios mayoristas day-ahead ([TradingEconomics](https://tradingeconomics.com/france/electricity-price)),
carbono de Alemania ~363 gCO₂/kWh (media 2024, [Statista vía Wikipedia](https://en.wikipedia.org/wiki/Electricity_sector_in_Germany)),
nuclear ~17–35 gCO₂e/kWh ([EEA](https://www.eea.europa.eu/en/analysis/indicators/greenhouse-gas-emission-intensity-of-1)),
España ~167 gCO₂/kWh (2020). El **PUE** multiplica toda esa energía: a 1,4, por cada kWh de
GPU el datacenter gasta 1,4 kWh con refrigeración incluida.

El cálculo, sobre el nodo de ejemplo (0,78 kWh por millón de tokens, con PUE): en
**Francia** (~40 gCO₂/kWh) son **~31 gCO₂ por millón de tokens**; en **Alemania** (~363
gCO₂/kWh), **~283 gCO₂ por millón** — un factor de **~9×**. Es decir, una misma carga
servida en Francia emite del orden de **9× menos carbono por token** que en Alemania, y
cuesta ~37 % menos de electricidad — **sin tocar una línea del stack**, solo por la red del
país. **Ubicar el cluster en Francia
o España es, a la vez, una palanca de coste, de carbono y de cumplimiento.** La intensidad
horaria de red se obtiene de **ElectricityMaps**, la fuente de referencia para estos
cálculos.

Contexto de escala: los datacenters globales consumieron **~460 TWh en 2025** (≈1,8 % de la
electricidad mundial), y la IEA proyecta superar **800 TWh en 2028** — razón por la que la
eficiencia energética por token deja de ser un detalle y pasa a ser una restricción de
diseño, y por la que el carbono entra en la ecuación regulatoria europea.

---

## Soberanía y regulación: el eje que no aparece en el CPM

Para una plataforma europea hay un cuarto factor que los tres ejes numéricos **no
capturan**, y que puede invalidar la cifra de coste más baja: la **jurisdicción**. Tres
frentes que convierten "la GPU-hora más barata" en "la GPU-hora más barata *que cumple*":

| Frente | Qué exige | Implicación de arquitectura |
|---|---|---|
| **RGPD + US CLOUD Act** | datos personales bajo jurisdicción accesible por autoridades de EE. UU. están expuestos | cloud europeo (Scaleway/OVHcloud) u on-prem mantienen los datos en la UE |
| **EU AI Act** | obligaciones para sistemas de alto riesgo (trazabilidad, control, documentación) | el control on-prem facilita auditabilidad y cumplimiento |
| **CSRD / reporte de emisiones** | reportar la huella de carbono (scope 2) | una red baja en carbono (Francia) mejora el dato reportado |

El punto clave para la propuesta: un hyperscaler estadounidense puede ofrecer una GPU-hora
competitiva, pero **mete los datos bajo la US CLOUD Act**, lo que para datos sujetos a RGPD
es un riesgo de cumplimiento, no un ahorro. Por eso el comparativo de esta serie no se hace
en USD contra proveedores estadounidenses: se hace en euros, contra opciones que mantienen
la **soberanía del dato** —on-prem propio o cloud europeo—. El coste, la energía y el
carbono son ejes medibles; la soberanía es la restricción que decide **qué opciones entran
siquiera en la tabla**. Esto enlaza con [el mapeo del EU AI Act sobre la arquitectura
on-premise](https://blog.lo0.es/posts/eu-ai-act-mapeo-arquitectura-llm-on-premise/index.md) y con [los controles
técnicos ENS × ISO 42001 × EU AI Act](https://blog.lo0.es/posts/controles-tecnicos-ens-42001-eu-ai-act/index.md).

La conclusión operativa: **Francia y España no solo salen más baratas y más limpias que
Alemania; al ser jurisdicción UE, cumplen la restricción de soberanía que un hyperscaler
estadounidense no cumple a ningún precio.** Tres ventajas que se refuerzan, y que la
propuesta puede defender con la misma tabla.

---

## Metodología: cómo leer (y no engañarse con) estas cifras

Cinco advertencias que aplican a todos los datos de esta serie:

1. **Placa vs nodo.** La potencia de la GPU (700 W por H100) es el **suelo**; el nodo
   completo (CPU, NICs, fuentes, ventiladores) consume más. Compara siempre el mismo límite.
2. **Mayorista vs retail.** El precio day-ahead no es lo que paga la empresa; el retail
   industrial añade peajes e impuestos. Usa el que corresponda a tu contrato.
3. **Medido vs estimado.** Un dato de vatímetro y uno de estimación por `nvidia-smi` no son
   lo mismo; la diferencia se cuantifica en los artículos de energía.
4. **Supuestos de amortización.** El coste/hora on-prem depende del ciclo de hardware (24 vs
   36 meses) y de la utilización asumida; cambiar esos supuestos mueve el CPM más que
   cualquier optimización de serving.
5. **Comparabilidad.** Dos cifras de CPM o de J/token solo son comparables si coinciden
   modelo, precisión, longitud de contexto, carga **y país**. La mayoría de comparativas
   públicas (y en USD) no fijan esos supuestos — por eso la serie reproduce las que importan
   con harness propio y datos europeos.

---

## El cuadro de mando combinado

El destino de la serie es un único cuadro donde cada modelo/configuración/ubicación se
puntúa en los ejes a la vez, para decidir sobre una **frontera de Pareto** y no sobre un
solo número. Un ejemplo **ilustrativo** (cifras de orden de magnitud) sobre el mismo nodo
8×H100:

| Candidato | CPM (€/1M) | Goodput (tok/s) | Energía (J/tok) | Carbono (gCO₂/1M) | Soberanía |
|---|---|---|---|---|---|
| A · 70B FP16, on-prem Francia | ~1,09 | ~2.800 | ~2,0 | bajo (red ~40 gCO₂/kWh) | UE |
| B · 70B FP8, on-prem Francia | ~0,75 | ~4.000 | ~1,4 | más bajo | UE |
| C · Scaleway on-demand | ~2,17 | ~2.800 | n/d | bajo (FR) | UE |
| D · hyperscaler US | ~3,0 | ~2.800 | n/d | depende región | **no UE** |

Lectura: **B domina a A** en los tres ejes propios gracias a FP8. **C** (cloud europeo) es
más caro por token pero traslada capex y operación, manteniendo la soberanía. **D**
(hyperscaler) puede ser competitivo en coste pero **pierde la soberanía** — un eje que para
datos RGPD no es negociable. Ningún número aislado decide: la elección sale de **ver la
fila entera**.

La trampa que el cuadro evita: **optimizar un solo eje**. Cada celda la rellenará un
artículo de la serie con datos medidos.

---

## Dónde se mide cada eje: del diseño a producción

Cada eje se mide en tres momentos distintos, con herramientas distintas y precisión
creciente. Confundirlos es una fuente habitual de cifras que no cuadran:

| Eje | Diseño (estimación) | Benchmark (controlado) | Producción (continuo) |
|---|---|---|---|
| **Coste** | datasheet, precio GPU-hora | CPM medido sobre carga sintética | OpenCost/Kubecost por equipo y token |
| **Rendimiento** | throughput teórico (roofline) | GuideLLM/AIPerf con SLO | OTel/Langfuse sobre tráfico real |
| **Energía** | TDP × horas | Zeus/MLPerf Power en banco | Kepler/DCGM por pod en el cluster |

La regla: una cifra de **diseño** sirve para dimensionar, pero no para defender una
propuesta; para eso hace falta una cifra de **benchmark** reproducible, y para operar, una
de **producción** continua. Cuando alguien rebata un número de la propuesta, la respuesta no
es "lo dice un blog", sino "este es el banco, esta la metodología, reprodúcelo".

---

## Glosario de unidades y conversiones

| Magnitud | Unidad | Conversión / referencia |
|---|---|---|
| Energía | julio (J), vatio-hora (Wh) | 1 Wh = 3.600 J; 1 kWh = 3,6 MJ = 3.600.000 J |
| Potencia | vatio (W) | 1 W = 1 J/s; H100 ≈ 700 W de TDP |
| Energía por token | J/token | = potencia media (W) ÷ throughput (tok/s) |
| Throughput | tok/s | tokens generados por segundo del sistema |
| Coste por token | €/1M tok (CPM) | = coste/hora ÷ (tok/s × 3.600 / 10⁶) |
| Latencia | ms | TTFT (primer token), TPOT/ITL (entre tokens) |
| PUE | ratio (≥1) | energía total del DC ÷ energía de cómputo |
| Carbono | gCO₂eq | = energía (kWh) × PUE × intensidad de red (gCO₂/kWh) |

Conversión útil de cabeza: a 700 W constantes, una H100 consume ~0,7 kWh por hora, ~16,8
kWh al día y ~6.130 kWh al año (solo placa, sin PUE). Multiplicado por el PUE y el precio de
energía de tu país (FR ~0,058, ES ~0,054, DE ~0,091 €/kWh mayorista), ese número es la base
de la parte eléctrica del TCO.

---

## Cómo encaja el resto de la serie

Los 28 artículos se agrupan en cuatro tracks; este es el mapa:

| Track | Qué aporta | Cierra en |
|---|---|---|
| **FinOps (8)** | medir y asignar el coste, modelo TCO | coste/token comparable on-prem vs cloud europeo |
| **Benchmarking LLM (8)** | medir rendimiento de forma reproducible | frontera de Pareto de motores |
| **Energía (8)** | medir vatios y carbono por token | energía en el TCO y la regulación europea |
| **Síntesis (4)** | cruzar los tres ejes | cuadro de mando, on-prem vs cloud, sizing, harness |

Los tres artículos que siguen a este en la tanda introducen **en profundidad** cada eje:
sus frameworks y el estado del arte. A partir de ahí, cada artículo añade una capa de datos
al cuadro de mando final.

El hilo conductor de las 28 entregas es el de este artículo: **coste, rendimiento y energía
son un solo problema con tres caras, atadas por el throughput y por la energía que vive
dentro del coste — y en Europa, por el país donde se ubica el cluster**. Quien optimice una
cara ignorando las otras acabará con un número bonito y una plataforma que no se sostiene.
El trabajo de la serie es producir las cifras —medidas, fechadas, europeas y reproducibles—
que permitan defender una arquitectura soberana ante cualquier comité con la única respuesta
que cierra un debate técnico: los datos y el banco para reproducirlos.

## Ver también

- [Comparativa de motores de serving (vLLM/SGLang/TRT-LLM/Dynamo)](https://blog.lo0.es/posts/comparativa-motores-serving-pareto/index.md) — la síntesis del eje de rendimiento: qué motor gana en cada punto de la frontera goodput-latencia con datos medidos.
- [Benchmarks de calidad de LLMs: MMLU, MT-Bench, HELM y los leaderboards que importan](https://blog.lo0.es/posts/benchmarks-de-calidad-llm/index.md) — la dimensión de calidad que complementa al rendimiento: cómo los leaderboards públicos permiten calibrar el modelo correcto para cada SLO.
- [Leaderboards de eficiencia energética de LLMs](https://blog.lo0.es/posts/leaderboards-energia-llm/index.md) — la síntesis del eje de energía: los rankings de J/token y cómo leerlos sin dejarse engañar por el setup del benchmark.
- [Cloud GPU: comparativa de precios, compromiso y neoclouds soberanos](https://blog.lo0.es/posts/cloud-gpu-commitment-spot-neoclouds/index.md) — la pieza del eje de coste para arquitecturas cloud o híbridas: precios on-demand, spot y reserved de los proveedores europeos en 2026.
- [TCO del cluster GPU on-premise: amortización, energía e infraestructura](https://blog.lo0.es/posts/tco-on-premise-gpu-cluster/index.md) — la pieza del eje de coste para arquitecturas propias: el €/GPU-hora real con CAPEX, energía y operación desglosados.
- [Sesgo de medición y reproducibilidad en benchmarks LLM](https://blog.lo0.es/posts/sesgo-medicion-reproducibilidad-bench/index.md) — las trampas metodológicas que hacen que dos benchmarks del mismo motor den resultados incompatibles: la base para confiar en los datos de esta serie.
- [Del vatio al carbono: PUE, intensidad de la red y el coste real de un token](https://blog.lo0.es/posts/del-vatio-al-carbono-pue-grid/index.md) — cómo convertir los vatios del GPU en gCO₂eq y en euros eléctricos, cerrando el bucle entre el eje de energía y el de coste.
- [Palancas de eficiencia energética en inferencia LLM](https://blog.lo0.es/posts/palancas-eficiencia-energetica-inferencia/index.md) — las optimizaciones que mueven los tres ejes a la vez: quantization, batching y motor como palancas que reducen J/token, €/token y mejoran el goodput simultáneamente.
- [El harness reproducible de medición de coste, rendimiento y energía](https://blog.lo0.es/posts/harness-reproducible-medicion-coste-rendimiento-energia/index.md) — el banco de pruebas que materializa la metodología de este artículo: cómo producir los datos de los tres ejes con un solo experimento reproducible.

## Fuentes

- Scaleway · H100 GPU instance (precio €/h, soberanía UE) — https://www.scaleway.com/en/h100/
- DeployBase · OVHcloud GPU Pricing (soberanía europea) — https://deploybase.ai/articles/ovhcloud-gpu-pricing
- TradingEconomics · precio electricidad Francia / Alemania / España — https://tradingeconomics.com/france/electricity-price
- EEA · intensidad de emisiones de la electricidad en Europa — https://www.eea.europa.eu/en/analysis/indicators/greenhouse-gas-emission-intensity-of-1
- Electricity sector in Germany (carbono ~363 gCO₂/kWh) — https://en.wikipedia.org/wiki/Electricity_sector_in_Germany
- Spheron · AI Inference Power & Cost Economics (2026) — https://www.spheron.network/blog/ai-inference-cost-economics-2026/
- NVIDIA · H100 (TDP/specs) — https://www.nvidia.com/en-us/data-center/h100/