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

Cloud-Europeo on lo0 — Blog Técnico