Inferenza decentralizzata: sotto il cofano, dai GPU al routing

Ogni volta che un assistente AI risponde a una domanda, da qualche parte una scheda grafica esegue miliardi di operazioni in una frazione di secondo. Nel modello tradizionale quella scheda vive dentro un data center di Amazon, Google o Microsoft. Nell’inferenza decentralizzata può invece trovarsi in un capannone in Norvegia, in una sala server a Singapore o sotto la scrivania di uno sconosciuto a Milano. La promessa è semplice da enunciare: usare hardware sparso per il pianeta, coordinato da una blockchain e pagato in token, per far girare i modelli AI a un costo inferiore rispetto ai grandi provider centralizzati.

In questa serie abbiamo già spiegato cos’è l’inferenza decentralizzata e perché esiste, perché a trainarne la domanda siano soprattutto gli agenti AI, e quanto costi davvero una volta messa alla prova. Questa guida apre il cofano. La domanda non è più «perché», ma «come»: come fa un modello da centinaia di miliardi di parametri a girare su GPU che non si conoscono tra loro, come una singola richiesta trova la scheda giusta in mezzo a centinaia di migliaia, perché la banda della rete conti più della potenza del singolo chip, e quanta energia consumi tutto questo.

È una storia di ingegneria prima ancora che di finanza, e come ogni storia di ingegneria è fatta di compromessi. Ogni euro risparmiato sul prezzo orario di una GPU tende a ripresentarsi sotto forma di latenza più alta, affidabilità variabile o un modello che nessuno può garantire sia esattamente quello promesso. Capire dove si nascondono quei compromessi è l’unico modo per giudicare se la parola «decentralizzata» sia una rivoluzione o soltanto un’etichetta di marketing.

Inferenza, non addestramento: cosa gira quando fai una domanda

Conviene ripartire da una distinzione che cambia tutta l’ingegneria. Addestrare un modello significa costruirlo: settimane di calcolo su migliaia di GPU strettamente interconnesse, un processo unico, fragile e affamato di banda. Fare inferenza significa usarlo: prendere un modello già pronto e trasformare un prompt in una risposta, spesso in poche centinaia di millisecondi, su una singola scheda o su un piccolo gruppo di schede. La prima operazione somiglia a un cantiere, la seconda a una catena di montaggio.

Questa differenza è la ragione per cui l’inferenza si presta alla decentralizzazione molto più dell’addestramento. Le richieste di inferenza sono indipendenti l’una dall’altra: mille utenti che fanno mille domande sono mille lavori separati, distribuibili su mille schede diverse senza che debbano parlarsi. È una parallelizzazione quasi banale, tollerante verso hardware eterogeneo e verso collegamenti di rete lenti. Non a caso l’inferenza è ormai la voce dominante della spesa di calcolo AI: le stime la collocano tra il 70% e il 90% del totale, a seconda di come si misura, secondo l’analisi di Spheron e di Coincub. Chi controlla la capacità di inferenza controlla la parte del mercato che cresce di più.

Per i concetti di base (cos’è un modello, cosa significano parametri e token) rimandiamo alla nostra guida introduttiva alla serie. Qui diamo per acquisito il vocabolario e scendiamo al livello dei circuiti.

Lo strato fisico: quali GPU compongono davvero la rete

Alla base di tutto c’è il silicio. Le reti decentralizzate aggregano una miscela eterogenea di schede: al vertice ci sono le GPU da data center, come la NVIDIA H100 SXM5 (80 GB di memoria HBM3) e la più recente H200 (141 GB), pensate per l’inferenza ad alte prestazioni. Sotto ci sono le schede prosumer e consumer, dalla RTX 4090 (24 GB) alla nuova RTX 5090 (32 GB), che vivono nelle case dei gamer e nei piccoli studi. Ognuna ha caratteristiche diverse di memoria, banda interna e consumo: una H100 assorbe circa 700 watt sotto carico, quasi il doppio dei 400 watt della precedente A100, come documenta TRG Datacenters.

