La potenza di calcolo inutilizzata intorno a noi

A volte una grande domanda infrastrutturale comincia con un’immagine minuscola: uno smartphone è sul caricatore durante la notte. Il laptop è chiuso. La console da gioco aspetta in salotto. L’auto è in garage. Ovunque c’è potenza di calcolo già pagata, alimentata e quasi sempre inattiva.

Allo stesso tempo nascono nuovi data center grandi come impianti industriali. Capannoni pieni di GPU, fibra ottica, trasformatori, sistemi di raffreddamento e contratti energetici. Stiamo costruendo un nuovo strato di infrastruttura digitale che dovrà sostenere il nostro scrivere, cercare, programmare, analizzare e, forse un giorno, anche decidere.

E se una piccola parte di questa potenza non andasse semplicemente persa? Non come fantasia selvaggia in cui ogni telefono sostituisce improvvisamente un data center. Ma come esperimento mentale serio: potrebbe esistere una specie di smart grid del compute in cui i dispositivi mettono a disposizione potenza di calcolo in modo volontario, limitato e remunerato?

Nell’articolo Da PRISM ai prompt parlo dell’altro lato di questa evoluzione: la crescente dipendenza da poche piattaforme di IA, soprattutto dagli Stati Uniti e dalla Cina. Qui mi interessa l’idea opposta. Non come ingenua nostalgia P2P, ma come domanda tecnica: quanta potenza di calcolo è già distribuita là fuori, quali attività di IA potrebbero davvero essere distribuite, e cosa dovrebbe accadere perché le persone vengano pagate in modo equo?

L’esperimento mentale

L’IA non è semplicemente software. L’IA è elettricità, raffreddamento, fibra ottica, GPU, terreno, acqua e capitale. L’Agenzia Internazionale dell’Energia stima che nel 2024 i data center abbiano consumato circa 415 TWh di elettricità nel mondo, circa l'1,5 per cento del consumo globale. Entro il 2030 potrebbero arrivare a circa 945 TWh.

Non è solo un numero per i report di sostenibilità. È politica infrastrutturale. I servizi di IA sono disponibili 7x24. Ogni riassunto, ogni domanda sul codice, ogni immagine, ogni esecuzione di un agente è un calcolo. E quando miliardi di persone e aziende spostano lavoro dentro cicli di IA, tutto questo diventa carico di base.

Per questo capisco il fascino delle grandi soluzioni centrali. I data center sono controllabili: stesso hardware, stessi rack, stesse reti, zone di sicurezza chiare, SLA, monitoraggio, fatturazione. Dal punto di vista operativo è attraente. Ma politicamente, economicamente e architettonicamente ricrea proprio ciò che ha sempre reso vulnerabile la rete: pochi centri di potere.

L’esperimento mentale parte quindi da una semplice controdomanda: cosa esiste già, prima di costruire il prossimo data center?

Quanto è grande la capacità inutilizzata?

L’idea nasce in realtà da un momento molto quotidiano. Lo smartphone è sul comodino di notte, collegato alla corrente, e non fa quasi nulla. Dentro però c’è un chip con più potenza di calcolo specifica per l’IA di quanta molti computer di dieci anni fa avessero nel complesso. Un iPhone 15 Pro con A17 Pro arriva a circa 35 trilioni di operazioni Neural Engine al secondo. Anche prendendo solo una media prudente, per un dispositivo che aspetta per gran parte della notte è una quantità assurda.

Lo stesso succede sulla scrivania. I nuovi notebook non hanno più soltanto CPU e GPU, ma anche NPU o Neural Engine. Apple integra da anni una Neural Engine nei suoi chip. I notebook Windows arrivano come AI PC con processori IA dedicati. Una console da gioco in salotto ha una potenza GPU che un tempo avrebbe ricordato una workstation. Eppure usiamo questa potenza locale quasi sempre solo in picchi brevi: un gioco, un export, una videochiamata, un effetto locale, una ricerca. Poi il dispositivo torna in idle.

È qui che comincia l’esperimento mentale. Non: “posso affittare domani il mio iPhone come data center?” Sarebbe assurdo. Ma: se così tanto silicio è già pagato, collegato alla rete e alimentato ogni notte, quanto sarebbe grande la capacità teorica se si potessero usare solo piccole finestre temporali sicure e adatte?

