Muse Spark Open sur AMD : prise en charge dès le premier jour, un seuil provisoire et un gate que personne n'a encore exécuté.

Meta a publié Muse Spark Open le 15 octobre 2026, et le soir même, une pull request préliminaire est arrivée dans SGLang, dont le titre ressemble moins à une fonctionnalité qu'à un aveu : [AMD] Ajouter un contrôle nocturne de précision GSM8K + MMMU pour Muse Spark Open MI35x. La raison de son existence est explicitée dans le corps de la PR. Sur HIP, le code du modèle est redirigé vers une implémentation ROCm distincte — sglang.srt.rocm_muse_spark — et aucune tâche d'intégration continue du projet ne la couvre. De l'aveu même de l'auteur, le nouveau contrôle n'a pas été exécuté sur du matériel, l'un de ses deux seuils de réussite/échec est une valeur fictive inventée parce qu'aucune mesure AMD n'était disponible pour être utilisée, et la tâche CI échouerait de toute façon dès sa première étape aujourd'hui. Ce n'est pas un récit de lancement. C'est une trace en forme de fuite de ce à quoi ressemble réellement le déploiement d'un modèle ouvert de 816 milliards de paramètres sur du matériel AMD depuis l'intérieur d'un framework de service.

Ce que la pull request ajoute réellement

Le gate est une tâche nocturne unique qui couvre les deux points de contrôle FP4 de la recette « Low Latency » du cookbook MI355X du projet. Dans les termes propres au projet :

• Suite — nightly-amd-4-gpu-mi35x-muse-spark-open, tâche nightly-4-gpu-mi35x-muse-spark-open sur le runner linux-mi35x-gpu-8 en TP4, avec un plafond de 21 600 secondes par fichier.

• Deux serveurs, deux classes — une par point de contrôle, car la cellule NVFP4 emprunte un chemin de chargement différent de celui de la MXFP4. MXFP4 charge amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4 ; NVFP4 charge le point de contrôle -NVFP4 du dépôt Meta avec --quantization quark_mxfp4, qui requantifie en MXFP4 au moment du chargement.

• Indicateurs de recette — TP4/EP4, attention AITER avec une taille de page de 16, MUSE_MOE_BACKEND=flydsl, DFlash2 avec un backend d'attention de brouillon Triton.

• Ce qui est mesuré — GSM8K en split complet via sgl-eval avec la réflexion activée, reasoning_effort=xhigh, 32 768 tokens max, température 1.0, top_p 0.95, plus 100 échantillons MMMU pour le chemin multimodal.

• Temps d'horloge — un seul exécuteur 8 GPU prend en charge les deux points de contrôle l'un après l'autre, soit environ quatre heures.

L'inclusion de MMMU est le détail qui rend la PR digne d'être lue. Comme le dit l'auteur, sur HIP, le modèle passe dans une implémentation ROCm, et le chemin des images à travers cette implémentation n'est pas testé par ailleurs — ainsi, la tour de vision est, au moment où ces lignes ont été écrites, la partie la moins sollicitée de Muse Spark Open sur silicium AMD.

Les deux nombres dans la PR, et d'où ils viennent

Rien ici ne constitue une mesure de Muse Spark Open sur du matériel AMD, et la PR le dit.

• GSM8K 0,93 — repris intégralement du test B300 Muse Spark dans la PR Day-0. B300 est NVIDIA Blackwell Ultra. Le seuil, les paramètres d’échantillonnage et la configuration de notation ont tous été reportés depuis des travaux « Hopper-class-to-Blackwell » vers un stack d’accélérateurs complètement différent.

• MMMU 0.50 — décrit dans la PR comme « un espace réservé sans aucune mesure AMD à l’appui ». C’est d’une franchise inhabituelle pour un fichier de CI, et il vaut la peine de comprendre pourquoi cela importe plus qu’il n’y paraît. Un contrôle bloquant avec un seuil inventé n’est pas une vérification d’exactitude ; c’est un fil-piège. Il détectera une régression catastrophique et laissera passer silencieusement une régression légère. Si le score MMMU réel du MI355X s’avère être de 0,68, le contrôle bloquant autorise une baisse de six points avant de se déclencher.

• DFlash2 accept length — indiqué dans le résumé d'étape du job, délibérément non bloquant. Ainsi, la voie de décodage spéculatif est observable mais non protégée : un modèle brouillon qui cesse discrètement de bien prédire apparaîtra dans un résumé sur lequel personne ne déclenche d'alerte.

Ce dernier point se généralise au-delà de cette seule PR. Un contrôle de précision nocturne mesure le code du modèle que le framework embarque, pas le modèle qu'un fournisseur vous sert. Une recette de quantification différente, une taille de page différente, un backend d'attention différent, un modèle de brouillon différent, et vous voilà en dehors de l'enveloppe pour laquelle le contrôle a été écrit.