Questa eterogeneità è insieme la forza e il tallone d’Achille del modello. La forza è la scala latente: io.net dichiara oltre 320.000 GPU registrate nella sua rete su Solana, un serbatoio che nessun singolo operatore possiede. La debolezza è che la quota realmente attiva in un dato momento è molto più bassa del totale registrato, come emerge dai dati raccolti da Messari: una scheda accesa nel salotto di qualcuno non è la stessa cosa di un rack certificato e sempre disponibile. Abbinare ogni carico di lavoro all’hardware capace di reggerlo è il primo, sottovalutato, problema di ingegneria.

C’è poi un ostacolo meno visibile ma insidioso: la compatibilità software. Non basta che una scheda abbia memoria sufficiente; deve avere i driver giusti, la versione corretta delle librerie CUDA e un ambiente capace di caricare quel preciso modello. Su una flotta eterogenea, dove convivono generazioni di GPU diverse e sistemi operativi assortiti, l’orchestratore deve tenere una mappa aggiornata di ciò che ciascun nodo sa fare davvero. È la differenza tra un catalogo teorico di capacità e la capacità realmente utilizzabile in questo istante, e spiega perché il numero di GPU dichiarate conti molto meno del numero di GPU pronte per un dato carico.

Il problema della taglia: far entrare un modello gigante in rete

Il vincolo che decide quasi tutto è la memoria. Per essere eseguito, un modello deve stare nella VRAM della GPU insieme allo spazio di lavoro necessario a rispondere. La matematica è spietata: un modello da 70 miliardi di parametri in mezza precisione (FP16) richiede circa 140 GB di sola memoria per i pesi, più della capacità di una singola H100 da 80 GB. Un modello da 405 miliardi di parametri ne richiede oltre 800. Nessuna scheda, per quanto potente, basta da sola.

Da qui la biforcazione. I modelli piccoli e medi (7, 8, 13 miliardi di parametri) entrano su una sola scheda di fascia alta: sono il pane quotidiano delle reti decentralizzate, perché ogni nodo può servire una richiesta intera da solo. I modelli giganti, invece, vanno spezzati e distribuiti su più GPU, un’operazione chiamata sharding. Il modo in cui li si spezza determina se è possibile farlo su schede vicine, dentro lo stesso rack, oppure su schede lontane migliaia di chilometri. E qui, come spiega bene la guida di Red Hat sull’inferenza distribuita, la geografia della rete diventa il fattore decisivo.

Tensor parallelism contro pipeline parallelism: perché la banda decide tutto

Ci sono due modi principali per distribuire un modello, e capirne la differenza è la chiave per capire i limiti reali dell’inferenza decentralizzata. Il tensor parallelism spezza ogni singolo strato del modello tra più GPU, che devono sincronizzarsi a ogni passaggio: è velocissimo, ma esige una banda enorme tra le schede, dell’ordine delle centinaia di gigabyte al secondo garantiti da interconnessioni dedicate come NVLink e InfiniBand. Funziona solo dentro un unico nodo o un unico data center. Il pipeline parallelism, invece, divide il modello in profondità (i primi strati su un nodo, gli strati successivi su un altro) e fa transitare i dati da uno all’altro: chiacchiera molto meno, tollera collegamenti più lenti, ma introduce latenza e tempi morti.

La conseguenza pratica è netta. Su Internet pubblica, dove la latenza si misura in millisecondi e la banda in gigabit al secondo (non in terabyte al secondo), il tensor parallelism tra macchine lontane è impraticabile: la documentazione di vLLM, il motore di inferenza più diffuso, lo dice chiaramente. Ecco perché le reti decentralizzate, nella stragrande maggioranza dei casi, non spezzano un modello colossale attorno al globo: replicano modelli piccoli e medi su tanti nodi indipendenti, ciascuno dei quali serve richieste intere. Far girare davvero un modello da 400 miliardi di parametri distribuito tra i PC di sconosciuti resta, per ora, terreno di ricerca più che di produzione.

