WebNN e ONNX Runtime Web: lo stack di inferenza accelerata nel browser

Ogni volta che qualcuno parla di eseguire l'intelligenza artificiale nel browser, la conversazione si trasforma presto in una domanda ingegneristica molto concreta: come farà un modello addestrato in Python, su un server con una GPU, a finire in una scheda di Chrome e a funzionare abbastanza velocemente da essere utile? La risposta non è un singolo prodotto. È una pila di tre pezzi che si incastrano insieme, e capire come si incastrano è ciò che separa una solida decisione architettonica da un esperimento che muore nel prototipo.

I tre pezzi sono una forma, un motore e un livello di accelerazione. Il formato è ONNX. Il motore è ONNX Runtime Web. Il livello di accelerazione è WebNN. Ognuno risolve un problema diverso e il divertimento sta nel modo in cui si uniscono.

Il formato: ONNX come denominatore comune

I modelli nascono in contesti diversi. Un team si allena con PyTorch, un altro con TensorFlow, un altro con i propri strumenti. Ogni framework memorizza il modello a modo suo e questo diventa problematico quando si desidera portare il modello fuori dall'ambiente in cui è stato creato.

ONNX, che sta per Open Neural Network Exchange, è un formato aperto progettato per essere quel denominatore comune. Ti alleni dove vuoi ed esporti su ONNX. Il modello è ora descritto in modo standardizzato, indipendente dal framework di origine, che può essere letto da qualsiasi strumento compatibile.

Per coloro che decidono l'architettura, il valore di ONNX è il disaccoppiamento. La scelta del quadro formativo non vincola più la scelta dell'ambiente di esecuzione. Allenati in un posto, corri in un altro e il formato intermedio garantisce l'esistenza del ponte. È un'infrastruttura noiosa nel senso migliore del termine: non ci pensi quando funziona.

Il motore: ONNX Runtime Web viene eseguito nel browser

Avere il modello in ONNX non è sufficiente. Qualcuno deve caricare questo file, interpretare la sequenza di operazioni che descrive e fare effettivamente i conti. Questo è il compito di un runtime di inferenza.

ONNX Runtime Web è la versione di questo runtime realizzata per essere eseguita all'interno del browser. Prende il modello ONNX e lo esegue sul client, utilizzando le risorse offerte dalla piattaforma web. Storicamente, ciò significava due percorsi: WebAssembly, che viene eseguito sulla CPU con prestazioni decenti, e WebGL, che sfrutta la GPU tramite l'API grafica del browser.

Questi percorsi funzionano, ma hanno dei limiti. WebAssembly sulla CPU è portatile e affidabile, ma non è il modo più veloce per i modelli più grandi. WebGL utilizza la GPU, ma indirettamente, poiché è stata creata per eseguire il rendering della grafica, non per eseguire reti neurali. È qui che entra in gioco il terzo pezzo dello stack, quello che cambia il limite massimo delle prestazioni.

Accelerazione: WebNN e accesso all'hardware giusto

WebNN, o Web Neural Network API, è un'API che fornisce al browser l'accesso diretto all'hardware di accelerazione AI del dispositivo. Invece di utilizzare un'API grafica come intermediario, comunica con ciò che è più adatto sul dispositivo: la CPU, la GPU o, quando disponibile, la NPU.

La NPU merita attenzione. È l'unità di elaborazione neurale, un blocco di silicio dedicato alle operazioni della rete neurale che appare frequentemente nei moderni telefoni cellulari e laptop. Esegue l'inferenza consumando meno energia e in modo più efficiente rispetto a una CPU o GPU generica. Il problema è che, fino a WebNN, il browser semplicemente non aveva modo di comunicare con esso. La NPU era lì, inattiva, invisibile al web.

ONNX Runtime Web può utilizzare WebNN come uno dei percorsi di esecuzione. Quando ciò accade, il motore delega il lavoro pesante al livello che sa come gestire il miglior hardware disponibile. Il modello ONNX rimane lo stesso. Ciò che cambia è dove e come scorre sotto, con un salto di prestazioni ed efficienza energetica che i vecchi tracciati non ottenevano. Questo guadagno è ciò che rende, in pratica, l'[inferenza locale nel browser] fattibile per modelli che in precedenza avevano senso solo sul server.

