🤖 machine learning

Measuring and Reducing WebGPU Dispatch Overhead for LLM Inference

Cet article révèle que le surcoût de dispatch de WebGPU, plutôt que la qualité du noyau, est le principal goulot d'étranglement pour l'inférence de LLM en lot unique dans les navigateurs, démontrant que des mesures simples surestiment les coûts en raison de la confusion de synchronisation et concluant que la réduction du nombre de dispatch par amortissement est la stratégie d'optimisation la plus efficace.

Auteurs originaux : Jędrzej Maczan

Publié 2026-08-11

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jędrzej Maczan

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayiez de faire tourner un jeu vidéo massif et complexe sur un ordinateur, mais que vous devez le faire via un gestionnaire très strict et soucieux de la sécurité qui ne vous laisse pas toucher directement au matériel. C'est le monde de l'exécution de l'Intelligence Artificielle (plus précisément des modèles de langage étendus, ou LLM) à l'intérieur d'un navigateur web. Ces modèles sont les cerveaux derrière les chatbots capables d'écrire des histoires, de résoudre des problèmes mathématiques et de tenir des conversations. Pour qu'ils fonctionnent rapidement sur votre ordinateur portable ou votre téléphone sans nécessiter un supercalculateur, les développeurs utilisent un outil spécial appelé WebGPU. Voyez WebGPU comme un traducteur universel qui permet à votre navigateur de parler à la carte graphique de votre ordinateur (la partie qui sert habituellement à générer des jeux vidéo) afin qu'elle puisse effectuer les calculs mathématiques lourds pour l'IA.

Cependant, il y a un piège. Par le passé, lorsque les développeurs essayaient de rendre ces modèles d'IA plus rapides, ils se concentraient sur l'optimisation des étapes mathématiques individuelles (appelées "kernels"), comme si l'on polissait le moteur d'une voiture. Mais cet article pose une question différente : et si la voiture allait bien, mais que le conducteur passait trop de temps à monter et descendre du véhicule ? Dans le monde du web, chaque étape mathématique nécessite un "dispatch" — une requête envoyée du navigateur vers la carte graphique pour commencer le travail. Le grand mystère était le suivant : quelle quantité de temps est réellement gaspillée simplement à envoyer ces requêtes, par rapport au temps passé à effectuer les calculs réels ? Comprendre cela est crucial car si nous perdons trop de temps simplement à demander à l'ordinateur de travailler, le chatbot paraîtra lent et poussif, peu importe la puissance de ses calculs mathématiques.

L'embouteillage du "Stop-and-Go"

Le chercheur de cet article a découvert que tout le monde mesurait la vitesse de ces requêtes d'IA de la mauvaise manière. Imaginez que vous chronométrez le temps nécessaire à un livreur pour déposer un colis. Si vous le chronométrez depuis le moment où il quitte l'entrepôt, conduit jusqu'à la maison, dépose le colis, puis revient à l'entrepôt pour chercher le suivant, vous mesurez l'aller-retour complet. Mais dans le monde réel de l'IA, le livreur ne revient pas à l'entrepôt après chaque colis. Il dépose toute une pile de colis en une seule fois, et ne revient qu'à la toute fin.

L'article montre que les mesures précédentes étaient comme si l'on chronométrait cet aller-retour complet pour chaque colis. On confondait le temps nécessaire pour envoyer la requête (le dispatch) avec le temps passé à attendre que l'ordinateur dise "D'accord, j'ai fini" (la synchronisation). Ce "temps d'attente" est énorme — c'est une pause de 450 microsecondes. Lorsque les chercheurs ajoutaient ce temps d'attente à chaque étape, ils pensaient que le coût de l'envoi d'une requête était environ 20 fois plus élevé qu'il ne l'était réellement.

En utilisant une nouvelle méthode appelée "dispatch séquentiel", l'auteur a réussi à mesurer uniquement l'acte d'envoyer la requête, sans le long délai d'attente entre les deux. Il a découvert que le coût réel est bien plus bas : entre 24 et 36 microsecondes sur certains systèmes (Vulkan) et entre 32 et 71 microsecondes sur d'autres (Metal). Curieusement, ce coût est le même que l'ordinateur utilise des nombres "float32" ou "float16" (deux façons différentes de stocker des nombres décimaux), prouvant que le délai provient des règles du navigateur, et non des mathématiques elles-mêmes.

