{"id":281,"date":"2026-08-11T22:38:13","date_gmt":"2026-08-11T22:38:13","guid":{"rendered":"https:\/\/hoge.gg\/it\/inferenza-decentralizzata-hardware-gpu-routing-2026\/"},"modified":"2026-08-11T22:38:13","modified_gmt":"2026-08-11T22:38:13","slug":"inferenza-decentralizzata-hardware-gpu-routing-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/it\/inferenza-decentralizzata-hardware-gpu-routing-2026\/","title":{"rendered":"Inferenza decentralizzata: sotto il cofano, dai GPU al routing"},"content":{"rendered":"

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\u00f2 invece trovarsi in un capannone in Norvegia, in una sala server a Singapore o sotto la scrivania di uno sconosciuto a Milano. La promessa \u00e8 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.<\/p>

In questa serie abbiamo gi\u00e0 spiegato cos’\u00e8 l’inferenza decentralizzata e perch\u00e9 esiste, perch\u00e9 a trainarne la domanda siano soprattutto gli agenti AI<\/a>, e quanto costi davvero una volta messa alla prova. Questa guida apre il cofano. La domanda non \u00e8 pi\u00f9 \u00abperch\u00e9\u00bb, ma \u00abcome\u00bb: 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\u00e9 la banda della rete conti pi\u00f9 della potenza del singolo chip, e quanta energia consumi tutto questo.<\/p>

\u00c8 una storia di ingegneria prima ancora che di finanza, e come ogni storia di ingegneria \u00e8 fatta di compromessi. Ogni euro risparmiato sul prezzo orario di una GPU tende a ripresentarsi sotto forma di latenza pi\u00f9 alta, affidabilit\u00e0 variabile o un modello che nessuno pu\u00f2 garantire sia esattamente quello promesso. Capire dove si nascondono quei compromessi \u00e8 l’unico modo per giudicare se la parola \u00abdecentralizzata\u00bb sia una rivoluzione o soltanto un’etichetta di marketing.<\/p>

Inferenza, non addestramento: cosa gira quando fai una domanda<\/h2>

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\u00e0 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.<\/p>

Questa differenza \u00e8 la ragione per cui l’inferenza si presta alla decentralizzazione molto pi\u00f9 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. \u00c8 una parallelizzazione quasi banale, tollerante verso hardware eterogeneo e verso collegamenti di rete lenti. Non a caso l’inferenza \u00e8 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<\/a> e di Coincub<\/a>. Chi controlla la capacit\u00e0 di inferenza controlla la parte del mercato che cresce di pi\u00f9.<\/p>

Per i concetti di base (cos’\u00e8 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.<\/p>

Lo strato fisico: quali GPU compongono davvero la rete<\/h2>

Alla base di tutto c’\u00e8 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\u00f9 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<\/a>.<\/p>

GPU<\/th>Memoria (VRAM)<\/th>Consumo indicativo<\/th>Ruolo tipico nella rete<\/th><\/tr><\/thead>
NVIDIA H200<\/td>141 GB HBM3e<\/td>circa 700 W<\/td>Modelli grandi, inferenza premium<\/td><\/tr>
NVIDIA H100 SXM5<\/td>80 GB HBM3<\/td>circa 700 W<\/td>Cavallo di battaglia dei data center<\/td><\/tr>
NVIDIA A100<\/td>40 o 80 GB<\/td>circa 400 W<\/td>Generazione precedente, ancora diffusa<\/td><\/tr>
NVIDIA RTX 5090 \/ 4090<\/td>32 \/ 24 GB GDDR<\/td>circa 575 \/ 450 W<\/td>Nodi prosumer, modelli piccoli e medi<\/td><\/tr><\/tbody><\/table><\/figure>

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

C’\u00e8 poi un ostacolo meno visibile ma insidioso: la compatibilit\u00e0 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\u00f2 che ciascun nodo sa fare davvero. \u00c8 la differenza tra un catalogo teorico di capacit\u00e0 e la capacit\u00e0 realmente utilizzabile in questo istante, e spiega perch\u00e9 il numero di GPU dichiarate conti molto meno del numero di GPU pronte per un dato carico.<\/p>

Il problema della taglia: far entrare un modello gigante in rete<\/h2>

Il vincolo che decide quasi tutto \u00e8 la memoria. Per essere eseguito, un modello deve stare nella VRAM della GPU insieme allo spazio di lavoro necessario a rispondere. La matematica \u00e8 spietata: un modello da 70 miliardi di parametri in mezza precisione (FP16) richiede circa 140 GB di sola memoria per i pesi, pi\u00f9 della capacit\u00e0 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.<\/p>

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\u00e9 ogni nodo pu\u00f2 servire una richiesta intera da solo. I modelli giganti, invece, vanno spezzati e distribuiti su pi\u00f9 GPU, un’operazione chiamata sharding. Il modo in cui li si spezza determina se \u00e8 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<\/a>, la geografia della rete diventa il fattore decisivo.<\/p>

Tensor parallelism contro pipeline parallelism: perch\u00e9 la banda decide tutto<\/h2>

Ci sono due modi principali per distribuire un modello, e capirne la differenza \u00e8 la chiave per capire i limiti reali dell’inferenza decentralizzata. Il tensor parallelism spezza ogni singolo strato del modello tra pi\u00f9 GPU, che devono sincronizzarsi a ogni passaggio: \u00e8 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\u00e0 (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\u00f9 lenti, ma introduce latenza e tempi morti.<\/p>

Strategia<\/th>Come divide il modello<\/th>Banda di rete richiesta<\/th>Adatta a una rete decentralizzata?<\/th><\/tr><\/thead>
Tensor parallelism<\/td>Ogni strato spezzato tra pi\u00f9 GPU<\/td>Altissima (NVLink, InfiniBand)<\/td>No: solo dentro un nodo o data center<\/td><\/tr>
Pipeline parallelism<\/td>Strati diversi su nodi diversi<\/td>Media<\/td>In parte: tollera link lenti, ma aggiunge latenza<\/td><\/tr>
Replica del modello intero<\/td>Copia completa su ogni nodo<\/td>Bassa<\/td>S\u00ec: \u00e8 il modello preferito dalle reti attuali<\/td><\/tr><\/tbody><\/table><\/figure>

La conseguenza pratica \u00e8 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 \u00e8 impraticabile: la documentazione di vLLM<\/a>, il motore di inferenza pi\u00f9 diffuso, lo dice chiaramente. Ecco perch\u00e9 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\u00f9 che di produzione.<\/p>

Il routing: come una richiesta trova la GPU giusta<\/h2>

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\u00f9 criteri contemporaneamente: quel nodo ha gi\u00e0 il modello caricato in memoria? Ha capacit\u00e0 libera? \u00c8 vicino all’utente, cos\u00ec da ridurre la latenza di rete? Ha una buona reputazione di affidabilit\u00e0? 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\u00f9 bassa latenza per la geografia dell’utente, con nodi distribuiti in decine di paesi.<\/p>

Un dettaglio spesso frainteso: quasi mai \u00e8 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\u00e0 che l’utente pretende. La decentralizzazione, in altre parole, riguarda pi\u00f9 la propriet\u00e0 dell’hardware e la contabilit\u00e0 del valore che il percorso fisico del singolo pacchetto. Molte reti espongono, non a caso, un’interfaccia compatibile con le API di OpenAI, cos\u00ec che uno sviluppatore possa puntarci un’applicazione esistente cambiando poche righe.<\/p>

Batching e KV-cache: il segreto nascosto del throughput<\/h2>

Una GPU che serve un solo utente alla volta \u00e8 una GPU sprecata. Il vero motore dell’economia dell’inferenza \u00e8 la capacit\u00e0 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\u00e0 calcolato, cos\u00ec che i token successivi non debbano ricalcolare da zero l’intera conversazione. Motori come vLLM e SGLang hanno reso queste ottimizzazioni standard di settore.<\/p>

Il risultato \u00e8 che il throughput, cio\u00e8 i token al secondo prodotti da tutti gli utenti insieme, conta pi\u00f9 della velocit\u00e0 della singola risposta quando si guarda al costo. \u00c8 cos\u00ec che una subnet come Chutes, su Bittensor, arriva a numeri dichiarati enormi: secondo i dati raccolti da Own Your Mind<\/a>, l’ordine di grandezza \u00e8 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.<\/p>

Il batching non \u00e8 l’unica leva. La quantizzazione riduce la precisione numerica dei pesi (da 16 bit a 8 o persino 4), facendo entrare modelli pi\u00f9 grandi in schede pi\u00f9 piccole e aumentando la velocit\u00e0, al prezzo di una perdita di qualit\u00e0 che va misurata caso per caso. La decodifica speculativa usa un modello piccolo e veloce per proporre pi\u00f9 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\u00f9 sta erogando un servizio diverso da quello promesso, ed \u00e8 esattamente qui che il problema della verifica smette di essere teorico.<\/p>

Il viaggio di una richiesta, passo per passo<\/h2>

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

  1. L’app o l’agente invia il prompt a un endpoint della rete, spesso un’API compatibile con lo standard di OpenAI.<\/li>
  2. L’orchestratore autentica la chiamata e verifica il credito o il pagamento (in token oppure in valuta tradizionale tramite un intermediario).<\/li>
  3. L’abbinatore seleziona un nodo che abbia il modello richiesto, memoria sufficiente e bassa latenza verso l’utente.<\/li>
  4. Se il nodo non ha il modello gi\u00e0 caricato scatta un cold start: i pesi vengono trasferiti nella VRAM, operazione che per un modello grande pu\u00f2 richiedere decine di secondi. Se il modello \u00e8 gi\u00e0 caldo, si parte subito.<\/li>
  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.<\/li>
  6. I token vengono restituiti in streaming al client, di solito uno dopo l’altro man mano che sono prodotti.<\/li>
  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.<\/li><\/ol>

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

    Latenza, cold start e affidabilit\u00e0: la realt\u00e0 operativa<\/h2>

    Sulla carta il prezzo orario di una GPU decentralizzata \u00e8 imbattibile. In produzione la storia si complica. Il primo nemico \u00e8 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) \u00e8 ci\u00f2 che l’utente percepisce come lentezza. Il secondo nemico \u00e8 la varianza dell’affidabilit\u00e0: un nodo consumer pu\u00f2 spegnersi perch\u00e9 il proprietario riavvia il PC, cambia gioco o stacca la corrente. Le reti rispondono con sistemi di reputazione, staking e penalit\u00e0 (slashing), ma il rischio non sparisce.<\/p>

    Le reti serie affrontano il problema con la ridondanza. Alcune inviano la stessa richiesta a pi\u00f9 nodi e tengono la prima risposta valida, altre mantengono un pool di nodi caldi con i modelli pi\u00f9 richiesti gi\u00e0 in memoria, altre ancora costruiscono un livello di indirezione che nasconde all’utente il singolo nodo spentosi a met\u00e0 lavoro. Ognuna di queste scelte migliora l’affidabilit\u00e0 percepita, ma consuma capacit\u00e0 aggiuntiva e quindi denaro: \u00e8 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 \u00e8 disposta a scommettere.<\/p>

    Questa \u00e8 la differenza tra un’ora di GPU economica e un endpoint di produzione affidabile. L’analisi di Coincub<\/a> lo sintetizza bene: le reti decentralizzate possono costare dal 45% al 75% in meno rispetto agli hyperscaler sull’inferenza, ma la varianza di affidabilit\u00e0 spinge spesso a sovradimensionare la capacit\u00e0, 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\u00e0 molto elevata, ma raggiungere gli accordi sul livello di servizio (SLA) che un’azienda pretende resta la sfida pi\u00f9 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<\/a>.<\/p>

    Come si verifica che il nodo abbia fatto il lavoro giusto<\/h2>

    C’\u00e8 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\u00f9 piccolo ed economico, ridurre la precisione o restituire risultati approssimativi. \u00c8 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.<\/p>

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

    L’impronta energetica: il lato nascosto dell’inferenza<\/h2>

    Se l’inferenza \u00e8 la quota dominante del calcolo AI, \u00e8 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\u00f2 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<\/a>. Moltiplicato per la crescita dell’inferenza, il consumo elettrico \u00e8 diventato una variabile economica e politica di primo piano.<\/p>

    La decentralizzazione ha qui una doppia faccia, ed \u00e8 onesto raccontarle entrambe. Sul lato positivo, riusare GPU altrimenti inattive alza il tasso di utilizzo dell’hardware gi\u00e0 prodotto, riducendo lo spreco per token, e permette di collocare i nodi dove c’\u00e8 energia in eccesso o rinnovabile, con una flessibilit\u00e0 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\u00f9 trasparenza, la natura diffusa del modello rende l’impronta pi\u00f9 difficile da tracciare.<\/p>

    Qui si apre una tensione che vale la pena rendere esplicita. L’AI Act e pi\u00f9 in generale la spinta europea alla sostenibilit\u00e0 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 \u00e8 che il modello potenzialmente pi\u00f9 efficiente nell’uso dell’hardware gi\u00e0 esistente \u00e8 anche quello pi\u00f9 difficile da rendicontare, e nei prossimi anni saper dimostrare la propria impronta potrebbe diventare un vantaggio competitivo quanto il prezzo per token.<\/p>

    I protagonisti e come si dividono il lavoro<\/h2>

    Il panorama non \u00e8 monolitico: reti diverse hanno architetture e priorit\u00e0 diverse. Un fatto le accomuna, per\u00f2, ed \u00e8 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<\/a> l’11 agosto 2026.<\/p>

    Rete<\/th>Focus<\/th>Token (prezzo, cap. indicativa)<\/th>Nota distintiva<\/th><\/tr><\/thead>
    Bittensor \/ Chutes<\/td>Inferenza serverless a subnet<\/td>TAO circa 173 euro, ~1,66 mld<\/td>Ricavi reali in crescita, throughput dichiarato elevatissimo<\/td><\/tr>
    io.net<\/td>Cluster GPU on-demand su Solana<\/td>IO circa 0,10 euro, ~38 mln<\/td>Aggrega GPU inattive con il framework Ray<\/td><\/tr>
    Render<\/td>Rendering grafico e inferenza GPU<\/td>RENDER circa 1,09 euro, ~567 mln<\/td>Modello burn-and-mint, radici nella grafica<\/td><\/tr>
    Akash<\/td>Cloud decentralizzato generalista<\/td>AKT circa 0,44 euro, ~132 mln<\/td>Marketplace ad asta inversa, ampio spettro<\/td><\/tr>
    Aethir<\/td>Inferenza e gaming a bassa latenza<\/td>Token ATH<\/td>Routing geografico verso il nodo pi\u00f9 vicino<\/td><\/tr><\/tbody><\/table><\/figure>

    Le differenze contano. Render Network e il token RENDER<\/a> 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 \u00e8 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, \u00e8 un caso a s\u00e9 che merita un discorso dedicato.<\/p>

    Dal lavoro al token: come la rete paga i nodi<\/h2>

    Perch\u00e9 uno sconosciuto dovrebbe accendere la sua GPU per far girare il modello di qualcun altro? Perch\u00e9 viene pagato, e i meccanismi di pagamento sono parte integrante dell’ingegneria. Ci sono due grandi famiglie. La prima \u00e8 il modello marketplace, in cui il compenso segue direttamente il lavoro fatturato, come nel burn-and-mint di Render. La seconda \u00e8 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<\/a> nella guida dedicata.<\/p>

    Il passaggio chiave del 2026 \u00e8 la transizione da un modello alimentato quasi solo da emissioni inflazionistiche a uno sostenuto da ricavi veri. La subnet Chutes \u00e8 l’esempio pi\u00f9 citato: secondo i dati aggregati da CoinGecko<\/a> \u00e8 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. \u00c8 la stessa logica che fa scattare l’attenzione dei regolatori quando un token comincia a somigliare a uno strumento finanziario.<\/p>

    Le regole del gioco: AI Act, MiCA e il ruolo di Consob<\/h2>

    L’inferenza decentralizzata vive all’incrocio di due corpi normativi distinti, entrambi europei e attualissimi. Il primo \u00e8 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\u00e0 generali (GPAI): pu\u00f2 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<\/a>. 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, \u00e8 chi sia il \u00abfornitore\u00bb quando l’inferenza gira su una rete permissionless di sconosciuti: il protocollo, il gestore del nodo o l’applicazione che chiama il modello?<\/p>

    Il secondo corpo normativo riguarda i token. In Italia, il calcolo in s\u00e9 non \u00e8 un servizio finanziario, ma i token come TAO, RENDER, AKT e IO ricadono sotto il regolamento MiCA come cripto-attivit\u00e0, con la Consob<\/a> 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 \u00e8 il D.lgs. 129\/2024 e il periodo transitorio si \u00e8 chiuso il 1 luglio 2026. Il rischio latente \u00e8 la qualificazione: stabilire se un token di rete come TAO sia soltanto un mezzo di pagamento o piuttosto un titolo \u00e8 la stessa domanda al centro del test di Howey<\/a> negli Stati Uniti, e l’esito cambia radicalmente gli obblighi di chi emette e distribuisce.<\/p>

    Per uno sviluppatore o una startup in Italia la conseguenza pratica \u00e8 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\u00e0 di chi mette il prodotto sul mercato, non svanisce perch\u00e9 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, \u00e8 distinguere il livello dell’infrastruttura da quello dell’asset.<\/p>

    Rischi, limiti e quando conviene davvero<\/h2>

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

    • Ha senso<\/strong> 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.<\/li>
    • Ha meno senso, per ora<\/strong>, per servizi con SLA rigidi e latenza critica, per i modelli di frontiera pi\u00f9 grandi che richiedono cluster strettamente interconnessi, e per dati regolamentati (sanitari, personali sotto GDPR) dove la tracciabilit\u00e0 del trattamento \u00e8 imprescindibile.<\/li><\/ul>

      Restano tre rischi da non sottovalutare: il sovradimensionamento che erode il risparmio, il costo ancora alto della verifica robusta e la volatilit\u00e0 dei token con cui si paga o si viene pagati. Lo sguardo in avanti, per\u00f2, \u00e8 di consolidamento pi\u00f9 che di ripiego. La verifica ibrida (TEE pi\u00f9 controlli ottimistici) sta maturando, il routing diventa pi\u00f9 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, \u00e8 verso reti che smettono di vendere ore di GPU a basso costo e iniziano a vendere affidabilit\u00e0 dimostrabile: \u00e8 l\u00ec che si decider\u00e0 se l’inferenza decentralizzata diventa infrastruttura o resta nicchia.<\/p>

      Domande frequenti<\/h2>

      Che differenza c’\u00e8 tra inferenza e addestramento decentralizzati?<\/h3>

      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\u00e0 pronto per rispondere a un prompt, di solito su una scheda o poche schede, ed \u00e8 composta da richieste indipendenti tra loro. \u00c8 questa indipendenza a rendere l’inferenza molto pi\u00f9 adatta a una rete decentralizzata di macchine eterogenee.<\/p>

      Un modello enorme pu\u00f2 girare su GPU sparse per il mondo?<\/h3>

      In teoria s\u00ec, 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\u00f9 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.<\/p>

      L’inferenza decentralizzata \u00e8 davvero pi\u00f9 economica di AWS?<\/h3>

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

      Come faccio a sapere che il nodo ha usato il modello giusto?<\/h3>

      \u00c8 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 \u00e8 tecnicamente possibile ma ancora costosa, ed \u00e8 il motivo per cui la fiducia resta il vero collo di bottiglia del settore.<\/p>

      I token come TAO o RENDER sono regolamentati in Italia?<\/h3>

      Il servizio di calcolo in s\u00e9 non \u00e8 un servizio finanziario, ma i token di queste reti ricadono sotto il regolamento europeo MiCA come cripto-attivit\u00e0. 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 \u00e8 il D.lgs. 129\/2024 e il periodo transitorio si \u00e8 concluso il 1 luglio 2026.<\/p>