Break-Even on lo0 — Blog Técnico

Del SLO al número de GPUs: cómo dimensionar y justificar la inversión en hardware de inferencia

Tue, 16 Jun 2026 11:00:00 +0200

Notación: importes en N € o N USD (fuente denominada en dólares); decimales con coma; separador de millar con espacio fino (1\,234). Hardware de ejemplo genérico: nodos 4×H100 SXM5 80 GB. No se usa el símbolo de dólar (delimitador de fórmula).

TL;DR

Con un SLO de TTFT P99 ≤ 300 ms y ITL P99 ≤ 50 ms para un chat de producción, la utilización máxima de GPU debe quedar en ≤ 63 % en pico.
Un servicio que recibe 5 M peticiones/día con 512 tokens de entrada y 256 de salida en media genera un pico horario de ~11,600 tok/s (con factor de pico 1,8×). Con vLLM sobre H100 SXM5 (Llama-3.3 70B FP8, ~1,850 tok/s a 50 peticiones concurrentes), se necesitan ≥ 10 GPUs en pico para cumplir el SLO, que se traducen en 3 nodos 4×H100 (con headroom).
El coste all-in de esos 3 nodos es ~83 300 € al año por nodo (capex 3 años + opex base); el €/1M tokens en escenario base al 63 % de utilización es ~0,37 €.
Frente a AWS p5 on-demand (~3,90 USD/GPU-hora tras el recorte del 44 % de jun. 2025), el break-even de utilización se sitúa en ~55 %; frente a neoclouds on-demand (~2,01 USD/GPU-hora), no hay break-even factible a utilización media.
El payback del capex se produce entre 13 y 24 meses si la utilización sostenida supera el 70 %.

1. La cadena de dimensionado: de la demanda al número de GPUs

El dimensionado de una plataforma de inferencia sigue una cadena causal de cinco pasos. Cada paso tiene una fórmula; ninguno se puede saltar.

1.1 Paso 1 — Caracterizar la demanda

Parámetro	Símbolo	Ejemplo
Peticiones por día (media)	(D)	5 000 000
Tokens de entrada por petición (media)	(L_{\text{in}})	512
Tokens de salida por petición (media)	(L_{\text{out}})	256
Factor de pico (ratio pico-hora vs media)	(k_{\text{pico}})	1,8
Horas al día con tráfico significativo	(H)	16

El throughput de salida medio:

$$\dot{T}{\text{medio}} = \frac{D \times L{\text{out}}}{86,400,\text{s}} = \frac{5,000,000 \times 256}{86,400} \approx 14,815;\text{tok/s}$$

El throughput pico (hora punta):

$$\dot{T}{\text{pico}} = k{\text{pico}} \times \frac{D \times L_{\text{out}}}{H \times 3,600} = 1{,}8 \times \frac{5,000,000 \times 256}{16 \times 3,600} \approx 40,000;\text{tok/s}$$

Nota: si el perfil de tráfico tiene picos muy pronunciados (relación pico/media > 3), el dimensionado se hace para el pico y la utilización media cae; el análisis de sensibilidad de §5 cuantifica el efecto.

1.2 Paso 2 — Fijar el SLO y derivar la utilización máxima

El SLO de latencia impone un techo a la utilización de GPU. Usando teoría de colas (modelo M/G/1):

$$\rho_{\max} \approx 1 - \frac{1}{\sqrt{1 + C_{s}^{2}}} \cdot \frac{W_{\text{cola}}^{*}}{\bar{s}}$$

donde (\rho) es la utilización, (W_{\text{cola}}^{*}) el tiempo máximo de cola admisible y (\bar{s}) el tiempo medio de servicio por petición. Para el caso simplificado M/M/1 con tiempo de prefill dominante:

$$\rho_{\max} = 1 - \frac{W_{\text{cola}}^{}}{\bar{s} \cdot (1 + W_{\text{cola}}^{}/\bar{s})}$$

La tabla de referencia práctica (derivada de la fórmula de Spheron/Littles Law, 2026):

SLO TTFT P99	Utilización máxima (\rho_{\max})
200 ms	55 %
300 ms	63 %
400 ms	70 %
500 ms	75 %

Para nuestro ejemplo (SLO 300 ms P99): (\rho_{\max} = 0{,}63).

El SLO de ITL impone una restricción adicional: el motor de inferencia debe ser capaz de generar el siguiente token en ≤ 50 ms. En H100 SXM5 con vLLM y Llama-3.3 70B FP8, el ITL P50 a 50 peticiones concurrentes es ~20 ms, con P99 ~45 ms. El ITL es la restricción dominante solo cuando el batch size es muy alto (>64 secuencias) o la VRAM está casi llena.

1.3 Paso 3 — Throughput requerido y throughput por GPU

El throughput que debe servir el cluster en pico, respetando (\rho_{\max}):

$$\dot{T}{\text{requerido}} = \frac{\dot{T}{\text{pico}}}{\rho_{\max}} = \frac{40,000}{0{,}63} \approx 63,500;\text{tok/s (capacidad instalada)}$$

El throughput por GPU (benchmark de referencia, vLLM v0.18.0, Llama-3.3 70B FP8, H100 SXM5 80 GB, 50 peticiones concurrentes):

Motor	Throughput (tok/s por GPU)	TTFT P50 / P95 (50 req)	Fuente
vLLM 0.18.0	1 850	380 ms / 720 ms	Spheron benchmarks, mar. 2026
SGLang 0.5.9	1 920	360 ms / 680 ms	Spheron benchmarks, mar. 2026
TensorRT-LLM 1.2.0	2 100	340 ms / 620 ms	Spheron benchmarks, mar. 2026

Los datos de throughput corresponden al test con Llama 3.3 70B Instruct FP8, 512 tokens entrada / 256 salida, 50 peticiones concurrentes, en H100 SXM5 bare-metal. Véase el análisis de motores en comparativa motores serving Pareto.

Usamos vLLM como referencia de producción generalista: (\dot{T}_{\text{GPU}} = 1,850) tok/s.

1.4 Paso 4 — Número de GPUs y número de nodos

$$N_{\text{GPU}} = \left\lceil \frac{\dot{T}{\text{requerido}}}{\dot{T}{\text{GPU}}} \right\rceil = \left\lceil \frac{63,500}{1,850} \right\rceil = \lceil 34{,}3 \rceil = 35;\text{GPUs}$$

Con nodos 4×H100 SXM5:

$$N_{\text{nodos}} = \left\lceil \frac{N_{\text{GPU}}}{4} \right\rceil = \left\lceil \frac{35}{4} \right\rceil = 9;\text{nodos}$$

Añadimos un headroom del 15 % para fallos de hardware (tasa ~5 % anual en clusters pequeños), upgrades y picos imprevistos:

$$N_{\text{nodos, final}} = \lceil 9 \times 1{,}15 \rceil = 11;\text{nodos} \approx 44;\text{GPUs}$$

Para el ejemplo TL;DR (5 M peticiones/día con perfil de 16 h activas, k 1,8 y SLO 300 ms) el número de nodos es 11. El caso simplificado del TL;DR con k=1 y H=24 da 3 nodos; la diferencia ilustra el impacto del perfil horario.

1.5 Resumen de la cadena

2. Del sizing al coste: modelo TCO

Con (N_{\text{nodos}} = 11) nodos 4×H100 SXM5, el TCO sigue el modelo detallado en TCO on-premise GPU cluster. Aquí se replica la fórmula compacta y se aplica al cluster dimensionado.

2.1 Coste anual por nodo (escenario base)

$$C_{\text{nodo/año}} = \frac{\text{capex nodo}}{\text{años}} + \text{opex nodo/año}$$

Partida	Valor (USD / €)	Nota
Capex nodo 4×H100 (punto medio)	178 500 USD	GPUs + servidor + red + almacenamiento + rack
Amortización 3 años	59 500 USD/año ≈ 55 300 €/año	Lineal
Opex/año (escenario base, cluster 8–16 nodos)	~28 000 €/año	Energía + personal + mant. + colocación
Total anual por nodo	~83 300 €/año	—

Para 11 nodos: 915 300 €/año de coste total fijo.

2.2 Del €/nodo-año al €/GPU-hora

$$\text{EUR/GPU-hora} = \frac{C_{\text{nodo/año}}}{4;\text{GPUs} \times 8,760;\text{h} \times \rho}$$

Utilización (\rho)	EUR/GPU-hora
40 %	5,93
55 %	4,31
63 % (SLO 300 ms)	3,76
70 %	3,39
80 %	2,97
100 %	2,38

2.3 Del €/GPU-hora al €/1M tokens

$$\text{EUR/1M tokens} = \frac{\text{EUR/GPU-hora} \times 10^{6}}{\dot{T}_{\text{GPU}} \times 3,600}$$

Con (\dot{T}_{\text{GPU}} = 1,850) tok/s (vLLM, Llama-3.3 70B FP8):

Utilización	EUR/GPU-hora	EUR/1M tokens
40 %	5,93	0,891
55 %	4,31	0,647
63 % (SLO 300 ms)	3,76	0,564
70 %	3,39	0,509
80 %	2,97	0,446
100 %	2,38	0,357

La identidad completa coste/token en función del throughput y la utilización se desarrolla en coste por token y por request.

2.4 Comparación con cloud (€/1M tokens equivalente)

Para comparar, se convierte el precio cloud al equivalente €/1M tokens usando el mismo throughput de referencia ((\dot{T}_{\text{GPU}} = 1,850) tok/s):