Non si può misurare con esattezza la potenza di calcolo inutilizzata del mondo. Troppi dispositivi sono diversi, troppi sono offline, troppi non possono partecipare per motivi di batteria, calore, sicurezza o piattaforma. Però una stima grossolana aiuta a capire l’ordine di grandezza.

Prendiamo alcuni blocchi volutamente semplici. Il punto importante è questo: non calcolo come se ogni dispositivo fosse sempre disponibile a piena potenza. Uso finestre temporali, quote di partecipazione e sconti prudenti. Resta un esperimento mentale, ma con qualche numero a sostenerlo.

Tesla: silicio su ruote

Tesla ha annunciato a giugno 2025 l’ottavo milione di veicoli prodotti. Non tutti sono ancora attivi, non tutti hanno lo stesso hardware Autopilot e non tutti i proprietari autorizzerebbero la propria auto per una rete di calcolo. Quindi faccio un calcolo conservativo:

• Degli 8 milioni di veicoli prodotti, forse l'80 per cento è ancora realisticamente attivo e tecnicamente rilevante. Sarebbero 6,4 milioni di veicoli.
• Per Hardware 3, cioè il computer FSD dal 2019, viene spesso citato un ordine di grandezza di 144 TOPS per il sistema.
• Hardware 4 è installato nei veicoli più recenti ed è più moderno, ma Tesla non pubblica per questo hardware un valore TOPS pulito e semplice come nelle vecchie cifre dell’Autonomy Day. Per questo calcolo uso quindi comunque 144 TOPS come base conservativa.
• Un’auto resta spesso ferma 23 ore al giorno, ma la finestra davvero interessante è quella di ricarica. Se di notte resta 6,5 ore collegata alla corrente, su 24 ore significa in media circa 27 per cento di disponibilità.

Se solo il 25 per cento di questi proprietari Tesla attivi aderisse, sarebbero 1,6 milioni di veicoli e circa 62 exa-operazioni al secondo come equivalente giornaliero. Con il 50 per cento di partecipazione sarebbero circa 125 exa-operazioni al secondo. Se teoricamente partecipassero tutti i veicoli attivi, il numero sarebbe circa 250 exa-operazioni al secondo. Nella finestra notturna la potenza istantanea sarebbe più alta; il valore equivalente su 24 ore è solo il confronto più corretto con un data center che lavora tutto il giorno.

iPhone: la sorpresa più grande

Con gli iPhone il calcolo è insieme più semplice e più difficile. Semplice, perché Apple consegna ogni anno quantità enormi di dispositivi. Difficile, perché Apple non fornisce una tabella pubblica pulita su quali generazioni di iPhone siano ancora attive nel mondo. Quindi prendo le spedizioni pubblicate degli ultimi anni e ci applico sopra una quota residua attiva plausibile.

Questa stima mista produce circa 885 milioni di iPhone probabilmente ancora attivi considerando solo cinque anni di spedizioni. Non è l’intera base installata di iPhone, ma volutamente un sottoinsieme limitato. Le vecchie generazioni A14/A15 erano nell’ordine dei TOPS a doppia cifra bassa, A16 appena sotto 17 TOPS, A17 Pro circa 35 TOPS. Per questo una media per anno ha più senso che fingere che tutti i dispositivi abbiano lo stesso chip.

Ora lo stesso gioco: 6,5 ore di notte collegati alla corrente, non l’intera giornata. Se il 25 per cento di questi dispositivi partecipasse, si arriverebbe a circa 1'437 exa-operazioni al secondo come equivalente giornaliero. Con il 50 per cento di partecipazione sarebbero circa 2'875 exa-operazioni al secondo. Se teoricamente partecipassero tutti i dispositivi, il numero sarebbe circa 5'750 exa-operazioni al secondo.

Sembra folle. Ma è esattamente questo il punto. Non perché un iPhone sia un server. Ma perché la massa dei dispositivi è così grande che anche quote prudenti entrano improvvisamente in un ordine di grandezza che di solito attribuiamo solo ai data center.

Il confronto

Come ulteriori riferimenti prendo:

