L'inferenza dell'intelligenza artificiale nel cloud è il percorso predefinito. Addestra il modello su GPU potenti, ospiti un endpoint e chiami l'API quando la tua app necessita di una risposta. È un'architettura pulita, ben documentata e con una buona copertura degli strumenti. Il problema è che questa premessa porta con sé un presupposto inespresso: che la latenza della rete sia accettabile, che la privacy possa essere delegata a terzi e che il costo per chiamata non aumenterà con l’aumento dell’utilizzo. Quando si esaminano attentamente questi tre presupposti, si scopre che il cloud non è la scelta ovvia in più situazioni di quanto potrebbe sembrare.
Perché la latenza è il primo vero problema
Una risposta LLM tramite API richiede in genere tra 300 millisecondi e 2 secondi, a seconda delle dimensioni del modello, del carico del server e della qualità della connessione dell'utente. Per molte applicazioni, questo tempo è accettabile. Per altri è fatale.
Prendiamo in considerazione un assistente vocale in un’auto, un sistema di riconoscimento dei gesti in un dispositivo industriale o un’app di traduzione in tempo reale utilizzata da un medico in una regione con una copertura dati instabile. In tutti questi casi, attendere che un pacchetto di dati raggiunga un data center e ritorno non è un vincolo operativo minore: è il fattore determinante per stabilire se il prodotto funziona effettivamente. L'inferenza locale elimina questo percorso. Il modello viene eseguito sul chip del dispositivo, la risposta arriva in decine di millisecondi e nessuna riga di stato della rete entra nell'equazione.
Privacy come vantaggio competitivo, non solo compliance
Quando invii dati al cloud per l'inferenza, stai trasferendo informazioni potenzialmente sensibili a server di terze parti. Ciò include ciò che l'utente ha digitato, ciò che ha detto, ciò che ha visto la fotocamera. Anche con solidi contratti di elaborazione dati e certificazioni SOC 2, la domanda che l'utente aziendale o l'autorità di regolamentazione si porrà è semplice: questi dati lasciano il dispositivo?
Con l’inferenza locale, la risposta è no. Il modello elabora tutto sull'hardware dell'utente. Nessun pacchetto sale. Per settori come quello sanitario, finanziario, legale e della difesa, questa caratteristica non è un differenziale di marketing, ma un requisito tecnico contrattuale. Le aziende che realizzano prodotti per questi mercati e ignorano le inferenze locali si stanno, di fatto, escludendo da contratti che richiedono la sovranità dei dati.
La logica si applica anche agli utenti finali. App per tastiera predittiva che elaborano il testo localmente, assistenti personali che non sincronizzano mai la cronologia delle conversazioni, strumenti di analisi dei documenti che funzionano offline: rispondono tutti a una domanda reale da parte di persone che non vogliono che i propri dati fluiscano attraverso un'infrastruttura che non controllano.
Dove il cloud vince ancora senza discussioni
L’onestà strategica richiede il riconoscimento dei limiti del dispositivo. GPT-4 non funziona su un iPhone. I modelli all’avanguardia, con miliardi di parametri, richiedono una quantità di memoria e potenza di calcolo che semplicemente non esiste, per ora, nell’hardware di consumo. Il cloud rimane l'unico luogo in cui è possibile eseguire i modelli più capaci senza compromettere la reattività.
La flessibilità degli aggiornamenti pesa anche sul lato cloud. Quando servi il modello in remoto, puoi aggiornare pesi, cambiare versione o correggere comportamenti senza distribuire una nuova versione della tua app. Con l'inferenza locale, il modello è confezionato in binario. Per aggiornamento si intende una nuova release, con tutti i costi di revisione dello store, download e adozione graduale.
Le attività che sono già di natura asincrona (generazione di report, sintesi di documenti lunghi, ragionamenti complessi su grandi volumi di testo) non soffrono della latenza di rete e beneficiano della potenza di calcolo illimitata del cloud. Forzare questi carichi sul dispositivo significherebbe ottimizzare il punto sbagliato.
Il costo su larga scala è il punto in cui gira il calcolo
Per volumi di inferenza ridotti, il costo per chiamata API è trascurabile. Per i prodotti con milioni di utenti attivi che eseguono decine di inferenze per sessione, il costo mensile inizia a competere con il libro paga. Questa non è una proiezione ipotetica: le aziende con app di produttività ad alta intensità di intelligenza artificiale stanno già affrontando questo problema oggi.
L'inferenza locale sposta il costo dell'operazione sull'hardware dell'utente. Il modello viene eseguito sul processore del dispositivo e ciò per cui paghi è la dimensione del codice binario, non il volume delle inferenze. Per i prodotti in cui l'utilizzo per sessione è elevato e prevedibile, questo compromesso modifica radicalmente la struttura dei costi. Il costo marginale di ogni risposta aggiuntiva scende a zero una volta installata l'app. Per i team che realizzano prodotti con margini ristretti, questo non è un dettaglio architettonico, ma una decisione sul modello di business.
Toolchain e criteri concreti per decidere
Gli strumenti per l’inferenza locale sono sufficientemente maturi da essere presi seriamente in considerazione in nuovi progetti. CoreML di Apple compila modelli da eseguire con l'accelerazione Neural Engine su dispositivi iOS e macOS. Il runtime ONNX è portabile su tutte le piattaforme e supporta la quantizzazione aggressiva del modello, riducendo le dimensioni e il consumo di memoria senza una grave perdita di precisione. TensorFlow Lite copre Android con una buona copertura operativa e accelerazione GPU. MediaPipe offre pipeline già pronte per la visione artificiale e l'elaborazione audio, ottimizzate per i dispositivi mobili senza richiedere al team di reinventare ogni fase del processo.
La scelta tra cloud e dispositivo è raramente binaria. L'architettura più robusta è spesso ibrida: modelli più piccoli e più veloci vengono eseguiti localmente per interazioni immediate e frequenti, mentre le attività che richiedono modelli più grandi vengono delegate al cloud in modo asincrono quando esiste la connettività. I criteri decisionali riguardano tre domande concrete: è importante il tempo di risposta in millisecondi? I dati elaborati non possono lasciare il dispositivo? Il volume delle inferenze renderà il costo API rilevante nella struttura dei costi del prodotto? Se la risposta è sì a una qualsiasi di queste domande, l’inferenza locale merita di essere la prima opzione sul tavolo e non una risorsa di emergenza per quando la rete fallisce.
Leggi anche
- AI nel browser: perché eseguire l'inferenza sul dispositivo dell'utente
- Chip di inferenza e ASIC: quando lo specializzato batte il generico
- Edge computing in fabbrica: quando lavorare localmente ha più senso
- AI sul dispositivo: la decisione strategica tra server e dispositivo
- Edge computing: perché l'informatica lascia il cloud e si avvicina ai dati
- AI a risparmio energetico: più piccola ed economica batte più grande