Le véritable goulot d'étranglement : Trop d'arrêts

Une fois le coût réel d'une requête connu, l'équipe s'est demandé : "Est-ce que cela compte vraiment ?" Pour le savoir, ils ont mené une expérience contrôlée. Ils ont pris un modèle d'IA standard et ont modifié la façon dont il était emballé. Au lieu d'envoyer 876 petites requêtes à la carte graphique pour traiter un mot de texte, ils ont "fusionné" (collé ensemble) certaines étapes pour que la carte n'ait à recevoir que 564 requêtes.

Voici le point crucial : ils n'ont pas rendu les calculs à l'intérieur des requêtes plus rapides. Ils n'ont pas modifié le code pour le rendre plus intelligent ou utiliser moins de mémoire. Ils ont simplement réduit le nombre de fois où le navigateur devait frapper à la porte de la carte graphique.

Le résultat ? L'IA est devenue 53 % plus rapide. Le temps nécessaire pour générer le premier mot d'une réponse est passé de 71,4 ms à 41,6 ms.

Cette expérience a prouvé qu'au réglage le plus courant (le traitement d'un mot à la fois, appelé "taille de lot 1" ou "batch size 1"), le problème majeur n'est pas que les mathématiques sont trop lentes ou que la mémoire est saturée. Le problème est simplement qu'il y a trop de "frappes à la porte". L'auteur a explicitement écarté l'idée que l'amélioration du code mathématique ou la réduction de l'usage de la mémoire soit la raison de ce gain de vitesse. La seule chose qui a changé, c'est le nombre de dispatches.

Ce que cela signifie pour l'avenir

L'article conclut que si nous voulons que les navigateurs fassent fonctionner les chatbots d'IA de manière fluide, nous devons arrêter d'essayer de perfectionner chaque étape mathématique et commencer à les regrouper. C'est comme réaliser que pour qu'un camion de livraison arrive plus vite à une maison, il ne faut pas seulement faire courir le chauffeur plus vite ; il faut plutôt s'assurer qu'il transporte des boîtes plus grandes pour éviter de faire autant de trajets.

L'auteur suggère que la solution réside dans l' "amortissement du dispatch" — une façon sophistiquée de dire que nous devons répartir le coût de ces "frappes" sur de nombreuses tâches afin que le délai ne soit pas pénalisant. Il souligne que cela pourrait nécessiter des changements non seulement dans les logiciels qui font fonctionner l'IA, mais potentiellement dans les règles mêmes de WebGPU, en permettant peut-être au navigateur d'accepter un "graphe de commandes" (un itinéraire pré-planifié) plutôt que de vérifier chaque étape individuellement.

Bien que ces conclusions soient basées sur un matériel spécifique (comme la NVIDIA RTX 5090) et une méthode spécifique d'exécution de l'IA, le message est clair : pour l'instant, le secret pour avoir une IA plus rapide dans votre navigateur n'est pas un moteur plus rapide ; c'est faire moins d'arrêts.

Résumé technique : Mesurer et réduire le surcoût de dispatch WebGPU pour l'inférence LLM

Énoncé du problème

Les grands modèles de langage (LLM) sont de plus en plus déployés dans des environnements de navigateur et de bordure (edge) en utilisant WebGPU comme standard multiplateforme. Alors que l'ingénierie de performance existante pour ces systèmes se concentre sur la quantification, l'optimisation des noyaux (kernels) et l'efficacité de la mémoire, le coût du dispatch des opérations WebGPU reste mal caractérisé.

Un problème critique identifié est que les mesures de performance standard de type « opération unique » — qui chronomètrent une seule opération de bout en bout — confondent le coût du dispatch lui-même avec le coût de la synchronisation complet GPU-CPU. Dans le décodage autorégressif réel, la synchronisation ne se produit qu'une fois par jeton (token), et non une fois par opération. Par conséquent, les mesures d'opération unique surestiment le coût par dispatch d'environ 20 fois, occultant le véritable goulot d'étranglement des performances. De plus, il reste à déterminer si les limitations de débit à une taille de lot (batch size) de 1 sont causées par la qualité du noyau (efficacité du shader) ou par le nombre pur de dispatches requis.

Méthodologie

L'auteur introduit une méthode de mesure par dispatch séquentiel pour isoler le coût marginal réel d'un seul dispatch.