• 50 milioni di GPU desktop, workstation o piccoli server, che potrebbero fornire in media 20 TFLOPS FP32. Se solo il 20 per cento fosse praticamente utilizzabile, resterebbero circa 200 exa-operazioni al secondo in finestre temporali adatte.
• xAI Colossus come confronto dal mondo dei data center. Con 200'000 GPU Hopper e circa 3'958 INT8 TOPS per ordine di grandezza H100, si arriva a circa 792 exa-operazioni al secondo di picco teorico IA. È il picco con sparsity; la potenza densa e utilizzabile in modo continuativo è più bassa.

Questa non è una capacità globale esatta. È un modello di pensiero. Ed è proprio qui che bisogna frenare: i TOPS non si possono versare in una piscina comune come litri d’acqua. I Neural Engine TOPS di un iPhone, gli INT8 TOPS di una GPU e la potenza FP32 di una workstation sono cose diverse. Molti lavori sensati non richiedono solo operazioni di calcolo, ma RAM, VRAM, banda di memoria, tempi di esecuzione stabili, accesso software e un sistema operativo che permetta davvero questi job.

Eppure il calcolo mostra perché l’idea non è ridicola. Già una combinazione conservativa di PC, veicoli e smartphone, come silicio teorico, arriva in un ordine di grandezza che accanto a uno dei data center IA più visibili al mondo non sembra più assurdamente piccolo.

Il numero degli iPhone è particolarmente interessante perché considera solo cinque anni di consegne, non l’intera base installata attiva. Allo stesso tempo è il miglior esempio del perché la potenza di picco non basti: un iPhone non è un server. Ha limiti termici, logica della batteria, regole del sistema operativo, modelli di privacy e un proprietario che al mattino si aspetta un dispositivo funzionante. Eppure lì c’è potenza di calcolo che pochi anni fa sarebbe sembrata fantascienza.

E anche questi valori di picco sono solo valori di picco. Uno smartphone, un notebook senza ventola o una centralina automobilistica non possono semplicemente erogare questa potenza per sei ore come una GPU da data center. Limiti termici, throttling e logiche di protezione riducono drasticamente la potenza sostenuta. Chi volesse costruire una rete reale dovrebbe quindi ragionare in termini di prestazioni sostenute, non della cifra più bella nella scheda tecnica.

Si può ragionare anche tramite l’elettricità. Se 50 milioni di dispositivi contribuissero in media 150 watt per quattro ore al giorno, sarebbero circa 11 TWh all’anno. È solo una piccola frazione dell’attuale consumo globale dei data center. Ma basterebbe per sostenere molti job in background, embedding, workload scientifici, rendering, attività di verifica o processi di storage decentralizzato.

L’obiezione scomoda è: non è detto che sia automaticamente più efficiente. I data center hanno raffreddamento migliore, utilizzo migliore, energia più economica, hardware più nuovo e batching professionale. Un dispositivo domestico può essere peggiore per unità di lavoro utile, soprattutto se nasce molto overhead o se la batteria di uno smartphone invecchia più in fretta per pochi centesimi di crediti. Una compute grid decentralizzata non sarebbe quindi buona solo perché è distribuita. Dovrebbe avere senso netto per i workload adatti: tecnicamente, energeticamente ed economicamente.

La cosa diventa ancora più interessante con i nuovi AI PC. Canalys prevedeva per il 2025 circa 100 milioni di AI PC consegnati. Molti di questi dispositivi portano NPU da 40 TOPS o più. TOPS non è la stessa cosa dei GPU FLOPS, e una NPU non sostituisce un data center. Ma anche guardando questa potenza con molta prudenza, nasce una nuova classe di hardware IA locale che non esiste solo sulla carta, ma arriva in uffici e abitazioni.

La morale quindi non è: “domani sostituiamo tutti i data center con PC da gaming, Tesla e iPhone.” La morale è: stiamo costruendo nuova capacità centrale enorme, mentre allo stesso tempo una quantità gigantesca di capacità distribuita e già pagata scade inutilizzata.

La potenza di calcolo scade

L’elettricità posso conservarla. Non perfettamente, non senza perdite, ma in linea di principio. Se il mio impianto solare a mezzogiorno produce più di quanto mi serve, l’energia va in una batteria o nella rete. La sera posso riutilizzarla, oppure la usa il mio vicino. Smart grid, batterie e modelli energetici peer-to-peer rendono questo modo di pensare sempre più concreto: a volte produco, a volte consumo, e il confine tra cliente e fornitore diventa più morbido.

