Meta rerouted retired DDR4 through CXL, a memory pooling standard, and trimmed its server count by a quarter. The full stack control that made it work is what rivals can't buy.
Meta runs an experiment in compute economics across millions of servers, and the data is public.
The company disclosed last month in a paper called Vistara that it cut its server count by roughly 25% by reusing DDR4 memory modules pulled from decommissioned machines, instead of scrapping them with the host systems. The older DDR4 sits behind CXL controllers that pool the modules into newer servers. Meta says the configuration is in production at fleet scale and lowers cost per unit of compute (EE Times; Vistara paper).
Server refresh cycles run every 4 to 5 years; DDR memory modules typically last 10 to 12 years. A module pulled from a retired server usually has half its useful life left, which makes it a candidate for reuse rather than scrap. For most operators, those modules go to e-waste because no one built the plumbing to move them into a new system. Meta built the plumbing.
That plumbing is CXL, short for Compute Express Link, a standard that lets a CPU treat memory attached to a separate device as if it were local. In Meta's setup, a CXL expander board accepts DDR4 DIMMs from older servers and presents that capacity to a current-generation host. The host sees a working memory pool. The module gets a second life.
The 25% number is Meta's own disclosed figure from the paper, a company metric rather than an independent measurement. The harder-to-replicate fact is the vertical integration that made the deployment possible.
Meta designed the inference and training ASIC in-house, wrote the firmware, runs its own fleet management software, builds its own server boards, and pulls the reclaimed DIMMs from its own data centers. The company also maintains a customized Linux kernel with CXL support and has contributed parts of that work back upstream. None of those steps is exotic on its own. Few companies stack all of them.
Khurram Malik, who tracks memory and storage at Marvell, lays out the broader economics. The case for routing DDR4 behind CXL used to be weak because adding more DDR5 was cheaper than buying CXL expander hardware. DDR5 price increases have flipped that math, and the second-life DDR4 path can now win on cost for operators with the right fleet mix and software stack. The market-wide DDR5 shift is the precondition, not the gimmick (EE Times).
Ameet Sanghavi points to the harder constraint. Most organizations do not have the full-stack control Meta has, he told EE Times, and they cannot rebuild firmware, redesign boards, or fork the kernel to make a CXL reuse program work. For them, CXL is a roadmap item, not a deployment.
AI-era compute economics are splitting operators into tiers, and the tier boundary runs through who controls the stack. A company that owns the chip, the firmware, the board, the kernel, and the fleet can absorb a memory-generation transition by rerouting the previous generation's modules through a new interconnect. A company that buys commodity servers and runs stock Linux cannot, at least not without years of in-house investment.
There is a falsifier worth naming. If a non-vertically-integrated operator ships a comparable CXL-backed DDR4 reuse deployment at hyperscale within 12 to 18 months, the tier-split model breaks. The likely test cases are Google, Microsoft, and AWS. All three have the scale to amortize CXL hardware. All three run more heterogeneous software stacks than Meta. Watch the next round of OCP submissions and the ASPLOS, ATC, and ISCA paper lists for whether any of them name a second-life DDR4 program at production scale.
If Meta's 25% reduction holds across the deployed fleet, the implied compute-per-dollar advantage compounds every refresh cycle. Rivals do not have to match the percentage to feel the pressure. They have to keep buying new DDR5 at rising prices while Meta amortizes memory that would otherwise be scrap. The next refresh cycle is where the asymmetry lands.