Four ways memory can reach a CPU, with measured latency for each.
Expansion is already in production. Pooling is reaching real hardware, but its economics are still unsettled.
A database server maxing out its 512 GB cannot directly borrow unused DIMMs from the machine one rack slot over. The neighbor can serve data over the network, and workloads can be migrated or distributed in software, but that DRAM is not part of the first server’s coherent memory address space.
Within a multisocket server, CPUs reach memory attached to other sockets through the socket interconnect. Across separate servers, conventional DIMMs stay isolated behind their own systems.
For thirty years that was an accounting annoyance. With DRAM prices where they are and AI workloads consuming memory faster than anything before them, it has become a line item nobody can ignore.
Compute Express Link — CXL — is the industry’s answer, and it is more specific than the pitch suggests. It does not make one server’s DIMMs visible to its neighbor. It adds a new class of memory device that one or several hosts can draw from. Seven years into its development, that distinction is where most of the confusion lives.
Why this is suddenly worth paying attention to
Servers get sized for their worst day. An operator picks a configuration that covers peak load, then watches most of that capacity sit unused for the other 23 hours.
Meta put a number on the waste. Across its fleet of millions of machines, roughly 40% of servers are memory-capacity bound — its measurement is 43.7% — meaning they run out of RAM before they run out of cores, network, or storage. The CPUs in those machines are stranded behind a resource that ran out first.
Two things turned that from wasteful into urgent. Memory is now one of the largest single costs in a server build. And AI inference added a second memory problem on top of the fixed cost of model weights: the KV cache, the working state a model accumulates while generating, which grows roughly with sequence length and with how many requests run concurrently. Long-running agentic workflows amplify it by holding context alive across many steps, though eviction, compression, and offload all change the real footprint. Weights still set the floor; the cache is what makes the ceiling unpredictable.
So what is CXL?
CXL is a cache-coherent interconnect that reuses PCIe’s physical and electrical infrastructure. Its memory sub-protocol, CXL.mem, lets a host map a CXL device’s memory into its own physical address space and reach it with ordinary CPU load and store instructions.
The devices themselves take unremarkable forms — add-in cards, EDSFF modules, mezzanine components, sometimes a cabled enclosure. What matters is not where they sit but how the CPU sees them.
Coherency is the piece conventional PCIe does not provide. CXL defines two coherent protocols: CXL.cache lets a capable device coherently access and cache host memory, and CXL.mem lets the host reach device-attached memory under defined coherence rules. For a Type-3 memory expander — the plain memory device, no accelerator logic — the host can cache data from the device while the platform maintains a consistent view of it.
PCIe can already expose device memory through memory-mapped I/O, and DMA engines move data efficiently. What PCIe does not offer is standardized coherent memory semantics: a device whose memory participates in the host’s memory model the way a DIMM does. That is the gap CXL fills.
The practical result: applications stop orchestrating explicit transfers for ordinary accesses. Firmware and the operating system still have real work to do — discovering the device, mapping it, exposing it as a NUMA node or a DAX device, and deciding which pages live where. Page placement across memory tiers remains an active, workload-dependent systems problem.
Why not simply put more RAM in the server?
The obvious question, and the answer is a stack of physical limits.
A CPU socket has a fixed number of memory channels. A motherboard has a fixed number of DIMM slots, constrained by trace routing and signal integrity — DDR5 is particularly fussy about how far its signals travel. Add slots and the memory runs slower. Populate every slot and the power and cooling budgets tighten. Core counts have also grown faster than channel counts, so capacity per unit of socket performance has been drifting down for years.
So a server has a ceiling set by the chassis rather than by what the workload wants.
When a workload exceeds it, data spills to storage, and that is where the numbers turn brutal. A 4K random read on Micron’s 7450 enterprise SSD has a median latency near 80 microseconds — 80,000 nanoseconds, against roughly 115 for a local DDR5 read. Falling off the memory cliff costs several hundred times, not a few percent.
CXL exists to put a step between those two, and to let capacity grow past what one board can hold.
Three different things, constantly confused
Most confusion about CXL comes from collapsing these into one idea. They are separate problems at very different stages of maturity.
Expansion. One host, additional CXL-attached memory as a second tier. The server sees more capacity than its slots allow, at higher latency than local DRAM. This is in production.
Pooling. Several hosts draw exclusive, dynamically assigned portions of a common body of CXL memory. Capacity gets allocated where it is needed and handed back when it is not. Each host owns its slice; nobody reads anybody else’s.
Sharing. Multiple hosts access the same memory region concurrently. CXL 3.0 defines optional mechanisms for keeping host copies coherent in hardware, but the multi-port CXL 2.0 devices in published evaluations do not provide cross-host coherency — the Octopus authors note that the CXL 3.0 Back-Invalidate mechanism “requires significant hardware changes on both processors and devices.” Software-managed shared buffers work today. Coherent sharing is a specification capability, not a deployed one.
A common shortcut treats pooling as synonymous with switched fabrics. It isn’t. A multi-port device — one CXL controller with several host-facing ports — pools memory across the hosts plugged into it with no switch anywhere in the path. Two-port parts are available today from several vendors, with four-port prototypes in circulation. Switches scale further, but they are one topology rather than the definition of pooling.
Is it fast enough?
Memory is latency-sensitive in a way storage is not, so this is the question everything turns on.
One of the most complete public measurement sets comes from Octopus, an NSDI ’26 paper from Microsoft Azure and Columbia researchers who built a three-server CXL pod and measured every topology on real silicon. The figures below are P50 load-to-use latency for random 64-byte cache-line reads, not whole-application latency.
| Path to memory | P50 read latency |
|---|---|
| Local DDR5 | ~115 ns |
| CXL expansion device | 230–270 ns |
| Multi-port CXL device | 260–300 ns |
| Through a CXL switch | 490–600 ns |
| Another server, via RDMA | ~3,550 ns |
Two things fall out of that table. Every CXL option sits far closer to local DRAM than to anything across the network, let alone to the SSD a workload would otherwise spill onto. And the switch is not free — the paper attributes at least 220 ns to the switch itself, because every flit round-trip gets deserialized and reserialized twice.
Meta’s production numbers agree from a different direction: ≈130 ns idle for local DDR5 against ≈250 ns for CXL-attached DDR4 in the same machine, and 234 ns against 372 ns under load at 60% bandwidth utilization.
There is a catch most coverage flattens, though, and it is worth knowing before reading any CXL benchmark. Researchers at MICRO 2023 tested three CXL memory devices built to the same specification, each measured against memory on a remote CPU socket.
| Device | Implementation | Load latency vs remote DDR5 |
|---|---|---|
| CXL-A | Hardened ASIC, DDR5-4800 | +35% |
| CXL-B | Hardened ASIC, DDR4-2400 | ≈2× |
| CXL-C | FPGA soft IP, DDR4-3200 | ≈3× |
Same protocol, same compliance claim, and a spread wide enough that “CXL latency” means little unless the controller is named alongside it. The worst performer is the FPGA-based part, and FPGAs are what a great deal of early evaluation hardware used — so a fair amount of CXL’s early reputation was earned by prototype silicon rather than by the standard.
Meta reached the good end through unglamorous engineering: configuring the controller IP for low latency, minimizing clock-domain crossings inside the chip, tight floorplanning of the latency-critical paths.
Where CXL actually stands today
Here is where the popular narrative and the deployed reality part ways.
| Spec version | Major additions | Most mature documented deployment |
|---|---|---|
| 2.0 (Nov 2020) | Switching, pooling | Direct expansion, at hyperscale |
| 3.0 (Aug 2022) | Multi-level fabrics, sharing | Prototypes and early silicon |
| 3.1 (Nov 2023) | Fabric enhancements, peer-to-peer | Prototypes and early silicon |
| 3.2 (Dec 2024) | Monitoring, management, security | Pre-release silicon |
| 4.0 (Nov 2025) | 128 GT/s, bundled ports, RAS | Specification and IP stage |
The latest published specification is CXL 4.0. The deployment with the most complete public results uses the oldest row on that list, in its simplest form: a plain memory expander, one host, no pooling.
That deployment is worth respecting. Meta’s Vistara ASIC lets DDR4 modules pulled from decommissioned servers act as a second memory tier inside new DDR5-only machines — 768 GB of local DDR5-6400 alongside 256 GB of reclaimed DDR4-2400 per node. Up to a 25% reduction in server count for disaggregated ML inference, and 29% lower average latency for distributed caches. The Octopus authors note that Azure also runs CXL expansion in production, though without a comparable published workload study.
One detail makes the gap concrete. CXL 4.0’s headline feature is doubled bandwidth, and Meta reports its production operating point at less than 10% CXL bandwidth utilization. The constraint the newest spec relieves is not the one the best-documented deployment was hitting.
Meta’s own paper asks it plainly: why has large-scale CXL deployment not been reported, six years after the standard appeared?
Why switched pooling is the hard part
Pooling through a switch scales furthest, and it has taken longest. The reason is more interesting than “switches add latency.” It traces back to PCIe, and it is a rule about ordering rather than about speed.
PCIe enforces transaction ordering across the entire memory space — a guarantee that operations complete in a predictable sequence no matter which device issued them. As the CXL specification’s own technical leadership explains, that global requirement is precisely why PCIe, and early CXL along with it, “must follow the tree topology.” A tree is the only shape in which the guarantee holds.
The consequences are what kept large fabrics theoretical. Every memory range is decoded inside exactly one host’s address map. Two memory devices sitting side by side must route up through the host to reach each other. No range can be shared across hosts in hardware, because the map defining it exists in only one host’s world.
CXL 3.0 relaxed those ordering rules and introduced port-based routing. Instead of routing by address, the first switch port stamps each message with a 12-bit device ID — 4,096 possible endpoints — and interior switches forward on that ID alone, never decoding addresses at all. The specification authors describe this as improving scalability while cutting the latency and cost of interior switches.
The postal version: address routing needs the full street directory at every sorting office. ID routing needs only the ZIP code.
Hierarchy-based routing versus port-based routing in CXL
Silicon has trailed the spec by years. Panmnesia, a Korean chip designer, presented a peer-reviewed paper at ISCA 2026 on a port-based-routing switch, reporting stable performance at 64 nodes and arguing that early CXL controllers inherited PCIe habits — a separate, independently timed buffer at each protocol layer — that cost latency for no benefit. That silicon is sampling to early partners rather than shipping. Marvell’s CXL 2.0 switch is in production, with its 3.0 part expected to begin sampling in calendar Q3 2026.
The argument about whether pooling is worth it
Three Google researchers published a direct case against CXL memory pooling at HotNets ’23, and it remains the sharpest skeptical account available.
Their cost arithmetic says the switching hardware eats the RAM savings unless the pool is large — even with free pool memory, a standard 4 GB-per-core shape needs roughly 24 nodes just to break even. Their utilization analysis found no gain at all on a Google trace at real VM sizes, and at most 1% even with virtual machines inflated 16×.
The architectural objection is sharper still. Disaggregation worked for disk because seek times are measured in milliseconds, so a network hop vanishes into the noise. Memory sits at the opposite end of that spectrum. Architecture has spent decades moving memory closer to compute, because locality is the entire point, and six feet of cable costs about 12 nanoseconds each way.
The Octopus authors reach a partly different answer, and the disagreement is the useful part. Their cost model finds that switch-based pods raise total server cost even after counting pooling savings, which agrees with the Google paper. But sparse multi-port topologies come out at a net 3% to 5.4% server cost reduction, and their prototype’s communication latency is 2.4× lower than through a switch and 3.2× lower than in-rack RDMA. The conclusion is not that pooling doesn’t pay — it is that the topology decides whether it pays.
Neither result contradicts Meta, whose deployment is single-host expansion rather than a pool. The three papers are answering three different questions.
What this means for hardware already in racks
The most interesting number in Meta’s paper is not a latency figure. It is 0.13 — the cost per gigabyte of its CXL tier relative to local DRAM.
That ratio holds because the DIMMs were already bought. Meta’s reasoning is that memory has a useful lifetime of 10 to 14 years while servers last 5 to 7, so retiring the modules with the chassis throws away most of their life. The custom controller exists largely so already-depreciated DDR4 can keep working in machines that would otherwise refuse it.
Few organizations will build an ASIC to reuse their own DIMMs. The observation underneath still travels: memory outlives the server it shipped in, and its value is independent of that chassis. That applies most directly to the DDR4 modules coming out of machines retired now, which have years of service left, and increasingly to DDR5 as the first DDR5-era servers reach end of lease.
Modules pulled from decommissioned machines can be sold as server memory rather than scrapped with the box — the small-scale version of the argument Meta made in a peer-reviewed venue. For a full rack decommissioning, where memory is one line among many, the same logic covers bulk hardware lots. Which modules hold value, and for how long, is covered in the DDR4 versus DDR5 resale breakdown.
Common questions
Does CXL replace HBM or local DDR5? No. It adds a tier between local DRAM and storage. Hot data stays local; the CXL tier holds data too large for local memory but too active for disk. The high-bandwidth flash explainer covers how the tiers below DRAM are shifting.
Do current CPUs support CXL? Recent Intel and AMD server processors speak the protocol — Intel Xeon 6 production platforms carry up to 64 CXL lanes per socket. Whether the fabric features from 3.0 onward work depends on the CPU, the switch, the firmware, and the operating system. All four have to line up, which is much of why deployment lags the spec.
Does an ordinary business need to plan for this? For most business-server purchases in 2026, CXL is not yet a selection criterion. It is already relevant for unusually memory-intensive systems and for anyone evaluating memory expansion. And it shapes what happens to memory after a refresh, which is where it touches the widest audience.
What would settle the pooling argument? A detailed operator report on an at-scale multi-host CXL pool, covering workload performance, reliability, power, operational overhead, and total cost. Real-hardware prototypes and peer-reviewed measurements now exist for every topology. What remains publicly unavailable is an account of running one at scale.
The next specification release alone will not settle it. The decisive evidence will be an operator willing to publish the complete technical and economic picture of a multi-host CXL memory system.