Hugging Face publie 207 kernels WebGPU et l’outil Fleet

Hugging Face diffuse une collection de 207 kernels WebGPU versionnés et un chargeur JavaScript pour les exécuter depuis le Hub. Un nouvel outil, Fleet, mesure dans le navigateur la correction et la performance sur des GPU réels. La société rapporte des gains face à ORT WebGPU sur un Apple M4, avec des réserves méthodologiques et des variations attendues selon les appareils et navigateurs.

Des gains mesurés face à ORT WebGPU et leurs bornes

Hugging Face a comparé ses kernels WebGPU à ORT WebGPU sur un GPU Apple M4, avec ONNX Runtime Web version 1.30.0-dev.20260826-b1f76d586a. Les essais ont démarré avec 1 756 cas couvrant 207 opérations et ont retenu 809 cas aux sorties concordantes et temps jugés fiables. La société indique des accélérations de 2,57 fois en moyenne géométrique et 1,90 fois à la médiane, pour 629 gains, 176 pertes et 4 égalités. Dans un cas d’Einsum bilinéaire i,ij,j de taille 4096, le kernel Hugging Face a exécuté en 0,136 ms contre 1 396 ms avec ORT WebGPU, soit un ordre de grandeur présenté comme supérieur à 10 000 fois. Un CumSum ligne par ligne sur [256, 4096] a montré 301 fois d’écart, avec 0,016 ms contre 4,784 ms. Les mesures portent sur le travail GPU uniquement, hors chargement, création de session, transfert des entrées, compilation des shaders et lecture des sorties. L’éditeur prévient que les petites charges sont plus difficiles à mesurer et peuvent bénéficier du cache GPU, et que ces chiffres comparent des opérations isolées, pas des modèles entiers. Il anticipe des variations selon GPU et navigateurs, d’où l’intérêt de Fleet pour élargir le panorama.

Fleet organise des preuves sur matériel réel avec consentement

Fleet exécute et évalue les kernels directement dans le navigateur de l’utilisateur. Avec consentement, chaque passage ajoute des preuves privées qui aident à repérer des résultats incorrects ou des lenteurs pathologiques, à comparer des variantes et à améliorer les règles de sélection. L’outil vise à agréger des données issues d’une diversité de GPU et de navigateurs pour guider les optimisations. L’objectif déclaré est de s’appuyer sur une couverture large et réelle afin de rendre les kernels plus rapides et plus fiables pour tous.

Des kernels publiés comme artefacts complets et versionnés

Les 207 kernels sont publiés en dépôts séparés au sein de l’organisation webgpu-kernels, sous licence Apache-2.0. Chaque kernel comprend une interface documentée, des modèles WGSL, des tests de correction, des cas de benchmark et des instructions d’usage. Les dépôts embarquent manifest.json pour le contrat d’opération, metadata.json pour l’identifiant et la provenance, test.json pour la validation fonctionnelle, bench.json pour l’évaluation de performance et .wgsl.jinja afin de produire les shaders correspondant à la demande et à l’appareil utilisé. Cette méthode fait de chaque shader un composant logiciel réutilisable, dont l’interface peut être examinée sans consulter le code WGSL, et qui se charge via des versions publiées plutôt que par des URL non permanentes. Ces kernels peuvent également être utilisés comme ressources de référence pour les développeurs qui créent leurs propres kernels ou qui intègrent ces opérations dans des runtimes.

Le module JavaScript permet l’exécution directe des kernels depuis le Hub

Le module JavaScript @huggingface/kernels récupère, prépare et lance les kernels directement à partir du Hub. Le package s’obtient via npm en version preview. Son usage suppose un navigateur compatible WebGPU, dont la disponibilité dépend du navigateur, du système d’exploitation, du GPU et du pilote ; la présence de l’API peut être vérifiée par la propriété gpu de navigator. L’API getKernel charge un kernel par identifiant de dépôt et version de contrat, puis la fonction retournée s’appelle avec des données typées et des formes de tenseurs. Dans l’exemple d’addition de biais, la sortie diffusée a la forme [2, 3] ; le chargeur déduit forme et type depuis le contrat et alloue la sortie automatiquement.

Variantes d’exécution et stabilité des contrats

Le kernel ai.onnx.Add sert d’exemple pour l’addition élémentaire avec diffusion. Sa fiche décrit deux entrées, la forme de sortie après diffusion, les types compatibles et plusieurs alternatives. Lorsque l’échelle est très réduite, le coût du transfert GPU peut dépasser celui du calcul, mais la manière d’appeler l’opération reste la même pour des tâches plus lourdes comme ai.onnx.MatMul. Le kernel Add disponible inclut des versions pour des formes identiques, pour la diffusion vectorisée, pour le traitement scalaire et pour la diffusion générale ; l’exécution sélectionne automatiquement la version adéquate sans modification de l’API. L’option version: 1 permet de choisir un contrat de kernel particulier, qui ne correspond pas aux concepts d’opset ONNX, de since_version d’opérateur ou de révision de modèle, afin de garantir la stabilité côté JavaScript.

Périmètre initial, collaboration ONNX Runtime et ambition commune

207 kernels WebGPU et un outil de benchmarking dans le navigateur, s’appuyant sur WebGPU et sur le langage WGSL pour l’exécution des opérations, ont été présentés. Hugging Face mentionne collaborer avec l’équipe ONNX Runtime pour que ses avancées profitent à l’ensemble de l’écosystème ONNX Runtime Web. L’éditeur considère ces 207 kernels comme une première étape, visant à proposer sur le Hub un espace partagé pour examiner les contrats, comparer les implémentations, vérifier les résultats et optimiser les performances sans multiplier les shaders dans chaque application. Cette initiative s’insère dans la volonté affichée de rendre l’inférence rapide et accessible dans le navigateur.