Por qué no montaría un marketplace P2P de cómputo IA (y qué haría en su lugar)

La idea es atractiva y circula bastante: un marketplace donde cualquiera vende el cómputo ocioso de su portátil o de su GPU, pone su propio precio, y varios equipos modestos se juntan por internet para ejecutar un modelo grande que ninguno podría mover solo. Me puse a investigarla en serio, con papers, tarifas reales y la normativa española delante. Mi conclusión es que no lo construiría. Técnicamente no sirve para chat, económicamente el proveedor gana entre cero y nueve euros al mes, y legalmente choca con el RGPD y con el IVA de una forma que ningún contrato arregla.

Este post es la versión corta de esa investigación. Va en la misma línea que el de cómo mantener a raya la factura de 100k interacciones de IA al día: allí el problema era pagar menos por cada token, aquí es si tiene sentido fabricar esos tokens con hardware doméstico. Al final cuento qué sí haría en su lugar.

Lo que ya existe

A octubre de 2026 hay tres familias de proyectos, y cada una resuelve una parte del problema:

Marketplaces donde el proveedor fija el precio (Vast.ai, Clore, Akash, Octaspace). Alquilan GPUs enteras, no trozos de modelo, y dejan fuera a los portátiles: piden Linux, VRAM dedicada y buena conexión.
Redes que aceptan PCs de consumo (Salad, io.net, Distribute.ai). Aquí sí entra el equipo de casa, pero el precio lo pone la plataforma.
Motores que reparten un modelo entre varias máquinas por internet (Petals, Gradient Parallax, exo). Funcionan, pero nadie cobra ni paga.

Nadie opera en producción la combinación completa: pago, precio por proveedor y varios equipos débiles sirviendo un modelo grande. Petals, el único que lo intentó en abierto, lleva unos dos años sin commits y su propio panel de estado marca el swarm público como roto. Los diseños que sí unen las dos cosas siguen en testnet.

El historial del sector tampoco anima. Lilypad cerró en septiembre de 2025 por falta de financiación. Kuzco llegó a 8.000 dispositivos y acabó pivotando a modelos a medida para empresas. io.net pasó de unas 600.000 conexiones a unas 10.000 cuando empezó a verificar que las GPUs eran reales. Y el conjunto de proyectos DePIN (infraestructura física descentralizada) ha perdido un 83 % de capitalización desde marzo de 2024, con unos 72 millones de dólares de ingresos on-chain en 2025 repartidos entre más de 650 proyectos: unos 110.000 dólares por proyecto.

Los números que deciden

Si solo te quedas con una parte del post, que sea esta:

≈1,2 tokens por segundo para un Llama 3.3 70B repartido entre cinco portátiles de 16 GB, con 20-30 segundos hasta el primer token. Es una estimación mía a partir de RTT y ancho de banda de memoria, no una medición, pero los datos medidos que existen van en la misma dirección.
3-9 € al mes es lo que gana un portátil sin GPU dedicada en Salad, la única red que paga CPU, según sus tarifas de septiembre de 2026 y con luz a 0,20 €/kWh. Una RTX 3060 directamente pierde dinero.
0,10 $ / 0,32 $ por millón de tokens cuesta Llama 3.3 70B en las APIs más baratas. Servirlo en dos RTX 4090 alquiladas sale por unos 0,46 $, y aun pagando al proveedor el mínimo de Salad no baja de 0,13 $, sin margen para la red.
4,4 % de las GPUs inscritas en Salad estaban activas en un día típico (unas 20.000 de 450.000, febrero de 2025). La oferta sobra, lo que falta es demanda.
−83 % de capitalización del sector y unos 110.000 $ de ingresos por proyecto: los que sobreviven con ingresos reales tienen un operador central que decide scheduling, verificación y precio.

La física no negocia

Para repartir un modelo entre máquinas por internet solo hay una opción práctica: pipeline parallelism, es decir, cada equipo ejecuta un bloque de capas y pasa el resultado al siguiente. La alternativa, tensor parallelism, necesita sincronizar en cada capa y en cada token; en el benchmark de DeServe entre dos regiones de Google Cloud, vLLM con tensor parallelism directamente falló.

