Résumé Technique : Llamas sur le Web

Énoncé du Problème

L'exécution locale de modèles de langage de grande taille (LLM) dans les navigateurs web offre des avantages significatifs en matière de confidentialité, de latence et d'efficacité énergétique, particulièrement alors que les développeurs de modèles publient des modèles à poids ouverts conçus pour le déploiement en périphérie. Cependant, la réalisation de ce potentiel est entravée par trois contraintes principales dans les frameworks d'inférence basés sur le navigateur existants (par exemple, WebLLM, Transformers.js) :

1. Inefficacités Mémoire : Les moteurs existants allouent souvent dynamiquement la mémoire GPU et chargent les poids de manière inefficace. Cela entraîne une croissance de la mémoire pendant l'exécution, provoquant des ralentissements ou des plantages dus aux limites mémoire strictes imposées par les navigateurs par onglet.
2. Absence de Conception Portable en Performance : Bien que WebGPU offre une portabilité fonctionnelle sur divers matériels, les frameworks existants manquent de spécialisation suffisante des noyaux. Ils échouent à s'ajuster aux capacités spécifiques des appareils (par exemple, opérations de sous-groupes, cœurs tensoriels), entraînant des performances sous-optimales à travers le paysage hétérogène du matériel des navigateurs.
3. Support Limité de la Quantification : Pour prendre en charge la grande variété de formats de quantification utilisés dans l'écosystème llama.cpp (allant des schémas hérités aux K-quants et I-quants avancés), les moteurs d'inférence nécessitent des conceptions de noyaux flexibles. Les frameworks existants manquent souvent de l'extensibilité nécessaire pour prendre en charge efficacement ces formats divers ou pour intégrer rapidement de nouveaux formats.

Méthodologie : LlamaWeb

Les auteurs présentent LlamaWeb, un backend WebGPU pour llama.cpp conçu pour répondre à ces contraintes. Le système est construit au sein du codebase de llama.cpp pour tirer parti de son support étendu des modèles et de son écosystème actif. La conception se concentre sur trois piliers fondamentaux :

1. Inférence Locale Efficace en Mémoire

Pour minimiser la surcharge mémoire et assurer la stabilité sur les appareils à mémoire contrainte :

• Allocation Statique de Mémoire : Toute la mémoire requise pour l'exécution du modèle, y compris les structures de données intermédiaires pour des opérations comme FlashAttention et les régions à taille fixe pour les paramètres de noyau, est allouée statiquement au démarrage. Cela évite la création dynamique de tampons et la fragmentation.
• Chargement Optimisé : Le système utilise la bibliothèque wllama pour streamer les poids de manière asynchrone depuis le Système de Fichiers Privé d'Origine (OPFS) directement vers les tampons WebGPU. Il évite de matérialiser les poids dans le tas WebAssembly, qui ne peut que croître et ne peut pas libérer de mémoire pendant la durée de vie d'un onglet.
• Arène de Tampon de Paramètres : Au lieu de maintenir des pools dynamiques de petits tampons pour les paramètres de noyau (une source courante de fragmentation), LlamaWeb alloue un seul tampon statique avec des emplacements configurables, en les faisant tourner pour garantir que les paramètres ne sont pas écrasés avant la fin de l'exécution du noyau.

2. Bibliothèque de Noyaux Portable en Performance

Pour maximiser les performances sur du matériel hétérogène :

• Génération de Shaders Templatisés : Le backend utilise un préprocesseur WGSL personnalisé (pre-wgsl) et une bibliothèque de noyaux qui génère des shaders basés sur les fonctionnalités spécifiques à l'appareil (par exemple, support des sous-groupes) et les types de données.
• Paramètres Ajustables : Des paramètres clés, tels que les tailles de tuiles pour la multiplication de matrices et les tailles de groupes de travail, sont ajustables. Les auteurs ont dérivé des valeurs par défaut « portables en performance » grâce à une étude empirique balayant des milliers de configurations sur quatre GPU de différents fournisseurs.
• Ordonnancement d'Exécution : Le temps d'exécution regroupe efficacement les soumissions de noyaux et minimise la synchronisation CPU-GPU. Il met en cache les pipelines compilés pour éviter les coûts de compilation redondants après le premier passage avant.

3. Conception de Shaders Consciente de la Quantification

Pour prendre en charge les formats de quantification divers de llama.cpp :

• Déquantification Intégrée : Les routines de déquantification sont conçues conjointement avec les noyaux de calcul. Pour la multiplication de matrices, les blocs quantifiés sont chargés, déquantifiés dans la mémoire partagée et réutilisés. Pour la multiplication matrice-vecteur (phase de décodage), la déquantification se produit directement dans les registres pour améliorer les motifs d'accès mémoire.
• Extensibilité : Le système représente les formats de quantification comme des tampons plats d'entiers non signés sur 32 bits, avec une logique de déquantification sélectionnée au moment de la compilation. Cela permet d'intégrer de nouveaux formats (par exemple, le récemment introduit q1_0 pour les modèles 1-bit) en ajoutant une routine de déquantification sans réécrire les implémentations de base des opérations matricielles.

