Spain on lo0 — Tech Blog

Sovereign on-premise vs hyperscalers: the case with data (cost, energy, performance and sovereignty)

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

Notation: amounts in euros (N €), decimals with a point; when a source quotes dollars it is marked “USD”. Data centred on Europe and Spain. The dollar symbol is not used (formula delimiter).

What this article covers

Synthesis article of the series (S2), and the heart of the proposal: the case with data for sovereign on-premise against the hyperscalers and the European cloud. Up to here, each track measured its own axis, cost per token (FinOps), goodput (benchmarking), energy and carbon; here the four are crossed, with a fourth dimension no US technical comparison puts up front: data sovereignty. The aim is to answer, with numbers and not with ideology, the question that underpins any investment in an AI platform: serve on your own iron, on a European cloud or on a hyperscaler? And to do it honestly: on-prem does not always win, and saying when it wins and when it does not is what makes the recommendation credible.

The framework: four axes, not one number

The mistake in almost every comparison is reducing the decision to the hourly cost of a GPU. The real decision crosses four axes, and only by seeing them together do you decide well:

Axis	Question	Who measures it in the series
Cost (TCO)	how much does it cost to serve, all in?	FinOps (A2–A8)
Performance	does it meet the SLO, at what goodput?	Benchmarking (B2–B8)
Energy and carbon	how many watts and grams per token?	Energy (C2–C8)
Sovereignty	under which jurisdiction does the data live?	GDPR / EU AI Act / CSRD

The first three are quantifiable and meet in the cost per token; the fourth is a constraint that can rule out an option however cheap it is. The synthesis consists of scoring each option on all four and deciding on the Pareto frontier, not on whichever axis happens to suit.

The cost axis: TCO and break-even

The real on-premise cost is amortised capex plus opex, and its cost per effective hour depends on utilisation:

$$\text{effective cost/GPU-hour (on-prem)} = \frac{\text{annual amortised capex} + \text{annual opex}}{8760 \times \text{utilisation}}$$

This formula is the key to the whole debate: the cost per useful hour of on-prem rises as utilisation falls, because capex is paid whether the GPU is working or idle. The 2026 data:

Data point	Value	Source
On-prem cost 8×H100 (floor, high util.)	~2.83 USD/GPU-hour all-in	Spheron
Annual on-prem cost (floor)	~237,000 USD/year	Spheron
AWS H100 (p5.48xlarge)	4.10–6.88 USD/GPU-hour	Spheron
AWS 8-GPU on-demand annual (100 % util)	287,000–482,000 USD/year	Spheron
Sovereign European cloud (Lyceum/Scaleway)	from 2–2.73 €/GPU-hour, zero-egress	Lyceum, Scaleway

The break-even against AWS on-demand falls around 50–83 % utilisation depending on region and tariff; below ~70 % utilisation, the cloud wins on TCO, and above it, on-prem (Spheron). For very high-utilisation workloads, on-prem pays for itself in less than 4 months (Lenovo).

Three-year TCO: the full calculation for an 8×H100 node

Abstract numbers do not convince a committee; a three-year model with declared line items does. Take a sovereign 8×H100 node in Spain and compare it, for the same work, with AWS and with a European cloud. Declared assumptions: amortisation over 3 years, energy at a solar PPA of 32.5 €/MWh (with grid backup), PUE 1.3, and two utilisation scenarios (50 % and 80 %).

On-premise (own node), annual line items:

Line item	Annual value	Note
Amortised capex (node ~270,000 € / 3 years)	~90,000 €	8×H100 server + network + storage
Energy (≈10.4 kW × PUE 1.3 × 8760 h)	~3,850 € (at 32.5 €/MWh)	with solar PPA; at grid tariff, ~12–18 k €
Operation, cooling, maintenance	~25,000 €	prorated staff, support, spares
Datacenter space (rack, connectivity)	~12,000 €	colocation or own datacenter
Annual total	~131,000 €	independent of utilisation

At a fixed 131,000 €/year, the cost per token depends only on how many tokens you generate, that is, on utilisation:

Utilisation	Useful GPU-hours/year	Cost/1M tokens
50 %	~35,000	~2.9 €
65 %	~45,500	~2.2 €
80 %	~56,000	~1.8 € (with cheap grid, ~1.1 €)

Sovereign European cloud (Scaleway/Lyceum), pay per use: at ~2.2 €/GPU-hour with zero-egress, the cost per token is constant with utilisation (you only pay for what you use): ~1.5–2.2 €/1M tokens depending on model and batching, with no capex and no idle risk.

Hyperscaler (AWS p5), on-demand: at 4.10–6.88 USD/GPU-hour (≈3.8–6.4 €), the cost per token works out at ~2–3.5 €/1M tokens, and on top of that you have to add the egress, quite apart from the fact that for GDPR data the sovereignty axis rules it out already.

The reading of the model is the thesis of the whole of S2: at 50 % utilisation, on-prem (~2.9 €) does not beat the European cloud (~1.8 €); at 80 % with cheap energy (~1.1 €), it beats it comfortably. The crossover sits, as the literature says, around 65–70 %. Investing in on-prem is, fundamentally, a bet that you will sustain high utilisation, and that bet is won with scheduling, not with hardware.

The uncomfortable reality: the utilisation almost nobody reaches

Here is the honest figure missing from the “on-prem is always cheaper” speeches: most inference teams in production operate at 40–65 % GPU utilisation, because of traffic variability and the limits of batching; the 80–90 % assumption that makes on-prem attractive is rarely reached outside batch-only pipelines (Spheron).

This changes the naive conclusion: if your real utilisation is 50 %, on-prem is not cheaper than the cloud, because the capex you pay for the idle GPU eats you. That is why utilisation is not a detail, it is the variable that decides the cost axis, and it connects directly with the FinOps track (the idle of A2, the chargeback of A5) and with scheduling: raising utilisation is what makes on-prem pay. A badly used cluster of your own is more expensive than the cloud; a well scheduled one is far cheaper. The cost question is not “on-prem or cloud?”, it is “can I sustain high utilisation?”.

The hidden costs of the cloud: egress

