WebLLM : faire tourner un LLM dans l'onglet du navigateur, sans serveur

Le problème : servir un modèle sans serveur

Faire tourner un LLM implique classiquement une infra côté serveur : GPU loués, API à maintenir, requêtes utilisateur qui transitent par une machine tierce. WebLLM prend le problème par l'autre bout. Le README décrit un moteur d'inférence qui s'exécute entièrement dans le navigateur, accéléré par WebGPU, sans support serveur. Le cas d'usage visé est donc double : supprimer la facture d'infrastructure et garder les données de l'utilisateur sur sa machine. Le projet se présente comme un compagnon de MLC LLM, lequel cible le déploiement universel de LLM sur différents matériels. Là où MLC LLM compile des modèles pour des environnements variés, WebLLM restreint volontairement la cible au navigateur et à WebGPU. C'est une contrainte, pas un détail : elle élimine d'emblée les navigateurs sans cette API. Le public visé est donc l'ingénieur front ou TypeScript qui veut embarquer un assistant, un classificateur ou un générateur de JSON dans une page, sans monter de backend.

WebGPU comme unique porte d'entrée matérielle

Le mécanisme central tient en une phrase du README : tout s'exécute dans le navigateur, accéléré par WebGPU. Concrètement, le moteur charge des poids de modèle au format MLC et les exécute sur le GPU de la machine de l'utilisateur. Le README précise que la génération JSON structurée est implémentée dans la partie WebAssembly de la bibliothèque de modèles, ce qui indique une architecture hybride : une couche WebAssembly pour certaines opérations, WebGPU pour l'accélération. Cette dépendance à WebGPU est le point de rupture principal. Un utilisateur dont le navigateur ou le pilote graphique n'expose pas WebGPU ne peut pas exécuter le moteur, quelle que soit la qualité de votre code applicatif. Le README ne fournit pas de chemin de repli documenté vers un autre backend. C'est un choix de conception assumé : viser la performance matérielle plutôt que la couverture. Pour un outil interne déployé sur un parc maîtrisé, c'est tenable. Pour un site public, cela revient à conditionner l'accès à une fonctionnalité à une API navigateur dont la disponibilité varie selon les plateformes.

Une API calquée sur OpenAI, avec des trous

Le projet revendique une compatibilité complète avec l'API OpenAI, ce qui permet de réutiliser le même code client sur des modèles open source exécutés localement. Le README liste le streaming, le JSON-mode, le function-calling et le seeding parmi les fonctionnalités concernées. Un détail mérite attention : le function-calling est explicitement annoté WIP dans la liste des fonctionnalités. La promesse de compatibilité totale est donc à nuancer. Le streaming, en revanche, est présenté comme un support de premier plan, avec des complétions de chat en temps réel pour les interfaces conversationnelles. La génération JSON structurée est mise en avant comme implémentée dans la couche WebAssembly pour la performance, avec un playground HuggingFace cité comme démonstration. Autrement dit, si votre application repose sur des sorties contraintes par schéma, cette partie est traitée sérieusement. Si elle repose sur l'appel d'outils, il faut considérer la fonctionnalité comme non finalisée et prévoir un plan B.

Installation et premiers appels

L'installation passe par les gestionnaires de paquets habituels. Le README donne les trois commandes : npm install @mlc-ai/web-llm, yarn add @mlc-ai/web-llm et pnpm install @mlc-ai/web-llm. L'import se fait ensuite soit en bloc avec import * as webllm from "@mlc-ai/web-llm", soit de façon ciblée avec import { CreateMLCEngine } from "@mlc-ai/web-llm". Une alternative CDN existe via esm.run, avec import * as webllm from "https://esm.run/@mlc-ai/web-llm", ou en import dynamique avec await import. Ce second chemin est présenté comme fonctionnant sur des plateformes de développement en ligne comme jsfiddle.net, Codepen.io et Scribbler. Le point d'entrée de l'API est l'interface MLCEngine : on crée une instance et on charge le modèle via CreateMLCEngine. Le README indique aussi que le support des Web Workers et Service Workers sert à déporter les calculs hors du thread principal, ce qui compte pour ne pas figer l'interface pendant l'inférence. La liste des modèles disponibles se trouve dans prebuiltAppConfig.model_list, référencé dans src/config.ts.

Modèles pris en charge et modèles personnalisés