Contributions Clés

1. Un Moteur d'Inférence Efficace en Mémoire : Une implémentation WebGPU qui alloue statiquement la mémoire et optimise le mouvement des données, permettant l'exécution de modèles utiles sur des appareils périphériques à mémoire contrainte sans plantages inattendus.
2. Une Bibliothèque de Shaders Flexible : Une bibliothèque pour l'inférence LLM qui prend en charge le réglage externe, spécialise les shaders en fonction des fonctionnalités matérielles disponibles (par exemple, opérations matricielles de sous-groupes) et utilise un temps d'exécution d'ordonnancement optimisé.
3. Noyaux de Quantification Conçus Conjointement : Un ensemble de noyaux de base (opérations matricielles) conçus pour fonctionner avec les formats de quantification étendus de llama.cpp, permettant le déploiement de modèles optimisés pour différentes tailles et facilitant l'intégration de méthodes de quantification émergentes.

Résultats Expérimentaux

Les auteurs ont évalué LlamaWeb sur 16 appareils de 8 fournisseurs (incluant NVIDIA, AMD, Intel, Apple, Qualcomm, Samsung, ARM et Imagination Technologies) exécutant 10 modèles de langage sur quatre formats de poids.

• Efficacité Mémoire : Comparé à WebLLM et Transformers.js, LlamaWeb a réduit l'utilisation maximale de mémoire du navigateur de 29–33% en moyenne sur diverses combinaisons appareil/navigateur/système d'exploitation. Dans des tests spécifiques (par exemple, Safari sur Apple M4), il a utilisé jusqu'à 59% de mémoire en moins que Transformers.js, qui souffrait de fuites de mémoire dans ces configurations.
• Débit de Décodage : LlamaWeb a augmenté le débit de décodage de 45–69% par rapport à WebLLM et Transformers.js sur quatre GPU de fournisseurs distincts.
• Débit de Préremplissage : Pendant la phase de préremplissage, LlamaWeb a initialement sous-performé par rapport à WebLLM (de 21–51%) et Transformers.js. Les auteurs attribuent cela à l'utilisation par WebLLM de la fusion de noyaux de TVM et aux implémentations optimisées pour les sous-groupes de Transformers.js. Cependant, lors de l'exécution de LlamaWeb nativement (en dehors du navigateur) avec les contrôles de sécurité désactivés, il surpassait les autres frameworks, suggérant que les contrôles de sécurité spécifiques au navigateur et l'absence de support stable des matrices de sous-groupes dans les navigateurs sont les principaux goulots d'étranglement.
• Performance Native vs Navigateur : Sur certains appareils (par exemple, Intel Arc B580), le backend WebGPU de LlamaWeb était compétitif, voire plus rapide, que les backends natifs (par exemple, SYCL) pour des tâches spécifiques. Cependant, les backends natifs (CUDA, Metal) surpassaient généralement WebGPU jusqu'à 10 fois en préremplissage et 2,5 fois en décodage, principalement en raison d'une meilleure utilisation des fonctionnalités spécifiques au fournisseur comme les cœurs tensoriels et les chargements de mémoire asynchrones.
• Impact de la Quantification : L'étude a révélé que, bien que la quantification réduise les besoins en mémoire, elle n'améliore pas toujours linéairement les performances en raison du coût computationnel de la déquantification. Par exemple, passer de q8_0 à q4_k_m améliorait le débit, mais passer à q2_k le diminuait sur les clusters de milieu de gamme.

Importance et Revendications

L'article revendique que LlamaWeb représente une étape significative vers la rendre l'inférence LLM basée sur le navigateur accessible, privée et performante. En s'intégrant à l'écosystème llama.cpp, il prend en charge une vaste bibliothèque de modèles (177 691 modèles compatibles au format GGUF) que les autres frameworks de navigateur ne peuvent égaler.

Les auteurs soulignent que leur travail démontre que la portabilité en performance est réalisable dans le navigateur grâce à un réglage minutieux des noyaux et à une planification statique de la mémoire. Bien qu'ils reconnaissent que les backends natifs détiennent actuellement un avantage en performance, LlamaWeb fournit une alternative cross-plateforme compétitive qui évite la nécessité d'installations natives spécifiques à la plateforme. Le travail met également en évidence la nécessité d'améliorations supplémentaires dans les spécifications WebGPU, telles qu'un meilleur support pour les types d'entiers plus petits et la suppression des contrôles de sécurité au moment de l'exécution qui entravent les performances, pour réaliser pleinement le potentiel de l'IA basée sur le navigateur.

Le code est open-source et a été intégré au codebase de llama.cpp via plus de 100 demandes de tirage (pull requests), prenant en charge 72 opérateurs ML de base et 23 formats de données.