The cloud has its own small print: egress costs (taking data out of the provider). In the hyperscalers, moving data out or between regions is billed, and in AI workloads with a lot of data movement (datasets, checkpoints, embeddings) it can be a significant line item that does not appear in the GPU-hour price. The advantage of the sovereign European cloud: most of them (Lyceum among others) have adopted the zero-egress model, they do not charge for moving data out or between regions (Lyceum). When comparing, the real hyperscaler cost is GPU-hour + egress + other charges, not just the GPU-hour; ignoring it artificially inflates the hyperscaler’s competitiveness.

An example of the order of magnitude: a platform moving 50 TB/month outbound (datasets, checkpoints, responses served to systems outside the provider) at a typical egress tariff of ~0.08–0.09 €/GB pays ~4,000–4,500 €/month, that is ~50,000 €/year on egress alone, a line item the size of a third of the cost of a node of your own, invisible in the GPU-hour price. On the European cloud with zero-egress that line item is zero; on-prem, internal traffic is not billed either. That is why a fair comparison must model egress according to the real data pattern: for workloads with a lot of outbound movement, it can invert the ranking between hyperscaler and European cloud. The cloud bill is not the GPU-hour; it is the GPU-hour plus everything you move.

To this is added contract and lock-in risk: the hyperscaler’s on-demand GPU tariffs can change, commitment discounts (reserved/savings plans) tie you for 1–3 years, and migrating out, because of egress and coupling to proprietary services, has a real exit cost. On-prem and the European cloud with standard APIs (Kubernetes, S3 compatible) reduce that coupling: the same manifest and the same vLLM run on your cluster or on Scaleway without rewriting. Operational sovereignty, being able to move the workload without rebuilding it, is a value that does not appear in the tariff but weighs on a three-year decision.

The performance axis: the provider does not decide, goodput does

One point that simplifies the synthesis: performance does not depend on the provider, it depends on the hardware and the configuration. An H100 gives the same goodput on your cluster, on Scaleway or on AWS, served with the same vLLM and the same config. What decides performance is the goodput under your SLO (track B), not who hosts the GPU. So, in a comparison at equal hardware, the performance axis neutralises itself: what changes between options is cost, energy and sovereignty. The exception: if a provider gives you access to newer hardware (B200, GB200) ahead of your on-prem buying cycle, then the cloud can win on performance per GPU, a real argument in favour of the cloud for staying at the hardware frontier without capex.

The energy axis: the European and Spanish advantage

Here on-prem (or cloud) in Spain or France has a structural advantage over a hyperscaler in a dirty region. Recalling the data from the energy track:

Location	Grid carbon (gCO₂/kWh)	Price (indicative)
France (nuclear)	~20–60	low and stable
Spain (renewables + gas)	~150–170	low, volatile; solar PPA ~32.5 €/MWh
Germany	~363	high
Hyperscaler (region depends on provider)	depends; often not selectable	provider tariff

The same workload in France emits ~9× less carbon per token than in Germany, and in Spain, with a solar PPA at 32.5 €/MWh (an all-time low), the electricity cost, 30–50 % of the TCO, is low and, under contract, predictable. A sovereign cluster in Spain or France controls where the energy is consumed and with what carbon; a hyperscaler gives you the region it gives you, often with no choice of grid intensity. For CSRD reporting, that selectability is a quantifiable advantage of on-prem and the European cloud.

In concrete numbers: the example 8×H100 node (~10.4 kW × PUE 1.3 ≈ 118,000 kWh/year) emits, depending on the grid, ~2.4 t CO₂/year in France (~20 gCO₂/kWh) against ~43 t CO₂/year in Germany (~363 gCO₂/kWh), the same machine, the same work, ~18× the difference in reportable footprint just by choosing the location. That decision, which a hyperscaler in an imposed region does not let you take, is exactly what on-prem and the sovereign European cloud put in your hands. The energy axis is not an environmental detail: it is cost (the price of the kWh), compliance (CSRD) and sovereignty (control of location) all at once.

The sovereignty axis: the one that does not depend on utilisation

And here is the axis that invalidates the cheapest option if the data is sensitive. US hyperscalers are subject to the US CLOUD Act: US authorities can demand data held by a US company even if it sits in a European datacenter. For data subject to the GDPR, that is a compliance risk. Sovereign European clouds operate under EU/EFTA jurisdiction, providing data residency and GDPR compliance, and are exempt from the US CLOUD Act (Lyceum · sovereign providers). On-prem of your own is the maximum degree of sovereignty: the data does not leave your cluster.

The key difference from the other axes: sovereignty does not depend on utilisation or on volume. However much a hyperscaler cheapens the GPU-hour, for GDPR data it is not an option, the jurisdiction risk is not offset by price. It links with the ENS × ISO 42001 × EU AI Act controls and the EU AI Act mapping: compliance is a hard constraint, not an axis to optimise.

The four instruments that turn sovereignty into a concrete constraint rather than a slogan:

Instrument	What it requires	Implication for the architecture
US CLOUD Act	gives the US access to data held by US companies, wherever it is	a US hyperscaler does not guarantee jurisdictional residency even if the datacenter is in the EU
GDPR	residency and processing of personal data under EU law	requires an EU/EFTA provider or your own iron for personal data
EU AI Act	traceability, risk management and records for AI systems	favours the full control of the stack (logs, datasets, models) that on-prem gives
CSRD	verifiable reporting of environmental footprint	the selectable energy (clean grid, PPA) of on-prem and the European cloud is auditable

The operational conclusion: for a European entity processing personal data or deploying high-risk AI, three of the four technical axes can favour the hyperscaler and it can still lose, because the fourth axis, sovereignty, acts as a prior filter. That is why S2 orders the decision like this: first the sovereignty filter (which rules out the hyperscaler for GDPR data), then the optimisation of cost, performance and energy among the options that pass the filter (sovereign on-prem and European cloud).

The scorecard: the three options scored

Crossing the four axes for the three realistic options of a European platform (order-of-magnitude, illustrative figures):

