← Retour à l'application

Brimkern · Changelog

Inférence LLM accélérée par WebGPU, 100 % dans votre navigateur.

22 juillet 2026

Brimkern passe open source (MIT) — et devient embarquable : une balise <script> suffit pour poser une IA locale sur votre propre site. Le chat ultra-léger ne gèle plus, et la génération vidéo gagne un moteur résident et un vrai export WebM.

Open source — le code est public

  • Tout le moteur est désormais sur GitHub sous licence MIT : kernels WGSL, format .brik, chargeurs, application. Nouvelle adresse : brimkern.romainkhanoyan.fr.
  • Un README produit avec captures d’écran, et la plomberie SEO qui va avec (robots, sitemap, domaine canonique).

SDK embarquable (v0) — votre site, le GPU de vos visiteurs

  • Une balise <script src="/sdk.js"> + Brimkern.embed({ system: … }) monte un widget de chat qui exécute un modèle .brik entièrement sur le GPU du visiteur : zéro serveur, zéro coût par token, privé, hors-ligne après le premier chargement. Exemple live sur /sdk-demo.html.
  • Configurable avec un simple objet : modèle (URL d’un .brik hébergé), prompt système, titre, message d’accueil, couleur d’accent, budget de tokens. Le modèle ne se télécharge que quand le visiteur ouvre le widget — votre PageSpeed reste intact.
  • Il réutilise le chemin rapide de l’app (décodage GPU résident) et n’interprète jamais la sortie du modèle comme du HTML — texte brut uniquement, styles cantonnés au widget.

Le chat LFM2.5 dégelé — et 2,3× plus rapide

  • Basculer sur LFM2.5 en cours de conversation pouvait geler l’onglet : chaque token déclenchait ~100 allers-retours GPU, et rejouer tout l’historique les multipliait par milliers. Le calcul est désormais 100 % résident GPU — une soumission par token, une seule pour tout le prefill.
  • Vérifié token-identique à l’ancien chemin avant livraison, avec repli automatique et interrupteur ?lfm2resident=0. Mesuré : 13,5 → 31 tok/s sur la même machine.

Vidéo (labo) — moteur résident, enrichissement de prompt, export WebM

  • Les modules temporels (motion) tournent désormais entièrement sur le GPU en une seule soumission — 5× plus vite par module, avec repli vérifié contre la référence CPU et ?videoresident=0.
  • Votre prompt court est enrichi par le modèle local LFM2.5 en vraie description cinématographique avant la génération — un meilleur mouvement, toujours 100 % on-device.
  • Le résultat s’exporte en clip WebM bouclé à durée bornée (~10 s) au lieu de frames brutes.

RWKV-7 rejoint le catalogue — attention linéaire, mémoire constante

  • RWKV-7 G1 0.1B se charge depuis le navigateur de modèles : une architecture 100 % récurrente où un état fixe d’environ 1 Mo remplace le cache KV — la mémoire ne grandit pas avec la conversation. 128 Mo, Apache-2.0, tokenizer World embarqué, réponses simples mais honnêtes (c’est un 0.1B).

Mobile & entretien

  • Le navigateur de modèles complet est désormais accessible sur mobile avec une action « Changer de modèle » — Qwen 3 0.6B et compagnie sont à un tap, plus réservés au desktop.
  • La jauge de stockage affiche désormais le vrai quota du navigateur (il dépend de l’espace disque libre) au lieu d’une estimation optimiste, le splash de première visite trompeur a disparu, et la carte « Moteur GPU » est plus compacte.
21 juillet 2026

Un second moteur est né : les modèles à attention linéaire et hybrides tournent dans ton navigateur. Un modèle de 149 Mo qui discute en français, une démo live sur /local-ai — et la première vidéo jamais générée par Brimkern, entièrement sur ton GPU.

