Muse Spark Open auf AMD: Support ab Tag eins, ein Platzhalter-Schwellenwert und ein Gate, das noch niemand ausgeführt hat

Meta veröffentlichte Muse Spark Open am 15. Oktober 2026, und noch am selben Abend ging ein Draft-Pull-Request in SGLang ein, dessen Titel weniger nach einem Feature klingt als nach einem Eingeständnis: [AMD] Nächtliches GSM8K- + MMMU-Genauigkeitsgate für Muse Spark Open MI35x hinzufügen. Der Grund für seine Existenz steht im PR-Body. Unter HIP leitet der Code des Modells an eine separate ROCm-Implementierung weiter — sglang.srt.rocm_muse_spark — und kein Continuous-Integration-Job im Projekt deckt sie ab. Dem Autor zufolge wurde das neue Gate noch nicht auf Hardware ausgeführt, eine seiner beiden Pass/Fail-Schwellen ist ein Platzhalter, der erfunden wurde, weil keine AMD-Messung zur Verfügung stand, und der CI-Job würde ohnehin schon heute beim ersten Schritt fehlschlagen. Das ist keine Launch-Story. Es ist eine Spur in Leckform dessen, was es tatsächlich bedeutet, aus dem Inneren eines Serving-Frameworks heraus ein Open-Weight-Modell mit 816 Milliarden Parametern auf AMD-Hardware auszuliefern.

Was der Pull Request tatsächlich hinzufügt

Das Gate ist ein nächtlicher Job, der beide FP4-Checkpoints im MI355X-„Low Latency“-Cookbook-Rezept des Projekts abdeckt. In den eigenen Worten des Projekts:

• Suite — nightly-amd-4-gpu-mi35x-muse-spark-open, Job nightly-4-gpu-mi35x-muse-spark-open auf dem linux-mi35x-gpu-8 Runner bei TP4, mit einer Obergrenze von 21.600 Sekunden pro Datei.

• Zwei Server, zwei Klassen – eine pro Checkpoint, weil die NVFP4-Zelle einen anderen Ladepfad nimmt als die MXFP4-Zelle. MXFP4 lädt amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4; NVFP4 lädt den vom Meta-Repo bereitgestellten -NVFP4 Checkpoint mit --quantization quark_mxfp4, der beim Laden zu MXFP4 requantisiert wird.

• Rezept-Flags — TP4/EP4, AITER-Attention bei Seitengröße 16, MUSE_MOE_BACKEND=flydsl, DFlash2 mit einem Triton-Draft-Attention-Backend.

• Was gemessen wird — GSM8K im Full-Split über sgl-eval mit aktiviertem Thinking, reasoning_effort=xhigh, 32.768 maximale Tokens, Temperatur 1,0, top_p 0,95, plus 100 MMMU-Stichproben für den multimodalen Pfad.

• Wall-Clock-Zeit — ein einzelner 8-GPU-Runner bedient beide Checkpoints nacheinander, rund vier Stunden.

Die Einbeziehung von MMMU ist das Detail, das die PR lesenswert macht. Wie der Autor es formuliert, erfolgt unter HIP ein Dispatch des Modells in eine ROCm-Implementierung, und der Bildpfad durch diese Implementierung ist ansonsten ungetestet — deshalb ist der Vision Tower zum Zeitpunkt, als dies geschrieben wurde, der am wenigsten erprobte Teil von Muse Spark Open auf AMD-Silizium.

Die beiden Zahlen im PR und woher sie stammen

Nichts hiervon ist eine Messung von Muse Spark Open auf AMD-Hardware, und das sagt die PR auch.

• GSM8K 0.93 — in großem Umfang aus dem B300 Muse Spark Test im Day-0-PR übernommen. B300 ist NVIDIA Blackwell Ultra. Der Schwellenwert, die Sampling-Einstellungen und das Bewertungs-Setup wurden alle aus der Arbeit zum Übergang von der Hopper-Klasse zu Blackwell auf einen völlig anderen Beschleuniger-Stack übertragen.

