Muse Spark Open on AMD: Day-One Support, a Placeholder Threshold, and a Gate Nobody Has Run

Meta released Muse Spark Open on October 15, 2026, and that same evening a draft pull request landed in SGLang whose title reads less like a feature than an admission: [AMD] Add a Muse Spark Open MI35x nightly GSM8K + MMMU accuracy gate. The reason it exists is spelled out in the PR body. On HIP, the model's code dispatches to a separate ROCm implementation — sglang.srt.rocm_muse_spark — and no continuous-integration job in the project covers it. By the author's own account the new gate has not been run on hardware, one of its two pass/fail thresholds is a placeholder invented because no AMD measurement existed to use, and the CI job would fail at its first step today anyway. This is not a launch story. It is a leak-shaped trace of what shipping an 816-billion-parameter open-weight model onto AMD hardware actually looks like from inside a serving framework.

What the pull request actually adds

The gate is one nightly job that covers both FP4 checkpoints in the project's MI355X "Low Latency" cookbook recipe. In the project's own terms:

• Suite — nightly-amd-4-gpu-mi35x-muse-spark-open, job nightly-4-gpu-mi35x-muse-spark-open on the linux-mi35x-gpu-8 runner at TP4, with a 21,600-second per-file cap.

• Two servers, two classes — one per checkpoint, because the NVFP4 cell takes a different load path from the MXFP4 one. MXFP4 loads amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4; NVFP4 loads the Meta repo's -NVFP4 checkpoint with --quantization quark_mxfp4, which requantizes to MXFP4 at load time.

• Recipe flags — TP4/EP4, AITER attention at page size 16, MUSE_MOE_BACKEND=flydsl, DFlash2 with a Triton draft-attention backend.

• What is measured — full-split GSM8K through sgl-eval with thinking on, reasoning_effort=xhigh, 32,768 max tokens, temperature 1.0, top_p 0.95, plus 100 MMMU samples for the multimodal path.

• Wall time — a single 8-GPU runner serves both checkpoints one after the other, roughly four hours.

The MMMU inclusion is the detail that makes the PR worth reading. As the author puts it, on HIP the model dispatches into a ROCm implementation and the image path through that implementation is otherwise untested — so the vision tower is, at the moment this was written, the least exercised part of Muse Spark Open on AMD silicon.

The two numbers in the PR, and where they came from

Nothing here is a measurement of Muse Spark Open on AMD hardware, and the PR says so.

• GSM8K 0.93 — lifted wholesale from the B300 Muse Spark test in the Day-0 PR. B300 is NVIDIA Blackwell Ultra. The threshold, the sampling settings and the scoring setup were all carried across from Hopper-class-to-Blackwell work onto a completely different accelerator stack.

• MMMU 0.50 — described in the PR as "a placeholder with no AMD measurement behind it." That is unusually candid for a CI file, and it is worth understanding why it matters more than it looks. A gate with an invented floor is not a correctness check; it is a tripwire. It will catch a catastrophic regression and will silently wave through a mild one. If the real MI355X MMMU score turns out to be 0.68, the gate permits a six-point slide before it fires.

• DFlash2 accept length — reported in the job's step summary, deliberately not gated. So the speculative-decoding path is observable but unprotected: a draft model that quietly stops predicting well will show up in a summary nobody's alerting on.

That last point generalises beyond this one PR. A nightly accuracy gate measures the model code the framework ships, not the model a provider serves you. Different quantization recipe, different page size, different attention backend, different draft model, and you are outside the envelope the gate was written for.

The gate is blocked, and the reason is mundane

The PR stays in draft until the Day-0 support PR lands, which is a normal dependency. The more interesting blocker is the AMD AITER patch set. Those patches are validated against one revision of AITER (4ad9983), but the ROCm Dockerfile on main pins a different one (2bb5491). Against the pinned revision, 04-aiter-muse-moe-flydsl.patch applies cleanly; the AITER half of 03-plan-b-aiter-unified-attention-3d.patch does not, because aiter/ops/triton/attention/unified_attention.py was refactored after the patches were cut. The author has not checked the third patch, which targets the composable_kernel submodule. Until the second one applies, the job fails before it evaluates anything.

Read that as a signal about maturity rather than as an indictment. AMD serving paths for very large mixture-of-experts models are being rebuilt continuously upstream, and a vendor lockfile is exactly what breaks the patch set that got the model running in the first place.

Day one on AMD was not actually day one

The gate being unrun is not the same as the AMD path being new. The surrounding timeline tells a fuller story than either the launch post or the PR does.

• AMD quantization artifacts predate the launch by about four weeks — the Quark-MXFP4 and Quark-PTPC-FP8 checkpoints for Muse Spark Open were published to Hugging Face on 2026-09-18, roughly a month before Meta announced the weights.

• Framework support opened on launch day — SGLang's [Day0] Support Muse Spark Open PR and vLLM's [Model] Add Muse Spark Open support PR were both opened within twelve minutes of each other on 2026-10-15, which is what genuine day-zero coordination looks like.

