Memory is the silent bottleneck of every modern server. CPUs keep adding cores, GPUs keep demanding larger model shards, and databases keep asking for sub-millisecond latency against terabyte-scale working sets. In 2026, the server memory landscape looks fundamentally different from the DDR4 era: DDR5 RDIMM is now the universal baseline, MRDIMM (Multiplexed Rank DIMM) is climbing into mainstream AI and HPC sockets, and CXL attached memory is graduating from research prototype to production deployment.
This guide from Zhongxin Data — a Shenzhen-based supplier of enterprise server hardware from the secondary market — explains the tradeoffs buyers face when sizing server memory. We help operators, integrators, and cloud builders pick the right memory tier for a workload without paying for bandwidth or capacity they will never use, or — worse — losing performance on the one tier the workload actually needs.
Bottom line up front: DDR5 RDIMM remains the workhorse for the vast majority of servers in 2026. Reach for MRDIMM only when you have verified bandwidth-bound workloads (large LLM training, large in-memory databases, HPC simulation). Reach for CXL attached memory when you need to extend capacity beyond the DRAM ceiling of the platform, or pool DIMMs across multiple hosts. Mixing tiers inside one platform is increasingly supported, but only when the BIOS and CPU vendor (Intel Granite Rapids / Sierra Forest, AMD EPYC Turin / Bergamo, AmpereOne 192-core) expose the right interleaving controls.
Why server memory decisions have moved up the priority list
For most of the DDR4 generation, server memory was treated as a commodity: pick a speed, pick a capacity per DIMM, order it. The CPU controlled the channel topology, and the platform supported exactly one family of DIMMs. That assumption has retired. In 2026, the same socket can host three very different memory tiers, each with its own speed grade, rank architecture, and capacity ceiling:
- Standard DDR5 RDIMM at 4800–6400 MT/s
- MRDIMM (Multiplexed Rank DIMM, JEDEC JESD238) at 8000–8800 MT/s, multiplexed on the same channel
- CXL attached memory via CXL 2.0 / 3.0 Type-3 devices (DDR5 backing media exposed over PCIe or fabric)
Each tier maps cleanly to a workload. The wrong tier either underfeeds the CPU — leaving cores idle while they wait on memory — or burns budget on bandwidth the workload does not consume. We see both mistakes regularly in customer orders, especially since Intel Sapphire Rapids and AMD Genoa both widened the price spread between 4800 and 6400 MT/s RDIMMs, and MRDIMM added a third axis on top.
Tier comparison: DDR5 RDIMM vs MRDIMM vs CXL attached memory
The table below summarizes the three tiers as a buyer would experience them in early-to-mid 2026. Pricing is the typical street price per 64 GB equivalent module in single-channel 16-DIMM configurations, and it moves quarter to quarter; treat it as a directional number, not a quote.
| Attribute | DDR5 RDIMM (standard) | MRDIMM (JESD238) | CXL attached memory (Type-3) |
|---|---|---|---|
| JEDEC speed | DDR5-4800 / 5600 / 6400 | DDR5-8000 / 8800 (multiplexed) | n/a — transports DDR5 over CXL |
| Peak per-channel bandwidth | 51.2 GB/s @ 6400 MT/s | ~70 GB/s effective on a host channel (multiplexing benefits) | ~16–32 GB/s per CXL x16 link (PCIe 5.0 / 6.0) |
| Latency (load-to-use, typical) | ~90–110 ns | ~95–120 ns (slight buffering hit) | ~250–400 ns (fabric + protocol overhead) |
| Capacity per DIMM slot | 16 / 32 / 64 / 96 / 128 GB | 32 / 64 / 128 / 256 GB | 128 GB – 1 TB per device |
| Capacity per 1U/2U server | 8–12 TB (Sapphire / Genoa) | 8–16 TB (Granite Rapids, SP7/SP8) | Adds 4–16 TB via 1–4 devices |
| Power per DIMM | ~6–10 W | ~10–14 W | ~20–40 W per CXL device |
| Error correction | ECC (on-die + ECC on command/address) | Same ECC, plus rank-level parity buffers | ECC + device scrubbing; CXL.mem supports RAS |
| Approximate 64 GB module price (USD) | an amount quoted per part number (6400 MT/s) | an amount quoted per part number (8000 MT/s) | an amount quoted per part number+ per CXL device (512 GB) |
| Order of magnitude cost per GB (effective) | Quoted | Quoted | varies by configuration and volume (large devices) |
Two observations stand out. First, MRDIMM has a per-GB price premium of roughly 2x to 2.5x over standard RDIMM, and that premium is justified only when bandwidth — not just capacity — is the binding constraint. Second, CXL memory looks cheap per GB in large form factors, but the latency penalty is three to four times that of native DRAM, which makes it a good fit for capacity-augmenting workloads (analytics, secondary caches, model state extension) and a poor fit for hot-path code.
DDR5 RDIMM in 2026: the universal baseline
DDR5 RDIMM is the safe default. Every modern server platform — single-socket Ampere AmpereOne, dual-socket Intel Sapphire Rapids / Granite Rapids, AMD EPYC Genoa / Turin / Bergamo — supports DDR5 RDIMM at 4800 MT/s as a minimum, with 5600 and 6400 MT/s supported on platforms that have validated those speeds. Buyers have three practical sub-choices inside the DDR5 RDIMM family.
| Speed grade | Per-channel bandwidth | Typical platform support | Cost premium over 4800 | Use when |
|---|---|---|---|---|
| DDR5-4800 | 38.4 GB/s | All DDR5 platforms (mandatory floor) | Baseline | Capacity-only scaling, general-purpose VMs |
| DDR5-5600 | 44.8 GB/s | Sapphire Rapids / Genoa / Turin (validated) | +10–20% | Mixed-tenant virtualization, mid-range databases |
| DDR5-6400 | 51.2 GB/s | Granite Rapids, Turin, Bergamo (validated) | +30–60% | In-memory DB, AI inference, financial analytics |
The right way to think about DDR5 RDIMM speed grade is bandwidth per dollar. A 6400 MT/s DIMM costs roughly 1.5x a 4800 MT/s DIMM but delivers ~33% more bandwidth. The premium is worth paying only if the workload actually saturates the memory subsystem. For typical virtualization and web workloads, 4800 MT/s is fine. For in-memory databases (SAP HANA, Redis cluster, Aerospike) and LLM inference with high concurrency, the jump to 5600 or 6400 MT/s pays for itself fast.
Capacity ranks follow the same logic. 128 GB DDR5-6400 RDIMMs (using 32 Gbit dies in 4-high stacked ranks) are now common on Granite Rapids. Plan capacity based on the working set of the workload, but always validate that the platform supports the specific rank and density combination. AMD EPYC Bergamo (cloud-native, 128 Zen 5c cores) has different validated DIMM density lists than Turin (general-purpose, 128 Zen 5 cores) even though both share the same SP5 socket.
MRDIMM: when bandwidth dominates
MRDIMM (Multiplexed Rank DIMM, ratified by JEDEC as JESD238 in late 2024) is the second wave of DDR5. Conceptually, an MRDIMM puts a multiplex buffer on the DIMM that lets the host treat two physical ranks as if they were a single wider rank running at twice the effective data rate. The net result is DDR5-8800 MT/s effective on a host that physically supports DDR5-4400 MT/s, with measured bandwidth gains of 35–40% over standard 6400 MT/s RDIMMs on the same platform. The latency increase is small (a few nanoseconds from the buffer).
MRDIMM is purpose-built for bandwidth-bound workloads. Three workloads especially benefit:
- Large language model training: GPUs on a single node share model weights and gradients through host memory (or pooled memory on the same NUMA node). A single 8-GPU H100 / H200 / B200 node with 8 TB of MRDIMM-8800 avoids the bandwidth cliff when NCCL shifts collectives into the host tier.
- In-memory databases: SAP HANA, MemSQL / SingleStore, and Redis cluster with very large shards (multi-terabyte per node) stress bandwidth more than latency. MRDIMM delivers bandwidth without the cost of CXL expansion.
- HPC simulation: CFD, seismic, and molecular dynamics codes that stream working sets across cores run well on MRDIMM-8800, especially on Intel Granite Rapids with its 12-channel memory controller.
MRDIMM does have a few sharp edges. First, not every platform supports it: Granite Rapids SP7 supports MRDIMM, but Granite Rapids SP8 (edge variant) does not. Sierra Forest (efficiency cores) does not support MRDIMM because the bandwidth does not pay for itself on the small core count. Second, you cannot mix MRDIMM and standard RDIMM on the same channel. The boot BIOS will either enforce all-MRDIMM or all-RDIMM per channel, and mixing silently downgrades to RDIMM. Third, MRDIMM power draw is meaningfully higher — 10–14 W per DIMM versus 6–10 W for RDIMM — so thermal design in dense 2P servers matters.
CXL attached memory: extending capacity beyond the DRAM ceiling
CXL Type-3 devices expose DDR5 backing media over CXL.mem (CXL 2.0 with CXL 3.0 fabric extensions). A single CXL-attached memory device can present 128 GB to 1 TB of capacity to a host, and multiple devices can attach to multiple hosts for memory pooling. In early 2026, this is no longer experimental: Samsung, SK hynix, Micron, and several Tier-1 OEMs ship CXL memory modules and CXL memory appliances for production workloads.
The economics of CXL attached memory are unlike MRDIMM. Per-GB cost is the lowest of all three tiers (an amount quoted per part numberper GB on large devices, compared to an amount quoted per part numberon DDR5 RDIMM and varies by configuration and volumeon MRDIMM). The reason is that CXL devices use commodity DDR5 internally but pay a one-time silicon cost for the CXL controller, which gets amortized across hundreds of gigabytes. The catch is latency: 250–400 ns of fabric and protocol overhead is fine for analytics but unworkable for hot-path in-memory transactions.
| Memory tier | Typical load-to-use latency | Relative to L1 cache | Best fit |
|---|---|---|---|
| L1 / L2 / L3 CPU cache | 1–35 ns | 1x – 35x | Code path, instruction fetch |
| DDR5 RDIMM (6400 MT/s) | ~90–110 ns | ~95x | Universal baseline |
| MRDIMM (8800 MT/s) | ~95–120 ns | ~110x | Bandwidth-bound compute |
| CXL attached memory (Type-3) | ~250–400 ns | ~350x | Capacity extension, analytics |
| NVMe SSD (PCIe Gen4 x4) | ~10,000–25,000 ns | ~18,000x | Cold storage tier, swap |
Three concrete uses for CXL memory have matured: (1) extending SAP HANA or Oracle Exadata working sets without rebuilding on a larger NUMA node; (2) holding LLM model state that overflows host DRAM (especially for 70B+ parameter inference offload); and (3) memory pooling across hosts in a rack, where a CXL switch fans capacity out to multiple servers that request DRAM on demand. Memory pooling with CXL 3.0 fabric is the deployment model with the most disruptive TCO potential, but it is also the one still being qualified by every major OS and hypervisor.
Five rules for picking the right memory tier
- Measure before you spend. Use a memory profiler (Intel VTune, AMD uProf, or perf c2c on Linux) to confirm whether the workload is bandwidth-bound, latency-bound, or capacity-bound. Buying MRDIMM for a capacity-bound workload is the most common overspend we see.
- Match speed grade to the slowest validated speed of the platform. DDR5-6400 on a platform that only validates 5600 silently runs at 5600, but the platform vendor may refuse RMA support. Always cross-check the platform’s Memory Product List (MPL) before committing.
- For AI inference, size for the active model shard in DRAM and use CXL for cold tiers. LLM inference bandwidth is bounded by GPU HBM, not host memory, so over-investing in MRDIMM rarely helps inference latency. It does help training, where collective bandwidth matters.
- For virtualization, run mixed-tenant pools on 5600 MT/s RDIMM. The jump from 4800 to 5600 delivers ~17% more bandwidth at ~15% cost, which is the sweet spot for most VMs.
- Always budget 25–40% spare capacity per server. Memory bandwidth degrades sharply on the last populated DIMM of every channel (odd-slot configurations lose a fraction of the bandwidth). Always populate symmetrically and keep a budget for growth.
Where Zhongxin Data fits in your memory decision
Zhongxin Data supplies enterprise and used server memory across all three tiers. Our catalog typically carries:
- DDR5 RDIMM at 4800 / 5600 / 6400 MT/s in 16 / 32 / 64 / 96 / 128 GB densities, including original-vendor-validated SKUs from Micron, Samsung, SK hynix.
- Used and pull-out DDR4 RDIMM for legacy platform support (Skylake, Cascade Lake, Rome) where continued investment makes sense.
- Selected MRDIMM modules for Granite Rapids SP7 builds, usually on customer order rather than stocking inventory because buyer volumes are highly bimodal.
Because memory is the most commonly failed DIMM component of any server, we batch-test every module through a multi-pass burn-in loop and tag the result with the lot and firmware revision. For deployment support, our engineers can help you size the right memory tier against your workload and validate against your platform’s Memory Product List.
Browse Zhongxin Data Server Memory or contact our hardware team at +86 13068616914 (WhatsApp) for sizing advice on AMD EPYC Turin, Intel Granite Rapids, AmpereOne 192-core, or any cloud-native 128-core platform.
Picking the memory tier for the workload
- Standard DDR5 RDIMM is the baseline for almost every general server and the right answer unless a workload is bandwidth-bound
- MRDIMM earns its place when the application reads memory faster than a standard module can deliver, which shows up in in-memory analytics and some inference serving
- CXL attached memory is for capacity beyond the DRAM ceiling rather than for bandwidth
The memory modules we list and how to match them
- DDR5 RDIMM modules in the capacities and speeds current platforms use are the bulk of what we list in this category
- Matching means capacity per channel, speed rating and the platform’s memory population rules — a mismatch shows up as a downclock rather than an error
- Availability is confirmed per part number — send the part number and quantity and we quote per part number
What we check on memory modules before listing
- Every unit is cleaned, re-flashed and bench-tested on our own test line before it is listed
- We confirm the part number, the SPD profile and the reported speed against the part number you send
- Ask us for photos of the actual unit before you commit
Related reading
- CXL 3.0 and 3.1 memory pooling — the third tier in this comparison
- used hardware cost analysis — the economics of buying used memory
- server memory — the modules we list
- DDR5 RDIMM server memory — the baseline tier in the comparison
Frequently Asked Questions
Is DDR5-6400 always better than DDR5-4800?
No. A faster module only helps if the platform supports it — when the population is mixed or the platform’s speed rules cap the population, the whole set can downclock to a common, lower speed. Fit the speed the platform actually runs, and check the population rules before mixing modules of different ratings.
Can I mix MRDIMM and standard RDIMM in the same server?
Generally not within the same memory controller or the same platform generation. MRDIMM is a different module type with different signalling, and a platform that supports it typically does not accept standard RDIMMs in the same channel. Check the platform’s population matrix rather than assuming mixing is possible.
How much does CXL attached memory improve in-memory database workloads?
It depends on whether the workload’s working set actually exceeds DRAM. If it does, tiering can extend the dataset considerably with a modest hit on latency, and the benefit grows with the hit rate of the faster tier. If the working set fits in DRAM, CXL adds cost and complexity for no measurable gain, and the sensible answer is more DRAM.
Is MRDIMM worth it for LLM inference?
Only for specific serving patterns. Weight streaming is usually compute-bound on the accelerator, and for a large model the weights do not fit in host memory anyway, so host memory bandwidth is rarely the binding constraint. It becomes relevant where the model is small enough to live in host memory and the serving loop is memory-bound.
What is the typical price gap between standard RDIMM and MRDIMM?
MRDIMM commands a meaningful premium over an equivalent-capacity standard module because of the different signalling and the module complexity. Rather than quote a figure that moves, we price per part number: send the exact part number and quantity and we quote per part number, and we confirm availability against that part number.