Google and University of California San Diego researchers, backed by Google, are planning to deploy a datacenter built from 2,000 retired Pixel smartphones, with the goal of giving hundreds of students and researchers low-cost, low-carbon cloud computing. The project, in a project blog post this month, treats the phone upgrade cycle as an untapped ore body for compute. Stripped of their screens, batteries, and chassis, the surviving motherboards would be mounted into racks, loaded with a general-purpose Linux distribution, and orchestrated with the same Kubernetes tooling used by hyperscale clouds.
The full system is expected to launch in Fall 2026. Smaller prototype clusters are already running on the San Diego campus, grading computer science assignments at the 75-student-class scale with latencies the team says beat the default AWS backend. The point of the project is to show that the same machine intelligence can be had for a fraction of the manufacturing carbon, at workloads where the absolute peak of an Nvidia H200 is overkill.
The Phone Cluster That Wants to Be a Datacenter
The blog post is part of a Google Research collaboration with computer scientists at UC San Diego, and it lays out the carbon math behind the project. Phones, the post argues, are often replaced for cosmetic and software reasons well before their processors give out. People swap devices on average every four years, the team writes, and the cast-off hardware still contains a high-performance and energy-efficient processor, integrated accelerators, 8 to 12GB of memory, and storage.
Those phones, the post says, can be put back into service to directly reduce the environmental footprint of computing, sidestepping the raw material extraction tied to building new servers. The phone cluster computing approach pairs each motherboard with a small containerized workload and aggregates the nodes through Kubernetes, the same scheduler used to manage a fleet of traditional server containers. The architecture treats the phone as the unit, not the rack. It lets the cluster grow simply by adding more motherboards.
For David Patterson, a Turing Award winner who joined Google after a long career in academic computer architecture, the project is the second coming of an old idea. He has called the approach Redundant Array of Inexpensive Smartphones, or RAIS, riffing on the storage term RAID. The cluster’s reliance on scale-out design borrows the same logic RAID used to scale up cheap disks into reliable storage.
What Gets Stripped Before the Motherboard Goes In
A smartphone motherboard is the only component that survives the trip into the cluster. The screen, battery, chassis, speakers, and cameras come off, partly because they take up space the rack cannot use and partly because the battery in particular contains materials the team flags as not rated for a datacenter environment. What remains is a flat board with a mobile system-on-chip, a few gigabytes of memory, and storage soldered on. Once stripped, the phones are not simply dropped into a rack and turned on.
The Android operating system is replaced with a general-purpose Linux distribution, which switches off mobile-specific protections and lets the cluster run server-style containerized workloads. Kubernetes handles the orchestration across thousands of devices, splitting jobs into self-managing pools of 25 to 50 phones that, in aggregate, hit the throughput of a single modern server. Phones are organized into those self-managing clusters automatically, the team says, with the same tools a hyperscale cloud would use for a fleet of containers. The stripped phones also drop the mobile user space that exists to manage touchscreens, sensors, and battery life, since none of that is needed in a rack. The result is a server-class node that fits in a hand.
The hardware that does not make the cut:
- Display: removed, no value as a server output and a large fraction of the device’s surface area.
- Battery: removed, contains materials the team flags as not rated for a datacenter environment.
- Chassis: removed, the case is sized for a hand, not a rack.
- Cameras and speakers: removed, the cluster has no use for them.
Embodied Carbon, the Line Item Nobody Insulated
The argument that makes the project worth running is the carbon tied up in the hardware itself, not the speed. The Google blog points to two categories: operational carbon, the emissions from the energy a datacenter burns, and embodied carbon, the emissions from manufacturing the chips, boards, and metals in the first place. The industry has spent a decade cutting operational carbon, mostly by buying cleaner electricity. Embodied carbon has stayed roughly the same.
According to internal Google assessments cited in the blog, the motherboard is responsible for roughly 50% of a phone’s embodied carbon. Stripping the rest of the device and reusing the board therefore targets the largest fraction of a phone’s embodied carbon. Repurposing 2,000 phones in this way, the team argues, spares the carbon that would otherwise have been spent mining, refining, and fabricating new server parts. It also sidesteps the e-waste stream that the global phone upgrade cycle generates each year. The point is not to lower emissions by a few percent; the point is to skip the manufacturing step entirely.
The motherboard is responsible for the largest fraction of embodied carbon, approximately 50% based on internal carbon footprinting assessments.
The figure is from a Google Research blog post on the project, written by Jennifer Switzer and David Patterson. The post frames the work as a pathway to a second life for phones, and as a reprieve from the carbon cost of building new servers. Key numbers from the project:
- 2,000: retired Pixel smartphones planned for the cluster
- ~50%: share of a phone’s embodied carbon tied to its motherboard
- 4 years: average phone replacement cycle, per Google Research
- 8 to 12GB: typical memory in a modern phone
- Fall 2026: target launch for the full system
Twenty-Five Phones, One Server
Phones do not match servers on every axis, but on the axis the team cares about, they hold up. SPEC benchmarking results cited in the Google blog indicate that 25 to 50 phones deliver throughput comparable to a single modern dual-socket server. The advantage comes from per-core single-threaded performance, where phone CPUs match or exceed the cores in many server chips.
Tom’s Hardware, in coverage of the project, notes that phones from just three years ago still outscore servers in SPEC on a per-core basis. That server, the piece points out, can carry dual AMD EPYC processors and Nvidia H200 or RTX Pro 6000 GPUs.
Phones win per core. Those servers win everywhere else. The cluster covers the gap by adding more nodes, with Kubernetes holding the whole thing together.
A server packs dozens of multithreaded cores and a huge memory capacity. A phone has a handful of heterogeneous cores and 8 to 12GB of memory. For workloads that need parallel throughput, like grading hundreds of student submissions, the cluster is a fit. For workloads that need a single very large memory space, like training a frontier model, it is not.
How a phone node stacks up against a modern server:
| Attribute | Phone | Modern server |
|---|---|---|
| Cores per device | A handful of heterogeneous cores | Dozens of multithreaded cores |
| Memory | 8 to 12GB | Hundreds of GB |
| Per-core single-thread performance | Comparable or higher | Lower per core |
| Best fit | Education, web, small jobs | AI training, large-memory workloads |
| Cluster equivalent | 25 to 50 phones | 1 server |
A Test Bed for a Hundred Classes at Once
The use case the team has tested the most is the university course. Early experiments at UC San Diego show that a moderately-sized cluster of 20 phones can support peak submission rates for a computer science class of 75 or more students, with grading latencies the team says fall below the AWS t3.micro instance the university uses by default. That single t3.micro has 2 vCPUs and 1GB of memory, well within the capability of one phone. The grading backend runs on small cloud instances today, mostly because universities rent cloud capacity in bulk, and the cluster aims to bring that capacity on-prem. A 2,000-phone deployment would replace a long list of small rented instances with hardware the university already owns.
Scale the cluster to 2,000 phones and the math changes. The team estimates the deployment will be able to support a hundred such classes running in parallel, while delivering 50 server-equivalents of compute at a fraction of the usual cost. The cost saving comes from buying phones at scale and the absence of a new manufacturing run, not from the cluster being inherently cheaper to operate. The hardware is depreciated, the racks are not new, and the carbon tied to the silicon is already spent.
The Open Questions the Research Has to Clear
A rack of 2,000 phones is also 2,000 devices to keep running. The blog acknowledges that the project is, among other things, a long-running test of whether consumer-grade hardware can hold up under sustained server-style load. The motherboards were designed for occasional interactive use, not the 24/7 thermal and I/O profile of a datacenter.
The project will also have to demonstrate that the cost savings survive the operations tax. A traditional server is one machine to patch, monitor, and physically replace. A phone cluster is 25 to 50 machines, and the larger the cluster, the larger the surface area for hardware faults. Kubernetes can reschedule workloads across the surviving nodes, but it cannot keep a phone from failing.
The blog is clear that the project is not a replacement for hyperscale AI infrastructure. Phones will not train the next generation of frontier models, and the team’s own framing puts the project on the long tail of education and research workloads. The 2,000-phone cluster is meant to soak up exactly that workload, sparing the embodied carbon bill of a new server build.
Where the Idea Came From
The phone cluster is the public face of a longer-running research effort at UC San Diego. The Kastner Research Group, led by computer science professor Ryan Kastner, has been studying what to do with discarded smartphones for years under the Junkyard Computing project at UCSD. The work produced an ASPLOS paper that the group says has been downloaded more than 50,000 times, the most downloaded paper in the 28-year history of the conference, and was given a Distinguished Paper Award. The team has also shown how to repurpose smartphones as web servers, as cloudlets for microservices, and as wildlife monitoring sensors.
The Google collaboration runs through Kastner’s group and co-investigator Patrick Pannuto, with Patterson and PhD student Jennifer Switzer driving the work on the Google side. Switzer defended her Ph.D. thesis in January 2026 on repurposing smartphones to reduce carbon, and is now doing a postdoc at Google with Patterson to continue developing the work toward a planned 10,000-plus smartphone deployment. The 2,000-phone cluster is the next step on that roadmap, with a Fall 2026 launch the team says is on track for the first phase of the rollout.
Frequently Asked Questions
How many smartphones equal one server in this project?
Google Research’s own SPEC benchmark work indicates that 25 to 50 phones deliver throughput comparable to a single modern dual-socket server. The comparison holds per core, not on total throughput or memory capacity.
Which phones is UCSD using for the 2,000-phone cluster?
The Google Research blog specifies 2,000 retired Pixel smartphones. The phones are stripped of display, battery, chassis, cameras, and speakers before the motherboards are redeployed.
When does the 2,000-phone cluster go live?
The full deployment is expected to launch in Fall 2026. Smaller prototype clusters of 20 phones are already running on the San Diego campus to support computer science classes.
Can a phone cluster replace a hyperscale AI data center?
No. The project explicitly does not aim to replace the AI infrastructure operated by Google, Microsoft, or Amazon. The target is university teaching, research, and education workloads that do not need the absolute peak of a top-end server.