Option	Cost/1M tok	Break-even	Energy/carbon	Sovereignty
Sovereign on-prem (ES/FR)	~1.1 € (high util.) / ~3 € (low)	>65–70 % util.	controllable (clean grid, PPA)	total (EU)
Sovereign European cloud	~1.5–2.2 €	no capex, pay per use	EU, zero-egress	high (EU)
Hyperscaler (US)	~2–3.5 € + egress	no capex	imposed region	not EU (CLOUD Act)

The reading of the scorecard: for data subject to the GDPR, the US hyperscaler is ruled out by the sovereignty axis, however competitive its tariff. The real decision comes down to sovereign on-prem vs sovereign European cloud, and there it is decided by utilisation and volume.

When each option wins

The honest recommendation, by scenario:

Scenario	Winning option	Why
High, sustained volume (util. >65–70 %), GDPR data	Sovereign on-prem	lowest cost/token + total sovereignty
Variable or growing volume, GDPR data	Sovereign European cloud	sovereignty without capex/idle risk
Low volume or sporadic peak	European cloud (per use)	you do not amortise the capex
No sovereignty requirement, hardware frontier	Hyperscaler	access to new hardware without capex
Hybrid (base + peak)	On-prem + European cloud (burst)	cheap base of your own, sovereign elastic peak

On-prem makes sense when there is very high, predictable utilisation (80 %+), strict sovereignty requirements, or a hyperscaler contract that works out expensive (Spheron). For sovereign platforms with a sustained base load, the winning pattern is usually the hybrid: sovereign on-prem for the high-utilisation base (where the cost per token is unbeatable) and sovereign European cloud for the peak and for growth (elastic, no capex, keeping EU jurisdiction). The best of both without giving up sovereignty.

Sizing the hybrid: how much on iron, how much on cloud

The hybrid is not “a bit of each”; it is sized with one figure: the base load percentile. The rule is to put on on-prem the load that is almost always present (the load that keeps the GPU at 75–85 %) and to send to the European cloud only the peaks that, if covered with iron, would leave GPUs idle most of the time. An example with a realistic traffic profile:

Load band	% of the time	Where to serve	Why
Base (p0–p70)	always	on-prem (1 node 8×H100 at ~80 %)	minimum cost/token, high util. guaranteed
Middle (p70–p95)	daily peak hours	on-prem if it fits, otherwise European cloud	elasticity without idle capex
Peak (p95–p100)	sporadic	sovereign European cloud (burst)	absurd to buy iron for a rare peak

With this split, the base amortises your own node at high utilisation (~1.1–1.8 €/1M tokens) and the peak is paid per use with no idle penalty (~1.5–2.2 €/1M tokens), all under EU jurisdiction. The expensive mistake is the opposite: sizing the on-prem for the peak, in which case the GPU spends most of its time idle at 30–40 %, the cost per token shoots up above 3 € and the cloud would have been cheaper. You size the iron for the base, not for the peak; the peak is exactly what the cloud does well. This principle connects with the capacity planning and the scheduling (Kueue/Volcano) of the series: the hybrid only works if the scheduler fills your own node before overflowing to the cloud.

Assumptions and sensitivity

The whole comparison hangs on assumptions that have to be declared, because moving them moves the conclusion:

Assumption	If it rises	Effect
Utilisation	50 % → 80 %	on-prem goes from losing to clearly winning
Energy price	expensive region → France/PPA	lowers on-prem TCO and carbon
Amortisation period	24 → 36 months	lowers the on-prem cost per hour
Volume	< 2M tok/day → much more	crosses the break-even towards on-prem
Egress (hyperscaler)	low → high	makes the hyperscaler dearer than the European cloud

The rule: no on-prem vs cloud comparison is valid without fixing these assumptions. One that says “on-prem is 3× cheaper” without declaring the assumed utilisation is propaganda; one that fixes utilisation, energy price, period and volume is a data point. The dossier must present the case with explicit assumptions and a sensitivity analysis, which is what makes it defensible before a committee that questions them.

Decision checklist

To take S2 from theory to decision, the questions that order the choice, in order:

Is the data subject to the GDPR, or is the system high-risk under the EU AI Act? If so, the US hyperscaler is ruled out on sovereignty; you choose between on-prem and European cloud. If not, the hyperscaler enters the cost comparison.
Can I sustain utilisation above 65–70 % on the base load? If so, on-prem wins on cost for that base. If not, the European cloud avoids paying capex for idle GPUs.
Does the traffic profile have marked peaks? If so, hybrid: base on iron, peak on European cloud. Size the iron for the base, never for the peak.
How much data do I take out of the provider each month? Model the egress; with a lot of movement, the zero-egress of the European cloud, or on-prem, win clearly.
Which electricity grid and at what price? France or Spain with a PPA lower TCO and carbon; include it in the model and in the CSRD report.
Have I fixed utilisation, energy, period and volume in writing? Without those four declared assumptions, the number is not defensible.

Whoever answers these six questions with data, not with intuition, has the case built. The series' recommendation for a sovereign European platform with a sustained base load is stable: sovereign on-prem for the high-utilisation base plus sovereign European cloud for the peak, with the hyperscaler reserved only for workloads with no sovereignty requirement where frontier hardware is needed without capex.

Limits and traps (data-driven)

Unrealistic assumed utilisation. The 80–90 % that makes on-prem win rarely happens in production (40–65 % typical). Model your real utilisation, not the ideal one.
Comparing only the GPU-hour. TCO includes energy, operation, cooling, egress (cloud) and capex (on-prem). Compare totals with the same assumptions.
Ignoring sovereignty. For GDPR data, the sovereignty axis rules out the hyperscaler before cost does; it is not negotiable with price.
Forgetting the hybrid. It is not “all on-prem or all cloud”; the base-plus-peak pattern usually dominates.
Data in USD. US comparisons are in dollars and with dirty regions; convert them to euros and to your region’s grid (Spain/France) for your case.

The synthesis of S2, in one sentence: for sovereign European data, the decision is not on-prem vs cloud in the abstract, but sovereign on-prem (high utilisation) plus sovereign European cloud (peak) against a hyperscaler that the sovereignty axis rules out, and utilisation is the variable that splits the base between the first two. The rest of the series gives the numbers for each axis; this one crosses them into the recommendation. The next synthesis article (S3) sizes the investment; this one decides the architecture.

Sources

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

