AMD 上的 Muse Spark Open：首日支持、一个占位阈值，以及一道无人运行过的门

Meta 发布了 Muse Spark Open，发布时间是 2026 年 10 月 15 日；而就在当晚，一个草稿拉取请求落到了 SGLang 中，其标题读起来与其说像一项功能，不如说像一份承认：[AMD] 为 Muse Spark Open MI35x 添加夜间 GSM8K + MMMU 准确率门禁。它存在的原因在 PR 正文里写得很清楚。在 HIP 上，该模型的代码会分派到一个单独的 ROCm 实现——sglang.srt.rocm_muse_spark——而项目中没有任何持续集成任务覆盖它。据作者自己所说，这个新门禁尚未在硬件上运行过，它的两个通过/失败阈值中有一个是占位符，因为当时没有可用的 AMD 测量值，而且这个 CI 任务今天无论如何都会在第一步就失败。这不是一个发布故事。它是一道泄漏状的痕迹，记录了将一个 8160 亿参数的开放权重模型发布到 AMD 硬件上时，从服务框架内部看到的真实情形。

pull request 实际添加的内容

这个门禁是一项每晚运行的作业，覆盖了项目 MI355X“低延迟”cookbook 配方中的两个 FP4 检查点。用项目自己的话来说：

• 套件 — nightly-amd-4-gpu-mi35x-muse-spark-open，作业 nightly-4-gpu-mi35x-muse-spark-open 在 linux-mi35x-gpu-8 runner 上以 TP4 运行，单个文件上限为 21,600 秒。

• 两个服务器，两个类——每个检查点一个，因为 NVFP4 单元所走的加载路径与 MXFP4 单元不同。MXFP4 加载 amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4；NVFP4 加载 Meta 仓库的 -NVFP4 检查点，并使用 --quantization quark_mxfp4，该参数会在加载时重新量化为 MXFP4。

• 配方标志 — TP4/EP4，页面大小为 16 时的 AITER 注意力，MUSE_MOE_BACKEND=flydsl，DFlash2 搭配 Triton 草稿注意力后端。

• 测量内容 — 通过 sgl-eval 运行全量划分的 GSM8K，开启 thinking，reasoning_effort=xhigh，最大 32,768 tokens，temperature 1.0，top_p 0.95，另加 100 个 MMMU 样本用于多模态路径。

• 实际耗时 — 单个 8-GPU 运行器依次为两个检查点提供服务，大约需要四小时。

MMMU 的纳入，是让这个 PR 值得一读的细节。正如作者所说，在 HIP 上，模型会分派到某个 ROCm 实现中，而经由该实现的图像路径在其他情况下未经测试——因此，在撰写本文时，视觉塔是 Muse Spark Open 在 AMD 芯片上最少被检验的部分。

PR 中的两个数字，以及它们的来源

这里没有任何内容是在 AMD 硬件上对 Muse Spark Open 的测量，PR 里也这么说了。

• GSM8K 0.93——从 Day-0 PR 中的 B300 Muse Spark 测试中原封不动地照搬而来。B300 是 NVIDIA Blackwell Ultra。阈值、采样设置和评分方案，全都是从 Hopper 级到 Blackwell 的工作中照搬到一套完全不同的加速器栈上。

• MMMU 0.50 — 在 PR 中被描述为“一个背后没有任何 AMD 测量数据的占位符”。对于 CI 文件来说，这种坦率并不寻常，而且值得弄清楚为什么它比表面看起来更重要。一个用编造出来的下限设定的门禁不是正确性检查；它是绊线。它能捕捉到灾难性回归，却会悄无声息地放行轻微回归。如果真实的 MI355X MMMU 分数结果是 0.68，那么这道门禁允许下滑六分才会触发。

• DFlash2 接受长度 —— 在作业的步骤摘要中报告，刻意不设门控。因此，推测解码路径虽可观测，却未受保护：一个悄悄停止良好预测的草稿模型，只会出现在无人告警的摘要里。

