Muse Spark 在 AMD 上開放：首日支援、一個佔位符閾值，以及一道沒人跑過的閘門

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 硬體究竟是什麼樣子。

提取請求實際上新增了什麼

這個關卡是一項每晚執行的作業，涵蓋專案 MI355X「Low Latency」cookbook 配方中的兩個 FP4 檢查點。以專案本身的說法：

• 套件 — nightly-amd-4-gpu-mi35x-muse-spark-open，工作 nightly-4-gpu-mi35x-muse-spark-open於linux-mi35x-gpu-8 執行器上以 TP4 執行，每個檔案上限為 21,600 秒。

• 兩部伺服器、兩個類別 — 每個檢查點各一個，因為 NVFP4 單元所走的載入路徑與 MXFP4 單元不同。MXFP4 會載入 amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4；NVFP4 則載入 Meta 儲存庫的 -NVFP4 檢查點，並搭配 --quantization quark_mxfp4，這會在載入時重新量化為 MXFP4。

• Recipe 旗標 — TP4/EP4、頁面大小為 16 的 AITER 注意力、MUSE_MOE_BACKEND=flydsl，DFlash2 搭配 Triton 草稿注意力後端。

• 測量項目 — 透過 sgl-eval 執行完整分割的 GSM8K，並開啟思考模式，reasoning_effort=xhigh，最大 32,768 個 token，temperature 1.0，top_p 0.95，另加 100 個 MMMU 樣本以供多模態路徑使用。

• 實際耗時 — 單一 8-GPU 執行器會依序處理這兩個檢查點，大約需要四小時。

MMMU 的納入，才是讓這個 PR 值得一讀的細節。正如作者所言，在 HIP 上，模型會分派到 ROCm 實作，而透過該實作的影像路徑在其他方面未經測試——因此，在撰寫本文時，視覺塔是 Muse Spark Open 在 AMD 晶片上最少被測試到的部分。

PR 中的兩個數字，以及它們的來源

這裡沒有任何一項是 Muse Spark Open 在 AMD 硬體上的測量，而 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 可以乾淨套用；至於 AITER 部分的 03-plan-b-aiter-unified-attention-3d.patch 則無法，因為 aiter/ops/triton/attention/unified_attention.py 在補丁建立之後被重構了。作者尚未檢查第三個補丁，該補丁的目標是 composable_kernel 子模組。在第二個補丁能套用之前，作業會在評估任何內容之前就失敗。

請把它解讀為成熟的訊號，而不是一項指控。AMD 針對極大型混合專家模型（MoE）的服務路徑，正持續在上游重建；而廠商鎖定檔正是會破壞最初讓模型跑起來的那組修補程式集的元兇。

在 AMD 的第一天其實並不是第一天

這道關卡未被執行，並不等同於 AMD 路徑就是新的。周遭的時間軸比發表貼文或公關稿更能說出更完整的故事。

• AMD 量化產物比發布時間早了大約四週——Quark-MXFP4與Quark-PTPC-FP8檢查點已於 2026-09-18 發布至 Hugging Face，比 Meta 宣布這些權重早了約一個月。

• 框架支援在發佈首日便同步開通——SGLang 的[Day0] 支援 Muse Spark OpenPR 與 vLLM 的[Model] 新增 Muse Spark Open 支援PR，兩者於 2026-10-15 相隔不到十二分鐘內先後開出，這正是名副其實的零日協作樣貌。

• Meta 自家的建置指南提供 AMD 配方 —— 透過 vLLM 服務的 Instinct MI355X 專用 FP8（Quark），以及 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 列於 Intelligence Index 39 分，在其比較組的 118 個模型中排名第九，而可比模型的中位數為 19——這是相當強勁的結果。需要審慎看待的是其價格：每百萬輸入 token 為 1.25 美元、每百萬輸出 token 為 4.25 美元，享有 88% 快取折扣，混合費率為 0.78 美元，每項 Intelligence Index 任務的支出為 0.84 美元，在該效率指標上於 40 個模型中排名第 32。輸出速度列為無法取得，而該清單記錄的輸入為文字與圖像，與廠商自身宣稱的文字、圖像、影片與音訊不符——這是值得標記、而非逕行裁斷的未解歧異。這些數據是獨立且不偏向任何廠商的；上述 AMP 的數據則是 Meta 的。

如果你今天就要做決定，這是簡短版

如果你的容量是 AMD，而你原本打算在 MI355X 上自行託管 Muse Spark Open，那麼老實說，你就是那個量測基準。這裡有一條完整的第零日 serving 路徑、每個加速器各自的量化配方、已公布的推測解碼加速幅度——而且，就本文撰寫當下而言，AMD 晶片上兩個 FP4 組態都沒有已公布的準確度分數。不過這個 PR 還是給了你一些有用的東西：它的 eval 設定是一份完整、可直接沿用的定義，說明對這個模型做一次嚴謹的準確度檢查該長什麼樣子，連推理強度和 top_p 都寫清楚了。在你把客戶帶到它面前之前，先拿你自己的 checkpoint 跑一遍，並且留意作者承諾要跑的執行結果、rebase 過的 AITER 修補程式，以及 MMMU 門檻被替換成實測分數這件事。

關於部署已上線四週的量化堆疊的實務筆記

PR 中有一項機制值得特別留意。NVFP4 這個 cell 是以 --quantization quark_mxfp4 載入的，意思是來源 checkpoint 是 NVFP4，而執行環境會在載入時將其重新量化為 MXFP4。同一個測試套件下比較的是兩條數值上不同的管線，這正是為什麼每一條都各自擁有自己的伺服器、自己的類別，以及自己的通過／失敗判定列。Meta 自家的指引指出，AMD FP8（Quark）建置在 GSM8K 上能達到與 BF16 相符的準確度，但該說法針對的是 FP8，而非任何一個 FP4 cell，而且那是廠商自行測量的結果。如果你要為正式環境挑選量化方式，在有人公布數字之前，請把 FP4 cell 視為尚未驗證。

這正是路由層發揮價值的地方。對於呼叫代管端點的讀者來說，這些不確定性都不存在——但如果你是做自架決策的那個人，要降低未經驗證模型的風險，做法就是把一小部分流量導到它上面，並置於某個能把流量移回去的機制之後。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 日，還沒有人檢查過它在那裡是否仍然表現良好。