Inferenza decentralizzata: i costi reali e il nodo della fiducia

Nel 2026 la vera battaglia dell’intelligenza artificiale non si gioca più soltanto su chi addestra il modello più grande, ma su chi riesce a farlo rispondere. L’inferenza, cioè il momento in cui un modello già addestrato genera un testo, un’immagine o una decisione, è 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 piuttosto che al training. È 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.

La promessa è 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à ci sono due domande che decidono tutto. La prima è economica: l’inferenza decentralizzata è davvero più conveniente, o il risparmio si regge solo finché durano i sussidi in token? La seconda è 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?

Questo non è un catalogo di progetti né una lista di token da comprare. È 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ò 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ù spesso se le pongono anche gli agenti AI autonomi che pagano il calcolo da soli.

Inferenza, non training: dov’è finita la domanda di calcolo

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

L’inferenza è un’altra cosa: usa il modello già pronto, una richiesta alla volta. Per la maggior parte è 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ò reindirizzare altrove. Questa natura la rende molto più adatta a una rete di hardware eterogeneo e sparso geograficamente, dove i nodi entrano ed escono di continuo.

C’è poi il fattore economico che cambia gli equilibri. L’addestramento è un costo una tantum; l’inferenza è 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. È qui che si concentra la domanda futura, ed è qui che le reti crypto cercano di inserirsi con la leva che conoscono meglio: il prezzo.

La matematica del risparmio: quanto costa un’ora di H100

La leva competitiva numero uno è 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.

La ragione per cui c’è spazio è che la domanda di calcolo cresce più 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à già installata e inutilizzata (una GPU ferma di notte, un cluster tra un progetto e l’altro) diventa un’occasione di arbitraggio: è esattamente ciò che le reti decentralizzate provano a monetizzare, aggregando l’offerta frammentata che il cloud tradizionale non raccoglie.

I numeri, se presi ai prezzi di listino, sono notevoli. Spheron indica l’H100 SXM5 attorno a 2,40 dollari l’ora (circa 2,1 euro), mentre un’istanza AWS p5.48xlarge con otto H100 costa circa 55 dollari l’ora (circa 48 euro), cioè poco meno di 7 dollari per GPU. Sul fronte decentralizzato, io.net dichiara H100 SXM tra 2,10 e 3,50 dollari l’ora 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ù in basso.

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

I tre strati dello stack e dove si crea il margine

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 è quello dei marketplace di GPU grezze, l’infrastruttura DePIN che vende capacità di calcolo bruta. Qui operano Akash Network (AKT, circa 0,42 euro e una capitalizzazione intorno ai 125 milioni di euro), io.net (IO, circa 0,10 euro e una capitalizzazione attorno ai 40 milioni di euro), Nosana e Render Network (RENDER, circa 1,11 euro e una capitalizzazione vicina ai 577 milioni di euro).

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

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

Questa dinamica spiega perché 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à e verifica costruisce un fossato difendibile. È la stessa logica del cloud tradizionale, dove il margine non sta nel ferro ma nei servizi gestiti sopra il ferro; la differenza è che qui il coordinamento passa da un’azienda a un protocollo con incentivi in token.

Chutes: la prova che i ricavi possono essere reali

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

Il caso più istruttivo è Chutes (subnet 64, sviluppato da Rayon Labs), una piattaforma di inferenza serverless. Secondo l’analisi di CoinGecko, Chutes offre prezzi circa l’85% inferiori ad AWS e dal 10% al 50% inferiori ai provider centralizzati come Together AI; ha elaborato circa 9,1 mila miliardi di token cumulativi, con picchi giornalieri oltre i 50 miliardi, ed è stato il primo subnet a superare i 100 milioni di dollari di capitalizzazione, appena nove settimane dopo il lancio di dTAO. Ancora più 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.

Chutes non è un caso isolato dentro Bittensor: altri subnet si sono specializzati, come Nineteen (SN19), orientato all’inferenza a bassissima latenza. Il quadro d’insieme è 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é è proprio questa distinzione a separare un’infrastruttura da uno schema di incentivi che si regge solo finché il token sale.

