On July 20, 2026, Micron released the results of a data center LPDDR5X evaluation conducted jointly with Meta. Using "DCPerf," an open-source benchmark suite built to reflect Meta's real-world operations, the companies measured how far memory speed and capacity go toward improving AI data feeding, web services, and Spark SQL.
The results are clear-cut. An 8533 MT/s configuration increased AI data pipeline throughput by 11% and cut P99 memory-read latency for a MediaWiki-type workload by about 9%. Meanwhile, a configuration that lowered the operating speed to 6400 MT/s in exchange for doubling capacity boosted SparkBench throughput by 2.82x under a standard load and 3.45x under a 3x load. The choice of "make memory faster or make it bigger" produces opposite answers depending on the use case.
In These Two Configurations, 8533 MT/s and 1TB Capacity Don't Coexist
The joint white paper compared two dual-socket machines, each equipped with 72-core Arm CPUs per socket. The difference lies in the LPDDR5X rank count, capacity, and transfer speed.
| Item | SKU1: Capacity-focused | SKU2: Speed-focused |
|---|---|---|
| LPDDR5X Capacity | 512GB/socket, 1TB total | 256GB/socket, 512GB total |
| Data Rate | 6400MT/s | 8533MT/s |
| Theoretical Bandwidth | 384GB/s | 512GB/s |
| Rank Count | 4 | 2 |
| Micron Part Number | 62F8 | 62F4 |
Capacity-focused SKU1 stacks more DRAM dies to achieve 4 ranks. However, adding ranks increases the electrical load on the memory bus, forcing signal speed to be reduced. The 2-rank SKU2 sacrifices half the capacity in exchange for a 33% higher data rate.
Therefore, the table comparison is not a generational difference between "new memory and old memory." It is a comparison between a design that keeps a large working set inside DRAM and a design that moves data faster. This distinction serves as the baseline for understanding the numbers that follow.
11% AI Data Feeding, 9% P99 Reduction
The 8533 MT/s SKU2 boosted sustained DRAM bandwidth by 13% over SKU1 in Tensor Rebatching. Rebatching copies data from a large memory pool into contiguous output buffers, reassembling batches before handing them to the accelerator. The bandwidth increase raised throughput by 11% and shortened per-batch time by 10%.
This 11% does not represent an improvement in GPU compute performance. It means the CPU-side processing that feeds data to the compute engine got faster, reducing the time the accelerator spends waiting for input. The white paper explains that the reduction in per-batch time cuts accelerator idle time and improves overall pipeline throughput.
In Deserialization, which reconstructs serialized tensors in memory, SKU2 also increased memory bandwidth by 6% and CPU IPC by 18%. In workloads that mix light computation with memory access, the reduction in time the CPU spends stalled waiting for data manifested as a larger IPC gap than the bandwidth gap alone would suggest.
In oss_performance_mediawiki_mem, which simulates a web service, the number of connections per thread was scaled from 36 to 288. SKU2 reduced P99 memory-read latency by 12 to 20 milliseconds compared to SKU1—a roughly 9% improvement—while maintaining higher request throughput. The effect shows up more in tightening the slowest 1% of responses than in the average.
However, within the measured range, the throughput-versus-latency curve had not saturated. HHVM's autoscaling was also capped at 2 instances. These figures reflect only the difference under the evaluated concurrency level and software settings—not a measurement of the server's maximum capacity.
Using DCPerf carries real significance. Meta stated in 2024 that it designed DCPerf by referencing its own large-scale production applications, making it compatible with x86, Arm, and multi-tenant environments. In practice, the company uses it for product evaluation, server configuration selection, and capacity planning as well. That said, this joint white paper is not a report on deploying SOCAMM2 into Meta's production fleet. It should be accurately understood as a reproducible test designed to approximate production-like behavior.
What Slowed Spark Down Wasn't Compute—It Was SSD Spillover
The capacity difference showed up most dramatically in SparkBench. CPU architecture, core count, and cache hierarchy were kept identical. Spark workers were allocated 276GB, and both a standard query and a 3x load condition were run.
The QPH (queries per hour) of the 1TB-equipped SKU1 was 2.82x that of the 512GB SKU2 under the standard load, and 3.45x under the 3x load. The difference in execution time followed the same ratio. SKU2's speed advantage at 8533 MT/s vanished the moment data overflowed DRAM.
In Stage 2 of the standard load, the gap widened to 38.75x. Because SKU2's DRAM couldn't hold the intermediate data generated by shuffling, writes and reads to SSD occurred. SKU1, with double the capacity, kept the working set inside DRAM and avoided this I/O. That said, the 38.75x figure applies only to Stage 2; the overall application QPH difference is 2.82x.
Under the 3x load, a different cliff appeared. Because the dataset didn't fit in SKU2's OS page cache, every scan required re-reading from SSD, making SKU1 5.96x faster in Stage 1. Stage 2 showed a 4.25x difference, and Stage 3 showed 3.21x. Insufficient capacity doesn't necessarily degrade performance gradually. Once the working set crosses a boundary, the processing path itself switches from DRAM to SSD.
The design conclusion here is concrete. Bandwidth-sensitive preprocessing and low-latency services benefit from a high-speed configuration. For workloads like Spark that hold shuffle data and page caches, securing capacity—even with slower memory—wins out. This reversal cannot be predicted from peak-bandwidth spec sheets alone.
Don't Confuse a 6.8% Power Ratio with a 75% Reduction
During Tensor Rebatching execution, LPDDR5X DRAM power accounted for 6.8% of total system power. This is a value directly measured in the current joint evaluation. From this ratio alone, one cannot calculate system power if replaced with a DDR5 server, nor the power that could be redistributed within a rack.
The white paper also includes a graph showing LPDDR5X DRAM power as more than 75% lower than DDR5. However, this figure is cited from a separate technical document Micron published in 2025. Under Multichase's 1-read/1-write condition, LPDDR5X drew 19.9W versus DDR5's 86.5W—a 77% difference. Other access conditions showed 75-77% reductions as well.
That earlier evaluation used a 72-core NVIDIA Grace Hopper for the LPDDR5X side and a 64-core Intel Xeon Platinum 8592+ for the DDR5 side. Clock speed, L3 cache, and the interconnect linking CPU and GPU also differed. The method of capturing DRAM power differed too—NVIDIA's power model on the Grace side versus performance counters on the DDR5 side. It serves as material showing a memory-only power difference, but it is not a test that swapped LPDDR5X and DDR5 on the same CPU.
This new joint white paper compensates for that weakness from a different angle. It tracked application performance across two types of LPDDR5X on the same Arm CPU, breaking down which workloads benefited from speed versus capacity. In exchange, the performance gap versus DDR5 and the total rack-level TCO remain undetermined. Module pricing and cooling infrastructure costs are undisclosed. Failure rates and replacement times are also unknown, so it cannot be judged whether DRAM wattage savings would recoup deployment costs.
SOCAMM2 Enters Supply Competition in the Vera Generation
Interchangeability has long been a weakness in extending LPDDR to servers. LPDDR used in smartphones and previous Grace generations is often soldered directly to the board. SOCAMM2 shifts to a compact module with a compression-mount connector, bringing field-replaceable serviceability and capacity flexibility.
Micron began customer sampling of 256GB SOCAMM2 in March 2026. An 8-channel server CPU could be configured with up to 2TB. In its Q3 FY2026 earnings on June 24, the company stated that its LPDDR5X SOCAMM2 product lineup is in mass production and that it has expanded its capacity offerings. However, it did not explicitly state that the 256GB product itself has moved to mass production.
SK hynix has also entered the supply race. On April 20, the company announced the start of mass production of 192GB SOCAMM2, targeting NVIDIA Vera Rubin. NVIDIA's published specifications for the Vera CPU include up to 1.5TB of LPDDR5X and up to 1.2TB/s of memory bandwidth. It connects to the Rubin GPU via 1.8TB/s NVLink-C2C, treating LPDDR5X and HBM4 as a coherent address space. Rather than replacing HBM, the design offloads things like KV caches to the large-capacity CPU-side tier, freeing up the HBM located closest to the GPU.
Component mass production and platform design are already proceeding in parallel. The next benchmark is whether the DCPerf gains are reproduced in production operation of SOCAMM2-equipped machines, allowing server throughput, rack input power, and deployment costs to be placed into a single balance sheet. Once that level of disclosure is reached, LPDDR5X will move from being evaluated as a power-efficient component to becoming a data center procurement decision.