WebGPU : l'IA dans le navigateur, sur votre GPU
Comment un site web peut faire tourner un modèle linguistique sur l'appareil de son visiteur, sans installation et sans appel au nuage pour chaque mot généré. Vous ouvrez une page, une barre de progression met quelques minutes à se remplir, puis une zone de texte apparaît. Vous écrivez et le modèle répond. Aucun programme à installer, aucune clé à coller, aucun serveur distant qui produit des mots : le travail est exécuté par la carte graphique de l'ordinateur placé devant vous, guidée par une page web. Lors de la visite suivante, la barre de chargement est à peine visible, car les poids du modèle sont restés enregistrés sur le disque, dans un espace réservé par le navigateur pour ce site.
Le protagoniste de cette scène s'appelle WebGPU, et il convient de dire d'emblée ce qu'il n'est pas. Ce n'est pas un modèle, ce n'est pas un format de fichier, ce n'est pas un programme à installer. C'est une interface que le navigateur offre aux pages web pour communiquer avec la carte graphique, tant pour le rendu graphique que pour le calcul parallèle généraliste, définie par la spécification du W3C. Télécharger les poids, les conserver, traduire le texte en nombres et inversement relève d'autres maillons de la chaîne. Cet article les passe tous en revue, avec les chiffres disponibles aujourd'hui et un regard honnête sur les limites.
La GPU entre dans le navigateur
Pour comprendre pourquoi la carte graphique est indispensable à l'intelligence artificielle, l'image de la cuisine est éclairante. Le processeur est un chef expérimenté qui prépare un plat à la fois avec des gestes parfaits. La GPU est une cuisine comptant des milliers de commis, chacun capable d'une seule opération simple, mais tous au travail exactement au même instant. Un modèle linguistique passe son temps à multiplier des tableaux de nombres, une tâche qui se divise en millions de calculs indépendants : c'est le service idéal pour la brigade de cuisine, pas pour le chef.
Pendant des années, le navigateur ne savait pourtant parler à la GPU que pour dessiner des graphismes. Avec WebGL, quiconque voulait l'utiliser pour d'autres calculs devait déguiser les nombres en pixels et les opérations en effets graphiques. WebGPU change la donne, car il ajoute aux graphismes les compute shaders, de petits programmes écrits dans un langage nommé WGSL que la GPU exécute pour n'importe quel calcul, et pas seulement pour colorer des triangles.
Entre la page web et le silicium s'étend un réseau de conduits qui n'est pas sans rappeler celui de Brazil, le film de Terry Gilliam où chaque requête traverse bureaux et tuyauteries avant de produire un effet. Le site parle WebGPU, et le navigateur le traduit en Metal sur Apple, en Vulkan sur Linux et Android, ou en DirectX sur Windows ; ce rôle est assuré par différents moteurs : Dawn dans les navigateurs fondés sur Chromium, wgpu dans Firefox, et une implémentation propre à WebKit dans Safari, comme le décrit le preprint analysé plus loin.
Le résultat qui rend ce sujet pertinent aujourd'hui est la couverture des navigateurs. Comme le rappelle web.dev, Chrome et Edge prennent en charge WebGPU depuis la version 113 sur Windows, macOS et ChromeOS, tandis que sur Android il faut Chrome 121 et au moins Android 12. Firefox le propose sur Windows depuis la version 141 et sur les Mac dotés de puces ARM depuis la 145 ; Safari l'a introduit avec la version 26 sur tous les systèmes Apple. Les notes de Khronos situent Firefox sur Windows en juillet 2025 et Safari en septembre 2025, ajoutant que Chromium a étendu la prise en charge sur Linux aux GPU Intel de 12e génération et supérieures en janvier 2026. Firefox sur Linux et Android reste en retard, encore en chantier selon web.dev. Les développeurs doivent donc prévoir une solution de repli pour les utilisateurs hors de ces listes.
Du téléchargement aux tokens
Le parcours de l'IA dans le navigateur suit une séquence précise. La page vérifie que WebGPU est présent et que la GPU convient, puis télécharge le modèle depuis un serveur ou un réseau de distribution de contenu (CDN), le conserve dans l'espace du navigateur et le charge en mémoire vidéo. Lorsque l'utilisateur écrit, le texte est découpé en tokens (fragments de mots), les calculs s'exécutent sur la GPU via WebGPU et les tokens générés sont réassemblés en phrases. Un détail souvent omis : WebGPU ne télécharge rien et n'enregistre rien, il réalise uniquement le calcul. Le reste est pris en charge par les interfaces réseau et de stockage habituelles du navigateur.
Des bibliothèques JavaScript assemblent les pièces. WebLLM, né du projet MLC, offre une interface similaire à celle des API d'OpenAI et utilise WebGPU pour la carte graphique et WebAssembly pour les tâches sur le processeur. Transformers.js s'appuie sur ONNX Runtime, et wllama porte dans le navigateur les modèles de llama.cpp, conçu pour s'exécuter sur processeur et doté aujourd'hui d'un backend WebGPU. Le billet de web.dev déjà cité confirme qu'ONNX Runtime et Transformers.js exploitent WebGPU pour l'inférence locale.
Au cœur du calcul, deux phases se distinguent, et la différence compte. Lors du prefill, le modèle lit l'intégralité du prompt d'un seul coup, et les multiplications de matrices prédominent. Lors du decode, il produit un token à la fois, et le travail devient une multiplication de matrices par des vecteurs. Les mesures du preprint sur un Apple M3, avec un modèle d'un milliard de paramètres compressé en 4 bits, montrent que les premières occupent 92,6 % du temps de prefill et les secondes 89,9 % du decode. Le decode est en outre principalement limité par la vitesse de lecture des poids en mémoire, ce qui explique pourquoi comprimer les poids permet de gagner du temps : on déplace moins de octets.
C'est là que réside la différence entre accès et performance. WebGPU, note le preprint, offre une portabilité fonctionnelle mais pas une portabilité des performances : le même code s'exécute partout, mais pas à la même vitesse partout. Il faut des poids compressés, des calculs rédigés sur mesure pour chaque famille de GPU et une gestion attentive de la mémoire. Lors du premier lancement, un coût unique apparaît : la compilation des programmes pour la GPU, que les auteurs estiment entre une et cinq secondes.
Où finissent les poids ?
Après le téléchargement, les poids ne disparaissent pas. La notice de Chrome sur la conservation des modèles rappelle leur taille : un fichier de 1,35 gigaoctet, comme une version compressée de Gemma 2B, est considéré comme très petit pour un modèle linguistique. Pour les conserver sur l'appareil, trois voies existent : la Cache API, l'Origin Private File System et IndexedDB. L'équipe de Chrome recommande généralement la première et juge IndexedDB comme la moins adaptée aux volumineux fichiers.
Il ne s'agit donc pas d'un fichier à chercher dans un dossier ordinaire. L'Origin Private File System est, selon cette même notice, privé pour le site et invisible pour l'utilisateur. Cela ne signifie pas que le contenu utilise un format exotique : wllama, par exemple, conserve dans cet espace des fichiers au format GGUF de llama.cpp, comme le raconte le preprint. Ils n'apparaissent tout simplement pas dans le gestionnaire de fichiers.
Fermer l'onglet libère la mémoire système et la mémoire vidéo, mais les fichiers restent enregistrés. Fermer le navigateur ne change rien, et lors de la visite suivante, le site peut recharger le modèle depuis la copie locale. L'effacement n'intervient que via les paramètres du navigateur ou par le navigateur lui-même si le site n'a pas demandé et obtenu un stockage persistant lorsque l'espace vient à manquer.
Chaque site dispose de son propre espace étanche. La FAQ de webllm.io, un kit de développement indépendant qui s'appuie sur le moteur de MLC et ne doit pas être confondu avec le projet d'origine, précise que les modèles sont isolés par origine, donc inaccessibles aux autres sites et supprimables via les paramètres, avec des téléchargements variant entre 1,5 et 4,5 gigaoctets selon la puissance de l'appareil. Il en découle que le même modèle téléchargé depuis deux sites différents peut occuper de l'espace en double. Le navigateur ressemble au château ambulant de Howl, cette demeure de Miyazaki qui avance en portant de nombreuses portes, chacune donnant sur un lieu différent et possédant sa propre clé.
Qui paie le calcul ?
Nous voici au nœud économique. Si l'inférence se déroule sur l'appareil, le fournisseur distribue le modèle comme un fichier statique et laisse l'électricité, la chaleur et le temps de calcul à la charge du visiteur. C'est un raisonnement et non une mesure directe, mais il se tient : chaque session locale est une session de moins à traiter avec des GPU louées dans le nuage. Les auteurs du preprint rappellent que l'exécution locale peut améliorer la latence et l'efficacité énergétique, en citant des études tierces, ce qui laisse ouverte une question à laquelle personne ne répond ici : le bilan global, entre quelques data centers et des millions d'ordinateurs portables, s'améliore-t-il vraiment ?
Le serveur ne disparaît pas pour autant. Il reste propriétaire de la page, des comptes, des mises à jour et des fichiers du modèle, et ces fichiers pesent lourd : le coût de bande passante pour délivrer plusieurs gigaoctets à chaque nouveau visiteur ne s'évapore pas, il se déplace du calcul vers le transfert. Ce n'est pas un hasard si la documentation de webllm.io décrit une architecture hybride, avec repli sur le nuage lorsque WebGPU fait défaut ou que la carte graphique est insuffisante. Le même texte prévient que l'exécution locale exige des en-têtes d'isolement (COOP et COEP) parce qu'elle utilise la mémoire partagée : une contrainte de configuration sur le serveur qui peut avoir des répercussions sur les ressources externes intégrées dans la page.
Qui gagne et qui perd dans cette évolution ? Ce sont des scénarios, non des certitudes. Gagnent les fournisseurs de services légers qui réduisent leur facture cloud, les utilisateurs équipés d'une bonne carte graphique qui obtiennent des réponses immédiates et la confidentialité de leurs données, et les fabricants de GPU pour qui la mémoire vidéo devient un argument de vente. Perdent les utilisateurs possédant du matériel ancien, condamnés au repli sur le cloud ou à une expérience lente, ainsi que les loueurs de GPU spécialisés dans l'inférence légère.
Limites, chiffres à l'appui
Les données empiriques les plus complètes disponibles aujourd'hui proviennent du preprint Llamas on the Web, publié sur arXiv en mai 2026 par un groupe de l'Université de Californie à Santa Cruz avec un coauteur de Microsoft Research. Il doit être lu avec deux précautions : il n'a pas encore fait l'objet d'une évaluation par les pairs, et ses auteurs sont ceux-là mêmes qui ont écrit le backend WebGPU de llama.cpp, mesurant ainsi leur propre travail. Le volume d'essais est néanmoins considérable : seize appareils de huit fabricants, dix modèles, environ vingt-cinq heures de tests.
Le premier résultat offre un rappel à la réalité pour ceux qui espéraient des miracles. Face aux backends natifs de llama.cpp, WebGPU s'incline nettement sur du matériel dédié : CUDA et Vulkan natifs le dépassent jusqu'à dix fois en prefill et deux fois et demie en decode, grâce aux cores tensor et à des fonctions matricielles spécifiques au constructeur. Sur Apple Silicon, Metal natif l'emporte de plus du double en prefill et de 50 % en decode. Mais le tableau n'est pas unilatéral : toujours selon le preprint, sur Mac WebGPU dépasse Vulkan traduit via MoltenVK jusqu'à 59 % en prefill et 45 % en decode ; et sur une carte AMD, Vulkan natif reste en retrait de 3 fois en prefill par rapport à WebGPU bien qu'il batte HIP natif en decode. Sur GPU Intel, WebGPU dépasse SYCL de 23 % en prefill, mais uniquement avec les contrôles de sécurité désactivés, une condition qui n'existe pas en navigation réelle.
Ces contrôles de sécurité ont un prix. Les compilateurs WebGPU injectent des vérifications pour éviter les accès hors mémoire et les divisions par zéro. En les désactivant lors des essais, on constate un coût moyen de 14 % en prefill sur le modèle compressé et de 23 % sur le modèle en précision complète (jusqu'à 42 % sur une RTX 5080), tandis que sur le decode l'effet varie de 1 à 5 %. C'est le prix du bac à sable (sandbox) : une page web ne doit jamais pouvoir lire la mémoire hors de son périmètre réservé.
Par ailleurs, il y a WebLLM. Son article affirme qu'il peut conserver jusqu'à 80 % des performances natives, tandis que le blog de MLC évoque jusqu'à 85 % par rapport à Metal sur un MacBook Pro M3 Max avec les deux moteurs compilés par le même outil. Ils ne contredisent pas le preprint de Santa Cruz : ils mesurent par rapport à des références différentes et doivent être comparés avec prudence.
Parmi les moteurs du navigateur, la comparaison du preprint est moins favorable aux autres qu'à ses propres auteurs. Leur backend génère du texte plus vite, entre 45 et 69 % de plus en decode sur quatre GPU de constructeurs différents, et utilise de 29 à 33 % de mémoire en moins. Mais en prefill il reste en retrait (de 21 à 51 % plus lent), car les instructions matricielles les plus rapides, dites subgroup matrix, ne sont pas encore intégrées dans les versions stables des navigateurs. Pour WebLLM et Transformers.js, les auteurs signalent en outre des pics de consommation mémoire proches des 10 gigaoctets dans certaines configurations, qu'ils attribuent à de probables fuites de mémoire.
Sur smartphone, le bilan est plus étroit. Sur iPhone, un onglet Safari dispose de moins de 500 mégaoctets de mémoire utile, et les GPU les plus modestes sous iOS et Android n'ont réussi à faire tourner que les quatre plus petits modèles de la batterie de test, avec 4 à 17 tokens par seconde en decode. Sur les GPU mobiles haut de gamme, les petits modèles dépassent les 3 000 tokens par seconde en prefill et les 100 en decode, tandis que le plus grand essayé (un Gemma 4 d'environ 3 gigaoctets) chute à 65 et 30.
Le choix du navigateur pèse également lourd. Sur un Mac équipé d'une puce M3, le même modèle tourne à ~1 token par seconde sur Firefox contre ~52 tokens par seconde sur Chrome ; les auteurs ont exclu Firefox des mesures principales pour cette raison. C'est un point de donnée précis et non une loi universelle, mais il montre que « prend en charge WebGPU » et « offre les performances de Chrome » sont deux réalités distinctes.
Enfin, les limites du langage WGSL jouent un rôle. WGSL ne gère pas encore en natif les formats bf16, int8, int16 ni int4 que les GPU récentes exécutent directement, imposant une émulation. Il en découle un effet contre-intuitif documenté par le preprint : en WebGPU, la compression des poids sert surtout à faire tenir le modèle en mémoire et non à l'accélérer ; passer de 4 à 2 bits sur du matériel de milieu de gamme réduit la vitesse de decode de 17 %.
Confidentialité sous conditions
L'avantage le plus vanté est la confidentialité, bien réelle mais sous conditions. Il convient de séparer trois affirmations que la communication marketing tend à confondre. La première est que le calcul s'effectue en local : WebGPU le garantit pleinement. La seconde est que l'application n'envoie ni prompts, ni réponses, ni télémétrie à des tiers : cela dépend du créateur du site, non de l'API. La documentation de webllm.io, par exemple, garantit l'absence totale de transmission de données en mode strictement local, mais le produit inclut des modes avec repli sur le cloud, rendant la confidentialité dépendante de la configuration. Si les saisis de l'utilisateur sont transmis à un service de recherche, de modération ou de journalisation, les garanties locales s'évanouissent.
La troisième est que le modèle soit protégé contre l'extraction : sur ce point, la réponse est non. La notice de Chrome avertit que les poids stockés dans la Cache API ou dans l'OPFS s'extraient aisément via les outils de développement du navigateur, et que le chiffrement ne résout rien puisque la clé doit inévitablement parvenir au client. Quiconque doit protéger un modèle propriétaire doit le conserver sur son serveur.
Navigateur ou exécution native ?
Où se situe dès lors l'intérêt ? Cela dépend de l'objectif visé, comme le résume le tableau ci-dessous.
Les deux voies se rapprochent progressivement : le backend WebGPU de llama.cpp a rejoint le projet principal grâce à plus de cent contributions de la communauté, apportant au navigateur les modèles GGUF issus des applications natives. Les standards du web évoluent eux aussi : les mises à jour de Khronos signalent des extensions liées aux sous-groupes apparues dans Chrome 144 et 145, distinctes des instructions matricielles attendues ultérieurement. Une autre voie est celle des API d'IA intégrées de Chrome (Prompt, Summarizer, Translator), présentées dans leur documentation officielle : des modèles mis à disposition par le navigateur lui-même pour les sites, plutôt que des sites apportant leurs propres poids. La manière dont ce parcours coexistera avec WebGPU reste une question ouverte.
Votre PC comme serveur
La première conclusion invite à la modestie : pour qui recherche la vitesse maximale, les modèles très volumineux et un contrôle absolu, WebGPU ne remplace pas llama.cpp ou LM Studio. Les chiffres montrent que les moteurs natifs dominent le prefill jusqu'à un facteur 10x, tandis que les smartphones ne gèrent que de très petits modèles. La seconde conclusion est nettement más stimulante : pour la première fois, les principaux navigateurs communiquent directement avec la GPU, rendant crédible un nouveau mode de distribution : une URL, un téléchargement initial du modèle, et un calcul exécuté intégralement sur la machine de l'utilisateur.
Des défis subsistent : la fragmentation entre navigateurs et pilotes, le surcoût du bac à sable, la mise à disposition des instructions matricielles de sous-groupe dans les versions stables, et le bilan énergétique de millions de petites GPU clientes face à quelques data centers centralisés. En résumé : WebGPU ne transforme pas le navigateur en un serveur d'IA, il le transforme en un bac à sable sécurisé dans lequel votre propre ordinateur devient le serveur de votre IA.
Note technique : les données de performance proviennent d'un preprint non évalué par les pairs correspondant à des versions logicielles de mai 2026. Les moteurs d'exécution et les navigateurs évoluent rapidement ; il convient de vérifier ces chiffres avant toute utilisation en environnement de production.