• MMMU 0,50 — im PR beschrieben als „ein Platzhalter, hinter dem keine AMD-Messung steht". Das ist ungewöhnlich offen für eine CI-Datei, und es lohnt sich zu verstehen, warum es wichtiger ist, als es aussieht. Ein Gate mit einer erfundenen Untergrenze ist keine Korrektheitsprüfung; es ist ein Stolperdraht. Es wird eine katastrophale Regression abfangen und eine milde stillschweigend durchwinken. Wenn sich der echte MI355X-MMMU-Wert als 0,68 herausstellt, erlaubt das Gate einen Rückgang um sechs Punkte, bevor es auslöst.

• DFlash2-Akzeptanzlänge — wird in der Schritt-Zusammenfassung des Jobs gemeldet, bewusst ohne Gate. Der Pfad der spekulativen Dekodierung ist also beobachtbar, aber ungeschützt: Ein Entwurfsmodell, das still und leise aufhört, gut vorherzusagen, taucht in einer Zusammenfassung auf, auf die niemand einen Alarm gesetzt hat.

Dieser letzte Punkt lässt sich über diesen einen PR hinaus verallgemeinern. Ein nächtliches Accuracy-Gate misst den Modellcode, den das Framework ausliefert, nicht das Modell, das ein Anbieter dir bereitstellt. Andere Quantisierungsrezeptur, andere Seitengröße, anderes Attention-Backend, anderes Draft-Modell – und schon bist du außerhalb des Bereichs, für den das Gate geschrieben wurde.

Das Tor ist blockiert, und der Grund ist banal.

Der PR bleibt im Entwurf, bis der Day-0-Support-PR gemergt wird, was eine normale Abhängigkeit ist. Der interessantere Blocker ist das AMD-AITER-Patch-Set. Diese Patches sind gegen eine Revision von AITER validiert (4ad9983), doch das ROCm-Dockerfile auf mainpinnt eine andere fest (2bb5491). Gegen die gepinnte Revision lässt sich 04-aiter-muse-moe-flydsl.patchsauber anwenden; die AITER-Hälfte von 03-plan-b-aiter-unified-attention-3d.patchhingegen nicht, weil aiter/ops/triton/attention/unified_attention.pynach dem Erstellen der Patches refaktoriert wurde. Der Autor hat den dritten Patch nicht geprüft, der auf das composable_kernel-Submodul abzielt. Solange der zweite nicht angewendet werden kann, schlägt der Job fehl, bevor er überhaupt etwas auswertet.

Lies das als Signal für Reife, nicht als Anklage. AMDs Serving-Pfade für sehr große Mixture-of-Experts-Modelle werden upstream kontinuierlich neu aufgebaut, und eine Hersteller-Lockfile ist genau das, was das Patch-Set bricht, das das Modell überhaupt erst zum Laufen gebracht hat.

Tag eins bei AMD war eigentlich nicht Tag eins.

Dass das Gate nicht ausgeführt wurde, ist nicht dasselbe, wie wenn der AMD-Pfad neu wäre. Die umgebende Zeitlinie erzählt eine vollständigere Geschichte als es der Launch-Beitrag oder die PR tut.

• AMDs Quantisierungsartefakte liegen etwa vier Wochen vor dem Launch — die Quark-MXFP4- und Quark-PTPC-FP8-Checkpoints für Muse Spark Open wurden am 18. September 2026 auf Hugging Face veröffentlicht, etwa einen Monat, bevor Meta die Gewichte ankündigte.

• Framework-Unterstützung wurde am Launch-Tag geöffnet — SGLangs [Day0] Support Muse Spark Open PR und vLLMs [Model] Add Muse Spark Open support PR wurden beide am 15.10.2026 eröffnet und lagen nur zwölf Minuten auseinander, was genau das ist, was echte Day-Zero-Koordination ausmacht.

• Metas eigener Build-Guide enthält AMD-Rezepte — FP8 (Quark) für Instinct MI355X, bereitgestellt über vLLM, und MXFP4 (Quark) für MI350X und MI355X, neben einem Intel-MXFP4-Pfad, ausgelegt für vier 160-GB-Karten, und einem INT4-Xeon-6-Pfad für den Offline-Einsatz.

