The Unused Compute Power Around Us

Sometimes a huge infrastructure question starts with a very small picture: a smartphone is charging overnight. The laptop is closed. The game console is waiting in the living room. The car is parked in the garage. Everywhere there is compute power that has already been paid for, is connected to power, and mostly does nothing.

At the same time, new data centers are being built on the scale of industrial plants. Halls full of GPUs, fiber, transformers, cooling systems, and power contracts. We are building a new layer of digital infrastructure meant to carry our writing, searching, programming, analysis, and perhaps one day even decisions.

What if a small part of that power did not simply expire? Not as a wild fantasy where every phone suddenly replaces a data center. But as a serious thought experiment: could there be something like a compute smart grid, where devices voluntarily, within limits, and for compensation contribute compute power?

In the article From PRISM to Prompts, I look at the other side of this development: the growing dependency on a small number of AI platforms, especially from the United States and China. Here, I am interested in the counter-idea. Not as naive P2P romance, but as a technical question: how much compute power is already scattered around, which AI tasks could even be distributed, and what would need to happen so people are paid fairly for it?

The Thought Experiment

AI is not just software. AI is electricity, cooling, fiber, GPUs, land, water, and capital. The International Energy Agency estimates that data centers consumed around 415 TWh of electricity worldwide in 2024, about 1.5 percent of global electricity consumption. By 2030, that could rise to around 945 TWh.

That is not just a number for sustainability reports. It is infrastructure policy. AI services are available 24/7. Every summary, every code question, every image, every agent run is a computation. And when billions of people and companies put work into AI loops, that becomes base load.

That is why I understand the fascination with large central solutions. Data centers are controllable: same hardware, same racks, same networks, clear security zones, SLAs, monitoring, billing. From an operations perspective, that is attractive. But politically, economically, and architecturally, it recreates exactly what has always made the internet vulnerable: a few centers of power.

So the thought experiment starts with a simple counter-question: what is already there before we build the next data center?

How Large Is the Unused Capacity?

The idea really begins in a completely ordinary moment. The smartphone is lying on the bedside table at night, connected to power, doing almost nothing. Inside it, however, is a chip with more AI-specific compute power than many computers had as an entire package ten years ago. An iPhone 15 Pro with A17 Pro reaches around 35 trillion Neural Engine operations per second. Even if you take only a cautious average from that, it is an absurd amount for a device that spends most of the night waiting.

The same thing happens on the desk. New laptops no longer have only CPU and GPU, but also NPUs or Neural Engines. Apple has been building a Neural Engine into its chips for years. Windows laptops are arriving as AI PCs with dedicated AI processors. A game console in the living room has GPU power that used to sound like a workstation. And still, we mostly use that local compute power only in short spikes: a game, an export, a video call, a local effect, a search. Then the device falls back into idle.

This is where the thought experiment begins. Not: “Can I rent out my iPhone as a data center tomorrow?” That would be nonsense. Instead: if so much silicon has already been paid for, is networked, and is connected to power every night, how large would the theoretical capacity be if we could use only small, safe, suitable windows of time?

You cannot measure the world’s unused compute power exactly. Too many devices are different, too many are offline, too many must not participate for battery, heat, security, or platform reasons. Still, a rough extrapolation helps build a sense of scale.

For that, let us take a few deliberately simple blocks. Important: I am not calculating as if every device were fully available all the time. I am calculating with time windows, participation rates, and cautious discounts. It remains a thought experiment, but one with numbers to stand on.

Tesla: Silicon on Wheels

In June 2025, Tesla reported its eight millionth produced vehicle. Not every one of those vehicles is still active, not every one has the same Autopilot hardware, and not every owner would make their car available to a compute network. So I calculate conservatively:

• Of 8 million produced vehicles, perhaps 80 percent are still realistically active and technically relevant. That would be 6.4 million vehicles.
• For Hardware 3, the FSD Computer from 2019 onward, a figure of around 144 TOPS for the system is often cited.
• Hardware 4 is in newer vehicles and is more modern, but Tesla does not publish a clean, simple TOPS value for it like the older Autonomy Day numbers. For this calculation, I therefore still use 144 TOPS as a conservative baseline.
• A car may stand still for 23 hours a day, but the charging window is what really matters. If it is connected to power for 6.5 hours at night, averaged over 24 hours that corresponds to about 27 percent availability.

