La capacidad de cómputo desaprovechada que nos rodea

A veces una gran pregunta de infraestructura empieza con una imagen muy pequeña: un smartphone se carga por la noche. El portátil está cerrado. La consola espera en el salón. El coche está aparcado en el garaje. En todas partes hay capacidad de cómputo que ya está pagada, recibe electricidad y la mayor parte del tiempo no hace nada.

Al mismo tiempo se construyen nuevos centros de datos, tan grandes como instalaciones industriales. Naves llenas de GPUs, fibra, transformadores, refrigeración y contratos eléctricos. Estamos construyendo una nueva capa de infraestructura digital llamada a sostener nuestra escritura, búsqueda, programación, análisis y quizá algún día también nuestras decisiones.

¿Y si una pequeña parte de esa potencia no se perdiera sin más? No como una fantasía salvaje en la que cada móvil sustituye de repente a un centro de datos. Sino como un experimento mental serio: ¿podría existir una especie de red inteligente de cómputo en la que los dispositivos aporten capacidad voluntariamente, con límites y a cambio de una compensación?

En el artículo De PRISM a los prompts hablo del otro lado de este desarrollo: la dependencia creciente de unas pocas plataformas de IA, sobre todo de Estados Unidos y China. Aquí me interesa la idea contraria. No como romanticismo P2P ingenuo, sino como pregunta técnica: ¿cuánta capacidad de cómputo ya está repartida por ahí, qué tareas de IA podrían distribuirse realmente y qué tendría que pasar para que las personas reciban una compensación justa?

El experimento mental

La IA no es solo software. La IA es electricidad, refrigeración, fibra, GPUs, suelo, agua y capital. La Agencia Internacional de la Energía estima que los centros de datos consumieron en 2024 unos 415 TWh de electricidad en todo el mundo, alrededor del 1,5 por ciento del consumo eléctrico global. En 2030 podrían ser unos 945 TWh.

Eso no es solo una cifra para informes de sostenibilidad. Es política de infraestructura. Los servicios de IA están disponibles 24/7. Cada resumen, cada pregunta de código, cada imagen, cada ejecución de un agente es un cálculo. Y cuando miles de millones de personas y empresas meten trabajo en bucles de IA, eso se convierte en carga base.

Por eso entiendo la fascinación por las grandes soluciones centrales. Los centros de datos son controlables: el mismo hardware, los mismos racks, las mismas redes, zonas de seguridad claras, SLAs, monitorización, facturación. Desde el punto de vista operativo, eso es atractivo. Pero política, económica y arquitectónicamente vuelve a crear exactamente aquello que siempre nos ha hecho vulnerables en la red: unos pocos centros de poder.

El experimento mental empieza por eso con una contrapregunta sencilla: ¿qué hay ya antes de construir el próximo centro de datos?

¿Qué tamaño tiene la capacidad sin usar?

La idea nace en realidad en un momento completamente cotidiano. El smartphone está de noche en la mesita, conectado a la corriente, haciendo casi nada. Pero dentro hay un chip con más capacidad de cómputo específica para IA que muchos ordenadores de hace diez años en conjunto. Un iPhone 15 Pro con A17 Pro alcanza alrededor de 35 billones de operaciones de Neural Engine por segundo. Incluso si se toma solo una media prudente, es absurdamente mucho para un dispositivo que pasa la mayor parte de la noche esperando.

Lo mismo ocurre en el escritorio. Los portátiles nuevos ya no tienen solo CPU y GPU, sino además NPUs o Neural Engines. Apple lleva años integrando una Neural Engine en sus chips. Los portátiles Windows llegan como AI PCs con procesadores de IA dedicados. Una consola en el salón tiene una potencia GPU que antes sonaba a estación de trabajo. Y aun así usamos esta capacidad local casi siempre solo en picos breves: un juego, una exportación, una videollamada, un efecto local, una búsqueda. Después el dispositivo vuelve al reposo.

Ahí empieza el experimento mental. No: “¿Puedo alquilar mañana mi iPhone como centro de datos?” Eso sería absurdo. Sino: si tanto silicio ya está pagado, conectado a la red y enchufado cada noche, ¿qué tamaño tendría la capacidad teórica si solo pudiéramos usar ventanas pequeñas, seguras y adecuadas?

