Muse Spark Open op AMD: ondersteuning vanaf dag één, een placeholderdrempel en een gate die niemand heeft gedraaid

Meta bracht Muse Spark Open uit op 15 oktober 2026, en diezelfde avond belandde er een concept-pullrequest in SGLang waarvan de titel eerder als een bekentenis dan als een feature leest: [AMD] Voeg een nightly GSM8K- + MMMU-nauwkeurigheidsgate voor Muse Spark Open MI35x toe. De reden dat die bestaat, staat in de PR-body. Op HIP verwijst de code van het model naar een aparte ROCm-implementatie — sglang.srt.rocm_muse_spark — en geen enkele continuous-integration-job in het project dekt die. Volgens de auteur zelf is de nieuwe gate niet op hardware gedraaid, is een van de twee drempelwaarden voor slagen/zakken een placeholder die is bedacht omdat er geen AMD-meting voorhanden was, en zou de CI-job vandaag sowieso al bij de eerste stap falen. Dit is geen lanceringsverhaal. Het is een lekachtig spoor van hoe het uitleveren van een open-weight model met 816 miljard parameters naar AMD-hardware er van binnenuit een serving-framework daadwerkelijk uitziet.

Wat de pull request daadwerkelijk toevoegt

De gate is één nightly job die beide FP4-checkpoints dekt in het MI355X "Low Latency"-cookbookrecept van het project. In de eigen terminologie van het project:

• Suite — nightly-amd-4-gpu-mi35x-muse-spark-open, job nightly-4-gpu-mi35x-muse-spark-open op de linux-mi35x-gpu-8runner bij TP4, met een limiet van 21.600 seconden per bestand.

• Twee servers, twee klassen — één per checkpoint, omdat de NVFP4-cel een ander laadpad volgt dan de MXFP4-cel. MXFP4 laadt amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4; NVFP4 laadt de Meta-repo's -NVFP4 checkpoint met --quantization quark_mxfp4, die bij het laden naar MXFP4 herkwantiseert.

• Receptvlaggen — TP4/EP4, AITER-attentie bij paginagrootte 16, MUSE_MOE_BACKEND=flydsl, DFlash2 met een Triton-backend voor concept-attentie.

• Wat wordt gemeten — volledige GSM8K-split via sgl-eval met thinking aan, reasoning_effort=xhigh, 32.768 max. tokens, temperatuur 1.0, top_p 0.95, plus 100 MMMU-samples voor het multimodale pad.

• Kloktijd — één enkele 8-GPU-runner bedient beide checkpoints na elkaar, ongeveer vier uur.

Het meenemen van MMMU is het detail dat de PR de moeite waard maakt om te lezen. Zoals de auteur het formuleert, dispatcht het model op HIP naar een ROCm-implementatie en is het beeldpad via die implementatie overigens ongetest — dus de visiontoren is, op het moment dat dit werd geschreven, het minst gebruikte onderdeel van Muse Spark Open op AMD-silicon.

De twee getallen in de PR, en waar ze vandaan komen

Niets hier is een meting van Muse Spark Open op AMD-hardware, en dat zegt de PR ook.

• GSM8K 0.93 — integraal overgenomen uit de B300 Muse Spark-test in de Day-0 PR. B300 is NVIDIA Blackwell Ultra. De drempelwaarde, de sampling-instellingen en de scoringsopzet werden allemaal overgebracht van het Hopper-class-naar-Blackwell-werk naar een volledig andere acceleratorstack.

• MMMU 0.50 — in de PR beschreven als "een plaatsvervanger zonder enige AMD-meting erachter." Dat is ongewoon openhartig voor een CI-bestand, en het is de moeite waard om te begrijpen waarom het meer uitmaakt dan het lijkt. Een gate met een verzonnen ondergrens is geen correctheidscontrole; het is een struikeldraad. Hij vangt een catastrofale regressie op en laat een milde regressie geruisloos door. Als de echte MI355X MMMU-score 0,68 blijkt te zijn, staat de gate een daling van zes punten toe voordat hij afgaat.

• DFlash2 acceptatielengte — gerapporteerd in de stapsamenvatting van de job, bewust niet gegateerd. Het pad van speculatieve decoding is dus wel waarneembaar maar niet beschermd: een conceptmodel dat stilletjes ophoudt goed te voorspellen, duikt op in een samenvatting waar niemand een alert op heeft.

Dat laatste punt gaat verder dan deze ene PR. Een nightly accuracy-gate meet de modelcode die het framework meelevert, niet het model dat een provider je serveert. Een ander kwantisatierecept, een andere paginagrootte, een andere attention-backend, een ander draftmodel, en je zit buiten de envelope waarvoor de gate was geschreven.