Perché conta? Perché Chutes è la migliore evidenza disponibile che il modello a subnet può generare un business con ricavi reali e non solo emission farming, cioè token stampati per sussidiare un’attività che altrimenti non esisterebbe. È l’eccezione che dimostra la regola: non tutte le reti hanno un business sotto la capitalizzazione, e distinguere l’uso pagante dalle emissioni è il primo esercizio di igiene mentale in questo settore.

Il problema della fiducia: chi garantisce che l’abbiano calcolata davvero?

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

I modi per imbrogliare sono concreti: servire un modello più piccolo o distillato al posto di quello richiesto, ridurre la precisione numerica (da FP16 a INT8 o INT4) per andare più veloce, tagliare passi di calcolo, comprimere la cache o restituire una risposta pre-calcolata. Il risultato spesso sembra plausibile ma non è 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, e oggi l’utente non ha modo di accorgersene.

La difficoltà tecnica è che l’inferenza di un LLM su GPU non è 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. È il motivo per cui la verifica dell’inferenza è un campo di ricerca a sé.

Le strade per verificare l’inferenza

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ù grandi; è quello che si chiama trilemma della verificabilità, il compromesso tra integrità, latenza e costo.

Nessuno di questi approcci è 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à più interessante del 2026 arriva proprio dall’ultima riga della tabella.

TOPLOC: l’impronta digitale dell’inferenza

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ù 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é i valori più grandi resistono meglio agli errori di arrotondamento in virgola mobile, il che rende il controllo robusto tra GPU, kernel e ordini di calcolo diversi.

I numeri, verificabili nel paper originale, spiegano perché 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ù velocemente dell’inferenza originale e nei test raggiunge il 100% di accuratezza nel rilevare modifiche a modello, prompt o precisione, senza falsi positivi né falsi negativi. È stato provato su motori come vLLM e SGLang, con robustezza attraverso versioni CUDA, modelli di GPU e configurazioni di parallelismo diverse, ed è 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.

Non è una garanzia crittografica assoluta: resta un controllo statistico e campionario, non una prova zero-trust. Ma è economico e pratico, adatto alle reti eterogenee reali dove lo zkML è 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 è ricerca applicata, non un asset speculativo, e questo è un segnale di serietà da non sottovalutare.

TEE, zkML e il compromesso di Vitalik

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 è oggi tra i riferimenti: gestisce oltre 30.000 dispositivi TEE e serve oltre un miliardo di token al giorno, appoggiandosi anche al confidential computing delle GPU NVIDIA H100, che aggiunge un overhead contenuto. La fiducia non è azzerata ma spostata sul produttore del chip, e resta il rischio, teorico ma reale, degli attacchi side-channel.

Lo zkML produce una prova crittografica che il calcolo è corretto, verificabile da chiunque senza rieseguirlo: è l’ideale dal punto di vista della fiducia, ma generare una prova per un modello da miliardi di parametri è 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) offre un’API compatibile con OpenAI e punta sull’esecuzione deterministica dell’inferenza, con una garanzia di tipo economico basata su stake e slashing.

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ù solido della crittografia nell’intelligenza artificiale è renderne verificabili i meccanismi, ma avverte del compromesso di fondo: la verifica crittografica completa è 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, ha dichiarato, è «autonomo e verificabile, con agenti capaci di agire per conto degli utenti nel mondo reale, dal gestire capitali al negoziare accordi». Sono due facce dello stesso problema: senza verifica, l’inferenza decentralizzata resta un esperimento; con una verifica troppo cara, non decolla.

Quanto è davvero decentralizzata? Il test della realtà

Ora il contrappeso necessario, perché il rischio in questo settore è scambiare le metriche di marketing per uso reale. La prima insidia è il divario tra capacità dichiarata e capacità usata. io.net comunica una rete di oltre 300.000 GPU distribuite in più di 130 paesi, ma la capacità effettivamente pagante è 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, cioè circa il 2%. Akash ha storicamente mostrato un divario analogo tra capacità disponibile e capacità utilizzata.

Il punto è che il numero di GPU registrate è una metrica vanitosa: conta l’utilizzo pagante, non l’hardware potenzialmente disponibile. A questo si aggiunge il tema dell’affidabilità. L’hardware è 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, è un limite serio, non un dettaglio.

