Muse Spark Open dévoilé : un modèle multimodal de 816 milliards de paramètres

Le modèle multimodal à poids ouverts de Meta, Muse Spark Open, a été présenté le 15 octobre 2026 sur le blog de Hugging Face. Entraîné, selon les informations communiquées, pour des workflows de programmation, il peut traiter des entrées textuelles, visuelles, audio et vidéo, puis générer du texte. Il compte environ 816 milliards de paramètres au total et, grâce à son architecture Mixture-of-Experts (MoE), en active environ 42 milliards pour chaque token.

Quels types d’entrées Muse Spark Open peut-il traiter ?

Le modèle peut combiner différents types de médias dans un même système. Les images et les images vidéo sont transmises au modèle de langage par un encodeur de perception ; l’audio passe par un encodeur audio distinct. L’article de Hugging Face donne des exemples où le modèle lit des captures d’écran, écoute des notes vocales et examine des enregistrements d’écran. Les sorties du modèle se limitent au texte.

Par défaut, la vidéo est échantillonnée à 2 images par seconde, avec un maximum de 96 images traitées. Il est possible d’augmenter la fréquence d’images, mais la source précise que cela peut accroître les besoins en mémoire et la latence du prétraitement. Pour une entrée audio traitée directement, le modèle attend un signal mono avec une fréquence d’échantillonnage de 24 kHz. Sa fenêtre de contexte peut atteindre 1 million de tokens, en comptant ensemble les tokens textuels et multimédias.

Architecture MoE et besoins matériels

Chacune des couches MoE de Muse Spark Open comprend 256 experts, dont 8 sont sélectionnés pour chaque token. Cette conception maintient le nombre de paramètres actifs pendant le calcul à environ 42 milliards ; toutefois, tous les experts doivent être présents en mémoire. Le nombre de paramètres actifs ne suffit donc pas, à lui seul, à indiquer la quantité de mémoire nécessaire pour exécuter le modèle complet.

D’après les informations techniques publiées par Hugging Face, les fichiers de poids BF16 au format safetensors occupent environ 1,5 To. Pour exécuter la version BF16 avec Transformers, la configuration indiquée comprend 4 nœuds équipés de 8 GPU H200 ; pour la version NVFP4, il s’agit d’un seul nœud B200. NVFP4 est décrit comme un format 4 bits conçu pour les GPU NVIDIA Blackwell. L’article estime également qu’une fenêtre de contexte complète de 1 million de tokens pourrait nécessiter environ 266 Go de cache KV en BF16.

Programmation et options de déploiement

Le modèle a été entraîné pour répondre aux workflows de développement, notamment la refactorisation de plusieurs fichiers et les longues sessions de débogage. Il prend également en charge les appels d’outils et peut aborder les tâches longues en planifiant, en agissant, en observant les résultats et en s’autocorrigeant. Ces caractéristiques montrent que le produit est principalement axé sur la programmation et l’utilisation d’outils à partir d’entrées multimodales, et non sur la génération directe d’images.

L’article de Hugging Face décrit les composants MuseSparkForConditionalGeneration et MuseSparkProcessor dans Transformers. DistributedConfig sert à configurer l’exécution distribuée. L’article renvoie également à des instructions d’exécution pour llama.cpp, vLLM et SGLang. Le texte publié ne précise ni le prix ni les détails de la licence d’utilisation ; avant tout déploiement, il convient donc de vérifier séparément la licence et les exigences matérielles indiquées dans le dépôt des poids.

Conséquences pour les workflows d’architecture et de visualisation

Pour les architectes, les architectes d’intérieur et les équipes de visualisation, l’intérêt pratique du modèle pourrait être sa capacité à examiner des images et des enregistrements vidéo en parallèle du texte. Par exemple, la possibilité de poser des questions sur une capture d’écran ou un enregistrement de travail pourrait être testée dans les processus de conception et d’évaluation technique ; toutefois, la source ne mentionne ni plug-ins pour les logiciels d’architecture ni fonction dédiée à l’analyse de rendu. Il s’agit donc d’un usage potentiel rendu possible par la prise en charge des entrées multimodales, et non d’une fonction déjà disponible.

Le principal obstacle reste le matériel. Les configurations d’exécution décrites nécessitent des systèmes dotés d’une très grande capacité mémoire ; les bureaux qui envisagent une utilisation locale du modèle ne doivent donc pas se fier uniquement au nombre de paramètres actifs par token. Le format des poids, la compatibilité GPU, les besoins en mémoire et les conditions de licence doivent être examinés ensemble.