If only 25 percent of these active Tesla owners opted in, that would be 1.6 million vehicles and around 62 exa-operations per second as a daily equivalent. At 50 percent participation, it would be around 125 exa-operations per second. If, theoretically, all active vehicles participated, the number would be about 250 exa-operations per second. During the night window itself, the instantaneous power would be higher; the daily-equivalent number is just the fairer comparison with a data center that runs 24 hours a day.

iPhones: The Bigger Surprise

For iPhones, the calculation is both simpler and harder. Simpler because Apple ships enormous volumes every year. Harder because Apple does not publish a clean public table showing which iPhone generations are still active worldwide. So I use published shipments from recent years and apply a plausible active remaining share.

This blended calculation yields around 885 million likely still active iPhones from only five shipping years. That is not the entire iPhone base, but deliberately a limited slice. Older A14/A15 generations were in the low double-digit TOPS range, A16 at just under 17 TOPS, and A17 Pro at around 35 TOPS. That is why an annual average makes more sense than pretending every device has the same chip.

Now the same game again: 6.5 hours at night on power, not the whole day. If 25 percent of these devices participated, the result would be around 1'437 exa-operations per second as a daily equivalent. At 50 percent participation, it would be around 2'875 exa-operations per second. If all devices theoretically participated, the number would be about 5'750 exa-operations per second.

That sounds crazy. But that is exactly the point. Not because an iPhone is a server. But because the mass of devices is so large that even cautious quotas suddenly reach a scale we usually associate only with data centers.

The Comparison

As additional reference points, I use:

• 50 million desktop GPUs, workstations, or small servers that could deliver an average of 20 TFLOPS FP32. If only 20 percent of that were practically usable, around 200 exa-operations per second would remain in suitable time windows.
• xAI Colossus as a comparison from the data center world. With 200'000 Hopper GPUs and around 3'958 INT8 TOPS per H100-class GPU, you get roughly 792 exa-operations per second of theoretical AI peak performance. That is the sparsity peak; dense and continuously usable performance is lower.

This is not an exact global capacity number. It is a mental model. And this is exactly where we need to slow down: TOPS cannot simply be poured into a common pool like liters of water. Neural Engine TOPS in an iPhone, INT8 TOPS on a GPU, and FP32 performance on a workstation are different things. Many useful jobs need not only operations, but RAM, VRAM, memory bandwidth, stable runtime, software access, and an operating system that allows such jobs at all.

Still, the calculation shows why the idea is not ridiculous. Even a conservative combination of PCs, vehicles, and smartphones reaches a theoretical silicon scale that no longer looks absurdly small next to one of the most visible AI data centers in the world.

The iPhone number is especially interesting because it looks only at five shipping years, not the entire active installed base. At the same time, it is the best example of why peak performance is not enough: an iPhone is not a server. It has thermal limits, battery logic, operating system rules, privacy models, and an owner who expects a working device in the morning. Still, there is compute power there that would have looked like science fiction only a few years ago.

And even these peak values are only peak values. A smartphone, a fanless laptop, or a car control unit cannot simply deliver that kind of performance for six hours like a data center GPU. Heat, throttling, and protection logic massively reduce sustained performance. Anyone who wanted to build a real network from this would need to calculate with sustained performance, not the prettiest number from a data sheet.

You can also think about it in terms of electricity. If 50 million devices contributed an average of 150 watts for four hours per day, that would be about 11 TWh per year. That is only a small fraction of today’s global data center consumption. But it would be enough to carry many background jobs, embeddings, scientific workloads, rendering, verification tasks, or decentralized storage processes.

