IA locale : un modèle dans le navigateur, 552B de paramètres sur une RTX 3090 Ti

Dans le navigateur, sans serveur derrière

Liquid AI a présenté LFM3 Omni 2B, son nouveau modèle omni, en démonstration directement dans un navigateur via WebGPU. La vidéo de la démo provient de leur propre espace Hugging Face. L'intérêt avancé est simple : une exécution locale, côté navigateur, sans dépendre d'une infrastructure serveur distante.

Le format 2B place évidemment le modèle ailleurs que dans la catégorie des gros MoE qui suivent : ici, la contrainte n'est pas la VRAM mais le runtime. WebGPU sert de pont entre le modèle et la puce graphique de la machine, et la démonstration tient dans une page.

552 milliards de paramètres, une carte, six ans de matériel

À l'autre bout du spectre, un utilisateur détaille ses mesures sur une machine vieille de six ans : Gentoo Linux, Ryzen Threadripper 3990X, 128 Go de DDR4 et une seule RTX 3090 Ti de 24 Go. Il y fait tourner DeepSeek-V4.1-Flash-1017, un MoE de 552B, à 35 tok/s en décodage, et Qwen3.8-Flash-Next à 130 tok/s.

Son constat : cela fonctionne bien mieux qu'avec les modèles plus anciens d'il y a quelques mois. Autrement dit, à matériel constant, c'est le couple modèle/moteur qui a bougé.

La même logique de réemploi apparaît ailleurs : DeepSeek V4.1 Flash en 1M de contexte, entièrement hors ligne via Strata, sur une RX 9070 XT 16 Go, un 5800X3D, 64 Go de DDR4 et un NVMe PCIe 3.0 — les experts répartis entre VRAM, RAM et SSD.

Le goulot n'est plus la génération, c'est le prefill

Sur cette dernière configuration, la génération à ~7 tok/s convenait à son propriétaire. Le point noir était ailleurs : la lecture du prompt. Chaque session OpenCode relisait ~37K tokens de prompt système et d'outils, soit environ 100 s avant le premier token. Il a donc patché le moteur DeepSeek, avec deux changements, pour accélérer d'un facteur 20 le démarrage des sessions d'agent. La réponse, ironique, à Sam Altman qui jugeait « assez terrible » de laisser de la DRAM mondiale dormir dans les ordinateurs personnels.

Même diagnostic sur une autre machine : Qwen 3.8 Flash Next en NVFP4 sur 64 Go de RAM et une RTX 5090, via Basalt, un fork spécialisé. Sous Windows 11, 1,5 Go de VRAM et 6 Go de RAM sont absorbés par le système ; les experts débordent vers la RAM et le CPU, et prefill comme decode chutent de 70 %. Passé à cachy, il atteint près de 9K de prefill, un gain de 2 à 3× qu'il attribue à ninfer et au modèle dense 27b. Il juge la qualité supérieure à qwen 27b sur de nombreuses tâches.

tandem.cpp : garder les experts utiles sur le GPU

Troisième angle, troisième rustine. tandem.cpp, un jeu de patches pour llama.cpp, accélère les modèles MoE trop gros pour la VRAM : les experts les plus utilisés restent sur le GPU, le CPU prend le reste. C'est ciblé sur le décodage mono-utilisateur, et réglé pour Qwen3.8.

Les chiffres annoncés : sur i5-12400F, 64 Go de DDR4 et RTX 4090, Qwen3.8-Flash-Next passe de 29,8 à 97,3 tok/s sur GSM8K, soit 3,3×. Les autres MoE y gagnent 1,4 à 2,1×.

Le principe rejoint celui du patch DeepSeek : arrêter de traiter le dépassement de VRAM comme une fatalité uniforme, et hiérarchiser ce qui reste sur la carte.

Et maintenant ?

Les cinq dépêches décrivent des machines très différentes — un navigateur, une 3090 Ti de six ans, une 9070 XT, une 5090 — mais un même déplacement : la performance ne vient plus seulement du matériel acheté, elle vient du moteur qu'on accepte de patcher. Reste que les gains annoncés sont des mesures isolées, publiées par leurs auteurs, sur des configurations singulières : rien n'y tient lieu de banc d'essai reproductible, et les facteurs 20 ou 3,3 valent pour un usage précis, celui du décodage mono-utilisateur. La remarque attribuée à Sam Altman sur la DRAM « qui dort » sert de fil ironique à l'ensemble, sans qu'aucune de ces expériences ne tranche vraiment le débat.