Il routing: come una richiesta trova la GPU giusta

Supponiamo che la rete abbia migliaia di nodi idonei. Quando arriva una richiesta, qualcuno deve decidere in pochi millisecondi dove mandarla. Questo compito spetta allo strato di orchestrazione, un abbinatore (matchmaker) che valuta più criteri contemporaneamente: quel nodo ha già il modello caricato in memoria? Ha capacità libera? È vicino all’utente, così da ridurre la latenza di rete? Ha una buona reputazione di affidabilità? io.net, per esempio, usa il framework Ray per programmare i carichi su GPU sparse, mentre reti orientate all’inferenza come Aethir instradano le richieste verso la scheda a più bassa latenza per la geografia dell’utente, con nodi distribuiti in decine di paesi.

Un dettaglio spesso frainteso: quasi mai è la blockchain a instradare la singola richiesta. Registrare ogni prompt on-chain sarebbe lento e costoso. La catena serve al livello economico e di coordinamento (pagamenti, staking, reputazione, regolamento), mentre lo scheduling vero e proprio avviene fuori catena, alla velocità che l’utente pretende. La decentralizzazione, in altre parole, riguarda più la proprietà dell’hardware e la contabilità del valore che il percorso fisico del singolo pacchetto. Molte reti espongono, non a caso, un’interfaccia compatibile con le API di OpenAI, così che uno sviluppatore possa puntarci un’applicazione esistente cambiando poche righe.

Batching e KV-cache: il segreto nascosto del throughput

Una GPU che serve un solo utente alla volta è una GPU sprecata. Il vero motore dell’economia dell’inferenza è la capacità di servire molti utenti simultaneamente sulla stessa scheda. Due tecniche lo rendono possibile. Il continuous batching intreccia le richieste in arrivo, riempiendo i tempi morti di un utente con il lavoro di un altro. La KV-cache memorizza lo stato di attenzione già calcolato, così che i token successivi non debbano ricalcolare da zero l’intera conversazione. Motori come vLLM e SGLang hanno reso queste ottimizzazioni standard di settore.

Il risultato è che il throughput, cioè i token al secondo prodotti da tutti gli utenti insieme, conta più della velocità della singola risposta quando si guarda al costo. È così che una subnet come Chutes, su Bittensor, arriva a numeri dichiarati enormi: secondo i dati raccolti da Own Your Mind, l’ordine di grandezza è di circa 160 miliardi di token elaborati al giorno e migliaia di miliardi cumulati. Sono cifre in gran parte auto-riportate, da prendere con prudenza, ma raccontano bene la dinamica: la partita si gioca tutta sull’utilizzo. Una scheda inattiva non guadagna nulla; il batching la tiene piena.

Il batching non è l’unica leva. La quantizzazione riduce la precisione numerica dei pesi (da 16 bit a 8 o persino 4), facendo entrare modelli più grandi in schede più piccole e aumentando la velocità, al prezzo di una perdita di qualità che va misurata caso per caso. La decodifica speculativa usa un modello piccolo e veloce per proporre più token in anticipo, che il modello grande conferma poi in blocco, riducendo i tempi di attesa. Sono ottimizzazioni potenti, ma aprono anche una zona grigia: un nodo che quantizza in modo aggressivo per guadagnare di più sta erogando un servizio diverso da quello promesso, ed è esattamente qui che il problema della verifica smette di essere teorico.

Il viaggio di una richiesta, passo per passo

Mettendo insieme i pezzi, ecco cosa accade davvero quando un’applicazione invia un prompt a una rete di inferenza decentralizzata.