La potenza di calcolo funziona diversamente.

Un’ora di GPU inutilizzata ieri non posso tirarla fuori oggi da un cassetto. Un processore che non ha fatto nulla per una notte non ha conservato calcolo per dopo. Quel tempo è andato. Irrimediabilmente. La potenza di calcolo è deperibile.

È proprio questo a rendere interessanti i dispositivi inutilizzati. Non abbiamo solo hardware. Abbiamo possibilità che scadono continuamente. Il pool realistico a breve termine è composto soprattutto da GPU desktop, workstation, console da gioco, piccoli server, NAS e risorse libere di campus o provider. Smartphone e auto sono piuttosto casi di confine a lungo termine: tecnicamente affascinanti, ma molto più difficili per batteria, calore, regole di piattaforma, sicurezza e controllo dei produttori.

Quindi non fallisce solo per la matematica, ma anche per l’incentivo. I dispositivi con il silicio inutilizzato più interessante appartengono proprio a piattaforme chiuse: Apple costruisce con Private Cloud Compute la propria infrastruttura per le richieste più grandi di Apple Intelligence, Tesla con Cortex la propria capacità di training per FSD e Optimus. Perché queste aziende dovrebbero aprire le loro flotte di dispositivi a un mercato del compute indipendente dal produttore, se il controllo su hardware, software e cloud è il vero fossato competitivo?

Eppure la domanda di fondo resta: perché trattiamo la potenza di calcolo distribuita come se fosse irrilevante, mentre costruiamo impianti centrali sempre più grandi?

L’IA può davvero calcolare in modo decentralizzato?

Qui bisogna essere onesti: per molte cose che oggi vediamo come IA, la decentralizzazione è difficile.

Un grande modello linguistico non è semplicemente una lista di piccoli compiti da lanciare a caso su dispositivi estranei. I modelli hanno bisogno di RAM o VRAM. Hanno bisogno di banda di memoria. In parte hanno bisogno di interconnect veloci. Durante la generazione dei token il modello viene attraversato continuamente, e ogni salto di rete aggiuntivo rende la risposta più lenta. Spezzare un frontier model su smartphone estranei, vecchi laptop e auto sarebbe quasi sempre insensato per una risposta chat interattiva.

Questo però non significa che l’IA decentralizzata sia impossibile. Significa solo che bisogna scegliere i compiti giusti.

Si prestano molto bene lavori che non devono finire in due secondi: embedding per grandi archivi, riassunti batch, rendering, simulazioni scientifiche, dati sintetici, test, crawling, attività di verifica, riparazione di storage decentralizzato, piccoli modelli locali, pre-elaborazione e compiti in cui i risultati possono essere controllati o calcolati più volte.

In pratica bisognerebbe separare le attività in modo molto più pulito:

Nemmeno i grandi modelli sono completamente esclusi, ma richiedono un’altra architettura. Petals ha mostrato che inferenza collaborativa e fine-tuning di grandi modelli su risorse distribuite sono possibili in linea di principio. Prime Intellect con INTELLECT-2 fa un passo in più e mostra come il reinforcement learning distribuito possa funzionare con worker non affidabili, se i risultati vengono verificati. Non è ancora il mondo in cui il tuo iPhone di notte allena di nascosto GPT-7. Ma è un indizio che il problema non è fondamentalmente impossibile.

Il punto di partenza realistico quindi non sarebbe: “distribuiamo un modello enorme su qualunque cosa.” Il punto di partenza realistico sarebbe: prima modelli locali, pool regionali per batch job adatti, compiti verificabili, zone dati chiare e data center centrali solo dove servono davvero.

Il vecchio sogno dei sistemi distribuiti

Esiste un’altra narrazione di Internet. Una che suona meno come una cattedrale e più come uno sciame.

Calcolo volontario

