J'ai exécuté un modèle d'IA de 2 milliards de paramètres dans un onglet de navigateur. Aucun serveur.

DEV - 25/05
J'ai exécuté un modèle de langage de 2 milliards de paramètres entièrement dans un onglet de navigateur. Pas de serveur. Aucune clé API. Non...

J'ai exécuté un modèle de langage de 2 milliards de paramètres entièrement dans un onglet de navigateur.

Pas de serveur. Aucune clé API. Pas de nuage. Complètement hors ligne, uniquement Chrome, WebGPU et le GPU de mon ordinateur portable générant des jetons localement.

Ce n'était pas un frontend parlant à un backend caché. Le modèle s'est chargé sur ma machine et a répondu à environ 20+ jetons/s sur un MacBook Pro M1.

Cela signifie une IA privée, pas de facture d'inférence et pas d'attente sur le backend de quelqu'un d'autre.

La première fois que cela a fonctionné, cela semblait légèrement illégal.

J'avais passé suffisamment de temps avec les configurations LLM locales pour connaître la forme habituelle du problème. Téléchargez un modèle. Chargez-le via un runtime natif. Regardez vos fans tourner en rond. Acceptez que le navigateur ne soit qu’un joli frontal posé au-dessus du véritable système d’apprentissage automatique.

Ensuite, je me suis posé une question que je ne pouvais pas lâcher : si mon ordinateur portable peut déjà exécuter le modèle localement, pourquoi le navigateur ne peut-il pas communiquer directement avec le même GPU ?

Cette question est devenue BrowserAI. Cela a commencé comme une expérience locale et s'est terminé comme une application publique qui exécute plus de 100 modèles provenant de plus de 13 familles, entièrement côté client, sans aucune inférence backend.

Il fonctionne également sur les téléphones modernes. The UI is responsive, the app is installable as a PWA, and smaller models are surprisingly usable on mobile hardware.

Si vous souhaitez essayer le produit avant de lire les informations internes :

  • Démo en direct : BrowserAI
  • Code : GitHub

Instantané de ma machine Appareil : MacBook Pro (Apple M1, 8 Go de RAM) Navigateur : Chrome/Brave Modèle : Qwen 3.5 9B q4f16_1 (quantisé 4 bits) Vitesse observée : ~20+ jetons/s Avertissement : il s'agit d'un résultat personnel, pas d'une référence universelle

Cet article est la véritable histoire technique derrière tout cela : ce qui a rendu cela possible, ce qui a été plus difficile que prévu et comment l'ensemble de la pile fonctionne, du chargement de la première page au jeton diffusé.

Tout a commencé avec une sorte de curiosité très spécifique

J'étais déjà plongé dans le terrier habituel de l'IA locale : llama.cpp, Ollama, fichiers de modèle quantifiés, comparaisons de vitesse de jeton, réglage de la fenêtre contextuelle, tout cela. Une fois que vous commencez à exécuter des modèles sur votre propre machine, votre cerveau commence immédiatement à poser des questions ennuyeuses.

Le mien était simple :

Si le GPU est déjà là, pourquoi est-ce que je traite toujours le navigateur comme un spectateur ?

Au début, j’ai supposé que la réponse était une limitation ennuyeuse de la plateforme. Les navigateurs font l'interface utilisateur. Les applications natives effectuent des calculs lourds. Fin de l'histoire.

Mais cela a cessé d’être vrai au moment où j’ai commencé à lire sur WebGPU.

Ensuite, j'ai trouvé WebLLM de MLC-AI. Ce fut le véritable tournant. WebLLM prend des modèles ouverts, les compile via Apache TVM et les exécute sur WebGPU avec une API qui vous semble étrangement familière si vous avez déjà utilisé le SDK d'OpenAI.

Je l'ai pointé sur Qwen 3.5 2B, j'ai ouvert Chrome, j'ai tapé un message et j'ai regardé le flux de réponse localement. Aucun appel de serveur caché. Pas de point de terminaison d'API magique. Juste mon navigateur qui transmet le travail à mon propre GPU.

C’est à ce moment-là que le projet a cessé d’être une expérience et a commencé à devenir un produit.

L'ensemble du projet consiste en réalité à résoudre trois problèmes

Une fois le premier prototype fonctionnel, l’architecture est devenue beaucoup plus claire. L'exécution de LLM dans le navigateur n'est pas un problème. Il s’agit de trois problèmes distincts empilés les uns sur les autres :

  1. Calcul : Comment rapprocher suffisamment le code du navigateur du GPU pour rendre l'inférence du transformateur pratique ?
  2. Mémoire : comment intégrer des modèles comportant des milliards de paramètres dans la mémoire qu'un navigateur peut utiliser de manière réaliste ?
  3. Réactivité : comment faire tout cela sans geler l'interface utilisateur et sans donner l'impression que l'application est cassée ?

BrowserAI existe parce que le navigateur moderne a enfin des...
[Courte citation de 8% de l'article original]

Loading...