1. L’app o l’agente invia il prompt a un endpoint della rete, spesso un’API compatibile con lo standard di OpenAI.
2. L’orchestratore autentica la chiamata e verifica il credito o il pagamento (in token oppure in valuta tradizionale tramite un intermediario).
3. L’abbinatore seleziona un nodo che abbia il modello richiesto, memoria sufficiente e bassa latenza verso l’utente.
4. Se il nodo non ha il modello già caricato scatta un cold start: i pesi vengono trasferiti nella VRAM, operazione che per un modello grande può richiedere decine di secondi. Se il modello è già caldo, si parte subito.
5. Il nodo esegue l’inferenza (la fase di prefill del prompt e poi la generazione token dopo token), mescolando la richiesta ad altre tramite batching.
6. I token vengono restituiti in streaming al client, di solito uno dopo l’altro man mano che sono prodotti.
7. Il consumo viene misurato, il nodo matura il compenso, il regolamento viene registrato (spesso on-chain) ed eventualmente si genera una prova di corretta esecuzione.

Ogni passaggio nasconde un compromesso. Il punto 4 è la ragione per cui i modelli poco richiesti costano di più (restano freddi e vanno ricaricati). Il punto 3 è dove si decide la qualità del servizio. Il punto 7 è dove entra in gioco il problema, tutt’altro che risolto, della fiducia.

Latenza, cold start e affidabilità: la realtà operativa

Sulla carta il prezzo orario di una GPU decentralizzata è imbattibile. In produzione la storia si complica. Il primo nemico è il cold start: caricare un modello da 70 miliardi di parametri richiede tempo, e il tempo di comparsa del primo token (time-to-first-token) è ciò che l’utente percepisce come lentezza. Il secondo nemico è la varianza dell’affidabilità: un nodo consumer può spegnersi perché il proprietario riavvia il PC, cambia gioco o stacca la corrente. Le reti rispondono con sistemi di reputazione, staking e penalità (slashing), ma il rischio non sparisce.

Le reti serie affrontano il problema con la ridondanza. Alcune inviano la stessa richiesta a più nodi e tengono la prima risposta valida, altre mantengono un pool di nodi caldi con i modelli più richiesti già in memoria, altre ancora costruiscono un livello di indirezione che nasconde all’utente il singolo nodo spentosi a metà lavoro. Ognuna di queste scelte migliora l’affidabilità percepita, ma consuma capacità aggiuntiva e quindi denaro: è la tassa nascosta della decentralizzazione, quella che separa il prezzo di listino di un’ora di GPU dal costo reale di un servizio su cui un’azienda è disposta a scommettere.

Questa è la differenza tra un’ora di GPU economica e un endpoint di produzione affidabile. L’analisi di Coincub lo sintetizza bene: le reti decentralizzate possono costare dal 45% al 75% in meno rispetto agli hyperscaler sull’inferenza, ma la varianza di affidabilità spinge spesso a sovradimensionare la capacità, e quel sovradimensionamento erode in fretta il risparmio. I gestori delle reti lo sanno: io.net rivendica per la sua API di intelligenza un’operatività molto elevata, ma raggiungere gli accordi sul livello di servizio (SLA) che un’azienda pretende resta la sfida più dura del settore. Per un’analisi dettagliata dei costi reali e del confronto con AWS abbiamo dedicato un approfondimento separato sui costi e sul nodo della fiducia.

Come si verifica che il nodo abbia fatto il lavoro giusto

C’è una domanda che rende l’inferenza decentralizzata diversa da qualsiasi altro cloud: se non vedo la macchina, come faccio a sapere che ha davvero usato il modello che ho chiesto, alla precisione promessa, senza scorciatoie? Un nodo malintenzionato potrebbe sostituire il modello con uno più piccolo ed economico, ridurre la precisione o restituire risultati approssimativi. È il problema della verifica, e le soluzioni proposte sono diverse: la ri-esecuzione ottimistica (si ricontrolla a campione e si punisce chi bara), gli ambienti di esecuzione fidati o TEE (come i chip con confidential computing usati da Phala), le prove crittografiche in stile zkML (robuste ma ancora costose) e il fingerprinting statistico delle attivazioni, l’approccio del progetto TOPLOC.