The uncomfortable objection is this: it is not automatically more efficient. Data centers have better cooling, better utilization, cheaper power, newer hardware, and professional batching. A home device can look worse per useful unit of compute, especially if there is a lot of overhead or if a smartphone battery ages faster for a few cents of credits. A decentralized compute grid would therefore not be good just because it is distributed. It would have to make net sense for suitable workloads: technically, energetically, and economically.

It becomes even more interesting with new AI PCs. Canalys expected around 100 million AI PCs to ship in 2025. Many of these devices bring NPUs with 40 TOPS or more. TOPS is not the same as GPU FLOPS, and an NPU does not replace a data center. But even when viewed very cautiously, a new class of local AI hardware is emerging, not just on paper, but in offices and homes.

So the point is not: “Tomorrow we replace all data centers with gaming PCs, Teslas, and iPhones.” The point is: we are building enormous new central capacity while a huge amount of distributed, already paid-for capacity expires unused at the same time.

Compute Is Perishable

I can store electricity. Not perfectly, not without losses, but in principle. If my solar system produces more at noon than I need, energy goes into a battery or into the grid. In the evening I can use it again, or my neighbor can use it. Smart grids, battery storage, and peer-to-peer energy models are making this way of thinking more concrete: sometimes I produce, sometimes I consume, and the boundary between customer and provider becomes softer.

Compute power works differently.

I cannot pull an unused GPU hour from yesterday out of a drawer today. A processor that did nothing for a night has not saved compute power for later. That time is gone. Irretrievably. Compute is perishable.

That is exactly what makes unused devices interesting. We do not just have hardware. We have constantly expiring opportunities. The realistic near-term pool is mainly desktop GPUs, workstations, game consoles, small servers, NAS storage, and campus or provider resources. Smartphones and cars are more like long-term edge cases: technically fascinating, but much harder because of battery, heat, platform rules, security, and manufacturer control.

So it is not only the math that gets in the way, but also the incentive. The most interesting idle silicon sits on closed platforms, of all places: Apple is building its own infrastructure for large Apple Intelligence requests with Private Cloud Compute, while Tesla is building its own training capacity for FSD and Optimus with Cortex. Why would these companies open their device fleets for a manufacturer-independent compute market when control over hardware, software, and cloud is the real moat?

Still, the basic question remains: why do we treat distributed compute power as if it were irrelevant while we build ever larger central facilities at the same time?

Can AI Even Run in a Decentralized Way?

Here we need to be honest: for much of what is visible as AI today, decentralization is difficult.

A large language model is not simply a list of small tasks that you can throw onto arbitrary third-party devices. Models need RAM or VRAM. They need memory bandwidth. Sometimes they need fast interconnects. During token generation, the model is run again and again, and every additional network hop makes the answer slower. Splitting a frontier model across strangers’ smartphones, old laptops, and cars would usually be nonsense for an interactive chat response.

But that does not mean decentralized AI is impossible. It only means you have to choose the right tasks.

Work that does not need to finish in two seconds is a very good fit: embeddings for large archives, batch summaries, rendering, scientific simulations, synthetic data, tests, crawling, verification tasks, decentralized storage repair, small local models, preprocessing, and tasks where results can be checked or computed more than once.

In practice, tasks would need to be separated much more cleanly:

Large models are not completely excluded either, but they need a different architecture. Petals has shown that collaborative inference and fine-tuning of large models across distributed resources is possible in principle. Prime Intellect goes one step further with INTELLECT-2 and shows how distributed reinforcement learning can work with untrusted workers when results are verified. That is not yet the world where your iPhone secretly trains GPT-7 at night. But it is a sign that the problem is not impossible in principle.

The realistic starting point would therefore not be: “We distribute one huge model across everything.” The realistic starting point would be: local models first, regional pools for suitable batch jobs, verifiable tasks, clear data zones, and central data centers only where they are truly needed.

The Old Dream of Distributed Systems

There is another story of the internet. One that sounds less like a cathedral and more like a swarm.

Volunteer Computing

SETI@home was always one of the most beautiful examples to me. Millions of people let their computers process radio astronomy data in the background. Not because they got a SaaS dashboard for it, but because the idea was big enough: together, we are searching for signals in the noise of the universe. Since March 2020, SETI@home has not distributed new work units and is in a kind of hibernation. But as proof that volunteer computing can work globally, it remains important.