LFM2.5 230M — l’ultra-léger qui discute vraiment (mobile aussi)

  • Nouveau chemin moteur pour les architectures hybrides (convolution courte + attention) : LFM2.5-230M tourne de bout en bout sur nos kernels WGSL — 149 Mo, répond en français propre, ~24 tok/s.
  • Disponible dans le chat en preset — et sur mobile, où tu choisis désormais entre LFM2.5 (149 Mo, recommandé) et Qwen 0.5B (378 Mo).
  • Chaque kernel validé contre un oracle CPU, token par token face à llama.cpp avant livraison.

Démo live sur /local-ai — classer, extraire & discuter

  • Sentiment (12/12 sur nos bancs), extraction d’email avec garde-fou anti-hallucination (un email absent de ton texte n’est jamais inventé), et un petit chat francophone — le tout dans ton navigateur, en cache après le premier téléchargement de 149 Mo.
  • Classification contrainte sous le capot : le modèle ne peut répondre que dans le jeu d’étiquettes autorisé — la technique qui rend les petits modèles fiables.

Première vidéo générée dans le navigateur (labo)

  • 16 frames temporellement cohérentes (un renard qui marche dans la neige) en ~3,5 minutes, 100 % local : les modules motion AnimateDiff-Lightning greffés sur notre pipeline image existant — zéro nouveau kernel GPU nécessaire.
  • Encore en labo (banc dev) — l’UI produit, le pacing thermique et l’export WebM arrivent ensuite.

Correctifs & entretien

  • Rouvrir une conversation contenant des images ne re-télécharge plus le modèle image : seuls les modèles texte se chargent automatiquement, tes images sauvegardées s’affichent telles quelles.
  • Badge « En cache » renommé « Téléchargé » avec un style plein distinct — fini la confusion avec le verdict GPU « Tourne bien ».
18 juillet 2026

Brimkern apprend à voir : montre-lui une photo et pose tes questions — entièrement sur ton GPU. Affiner une image repart désormais de ses vrais pixels, et le dernier kernel différé est livré.

Vision (bêta, desktop) — image + texte → texte

  • Qwen2-VL 2B tourne entièrement dans le navigateur : un encodeur visuel de 675 M de paramètres (32 couches transformer, positions rotatives 2D) lit l’image en patches, un « merger » les projette dans le modèle de langage, et le LLM répond à tes questions dessus. Les deux fichiers de poids streament depuis Hugging Face et restent en cache (~2,3 Go, GPU de bureau uniquement).
  • Sous le capot : deux nouveaux kernels de position (RoPE 2D pour la tour visuelle, M-RoPE pour le modèle de langage) — le second touche le chemin chaud du chat, donc il ne se déclenche QUE pour cette architecture et s’auto-teste au chargement, avec un repli qui coupe la vision, jamais le texte.
  • Dans le catalogue, la carte Qwen2-VL est désormais chargeable (desktop). Joins une image avec le bouton 📎 et pose tes questions — le multi-tours fonctionne, tout reste local.

Deux nouveaux cerveaux au catalogue — Qwen 3, et Llama est de retour

  • Qwen 3 (4B et 0.6B) : la génération suivante, nettement plus forte que Qwen 2.5 à taille égale, avec le raisonnement pas-à-pas natif — le sélecteur de budget de réflexion s’y applique. Son architecture QK-Norm est auto-testée au chargement comme chaque évolution de kernel.
  • Llama 3.2 est réparé et de retour au catalogue : llama.cpp permute les poids d’attention à la conversion GGUF d’une façon que nos kernels n’attendaient pas — ils sont désormais dé-permutés au chargement (toutes quantifications), et le scaling de fréquences longue-contexte « llama3 » est appliqué. Mesuré : 178 t/s de prefill, 19,5 t/s de génération.

Vrai img2img — affiner depuis les pixels

  • « Affiner cette image » rejouait le même bruit initial ; désormais l’image affichée est ré-encodée en espace latent (petit encodeur VAE de 5 Mo, téléchargé à la première utilisation), re-bruitée partiellement et régénérée : la composition est conservée depuis les vrais pixels. Réglable via ?strength= (défaut 0.55).
  • Une image affinée dépend de ses pixels source, donc elle n’est pas régénérable depuis prompt+seed comme les autres — elle est sauvegardée entière avec la conversation.