Le catalogue intégré couvre plusieurs familles : Llama (Llama 3, Llama 2, Hermes-2-Pro-Llama-3), Phi (3, 2, 1.5), Gemma-2B, Mistral (7B-v0.3 et plusieurs variantes Hermes ou OpenHermes) et Qwen (0.5B, 1.5B, 7B). Le README précise qu'il s'agit d'un sous-ensemble des modèles listés sur mlc.ai/models, et que la liste exacte est accessible via prebuiltAppConfig.model_list. Pour aller au-delà, deux voies : ouvrir une issue pour demander un modèle, ou compiler le sien au format MLC et l'intégrer comme modèle personnalisé. Cette seconde voie est la plus intéressante sur le plan technique, mais elle suppose une étape de compilation hors du périmètre de la bibliothèque TypeScript. Le README ne détaille pas ce processus dans l'extrait disponible. Il faut donc le traiter comme une piste à explorer dans la documentation, pas comme une opération triviale.

Ce que le projet ne résout pas

La limite la plus concrète est physique : un modèle doit tenir dans la mémoire GPU de l'appareil, et ses poids doivent être téléchargés par l'utilisateur. Le README ne donne aucune indication sur la taille des fichiers ni sur la gestion du cache au-delà de la mention des Service Workers pour le cycle de vie des modèles. Un utilisateur sur une connexion lente ou un appareil modeste paiera ce coût au premier chargement. Deuxième limite : l'absence de repli hors WebGPU, déjà évoquée, exclut une partie du parc. Troisième limite : la compatibilité OpenAI est incomplète, le function-calling étant en chantier. Enfin, la qualité des sorties dépend entièrement du modèle choisi, et les modèles listés incluent des variantes de petite taille comme Qwen2 0.5B ou Gemma-2B, dont les capacités de raisonnement sont limitées par construction. WebLLM est le mauvais outil si votre cas d'usage exige un modèle de grande taille, un appel d'outils fiable, ou une compatibilité navigateur large.

Face à un backend d'inférence classique

L'alternative évidente est un serveur d'inférence, qu'il soit auto-hébergé ou consommé via une API distante. La différence n'est pas une question de vitesse, mais de lieu d'exécution. Un backend centralise le modèle, ce qui permet d'utiliser une version plus grande que ne le supporterait n'importe quel appareil client, et de mettre à jour les poids sans rien redéployer chez l'utilisateur. WebLLM inverse ce compromis : la mise à jour du modèle implique un nouveau téléchargement côté client, mais aucune donnée ne quitte la machine et la facture GPU disparaît. Pour une application où les entrées contiennent des données personnelles ou médicales, cet échange est souvent décisif. Pour une application qui doit servir un modèle de 70B à tous, il ne l'est pas. Le choix se fait donc sur la nature des données et sur la puissance minimale du parc client, pas sur des chiffres de débit que le README ne fournit pas.

Maintenance, versions et licence

Le dépôt n'est pas archivé et les versions récentes s'enchaînent : v0.2.85 en septembre 2026, v0.2.83 en avril 2026, v0.2.82 en mars 2026. Le rythme observé sur ces trois publications est irrégulier, avec un écart de plusieurs mois entre certaines d'entre elles. La numérotation reste en 0.2.x, ce qui suggère une API encore en évolution mineure. La licence est Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de copyright et du fichier de licence. Elle inclut une clause de brevets. Rien dans le matériel fourni n'indique de coût de licence supplémentaire ni de restriction d'usage. La charge de maintenance réelle se situe ailleurs : suivre les évolutions de WebGPU dans les navigateurs, et recompiler les modèles personnalisés lorsque le format MLC change. Ce dernier point est le coût caché du projet pour quiconque sort du catalogue prebuiltAppConfig.model_list.

Conclusion éditoriale

Adoptez WebLLM si vous livrez une application web où la confidentialité des requêtes compte plus que la taille du modèle, et si votre public utilise un navigateur avec WebGPU. Évitez-le si vous avez besoin de modèles dépassant la mémoire GPU de l'appareil ou d'une parité complète avec l'API OpenAI, le function-calling étant encore marqué WIP dans le README. Avant d'intégrer, vérifiez deux choses concrètes : la présence de votre modèle cible dans prebuiltAppConfig.model_list, et le comportement de CreateMLCEngine sur les navigateurs de vos utilisateurs, car le chargement des poids se fait depuis le réseau à chaque nouvelle session.

Sources officielles

1. License: Apache-2.0
2. mlc-ai/web-llm on GitHub
3. Project website
4. README
5. Releases