Energy per token in Spain: methodology, the electricity market and the cases of speculation

Sun, 14 Jun 2026 03:00:00 +0200

Notation: amounts in euros (N €), decimals with a point. The whole article is focused on the Spanish electricity market (OMIE). The dollar symbol is not used (on this site it is a formula delimiter).

What this article covers

This is the second article of the energy track (C2), and deliberately longer, because it puts together two things that are almost never told together: the technical methodology of measuring energy per token, and the reality of the Spanish electricity market that puts a price on that energy. For an inference platform in Spain, the J/token figure is half the story; the other half is that those kilowatt-hours are bought in a market that is marginal-priced, volatile and with documented cases of manipulation. Anyone who sizes the electricity cost of a cluster without understanding how the price is formed in OMIE, and why it has tripled in a year, is building 30–50 % of the TCO on sand. This article covers the measurement, the market, the cases of speculation and the strategies for not being left exposed. No partisan opinions: data, market mechanics and documented facts, with their sources.

The identity: energy per token, and why the price rules

Energy per token comes from the identity set out in the opening article:

$$\text{energy per token (J)} = \frac{\text{average power (W)}}{\text{throughput (tok/s)}}$$

And the electricity cost per token is that energy multiplied by the price of electricity:

$$\text{electricity cost per token} = \text{energy per token (kWh)} \times \text{PUE} \times \text{price (€/kWh)}$$

Here is the point of this article: the first two factors (energy and PUE) are controlled by your engineering; the third, the price, is set by the Spanish electricity market, and it is the one that moves most. The same workload, with the same efficiency, can cost three times as much in electricity depending on the month, not because of the technology but because of OMIE. That is why measuring energy per token well is necessary but not sufficient: you have to understand the price variable that multiplies it.

Methodology: measuring energy per token without fooling yourself

Before the market, the measurement. As we saw in the energy introduction, the energy-per-token figure has four instrumentation decisions that change the result:

Decision	Trap	Good practice
Sampling frequency	coarse sampling misses the prefill peaks	sample finely (sub-second)
Board vs node	the GPU alone underestimates by 10–20 %	measure the whole node or declare the limit
Time window	including warm-up or shutdown distorts the J/token	align the window with the measured workload
Idle baseline	attributing or subtracting changes the number	decide and document it

The golden rule: the same window for the power and for the tokens. If DCGM integrates the power of one interval and the benchmark tool counts the tokens of another, the J/token means nothing. With that settled, you already have the energy per token; the rest of the article is about what multiplies it.

The Spanish electricity market: how the price is formed

In Spain (and Portugal), the wholesale price of electricity is set by OMIE (Operador del Mercado Ibérico de Energía), which runs the day-ahead market and sets the price for each hour (OMIE). The system is marginal-priced (pay-as-clear): each hour supply (the plants, ordered from cheapest to most expensive) and demand are matched, and the price for everyone is that of the last plant to enter, the marginal one. That marginal price is the same across all of Spain (except the Canaries) and applies to all agents regardless of their initial bid (Energía y Sociedad).

The consequence, central to understanding the bill: when gas is the marginal plant (the usual case in hours without sun or wind), renewables, nuclear and hydro, dirt cheap to produce, are paid the price of gas. That difference between production cost and price received is what are called “windfall profits”, the heart of the debate about market design. For the buyer of electricity, a datacenter for example, it means that the price paid does not reflect the cost of generating, but that of the most expensive technology needed that hour.

The volatility: the price that triples in a year

The marginal-priced market, tied to gas in the expensive hours, produces enormous volatility. The 2026 data illustrates it: the Spanish wholesale price closed May 2026 with an average of 54 €/MWh, more than triple the 16.92 €/MWh of the same month in 2025 (Merca2). Tripling in a year, without your consumption or your efficiency changing.

And within a single day, the dispersion is brutal because of the effect of renewables: solar and wind enter at prices close to zero, and in the midday hours of May 2026 prices reached negative levels in several sessions (Merca2). The structural context: wind and solar went from 26 % of generation in 2019 to more than 40 % in the first half of 2024, and over that period the wholesale price was more than 40 % lower than it would have been with 2019 renewable levels (Banco de España).

Reference	Value	Source
Wholesale May 2026	54 €/MWh	Merca2
Wholesale May 2025	16.92 €/MWh	Merca2
Year-on-year variation	+219 % (×3.2)	derived
Solar hours 2026	prices close to 0 or negative	Merca2
Renewables in generation	26 % (2019) → >40 % (2024)	Banco de España

The reading for a cluster: the electricity part of the TCO is not a fixed number, it is a variable with a range of 3× year on year and from zero-price hours to peak hours within the day. Sizing the energy cost with an annual average price and forgetting about it is ignoring the biggest risk in the model.

The structure of the bill: wholesale is not what you pay

It is worth not confusing the wholesale price (the OMIE pool price, the one the headlines talk about) with what a company actually pays. On top of the wholesale price come:

Component	What it is	Nature
Energy (wholesale)	the OMIE price hour by hour	variable, volatile
Access tolls	use of the transmission and distribution networks	regulated
Charges	system costs (past renewables, etc.)	regulated
Taxes	IEE (special electricity tax) + VAT	fiscal

The result: the industrial retail price a datacenter pays is well above the wholesale price, since tolls, charges and taxes can double the price of pure energy. That is why this article always distinguishes between the wholesale price (~0.054 €/kWh in May 2026) and industrial retail (~0.12 €/kWh): for the TCO the second one matters, but the first is the one that moves and drags the second with it. A large company can access the wholesale market more directly (via a supplier or a representative), reducing the mark-up, but taking on the exposure to volatility that comes with it.

There is also the PVPC (Precio Voluntario al Pequeño Consumidor), the regulated tariff indexed to the wholesale price for small consumers; a datacenter does not use PVPC, but its existence explains why the volatility of the pool reaches public opinion and political debate directly, and, with it, the regulation that ends up affecting everyone.

The 2021–2022 crisis: the origin of the problem

