openEuler Wants Linux to Treat an Entire AI Cluster Like One Single Machine

For most of its life, Linux has been built around one simple assumption. There’s a box; it has CPUs, memory, and devices, and the kernel manages them. Clusters exist, of course, but they’ve mostly been a problem for the layers above the OS, i.e., schedulers, orchestrators, distributed frameworks.

AI infrastructure wants more. Today’s training and inference setups bind dozens of CPUs, NPUs, GPUs, and memory pools so tightly together that they behave less like a group of servers and more like a single but very large computer. And then come AI agents, which don’t just run a model but spin up tools, sandboxes, and long-running sessions on the fly.

That was the core of the keynote Xinwei Hu, Chairman of the openEuler Technical Committee, gave at Open Source Summit Europe 2026 in Prague.

Let’s see how openEuler is innovating Linux around agentic scaling.

The problem: the server is no longer the unit

openEuler’s keynote slide describes the shift as moving “beyond the box,” from a single host to a SuperPoD. A SuperPoD is a tightly interconnected system where compute, memory, and accelerators across many nodes are linked and expected to work as one pool of resources.

That creates trouble the classic OS was never designed for. Memory you need may sit on another node, a fault on one machine can ripple into others, and moving data between hosts and accelerators becomes a bottleneck. And somebody has to manage the whole thing.

Hu grouped openEuler’s goals for this into three buckets: ease of use, reliability, and performance.

SuperPoD OS: making a rack look like a server

The ease-of-use goal is ambitious. openEuler wants runtimes and SDKs that work out of the box on SuperPoD hardware, and system administration that is assisted by an agent, so that you can manage a SuperPoD “like a single server.”

Reliability is of upmost importance here. According to Hu, openEuler can notify other nodes of a node failure with a latency of 500 ms or less, and can notify individual threads when shared memory develops a fault. It also aims to isolate faults so they don’t spread across processes on the same host or across nodes. There’s also “fault storm suppression,” a fast response to remote memory faults so that a flood of SEA errors doesn’t hang the system.

On performance, the Hu’s keynote cites two figures. UMDK, which openEuler describes as a unified heterogeneous interconnect infrastructure for SuperPoDs, cuts RPC latency by 20%. An asynchronous pipeline plus unified memory addressing cuts RH2D (Remote Host-to-Device) latency in KV cache operations by 20%.

All of this sits on UnifiedBus, a hardware interconnect protocol in the same family as NVLink, RDMA, and CXL. openEuler’s architecture slides show two layers built on top of it. The UB OS Component adds device management, memory pooling, inter-node communication, and virtualization to existing OS components. The UB Service Core adds higher-level services (memory, communication, I/O, a resource engine, virtualization, serverless, and a compiler and runtime).

The part I find most practical is how applications reach this. General-purpose apps keep using the standard POSIX API with transparent calls, while AI applications can use the UB Service Core API directly. If an app needs a memory pool, the UBS Engine finds which servers can spare memory, exports it from them, and imports it into the local machine.

We covered the UnifiedBus foundations in more depth earlier if you want the background.

Where mainline Linux stands

openEuler isn’t alone. Mainline Linux has been working on the memory side of the same problem for a few years, mostly through CXL, an open interconnect standard that lets servers attach or share memory beyond what sits on the motherboard.

The idea is to present far memory as just another NUMA (Non-Uniform Memory Access) node, so most applications don’t need to change.

That’s roughly the philosophy behind openEuler’s transparent POSIX path. The difference is scope. Mainline mostly deals with extra memory attached to one host, while SuperPoD OS tries to coordinate memory, devices, and faults across many hosts at once, on a Huawei-originated interconnect rather than a vendor-neutral standard for now.

Agentic Scaling: an OS for workloads that think in loops

The second half of the keynote moves from hardware to how AI itself is scaling. Hu’s slide traced three phases. First came “big is better,” where intelligence is fixed during pre-training. Then came test-time scaling, where models get smarter through post-training and spending more compute at inference time. The third phase is Agentic Scaling: building new system architecture around the way agents actually behave, while keeping costs under control.

The pitch is aimed squarely at open-weight models (models like DeepSeek, Qwen, and Llama, whose weights you can download and run yourself). openEuler’s argument is that this ecosystem won’t reach the frontier by chasing raw model size. Instead, it should use the control you get from running models locally to build intelligence at the system level.

Here’s what it means. An agent doesn’t just call a model once. It runs tools, executes generated code, keeps memory across long sessions, and spawns many short-lived tasks in parallel. Each of those is an OS problem: isolation, startup time, memory management, and recovery.

openEuler’s agentic infrastructure slides tackle three of them.

Sandboxes. Agents running code need isolated, disposable environments. openEuler’s sandbox stack works with Firecracker, StratoVirt, gVisor, and Cloud Hypervisor, and is compatible with Kubernetes and E2B APIs. Using prewarmed pools and snapshot recovery, the project claims cold starts down to 20 ms (a 70% to 95% reduction), over 2,000 concurrent sandboxes, and task recovery times cut by more than 50%.

KV cache. The KV cache (the model’s short-term working memory for a conversation) grows fast with long contexts and many users. openEuler’s approach spreads it over four tiers: HBM on the accelerator, local DRAM, a shared DRAM pool across nodes via UnifiedBus, and SSD or object storage for cold data. Combined with a global index that lets one instance reuse cache built by another, the project claims a 30% to 70% drop in time to first token and 1.5x to 3x higher throughput.

Agent memory. For long-term agent memory, openEuler showed oGMemory, built on the openGauss database with vector, full-text, and graph search. The slide claims it halves token overhead and improves task completion by 20%.

What this means for Linux

I think the most important takeaway is that the definition of “the machine” an OS manages is changing, and openEuler is one of the few distros building for that openly.

There’s a fair caveat, though. UnifiedBus and the TaiShan and Atlas hardware platforms are closely associated with Huawei’s technology ecosystem, and much of the SuperPoD stack is optimized for these platforms.

The real test is how much of this work flows upstream into mainline Linux and plays well with vendor-neutral standards like CXL, rather than staying an openEuler-specific feature. Given that openEuler already counts itself among the top contributors to the Linux kernel, that’s the thing worth watching.

Either way, the questions Hu raised (how an OS handles memory it doesn’t physically own, faults it didn’t cause, and workloads that spawn themselves) are ones every Linux distribution will have to answer soon.