SETI@home per me è sempre stato uno degli esempi più belli. Milioni di persone lasciavano che i loro computer elaborassero in background dati di radioastronomia. Non perché ricevessero un dashboard SaaS, ma perché l’idea era abbastanza grande: cercare insieme segnali nel rumore dell’universo. Da marzo 2020 SETI@home non distribuisce più nuove Work Unit ed è in una specie di ibernazione. Ma come prova che il calcolo volontario globale può funzionare resta importante.

BOINC, la piattaforma dietro e accanto a SETI@home, spiega in modo sobrio perché funziona: molti job indipendenti e intensivi dal punto di vista computazionale, in cui il throughput conta più della bassa latenza. Questa è la differenza decisiva. Un sistema distribuito non deve consegnare ogni risposta chat interattiva in due secondi. Può essere forte dove il lavoro è scomponibile, verificabile e non immediatamente urgente.

Storage senza luogo fisso

IPFS porta lo stesso pensiero nell’ambito dello storage. I file non vengono indirizzati principalmente tramite un luogo, ma tramite il loro contenuto. Il contenuto ha un’impronta. Chi ce l’ha può fornirlo. È un modo di pensare diverso da “questo file si trova su questo server a questo URL”.

Denaro senza contabilità centrale

Bitcoin, del tutto indipendentemente da come si valutino speculazione e consumo energetico, ha reso popolare una simile idea originaria: un sistema senza contabilità centrale, in cui il consenso non dipende da un’unica istituzione. Non ogni idea decentralizzata è automaticamente buona. Ma Bitcoin ha mostrato che un protocollo può essere politicamente potente quando rimuove il punto di controllo centrale.

Storage come rete

Anche nello storage ci sono stati tentativi interessanti. Symform era un provider di cloud storage decentralizzato in cui lo spazio in eccesso poteva essere messo a disposizione di una rete. Nel 2014 la piattaforma è stata acquisita da Quantum; in quel momento si parlava di 45'000 utenti e piccole imprese in 170 paesi. Storj, Sia, Filecoin e altre varianti mostrano la stessa cosa: l’idea non è nuova. È solo che non arriva mai del tutto nella quotidianità.

Oggi questa idea vive in nuove forme. Storj divide i file lato client, li cifra e distribuisce i frammenti su molti Storage Node. È più vicino all’infrastruttura che al romanticismo: nel caso migliore l’utente non vede lo sciame, ma un servizio di storage che funziona.

Compute come marketplace

Golem e Akash vogliono rendere accessibile la potenza di calcolo inutilizzata come marketplace. Per me è il ponte diretto verso questo articolo: non solo lo spazio di archiviazione è distribuito là fuori, ma anche processori, GPU e piccoli server che oggi spesso restano inattivi.

IA nello sciame distribuito

Anche Andrej Karpathy ricompare in questo ambiente: Prime Intellect lo cita come sostenitore di rilievo, e Prime Intellect con INTELLECT-2 ha avviato una sessione di training RL distribuita e decentralizzata per un modello da 32B parametri, alla quale possono contribuire risorse di calcolo eterogenee e permissionless.

Non è ancora la risposta perfetta. Ma mostra che il sogno non è scomparso. Cerca solo, ogni volta, una forma che sopravviva nell’operatività reale.

Imparare dalla centrale elettrica virtuale

La cosa interessante è che nel settore elettrico questo modo di pensare suona già molto meno esotico.

Tesla descrive il suo Virtual Power Plant come una rete di fonti energetiche distribuite: case con impianti solari e Powerwall vengono considerate insieme come una centrale elettrica. Quando la rete ha bisogno di supporto, le batterie possono immettere energia. Il proprietario mette a disposizione una risorsa e riceve denaro o altri vantaggi. Le singole Powerwall sono piccole. Insieme però possono diventare rilevanti per la rete.

È esattamente l’analogia che mi affascina nel compute. Una singola GPU in home office, un singolo NAS, un singolo iPhone o una singola auto non sono un data center. Ma molti dispositivi insieme potrebbero formare un nuovo strato: non per tutto, non sempre, non senza regole, ma per determinati compiti.

L’analogia ha limiti. L’elettricità è molto più fungibile del lavoro di calcolo. Un chilowattora non dipende dal fatto che debba eseguire un modello con 80 GB di VRAM, una pipeline di embedding o una riparazione di storage cifrato. Il compute dipende dal workload. Proprio per questo servono classi di job, scheduling ed esclusioni rigide.

