Meta vient de sortir un modèle de 30 milliards de paramètres avec une cible beaucoup plus intéressante que « gagner deux points sur un benchmark » : faire tourner un agent complet sur une machine personnelle.

Muse Glimmer est publié en open weights sous licence Apache 2.0 selon Meta. Le modèle vise le tool calling, le code, les tâches agentiques longues et l’entrée multimodale texte + image.

La partie à regarder est surtout son budget mémoire.

Le modèle quantifié descend sous 20 Go

Meta estime qu’un modèle 30B en pleine précision demanderait plus de 55 Go de mémoire uniquement pour les poids.

Pour Glimmer, l’entreprise utilise une quantification proche de 4 bits et annonce une version du modèle de langage sous 20 Go. Elle cite notamment un K-Quant de 17 Go dans ses mesures de vitesse.

Ce chiffre n’est pas toute la mémoire nécessaire à l’inférence. Un agent doit encore conserver son cache KV, charger l’encodeur visuel et, dans la configuration proposée par Meta, un petit modèle auxiliaire pour le speculative decoding.

L’objectif annoncé est de faire tenir cet ensemble dans une enveloppe de 24 ou 32 Go.

C’est là que le 30B devient réellement intéressant pour du local. Pas parce que 17 Go est petit, ce serait une définition assez sportive du mot petit, mais parce que cette taille rentre dans des machines haut de gamme déjà présentes sur des bureaux de développeurs et créateurs.

Glimmer est entraîné pour faire plus que répondre

Meta présente le modèle comme une version compacte orientée agent de sa famille Muse.

Il a été entraîné pour appeler des outils avec des schémas précis, maintenir des plans sur plusieurs étapes, récupérer après un appel de fonction raté et travailler dans des scaffolds agentiques. Il accepte aussi des images intercalées avec du texte grâce à un encodeur de perception séparé.

L’entreprise publie des résultats sur SWE-Bench, τ-Bench, MCP-Atlas et d’autres benchmarks agentiques.

Ces résultats restent des évaluations Meta au jour de la sortie. Ils disent ce que l’équipe a mesuré dans ses configurations. Ils ne remplacent pas encore les essais indépendants sur de vrais projets, avec les contextes sales, les outils bizarres et les dépôts qui ont accumulé sept ans de décisions discutables.

Pour IRZ, le point utile n’est donc pas de déclarer un nouveau champion. C’est de voir quel type de modèle Meta essaie de rendre praticable localement.

Un petit modèle vient l’aider à écrire plus vite

Glimmer est livré avec un « drafter » basé sur DFlash.

Le principe du speculative decoding est de laisser ce modèle plus léger proposer plusieurs tokens à l’avance. Le modèle principal vérifie ensuite ces propositions en parallèle, accepte ce qui convient et corrige le reste.

Meta affirme que cette approche accélère la génération sans changer la qualité de sortie du modèle principal. Des versions quantifiées du drafter sont prévues pour limiter leur coût mémoire.

L’entreprise dit avoir mesuré la configuration K-Quant 17 Go avec ce drafter sur MacBook M4 Max, M5 Max et RTX 5090.

Ça ne donne pas encore une vitesse universelle. Le contexte, le cache, la quantification et le matériel changent énormément le résultat. Mais la cible est claire : éviter qu’un agent local prenne tellement de temps entre deux appels d’outil qu’on finit par faire le travail soi-même par fatigue.

Les poids sont là, les intégrations arrivent encore

Les poids sont annoncés disponibles sur Hugging Face dès aujourd’hui.

Il faut être plus prudent avec le reste. Meta indique que les intégrations optimisées pour llama.cpp, MLX et ExecuTorch doivent arriver dans les prochains jours. L’annonce parle aussi d’Ollama, LM Studio et Unsloth comme partenaires à venir.

Donc « Glimmer fonctionne déjà partout » serait prématuré.

Pour l’instant, la sortie intéressante est celle des poids et de la cible matérielle. L’expérience simple dans les outils locaux habituels va dépendre du travail d’intégration qui suit.

Le local commence à être pensé comme une architecture d’agent

Les modèles locaux étaient souvent évalués comme de petites alternatives au chatbot cloud : combien de tokens par seconde, combien de mémoire, quel score de raisonnement.

Glimmer déplace légèrement le cahier des charges. La mémoire doit accueillir non seulement les poids, mais aussi une perception visuelle, un long contexte et un modèle auxiliaire de décodage, pendant que le modèle appelle des outils et reprend après des erreurs.

Le PC ne doit plus seulement héberger un LLM. Il doit héberger une petite pile agentique.

Reste maintenant la partie moins propre et beaucoup plus utile : voir ce que ces 17 à 20 Go donnent une fois branchés à de vrais fichiers, de vrais outils et un utilisateur qui n’a aucune intention de transformer son ordinateur en benchmark permanent.