Skip to main content
Gemma 4WebGPUлокальные LLM

Gemma 4 dans le navigateur sans serveur

Sur Hugging Face, des noyaux WebGPU spéciaux pour Gemma 4 ont été présentés, permettant d'exécuter le modèle entièrement dans le navigateur sans backend. Pour les entreprises, ce changement signifie une intégration IA moins chère, plus privée et mieux adaptée aux applications hors ligne et aux PWA.

Contexte technique

J'ai jeté un coup d'œil au Space Hugging Face, et le fond n'est pas une jolie démo : Gemma 4 tourne vraiment on-device via WebGPU. Pour certaines tâches d'intégration IA, on peut donc soudainement faire de l'inférence sans aucun backend.

Ces noyaux WebGPU, selon la description et les discussions, ont été écrits par Fable 5. Il s'agit d'un ensemble de compute shaders de bas niveau qui prennent en charge le gros du travail d'inférence directement dans le navigateur, sans aller-retour serveur.

C'est là que je me suis arrêté et que j'ai revu l'architecture : les prompts, les activations et la génération restent localement sur l'appareil. Pour les cas d'usage avec des données sensibles, ce n'est plus du marketing, c'est un véritable embranchement pratique.

Pour l'instant, cela concerne principalement Gemma 4 E2B, car les modèles 12B et 27B ne rentrent pas dans les limites de VRAM d'un navigateur. Les guides évoquent une quantification INT4, des fenêtres de contexte réduites et un mode texte seul, bien que la démo mentionne aussi le chargement d'images.

Les performances sont vivantes, pas synthétiques : les documents navigateur font état d'environ 40-80 tokens/s en prefill et 40-180 tokens/s en décodage, et la communauté a discuté d'environ 255 tokens/s sur M4. Je ne le prends pas comme une promesse, mais comme un plafond pour une combinaison réussie navigateur-GPU-compilation.

Il est important de noter qu'il ne s'agit pas simplement d'un « LLM dans un onglet ». C'est une brique pour une nouvelle classe d'applications où l'on peut amener le modèle directement dans l'interface utilisateur : Chrome, Edge, cache local, PWA, réseau faible — zéro dépendance à une API cloud pendant l'exécution.

Ce que cela change pour l'automatisation

Le premier avantage est évident : le coût d'entrée de l'implémentation IA diminue. Si je n'ai pas besoin d'inférence côté serveur, je supprime une partie de DevOps, la latence et les coûts API récurrents pour certains scénarios.

Le deuxième point est plus subtil : des flux de travail véritablement hors ligne deviennent possibles. Assistants internes, interfaces terrain, kiosques, postes de travail sécurisés — des endroits où l'automatisation par IA butait auparavant sur des contraintes réseau ou de confidentialité.

Mais tout le monde n'y trouve pas son compte. Les projets avec des contextes longs, une multimodalité lourde et une prédictibilité stricte de la qualité resteront sur une architecture hybride ou serveur.

Je vois constamment cela chez les clients : le problème est rarement le modèle lui-même, mais où se situe la frontière entre navigateur, appareil et cloud. Chez Nahornyi AI Lab, nous construisons l'architecture IA autour de processus réels, pas de jolies captures d'écran. Si vous avez un produit qui nécessite une automatisation IA locale sans les tracas du serveur, nous pouvons étudier ensemble ce qui a du sens à déplacer dans le navigateur dès maintenant.

Nous avons déjà examiné Rust LocalGPT — un assistant IA local compact avec mémoire persistante et API HTTP, fonctionnant entièrement sans services cloud. Cette approche de l'inférence locale fait écho à la révolution WebGPU dans le navigateur, où le modèle s'exécute également côté client.

Partager cet article