Published by Zhongxin Data · Data Center Interconnect Engineering Team · 11 September 2026

Memory has become the most expensive, most stranded resource in the modern AI rack. CXL 3.0 and 3.1 turn DRAM from a per-server captive asset into a shared, fabric-attached tier that an operating system or runtime can reason about. This guide explains what CXL 3.x actually changes, where it pays back first, and how Zhongxin Data builds the PCIe, NVMe-oF and switching fabric underneath it.

Why CXL matters in 2026

The AI/HPC compute roadmaps from NVIDIA, AMD and Intel all share the same shape: more FLOPS per accelerator, more HBM per package, more NUMA domains per server, more GPUs per rack — and not enough DRAM and SSD capacity per accelerator. CXL (Compute Express Link) is the first industry-standard coherent interconnect that lets the host CPU coherently access memory that does not sit on the local DIMM slots.

CXL 3.0 (released August 2022, in silicon from 2024) added memory pooling, memory sharing, and a 64-host coherent fabric. CXL 3.1 (June 2025) tightened the fabric, added trusted memory protection, port-based routing and standardized CXL switch class devices. Together they make it possible to:

  • Pool tens of TB of DDR5 across a rack behind one or two CXL switches
  • Share a single memory page between VMs, containers or accelerators
  • Build tiered memory hierarchies (HBM → local DRAM → pooled DRAM → CXL-NVMe) without rewriting the application
  • Hot-add memory capacity to a running host, similar to how SAN storage is added

CXL 1.1 / 2.0 vs 3.0 / 3.1 — what actually changed

Feature CXL 1.1 / 2.0 CXL 3.0 CXL 3.1
Topologies Host-to-device only Host-to-device, pool, fabric Same + trusted fabric, port routing
Hosts sharing one device Not supported Up to 64 hosts via fabric manager Same + dynamic binding
Memory sharing (coherence) Limited (1.1) / 2.0 multi-host Full multi-host coherency Same + accelerator coherence hints
Link rate (PCIe physical) PCIe 5.0 ×16 (64 GB/s) PCIe 5.0 ×16, optional PCIe 6.0 PCIe 6.0 standard, 256 GB/s ×16 port
Security IDE (Integrity & Data Encryption) Same + CMA/SPDM Trusted Memory Protection (TMP), port authentication
Software stack maturity (2026) Mature for accelerators Linux 6.8+ stable for type-3 pooling Linux 6.10+, switch class drivers emerging

Three numbers to remember: 64 GB/s per PCIe 5.0 ×16 CXL port, 256 GB/s per PCIe 6.0 ×16 port, and ~150–250 ns pooled-memory access latency versus ~80–90 ns for local DDR5. That last number is the one design teams fixate on, because it decides whether a workload can tolerate a memory-pool tier.

The three CXL use-cases that pay back in 2026

1. Memory pooling for memory-bound analytics

In-memory databases (Redis, SAP HANA, Aerospike), large-language-model inference where KV-cache spills out of HBM, and graph analytics are all memory-bound, not compute-bound. CXL 3.0 type-3 memory expanders let a 1-socket host see 4 TB or 8 TB of “local” memory by attaching one or two pooled-memory nodes through a CXL switch. We have observed 35–55% cost-per-GB reduction versus densest DDR5 configurations and zero application code changes for workloads that already over-subscribe DRAM.

2. Memory sharing between accelerators

CXL 3.0 fabric coherency means two hosts can map the same physical page. The practical case in 2026 is sharing a large embedding table or KV-cache between a training GPU host and an inference CPU host — the data lives once in the pool, both hosts coherently access it, and consistency is enforced by the CXL coherency engine rather than by application code.

3. Tiered memory: HBM → DRAM → CXL → NVMe-oF

The pattern that has gained the most engineering traction is a four-tier hierarchy:

  • Tier 0 — HBM on the GPU package (40–80 GB, ~3 TB/s)
  • Tier 1 — Local DDR5 RDIMM (512 GB – 2 TB per host, ~700 GB/s)
  • Tier 2 — CXL-pooled DDR5 across the rack (4–32 TB, ~250 ns)
  • Tier 3 — CXL-attached NVMe or NVMe-oF (tens to hundreds of TB, microseconds)

Linux 6.10’s tiered-memory demotion/promotion hot paths place “hot” pages in tier 0/1 and “warm” pages in tier 2/3 transparently. For LLM inference with long context, we typically see 20–30% of pages migrate to tier 2 within the first hour, freeing DRAM for KV-cache growth without operator intervention.

