Le 1er septembre, Hugging Face a publié @huggingface/kernels, une bibliothèque de chargement JavaScript destinée à télécharger, préparer et exécuter des kernels WebGPU optimisés depuis le Hub. Dans la foulée sont arrivés 207 kernels GPU déjà réglés, couvrant la multiplication matricielle, la normalisation, la convolution, les primitives d'attention, les opérations de quantification et les transformations de disposition des données, sur plusieurs architectures de machine learning. Le tout sous licence Apache-2.0.
C'est l'organisation qui a le plus de quoi surprendre dans ce projet : chaque kernel est publié comme un dépôt indépendant, avec sa propre définition d'interface, ses templates de shader, ses tests de correction et ses données de benchmark. Une fois sur le Hub, un kernel et un modèle suivent le même mécanisme de versionnage, de téléchargement et de référencement.
809 comparaisons de référence
Les performances ont été mesurées directement face à ORT WebGPU 1.30.0-dev, sur 809 cas de test : une accélération moyenne géométrique de 2,57 fois, une médiane de 1,90 fois, avec un bilan de 629 victoires, 176 défaites et 4 égalités. Kernel par kernel, Add est 3,52 fois plus rapide, Softmax 2,11 fois et LayerNormalization 2,22 fois.
À la louche, le taux de victoires tourne autour de 78 %. Le fait que la moyenne géométrique de 2,57 dépasse nettement la médiane de 1,90 indique une distribution des gains asymétrique vers la droite — une poignée de kernels accélèrent énormément et tirent la moyenne vers le haut. Le gain réellement perceptible sur des charges de travail concrètes est sans doute plus proche de la médiane que du chiffre le plus flatteur de l'annonce. Cela ne change pas la conclusion, ça remet simplement les attentes à leur juste place.
S'y ajoute un outil de benchmark fonctionnant directement dans le navigateur, baptisé Fleet, conçu sur le principe du crowdsourcing : chaque machine qui l'exécute renvoie des preuves de performance et de correction. La fragmentation matérielle de WebGPU est bien plus marquée que celle de CUDA côté serveur — GPU intégrés, GPU dédiés, GPU mobiles et implémentations navigateur diffèrent fortement, ce qu'une poignée de machines de laboratoire ne peut pas révéler. Répartir les tests entre les utilisateurs est la solution pragmatique.
Pourquoi le blocage se situe à la couche des kernels
L'attrait de faire tourner des modèles directement dans le navigateur a toujours été évident : le calcul se fait sur l'appareil de l'utilisateur, le serveur ne paie pas la facture de calcul, et les données n'ont pas besoin de quitter la machine. Ce qui freine généralement l'adoption, ce n'est ni le format du modèle ni le framework d'inférence, mais la couche des kernels en dessous — pour une même fonction Softmax, l'écart entre une implémentation soignée et une implémentation moyenne, c'est l'écart entre pouvoir tourner en temps réel ou non.
Jusqu'ici, cette couche ne pouvait évoluer qu'avec l'ensemble du runtime d'inférence. Pour passer à une implémentation d'attention plus rapide, il fallait généralement attendre une nouvelle version du framework. Séparés en dépôts indépendants, les kernels deviennent des unités que l'on peut remplacer, annuler ou améliorer isolément. Remplacer, pour un modèle donné, un kernel de multiplication matricielle optimisé pour un type de GPU précis ne devrait, en théorie, exiger de toucher à rien d'autre dans le code.
L'appel est lui aussi réduit à l'essentiel : on récupère l'objet kernel et on l'utilise directement comme une fonction :
const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });Le prérequis est que le navigateur supporte WebGPU, ce qui se vérifie en une seule ligne : "gpu" in navigator.
Ce que ça change pour les outils embarqués
Les bénéficiaires de cette mise à jour sont assez précis : les équipes qui font du traitement d'image purement dans le navigateur, de la transcription locale, de la traduction hors ligne, des outils sensibles à la vie privée. Le modèle économique de ce type de produits repose sur un serveur qui ne sert que des fichiers statiques, sans supporter le coût de calcul — et la taille de modèle qui tient dans le navigateur dépend directement des performances des kernels. Avec des kernels globalement deux fois plus rapides, le plafond de paramètres des modèles utilisables remonte d'un cran, et une opération qui prenait trois secondes peut tenir en une seconde.
La part de prudence mérite aussi d'être posée clairement. Le benchmark compare à une version dev d'ORT WebGPU, un concurrent qui continue lui aussi de progresser ; 207 kernels, ça paraît beaucoup, mais cela couvre surtout les opérations courantes — face à une architecture peu répandue, il faudra toujours écrire soi-même le kernel. Le support de WebGPU s'est certes généralisé sur les navigateurs, mais la qualité des implémentations mobiles reste inégale, et le comportement d'un appareil à l'autre demande d'être testé soi-même avec des outils comme Fleet.
Faire des kernels des ressources adressables, versionnées et vérifiées par crowdsourcing a un impact plus durable que le simple doublement de vitesse. Les poids des modèles circulent déjà de cette façon depuis longtemps ; que l'infrastructure du code suive n'était qu'une question de temps.
Sources : blog officiel de Hugging Face, CocoLoop, dépôts Hugging Face Hub ; les chiffres de 207 kernels, 809 cas de test, l'accélération moyenne géométrique de 2,57x et la médiane de 1,90x, le bilan de 629-176-4 ainsi que les facteurs par kernel ont été vérifiés d'après l'annonce officielle ; le taux de victoires et la lecture sur l'asymétrie de la distribution relèvent d'une estimation de la rédaction.