Meta lance Muse Glimmer, un modèle d'agent multimodal d'environ 30 milliards de paramètres, prenant en charge un contexte de 128K et fonctionnant sur des appareils avec 24 Go de mémoire GPU. Ce modèle est open-source sous licence Apache 2.0, utilise GQA pour réduire l'occupation du KV Cache, combine une architecture hybride d'attention locale et globale pour diminuer le coût de calcul sur de longs contextes, et propose deux versions quantifiées adaptées à différents niveaux de mémoire GPU. Le module visuel intègre un encodeur ViT Perception dédié pour traiter les captures d'écran et les informations d'écran ; durant l'entraînement, une distillation On Policy est introduite pour couvrir les dérives de contexte sur de longues tâches. Le composant d'accélération DFlash utilise la diffusion par blocs pour prédire les tokens en parallèle, réalisant une amélioration d'environ 3 fois de la vitesse de décodage sur RTX 5090. Le modèle obtient d'excellents résultats sur les benchmarks d'agents tels que MCP Atlas et DeepSearch QA, mais présente encore des possibilités d'amélioration dans les scénarios purement GUI comme OSWorld Verified.

Auteur et source de l'article : Leifengwang

Hier, Meta a lancé Muse Glimmer. Il s'agit d'un modèle d'agent multimodal d'environ 30 milliards de paramètres, prenant en charge un contexte de 128K, capable d'appeler des outils, d'exécuter du code, ainsi que de traiter des images et des informations d'écran.

Ce modèle est open source sous licence Apache 2.0, avec deux versions quantifiées 4-bit, un encodeur visuel indépendant et des composants d'accélération d'inférence DFlash, et propose des déploiements locaux via llama.cpp, MLX, ExecuTorch, etc.

Bien que la taille de 30 milliards de paramètres et le contexte de 128K ne semblent pas exceptionnels aujourd'hui, le problème réside dans le fait que Meta souhaite qu'il serve à établir un modèle complet d'exécution locale d'agent, et non à effectuer des conversations ordinaires.

L'Agent local à long terme destiné à Muse Glimmer fait face à des contraintes techniques exigeantes : il doit traiter des captures d'écran en continu tout en maintenant une logique de tâche s'étendant sur plusieurs dizaines d'étapes, tout cela dans une mémoire GPU limitée à 24 Go. Après plusieurs dizaines d'étapes, les résultats des outils précédents, les journaux de code, l'état des pages et les processus d'inférence s'accumulent continuellement dans le contexte.

À ce moment-là, de nombreux problèmes peu visibles dans les scénarios de discussion s’amplifient rapidement. Comment insérer un contexte de 128K dans une mémoire GPU limitée ? Comment gérer l’état historique lorsque les captures d’écran deviennent de plus en plus nombreuses ? Comment le modèle continue-t-il après un échec d’appel d’outil ? Et à quel point les nombreux tokens de raisonnement ralentissent-ils le décodage ?

La conception technique de Muse Glimmer s'articule essentiellement autour de ces questions. Elle ne repose pas sur une nouvelle architecture particulièrement remarquable pour résoudre tous les problèmes, mais effectue des compromis audacieux sur l'Attention, le KV Cache, les méthodes d'entraînement, la quantification et le Decode.

Si les modèles locaux précédents étaient « capables de fonctionner », Muse Glimmer vise à être « aussi facile à utiliser et aussi performant en continu qu’un modèle cloud ».

En regardant ces parties ensemble, il est plus facile de comprendre pourquoi Meta l'a conçu tel qu'il est aujourd'hui, plutôt que de les examiner séparément, comme 30B ou 128K.

Comment compresser 128K de contexte dans 24 Go de VRAM ?

Muse Glimmer utilise 52 couches Dense Transformer, une taille cachée de 6656, 32 têtes de requête, mais seulement 2 têtes KV.

L'attention n'applique pas le contexte complet à chaque couche, mais utilise plutôt une boucle de trois attention locales suivies d'une attention globale.

L'attention locale ne traite que les 2048 tokens voisins, tandis que l'attention globale gère les échanges d'informations à plus longue distance.

