ExecuTorch exécute PyTorch dans le navigateur sur GPU : une génération de texte 2 à 10 fois plus rapide

Si votre équipe entraîne un modèle dans PyTorch, l'exécuter dans le navigateur signifie généralement une tâche d'ingénierie supplémentaire : le convertir dans un format adapté, puis vérifier que tout fonctionne après le transfert. Le nouveau backend WebGPU d'ExecuTorch raccourcit ce parcours. Le modèle est exporté dans un fichier .pte, et les calculs s'exécutent sur le GPU de l'appareil de l'utilisateur. Dans le test publié, la génération de texte s'est révélée de 2 à 10 fois plus rapide que la variante CPU. Pour un développeur, c'est une raison d'examiner quelle part du traitement peut passer du serveur à l'onglet du navigateur.

Ce qui change pour l'équipe

Imaginez une application web où l'utilisateur charge la photo d'un produit et supprime l'arrière-plan. Avec un traitement côté serveur, il faut recevoir l'image, mettre la tâche en file d'attente, exécuter le modèle et renvoyer le résultat. Une approche locale permet un autre scénario : le navigateur télécharge le modèle, puis traite l'image sur l'appareil de l'utilisateur. Il s'agit d'un exemple d'usage de la technologie, et non de la mesure d'un service commercial existant.

La différence pour l'équipe est très concrète. Si le traitement convient à l'appareil du client, il n'est plus nécessaire de payer une exécution serveur pour chaque photo. En revanche, d'autres coûts apparaissent : la distribution des poids, la prise en charge de divers appareils et l'analyse des erreurs dans le navigateur. Les économies doivent être calculées à partir de votre propre trafic, et non déduites du seul fait que WebGPU existe.

En interne, le système associe WebAssembly et WebGPU. Le premier permet au moteur d'exécution de fonctionner dans le navigateur, le second donne accès aux calculs sur la carte graphique. L'export reste dans l'écosystème d'outils de PyTorch : il n'est pas nécessaire de passer au format d'un autre framework. Cela reste une étape distincte de préparation du modèle, et non la possibilité d'insérer du code Python arbitraire dans une page web. L'architecture et les résultats des tests sont décrits dans la publication de l'équipe PyTorch.

D'où viennent les 2 à 10 fois

L'équipe a comparé WebGPU au backend CPU d'ExecuTorch, qui s'appuie sur WebAssembly et XNNPACK. Les mesures ont été effectuées dans Chrome sur un Apple M1 Pro avec les modèles quantifiés Llama 3.2 1B et Qwen3-0.6B. Le traitement du contexte d'entrée a été accéléré de 4 à 7 fois, et la génération séquentielle de jetons de 2 à 10 fois. Ces chiffres correspondent à une comparaison précise, et non à l'ensemble des méthodes d'exécution de modèles dans le navigateur.

Pour un product manager, il est important de distinguer deux latences. D'abord, l'application doit obtenir le modèle et le préparer. Ensuite, l'utilisateur attend la réponse à sa requête. L'accélération des calculs est utile, mais ne dit rien, à elle seule, du temps que les gens passeront devant l'écran lors de la première ouverture de l'application. C'est un indicateur distinct qu'il vaut la peine de mesurer dans un prototype.

Un test pratique gagne donc à être construit autour de l'action de l'utilisateur : ouvrir la page via un réseau ordinaire, charger un vrai fichier, obtenir le résultat, répéter l'opération. Comparez le premier lancement et les suivants, vérifiez la mémoire disponible et le comportement sur un ordinateur portable peu puissant. Une réponse rapide sur la machine du développeur ne dit pas encore quelle expérience vivra l'ensemble du public.

Que tester et où sont les limites

On peut commencer par le Playground officiel. Il propose un chat local, la reconnaissance vocale, la détection d'objets et l'estimation de profondeur à partir de l'image de la caméra. La plateforme est signalée comme expérimentale ; elle permet de vérifier le scénario lui-même sur vos appareils avant de préparer votre propre export.

Pour une application de photos ou de voix, le traitement local modifie aussi le trajet des données : il n'est pas nécessaire d'envoyer l'entrée au serveur pour l'inférence. Mais c'est une propriété d'une implémentation donnée. Si vous ajoutez l'envoi des sources vers l'analytique ou un scénario de repli dans le cloud, la promesse faite à l'utilisateur devra être revue. L'architecture de traitement et les requêtes réseau réelles doivent être vérifiées ensemble.

Le backend lui-même en est encore à un stade précoce de développement. Une étape suivante raisonnable consiste donc à prendre une fonction limitée, à définir les appareils pris en charge et à la comparer à la solution actuelle. Par exemple, tester la suppression d'arrière-plan sur des photos typiques de clients. La décision de déploiement doit reposer sur le délai d'obtention du résultat, la qualité du traitement et le coût de maintenance. Le nouveau chemin de PyTorch vers le navigateur facilite une telle expérience, mais c'est à l'équipe d'en mesurer elle-même le résultat.