Résumé Technique : ExecuTorch – Une Solution PyTorch Unifiée pour Exécuter des Modèles d'IA sur Appareil

Énoncé du Problème

L'exécution locale de l'IA sur les appareils périphériques (edge) est cruciale pour les applications nécessitant une faible latence et un fonctionnement hors ligne, telles que la traduction en direct, les véhicules autonomes et la surveillance des patients. Cependant, la transition de la recherche vers la production reste fragmentée. Bien que PyTorch alimente plus de 70 % de la recherche en IA, le déploiement de modèles sur des matériels diversifiés oblige souvent les développeurs à quitter l'écosystème PyTorch. Les solutions actuelles souffrent de plusieurs limitations clés :

• Fossés Sémantiques : La conversion de modèles entre des environnements déconnectés (par exemple, vers ONNX ou TensorFlow Lite) introduit des incohérences sémantiques qui ne se manifestent souvent qu'après le déploiement.
• Coûts de Réimplémentation : Des frameworks comme llama.cpp ou des outils spécifiques aux fournisseurs (par exemple, Qualcomm SNPE, Apple CoreML) nécessitent souvent une réimplémentation complète du modèle ou un couplage étroit avec des fournisseurs de matériel spécifiques.
• Surcharge d'Exécution : Les solutions natives PyTorch existantes, telles que TorchScript et PyTorch Mobile, souffrent d'une surcharge d'exécution et d'empreintes mémoire prohibitives.
• Friction d'Expérimentation : L'absence de « parité d'expérimentation » signifie que les chercheurs ne peuvent pas valider les comportements de déploiement (quantification, délégation matérielle) dans PyTorch avant de s'engager dans la production, ce qui entraîne des écarts numériques et des cycles de débogage intensifs en ressources.

Méthodologie : Architecture d'ExecuTorch

ExecuTorch est présenté comme un framework de déploiement unifié et natif PyTorch conçu pour combler le fossé entre la recherche et la production. Il exploite les technologies centrales de PyTorch (torch.compile, torch.export) pour construire une représentation portable des modèles, qui peut être déployée sous forme de binaires sur des matériels hétérogènes.

Composants Principaux

1. Pile d'Export AOT (Ahead-of-Time) :

   • torch.export et IR : Le système capture les graphes de calcul issus de torch.nn.Module dans une structure de données de graphe statique appelée Export IR. Cette IR est un graphe Torch FX offrant des garanties solides concernant la validité des formes, la normalisation des graphes (sans sémantique Python) et la disponibilité des métadonnées.
   • Dialecte Edge : Une Représentation Intermédiaire (IR) plus restrictive construite sur Export IR. Elle impose des graphes entièrement fonctionnels (pas de mutations/aliasing), restreint les opérateurs à un ensemble de <300 primitives « Core ATen », et définit explicitement les types de données et les formats mémoire.
   • Transformations de Graphe : Des opérations telles que la quantification, la délégation de sous-graphes et la planification mémoire sont effectuées en amont (AOT). Cela permet au runtime de rester léger, se concentrant uniquement sur l'exécution de graphes pré-optimisés.

2. Pile Runtime :

   • Exécution Légère : Le runtime est une bibliothèque C++ légère (C++17) avec des dépendances minimales. Il exécute des listes d'instructions encodées dans le format de fichier PTE (PyTorch Edge).
   • Délégation Backend : L'architecture prend en charge une délégation sélective de backend. Un partitionneur identifie les sous-graphes composés d'opérateurs pris en charge par des accélérateurs matériels spécifiques (par exemple, Qualcomm Hexagon, Apple Neural Engine) et les achemine vers des compilateurs de délégation. Le reste du graphe s'exécute sur le CPU.
   • Gestion de la Mémoire : Un planificateur de mémoire alloue de l'espace au sein d'aires mémoire de taille fixe avant la sérialisation, éliminant ainsi l'allocation mémoire dynamique au moment de l'exécution. Cela est crucial pour les environnements contraints en ressources comme les microcontrôleurs.

3. Sérialisation et Stockage :

   • Format PTE : Un format de fichier personnalisé conçu pour une surcharge minimale, séparant les données du programme (instructions) des données de poids (segments).
   • Partage de Poids : Prend en charge les fichiers PTE multi-méthodes (partage de données entre les méthodes de modèle telles que prefill et decode) et la séparation programme-données (partage de poids entre modèles via des fichiers PTD externes).

Technologies Clés