BOINC, the platform behind it and alongside it, describes very soberly why this works: many independent, compute-intensive jobs where throughput matters more than low latency. That is the decisive difference. A distributed system does not have to deliver every interactive chat response in two seconds. It can be strong where work is divisible, verifiable, and not due immediately.

Storage Without a Fixed Place

IPFS carries the same thought into storage. Files are not primarily addressed by a place, but by their content. The content has a fingerprint. Whoever has it can deliver it. That is a different way of thinking from “this file lives on this server at this URL.”

Money Without Central Bookkeeping

Bitcoin, completely independently of how you judge speculation and energy consumption, made a similar core idea popular: a system without central bookkeeping, where consensus does not depend on a single institution. Not every decentralized idea is automatically good. But Bitcoin showed that a protocol can be politically powerful when it removes the central control point.

Storage as a Network

There have also been interesting attempts in storage. Symform was a decentralized cloud storage provider where surplus storage could be contributed to a network. In 2014, the platform was acquired by Quantum; at that point, there was talk of 45'000 users and small businesses in 170 countries. Storj, Sia, Filecoin, and other variants show the same thing: the idea is not new. It just never quite arrives in everyday use.

Today, this idea lives on in new forms. Storj splits files client-side, encrypts them, and distributes pieces across many storage nodes. That is closer to infrastructure than romance: ideally, the user does not see the swarm, but a storage service that works.

Compute as a Marketplace

Golem and Akash want to make unused compute power accessible as a marketplace. To me, that is the direct bridge to this article: not only storage space is scattered around, but also processors, GPUs, and small servers that often sit idle today.

AI in the Distributed Swarm

Andrej Karpathy shows up in this environment too: Prime Intellect names him as a prominent supporter, and with INTELLECT-2, Prime Intellect has started a decentralized distributed RL training run for a 32B-parameter model, where heterogeneous, permissionless compute resources can contribute.

That is not the perfect answer yet. But it shows that the dream has not disappeared. It is simply still looking for a form that survives real operations.

Learning from the Virtual Power Plant

The interesting part is that this way of thinking already sounds much less exotic in electricity.

Tesla describes its Virtual Power Plant as a network of distributed energy resources: homes with solar systems and Powerwalls are aggregated and treated like a power plant. When the grid needs support, batteries can feed electricity back. The owner provides a resource and receives money or other benefits. Individual Powerwalls are small. Together, they can become relevant for the grid.

That is exactly the analogy that fascinates me with compute. A single GPU in a home office, a single NAS, a single iPhone, or a single car is not a data center. But many devices together could form a new layer: not for everything, not at any time, not without rules, but for certain tasks.

The analogy has limits. Electricity is much more fungible than compute work. A kilowatt-hour does not depend on whether it is supposed to run a model with 80 GB of VRAM, an embedding pipeline, or an encrypted storage repair. Compute depends on the workload. That is exactly why it needs job classes, scheduling, and hard exclusions.

With Tesla, you can see the same idea in two places. Powerwalls can become part of a virtual power plant. Cars are expected, eventually, to become part of an autonomous robotaxi fleet, earning money when the owner is not using them. Whether and how quickly that really scales is another question. But the basic idea matters: a private device is no longer merely something you consume; in free time windows, it can work as infrastructure.

Compute could be imagined in a similar way. Not as selling electricity to the neighbor, but as selling verifiable compute time, storage space, or model work to a regional cell. The user ultimately pays for electricity, heat, hardware wear, and risk. So the user must also be compensated. Without that point, the idea is only a pretty technical experiment.

Why the Swarm So Rarely Wins

If decentralization sounds so beautiful, why does it not simply win?

Because centralization is often the better product package.

A data center is controllable. A swarm consists of other people’s devices, different operating systems, changing availability, poor predictability, and owners who turn off, sell, update, or disconnect their device. For a product manager, that is not romance, but a headache.

