---
title: "On-premise soberano vs hyperscalers: el caso con datos (coste, energía, rendimiento y soberanía)"
url: https://blog.lo0.es/posts/on-premise-soberano-vs-hyperscalers-datos/
markdown: https://blog.lo0.es/posts/on-premise-soberano-vs-hyperscalers-datos/index.md
lang: es
date: 2026-06-14
lastmod: 2026-06-17
author: "José Manuel Román"
description: "Artículo de síntesis de la serie: el caso on-premise soberano frente a los hyperscalers y el cloud europeo, cruzando los cuatro ejes (coste/TCO y break-even, rendimiento, energía y carbono, y soberanía del dato) con datos europeos en euros. Con la honestidad de la utilización real y un cuadro de mando de decisión. Con fuentes."
tags: ["finops","tco","soberania","on-premise","hyperscalers","cloud-europeo","break-even","espana","serie-datos"]
translations:
  en: https://blog.lo0.es/en/posts/sovereign-on-premise-vs-hyperscalers-data/index.md
---

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


> 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](https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/) |
| Coste on-prem anual (floor) | ~237.000 USD/año | [Spheron](https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/) |
| AWS H100 (p5.48xlarge) | 4,10–6,88 USD/GPU-hora | [Spheron](https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/) |
| AWS 8-GPU on-demand anual (100 % util) | 287.000–482.000 USD/año | [Spheron](https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/) |
| Cloud europeo soberano (Lyceum/Scaleway) | desde **2–2,73 €/GPU-hora**, **zero-egress** | [Lyceum](https://lyceum.technology/magazine/eu-sovereign-inference-platform-comparison/), [Scaleway](https://www.scaleway.com/en/h100/) |

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](https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/)). Para cargas de muy
alta utilización, el on-prem amortiza en **menos de 4 meses** ([Lenovo](https://lenovopress.lenovo.com/lp2368-on-premise-vs-cloud-generative-ai-total-cost-of-ownership-2026-edition)).

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

> **Diagrama:** Break-even on-prem vs cloud segun utilizacion: el coste por hora util del on-prem baja con la utilizacion y cruza al del cloud en torno al 65-70 por ciento — [verlo en la versión HTML](https://blog.lo0.es/posts/on-premise-soberano-vs-hyperscalers-datos/)

---

## 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](https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/)).

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](https://lyceum.technology/magazine/eu-sovereign-inference-platform-comparison/))—. 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](https://lyceum.technology/magazine/sovereign-cloud-providers-2026/)).
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](https://blog.lo0.es/posts/controles-tecnicos-ens-42001-eu-ai-act/index.md)
y [el mapeo del EU AI Act](https://blog.lo0.es/posts/eu-ai-act-mapeo-arquitectura-llm-on-premise/index.md): 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)** |

> **Diagrama:** Cuadro de mando: on-prem soberano, cloud europeo soberano y hyperscaler puntuados en coste, energia y soberania; el hyperscaler pierde la soberania — [verlo en la versión HTML](https://blog.lo0.es/posts/on-premise-soberano-vs-hyperscalers-datos/)

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](https://www.spheron.network/blog/llm-inference-on-premise-vs-cloud/)).
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:

1. **¿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.
2. **¿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.
3. **¿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.
4. **¿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.
5. **¿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.
6. **¿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)

1. **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.
2. **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.
3. **Ignorar la soberanía.** Para datos RGPD, el eje de soberanía descarta el hyperscaler antes que el
   coste; no es negociable con precio.
4. **Olvidar el híbrido.** No es "todo on-prem o todo cloud"; el patrón base+pico suele dominar.
5. **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](https://blog.lo0.es/posts/cloud-gpu-commitment-spot-neoclouds/index.md) — 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](https://blog.lo0.es/posts/tco-on-premise-gpu-cluster/index.md) — 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