Muse Spark Open su AMD: supporto dal primo giorno, una soglia segnaposto e un gate che nessuno ha mai eseguito

Meta ha rilasciato Muse Spark Open il 15 ottobre 2026, e quella stessa sera è atterrata in SGLang una pull request in bozza il cui titolo suona meno come una funzionalità e più come un'ammissione: [AMD] Aggiungi un gate di accuratezza notturno GSM8K + MMMU per Muse Spark Open MI35x. Il motivo per cui esiste è spiegato chiaramente nel corpo della PR. Su HIP, il codice del modello rimanda a un'implementazione ROCm separata — sglang.srt.rocm_muse_spark — e nessun job di continuous integration nel progetto la copre. Secondo quanto dichiarato dall'autore stesso, il nuovo gate non è stato eseguito su hardware, una delle sue due soglie di superamento/fallimento è un segnaposto inventato perché non esisteva alcuna misura AMD da usare, e il job CI fallirebbe comunque al primo passo già oggi. Questa non è una storia di lancio. È una traccia a forma di fuga di ciò che significa davvero distribuire un modello open-weight da 816 miliardi di parametri su hardware AMD dall'interno di un framework di serving.

Cosa aggiunge effettivamente la pull request

Il gate è un unico job notturno che copre entrambi i checkpoint FP4 nella ricetta "Low Latency" del cookbook MI355X del progetto. Nei termini propri del progetto:

• Suite — nightly-amd-4-gpu-mi35x-muse-spark-open, job nightly-4-gpu-mi35x-muse-spark-open sul linux-mi35x-gpu-8 runner a TP4, con un limite di 21.600 secondi per file.

• Due server, due classi — uno per checkpoint, perché la cella NVFP4 segue un percorso di caricamento diverso da quella MXFP4. MXFP4 carica amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4; NVFP4 carica il checkpoint -NVFP4 del repository Meta con --quantization quark_mxfp4, che viene riquantizzato in MXFP4 al momento del caricamento.

• Flag della recipe — TP4/EP4, attenzione AITER a dimensione pagina 16, MUSE_MOE_BACKEND=flydsl, DFlash2 con un backend Triton per la draft-attention.

• Cosa viene misurato — full-split GSM8K tramite sgl-eval con thinking attivo, reasoning_effort=xhigh, 32.768 token massimi, temperature 1.0, top_p 0.95, più 100 campioni MMMU per il percorso multimodale.

• Tempo reale — un singolo runner con 8 GPU serve entrambi i checkpoint uno dopo l'altro, circa quattro ore.

L'inclusione di MMMU è il dettaglio che rende il PR degno di essere letto. Come dice l'autore, su HIP il modello viene indirizzato verso un'implementazione ROCm e il percorso delle immagini attraverso tale implementazione è altrimenti non testato — quindi il vision tower è, nel momento in cui è stato scritto questo, la parte meno esercitata di Muse Spark Open su silicio AMD.

I due numeri nella PR, e da dove provengono

Nulla di quanto presente qui è una misurazione di Muse Spark Open su hardware AMD, e il PR lo dice.

• GSM8K 0.93 — ripreso integralmente dal test B300 Muse Spark nel PR del Day-0. B300 è NVIDIA Blackwell Ultra. La soglia, le impostazioni di campionamento e la configurazione di scoring sono state tutte trasferite da lavori da Hopper-class a Blackwell su uno stack di acceleratori completamente diverso.

• MMMU 0.50 — nel PR è descritto come "un segnaposto senza alcuna misura AMD alle spalle". È insolitamente schietto per un file CI, e vale la pena capire perché conta più di quanto sembri. Un gate con una soglia minima inventata non è un controllo di correttezza; è un allarme a filo. Intercetterà una regressione catastrofica e lascerà passare silenziosamente una lieve. Se il punteggio MMMU reale di MI355X si rivelasse 0,68, il gate consentirebbe uno scivolamento di sei punti prima di scattare.

• Lunghezza di accettazione di DFlash2 — riportata nel riepilogo degli step del job, deliberatamente non soggetta a gating. Quindi il percorso di decodifica speculativa è osservabile ma non protetto: un modello draft che smette silenziosamente di fare buone previsioni comparirà in un riepilogo su cui nessuno ha alert.

Quest'ultimo punto si generalizza oltre questa singola PR. Un gate di accuratezza notturno misura il codice del modello che il framework distribuisce, non il modello che un provider ti serve. Ricetta di quantizzazione diversa, dimensione di pagina diversa, backend di attenzione diverso, modello draft diverso: sei fuori dal perimetro per cui il gate è stato scritto.

