In a modern server there are two resources growing at different speeds. Cores multiply with every generation; memory bandwidth per core does not. That mismatch is the well-known memory wall: the processor spends more and more time waiting for data. And there is a second, more expensive problem: memory is nailed to the socket. Each CPU can only use the modules sitting in front of it, even if the server next door is running with half its RAM empty. CXL was born to break that bond, and its fourth version is already published: in November 2025 the consortium released the CXL 4.0 specification, which doubles bandwidth to 128 GT/s without adding latency. The real question is what it means, in practice, for several CPUs and GPUs to look at the same memory at once.
One protocol, three different conversations
Compute Express Link is not a brand-new bus invented from scratch: it is a coherency layer that travels over the same physical link as PCI Express. That explains much of its success. A CXL device sits in a normal PCIe slot and uses PCIe’s training, signalling and error control; what changes is what is said on top. The specification defines three protocols a device can implement depending on what it needs:
- CXL.io: the equivalent of ordinary PCIe. Device discovery, register configuration, BAR access, interrupts and DMA. Every CXL device needs it.
- CXL.cache: the device can keep lines of the host‘s memory in its own cache. The key word is coherency: if the CPU modifies a datum, the accelerator’s copy is invalidated or updated without anyone synchronising by hand.
- CXL.mem: the processor issues loads and stores directly against memory that physically lives in the device. To software it is ordinary memory, reachable with the usual instructions, except that it arrives over a serial link.
Three device types follow from that. Type 1 only caches host memory (an accelerator with no memory of its own). Type 2 adds coherent local memory and is the natural slot for GPUs and FPGAs. Type 3 is the simplest and the first to reach the market: a memory module, with no compute, that the CPU sees as an extension of its own address space. All three coexist, and the standard mandates backward compatibility.
The hard part is not the cable, it is the directory
If the challenge were only moving bytes fast, PCIe would already do. The problem is coherency. When a GPU caches a line of processor memory and the processor then decides to write to it, somebody has to know who holds copies of that line in order to invalidate them. In a CXL system that job falls to the processor’s home agent, which keeps a directory with the state of every line and a snoop filter summarising which devices may have it cached. It is the same kind of structure classic multiprocessors use, moved onto a serial link with PCIe’s round-trip latency.
In Type 2 devices a nuance appears that engineers call bias. The accelerator’s local memory can sit in device bias, where the accelerator itself uses it without consulting the host because it knows there are no external copies; or in host bias, where the processor treats it as its own and any device access goes through the coherency protocol. Switching from one mode to the other means invalidating and flushing caches: it is quick, but not free. That round trip is one reason CXL complements a GPU’s HBM rather than replacing it.
From PCIe 5.0 to 128 GT/s
The standard’s evolution is tied to the physical link. CXL 1.1 leaned on PCIe 5.0, at 32 GT/s per lane. CXL 3.x jumped to PCIe 6.0 and PAM4 encoding, which carries two bits per symbol instead of one: 64 GT/s and a 256-byte frame (flit) that cuts header overhead. CXL 4.0 moves to PCIe 7.0 and 128 GT/s. Translated into usable bytes over an x16 connector: about 63 GB/s in the first generation, about 121 GB/s in the third and about 242 GB/s in the fourth. The honest comparison is against local memory: a DDR5 channel at 4,800 MT/s delivers roughly 38 GB/s, so an x16 CXL 4.0 link has more raw bandwidth than several DRAM channels together.
Version 4.0 also adds details aimed at the real wiring of a rack: native two-lane (x2) ports to multiply the fan-out of connections, up to four retimers to extend signal reach, and the ability to bundle ports (bundled ports) between the host and an accelerator to add bandwidth. It also improves reliability, availability and serviceability (RAS): error logging, isolation of faulty lines and memory replacement without powering the server down. It keeps the 256-byte frame and compatibility with everything before it, which is no small feat in a standard that has gone through five generations in six years.
The real price: latency
A local DRAM access takes on the order of 80 to 100 nanoseconds. A Type 3 CXL memory access, according to figures published by vendors and by several data centres, lands between 170 and 300 nanoseconds. The difference looks small until it is multiplied by millions of accesses: for workloads that miss cache often, such as a random walk through a large index, that overhead shows. For workloads with locality, or for data consulted only occasionally, it is perfectly acceptable.
That is why the most immediate application is not replacing RAM but sorting it by temperature. Linux exposes CXL memory as one more NUMA node, with its own distance from the socket, and the scheduler can migrate pages between the local and the remote node. CXL 3.2 added hot page monitoring, a mechanism by which the device itself reports which pages are being used most, so the hypervisor or the operating system can decide what deserves to be close. That builds a hierarchy of three or four levels: HBM on the GPU, local DDR5, CXL DDR5 and, underneath, NVMe storage.
From a lone module to a shared pool
The first products to arrive were E3.S modules with DRAM and a CXL controller: Micron sells the CZ120 in 128 and 256 GB versions, and SK hynix has its CMM-DDR5 family at 96 and 128 GB, with a 256 GB version on CXL 3.2 announced in 2026. They are pure Type 3: they expand one specific server’s capacity without touching the motherboard.
The next step is the one that justifies the technology’s name. CXL 2.0 introduced the single-level switch and pooling: several hosts share a set of modules and a fabric manager assigns each slice to the server that needs it. The module is split into multiple logical devices (up to 16 on one module) and each is assigned to a different host. CXL 3.0 went further with multi-level switching and true sharing: several hosts can read and write the same region coherently, something that previously required purpose-built software. That is the basis of shared-memory demonstrations for inference: in July 2026 Samsung showed a 1 TB pool built from CMM-D modules and a CXL switch that, attached to an eight-GPU system, held around 92% of conventional DRAM performance while hosting KV caches that did not fit in local memory.
The idea behind it is powerful: if memory stops belonging to a processor, it stops being a resource bought per server and becomes one assigned the way network bandwidth is assigned. The large cloud providers are already studying it for their inference farms, where one GPU can run short of VRAM while another sits idle.
What still holds adoption back
The first obstacle is software. An application written for local memory does not know there is now a node with higher latency; if the operating system places its pages in the wrong spot, performance collapses. It takes node-aware allocation (numactl, mbind, tiering policies) and, inside virtual machines, a hypervisor that knows how to pass that topology to the guest. The second is the cost and complexity of the fabric: a CXL switch plus its manager is not cheap, and it only pays off in large farms. The third is security: memory shared between hosts requires link encryption (IDE) and trust protocols such as TSP, because a shared module is a side channel waiting to happen.
And there is the temptation to sell it as an instant revolution. Reality is duller and more useful: CXL will not make a two-socket server behave like an eight-socket one, but it does let you stop wasting memory. In a data centre where 20 or 30% of RAM sits unused on every machine, aggregating it and handing it out is a saving measured in megawatts. The 4.0 specification, with its 128 GT/s and its backward compatibility, is the infrastructure for that to stop being a laboratory experiment.
The question is no longer whether memory will be decoupled from the processor. The modules are in the catalogue, the switches are on sale and the standard is on its fourth generation. The question is whether software — operating systems, hypervisors, databases, inference engines — will learn to treat memory as what it now is: a networked resource at different distances, rather than a block bolted to the socket.