In Tesla si vede lo stesso pensiero persino in due punti. Le Powerwall possono diventare parte di una centrale elettrica virtuale. Le auto dovrebbero in prospettiva diventare parte di una flotta robotaxi autonoma, quindi guadagnare denaro quando il proprietario non le usa. Se e quanto rapidamente questo scalerà davvero è un’altra domanda. Ma l’idea di fondo è importante: un dispositivo privato non viene più soltanto consumato, ma può lavorare come infrastruttura nelle finestre libere.

Il compute potrebbe essere pensato in modo simile. Non come vendita di elettricità al vicino, ma come vendita di tempo di calcolo verificabile, spazio di storage o lavoro di modello a una cella regionale. Alla fine l’utente paga elettricità, calore, usura dell’hardware e rischio. Quindi deve anche essere remunerato. Senza questo punto, l’idea resta solo un grazioso esperimento tecnico.

Perché lo sciame vince così raramente

Se la decentralizzazione suona così bella, perché non si afferma semplicemente?

Perché la centralizzazione è spesso il pacchetto prodotto migliore.

Un data center è controllabile. Uno sciame è fatto di dispositivi estranei, sistemi operativi diversi, disponibilità variabile, scarsa prevedibilità e proprietari che spengono, vendono, aggiornano o scollegano il proprio dispositivo. Per un product manager non è romanticismo, è mal di testa.

Poi c’è l’economia. Molti progetti decentralizzati hanno cercato di risolvere gli incentivi con token. È comprensibile, perché una rete senza azienda centrale ha comunque bisogno di remunerazione. Ma appena i costi per storage o tempo di calcolo sono legati a una valuta volatile, per le aziende normali diventa poco attraente. Non voglio che il mio terabyte di backup diventi improvvisamente più costoso perché una coin viene pompata su Twitter. E non voglio che il mio budget per ore GPU dipenda da un mercato che somiglia più a un casinò che a un’infrastruttura.

E l’avversario sul prezzo non è la GPU on demand più cara nel cloud. Il vero confronto sono le offerte spot e preemptible, cioè capacità di data center comunque in eccesso che i provider vendono con forti sconti. Una rete di compute decentralizzata quindi non dovrebbe essere solo filosoficamente più bella. Dovrebbe competere con capacità cloud molto economica, ben integrata, anche se interrompibile.

Il secondo freno è la comodità. S3 non ha vinto perché è filosoficamente bello. Ha vinto perché è abbastanza semplice, abbastanza documentato e integrato ovunque. Se reti decentralizzate di storage o compute vogliono diventare rilevanti, devono risultare quasi noiose per sviluppatori e admin: inserisci API key, crei un bucket, monitoraggio, fattura, SLA, test di restore, fatto.

Poi arriva la sicurezza. In una rete aziendale non deve comparire all’improvviso un job di compute estraneo in ingresso sulle workstation. Qualsiasi firewall sensato lo bloccherebbe, e per i sistemi di threat intelligence sembrerebbe sospetto. In pratica un sistema del genere dovrebbe lavorare piuttosto dall’interno verso l’esterno: il nodo si registra presso una cella, scarica job verificati, gira in una sandbox e vede solo i dati che può vedere. Altrimenti, a livello di rete, una rete di compute legittima assomiglia rapidamente a un botnet formulato in modo molto educato.

La fiducia è il prossimo punto duro. I sistemi decentralizzati devono poter provare che il lavoro è stato svolto correttamente senza che ogni nodo possa vedere tutto. Nello storage esistono componenti noti: crittografia, erasure coding, audit, meccanismi di riparazione. Con IA e compute diventa più difficile. Come verifico se un dispositivo estraneo ha eseguito correttamente un modello? Come impedisco la fuoriuscita dei dati? Come proteggo il dispositivo del partecipante da codice estraneo?

Anche l’usura hardware è più che elettricità. SSD e storage NVMe hanno limiti di scrittura. Chi scrive continuamente pesi di modello, dati temporanei, batch di embedding o file di swap su dispositivi consumer consuma vita utile reale. Si aggiunge il problema della banda: se il download di un grande modello o dataset dura più della computazione vera e propria e crea più overhead di rete, il conto si rovescia. I dati sono più pesanti di quanto lasci intuire la semplice metafora della smart grid.

