Why I wouldn't build a P2P AI compute marketplace (and what I'd build instead)

The idea is appealing and comes up a lot: a marketplace where anyone sells the idle compute of their laptop or GPU, sets their own price, and several modest machines team up over the internet to run a large model none of them could handle alone. I researched it properly, with papers, real payout rates and Spanish regulation on the table. My conclusion is that I wouldn't build it. Technically it doesn't work for chat, economically the provider earns between zero and nine euros a month, and legally it runs into GDPR and VAT in ways no contract can fix.

This post is the short version of that research. It follows on from the one about keeping the bill for 100k daily AI interactions under control: there the problem was paying less for each token, here it's whether it makes sense to produce those tokens on consumer hardware. At the end I describe what I would build instead.

What already exists

As of October 2026 there are three families of projects, and each one solves part of the problem:

Marketplaces where the provider sets the price (Vast.ai, Clore, Akash, Octaspace). They rent whole GPUs, not slices of a model, and they leave laptops out: they want Linux, dedicated VRAM and a good connection.
Networks that accept consumer PCs (Salad, io.net, Distribute.ai). Your home machine is welcome here, but the platform sets the price.
Engines that split a model across machines over the internet (Petals, Gradient Parallax, exo). They work, but nobody pays or gets paid.

Nobody runs the full combination in production: payments, per-provider pricing and several weak machines serving one large model. Petals, the only project that tried it in the open, has gone about two years without a commit, and its own status page marks the public swarm as broken. The designs that do combine both halves are still on testnet.

The sector's track record doesn't help either. Lilypad shut down in September 2025 for lack of funding. Kuzco reached 8,000 devices and ended up pivoting to custom models for enterprises. io.net went from roughly 600,000 connections to about 10,000 once it started checking that the GPUs were real. And DePIN projects (decentralised physical infrastructure) as a group have lost 83% of their market cap since March 2024, with about $72M of on-chain revenue in 2025 spread across more than 650 projects: roughly $110K per project.

The numbers that decide it

If you only take one part of this post with you, make it this one:

≈1.2 tokens per second for Llama 3.3 70B split across five 16 GB laptops, with 20-30 seconds to the first token. That's my own estimate from RTT and memory bandwidth, not a measurement, but the measured data that does exist points the same way.
€3-9 a month is what a laptop without a dedicated GPU earns on Salad, the only network that pays for CPU, based on its September 2026 rates and electricity at €0.20/kWh. An RTX 3060 actually loses money.
$0.10 / $0.32 per million tokens is what Llama 3.3 70B costs on the cheapest APIs. Serving it on two rented RTX 4090s comes to about $0.46, and even paying providers Salad's floor rate it doesn't go below $0.13, leaving nothing for the network.
4.4% of the GPUs enrolled on Salad were active on a typical day (about 20,000 out of 450,000, February 2025). Supply isn't the problem; demand is.
−83% sector market cap and about $110K of revenue per project: the survivors with real revenue all have a central operator that controls scheduling, verification and pricing.

Physics doesn't negotiate

To split a model across machines over the internet there is only one practical option: pipeline parallelism, where each machine runs a block of layers and hands the result to the next. The alternative, tensor parallelism, has to synchronise on every layer for every token; in the DeServe benchmark between two Google Cloud regions, vLLM with tensor parallelism simply failed.

With pipeline parallelism, every generated token has to travel through every stage. Latency per token is the compute of each stage plus the number of hops times the RTT. With 50 ms between nodes and five stages you've already spent a quarter of a second per token on the network, before computing anything. The Petals paper measured it: BLOOM-176B on ten RTX 3090s drops from 1.17 to 0.34 steps per second when emulating a 100 Mbit/s link with 100 ms RTT. More weak stages multiply the penalty.

Splitting isn't free even on a local network. exo runs Kimi K2 (a trillion parameters) at 25-32 tokens per second on four Mac Studio M3 Ultras, about $40K of hardware, but only with RDMA over Thunderbolt 5; without it, it drops to around 5. With llama.cpp over 10 GbE, Qwen2.5-72B goes from 11.1 to 5.9 tokens per second when split. The rule that comes out of all the data is simple: if the model fits on one machine, one machine wins.

This table summarises what each setup would deliver. These are estimates with explicit assumptions (4-bit weights, 10-11 GB usable per 16 GB laptop, 50 ms RTT within Europe), anchored on the measurements above:

Model (4-bit)	Machines	tok/s per user	First token	Verdict
Llama 3.1 8B	1 laptop	15-50	<1 s	No network needed
Qwen3-30B-A3B (MoE)	2 laptops	≈8	≈3 s	Usable, but one 32 GB laptop beats it
Qwen3-32B	3 laptops	3-4	5-10 s	Marginal
Llama 3.3 70B	5 laptops	≈1.2	20-30 s	Not usable
Llama 3.3 70B	4× RTX 3060	≈5	≈15 s	Only with fibre and short prompts
Qwen3-235B-A22B	14 laptops	≈1.2	—	Not usable

For chat, "usable" means at least 5-10 tokens per second and under 3 seconds to the first token. Only the MoE row with few active parameters gets close, and that exact model fits entirely on a laptop with more memory.

Verification and data protection aren't solved either