No se puede medir con exactitud la capacidad de cómputo sin usar del mundo. Demasiados dispositivos son diferentes, demasiados están desconectados, demasiados no pueden participar por batería, calor, seguridad o reglas de plataforma. Aun así, una estimación aproximada ayuda a hacerse una idea del orden de magnitud.

Para eso tomemos unos bloques deliberadamente simples. Lo importante: no calculo como si cada dispositivo estuviera siempre disponible al máximo. Calculo con ventanas de tiempo, cuotas de participación y descuentos prudentes. Sigue siendo un experimento mental, pero uno con números bajo los pies.

Tesla: silicio sobre ruedas

En junio de 2025, Tesla informó de su vehículo número ocho millones producido. No todos siguen activos, no todos tienen el mismo hardware de Autopilot y no todos los propietarios liberarían su coche para una red de cómputo. Así que calculo de forma conservadora:

• De 8 millones de vehículos producidos, quizá un 80 por ciento siga activo y sea técnicamente relevante. Eso serían 6,4 millones de vehículos.
• Para Hardware 3, es decir, el FSD Computer desde 2019, se menciona a menudo un orden de magnitud de 144 TOPS para el sistema.
• Hardware 4 está en vehículos más nuevos y es más moderno, pero Tesla no publica para él un valor TOPS limpio y simple como en las cifras antiguas del Autonomy Day. Para este cálculo uso por tanto igualmente 144 TOPS como base conservadora.
• Un coche puede estar parado 23 horas al día, pero lo interesante de verdad es la ventana de carga. Si está 6,5 horas conectado por la noche, eso equivale de media en 24 horas a aproximadamente un 27 por ciento de disponibilidad.

Si solo el 25 por ciento de estos propietarios activos de Tesla se registrara, serían 1,6 millones de vehículos y unas 62 exaoperaciones por segundo como equivalente diario. Con un 50 por ciento de participación serían unas 125 exaoperaciones por segundo. Si en teoría todos los vehículos activos participaran, la cifra estaría alrededor de 250 exaoperaciones por segundo. En la propia ventana nocturna la potencia instantánea sería mayor; la cifra equivalente diaria es solo la comparación más justa con un centro de datos que funciona 24 horas.

iPhones: la sorpresa mayor

Con los iPhones, el cálculo es a la vez más fácil y más difícil. Más fácil porque Apple entrega cantidades enormes cada año. Más difícil porque Apple no ofrece una tabla pública limpia sobre qué generaciones de iPhone siguen activas en todo el mundo. Así que tomo los envíos publicados de los últimos años y aplico una cuota activa restante plausible.

Esta mezcla da unos 885 millones de iPhones probablemente todavía activos de solo cinco años de entregas. No es toda la base de iPhones, sino un recorte deliberadamente limitado. Las generaciones A14/A15 antiguas estaban en el rango bajo de dos dígitos TOPS, A16 en algo menos de 17 TOPS, A17 Pro en torno a 35 TOPS. Por eso tiene más sentido usar una media por año que fingir que todos los dispositivos tienen el mismo chip.

Ahora el mismo juego: 6,5 horas por la noche enchufados, no todo el día. Si participara el 25 por ciento de estos dispositivos, se llegaría a unas 1'437 exaoperaciones por segundo como equivalente diario. Con un 50 por ciento de participación serían unas 2'875 exaoperaciones por segundo. Si teóricamente participaran todos los dispositivos, la cifra estaría alrededor de 5'750 exaoperaciones por segundo.

Suena disparatado. Pero de eso se trata precisamente. No porque un iPhone sea un servidor. Sino porque la masa de dispositivos es tan grande que incluso cuotas prudentes llegan de repente a un orden de magnitud que normalmente atribuimos solo a centros de datos.

La comparación

Como otros puntos de referencia tomo:

• 50 millones de GPUs de escritorio, estaciones de trabajo o servidores pequeños que podrían entregar de media 20 TFLOPS FP32. Si solo el 20 por ciento fuera utilizable en la práctica, quedarían unas 200 exaoperaciones por segundo en ventanas adecuadas.
• xAI Colossus como comparación del mundo de los centros de datos. Con 200'000 GPUs Hopper y unos 3'958 INT8-TOPS por GPU de clase H100, se llega a aproximadamente 792 exaoperaciones por segundo de pico teórico de IA. Es el pico con sparsity; el rendimiento denso y utilizable de forma continua queda por debajo.

No es una capacidad global exacta. Es un modelo para pensar. Y justo aquí hay que frenar: los TOPS no se pueden verter en un depósito común como litros de agua. Los TOPS de la Neural Engine de un iPhone, los TOPS INT8 de una GPU y el rendimiento FP32 de una estación de trabajo son cosas distintas. Muchos trabajos útiles no necesitan solo operaciones, sino RAM, VRAM, ancho de banda de memoria, tiempo de ejecución estable, acceso al software y un sistema operativo que permita esos trabajos.

Aun así, el cálculo muestra por qué la idea no es ridícula. Incluso una combinación conservadora de PCs, vehículos y smartphones alcanza como silicio teórico una escala que ya no parece absurdamente pequeña junto a uno de los centros de datos de IA más visibles del mundo.

La cifra de los iPhones es especialmente interesante porque solo mira cinco años de entregas, no toda la base instalada activa. Al mismo tiempo es el mejor ejemplo de por qué el rendimiento pico no basta: un iPhone no es un servidor. Tiene límites térmicos, lógica de batería, reglas del sistema operativo, modelos de privacidad y un propietario que espera un dispositivo funcional por la mañana. Aun así, allí hay capacidad de cómputo que hace pocos años habría parecido ciencia ficción.

E incluso esos valores pico son solo valores pico. Un smartphone, un portátil sin ventilador o una unidad de control de coche no puede entregar esa potencia seis horas seguidas como una GPU de centro de datos. La temperatura, la reducción de frecuencia y la lógica de protección reducen mucho el rendimiento sostenido. Quien quisiera construir una red real con esto tendría que calcular con rendimiento sostenido, no con la cifra más bonita de la ficha técnica.

También se puede pensar desde la electricidad. Si 50 millones de dispositivos aportaran de media 150 vatios durante cuatro horas al día, serían unos 11 TWh al año. Es solo una pequeña fracción del consumo global actual de los centros de datos. Pero bastaría para sostener muchos trabajos de fondo, embeddings, cargas científicas, renderizado, tareas de verificación o procesos de almacenamiento descentralizado.

La objeción incómoda es: eso no tiene por qué ser automáticamente más eficiente. Los centros de datos tienen mejor refrigeración, mejor utilización, electricidad más barata, hardware más nuevo y batching profesional. Un dispositivo doméstico puede salir peor por unidad útil de cómputo, sobre todo si hay mucho overhead o si la batería de un smartphone envejece más rápido por unos pocos céntimos de créditos. Una red descentralizada de cómputo no sería buena solo por estar distribuida. Tendría que tener sentido neto para cargas adecuadas: técnico, energético y económico.

La cosa se vuelve aún más interesante con los nuevos AI PCs. Canalys esperaba unos 100 millones de AI PCs entregados en 2025. Muchos de estos dispositivos traen NPUs con 40 TOPS o más. TOPS no es lo mismo que GPU-FLOPS, y una NPU no sustituye a un centro de datos. Pero incluso mirado con mucha prudencia, surge una nueva clase de hardware local de IA que no existe solo sobre el papel, sino que llega a oficinas y viviendas.

La idea central no es por tanto: “Mañana sustituimos todos los centros de datos por PCs gaming, Teslas e iPhones.” La idea central es: estamos construyendo una capacidad central gigantesca mientras, al mismo tiempo, se pierde sin usarse una enorme cantidad de capacidad distribuida y ya pagada.

El cómputo es perecedero

Puedo almacenar electricidad. No perfectamente, no sin pérdidas, pero en principio sí. Si mi instalación solar produce al mediodía más de lo que necesito, la energía va a una batería o a la red. Por la noche puedo volver a usarla, o la usa mi vecino. Las smart grids, las baterías y los modelos peer-to-peer de energía hacen esta forma de pensar cada vez más concreta: a veces produzco, a veces consumo, y la frontera entre cliente y proveedor se vuelve más suave.

