BrowserAI : exécuter des LLM locaux dans le navigateur, sans serveur

Le problème : inférer sans faire sortir la requête du poste

Le README énonce l'objectif sans détour : « 100% Private: All processing happens locally in your browser ». La formulation est commerciale, mais le mécanisme sous-jacent est réel. Si le modèle s'exécute dans la page, le texte soumis par l'utilisateur n'a pas besoin de traverser le réseau, et il n'y a pas de facture GPU côté serveur. Le projet cible explicitement les développeurs web qui veulent ajouter de la génération de texte, de la transcription ou de la synthèse vocale à une interface existante, ainsi que les plateformes no-code, comme l'indique le renvoi vers Browseragent.dev. Ce n'est donc pas un outil de recherche sur les performances d'inférence : c'est une couche d'intégration. La question pertinente n'est pas de savoir si un navigateur peut faire tourner un LLM, mais si l'API proposée tient ses promesses sur les cas d'usage réels d'une application web.

Une façade unique posée sur quatre moteurs distincts

L'architecture visible dans le README repose sur une classe BrowserAI qui expose loadModel puis generateText, tandis que les moteurs sous-jacents diffèrent nettement. Le chemin MLC charge des modèles convertis et quantifiés, avec l'exemple llama-3.2-1b-instruct en quantization q4f16_1. Le chemin Transformers couvre Whisper pour la reconnaissance vocale et Kokoro pour la synthèse. Le chemin Flare exécute des fichiers GGUF via WASM, avec un loadAdapter séparé pour appliquer un adaptateur LoRA au format safetensors. Demucs est importé à part, depuis @browserai/browserai/demucs, et renvoie quatre pistes : drums, bass, other, vocals. Cette séparation est cohérente : Demucs ne partage pas la même sémantique de sortie que la génération de texte. Le README annonce une commutation « seamless » entre moteurs, mais les exemples montrent surtout que l'appel generateText reste stable alors que les modèles et les formats de poids changent. C'est déjà beaucoup, et c'est plus honnête que de prétendre à une abstraction totale.

Mise en route : le modèle se télécharge au premier chargement

L'installation se fait par npm install @browserai/browserai ou yarn add @browserai/browserai. Le premier appel utile est loadModel avec une fonction onProgress, ce qui laisse entendre que les poids sont récupérés depuis le réseau au moment du chargement et non embarqués dans le bundle. Le README ne précise ni la taille des fichiers ni l'origine exacte des téléchargements, et c'est un manque : sur une application réelle, c'est la première chose qu'un développeur veut mesurer. La génération accepte soit une chaîne, soit un tableau de messages au format role/content, avec system_prompt, temperature et max_tokens. La sortie structurée passe par json_schema et response_format avec type json_object. Deux points méritent l'attention. D'abord, les clés sont en snake_case dans les options alors que l'API JavaScript environnante est en camelCase : max_tokens, system_prompt, json_schema, return_timestamps, c'est un détail qui provoquera des erreurs silencieuses chez ceux qui ne lisent pas les exemples. Ensuite, pour la synthèse vocale, textToSpeech renvoie un audioBuffer qu'il faut décoder soi-même via AudioContext, comme le montre l'exemple. Le SDK ne joue pas le son à votre place.

Ce que le navigateur ne peut pas absorber

La liste des modèles MLC va de SmolLM2-135M à DeepSeek-R1-Distill-Llama-8B, et cette amplitude mérite d'être lue avec prudence. Un modèle de 8 milliards de paramètres en quantification 4 bits représente plusieurs gigaoctets à télécharger et à conserver côté client, avant même de parler de vitesse d'inférence. Le README ne fournit aucune mesure de temps de chargement, de débit de tokens ni de consommation mémoire par modèle, et je ne peux donc affirmer aucune performance. Ce qui est certain, c'est que le coût se déplace du serveur vers l'utilisateur : bande passante, RAM, batterie, et temps d'attente au premier lancement. Un autre point de friction est absent de la documentation : la disponibilité de WebGPU. Le README en fait un argument central sans décrire de comportement de repli lorsque l'API n'est pas exposée par le navigateur. Si votre audience inclut des navigateurs anciens ou des environnements où WebGPU est désactivé, vous ne saurez pas depuis ce document ce qui se passe. C'est le principal angle mort du projet.

Face à Transformers.js seul

L'alternative la plus directe est d'utiliser directement Transformers.js, la bibliothèque de Hugging Face qui exécute des modèles ONNX dans le navigateur. La différence d'approche est nette. Transformers.js vous laisse choisir et convertir vous-même vos modèles, avec un écosystème large et une correspondance étroite avec les dépôts Hugging Face. BrowserAI prend le parti inverse : il fige une liste de modèles pré-configurés, répartis par moteur, et vous donne une API unique par-dessus. Le README assume ce choix avec la mention « Pre-optimized popular models » et invite à ouvrir une issue pour demander un modèle manquant. Le compromis est classique : moins de flexibilité, moins de configuration à écrire. Si votre modèle n'est pas dans la liste, BrowserAI ne vous aide pas ; si votre modèle y est, vous évitez la chaîne de conversion et le choix de quantification. Le chemin Flare complique un peu la comparaison, puisqu'il accepte des GGUF, un format que Transformers.js ne prend pas en charge nativement.

Maintenance, versions et licence

Le dépôt n'est pas archivé et le dernier push est daté du 21 juillet 2026. La cadence des versions est irrégulière : v2.0.2 en avril 2025, v2.0.4 en mai 2025, puis v2.2.0 en avril 2026. Il y a donc eu environ onze mois entre v2.0.4 et v2.2.0, ce qui suggère un projet mené par une petite équipe plutôt qu'un cycle de publication soutenu. Concrètement, cela signifie que le coût de mise à jour se concentre sur les changements de version majeure, où l'API peut bouger, et que les correctifs intermédiaires sont espacés. Le SDK est publié sous MIT, ce qui autorise l'usage commercial et la modification. Attention toutefois : la licence MIT couvre le code du SDK, pas les poids des modèles téléchargés. Chaque modèle listé (Llama, Gemma, Qwen, DeepSeek, Whisper, Kokoro, HTDemucs) possède ses propres conditions d'utilisation, et certaines sont restrictives. Le README ne traite pas ce point. C'est à vous de vérifier la licence de chaque poids avant une mise en production, et je ne fournis ici aucun avis juridique.

Conclusion éditoriale

BrowserAI convient aux équipes qui construisent une application web où la requête ne doit pas quitter le poste de l'utilisateur, et qui acceptent de plafonner la taille du modèle à ce qu'un navigateur peut charger. Il ne convient pas si votre catalogue de modèles dépasse quelques milliards de paramètres, ni si vous devez servir des utilisateurs sans WebGPU. Avant d'adopter, vérifiez deux choses dans le dépôt : la licence exacte des poids que vous comptez distribuer, distincte du MIT du SDK, et le comportement de loadModel lorsque l'utilisateur ferme l'onglet pendant le téléchargement.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. sauravpanda/BrowserAI on GitHub