Sous le capot

  • Le dernier kernel différé est livré : l’attention pleine (non causale) donne désormais à chaque (token, tête) un workgroup de 64 lanes avec softmax en ligne — une passe sur les clés au lieu de deux. Auto-testé aux formes réelles du UNet au chargement, repli silencieux, ?attnfullwg=0 pour forcer l’ancien kernel.
  • Vider l’historique des conversations vide maintenant vraiment l’écran (chat neuf), et l’app ne rouvre plus automatiquement une conversation dont le modèle n’est pas en cache — tu arrives sur un accueil neuf au lieu d’un chat mort.
16 juillet 2026

Les longues conversations retrouvent leur vitesse (jusqu’à ×26 sur l’attention), le GPU peut se déconnecter sans tuer l’app, le modèle se charge tout seul, et l’interface assume pour de bon son identité d’imprimeur.

L’attention refaite pour le décodage — fin du 1 t/s en contexte long

  • Le kernel d’attention n’utilisait qu’un thread GPU par tête : 14 threads en tout au décodage — sur du matériel taillé pour des milliers. Au-delà de ~1 000 tokens de contexte, il devenait le mur (~680 ms par token). Les nouveaux kernels donnent à chaque tête un workgroup complet de 64 lanes avec softmax en ligne : ×14 à ×26 mesurés, résultats identiques à 1e-7 près.
  • Ceinture et bretelles : au chargement, le moteur auto-teste les nouveaux kernels aux formes réelles ; un driver GPU qui les miscompile bascule en silence sur les kernels classiques (plus lents en contexte long, corrects partout). ?attndecode=0 force le repli pour diagnostiquer.
  • Sur mobile, les réponses sont désormais volontairement concises (le téléphone n’a pas à chauffer une minute par réponse), et l’écran reste allumé pendant que le modèle travaille.

Un crash GPU n’est plus une fin

  • Quand le système reprend le GPU (longue conversation, onglet en arrière-plan, chauffe), l’app continuait sur un device mort — statut « prêt », envois permis, chaque calcul en échec. Elle détecte désormais la perte, conserve votre conversation, et propose de vraies sorties : recharger le modèle, inspecter/vider le stockage.
  • La détection WebGPU réessaie avant d’abandonner, et « Non supporté » explique désormais la cause n°1 : l’accélération matérielle désactivée dans le navigateur — avec le réglage exact à activer.

Le modèle se charge tout seul

  • Rouvrir l’app reprend votre dernière conversation ET son modèle quand il est intégralement en cache (BRIK streamés compris — desktop comme mobile, zéro réseau). Téléchargement partiel ? Le préchargement d’arrière-plan finit le travail — avec le vrai progrès affiché sur le splash de première visite — puis charge le modèle tout seul.
  • Corrigé au passage : le préchargement d’arrière-plan pouvait mourir en silence avant même de démarrer, et un chargement auto au démarrage prenait le téléphone pour un desktop (f16 chargé au lieu du format mixte).

La génération d’image maigrit — et arrive sur mobile

  • Le pipeline image téléchargeait 2,4 Go de poids fp16, puis les quantifiait en int8 sur votre GPU à chaque chargement. Les poids arrivent désormais pré-quantifiés et streamés par plages (repris, mis en cache) : 1,28 Go sur desktop, sortie identique — vérifiée numériquement ET visuellement contre l’ancien chemin.
  • Nouveau sur mobile (bêta) : « Essayer la génération d’image » charge SDXS-512, un UNet distillé à 1 étape, en build int4 « light » avec un encodeur de texte allégé — ~445 Mo tout compris pour une image 512px native. Jugé côte à côte contre le build lourd : quasi identique.

« Le Kern », encré jusqu’au bout

  • La police de titre devient Fraunces (une serif d’imprimeur — la marque kern-B, les titres et le splash la portent), un filet rouge d’imprimeur coiffe l’app, le curseur de saisie et la sélection passent au rouge Kern, et l’écran d’accueil se lit comme une page de spécimen. Les derniers reliquats violets et dégradés ont disparu.
  • Mobile désencombré : la bannière de conversion BRIK disparaît (le modèle mixte est servi automatiquement), et une seule suggestion de départ laisse la place au message d’accueil du modèle.