Then there is the economics. Many decentralized projects have tried to solve incentives with tokens. That is understandable, because a network without a central company still needs compensation. But as soon as the cost of storage or compute time is tied to a volatile currency, it becomes unattractive for normal companies. I do not want my terabyte of backup to suddenly become more expensive because a coin is pumped on Twitter. I also do not want my GPU-hour budget to depend on a market that feels more like a casino than infrastructure.

And the price competitor is not the most expensive on-demand GPU in the cloud. The real comparison is spot and preemptible offers, meaning already surplus data center capacity that providers sell at a significant discount. A decentralized compute network would therefore not only have to be philosophically nicer. It would have to hold up against very cheap, well-integrated, albeit interruptible, cloud capacity.

The second obstacle is convenience. S3 did not win because it is philosophically beautiful. It won because it is simple enough, documented enough, and integrated everywhere. If decentralized storage or compute networks want to matter, they have to feel almost boring to developers and admins: enter an API key, create a bucket, monitoring, invoice, SLA, restore test, done.

Then comes security. In an enterprise network, some random outside compute job should not suddenly arrive inbound on workstations. Any reasonable firewall would block that, and threat intelligence systems would find it suspicious. In practice, such a system would need to work more from the inside out: the node checks in with a cell, fetches verified jobs, runs in a sandbox, and sees only data it is allowed to see. Otherwise, on the network layer, a legitimate compute network quickly looks like a very politely worded botnet.

Trust is the next hard point. Decentralized systems need to prove that work was done correctly without every node being allowed to see everything. For storage, there are known building blocks: encryption, erasure coding, audits, repair mechanisms. For AI and compute, it becomes harder. How do I check whether a third-party device ran a model correctly? How do I prevent data leakage? How do I protect the participant’s device from foreign code?

Hardware wear is more than electricity too. SSDs and NVMe storage have write limits. Anyone constantly writing model weights, temporary data, embedding batches, or swap files to consumer devices is consuming real lifespan. Then there is the bandwidth problem: if downloading a large model or dataset takes longer and creates more network overhead than the actual calculation, the equation flips. Data is heavier than the simple smart-grid metaphor suggests.

This is exactly where INTELLECT-2 becomes interesting. In its paper, Prime Intellect describes TOPLOC as a building block that verifies rollouts from untrusted inference workers. That does not suddenly solve every compute problem. It is not magical privacy for arbitrary company data on third-party hardware. But it shows a real mechanism for a specific class of distributed AI work: jobs are built so results can be verified instead of trusting every worker blindly.

For confidential data, that alone is not enough. Other building blocks would be needed: Confidential Computing, Trusted Execution Environments, Remote Attestation, clean sandboxes, clear data classification, and, when in doubt, the hard decision not to run certain jobs on third-party hardware at all. Then there are boring but decisive questions: taxation, liability, privacy, data residency, and the terms of internet providers. Infrastructure rarely fails only because of math. Often it fails because of operations.

A Compute Smart Grid

I am not imagining a naive “everything is P2P and then everything will be fine.” That is not how infrastructure works. What could work is a compute smart grid with clear layers.

The first layer is: local first. Everything personal, confidential, or latency-critical should run, as much as possible, on the user’s own device or in their own trust zone. Small models, local search, private summaries, simple classification, preprocessing, encryption, embeddings for personal data. Not every email, every note, and every search needs to go to a hyperscaler.

The second layer would be regional and federated. A city, a neighborhood, a campus, a company, a cooperative, or a provider could operate a cell. In that cell, devices voluntarily provide resources, but only under clear conditions: only on power, only when idle, only within thermal limits, only with a defined maximum power draw, only for certain job classes.

The starting point would not be smartphones and cars, but the more boring devices: desktop GPUs, workstations, game consoles, small servers, NAS systems, and free capacity at local providers. Smartphones could later take on small verification jobs. Cars might be conceivable even later, within very tight, manufacturer-controlled limits. Just as in the electricity grid, you would first need to start with resources that are reliable, measurable, and controllable.