Proprio qui INTELLECT-2 diventa interessante. Prime Intellect descrive nel suo paper TOPLOC come componente che verifica i rollout di inference worker non affidabili. Non risolve di colpo tutti i problemi del compute. Non è una magia per la privacy di qualunque dato aziendale su hardware estraneo. Ma mostra un meccanismo reale per una determinata classe di lavoro IA distribuito: i job vengono progettati in modo che i risultati siano verificabili, invece di dover dare fiducia cieca a ogni worker.

Per i dati riservati non basta. Servirebbero altri componenti: Confidential Computing, Trusted Execution Environments, Remote Attestation, sandbox pulite, classificazione chiara dei dati e, in caso di dubbio, la decisione dura di non eseguire certi job su hardware estraneo. E poi ci sono domande noiose ma decisive: tasse, responsabilità, protezione dei dati, residenza dei dati e condizioni dei provider Internet. L’infrastruttura raramente fallisce solo per la matematica. Spesso fallisce per l’operatività.

Una smart grid del compute

Non immagino un ingenuo “tutto è P2P e poi andrà tutto bene”. L’infrastruttura non funziona così. Ciò che potrebbe funzionare è una smart grid del compute con strati chiari.

Il primo strato si chiama: locale prima di tutto. Tutto ciò che è personale, riservato o sensibile alla latenza dovrebbe girare il più possibile sul proprio dispositivo o nel proprio spazio di fiducia. Piccoli modelli, ricerca locale, riassunti privati, classificazione semplice, pre-elaborazione, crittografia, embedding per dati personali. Non ogni e-mail, ogni nota e ogni ricerca deve andare a un hyperscaler.

Il secondo strato sarebbe regionale e federato. Una città, un quartiere, un campus, un’azienda, una cooperativa o un provider potrebbe gestire una cella. In questa cella i dispositivi mettono a disposizione risorse volontariamente, ma solo a condizioni chiare: solo collegati alla corrente, solo in idle, solo entro limiti termici, solo con potenza massima definita, solo per determinate classi di job.

Il punto di partenza non sarebbero smartphone e auto, ma i dispositivi più noiosi: GPU desktop, workstation, console da gioco, piccoli server, sistemi NAS e capacità libera presso provider locali. Gli smartphone potrebbero poi assumere piccoli job di verifica. Le auto sarebbero pensabili ancora più avanti, in limiti molto stretti e controllati dal produttore. Proprio come nella rete elettrica, bisognerebbe cominciare dalle risorse affidabili, misurabili e controllabili.

Il terzo strato resta centrale. Frontier training, tempo reale rigido, modelli estremamente grandi, casi speciali delicati dal punto di vista regolatorio e workload con forte accoppiamento appartengono ancora ai data center professionali. La decentralizzazione non deve sostituire tutto. Deve solo impedire che ogni lavoro quotidiano passi automaticamente dagli stessi cinque centri di potere.

Se si volesse testare tutto questo, partirei in piccolo. Non con milioni di iPhone, ma con una cella regionale composta forse da 500 a 2'000 GPU desktop volontarie, workstation, sistemi NAS e piccoli server. Sarebbero ammessi solo pochi tipi di job: embedding per dati non sensibili, batch job scientifici, frammenti di storage cifrati e attività di verifica. Il successo non si misurerebbe con una bella cifra exa, ma con tre metriche noiose: job completati per 1 dollaro di costo energetico, tasso di errore e ripetizione, pagamento dopo l’usura hardware.

La parte più difficile sarebbe la remunerazione. L’utente paga elettricità, calore e usura hardware. Quindi deve ricevere qualcosa in cambio. Probabilmente servirebbe davvero un token o un credito. Ma non come oggetto speculativo, bensì come credito infrastrutturale.

Un compute credit di questo tipo dovrebbe rappresentare qualcosa di reale: un minuto GPU di una certa classe, un GB-mese di storage, un’inferenza verificata, un’unità di batch embedding o un’unità di calcolo equivalente a kWh. Chi fornisce risorse guadagna crediti. Chi in seguito ha bisogno di potenza IA li spende. Chi non vuole consumarli potrebbe incassarli in valuta fiat, in modo simile a una centrale elettrica virtuale, dove non si vuole essere pagati in “Powerwall Coin”, ma in denaro reale o in un credito chiaro.

