AIREITERLes démonstrations publiées de Muse Spark Open exigent au minimum deux Mac Studio avec la mémoire maximale. Pour la grande majorité des développeurs, mieux vaut donc commencer par le tester via une API hébergée.
Faut-il utiliser Muse Spark Open ?
Muse Spark Open mérite d’être évalué pour des workflows d’agents privés et de longue durée, en particulier lorsqu’une équipe a besoin de poids téléchargeables et d’une large compatibilité avec les runtimes. Ce n’est toutefois pas le choix par défaut pour les tâches de code courantes : son coût d’infrastructure est extrême et les scores de programmation communiqués par Meta restent derrière plusieurs alternatives open-weight.
| Situation | Recommandation | Pourquoi |
|---|---|---|
| Tester la qualité d’un agent ou de l’usage d’outils | Passer par un fournisseur hébergé | Pas de cluster à acheter ni de configuration MLX distribuée |
| Workflows privés sur site | Envisager l’auto-hébergement | Les poids restent sous le contrôle de l’organisation |
| Génération de code au quotidien | Comparer d’abord des modèles plus petits | Muse Spark Open ne domine pas les tests de code cités |
| Un GPU grand public ou un Mac | Ne pas auto-héberger | Le checkpoint 4 bits ne laisse aucune marge pour l’espace de travail d’inférence |
| Service commercial d’API de modèles | Examiner d’abord la licence | Un seuil de revenus et une clause d’accord distinct peuvent s’appliquer |
| Charge de travail complète de 1M tokens | Valider avec des données représentatives | Les tests Apple publiés s’arrêtent à 65,536 tokens |
Il s’agit bien d’un lancement officiel, et non d’un aperçu. Meta a publié Muse Spark Open le 15 octobre 2026, avec des poids téléchargeables et un accès auprès de sept fournisseurs d’inférence nommément cités.
Ce que Meta a réellement publié
Muse Spark Open est un modèle open-weight multimodal natif de type mixture-of-experts, conçu pour le code, l’ingénierie logicielle, l’utilisation d’outils et les agents à longue échéance. Il accepte du texte, des images, de l’audio et de la vidéo en entrée, et produit du texte en sortie.
| Caractéristique | Valeur publiée |
|---|---|
| Nombre total de paramètres | 816B |
| Paramètres actifs par token | 42B |
| Fenêtre de contexte | 1M tokens |
| Formats de poids | BF16 et NVFP4 |
| Couverture linguistique d’entraînement | Plus de 100 langues |
| Fournisseurs d’API hébergées cités par Meta | 7 |
| Runtimes pris en charge cités par Meta | 7 |
Avec 42B paramètres actifs, le modèle ne calcule pas sur l’ensemble des 816B paramètres à chaque token. Le stockage reste néanmoins la contrainte la plus lourde : Apple indique que les paramètres BF16 natifs demandent plus de 1.6TB de mémoire, tandis que le checkpoint NVFP4 en 4 bits occupe environ 493GB avant même l’espace de travail d’inférence et la mémoire de contexte.
« Open-weight » est le terme juste. Les développeurs peuvent télécharger, modifier, affiner, distiller et distribuer le modèle sous la Muse Model License, mais celle-ci prévoit une attribution, des restrictions d’usage et des conditions particulières pour certaines activités de modèles en tant que service. Ces dispositions ne correspondent pas à une licence open source permissive classique.
La réalité du déploiement local
Déployer Muse Spark Open localement est techniquement crédible, mais exigeant financièrement et opérationnellement. Meta présente deux Mac Studio M5 Ultra avec jusqu’à 512GB de mémoire unifiée chacun ; le rapport d’Apple sur l’inférence MLX distribuée mesure des configurations à deux et quatre machines.
Pourquoi un seul Mac de 512GB ne suffit pas
Un Mac Studio de 512GB ne peut pas contenir le checkpoint NVFP4 d’environ 493GB, en plus de la mémoire nécessaire aux traitements intermédiaires d’inférence. Apple répartit donc le modèle entre plusieurs machines au moyen de MLX et de RDMA via Thunderbolt 5.
Le test d’Apple utilisait macOS 26.2, MLX 0.30.1 ou version ultérieure, le backend de communication jaccl, ainsi que deux câbles Thunderbolt entre les pairs. Il portait sur des contextes de 8,192 et 65,536 tokens, avec 128 tokens générés pour une taille de lot de un.
| Configuration Apple, prompt de 8,192 tokens | Temps jusqu’au premier token | Vitesse de décodage |
|---|---|---|
| 2 M5 Ultra, parallélisme de pipeline | 8.4 s | 15.74 tok/s |
| 2 M5 Ultra, parallélisme tensoriel | 8.2 s | 24.99 tok/s |
| 4 M5 Ultra, parallélisme tensoriel | 4.8 s | 36.73 tok/s |
Le chiffre à quatre machines constitue la vitrine de performances, pas le déploiement minimal. La configuration à deux machines de Meta montre que le modèle tient et fonctionne ; les mesures d’Apple illustrent à quel point la topologie change l’expérience.
Parallélisme de pipeline ou tensoriel
Le parallélisme de pipeline découpe le modèle selon la profondeur des couches et représente la solution la plus simple pour répartir les poids sur deux machines. Il nécessite relativement peu de communications, mais l’exécution séquentielle des couches limite l’accélération du décodage.
Le parallélisme tensoriel répartit chaque couche entre les machines. Apple a mesuré 24.99 tokens par seconde sur deux systèmes M5 Ultra, soit 59% de plus que les 15.74-token obtenus en pipeline lors du test à 8,192 tokens. En contrepartie, les communications sont plus lourdes : à 65,536 tokens, Apple a constaté que le préremplissage tensoriel sur deux machines pouvait être plus lent que le préremplissage en pipeline.
Performances : solide sur deux tests d’agents, moins sur le code
Muse Spark Open arrive en tête de deux comparaisons publiées sur les agents et l’usage d’outils, mais pas de tous les benchmarks agentiques. Les valeurs ci-dessous sont rapportées par Meta et n’ont pas été reproduites indépendamment : elles justifient une présélection, pas une décision de production.
| Benchmark | Muse Spark Open | Meilleure comparaison citée |
|---|---|---|
| JobBench | 61.8 | GLM 5.3: 61.4 |
| MCP-Atlas | 89.2 | Qwen3.8: 84.5 |
| Terminal-Bench 2.1 | 76.4 | Kimi K3: 85.0 |
| DeepSWE 1.1 | 60 | Kimi K3: 68 |
| SWE-Atlas-QnA | 58 | Kimi K3: 66 |
| GPQA Diamond | 89.0 | Kimi K3 and Qwen3.8: 93.5 |
Muse Spark Open devance de 0.4 point le score suivant affiché sur JobBench, et de 4.7 points sur MCP-Atlas. Sur Terminal-Bench 2.1, il est derrière Kimi K3 de 8.6 points et GLM 5.3 de 7.5 points.
Meta décrit aussi deux démonstrations locales : la modification et la compilation de l’application iOS open source Ice Cubes, puis l’utilisation de DaVinci Resolve pour inspecter des séquences et produire des recadrages verticaux. Aucune de ces démonstrations ne communique de taux de réussite, de durée, de nombre d’interventions ou de fichiers de tâches reproductibles : elles illustrent donc une capacité, pas une fiabilité.
Les éléments de preuve indépendants en production pour le checkpoint Open publié restent limités.
Des conditions de licence qui peuvent bloquer un déploiement
La Muse Model License autorise des usages étendus, mais impose des conditions que les équipes produit et juridiques doivent examiner avant tout déploiement. Les principaux points bloquants sont l’attribution, le seuil lié au modèle en tant que service et les règles sur les usages interdits.
| Point de licence | Effet pratique |
|---|---|
| Attribution | Les produits et services doivent afficher de façon visible « Built with Muse Spark Open » |
| Seuil pour les modèles en tant que service | Les entreprises dépassant $20M de chiffre d’affaires brut agrégé sur une période consécutive de 12 mois doivent notifier Meta et obtenir un accord distinct avant de proposer un accès au modèle concerné |
| Usage interne ou produit embarquant le modèle | La disposition citée sur les modèles en tant que service ne s’applique pas de la même manière à un usage interne ou à un modèle alimentant un produit qui n’est pas un service de modèles |
| Restrictions d’usage | La politique restreint notamment les domaines des malwares, des armes, des infrastructures critiques, de la fraude et de l’usurpation d’identité non autorisée |
| Déclaration d’âge | Le modèle n’est pas destiné aux personnes de moins de 18 ans |
La clause des $20 millions n’est pas un tarif d’API. C’est un seuil de licence lié à une activité éligible de modèle en tant que service. Intégrer Muse Spark Open dans une application peut demander une analyse différente de celle d’une revente via un endpoint d’inférence.
Comment accéder à Muse Spark Open dès maintenant
Muse Spark Open est disponible via des API hébergées et des catalogues de modèles téléchargeables. Meta cite Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter et Together AI pour l’accès hébergé ; les poids sont référencés via Hugging Face, Amazon SageMaker AI, Google Cloud Model Garden et Microsoft Foundry Models.
Les runtimes pris en charge incluent SGLang, vLLM, TensorRT-LLM, Hugging Face Transformers, MLX, llama.cpp et Unsloth. Meta annonce un gain de bout en bout de 3% dans son test cité de kernels Helion sur matériel AMD MI350.
Il n’existe pas de prix hébergé officiel unique, les fournisseurs définissant leurs propres routes et conditions. Comparez les prix par token, la précision, les limites de contexte, les réglages de raisonnement, le routage régional, les politiques de rétention des données et d’entraînement des modèles, ainsi que la disponibilité effective du checkpoint Open publié.
FAQ Muse Spark Open
Muse Spark Open est-il vraiment open source ?
Non. Les poids sont téléchargeables et modifiables, mais la licence contient des restrictions d’attribution, commerciales et d’usage. « Open-weight » est une description plus prudente.
Muse Spark Open peut-il tourner sur un seul Mac Studio ou GPU ?
Pas dans la configuration publiée par Apple. Le checkpoint NVFP4 représente environ 493GB avant l’espace de travail, tandis que les paramètres BF16 exigent plus de 1.6TB ; un déploiement pratique demande donc plusieurs machines ou accélérateurs.
Combien coûte l’API Muse Spark Open ?
Le prix dépend du fournisseur hébergé. Meta cite sept partenaires API, mais ne publie aucun prix universel par token.
Muse Spark Open est-il meilleur que Kimi K3 ou GLM 5.3 ?
Muse Spark Open arrive en tête de JobBench et MCP-Atlas dans les résultats cités, tandis que Kimi K3 et GLM 5.3 dominent plusieurs tests orientés code. Évaluez la même charge de travail plutôt que de vous fier à une étiquette générale.
Ce qu’il faut tester avant l’auto-hébergement
Avant d’acheter du matériel, exécutez les mêmes tâches d’agents représentatives auprès de deux fournisseurs hébergés. Relevez la réussite des tâches, les interventions humaines, le temps jusqu’au premier token, la latence totale, le coût de sortie, les conditions de rétention des données et l’identité du checkpoint ; n’auto-hébergez que si les impératifs de confidentialité ou de contrôle compensent le coût opérationnel mesuré.