Muse Glimmer 30B tient dans 24 Go de VRAM

Ce qui a été publié exactement

Muse Glimmer 30B accroche non pas parce que c'est encore un gros modèle, mais parce que Meta le positionne dans l'annonce de lancement et sur la fiche Hugging Face comme un modèle local ouvert pour le codage agentique. La fiche indique 30 milliards de paramètres, Apache 2.0, une date de sortie August 2026 et un contexte de 131 072+ tokens.

Les poids ouverts sont disponibles sur Hugging Face, et le lancement s'accompagne d'une quantification de 17 Go pour fonctionner sur des machines avec 24 Go de mémoire. C'est là la frontière pratique : pas un rack de serveurs, pas une facture cloud, mais un nœud local puissant.

Le modèle est aussi multimodal, avec un accent sur le codage agentique. Le pari n'est pas seulement l'autocomplétion du code, mais le travail en mode agent : lire le contexte, tenir une longue tâche, appeler des outils et revenir au patch. Les 131k tokens ne sont pas un luxe ici, mais une assurance contre la troncature permanente du dépôt.

Les benchmarks semblent solides, mais sans magie

Le sens des benchmarks est simple : Glimmer ne ressemble plus à un modèle local de second rang. Dans les comparaisons annoncées en codage agentique, il est nettement plus fort que Gemma4-31B et se situe à peu près au niveau de Qwen3.6-27B : Glimmer est meilleur sur SWE-Bench Pro, Qwen est plus fort sur Terminal-Bench.

Par ailleurs, la documentation NVIDIA de Muse Glimmer mentionne un SWE-Bench Verified de 76,0. C'est un point utile sur la carte, mais je n'en ferais pas un chiffre culte : les agents de codage cassent non seulement sur la résolution de tâches, mais aussi sur les longues itérations, les dépendances sales et le mauvais usage des outils.

L'affirmation la plus vive sur la vitesse vient d'un petit modèle auxiliaire pour accélérer la génération. Avec lui, on cite pour Glimmer 233 tokens par seconde sur RTX 5090, 50 sur M5 Max et 38 sur M4 Max. C'est joli, mais en conditions réelles, le débit de pointe importe moins que le nombre de tokens qui survivent à la revue.

Ce que cela change pour le codage local

Le changement principal : 24 Go de VRAM deviennent une classe matérielle normale pour un agent de codage local sérieux. Pas pour un chatbot jouet à côté de l'éditeur, mais pour un modèle avec des poids ouverts, un long contexte et une licence Apache 2.0.

Pour moi, ce qui compte ici, c'est la combinaison licence, taille et quantification. Si le modèle peut tourner en local, rester près du code privé et ne pas se heurter immédiatement à une API cloud, les expériences d'ingénierie deviennent beaucoup plus sereines.

Mais le point faible n'a pas disparu : l'agentivité. L'exécution locale ne garantit pas des modifications soignées, des commandes sûres et un travail fluide avec un grand dépôt. La question n'est plus de savoir si un modèle local peut écrire du code, mais combien d'autonomie on peut lui confier sans corde de sécurité.

Pydantic Monty résout le problème de l'exécution sécurisée du code généré par LLM via un interpréteur Python isolé sans conteneurs. Pour un agent de code local comme Muse Glimmer 30B, cela règle directement la question de l'environnement d'exécution du code généré.