$$\text{EUR/1M tokens (cloud)} = \frac{P_{\text{cloud}} \times 10^{6}}{1,850 \times 3,600}$$

Proveedor / Modalidad	Precio GPU-hora (USD)	EUR/GPU-hora ((1,\text{USD} \approx 0{,}93,\text{EUR}))	EUR/1M tokens equiv.
AWS p5 on-demand (post jun. 2025)	3,90	3,63	0,545
AWS p5 reserved 1 año	~2,50	2,33	0,350
CoreWeave on-demand	~2,01	1,87	0,281
CoreWeave reserved 3 años	~1,49	1,39	0,209
GCP A3 on-demand	~3,67	3,41	0,512
Azure ND H100 v5 on-demand	~6,98	6,49	0,975

Fuentes: IntuitionLabs (jun. 2026), CloudZero (jun. 2026), Spheron GPU pricing (may. 2026).

3. Break-even y payback de la inversión propia

3.1 La fórmula del break-even de utilización

El break-even de utilización (u^{*}) es la utilización a la que el coste anual on-prem por GPU-hora iguala el precio cloud:

$$u^{*} = \frac{\text{capex/año} + \text{opex/año}}{4 \times 8,760 \times P_{\text{cloud}}}$$

donde (P_{\text{cloud}}) es el precio cloud en la misma divisa que los costes on-prem.

Con el escenario base (capex/año 55 300 €, opex/año 28 000 €, total 83 300 €/nodo/año):

Referencia cloud	Precio cloud (EUR/GPU-hora)	(u^{*}) break-even
Azure on-demand (~6,49 EUR)	6,49	23 %
AWS on-demand post-recorte (~3,63 EUR)	3,63	41 %
GCP on-demand (~3,41 EUR)	3,41	44 %
CoreWeave on-demand (~1,87 EUR)	1,87	80 %
CoreWeave reserved 3a (~1,39 EUR)	1,39	>100 % (imposible)
AWS reserved 1a (~2,33 EUR)	2,33	64 %

3.2 Payback del capex

El payback es el tiempo (T_{\text{pay}}) en el que el ahorro acumulado frente al cloud iguala el capex inicial:

$$T_{\text{pay}} = \frac{\text{capex total cluster}}{(\text{coste cloud/año}) - (\text{opex on-prem/año})}$$

donde el coste cloud/año se calcula a la misma utilización sostenida.

Para el cluster de 11 nodos (capex total 11 × 178 500 USD ≈ 1 825 000 USD ≈ 1 697 000 €):

Referencia cloud	Utilización sostenida	Ahorro anual vs cloud	Payback
AWS on-demand (3,63 EUR/h)	70 %	(3,63 − 3,39 EUR) × 4 × 8760 × 0,70 × 11 nodos ≈ 63 900 €/año	~27 meses
AWS on-demand (3,63 EUR/h)	80 %	(3,63 − 2,97) × 4 × 8760 × 0,80 × 11 ≈ 203 600 €/año	~10 meses
GCP on-demand (3,41 EUR/h)	70 %	(3,41 − 3,39) × 4 × 8760 × 0,70 × 11 ≈ 5 400 €/año	~315 meses (no rentable)
Azure on-demand (6,49 EUR/h)	70 %	(6,49 − 3,39) × 4 × 8760 × 0,70 × 11 ≈ 830 000 €/año	~2 meses

El payback de 13 meses citado en estudios como Lenovo TCO 2026 corresponde a utilización ~80 % frente a hyperscalers de precio alto (Azure/AWS pre-recorte). Con los precios actuales (post junio 2025, AWS a 3,90 USD), la ventana se amplía.

3.3 Payback simple (solo capex vs cloud equivalente)

Si se omite el opex on-prem y se compara solo el capex con el ahorro bruto:

$$T_{\text{pay,simple}} = \frac{\text{capex}}{P_{\text{cloud}} \times 4 \times 8,760 \times \rho \times N_{\text{nodos}}}$$

Utilización	AWS (3,63 EUR)	Azure (6,49 EUR)
50 %	54 meses	30 meses
70 %	39 meses	22 meses
80 %	34 meses	19 meses

4. Tabla de decisión: cuándo comprar, alquilar o híbrido

La tabla siguiente es un Pareto de cinco dimensiones. No hay orden implícito entre columnas; la lectura depende de las restricciones de la organización.

Opción	EUR/GPU-hora (util. 70 %)	Capex inicial	Utilización requerida	Soberanía dato	Elasticidad pico
On-prem compra, util. ≥ 70 %	3,39	alto (178 k USD/nodo)	≥ 70 % sostenido	total	ninguna
On-prem compra, util. < 50 %	> 4,75	alto	< 50 % → pierde vs cloud	total	ninguna
Cloud EU soberano OD (Scaleway/Nebius EU)	2,00–3,59	ninguno	cualquiera	sí (UE)	total
AWS p5 on-demand (post jun. 2025)	3,63	ninguno	cualquiera	no (CLOUD Act)	total
CoreWeave on-demand	1,87	ninguno	cualquiera	parcial (US)	total
CoreWeave reserved 3 años	1,29–1,39	compromiso financiero	contrato rígido	parcial (US)	ninguna
AWS reserved 1 año	~2,17	compromiso 1 año	contrato	no (CLOUD Act)	ninguna
Híbrido on-prem base + cloud EU pico	2,50–3,39 (ponderado)	medio	base ≥ 70 %, pico elástico	sí (UE)	pico elástico

Criterios de corte previos a la tabla:

Soberanía RGPD: si los datos son personales o el sistema es de riesgo EU AI Act, CoreWeave/AWS quedan descartados antes de comparar precios.
Volumen mínimo para amortizar capex: por debajo de ~2 M tokens/día sostenidos durante 3 años, el capex on-prem no se amortiza frente a AWS on-demand.
Elasticidad de tráfico: picos >3× la base favorecen el híbrido o el cloud puro; base estable favorece el on-prem.

La frontera de Pareto coste/soberanía para datos RGPD deja tres opciones: on-prem, cloud EU soberano e híbrido. Entre ellas decide la utilización sostenida y la predecibilidad del tráfico. Véase el análisis cruzado de los cuatro ejes en on-premise soberano vs hyperscalers.

5. Análisis de sensibilidad

5.1 Sizing vs perfil horario y factor de pico

El número de GPUs crece linealmente con (k_{\text{pico}}) e inversamente con (\rho_{\max}):

$$N_{\text{GPU}} = \left\lceil \frac{D \times L_{\text{out}} \times k_{\text{pico}}}{H \times 3,600 \times \rho_{\max} \times \dot{T}_{\text{GPU}}} \right\rceil$$

Factor de pico (k)	SLO 300 ms ((\rho_{\max}=0{,}63))	SLO 500 ms ((\rho_{\max}=0{,}75))
1,2	8 GPUs (2 nodos)	6 GPUs (2 nodos)
1,8	12 GPUs (3 nodos)	10 GPUs (3 nodos)
2,5	16 GPUs (4 nodos)	13 GPUs (4 nodos)
3,5	22 GPUs (6 nodos)	18 GPUs (5 nodos)

(Ejemplo simplificado a 5 M pet/día con H=24 para ilustrar la sensibilidad al factor de pico)

Un factor de pico 3,5× triplica el número de nodos respecto a k=1,2 manteniendo el mismo SLO. Dimensionar hardware para (k > 2{,}5) deja GPUs paradas el 70 %+ del tiempo; el cloud de pico es más eficiente a partir de ese umbral.

5.2 Break-even vs utilización sostenida

$$u^{*} = \frac{83,300}{4 \times 8,760 \times P_{\text{cloud}}}$$

Precio cloud (EUR/GPU-hora)	(u^{*}) break-even	Escenario
6,49 (Azure OD)	23 %	On-prem gana casi siempre
3,63 (AWS OD)	41 %	On-prem gana si util. > 41 %
3,41 (GCP OD)	44 %	—
2,33 (AWS reserved 1a)	64 %	On-prem gana si util. > 64 %
1,87 (CoreWeave OD)	80 %	Difícil de alcanzar en producción
1,39 (CoreWeave reserved 3a)	>100 %	On-prem nunca cierra brecha

5.3 Break-even vs precio de energía

La energía representa el 6–11 % del TCO total. Su impacto en el break-even es moderado:

Precio energía (EUR/kWh)	Opex energía/año por nodo	EUR/GPU-hora (70 % util.)	(u^{*}) vs AWS OD
0,034 (PPA solar)	1 604 €	3,22	38 %
0,116 (industrial ES, base)	5 475 €	3,39	41 %
0,200 (tarifa alta)	9 437 €	3,57	43 %

La diferencia entre el escenario más barato y el más caro es de solo 5 puntos porcentuales en el break-even. La variable que mueve la aguja es la utilización, no la energía.

5.4 Break-even vs crecimiento de la demanda

Si la demanda crece a una tasa anual (g), la utilización media del cluster (dimensionado para el año 1) sube con el tiempo hasta que se satura y hay que ampliar:

$$\rho(t) = \rho_{0} \times (1 + g)^{t}$$

Crecimiento anual (g)	Tiempo hasta saturación ((\rho \to 100,%))	Decisión
10 %	~11 años	Compra cómoda
30 %	~4 años	Compra con revisión a 3 años
60 %	~2 años	Híbrido: base + cloud elástico
>100 %	<1 año	Cloud puro hasta estabilización