Ces deux conceptions augmentent simultanément le coût des longs contextes. Lorsque le modèle génère un nouveau token, il met en cache les clés et valeurs des tokens précédents, également appelés KV Cache. Plus le contexte est long, plus cette partie occupe de mémoire.

Muse Glimmer dispose de seulement 2 KV Heads par couche, avec une dimension de 128 par head. Selon un calcul approximatif en BF16, un token occupe environ 1024 Go dans une couche pour les KV.

Si les 52 couches conservent intégralement un contexte de 128 K, le cache KV nécessiterait environ 6,5 GiB. Toutefois, Muse Glimmer compte réellement 39 couches locales et 13 couches globales. Les couches locales ne doivent conserver qu'une fenêtre glissante d'environ 2048 tokens, seules les couches globales nécessitent de sauvegarder le contexte long complet.

En estimant de la même manière, le KV Cache peut être réduit à environ 1,7 GiB. Ce n'est pas la mémoire GPU en temps réel publiée officiellement, mais une estimation théorique basée sur les paramètres d'architecture publiés ; toutefois, cela suffit à expliquer pourquoi cette architecture a été conçue ainsi.

S'il n'utilise pas 2 KV Heads, mais conserve des KV indépendants pour les 32 Heads, comme dans l'MHA traditionnelle, sous les mêmes conditions, le KV Cache théorique augmenterait encore d'environ 16 fois, atteignant directement plus de 20 GiB.

Le cache KV seul dépasse déjà une carte graphique de 24 Go. Deux méthodes sont en réalité utilisées ici : le GQA réduit le nombre de KV à sauvegarder par token, tandis que l'attention locale réduit le nombre de couches nécessitant de conserver les KV complets sur le long terme.

Après avoir effectué cette étape, la quantification des poids prend tout son sens. Le poids de Muse Glimmer avec K Quant 17GB est d'environ 16,8 Go, le module visuel environ 1,4 Go, et DFlash environ 1,6 Go ; ensemble, ces composants atteignent déjà près de 20 Go. Cette version est conçue pour les appareils avec 24 Go de mémoire vidéo, tandis qu'une autre version de 20 Go avec Dynamic K Quant est destinée aux appareils avec 32 Go.

Les deux quantifications ne diffèrent pas seulement par la taille du fichier. Parmi les 15 benchmarks fournis par Meta, la perte moyenne de précision pour Dynamic K Quant est d'environ 0,2 %, tandis que pour K Quant 17 Go, elle est d'environ 1,0 %.

Autrement dit, la version 24 Go réduit davantage la mémoire vidéo, occupant moins d'espace, mais nécessite d'accepter une perte de performance légèrement plus marquée. La version 32 Go cherche à préserver au maximum les performances du modèle d'origine.

Le contexte de 128K de Muse Glimmer repose sur cette combinaison. L'attention réduit d'abord la charge de calcul, le GQA réduit ensuite le KV Cache, et enfin la quantification diminue les poids du modèle.

Cette approche comporte un coût. Les 39 couches Local ne peuvent accéder directement qu'à 2048 tokens voisins ; les informations à longue distance doivent être propagées via la couche Global. Ainsi, pouvoir entrer 128K n'est pas la même chose que pouvoir l'utiliser de manière stable dans sa totalité.

Les résultats de Beam128K de Meta montrent que cette architecture hybride locale et globale conserve toujours une bonne capacité à exploiter les informations à long terme, mais elle résout le problème du contexte long, pas de la mémoire à long terme. Quelles informations doivent être conservées, lesquelles sont obsolètes et quand mettre à jour l'état reste à la charge de l'Agent Runtime.

This issue becomes even more apparent with the visual agent.

128K n'est pas un espace infini

Muse Glimmer comprend également un encodeur de perception ViT G 14 d'environ 1,8 milliard de paramètres, conçu pour traiter les captures d'écran, les pages web, les graphiques et les documents. Une image peut être convertie en jusqu'à 4096 jetons visuels.

Il s'agit actuellement d'entrées texte et image avec une sortie texte, et non d'intégrer tous les modalités dans un seul modèle de génération.

Dans le flux de travail de l'Agent, cette capacité visuelle est principalement chargée de lire l'état de l'environnement. L'Agent d'utilisation de l'ordinateur observe d'abord l'écran actuel, identifie la position des pages, des boutons et du texte, puis effectue une action. Une fois la page modifiée, il lit la nouvelle capture d'écran et décide de la prochaine étape.