Mesure séquentielle : Au lieu de chronométrer une seule opération avec une synchronisation immédiate, la méthode soumet $N$ opérations identiques à la file d'attente (queue) et effectue une synchronisation unique à la toute fin. Le temps total est divisé par $N$ , amortissant le coût de synchronisation unique et révélant le véritable surcoût de dispatch.
Expérience de fusion contrôlée : Pour déterminer l'impact du nombre de dispatches par rapport à la qualité du noyau, l'auteur a mené une expérience de fusion de noyaux. Ils ont fusionné des groupes d'opérations pour réduire le nombre de dispatches par passage direct (forward pass) de 876 à 564. Crucialement, les shaders WGSL sous-jacents (logique de calcul) sont restés inchangés, et la réduction du trafic mémoire intermédiaire était négligeable (<1,8 Mo, <1 µs). Cette configuration isole le nombre de dispatches comme la seule variable.
Implémentation : Les mesures ont été effectuées à l'aide de torch-webgpu, un backend PyTorch personnalisé, à travers plusieurs vendeurs de matériel (NVIDIA, AMD, Apple, Intel) et backends (Vulkan, Metal, Dawn, wgpu).

Résultats clés

1. Coût réel par dispatch

En utilisant la méthode séquentielle, l'auteur a mesuré le coût réel par dispatch, constatant qu'il est indépendant du type de données (float32 vs float16) :

Vulkan : 24–36 µs par dispatch.
Metal : 32–71 µs par dispatch.
Surestimation : Les mesures d'opération unique surestiment ces coûts d'environ 20x (par exemple, en mesurant ~497 µs sur Dawn, où ~450 µs sont attribués à la synchronisation).

2. Le nombre de dispatches comme goulot d'étranglement

L'expérience de fusion contrôlée a démontré que la réduction du nombre de dispatches améliore considérablement le débit sans modifier la qualité du noyau :

La réduction des dispatches de 876 à 564 a entraîné une augmentation de 53 % du débit (jetons par seconde).
Le temps jusqu'au premier jeton (TTFT) est passé de 71,4 ms à 41,6 ms.
Puisque le calcul et le trafic mémoire ont été maintenus constants, l'auteur conclut que le nombre de dispatches, et non la qualité du noyau, est le principal goulot d'étranglement pour l'inférence LLM à une taille de lot de 1.

3. Répartition du surcoût (overhead)

L'analyse des composants du surcoût de dispatch a révélé que la soumission du tampon de commande (command buffer submission) est le facteur dominant :

Submit : ~12,9 µs (40 % du temps CPU total).
Encoder Create/Finish : ~12,5 µs combinés (39 %).
Configuration Pipeline/Bind Group : <1,5 µs chacun.
Cela indique que le principal goulot d'étranglement réside dans l'overhead de l'API lors de la soumission des commandes, plutôt que dans la configuration des pipelines ou la liaison des ressources.

Signification et affirmations

Le document affirme combler une lacune dans l'ingénierie de performance WebGPU en caractérisant le surcoût de dispatch, un facteur laissé comme « travail futur » dans des études de pointe comme LlamaWeb.

Stratégie d'optimisation : Pour l'inférence à taille de lot 1 dans WebGPU, la stratégie d'optimisation efficace est la réduction du nombre de dispatches (via la fusion ou l'amortissement) plutôt que l'optimisation des noyaux individuels.
Implications pour la spécification : L'auteur suggère que des gains de performance plus profonds pourraient nécessiter des modifications de la spécification WebGPU elle-même. Il propose des mécanismes d'amortissement de dispatch analogues aux CUDA Graphs (capture et rejeu de graphes de commandes) pour éviter de revalider et de resoumettre chaque opération, bien qu'il reconnaisse que cela doit être mis en balance avec les modèles de sécurité des navigateurs qui imposent une validation par opération.
Limites de portée : L'auteur note modestement que ses résultats de fusion causale sont spécifiques à la plateforme testée (RTX 5090, Dawn, Vulkan) et à la taille de lot 1. Il ne prétend pas que ces résultats sont universels pour toutes les tailles de lots, notant que le calcul du noyau commence à dominer à des tailles de lots plus importantes.

En conclusion, ce travail établit que les benchmarks d'opération unique sont trompeurs en raison de la confusion de synchronisation et identifie la réduction du nombre de dispatches comme la voie critique vers une inférence LLM haute performance et pratique dans le navigateur.