On November 10, 2026 (US time), alongside the launch of its 6th-generation EPYC processors, AMD introduced AMD MEXT, software that lets servers use NVMe SSDs as memory. It uses AI to predict an application's memory access patterns and moves rarely used data to the SSD, expanding usable memory capacity without increasing the amount of physical DRAM. With DRAM price increases pushing up the cost of buying and expanding servers, AMD is positioning MEXT as a way to cover memory shortfalls in existing infrastructure.
In an internal deployment case study that AMD published, the company deployed MEXT on 86 servers and added roughly 58TB of usable memory. That equals a 20% increase over existing capacity, and the deployment cost was reportedly 18% of what it would have cost to add the same capacity with DRAM. AMD also said it plans to expand the rollout to about 2,000 servers by the end of 2027, targeting cumulative cost savings of more than $60 million. However, these savings figures are AMD's own estimates and do not guarantee real-world performance or cost-effectiveness in other companies' environments.
MEXT is built on memory optimization technology from a company AMD announced it would acquire on June 15, 2026. This announcement is not the technology's first public debut; AMD is reintroducing it as a memory expansion option for servers in step with the 6th-generation EPYC launch.
AI predicts memory access and prefetches from SSD to DRAM
Normally, the data a server application uses is placed in DRAM. DRAM is fast but expensive per unit of capacity, so for large databases, semiconductor design, and AI-related workloads, memory expansion can be a heavy cost burden. NVMe SSDs, on the other hand, offer larger capacity at lower cost, but their access latency is higher, so simply using them as a substitute for memory tends to degrade performance.
MEXT uses AI prediction to make up for this speed gap. According to AMD's product description, it first moves infrequently accessed memory pages from DRAM to the NVMe SSD. An AI engine then analyzes memory page usage and predicts which pages the application will need soon. Predicted pages are returned from the SSD to DRAM before they are actually requested.
The key point of this design is that it tries to finish loading before a request occurs, rather than reading from the SSD after the application asks for the data. In conventional swapping, if a required page is not in DRAM, processing has to wait until the read from storage completes. MEXT reduces this wait through prefetching and treats DRAM and flash as a tiered memory system.
That said, the SSD itself does not become as fast as DRAM. If a prediction misses, or if an access occurs before the needed page has been returned to DRAM, SSD read latency can affect performance. Even with high prediction accuracy, if prefetching happens too late, the wait cannot be fully hidden. Actual performance depends on the application's memory access patterns and on how much capacity is allocated to DRAM and SSD.
There are two main ways to use MEXT. One is to keep the existing DRAM capacity and add SSDs to increase usable memory. The other is to combine MEXT with servers that have less DRAM than before, securing the required memory capacity while reducing hardware costs. The former mainly addresses memory shortages, while the latter is aimed at optimizing the configuration of new servers.
Benchmarks show 94–96% performance retained with DRAM cut in half
Even if MEXT can expand memory capacity, the benefit is limited if performance drops sharply. On this point, the performance evaluation document "MEXT Performance Benchmarking", published by MEXT before the AMD acquisition, presents measurements for configurations with DRAM capacity cut in half.
In these tests, a configuration with 64GB of DRAM served as the baseline, and it was compared with a configuration that reduced DRAM to 32GB and added a 32GB MEXT-provided expansion area. The three workloads were the in-memory data store Redis, the graph database Neo4j, and the caching system Memcached.
| Workload | Baseline | MEXT configuration | Performance vs. baseline |
|---|---|---|---|
| Redis | DRAM 64GB | DRAM 32GB + MEXT 32GB | 94% |
| Neo4j | DRAM 64GB | DRAM 32GB + MEXT 32GB | 95% |
| Memcached | DRAM 64GB | DRAM 32GB + MEXT 32GB | 96% |
Memtier Benchmark was used for Redis and Memcached, and WDBench for Neo4j. MEXT reports that with DRAM halved, each retained 94–96% of the original performance. The document also estimates that performance per cost rose about 1.7 times for each of the three workloads.
However, these are benchmarks run by MEXT itself, and similar results will not necessarily be obtained for every database or caching workload. The published materials do not allow a full assessment of load fluctuations in real production environments or of performance over long-term operation. Also, a result of 94–96% performance refers to the throughput of the measured workload and does not mean that the latency of individual access requests stays at a comparable level.
AMD has also described MEXT's effects in other use cases. In an official AMD blog post on July 17, 2026, the company discussed a performance evaluation of pre-acquisition MEXT using MoonRay, a renderer used in film production and other fields. On a system with an AMD Ryzen Threadripper PRO, it compared a configuration using 512GB of DRAM with one combining 256GB of DRAM and 256GB of NAND flash, and reported that rendering performance was roughly equivalent.
In the MoonRay test, the accuracy with which the AI engine predicted the next memory pages needed was reported as 97.9%. MEXT also estimated it could reduce DRAM-related costs by about 40% and total cost of ownership (TCO) by about 29%. However, this is an evaluation of a specific rendering workload and is not a figure that applies to every workload on EPYC servers. Nor is there any guarantee that the 97.9% prediction accuracy can be achieved in other applications.
These results support the idea that there are workloads where replacing part of the DRAM with SSD keeps performance degradation small. On the other hand, performance may drop significantly for irregular memory access that is hard to prefetch, or for latency-sensitive processing. How much DRAM can be cut needs to be evaluated application by application.
At AMD, 86 servers gained about 58TB, cutting expansion costs by 82%
The internal deployment case study AMD has now published is an effort to increase usable memory on existing servers, rather than to reduce DRAM. AMD's IT department began deploying MEXT in September 2026 to the production compute environment used by its engineers. The environment includes servers with 4th- and 5th-generation AMD EPYC processors and supports memory-intensive work such as semiconductor design.
Across the 86 servers in the initial deployment, MEXT added a total of about 58TB of usable memory. According to AMD, that is a 20% increase over the previous usable capacity. Adding the same capacity with physical DRAM would have cost about $3.3 million, whereas the MEXT expansion cost about $601,000.
The cost comparison AMD published is as follows.
| Item | AMD's published figure |
|---|---|
| Servers in initial deployment | 86 |
| Usable memory added | About 58TB |
| Increase in usable memory | 20% |
| Cost of adding equivalent DRAM | About $3.3 million |
| Cost of expansion with MEXT | About $601,000 |
| Cost as a share of DRAM expansion | About 18% |
| Savings published by AMD | About $2.78 million |
| Cost reduction rate | About 82% |
It is worth noting that the 82% reduction applies to the cost of adding memory capacity. It does not mean that total cost of ownership, including server purchase prices, power, cooling, and maintenance, fell by 82%. AMD's figures are also approximations, and the amount obtained by simply subtracting about $601,000 from about $3.3 million does not exactly match the published savings of about $2.78 million. Detailed cost breakdowns and the specific conditions used in the calculation have not been disclosed.
For AMD, this deployment is also an effort to use its own IT environment as an early customer of its product. Hasmukh Ranjan, the company's chief information officer, explained that rising DRAM prices have become a major challenge for the IT department. If the budget needed for memory expansion can be reduced, the difference can be redirected to investments in GPUs and other IT equipment.
AMD says it will continue deploying MEXT on existing servers and will also build it into newly deployed servers as a standard component. It expects to expand to about 700 servers by March 2027, with cumulative savings of about $21 million. By the end of 2027, it plans to reach about 2,000 servers, with cumulative savings forecast to exceed $60 million.
However, the figures of 700 and 2,000 servers are future plans, not results achieved so far. The savings could also change depending on future DRAM prices, server configurations, and deployment costs. What matters is how far AMD actually advances the rollout and whether the expanded memory can be used continuously in production.
Deployment requires a dedicated NVMe SSD and two CPU cores
MEXT is software-based memory expansion technology, but it cannot be used simply by installing it on an existing server. The product FAQ published by AMD lists preparing a dedicated NVMe drive and disabling the OS swap as conditions for deployment. Rather than repurposing a general swap area for MEXT, dedicated storage must be set aside.
MEXT's processing also uses two CPU cores: one for the AI engine and one for the daemon. A GPU is not required. Although it is AI-based software, it is not configured with a dedicated GPU added for inference.
The main deployment requirements AMD has published are summarized below.
| Item | Requirement / published information |
|---|---|
| Storage | Dedicated NVMe SSD required |
| OS swap | Must be disabled |
| CPU resources | 1 core for the AI engine, 1 core for the daemon |
| GPU | Not required |
| Supported OS | RHEL, Rocky Linux, AlmaLinux, Oracle Linux, SUSE Linux, Debian, Ubuntu, and others |
| Network | No special network or firewall requirements |
| Installation | Described as possible with a single command after download |
| Verification | A proof of concept (PoC) is offered through AMD sales contacts |
According to AMD, if the required conditions are met, everything from installation to deployment can be completed in a few minutes. However, this describes the software installation work and does not mean that validating performance and stability in an existing production environment also takes only minutes. For whether it can be used with a specific Linux distribution or server configuration, AMD asks customers to confirm with its sales contacts.
As use cases likely to benefit from MEXT, AMD cites memory-intensive workloads that require more than 64GB of DRAM. Specifically, it envisions semiconductor design and EDA, media production, AI agents, databases, and analytics. All of these require large amounts of memory, but the DRAM capacity actually needed and the effect of prefetching differ depending on the workload.
Although this announcement is tied to the 6th-generation EPYC, AMD IT's existing environment includes 4th- and 5th-generation EPYC, so MEXT need not be seen as technology exclusive to the 6th generation. However, AMD's published materials alone do not make it possible to tell whether it works on every existing EPYC server.
Real memory access patterns determine how much DRAM MEXT can save
Evaluating the benefit of MEXT takes more than a simple comparison of memory capacity. For example, if DRAM is reduced from 512GB to 256GB and the rest is covered by a MEXT area on SSD, the cost per unit of capacity may come down. But if the memory pages a process needs are frequently moved out to the SSD and prefetching cannot keep up, execution time can grow and response latency can increase.
One point deserves particular attention: average performance and worst-case latency do not necessarily match. Even if a benchmark retains 95% of the original throughput, the possibility remains that certain access requests will incur large delays. For online databases and workloads that require real-time behavior, it is necessary to check not only average throughput but also 95th- and 99th-percentile response latency and variability in processing time.
When pages are moved frequently between DRAM and SSD, the write volume and endurance of the NVMe SSD also become important. Because MEXT works by moving out infrequently accessed pages, writes to the SSD will occur during operation. SSD lifespan, behavior during failures, and recovery after a reboot need to be verified under actual operating conditions.
On cost, too, the decision cannot rest on the per-capacity prices of DRAM and SSD alone. A comparison needs to include the purchase cost of the dedicated NVMe SSD, MEXT licensing fees, CPU resource consumption, additional power load, and operations and management costs. The internal deployment case study AMD published gives the total expansion cost but does not disclose individual costs such as SSDs or licenses.
The way cost-effectiveness is calculated also differs between increasing the capacity of existing servers and reducing the DRAM in new servers. In the former, the main comparison is the expansion cost of obtaining the extra capacity, whereas in the latter, the lower purchase cost from reduced DRAM must be weighed together with MEXT's impact on performance.
AMD MEXT is technology that widens the options for tuning server memory capacity and cost by combining SSDs rather than relying on DRAM alone. AMD's internal deployment results and the earlier benchmarks serve as evidence of its effectiveness, but they do not prove the same effect for every workload. Going forward, validation results from companies other than AMD in production environments, total cost of ownership including licensing fees, and stability over long-term operation will shape its practical evaluation.