Dai 5x ai 10x: come spremere WebGPU per l’inferenza AI nel browser

WebGPU sta cambiando il modo in cui pensiamo alle prestazioni nel browser, soprattutto per i carichi di lavoro di inferenza AI. Non parliamo più di piccoli miglioramenti: quando si lavora “a livello basso”, ottimizzando grafo e kernel, gli incrementi possono arrivare nell’ordine di 5x–10x.

L’aspetto interessante è che questi risultati non dipendono da una singola magia, ma da un insieme di decisioni architetturali molto concrete: costruire un motore di inferenza dedicato a WebGPU, scrivere kernel su misura, e applicare ottimizzazioni aggressive sul dataflow per minimizzare il collo di bottiglia più comune: la memoria.

Perché un motore di inferenza “dedicato” a WebGPU

Molti stack di inferenza nascono con obiettivi generalisti: supportare tanti operatori, tanti backend, tante combinazioni. Questa flessibilità ha un costo.

Un motore di inferenza progettato specificamente per WebGPU può invece:

• Conoscere i pattern ricorrenti dei modelli (es. catene di operatori, blocchi ripetuti).
• Decidere in modo più aggressivo come mappare il grafo sul backend GPU.
• Massimizzare l’efficienza dei kernel senza dover restare compatibile con compromessi multi-backend.

In pratica: meno “strati” e meno astrazioni che impediscono di fare ottimizzazioni importanti.

Il punto chiave: scrivere kernel WebGPU ad hoc

Le prestazioni su GPU spesso non si vincono con l’algoritmo “giusto”, ma con l’implementazione “giusta”. Scrivere kernel personalizzati significa poter intervenire su dettagli che incidono enormemente:

• layout dei dati
• dimensioni dei workgroup
• access patterns (coalescing, locality)
• uso di memoria condivisa (quando applicabile)

Quando un kernel è pensato per una specifica porzione di grafo (e non per essere universalmente riutilizzabile), può essere costruito intorno ai vincoli reali di quel caso d’uso.

Ottimizzare il grafo a basso livello: fusion e riduzione degli accessi in memoria

Nel browser, come altrove, la GPU non è “lenta”: spesso è la memoria a diventare il freno. Molte pipeline di inferenza pagano costi pesanti perché ogni operazione:

1. legge tensori dalla memoria
2. calcola
3. riscrive il risultato in memoria

Ripetuto decine/centinaia di volte, questo schema diventa dominante.

Fusion delle operazioni

Una leva potentissima è la fusione (fusion) di più operazioni in una sola. Se invece di eseguire operatori separati in sequenza (con intermediate buffers) riusciamo a fonderli, otteniamo:

• meno letture/scritture di tensori intermedi
• meno passaggi (dispatch) verso la GPU
• spesso migliore cache locality

Il guadagno non è solo teorico: riducendo i roundtrip verso la memoria, si sbloccano accelerazioni “a due cifre” su parti importanti della pipeline.

Meno memory reads: la metrica che conta davvero

Quando si parla di 5x o 10x, quasi sempre sotto c’è una storia di bandwidth risparmiata:

• eliminazione di buffer intermedi
• riordino degli operatori per ridurre materializzazioni inutili
• kernel che producono direttamente la forma/il layout richiesto dallo step successivo

In altre parole: si sposta il focus da “quante operazioni faccio” a “quante volte tocco la memoria”.

Sistemi agentici e ottimizzazione automatizzata (ma guidata)

Un approccio interessante è usare un sistema in grado di analizzare il grafo e proporre ottimizzazioni a livello molto basso: identificare sotto-grafi candidati alla fusion, suggerire kernel specializzati, e selezionare strategie di scheduling.

Il punto non è “premere un bottone e sperare”, ma fornire al sistema abbastanza informazioni per:

• capire la struttura del grafo e i colli di bottiglia
• applicare trasformazioni sicure (semantica invariata)
• scegliere ottimizzazioni in base al backend reale (WebGPU) e ai suoi vincoli

Implicazioni pratiche per chi fa frontend

Se stai valutando AI nel browser, la lezione è chiara: per ottenere performance davvero competitive non basta “eseguire il modello su WebGPU”. Serve una mentalità da performance engineering:

• considera l’inferenza come un grafo ottimizzabile, non come una lista di layer
• investi nel ridurre gli intermedi (fusion, operatori combinati)
• misura e ottimizza in termini di accessi in memoria e dispatch, non solo di FLOPs
• quando possibile, usa o costruisci una pipeline con kernel specializzati, non soltanto operatori generici

Sintesi e conclusione

WebGPU abilita l’inferenza AI nel browser con prestazioni sorprendenti, ma i salti più grandi arrivano quando si scende sotto la superficie: motore di inferenza dedicato, kernel WebGPU su misura e fusion delle operazioni per ridurre drasticamente letture e scritture in memoria. Se l’obiettivo è passare da demo a produzione, la strada è trasformare il grafo in qualcosa di “GPU-friendly” e tagliare senza pietà tutto ciò che genera traffico inutile in memoria: è lì che si guadagnano davvero quei 5x–10x.