• Quantification : Basée sur TorchAO, prenant en charge à la fois la Quantification Post-Entraînement (PTQ) et la Quantification Sensible à l'Entraînement (QAT). Elle supporte la quantification statique, dynamique et uniquement sur les poids, y compris la quantification par groupes de 4 bits pour les Grands Modèles de Langage (LLM).
• Kernels Personnalisés : Les développeurs peuvent implémenter des kernels personnalisés et construire sélectivement des opérateurs pour réduire la taille du binaire.
• Outils de Développement : Comprend ETRecord (capture des graphes Dialecte Edge et des métadonnées de débogage) et ETDump (capture des événements d'exécution, des latences et des durées de vie mémoire) pour relier le comportement en mode eager à l'exécution sur appareil.

Contributions Principales

L'article expose trois contributions principales :

1. Framework Unifié : ExecuTorch est présenté comme le premier framework PyTorch à atteindre la parité d'expérimentation grâce à des graphes d'export exécutables localement. Il permet un déploiement unifié, des microcontrôleurs aux smartphones, sans conversion ni réimplémentation de modèle.
2. Principe de Conception : L'article introduit la « parité d'expérimentation » comme principe de conception fondamental. Grâce à torch.export et à une intégration backend pilotée par les capacités, les chercheurs peuvent valider la quantification, la délégation matérielle et les performances entièrement dans PyTorch avant le déploiement en production.
3. Viabilité en Production : Le framework est démontré à grande échelle, alimentant des milliards d'inférences quotidiennes à travers la famille d'applications de Meta et les Reality Labs (par exemple, les lunettes intelligentes Ray-Ban). Il prend en charge la vision, l'audio et les LLM sur 12 backends matériels.

Résultats de Performance

Les auteurs ont évalué ExecuTorch par rapport à des alternatives largement utilisées (ONNX Runtime, llama.cpp, LiteRT, CoreML) sur des appareils mobiles (Samsung Galaxy S25 Ultra, Google Pixel 9 Pro XL, iPhone 15 Pro).

• Performance des LLM :
  • CPU : Le backend XNNPACK d'ExecuTorch offre des performances compétitives ou de pointe, surpassant souvent ONNX et LiteRT.
  • GPU : Le backend Vulkan atteint un débit élevé de génération de tokens. Sur le Pixel 9 Pro XL, il surpasse significativement llama.cpp en débit de prefill.
  • NPU : Le backend QNN débloque des accélérations substantielles de prefill sur les NPU (par exemple, Qualcomm Hexagon) lorsque les modèles sont bien délégués. Pour Llama 3.2 1B, QNN a montré un débit de prefill supérieur à QAIRT, bien que QAIRT ait atteint un débit de decode plus élevé.
• Modèles de Vision :
  • Sur CPU, le delegate XNNPACK a offert des performances extrêmement solides par rapport à LiteRT et ONNX.
  • Sur GPU, le delegate Vulkan a exécuté les modèles avec une délégation complète du graphe. Bien que certains opérateurs non pris en charge aient nécessité une bascule CPU (par exemple, dans ViT et Swin-T), la surcharge des ruptures de graphe était minimale (5–6 % de la latence).
  • Sur iOS, le delegate CoreML correspondait ou surpassait légèrement le CoreML natif sur tous les modèles testés.
• Déploiement sur Microcontrôleur (MCU) :
  • Démontré sur un Raspberry Pi Pico 2 (520 KiB de SRAM).
  • La construction sélective a réduit la taille du code d'environ 1,3 MiB à environ 200–250 KiB.
  • La quantification Int8 avec CMSIS-NN a réduit l'utilisation de la RAM à environ 11 KiB et a fourni une accélération d'inférence de 16,46× par rapport au FP32.

Importance et Affirmations

L'article affirme qu'ExecuTorch élimine avec succès le compromis entre la vélocité de développement de PyTorch et les exigences de déploiement périphérique. En préservant la sémantique PyTorch de l'entraînement à la production, il permet aux chercheurs de valider le comportement de déploiement (y compris la quantification et la délégation matérielle) au sein de l'environnement PyTorch familier. Cette « parité d'expérimentation » comble le fossé entre la recherche et la production, permettant une expérimentation rapide et réduisant la friction dans la boucle expérimentation-déploiement. Le framework est positionné non seulement comme un outil de performance, mais comme un flux de travail unifié qui prend en charge tout le spectre des appareils périphériques, des microcontrôleurs à moins d'un dollar aux systèmes complexes sur puce (SoC).