• Meta's own build guide ships AMD recipes — FP8 (Quark) for Instinct MI355X served through vLLM, and MXFP4 (Quark) for MI350X and MI355X, alongside an Intel MXFP4 path sized for four 160 GB cards and an INT4 Xeon 6 path for offline use.

• Meta published throughput for AMD specifically — the DFlash V2 draft model gives 3.7× throughput for a single request on MI355X and 2.9× at 16 concurrent requests, with 6.4 drafted tokens accepted per step; custom Helion kernels in SGLang are credited with 1.03–3.95× kernel-level speedups across NVIDIA and AMD and a 3% end-to-end gain on MI350.

So the story is not "AMD support arrives late." It is that AMD support arrived rehearsed and unmeasured at the same time: the artifacts, the recipes and the speedups were all ready, and the accuracy number was not, which is precisely the gap a nightly gate exists to close.

What the independent numbers say meanwhile

While AMD accuracy is unresolved, the aggregate picture is not. Artificial Analysis lists Muse Spark Open at an Intelligence Index of 39, ninth of 118 models in its comparison set, with a median of 19 across comparable models — a strong result. Its price is where the caution sits: $1.25 per million input tokens and $4.25 per million output, with an 88% cache discount, a $0.78 blended rate and $0.84 of spend per Intelligence Index task, which ranks 32nd of 40 on that efficiency measure. Output speed is listed as not available, and the listing records text and image input against the vendor's own text, image, video and audio claim — an unresolved discrepancy worth flagging rather than adjudicating. Those figures are independent and vendor-agnostic; the AMP figures above are Meta's.

The short version if you are deciding today

If your capacity is AMD and you were planning to self-host Muse Spark Open on MI355X, the honest position is that you are the measurement. There is a full day-zero serving path, a quantization recipe per accelerator, a published speculative-decoding speedup — and, as of this writing, no published accuracy score for either FP4 cell on AMD silicon. The PR hands you something useful regardless: its eval configuration is a complete, ready-to-lift definition of what a serious accuracy check on this model looks like, down to the reasoning effort and the top_p. Run it against your own checkpoint before you put a customer in front of it, and watch for the author's promised runs, the rebased AITER patches, and the MMMU threshold being replaced with a measured score.

The practical note on serving a four-week-old quantization stack

One mechanic in the PR repays attention. The NVFP4 cell is loaded with --quantization quark_mxfp4, meaning the source checkpoint is NVFP4 and the runtime requantizes it to MXFP4 at load. Two numerically different pipelines are being compared under one suite, which is exactly why each gets its own server, its own class and its own pass/fail line. Meta's own guidance is that the AMD FP8 (Quark) build matches BF16 accuracy on GSM8K, but that claim is about FP8, not about either FP4 cell, and it is a vendor measurement. If you are choosing a quantization for production, treat the FP4 cells as unverified until someone publishes the number.

This is where the routing layer earns its place. None of this uncertainty exists for a reader calling a hosted endpoint — but if you are the one making the self-host decision, the way to de-risk an unproven model is to put a small share of traffic on it behind something that can move traffic back. OrcaRouter routes Muse Spark 1.2 and Muse Spark 1.1 today and does not route Muse Spark Open, so nothing here is a claim about hosting the new model; it is the same one API across 200+ models, with automatic failover when a provider degrades and a routing DSL for splitting traffic between models and providers by configuration rather than by code change. We pass the provider's list price through with 0% markup, which is what makes a cautious parallel run cheap enough to actually do.

For Muse Spark Open itself, availability today runs through Meta's own API and a set of third-party inference platforms, plus the weight downloads on Hugging Face and the two cloud model catalogues Meta named. On AMD, the fastest way to a trustworthy number is the gate in this PR — once someone runs it.

What to watch

• The Day-0 PR landing — the accuracy gate cannot merge before it does, and its arrival is when the model's own code becomes the baseline rather than a snapshot.

• The AITER patch rebase — specifically the AITER half of the unified-attention patch against the pinned revision. Until that applies, the AMD suite is red for reasons that have nothing to do with the model.

• The MMMU threshold moving off 0.50 — the moment a real MI355X score replaces the placeholder, the multimodal gate starts doing work.

• The first published run reports — the author has committed to posting runs on all three images before marking the PR ready. That is the first AMD accuracy reading for Muse Spark Open, and it will come from a test harness rather than a vendor slide.

• Whether NVIDIA and AMD numbers diverge — if GSM8K holds near 0.93 on MI355X while MMMU lands materially lower than any other platform, the vision path on ROCm is the story, and the framework PR that added the gate will have been the first place it was visible.

For anyone tracking how open-weight flagships actually reach secondary hardware, this is the file to keep open. The launch post tells you the model is available on AMD. The pull request tells you that as of October 15, 2026, nobody has yet checked whether it is still good there.