Le portail est bloqué, et la raison est banale.

La PR reste en brouillon jusqu'à ce que la PR de support Day-0 soit fusionnée, ce qui est une dépendance normale. Le blocage plus intéressant est l'ensemble de correctifs AMD AITER. Ces correctifs sont validés contre une révision d'AITER (4ad9983), mais le Dockerfile ROCm sur main en épingle une différente (2bb5491). Contre la révision épinglée, 04-aiter-muse-moe-flydsl.patch s'applique proprement ; la moitié AITER de 03-plan-b-aiter-unified-attention-3d.patch ne s'applique pas, car aiter/ops/triton/attention/unified_attention.py a été refactorisé après la création des correctifs. L'auteur n'a pas vérifié le troisième correctif, qui cible le sous-module composable_kernel. Tant que le deuxième ne s'applique pas, le job échoue avant même d'évaluer quoi que ce soit.

Lisez cela comme un signal de maturité plutôt que comme un réquisitoire. Les chemins de serving AMD pour les très grands modèles de mélange d’experts sont reconstruits en continu en amont, et un lockfile de fournisseur est exactement ce qui casse la série de correctifs qui a permis de faire tourner le modèle au départ.

Le premier jour chez AMD n'était pas vraiment le premier jour

Le fait que la gate n'ait pas été exécutée n'est pas la même chose que le fait que le chemin AMD soit nouveau. La chronologie environnante raconte une histoire plus complète que ne le fait le post de lancement ou la PR.

• Les artefacts de quantification AMD précèdent le lancement d'environ quatre semaines — les checkpoints Quark-MXFP4 et Quark-PTPC-FP8 pour Muse Spark Open ont été publiés sur Hugging Face le 2026-09-18, environ un mois avant que Meta n'annonce les poids.

• Le support du framework a été ouvert le jour du lancement — la PR [Day0] Support Muse Spark Open de SGLang et la PR [Model] Add Muse Spark Open support de vLLM ont toutes deux été ouvertes à moins de douze minutes d'intervalle l'une de l'autre le 2026-10-15, voilà à quoi ressemble une véritable coordination dès le jour zéro.

• Le guide de compilation propre à Meta fournit des recettes AMD — FP8 (Quark) pour Instinct MI355X servi via vLLM, et MXFP4 (Quark) pour MI350X et MI355X, ainsi qu'un chemin Intel MXFP4 dimensionné pour quatre cartes de 160 Go et un chemin INT4 Xeon 6 pour une utilisation hors ligne.

• Meta a publié les débits spécifiquement pour AMD — le modèle de proposition DFlash V2 offre un débit 3,7× pour une requête unique sur MI355X et 2,9× à 16 requêtes simultanées, avec 6,4 jetons proposés acceptés par étape ; les noyaux Helion personnalisés dans SGLang sont crédités d'accélérations au niveau du noyau de 1,03–3,95× sur NVIDIA et AMD, ainsi que d'un gain de 3 % de bout en bout sur MI350.

Donc, l’histoire n’est pas « le support AMD arrive en retard ». C’est que le support AMD est arrivé à la fois rodé et non mesuré : les artefacts, les recettes et les accélérations étaient tous prêts, et la valeur de précision ne l’était pas, ce qui est précisément l’écart qu’une porte nocturne a pour fonction de combler.

Ce que disent, entre-temps, les chiffres indépendants

Si l'exactitude d'AMD n'est pas résolue, le tableau d'ensemble, lui, l'est. Artificial Analysis classe Muse Spark Open à un Intelligence Index de 39, neuvième sur 118 modèles de son ensemble de comparaison, avec une médiane de 19 parmi les modèles comparables — un résultat solide. C'est sur son prix que la prudence s'impose : 1,25 $ par million de jetons d'entrée et 4,25 $ par million de jetons de sortie, avec une remise de cache de 88 %, un tarif mixte de 0,78 $ et 0,84 $ de dépense par tâche d'Intelligence Index, ce qui le classe 32e sur 40 pour cette mesure d'efficacité. La vitesse de sortie est indiquée comme non disponible, et la fiche mentionne des entrées texte et image, alors que le fournisseur revendique pour sa part texte, image, vidéo et audio — une divergence non résolue qu'il vaut mieux signaler que trancher. Ces chiffres sont indépendants et agnostiques vis-à-vis des fournisseurs ; les chiffres AMP ci-dessus sont ceux de Meta.

La version courte si vous décidez aujourd’hui

