WebLLM : comment exécuter un LLM directement dans le navigateur, sans serveur

Pourquoi WebLLM attire l’attention

WebLLM se présente comme un moteur d’inférence de LLM haute performance exécuté directement dans le navigateur. Le point clé est simple : l’inférence se fait côté client, avec accélération matérielle, sans support serveur, et en s’appuyant sur WebGPU.

Pour une équipe produit ou une équipe front-end, cela change la manière d’intégrer un modèle de langage dans une application web. Au lieu d’envoyer chaque requête vers une API distante, une partie du traitement peut être déplacée dans l’environnement du navigateur lui-même. Cela peut intéresser les cas d’usage où l’on veut réduire la dépendance à une infrastructure backend pour l’inférence, ou améliorer l’expérience hors ligne quand le modèle a déjà été chargé.

Le projet met aussi en avant une compatibilité avec l’API d’OpenAI. En pratique, l’objectif est de permettre aux développeurs de réutiliser un style d’intégration déjà familier, mais avec des modèles open source exécutés localement dans le navigateur.

Une API pensée pour limiter la friction d’intégration

WebLLM expose des interfaces de type OpenAI pour les conversations. Après initialisation du moteur, les complétions de chat passent par engine.chat.completions. Le streaming est activé en passant stream: true à l’appel de création.

Le projet indique aussi la prise en charge de plusieurs fonctions associées à cette compatibilité : streaming, mode JSON, contrôle au niveau des logits et seeding. Le function calling est mentionné comme un travail en cours.

Un détail important pour les intégrateurs : dans les chat completions, le paramètre model n’est pas pris en charge et sera ignoré. Autrement dit, le choix du modèle se fait ailleurs dans le cycle d’initialisation du moteur, et non au moment de chaque appel comme dans certaines API distantes.

Pour les applications qui produisent des sorties structurées, WebLLM indique que sa génération JSON structurée est implémentée dans la partie WebAssembly de la bibliothèque de modèles, avec un objectif de performance. C’est un point utile pour les développeurs qui veulent brancher un LLM sur des flux applicatifs nécessitant des réponses formalisées plutôt qu’un simple texte libre.

Quels modèles et quels formats sont pris en charge

WebLLM annonce un support natif de plusieurs familles de modèles, notamment Llama 3, Phi 3, Gemma, Mistral et Qwen. La documentation cite aussi un exemple concret de modèle sélectionné pour CreateMLCEngine : Llama-3.1-8B-Instruct-q4f32_1-MLC.

Le projet ne se limite pas aux modèles intégrés. Il prend également en charge des modèles personnalisés au format MLC, avec des paramètres model et model_lib personnalisables. Pour les équipes qui veulent contrôler précisément leur pile de modèles, c’est un élément important : WebLLM n’est pas seulement une vitrine de modèles prédéfinis, mais aussi un runtime capable d’accueillir des artefacts adaptés à un besoin spécifique.

Sur le plan technique, la documentation précise que le runtime dépend largement de TVMjs. Elle mentionne aussi le paquet npm @mlc-ai/web-runtime, avec une référence à la version 0.18.0-dev2 dans un exemple de package.json. Pour les builds depuis les sources, le README recommande d’utiliser emsdk en version 3.1.56 comme solution de contournement au lieu de la dernière version de emcc. Un autre exemple de version, 0.2.52, est cité pour illustrer la construction d’une version npm spécifique depuis les sources.

Workers, extensions et expérience hors ligne

WebLLM prend en charge les Web Worker et les Service Worker. Ce choix d’architecture est important, car l’inférence d’un LLM dans le navigateur peut être coûteuse pour le thread principal. La documentation propose un support dédié côté worker avec WebWorkerMLCEngineHandler.

Le support des workers sert d’abord à préserver la réactivité de l’interface en déportant les calculs. Il s’aligne aussi avec les capacités des API de stockage du navigateur : selon MDN, l’interface Cache est disponible dans les Web Workers, tout comme IndexedDB.

Le support des Service Worker vise un autre objectif : éviter de recharger le modèle à chaque visite de page et améliorer l’expérience hors ligne. Il faut toutefois garder en tête une contrainte structurelle rappelée par la documentation : le cycle de vie d’un service worker est géré par le navigateur, qui peut l’arrêter à tout moment sans prévenir l’application web. Cela en fait un bon outil d’optimisation, mais pas un composant dont la disponibilité continue peut être supposée.

WebLLM mentionne aussi un support pour les extensions Chrome, avec des exemples pour des extensions simples ou avancées. Cela ouvre des scénarios où le modèle local devient une brique d’assistance directement intégrée au navigateur.

Le vrai sujet pratique : le cache des artefacts de modèle

Pour un LLM exécuté dans le navigateur, la stratégie de cache est centrale. WebLLM documente quatre backends via AppConfig.cacheBackend : cache, indexeddb, opfs et cross-origin.