Les entrées visuelles continuent donc d’entrer dans le contexte. Si toutes les captures d’écran des dizaines d’étapes sont conservées intégralement, même avec une capacité de 128K, le contexte sera rapidement saturé par les tokens visuels. Les captures d’écran antérieures pourraient également entrer en conflit avec l’état actuel. La page a changé, mais les boutons et fenêtres précédents restent encore dans le contexte, obligeant le modèle à effectuer une évaluation supplémentaire pour déterminer quel est l’état le plus récent.

Meta n' conserve pas non plus l'historique des captures d'écran à l'infini dans l'évaluation OSWorld Verified, mais uniquement les captures les plus récentes. Cela montre que l'encodeur de perception et la gestion du contexte sont deux problèmes distincts.

Le premier est chargé de convertir l'écran actuel en informations compréhensibles pour le modèle, tandis que le second détermine quels états historiques conservent de la valeur et lesquels doivent être supprimés. Ainsi, 128K offre plutôt au modèle un espace de travail plus vaste, sans supprimer la gestion d'état.

Et au fur et à mesure que l'agent interagit continuellement avec l'environnement, la question passe de ce que le modèle a vu à ce que le modèle vient de faire.

Ceci débute la phase d'entraînement de Muse Glimmer.

Comment continuer après un écart de l'agent

Muse Glimmer est distillé à partir de Muse Spark.

Meta divise l'entraînement en Pre Training, Mid Training et Post Training. Le Pre Training utilise la distillation de logit, le Mid Training intègre davantage de données à long contexte, de traces de raisonnement et d'agents, et le Post Training ajoute ensuite la SFT, la distillation on-policy et le RL.

La distillation de logit présente une légère différence par rapport à l'entraînement d'un petit modèle en utilisant simplement les réponses d'un grand modèle. Lorsque l'enseignant prédit le prochain token, il fournit une distribution de probabilité sur l'ensemble du vocabulaire. L'élève n'apprend pas seulement le token finalement sélectionné, mais aussi les jugements relatifs de l'enseignant sur les autres candidats.

Cela est utile pour l'agent, car de nombreux scénarios n'ont pas d'action unique. Face à une page web, le modèle peut continuer à rechercher, ouvrir un résultat spécifique ou changer d'outil. La distribution de probabilité du professeur inclura ses préférences pour ces actions, et non seulement le texte final produit.

Au Mid Training, l'entraînement passe de réponses individuelles à des trajectoires de tâches complètes. Après l'exécution d'un outil, l'environnement change : la recherche retourne de nouveaux résultats, l'exécution du code échoue et génère des erreurs, et une interaction incorrecte avec l'interface graphique modifie la page. Autrement dit, la sortie de l'Agent modifie directement l'entrée suivante.

Supposons que la trajectoire correcte de Teacher soit A vers B, puis C, enfin D. Si Student n'apprend que les données de Teacher, il verra répétitivement A vers B, puis B vers C. Mais en cours d'exécution réelle, Student pourrait dès la première étape atteindre un autre état B.

À partir de ce moment, l'environnement a changé, et les transitions de B à C dans l'ensemble d'entraînement ne peuvent pas directement lui indiquer comment réagir maintenant. L'On Policy Distillation intervient précisément ici. L'élève effectue d'abord un Rollout pour entrer dans les états qu'il produira réellement, puis reçoit une supervision provenant d'un modèle plus puissant sur ces états.

Les données d'entraînement ne contiennent donc plus seulement la trajectoire idéale de l'enseignant, mais couvrent également les états d'erreur générés par l'étudiant. Cela est directement lié à la notion de récupération en cas d'échec mise en avant par Muse Glimmer.

Après une erreur de saisie de paramètres, si le modèle peut comprendre l'erreur et effectuer un nouvel appel d'outil, la tâche peut continuer. Si l'on se rend sur une page incorrecte, tant qu'on peut identifier que l'état actuel est erroné, il est possible de revenir en arrière ou de changer de chemin. Le véritable problème survient lorsque le modèle ne reconnaît pas l'erreur et continue d'agir sur la base d'un état erroné, accumulant ainsi progressivement les écarts.