The third layer remains central. Frontier training, hard real time, extremely large models, regulatory edge cases, and workloads with high coupling still belong in professional data centers. Decentralization does not have to replace everything. It only has to prevent every ordinary task from automatically running through the same five centers of power.

If you wanted to test this, I would start small. Not with millions of iPhones, but with a regional cell of perhaps 500 to 2'000 volunteer desktop GPUs, workstations, NAS systems, and small servers. Only a few job types would be allowed: embeddings for non-sensitive data, scientific batch jobs, encrypted storage pieces, and verification tasks. Success would not be measured by a pretty exa-number, but by three boring metrics: completed jobs per $1 of electricity cost, error and retry rate, and payout after hardware wear.

The hardest part would be compensation. The user pays for electricity, heat, and hardware wear. So the user needs something back. It would probably need a token or credit. But not as a speculation object. As an infrastructure credit.

Such a compute credit would need to stand for something real: a GPU minute of a certain class, a GB-month of storage, a verified inference, a batch embedding unit, or a kWh-equivalent compute unit. Whoever contributes resources earns credits. Whoever later needs AI capacity spends them. Whoever does not want to spend them could cash them out in fiat, similar to a virtual power plant where you do not want to be paid in “Powerwall coins,” but in real money or a clear credit.

That does not magically solve the pricing question. Stability needs an anchor: fiat billing, energy price corridors, regional clearing houses, cooperative tariffs, or regulated operators. Without governance, “stable credits” quickly become just another freely floating token. And then you are back at the old problem: infrastructure feels like a casino.

Even more important is the question of operating rights. We do not have to train every large foundation model ourselves. Maybe models, open weights, or model families are purchased or licensed and then operated in a decentralized, federated, regionally controlled way. The actual sovereignty would then lie not only in training, but in operations: where do the models run? Where is the data stored? Who is allowed to audit? Is there a back channel to the provider? Can I keep running the model locally if politics, prices, or terms change?

For that to be more than a pretty purchasing contract, such licenses would need real operating rights: local deployments, long-term update and security commitments, understandable model cards, auditability, clear exit rights, and no obligation to push sensitive data back into the central vendor cloud. That would not be the pure decentralized utopia. But it would be a realistic path between naive self-sufficiency and total platform lock-in.

The Night When Devices Compute

Imagine it is 10:43 p.m. Your desktop with a GPU is idle, the NAS is online, the phone is charging. In the settings you have defined: maximum 80 watts, only when idle, only for verified workloads from the region, and only if compensation covers electricity costs plus a hardware allowance.

A local agent reports free capacity. Not with your name and not with your private data, but as an attested node with certain capabilities. The cell distributes small jobs: simulations, embeddings, encrypted storage pieces, verification tasks.

In the morning there is no rocket, no Wall Street story, no hype token. Just a sober line:

Tonight: earned 2.4 GPU credits, confirmed 18 GB-months storage, estimated $0.31 electricity cost.

Later, you use these credits for a local model over your own documents. The sensitive data stays with you. You are not only a customer. You are a participant.

That sounds romantic. Yes. But sometimes that is exactly the reason to take a difficult engineering problem seriously.

The Swarm and the Mountain

I do not believe central data centers will disappear. They are too efficient, too important, and simply necessary for some tasks. The mountain remains. The only question is whether we build a base next to it again.

A base made of local devices, regional cells, open protocols, stable credits, and clear security models. A base where compute power is not only sold from top to bottom, but flows between participants. A base where certain AI work runs where it belongs: private work locally, regional work regionally, global edge cases in the data center.

Maybe that is naive. Maybe not. Virtual power plants were once a strange idea too: thousands of small batteries as one large network. Decentralized money sounded absurd for a long time. Cars that autonomously drive as taxis sounded like science fiction. Not all of it will arrive as promised. But the direction is clear: resources that used to stand around passively are increasingly being treated as part of a larger system.

Right now, unused machines are everywhere. In apartments, offices, garages, server rooms, and pockets. Not all of them are equally suitable. Not all of them should ever run third-party work. But many are already there, paid for and networked. And every unused second disappears.

Maybe we should start listening to them.

Until next time,
Joe