AMDでMuse Sparkがオープン：Day-Oneサポート、プレースホルダーのしきい値、そして誰も実行していないゲート

MetaはMuse Spark Openを2026年10月15日にリリースし、その同じ夜、SGLangにドラフトのプルリクエストが着地した。そのタイトルは機能というより告白のように読める：[AMD] Muse Spark Open MI35x ナイトリー GSM8K + MMMU 精度ゲートを追加。これが存在する理由はPR本文に明記されている。HIP上では、このモデルのコードは別個のROCm実装——sglang.srt.rocm_muse_spark——へディスパッチされ、プロジェクト内のどの継続的インテグレーションジョブもそれをカバーしていない。著者自身の説明によれば、この新しいゲートはハードウェア上で実行されたことがなく、2つある合否しきい値のうち1つは、使えるAMDの測定値が存在しなかったためにでっち上げられたプレースホルダーであり、しかもそのCIジョブは今日時点で最初のステップで失敗するだろう。これはローンチの記事ではない。8160億パラメータのオープンウェイトモデルをAMDハードウェアで出荷するとは実際にどういうことなのかを、サービングフレームワークの内側から見た、漏洩の形をした痕跡である。

プルリクエストが実際に追加するもの

ゲートは、プロジェクトのMI355X「Low Latency」クックブックレシピにある両方のFP4チェックポイントをカバーする1つのナイトリージョブです。プロジェクト独自の用語では：

• スイート — nightly-amd-4-gpu-mi35x-muse-spark-open、ジョブ nightly-4-gpu-mi35x-muse-spark-openをlinux-mi35x-gpu-8ランナー上でTP4、ファイルごとの上限21,600秒で実行

• 2つのサーバー、2つのクラス — チェックポイントごとに1つです。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、Tritonドラフトアテンションバックエンドを備えたDFlash2。

• 測定対象 — thinking を有効にした sgl-eval 経由の full-split GSM8K、reasoning_effort=xhigh、最大トークン数 32,768、temperature 1.0、top_p 0.95、さらにマルチモーダル経路向けの MMMU サンプル 100 件。

• 実時間 — 単一の8-GPUランナーが両方のチェックポイントを順番に処理し、およそ4時間かかります。

MMMUを含めている点が、このPRを読む価値のあるものにしている細部だ。著者が述べているように、HIP上ではモデルはROCm実装にディスパッチされ、その実装を通る画像パスはそれ以外にテストされていない——そのため、これが書かれた時点では、ビジョンタワーはAMDシリコン上のMuse Spark Openで最もテスト実行が少ない部分である。

PRにある2つの数値と、それらがどこから来たのか

ここにあるものはどれも、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 だった場合、このゲートは発動するまでに 6 ポイントの低下を許容することになる。

• DFlash2 accept length — ジョブのステップサマリーで報告され、意図的にゲートされていない。つまり、投機的デコーディングの経路は観測可能だが保護されていない。ドラフトモデルがひっそりと予測精度を落としても、誰もアラートを上げていないサマリーに現れるだけだ。

その最後の点は、この1つのPRを超えて一般化できます。夜間の精度ゲートが測っているのは、フレームワークが出荷するモデルコードであって、プロバイダーがあなたに提供するモデルではありません。量子化レシピが違う、ページサイズが違う、アテンションバックエンドが違う、ドラフトモデルが違う——それだけで、あなたはそのゲートが想定して書かれた範囲の外に出てしまいます。

ゲートは塞がれており、その理由はありふれている

Day-0 サポート PR がマージされるまで、この 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 サブモジュールを対象とする 3 番目のパッチは、著者はまだ確認していません。2 番目のパッチが適用されるまで、ジョブは何かを評価する前に失敗します。

それは非難ではなく、成熟度に関するシグナルとして受け止めよう。非常に大規模な Mixture-of-Experts モデル向けの AMD のサービングパスは、アップストリームで継続的に再構築されており、ベンダーロックファイルこそが、そもそもそのモデルを動作させたパッチセットを壊す原因なのだ。

AMDでの初日は、実は初日ではなかった

ゲートが未実行であることは、AMD パスが新しいことと同じではない。前後のタイムラインは、ローンチ投稿や PR のどちらよりも、より全貌を伝えている。

• AMDの量子化アーティファクトは、ローンチより約4週間先行していた — Quark-MXFP4およびQuark-PTPC-FP8チェックポイントは2026年9月18日にHugging Faceへ公開されており、Metaがウェイトを発表するおよそ1か月前のことだった。

• ローンチ当日にフレームワーク対応が開始 — SGLang の [Day0] Muse Spark Open サポート PR と vLLM の [Model] Muse Spark Open サポートを追加 PR は、2026-10-15 に互いに12分以内のタイミングで両方ともオープンされました。これこそが真のデイゼロ連携の姿です。