Para crecimientos >30 % anual, la estrategia de compra-sola implica sobredimensionar para el pico futuro o re-comprar hardware en ciclos cortos. El híbrido (base on-prem + cloud para crecimiento) minimiza el capex en riesgo.

5.5 Headroom: el coste del margen de seguridad

El headroom del 15 % en (N_{\text{nodos}}) equivale a tener ~1,6 nodos adicionales de media. Su coste anual es:

$$C_{\text{headroom}} = 0{,}15 \times 83,300;\text{EUR/nodo/año} \times N_{\text{nodos,base}} \approx 12,500 \times 9 = 112,500;\text{EUR/año}$$

Este coste se justifica por:

Tasa de fallo GPU ~5 % anual (en clusters pequeños, documentada por Introl, abr. 2026)
Tiempo de reposición 2–8 semanas (según disponibilidad de mercado)
Picos imprevistos hasta un 20 % sobre el estimado

Si el servicio puede degradarse gracefully (reducción de SLO TTFT de 300 ms a 500 ms en pico extremo), el headroom se puede reducir al 10 %, con un ahorro de ~37 500 EUR/año.

6. Mapa de sensibilidad: €/GPU-hora y break-even en dos ejes

La tabla siguiente cruza utilización y escenario de opex, mostrando el EUR/GPU-hora all-in (escenario base, capex/año 55 300 €):

	Opex bajo (13 000 €/año)	Opex base (28 000 €/año)	Opex alto (75 000 €/año)
Util. 40 %	4,74	5,93	9,06
Util. 55 %	3,45	4,31	6,59
Util. 63 %	3,01	3,76	5,75
Util. 70 %	2,71	3,39	5,18
Util. 80 %	2,37	2,97	4,54
Util. 100 %	1,90	2,38	3,63

El cruce con el precio cloud (AWS OD: 3,63 EUR):

Escenario opex bajo: break-even a ~38 % de utilización
Escenario opex base: break-even a ~41 % de utilización
Escenario opex alto: break-even a ~53 % de utilización

La palanca más grande para reducir el break-even no es el capex del hardware sino el opex (especialmente personal y colocación). Véase el análisis de utilización como palanca FinOps en utilización GPU como FinOps.

7. Integración con el resto de la cadena FinOps

El dimensionado de §1 determina el número de nodos; el TCO de §2 da el coste/hora; la comparación de §3 da el break-even. Estos tres números alimentan directamente los demás instrumentos de la serie:

Instrumento	Input de este artículo	Output
GuideLLM — validación SLO bajo carga	SLO TTFT/ITL P99 del paso 2	Confirmación experimental del throughput real por GPU
Capacity planning inferencia on-premise	Perfil de demanda y N GPUs del paso 4	Política de escalado y autoscaling triggers
Coste por token y por request	EUR/GPU-hora del paso §2.2	EUR/1M tokens por modelo y batching
Cloud GPU commitment y spot	Precios cloud de la tabla §2.4	Optimización del tier cloud complementario
On-premise soberano vs hyperscalers	Break-even de §3	Decisión final compra/alquiler incluyendo eje soberanía
TCO on-premise GPU cluster	Capex y opex de §2.1	Modelo TCO detallado con todas las partidas
Utilización GPU como FinOps	Utilización objetivo del paso 2	Palancas de scheduling para subir la utilización real

Fuentes

Spheron · LLM Inference SLO Engineering: TTFT, ITL, and P99 Latency Budgets for Production AI (2026) — https://www.spheron.network/blog/llm-inference-slo-ttft-itl-latency-budget-guide-2026/
Spheron · vLLM vs TensorRT-LLM vs SGLang: H100 Benchmarks (2026) — https://www.spheron.network/blog/vllm-vs-tensorrt-llm-vs-sglang-benchmarks/
Spheron · GPU Cloud Pricing 2026: H100 from 1.03 USD/hr, B200 from 2.12 USD/hr — https://www.spheron.network/blog/gpu-cloud-pricing-comparison-2026/
Spheron · LLM Inference On-Premise vs GPU Cloud: 2026 Cost and Break-Even Analysis — https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/
MLPerf Inference v5.1 — Red Hat: 5 777 tok/s (offline) en Llama 3.1-8B FP8 en H100 — https://www.redhat.com/en/blog/efficient-and-reproducible-llm-inference-red-hat-mlperf-inference-v51-results
MLPerf Inference v6.0 Results Explained: GPU Performance Rankings for AI Workloads (2026) — https://www.spheron.network/blog/mlperf-inference-v6-benchmark-results-2026/
IntuitionLabs · H100 Rental Prices Compared: 1.49–6.98 USD/hr Across 15+ Cloud Providers (2026) — https://intuitionlabs.ai/articles/h100-rental-prices-cloud-comparison
CloudZero · Cloud GPU Pricing Comparison: AWS vs Azure vs GCP For AI Workloads (2026) — https://www.cloudzero.com/blog/cloud-gpu-pricing-comparison/
Lenovo Press · On-Premise vs Cloud: Generative AI Total Cost of Ownership (2026 Edition) — https://lenovopress.lenovo.com/lp2368-on-premise-vs-cloud-generative-ai-total-cost-of-ownership-2026-edition
Introl · GPU Infrastructure TCO Model: 5-Year Cost Analysis for Enterprise AI (abr. 2026) — https://introl.com/blog/gpu-infrastructure-tco-5-year-cost-model
GMI Cloud · NVIDIA H100 GPU Pricing 2026: Rent vs Buy Cost Analysis — https://www.gmicloud.ai/en/blog/nvidia-h100-gpu-pricing-2026-rent-vs-buy-cost-analysis
Red Hat · 233 % 3-year ROI and 13 months to payback with Red Hat AI (feb. 2026) — https://www.redhat.com/en/blog/233-3-year-return-investment-and-13-months-payback-red-hat-ai
VentureBeat · 5 % GPU utilization: the 401 billion USD AI infrastructure problem — https://venturebeat.com/infrastructure/5-gpu-utilization-the-401-billion-ai-infrastructure-problem-enterprises-cant-keep-ignoring/
DZone · Queueing Theory for LLM Inference — https://dzone.com/articles/queueing-theory-for-llm-inference
GuideLLM · Evaluate LLM deployments for real-world inference (Red Hat Developer, jun. 2025) — https://developers.redhat.com/articles/2025/06/20/guidellm-evaluate-llm-deployments-real-world-inference

TCO completo de un cluster GPU on-premise: del capex al €/GPU-hora all-in y el break-even contra cloud

Tue, 16 Jun 2026 06:00:00 +0200

Notación: importes en N € o N USD (fuente denominada en dólares); decimales con coma; separador de millar con espacio. No se usa el símbolo de dólar (delimitador de fórmula). Datos centrados en Europa/España. Hardware de ejemplo genérico: cluster de N nodos, cada uno con 4×H100 SXM5 80 GB.

TL;DR

Un nodo 4×H100 SXM5 cuesta entre 150 000 USD y 200 000 USD de capex total (GPUs + servidor + red + almacenamiento + rack prorrateo). Amortizado a 3 años con opex europeo (energía a ~0,116 €/kWh industrial, PUE 1,54 medio o 1,2 con líquido, 0,3 FTE personal), el coste all-in oscila entre 3,10 USD/GPU-hora (utilización 100 %) y 6,20 USD/GPU-hora (utilización 50 %). El break-even frente a AWS p5 on-demand (~6,88 USD/GPU-hora) se cruza en torno al 70 % de utilización; frente a un neocloud reserved 3 años (~1,49–2,10 USD/GPU-hora), el on-prem nunca cierra la brecha en ese escenario. La utilización es la variable que decide el eje de coste, no el precio del hardware.

El modelo: supuestos declarados

Todos los cálculos siguientes parten de estos supuestos. Cambiar cualquiera de ellos mueve la conclusión; se cuantifica en la sección de sensibilidad.

Parámetro	Valor base	Rango de sensibilidad
Nodo	4×H100 SXM5 80 GB (HGX baseboard)	—
Cluster	N nodos (modelo por nodo; escala linealmente)	1–32 nodos
Amortización capex	3 años (lineal)	3–5 años
Utilización GPU	70 %	30 %–100 %
Precio energía	0,116 €/kWh (industrial España, sept. 2025)	0,06–0,20 €/kWh
PUE	1,54 (media global Uptime Institute 2025)	1,15–1,80
Tipo de cambio	1 USD = 0,93 € (referencia jun. 2026)	—

Fuente energía: GlobalPetrolPrices · Spain Business Electricity, sept. 2025. Fuente PUE: Uptime Institute Global Data Center Survey 2025 — PUE global medio estancado en 1,54 por sexto año consecutivo; hyperscalers 1,10–1,15; colocación/empresa 1,58–1,80; instalaciones con menos de 5 años de antigüedad, 1,48. PUE 1,2 alcanzable con refrigeración líquida directa al chip.

Desglose capex por nodo 4×H100 SXM5

GPUs

Componente	Precio unitario (USD)	Cantidad	Subtotal (USD)	Fuente y fecha
H100 SXM5 80 GB (tarjeta)	30 000–40 000	4	120 000–160 000	GMI Cloud, abr. 2026 · Introl, abr. 2026

El rango refleja variabilidad de mercado y descuentos por volumen (5–15 % para pedidos >50 unidades). Las H100 SXM5 requieren el HGX baseboard de NVIDIA; no se venden sueltas para instalación directa en servidores estándar.

Servidor / HGX baseboard