Si votre capacité de calcul est AMD et que vous prévoyiez d’auto-héberger Muse Spark Open sur MI355X, la position honnête est que c’est vous, la mesure. Il existe un chemin de service complet dès le jour zéro, une recette de quantification par accélérateur, une accélération de décodage spéculatif publiée — et, à l’heure où nous écrivons, aucun score de précision publié pour l’une ou l’autre des cellules FP4 sur silicium AMD. La PR vous donne néanmoins quelque chose d’utile : sa configuration d’évaluation est une définition complète, prête à être reprise, de ce à quoi ressemble un contrôle sérieux de la précision sur ce modèle, jusqu’à l’effort de raisonnement et au top_p. Exécutez-la sur votre propre checkpoint avant de mettre un client devant, et guettez les exécutions promises par l’auteur, les patchs AITER rebasés, et le remplacement du seuil MMMU par un score mesuré.

La note pratique sur la mise en service d'une pile de quantification vieille de quatre semaines

Un mécanisme dans la PR mérite attention. La cellule NVFP4 est chargée avec --quantization quark_mxfp4, ce qui signifie que le checkpoint source est NVFP4 et que le runtime le requantifie en MXFP4 au chargement. Deux pipelines numériquement différents sont comparés au sein d'une même suite, et c'est précisément pourquoi chacun dispose de son propre serveur, de sa propre classe et de sa propre ligne de réussite/échec. Les recommandations de Meta indiquent que la version AMD FP8 (Quark) égale la précision du BF16 sur GSM8K, mais cette affirmation concerne le FP8, pas l'une ou l'autre des cellules FP4, et il s'agit d'une mesure de fournisseur. Si vous choisissez une quantification pour la production, considérez les cellules FP4 comme non vérifiées jusqu'à ce que quelqu'un publie le chiffre.

C'est ici que la couche de routage gagne sa place. Aucune de ces incertitudes n'existe pour un lecteur qui appelle un point de terminaison hébergé — mais si c'est vous qui prenez la décision de l'auto-hébergement, la façon de réduire le risque d'un modèle non éprouvé est de placer une petite part du trafic dessus, derrière un mécanisme capable de rediriger le trafic en sens inverse. OrcaRouter route Muse Spark 1.2 et Muse Spark 1.1 aujourd'hui et ne route pas Muse Spark Open, donc rien ici n'est une affirmation sur l'hébergement du nouveau modèle ; il s'agit de la même API unique pour plus de 200 modèles, avec un basculement automatique lorsqu'un fournisseur se dégrade et un DSL de routage pour répartir le trafic entre modèles et fournisseurs par configuration plutôt que par modification de code. Nous répercutons le prix catalogue du fournisseur avec 0 % de marge, ce qui rend une exécution parallèle prudente suffisamment peu coûteuse pour être réellement mise en œuvre.

Pour Muse Spark Open lui-même, la disponibilité aujourd’hui passe par l’API propre à Meta et un ensemble de plateformes d’inférence tierces, ainsi que par les téléchargements de poids sur Hugging Face et les deux catalogues de modèles cloud nommés par Meta. Sur AMD, le moyen le plus rapide d’obtenir un chiffre fiable est le gate dans cette PR — une fois que quelqu’un l’exécute.

Que regarder

• L’arrivée de la PR du jour 0 — le contrôle d’exactitude ne peut pas être fusionné avant cela, et son arrivée marque le moment où le code du modèle lui-même devient la référence plutôt qu’un instantané.

• Le rebase du patch AITER — plus précisément la moitié AITER du patch d’attention unifiée par rapport à la révision épinglée. Tant que cela ne s’applique pas, la suite AMD est rouge pour des raisons qui n’ont rien à voir avec le modèle.

• Le seuil MMMU s’écartant de 0,50 — au moment où un vrai score MI355X remplace la valeur provisoire, la porte multimodale commence à faire son travail.

• Le premier rapport d'exécution publié — l'auteur s'est engagé à publier des exécutions sur les trois images avant de marquer la PR comme prête. Il s'agit de la première mesure de précision AMD pour Muse Spark Open, et elle proviendra d'un banc de test plutôt que d'une présentation commerciale.

• Divergence éventuelle entre les chiffres NVIDIA et AMD — si GSM8K se maintient autour de 0,93 sur MI355X tandis que MMMU se situe nettement en dessous de celui de toute autre plateforme, c'est la voie vision sur ROCm qui est le point central, et la PR du framework qui a ajouté le garde-fou aura été le premier endroit où cela s'est manifesté.

Pour quiconque suit la manière dont les modèles phares à poids ouverts arrivent réellement sur du matériel secondaire, c'est le fichier à garder ouvert. Le billet d'annonce vous indique que le modèle est disponible sur AMD. La pull request vous indique qu'au 15 octobre 2026, personne n'avait encore vérifié s'il y était toujours performant.