• Meta veröffentlicht Durchsatz speziell für AMD — Das DFlash V2 Draft-Modell liefert 3,7× Durchsatz für eine einzelne Anfrage auf MI355X und 2,9× bei 16 gleichzeitigen Anfragen, wobei 6,4 entworfene Tokens pro Schritt akzeptiert werden; benutzerdefinierte Helion-Kernel in SGLang werden mit 1,03–3,95× Kernel-Level-Beschleunigungen über NVIDIA und AMD hinweg und einem 3%igen End-to-End-Gewinn auf MI350 zugeschrieben.

Die Geschichte ist also nicht „AMD-Unterstützung kommt zu spät“. Sondern dass AMD-Unterstützung zugleich einstudiert und ungemessen ankam: Die Artefakte, die Rezepte und die Speedups waren alle fertig, die Genauigkeitszahl aber nicht – und genau das ist die Lücke, die ein Nightly-Gate schließen soll.

Was die unabhängigen Zahlen in der Zwischenzeit sagen

Während die AMD-Genauigkeit ungeklärt ist, ist das Gesamtbild es nicht. Artificial Analysis führt Muse Spark Open mit einem Intelligence Index von 39, an neunter Stelle von 118 Modellen in seinem Vergleichsset, bei einem Median von 19 über vergleichbare Modelle hinweg – ein starkes Ergebnis. Sein Preis ist der Punkt, an dem Vorsicht angebracht ist: 1,25 $ pro Million Eingabe-Tokens und 4,25 $ pro Million Ausgabe, mit einem Cache-Rabatt von 88 %, einem Mischsatz von 0,78 $ und 0,84 $ Ausgaben pro Intelligence-Index-Aufgabe, was bei diesem Effizienzmaß den 32. Platz von 40 belegt. Die Ausgabegeschwindigkeit ist als nicht verfügbar aufgeführt, und der Eintrag führt Text- und Bildeingabe gegenüber der eigenen Angabe des Anbieters zu Text, Bild, Video und Audio auf – eine ungeklärte Abweichung, die eher kenntlich gemacht als entschieden werden sollte. Diese Zahlen sind unabhängig und anbieteragnostisch; die oben genannten AMP-Zahlen stammen von Meta.

Die Kurzfassung, falls Sie sich heute entscheiden

Wenn Ihre Kapazität AMD ist und Sie vorhatten, Muse Spark Open auf MI355X selbst zu hosten, dann ist die ehrliche Position, dass Sie die Messung sind. Es gibt einen vollständigen Day-Zero-Serving-Pfad, ein Quantisierungsrezept pro Beschleuniger, eine veröffentlichte Speculative-Decoding-Beschleunigung – und, zum Zeitpunkt dieses Schreibens, keinen veröffentlichten Genauigkeitswert für eine der beiden FP4-Zellen auf AMD-Silizium. Der PR liefert Ihnen unabhängig davon etwas Nützliches: Seine Eval-Konfiguration ist eine vollständige, direkt übernehmbare Definition dessen, wie ein ernsthafter Genauigkeitscheck für dieses Modell aussieht – bis hin zum Reasoning-Aufwand und zum top_p. Führen Sie ihn gegen Ihren eigenen Checkpoint aus, bevor Sie einen Kunden davor setzen, und achten Sie auf die vom Autor versprochenen Runs, die rebasten AITER-Patches und darauf, dass der MMMU-Schwellenwert durch einen gemessenen Wert ersetzt wird.

Der praktische Hinweis zur Bereitstellung eines vier Wochen alten Quantisierungs-Stacks