Con pipeline parallelism, cada token generado tiene que recorrer todas las etapas. La latencia por token es la suma del cómputo de cada etapa más el número de saltos multiplicado por el RTT. Con 50 ms entre nodos y cinco etapas ya gastas un cuarto de segundo por token solo en la red, antes de calcular nada. El paper de Petals lo midió: BLOOM-176B en diez RTX 3090 cae de 1,17 a 0,34 pasos por segundo al emular un enlace de 100 Mbit/s con 100 ms de RTT. Más etapas débiles multiplican la penalización.

Ni siquiera en red local el reparto sale gratis. exo consigue mover Kimi K2 (un billón de parámetros) a 25-32 tokens por segundo en cuatro Mac Studio M3 Ultra, unos 40.000 dólares de hardware, pero solo con RDMA sobre Thunderbolt 5; sin él baja a unos 5. Con llama.cpp por 10 GbE, Qwen2.5-72B pasa de 11,1 a 5,9 tokens por segundo al repartirlo. La regla que sale de todos los datos es sencilla: si el modelo cabe en una máquina, una máquina gana.

Esta tabla resume lo que daría cada configuración. Son estimaciones con supuestos explícitos (pesos a 4 bits, 10-11 GB útiles por portátil de 16 GB, 50 ms de RTT dentro de Europa), ancladas en las mediciones anteriores:

Modelo (4 bits)	Equipos	tok/s por usuario	Primer token	Veredicto
Llama 3.1 8B	1 portátil	15-50	<1 s	No necesita red
Qwen3-30B-A3B (MoE)	2 portátiles	≈8	≈3 s	Usable, pero un portátil de 32 GB lo gana
Qwen3-32B	3 portátiles	3-4	5-10 s	Marginal
Llama 3.3 70B	5 portátiles	≈1,2	20-30 s	No usable
Llama 3.3 70B	4× RTX 3060	≈5	≈15 s	Solo con fibra y prompts cortos
Qwen3-235B-A22B	14 portátiles	≈1,2	—	No usable

Para chat, "usable" significa al menos 5-10 tokens por segundo y menos de 3 segundos hasta el primer token. Solo la fila del MoE con pocos parámetros activos se acerca, y justo ese modelo cabe entero en un portátil con más memoria.

Verificar y proteger los datos tampoco está resuelto

Si pagas a desconocidos por ejecutar un modelo, necesitas saber que lo han ejecutado de verdad. No existe una prueba criptográfica barata para eso. Lo más práctico hoy es TOPLOC, de Prime Intellect: una huella de las activaciones que un validador comprueba repitiendo el prefill. Pero el validador necesita el modelo completo, no verifica el sampling y no cubre las etapas intermedias de un pipeline, que es justo el caso que nos interesa. Las soluciones con hardware de confianza (TEE) no existen para GPUs GeForce.

La privacidad está peor. Un paper de USENIX Security 2025 reconstruye el prompt a partir de las activaciones intermedias de Llama-2-7B con un token-F1 de 88 en la capa 2 y de 69 en la capa 16, y cuantizar a 4 u 8 bits no lo impide. Dicho de otra forma: cada nodo del pipeline puede leer, con bastante precisión, lo que el usuario ha escrito. Con datos personales de por medio, eso descarta el modelo entero.

La economía del proveedor

Supongamos que todo lo anterior se resolviera. ¿Cuánto ganaría alguien en España por dejar su equipo encendido? Con luz a 0,20 €/kWh, las tarifas que Salad publica por hardware y una utilización del 30 % (la única estimación independiente que encontré para un host doméstico con una GPU):

Hardware	Plataforma	Neto al mes (30 % uso)	Nota
Portátil sin GPU	Salad (CPU)	≈3 €	El resto de redes no acepta CPU
RTX 3060 12 GB	Salad / Clore	−2 € a 0 €	Pierde dinero con PVPC
RTX 4060 Ti 16 GB	Salad	2-8 €
RTX 4090	Salad	1-18 €	La depreciación (≈40 €/mes) se lo come
RTX 4090	Vast.ai	≈34 €	Exige ≈500 Mbps simétricos e IPv4 pública
RTX 5090	Vast.ai	≈54 €	Vast anuncia 175-350 $ al 80 % de uso

Y esas tarifas no son estables. En septiembre de 2026 Salad recortó un 25 % los pagos en quince clases de GPU porque los clientes no estaban pagando, mientras subía la 4090 y la 5090 por exceso de demanda. La propia Salad dice en su FAQ que no recomienda comprar una GPU para usarla con ellos. La propuesta de "instala una app y gana dinero con tu portátil" no cierra en España para nada por debajo de una 4090 ya amortizada con fibra simétrica.