Il tema attira alcune delle voci più autorevoli del settore. Vitalik Buterin, in un saggio del gennaio 2024 su crypto e AI, ha sostenuto che l’applicazione più solida della crittografia all’intelligenza artificiale è renderla verificabile, avvertendo però che esiste un compromesso di fondo tra calcolo economico ma non verificabile e calcolo costoso ma verificabile. Il team di Prime Intellect spiega perché il problema è concreto: i fornitori, scrivono, «apportano modifiche ai metodi di calcolo per ottimizzare costi, efficienza o specifici obiettivi commerciali», rendendo difficile sapere quale modello sia stato eseguito davvero. E Sreeram Kannan, fondatore di EigenLayer, riassume la scommessa così: il futuro del software è «autonomo e verificabile», come ha dichiarato al lancio della piattaforma di AI verificabile del suo gruppo, riportato da SiliconANGLE.

L’impronta energetica: il lato nascosto dell’inferenza

Se l’inferenza è la quota dominante del calcolo AI, è anche una quota dominante dei suoi consumi. I numeri aiutano a farsi un’idea della scala fisica. Una singola H100 assorbe circa 700 watt sotto carico; un server con otto schede arriva intorno ai 10 kilowatt considerando processori, ventole e infrastruttura; un cluster da mille GPU può richiedere circa 1,76 megawatt in continuo, una volta inclusi gli oneri di sistema e l’efficienza del data center (il cosiddetto PUE), secondo i calcoli di Spheron. Moltiplicato per la crescita dell’inferenza, il consumo elettrico è diventato una variabile economica e politica di primo piano.

La decentralizzazione ha qui una doppia faccia, ed è onesto raccontarle entrambe. Sul lato positivo, riusare GPU altrimenti inattive alza il tasso di utilizzo dell’hardware già prodotto, riducendo lo spreco per token, e permette di collocare i nodi dove c’è energia in eccesso o rinnovabile, con una flessibilità geografica che un mega data center non ha. Sul lato negativo, un rig casalingo perde l’efficienza di raffreddamento e di alimentazione di una struttura ottimizzata, la rete introduce sovraccarichi di trasferimento, e soprattutto manca un unico operatore a cui chiedere conto di un impegno verde o di una misurazione trasparente. Proprio mentre le regole europee spingono verso più trasparenza, la natura diffusa del modello rende l’impronta più difficile da tracciare.

Qui si apre una tensione che vale la pena rendere esplicita. L’AI Act e più in generale la spinta europea alla sostenibilità chiedono di misurare e dichiarare i consumi; un data center centralizzato, per quanto energivoro, ha un contatore e un bilancio. Una rete di migliaia di nodi domestici non ha un contatore unico, e ricostruire quanto e come consuma diventa un esercizio di stima. Il paradosso è che il modello potenzialmente più efficiente nell’uso dell’hardware già esistente è anche quello più difficile da rendicontare, e nei prossimi anni saper dimostrare la propria impronta potrebbe diventare un vantaggio competitivo quanto il prezzo per token.

I protagonisti e come si dividono il lavoro

Il panorama non è monolitico: reti diverse hanno architetture e priorità diverse. Un fatto le accomuna, però, ed è la svolta del 2026 fotografata da Coincub e da altri osservatori: il settore ha iniziato a generare ricavi reali da clienti che pagano per il calcolo, invece di dipendere solo dall’emissione di token. La tabella seguente riassume i principali attori, con i prezzi dei rispettivi token rilevati su CoinGecko l’11 agosto 2026.

Le differenze contano. Render Network e il token RENDER nascono dal rendering grafico e usano un meccanismo burn-and-mint in cui gli utenti pagano e i token vengono bruciati a fronte del lavoro svolto. Akash è un cloud generalista costruito attorno a un’asta inversa in cui i fornitori si contendono i carichi al ribasso. Bittensor, con la sua struttura a subnet, è un caso a sé che merita un discorso dedicato.

Dal lavoro al token: come la rete paga i nodi