Ein Mechanismus im PR verdient Aufmerksamkeit. Die NVFP4-Zelle wird mit --quantization quark_mxfp4, geladen, was bedeutet, dass der Quell-Checkpoint NVFP4 ist und die Laufzeit ihn beim Laden auf MXFP4 requantisiert. Zwei numerisch unterschiedliche Pipelines werden unter einer Suite verglichen, weshalb jede ihren eigenen Server, ihre eigene Klasse und ihre eigene Bestanden/Nicht-bestanden-Zeile erhält. Metas eigene Anleitung besagt, dass der AMD FP8 (Quark)-Build auf GSM8K die BF16-Genauigkeit erreicht, aber diese Aussage bezieht sich auf FP8, nicht auf eine der beiden FP4-Zellen, und es ist eine Herstellermessung. Wenn Sie eine Quantisierung für die Produktion wählen, behandeln Sie die FP4-Zellen als unbestätigt, bis jemand die Zahl veröffentlicht.

Hier verdient sich die Routing-Schicht ihren Platz. Für einen Leser, der einen gehosteten Endpunkt aufruft, gibt es nichts von dieser Unsicherheit – aber wenn Sie die Person sind, die die Self-Hosting-Entscheidung trifft, besteht der Weg, ein unerprobtes Modell abzusichern, darin, einen kleinen Teil des Traffics darauf zu leiten, und zwar hinter etwas, das den Traffic zurückverlagern kann. OrcaRouter routet heute Muse Spark 1.2 und Muse Spark 1.1 und routet Muse Spark Open nicht, daher ist nichts hiervon eine Behauptung über das Hosting des neuen Modells; es ist dieselbe einheitliche API über 200+ Modelle hinweg, mit automatischem Failover, wenn ein Anbieter sich verschlechtert, und einer Routing-DSL zum Aufteilen des Traffics zwischen Modellen und Anbietern per Konfiguration statt durch Codeänderung. Wir geben den Listenpreis des Anbieters mit 0 % Aufschlag weiter, was einen vorsichtigen Parallelbetrieb günstig genug macht, um ihn tatsächlich durchzuführen.

Was Muse Spark Open selbst betrifft, läuft die Verfügbarkeit heute über Metas eigene API und eine Reihe von Drittanbieter-Inferenzplattformen, dazu die Downloads der Gewichte auf Hugging Face und die zwei Cloud-Modellkataloge, die Meta genannt hat. Bei AMD ist der schnellste Weg zu einer belastbaren Zahl das Gate in diesem PR — sobald es jemand ausführt.

Was zu sehen

• Das Landen des Day-0 PR — das Genauigkeits-Gate kann nicht gemergt werden, bevor dieser landet, und mit seinem Eintreffen wird der eigene Code des Modells zur Baseline statt zu einem Snapshot.

• Das Rebase des AITER-Patches — konkret die AITER-Hälfte des Unified-Attention-Patches gegen die gepinnte Revision. Bis dieser sich anwenden lässt, ist die AMD-Suite rot aus Gründen, die nichts mit dem Modell zu tun haben.

• Die MMMU-Schwelle entfernt sich von 0,50 — in dem Moment, in dem ein echter MI355X-Wert den Platzhalter ersetzt, beginnt das multimodale Gate zu arbeiten.

• Die ersten veröffentlichten Run-Berichte — der Autor hat zugesagt, Runs auf allen drei Images zu posten, bevor er die PR als bereit markiert. Das ist der erste AMD-Genauigkeitsmesswert für Muse Spark Open, und er wird aus einem Test-Harness stammen statt von einer Hersteller-Folie.

• Ob die NVIDIA- und AMD-Zahlen auseinandergehen – wenn GSM8K auf dem MI355X nahe 0,93 bleibt, während MMMU deutlich niedriger ausfällt als auf jeder anderen Plattform, dann ist der Vision-Pfad auf ROCm die eigentliche Geschichte, und der Framework-PR, der das Gate hinzugefügt hat, wird der erste Ort gewesen sein, an dem es sichtbar wurde.

Für alle, die verfolgen, wie Open-Weight-Flaggschiffmodelle tatsächlich auf Sekundärhardware gelangen, ist dies die Datei, die man geöffnet lassen sollte. Der Launch-Beitrag sagt einem, dass das Modell auf AMD verfügbar ist. Der Pull Request sagt einem, dass Stand 15. Oktober 2026 noch niemand geprüft hat, ob es dort noch gut ist.