If you pay strangers to run a model, you need to know they actually ran it. There is no cheap cryptographic proof for that. The most practical option today is TOPLOC, from Prime Intellect: a fingerprint of the activations that a validator checks by re-running the prefill. But the validator needs the full model, it doesn't verify sampling, and it doesn't cover the intermediate stages of a pipeline, which is exactly the case we care about. Trusted-hardware solutions (TEEs) don't exist for GeForce GPUs.

Privacy is worse. A USENIX Security 2025 paper reconstructs the prompt from Llama-2-7B's intermediate activations with a token-F1 of 88 at layer 2 and 69 at layer 16, and quantising to 4 or 8 bits doesn't stop it. Put differently: every node in the pipeline can read, fairly accurately, what the user typed. Once personal data is involved, that rules out the whole model.

The provider's economics

Suppose all of the above were solved. How much would someone in Spain earn by leaving their machine on? With electricity at €0.20/kWh, the per-hardware rates Salad publishes, and 30% utilisation (the only independent estimate I found for a single-GPU home host):

Hardware	Platform	Net per month (30% use)	Note
Laptop, no GPU	Salad (CPU)	≈€3	No other network accepts CPU
RTX 3060 12 GB	Salad / Clore	−€2 to €0	Loses money on Spain's regulated tariff
RTX 4060 Ti 16 GB	Salad	€2-8
RTX 4090	Salad	€1-18	Depreciation (≈€40/month) eats it
RTX 4090	Vast.ai	≈€34	Needs ≈500 Mbps symmetric and a public IPv4
RTX 5090	Vast.ai	≈€54	Vast advertises $175-350 at 80% use

And those rates aren't stable. In September 2026 Salad cut payouts by 25% across fifteen GPU classes because customers weren't paying, while raising the 4090 and 5090 because of excess demand. Salad's own FAQ says it doesn't recommend buying a GPU to use with them. The "install an app and earn money with your laptop" pitch doesn't add up in Spain for anything below an already paid-off 4090 on symmetric fibre.

From the buyer's side the picture is just as bad. The price for a fixed level of model capability falls at least 10× a year, while renting a 4090 has only dropped from about $0.50 an hour in 2024 to $0.34-0.44 in 2026. Any price advantage you find with consumer hardware gets eaten by a centralised API in less than a year.

The legal problem in Spain

I'm not a lawyer, and what follows is what I'd take to one, and to a binding ruling from the tax authority, before launching anything. But there are two structural problems no contract fixes:

GDPR. EDPB Opinion 22/2024 says the controller must be able to identify and verify every sub-processor in the chain. With hundreds of private laptops processing prompts, that's unworkable. The Spanish DPA (AEPD) has already fined generic processing agreements.
VAT. Under art. 5.Uno.c of Spain's VAT law, anyone who exploits an asset for ongoing income is a business from the first euro, and tax ruling DGT V1573-25 points the same way. Every individual renting out their GPU would have to invoice with VAT. That kills the passive-income idea for providers.

Add a token and you need a company and probably authorisation from the CNMV as a crypto-asset service provider under MiCA. Spain's transition period ended on 1 July 2026.

Where consumer hardware does compete

It's not all negative. There are workloads where a home GPU beats the API on raw compute, always in batch and never in real time:

Transcription. Whisper on an RTX 3060 costs about $0.006 per hour of audio, against $0.04 on Groq. But Salad already sells it at $0.03-0.08: the margin goes to the platform, not the provider. And x86 laptops without a GPU don't qualify, because they transcribe slower than real time.
Batch inference with low-active-parameter MoE models (classification, extraction, tagging). It's the only regime where a 4090 ties with the cheapest APIs, and only at high utilisation.

Out of the game: real-time chat, dense models of 70B and up, and any personal or confidential data.

What I wouldn't build

An app for individuals to sell their laptop's compute.
A token or transferable credits.
Splitting models over the internet across nodes I don't control.
My own cryptographic verification: it's an open research problem.
Custody of third-party funds.
A generic router "cheaper than OpenRouter", which already routes to 94 providers at zero margin per token.

What I'd build instead

What I do see as viable is much smaller and less flashy: a batch inference gateway that only uses providers with an EU region (Scaleway, OVH, IONOS) and ships compliance pre-packaged for Spanish SMEs and law firms: a Spanish-language DPA under GDPR art. 28, a sub-processor list, output marking under AI Act art. 50, a record of what was processed where, and correct VAT invoicing. Plus a batch tier at half price for jobs that can wait a few hours.

Let's be honest about its limits. The technology is a thin layer, and an SME could sign with Scaleway directly. What you're selling is not having to: the routing, the paperwork and the relationship. It isn't passive income; it's a service with a product component. That's why I'd start with my own workload as the first customer, about six weeks of MVP, and a decision at 90 days: three paying external customers or it stays an internal tool. If support goes past ten hours a month per customer, it doesn't pay off either.

If you're facing this decision. If you have an AI workload in production, or about to be, and you're torn between staying on APIs, running your own GPUs or moving processing to European providers, I run a paid 4-hour assessment of your case: an inventory of your workload by model, the real cost of each option at your volumes, what each one means for GDPR and the AI Act, and a concrete recommendation. Email me at info@shelakh.com with a line about what you do and I'll tell you whether it makes sense.

Main sources