Published by Zhongxin Data | November 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).

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. Models listed on zhongxindata.hk are available used NVIDIA Mellanox InfiniBand and Ethernet adapters, Broadcom RAID controllers, Dell/HPE/Lenovo server components, and the optics and cabling that connect them.


What actually changed in CXL 3.0 and 3.1

  • The meaningful changes are in the fabric and the security model rather than in the headline version number
  • The practical effect for a deployment is better fabric efficiency and a clearer path to trusted memory isolation, and both matter before the version does
  • The platforms this runs on are PCIe-based, so the host slot and generation are the first constraint to check

Where a CXL pilot should start

  • Capacity extension for a specific workload is a smaller first step than pooling across hosts, and it delivers a measurable result
  • Pool across hosts only when the workload’s data placement is actually coordinated — otherwise the pooling layer adds latency without benefit
  • We supply the adapter and controller families a pilot needs, and availability is confirmed per part number

How we test the hardware a CXL pilot depends on

  • Every unit is cleaned, re-flashed and bench-tested on our own test line before it is listed
  • We confirm negotiated link rate, firmware revision and error counters against the part number you send
  • Ask us for photos of the actual unit before you commit


Related reading

Frequently Asked Questions

Does CXL 3.0 work with current AI accelerators?

The CXL specification is independent of the accelerator, but the practical constraint is the host platform: whether it exposes a CXL-capable slot, at which PCIe generation, and whether the platform’s memory subsystem supports the attached tier. Check the platform’s CXL support matrix rather than assuming a generation number implies support.

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

They solve different problems. NVMe-oF extends block storage across a network; CXL extends memory across a fabric. They can coexist — a pool for capacity and a fast local tier for hot data — but they are not substitutes, and the latency characteristics differ by orders of magnitude for the operations each is built for.

Is CXL a replacement for more DRAM?

No. CXL memory is slower than local DRAM, so it extends capacity rather than replacing it. The value shows up when a workload’s working set can be tiered — the hot portion in DRAM and the cold portion in attached memory — where the effective capacity rises without the latency of a full DRAM solution.

What is the cheapest way to start a CXL pilot?

Start with capacity extension on one host rather than pooling across many. It needs one CXL-capable slot rather than a fabric, it can be run against a real workload, and it produces a latency and hit-rate measurement that tells you whether the pooling work is worth doing. Send the host model and we confirm the part numbers that fit.

How does CXL 3.1 trusted memory protection differ from the earlier CXL IDE?

The earlier model tied confidentiality to a device identifier, which meant the trust boundary stopped at the device. The newer approach moves part of the trust decision into the fabric and the host’s own policy, so the isolation can be enforced across a shared pool rather than per device. For multi-tenant deployments that is the difference between a shared resource and a shared risk.