Brimkern
WebGPU · WGSL écrit à la main · rien ne sort de l’onglet

N’importe quel modèle du Hub.
Exécuté dans votre navigateur.

Brimkern lit les GGUF mono-fichier directement depuis Hugging Face et les exécute sur votre propre GPU — sans conversion, sans étape de compilation, sans serveur, sans clé d’API. Les poids arrivent une fois, restent chez vous, et fonctionnent hors-ligne ensuite.

Essayer maintenant — 149 MoLire la doc

Chrome, Edge, ou Safari 18+. Gratuit, open source (MIT), sans compte.

collez un modèle — le Hub en héberge des dizaines de milliers
Testez n’importe quel modèle de Hugging Face
GGUF mono-fichier et .brik, directement depuis le Hub. Rien à régler : la meilleure quantification est choisie, et le tokenizer suit le fichier. Rien ne sort de votre navigateur.
Exemples :
Le chat Brimkern : un Qwen 2.5 0.5B répond à une question sur WebGPU, avec ses mesures en dessous — 460 tokens/s de prefill, 47,5 tokens/s de décodage.
Une vraie session, sur le GPU d’un portable. Chaque réponse porte ses mesures — rien ici n’est estimé.
pourquoi ça existe

Trois choses qu’on ne trouve pas ensemble ailleurs

aucune compilation

Le format que le Hub héberge déjà

Collez auteur/modèle et ça tourne. La meilleure quantification est choisie pour vous, le tokenizer vient du fichier. Les autres moteurs navigateur exigent des poids pré-compilés dans leur propre format avant de pouvoir y toucher.

des kernels écrits à la main

WGSL, validé au chargement

Le forward pass est fait de compute shaders écrits à la main — matmuls quantifiés fusionnés, cache KV résident, une seule bibliothèque de kernels pour le texte, la vision, l’image et la vidéo. Chacun se valide contre une référence CPU au chargement, et retombe sur un chemin plus simple si un GPU compile mal.

streamé, pas téléchargé

.brik : une couche = une plage HTTP

Notre conteneur range les poids déjà quantifiés dans la disposition exacte que lisent les kernels, une couche par plage contiguë. Un modèle de 4,7 Go revient du cache en 15,8 s — reprise possible, partielle, vraiment hors-ligne ensuite.

Ce que ça donne face à WebLLM, mesuré

ce qui se passe vraiment

D’un nom de dépôt à des tokens sur votre GPU

  1. 01
    Vous collez author/model

    Un identifiant, une URL du Hub, ou un lien direct.

  2. 02
    On résout le meilleur fichier

    L’API du Hub liste le dépôt ; la meilleure quantification gagne (un .brik devant un GGUF).

  3. 03
    Ça streame une couche = une plage

    Seulement les octets de la couche en cours, reprise possible, gardés sur votre appareil.

  4. 04
    Ça tourne sur votre GPU

    Des kernels WGSL écrits à la main. Rien ne repart — il n’y a aucun serveur où l’envoyer.

149 MB
plus petit modèle de chat, mis en cache une fois
47.2 tok/s
prefill sur un 7B int4 (WebLLM : 18,7)
15.8 s
pour recharger 4,7 Go depuis le cache
0
serveur, compte, clé d’API
pour votre produit

Une balise script, un assistant qui ne coûte rien à faire tourner

Le calcul, c’est le GPU de votre visiteur : aucune facture d’inférence, aucune limite de débit, aucune donnée qui quitte son navigateur. Le modèle ne se télécharge que si quelqu’un ouvre le widget : votre vitesse de page reste intacte.

Page SDK & démo live 
<script src="https://brimkern.com/sdk.js"></script>
<script>
  Brimkern.embed({
    system: "Tu réponds aux questions sur ma boutique.",
  });
</script>
aussi dans la boîte

Un moteur, quatre modalités

  • Chat — multi-tours, modèles à raisonnement, français & anglais, sur un cache KV résident en GPU.
  • Vision — joignez une image et posez vos questions (Qwen2-VL, sur ordinateur).
  • Images — texte vers image dans l’onglet (SD-Turbo / SDXS sur une pile de diffusion WebGPU).
  • Vidéo (bêta) — de courts clips animés depuis un prompt, sur les mêmes kernels.