Muse Spark Open på AMD: Support från dag ett, en platshållartröskel och en grind som ingen har kört

Meta släppte Muse Spark Open den 15 oktober 2026, och samma kväll landade en pull request i utkastläge i SGLang vars titel låter mindre som en funktion än som ett medgivande: [AMD] Lägg till en nattlig GSM8K + MMMU-noggrannhetsgrind för Muse Spark Open MI35x. Anledningen till att den finns framgår tydligt av PR-beskrivningen. På HIP skickar modellens kod vidare till en separat ROCm-implementation — sglang.srt.rocm_muse_spark — och inget CI-jobb i projektet täcker den. Enligt författarens egen utsago har den nya grinden inte körts på hårdvara, ett av dess två tröskelvärden för godkänt/underkänt är en påhittad platshållare eftersom inget AMD-mått fanns att använda, och CI-jobbet skulle ändå misslyckas redan i sitt första steg i dag. Det här är inte en lanseringshistoria. Det är ett läckageliknande spår av hur det faktiskt ser ut inifrån ett serveringsramverk att skeppa en modell med öppna vikter och 816 miljarder parametrar till AMD-hårdvara.

Vad pull requesten faktiskt tillför

Grinden är ett enda nattligt jobb som täcker båda FP4-checkpunkterna i projektets kokboksrecept "Low Latency" för MI355X. Med projektets egna ord:

• Sviten — nightly-amd-4-gpu-mi35x-muse-spark-open, jobbet nightly-4-gpu-mi35x-muse-spark-open på linux-mi35x-gpu-8-runnern vid TP4, med en gräns på 21 600 sekunder per fil.

• Två servrar, två klasser — en per checkpoint, eftersom NVFP4-cellen tar en annan inläsningsväg än MXFP4-cellen. MXFP4 laddar amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4; NVFP4 laddar Meta-repots -NVFP4checkpoint med --quantization quark_mxfp4, som omkvantiserar till MXFP4 vid inläsning.

• Receptflaggor — TP4/EP4, AITER-attention vid sidstorlek 16, MUSE_MOE_BACKEND=flydsl, DFlash2 med en Triton-backend för draft-attention.

• Vad som mäts — fullständig uppdelning av GSM8K via sgl-eval med tänkande aktiverat, reasoning_effort=xhigh, max 32 768 tokens, temperatur 1,0, top_p 0,95, plus 100 MMMU-sampel för den multimodala vägen.

• Väggtid — en enda 8-GPU-körare hanterar båda checkpoints efter varandra, ungefär fyra timmar.

MMMU-inkluderingen är detaljen som gör PR:en värd att läsa. Som författaren uttrycker det skickas modellen på HIP till en ROCm-implementation, och bildvägen genom den implementationen är annars otestad — så visionstornet är, vid den tidpunkt då detta skrevs, den minst utnyttjade delen av Muse Spark Open på AMD-silikon.

De två siffrorna i PR:en, och var de kom ifrån

Inget här är en mätning av Muse Spark Open på AMD-hårdvara, och det står i PR:en.

• GSM8K 0.93 — lyftes rakt av från B300 Muse Spark-testet i Day-0-PR:en. B300 är NVIDIA Blackwell Ultra. Tröskelvärdet, samplingsinställningarna och poängsättningsupplägget fördes alla över från Hopper-klass-till-Blackwell-arbete till en helt annan acceleratorstack.

• MMMU 0,50 — beskrivs i PR:en som "en platshållare utan någon AMD-mätning bakom sig." Det är ovanligt uppriktigt för en CI-fil, och det är värt att förstå varför det är viktigare än det verkar. En grind med en påhittad miniminivå är inte en korrekthetskontroll; den är en snubbeltråd. Den fångar en katastrofal regression och vinkar tyst igenom en lindrig sådan. Om den verkliga MMMU-poängen för MI355X visar sig vara 0,68 tillåter grinden en glidning på sex punkter innan den utlöses.

• DFlash2 accept length — rapporteras i jobbets stegsammanfattning, avsiktligt inte gated. Så den spekulativa avkodningsvägen är observerbar men oskyddad: en draft-modell som tyst slutar predikera bra kommer att dyka upp i en sammanfattning som ingen larmar på.