最后一点的意义超出了这一个 PR。每晚运行的准确率门禁衡量的是框架所发布的模型代码，而不是某个提供商为你提供服务的模型。不同的量化方案、不同的页面大小、不同的注意力后端、不同的草稿模型，都会让你落到这个门禁所针对的范围之外。

大门被堵住了，原因很平常。

该 PR 会一直保持草稿状态，直到 Day-0 支持 PR 合入，这是正常的依赖关系。更有意思的阻塞项是 AMD AITER 补丁集。这些补丁是针对 AITER 的某一个修订版本（4ad9983）验证的，但 main 上的 ROCm Dockerfile 固定的却是另一个版本（2bb5491）。针对所固定的那个修订版本，04-aiter-muse-moe-flydsl.patch 可以干净地应用；而 03-plan-b-aiter-unified-attention-3d.patch 中涉及 AITER 的那一半则无法应用，因为 aiter/ops/triton/attention/unified_attention.py 在这些补丁制作完成之后被重构了。作者尚未检查第三个补丁，该补丁针对的是 composable_kernel 子模块。在第二个补丁能够应用之前，该任务会在评估任何内容之前就失败。

把这看作关于成熟度的信号，而不是一项指控。AMD 面向超大型混合专家模型的服务路径正在上游持续重建，而厂商锁文件恰恰会破坏最初让模型跑起来的那套补丁集。

在 AMD 的第一天其实并不是第一天

门禁未运行，并不等同于 AMD 路径是新的。相关时间线所讲述的故事，比发布帖或 PR 都更完整。

• AMD 量化产物比发布早了约四周——Quark-MXFP4和Quark-PTPC-FP8检查点已于 2026-09-18 发布到 Hugging Face（面向 Muse Spark Open），比 Meta 公布这些权重早了大约一个月。

• 框架支持在发布当天就已开启 — SGLang 的 [Day0] 支持 Muse Spark Open PR 与 vLLM 的 [模型] 新增 Muse Spark Open 支持 PR 于 2026-10-15 在相隔不到十二分钟内先后创建，这才是真正零日协同该有的样子。

• Meta 自家的构建指南提供了 AMD 方案 —— 针对 Instinct MI355X 的 FP8（Quark），通过 vLLM 提供服务；以及面向 MI350X 和 MI355X 的 MXFP4（Quark），此外还有适配四张 160 GB 显卡的 Intel MXFP4 路径，以及用于离线场景的 INT4 Xeon 6 路径。

• Meta 专门公布了 AMD 的吞吐量数据——DFlash V2 草稿模型在 MI355X 上使单请求吞吐量提升 3.7 倍，16 路并发请求时提升 2.9 倍，每步可接受 6.4 个草拟 token；SGLang 中的自定义 Helion 内核被认为在 NVIDIA 和 AMD 上实现了 1.03–3.95 倍的核函数级加速，并在 MI350 上带来 3% 的端到端增益。

所以，故事并不是“AMD 支持来得晚”。而是 AMD 支持在登场时既经过了排练，又未经度量：制品、配方和加速比全都就绪，唯独准确率数字没有准备好——而这恰恰正是夜间门禁存在所要堵上的缺口。

与此同时，独立数据怎么说

尽管 AMD 的准确性尚未确定，但整体情况并非如此。Artificial Analysis 将 Muse Spark Open 的智能指数列为 39，在其比较集中的 118 个模型中排名第九，而同类模型的中位数为 19——这是一个强劲的结果。需要谨慎之处在于其价格：每百万输入 token 1.25 美元，每百万输出 4.25 美元，缓存折扣为 88%，混合费率为 0.78 美元，每个智能指数任务的支出为 0.84 美元，在该效率指标上于 40 个中排名第 32。输出速度列为不可用，且该列表记录的是文本和图像输入，而供应商自身则宣称支持文本、图像、视频和音频——这一未解决的差异值得指出，而非加以裁定。这些数据是独立的，且不依赖厂商；上文中的 AMP 数据来自 Meta。