Il cancello è bloccato, e il motivo è banale

La PR rimane in bozza finché non arriva la PR di supporto del Day-0, che è una dipendenza normale. Il blocco più interessante è il set di patch di AMD AITER. Quelle patch sono validate rispetto a una revisione di AITER (4ad9983), ma il Dockerfile ROCm su main ne fissa una diversa (2bb5491). Rispetto alla revisione fissata, 04-aiter-muse-moe-flydsl.patch si applica senza problemi; la metà AITER di 03-plan-b-aiter-unified-attention-3d.patch no, perché aiter/ops/triton/attention/unified_attention.py è stato rifattorizzato dopo il taglio delle patch. L'autore non ha controllato la terza patch, che punta al sottomodulo composable_kernel. Finché la seconda non si applica, il job fallisce prima di valutare qualsiasi cosa.

Leggilo come un segnale di maturità più che come un'accusa. I percorsi di serving AMD per modelli mixture-of-experts molto grandi vengono ricostruiti continuamente upstream, e un lockfile di fornitore è esattamente ciò che rompe il set di patch che aveva fatto funzionare il modello in primo luogo.

Il primo giorno in AMD non era in realtà il primo giorno

Il fatto che il gate non sia stato eseguito non equivale a un percorso AMD nuovo. La cronologia circostante racconta una storia più completa di quanto facciano sia il post di lancio sia il comunicato stampa.

• Gli artefatti di quantizzazione AMD precedono il lancio di circa quattro settimane — i checkpoint Quark-MXFP4 e Quark-PTPC-FP8 per Muse Spark Open sono stati pubblicati su Hugging Face il 18 settembre 2026, circa un mese prima che Meta annunciasse i pesi.

• Il supporto dei framework è stato aperto il giorno del lancio — la PR di SGLang [Day0] Support Muse Spark Open e la PR di vLLM [Model] Add Muse Spark Open support sono state entrambe aperte a distanza di dodici minuti l'una dall'altra il 2026-10-15, ovvero quello che sembra un autentico coordinamento day-zero.

• La guida di build di Meta stessa include ricette AMD — FP8 (Quark) per Instinct MI355X servito tramite vLLM, e MXFP4 (Quark) per MI350X e MI355X, insieme a un percorso Intel MXFP4 dimensionato per quattro schede da 160 GB e un percorso INT4 Xeon 6 per l'uso offline.

• Meta ha pubblicato il throughput specificamente per AMD — il modello draft DFlash V2 offre un throughput di 3,7× per una singola richiesta su MI355X e di 2,9× con 16 richieste concorrenti, con 6,4 token draft accettati per step; ai kernel Helion personalizzati in SGLang vengono attribuiti speedup a livello di kernel da 1,03–3,95× su NVIDIA e AMD e un guadagno end-to-end del 3% su MI350.

Quindi la storia non è "il supporto AMD arriva in ritardo". È che il supporto AMD è arrivato provato e non misurato allo stesso tempo: gli artefatti, le ricette e gli speedup erano tutti pronti, e il valore di accuratezza non lo era, che è esattamente il divario che un gate notturno esiste per colmare.

Cosa dicono intanto i numeri indipendenti

Mentre l'accuratezza di AMD resta irrisolta, il quadro complessivo non lo è. Artificial Analysis colloca Muse Spark Open a un Intelligence Index di 39, nono su 118 modelli nel suo insieme di confronto, con una mediana di 19 tra i modelli comparabili — un risultato solido. È sul prezzo che risiede la cautela: 1,25 $ per milione di token in input e 4,25 $ per milione in output, con uno sconto cache dell'88%, una tariffa combinata di 0,78 $ e 0,84 $ di spesa per attività dell'Intelligence Index, che si colloca al 32º posto su 40 in quella misura di efficienza. La velocità di output è indicata come non disponibile, e la scheda riporta input testuali e di immagini a fronte della dichiarazione dello stesso fornitore su testo, immagini, video e audio — una discrepanza irrisolta che vale la pena segnalare anziché dirimere. Quelle cifre sono indipendenti e agnostiche rispetto al fornitore; le cifre AMP sopra riportate sono di Meta.

La versione breve se stai decidendo oggi

