Hugging Face a annoncé @huggingface/kernels le 1er septembre 2026, avec une première collection de 207 kernels WebGPU. Pour les évaluer utilement, il faut relier chaque résultat à votre navigateur, votre GPU, vos formes de tenseurs et votre charge de travail, plutôt que de retenir un chiffre isolé.

Commencez par l’environnement d’exécution

Vérifiez d’abord que le navigateur ciblé prend en charge WebGPU. Sa disponibilité dépend du navigateur, du système d’exploitation, du GPU et du pilote. Un résultat obtenu sur un autre matériel ou dans un autre navigateur peut donc différer de celui observé par les utilisateurs de votre application.

Dans une application JavaScript, Hugging Face relie un dépôt du Hub à l’application avec getKernel. L’appel reçoit un identifiant de dépôt et une version de contrat, puis accepte des données typées et des formes de tenseurs. Notez ces paramètres dès le début : ils sont nécessaires pour reproduire la comparaison avec le même kernel et le même contrat.

Identifiez précisément le package testé

Chaque kernel est un package versionné qui contient son interface, ses modèles de shaders, ses cas de test de justesse, ses cas de benchmark et ses instructions d’utilisation. Les 207 kernels sont des dépôts individuels de l’organisation webgpu-kernels et sont distribués sous licence Apache-2.0.

L’interface et la version du contrat font donc partie du résultat à évaluer. Un test de vitesse ne suffit pas à décrire ce que l’application devra réellement intégrer.

Dans une mise à jour publiée le 6 juillet 2026, Hugging Face a présenté Kernels comme un projet destiné à standardiser le packaging, la distribution et la consommation de kernels personnalisés. La même mise à jour a introduit un type de dépôt Hub appelé kernel, qui indique les accélérateurs pris en charge, les systèmes d’exploitation compatibles et les versions des backends. Servez-vous de ces informations comme premier filtre, puis confirmez la compatibilité sur le matériel qui exécutera l’application.

Validez les sorties avant de comparer les temps

Un kernel plus rapide n’est intéressant que si ses sorties concordent avec celles attendues. Hugging Face a comparé sa collection à ORT WebGPU avec ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a, sur un GPU Apple M4. La comparaison a commencé avec 1 756 cas couvrant les 207 opérations. Seuls 809 cas ont été conservés, car les deux implémentations produisaient des sorties concordantes et des mesures de temps fiables.

Reproduisez cette logique sur les formes et les données utilisées par votre application. Exécutez les cas de justesse, puis écartez les mesures trop instables pour être comparées. Un essai isolé rapide ne constitue pas un gain exploitable si le cas correspondant produit une sortie incorrecte.

Interprétez les chiffres opération par opération

Sur les 809 comparaisons conservées, Hugging Face a annoncé une accélération moyenne géométrique de 2,57× et une accélération médiane de 1,90× face à ORT WebGPU. La collection a enregistré 629 gains, 176 pertes et quatre égalités.

Ces valeurs concernent des opérations individuelles dans la configuration indiquée. Elles ne mesurent pas la vitesse d’un modèle complet, qui peut aussi dépendre d’autres opérations, des transferts et du travail de préparation.

L’écart varie fortement selon l’opération et le nombre de cas. Add a affiché 0,064 ms pour le kernel Hugging Face contre 0,227 ms pour ORT WebGPU sur cinq cas, soit un facteur de 3,52×. MatMul a affiché 0,115 ms contre 0,131 ms sur 29 cas, soit 1,14×. Softmax a affiché 0,114 ms contre 0,240 ms sur 12 cas, tandis que LayerNormalization a affiché 0,061 ms contre 0,135 ms sur six cas.

Les cas atypiques doivent rester associés à leur opération et à leur forme. Un cas bilinéaire d’Einsum de taille 4096 a affiché 0,136 ms avec le kernel Hugging Face et 1 396 ms avec ORT WebGPU, soit plus de 10 000× plus rapide selon le rapport. Un CumSum par lignes sur [256,4096] a affiché 0,016 ms contre 4,784 ms, soit une accélération de 301×.

Ces résultats servent à repérer des candidats à examiner, pas à promettre un gain général. Une accélération importante au niveau d’une opération ne modifiera le temps total que si cette opération et cette forme apparaissent assez souvent et représentent une part suffisante du travail exécuté.

Reconstruisez la comparaison autour de votre charge

  1. Répertoriez les opérations et les formes de tenseurs importantes pour l’application.
  2. Vérifiez la disponibilité de WebGPU, le contrat du package et ses informations de compatibilité.
  3. Exécutez les cas de justesse avant d’utiliser les mesures de temps pour choisir entre les implémentations.
  4. Comparez la même opération et la même forme avec l’alternative disponible dans l’application.
  5. Associez à chaque résultat le navigateur, le système d’exploitation, le GPU, le pilote et la version du backend.
  6. Décidez seulement après avoir vérifié que l’opération mesurée peut modifier le comportement de l’application complète.

Cette séquence permet de conserver une décision vérifiable. Utilisez le candidat lorsque sa justesse est confirmée et que ses formes pertinentes améliorent la charge de travail. Conservez l’alternative si la compatibilité échoue, si les sorties divergent ou si le gain mesuré ne change pas réellement le résultat de l’application complète.

Ne confondez pas le temps GPU et le temps visible

Hugging Face a lancé Fleet, une suite de benchmarking et de tests GPU accessible depuis le navigateur. Elle exécute et évalue les kernels sur le matériel de l’utilisateur. Avec son consentement, chaque exécution fournit des données privées sur les performances et la justesse, qui peuvent aider à repérer les échecs, à comparer des variantes et à améliorer les décisions d’optimisation.

Le consentement de l’utilisateur doit être recueilli avant d’utiliser Fleet à cette fin. La mesure couvre uniquement le travail du GPU : elle exclut le chargement des kernels, la création de session, les transferts d’entrée, la compilation des shaders et la récupération des sorties.

Un kernel gagnant dans Fleet peut donc procurer un bénéfice de bout en bout plus faible une fois ces activités prises en compte. Mesurez séparément l’application complète lorsque le démarrage, le déplacement des données ou la gestion des sorties participent au temps perçu par l’utilisateur.

Ce que la comparaison ne permet pas encore d’affirmer

Hugging Face indique travailler avec l’équipe d’ONNX Runtime à l’intégration de ces améliorations dans l’écosystème ONNX Runtime Web. Cette intégration reste une orientation annoncée, et non une intégration achevée. Évaluez donc le kernel disponible et son alternative dans l’environnement que vous contrôlez réellement.

La décision tient en trois vérifications : compatibilité WebGPU et du package, sorties correctes, puis gain mesuré sur les opérations et les formes propres à l’application. La comparaison publiée aide à sélectionner des candidats, mais seule une mesure de bout en bout permet de savoir si le remplacement améliore réellement l’expérience.

Sources officielles

Sources et méthodologie

  1. Official source: huggingface.co Ouvre une source externe
  2. Official source: huggingface.co Ouvre une source externe