如果你今天就要做决定，这是简短版

如果你的算力平台是 AMD，而且你正打算在 MI355X 上自托管 Muse Spark Open，那么老实说，你就是那个测量本身。已经有完整的首日服务路径、每种加速器对应的量化配方、已发布的投机解码加速比——而截至本文撰写时，AMD 芯片上两个 FP4 单元都还没有公开的准确率分数。无论如何，这个 PR 都给了你有用的东西：它的评估配置完整且可以直接照搬，定义了对这个模型做严肃准确率检查应当是什么样，细到 reasoning effort 和 top_p。在把客户带到它面前之前，先拿你自己的检查点跑一遍，并留意作者承诺的运行结果、变基后的 AITER 补丁，以及 MMMU 阈值被实测分数取代。

关于服务一个已发布四周的量化技术栈的实用笔记

PR 中有一个机制值得关注。NVFP4 单元格加载时使用了 --quantization quark_mxfp4，这意味着源检查点是 NVFP4，而运行时在加载时会将其重新量化为 MXFP4。两个数值上不同的流水线正在同一套测试套件下进行比较，这正是为什么每个都有各自的服务器、各自的类别以及各自的通过/失败结果行。Meta 自己的指导是，AMD FP8（Quark）构建在 GSM8K 上达到与 BF16 相同的准确率，但该说法针对的是 FP8，而不是两个 FP4 单元格中的任何一个，并且它是供应商的测量结果。如果你正在为生产环境选择量化方案，请将 FP4 单元格视为未经验证，直到有人公布具体数值。

这正是路由层体现其价值之处。对于调用托管端点的读者来说，这些不确定性都不存在——但如果你是那个要做出自托管决策的人，为尚未经过验证的模型降低风险的方法，是让它承载一小部分流量，并置于某种能够将流量切回的机制之后。OrcaRouter 目前已路由 Muse Spark 1.2 和 Muse Spark 1.1，并不路由 Muse Spark Open，因此这里没有任何内容是在声称托管这个新模型；它只是同一个覆盖 200+ 模型的单一 API，具备当提供商性能下降时自动故障转移以及一套路由 DSL，可通过配置而非修改代码在模型与提供商之间拆分流量。我们按提供商的标价原价传递，0% 加价，这正是让谨慎的并行运行足够便宜、真正可行的原因。

对于 Muse Spark Open 本身，如今的可用途径包括 Meta 自有 API 和一组第三方推理平台，再加上 Hugging Face 上的权重下载，以及 Meta 点名的两个云模型目录。在 AMD 上，要获得可信数字，最快的方式就是这个 PR 中的门禁——只要有人运行它。

看什么

• Day-0 PR 的合入——在它合入之前，准确率门禁无法合并，而它的到来意味着模型自身的代码成为基线，而非一份快照。

• AITER 补丁变基 —— 具体而言，是针对固定版本的统一注意力补丁中属于 AITER 的那一半。在该补丁应用成功之前，AMD 测试套件报红的原因与模型本身毫无关系。

• MMMU 阈值脱离 0.50——一旦真实的 MI355X 分数取代占位值，多模态门控便开始发挥作用。

• 首次公布的运行报告——作者已承诺在将 PR 标记为就绪之前，会对全部三张图像发布运行结果。这是 Muse Spark Open 的首个 AMD 精度读数，而且它将来自测试工具，而非厂商的宣传幻灯片。

• NVIDIA 与 AMD 的数值是否出现分化——如果 GSM8K 在 MI355X 上保持在 0.93 左右，而 MMMU 却明显低于其他任何平台，那么 ROCm 上的视觉路径就是关键所在，而添加该门控的那个框架 PR 将是它首次显现的地方。

对于任何关注开放权重旗舰模型究竟如何进入二线硬件的人来说，这就是那个值得一直打开的文件。发布帖会告诉你，该模型已在 AMD 上可用。而拉取请求则告诉你，截至 2026 年 10 月 15 日，还没有人检查过它在那边是否仍然表现良好。