La capacidad de cómputo funciona de otra manera.

Una hora de GPU sin usar ayer no puedo sacarla hoy de un cajón. Un procesador que no hizo nada durante una noche no guardó capacidad para más tarde. Ese tiempo se fue. Irrecuperablemente. El cómputo es perecedero.

Eso es exactamente lo que hace interesantes a los dispositivos sin usar. No solo tenemos hardware. Tenemos posibilidades que se pierden constantemente. El pool realista a corto plazo son sobre todo GPUs de escritorio, estaciones de trabajo, consolas, servidores pequeños, almacenamiento NAS y recursos de campus o proveedores. Los smartphones y los coches son más bien casos periféricos a largo plazo: técnicamente fascinantes, pero mucho más difíciles por batería, calor, reglas de plataforma, seguridad y control del fabricante.

Así que no fallan solo las matemáticas, sino también el incentivo. Los dispositivos con el silicio ocioso más interesante pertenecen precisamente a plataformas cerradas: Apple construye con Private Cloud Compute su propia infraestructura para grandes peticiones de Apple Intelligence, Tesla con Cortex su propia capacidad de entrenamiento para FSD y Optimus. ¿Por qué deberían esas empresas abrir sus flotas de dispositivos a un mercado de cómputo independiente del fabricante, si el control sobre hardware, software y nube es precisamente su ventaja defensiva?

Aun así, queda la pregunta básica: ¿por qué tratamos la capacidad de cómputo distribuida como si fuera irrelevante mientras construimos instalaciones centrales cada vez más grandes?

¿Puede la IA calcular de forma descentralizada?

Aquí hay que ser honestos: para muchas cosas que hoy vemos como IA, la descentralización es difícil.

Un gran modelo de lenguaje no es simplemente una lista de tareas pequeñas que se puedan lanzar a dispositivos ajenos al azar. Los modelos necesitan RAM o VRAM. Necesitan ancho de banda de memoria. A veces necesitan interconexiones rápidas. Durante la generación de tokens, el modelo se ejecuta una y otra vez, y cada salto adicional de red hace más lenta la respuesta. Dividir un modelo de frontera entre smartphones ajenos, portátiles antiguos y coches sería casi siempre absurdo para una respuesta interactiva de chat.

Pero eso no significa que la IA descentralizada sea imposible. Solo significa que hay que elegir las tareas correctas.

Encajan muy bien los trabajos que no tienen que terminar en dos segundos: embeddings para grandes archivos, resúmenes por lotes, renderizado, simulaciones científicas, datos sintéticos, pruebas, crawling, tareas de verificación, reparación de almacenamiento descentralizado, pequeños modelos locales, preprocesamiento y tareas cuyos resultados se pueden comprobar o calcular varias veces.

En la práctica habría que separar las tareas con mucha más limpieza:

Los modelos grandes tampoco quedan completamente excluidos, pero necesitan otra arquitectura. Petals ha mostrado que la inferencia colaborativa y el fine-tuning de modelos grandes sobre recursos distribuidos son posibles en principio. Prime Intellect va un paso más allá con INTELLECT-2 y muestra cómo puede funcionar el reinforcement learning distribuido con workers no confiables cuando se verifican los resultados. Todavía no es el mundo en el que tu iPhone entrena GPT-7 en secreto por la noche. Pero es una señal de que el problema no es imposible por principio.

El inicio realista no sería por tanto: “Distribuimos un modelo enorme por todo.” El inicio realista sería: primero modelos locales, pools regionales para trabajos por lotes adecuados, tareas verificables, zonas de datos claras y centros de datos centrales solo donde sean realmente necesarios.

El viejo sueño de los sistemas distribuidos

Hay otra narración de Internet. Una que suena menos a catedral y más a enjambre.

Cómputo voluntario

SETI@home siempre me pareció uno de los ejemplos más bonitos. Millones de personas dejaban que sus ordenadores procesaran datos de radioastronomía en segundo plano. No porque recibieran un dashboard SaaS, sino porque la idea era lo bastante grande: buscamos juntos señales en el ruido del universo. Desde marzo de 2020, SETI@home ya no reparte nuevas work units y está en una especie de hibernación. Pero como prueba de que el cómputo voluntario puede funcionar globalmente, sigue siendo importante.