Ainsi, les capacités d’un agent ne doivent pas être évaluées uniquement sur la base de la correction d’un seul appel d’outil, mais aussi sur la capacité à accomplir la tâche dans son ensemble et à se rétablir en cas d’erreur intermédiaire. Cela explique pourquoi Muse Glimmer obtient de meilleurs résultats sur certains benchmarks d’agents à long processus.

Cependant, le fait que la tâche puisse être accomplie ne signifie pas qu'il n'y ait plus de problèmes lors de l'exécution locale. Si une tâche complexe génère un grand nombre de tokens de raisonnement, le nouveau goulot d'étranglement deviendra rapidement le décodage.

Deux questions l'une après l'autre

Muse Glimmer prend en charge quatre niveaux de force de raisonnement : low, medium, high et xhigh. Ce paramètre peut être compris comme un budget d'inférence en temps réel.

Les niveaux supérieurs permettent généralement au modèle de générer davantage de tokens de raisonnement, ce qui peut augmenter le taux de réussite sur des tâches complexes de codage et d'agent, mais le coût est direct : le contexte augmente plus rapidement et le temps de décodage s'allonge.

Meta utilise une force de raisonnement élevée dans ses benchmarks publics. Cela a conduit à DFlash.

Le décodage de Transformer est autoregressif. Le deuxième token doit attendre le premier, le troisième dépend du deuxième. Pour des réponses de quelques centaines de tokens, cela reste acceptable, mais une tâche d'agent peut générer au total des milliers, voire des dizaines de milliers de tokens.

La méthode de décodage spéculatif consiste à ajouter un Drafter plus petit. Le Drafter prédit d'abord une série de tokens futurs, puis le modèle principal les valide en une seule étape. Si plusieurs candidats peuvent être acceptés consécutivement, cela réduit le nombre d'étapes de décodage exécutées par le modèle principal de 30 milliards.

Le problème avec les solutions traditionnelles est que le Drafter lui-même est généralement un modèle autoregressif. S'il doit générer 16 tokens, il doit encore les produire un par un.

DFlash a remplacé cette section par Block Diffusion.

La taille du bloc DFlash de Muse Glimmer est de 16, ce qui permet de prédire en parallèle un ensemble de tokens candidats. Toutefois, être plus rapide n'est pas suffisant pour Drafter. Si les prédictions sont imprécises, le modèle principal rejette un grand nombre de candidats, et l'avantage de vitesse initial disparaît rapidement.

Ainsi, DFlash lit directement les Fonctionnalités Cachées des couches 1, 13, 25, 37 et 49 de Muse Glimmer et transmet ces représentations intermédiaires au Drafter, qui ne possède que 5 couches. Ainsi, le Drafter n’a pas besoin de réinterpréter le contexte complet, mais peut directement exploiter les représentations internes déjà formées par le modèle principal de 30B.

Ces fonctionnalités ne sont pas utilisées uniquement une fois en entrée, mais sont continuellement injectées dans les clés et valeurs de chaque couche du Drafter pour éviter qu'elles ne s'affaiblissent progressivement à mesure que le réseau s'approfondit.

Il y a un autre détail lors de l'entraînement : dans un bloc de 16 tokens, les tokens initiaux sont plus importants que les suivants. Si le premier token est incorrect, même si les suivants sont devinés correctement, la longueur d'acceptation continue sera très courte.

Ainsi, DFlash attribue un poids de perte plus élevé aux jetons situés avant le bloc, puis il diminue progressivement. Il optimise le préfixe acceptable le plus long possible, et non simplement la précision moyenne sur les 16 positions. Dans les données K Quant de 17 Go fournies par Meta, la vitesse de décodage sur RTX 5090 passe d'environ 74,9 jetons/s à 233,4 jetons/s.

Si une tâche Agent génère cumulativement 10 000 tokens, en ne considérant que le décodage, la première prend environ 134 secondes, la seconde environ 43 secondes. Les tâches réelles incluent également le préremplissage, l'exécution d'outils et des attentes réseau, mais pour un Agent à forte puissance de raisonnement, cet écart influence déjà notablement l'expérience complète de la tâche.