L'intera pila, da un'estremità all'altra

Vale la pena mettere insieme i pezzi in un unico flusso mentale. Un modello viene addestrato in qualsiasi framework, sul server, con l'intera infrastruttura di addestramento. Viene quindi esportato in ONNX, ottenendo una rappresentazione standardizzata e portabile. Questo file viene inviato al browser, dove ONNX Runtime Web lo carica ed esegue. E, quando l'ambiente lo consente, il runtime attiva WebNN in modo che gli account vengano eseguiti sulla CPU, GPU o NPU del dispositivo dell'utente.

Il risultato di questa catena è un'inferenza che avviene interamente sul client. Nessun dato deve necessariamente viaggiare verso un server, il che è importante per la privacy. Nessuna richiesta genera costi di cloud computing, che contano sulla bolletta di fine mese. Inoltre, non c'è latenza di rete tra l'azione dell'utente e la risposta del modello, il che è importante per l'esperienza.

Aggiungete questo alla quantizzazione del modello, che riduce ONNX a una dimensione di download ragionevole, e avrete una combinazione che finalmente rende l'intelligenza artificiale nel browser difendibile nel prodotto, non solo nella demo.

I limiti che devi rispettare

Ecco la parte che separa l’entusiasmo dalla responsabilità. WebNN non è ancora una tecnologia matura e stabile ovunque. Al W3C è in fase di Candidate Recommendation, ovvero è una specifica avanzata ma non ancora finalizzata come standard consolidato. Ciò significa che i dettagli possono cambiare.

Il sostegno pratico non è uniforme. L'esecuzione accelerata GPU e NPU di WebNN nella maggior parte dei browser è in fase di anteprima o dietro flag sperimentali. Funziona in ambienti controllati, in versioni specifiche, con configurazioni specifiche. Non è qualcosa su cui puoi contare in modo uniforme su tutti i dispositivi e i browser dei tuoi utenti reali.

La raccomandazione, quindi, è diretta e poco romantica: non collocare ancora WebNN come una dipendenza critica della produzione. Utilizzare per prototipi, prove di concetto, funzionalità opzionali che si degradano gradualmente quando l'accelerazione non è disponibile. Avere sempre un percorso di fallback, in genere WebAssembly sulla CPU, per quando non è possibile attivare l'accelerazione hardware. Trattare una specifica nella Candidate Recommendation come se fosse un'infrastruttura stabile è il tipo di scommessa che invecchia male.

Come pensare a questa decisione

Per i progettisti di architettura, lo stack ONNX più ONNX Runtime Web più WebNN rappresenta una scommessa sensata a medio termine, non una base per oggi. Il formato ONNX e ONNX Runtime Web sono già sufficientemente solidi per l'uso nel mondo reale, inclusi i percorsi tradizionali di CPU e GPU. Il livello WebNN è il futuro delle prestazioni, ma un futuro che deve ancora arrivare.

Leggere onestamente significa separare ciò che è già pronto da ciò che è ancora maturo. Adotta ONNX come formato senza paura, ti dà portabilità oggi. Utilizza ONNX Runtime Web laddove l'inferenza lato client ha senso, affidandosi a WebAssembly come base affidabile. E tratta WebNN come un'ottimizzazione progressiva: quando è disponibile e stabile, accelera; in caso contrario, il prodotto continua a funzionare. Questa posizione si adatta bene alla maturità attesa dallo sviluppo web nel 2026, dove risorse all’avanguardia si aggiungeranno a una base che non dipende mai da esse.

Se stai creando una strategia di intelligenza artificiale lato client, la mossa prudente è quella di basarsi su ONNX e ONNX Runtime Web ora, con un solido fallback, e monitorare l'evoluzione di WebNN per attivare l'accelerazione man mano che matura. Inizia con ciò che è stabile e lascia spazio a ciò che verrà.