El nodo completo 4×H100 SXM utiliza el HGX H100 4-GPU baseboard de NVIDIA más un servidor host compatible. Modelos de referencia: Supermicro SYS-421GU-TNXR (4U, Dual Intel Xeon 4th Gen, HGX H100 4-GPU) y su equivalente en Dell.

Componente	Coste estimado (USD)	Nota
Servidor chassis + CPU (2× Xeon) + RAM (512 GB DDR5) + PSU redundante	18 000–25 000	Basado en Supermicro SYS-821GE bare sin GPUs a ~24 806 USD (xicomputer.com, jun. 2026); proporcional al 4-GPU
HGX H100 4-GPU baseboard	incluido en precio GPU	NVIDIA HGX plataforma; no precio separado público
NVLink inter-GPU (dentro del nodo)	incluido en baseboard	4 GPUs conectadas por NVLink 4.0 en el baseboard HGX

Claim de marketing (sin verificación independiente): Supermicro anuncia reducción de costes de energía del datacenter de hasta el 40 % con refrigeración líquida en sus servidores HGX H100 (Supermicro press release).

Red InfiniBand NDR

Para un cluster multi-nodo con paralelismo tensorial entre nodos, la red GPU-GPU es crítica. NDR InfiniBand (400 Gb/s por puerto) es el estándar de facto para clusters HGX.

Componente	Coste estimado por nodo (USD)	Fuente / Nota
Switch NVIDIA Quantum-2 NDR 400G (64 puertos, prorrateado entre N nodos)	2 000–4 000	Switch ~35 000 USD (Introl, abr. 2026); a 16 nodos, ~2 200 USD/nodo
Cables/transceptores InfiniBand NDR (4 puertos por nodo × ~1 000 USD/puerto)	4 000	Estimación basada en ~1 000 USD/transceptor óptico (Introl, abr. 2026)
Red InfiniBand (prorrateado por nodo 4-GPU)	~6 000–8 000	—

Para inferencia serving dentro de un nodo (4 GPUs con NVLink), la red inter-nodo es menos crítica que para training multi-nodo. Para cargas de prefill-decode disaggregated entre nodos, InfiniBand NDR es necesaria.

Almacenamiento NVMe

Componente	Coste estimado (USD)	Nota
NVMe local (4 TB × 2 unidades U.2/E1.S, datasets de trabajo y checkpoints)	2 000–4 000	~500–1 000 USD/TB NVMe enterprise 2025
Almacenamiento de objetos compartido (NAS/MinIO, prorrateado por nodo)	2 000–5 000	Varía según capacidad total del cluster
Almacenamiento total por nodo	~4 000–9 000	—

Introl modela 50 TB por GPU para operaciones efectivas en clusters de training (Introl, abr. 2026); para inferencia pura, el requerimiento es significativamente menor (pesos del modelo + logs).

Rack, PDU y conectividad de datacenter

Componente	Coste estimado por nodo (USD/año)	Fuente
Colocación rack (alta densidad, 10–15 kW por nodo)	5 000–12 000/año	Encoradvisors · Colocation Pricing 2026: alta densidad 3 000–6 000 USD/mes por rack; a 2 nodos por rack, ~1 500–3 000 USD/mes por nodo = 18 000–36 000 USD/año en tier-1; menor en España
PDU rack, cableado eléctrico (prorrateo)	500–1 000 por nodo (capex amortizado)	Dentro de la partida de colocación o CPD propio

Colocación en España/Europa es estructuralmente más barata que en mercados tier-1 de EE. UU. (Nueva York, Silicon Valley). Para CPD propio, sustituir por coste de espacio propio + amortización de infraestructura eléctrica y de refrigeración.

Resumen capex por nodo 4×H100 SXM5

Partida	Rango (USD)	Punto medio
GPUs (4× H100 SXM5)	120 000–160 000	140 000
Servidor chassis + CPU/RAM/PSU	18 000–25 000	21 500
Red InfiniBand NDR (prorrateo)	6 000–8 000	7 000
Almacenamiento NVMe + objetos	4 000–9 000	6 500
PDU/rack/otros (capex)	2 000–5 000	3 500
Capex total por nodo	150 000–207 000	178 500

Fuentes: GMI Cloud (abr. 2026), Introl (abr. 2026), Spheron (abr. 2026), xicomputer.com (jun. 2026).

Desglose opex por nodo 4×H100 SXM5 (anual)

Energía

Un nodo 4×H100 SXM5 en carga completa consume aproximadamente:

$$P_{\text{nodo}} = 4 \times 700,\text{W (TDP H100 SXM5)} + 800,\text{W (servidor)} \approx 3{,}6,\text{kW (IT)}$$

La potencia total del datacenter incluye el overhead de refrigeración, expresado por el PUE:

$$P_{\text{total}} = P_{\text{IT}} \times \text{PUE}$$

$$\text{coste energía anual} = P_{\text{IT}} \times \text{PUE} \times 8,760,\text{h} \times \text{precio kWh}$$

Con los valores base (PUE 1,54; 0,116 €/kWh):

$$\text{energía/año} = 3{,}6,\text{kW} \times 1{,}54 \times 8,760,\text{h} \times 0{,}116,\text{EUR/kWh} \approx 5,475,\text{EUR}$$

Con PPA solar España (precio referencia Q3 2025: ~34 €/MWh = 0,034 €/kWh según PV Tech, oct. 2025):

$$\text{energía/año (PPA solar)} = 3{,}6 \times 1{,}54 \times 8,760 \times 0{,}034 \approx 1,604,\text{EUR}$$

Escenario energético	Precio (€/kWh)	Coste energía/año por nodo 4-GPU
PPA solar España (Q3 2025)	0,034	~1 604 €
Industrial España (sept. 2025)	0,116	~5 475 €
Europa media (tarifa industrial)	0,160	~7 550 €
Peor caso (sin PPA, tarifa alta)	0,200	~9 437 €

Personal / operación

El coste de personal es la partida más variable según el tamaño del cluster. Para un cluster pequeño (2–8 nodos), la regla práctica es 0,3–0,5 FTE por cluster de soporte de infraestructura GPU (Spheron, abr. 2026).

Tamaño cluster	FTE estimado	Coste FTE (€/año, Europa Occ.)	Coste por nodo 4-GPU (€/año)
2–4 nodos	0,3 FTE	~120 000	36 000–18 000
8–16 nodos	0,5 FTE	~120 000	7 500
32+ nodos	1–2 FTE	~120 000	3 750–7 500

Referencia salarial orientativa: ingeniero de infraestructura GPU con conocimiento de CUDA, InfiniBand y Kubernetes en Europa Occidental, ~90 000–140 000 €/año coste total empresa. Las cifras de Introl (abr. 2026) en USD (~275 000 USD/año para EE. UU.) reflejan el mercado norteamericano, sensiblemente más alto.

Mantenimiento y soporte

Partida	Coste anual (% del capex hardware)	Por nodo 4-GPU (punto medio)
Mantenimiento / soporte vendor	5–10 % del capex	~7 000–14 000 USD → ~6 500–13 000 €
Tasa de fallos GPU (~5 % anual) × coste reposición	5 % × 4 GPUs × ~35 000 USD = ~7 000 USD esperados	~6 500 € (amortizado como provisión)
Recambios menores (cables, módulos)	~500–1 000 €	—

Introl cita tasas de fallo de GPU del 2–3 % anual en clusters pequeños; Google Research documentó ~9 % anualizado en el cluster H100 de 16 384 GPUs de Meta (Introl, abr. 2026). Se usa 5 % como valor conservador intermedio.

Depreciación (a efectos contables)

La depreciación lineal convierte el capex en un flujo anual equiparable al coste del cloud committed:

$$\text{depreciación anual} = \frac{\text{capex nodo}}{\text{años amortización}}$$

Capex nodo (USD)	Amortización 3 años (USD/año)	Amortización 5 años (USD/año)
150 000 (mínimo)	50 000	30 000
178 500 (medio)	59 500	35 700
207 000 (máximo)	69 000	41 400

El hardware H100 deprecia rápidamente: los análisis de mercado secundario sitúan el valor residual en el 20–40 % del precio de compra a los 3 años (Introl, abr. 2026). La llegada de Blackwell GB200/GB300 acelera la obsolescencia percibida.

Resumen opex anual por nodo 4×H100 SXM5 (escenario base, cluster de 8 nodos)

Partida	Escenario base (€/año)	Rango
Energía (PUE 1,54; 0,116 €/kWh)	5 475	1 604–9 437
Personal (0,5 FTE × 8 nodos, prorrateado)	7 500	3 750–36 000
Mantenimiento / soporte / fallos	9 000	5 000–15 000
Colocación rack (España, alta densidad)	6 000	3 000–15 000
Opex total por nodo	~28 000	~13 000–75 000

El rango extremo refleja la diferencia entre un datacenter propio bien amortizado con PPA solar y energía barata (opex mínimo) frente a colocación tier-1 con tarifas de mercado y personal sénior.

Derivación del €/GPU-hora all-in

Fórmula

$$\text{EUR/GPU-hora all-in} = \frac{\frac{\text{capex nodo}}{\text{años}} + \text{opex anual nodo}}{4,\text{GPUs} \times 8,760,\text{h} \times u}$$

donde (u) es la utilización media anual (0 a 1).

Véase la identidad de coste por token en coste por token y por request para la conexión con el throughput.

Tabla de €/GPU-hora según utilización y escenario