15 juillet 2026

Le modèle mobile gagne la qualité int8 pour presque la taille int4 (nouveau format « mixte »), se télécharge tout seul en arrière-plan pendant que vous lisez l’accueil, et accueille dignement les nouveaux venus.

Quantification mixte — la qualité int8 pour (presque) la taille int4

  • Une étude A/B tenseur par tenseur a montré OÙ l’int4 casse un petit modèle : le tout-int4 produit du charabia, mais garder les seules matrices d’attention en int8 restaure une qualité digne de l’int8. Le nouveau format « mixte » stocke exactement ça : corps int4 + attention int8.
  • Le modèle mobile est servi au format mixte : 377 Mo au lieu de 508 (int8 plein) — pour +18 Mo par rapport à l’ancien fichier int4 qui le dégradait. Le bandeau de diagnostic affiche honnêtement « mixte int8+int4 ».
  • Le profil « Mixte » est aussi proposé dans les deux convertisseurs BRIK (recommandé pour les petits modèles — l’int4 reste pour les gros).

Le téléchargement s’efface en arrière-plan

  • Sur mobile, si le modèle n’est pas (entièrement) en cache, son téléchargement démarre désormais tout seul peu après votre arrivée — au moment de taper « Charger le modèle », l’essentiel est déjà local. Reprise incluse : un onglet fermé ne re-télécharge que ce qui manque.
  • Visible et poli : une ligne de progression avec « Annuler », rien ne démarre si l’économiseur de données du téléphone est actif, et tout chargement réel reprend la main instantanément.
  • Première visite sur mobile : un court écran d’accueil (« Préparation de votre espace IA… ») couvre le démarrage — tap pour passer, plus jamais montré ensuite.

Sous le capot

  • Le prompt n’est plus re-tokenisé de zéro à chaque message : seul le nouveau tour l’est (~×90 plus rapide sur les longs historiques).
  • Les images générées ne gèlent plus la page ~100 ms après le rendu (encodage PNG asynchrone).
6 juillet 2026

Mobile enfin fluide et fiable : conversations ~4× plus rapides (cache KV réutilisé entre les tours, échantillonnage sur GPU), int8 par défaut, et un panneau Réglages.

Conversations plus rapides — surtout sur mobile

  • Le cache d’attention (KV) est réutilisé d’un message à l’autre : seul votre nouveau message est analysé, plus jamais tout l’historique. Avant, chaque tour relisait toute la conversation — le temps de réponse doublait dès le 2e message ; il est maintenant constant.
  • Échantillonnage du prochain token calculé sur le GPU (softcap, pénalité de répétition et top-K dans la même passe que le calcul) : ~600 Ko relus par token → 512 octets. Auto-testé au chargement, avec repli automatique sur le chemin CPU si le GPU de l’appareil échoue au test.
  • Boucle de génération allégée : détection de fin sur les derniers tokens seulement et affichage rafraîchi ~8×/s (au lieu d’une re-détokenisation et d’un re-rendu complets à CHAQUE token, qui asphyxiaient les téléphones). Seule la bulle en cours de frappe se re-rend.
  • Résultat mesuré sur téléphone (Qwen 0.5B) : réponse complète en ~10 s au lieu de 20–38 s, génération à ~5 t/s au lieu de 2,7.

Qualité mobile — int8 par défaut

  • Les petits modèles (≤ ~1,2 Md de paramètres) se chargent désormais en int8 sur mobile, plus en int4 : l’int4 dégradait fortement un 0.5B (réponses absurdes, répétitions en boucle) alors qu’il tient largement en int8. L’int4 reste réservé aux gros modèles qui ne rentreraient pas.
  • Et le cache d’attention reste en f32 par défaut (plus rapide) : sa version int8 — qui ajoute du travail à chaque token — n’est activée que là où sa VRAM compte vraiment (gros modèles, int4).
  • Nouveau bandeau de diagnostic sous chaque réponse : précision réelle, format du cache KV, chemin d’échantillonnage et réutilisation du contexte — pour comprendre ce qui a tourné, même sans console. Et il dit la vérité : quand le fichier du modèle est plus quantifié que la précision demandée, il affiche par ex. « int8 (source int4) ».
  • Stockage persistant demandé au navigateur : le modèle streamé mis en cache ne devrait plus être effacé entre deux sessions sur mobile.