Under the hood: how the fabric is built

A CXL 3.0 fabric in production today looks like this:

  • 2–16 hosts in a rack, each with a CXL-capable CPU (Intel Granite Rapids / Sierra Forest, AMD Turin / EPYC 9005)
  • 1–2 CXL switches (XConn XC80896, Astera Labs Aries, Microchip P0X) with 16–64 ports each
  • Memory pooling nodes with 8–24 DDR5 channels of DDR5-5600 or DDR5-6400 RDIMM, presented as one or more CXL type-3 devices
  • Optional NVMe tier behind the same CXL switch via CXL-NVMe (CXL 3.1) or via a sibling PCIe switch carrying NVMe-oF to a separate Ethernet/InfiniBand network

For larger deployments the CXL fabric is layered on top of the data-center network: pooled-memory nodes act as NVMe-oF targets on a 100/200/400 GbE or NDR InfiniBand network so remote racks can coherently consume pooled memory. This is the early shape of “rack-scale memory” — the topic we covered separately in our Rack-Scale Power & Cooling and PCIe Gen5/Gen6 Network Impact deep-dives.

Latency reality check: when does CXL win, when does it lose?

Workload Local DRAM ns CXL-pooled DRAM ns Verdict
In-memory KV lookup (Redis GET) ~120 ~280 Use CXL for warm tier, local for hot
Larger-than-memory sort baseline +8–12% CXL wins on cost-per-GB
LLM KV-cache spill baseline +5–9% CXL wins — access pattern is sequential
Random OLTP index walk baseline +18–25% Stick with local DRAM
HPC sparse-matrix multiplication baseline +2–6% CXL wins if dataset exceeds DRAM

The rule of thumb we use with customers: if the dataset fits in local DRAM and the access pattern is random, stay local. If the dataset is 2×–10× local DRAM, or the access pattern is sequential / streaming, CXL pays back almost immediately because you avoid the much larger cost of falling out to NVMe.

What to buy first if you are building a CXL pilot in 2026

Three line items on a typical 8-host CXL memory pool pilot:

  1. 2 × CXL switches (redundant) — 32-port PCIe 5.0 / CXL 3.0 class, managed fabric manager
  2. 2–4 × memory pooling nodes — each 1U, 24 × DDR5-6400 RDIMM, Astera Labs or Samsung controller, presented as one type-3 device
  3. CXL-aware PCIe retimers / cabled backplane — to extend CXL beyond a 21-inch motherboard to a 2U or 4U pooled-memory sled

Zhongxin Data supplies the network fabric and the host-adapter / retimer layers that sit next to CXL: NVIDIA/Mellanox ConnectX-7/8 BlueField-3 SuperNICs for NVMe-oF offload, Broadcom PEX89048 PCIe 5.0 switches for fan-out, and Microchip/Samtec cabled PCIe backplanes for pooled-memory sleds.

Deployment gotchas we have hit in the field

  • OS support — RHEL 9.4+, Ubuntu 24.04 LTS, and SLES 15 SP6 ship with CXL 3.0 type-3 hotplug. RHEL 8 and older kernels see the device but cannot hot-add memory.
  • BIOS defaults — many server vendors still ship CXL ports in “disabled” state. Confirm PCIe Bifurcation = x4x4x4x4 and CXL Port Enable = Auto/Enabled.
  • Memory interleaving — disable interleaving across pooled nodes; interleave only inside one pooled-memory sled. Otherwise NUMA effects tank performance.
  • Fabric manager licensing — the CXL fabric manager is licensed per switch port in 2026. Budget for it as a separate line item.
  • Power and cooling — a single 24-DIMM pooled-memory sled draws 350–450 W and needs front-to-back airflow compatible with 100 kW+ AI rack densities (see our rack-scale cooling guide).

Frequently asked questions

Does CXL 3.0 work with NVIDIA GPUs today?

Direct coherent access between an x86 host and an NVIDIA GPU over CXL is not yet in production. What is in production is CXL-pooled memory feeding the CPU side of a GPU server, with GPUDirect RDMA over NVLink or InfiniBand carrying accelerator-side traffic. We cover this hybrid in our GPU-Direct RDMA article.

How does CXL compare with NVMe-oF for “remote memory”?