Capex medio (178 500 USD → ~166 000 €), amortización 3 años → 55 300 €/año.

Utilización	Opex/año (base, €)	Coste total/año (€)	GPU-horas útiles/año	€/GPU-hora
30 %	28 000	83 300	10 512	7,93
50 %	28 000	83 300	17 520	4,75
70 %	28 000	83 300	24 528	3,39
80 %	28 000	83 300	28 032	2,97
100 %	28 000	83 300	35 040	2,38

Escenario opex bajo (PPA solar, CPD propio, cluster grande): opex/año ~13 000 €.

Utilización	Coste total/año (€)	€/GPU-hora
50 %	68 300	3,90
70 %	68 300	2,78
80 %	68 300	2,43
100 %	68 300	1,95

Escenario opex alto (tarifa mercado, colocation cara, cluster pequeño): opex/año ~75 000 €.

Utilización	Coste total/año (€)	€/GPU-hora
50 %	130 300	7,44
70 %	130 300	5,31
80 %	130 300	4,65
100 %	130 300	3,72

Del €/GPU-hora al €/1M tokens

La identidad de coste por token conecta el coste de hardware con el coste de inferencia:

$$\text{EUR/1M tokens} = \frac{\text{EUR/GPU-hora} \times 10^6}{\text{throughput (tok/s)} \times 3,600}$$

Para throughputs de referencia en H100 SXM5 con vLLM (ver capacity planning de inferencia on-premise):

Modelo	Throughput típico (tok/s por GPU)	Fuente
Llama-3 70B FP8, batch alto	~2 800	Benchmarks serie B
Llama-3 8B FP16, batch medio	~9 000	Benchmarks serie B
Mixtral 8×7B, batch alto	~4 500	Benchmarks serie B

Tabla €/1M tokens en escenario base (€/GPU-hora 3,39 al 70 % de utilización):

Modelo	Throughput (tok/s)	€/1M tokens
Llama-3 70B FP8	2 800	~0,336
Llama-3 8B FP16	9 000	~0,105
Mixtral 8×7B	4 500	~0,209

Al 50 % de utilización (€/GPU-hora 4,75):

Modelo	€/1M tokens
Llama-3 70B FP8	~0,471
Llama-3 8B FP16	~0,147

La ocupación (batching) multiplica el throughput efectivo y baja el €/1M tokens sin cambiar el hardware; se analiza en utilización GPU como palanca FinOps.

Break-even on-prem vs cloud

La fórmula del break-even

El break-even se da cuando el coste total anual on-prem iguala el coste anual del cloud a igual utilización:

$$\text{coste cloud anual} = \text{precio GPU-hora cloud} \times 4,\text{GPUs} \times 8,760,\text{h} \times u$$

$$\text{break-even}: \quad \frac{\text{capex/año} + \text{opex/año}}{4 \times 8,760 \times u} = \text{precio GPU-hora cloud}$$

Despejando la utilización de break-even:

$$u^* = \frac{\text{capex/año} + \text{opex/año}}{4 \times 8,760 \times \text{precio GPU-hora cloud}}$$

Tabla de break-even por modalidad cloud y escenario on-prem

Escenario base on-prem (capex/año 55 300 €, opex/año 28 000 €, total 83 300 €/año por nodo 4-GPU):

Referencia cloud (precio/GPU-hora)	USD equiv.	Utilización break-even (u^*)	Nota
Neocloud on-demand (Lambda/Spheron ~2,90 USD)	2,90 USD (~2,70 €)	>100 % — el on-prem no compite	El cloud on-demand de neocloud es más barato incluso a utilización plena
Neocloud reserved 3 años (CoreWeave ~1,49–2,10 USD)	~1,80 USD (~1,67 €)	>100 % — imposible	El reserved neocloud supera al on-prem en cualquier escenario de este modelo
AWS p5 on-demand (6,88 USD/GPU-hora)	6,88 USD (~6,40 €)	~47 %	A más del 47 %, el on-prem medio bate a AWS on-demand
AWS p5 reserved 3 años (~2,97 USD/GPU-hora)	2,97 USD (~2,76 €)	>100 %	—
GCP A3 on-demand (~10,98 USD/GPU-hora)	10,98 USD (~10,21 €)	~29 %	A más del 29 %, el on-prem bate a GCP on-demand
Azure ND H100 v5 on-demand (~12,29 USD/GPU-hora)	12,29 USD (~11,43 €)	~26 %	—

Escenario opex bajo (total 68 300 €/año):

Referencia cloud	Utilización break-even
AWS p5 on-demand (6,88 USD ≈ 6,40 €)	~38 %
Neocloud on-demand (2,90 USD ≈ 2,70 €)	~91 %
Neocloud reserved 3a (1,80 USD ≈ 1,67 €)	>100 %

Escenario opex alto (total 130 300 €/año):

Referencia cloud	Utilización break-even
AWS p5 on-demand (6,88 USD ≈ 6,40 €)	~72 %
GCP A3 on-demand (~10,21 €)	~45 %
Azure on-demand (~11,43 €)	~41 %

Lectura de la tabla de break-even

Frente a neoclouds (on-demand o reserved), el TCO on-prem no cierra el break-even en ningún escenario del modelo base. El neocloud reserved bate al on-prem incluso a utilización del 100 %, porque su precio/hora es inferior al coste all-in del hardware propio. Esto es coherente con el análisis de cloud GPU: on-demand, reserved y spot.
Frente a hyperscalers on-demand (AWS, GCP, Azure), el on-prem sí tiene break-even alcanzable: en torno al 26–72 % de utilización según el escenario. A utilización media-alta (>70 %), el on-prem bate claramente a AWS/GCP/Azure on-demand.
La variable que más mueve el break-even es el opex (especialmente el personal), no el capex del hardware. Un cluster bien dimensionado en colocación barata con energía PPA puede bajar el umbral 20 puntos porcentuales respecto al escenario alto.
Para datos RGPD, el break-even frente a hyperscalers estadounidenses está sesgado: el eje de soberanía descarta los hyperscalers US antes que el coste (ver on-premise soberano vs hyperscalers).

Análisis de sensibilidad

TCO vs utilización

El coste all-in por GPU-hora varía inversamente con la utilización porque el capex es fijo:

$$\frac{d(\text{EUR/GPU-hora})}{du} = -\frac{\text{capex/año} + \text{opex/año}}{4 \times 8,760 \times u^2} < 0$$

Pasar del 50 % al 80 % de utilización reduce el €/GPU-hora en (\frac{4{,}75 - 2{,}97}{4{,}75} \approx 37,%) en el escenario base. Esta reducción del 37 % no requiere ningún cambio de hardware; solo scheduling más eficiente (ver utilización GPU como palanca FinOps).

Utilización	€/GPU-hora (escenario base)	Variación vs 50 %
30 %	7,93	+67 %
50 %	4,75	referencia
70 %	3,39	−29 %
80 %	2,97	−37 %
100 %	2,38	−50 %

TCO vs precio de energía

Precio energía (€/kWh)	Opex energía/año	€/GPU-hora (70 % util.)	Variación vs base
0,034 (PPA solar)	1 604 €	3,00	−12 %
0,116 (industrial ES, base)	5 475 €	3,39	referencia
0,160 (Europa media)	7 550 €	3,54	+4 %
0,200 (tarifa alta)	9 437 €	3,67	+8 %

La energía tiene un impacto moderado en el TCO total (8–12 % de variación frente a extremos), porque el capex del hardware domina. Sin embargo, a muy larga amortización (5 años) y PPA solar, la energía baja del 6 % al 1 % del TCO total y el diferencial se amplifica. El precio de la energía importa más para la huella de carbono (CSRD) que para el TCO cuando el capex es dominante.

TCO vs PUE

PUE	Overhead refrigeración	Energía/año (0,116 €/kWh)	€/GPU-hora (70 % util.)
1,15 (refrigeración líquida, nuevas instalaciones)	+15 %	2 166 €	3,21
1,20 (líquido, datacenter moderno)	+20 %	2 259 €	3,23
1,48 (instalaciones <5 años, Uptime 2025)	+48 %	3 490 €	3,33
1,54 (media global Uptime 2025)	+54 %	3 627 €	3,39
1,80 (colocación legacy)	+80 %	4 260 €	3,47

La diferencia entre PUE 1,15 (líquido) y 1,80 (legacy) es de apenas ~8 % en el €/GPU-hora al 70 % de utilización, porque la energía solo representa una fracción del TCO. El PUE importa mucho más para el coste de energía absoluto y el reporte CSRD que para el TCO total cuando el hardware es el componente dominante.

TCO vs años de amortización

Amortización	Capex/año (nodo medio, USD)	€/GPU-hora (70 % util., escenario base opex)
3 años	59 500 USD (~55 300 €)	3,39
4 años	44 625 USD (~41 500 €)	2,99
5 años	35 700 USD (~33 200 €)	2,72

Alargar la amortización de 3 a 5 años baja el €/GPU-hora en ~20 %, asumiendo que el hardware sigue siendo competitivo y el mercado de reventa soporta el valor residual. Con el ciclo de refreshing acelerado por Blackwell GB200/GB300, una amortización a 5 años conlleva mayor riesgo de obsolescencia tecnológica.

Mapa de calor de sensibilidad (€/GPU-hora al 70 % de utilización, escenario base)

	PUE 1,15	PUE 1,54	PUE 1,80
