openEuler Reimagines Linux for AI Clusters as Unified Machines

Throughout its history, Linux has operated on a foundational premise: a single machine contains processors, memory, and peripherals that the kernel orchestrates. While clusters have existed for decades, they have typically remained the concern of higher-level software layers—schedulers, orchestrators, and distributed computing frameworks—rather than the operating system itself.

Modern artificial intelligence workloads demand something different. Contemporary training and inference systems interconnect dozens of CPUs, NPUs, GPUs, and memory resources so intimately that they function more like one enormous computer than a collection of independent machines. The emergence of AI agents compounds this challenge: these systems not only execute models but also instantiate tools, isolated environments, and persistent sessions dynamically.

Xinwei Hu, Chairman of the openEuler Technical Committee, presented this vision at Open Source Summit Europe 2026 in Prague, detailing how openEuler is reshaping Linux to accommodate agentic scaling.

The problem: the server is no longer the unit

openEuler frames the transformation as progressing "beyond the box," transitioning from individual hosts to what it calls a SuperPoD—a densely connected infrastructure where compute, memory, and accelerators spanning multiple nodes are unified into a single resource pool.

This architecture introduces challenges that conventional operating systems never anticipated. Required memory may reside on a distant node; a failure on one machine can cascade to others; transferring data between hosts and accelerators becomes a critical bottleneck. Orchestrating this heterogeneous system demands new approaches.

Hu organized openEuler's objectives into three categories: ease of use, reliability, and performance.

SuperPoD OS: making a rack look like a server

The ease-of-use objective represents a significant undertaking. openEuler aims to deliver runtimes and SDKs that function seamlessly on SuperPoD infrastructure, coupled with agent-assisted system administration that enables operators to manage a SuperPoD "like a single server."

Reliability stands as a paramount concern. Hu outlined that openEuler can alert other nodes to a node failure within 500 milliseconds or less, and can notify individual threads of faults in shared memory. The system also aims to contain faults so they remain isolated within a single host or do not propagate across nodes. Additionally, openEuler implements "fault storm suppression," which rapidly responds to remote memory faults to prevent cascading SEA errors from freezing the system.

Performance metrics presented in Hu's keynote demonstrate measurable improvements. UMDK, which openEuler describes as a unified heterogeneous interconnect infrastructure for SuperPoDs, reduces RPC latency by 20%. An asynchronous pipeline combined with unified memory addressing decreases RH2D (Remote Host-to-Device) latency in KV cache operations by 20%.

These capabilities rest upon UnifiedBus, a hardware interconnect protocol aligned with NVLink, RDMA, and CXL. openEuler's architecture incorporates two layers atop this foundation. The UB OS Component integrates device management, memory pooling, inter-node communication, and virtualization into existing OS functionality. The UB Service Core supplies higher-level capabilities including memory management, communication, I/O, a resource engine, virtualization, serverless execution, and compiler and runtime support.

The practical application path is particularly noteworthy. Conventional applications continue using the standard POSIX API with transparent function calls, whereas AI applications can directly access the UB Service Core API. When an application requires a memory pool, the UBS Engine identifies which servers possess spare capacity, exports memory from those systems, and imports it into the requesting machine.

Where mainline Linux stands

openEuler is not pursuing this direction in isolation. Mainline Linux has invested effort in addressing the memory dimension of this challenge over recent years, primarily through CXL, an open interconnect standard enabling servers to attach or share memory beyond onboard capacity.

The approach involves presenting remote memory as an additional NUMA (Non-Uniform Memory Access) node, allowing most applications to function without modification.

This philosophy parallels openEuler's transparent POSIX approach. The distinction lies in breadth. Mainline Linux primarily addresses supplementary memory connected to a single host, while SuperPoD OS orchestrates memory, devices, and faults across numerous hosts simultaneously, currently leveraging a Huawei-originated interconnect rather than a vendor-neutral standard.

Agentic Scaling: an OS for workloads that think in loops

The second portion of Hu's keynote shifted from hardware infrastructure to the evolution of AI workloads themselves. Hu's presentation outlined three successive phases. The initial phase emphasized "big is better," where model capabilities were determined during pre-training. The second phase introduced test-time scaling, enabling models to improve through post-training and increased inference-time computation. The third phase represents Agentic Scaling: constructing system architecture around agent behavior patterns while managing costs effectively.

This approach targets open-weight models—systems like DeepSeek, Qwen, and Llama whose weights are publicly available for local deployment. openEuler contends that this sector will not reach state-of-the-art performance by pursuing raw model scale alone. Instead, it should leverage the autonomy gained from local model execution to develop system-level intelligence.

The implications are substantial. An agent does not simply invoke a model once. It executes tools, runs generated code, maintains memory across extended sessions, and launches numerous short-lived parallel tasks. Each represents an operating system challenge: isolation, initialization latency, memory allocation, and fault recovery.

openEuler's agentic infrastructure addresses three of these concerns.

Sandboxes

Agents executing code require isolated, ephemeral environments. openEuler's sandbox implementation integrates with Firecracker, StratoVirt, gVisor, and Cloud Hypervisor, and maintains compatibility with Kubernetes and E2B APIs. Through prewarmed pools and snapshot-based recovery, the project achieves cold starts as low as 20 milliseconds (a 70% to 95% reduction), supports over 2,000 concurrent sandboxes, and reduces task recovery times by more than 50%.

KV cache

The KV cache—the model's immediate working memory during conversations—expands rapidly with extended contexts and multiple concurrent users. openEuler distributes this across four layers: HBM on the accelerator, local DRAM, a shared DRAM pool spanning nodes via UnifiedBus, and SSD or object storage for infrequently accessed data. Combined with a global index permitting one instance to leverage cache generated by another, the project reports a 30% to 70% reduction in time to first token and 1.5x to 3x improvement in throughput.

Agent memory

For persistent agent memory, openEuler introduced oGMemory, constructed on the openGauss database with vector, full-text, and graph search capabilities. According to the presentation, this approach reduces token overhead by half and increases task completion rates by 20%.

What this means for Linux

The most significant implication is that the definition of "the machine" managed by an operating system is undergoing transformation, and openEuler ranks among the few distributions openly engineering for this shift.

An important qualification exists, however. UnifiedBus and the TaiShan and Atlas hardware platforms maintain close ties to Huawei's technology ecosystem, and substantial portions of the SuperPoD stack are tuned for these specific platforms.

The critical question concerns how extensively this work integrates into mainline Linux and interoperates with vendor-neutral standards such as CXL, rather than remaining confined to openEuler-specific implementations. Given that openEuler already ranks among the leading contributors to the Linux kernel, this development warrants close attention.

Regardless, the fundamental questions Hu posed—how an OS manages memory it does not physically possess, handles faults it did not generate, and orchestrates workloads that create themselves—are challenges every Linux distribution will confront in the near term.