Perché uno sconosciuto dovrebbe accendere la sua GPU per far girare il modello di qualcun altro? Perché viene pagato, e i meccanismi di pagamento sono parte integrante dell’ingegneria. Ci sono due grandi famiglie. La prima è il modello marketplace, in cui il compenso segue direttamente il lavoro fatturato, come nel burn-and-mint di Render. La seconda è il modello a incentivi di protocollo di Bittensor, dove ogni subnet ha il proprio token Alpha e le emissioni di TAO ricompensano chi produce valore attraverso il meccanismo di consenso Yuma. Abbiamo spiegato in dettaglio come funzionano dTAO e i subnet nella guida dedicata.

Il passaggio chiave del 2026 è la transizione da un modello alimentato quasi solo da emissioni inflazionistiche a uno sostenuto da ricavi veri. La subnet Chutes è l’esempio più citato: secondo i dati aggregati da CoinGecko è stata la prima subnet a superare i 100 milioni di dollari di capitalizzazione dopo l’introduzione di dTAO, e i suoi ricavi da clienti reali si contano ormai in milioni di dollari l’anno, una soglia che distingue un progetto con clienti veri da un token sostenuto solo dalla speculazione. È la stessa logica che fa scattare l’attenzione dei regolatori quando un token comincia a somigliare a uno strumento finanziario.

Le regole del gioco: AI Act, MiCA e il ruolo di Consob

L’inferenza decentralizzata vive all’incrocio di due corpi normativi distinti, entrambi europei e attualissimi. Il primo è l’AI Act. Dal 2 agosto 2026 la Commissione europea, tramite l’AI Office, ha acquisito i poteri per far rispettare gli obblighi sui modelli di intelligenza artificiale per finalità generali (GPAI): può richiedere documentazione, condurre valutazioni tecniche, imporre misure di mitigazione, limitare o ritirare un modello dal mercato e comminare sanzioni fino al 3% del fatturato mondiale annuo o 15 milioni di euro, a seconda di quale importo sia maggiore, come ricostruisce il portale ufficiale dell’AI Act. I modelli immessi sul mercato prima del 2 agosto 2025 hanno tempo fino al 2 agosto 2027 per adeguarsi. La domanda spinosa, tutt’altro che risolta, è chi sia il «fornitore» quando l’inferenza gira su una rete permissionless di sconosciuti: il protocollo, il gestore del nodo o l’applicazione che chiama il modello?

Il secondo corpo normativo riguarda i token. In Italia, il calcolo in sé non è un servizio finanziario, ma i token come TAO, RENDER, AKT e IO ricadono sotto il regolamento MiCA come cripto-attività, con la Consob competente sulla condotta di mercato e la tutela degli investitori e la Banca d’Italia sui profili prudenziali e sulle stablecoin; i derivati su cripto restano sotto la MiFID II. Il decreto italiano di attuazione è il D.lgs. 129/2024 e il periodo transitorio si è chiuso il 1 luglio 2026. Il rischio latente è la qualificazione: stabilire se un token di rete come TAO sia soltanto un mezzo di pagamento o piuttosto un titolo è la stessa domanda al centro del test di Howey negli Stati Uniti, e l’esito cambia radicalmente gli obblighi di chi emette e distribuisce.

Per uno sviluppatore o una startup in Italia la conseguenza pratica è duplice. Sul fronte tecnico, appoggiarsi a una rete decentralizzata non cancella gli obblighi dell’AI Act se il servizio finale rientra tra quelli regolati: documentare e mitigare i rischi resta responsabilità di chi mette il prodotto sul mercato, non svanisce perché il calcolo gira altrove. Sul fronte finanziario, chi tratta o detiene i token di queste reti opera in un perimetro presidiato da Consob e Banca d’Italia, con obblighi di trasparenza e antiriciclaggio che valgono a prescindere dalla natura decentralizzata del protocollo. La regola pratica, come sempre in questo settore, è distinguere il livello dell’infrastruttura da quello dell’asset.

Rischi, limiti e quando conviene davvero

Dopo aver aperto il cofano, la domanda pratica è: quando ha senso usare l’inferenza decentralizzata e quando no? Non è una tecnologia universale, ed è utile essere onesti sui suoi confini.