Amort. 3 años, PPA solar (0,034 €)	2,72	2,74	2,76
Amort. 3 años, industrial (0,116 €)	3,21	3,39	3,47
Amort. 5 años, industrial (0,116 €)	2,54	2,72	2,80
Amort. 3 años, tarifa alta (0,200 €)	3,44	3,67	3,78

Tabla de decisión: Pareto coste/control/soberanía

La tabla siguiente cruza las cuatro dimensiones sin jerarquía implícita; la lectura ordinal depende de las restricciones de cada organización.

Opción	€/GPU-hora	Capex inicial	Control total stack	Soberanía UE	Elasticidad	Riesgo operativo
On-prem (util. >70 %, opex bajo)	2,40–3,00	alto (150–207 k USD/nodo)	total	total	ninguna	fallo hardware, idle
On-prem (util. <50 %, opex base)	4,75–7,93	alto	total	total	ninguna	capex sin retorno
Neocloud reserved 3 años (CoreWeave, Lambda)	1,49–2,10 USD	ninguno	parcial (API)	depende del proveedor	contrato rígido	interrupción mínima
Neocloud on-demand (Lambda, Spheron)	2,49–3,44 USD	ninguno	parcial	depende	total	sin interrupción
AWS p5 on-demand	6,88 USD	ninguno	mínimo	NO (CLOUD Act)	total	sin interrupción
AWS p5 reserved 3 años	~2,97 USD	compromiso financiero	mínimo	NO (CLOUD Act)	rígida	sin interrupción
Cloud EU soberano (Scaleway, Nebius EU)	2,15–3,85 USD	ninguno	parcial	sí (UE)	total	sin interrupción
Híbrido on-prem base + cloud EU pico	2,00–3,50 (ponderado)	medio	alto	sí (UE)	pico elástico	complejidad operativa

Columna “Soberanía UE”: los hyperscalers estadounidenses (AWS, GCP, Azure) están sujetos a la US CLOUD Act independientemente de la región del datacenter. Nebius tiene entidad legal neerlandesa; CoreWeave es empresa estadounidense. Ver análisis completo en on-premise soberano vs hyperscalers.

Columna “Control total stack”: on-prem permite elegir versión de driver, kernel, configuración NCCL, particionado MIG, y cualquier parámetro del sistema. Las opciones cloud ofrecen control a nivel de contenedor/pod, con el hipervisor y el firmware opaco.

La frontera de Pareto coste/soberanía para datos RGPD excluye los hyperscalers US, dejando: on-prem, cloud EU soberano, y el híbrido. Entre estos tres, la variable que decide es la utilización sostenida y la predecibilidad del tráfico (ver capacity planning de inferencia LLM on-premise).

Integración con el modelo FinOps de la serie

El €/GPU-hora all-in del on-prem es el número que alimenta el pipeline de cost allocation de la serie:

Identidad de coste por token (coste por token y por request): throughput del motor × €/GPU-hora → €/1M tokens.
Chargeback y showback (chargeback y showback multitenancy GPU): el €/GPU-hora all-in es el precio interno que se imputa a cada tenant del cluster multi-tenant.
Utilización como palanca (utilización GPU como FinOps): subir la utilización del 50 % al 80 % reduce el €/GPU-hora en un 37 % sin cambiar el hardware — el ROI más alto del FinOps on-prem.
Capacity planning (capacity planning de inferencia LLM on-premise): el número de nodos a comprar depende del percentil de carga base que se quiere cubrir en hierro.
Comparativa cloud (cloud GPU: on-demand, reserved y spot): el €/GPU-hora all-in se enfrenta directamente al precio cloud de la tabla A7 para calcular el break-even.

Fuentes

Spheron · LLM Inference On-Premise vs GPU Cloud: 2026 Cost and Break-Even Analysis (abr. 2026) — https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/
Introl · GPU Infrastructure TCO Model: 5-Year Cost Analysis for Enterprise AI (abr. 2026) — https://introl.com/blog/gpu-infrastructure-tco-5-year-cost-model
GMI Cloud · NVIDIA H100 GPU Pricing: 2026 Rent vs. Buy Cost Analysis (abr. 2026) — https://www.gmicloud.ai/en/blog/nvidia-h100-gpu-pricing-2026-rent-vs-buy-cost-analysis
Uptime Institute · Global Data Center Survey 2025 (PDF oficial) — https://datacenter.uptimeinstitute.com/rs/711-RIA-145/images/2025.Annual.Survey.Report.pdf
Uptime Institute · Global Data Center PUE Stalls at 1.54 (comunicado, oct. 2025) — https://mgrid.org/2025/10/01/uptime-institute-data-center-pue-stagnation-2025-liquid-cooling/
GlobalPetrolPrices · Spain Business Electricity Price (sept. 2025) — https://www.globalpetrolprices.com/Spain/electricity_prices/
PV Tech · European Solar PPA Prices Fall Below 35 €/MWh in Q3 2025 (oct. 2025) — https://www.pv-tech.org/european-solar-ppa-prices-fall-below-35-mwh-q3-2025/
Xi Computers · Supermicro SYS-821GE-TNHR 8U GPU Server Pricing (jun. 2026) — https://www.xicomputer.com/Solutions/Data-Center-Servers/SYS-821GE-TNHR.asp
Encoradvisors · Data Center Colocation Pricing 2026 — https://encoradvisors.com/data-center-colocation-pricing/
CloudZero · H100 GPU Cost In 2026: Buy, Rent, and Cloud Pricing Compared — https://www.cloudzero.com/blog/h100-gpu-cost/
Spheron · AI Inference Power Consumption and GPU Electricity Costs: 2026 Guide — https://www.spheron.network/blog/ai-inference-power-electricity-cost-2026/
NVIDIA · DGX SuperPOD H100 Electrical Specifications (documentación oficial) — https://docs.nvidia.com/dgx-superpod/design-guides/dgx-superpod-data-center-design-h100/latest/electrical.html

On-premise soberano vs hyperscalers: el caso con datos (coste, energía, rendimiento y soberanía)

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

Notación: importes en euros (N €), decimales con coma; cuando una fuente cita dólares se indica “USD”. Datos centrados en Europa/España. No se usa el símbolo de dólar (delimitador de fórmula).

Qué cubre este artículo

Artículo de síntesis de la serie (S2), y el corazón de la propuesta: el caso con datos del on-premise soberano frente a los hyperscalers y el cloud europeo. Hasta aquí, cada track midió su eje —coste por token (FinOps), goodput (benchmarking), energía y carbono—; aquí se cruzan los cuatro, con una cuarta dimensión que ninguna comparativa técnica estadounidense pone delante: la soberanía del dato. El objetivo es responder, con números y no con ideología, la pregunta que sostiene cualquier inversión en plataforma de IA: ¿servir en hierro propio, en cloud europeo o en un hyperscaler? Y hacerlo con honestidad: el on-prem no siempre gana, y decir cuándo gana y cuándo no es lo que hace creíble la recomendación.

El marco: cuatro ejes, no un número

El error de casi todas las comparativas es reducir la decisión al coste por hora de una GPU. La decisión real cruza cuatro ejes, y solo viéndolos juntos se decide bien:

Eje	Pregunta	Quién lo mide en la serie
Coste (TCO)	¿cuánto cuesta servir, todo incluido?	FinOps (A2–A8)
Rendimiento	¿cumple el SLO, a qué goodput?	Benchmarking (B2–B8)
Energía y carbono	¿cuántos vatios y gramos por token?	Energía (C2–C8)
Soberanía	¿bajo qué jurisdicción vive el dato?	RGPD / EU AI Act / CSRD

Los tres primeros son cuantificables y se cruzan en el coste por token; el cuarto es una restricción que puede descartar una opción por barata que sea. La síntesis consiste en puntuar cada opción en los cuatro y decidir sobre la frontera de Pareto, no sobre el eje que más convenga.

El eje de coste: TCO y break-even

El coste real on-premise es capex amortizado + opex, y su coste por hora efectiva depende de la utilización:

$$\text{coste/GPU-hora efectiva (on-prem)} = \frac{\text{capex amortizado anual} + \text{opex anual}}{8760 \times \text{utilización}}$$

Esta fórmula es la clave de todo el debate: el coste por hora útil del on-prem sube al bajar la utilización, porque el capex se paga igual esté la GPU trabajando o parada. Los datos de 2026:

Dato	Valor	Fuente
Coste on-prem 8×H100 (floor, alta util.)	~2,83 USD/GPU-hora all-in	Spheron
Coste on-prem anual (floor)	~237.000 USD/año	Spheron
AWS H100 (p5.48xlarge)	4,10–6,88 USD/GPU-hora	Spheron
AWS 8-GPU on-demand anual (100 % util)	287.000–482.000 USD/año	Spheron
Cloud europeo soberano (Lyceum/Scaleway)	desde 2–2,73 €/GPU-hora, zero-egress	Lyceum, Scaleway

El break-even frente a AWS on-demand cae en torno al 50–83 % de utilización según región y tarifa; por debajo del ~70 % de utilización, el cloud gana en TCO, y por encima, el on-prem (Spheron). Para cargas de muy alta utilización, el on-prem amortiza en menos de 4 meses (Lenovo).

TCO a 3 años: el cálculo completo de un nodo 8×H100

Los números abstractos no convencen a un comité; un modelo a 3 años con las partidas declaradas, sí. Tomemos un nodo 8×H100 soberano en España y comparémoslo, a igualdad de trabajo, con AWS y con un cloud europeo. Supuestos declarados: amortización a 3 años, energía a PPA solar 32,5 €/MWh (con red de respaldo), PUE 1,3, y dos escenarios de utilización (50 % y 80 %).