BOINC, la plataforma detrás y al lado de aquello, describe con sobriedad por qué funciona: muchos trabajos independientes e intensivos en cómputo, donde el rendimiento importa más que la baja latencia. Esa es la diferencia decisiva. Un sistema distribuido no tiene que entregar cada respuesta interactiva de chat en dos segundos. Puede ser fuerte donde el trabajo es divisible, verificable y no vence inmediatamente.

Almacenamiento sin lugar fijo

IPFS lleva el mismo pensamiento al ámbito del almacenamiento. Los archivos no se direccionan principalmente por un lugar, sino por su contenido. El contenido tiene una huella. Quien lo tiene puede entregarlo. Es una forma distinta de pensar a “este archivo está en este servidor bajo esta URL”.

Dinero sin contabilidad central

Bitcoin, independientemente de cómo se valore la especulación y el consumo energético, popularizó una idea original parecida: un sistema sin contabilidad central, en el que el consenso no depende de una sola institución. No toda idea descentralizada es automáticamente buena. Pero Bitcoin mostró que un protocolo puede ser políticamente poderoso cuando elimina el punto central de control.

Storage como red

En almacenamiento también hubo intentos interesantes. Symform fue un proveedor descentralizado de cloud storage en el que se podía aportar almacenamiento sobrante a una red. En 2014, Quantum adquirió la plataforma; en ese momento se hablaba de 45'000 usuarios y pequeñas empresas en 170 países. Storj, Sia, Filecoin y otras variantes muestran igualmente que la idea no es nueva. Solo que nunca termina de llegar al día a día.

Hoy esta idea vive en formas nuevas. Storj divide archivos en el cliente, los cifra y distribuye fragmentos entre muchos nodos de almacenamiento. Eso está más cerca de infraestructura que de romanticismo: en el mejor caso, el usuario no ve el enjambre, sino un servicio de almacenamiento que funciona.

Compute como mercado

Golem y Akash quieren hacer accesible la capacidad de cómputo sin usar como mercado. Para mí, esa es la conexión directa con este artículo: no solo hay espacio de almacenamiento repartido por ahí, sino también procesadores, GPUs y servidores pequeños que hoy suelen permanecer ociosos.

IA en el enjambre distribuido

Andrej Karpathy también vuelve a aparecer en este entorno: Prime Intellect lo menciona como un apoyo destacado, y con INTELLECT-2 Prime Intellect ha iniciado una ronda de entrenamiento RL distribuida y descentralizada para un modelo de 32B parámetros, en la que pueden contribuir recursos de cómputo heterogéneos y permissionless.

No es todavía la respuesta perfecta. Pero muestra que el sueño no ha desaparecido. Solo sigue buscando una forma que sobreviva en operación real.

Aprender de la central eléctrica virtual

Lo interesante es que esta forma de pensar ya suena mucho menos exótica en el ámbito eléctrico.

Tesla describe su Virtual Power Plant como una red de recursos energéticos distribuidos: casas con paneles solares y Powerwalls se consideran juntas como una central eléctrica. Cuando la red necesita apoyo, las baterías pueden entregar electricidad. El propietario proporciona un recurso y recibe dinero u otras ventajas. Una Powerwall individual es pequeña. Juntas pueden volverse relevantes para la red.

Esa es exactamente la analogía que me fascina con el cómputo. Una sola GPU en una oficina en casa, un solo NAS, un solo iPhone o un solo coche no es un centro de datos. Pero muchos dispositivos juntos podrían formar una capa nueva: no para todo, no siempre, no sin reglas, pero sí para tareas concretas.

La analogía tiene límites. La electricidad es mucho más fungible que el trabajo de cómputo. Un kilovatio hora no depende de si debe ejecutar un modelo con 80 GB de VRAM, una pipeline de embeddings o una reparación de storage cifrado. El cómputo depende de la carga de trabajo. Precisamente por eso necesita clases de trabajos, scheduling y exclusiones claras.

