🤖 machine learning

Measuring and Reducing WebGPU Dispatch Overhead for LLM Inference

Dit artikel onthult dat de WebGPU-dispatch-overhead, in plaats van de kwaliteit van de kernel, de primaire flessenhals is voor single-batch LLM-inferentie in browsers, waarbij wordt aangetoond dat eenvoudige metingen de kosten overschatten door synchronisatie-conflatie en concluderend dat het verminderen van het aantal dispatches door middel van amortisatie de meest effectieve optimalisatiestrategie is.

Oorspronkelijke auteurs: Jędrzej Maczan

Gepubliceerd 2026-08-11

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Jędrzej Maczan

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een enorme, complexe videogame probeert te draaien op een computer, maar je moet dit doen via een zeer strikte, beveiligingsbewuste manager die je niet direct de hardware laat aanraken. Dit is de wereld van het draaien van Kunstmatige Intelligentie (specifiek Large Language Models, of LLM's) in een webbrowser. Deze modellen zijn de hersens achter chatbots die verhalen kunnen schrijven, wiskunde kunnen oplossen en gesprekken kunnen voeren. Om deze modellen snel te laten draaien op je laptop of telefoon zonder dat er een supercomputer nodig is, gebruiken ontwikkelaars een speciale tool genaamd WebGPU. Zie WebGPU als een universele vertaler die ervoor zorgt dat je browser met de grafische kaart van je computer kan praten (het onderdeel dat normaal gesproken videogames rendert), zodat het de zware berekeningen kan uitvoeren.

Maar er is een addertje onder het gras. In het verleden, wanneer ontwikkelaars probeerden deze AI-modellen sneller te maken, richtten ze zich op het efficiënter maken van de individuele wiskundige stappen (genaamd "kernels"), zoals het polijsten van de motor van een auto. Maar dit artikel stelt een andere vraag: wat als de auto prima is, maar de bestuurder te veel tijd besteedt aan het in- en uitstappen van het voertuig? In de browserwereld vereist elke wiskundige stap een "dispatch"—een verzoek dat van de browser naar de grafische kaart wordt gestuurd om te beginnen met werken. Het grote mysterie was: hoeveel tijd gaat er eigenlijk verloren aan het simpelweg versturen van deze verzoeken, versus het daadwerkelijk doen van de wiskunde? Het begrijpen hiervan is cruciaal, want als je te veel tijd verspilt aan het simpelweg vragen aan de computer om te werken, zal de chatbot traag en loom aanvoelen, ongeacht hoe slim de wiskunde ook is.

De "Stop-en-Go" File

De onderzoeker in dit artikel ontdekte dat iedereen de snelheid van deze AI-verzoeken verkeerd heeft gemeten. Stel je voor dat je de tijd meet die een bezorger nodig heeft om een pakketje af te leveren. Als je de tijd meet vanaf het moment dat ze het magazijn verlaten, naar het huis rijden, het pakketje afleveren en dan helemaal terugrijden naar het magazijn om het volgende pakketje te halen, dan meet je de hele ronde. Maar in de echte wereld van AI rijdt de chauffeur niet na elk pakketje terug naar het magazijn. Ze leveren in één keer een hele stapel pakketten af en rijden pas aan het einde weer terug.

Het artikel laat zien dat eerdere metingen als het timen van die volledige ronde voor elk afzonderlijk pakketje waren. Ze haalden de tijd die nodig is om het verzoek te verzenden (de dispatch) door de tijd die nodig is om te wachten tot de computer zegt "Oké, ik ben klaar" (synchronisatie) door elkaar. Deze "wachttijd" is enorm—het is een pauze van maar liefst 450 microseconden. Wanneer onderzoekers deze wacertijd bij elke stap optelden, dachten ze dat de kosten van het verzenden van een verzoek ongeveer 20 keer hoger waren dan ze in werkelijkheid zijn.

Door een nieuwe methode genaamd "sequential-dispatch" te gebruiken, heeft de auteur ontdekt hoe je alleen het proces van het verzenden van het verzoek kunt timen, zonder de lange wachttijd tussendoor. Ze ontdekten dat de werkelijke kosten veel lager zijn: tussen de 24–36 microseconden op sommige systemen (Vulkan) en 32–71 microseconden op andere (Metal). Interessant genoeg zijn deze kosten hetzelfde of de computer nu "float32" of "float16" getallen gebruikt (twee verschillende manieren om decimale getallen op te slaan), wat bewijst dat de vertraging voortkomt uit de regels van de browser, en niet uit de wiskunde zelf.

De Echte Bottleneck: Te Veel Stops

Toen ze de werkelijke kosten van een enkel verzoek kenden, vroeg het team zich af: "Maakt dit eigenlijk uit?" Om dit te testen, voerden ze een gecontroleerd experiment uit. Ze namen een standaard AI-model en veranderen de manier waarop het werd verpakt. In plaats van 876 kleine verzoeken naar de grafische kaart te sturen om één woord tekst te verwerken, hebben ze enkele stappen "gefuseerd" (aan elkaar gelijmd), zodat de kaart slechts 564 verzoeken hoeft te ontvangen.

Hier is de kern: ze hebben de wiskunde binnen de verzoeken niet sneller gemaakt. Ze hebben de code niet slimmer gemaakt of het geheugengebruik niet verminderd. Ze hebben simpelweg het aantal keren verminderd dat de browser aan de deur van de grafische kaart hoefde te kloppen.

Het resultaat? De AI werd 53% sneller. De tijd die nodig was om het eerste woord van een reactie te genereren, daalde van 71,4 ms naar 41,6 ms.

Dit experiment bewees dat bij de meest voorkomende instelling (het verwerken van één woord per keer, bekend als "batch size 1"), het grootste probleem niet is dat de wiskunde te traag is of dat het geheugen te vol zit. Het probleem is simpelweg dat er te veel "kloppen aan de deur" is. De auteur sloot expliciet de mogelijkheid uit dat betere wiskundige code of minder geheugengebruik de reden was voor de versnelling. Het enige dat veranderde, was het aantal dispatches.

Wat Dit Betekent voor de Toekomst

Het artikel concludeert dat als we willen dat browsers AI-chatbots soepel laten draaien, we moeten stoppen met het proberen te perfectioneren van elke individuele wiskundige stap en ons moeten gaan richten op het groeperen van deze stappen. Het is alsoast beseffen dat om een bezorgwagen sneller bij een huis te krijgen, je niet alleen de chauffeur sneller moet laten rennen; je moet er ook voor zorgen dat hij een grotere doos meeneemt, zodat hij niet zo vaak op pad hoeft.

De auteur suggereert dat de oplossing ligt in "dispatch amortisatie"—een chique manier om te zeggen dat we de kosten van die "kloppen" moeten spreiden over veel taken, zodat de vertraging niet zo hard toeslaat. Ze wijzen erop dat dit mogelijk niet alleen veranderingen vereist in de software die de AI draait, maar potentieel ook in de WebGPU-regels zelf, bijvoorbeeld door de browser toe te staan een "command graph" (een vooraf geplande route) te accepteren, in plaats van elke stap individueel te controleren.

Hoewel deze bevindingen gebaseerd zijn op specifieke hardware (zoals de NVIDIA RTX 5090) en één specifieke manier van AI draaien, is de boodschap duidelijk: voor nu is het geheim voor snellere AI in je browser niet een snellere motor; het is minder stops.

Technische Samenvatting: Het Meten en Verminderen van WebGPU Dispatch-overhead voor LLM-inferentie

Probleemstelling

Grote taalmodellen (LLM's) worden steeds vaker ingezet in browser- en edge-omgevingen met behulp van WebGPU als cross-platform standaard. Terwijl bestaande performance engineering voor deze systemen zich richt op kwantisatie, kernel-optimalisatie en geheugenefficiëntie, blijft de kosten van WebGPU-operatie-dispatch slecht gekarakteriseerd.

Een kritiek probleem dat is geïdentificeerd, is dat standaard "single-operation" prestatiemetingen—waarbij een enkele operatie end-to-end wordt getimed—de kosten van de dispatch zelf verwarren met de kosten van volledige GPU-CPU-synchronisatie. In real-world autoregressieve decodering vindt synchronisatie slechts één keer per token plaats, niet één keer per operatie. Daarom overschatten "single-operation" metingen de per-dispatch kosten met ongeveer 20x, waardoor de werkelijke bottleneck in de performance verborgen blijft. Bovendien blijft het onduidelijk of doorvoerbeperkingen bij batchgrootte 1 worden veroorzaakt door de kwaliteit van de kernels (shader-efficiëntie) of door het loutere aantal vereiste dispatches.

Methodologie

De auteur introduceert een sequentiële-dispatch-meetmethode om de werkelijke marginale kosten van een enkele dispatch te isoleren.

Sequentiële Meting: In plaats van een enkele operatie te timen met onmiddellijke synchronisatie, dient de methode $N$ identieke operaties in bij de queue en voert één enkele synchronisatie uit aan het einde. De totale tijd wordt gedeeld door $N$ , waardoor de eenmalige synchronisatiekosten worden geamortiseerd en de werkelijke dispatch-overhead wordt onthuld.
Gecontroleerd Fusie-experiment: Om de impact van het aantal dispatches versus de kwaliteit van de kernel te bepalen, heeft de auteur een kernel-fusie-experiment uitgevoerd. Ze hebben groepen operaties gefuseerd om het aantal dispatches per forward pass te verminderen van 876 naar 564. Cruciaal is dat de onderliggende WGSL-shaders (computatielogica) ongewijzigd bleven, en de reductie in intermediair geheugentrafiek verwaarloosbaar was (<1,8 MB, <1 µs). Deze opzet isoleert het aantal dispatches als de enige variabele.
Implementatie: Metingen werden uitgevoerd met torch-webgpu, een aangepaste PyTorch-backend, over meerdere hardwareleveranciers (NVIDIA, AMD, Apple, Intel) en backends (Vulkan, Metal, Dawn, wgpu).

Belangrijkste Resultaten

1. Werkelijke Per-Dispatch Kosten

Met behulp van de sequentiële methode heeft de auteur de werkelijke per-dispatch kosten gemeten, waarbij werd vastgesteld dat deze onafhankelijk zijn van het datatype (float32 versus float16):

Vulkan: 24–36 µs per dispatch.
Metal: 32–71 µs per dispatch.
Overschatting: "Single-operation" metingen overschatten deze kosten met ~20x (bijvoorbeeld het meten van ~497 µs op Dawn, waarbij ~450 µs aan synchronisatie wordt toegeschreven).

2. Dispatch Count als de Bottleneck

Het gecontroleerde fusie-experiment toonde aan dat het verminderen van het aantal dispatches de doorvoer aanzienlijk verbetert zonder de kernelkwaliteit te wijzigen:

Het verminderen van de dispatches van 876 naar 564 resulteerde in een toename van de doorvoer met 53% (tokens per seconde).
De Time to First Token (TTFT) daalde van 71,4 ms naar 41,6 ms.
Omdat de computatie en het geheugentrafiek constant werden gehouden, concludeert de auteur dat het aantal dispatches, en niet de kernelkwaliteit, de primaire bottleneck is voor LLM-inferentie bij batchgrootte 1.

3. Overhead Breakdown

Analyse van de componenten van de dispatch-overhead onthulde dat command buffer submission de dominante factor is:

Submit: ~12,9 µs (40% van de totale CPU-tijd).
Encoder Create/Finish: ~12,5 µs gecombineerd (39%).
Pipeline/Bind Group Setup: <1,5 µs elk.
Dit geeft aan dat de primaire bottleneck ligt in de API-overhead van het indienen van commando's, in plaats van de setup van pipelines of het binden van resources.

Betekenis en Claims

Het artikel beweert een gat te vullen in de WebGPU-performance engineering door de dispatch-overhead te karakteriseren, een factor die in state-of-the-art studies zoals LlamaWeb als "toekomstig werk" werd achtergelaten.

Optimalisatiestrategie: Voor inferentie met batchgrootte 1 in WebGPU is de effectieve optimalisatiestrategie het verminderen van het aantal dispatches (via fusie of amortisatie) in plaats van het optimaliseren van individuele kernels.
Implicaties voor de Specificatie: De auteur suggereert dat diepere prestatiewinsten mogelijk een verandering in de WebGPU-specificatie zelf vereisen. Ze stellen dispatch-amortisatiemechanismen voor, analoog aan CUDA Graphs (command-graph capture en replay), om te voorkomen dat elke operatie opnieuw gevalideerd en ingediend moet worden, hoewel ze erkennen dat dit moet worden afgewogen tegen de browser-securitymodellen die validatie per operatie voorschrijven.
Scope Beperkingen: De auteur merkt bescheiden op dat hun causale fusieresultaten specifiek zijn voor het geteste platform (RTX 5090, Dawn, Vulken) en batchgrootte 1. Ze beweren niet dat deze resultaten universeel zijn voor alle batchgroottes, waarbij zij opmerken dat de kernel-compute begint te domineren bij grotere batchgroottes.

Concluderend stelt dit werk vast dat single-operation benchmarks misleidend zijn vanwege de verwarring met synchronisatie, en identificeert het verminderen van het aantal dispatches als het kritieke pad naar praktische, hoogwaardige browser-gebaseerde LLM-inferentie.