Federated Compute for Europe (EuroAI)

A minimal way to make existing capacity work as one system

 

1. Starting point

Europe does not lack computing resources.

It struggles to use them effectively as a whole.

Across Europe there are:

EuroHPC systems

national clusters

emerging AI infrastructure

Taken together, this is significant capacity.

In practice, it does not behave as one system.

Some centres have long queues.

Others have unused capacity.

This is not a failure of execution.

It follows from how the system is set up.

Most centres are evaluated by:

funding received

projects hosted

not by how efficiently their capacity is used.

As a result:

capacity is allocated locally

unused resources are kept local

coordination does not emerge on its own

2. What follows from this

If the system rewards local control,

it will produce local behaviour.

Coordination will not appear by itself.

It will not be solved by:

new programmes

general calls for cooperation

additional coordination layers

Any approach that depends on goodwill will fail.

3. The shift

The issue is no longer how to build more compute, but how to use what already exists as one system.

The question is not:

how to make centres cooperate

The question is:

can something work without requiring coordination first

4. The mechanism

This does not introduce a new system.

It introduces a small addition.

Its purpose is simple:

allow existing capacity to be used when it is available,

outside of local constraints.

This is implemented as a minimal shared interface between participating centres, not as a new platform or central system.

5. How it works

Centres can make available capacity visible.

Jobs can be matched to that capacity using simple rules, such as:

urgency (how long a job has been waiting)

priority (type of work)

balance (recent usage vs contribution)

These rules are agreed once and adjusted by participating centres.

They are not negotiated for each job.

When conditions match, execution can be triggered on the available system.

Coordination happens through matching,

not through negotiation.

6. Where this works

This approach applies when:

capacity exists but is not fully used

jobs can be executed remotely

no blocking legal or data constraints apply

It is primarily suited to compute-intensive workloads,

not to large-scale data movement.

7. Where it does not

It does not apply when:

workloads depend on local data

all capacity is already fully used

centres choose not to take part

8. Participation logic

Participation is not based on cooperation.

It is based on access

Centres that take part can use more than their local capacity.

Centres that do not take part remain limited to what they have.

9. Incentive structure

Participation is tracked in simple terms:

contribution (capacity made available)

usage (capacity consumed)

Over time:

centres that contribute more gain better access

centres that only consume receive lower priority

Tracking is done between comparable resources.

Exact equivalence is not required at this stage.

Initial accounting can remain simple (for comparable workloads) and be refined over time as participation grows.

This creates a basic balance without requiring a central payment system.

10. Control

Control remains local.

Each centre decides:

when to make capacity available

how much to allocate

under what conditions

Most decisions follow predefined rules.

Exceptions remain under human control.

Participation is voluntary and reversible.

Capacity can be withdrawn at any time.

11. Rules

The rules used for matching are defined and adjusted by participating centres.

No central authority is required.

Conflicts are handled by participating centres themselves under agreed rules; no global arbitration is required at the initial stage.

12. Scope

This does not replace existing systems.

It adds a small layer that allows them to work together when useful.

13. Adoption

Full participation is not required.

This can start with a small number of sites.

even 2–3 centres can reduce local bottlenecks

and demonstrate measurable value

14. When it becomes relevant

This becomes relevant when:

queues grow in some places

capacity remains unused elsewhere

demand exceeds local limits

Even when systems appear fully loaded,

allocation remains uneven and prioritisation becomes critical.

15. Expected effect

This does not eliminate inefficiencies.

it reduces the most visible ones

Reducing visible inefficiencies

is often the first step before larger changes.

16. One line

It does not change the system.

It makes it slightly harder for capacity to remain unused.

17. Strategic urgency

This is not primarily a question of building more capacity.

It is a question of who defines how capacity is used.

If a coordination layer is established externally,

then even locally installed infrastructure

will operate under external control.

In that case:

– access is defined elsewhere

– allocation is decided elsewhere

– value is captured elsewhere

This can happen without any formal transfer of ownership.

Infrastructure remains local,

but the system that uses it does not.

If Europe does not establish its own minimal coordination layer,

it will rely on those provided by others.

At that point, increasing capacity does not increase control.

It only increases dependency.

The window is therefore not defined by hardware timelines.

It is defined by whether a coordination layer emerges locally

before it is adopted from outside.

18. Minimal starting point

This does not require a formal programme or coordination framework.

A minimal starting point can emerge with:

2–3 participating centres

a limited subset of workloads (e.g. batch jobs)

a simple shared interface for:

capacity visibility

job matching

No structural changes are required.

Each centre:

defines a small portion of capacity available externally

applies predefined matching rules

retains full control over execution

This can operate alongside existing allocation mechanisms.

What this demonstrates:

that matching can occur without prior coordination

that unused capacity can be utilised without system change

that local control is not affected

If this proves workable, it can expand incrementally.

Tagy
ai infrastructures

Komentáře

Profile picture for user n007od6h
Vytvořil uživatel Daniel Živica dne Pá, 10/04/2026 - 12:20

Critical post. Hardware isn't the bottleneck, but siloed governance is. Your Strategic Urgency (17) is the core: without a local coordination layer, infrastructure is just a high-maintenance dependency. 

I value the shift from "goodwill" to "incentive-based" access. Minimal shared interfaces are the practical path to efficiency. 

If Europe doesn’t own the orchestration layer, it doesn’t own its sovereignty. Let’s stop negotiating and start matching capacity across the Block.

User
Vytvořil uživatel Gintautas Vindašius dne Út, 14/04/2026 - 16:33

That’s a very clear way to put it — especially your point about orchestration and sovereignty. That connection is often missed.