Google is recovering DDR4 memory from retired servers and feeding it back into new-generation AI servers through a dedicated interface. The generational turnover of AI servers no longer necessarily means clearing out old components. As supply constraints have intensified, memory that had already finished its service life is being converted into parts that expand the newest AI infrastructure.
This policy was detailed by Nikhil Cherian, Senior Director overseeing supply chain infrastructure at Alphabet, at SEMICON Taiwan 2026 on September 1, 2026. The event's official presentation page states that AI infrastructure has shifted from compute-centric constraints to severe memory constraints, with high-performance memory now accounting for more than 75% of the bill of materials (BOM) cost of AI servers. According to the local outlet Economic Daily News, Google has been disassembling retired servers to extract reusable DDR4 and has also asked memory makers to increase production.
However, it has not been confirmed that DDR4 is replacing the High Bandwidth Memory (HBM) used in TPUs. What Google has disclosed is only the fact that it integrated older-generation memory into new servers—it has not revealed where or under what standard the connection was made. The significance here is not the novelty of "even Google uses secondhand memory," but the fact that Google is restructuring the memory hierarchy of AI servers according to speed and use case, trying to wring out every last bit of procurable capacity.
Why Google Brought Back Retired DDR4
For Google, recovering usable components from servers is nothing new. The company has run a decade-long data center circularity program, building a supply chain that evaluates and disassembles retired equipment before routing components to internal reuse, resale, or recycling.
In 2024, Google recovered approximately 8.8 million components from retired data center hardware. This figure includes more than 3 million hard disks that were reused or resold after data erasure. That same year, at data centers Google owns and operates, 84% of operational waste was diverted from disposal. The roughly 8.8 million figure is not a count of DDR4 modules—it represents overall component recovery, including hard disks.
What's changed this time is that the recovery network has been foregrounded as a supply countermeasure specifically for AI. Rather than treating old-generation DDR4 as an asset to be disposed of, Google is integrating it back into new AI servers—and has even built a dedicated interface to connect memory across generations. A system originally designed to reduce environmental impact has also become a form of supply defense at a moment when manufacturers cannot supply enough memory, allowing capacity expansion to continue.
Even so, Google itself states that recovered DDR4 alone cannot meet demand. The number of modules that can be recovered depends on past deployment volumes and retirement timing, and usable modules still require inspection. Component circulation should not be viewed as a policy that eliminates the need for new production, but rather as a way of drawing reserve capacity from internal assets until supply catches up.
Is DDR4 a Substitute for HBM? The Connection Point Remains Undisclosed
Treating "AI server memory" as a single category leads to a misreading of this announcement. Google's 8th-generation TPU is a system that connects on-chip SRAM, near-chip HBM, a host with Arm-based Axion CPUs, and storage—each operating at different speeds and roles.
| Memory / Path | Google's Disclosed 8th-Gen TPU Specs | Relationship to Recovered DDR4 |
|---|---|---|
| TPU 8i On-chip SRAM | 384MB. Holds KV cache on-chip during inference | No explanation of replacement |
| TPU 8i HBM | 288GB, 8,601GB/s bandwidth | No explanation of DDR4 substitution |
| TPU 8t HBM | 216GB, 6,528GB/s bandwidth. For large-scale training | No explanation of DDR4 substitution |
| CPU Header | Both TPU 8t and 8i use Arm Axion | Undisclosed whether connected to local DRAM |
| Recovered DDR4 | Integrated into new-generation AI servers via dedicated interface | Standard, capacity, bandwidth, latency, and placement undisclosed |
What can be confirmed from this table is only that Google presented the specs of its high-speed memory hierarchy and the integration of DDR4 as separate items. It's possible that recovered DDR4 was added as a separate capacity source, but beyond that, public materials alone cannot confirm the details. Whether DDR4 functions as local memory for the Axion host, as expanded memory attached to it, or as shared memory from a separate node remains unknown.
HBM and DDR4 differ both in role and in how they connect. HBM sits near the TPU and delivers several terabytes per second of bandwidth, feeding massive volumes of data into matrix operations. Standard DDR4 DIMMs make it easy to increase capacity, but they cannot match HBM's bandwidth or latency. Therefore, reused DDR4 is likely effective not for workloads where all data constantly requires HBM-class speed, but for domains where data placement can be split according to access frequency. This condition is concretely illustrated by Meta's earlier implementation—but that is no proof Google adopted the same approach.
Software and Data Paths Also Expand Memory
Google's countermeasures don't end with simply increasing the physical count of memory modules. The official presentation lists capacity ceilings, bandwidth shortages, latency, and power efficiency as separate constraints. Rather than solving all four with a single component, this is a design that varies data placement and movement according to use case.
TPU 8i targets inference and sampling primarily, equipped with 384MB of on-chip SRAM and 288GB of HBM. It places the KV cache—which reuses attention computations for already-generated tokens—close to the chip, reducing the time compute units spend waiting on memory when processing long contexts. Here, latency in returning a response matters as much as capacity.
For the large-scale training-focused TPU 8t, TPU Direct RDMA and TPU Direct Storage bypass the host CPU and DRAM. Data moves directly from the network or high-performance storage into the TPU's HBM, avoiding bottlenecks that arise when the host side becomes a data transfer chokepoint. This is a design choice for the 8th generation's data path and must be considered separately from the effects of DDR4 reuse.
On the software side, Google Research's TurboQuant quantizes the KV cache down to 3 bits. In Google's published evaluation, this reduced KV cache memory usage by at least 6x on a task involving searching for specific information within long contexts. Compared to unquantized 32-bit keys, attention logit computation was up to 8x faster under a 4-bit setting on H100.
Here too, the figures apply to different targets. The 6x figure concerns KV cache capacity; the 8x figure concerns a single step in attention logit computation. This is not a result showing that overall AI inference becomes 8x faster. Google's presentation advocates simultaneous hardware and software countermeasures precisely because compression reduces required volume but leaves physical supply shortages unresolved, and adding memory leaves bandwidth and latency problems unresolved.
Google vs. Meta: The Gap Is in Disclosure Depth, Not in the Fact of Reuse Itself
As a precedent for connecting retired-server DDR4 to new-generation servers, Meta published the design and production evaluation of its proprietary ASIC, "Vistara," at ISCA 2026. Both companies are similar in that they recover old DIMMs. The major difference is that while Google has only disclosed the fact of integration, Meta disclosed the connection standard and memory configuration, along with numerical figures covering speed differentials, target workloads, and measured effects.
| Disclosure Item | Meta Vistara | |
|---|---|---|
| Old-generation memory connection | Dedicated interface. Standard undisclosed | Compute Express Link (CXL) compatible |
| New/old memory capacity | Undisclosed | 768GB of DDR5-6400, 256GB of DDR4-2400, 1TB total |
| Rated peak bandwidth | Undisclosed | DDR5 at 614GB/s, CXL-connected DDR4 at 76GB/s |
| Idle latency | Undisclosed | DDR5 at ~130ns, CXL-connected DDR4 at ~250ns |
| Placement control | Undisclosed | Frequently used pages go to DDR5, low-access pages go to DDR4 |
| Reported effect | Undisclosed | 25% reduction in server count, 12% increase in throughput on a specific ML parameter server |
Google has disclosed only that it integrated retired-server DDR4 into new-generation AI servers via a dedicated interface, without revealing the connection standard, the specific point within the server it connects to, the DDR4's capacity, bandwidth, or latency, the target workload, or the measured effect. In contrast, Meta's Vistara paper reports that it operates local DDR5 (768GB) alongside CXL-connected DDR4 (256GB) as distinct tiers—614GB/s versus 76GB/s in bandwidth, and roughly 130ns versus roughly 250ns in idle latency—and states that this reduced the number of servers required by 25% for a specific ML parameter server. Meta's figures cannot be transposed onto Google, and there is no basis for concluding that Google's reused DDR4 serves as a substitute for TPU HBM or is connected via CXL.
In Meta's configuration, the CXL-side DDR4 has roughly one-eighth the bandwidth of local DDR5, along with higher idle latency. Simply adding a slower tier could make some workloads heavier, so the OS keeps frequently used pages on DDR5 and moves rarely used pages to DDR4. For workloads where extra servers had previously been added merely due to capacity shortages, accepting this speed differential can still reduce the total server count.
The Vistara paper estimates memory's useful lifespan at 7–10 years versus 3–5 years for servers. This is the economic rationale behind migrating DIMMs—which outlast the server chassis itself—into the next generation. However, Meta's configuration and results are not the answer to filling in Google's unspecified details. Whether Google's dedicated interface is CXL, and whether it performs the same kind of page placement, remains unknown. Nor can the 25% server-count reduction be cited as Google's own result.
What this comparison reveals is the verification gap left open by Google's announcement. Which memory tier does the reused DDR4 serve, and which workloads—tolerant of added latency—is it assigned to? Until this is known, neither the scale of reuse nor the cost-effectiveness for AI servers can be properly evaluated.
Conditions for Turning Reuse Into a Lasting Strategy
That the memory shortage is not unique to Google is clear from statements on the supply side. Micron forecasts that industry-wide data center DRAM and NAND bit shipments in 2026 will more than double compared to two years earlier. Samsung has similarly indicated that for the second half of 2026, accelerating demand growth in server DRAM, eSSD, and HBM will keep the market undersupplied even as some PC and mobile demand eases.
In this environment, hyperscalers' procurement decisions are shifting from unit-price optimization toward securing supply. Even installing expensive TPUs or GPUs is of limited use if there isn't enough capacity and bandwidth to keep the compute units adequately fed. Reusing retired DDR4 is not a technology that eliminates demand for new HBM or DDR5—it's a technology that adds one more capacity option so that already-procured compute power isn't left idle.
What should be confirmed next is the standard behind Google's dedicated interface and the exact point at which recovered DDR4 connects. Following that, the modules' capacity and speed, the resulting bandwidth and latency after integration, and the target workloads all need clarification. Even if performance holds up, this cannot function as a sustained supply strategy at scale unless there are workable methods for inspecting aged DIMMs, monitoring correctable errors, and handling replacement procedures upon failure.
The final numbers worth watching are the deployed server count and the measured impact: how much new-memory purchasing volume was reduced, how many extra servers—previously needed due to capacity shortfalls—were eliminated, and how much manufacturing-related carbon emissions were avoided through reuse. Only once these are disclosed can this measure be elevated from an emergency stopgap to an enduring design principle.
Google's announcement has shifted the conversation—from the simple fact that old DDR4 still has a use—toward system design that encompasses the supply chain itself. The value of an AI server is not determined by the number of fastest chips it contains, but by whether fast memory is allocated to the data that truly needs it, whether slower memory is routed to workloads that can tolerate it, and whether even the components remaining in the supply chain can be used to their fullest as part of one integrated system. The next thing to watch is how much of that design and operational data Google is willing to make public.