Pipeline image — encore plus léger

  • L’encodeur de texte (CLIP) rejoint le UNet : quantifié int8, résident sur le GPU, exécuté en une seule soumission — fini les ~280 allers-retours et les ~500 Mo de poids renvoyés au GPU à chaque image.
  • Chargement du modèle image sans blocage : la conversion des poids fp16 se fait désormais sur le GPU (l’onglet gelait ~10 s à chaque chargement).
  • Mémoire GPU rendue après chaque image (le tampon de travail conservait des centaines de Mo), et le pipeline image est entièrement libéré (~1 Go) quand on charge un modèle de texte.
  • Décodage 512px plus rapide : les convolutions 3×3 dominantes passent en kernel tuilé à mémoire partagée (chaque pixel lu 1× au lieu de 9×, chaque poids 1× au lieu de 256×), et la normalisation de groupe utilise 4× plus de threads. Les deux auto-testés au chargement avec repli automatique.

Web & outils (MCP) — premiers pas, en toute transparence

  • Recherche web optionnelle (OFF par défaut) : le modèle s’appuie sur des extraits Wikipédia et cite ses sources. Seule votre question est envoyée — jamais la conversation. Signalé sous chaque réponse concernée et dans la barre de saisie.
  • Calculatrice locale (ON par défaut, aucun réseau) : les calculs de vos messages sont évalués exactement côté machine et le résultat fourni au modèle — les petits modèles se trompent systématiquement en arithmétique. Le modèle connaît aussi la date du jour.
  • Lecture des liens collés (OFF par défaut) : collez une URL, le modèle lit la page (via le lecteur r.jina.ai — indiqué sur l’option).

Réglages & correctifs

  • Nouveau panneau « Réglages » dans la barre latérale : puissance GPU (Éco / Équilibré / Max — régule la chauffe pendant la génération d’images) et les options Web & outils ci-dessus.
  • Interface entièrement bilingue : la bascule FR/EN couvre désormais toute l’application (panneaux, erreurs, étapes de chargement, info-bulles…) — y compris ce changelog.
  • Chargement des modèles streamés plus vif : les poids d’une couche sont récupérés en une seule requête au lieu de 9-12 (~25 requêtes au lieu de ~220 pour un modèle entier).
  • L’écran de chargement devient un vrai journal : fond opaque et liste des étapes réelles (téléchargement, quantification, validation) avec leur progression.
  • Le défilement automatique respecte votre lecture : si vous remontez pendant que l’IA écrit, plus aucun retour forcé en bas — il reprend quand vous y redescendez.
  • Corrigé : charger un modèle de texte par-dessus le mode image ne basculait pas — les messages partaient en génération d’image (et le pipeline image restait en mémoire).
  • Interrupteurs de diagnostic dans l’URL (?gputopk=0, ?kvreuse=0) pour isoler un souci propre à un appareil.
2 juillet 2026

Génération d’images 100 % navigateur (SD-Turbo en WGSL maison), UNet quantifié int8 résident GPU, régulation thermique — et une nouvelle identité visuelle.