Se la tua capacità è AMD e stavi pianificando di self-hostare Muse Spark Open su MI355X, la posizione onesta è che la misura sei tu. Esiste un percorso di serving day-zero completo, una ricetta di quantizzazione per acceleratore, uno speedup di decodifica speculativa pubblicato — e, al momento in cui scriviamo, nessun punteggio di accuratezza pubblicato per nessuna delle due celle FP4 su silicio AMD. La PR ti offre comunque qualcosa di utile: la sua configurazione di eval è una definizione completa e pronta da riutilizzare di come appare un serio controllo di accuratezza su questo modello, fino al reasoning effort e al top_p. Eseguila sul tuo checkpoint prima di mettere un cliente davanti ad esso, e tieni d'occhio le run promesse dall'autore, le patch AITER rebasate e la soglia MMMU che viene sostituita con un punteggio misurato.

La nota pratica sull'erogazione di uno stack di quantizzazione vecchio di quattro settimane

Un meccanismo nel PR merita attenzione. La cella NVFP4 viene caricata con --quantization quark_mxfp4, il che significa che il checkpoint sorgente è NVFP4 e il runtime lo requantizza a MXFP4 al caricamento. Due pipeline numericamente diverse vengono confrontate sotto un'unica suite, ed è esattamente per questo che ciascuna riceve il proprio server, la propria classe e la propria riga di pass/fail. Le indicazioni di Meta stesse dicono che la build AMD FP8 (Quark) eguaglia l'accuratezza BF16 su GSM8K, ma tale affermazione riguarda FP8, non una delle due celle FP4, ed è una misurazione del fornitore. Se stai scegliendo una quantizzazione per la produzione, considera le celle FP4 come non verificate finché qualcuno non pubblica il numero.

È qui che il livello di routing si guadagna il suo posto. Nessuna di queste incertezze esiste per chi chiama un endpoint ospitato — ma se sei tu a dover prendere la decisione di self-hosting, il modo per ridurre il rischio di un modello non ancora collaudato è mettergli davanti una piccola quota di traffico, dietro qualcosa in grado di riportare indietro quel traffico. Oggi OrcaRouter instrada Muse Spark 1.2 e Muse Spark 1.1 e non instrada Muse Spark Open, quindi qui non si afferma nulla riguardo all'hosting del nuovo modello; è la stessa unica API per oltre 200 modelli, con failover automatico quando un provider peggiora e un DSL di routing per suddividere il traffico tra modelli e provider tramite configurazione anziché modifiche al codice. Trasmettiamo il prezzo di listino del provider con 0% di markup, ed è questo che rende un'esecuzione parallela prudente abbastanza economica da poter essere davvero fatta.

Per Muse Spark Open stesso, oggi la disponibilità passa attraverso l'API di Meta stessa e una serie di piattaforme di inferenza di terze parti, oltre ai download dei pesi su Hugging Face e ai due cataloghi di modelli cloud indicati da Meta. Su AMD, il modo più rapido per ottenere un numero attendibile è il gate in questa PR — una volta che qualcuno lo esegue.

Cosa guardare

• L'atterraggio della PR Day-0 — il gate di accuratezza non può eseguire il merge prima che ciò avvenga, e il suo arrivo è il momento in cui il codice del modello stesso diventa la baseline anziché uno snapshot.

• Il rebase della patch AITER — nello specifico la metà AITER della patch di unified-attention rispetto alla revisione pinnata. Finché non viene applicata, la suite AMD è rossa per motivi che non hanno nulla a che fare con il modello.

• La soglia MMMU che si sposta da 0.50 — nel momento in cui un punteggio MI355X reale sostituisce il segnaposto, il gate multimodale inizia a svolgere il suo lavoro.

• Il primo run pubblicato riporta — l'autore si è impegnato a pubblicare i run su tutte e tre le immagini prima di contrassegnare la PR come pronta. Questa è la prima lettura di accuratezza AMD per Muse Spark Open, e arriverà da un test harness anziché da una slide del fornitore.

• Se i numeri di NVIDIA e AMD divergono — se GSM8K si mantiene vicino a 0,93 su MI355X mentre MMMU si colloca materialmente più in basso rispetto a qualsiasi altra piattaforma, il percorso vision su ROCm è il punto chiave, e la PR del framework che ha aggiunto il gate sarà stata il primo luogo in cui è stato visibile.

Per chiunque tenga traccia di come i modelli di punta open-weight arrivino effettivamente su hardware secondario, questo è il file da tenere aperto. Il post di lancio ti dice che il modello è disponibile su AMD. La pull request ti dice che al 15 ottobre 2026 nessuno ha ancora verificato se lì sia ancora valido.