En Tesla se ve la misma idea incluso en dos lugares. Las Powerwalls pueden formar parte de una central eléctrica virtual. Los coches deberían, a futuro, formar parte de una flota autónoma de robotaxis, es decir, ganar dinero cuando el propietario no los usa. Si eso escalará realmente y a qué velocidad es otra pregunta. Pero la idea básica es importante: un dispositivo privado ya no se consume solo como producto, sino que puede trabajar como infraestructura en ventanas libres.

El cómputo podría pensarse de forma similar. No como venta de electricidad al vecino, sino como venta de tiempo de cómputo verificable, espacio de almacenamiento o trabajo de modelo a una célula regional. El usuario paga al final electricidad, calor, desgaste de hardware y riesgo. Por tanto, también debe recibir compensación. Sin ese punto, la idea no pasa de ser un experimento técnico bonito.

Por qué el enjambre gana tan pocas veces

Si la descentralización suena tan bonita, ¿por qué no se impone simplemente?

Porque la centralización suele ser el mejor paquete de producto.

Un centro de datos es controlable. Un enjambre está formado por dispositivos ajenos, sistemas operativos distintos, disponibilidad cambiante, mala previsibilidad y propietarios que apagan, venden, actualizan o desconectan su dispositivo. Para un responsable de producto eso no es romanticismo, sino dolor de cabeza.

A eso se suma la economía. Muchos proyectos descentralizados han intentado resolver los incentivos con tokens. Es comprensible, porque una red sin empresa central sigue necesitando compensación. Pero en cuanto los costes de almacenamiento o tiempo de cómputo se vinculan a una moneda volátil, se vuelve poco atractivo para empresas normales. No quiero que mi terabyte de backup se encarezca de repente porque una moneda se bombea en Twitter. Tampoco quiero que mi presupuesto de horas GPU dependa de un mercado que se parece más a un casino que a infraestructura.

Y el rival de precio no es la GPU on-demand más cara de la nube. La comparación real son las ofertas spot y preemptible, es decir, capacidad sobrante de centros de datos que los proveedores venden con descuentos claros. Una red descentralizada de cómputo no tendría por tanto que ser solo filosóficamente más bonita. Tendría que competir con capacidad cloud muy barata, bien integrada, aunque interrumpible.

El segundo freno es la comodidad. S3 no ganó porque fuera filosóficamente bonito. Ganó porque es lo bastante simple, está lo bastante documentado y está integrado en todas partes. Si las redes descentralizadas de storage o cómputo quieren ser relevantes, tienen que sentirse casi aburridas para desarrolladores y administradores: introducir la API key, crear el bucket, monitorización, factura, SLA, prueba de restauración y listo.

Luego viene la seguridad. En una red corporativa no debería aterrizar de repente en las estaciones de trabajo cualquier job de cómputo ajeno entrante. Cualquier firewall razonable lo bloquearía y para los sistemas de threat intelligence parecería sospechoso. En la práctica, un sistema así tendría que funcionar más bien de dentro hacia fuera: el nodo se registra en una célula, recoge jobs verificados, se ejecuta en una sandbox y ve solo los datos que puede ver. Si no, una red de cómputo legítima se parece rápidamente, a nivel de red, a una botnet formulada con mucha educación.

La confianza es el siguiente punto duro. Los sistemas descentralizados tienen que poder demostrar que el trabajo se realizó correctamente sin que cada nodo pueda verlo todo. En almacenamiento hay piezas conocidas: cifrado, erasure coding, auditorías, mecanismos de reparación. En IA y cómputo se complica más. ¿Cómo compruebo si un dispositivo ajeno ejecutó correctamente un modelo? ¿Cómo evito fuga de datos? ¿Cómo protejo el dispositivo del participante frente a código ajeno?

El desgaste de hardware también es más que electricidad. Los SSDs y NVMe tienen límites de escritura. Quien escribe constantemente pesos de modelos, datos temporales, lotes de embeddings o archivos swap en dispositivos de consumo consume vida útil real. A eso se suma el problema del ancho de banda: si descargar un modelo o dataset grande tarda más y genera más overhead de red que el cálculo en sí, la cuenta se cae. Los datos pesan más de lo que sugiere la metáfora simple de la smart grid.