• Ha senso per carichi asincroni e sensibili al costo, per modelli open source che entrano su GPU modeste, per applicazioni crypto-native e agenti autonomi, e dove la resistenza alla censura o l’indipendenza da un singolo fornitore hanno un valore proprio.
• Ha meno senso, per ora, per servizi con SLA rigidi e latenza critica, per i modelli di frontiera più grandi che richiedono cluster strettamente interconnessi, e per dati regolamentati (sanitari, personali sotto GDPR) dove la tracciabilità del trattamento è imprescindibile.

Restano tre rischi da non sottovalutare: il sovradimensionamento che erode il risparmio, il costo ancora alto della verifica robusta e la volatilità dei token con cui si paga o si viene pagati. Lo sguardo in avanti, però, è di consolidamento più che di ripiego. La verifica ibrida (TEE più controlli ottimistici) sta maturando, il routing diventa più intelligente, i modelli a esperti (MoE) si prestano meglio alla distribuzione e la spinta dell’AI Act verso la trasparenza potrebbe premiare proprio chi sa dimostrare cosa gira sui propri nodi. La direzione, insomma, è verso reti che smettono di vendere ore di GPU a basso costo e iniziano a vendere affidabilità dimostrabile: è lì che si deciderà se l’inferenza decentralizzata diventa infrastruttura o resta nicchia.

Domande frequenti

Che differenza c’è tra inferenza e addestramento decentralizzati?

L’addestramento costruisce il modello e richiede migliaia di GPU strettamente interconnesse per settimane, un carico difficilissimo da distribuire su hardware sparso. L’inferenza usa il modello già pronto per rispondere a un prompt, di solito su una scheda o poche schede, ed è composta da richieste indipendenti tra loro. È questa indipendenza a rendere l’inferenza molto più adatta a una rete decentralizzata di macchine eterogenee.

Un modello enorme può girare su GPU sparse per il mondo?

In teoria sì, in pratica quasi mai. Spezzare un modello colossale richiede o il tensor parallelism, che esige interconnessioni velocissime disponibili solo dentro un data center, oppure il pipeline parallelism, che tollera link più lenti ma aggiunge latenza. Per questo le reti attuali replicano modelli piccoli e medi su molti nodi indipendenti, invece di distribuire un singolo modello gigante attorno al globo. La distribuzione planetaria di un modello da centinaia di miliardi di parametri resta soprattutto terreno di ricerca.

L’inferenza decentralizzata è davvero più economica di AWS?

Il prezzo orario grezzo di una GPU può essere dal 45% al 75% più basso rispetto agli hyperscaler, ma la varianza di affidabilità spinge spesso a sovradimensionare la capacità, e questo riduce il risparmio effettivo. Per carichi asincroni e tolleranti ai guasti il vantaggio economico è reale; per servizi di produzione con requisiti di latenza e disponibilità rigidi il divario si assottiglia.

Come faccio a sapere che il nodo ha usato il modello giusto?

È il problema aperto della verifica. Gli approcci vanno dalla ri-esecuzione ottimistica a campione agli ambienti di esecuzione fidati (TEE), fino alle prove crittografiche e al fingerprinting statistico delle attivazioni. Ognuno bilancia in modo diverso costo e robustezza: la verifica forte è tecnicamente possibile ma ancora costosa, ed è il motivo per cui la fiducia resta il vero collo di bottiglia del settore.

I token come TAO o RENDER sono regolamentati in Italia?

Il servizio di calcolo in sé non è un servizio finanziario, ma i token di queste reti ricadono sotto il regolamento europeo MiCA come cripto-attività. In Italia la Consob vigila su condotta di mercato e tutela degli investitori e la Banca d’Italia sui profili prudenziali, con i derivati su cripto sotto la MiFID II. Il decreto di attuazione è il D.lgs. 129/2024 e il periodo transitorio si è concluso il 1 luglio 2026.

Marcus Okafor segue infrastrutture AI, DePIN e mercati crypto per HOGE Wire.