veilletech.fr
2 sept. Feed du jour
#08 WEB Article

207 kernels WebGPU pour le navigateur

Portable ne veut pas dire rapide. Ça se mesure.

Hugging Face publie @huggingface/kernels et 207 kernels WebGPU versionnés sur le Hub, chacun livré avec manifeste, tests de correction, benchmarks et shaders WGSL. Face à ONNX Runtime Web sur un M4, les kernels sont 2,57× plus rapides en moyenne géométrique sur 809 cas comparables.

2 min de lectureavancévidéo 1:20
Partager
Sommaire4 sections
  1. Ce qui se passe
  2. Un dépôt par kernel, pas un shader isolé
  3. La mesure
  4. À retenir

Ce qui se passe

L'équipe WebAI de Hugging Face publie 207 kernels WebGPU, sous licence Apache-2.0, chacun dans son propre dépôt sur le Hub (huggingface.co/webgpu-kernels), accompagnés d'une bibliothèque de chargement, @huggingface/kernels. S'y ajoute Fleet, un banc d'essai qui tourne dans le navigateur.

Le constat de départ mérite d'être posé. Un modèle qui s'exécute dans un navigateur devient une suite d'opérations GPU : multiplications matricielles, normalisations, convolutions, primitives d'attention, quantification, réorganisations de données. WebGPU rend ces opérations portables et WGSL fournit un langage commun — mais portable ne veut pas dire rapide. Deux shaders qui produisent la même sortie peuvent se comporter très différemment selon la taille des groupes de travail, les motifs d'accès mémoire, la vectorisation ou la stratégie de fusion. Et le meilleur choix change avec la forme de l'entrée, l'appareil, le navigateur et les fonctionnalités WebGPU disponibles.

Un dépôt par kernel, pas un shader isolé

Chaque kernel embarque son contrat : manifest.json définit entrées, sorties, attributs, contraintes de type et règles de dérivation de forme ; metadata.json porte identifiant, empreintes et provenance ; s'y ajoutent les cas de correction, les cas de mesure et les gabarits de shaders WGSL.

JavaScript
import { getKernel } from "@huggingface/kernels";

const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });
Terminal
npm install @huggingface/kernels@preview

La version sélectionne le contrat publié, distinct de l'opset ONNX, du since_version d'un opérateur ou de la révision d'un modèle. L'application dépend d'un contrat JavaScript stable pendant que l'implémentation évolue derrière.

La mesure

Comparaison avec ONNX Runtime Web 1.30.0-dev sur un GPU Apple M4 : 1 756 cas de départ, 809 retenus là où les deux côtés produisaient des sorties concordantes et des mesures fiables.

Opération Kernel HF ORT WebGPU Gain
Add 0,064 ms 0,227 ms ×3,52
Softmax 0,114 ms 0,240 ms ×2,11
LayerNormalization 0,061 ms 0,135 ms ×2,22
MatMul 0,115 ms 0,131 ms ×1,14

Sur l'ensemble : ×2,57 en moyenne géométrique, ×1,90 à la médiane, avec 629 victoires, 176 défaites et 4 nuls. Les défaites sont publiées, ce qui est rare. Quelques cas extrêmes existent — un Einsum bilinéaire i,ij,j de taille 4096 passe de 1 396 ms à 0,136 ms, un CumSum par lignes sur [256, 4096] gagne ×301 — mais Hugging Face les présente comme des chemins lents de l'implémentation générale, pas comme une attente raisonnable.

Les limites sont annoncées : temps GPU seul, hors chargement, création de session, transferts et compilation de shaders ; opérations isolées, pas modèles complets.

À retenir

  1. npm install @huggingface/kernels@preview — l'API tient en un getKernel et un appel de fonction.
  2. Fleet mesure correction et vitesse sur votre propre GPU, et alimente le corpus collectif avec votre accord.
  3. Hugging Face travaille avec l'équipe ONNX Runtime pour reverser ces gains en amont : ce n'est pas un fork concurrent.

Source : Hugging Face