Justo aquí INTELLECT-2 se vuelve interesante. Prime Intellect describe en su paper TOPLOC como una pieza que verifica rollouts de inference workers no confiables. Eso no resuelve de golpe todos los problemas de cómputo. No es privacidad mágica para datos empresariales arbitrarios en hardware ajeno. Pero muestra un mecanismo real para una clase concreta de trabajo de IA distribuido: los jobs se construyen para que los resultados sean verificables, en vez de confiar ciegamente en cada worker.

Para datos confidenciales, eso por sí solo no basta. Harían falta otras piezas: Confidential Computing, Trusted Execution Environments, Remote Attestation, sandboxes limpias, clasificación clara de datos y, en caso de duda, la decisión dura de no ejecutar ciertos jobs en hardware ajeno. Y además llegan preguntas aburridas pero decisivas: impuestos, responsabilidad, protección de datos, residencia de datos y términos de los proveedores de Internet. La infraestructura rara vez fracasa solo por las matemáticas. A menudo fracasa por la operación.

Una red inteligente de cómputo

No imagino un ingenuo “todo es P2P y entonces todo irá bien”. La infraestructura no funciona así. Lo que podría funcionar sería una red inteligente de cómputo con capas claras.

La primera capa se llama: local primero. Todo lo personal, confidencial o crítico en latencia debería ejecutarse, si es posible, en el propio dispositivo o en el propio espacio de confianza. Modelos pequeños, búsqueda local, resúmenes privados, clasificación simple, preprocesamiento, cifrado, embeddings para datos personales. No cada email, cada nota y cada búsqueda tiene que ir a un hyperscaler.

La segunda capa sería regional y federada. Una ciudad, un barrio, un campus, una empresa, una cooperativa o un proveedor podría operar una célula. En esa célula los dispositivos aportan recursos voluntariamente, pero solo bajo condiciones claras: solo conectados a la corriente, solo en idle, solo dentro de límites térmicos, solo con potencia máxima definida, solo para ciertas clases de trabajo.

El punto de partida no serían smartphones y coches, sino los dispositivos más aburridos: GPUs de escritorio, estaciones de trabajo, consolas, servidores pequeños, sistemas NAS y capacidad libre en proveedores locales. Los smartphones podrían asumir más tarde pequeños trabajos de verificación. Los coches serían concebibles aún más tarde, en límites muy estrechos y controlados por el fabricante. Igual que en la red eléctrica, primero habría que empezar con recursos fiables, medibles y controlables.

La tercera capa sigue siendo central. Entrenamiento de frontera, tiempo real estricto, modelos extremadamente grandes, casos especiales delicados por regulación y cargas de trabajo con mucho acoplamiento interno siguen perteneciendo a centros de datos profesionales. La descentralización no tiene que sustituirlo todo. Solo tiene que impedir que cada trabajo cotidiano pase automáticamente por los mismos cinco centros de poder.

Si se quisiera probar, yo empezaría pequeño. No con millones de iPhones, sino con una célula regional de quizá 500 a 2'000 GPUs de escritorio voluntarias, estaciones de trabajo, sistemas NAS y servidores pequeños. Solo se permitirían pocos tipos de trabajos: embeddings para datos no sensibles, trabajos científicos por lotes, fragmentos de storage cifrados y tareas de verificación. El éxito no se mediría con una bonita cifra exa, sino con tres métricas aburridas: jobs completados por cada $1 de coste eléctrico, tasa de error y repetición, y pago después del desgaste de hardware.

La parte más difícil sería la compensación. El usuario paga electricidad, calor y desgaste de hardware. Así que necesita algo a cambio. Probablemente haría falta un token o crédito. Pero no como objeto de especulación, sino como crédito de infraestructura.

Un crédito de cómputo así tendría que representar algo real: un minuto de GPU de una clase determinada, un GB-mes de almacenamiento, una inferencia verificada, una unidad de embeddings por lotes o una unidad de cómputo equivalente a kWh. Quien aporta recursos gana créditos. Quien más tarde necesita capacidad de IA los consume. Quien no quiere consumirlos podría cobrarlos en fiat, parecido a una central eléctrica virtual donde no quieres que te paguen en “Powerwall-Coins”, sino en dinero real o en una bonificación clara.

