Meta ouvre Muse Spark Open : un MoE de 816 milliards de paramètres et un contexte de 1 million de tokens

Meta a publié Muse Spark Open, un modèle multimodal open-weight à architecture mixture-of-experts. Il compte environ 816 milliards de paramètres au total, dont environ 42 milliards sont activés pour chaque token, et sa fenêtre de contexte atteint un million de tokens. Il accepte en entrée du texte, des images, de l'audio et de la vidéo, et produit du texte en sortie. Selon la description de Hugging Face, c'est aujourd'hui le modèle ouvert américain le plus performant. Meta l'a entraîné avant tout pour le codage agentique : lire une base de code, écrire et déboguer du code, appeler des outils, planifier, agir, observer le résultat et se corriger sur des tâches longues.

Muse Spark Open est le modèle haut de gamme de la gamme Muse. En août, Meta avait publié Muse Glimmer, un petit modèle dense destiné à l'exécution locale. Les deux modèles partagent le même tokenizer et le même vocabulaire, et le chat template du nouveau modèle étend celui de Glimmer pour couvrir les nouvelles modalités. Concrètement, une capture d'écran, une note vocale ou un enregistrement d'écran peuvent être transmis au modèle même qui est en train de corriger votre code.

Où se cachent les 816 milliards

La partie langage compte 62 couches, avec une dimension cachée de 8192. L'attention est de type grouped-query : 128 têtes de query et 16 têtes key-value de 64 dimensions. Le modèle comprend une porte de sortie, une normalisation en sortie de bloc et une QK-norm pour les requêtes et les clés.

Au lieu d'une simple somme, le bloc combine l'entrée et la sortie via une porte résiduelle (residual gate) apprenable. Dans Glimmer, chaque couche comporte un réseau feed-forward dense unique ; dans Muse Spark Open, il est remplacé par un bloc MoE : 256 experts, dont le routeur en sélectionne 8 par token. Chaque expert projette 8192 vers 4096, puis de nouveau vers 8192, et normalise sa propre sortie.

Les experts représentent environ 97 % de tous les paramètres.

D'où le principal compromis du MoE : les 256 experts doivent tous résider en mémoire, donc le déploiement exige les ressources d'un modèle de 816B, mais chaque token est calculé sur ~42B, ce qui accélère nettement la génération. Les embeddings d'entrée et la couche de sortie sont des matrices distinctes, d'environ 1,66 milliard de paramètres chacune.

Yeux, oreilles et un million de tokens

Les images et les images de vidéo sont converties en tokens par un perception encoder de 1,8 milliard de paramètres : 50 couches, dimension 1536, 16 têtes d'attention, patchs de 14×14 et features de dimension 4096. Une couche sur quatre, ainsi que la dernière, utilise l'attention complète ; les autres utilisent une attention éparse. Les positions sont encodées par des embeddings absolus apprenables et par du RoPE 2D. Le même encodeur équipe Muse Glimmer 30B.

L'audio est traité par une tour distincte, qui exige un signal mono à 24 kHz : un token audio correspond à 80 ms, soit 12,5 tokens par seconde. Dix secondes d'enregistrement produisent 125 tokens. L'encodeur est une pyramide convolutive avec des patch embedders de tailles 16, 6, 5 et 4. La vidéo est échantillonnée par défaut à 2 images par seconde, avec un maximum de 96 images, et peut désormais être accompagnée du son, ce que Glimmer ne savait pas faire. Les images sont entrecoupées de repères temporels textuels du type « Time: 3.5s ». Plus le FPS est élevé, plus les événements entre deux images sont captés avec précision, mais la mémoire et la latence du prefill augmentent.

Le contexte est de 1 048 576 tokens, et les images, la vidéo et l'audio partagent cette fenêtre avec le texte. Grâce au GQA, le cache reste modéré : chaque token ajoute 2 × 16 × 64 × 62 = 126 976 valeurs, soit environ 250 Ko en BF16 et environ 266 Go pour le million de tokens complet.

Caractéristiques clés

• Taille : ~816B de paramètres au total, ~42B actifs par token
• Routage : 256 experts par couche MoE, 8 par token
• Entrée : texte, images, audio, vidéo ; sortie : texte
• Contexte : jusqu'à 1M de tokens
• Couches : 62, dimension cachée 8192, 128 têtes query et 16 têtes KV
• Encodeur vision : 1,8B de paramètres, 50 couches
• Audio : 12,5 tokens par seconde, 24 kHz mono
• Checkpoints : BF16 (~1,5 To, safetensors) et NVFP4 (4 bits, pour NVIDIA Blackwell, avec, d'après les déclarations, une perte de précision négligeable)
• Dépôts : Muse-Spark-Open-816B-A42B et Muse-Spark-Open-816B-A42B-NVFP4

Comment l'exécuter et ce qu'il faut savoir

La bibliothèque transformers fournit les classes MuseSparkForConditionalGeneration et MuseSparkProcessor. Le processeur réunit le tokenizer, les gestionnaires d'images et de vidéo, l'extracteur audio et le chat template. Le parallélisme se configure via DistributedConfig : tp_size répartit les couches denses en shards, ep_size répartit les experts entre les appareils. Dans transformers, la version BF16 tourne sur quatre nœuds de 8 GPU H200 avec un tensor parallelism TP=32, et la version NVFP4 sur un seul nœud B200. Pour la production, Hugging Face a préparé des recettes pour llama.cpp, vLLM et SGLang. L'appel d'outils est pris en charge, y compris en mode multimodal.

Le raisonnement appelle une précision : il ne peut pas être désactivé. Les niveaux low, medium, high et xhigh correspondent aux valeurs 16, 64, 256 et 512, et xhigh est le niveau par défaut. Pour les tâches simples, réglez-le sur low, sinon des tokens seront gaspillés. La valeur numérique peut aussi être définie par une ligne « Reasoning strength » dans le prompt système. Pour les équipes qui construisent des agents de codage, la question centrale n'est désormais plus la disponibilité des poids, mais le budget matériel et la mémoire à prévoir pour le KV-cache sur les contextes longs.