Génération d’images — Stable Diffusion Turbo, 100 % local

  • Nouveau mode image dans le chat : décris une image, elle est générée entièrement dans le navigateur — CLIP (encodage du prompt), UNet (débruitage) et décodeur TAESD tournent sur nos propres kernels WGSL, sans aucun serveur.
  • Fidélité au prompt corrigée face à la référence diffusers : padding du tokenizer (« ! », pas <|endoftext|> — sans masque d’attention, les 77 positions comptent) et LayerNorm final du CLIP appliqué. Résultat : des images cohérentes avec la demande.
  • Qualité réglable par génération au-dessus de la zone de saisie : 128px (rapide), 256px (conseillé) ou 512px (résolution native de SD-Turbo).
  • Conversations légères : seule une vignette floue + le prompt + la graine sont persistés ; « cliquer pour révéler » régénère l’image à l’identique (génération déterministe) sans jamais stocker les pixels.
  • Poids (UNet + CLIP fp16, TAESD) mis en cache navigateur au premier chargement → les fois suivantes, aucun téléchargement.

Performance & thermique — int8 résident + régulation

  • UNet quantifié int8 (BRIK8) directement sur le GPU au chargement : ~0,9 Go de VRAM au lieu de ~3,4 Go en f32, et plus aucun ré-envoi de poids à chaque image (avant : ~3,4 Go re-transférés par génération). Nouveau kernel conv2d int8 à déquantification fusionnée, couvert par le self-test.
  • Exécution GPU-résidente de bout en bout : les activations restent sur le GPU entre tous les blocs (UNet et décodeur), une seule lecture CPU par étape de débruitage → beaucoup moins d’allers-retours, génération plus efficace.
  • Régulation thermique intégrée : le pipeline mesure le temps GPU réellement consommé et intercale des pauses proportionnelles (~60 % de charge cible) — la génération lisse sa consommation au lieu de faire chauffer la machine en rafale continue.
  • Progression détaillée pendant la génération (étape de débruitage + bloc UNet en cours).

Nouvelle identité — « Le Kern »

  • Exit le violet et le logo dégradé : place à une identité papier / encre / rouge imprimeur, en clin d’œil au crénage typographique de brimKERN. Mode sombre « encre » assorti.
  • Logo redessiné en SVG plat (un B massif entaillé d’un kern diagonal) : net à toutes les tailles, suit le thème clair/sombre, et remplace 700 Ko de PNG.
  • Favicon et carte de partage (OpenGraph) mis à jour dans la nouvelle identité.

Nettoyage

  • Suppression du générateur d’image « aperçu » (placeholder), des gabarits de prompt Llama 2/3 inaccessibles depuis le retrait de Llama, et des assets inutilisés — bundle plus léger.
25 juin 2026

Gemma 2 pleinement fonctionnel, appariement tokenizer auto, reprise de conversation, perf prefill (matmul tilé), Skills, stockage enrichi et interface bilingue FR/EN.

Gemma 2 — pleinement fonctionnel

  • Génération cohérente sur Gemma 2 (2B) : correction d’un débordement numérique de l’activation GELU (qui produisait des NaN), et de la double application de la normalisation RMSNorm (1+w) — la cause du texte incohérent.
  • Appariement automatique tokenizer + architecture depuis le fichier GGUF : charger un modèle n’utilise plus par erreur le tokenizer d’un autre (un mismatch de vocabulaire donnait du charabia malgré un calcul correct).
  • Socle réutilisable pour ajouter d’autres familles de modèles locaux (prochaine cible : Microsoft Phi-3.5-mini).

Sélection de modèle & stockage

  • Reprise complète à l’ouverture : la dernière conversation est rechargée et, si le modèle qu’elle utilisait est déjà en cache, il est rechargé automatiquement (sans réseau) → on retombe directement sur une session prête à discuter.
  • Nouveau sélecteur « Parcourir les modèles » en fenêtre large avec recherche (nom, usage, tag) et grille — plus lisible que la liste étriquée à mesure que le catalogue grandit.
  • Badges sur chaque modèle : « ● en cache » (déjà téléchargé localement), « BRIK conseillé » (≥ ~1.5B : ÷2–4 la VRAM + réouvertures instantanées), et indicateur du modèle actuellement chargé.
  • Panneau Stockage : modèle actif mis en évidence, badge « chargé » sur le BRIK correspondant, et bouton « Tout supprimer » (caches + BRIK + historique).
  • Roadmap : aperçu de la prochaine architecture portée sur nos kernels (Microsoft Phi-3.5-mini).