Pero eso no resuelve mágicamente la cuestión del precio. La estabilidad necesita un ancla: facturación fiat, corredores de precio energético, cámaras regionales de compensación, tarifas cooperativas u operadores regulados. Sin governance, los “créditos estables” se convierten rápidamente en otro token de libre fluctuación. Y entonces volvemos al viejo problema: la infraestructura se siente como un casino.

Más importante aún es la cuestión de los derechos de operación. No tenemos que entrenar nosotros mismos cada gran modelo fundacional. Quizá se compran o licencian modelos, pesos abiertos o familias de modelos y luego se operan de forma descentralizada, federada y regionalmente controlada. La soberanía real no estaría solo en el entrenamiento, sino en la operación: ¿dónde corren los modelos? ¿Dónde están los datos? ¿Quién puede auditar? ¿Hay un canal de retorno al proveedor? ¿Puedo seguir ejecutando el modelo localmente si cambian la política, los precios o los términos?

Para que eso sea más que un bonito contrato de compra, esas licencias tendrían que incluir derechos reales de operación: despliegues locales, compromisos largos de actualización y seguridad, fichas de modelo trazables, auditabilidad, derechos claros de salida y ninguna obligación de empujar datos sensibles de vuelta a la nube central del fabricante. No sería la utopía descentralizada pura. Pero sería un camino realista entre la autosuficiencia ingenua y el lock-in total de plataforma.

La noche en que los dispositivos calculan

Imagina que son las 22:43. Tu equipo de escritorio con GPU está en idle, el NAS está online, el móvil se está cargando. En los ajustes has definido: máximo 80 vatios, solo en reposo, solo para cargas de trabajo verificadas de la región y solo si la compensación cubre los costes eléctricos más una tarifa de hardware.

Un agente local informa de capacidad libre. No con tu nombre ni con tus datos privados, sino como nodo certificado con ciertas capacidades. La célula reparte pequeños jobs: simulaciones, embeddings, fragmentos de almacenamiento cifrado, tareas de verificación.

Por la mañana no hay cohete, ni historia de Wall Street, ni token de hype. Solo una línea sobria:

Esta noche: 2,4 créditos GPU ganados, 18 GB-meses de storage confirmados, $0.31 de electricidad estimados.

Más tarde usas esos créditos para un modelo local sobre tus propios documentos. Los datos sensibles se quedan contigo. No eres solo cliente. Eres participante.

Suena romántico. Sí. Pero a veces esa es precisamente la razón para tomarse en serio un problema difícil de ingeniería.

El enjambre y la montaña

No creo que los centros de datos centrales desaparezcan. Son demasiado eficientes, demasiado importantes y para algunas tareas simplemente necesarios. La montaña permanece. La pregunta es solo si volvemos a construir un suelo al lado.

Un suelo hecho de dispositivos locales, células regionales, protocolos abiertos, créditos estables y modelos de seguridad claros. Un suelo en el que la capacidad de cómputo no solo se vende de arriba abajo, sino que fluye entre participantes. Un suelo en el que cierto trabajo de IA corre donde corresponde: trabajo privado localmente, trabajo regional regionalmente, casos límite globales en el centro de datos.

Quizá sea ingenuo. Quizá no. Las centrales eléctricas virtuales también fueron una vez una idea extraña: miles de baterías pequeñas como una gran red. El dinero descentralizado sonó absurdo durante mucho tiempo. Coches que conducen solos como taxis sonaban a ciencia ficción. No todo llegará como se prometió. Pero la dirección es clara: los recursos que antes estaban pasivos se piensan cada vez más como parte de un sistema mayor.

Ahora mismo hay máquinas sin usar por todas partes. En viviendas, oficinas, garajes, salas de servidores y bolsillos. No todas sirven igual de bien. No todas deberían ejecutar jamás trabajo ajeno. Pero muchas ya están ahí, pagadas y conectadas. Y cada segundo sin usar desaparece.

Quizá deberíamos empezar a escucharlas.

Hasta la próxima,
Joe