High Reasoning Strength augmente la génération de tokens, tandis que DFlash réduit le temps nécessaire à cette opération. Un contexte long augmente le KV Cache, et GQA ainsi que l'attention locale réduisent la consommation mémoire. La quantification permet de maintenir les poids du modèle dans une plage supportée par les cartes graphiques grand public.

En outre, Muse Glimmer obtient de bons résultats sur les benchmarks d'agents tels que MCP Atlas, DeepSearch QA et Gaia2. Ces tâches nécessitent des chaînes d'exécution longues.

MCP Atlas nécessite que le modèle sélectionne et appelle des outils entre plusieurs serveurs MCP. DeepSearch QA doit effectuer des recherches continues, ouvrir des pages, rechercher des informations, puis poursuivre en fonction des nouveaux résultats. Gaia2 simule des applications avec état telles que le courrier électronique, le calendrier et les contacts, et l'environnement lui-même évolue pendant le déroulement de la tâche.

Ces tâches sont plus en accord avec la méthode d'entraînement de Muse Glimmer. Toutefois, sur OSWorld Verified, TerminalBench et SWE Bench Verified, il ne conserve pas cet avantage. Par exemple, sur OSWorld Verified, Muse Glimmer obtient un score de 65,9 contre 75,6 pour Qwen3.6 27B. Sur TerminalBench 2.1, Muse Glimmer atteint 51,7 contre 60,7 pour son concurrent.

Sa répartition des capacités est donc plus claire. L'Agent de recherche, la collaboration avec les outils et les tâches à long processus affichent de meilleures performances, tandis que les scénarios purement GUI, terminal et une partie des Agents de codage présentent encore un espace de progression notable. Ces scores ne doivent pas être interprétés strictement selon les classements traditionnels des modèles.

Les résultats de l'Agent Benchmark peuvent également être influencés par le System Prompt, la définition des outils, le scaffold, le nombre maximal d'étapes d'exécution, les paramètres d'échantillonnage et même le modèle de jugement. Meta lui-même précise que les outils d'agent et les System Prompts utilisés par des modèles tiers ne sont pas nécessairement optimisés spécifiquement pour eux.

Ainsi, à l'étape Agent, il devient de plus en plus difficile de décrire la situation complète en comparant uniquement les checkpoints. La sécurité pose un problème similaire.

L'exécution locale réduit effectivement l'envoi fréquent de fichiers, de captures d'écran et de contextes privés vers le cloud, mais cela ne résout que le chemin des données. Les injections de prompt, les appels d'outils erronés, les dépassements de permissions et les opérations irréversibles persistent toujours. Meta a également évalué séparément les risques agentic, la vie privée et les injections de prompt, et recommande d'ajouter davantage de garde-fous et des mécanismes humains nécessaires lors d'un déploiement réel.

A clear capability roadmap

La chaîne complète de la technologie de Muse Glimmer peut finalement être reliée à une trajectoire plus claire.

La taille du modèle est limitée à environ 30 Go, GQA et Local Attention réduisent le coût mémoire GPU pour un contexte de 128K, la quantification permet au modèle de s'exécuter sur des appareils de 24 Go et 32 Go, l'encodeur de perception est chargé de lire l'environnement visuel, la distillation on-policy gère les dérives d'état dans les tâches longues, la puissance de raisonnement permet aux développeurs de contrôler le budget d'inférence, et DFlash traite la latence de décodage causée par un grand nombre de tokens de raisonnement.

Muse Glimmer n'a pas démontré qu'un modèle local de 30B pouvait remplacer les modèles Frontier hébergés dans le cloud, mais elle a prouvé que l'aboutissement d'un modèle local de 30B ne réside pas dans la simple échelle, mais dans l'ingénierie systémique visant à équilibrer ensemble diverses contraintes matérielles. Elle a intégré dans une même conception système les quatre contraintes les plus difficiles à gérer dans un agent local : la mémoire vidéo, le contexte, la perception de l'état de l'environnement et la vitesse d'inférence.

Muse Glimmer, bien qu'il ne puisse pas encore remplacer complètement les modèles phares du cloud, a tracé une voie réalisable à l'échelle industrielle vers l'objectif « chaque individu a son propre Agent ».