De poort is geblokkeerd, en de reden is alledaags.

De PR blijft in draft totdat de Day-0-support-PR landt, wat een normale afhankelijkheid is. De interessantere blokkade is de AMD AITER-patchset. Die patches zijn gevalideerd tegen één revisie van AITER (4ad9983), maar de ROCm Dockerfile op main pint een andere vast (2bb5491). Tegen de vastgepinde revisie past 04-aiter-muse-moe-flydsl.patch zonder problemen; het AITER-deel van 03-plan-b-aiter-unified-attention-3d.patch niet, omdat aiter/ops/triton/attention/unified_attention.py is gerefactord nadat de patches waren gemaakt. De auteur heeft de derde patch niet gecontroleerd, die gericht is op de submodule composable_kernel. Zolang de tweede niet past, faalt de job voordat er iets wordt geëvalueerd.

Zie dat als een signaal over volwassenheid, niet als een aanklacht. AMD-serveerpaden voor zeer grote mixture-of-experts-modellen worden continu upstream herbouwd, en een leverancierslockfile is precies wat de patchset breekt die het model in eerste instantie aan de praat kreeg.

Dag één bij AMD was eigenlijk niet dag één

Dat de gate niet is gedraaid, is niet hetzelfde als dat het AMD-pad nieuw is. De tijdlijn eromheen vertelt een vollediger verhaal dan zowel de launchpost als de PR.

• AMD-kwantisatie-artefacten zijn ongeveer vier weken ouder dan de lancering — de Quark-MXFP4- en Quark-PTPC-FP8-checkpoints voor Muse Spark Open werden op 2026-09-18 gepubliceerd op Hugging Face, ongeveer een maand voordat Meta de gewichten aankondigde.

• Frameworkondersteuning werd op de lanceringsdag geopend — SGLang's [Day0] Ondersteuning voor Muse Spark Open PR en vLLM's [Model] Muse Spark Open-ondersteuning toevoegen PR werden beide binnen twaalf minuten van elkaar geopend op 2026-10-15, wat echte day-zero-coördinatie is.

• Meta's eigen buildgids bevat AMD-recepten — FP8 (Quark) voor Instinct MI355X geserveerd via vLLM, en MXFP4 (Quark) voor MI350X en MI355X, naast een Intel MXFP4-pad voor vier kaarten van 160 GB en een INT4 Xeon 6-pad voor offline gebruik.

• Meta heeft doorvoercijfers specifiek voor AMD gepubliceerd — het DFlash V2-conceptmodel levert 3,7× doorvoer voor één verzoek op MI355X en 2,9× bij 16 gelijktijdige verzoeken, waarbij per stap 6,4 concepttokens worden geaccepteerd; aan aangepaste Helion-kernels in SGLang worden 1,03–3,95× versnellingen op kernelniveau bij NVIDIA en AMD en een end-to-endwinst van 3% op MI350 toegeschreven.

Het verhaal is dus niet: "AMD-ondersteuning komt laat." Het is dat AMD-ondersteuning tegelijkertijd ingestudeerd en ongemeten aankwam: de artefacten, de recepten en de snelheidswinsten waren allemaal klaar, en het nauwkeurigheidscijfer niet, en dat is precies het gat dat een nightly gate moet dichten.

Wat de onafhankelijke cijfers intussen zeggen

Hoewel de AMD-nauwkeurigheid onopgelost is, is het totaalbeeld dat niet. Artificial Analysis vermeldt Muse Spark Open met een Intelligence Index van 39, de negende van de 118 modellen in zijn vergelijkingsset, met een mediaan van 19 over vergelijkbare modellen — een sterk resultaat. De prijs is waar de voorzichtigheid zit: $1,25 per miljoen invoertokens en $4,25 per miljoen uitvoertokens, met 88% cachekorting, een blended tarief van $0,78 en $0,84 aan uitgaven per Intelligence Index-taak, wat op die efficiëntiemaatstaf de 32e plaats van 40 inneemt. De uitvoersnelheid wordt vermeld als niet beschikbaar, en de vermelding registreert tekst- en beeldinvoer tegenover de eigen claim van de leverancier over tekst, beeld, video en audio — een onopgeloste discrepantie die het vermelden waard is in plaats van te worden beslecht. Die cijfers zijn onafhankelijk en leveranciersagnostisch; de AMP-cijfers hierboven zijn van Meta.

De korte versie als je vandaag beslist

