Brimkern vs WebLLM : deux façons de faire tourner un LLM dans le navigateur
Les deux exécutent un grand modèle de langage côté client sur WebGPU, sans serveur ni clé d’API. Ils diffèrent sur un point décisif : ce qu’il faut faire subir à un modèle avant qu’il tourne.
Les chiffres ci-dessous ont été mesurés entre le 13 et le 15 août 2026, même GPU de portable, même modèle (DeepSeek-R1-Distill-Qwen-7B, int4), même prompt. Rien ici n’est estimé — et ce modèle est dans le catalogue, vous pouvez donc le lancer vous-même.
Mesuré, côte à côte
| Quoi | Brimkern | WebLLM |
|---|---|---|
| Prefill (lecture du prompt)Même modèle 7B int4, même GPU de portable. Nos matmuls WGSL tuilés tiennent ~1 TFLOP/s sur ces formes. | 47,2 tok/s | 18,7 tok/s |
| Décodage (écriture de la réponse)WebLLM est devant ici, et nous l’écrivons. Le nôtre a été re-mesuré le 15/08/2026 après le passage de la RMSNorm en parallèle par ligne : 8,1 → 10,2 tok/s sur ce modèle exact (deux passages : 9,7 et 10,7). L’écart s’est réduit — 1,37× au lieu de 1,46× — mais c’est toujours un écart, et le combler est le chantier en cours. | 10,2 tok/s | 14,0 tok/s |
| Préparation du modèleC’est la différence structurelle. Nous lisons les GGUF mono-fichier directement depuis Hugging Face ; WebLLM exige des poids pré-compilés dans son propre format. | aucune — collez auteur/modèle | compilation MLC/TVM |
| Rechargement depuis le cache (4,7 Go)Notre conteneur .brik range une couche par plage HTTP contiguë : le rechargement reprend après coupure et fonctionne hors-ligne. | 15,8 s | — |
| Catalogue & maturitéWebLLM a des années d’usage en production, des kernels auto-tunés et une API compatible OpenAI. Pour une liste de modèles choisis qui marchent, c’est le choix le plus sûr aujourd’hui. | plus jeune, moins de presets | large, éprouvé |
| Kernels vérifiés au chargementChaque kernel écrit à la main se valide contre une référence CPU au démarrage du moteur, et retombe sur un chemin plus simple si un GPU le compile mal — une panne réelle sur la variété de GPU qu’on trouve sur le web. Chacun a aussi un commutateur d’URL pour l’isoler. | référence CPU + repli | compilés, donc supposés justes |
La différence qui décide
WebLLM : compiler, puis exécuter
Les poids passent par la chaîne MLC/TVM et en ressortent en artefact WebLLM. Cette étape achète des kernels auto-tunés par architecture — et vous coûte une compilation dès que vous voulez un modèle absent du catalogue.
Brimkern : lire le fichier que le Hub héberge déjà
Collez auteur/modèle et ça tourne : la quantification est choisie pour vous, le tokenizer est reconstruit depuis le fichier lui-même, et les poids arrivent par plages HTTP. Rien à compiler, rien à héberger, rien à régler.
Lequel choisir ?
- Vous voulez essayer un modèle trouvé à l’instant sur Hugging Face, sans étape de build → Brimkern.
- Vous livrez un produit sur une liste de modèles figée et voulez le runtime le plus éprouvé → WebLLM.
- Votre widget reste ouvert sur une longue conversation et la mémoire ne doit pas grimper → Brimkern — le catalogue contient des modèles récurrents (RWKV-7) dont l’état est un bloc fixe d’environ 1 Mo, au lieu d’un cache KV qui grandit à chaque token.
- Vous devez héberger les poids vous-même, sur votre domaine → Brimkern — convertissez un GGUF en .brik dans le navigateur, posez le fichier sur n’importe quel hébergement statique, et il se streame par plages depuis là.
- Vous voulez une API compatible OpenAI clé en main → WebLLM.
WebLLM est un excellent projet, et la raison pour laquelle l’inférence dans le navigateur est prise au sérieux. Cette page compare des choix techniques, pas des équipes. Si un chiffre est faux, dites-le — le harnais de mesure est dans le dépôt.
Brimkern — moteur WebGPU open, conçu par Romain Khanoyan. IA locale, WebGPU, moteurs on-device.