NVMe-oF gives you block-level remote storage at 10–30 µs. CXL 3.0 gives you byte-level coherent memory at 150–250 ns. That is two orders of magnitude faster and a fundamentally different programming model. Use CXL when the workload is memory-bound and you want zero-copy access; use NVMe-oF when the dataset is genuinely cold or huge.

Is CXL a replacement for more DRAM?

No — it is a complement. Local DRAM is still the fastest tier. CXL adds a second tier that is one order of magnitude slower but 2–4× cheaper per GB, and lets you decouple capacity from CPU socket count.

What is the cheapest way to start a CXL pilot?

A single host with a CXL 3.0 type-3 add-in card (Astera Labs A1000 or Samsung CXL Memory Module) plugged into a PCIe 5.0 ×16 slot, plus a Linux 6.10+ kernel with cxl_test enabled, is enough to validate an application against pooled memory without buying a switch. From there, add a CXL switch and a pooling sled.

How does CXL 3.1’s “trusted memory protection” differ from CXL IDE?

CXL IDE (1.1/2.0) protects the link between host and device with AES-XTS inline encryption. CXL 3.1 TMP extends that with per-page memory encryption keys and per-port authentication, so a compromised pooled-memory sled cannot read another tenant’s pages even at the fabric level.

PCIe 6.0 and the physical layer underneath CXL 3.1

CXL 3.1 standardises on a PCIe 6.0 physical layer, which is itself a major shift. PCIe 6.0 introduces PAM-4 signalling (4-level pulse amplitude modulation) at 64 GT/s, replacing the NRZ scheme used in PCIe 5.0. PAM-4 doubles the bits per UI but tightens the link budget: pre-emphasis, equalisation and forward-error correction (FLIT-level FEC) all become mandatory. In practical terms this means that every CXL 3.1 retimer, CXL switch port and pooled-memory sled must support PAM-4, FEC and the new FLIT framing. The upside is 256 GB/s of bidirectional bandwidth on a ×16 slot, which is enough to carry aggregated CXL traffic for two or three pooled-memory sleds and the local NVMe tier without becoming the bottleneck.

The clocking model is also new. PCIe 6.0 / CXL 3.1 moves from the PCIe 5.0 spread-spectrum clocking on the host to a more disciplined reference-clock architecture driven by the CXL switch. For pooled-memory topologies this matters: the switch becomes the timing master for all attached devices, simplifying cabling and enabling longer reach (up to ~2 metres of PCB + cable) without the jitter penalties that plagued PCIe 5.0 reference-clock designs.

How Zhongxin Data fits into your CXL deployment

We do not sell the CXL switches or the pooling controllers themselves — those are Astera, XConn, Samsung and Microchip territory. What we supply is everything that surrounds the CXL fabric:

  • NVIDIA/Mellanox ConnectX-7 / ConnectX-8 / BlueField-3 SuperNICs for the NVMe-oF and RDMA planes that complement CXL
  • Broadcom PEX89048 / PEX90144 PCIe 5.0/6.0 switches for fan-out inside the pooled-memory sled
  • Mellanox Quantum-2 and Spectrum-4 200/400/800 GbE and NDR switches for the rack-scale fabric
  • QSFP-DD800 / OSFP 800G optical transceivers and MPO-16 cabling for the CXL-aware fabric extensions
  • Broadcom MegaRAID 9540 / 9560 controllers for the cold-storage tier below CXL

Browse the full zhongxindata.hk collections or contact our interconnect engineering team on WhatsApp +86 13068616914 to scope a CXL pilot around your specific workload.

2027 outlook. CXL 3.1 silicon is sampling from Samsung, Micron and SK hynix in 2026; volume pooled-memory sleds land in 2027. Combined with NVIDIA’s BlueField-3 SuperNIC and Broadcom’s PEX90144 PCIe 6.0 switches, the rack of 2027 will look more like a fabric-attached memory and storage grid than a collection of isolated 1U servers. Customers who pilot CXL memory pooling in 2026 will be the first to retire expensive over-provisioned DRAM configurations and to ride the same wave that moved enterprise storage from direct-attached to fabric-attached fifteen years ago.

About Zhongxin Data — Zhongxin Data (zhongxindata.hk) is an independent supplier of enterprise and data-center network hardware. We stock used NVIDIA Mellanox InfiniBand and Ethernet adapters, Broadcom RAID controllers, Dell/HPE/Lenovo server components, and the optics and cabling that connect them.