• Meta自身のビルドガイドにはAMDのレシピが含まれています — vLLM経由で提供されるInstinct MI355X向けFP8（Quark）、およびMI350XとMI355X向けMXFP4（Quark）、さらに160 GBカード4枚向けに調整されたIntel MXFP4パスと、オフライン利用向けのINT4 Xeon 6パスも含まれています。

• Metaが特にAMD向けに公開したスループット — DFlash V2ドラフトモデルは、MI355Xでの単一リクエストで3.7倍のスループット、16並列リクエストで2.9倍を実現し、ステップあたり6.4個のドラフトトークンが受理される。SGLangのカスタムHelionカーネルには、NVIDIAとAMDにわたる1.03～3.95倍のカーネルレベルの高速化と、MI350での3%のエンドツーエンドの向上が認められている。

つまり話の本質は「AMDサポートの到着が遅れた」ということではない。AMDサポートが、リハーサル済みの部分と未計測の部分を同時に携えてやって来た、ということだ。アーティファクト、レシピ、高速化はすべて揃っていたのに、精度の数値だけが揃っていなかった——これはまさに、ナイトリーゲートが埋めるために存在するギャップである。

一方、独立した数値が示すもの

AMDの精度は未解決だが、全体像はそうではない。Artificial AnalysisはMuse Spark OpenをIntelligence Index 39としてリストしており、比較セット内の118モデル中9位で、同等モデル全体の中央値は19である — これは強い結果だ。注意すべきはその価格である：入力トークン100万個あたり$1.25、出力100万個あたり$4.25で、88%のキャッシュ割引、$0.78のブレンドレート、Intelligence Indexタスクあたり$0.84の支出であり、その効率指標では40中32位にランクされる。出力速度は利用不可と記載されており、この記載は、ベンダー自身のテキスト、画像、動画、音声という主張に対して、テキストと画像の入力を記録している — 裁定するよりも指摘する価値のある未解決の不一致である。これらの数値は独立しており、ベンダーに依存しない。上記のAMPの数値はMetaのものである。

今日決める方へ：短縮版

あなたの計算基盤がAMDで、MI355X上でMuse Spark Openをセルフホストしようとしているなら、正直なところ、測定を担うのはあなた自身だ。完全なday-zeroのサービングパス、アクセラレータごとの量子化レシピ、公開された投機的デコーディングの高速化はある——そして本稿執筆時点では、AMDシリコン上のどちらのFP4セルについても公開された精度スコアはない。それでもこのPRは有用なものを与えてくれる。そのeval設定は、このモデルに対する本格的な精度チェックとはどういうものかを示す、完全でそのまま流用可能な定義であり、reasoning effortやtop_pに至るまで網羅している。顧客の前に出す前に、自分のチェックポイントに対してこれを実行し、著者が約束した実行、リベースされたAITERパッチ、そしてMMMU閾値が実測スコアに置き換えられることを注視せよ。

4週間前の量子化スタックをサービングする際の実践的な注意点

PR内の1つの仕組みは注目に値します。NVFP4セルは--quantization quark_mxfp4でロードされます。これは、ソースチェックポイントがNVFP4であり、ランタイムがロード時にそれをMXFP4に再量子化することを意味します。数値的に異なる2つのパイプラインが1つのスイートで比較されています。だからこそ、それぞれに独自のサーバー、独自のクラス、独自の合否ラインが与えられています。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 が挙げた2つのクラウドモデルカタログを通じたものだ。AMD に関して言えば、信頼できる数値に最速でたどり着く方法はこの PR のゲートだ — 誰かがそれを実行しさえすれば。

何を見るべきか

• Day-0 PR のマージ — 精度ゲートはそれがマージされるまでマージできず、それがマージされた時点で、モデル自身のコードがスナップショットではなくベースラインになる。

• AITERパッチのリベース — 具体的には、ピン留めされたリビジョンに対する統合アテンションパッチのAITER側。それが適用されるまで、AMDスイートはモデルとは何の関係もない理由でレッドのままだ。

• MMMUしきい値が0.50から動く — 本物のMI355Xスコアがプレースホルダーに取って代わるその瞬間、マルチモーダルゲートが機能し始める。

• 最初に公開される実行結果は — 作者はPRをレディに設定する前に、3つのイメージすべての実行結果を投稿すると約束している。これはMuse Spark Openにとって初のAMD精度測定値であり、ベンダーのスライドではなくテストハーネスから得られることになる。

• NVIDIAとAMDの数値が乖離するかどうか — MI355XでGSM8Kが0.93付近を維持する一方でMMMUが他のどのプラットフォームよりも実質的に低く着地するなら、ROCm上のビジョンパスこそが本題であり、そのゲートを追加したフレームワークPRが、それが最初に可視化された場所だったはずだ。

オープンウェイトのフラッグシップモデルが実際にセカンダリハードウェアへどう届くのかを追っている人にとって、これは開いたままにしておくべきファイルだ。発表記事には、そのモデルがAMDで利用可能だと書かれている。プルリクエストが示しているのは、2026年10月15日時点で、そこでもまだ快調に動くかどうかを誰も確認していないということだ。