🤖 machine learning

Measuring and Reducing WebGPU Dispatch Overhead for LLM Inference

Questo articolo rivela che l'overhead di dispatch di WebGPU, piuttosto che la qualità del kernel, è il collo di bottiglia primario per l'inferenza di LLM a batch singolo nei browser, dimostrando che misurazioni semplici sovrastimano i costi a causa della conflazione della sincronizzazione e concludendo che la riduzione del numero di dispatch attraverso l'ammortamento è la strategia di ottimizzazione più efficace.

Autori originali: Jędrzej Maczan

Pubblicato 2026-08-11

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Jędrzej Maczan

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di dover eseguire un videogioco massiccio e complesso su un computer, ma di doverlo fare attraverso un manager molto severo e attento alla sicurezza che non ti permette di toccare direttamente l'hardware. Questo è il mondo dell'esecuzione di un'Intelligenza Artificiale (specificamente di Large Language Models, o LLM) all'interno di un browser web. Questi modelli sono i cervelli dietro le chatbot in grado di scrivere storie, risolvere problemi matematici e sostenere conversazioni. Per farli girare velocemente sul tuo laptop o sul tuo telefono senza bisogno di un supercomputer, gli sviluppatori usano uno strumento speciale chiamato WebGPU. Pensa a WebGPU come a un traduttore universale che permette al tuo browser di parlare con la scheda grafica del tuo computer (la parte che di solito renderizza i videogiochi) in modo che possa eseguire i calcoli pesanti necessari per l'IA.

Tuttavia, c'è un problema. In passato, quando i developer cercavano di rendere queste IA più veloci, si concentravano sul rendere più efficienti i singoli passaggi matematici (chiamati "kernel"), come se stessero lucidando il motore di un'auto. Ma questo articolo pone una domanda diversa: e se l'auto fosse perfetta, ma il conducente passasse troppo tempo a salire e scendere dal veicolo? Nel mondo del browser, ogni singolo passaggio matematico richiede un "dispatch" — una richiesta inviata dal browser alla scheda grafica per iniziare a lavorare. Il grande mistero era: quanto tempo viene effettivamente sprecato solo per inviare queste richieste, rispetto al tempo impiegato per fare l'effettiva matematica? Capire questo è fondamentale perché, se sprechiamo troppo tempo solo nel chiedere al computer di lavorare, la chatbot sembrerà lenta e pigra, indipendentemente da quanto sia intelligente la matematica.

L'ingorgo del "Stop-and-Go"

Il ricercatore in questo articolo ha scoperto che tutti avevano misurato la velocità di queste richieste IA nel modo sbagliato. Immagina di cronometrare quanto tempo impiega un corriere a consegnare un pacco. Se cronometri il tempo che impiega dal momento in cui lascia il magazzino, guida fino alla casa, consegna il pacco e poi torna indietro al magazzino per prendere il successivo, stai misurando l'intero viaggio di andata e ritorno. Ma nel mondo reale dell'IA, il corriere non torna al magazzino dopo ogni singolo pacco. Consegna un intero carico di pacchi in un'unica soluzione e torna indietro solo alla fine.

L'articolo mostra che le misurazioni precedenti erano come cronometrare quel viaggio completo per ogni singolo pacco. Confondevano il tempo necessario per inviare la richiesta (il dispatch) con il tempo necessario per aspettare che il computer dicesse "Ok, ho finito" (sincronizzazione). Questo "tempo di attesa" è enorme — è una pausa di circa 450 microsecondi. Quando i ricercatori hanno aggiunto questo tempo di attesa a ogni singolo passaggio, hanno pensato che il costo dell'invio di una richiesta fosse circa 20 volte superiore a quello reale.

Utilizzando un nuovo metodo chiamato "sequential-dispatch", l'autore è riuscito a misurare solo l'atto di inviare la richiesta, senza la lunga attesa nel mezzo. Ha scoperto che il costo reale è molto più basso: tra i 24 e i 36 microsecondi su alcuni sistemi (Vulkan) e tra i 32 e i 71 microsecondi su altri (Metal). Interessante è che questo costo rimane lo stesso sia che il computer utilizzi numeri "float32" che "float16" (due modi diversi di memorizzare numeri decimali), dimostrando che il ritardo deriva dalle regole del browser, non dalla matematica stessa.

