L'accélération WebGPU de 2,57x de Hugging Face s'accompagne de 176 pertes

Hugging Face a publié 207 noyaux WebGPU sous une nouvelle organisation webgpu-kernels sur son Hub, ainsi qu'un chargeur JavaScript appelé @huggingface/kernels qui les télécharge et les exécute dans le navigateur. Un troisième volet, Fleet, évalue ces noyaux sur le GPU dont dispose le visiteur.

La publication s'accompagne d'un chiffre : une accélération de 2,57x en moyenne géométrique mesurée face au backend WebGPU d'ONNX Runtime Web sur une Apple M4, et de 1,90x en médiane. Les deux chiffres sont réels. Les deux sont plus étroits qu'ils n'en ont l'air.

Ce que mesure réellement le 2,57x

La comparaison directe a été menée sur un GPU Apple M4 face à ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a. Hugging Face est parti de 1 756 cas de test couvrant les 207 opérations, puis a retenu les 809 où les deux implémentations produisaient des sorties identiques et des mesures de temps fiables. Les 947 autres cas ne figurent pas dans le chiffre.

La mesure ne couvre que le travail du GPU. Le chargement des noyaux, la création de sessions, l'envoi des entrées, la compilation des shaders et la lecture des sorties sont exclus des deux côtés. Hugging Face prévient que les charges de travail très courtes sont difficiles à mesurer et que les petits cas peuvent bénéficier du cache GPU, si bien que ces chiffres se lisent mieux comme une comparaison que comme une promesse pour une application donnée. Un appareil sur un navigateur ne décrit pas non plus WebGPU, une réserve que l'entreprise formule elle-même.

Un Einsum à 10 000x et un CumSum à 301x

Deux entrées sortent largement de l'agrégat. Un Einsum bilinéaire de taille 4096 a tourné en 0,136 ms contre 1 396 ms pour ORT WebGPU, un écart de plus de 10 000x. Un CumSum ligne par ligne sur une entrée [256, 4096] s'est terminé en 0,016 ms contre 4,784 ms, soit 301x. Hugging Face qualifie les deux d'inhabituels et les attribue à une implémentation générale tombant dans un chemin lent.

Les opérations ordinaires racontent une histoire plus plate :

MatMul s'améliore de 1,14x. Add l'emporte de 3,52x, même si additionner quelques flottants n'est pas là où passe le temps d'inférence. La publication ne ventile pas les 629 victoires par classe d'opération, si bien que les charges de travail que la collection accélère le plus ne sont pas tranchées par les données publiées.

Les 176 pertes

Le décompte de Hugging Face lui-même est de 629 victoires, 176 pertes et 4 égalités. Les pertes ne sont pas la colonne qu'un billet de lancement est obligé d'afficher, et la publication ne les explique pas. Elle note en revanche que la meilleure implémentation change selon la forme des entrées, l'appareil, le navigateur et les fonctionnalités WebGPU disponibles, soit le type de variabilité qui produit une colonne de pertes de cette taille. Les données de pertes par opération ne sont pas publiées, si bien que l'on ignore si les pertes se concentrent sur quelques noyaux ou se répartissent sur l'ensemble.

Des noyaux empaquetés comme des contrats, pas comme des shaders

Chaque noyau dispose de son propre dépôt, avec sa propre fiche documentant la sémantique, les entrées, les sorties, les attributs, les types de données pris en charge et les fichiers source. Derrière la fiche se trouvent cinq types d'artefacts : manifest.json, la source de vérité du contrat de l'opération ; metadata.json pour les identifiants, les empreintes et la provenance ; test.json pour les cas de correction ; bench.json pour les cas de benchmark et de réglage ; et les fichiers *.wgsl.jinja contenant le WGSL paramétré, spécialisé selon la requête et l'appareil.

Le versionnage des contrats reste distinct de celui d'ONNX. Une version passée à getKernel n'est ni un opset, ni un since_version d'opérateur, ni une révision de modèle, ce qui permet à une application de dépendre d'une interface JavaScript stable pendant que les implémentations de shaders évoluent en dessous. Le noyau Add est livré en quatre variantes : formes égales, diffusion vectorisée, traitement scalaire et diffusion générale, l'addition avec diffusion nécessitant un indexage différent.

import { getKernel } from "@huggingface/kernels";
const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });
const { c } = await add({
  a: { data: new Float32Array([1, 2, 3, 4, 5, 6]), shape: [2, 3] },
  b: { data: new Float32Array([10, 20, 30]), shape: [3] },
});

Le chargeur déduit la forme de sortie à partir du manifest et alloue le résultat, si bien que le schéma d'appel reste identique pour les opérations lourdes où les noyaux rapportent réellement. Hugging Face indique travailler avec l'équipe ONNX Runtime pour remonter ces améliorations dans ONNX Runtime Web. Si cela aboutit, les accélérations cessent d'être une raison d'adopter le chargeur de Hugging Face et deviennent quelque chose que les utilisateurs d'ORT Web obtiennent par défaut.

Fleet, le consentement et la distance jusqu'à un modèle

Fleet exécute des contrôles de correction et de performance dans le navigateur et rapporte les résultats pour la machine locale. La contribution se fait sur base volontaire : avec le consentement, chaque exécution ajoute ce que Hugging Face appelle des preuves privées, utilisées pour identifier les défaillances propres à un appareil, comparer les variantes et améliorer les règles de sélection sur un matériel qu'un laboratoire de test classique ne pourrait pas couvrir. La prise en charge de WebGPU varie elle-même selon le navigateur, le système d'exploitation, le GPU et le pilote, et peut être détectée avec "gpu" in navigator.

Rien de tout cela n'est un benchmark de modèle. Les mesures sont par opération, et un modèle exécuté dans le navigateur est une séquence d'opérations GPU dont le temps d'exécution ne peut être aussi efficace que les opérations qu'il envoie. Relever le plancher sous Add, Softmax et LayerNormalization ne garantit pas que la couche supérieure affiche le même multiple.

Les éléments qui décident si tout cela compte sont ternes : si le travail de remontée vers ONNX Runtime aboutit, si les preuves de Fleet arrivent assez vite pour corriger ce qu'elles trouvent, et si la colonne des pertes se réduit. Hugging Face l'a imprimée à côté des victoires, ce qui n'est pas la manière habituelle d'écrire les lancements de noyaux.