Today’s volatility is not new: it originates in the gas crisis of 2021–2022. When the price of gas shot up (the marginal plant in many hours), the marginal-pricing system passed that price on to all electricity, including that generated by cheap renewables, nuclear and hydro. The result was wholesale prices that were several times the historical levels and massive “windfall profits” for generators of cheap technologies that were paid the price of gas. That episode is what motivated both the Iberian exception (capping gas in price formation) and the European debate about redesigning the market, and it explains why, years later, the price is still a first-order risk variable for anyone consuming a lot of megawatt-hours. For a multi-year TCO model, the lesson is that the Spanish electricity price has shown it can multiply within months through external factors (gas geopolitics), and that no assumption of a “stable” price survives an episode like that unless it is covered by contract.

The cases of speculation and manipulation

The volatility of marginal pricing creates incentives to manipulate the price, and in Spain there are documented cases with final CNMC fines. The largest sanctions on utilities for manipulating the wholesale market (Nada es Gratis):

Company	CNMC fine	Concept
Iberdrola	25 million €	manipulation of the wholesale price via hydro plants
Naturgy	19.5 million €	manipulation of the wholesale market
Endesa	5.8 million €	manipulation of the wholesale market

The Iberdrola case is the most illustrative of how marginal pricing is gamed: between 30 November and 23 December 2013, the company raised the prices of several hydro plants so that they would not clear despite the high prices in the day-ahead market (Nada es Gratis). The mechanism: withhold cheap water (not bidding it, or bidding it at a prohibitive price) so that the clearing needs a more expensive plant, pushing up the marginal price paid to your whole portfolio. In a pay-as-clear system, withdrawing cheap capacity raises the price of everything you sell that hour; the incentive to manipulate is embedded in the design.

OMIE has supervision mechanisms and carries out audits to prevent manipulation (Energía y Sociedad), and the CNMC sanctions it when it is detected; the fines above are the proof that it happens. For the buyer, the relevant point is not to assign blame, but to recognise that the price paid is formed in a market where manipulation is possible and has happened, and that therefore exposure to that price is a risk to manage, not a figure to accept.

The other speculation: hoarding grid capacity (and the new 2026 law)

There is a second form of speculation, distinct from price manipulation, that affects directly anyone who wants to build a datacenter: the hoarding of access and connection permits to the grid. For years, many developers reserved connection capacity at grid nodes for projects (mostly renewable) that had no real intention or capacity to build, blocking that capacity for firm projects and speculating on the value of the permit. Since an inference platform is a demand facility that needs its connection point, this bottleneck hits it squarely: grid capacity is a scarce and hoarded resource.

The regulatory response of 2026 targets exactly that. The Government (Ministry for the Ecological Transition) finalised a set of rules, within the framework of Royal Decree-Law 7/2026, to free up grid capacity and fight speculation, ensuring that firm requests can connect (El Periódico de la Energía, Fieldfisher). The central mechanism, with effect from 22 March 2026:

Element	Detail
Who pays	holders of access and connection permits for demand facilities
What they pay	a monthly charge for “reserving” capacity until entering operation
How it is calculated	transmission and distribution tolls × a “k factor”
Modulation	by voltage level and by the delay in commissioning
k factor	to be set by resolution of the Secretary of State for Energy

The logic: if reserving capacity costs every month and the cost grows with the delay, hoarding stops being free and the speculator releases the capacity it is not going to use. For a real datacenter project the implication is twofold: (1) that charge on the reserved capacity has to be budgeted during construction, and (2) there is a strong incentive to build quickly, since every month of delay in starting up adds to the charge. In other words, the new law turns commissioning time into an explicit cost. For the TCO model and the timetable of the proposal, this is a figure to build in from the start: grid capacity is no longer reserved “just in case” for free, and the construction schedule now has a bill attached.

The design debate: why marginal pricing rewards speculation

The underlying problem is not just that some companies manipulate: it is that the market design rewards doing it. In a pay-as-clear system (everyone is paid the marginal price), a generator with a lot of cheap capacity has a perverse incentive: withdrawing part of its cheap capacity raises the marginal price it is paid for all the capacity it does sell. If you control enough market share, the extra revenue from raising the price of your whole portfolio can exceed what you lose by not selling the withdrawn capacity. That is exactly what the CNMC sanctioned in the hydro case.

The design alternatives under debate:

Design	How it pays	Effect on the incentive to speculate
Pay-as-clear (current)	everyone is paid the marginal price	high: withdrawing capacity raises the price of everything
Pay-as-bid	each one is paid its own bid	lower incentive, but strategic bidding
Long-term contracts / PPA	fixed bilateral price	takes volume out of the pool, reduces exposure

There is no technical consensus that pay-as-bid is better (it introduces its own problems of strategic bidding), and the reform of the European electricity market has opted more for promoting long-term contracts (PPA and CfD) than for changing the pool mechanism. For the buyer, the practical conclusion is the same as for the regulator: taking your volume out of the pool through forward contracts is the most direct way of not being exposed to the marginal price, and to whoever manipulates it.

The Iberian exception: a patch with an expiry date

Faced with the gas price crisis of 2021–2022, the European Commission granted Spain and Portugal an exception allowing them to cap the price of the gas used to produce electricity (market context). The “Iberian exception” partially decoupled the electricity price from gas, containing the peaks. It is relevant for a multi-year cost projection because it is a regulatory mechanism with limited duration: any 36-month TCO model has to consider what happens to the price if the exception changes or expires. Regulation is another price variable, not just the market.

What it means for the electricity cost of a cluster

Putting together energy per token (technical) with the Spanish price (market), the electricity cost per token of an example node (8×H100, 0.78 kWh per million tokens with PUE) according to the price scenario:

Price scenario (Spain)	€/kWh	Electricity cost / 1M tokens
Solar hour / negative price	~0	~0
May 2025 (low wholesale)	0.017	~0.013 €
May 2026 (average wholesale)	0.054	~0.042 €
Industrial retail (with tolls and taxes)	~0.12	~0.094 €
Peak hour / crisis	0.20+	~0.16 €

The range is more than 10× between the solar hour and the peak hour, and 3× year on year at the level of the average. Over a fleet consuming megawatt-hours a year, that variability is the difference between a comfortable TCO and a suffocated one, and it does not depend on your technology but on when and how you buy the energy.

Strategies for not being left exposed