Il vero collo di bottiglia: Troppe fermate

Una volta conosciuto il costo reale di una singola richiesta, il team si è chiesto: "Questo conta davvero?". Per scoprirlo, hanno eseguito un esperimento controllato. Hanno preso un modello di IA standard e hanno cambiato il modo in cui veniva confezionato. Invece di inviare 876 piccole richieste alla scheda grafica per elaborare una parola di testo, hanno "fuso" (incollato insieme) alcuni passaggi in modo che la scheda dovesse ricevere solo 564 richieste.

Ecco il punto cruciale: non hanno reso la matematica all'interno delle richieste più veloce. Non hanno cambiato il codice per renderlo più intelligente o per usare meno memoria. Hanno solo ridotto il numero di volte in cui il browser doveva bussare alla porta della scheda grafica.

Il risultato? L'IA è diventata il 53% più veloce. Il tempo necessario per generare la prima parola di una risposta è sceso da 71,4 ms a 41,6 ms.

Questo esperimento ha dimostato che, nell'impostazione più comune (elaborare una parola alla volta, nota come "batch size 1"), il problema principale non è che la matematica sia troppo lenta o che la memoria sia troppo piena. Il problema è semplicemente che ci sono troppi "toc toc alla porta". L'autore ha escluso esplicitamente l'idea che un codice matematico migliore o un minor uso della memoria fossero la ragione dell'aumento di velocità. L'unica cosa che è cambiata è stato il numero di dispatch.

Cosa significa per il futuro

L'articolo conclude che, se vogliamo che i browser eseguano le chatbot IA in modo fluido, dobbiamo smettere di cercare di perfezionare ogni singolo passaggio matematico e iniziare a concentrarci sul raggrupparli. È come rendersi conto che, per far arrivare un camion delle consegne più velocemente a una casa, non dovresti solo far correre di più il conducente; dovresti semplicemente assicurarti che trasporti scatole più grandi in modo da non dover fare così tanti viaggi.

L'autore suggerisce che la soluzione risiede nella "dispatch amortization" — un modo elaborato per dire che dobbiamo distribuire il costo di quei "toc toc" su molti compiti, in modo che il ritardo non faccia danni. Evidenzia che questo potrebbe richiedere cambiamenti non solo nel software che esegue l'IA, ma potenzialmente anche nelle regole di WebGPU, permettendo forse al browser di accettare un "command graph" (un percorso pre-pianificato) invece di controllare ogni singolo passaggio individualmente.

Sebbene queste scoperte si basino su hardware specifico (come la NVIDIA RTX 5090) e su un modo specifico di eseguire l'IA, il messaggio è chiaro: per ora, il segreto per un'IA più veloce nel tuo browser non è un motore più veloce; è fare meno fermate.

Riepilogo Tecnico: Misurazione e Riduzione dell'Overhead di Dispatch in WebGPU per l'Inferenza LLM

Definizione del Problema

I Large Language Models (LLM) vengono sempre più distribuiti in ambienti browser ed edge utilizzando WebGPU come standard cross-platform. Mentre l'attuale ingegneria delle prestazioni per questi sistemi si concentra su quantizzazione, ottimizzazione dei kernel ed efficienza della memoria, il costo del dispatch delle operazioni WebGPU rimane scarsamente caratterizzato.

Un problema critico identificato è che le misurazioni delle prestazioni "single-operation" standard — che cronometrano una singola operazione end-to-end — confondono il costo del dispatch stesso con il costo della sincronizzazione completa GPU-CPU. Nell'inferenza autoregressiva del mondo reale, la sincronizzazione avviene solo una volta per token, non una volta per operazione. Di conseguenza, le misurazioni su singola operazione sovrastimano il costo per dispatch di circa 20 volte, oscurando il vero collo di bottiglia delle prestazioni. Inoltre, rimane incerto se i limiti di throughput con batch size 1 siano causati dalla qualità del kernel (efficienza dello shader) o dal mero numero di dispatch richiesti.

Metodologia

L'autore introduce un metodo di misurazione del dispatch sequenziale per isolare il vero costo marginale di un singolo dispatch.