On-premise (nodo propio), partidas anuales:

Partida	Valor anual	Nota
Capex amortizado (nodo ~270.000 € / 3 años)	~90.000 €	servidor 8×H100 + red + almacenamiento
Energía (≈10,4 kW × PUE 1,3 × 8760 h)	~3.850 € (a 32,5 €/MWh)	con PPA solar; a tarifa de red, ~12–18 k €
Operación, refrigeración, mantenimiento	~25.000 €	personal prorrateado, soporte, recambios
Espacio en datacenter (rack, conectividad)	~12.000 €	colocation o CPD propio
Total anual	~131.000 €	independiente de la utilización

A 131.000 €/año fijos, el coste por token depende solo de cuántos tokens generes, es decir, de la utilización:

Utilización	GPU-horas útiles/año	Coste/1M tokens
50 %	~35.000	~2,9 €
65 %	~45.500	~2,2 €
80 %	~56.000	~1,8 € (con red barata, ~1,1 €)

Cloud europeo soberano (Scaleway/Lyceum), pago por uso: a ~2,2 €/GPU-hora con zero-egress, el coste por token es constante con la utilización (solo pagas lo que usas): ~1,5–2,2 €/1M tokens según modelo y batching, sin capex ni riesgo de idle.

Hyperscaler (AWS p5), on-demand: a 4,10–6,88 USD/GPU-hora (≈3,8–6,4 €), el coste por token sale ~2–3,5 €/1M tokens —y a eso hay que sumar el egress—, sin contar que para datos RGPD el eje de soberanía ya lo descarta.

La lectura del modelo es la tesis de todo S2: al 50 % de utilización, el on-prem (~2,9 €) no le gana al cloud europeo (~1,8 €); al 80 % con energía barata (~1,1 €), lo bate con holgura. El cruce está, como dice la literatura, en torno al 65–70 %. La inversión en on-prem es, en el fondo, una apuesta a que sostendrás una utilización alta —y esa apuesta se gana con scheduling, no con hardware—.

La realidad incómoda: la utilización que casi nadie alcanza

Aquí está el dato honesto que falta en los discursos de “on-prem siempre es más barato”: la mayoría de los equipos de inferencia en producción operan al 40–65 % de utilización de GPU, por la variabilidad del tráfico y los límites del batching; la suposición de 80–90 % que hace atractivo el on-prem rara vez se alcanza fuera de pipelines solo-batch (Spheron).

Esto cambia la conclusión ingenua: si tu utilización real es del 50 %, el on-prem no es más barato que el cloud —el capex que pagas por la GPU parada te lo come—. Por eso la utilización no es un detalle, es la variable que decide el eje de coste, y conecta directamente con el track de FinOps (el idle de A2, el chargeback de A5) y con el scheduling: subir la utilización es lo que hace rentable el on-prem. Un cluster propio mal aprovechado es más caro que el cloud; uno bien schedulado, mucho más barato. La pregunta de coste no es “¿on-prem o cloud?”, es “¿puedo sostener una utilización alta?”.

Los costes ocultos del cloud: el egress

El cloud tiene su propia letra pequeña: los costes de egress (sacar datos del proveedor). En los hyperscalers, mover datos fuera o entre regiones se factura, y en cargas de IA con mucho movimiento de datos (datasets, checkpoints, embeddings) puede ser una partida significativa que no aparece en el precio de la GPU-hora. La ventaja del cloud europeo soberano: la mayoría (Lyceum, entre otros) han adoptado el modelo de zero-egress —no cobran por mover datos fuera ni entre regiones (Lyceum)—. Al comparar, el coste real del hyperscaler es GPU-hora + egress + otros cargos, no solo la GPU-hora; ignorarlo infla artificialmente la competitividad del hyperscaler.

Un ejemplo del orden de magnitud: una plataforma que mueva 50 TB/mes de salida (datasets, checkpoints, respuestas servidas a sistemas fuera del proveedor) a una tarifa de egress típica de ~0,08–0,09 €/GB paga ~4.000–4.500 €/mes, es decir ~50.000 €/año solo en egress —una partida del tamaño de un tercio del coste de un nodo propio, invisible en el precio de la GPU-hora—. En el cloud europeo con zero-egress esa partida es cero; en el on-prem, el tráfico interno tampoco se factura. Por eso una comparación justa debe modelar el egress según el patrón real de datos: para cargas con mucho movimiento de salida, puede invertir el ranking entre hyperscaler y cloud europeo. La factura del cloud no es la GPU-hora; es la GPU-hora más todo lo que mueves.

A esto se suma el riesgo de contrato y de lock-in: las tarifas de GPU on-demand del hyperscaler pueden cambiar, los descuentos por compromiso (reserved/savings plans) atan a 1–3 años, y migrar fuera —por el egress y por el acoplamiento a servicios propietarios— tiene un coste de salida real. El on-prem y el cloud europeo con APIs estándar (Kubernetes, S3 compatible) reducen ese acoplamiento: el mismo manifiesto y el mismo vLLM corren en tu cluster o en Scaleway sin reescribir. La soberanía operativa —poder mover la carga sin reconstruirla— es un valor que no aparece en la tarifa pero pesa en una decisión a tres años.

El eje de rendimiento: el proveedor no decide, el goodput sí

Un punto que simplifica la síntesis: el rendimiento no depende del proveedor, depende del hardware y la configuración. Una H100 da el mismo goodput en tu cluster, en Scaleway o en AWS, servida con el mismo vLLM y la misma config. Lo que decide el rendimiento es el goodput bajo tu SLO (track B), no quién aloja la GPU. Por tanto, en una comparación a igualdad de hardware, el eje de rendimiento se neutraliza: lo que cambia entre opciones es el coste, la energía y la soberanía. La excepción: si un proveedor te da acceso a hardware más nuevo (B200, GB200) antes que tu ciclo de compra on-prem, ahí el cloud puede ganar en rendimiento por GPU —un argumento real a favor del cloud para estar en la frontera del hardware sin capex—.

El eje de energía: la ventaja europea y española

Aquí el on-prem (o el cloud) en España/Francia tiene una ventaja estructural sobre un hyperscaler en una región sucia. Recordando los datos del track de energía:

Ubicación	Carbono red (gCO₂/kWh)	Precio (orientativo)
Francia (nuclear)	~20–60	bajo y estable
España (renovable + gas)	~150–170	bajo, volátil; PPA solar ~32,5 €/MWh
Alemania	~363	alto
Hyperscaler (región según proveedor)	depende; a menudo no elegible	tarifa del proveedor

Una misma carga en Francia emite ~9× menos carbono por token que en Alemania, y en España, con PPA solar a 32,5 €/MWh (mínimo histórico), el coste eléctrico —el 30–50 % del TCO— es bajo y, con contrato, predecible. Un cluster soberano en España o Francia controla dónde se consume la energía y con qué carbono; un hyperscaler te da la región que te da, a menudo sin elección de intensidad de red. Para el reporte CSRD, esa elegibilidad es una ventaja cuantificable del on-prem/cloud europeo.

En números concretos: el nodo 8×H100 del ejemplo (~10,4 kW × PUE 1,3 ≈ 118.000 kWh/año) emite, según la red, ~2,4 t CO₂/año en Francia (~20 gCO₂/kWh) frente a ~43 t CO₂/año en Alemania (~363 gCO₂/kWh) —la misma máquina, el mismo trabajo, ~18× de diferencia en huella reportable por elegir la ubicación—. Esa decisión, que un hyperscaler en una región impuesta no te deja tomar, es exactamente lo que el on-prem y el cloud europeo soberano ponen en tus manos. El eje de energía no es un detalle ambiental: es coste (precio del kWh), cumplimiento (CSRD) y soberanía (control de la ubicación) a la vez.

El eje de soberanía: el que no depende de la utilización

Y aquí está el eje que invalida la opción más barata si el dato es sensible. Los hyperscalers estadounidenses están sujetos a la US CLOUD Act: las autoridades de EE. UU. pueden requerir datos alojados por una empresa estadounidense aunque estén en un datacenter europeo. Para datos sujetos a RGPD, eso es un riesgo de cumplimiento. Los cloud soberanos europeos operan bajo jurisdicción UE/EFTA, dando residencia del dato y cumplimiento RGPD, y están exentos de la US CLOUD Act (Lyceum · sovereign providers). El on-prem propio es el grado máximo de soberanía: el dato no sale de tu cluster.

La diferencia clave con los otros ejes: la soberanía no depende de la utilización ni del volumen. Por mucho que un hyperscaler abarate la GPU-hora, para datos RGPD no es una opción —el riesgo de jurisdicción no se compensa con precio—. Enlaza con los controles ENS × ISO 42001 × EU AI Act y el mapeo del EU AI Act: el cumplimiento es una restricción dura, no un eje a optimizar.

Los cuatro instrumentos que convierten la soberanía en una restricción concreta, no en un eslogan:

Instrumento	Qué obliga	Implicación para la arquitectura
US CLOUD Act	da a EE. UU. acceso a datos de empresas estadounidenses, estén donde estén	un hyperscaler US no garantiza residencia jurisdiccional aunque el datacenter esté en la UE
RGPD	residencia y tratamiento del dato personal bajo derecho UE	exige proveedor UE/EFTA o hierro propio para datos personales
EU AI Act	trazabilidad, gestión de riesgo y registros para sistemas de IA	favorece el control total del stack (logs, datasets, modelos) que da el on-prem
CSRD	reporte verificable de huella ambiental	la energía elegible (red limpia, PPA) del on-prem/cloud europeo es auditable