C’è poi la geografia. Distribuire i nodi nel mondo migliora la resilienza ma può peggiorare la latenza: instradare una richiesta verso la GPU libera più vicina non è banale, e per le applicazioni interattive (un assistente che risponde in tempo reale) qualche centinaio di millisecondi in più cambia l’esperienza d’uso. Le reti più 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.

C’è 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à è ancora sussidiata da emissioni di token piuttosto che da domanda genuina. Chutes dimostra che un business reale è possibile, ma non tutte le reti hanno un business sotto la superficie. Il consiglio pratico è banale e prezioso: guardate i ricavi reali, non la capitalizzazione, e diffidate dei conteggi di hardware registrato.

Gli agenti AI e la domanda che rende tutto necessario

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

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

Quando conviene davvero l’inferenza decentralizzata

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

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à 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à (residenza dei dati, certificazioni, un fornitore identificabile con cui firmare un contratto) impongono una controparte con un nome e una responsabilità legale. La sintesi è semplice: il risparmio di prezzo va sempre scontato per il costo della verifica e per il rischio di affidabilità. Dove la verifica è economica e la latenza non è critica, il conto torna; dove serve una garanzia crittografica completa su un modello enorme, oggi spesso non torna ancora.

Regolamentazione: AI Act, MiCA e il ruolo di Consob

Sul piano normativo europeo bisogna distinguere due binari. Il primo è l’AI Act: gli obblighi per i modelli di intelligenza artificiale per finalità generali (GPAI) sono in vigore dal 2 agosto 2025, con il Codice di condotta GPAI approvato il giorno prima. L’attività di enforcement della Commissione parte dal 2 agosto 2026, mentre i modelli già 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.

Il secondo binario è quello dei crypto-asset. L’infrastruttura in sé (le GPU, il protocollo) non è 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 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 è 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.

Un terzo profilo, spesso trascurato, è 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 è il responsabile del trattamento, come si garantisce la cancellazione. È 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à, perché permettono di elaborare dati sensibili senza esporli all’operatore del nodo.

C’è poi la domanda che ritorna a ogni ciclo: questi token sono titoli? Se un token dà diritto a una quota di ricavi o a un rendimento, la questione diventa centrale. Negli Stati Uniti si applica il test di Howey; 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, è un tema tutt’altro che accademico.

Rischi, limiti e cosa guardare nei prossimi mesi

Prima di considerare l’inferenza decentralizzata una scommessa vinta, conviene tenere a mente una lista di rischi concreti.

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

Cosa vale la pena osservare nei prossimi mesi? Il passaggio di EigenAI ed EigenCompute dalla fase alpha alla disponibilità generale, che direbbe molto sulla maturità 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à reale, non dichiarata, di queste reti. Il verdetto non arriverà da un annuncio, ma da un dato noioso: quanti token paganti passano davvero per queste GPU.

La lettura più onesta, a metà 2026, è 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ù credibile al problema della fiducia; contro, ha metriche gonfiate, un’affidabilità 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 è già competitivo, e la fiducia, che solo ora sta diventando davvero verificabile.

Domande frequenti

Che cos’è l’inferenza decentralizzata e in cosa differisce dal cloud AI?

È l’esecuzione di modelli di intelligenza artificiale già 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 è che chi esegue il calcolo è un operatore qualsiasi, senza permessi e pagato in crypto; questo abbassa i prezzi ma introduce il problema di verificare che il risultato sia autentico.

L’inferenza decentralizzata è davvero più economica del cloud tradizionale?

Sui prezzi di listino sì: 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ò da affidabilità, disponibilità e da quanto l’attività sia sostenuta da domanda reale invece che da sussidi in token; per i carichi mission-critical gli hyperscaler restano più prevedibili.

Come si verifica che un’inferenza sia stata eseguita correttamente?

Esistono più 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à, latenza e costo, e nessuno è ancora sia economico sia crittograficamente completo sui modelli molto grandi.

Quali sono i principali token legati all’inferenza decentralizzata?

I più 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.

Come sono regolati e tassati questi token in Italia?

L’infrastruttura in sé non è 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.

A cura della redazione AI e crypto di HOGE Wire.