Interface — sélecteur de modèle unifié

  • Toute la sélection de modèle passe par une seule fenêtre « Choisir un modèle » à taille fixe (scroll interne) : onglet Modèles (grille + recherche + créateur/modalité par tuile) et onglet Importer (fichier local, URL GGUF, stream .brik), avec la case « Convertir en BRIK ».
  • En-tête de chat allégé : nom du modèle raccourci (info-bulle au survol), bascule langue/thème déplacée près du logo, et options dev (précision/VRAM, cache KV, benchmark) repliées dans un accordéon fermé par défaut.
  • Aperçu roadmap multimodale (Microsoft Phi-3.5, Mistral, Stable Diffusion, Qwen2-VL) en cartes « bientôt ».

Performance & conversion

  • Matmul q8/q4 « tilé » au prefill : chaque invocation calcule 4 tokens d’un coup en déquantifiant chaque poids une seule fois → ~4× moins de trafic mémoire poids sur le traitement du prompt.
  • Conversion GGUF → BRIK en flux (shard par shard) : pic mémoire ≈ une couche au lieu du modèle entier → de gros modèles se convertissent dans le navigateur sans saturer la RAM.
  • Llama temporairement retiré des architectures proposées (incompatibilité RoPE / poids permutés par llama.cpp → sorties incohérentes) ; il reviendra avec un mode RoPE adapté. Architectures actives : Qwen 2/2.5, Gemma 2, DeepSeek-R1 (distill Qwen).

Skills — consignes réutilisables

  • Bibliothèque de « skills » (personas / instructions système) : intégrés + tes propres skills, persistés localement.
  • Multi-sélection (les skills se combinent), import depuis une URL GitHub, et popup accessible via un bouton à gauche de la barre de chat.

Gestion du stockage

  • Panneau « Stockage » : voir l’espace pris par les modèles streamés, GGUF téléchargés, BRIK convertis et l’historique — avec suppression individuelle.

Mobile & bilingue

  • Mobile simplifié : un seul modèle prêt à l’emploi (Qwen 0.5B BRIK streamé), barre de progression de téléchargement, et la zone de chat s’affiche pendant le chargement.
  • Interface bilingue : français (défaut) / anglais, bascule dans l’en-tête, mémorisée.
24 juin 2026

BRIK autonome : modèles hébergés, tokenizer embarqué, fichiers plus légers — et chargement mobile optimisé.

BRIK autonome, hébergé & optimisé mobile

  • Tokenizer embarqué dans le .brik → chargement 100 % hors-ligne, sans fetch externe ni choix manuel de tokenizer.
  • Embeddings « tied » dédupliquées (output = token_embd) → fichier ~⅓ plus léger, sans perte de qualité.
  • Modèle Qwen 2.5 0.5B pré-converti, hébergé et streamé par HTTP Range (faible VRAM) → chargement direct optimisé, mobile comme desktop.
  • Conversion GGUF → BRIK fiabilisée : les très gros tenseurs sont traités par tranches pour ne plus dépasser la limite de buffer GPU (qui corrompait silencieusement les poids).
  • Niveau de réflexion réglable (off / low / medium / high) pour les modèles de raisonnement ; catalogue resserré sur les architectures pleinement supportées (Qwen, Gemma, DeepSeek).

Format BRIK v2 — plus léger & streamable

  • Quants web-natifs BRIK8 (int8) et BRIK4 (int4) : déquantification fusionnée dans le matmul GPU (poids gardés quantifiés en VRAM), petit téléchargement ET inférence rapide.
  • Fichier unique .brik auto-contenu (en-tête + manifeste + données alignées 16 octets) à la place du .brik.zip — un seul fichier à héberger/charger.
  • Chargement par streaming HTTP Range : seul l’en-tête (manifeste) est récupéré d’abord, puis chaque tenseur à la demande, mis en cache (Cache API) → re-chargements instantanés et hors-ligne.
  • Embeddings stockés en int8 (souvent le plus gros tenseur) → téléchargement et VRAM nettement réduits, qualité quasi inchangée.