La conclusión operativa: para una entidad europea que trate datos personales o despliegue IA de riesgo, tres de los cuatro ejes técnicos pueden favorecer al hyperscaler y aun así perder, porque el cuarto eje —soberanía— actúa como filtro previo. Por eso S2 ordena la decisión así: primero el filtro de soberanía (descarta el hyperscaler para datos RGPD), después la optimización de coste, rendimiento y energía entre las opciones que pasan el filtro (on-prem soberano y cloud europeo).

El cuadro de mando: las tres opciones puntuadas

Cruzando los cuatro ejes para las tres opciones realistas de una plataforma europea (cifras de orden de magnitud, ilustrativas):

Opción	Coste/1M tok	Break-even	Energía/carbono	Soberanía
On-prem soberano (ES/FR)	~1,1 € (alta util.) / ~3 € (baja)	>65–70 % util.	controlable (red limpia, PPA)	total (UE)
Cloud europeo soberano	~1,5–2,2 €	sin capex, paga uso	UE, zero-egress	alta (UE)
Hyperscaler (US)	~2–3,5 € + egress	sin capex	región impuesta	no UE (CLOUD Act)

La lectura del cuadro: para datos sujetos a RGPD, el hyperscaler estadounidense queda descartado por el eje de soberanía, por competitiva que sea su tarifa. La decisión real se reduce a on-prem soberano vs cloud europeo soberano, y ahí la decide la utilización y el volumen.

Cuándo gana cada opción

La recomendación honesta, por escenario:

Escenario	Opción que gana	Por qué
Volumen alto y sostenido (util. >65–70 %), datos RGPD	On-prem soberano	el coste/token más bajo + soberanía total
Volumen variable o en crecimiento, datos RGPD	Cloud europeo soberano	soberanía sin riesgo de capex/idle
Volumen bajo o pico esporádico	Cloud europeo (uso)	no amortizas el capex
Sin requisito de soberanía, frontera de hardware	Hyperscaler	acceso a hardware nuevo sin capex
Híbrido (base + pico)	On-prem + cloud europeo (burst)	base barata propia, pico elástico soberano

El on-prem tiene sentido cuando hay utilización muy alta y predecible (80 %+), requisitos estrictos de soberanía, o un contrato hyperscaler que sale caro (Spheron). Para plataformas soberanas con carga base sostenida, el patrón ganador suele ser el híbrido: on-prem soberano para la base de alta utilización (donde el coste/token es imbatible) y cloud europeo soberano para el pico y el crecimiento (elástico, sin capex, manteniendo la jurisdicción UE). Lo mejor de los dos sin ceder soberanía.

Dimensionar el híbrido: cuánto en hierro, cuánto en cloud

El híbrido no es “un poco de cada”; se dimensiona con un dato: el percentil de carga base. La regla es poner en on-prem la carga que está casi siempre presente (la que mantiene la GPU al 75–85 %) y enviar al cloud europeo solo los picos que, de cubrirse con hierro, dejarían GPUs paradas la mayor parte del tiempo. Un ejemplo con un perfil de tráfico realista:

Franja de carga	% del tiempo	Dónde servir	Por qué
Base (p0–p70)	siempre	on-prem (1 nodo 8×H100 al ~80 %)	coste/token mínimo, util. alta garantizada
Media (p70–p95)	horas pico diarias	on-prem si cabe, si no cloud europeo	elasticidad sin capex ocioso
Pico (p95–p100)	esporádico	cloud europeo soberano (burst)	absurdo comprar hierro para un pico raro

Con este reparto, la base amortiza el nodo propio a utilización alta (~1,1–1,8 €/1M tokens) y el pico se paga por uso sin penalización de idle (~1,5–2,2 €/1M tokens), todo bajo jurisdicción UE. El error caro es el contrario: dimensionar el on-prem para el pico —entonces la GPU pasa la mayor parte del tiempo parada al 30–40 %, el coste/token se dispara a >3 € y el cloud habría sido más barato—. Se dimensiona el hierro para la base, no para el pico; el pico es justo lo que el cloud hace bien. Este principio conecta con el capacity planning y el scheduling (Kueue/Volcano) de la serie: el híbrido solo funciona si el scheduler llena el nodo propio antes de desbordar al cloud.

Supuestos y sensibilidad

Toda la comparación cuelga de unos supuestos que hay que declarar, porque moverlos mueve la conclusión:

Supuesto	Si sube	Efecto
Utilización	50 % → 80 %	el on-prem pasa de perder a ganar claramente
Precio de energía	región cara → Francia/PPA	baja el TCO on-prem y el carbono
Plazo de amortización	24 → 36 meses	baja el coste/hora on-prem
Volumen	< 2M tok/día → mucho más	cruza el break-even hacia on-prem
Egress (hyperscaler)	bajo → alto	encarece el hyperscaler frente al cloud europeo

La regla: ninguna comparación on-prem vs cloud es válida sin fijar estos supuestos. Una que diga “on-prem es 3× más barato” sin declarar la utilización asumida es propaganda; una que fije utilización, precio de energía, plazo y volumen es un dato. El dossier debe presentar el caso con los supuestos explícitos y un análisis de sensibilidad —es lo que lo hace defendible ante un comité que los cuestione.

Checklist de decisión

Para llevar S2 de la teoría a la decisión, las preguntas que ordenan la elección, en orden:

¿Los datos están sujetos a RGPD o el sistema es de riesgo bajo el EU AI Act? Si sí, el hyperscaler US queda descartado por soberanía; decides entre on-prem y cloud europeo. Si no, el hyperscaler entra en la comparación de coste.
¿Puedo sostener una utilización >65–70 % en la carga base? Si sí, el on-prem gana en coste para esa base. Si no, el cloud europeo evita pagar capex por GPUs paradas.
¿El perfil de tráfico tiene picos marcados? Si sí, híbrido: base en hierro, pico en cloud europeo. Dimensiona el hierro para la base, nunca para el pico.
¿Cuánto dato saco del proveedor al mes? Modela el egress; con mucho movimiento, el zero-egress del cloud europeo o el on-prem ganan claramente.
¿Qué red eléctrica y a qué precio? Francia/España con PPA bajan TCO y carbono; inclúyelo en el modelo y en el reporte CSRD.
¿He fijado utilización, energía, plazo y volumen por escrito? Sin esos cuatro supuestos declarados, el número no es defendible.

Quien responda estas seis preguntas con datos —no con intuición— tiene el caso construido. La recomendación de la serie para una plataforma soberana europea con carga base sostenida es estable: on-prem soberano para la base de alta utilización + cloud europeo soberano para el pico, con el hyperscaler reservado solo para cargas sin requisito de soberanía donde se necesite hardware en la frontera sin capex.

Límites y trampas (data-driven)

Utilización asumida irreal. El 80–90 % que hace ganar al on-prem rara vez se da en producción (40–65 % típico). Modela tu utilización real, no la ideal.
Comparar solo la GPU-hora. El TCO incluye energía, operación, refrigeración, egress (cloud) y capex (on-prem). Compara totales con los mismos supuestos.
Ignorar la soberanía. Para datos RGPD, el eje de soberanía descarta el hyperscaler antes que el coste; no es negociable con precio.
Olvidar el híbrido. No es “todo on-prem o todo cloud”; el patrón base+pico suele dominar.
Datos en USD. Las comparativas estadounidenses están en dólares y con regiones sucias; reconviértelas a euros y a la red de tu región (España/Francia) para tu caso.

La síntesis de S2, en una frase: para datos soberanos europeos, la decisión no es on-prem vs cloud en abstracto, sino on-prem soberano (alta utilización) + cloud europeo soberano (pico) frente a un hyperscaler que el eje de soberanía descarta —y la utilización es la variable que reparte la base entre las dos primeras. El resto de la serie da los números de cada eje; este los cruza en la recomendación. El siguiente artículo de síntesis (S3) dimensiona la inversión; este decide la arquitectura.

Ver también

Cloud GPU: comparativa de precios, compromiso y neoclouds soberanos — los precios on-demand, spot y reserved de los proveedores cloud europeos que aparecen como alternativa en este análisis, con datos actualizados de 2026.
TCO del cluster GPU on-premise: amortización, energía e infraestructura — el desglose completo del TCO on-premise: CAPEX de servidores, amortización, energía, red y personal, con la hoja de cálculo que da el €/GPU-hora real.

Fuentes

Spheron · LLM Inference On-Premise vs GPU Cloud: 2026 Cost and Break-Even — https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/
Lenovo Press · On-Premise vs Cloud: Generative AI TCO (2026) — https://lenovopress.lenovo.com/lp2368-on-premise-vs-cloud-generative-ai-total-cost-of-ownership-2026-edition
Lyceum · EU Sovereign Inference Platform Comparison (2026) — https://lyceum.technology/magazine/eu-sovereign-inference-platform-comparison/
Lyceum · Sovereign Cloud Providers 2026 — https://lyceum.technology/magazine/sovereign-cloud-providers-2026/
Scaleway · H100 GPU instance (precio €, soberanía UE) — https://www.scaleway.com/en/h100/
Nerd Level Tech · GPU Cloud TCO 2026: hidden fees, egress costs — https://nerdleveltech.com/gpu-cloud-comparison-2026-the-real-cost-of-ai-compute