{"id":273,"date":"2026-08-10T22:38:18","date_gmt":"2026-08-10T22:38:18","guid":{"rendered":"https:\/\/hoge.gg\/it\/inferenza-decentralizzata-costi-fiducia-verifica-2026\/"},"modified":"2026-08-10T22:38:18","modified_gmt":"2026-08-10T22:38:18","slug":"inferenza-decentralizzata-costi-fiducia-verifica-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/it\/inferenza-decentralizzata-costi-fiducia-verifica-2026\/","title":{"rendered":"Inferenza decentralizzata: i costi reali e il nodo della fiducia"},"content":{"rendered":"

Nel 2026 la vera battaglia dell’intelligenza artificiale non si gioca pi\u00f9 soltanto su chi addestra il modello pi\u00f9 grande, ma su chi riesce a farlo rispondere. L’inferenza, cio\u00e8 il momento in cui un modello gi\u00e0 addestrato genera un testo, un’immagine o una decisione, \u00e8 diventata la voce di spesa dominante nell’infrastruttura AI: diverse analisi di settore collocano ormai tra il 55% e l’80% la quota di spesa in GPU destinata all’inferenza<\/a> piuttosto che al training. \u00c8 proprio su questo mercato che una manciata di reti crypto, da Bittensor ad Akash, da io.net a Render, promette di sottrarre lavoro ai grandi provider cloud.<\/p>

La promessa \u00e8 semplice: prendere le GPU inutilizzate sparse nel mondo, coordinarle con incentivi in token e vendere inferenza a una frazione del prezzo di AWS, Google Cloud o Microsoft Azure. Ma tra la promessa e la realt\u00e0 ci sono due domande che decidono tutto. La prima \u00e8 economica: l’inferenza decentralizzata \u00e8 davvero pi\u00f9 conveniente, o il risparmio si regge solo finch\u00e9 durano i sussidi in token? La seconda \u00e8 di fiducia: quando invii un prompt alla GPU di uno sconosciuto, come fai a sapere che ha eseguito davvero il modello giusto, alla precisione giusta, e non una versione ridotta per risparmiare?<\/p>

Questo non \u00e8 un catalogo di progetti n\u00e9 una lista di token da comprare. \u00c8 un’analisi dei due nodi che separano una narrazione di marketing da un’infrastruttura che regge: quanto costa davvero un’ora di calcolo su queste reti rispetto al cloud tradizionale, e con quali meccanismi si pu\u00f2 verificare che il risultato sia autentico. Sono le stesse domande che si pongono gli sviluppatori quando decidono dove far girare un modello, e sempre pi\u00f9 spesso se le pongono anche gli agenti AI autonomi che pagano il calcolo da soli.<\/p>

Inferenza, non training: dov’\u00e8 finita la domanda di calcolo<\/h2>

Per capire perch\u00e9 le reti decentralizzate puntano tutto sull’inferenza serve una distinzione tecnica. Il training insegna al modello: \u00e8 un processo intensivo che pu\u00f2 durare settimane o mesi, richiede migliaia di GPU strettamente interconnesse (con reti veloci come InfiniBand), \u00e8 sensibile alla latenza tra i nodi e va coordinato come un unico organismo. Decentralizzarlo \u00e8 difficile, anche se progetti come Prime Intellect e Gensyn ci stanno provando con risultati crescenti.<\/p>

L’inferenza \u00e8 un’altra cosa: usa il modello gi\u00e0 pronto, una richiesta alla volta. Per la maggior parte \u00e8 un’operazione senza stato, breve e altamente parallelizzabile. Una richiesta non ha bisogno di sapere cosa stanno facendo le altre, e se la GPU che la sta servendo cade, la si pu\u00f2 reindirizzare altrove. Questa natura la rende molto pi\u00f9 adatta a una rete di hardware eterogeneo e sparso geograficamente, dove i nodi entrano ed escono di continuo.<\/p>

C’\u00e8 poi il fattore economico che cambia gli equilibri. L’addestramento \u00e8 un costo una tantum; l’inferenza \u00e8 un costo ricorrente che cresce con ogni utente e ogni chiamata. Man mano che i prodotti AI passano dalla fase sperimentale alla produzione, l’inferenza supera il training come principale voce di spesa in calcolo. \u00c8 qui che si concentra la domanda futura, ed \u00e8 qui che le reti crypto cercano di inserirsi con la leva che conoscono meglio: il prezzo.<\/p>

La matematica del risparmio: quanto costa un’ora di H100<\/h2>

La leva competitiva numero uno \u00e8 il costo. Le GPU di fascia data center (NVIDIA H100 e H200) sono scarse e care sul cloud tradizionale; i provider centralizzati le noleggiano con ampi margini e riservano i prezzi migliori a chi accetta impegni pluriennali. Le reti decentralizzate aggregano invece hardware sottoutilizzato (data center indipendenti, miner in riconversione, operatori privati) e lo mettono all’asta, tagliando i margini di intermediazione.<\/p>

La ragione per cui c’\u00e8 spazio \u00e8 che la domanda di calcolo cresce pi\u00f9 in fretta dell’offerta. Le GPU di ultima generazione sono contingentate, i tempi di consegna dei data center si misurano in trimestri e i grandi fornitori scaricano su clienti e prezzi il costo di infrastrutture enormi. In questo scenario qualunque capacit\u00e0 gi\u00e0 installata e inutilizzata (una GPU ferma di notte, un cluster tra un progetto e l’altro) diventa un’occasione di arbitraggio: \u00e8 esattamente ci\u00f2 che le reti decentralizzate provano a monetizzare, aggregando l’offerta frammentata che il cloud tradizionale non raccoglie.<\/p>

I numeri, se presi ai prezzi di listino, sono notevoli. Spheron indica l’H100 SXM5 attorno a 2,40 dollari l’ora<\/a> (circa 2,1 euro), mentre un’istanza AWS p5.48xlarge con otto H100 costa circa 55 dollari l’ora (circa 48 euro), cio\u00e8 poco meno di 7 dollari per GPU. Sul fronte decentralizzato, io.net dichiara H100 SXM tra 2,10 e 3,50 dollari l’ora<\/a> e stima un cluster da 256 H100 attorno al 40% del costo AWS equivalente. Su Bittensor, come vedremo, il subnet Chutes spinge il risparmio ancora pi\u00f9 in basso.<\/p>

Provider<\/th>Tipo di accesso<\/th>Prezzo indicativo per GPU H100<\/th>Note<\/th><\/tr><\/thead>
AWS (p5, 8x H100)<\/td>on-demand<\/td>~6,9 $ \/ ora (~6,0 EUR)<\/td>listino elevato, sconti solo con impegni pluriennali<\/td><\/tr>
CoreWeave<\/td>riservato (impegno 1 anno)<\/td>~2,65 $ \/ ora (~2,3 EUR)<\/td>tra i pi\u00f9 bassi del cloud specializzato<\/td><\/tr>
io.net<\/td>on-demand decentralizzato<\/td>2,10-3,50 $ \/ ora (~1,8-3,0 EUR)<\/td>cluster stimati attorno al 40% del costo AWS<\/td><\/tr>
Chutes (Bittensor SN64)<\/td>serverless<\/td>fino a ~85% sotto AWS<\/td>pagamento legato ai token generati<\/td><\/tr>
Akash Network<\/td>asta inversa<\/td>variabile<\/td>prezzo fissato dall’offerta di mercato<\/td><\/tr><\/tbody><\/table>
Prezzi indicativi di listino, non garanzie di costo effettivo. Fonti citate nel testo.<\/figcaption><\/figure>

Attenzione per\u00f2: sono prezzi dichiarati. Il costo reale per chi manda un carico in produzione dipende da disponibilit\u00e0, affidabilit\u00e0 e livelli di servizio, tre variabili su cui gli hyperscaler hanno ancora un vantaggio strutturale. Un’ora di H100 a met\u00e0 prezzo vale poco se il nodo scompare a met\u00e0 lavoro. Su questo scarto tra listino e valore consegnato torneremo nella sezione dedicata al test della realt\u00e0.<\/p>

I tre strati dello stack e dove si crea il margine<\/h2>

Il settore si legge meglio come una pila di tre strati, e capire dove si cattura il valore aiuta a distinguere i progetti destinati a durare da quelli che vivono solo di narrazione. Il primo strato \u00e8 quello dei marketplace di GPU grezze, l’infrastruttura DePIN che vende capacit\u00e0 di calcolo bruta. Qui operano Akash Network (AKT, circa 0,42 euro e una capitalizzazione intorno ai 125 milioni di euro)<\/a>, io.net (IO, circa 0,10 euro e una capitalizzazione attorno ai 40 milioni di euro<\/a>), Nosana e Render Network<\/a> (RENDER, circa 1,11 euro e una capitalizzazione vicina ai 577 milioni di euro<\/a>).<\/p>

Il secondo strato \u00e8 quello dell’aggregazione e del routing: reti che trasformano capacit\u00e0 grezza in API pronte all’uso, con orchestrazione, scelta del modello, bilanciamento del carico e fatturazione. \u00c8 il livello dei subnet di Bittensor specializzati in inferenza (come Chutes o Nineteen) e degli aggregatori in stile OpenRouter. Qui si cattura pi\u00f9 valore, perch\u00e9 lo sviluppatore paga per un servizio funzionante, non per una GPU da configurare.<\/p>

Il terzo strato \u00e8 quello applicativo e dei coprocessori on-chain: portare l’inferenza dentro gli smart contract, con la verifica come requisito nativo. \u00c8 il terreno di Ritual e delle sue architetture AI-native<\/a> e degli oracoli AI, dove un contratto pu\u00f2 interrogare un modello e agire sul risultato. La lezione economica \u00e8 netta: lo strato grezzo \u00e8 una commodity soggetta a guerra dei prezzi, mentre il valore si sposta verso affidabilit\u00e0, routing e, soprattutto, verifica.<\/p>

Questa dinamica spiega perch\u00e9 quasi tutti questi progetti stanno risalendo la pila: chi vende solo GPU grezze compete su un prezzo che tende a zero, mentre chi controlla instradamento, affidabilit\u00e0 e verifica costruisce un fossato difendibile. \u00c8 la stessa logica del cloud tradizionale, dove il margine non sta nel ferro ma nei servizi gestiti sopra il ferro; la differenza \u00e8 che qui il coordinamento passa da un’azienda a un protocollo con incentivi in token.<\/p>

Chutes: la prova che i ricavi possono essere reali<\/h2>

Il progetto pi\u00f9 capitalizzato dell’ai-crypto \u00e8 Bittensor (TAO, circa 172,88 euro, capitalizzazione intorno a 1,66 miliardi di euro, tra i primi cinquanta asset per capitalizzazione<\/a>). Dal febbraio 2025 la rete adotta il meccanismo dTAO (Dynamic TAO)<\/a>, che assegna a ogni subnet un proprio token Alpha e una pool di liquidit\u00e0<\/a>: il mercato, e non pi\u00f9 solo i validatori, decide dove fluiscono le emissioni.<\/p>

Il caso pi\u00f9 istruttivo \u00e8 Chutes (subnet 64, sviluppato da Rayon Labs), una piattaforma di inferenza serverless<\/em>. Secondo l’analisi di CoinGecko, Chutes offre prezzi circa l’85% inferiori ad AWS e dal 10% al 50% inferiori ai provider centralizzati<\/a> come Together AI; ha elaborato circa 9,1 mila miliardi di token cumulativi, con picchi giornalieri oltre i 50 miliardi, ed \u00e8 stato il primo subnet a superare i 100 milioni di dollari di capitalizzazione, appena nove settimane dopo il lancio di dTAO. Ancora pi\u00f9 significativo il modello economico: Rayon Labs convoglia i ricavi in un meccanismo di auto-staking che compra token Alpha di SN64, legando la domanda del token all’uso reale del prodotto.<\/p>

Chutes non \u00e8 un caso isolato dentro Bittensor: altri subnet si sono specializzati, come Nineteen (SN19), orientato all’inferenza a bassissima latenza. Il quadro d’insieme \u00e8 che il modello a subnet, criticato a lungo come una macchina per stampare token, sta iniziando a produrre servizi che qualcuno usa e paga. Resta il punto da verificare progetto per progetto: quanta parte della capitalizzazione poggia su ricavi e quanta su emissioni, perch\u00e9 \u00e8 proprio questa distinzione a separare un’infrastruttura da uno schema di incentivi che si regge solo finch\u00e9 il token sale.<\/p>

Perch\u00e9 conta? Perch\u00e9 Chutes \u00e8 la migliore evidenza disponibile che il modello a subnet pu\u00f2 generare un business con ricavi reali e non solo emission farming<\/em>, cio\u00e8 token stampati per sussidiare un’attivit\u00e0 che altrimenti non esisterebbe. \u00c8 l’eccezione che dimostra la regola: non tutte le reti hanno un business sotto la capitalizzazione, e distinguere l’uso pagante dalle emissioni \u00e8 il primo esercizio di igiene mentale in questo settore.<\/p>

Il problema della fiducia: chi garantisce che l’abbiano calcolata davvero?<\/h2>

Qui si arriva al nodo che il marketing tende a saltare. Nel cloud tradizionale la fiducia \u00e8 implicita: paghi OpenAI o AWS e presumi che il modello sia quello dichiarato, alla precisione dichiarata, perch\u00e9 il marchio ha una reputazione da difendere. In una rete permissionless chi esegue l’inferenza \u00e8 un operatore qualsiasi, spesso anonimo, con un incentivo economico diretto a barare per aumentare i propri margini.<\/p>

I modi per imbrogliare sono concreti: servire un modello pi\u00f9 piccolo o distillato al posto di quello richiesto, ridurre la precisione numerica (da FP16 a INT8 o INT4) per andare pi\u00f9 veloce, tagliare passi di calcolo, comprimere la cache o restituire una risposta pre-calcolata. Il risultato spesso sembra plausibile ma non \u00e8 quello che avete pagato. Come sintetizza il team di Prime Intellect nel presentare il proprio metodo di verifica, i provider di inferenza apportano spesso modifiche ai metodi di calcolo per ottimizzare costi, efficienza o specifici obiettivi commerciali<\/a>, e oggi l’utente non ha modo di accorgersene.<\/p>

La difficolt\u00e0 tecnica \u00e8 che l’inferenza di un LLM su GPU non \u00e8 deterministica: l’ordine delle operazioni in virgola mobile e il parallelismo producono piccole differenze tra un hardware e l’altro, quindi non basta rieseguire il calcolo e confrontarlo bit a bit. Serve un metodo di verifica robusto a queste differenze, che distingua un errore fisiologico da un imbroglio deliberato. \u00c8 il motivo per cui la verifica dell’inferenza \u00e8 un campo di ricerca a s\u00e9.<\/p>

Le strade per verificare l’inferenza<\/h2>

Esistono cinque grandi approcci per rispondere alla domanda: ognuno sposta la fiducia da qualche parte e paga un prezzo diverso in latenza o costo. Non esiste ancora un metodo che sia contemporaneamente economico e crittograficamente completo sui modelli pi\u00f9 grandi; \u00e8 quello che si chiama trilemma della verificabilit\u00e0, il compromesso tra integrit\u00e0, latenza e costo.<\/p>

Approccio<\/th>Cosa garantisce<\/th>Assunzione di fiducia<\/th>Overhead<\/th>Esempi<\/th><\/tr><\/thead>
zkML (prove ZK)<\/td>correttezza crittografica, verificabile da chiunque<\/td>nessuna (trustless)<\/td>molto alto, oggi impraticabile su LLM grandi<\/td>Boundless, Succinct SP1, RISC Zero<\/td><\/tr>
TEE (enclave hardware)<\/td>esecuzione isolata con attestazione firmata dal chip<\/td>fiducia nel produttore del chip; rischio side-channel<\/td>basso<\/td>Phala, EigenCompute<\/td><\/tr>
opML (ottimistico)<\/td>risultato valido salvo sfida entro una finestra<\/td>almeno un osservatore onesto<\/td>latenza della finestra di sfida<\/td>Ora Protocol<\/td><\/tr>
Crypto-economico (stake\/slashing)<\/td>costo di corruzione superiore al profitto atteso<\/td>onest\u00e0 razionale degli operatori<\/td>basso<\/td>EigenAI \/ EigenCloud<\/td><\/tr>
Fingerprinting \/ spot-check<\/td>impronta delle attivazioni ricalcolata a campione<\/td>robustezza statistica, non crittografica<\/td>molto basso<\/td>TOPLOC (Prime Intellect)<\/td><\/tr><\/tbody><\/table><\/figure>

Nessuno di questi approcci \u00e8 la soluzione definitiva; ciascuno serve un caso d’uso. Le prove ZK sono l’ideale teorico ma restano proibitive; i TEE sono pratici ma spostano la fiducia sull’hardware; l’approccio ottimistico funziona se qualcuno controlla; le garanzie economiche scalano ma non azzerano il rischio. La novit\u00e0 pi\u00f9 interessante del 2026 arriva proprio dall’ultima riga della tabella.<\/p>

TOPLOC: l’impronta digitale dell’inferenza<\/h2>

TOPLOC, sviluppato da Prime Intellect, affronta il problema con un’idea elegante: invece di rieseguire tutto o di produrre una costosa prova crittografica, genera un’impronta compatta delle attivazioni. Il metodo si impegna sui valori pi\u00f9 grandi (top-k) dell’ultimo hidden state tramite una codifica polinomiale; in fase di verifica quei valori di magnitudine maggiore vengono ricalcolati e confrontati con controlli su esponente e mantissa entro soglie. Funziona perch\u00e9 i valori pi\u00f9 grandi resistono meglio agli errori di arrotondamento in virgola mobile, il che rende il controllo robusto tra GPU, kernel e ordini di calcolo diversi.<\/p>

I numeri, verificabili nel paper originale<\/a>, spiegano perch\u00e9 il metodo attira attenzione. TOPLOC riduce l’overhead di memoria di circa mille volte (258 byte ogni 32 token contro i 262 KB necessari a memorizzare gli embedding su Llama-3.1-8B-Instruct), esegue la validazione fino a cento volte pi\u00f9 velocemente dell’inferenza originale e nei test raggiunge il 100% di accuratezza nel rilevare modifiche a modello, prompt o precisione, senza falsi positivi n\u00e9 falsi negativi. \u00c8 stato provato su motori come vLLM e SGLang, con robustezza attraverso versioni CUDA, modelli di GPU e configurazioni di parallelismo diverse, ed \u00e8 stato usato per validare i rollout worker di INTELLECT-2, il primo addestramento di reinforcement learning distribuito globalmente di un modello da 32 miliardi di parametri.<\/p>

Non \u00e8 una garanzia crittografica assoluta: resta un controllo statistico e campionario, non una prova zero-trust. Ma \u00e8 economico e pratico, adatto alle reti eterogenee reali dove lo zkML \u00e8 troppo costoso, e alza in modo sostanziale il costo di barare. Vale la pena notare che Prime Intellect, come diverse infrastrutture serie del settore, non ha (ancora) un token quotato: la sua \u00e8 ricerca applicata, non un asset speculativo, e questo \u00e8 un segnale di seriet\u00e0 da non sottovalutare.<\/p>

TEE, zkML e il compromesso di Vitalik<\/h2>

Gli altri approcci hanno ciascuno il proprio momento. I TEE (Trusted Execution Environment) eseguono il modello in un’enclave hardware cifrata che produce un’attestazione firmata dal chip. Phala Network \u00e8 oggi tra i riferimenti: gestisce oltre 30.000 dispositivi TEE e serve oltre un miliardo di token al giorno<\/a>, appoggiandosi anche al confidential computing delle GPU NVIDIA H100, che aggiunge un overhead contenuto. La fiducia non \u00e8 azzerata ma spostata sul produttore del chip, e resta il rischio, teorico ma reale, degli attacchi side-channel.<\/p>

Lo zkML produce una prova crittografica che il calcolo \u00e8 corretto, verificabile da chiunque senza rieseguirlo: \u00e8 l’ideale dal punto di vista della fiducia, ma generare una prova per un modello da miliardi di parametri \u00e8 oggi ordini di grandezza troppo caro. Marketplace di prove come Boundless e Succinct (con lo zkVM SP1) stanno abbassando i costi, ma per l’inferenza LLM completa siamo agli inizi. Sul versante crypto-economico, EigenAI (l’API di inferenza verificabile di EigenCloud, lanciata in mainnet alpha a fine settembre 2025<\/a>) offre un’API compatibile con OpenAI e punta sull’esecuzione deterministica dell’inferenza, con una garanzia di tipo economico basata su stake e slashing.<\/p>

Vale la pena ascoltare due voci autorevoli. Nel suo saggio del 30 gennaio 2024 su crypto e AI, Vitalik Buterin sostiene che l’uso pi\u00f9 solido della crittografia nell’intelligenza artificiale \u00e8 renderne verificabili i meccanismi<\/a>, ma avverte del compromesso di fondo: la verifica crittografica completa \u00e8 costosa, e in molti casi conviene un calcolo economico e non verificabile rispetto a uno verificabile ma proibitivo. Sreeram Kannan, fondatore e CEO di EigenCloud, mette invece l’accento sulla direzione di marcia: il futuro del software<\/a>, ha dichiarato, \u00e8 \u00abautonomo e verificabile, con agenti capaci di agire per conto degli utenti nel mondo reale, dal gestire capitali al negoziare accordi\u00bb. Sono due facce dello stesso problema: senza verifica, l’inferenza decentralizzata resta un esperimento; con una verifica troppo cara, non decolla.<\/p>

Quanto \u00e8 davvero decentralizzata? Il test della realt\u00e0<\/h2>

Ora il contrappeso necessario, perch\u00e9 il rischio in questo settore \u00e8 scambiare le metriche di marketing per uso reale. La prima insidia \u00e8 il divario tra capacit\u00e0 dichiarata e capacit\u00e0 usata. io.net comunica una rete di oltre 300.000 GPU distribuite in pi\u00f9 di 130 paesi, ma la capacit\u00e0 effettivamente pagante \u00e8 molto minore: secondo un’analisi indipendente su un trimestre di riferimento risultavano circa 327.000 GPU registrate a fronte di una media giornaliera di sole 6.720 GPU verificate e attive<\/a>, cio\u00e8 circa il 2%. Akash ha storicamente mostrato un divario analogo tra capacit\u00e0 disponibile e capacit\u00e0 utilizzata.<\/p>

Il punto \u00e8 che il numero di GPU registrate \u00e8 una metrica vanitosa: conta l’utilizzo pagante, non l’hardware potenzialmente disponibile. A questo si aggiunge il tema dell’affidabilit\u00e0. L’hardware \u00e8 eterogeneo, i nodi entrano ed escono, e nessuna di queste reti offre garanzie di uptime paragonabili a quelle di un hyperscaler. Per un carico mission-critical, ad esempio l’inferenza dietro a un prodotto con milioni di utenti, \u00e8 un limite serio, non un dettaglio.<\/p>

C’\u00e8 poi la geografia. Distribuire i nodi nel mondo migliora la resilienza ma pu\u00f2 peggiorare la latenza: instradare una richiesta verso la GPU libera pi\u00f9 vicina non \u00e8 banale, e per le applicazioni interattive (un assistente che risponde in tempo reale) qualche centinaio di millisecondi in pi\u00f9 cambia l’esperienza d’uso. Le reti pi\u00f9 mature investono in orchestrazione e caching proprio per contenere questo effetto, ma resta un compromesso strutturale rispetto a un singolo data center ottimizzato e vicino all’utente.<\/p>

C’\u00e8 infine la questione della reale distribuzione. Molti nodi possono concentrarsi in pochi data center o in mano a pochi operatori: decentralizzato non significa automaticamente distribuito. E parte dell’attivit\u00e0 \u00e8 ancora sussidiata da emissioni di token piuttosto che da domanda genuina. Chutes dimostra che un business reale \u00e8 possibile, ma non tutte le reti hanno un business sotto la superficie. Il consiglio pratico \u00e8 banale e prezioso: guardate i ricavi reali, non la capitalizzazione, e diffidate dei conteggi di hardware registrato.<\/p>

Gli agenti AI e la domanda che rende tutto necessario<\/h2>

Perch\u00e9 tutto questo sta accadendo adesso, e non \u00e8 solo un esercizio ideologico sulla decentralizzazione? La risposta pi\u00f9 concreta arriva dagli agenti AI autonomi, che sono il committente naturale dell’inferenza decentralizzata. Un agente software non pu\u00f2 aprire un conto AWS con carta di credito e passaggio KYC; pu\u00f2 per\u00f2 pagare per singola chiamata in crypto, senza chiedere permessi, e ha bisogno di prove verificabili di ci\u00f2 che consuma per essere affidabile agli occhi di chi gli affida denaro.<\/p>

\u00c8 la stessa dinamica che vediamo emergere con gli agenti AI sui mercati predittivi<\/a>: software che opera con capitale reale e che, per essere considerato affidabile, deve poter dimostrare come \u00e8 arrivato a una decisione. Quando un contratto on-chain agisce sulla base dell’output di un modello, la verifica non \u00e8 un lusso ma un requisito. Ecco perch\u00e9 lo strato applicativo (Ritual, gli oracoli AI, gli agenti che gestiscono capitali) \u00e8 quello che tira la domanda di inferenza verificabile, e non viceversa. La tecnologia della verifica esiste perch\u00e9 serve a qualcuno che rischia soldi.<\/p>

Quando conviene davvero l’inferenza decentralizzata<\/h2>

Messi insieme i costi, la verifica e i limiti, la domanda pratica diventa una sola: per quali carichi ha senso oggi? Non \u00e8 una risposta binaria, dipende dal profilo del lavoro. L’inferenza decentralizzata conviene quando la sensibilit\u00e0 al prezzo \u00e8 alta e una certa variabilit\u00e0 di latenza \u00e8 tollerabile: generazione asincrona, elaborazioni in batch, prototipi, fine-tuning sperimentali, carichi che scalano a ondate. Conviene anche quando servono neutralit\u00e0 e assenza di deplatforming, cio\u00e8 modelli o contenuti che un fornitore centralizzato potrebbe rifiutare, e quando il pagante \u00e8 un agente on-chain che ha bisogno di micro-pagamenti senza permessi e di prove verificabili di ci\u00f2 che ha consumato.<\/p>

Conviene meno, almeno per ora, in tre casi. Primo, i carichi mission-critical con SLA stringenti e latenza garantita al 99esimo percentile, dove la prevedibilit\u00e0 di un hyperscaler vale il sovrapprezzo. Secondo, quando servono i modelli proprietari di frontiera, disponibili solo dietro API centralizzate. Terzo, quando i requisiti di conformit\u00e0 (residenza dei dati, certificazioni, un fornitore identificabile con cui firmare un contratto) impongono una controparte con un nome e una responsabilit\u00e0 legale. La sintesi \u00e8 semplice: il risparmio di prezzo va sempre scontato per il costo della verifica e per il rischio di affidabilit\u00e0. Dove la verifica \u00e8 economica e la latenza non \u00e8 critica, il conto torna; dove serve una garanzia crittografica completa su un modello enorme, oggi spesso non torna ancora.<\/p>

Regolamentazione: AI Act, MiCA e il ruolo di Consob<\/h2>

Sul piano normativo europeo bisogna distinguere due binari. Il primo \u00e8 l’AI Act: gli obblighi per i modelli di intelligenza artificiale per finalit\u00e0 generali (GPAI) sono in vigore dal 2 agosto 2025<\/a>, con il Codice di condotta GPAI approvato il giorno prima. L’attivit\u00e0 di enforcement della Commissione parte dal 2 agosto 2026, mentre i modelli gi\u00e0 sul mercato hanno tempo fino al 2 agosto 2027 per adeguarsi. Gli obblighi principali riguardano documentazione tecnica, sintesi dei dati di addestramento e rispetto del diritto d’autore. Chi fornisce inferenza di modelli GPAI in Europa rientra in questo perimetro, come provider o come deployer a seconda del ruolo.<\/p>

Il secondo binario \u00e8 quello dei crypto-asset. L’infrastruttura in s\u00e9 (le GPU, il protocollo) non \u00e8 regolata come tale, ma lo sono i token che la pagano e i servizi costruiti sopra. In Italia il D.lgs. 129\/2024 designa Consob<\/a> per la condotta e la protezione degli investitori e Banca d’Italia per gli aspetti prudenziali e per le stablecoin (ART ed EMT); il periodo transitorio MiCA si \u00e8 chiuso il 1 luglio 2026. Una piattaforma italiana che scambia o custodisce TAO, AKT, IO o RENDER deve avere l’autorizzazione CASP. I derivati crypto (future e perpetual) restano invece sotto la MiFID II, non sotto MiCA.<\/p>

Un terzo profilo, spesso trascurato, \u00e8 la protezione dei dati. Inviare un prompt a una GPU gestita da un operatore sconosciuto solleva domande concrete sotto il GDPR quando quel prompt contiene dati personali: dove viene elaborato il dato, chi ne \u00e8 il responsabile del trattamento, come si garantisce la cancellazione. \u00c8 proprio qui che i TEE, con la loro esecuzione isolata e attestata, diventano non solo uno strumento di verifica ma anche un tassello di conformit\u00e0, perch\u00e9 permettono di elaborare dati sensibili senza esporli all’operatore del nodo.<\/p>

C’\u00e8 poi la domanda che ritorna a ogni ciclo: questi token sono titoli? Se un token d\u00e0 diritto a una quota di ricavi o a un rendimento, la questione diventa centrale. Negli Stati Uniti si applica il test di Howey<\/a>; in Europa vale l’approccio della sostanza sulla forma delle linee guida ESMA, adottate da Consob, che distingue tra crypto-asset MiCA e strumento finanziario MiFID II. Per gli asset legati all’inferenza, in cui i meccanismi di auto-staking creano un legame diretto tra ricavi del protocollo e valore del token, \u00e8 un tema tutt’altro che accademico.<\/p>

Rischi, limiti e cosa guardare nei prossimi mesi<\/h2>

Prima di considerare l’inferenza decentralizzata una scommessa vinta, conviene tenere a mente una lista di rischi concreti.<\/p>

  • Diluizione da emissioni:<\/strong> molti token del settore hanno inflazione elevata e sblocchi programmati (vesting) che pesano sul prezzo; il metro corretto \u00e8 il rapporto tra ricavi reali ed emissioni.<\/li>
  • Trilemma della verificabilit\u00e0:<\/strong> integrit\u00e0, latenza e costo non si massimizzano insieme, e ogni metodo di verifica sceglie un compromesso diverso.<\/li>
  • Paradosso del determinismo:<\/strong> l’inferenza su GPU non \u00e8 riproducibile bit a bit, e questo complica lo zkML e alcune forme di verifica.<\/li>
  • Fiducia nell’hardware:<\/strong> i TEE spostano la fiducia sul produttore del chip e restano esposti a vulnerabilit\u00e0 side-channel.<\/li>
  • Affidabilit\u00e0 e SLA:<\/strong> uptime e garanzie di servizio non sono ai livelli degli hyperscaler, un limite per i carichi critici.<\/li>
  • Regolamentazione e fisco:<\/strong> in Italia plusvalenze e proventi da staking vanno valutati caso per caso secondo la normativa vigente.<\/li><\/ul>

    Cosa vale la pena osservare nei prossimi mesi? Il passaggio di EigenAI ed EigenCompute dalla fase alpha alla disponibilit\u00e0 generale, che direbbe molto sulla maturit\u00e0 della verifica crypto-economica; l’adozione di metodi di verifica economici come TOPLOC oltre il perimetro di Prime Intellect; l’avvio effettivo dell’enforcement dell’AI Act sui GPAI dal 2 agosto 2026; e soprattutto l’andamento della curva della domanda di inferenza (spinta da agenti e prodotti in produzione) rispetto alla capacit\u00e0 reale, non dichiarata, di queste reti. Il verdetto non arriver\u00e0 da un annuncio, ma da un dato noioso: quanti token paganti passano davvero per queste GPU.<\/p>

    La lettura pi\u00f9 onesta, a met\u00e0 2026, \u00e8 che l’inferenza decentralizzata ha superato la fase della pura promessa ma non ha ancora vinto la partita. Ha dalla sua un vantaggio di costo reale su una categoria crescente di carichi e una risposta tecnica sempre pi\u00f9 credibile al problema della fiducia; contro, ha metriche gonfiate, un’affidabilit\u00e0 disomogenea e una dipendenza ancora forte dagli incentivi in token. Chi guarda al settore, da investitore o da sviluppatore, farebbe bene a tenere separate le due cose che questo articolo ha provato a misurare: il prezzo, che \u00e8 gi\u00e0 competitivo, e la fiducia, che solo ora sta diventando davvero verificabile.<\/p>

    Domande frequenti<\/h2>

    Che cos’\u00e8 l’inferenza decentralizzata e in cosa differisce dal cloud AI?<\/h3>

    \u00c8 l’esecuzione di modelli di intelligenza artificiale gi\u00e0 addestrati su una rete di GPU indipendenti coordinate da incentivi in token, invece che sui server di un unico provider come AWS o Google Cloud. La differenza chiave \u00e8 che chi esegue il calcolo \u00e8 un operatore qualsiasi, senza permessi e pagato in crypto; questo abbassa i prezzi ma introduce il problema di verificare che il risultato sia autentico.<\/p>

    L’inferenza decentralizzata \u00e8 davvero pi\u00f9 economica del cloud tradizionale?<\/h3>

    Sui prezzi di listino s\u00ec: reti come io.net e Chutes dichiarano risparmi tra il 40% e l’85% rispetto ad AWS per GPU equivalenti. Il risparmio effettivo dipende per\u00f2 da affidabilit\u00e0, disponibilit\u00e0 e da quanto l’attivit\u00e0 sia sostenuta da domanda reale invece che da sussidi in token; per i carichi mission-critical gli hyperscaler restano pi\u00f9 prevedibili.<\/p>

    Come si verifica che un’inferenza sia stata eseguita correttamente?<\/h3>

    Esistono pi\u00f9 approcci: prove a conoscenza zero (zkML), ambienti di esecuzione fidati (TEE), verifica ottimistica con fraud proof (opML), garanzie economiche con stake e slashing, e metodi di fingerprinting come TOPLOC che ricalcolano a campione un’impronta delle attivazioni. Ognuno bilancia in modo diverso integrit\u00e0, latenza e costo, e nessuno \u00e8 ancora sia economico sia crittograficamente completo sui modelli molto grandi.<\/p>

    Quali sono i principali token legati all’inferenza decentralizzata?<\/h3>

    I pi\u00f9 capitalizzati sono Bittensor (TAO), Render (RENDER), Akash (AKT) e io.net (IO), a cui si affiancano infrastrutture senza token quotato come Prime Intellect e Ritual. Attenzione: la capitalizzazione di un token non misura l’uso reale della rete, e molti progetti hanno un’inflazione da emissioni elevata.<\/p>

    Come sono regolati e tassati questi token in Italia?<\/h3>

    L’infrastruttura in s\u00e9 non \u00e8 regolata, ma i token rientrano tra i crypto-asset MiCA e una piattaforma italiana che li scambia o li custodisce deve avere l’autorizzazione CASP, con Consob per la condotta e Banca d’Italia per gli aspetti prudenziali. Sul piano fiscale, plusvalenze e proventi da staking vanno valutati caso per caso secondo la normativa vigente; per la classificazione come eventuale strumento finanziario conta la sostanza sulla forma.<\/p>