This is where the technical figure turns into a decision. Four levers for managing exposure to the Spanish price, from the least to the most structural:

Strategy	What it does	Trade-off
Indexed tariff	you pay the wholesale price hour by hour	cheap on average, maximum exposure to volatility
Fixed / forward tariff (OMIP)	price locked by contract	predictability, you pay a premium for the insurance
PPA with a renewable plant	you buy directly from a solar/wind farm	stable price and low carbon, requires volume and term
Solar self-consumption	you generate on site	you cover the sunlight hours almost free, capex and space
Temporal scheduling	move shiftable load to cheap hours	only applies to the non-urgent (batch, fine-tuning)

The sensible combination for an inference platform in Spain: a PPA or a fixed tariff for the base load (online inference, which cannot be moved), solar self-consumption to cover the midday hours almost free, and scheduling of the shiftable work (training, overnight batch) towards the off-peak or peak-solar hours. That turns the volatility of marginal pricing from risk into opportunity: the same zero-price hours that sink generators’ revenue are the cheap hours for whoever consumes.

Solar self-consumption: the numbers for a cluster

Spain is one of the best places in Europe for solar, and for a datacenter self-consumption has a clear cost logic. The numbers, for illustration:

Parameter	Reference value
Solar output in Spain	~1,400–1,600 kWh per kWp per year
Capex of an industrial installation	~600–900 € per kWp
Panel service life	~25–30 years
Electricity cost avoided (retail)	~0.12 €/kWh

For a 100 kWp installation (warehouse roof): it generates ~150 MWh/year, with a capex of ~70,000–90,000 €. At 0.12 €/kWh avoided, it saves ~18,000 €/year, with a payback of ~4–6 years and then ~20 years of almost free energy. The snag: a cluster consumes 24/7 and solar only produces by day, so self-consumption covers a fraction, the midday hours, not everything. But those midday hours are precisely the ones with low or negative wholesale prices, so self-consumption and the market complement each other: at night you buy cheap (off-peak), by day you generate. The avoided cost is not only that of the energy, it is that of not being exposed to the non-existent solar peak and to daytime volatility. For a cluster with roof space available, self-consumption is the most solid structural lever on electricity cost in Spain.

Annual electricity TCO: three scenarios for a cluster in Spain

Putting it all together, the annual electricity cost of an 8×H100 node (~7.84 kW with PUE, ~68,700 kWh/year at 100 % utilisation) according to the purchasing strategy, in Spain:

Strategy	Effective €/kWh	Annual electricity cost	Exposure
Indexed (unhedged)	~0.08 (variable)	~5,500 € ±a lot	maximum to volatility
Fixed / renewable PPA	~0.06 (stable)	~4,120 €	low, predictable
PPA + solar self-consumption	~0.045 (mixed)	~3,090 €	low + minimal carbon

The difference between the worst and the best strategy is ~2,400 €/year per node, before counting the risk: the indexed option can shoot up in a bad month, while PPA+solar is stable and low. Over a fleet of dozens of nodes and a 36-month horizon, the choice of how the energy is bought moves the TCO as much as a hardware decision, and it is a lever decided with contracts, not with engineering. This number feeds directly into the TCO model of the FinOps track (A8) and the sizing of the proposal.

PPAs: the central lever (and its small print in 2026)

Of all the strategies, the PPA (Power Purchase Agreement, a long-term energy purchase contract) is the most important piece for a datacenter in Spain today, and it deserves a section of its own because its current situation is exceptionally favourable… with a catch.

What a PPA is, in short

A PPA is a bilateral, long-term contract (typically 10–12 years in Spain) between a consumer and a renewable generator, at a locked price per MWh. It takes your volume out of the OMIE pool: instead of paying the marginal price hour by hour (with its volatility and its exposure to manipulation), you pay the contract price. There are two families: physical (you receive the energy from that farm) and financial/virtual (a swap covering the difference against the market); and two profile forms: pay-as-produced (you pay for what the farm generates, when it generates, cheap but intermittent) and baseload (a guaranteed flat profile, more expensive but firm).

Prices today: historic lows

Spain is living a unique moment in PPA prices. Solar PPAs fell to a historic low of 32.5 €/MWh in the fourth quarter of 2025, with the most competitive percentiles below 30 €/MWh, half the French level (pv-magazine, El Periódico de la Energía). Wind sits at around 50–60 €/MWh. To put it in context: a solar PPA at 30 €/MWh is ~0.030 €/kWh, less than half the industrial retail price (~0.12 €/kWh) and well below the volatile wholesale price.

Technology (PPA, Spain 2026)	Price	Reference
Solar photovoltaic	~32.5 €/MWh (percentiles <30)	pv-magazine
Wind	~50–60 €/MWh	market
Industrial retail (for comparison)	~120 €/MWh	—

Why so cheap: cannibalisation

The fall is no accident: it is the cannibalisation of photovoltaics. The more solar is installed, the more midday hours there are with wholesale prices close to zero or negative, which sinks the value captured by solar (captured prices have fallen below 15 €/MWh), and with it the price at which farms sign PPAs (Energía Estratégica). With more than 40 GW competing for 30 GW of demand, there is an excess of solar supply that cheapens the PPA. For the industrial consumer it is a historic opportunity; for the solar developer, a crisis of profitability, hence the talk of the “closing of the solar PPA window” and of the new Royal Decree seeking to restore industrial competitiveness.

Spain, European leader in PPAs

This is no marginal phenomenon: in 2024 Spain was the country with the most PPAs signed in Europe for the sixth consecutive year, with 47 agreements for 4.66 GW of renewable capacity (market sources). The market is deep, liquid and mature, which makes it easier for a datacenter to find a counterparty.

The catch for a datacenter: annual energy ≠ firm power

Here is the small print that decides the architecture. A cheap solar PPA offsets energy over the year, but does not guarantee physical power every hour. And an AI datacenter cannot stop because there is no wind one January night or because the solar curve falls at dusk (El Periódico de la Energía). This is the difference between energy (kWh per year, which the solar PPA covers dirt cheap) and firm power (kW available for all 8,760 hours, which the sun does not provide). The sector sums it up like this: Spain is now forced to talk about firm energy (Revista Cloud).

