Documentation

Démarrer

Ouvrez l'application et cliquez sur l'unique bouton de l'accueil. Le modèle arrive en streaming une fois (149 Mo pour celui par défaut), est mis en cache sur votre appareil, et chaque visite suivante démarre en quelques secondes — hors-ligne compris. Rien n'est jamais envoyé : les poids descendent chez vous et le calcul se fait sur votre GPU.

Prérequis : un navigateur avec WebGPU (Chrome, Edge, ou Safari 18+). Un GPU dédié aide au-delà de 1 Md de paramètres, mais un portable fait tourner les petits modèles confortablement.

N'importe quel modèle Hugging Face

Brimkern lit directement les GGUF mono-fichier — le format que le Hub héberge déjà, sans étape de conversion ni de compilation. Collez n'importe laquelle de ces formes dans le champ de l'accueil (ou du navigateur de modèles) :

Qwen/Qwen3-0.6B-GGUF
https://huggingface.co/Qwen/Qwen3-0.6B-GGUF
https://huggingface.co/Qwen/Qwen3-0.6B-GGUF/blob/main/Qwen3-0.6B-Q8_0.gguf
https://example.com/my-model.gguf

La meilleure quantification est choisie pour vous (Q4_K_M d'abord, puis Q4_K_S, Q5, Q8…), et le tokenizer suit le fichier — rien à régler. Les GGUF shardés (-00001-of-0000N) et les projecteurs vision (mmproj) sont refusés avec un message explicite plutôt que chargés à moitié.

Liens de test instantané

N'importe quel modèle peut devenir un lien qui le charge directement — pratique pour partager une démo, joindre un rapport de bug, ou renvoyer un collègue vers une quantification précise.

https://brimkern.com/chat?model=Qwen/Qwen3-0.6B-GGUF
https://brimkern.com/chat?model=Qwen/Qwen3-0.6B-GGUF&file=Qwen3-0.6B-Q8_0.gguf
https://brimkern.com/chat?gguf=https://example.com/model.gguf
https://brimkern.com/chat?brik=https://example.com/model.brik

?model= interroge l'API du Hub et choisit le meilleur fichier chargeable (un .brik gagne sur un GGUF). ?file= force une quantification précise. ?gguf= et ?brik= prennent une URL directe, pour les modèles que vous hébergez vous-même.

Le format .brik & le convertisseur

Un .brik est un GGUF ré-empaqueté pour le navigateur : poids déjà quantifiés en int4/int8, disposés pour qu'une couche soit une seule plage HTTP contiguë, tokenizer embarqué. Effet concret : le modèle se charge par plages (reprise possible, partiellement, vraiment hors-ligne ensuite) au lieu d'un téléchargement de plusieurs gigaoctets.

Vous pouvez convertir un GGUF vous-même, dans le navigateur — le fichier ne quitte jamais votre machine : ouvrir le convertisseur.

SDK embarquable

Une balise script pose un assistant local sur votre site. Il tourne sur le GPU de votre visiteur : aucun serveur, aucun coût par token, rien n'est envoyé où que ce soit.

<script src="https://brimkern.com/sdk.js"></script>
<script>
  Brimkern.embed({
    system: "You are the assistant of the Ferblanc store.",
    title: "Ask us anything",
    // Vos contenus. Découpés en passages, puis seuls les 1 à 3 passages proches de la
    // question posée sont donnés au modèle. Le tri est LOCAL (lexical) : rien ne part.
    knowledge: [
      { title: "Opening hours", text: "Open Tuesday to Saturday, 10am to 7pm." },
      { title: "Shipping", text: "Free in France from 60 euros. Switzerland: flat 8 euros." },
    ],
  });
</script>

Le modèle ne se télécharge que lorsqu'un visiteur ouvre réellement le widget : votre vitesse de page reste intacte. Les documents de connaissance restent sur la page : ils sont découpés et classés dans le navigateur, et seuls les passages qui correspondent à la question atteignent le modèle. Page SDK complète et démo live.

C’est aussi un paquet — types inclus, et l’importer côté serveur ne fait rien (Next, Remix, Astro passent sans risque) :

npm i brimkern

import { embed, createSession } from 'brimkern';

Épinglez une version si vous préférez que le widget ne change pas sous vos pieds : https://brimkern.com/sdk-0.1.0.js au lieu de https://brimkern.com/sdk.js.

Stockage & hors-ligne

Les poids vivent dans le cache du navigateur, par site. C'est le navigateur qui décide de l'espace accordé — souvent des dizaines de gigaoctets sur un profil normal, mais ~1,5 Go seulement en navigation privée, où un gros modèle ne pourra pas rester en cache. Le navigateur de modèles vous avertit avant un téléchargement qui ne tiendra pas.

Les modèles inutilisés depuis 30 jours sont nettoyés automatiquement (réglable, ou désactivable, dans le panneau Stockage). Les conversations et les .brik convertis en local ne sont jamais touchés.

Diagnostics

Chaque chemin de code risqué a un commutateur d'URL qui revient à la version plus lente et plus simple. Pratique pour vérifier si une optimisation est responsable d'un comportement bizarre — la réponse doit être identique, seulement plus lente.

?gemv=0        matmul de décodage → kernels par lignes
?f16shared=0   GEMM f16 du prefill → une ligne par thread
?qshared=0     GEMM q4/q8 du prefill → 4 lignes par invocation
?warmup=0      pas de préchauffe (le 1er message la paye)
?ggufstream=0  GGUF en un seul téléchargement au lieu de plages
?kvq=0         cache KV en f32 au lieu de int8
?timing=1      chronométrage du forward par étape, dans la console

Comparé à WebLLM

Si vous connaissez déjà WebLLM — l’autre moteur WebGPU qui exécute un grand modèle de langage côté client — les deux diffèrent sur un point décisif : ce qu’il faut faire subir à un modèle avant qu’il tourne. Nous lisons les GGUF mono-fichier directement depuis Hugging Face ; WebLLM exige des poids compilés avec MLC/TVM. la comparaison mesurée met les deux débits côte à côte sur le même GPU et le même modèle — y compris là où WebLLM est devant.

Changelog

Ce qui a changé, version par version, avec les mesures derrière chaque affirmation : lire le changelog.