Den sista punkten generaliserar bortom den här enskilda PR:en. En nattlig träffsäkerhetsgrind mäter den modellkod som ramverket levererar, inte den modell som en leverantör serverar dig. Annat kvantiseringsrecept, annan sidstorlek, annan attention-backend, annan draft-modell – och du befinner dig utanför det spann som grinden skrevs för.

Grinden är blockerad, och anledningen är vardaglig

PR:en ligger kvar som utkast tills Day-0-support-PR:en har landat, vilket är ett normalt beroende. Den mer intressanta blockeraren är AMD AITER-patchuppsättningen. De patcherna är validerade mot en revision av AITER (4ad9983), men ROCm-Dockerfile:n på main pinnar en annan (2bb5491). Mot den pinnade revisionen tillämpas 04-aiter-muse-moe-flydsl.patch utan problem; AITER-halvan av 03-plan-b-aiter-unified-attention-3d.patch gör det inte, eftersom aiter/ops/triton/attention/unified_attention.py refaktorerades efter att patcherna skars. Författaren har inte kontrollerat den tredje patchen, som riktar sig mot submodulen composable_kernel. Tills den andra tillämpas misslyckas jobbet innan det utvärderar något.

Läs det som en signal om mognad snarare än som en anklagelse. AMD:s serveringsvägar för mycket stora mixture-of-experts-modeller byggs kontinuerligt om uppströms, och en leverantörs lockfil är precis det som bryter patchuppsättningen som fick modellen att köra från första början.

Första dagen på AMD var faktiskt inte den första dagen

Att gaten inte har körts är inte samma sak som att AMD-vägen är ny. Den omgivande tidslinjen berättar en fylligare historia än vad antingen lanseringsinlägget eller PR:en gör.

• AMD:s kvantiseringsartefakter föregår lanseringen med ungefär fyra veckor — Quark-MXFP4- och Quark-PTPC-FP8-checkpointarna för Muse Spark Open publicerades på Hugging Face den 18 september 2026, ungefär en månad innan Meta meddelade vikterna.

• Ramverksstöd öppnades på lanseringsdagen — SGLangs [Day0] Stöd för Muse Spark Open PR och vLLMs [Model] Lägg till stöd för Muse Spark Open Båda PR:arna öppnades inom tolv minuter från varandra den 2026-10-15, vilket är vad äkta dag-noll-samordning ser ut som.

• Metas egen byggguide levererar AMD-recept — FP8 (Quark) för Instinct MI355X som serveras via vLLM, och MXFP4 (Quark) för MI350X och MI355X, tillsammans med en Intel MXFP4-väg dimensionerad för fyra 160 GB-kort och en INT4 Xeon 6-väg för offline-användning.

• Meta publicerade genomströmning specifikt för AMD — DFlash V2-utkastmodellen ger 3,7× genomströmning för en enskild begäran på MI355X och 2,9× vid 16 samtidiga begäranden, där 6,4 utkastade token accepteras per steg; anpassade Helion-kärnor i SGLang tillskrivs snabbhetsvinster på kärnnivå på 1,03–3,95× hos både NVIDIA och AMD samt en 3 % vinst från ände till ände på MI350.

Så berättelsen är inte ”AMD-stöd kommer sent”. Den är att AMD-stödet anlände både inövat och omätt samtidigt: artefakterna, recepten och snabbhetsvinsterna var alla klara, och noggrannhetstalet var det inte, vilket är precis det gap som en nattlig grind finns för att täppa igen.

Vad de oberoende siffrorna säger under tiden

Medan AMD:s noggrannhet är oklar är helhetsbilden inte det. Artificial Analysis listar Muse Spark Open med ett Intelligence Index på 39, nionde av 118 modeller i sin jämförelseuppsättning, med en median på 19 bland jämförbara modeller – ett starkt resultat. Det är vid priset som försiktigheten ligger: 1,25 USD per miljon indatatoken och 4,25 USD per miljon utdatatoken, med 88 % cacherabatt, en blandad taxa på 0,78 USD och 0,84 USD i utgift per Intelligence Index-uppgift, vilket ger en 32:a plats av 40 i det effektivitetsmåttet. Utdatahastighet anges som ej tillgänglig, och listningen redovisar text- och bildindata mot leverantörens egen uppgift om text, bild, video och ljud – en ouppklarad avvikelse som är värd att flagga snarare än att avgöra. Dessa siffror är oberoende och leverantörsoberoende; AMP-siffrorna ovan är Metas.

Kortversionen om du bestämmer dig idag