Misurazione Sequenziale: Invece di cronometrare una singola operazione con sincronizzazione immediata, il metodo sottomette $N$ operazioni identiche alla coda e esegue una singola sincronizzazione alla fine del processo. Il tempo totale viene diviso per $N$ , ammortizzando il costo della sincronizzazione una tantum e rivelando il vero overhead di dispatch.
Esperimento di Fusione Controllata: Per determinare l'impatto del numero di dispatch rispetto alla qualità del kernel, l'autore ha condotto un esperimento di fusione dei kernel. Ha fuso gruppi di operazioni per ridurre il numero di dispatch per forward pass da 876 a 564. Fondamentalmente, gli shader WGSL sottostanti (logica di calcolo) sono rimasti invariati e la riduzione del traffico di memoria intermedio è stata trascurabile (<1,8 MB, <1 µs). Questa configurazione isola il numero di dispatch come l'unica variabile.
Implementazione: Le misurazioni sono state eseguite utilizzando torch-webgpu, un backend personalizzato di PyTorch, attraverso molteplici vendor di hardware (NVIDIA, AMD, Apple, Intel) e backend (Vulkan, Metal, Dawn, wgpu).

Risultati Chiave

1. Vero Costo per Dispatch

Utilizzando il metodo sequenziale, l'autore ha misurato l'effettivo costo per dispatch, riscontrando che esso è indipendente dal tipo di dato (float32 vs float16):

Vulkan: 24–36 µs per dispatch.
Metal: 32–71 µs per dispatch.
Sovrastima: Le misurazioni su singola operazione sovrastimano questi costi di circa 20x (ad esempio, misurando circa 497 µs su Dawn, dove circa 450 µs sono attribuiti alla sincronizzazione).

2. Il Numero di Dispatch come Collo di Bottiglia

L'esperimento di fusione controllata ha dimostrato che la riduzione del numero di dispatch migliora significativamente il throughput senza alterare la qualità del kernel:

La riduzione dei dispatch da 876 a 564 ha prodotto un incremento del 53% del throughput (token al secondo).
Il Time to First Token (TTFT) è sceso da 71,4 ms a 41,6 ms.
Poiché il calcolo e il traffico di memoria sono stati mantenuti costanti, l'autore conclude che il numero di dispatch, e non la qualità del kernel, è il principale collo di bottiglia per l'inferenza LLM con batch size 1.

3. Scomposizione dell'Overhead

L'analisi dei componenti dell'overhead di dispatch ha rivelato che la sottomissione del command buffer è il fattore dominante:

Submit: ~12,9 µs (40% del tempo totale della CPU).
Encoder Create/Finish: ~12,5 µs combinati (39%).
Setup di Pipeline/Bind Group: <1,5 µs ciascuno.
Ciò indica che il collo di bottiglia primario risiede nell'overhead dell'API per la sottomissione dei comandi, piuttosto che nel setup di pipeline o nel binding delle risorse.

Significato e Rivendicazioni

Il paper sostiene di colmare una lacuna nell'ingegneria delle prestazioni di WebGPU caratterizzando l'overhead di dispatch, un fattore precedentemente lasciato come "lavoro futuro" in studi all'avanguardia come LlamaWeb.

Strategia di Ottimizzazione: Per l'inferenza con batch size 1 in WebGPU, la strategia di ottimizzazione efficace è la riduzione del numero di dispatch (tramite fusione o ammortamento) piuttosto che l'ottimizzazione dei singoli kernel.
Implicazioni per lo Specifica: L'autore suggerisce che guadagni di prestazioni più profondi potrebbero richiedere modifiche alla specifica stessa di WebGPU. Propone meccanismi di ammortamento del dispatch analoghi ai CUDA Graphs (cattura e riproduzione del grafo di comando) per evitare di validare e sottomettere ogni operazione, pur riconoscendo che ciò deve essere ponderato rispetto ai modelli di sicurezza dei browser che impongono la validazione per ogni operazione.
Limiti dell'Ambito: L'autore nota con modestia che i risultati della fusione causale sono specifici per la piattaforma testata (RTX 5090, Dawn, Vulkan) e per il batch size 1. Non afferma che questi risultati siano universali per tutti i batch size, osservando che il calcolo del kernel inizia a dominare a batch size più elevati.

In conclusione, il lavoro stabilisce che i benchmark a singola operazione sono fuorvianti a causa della conflazione della sincronizzazione e identifica la riduzione del numero di dispatch come il percorso critico per un'inferenza basata su browser pratica e ad alte prestazioni.