Contexte plus long — cache KV q8

  • Cache attention (K/V) optionnel en int8 : ÷~4 la VRAM du cache → jusqu’à ~4× plus de contexte à VRAM égale, qualité quasi-f16.
  • Bascule « KV f32 / KV q8 » dans le réglage de précision (déquant fusionnée dans l’attention, sans expansion f32).

Nouvelles architectures

  • Support de Gemma 2 par les kernels optimisés : softcap d’attention + des logits, activation GELU, doubles normes « sandwich », RMSNorm (1+w), scaling des embeddings, head_dim ≠ d/têtes.
  • Kernels rendus paramétrables (scale d’attention, activation, normes) — fondation réutilisable pour d’autres familles.

Chargement & cache

  • Conversion automatique GGUF → BRIK au chargement (optionnelle) : faite une seule fois, puis le .brik converti est mis en cache (IndexedDB) pour des ouvertures instantanées.
  • Page de conversion dédiée avec gestion du cache des modèles convertis (lister / supprimer).
  • Précision des poids clarifiée : GGUF en f16/f32, tiers BRIK8/BRIK4 réservés aux modèles BRIK.

Robustesse & correctifs

  • Correction d’un débordement de dispatch GPU sur les longs prompts (> ~860 tokens) qui produisait une sortie incohérente — désormais réparti sur une grille 2D.
  • Compteur de tokens + avertissement de contexte dans le composer.
  • Gros collage replié en « extrait » dans le champ de saisie (le texte complet reste envoyé au modèle).
  • Correctifs d’interface : plus d’anneau de focus résiduel au clic, bulles de message qui ne coupent plus les mots courts.
23 juin 2026

Première version — un moteur d'inférence LLM écrit de zéro, 100 % dans le navigateur.

Moteur WebGPU custom

  • Kernels de calcul WGSL maison : matmul vectorisé (vec4 128-bit), RMSNorm, RoPE, attention causale GQA avec cache KV, SwiGLU.
  • Parsing GGUF directement en JavaScript et déquantification des poids sur le GPU.
  • Chemin de décodage « GPU-resident » : tout le passage avant d'un token enchaîné en une seule soumission GPU.
  • Auto-validation des kernels au chargement (selfValidate) : le modèle ne se charge que si les calculs sont corrects.

Performances

  • Projection des logits mise en cache sur le GPU au lieu d'être recalculée à chaque token.
  • Argmax du token suivant calculé sur le GPU (un seul entier relu par token au lieu de ~152k logits).
  • Pool de buffers réutilisés entre les tokens. Résultat global : décodage ~2,5× plus rapide.

Précision des poids (commutable)

  • f32 — pleine précision (référence qualité).
  • f16 — demi-précision : ~1,25× plus rapide, ½ de la VRAM (selon le GPU).
  • int4 (format BRIK « q4web ») — déquantification à la volée, ¼ de la VRAM → permet de charger des modèles plus gros dans le navigateur.

Modèles & quantifications

  • Modèles : Qwen 2.5 (0.5B, Coder 1.5B), Llama 3.2 1B, DeepSeek-R1 Distill Qwen 1.5B (raisonnement <think>).
  • Quantifications GGUF lues : Q4_0, Q4_K, Q5_0, Q5_K, Q6_K, Q8_0, F16, F32.
  • Import de n'importe quel GGUF compatible (fichier local ou URL Hugging Face).

Interface

  • Chat avec rendu Markdown (gras, italique, listes, titres) et coloration + copie des blocs de code.
  • Historique des conversations persistant (IndexedDB), indépendant du modèle chargé.
  • Benchmark intégré comparant f32 / f16 / int4, et sélecteur de précision.
  • Panneau latéral repliable, interface adaptée mobile.

Confidentialité

  • Aucune donnée envoyée à un serveur : modèle et calculs s'exécutent entièrement sur votre GPU, hors-ligne après le téléchargement du modèle.

Brimkern — moteur WebGPU open. Créé par Romain Khanoyan.