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

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

Detalle del eje de rendimiento

Detalle del eje de energía

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:

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:

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

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:

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:

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

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, DeployBase).

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:

Fuentes: precios mayoristas day-ahead (TradingEconomics), carbono de Alemania ~363 gCO₂/kWh (media 2024, Statista vía Wikipedia), nuclear ~17–35 gCO₂e/kWh (EEA), 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”:

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 y con los controles técnicos ENS × ISO 42001 × EU AI Act.

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:

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:

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

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:

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) — 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 — 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 — 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 — 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 — 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 — 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 — 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 — 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 — 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/