Le backend par défaut est cache, c’est-à-dire la Cache API du navigateur. D’après MDN, cette interface est disponible à travers les navigateurs depuis avril 2018, en contexte sécurisé HTTPS, et fournit un mécanisme de stockage persistant de paires Request/Response en mémoire de longue durée. MDN précise aussi que les éléments d’un cache ne sont pas mis à jour automatiquement, n’expirent pas tant qu’ils ne sont pas supprimés, et que l’API ne respecte pas les en-têtes HTTP de cache. Pour un développeur, cela signifie qu’il faut penser explicitement la politique de rafraîchissement et d’invalidation des artefacts téléchargés.

Autre option : indexeddb. MDN décrit IndexedDB comme une API bas niveau pour stocker côté client de grandes quantités de données structurées, y compris des fichiers et des blobs. Elle est également disponible dans les Web Workers. Ce backend peut être pertinent quand l’application veut un contrôle plus fin sur le stockage local.

WebLLM propose aussi opfs, pour Origin Private File System. La contrepartie est claire dans la documentation : si ce backend est sélectionné dans un environnement qui ne prend pas OPFS en charge, les opérations de cache échouent avec une erreur de disponibilité OPFS. Il faut donc prévoir une détection ou une stratégie de repli.

Enfin, le backend cross-origin est présenté comme expérimental et lié à une extension Chrome de l’API Cross-Origin Storage. Il nécessite l’installation et l’activation d’une extension compatible. La documentation ajoute une limite opérationnelle : la suppression programmatique du cache de tenseurs n’est pas prise en charge actuellement, l’effacement étant géré par l’extension elle-même.

Intégrité des artefacts : utile, mais optionnelle

WebLLM prend en charge une vérification optionnelle de l’intégrité des artefacts de modèle via des hachages SRI. Lorsqu’un champ d’intégrité est défini sur un ModelRecord, le moteur vérifie les fichiers téléchargés de configuration, de WASM et de tokenizer avant chargement.

En cas de non-correspondance de hachage, le comportement par défaut est de lever une IntegrityError. La documentation indique aussi une alternative : si onFailure est réglé sur warn, un avertissement est journalisé à la place. À l’inverse, si le champ d’intégrité est omis, WebLLM conserve son comportement habituel et n’effectue aucune vérification.

Pour des équipes qui distribuent des modèles ou des bibliothèques à travers le web, cette option peut aider à mieux contrôler la chaîne de chargement des artefacts. Elle ne remplace pas une stratégie globale de sécurité, mais elle ajoute un garde-fou concret au moment du téléchargement et de l’initialisation.

Ce que cela change réellement pour les développeurs

WebLLM se situe à l’intersection du front-end avancé, du runtime navigateur et de l’IA embarquée côté client. Son intérêt principal n’est pas seulement de faire tourner un LLM dans un onglet, mais de proposer une intégration relativement familière pour les développeurs déjà habitués aux API de type OpenAI.

En contrepartie, l’approche impose de raisonner comme un développeur web système : choix du backend de cache, comportement des workers, contraintes des contextes sécurisés, disponibilité de WebGPU, gestion du cycle de vie des service workers, et éventuellement vérification d’intégrité des artefacts.

Autrement dit, WebLLM simplifie l’accès à l’inférence locale dans le navigateur, mais ne supprime pas les arbitrages d’architecture. Les équipes qui y verront le plus d’intérêt sont probablement celles qui veulent rapprocher l’IA de l’utilisateur final, réduire la dépendance à un serveur d’inférence pour certains usages, ou construire des expériences web et extension plus autonomes.

La promesse est donc moins celle d’un remplacement universel des API hébergées que celle d’un nouveau point d’équilibre : davantage de traitement local, avec les avantages et les contraintes propres à la plateforme web.

À retenir

• WebLLM exécute l’inférence de modèles de langage directement dans le navigateur avec accélération via WebGPU, sans support serveur.
• Le projet expose une compatibilité avec l’API OpenAI, avec streaming, mode JSON, contrôle des logits et seeding ; le function calling est encore en cours.
• Les familles de modèles prises en charge incluent Llama, Phi, Gemma, Mistral et Qwen, avec support de modèles personnalisés au format MLC.
• Le choix du backend de cache est structurant : Cache API par défaut, IndexedDB, OPFS ou backend cross-origin expérimental via extension.
• La vérification d’intégrité par hachages SRI est optionnelle mais permet de contrôler les artefacts téléchargés avant chargement.

Publié par : Diaa Al Hariri

Sources

• GitHub – mlc-ai/web-llm: High-performance In-browser LLM Inference Engine — github.com
• Cache – Web APIs | MDN — developer.mozilla.org, 23 mai 2025
• IndexedDB API – Web APIs | MDN — developer.mozilla.org, 3 avril 2025