Desde el lado del comprador el cuadro es igual de malo. El precio por capacidad fija de los modelos cae como mínimo 10× al año, mientras que alquilar una 4090 solo ha bajado de unos 0,50 $ la hora en 2024 a 0,34-0,44 $ en 2026. Cualquier ventaja de precio que encuentres con hardware doméstico se la come una API centralizada en menos de un año.

El problema legal en España

No soy abogado, y lo que sigue es lo que llevaría a una consulta vinculante antes de lanzar nada. Pero hay dos problemas estructurales que ningún contrato soluciona:

RGPD. La Opinión 22/2024 del EDPB dice que el responsable tiene que poder identificar y verificar a cada subencargado de la cadena. Con cientos de portátiles de particulares procesando prompts, eso es inviable. La AEPD ya ha multado contratos de encargo genéricos.
IVA. Según el art. 5.Uno.c de la LIVA, quien explota un bien para obtener ingresos continuados es empresario desde el primer euro, y la consulta DGT V1573-25 va en esa línea. Cada particular que alquila su GPU tendría que facturar con IVA. Eso mata la idea del ingreso pasivo para el proveedor.

Si además metes un token, necesitas una sociedad y probablemente autorización de la CNMV como proveedor de servicios de criptoactivos bajo MiCA. El periodo transitorio en España terminó el 1 de julio de 2026.

Dónde sí compite el hardware de consumo

No todo es negativo. Hay cargas donde una GPU doméstica bate a la API a nivel de cómputo, siempre en batch y nunca en tiempo real:

Transcripción. Whisper en una RTX 3060 sale por unos 0,006 $ por hora de audio, frente a 0,04 $ en Groq. Pero Salad ya lo vende a 0,03-0,08 $: el margen se lo queda la plataforma, no el proveedor. Y los portátiles x86 sin GPU no sirven, porque transcriben más despacio que el tiempo real.
Inferencia batch con MoE de pocos parámetros activos (clasificación, extracción, etiquetado). Es el único régimen donde una 4090 empata con las APIs más baratas, y solo con utilización alta.

Fuera de juego quedan el chat en tiempo real, los modelos densos de 70B o más y cualquier dato personal o confidencial.

Qué no haría

Una app para que particulares vendan su portátil.
Un token o créditos transferibles.
Repartir modelos por internet entre nodos que no controlo.
Verificación criptográfica propia: es un problema de investigación abierto.
Custodiar fondos de terceros.
Un router genérico "más barato que OpenRouter", que ya enruta a 94 proveedores con margen cero por token.

Qué haría en su lugar

Lo que sí veo viable es mucho más pequeño y menos vistoso: una pasarela de inferencia batch que solo use proveedores con región UE (Scaleway, OVH, IONOS) y que entregue el cumplimiento ya empaquetado para pymes y despachos españoles: DPA en castellano conforme al art. 28 del RGPD, lista de subencargados, marcado de salidas según el art. 50 del AI Act, registro de qué se procesó dónde y facturación con IVA correcta. Con un tier batch al 50 % de precio para los trabajos que pueden esperar unas horas.

Seamos honestos con sus límites. La tecnología es una capa fina, y una pyme podría firmar directamente con Scaleway. Lo que se vende es no tener que hacerlo: el enrutado, el papeleo y la relación. No es un ingreso pasivo; es un servicio con componente de producto. Por eso lo plantearía con mi propia carga de trabajo como primer cliente, unas seis semanas de MVP y una decisión a los 90 días: tres clientes externos de pago o se queda como herramienta interna. Si el soporte pasa de diez horas al mes por cliente, tampoco sale a cuenta.

Si estás en esta decisión. Si tienes una carga de IA en producción, o a punto de estarlo, y dudas entre seguir con APIs, montar GPU propia o mover el procesamiento a proveedores europeos, hago una evaluación de 4 horas, de pago, sobre tu caso: inventario de tu carga por modelo, coste real de cada opción con tus volúmenes, qué implica cada una en RGPD y AI Act, y una recomendación concreta. Escríbeme a info@shelakh.com con una línea sobre qué haces y te digo si tiene sentido.

Fuentes principales