Om din kapacitet är AMD och du planerade att självhosta Muse Spark Open på MI355X, är den ärliga positionen att du är mätningen. Det finns en komplett day-zero-servingväg, ett kvantiseringsrecept per accelerator, en publicerad snabbhetsvinst för spekulativ avkodning – och, i skrivande stund, ingen publicerad noggrannhetspoäng för någon av FP4-cellerna på AMD-silikon. PR:en ger dig något användbart oavsett: dess utvärderingskonfiguration är en komplett, färdig att lyfta definition av hur en seriös noggrannhetskontroll av den här modellen ser ut, ända ner till reasoning effort och top_p. Kör den mot din egen checkpoint innan du sätter en kund framför den, och håll utkik efter författarens utlovade körningar, de rebasade AITER-patcharna och att MMMU-tröskeln ersätts med en uppmätt poäng.

Den praktiska anteckningen om att serva en fyra veckor gammal kvantiseringsstack

En mekanism i PR:en förtjänar uppmärksamhet. NVFP4-cellen laddas med --quantization quark_mxfp4, vilket innebär att källans checkpoint är NVFP4 och att körtidsmiljön kvantiserar om den till MXFP4 vid laddning. Två numeriskt olika pipelines jämförs under en och samma testsvit, vilket är precis varför var och en får sin egen server, sin egen klass och sin egen rad för godkänt/underkänt. Metas egen vägledning är att AMD FP8 (Quark)-bygget matchar BF16-noggrannhet på GSM8K, men det påståendet gäller FP8, inte någon av FP4-cellerna, och det är en leverantörsmätning. Om du väljer en kvantisering för produktion bör du behandla FP4-cellerna som overifierade tills någon publicerar siffran.

Det är här routinglagret förtjänar sin plats. Ingen av den här osäkerheten finns för en läsare som anropar en hostad endpoint – men om du är den som fattar beslutet att självhosta, är sättet att minska risken med en obeprövad modell att lägga en liten andel av trafiken på den bakom något som kan flytta tillbaka trafiken. OrcaRouter routar Muse Spark 1.2 och Muse Spark 1.1 i dag och routar inte Muse Spark Open, så inget här är ett påstående om att hosta den nya modellen; det är samma ett API över 200+ modeller, med automatisk failover när en leverantör försämras och ett routing-DSL för att dela upp trafik mellan modeller och leverantörer via konfiguration i stället för kodändring. Vi för vidare leverantörens listpris med 0 % påslag, vilket är det som gör en försiktig parallellkörning billig nog att faktiskt genomföra.

För själva Muse Spark Open går tillgängligheten i dag via Metas eget API och en uppsättning tredjepartsplattformar för inferens, plus nedladdningarna av vikter på Hugging Face och de två molnmodellkataloger som Meta nämnde. På AMD är det snabbaste sättet till en tillförlitlig siffra gaten i den här PR:en – när någon väl kör den.

Vad du ska titta på

• Landningen av Day-0-PR:en – noggrannhetsgrinden kan inte mergas innan den har landat, och när den väl är på plats är det då modellens egen kod blir baslinjen snarare än en ögonblicksbild.

• Rebasen av AITER-patchen — närmare bestämt AITER-halvan av unified-attention-patchen mot den fastnålade revisionen. Tills den går att tillämpa är AMD-sviten röd av skäl som inte har något med modellen att göra.

• MMMU-tröskeln lämnar 0,50 — så fort en riktig MI355X-poäng ersätter platshållaren, börjar den multimodala grinden göra sitt jobb.

• De första publicerade körningsrapporterna — författaren har åtagit sig att publicera körningar på alla tre bilderna innan PR:en markeras som redo. Det är den första AMD-noggrannhetsmätningen för Muse Spark Open, och den kommer från en testrigg snarare än en leverantörsbild.

• Om NVIDIA- och AMD-siffrorna divergerar — om GSM8K håller sig nära 0,93 på MI355X medan MMMU hamnar väsentligt lägre än någon annan plattform, är visionsvägen på ROCm själva historien, och den framework-PR som lade till gaten kommer att ha varit den första platsen där det syntes.

För alla som följer hur flaggskeppsmodeller med öppna vikter faktiskt når sekundär hårdvara, är detta filen att hålla öppen. Lanseringsinlägget säger att modellen är tillgänglig på AMD. Pull requesten säger att per den 15 oktober 2026 ingen ännu har kontrollerat om den fortfarande är bra där.