Questo però non risolve magicamente la questione del prezzo. La stabilità ha bisogno di un ancoraggio: fatturazione fiat, corridoi dei prezzi dell’energia, camere di compensazione regionali, tariffe cooperative o operatori regolati. Senza governance, i “crediti stabili” tornano rapidamente a essere token liberamente fluttuanti. E allora si torna al vecchio problema: l’infrastruttura sembra un casinò.

Ancora più importante è la questione dei diritti operativi. Non dobbiamo addestrare noi ogni grande foundation model. Forse si acquistano o si licenziano modelli, pesi aperti o famiglie di modelli, e poi li si gestisce in modo decentralizzato, federato e controllato a livello regionale. La vera sovranità non sarebbe allora solo nel training, ma nell’esercizio: dove girano i modelli? Dove stanno i dati? Chi può fare audit? Esiste un canale di ritorno verso il fornitore? Posso continuare a usare il modello localmente se politica, prezzi o Terms cambiano?

Perché sia più di un bel contratto di acquisto, tali licenze dovrebbero contenere veri diritti operativi: deployment locali, promesse di aggiornamento e sicurezza a lungo termine, model card comprensibili, auditabilità, chiari diritti di uscita e nessun obbligo di rimandare dati sensibili nella cloud centrale del produttore. Non sarebbe la pura utopia decentralizzata. Ma sarebbe un percorso realistico tra autosufficienza ingenua e lock-in totale di piattaforma.

La notte in cui i dispositivi calcolano

Immagina che siano le 22:43. Il tuo desktop con GPU è in idle, il NAS è online, il telefono si sta caricando. Nelle impostazioni hai definito: massimo 80 watt, solo in inattività, solo per workload verificati dalla regione e solo se la remunerazione copre costi elettrici più una quota hardware.

Un agente locale segnala capacità libera. Non con il tuo nome e non con i tuoi dati privati, ma come nodo attestato con determinate capacità. La cella distribuisce piccoli job: simulazioni, embedding, frammenti di storage cifrati, compiti di verifica.

Al mattino non c’è un razzo, nessuna storia da Wall Street, nessun hype token. Solo una riga sobria:

Questa notte: guadagnati 2,4 GPU credit, confermati 18 GB-mese di storage, costi elettrici stimati $0.31.

Più tardi usi questi crediti per un modello locale sui tuoi documenti. I dati sensibili restano da te. Non sei solo cliente. Sei partecipante.

Suona romantico. Sì. Ma a volte è proprio questo il motivo per prendere sul serio un problema di engineering difficile.

Lo sciame e la montagna

Non credo che i data center centrali spariranno. Sono troppo efficienti, troppo importanti e per alcuni compiti semplicemente necessari. La montagna resta. La domanda è solo se, accanto, ricostruiamo anche un terreno.

Un terreno fatto di dispositivi locali, celle regionali, protocolli aperti, crediti stabili e modelli di sicurezza chiari. Un terreno su cui la potenza di calcolo non venga solo venduta dall’alto verso il basso, ma fluisca tra i partecipanti. Un terreno su cui un certo lavoro di IA giri dove appartiene: il lavoro privato in locale, il lavoro regionale nella regione, i casi limite globali nel data center.

Forse è ingenuo. Forse no. Anche le centrali elettriche virtuali una volta erano un’idea strana: migliaia di piccole batterie come un’unica grande rete. Il denaro decentralizzato è sembrato assurdo a lungo. Auto che guidano da sole come taxi sembravano fantascienza. Non tutto arriverà come era stato promesso. Ma la direzione è chiara: risorse che prima restavano passive vengono pensate sempre più come parte di un sistema più grande.

Proprio ora ci sono macchine inutilizzate ovunque. In abitazioni, uffici, garage, sale server e tasche. Non tutte sono adatte allo stesso modo. Non tutte dovrebbero mai eseguire lavoro estraneo. Ma molte sono già lì, pagate e connesse. E ogni secondo inutilizzato scompare.

Forse dovremmo cominciare ad ascoltarle.

Alla prossima,
Joe