The consequence for the design of the proposal: a solar PPA at 30 €/MWh is the ideal cost floor for the sunlight hours, but it has to be combined to cover the rest: a hybrid PPA (solar + wind, which complement each other over time), baseload for the flat part, or storage (batteries, which RDL 7/2026 also promotes) to move energy from the sunlight hours to the night. The sensible energy architecture of a Spanish datacenter in 2026 is not “a solar PPA”, it is a cheap solar PPA as the daytime base + firmness for the hours without sun (wind, baseload, batteries or the grid as backup). Anyone who signs only the cheap solar PPA and discovers in production that they have no firm power in the small hours will have optimised the cost of the energy and ignored that of availability, which for an inference platform with an SLO is non-negotiable.

The context: the datacenter boom in Spain

All of this is happening in the middle of a boom: Spain is positioning itself as the epicentre of southern Europe in datacenters, with investments of billions and installed capacity doubling towards 2026 (DCD). The appeal combines cheap renewable PPAs, industrial land more accessible than in other European digital capitals, and EU jurisdiction. The constraint that tempers it is exactly the one in C2: the cost of energy is low but firm power and grid capacity are the bottlenecks, and both are managed with the combination of a hybrid PPA, storage and a connection schedule that does not fall foul of the hoarding charge.

The sovereign and carbon angle

For a sovereign proposal, Spain has a double advantage worth quantifying. First, carbon: the Spanish grid runs at around ~150–170 gCO₂/kWh (a mix of renewables and gas), well below Germany (~363) though above nuclear France (~20–60). Second, growing renewables (>40 % of generation), which pull the price and the carbon down in the sunlight hours. The argument for the proposal: a cluster in Spain, with solar self-consumption and a renewable PPA, can achieve at the same time a low and predictable electricity cost and a competitive carbon per token, within EU jurisdiction. The volatility of marginal pricing is not only a risk: managed well with contracting and scheduling, it is a cost lever that a hyperscaler in another region does not exploit in the same way.

Carbon, moreover, is variable by the hour: in peak-solar hours the intensity of the Spanish grid drops, so moving shiftable load to those hours reduces both the cost and the carbon per token at once. The same scheduling strategy serves both axes.

Guarantees of Origin: carbon has its market too

One nuance that connects price speculation with carbon reporting: in Spain (and the EU) there is a market in Guarantees of Origin (GoO), certificates attesting that a quantity of energy was produced from a renewable source. A company can buy GoOs to declare that its consumption is “green” in its market-based carbon reporting, even though physically the electricity it received from the grid had the average intensity of the mix. This creates two ways of accounting for carbon, with different implications:

Method	What it counts	How the figure is brought down
By location (location-based)	the real intensity of the Spanish grid that hour	generate/consume in clean hours; location
By market (market-based)	according to the GoOs/PPAs contracted	buy certificates or sign a PPA

Location-based accounting rewards consuming when the Spanish grid is clean (solar hours); market-based allows the green attribute to be “bought” with GoOs. CSRD reporting normally requires both. The word of caution: the GoO market is relatively cheap, and buying GoOs without a real PPA behind them is a way of dressing up the figure without changing the physical electricity you consume, the cost equivalent of accounting greenwashing. For an honest sovereign proposal, the robust route is a real PPA with a Spanish renewable farm (which does change the physical origin and stabilises the price) plus location-based measurement that rewards scheduling to clean hours, rather than accumulating certificates.

Hourly intensity: the Red Eléctrica figure

Spain publishes the carbon intensity of the grid hour by hour (via Red Eléctrica / esios and ElectricityMaps), and it varies enormously over the day: on a sunny spring afternoon it can drop to ~80–100 gCO₂/kWh, and on a cold, windless night, with gas cycles, exceed ~250. That hourly figure is what makes carbon-aware scheduling possible: moving training, document ingestion or overnight batch to the hours of lowest intensity reduces the carbon per token of the shiftable work at no technical cost. It is the same lever as price-based scheduling, since the cheap hours and the clean ones largely coincide in Spain, because both are set by the excess of solar and wind. Measuring carbon per token “on an annual average” wastes this information; measuring it hour by hour and scheduling accordingly is what turns the figure into a real reduction.

Energy per token, with the Spanish price, step by step

Closing the circle with a complete calculation for the example node, in Spain:

Energy per token: 5,600 W (8×H100) ÷ 2,800 tok/s = 2 J/token (board); ×PUE 1.4 = 2.8 J/token effective.
Energy per 1M tokens: 0.78 kWh (with PUE).
Electricity cost per 1M tokens by contracting model:
- Indexed in a solar hour (~0 €/kWh): ~0 €.
- Renewable PPA (~0.05 €/kWh stable): ~0.039 €.
- Industrial retail (~0.12 €/kWh): ~0.094 €.
Carbon per 1M tokens: 0.78 kWh × ~160 gCO₂/kWh = ~125 gCO₂ (and less in solar hours).

The message: the J/token is fixed (your engineering sets it); the electricity cost per token varies more than 10× depending on how and when you buy the energy in Spain. That is why this article devotes more space to the market than to the measurement: measuring is 30 % of the problem; buying well is 70 %.

Limits and traps (data-driven)

A misleading annual average price. Using an annual average hides the 3× year-on-year volatility and the 10× intraday range. Model scenarios, not a point.
Indexed by default. The indexed tariff is cheap on average but leaves you exposed to every peak and every episode of manipulation. For base load, hedge it.
Ignoring the Iberian exception. It is a regulatory mechanism with an expiry date; a 36-month TCO has to consider it changing.
Forgetting hourly carbon. Carbon and price fall at the same time in solar hours; scheduling the shiftable work improves both axes.
Confusing wholesale with what you pay. Industrial retail adds tolls and taxes on top of the wholesale price; use your contract price, not the pool price.

With the Spanish price understood, the energy track continues towards measurement tools in depth (C3) and energy in TCO and regulation (C8). But the lesson of C2 is that, in Spain, the energy cost of AI is not decided in the GPU alone: it is decided in how you buy the electricity in a market that is marginal-priced, volatile and watched for manipulation.

Closing