Als je capaciteit AMD is en je was van plan om Muse Spark Open zelf te hosten op MI355X, dan is de eerlijke positie dat jij de meting bent. Er is een volledig day-zero servingpad, een quantisatierecept per accelerator, een gepubliceerde speculative-decoding-versnelling — en, op het moment van schrijven, geen gepubliceerde nauwkeurigheidsscore voor een van beide FP4-cellen op AMD-silicon. De PR levert je hoe dan ook iets nuttigs op: de evaluatieconfiguratie is een volledige, direct over te nemen definitie van hoe een serieuze nauwkeurigheidscontrole op dit model eruitziet, tot aan de reasoning effort en de top_p. Draai het op je eigen checkpoint voordat je er een klant mee laat werken, en let op de beloofde runs van de auteur, de gerebaseerde AITER-patches, en dat de MMMU-drempel wordt vervangen door een gemeten score.

De praktische noot over het serveren van een vier weken oude kwantisatiestack

Eén mechanisme in de PR verdient aandacht. De NVFP4-cel wordt geladen met --quantization quark_mxfp4, wat betekent dat het broncheckpoint NVFP4 is en de runtime het bij het laden naar MXFP4 herkwantiseert. Twee numeriek verschillende pipelines worden binnen één suite vergeleken, en dat is precies waarom elk zijn eigen server, zijn eigen klasse en zijn eigen pass/fail-regel krijgt. Meta's eigen richtlijn is dat de AMD FP8 (Quark)-build de BF16-nauwkeurigheid op GSM8K evenaart, maar die bewering gaat over FP8, niet over een van beide FP4-cellen, en het is een leveranciersmeting. Als je een kwantisatie voor productie kiest, behandel de FP4-cellen dan als niet-geverifieerd totdat iemand het cijfer publiceert.

Dit is waar de routeringslaag zijn plek verdient. Al deze onzekerheid bestaat niet voor een lezer die een gehost endpoint aanroept — maar als u degene bent die de self-hostbeslissing neemt, is de manier om een onbewezen model minder risicovol te maken, een klein deel van het verkeer erop te zetten achter iets dat het verkeer weer kan terugverplaatsen. OrcaRouter routeert vandaag Muse Spark 1.2 en Muse Spark 1.1 en routeert Muse Spark Open niet, dus niets hier is een claim over het hosten van het nieuwe model; het is dezelfde ene API voor 200+ modellen, met automatische failover wanneer een provider verslechtert en een routing-DSL om verkeer tussen modellen en providers te splitsen via configuratie in plaats van een codewijziging. We geven de lijstprijs van de provider door met 0% opslag, waardoor een voorzichtige parallelle run goedkoop genoeg is om daadwerkelijk te doen.

Voor Muse Spark Open zelf verloopt de beschikbaarheid vandaag via de eigen API van Meta en een reeks inferentieplatforms van derden, plus de gewichtsdownloads op Hugging Face en de twee cloudmodelcatalogi die Meta noemde. Op AMD is de snelste weg naar een betrouwbaar cijfer de gate in deze PR — zodra iemand die uitvoert.

Wat te kijken

• Het landen van de Day-0 PR — de accuracy-gate kan niet worden gemerged voordat dat gebeurt, en de komst ervan is het moment waarop de eigen code van het model de baseline wordt in plaats van een snapshot.

• De rebase van de AITER-patch — specifiek de AITER-helft van de unified-attention-patch tegen de vastgezette revisie. Totdat die kan worden toegepast, is de AMD-suite rood om redenen die niets met het model te maken hebben.

• De MMMU-drempel die van 0,50 af beweegt — op het moment dat een echte MI355X-score de tijdelijke aanduiding vervangt, begint de multimodale poort zijn werk te doen.

• De eerste gepubliceerde run rapporteert — de auteur heeft toegezegd runs te publiceren voor alle drie de afbeeldingen voordat hij de PR als gereed markeert. Dat is de eerste AMD-nauwkeurigheidsmeting voor Muse Spark Open, en die zal afkomstig zijn van een testharnas in plaats van een leveranciersslide.

• Of de cijfers van NVIDIA en AMD uiteenlopen — als GSM8K op MI355X rond 0,93 blijft terwijl MMMU aanzienlijk lager uitkomt dan op welk ander platform dan ook, dan is het vision-pad op ROCm het verhaal, en de framework-PR die de gate toevoegde zal de eerste plek zijn geweest waar dit zichtbaar was.

Voor iedereen die bijhoudt hoe open-weight-topmodellen daadwerkelijk secundaire hardware bereiken, is dit het bestand om open te houden. Het lanceringsbericht vertelt je dat het model beschikbaar is op AMD. De pull request vertelt je dat op 15 oktober 2026 nog niemand heeft gecontroleerd of het daar nog steeds goed is.