AMD's MEXT Aims to Halve Server DRAM by Predicting Which Memory Pages You'll Need

Memory offloading to flash isn't new. What's different about MEXT is the bet underneath it: that a predictive model can hide the latency penalty well enough that the operating system never notices the DRAM is missing. That's a much bigger claim than simple tiering, and it's why the numbers deserve a close look.

What MEXT actually does

MEXT moves cold memory pages to flash storage and pulls them back when they're needed. The physical DRAM it frees still shows up as installed memory to the OS, which is the part that makes it useful as a drop-in change. AMD and MEXT founder Gary Smerdon say the technology can cut the physical DRAM a server needs by 20% to 75%, depending on the application and the performance target. AMD took over MEXT's development in June and plans to extend it across a wide swath of its own IT infrastructure next year.

The obvious problem is speed. Flash is orders of magnitude slower than DRAM, so reactive paging would stall applications constantly. MEXT's answer is to predict the pages an application will touch next. If the model stays far enough ahead to cover the transfer latency from the SSD, the application sees what looks like full memory. When that works, the trade is hard to argue with. When the prediction misses, you pay for it in stalls.

Why a language model is the right tool here

The reasoning makes more sense once you look at how a transformer LLM works. Modern language models are built on next-token prediction: given a sequence, they estimate which token is most likely to come next. This open-source visualization is a clear walkthrough if the mechanics are new to you. MEXT applies the same idea to memory, predicting the next page rather than the next word.

The analogy has a useful consequence. With text, order matters enormously. With memory pages, it doesn't. A page only needs to be resident in DRAM at the moment it's accessed, so the model's job is to get the right pages into place in time, not to reproduce a sequence. That's a narrower problem than language generation, and it's one where a learned model has a realistic shot.

Smerdon's point is that AI is what changes the picture. Offloading on its own has existed for a while. Meta has described transparent memory offloading as a way to get more memory for less cost and power, and that approach relies on heuristics for deciding what to move. MEXT replaces those rules with a model that learns the access patterns of the workload in front of it.

Deployment: a Linux module, no pretraining

MEXT ships as a Linux kernel module that works with any Linux distribution. It runs an ensemble of AI models, with the transformer-based LLM doing the main prediction work. It doesn't come pre-trained, and that's a deliberate choice. AMD says it trains in under a second when first deployed, runs on a single EPYC core without a GPU, and keeps training as the workload evolves.

That design fits a world where the same server might run a database one hour and an agentic AI pipeline the next. A pretrained model would need to match each workload's access patterns in advance. An online learner adapts to whatever is running, at the cost of a small, always-on CPU overhead that AMD says is a single core.

RAM View and the cold-page problem

AMD built RAM View to accompany MEXT. It's a memory utilization tool that marks which pages are hot and which have gone cold. In the example AMD showed, a system with 1.5 TB of memory was running near full utilization, yet roughly half its pages hadn't been touched in five minutes or more at any given moment. That's the opportunity MEXT is built around.

The caveat is that AMD didn't say which workload produced that breakdown. It matters a lot. Access patterns vary sharply between applications, and so does the performance hit when memory runs short. AMD calls the point where performance drops off the "memory wall." MEXT's pitch is that it pushes that wall back, though by how much depends on the software sitting on top.

For many workloads, AMD says it's confident in capacity reductions of around 20% to 25%. Past that, applications get more specialized, and the performance gap widens.

The numbers AMD is showing

AMD's internal results are the most concrete data so far, and they're first-party, so they call for some skepticism. The company's main showcase is Synopsys PrimeTime, an EDA workload that's memory-hungry on large designs. AMD says servers at 50% DRAM capacity retain 95% of the performance of a full server. Dropping to 25% keeps about 80%.

Other workloads look even better on paper. In a three-node cluster running in Azure on 5th-gen EPYC CPUs, AMD reports 99% of full-cluster performance at 50% DRAM capacity using the Spark SQL workload from the TPC-DS benchmark. Databases are a natural fit, since they cache aggressively to avoid I/O bottlenecks, which leaves plenty of cold pages to move.

Agentic AI is probably the most relevant case right now. Across a five-agent concurrent geomean, AMD claims 99% of full-server performance at 50% memory capacity and 85% at 25%. For a "memory-hungry" agent, the figures are 90% and 88% at 50% and 25% capacity. Those are the numbers that would matter most to someone running agent fleets, but without the test configurations behind them, they're hard to interpret.

AMD hasn't shared the footnotes for these slides, so there's no way yet to see how the tests were run. It's reasonable to assume the company showed MEXT in its best light. Until the methodology is public, the results are directional rather than something to plan capacity around.

Where the rollout stands

AMD's internal deployment covers 145 servers and is expected to grow to 2,000 next year. HPE is bringing MEXT to customers, and the first rollout phase includes EPYC Venice servers with a "MEXT Ready" badge and a dedicated NVMe drive or bay for the offload. Phase 2 brings MEXT licenses and the RAM View application to those systems. AMD hasn't said when Phase 2 starts.

The EPYC-only restriction is the clearest sign of caution. AMD has left room for future support on other products, including consumer hardware, but that's a distant prospect. It will be sold as a license bundled with RAM View, and there's no firm date for broad availability outside AMD's own walls.

Here's the thing, though: even trimming 25% of a server's DRAM is a meaningful saving when memory is scarce and expensive. The AI-driven DRAM price surge is hitting enterprises whether or not they run AI workloads, so a technique that stretches existing modules has obvious appeal. If some workloads can reach 50%, the case gets stronger still.

What to watch next: the footnotes and test configurations, performance on workloads outside AMD's own EDA and database use, how the model behaves when access patterns shift abruptly, and whether the one-core overhead holds up under real production load. Those answers will determine whether MEXT becomes a standard part of server design or stays a well-engineered niche.