Energy per token is a number that engineering fixes with precision, so many joules per token, measured in a window aligned with the throughput, and that the Spanish electricity market multiplies by a factor that changes more than 10× depending on the hour and 3× depending on the year. That second half, the price one, hardly ever appears in technical AI articles, and it is what decides 30–50 % of the TCO of a cluster in Spain. The price is formed in a marginal-priced market where cheap renewables are paid the price of gas, where volatility has tripled the bill in a year, and where there are final CNMC fines, Iberdrola 25 M€, Naturgy 19.5 M€, Endesa 5.8 M€, that show that manipulation is not theoretical. For a sovereign inference platform in Spain, the conclusion the data supports is twofold: measure energy per token rigorously, and buy the electricity with your head — a PPA or fixed tariff for the base load, solar self-consumption for the sunlight hours, and scheduling of the shiftable work to the cheap, clean hours. Spain offers abundant sun, growing renewables and a reasonable average carbon figure; well contracted, its energy is a competitive advantage, and badly contracted, the biggest risk in the model. The J/token is yours to decide; the euro per token, the market’s, unless you take it out of the market with a contract.

Sources

OMIE · Operador del Mercado Ibérico de Energía — https://www.omie.es/
OMIE · precio del mercado diario — https://www.omie.es/es/market-results/daily/daily-market/day-ahead-price
Energía y Sociedad · importancia y precios de OMIE — https://www.energiaysociedad.es/omie-cual-es-su-importancia-para-el-sistema-electrico-espanol-y-portugues/
Nada es Gratis · manipulación del precio en el mercado eléctrico español (multas CNMC) — https://nadaesgratis.es/jose-luis-ferreira/manipulacion-del-precio-en-el-mercado-electrico-espanol
Merca2 · el precio de la luz en mayo 2026 (54 €/MWh, ×3 interanual) — https://www.merca2.es/2026/05/30/precio-luz-mayo-2026-disparo-2386473/
Banco de España · el sector eléctrico ante el alza del gas (renovables y precio) — https://www.bde.es/f/webbe/SES/Secciones/Publicaciones/PublicacionesSeriadas/DocumentosOcasionales/23/Fich/do2316.pdf
El Periódico de la Energía · normativa para liberar capacidad de red y combatir la especulación — https://elperiodicodelaenergia.com/el-gobierno-ultima-una-normativa-para-liberar-la-capacidad-de-las-redes-electricas-y-combatir-la-especulacion/
Fieldfisher · Real Decreto-ley 7/2026, paquete regulatorio de renovables — https://www.fieldfisher.com/es-es/locations/espana/actualidad/nuevo-paquete-regulatorio-energias-renovables
Bird & Bird · almacenamiento energético en el RDL 7/2026 — https://www.twobirds.com/es/insights/2026/spain/almacenamiento-energetico-real-decreto-ley-7-2026
pv-magazine · caída récord de los PPAs fotovoltaicos a 32,5 €/MWh — https://www.pv-magazine.es/2026/02/04/la-canibalizacion-provoca-una-caida-record-de-los-precios-de-los-ppas-fotovoltaicos-en-espana-hasta-los-325-e-mwh/
El Periódico de la Energía · PPAs solares cerca de 30 €/MWh (mitad que Francia) — https://elperiodicodelaenergia.com/la-canibalizacion-acerca-el-precio-de-los-ppas-solares-a-30-mwh-en-espana-la-mitad-que-en-francia/
Energía Estratégica · cierre de la ventana de PPAs solares y el nuevo RD — https://www.energiaestrategica.com/espana-atraviesa-un-cierre-de-la-ventana-de-ppas-solares-mientras-el-nuevo-real-decreto-busca-aliviar-la-industria/
El Periódico de la Energía · la gran decisión energética de los data centers (energía firme) — https://elperiodicodelaenergia.com/la-gran-decision-energetica-de-los-data-centers
Revista Cloud · los centros de datos obligan a España a hablar de energía firme — https://revistacloud.com/los-centros-de-datos-obligan-a-espana-a-hablar-de-energia-firme
DCD · boom de data centers en España hacia 2026 — https://www.datacenterdynamics.com/es/features/data-centers-en-espa%C3%B1a-hacia-2026-un-boom-de-90000-millones-en-proyectos/

Spain on lo0 — Tech Blog

Sovereign on-premise vs hyperscalers: the case with data (cost, energy, performance and sovereignty)

What this article covers

The framework: four axes, not one number

The cost axis: TCO and break-even

Three-year TCO: the full calculation for an 8×H100 node

The uncomfortable reality: the utilisation almost nobody reaches

The hidden costs of the cloud: egress

The performance axis: the provider does not decide, goodput does

The energy axis: the European and Spanish advantage

The sovereignty axis: the one that does not depend on utilisation

The scorecard: the three options scored

When each option wins

Sizing the hybrid: how much on iron, how much on cloud

Assumptions and sensitivity

Decision checklist

Limits and traps (data-driven)

See also

Sources

Energy per token in Spain: methodology, the electricity market and the cases of speculation

What this article covers

The identity: energy per token, and why the price rules

Methodology: measuring energy per token without fooling yourself

The Spanish electricity market: how the price is formed

The volatility: the price that triples in a year

The structure of the bill: wholesale is not what you pay

The 2021–2022 crisis: the origin of the problem

The cases of speculation and manipulation

The other speculation: hoarding grid capacity (and the new 2026 law)

The design debate: why marginal pricing rewards speculation

The Iberian exception: a patch with an expiry date

What it means for the electricity cost of a cluster

Strategies for not being left exposed

Solar self-consumption: the numbers for a cluster

Annual electricity TCO: three scenarios for a cluster in Spain

PPAs: the central lever (and its small print in 2026)

What a PPA is, in short

Prices today: historic lows

Why so cheap: cannibalisation

Spain, European leader in PPAs

The catch for a datacenter: annual energy ≠ firm power

The context: the datacenter boom in Spain

The sovereign and carbon angle

Guarantees of Origin: carbon has its market too

Hourly intensity: the Red Eléctrica figure

Energy per token, with the Spanish price, step by step

Limits and traps (data-driven)

Closing

See also

Sources