DM Explains · No. 045 · Sovereign AI
Resource federation: how fragmented compute becomes one sovereign supercomputer
Europe and others want hyperscaler-scale AI without giving up control of data or hardware. Federation is the architecture that pools many small, independently owned compute pools into one usable system.
· 13 min read
Read me first
Resource federation genuinely does let fragmented, independently owned compute act like one large system, but only when discovery, control and scheduling stay separate from ownership; nobody has to hand over their machines to join.
OpenTela: a cluster joins via gossip discovery (1) → control plane negotiates policy while data stays local (2) → Slurm and Kubernetes APIs unify (3) → the institution keeps its own key (4) → a locked cupboard doesn't starve the house (5) → cross-border request honours local law (6) → 13 million requests, 15 billion tokens, 142 models served over 22 months
A European research consortium has GPUs scattered across a dozen national HPC (high-performance computing) clusters, each run by a different institution with its own scheduler, its own admin team, and its own rules about who may touch its machines. No single cluster is big enough to train or serve a frontier-scale model; together they would rival a hyperscaler. The gap between "together" and "alone" is the whole problem.
If the clusters stay isolated, Europe's compute stays fragmented and dependent on foreign hyperscalers for anything at scale. If pooling means handing hardware and governance to one central operator, every participating institution loses the sovereignty it joined to protect. Get the architecture wrong and you either get no scale or no sovereignty.
Everyday picture. Instead of Amma, Papa and Dadi each buying a separate rice cooker, fridge and oven, the family agrees that whoever is cooking can borrow any appliance in the house, as long as everyone keeps their own cupboard key and nobody gives up ownership of what they bought.
Where the picture breaks. Real federation members live in separate houses on a street, under different house rules about who may enter — a single shared house can't show that cross-institutional, cross-border boundary.
Why it exists now
Through 2025, several parallel European efforts converged on federation as the delivery mechanism for "sovereign AI". Nineteen EU states signed the IPCEI-AI manifesto committing to a "continuum of federated and distributed AI services," tying the effort to the AI Continent Action Plan and the Cloud and AI Development Act, as the manifesto itself states. CISPE, the cloud infrastructure providers' body, published a Sovereign Cloud Manifesto proposing cross-border pooling APIs, and ETP4HPC — the European technology platform for high-performance computing — released a white paper formally defining what it calls "Federated Computing Infrastructure" for the EuroHPC era, laying out its characteristics.
What changed is not just policy appetite but proof that it works in production. A Cambridge-built system called OpenTela federated fragmented, cross-institutional HPC clusters into one LLM-serving platform, and ran that way for over 22 months, handling 13 million requests and 15 billion tokens across 142 models — entirely from user space, without root access or reconfiguring any underlying cluster, according to the OSDI paper describing it. That is the proof point this article keeps returning to: federation doesn't need a merger or a new owner, just an agreed set of rules for discovery, control and scheduling.
How it works
Discovery
Nobody owns the map, so the map updates itself
What it is. Each participating cluster advertises its own available compute — GPUs, models, capacity — into a shared layer that nobody centrally owns, rather than registering with one authority.
Why it exists. Without a way to know what capacity exists right now, across sites that can join, leave or vanish at any time, a federation cannot route anything.
Where it breaks. Gossip-style propagation takes time; a federation needing millisecond-fresh global state everywhere will see stale views at its edges.
How that's handled. OpenTela keeps a live, fault-tolerant picture of capacity using a conflict-free merge technique rather than a single source of truth, so partial outages don't blank the whole map.
In technical terms
In technical terms: OpenTela provides fault-tolerant service discovery via a CRDT-based (conflict-free replicated data type) gossip network across fragmented HPC clusters, so nodes exchange and merge state with neighbours without a central registry.
Control vs data plane
Decide separately from where the work happens
What it is. Policy negotiation and contract enforcement live in a control plane; the actual movement and processing of data and model weights lives in a separate data plane.
Why it exists. Separating the two lets each sovereign party enforce its own legal constraints — which jurisdiction's rules apply, who may access what — without trusting a shared processing layer with raw data.
Where it breaks. The split adds latency and operational complexity; workloads needing tight coupling between a decision and its execution pay a real tax here.
How that's handled. A federated, policy-governed architecture for sovereign European data spaces uses exactly this split to mediate negotiation and enforcement, as described in Open Research Europe.
In technical terms
In technical terms: the control plane mediates policy negotiation and contract enforcement; the data plane carries out computation, so no single component sees both the legal decision and the raw payload.
Heterogeneous stacks?
Slurm here, Kubernetes there, same API
What it is. Yes — federation only works if a scheduler abstracts over wildly different hardware and cluster managers, because federated members rarely run identical infrastructure.
Why it exists. One institution runs Slurm job scheduling, another runs a Kubernetes-style manager, a third runs neither; a usable pool needs one interface over all of it.
Where it breaks. Abstraction leaks: a workload tuned for one site's exact hardware may run worse once genericised across the pool.
How that's handled. OpenTela offers a single API over clusters that variously run Slurm, Kubernetes-style managers, or neither, routing serving requests to whichever federated resource fits the model and the load.
In technical terms
In technical terms: OpenTela offers a unified API over heterogeneous cluster managers and serving engines in HPC environments where Kubernetes-style control planes are unavailable.
Selectable autonomy
Join the pool, keep your own key
What it is. Every member chooses its own level of participation and can set local rules the federation must respect, rather than ceding full control.
Why it exists. Legal, data-protection and strategic requirements mean members must be able to opt in or out and define their own constraints — otherwise nobody with anything to lose would join.
Where it breaks. Too much selectable autonomy and the federation can't guarantee consistent service levels; members can opt out exactly when capacity is most needed.
How that's handled. ETP4HPC's definition of Federated Computing Infrastructure names six characteristics — decentralisation, interoperability, openness, scalability, data security and sovereignty, and fault tolerance — with selectable autonomy threaded through them as the thing that keeps participation voluntary.
In technical terms
In technical terms: a Federated Computing Infrastructure gives each participating organisation a selectable level of autonomy and independence over its own resources, as ETP4HPC's white paper defines it.
Fault tolerance
One cupboard locked doesn't starve the house
What it is. Losing any single site degrades capacity rather than collapsing the whole system.
Why it exists. Because capacity is spread across many independently administered sites, redundancy is structural: a node going offline is isolated rather than fatal.
Where it breaks. If one site holds a unique model or dataset with no replica elsewhere, its loss is still a real loss — redundancy only covers what's actually duplicated.
How that's handled. The same six-characteristic definition names fault tolerance, redundancy and resiliency as core properties of a Federated Computing Infrastructure, not optional extras.
In technical terms
In technical terms: distributing capacity across independent administrative domains means the discovery and scheduling layers isolate a failed node instead of halting the pool.
Cross-border rules
Shared APIs, not shared law
What it is. Interoperability standards let providers in different jurisdictions pool capability without harmonising their legal systems.
Why it exists. Legal fragmentation across borders is the main barrier to pooling; shared APIs let a request cross from one provider's infrastructure to another's while each side enforces its own law locally.
Where it breaks. Standards proposed by industry bodies are not yet law; until adopted broadly, cross-border federation depends on voluntary agreement, which can fragment under commercial pressure.
How that's handled. CISPE's Sovereign Cloud Manifesto proposes the Fulcrum and SECA APIs precisely to let European cloud providers pool capabilities across borders while each still meets its own obligations under GDPR, the AI Act and the Data Act, as the manifesto sets out.
In technical terms
In technical terms: Fulcrum and SECA are proposed APIs for cross-provider pooling of capabilities under shared interoperability standards, not a shared legal or ownership structure.
Compared with what came before
| Single sovereign facility | Resource federation | |
|---|---|---|
| Who owns the hardware | One organisation or government | Many independent organisations, each keeping their own |
| Scale ceiling | Bounded by what one facility can build | Bounded by how many sites join and how well they interoperate |
| Governance | One set of rules | Selectable autonomy; each member sets its own constraints |
| Resilience | One failure can take down the facility | Failure of one site degrades, rather than collapses, capacity |
| What you give up | Flexibility to pool with others | Simplicity; coordination overhead across discovery, control plane and scheduling |
A single sovereign facility is simpler to reason about and cheaper to build if your ambitions stay within what one facility can hold. Federation trades that simplicity for scale that no single member could build alone — but it only pays off once discovery, the control-plane split and cross-border APIs are actually working, not just agreed on paper.
Where it breaks
Federation adds real cost, not just real capability. The ETP4HPC white paper is explicit that Federated Computing Infrastructures bring increased system complexity, inter-system security concerns, and potential governance conflicts between participating organisations, which can undermine the intended benefits if not managed with proper governance.
Not a substitute for legal harmonisation
Shared APIs like Fulcrum and SECA let requests move across borders, but they do not change what GDPR, the AI Act or the Data Act require inside each jurisdiction. A federation is only as sovereignty-respecting as the weakest member's local enforcement.
Not for tight coupling
Splitting control plane from data plane, and routing across heterogeneous schedulers, adds latency at every hop. Workloads that need the decision and the execution to happen in the same breath will feel this tax.
Real-time, ultra-low-latency applications are a poor fit for the same reason: the coordination overhead of cross-domain discovery and scheduling is tolerable for serving an LLM across a research consortium, less tolerable for anything that cannot wait out a gossip propagation delay.
Numbers to carry
| Figure | Value |
|---|---|
| OpenTela deployment length | over 22 months |
| OpenTela requests served | 13 million |
| OpenTela tokens served | 15 billion |
| OpenTela models served | 142 |
| EU states signing the IPCEI-AI manifesto | 19 |
| ETP4HPC's defining characteristics of Federated Computing Infrastructure | 6 (decentralisation, interoperability, openness, scalability, data sovereignty, fault tolerance) |
Myths worth killing
| Commonly repeated | What is actually true |
|---|---|
| "Federation means one company or government ends up running everything." | Selectable autonomy is the defining feature: each member keeps its own resources and sets its own participation rules. |
| "You need root access or a single platform to pool clusters." | OpenTela federated clusters entirely from user space, without root access or reconfiguring any underlying cluster. |
| "Federated learning and resource federation are the same thing." | Federated learning keeps training data local while aggregating model updates; resource federation pools compute, storage and serving capacity at the infrastructure layer, and may or may not involve federated learning at all. |
| "Cross-border APIs mean cross-border laws are now the same." | Fulcrum and SECA are proposed interoperability APIs; GDPR, the AI Act and the Data Act are still enforced separately by each participant. |
Worked example
- The consortium's twelve institutions each advertise their idle GPU capacity into the discovery layer; no single registry owns the list, and it updates as sites come online or drop out.
- A researcher submits a request to serve a model; the scheduler checks which federated sites can host it, regardless of whether that site runs Slurm or something else.
- The control plane checks whether the requesting researcher's institution and the hosting site's policies allow the request, before any data moves — illustrative: say the hosting site's local rule requires the request to come from an EU-registered institution, and the check happens here, not after the fact.
- The data plane carries out the actual serving: weights and compute happen at the chosen site, under that site's own hardware and admin team.
- One of the twelve clusters goes offline for maintenance; the discovery layer's gossip-based view updates within its propagation delay, and the scheduler routes new requests elsewhere — illustrative: if that cluster held a fifth of total capacity, the pool's remaining throughput drops but does not stop.
- Over months, the pattern repeats across a growing set of researchers, accumulating into the scale OpenTela reported in production: millions of requests and billions of tokens, served without any one institution owning the whole system.
Should you use it?
Federation fits when multiple institutions or nations each hold fragmented, underused compute that no single one can scale alone, and when data or workloads must stay within specific legal or geographic boundaries while still reaching a larger shared pool. It is a poor fit for a single, simple, centrally manageable cluster where governance complexity outweighs the benefit, for real-time applications that cannot tolerate coordination overhead, and for organisations unwilling to agree on any shared interoperability layer at all — federation depends on that agreement existing.
The cheapest first experiment is not a new data centre: it's standing up a discovery layer across two or three existing clusters that already belong to willing partners, and proving that capacity can be found and routed to before any contract gets written about who owns what.
Say it in the room
"Pool the compute, not the ownership — federate discovery and scheduling first, and only then negotiate who's allowed to use what."
Lines to carry
- "Pooled, not ceded."
- "No single mind, just gossip that keeps up."
- "Decide locally, compute wherever fits."
- "Scale without surrender."
- "Redundancy only covers what's actually duplicated."
- "Shared APIs, not shared law."
FAQ
Does federation require everyone to run the same software?
No. OpenTela's entire premise is a unified API sitting over clusters that run Slurm, Kubernetes-style managers, or neither. Heterogeneity is the normal case, not an edge case.
Who is legally responsible if something goes wrong at one site?
Each participant keeps enforcing its own jurisdiction's rules locally; the control plane mediates policy negotiation between members, but it does not replace each member's own legal obligations under laws like GDPR or the AI Act.
Is this the same as federated learning?
No. Federated learning is a training technique that keeps data local while aggregating model updates. Resource federation is about pooling compute, storage and serving capacity at the infrastructure level — a federation can exist with no federated learning happening inside it at all.
What happens if one institution wants to leave the federation?
Selectable autonomy means that's expected to be possible; the design goal is that losing one member degrades total capacity rather than breaking the system for everyone else, provided what that member held wasn't the sole copy of something unique.
Does federation make cross-border AI projects legally simpler?
Not by itself. Proposed APIs like Fulcrum and SECA aim to make cross-border pooling technically possible, but they are proposals from an industry body, not law, and each jurisdiction's rules still apply independently inside the federation.
Glossary
- Resource federation — a system where independently owned compute, storage or data resources are combined so they can be used together, without one party controlling them all.
- Sovereign AI — AI infrastructure, data and models kept under a nation's or organisation's own legal, physical and operational control.
- Control plane — the part of a system that decides policy, routing and access, separate from the part that processes the data.
- Data plane — the part of a system that carries out the actual data processing or movement, following the control plane's decisions.
- CRDT (conflict-free replicated data type) — a data structure that lets multiple computers update shared information independently and later merge changes automatically without conflicts.
- Gossip network — a way for computers to spread information to each other informally and redundantly, so the system keeps working even when some nodes are unreachable.
- HPC cluster — a high-performance computing cluster: a group of powerful computers linked together to run demanding workloads.
- Slurm — a widely used job-scheduling system for allocating tasks to nodes in an HPC cluster.
- IPCEI (Important Project of Common European Interest) — an EU mechanism letting member states jointly fund and coordinate large strategic projects.
- Data space — a governed environment for sharing data across organisations under agreed rules, often used to meet laws like GDPR.
- Selectable autonomy — the ability of a federation member to choose its own level of participation and set its own local rules.
Sources
- A federated policy-governed architecture for sovereign European data spaces — Open Research Europe
- Manifesto for the Important Project of common European Interest on a continuum of federated and distributed Artificial Intelligence services (IPCEI-AI) — German Federal Ministry for Economic Affairs
- Federated computing: information integration under sovereignty constraints — Royal Society Open Science
- Executive Summary: A Strategic Vision for European Digital Sovereignty / European Cognitive Computing Continuum — EUCloudEdgeIoT, 2025
- OpenTela: Unifying Decentralized Computing Resources for Heterogeneous LLM Serving — University of Cambridge Computer Laboratory (OSDI), 2026
- CISPE Sovereign Cloud Manifesto — CISPE, 2025
- White Paper: Federation of Computing Architectures — ETP4HPC, 2025