Muse Spark Open na AMD: wsparcie od pierwszego dnia, zastępczy próg i bramka, której nikt nie uruchomił

Meta udostępniła Muse Spark Open 15 października 2026 r., a jeszcze tego samego wieczoru w SGLang pojawił się szkicowy pull request, którego tytuł brzmi mniej jak opis funkcji, a bardziej jak przyznanie: [AMD] Dodaj nocną bramkę dokładności GSM8K + MMMU dla Muse Spark Open MI35x. Powód jego istnienia został wprost podany w treści PR-a. W HIP kod modelu kieruje do osobnej implementacji ROCm — sglang.srt.rocm_muse_spark — i żadne zadanie ciągłej integracji w projekcie go nie obejmuje. Według relacji samego autora nowa bramka nie została uruchomiona na sprzęcie, jeden z jej dwóch progów zaliczenia/niezaliczenia jest wartością zastępczą wymyśloną, ponieważ nie istniał żaden pomiar AMD, który można by wykorzystać, a zadanie CI i tak już dziś zawiodłoby na pierwszym kroku. To nie jest historia premiery. To ślad w kształcie wycieku tego, jak wypuszczanie 816-miliardowego modelu o otwartych wagach na sprzęt AMD wygląda w praktyce z wnętrza frameworka do serwowania.

Co tak naprawdę dodaje pull request

Bramka to jedno nocne zadanie, które obejmuje oba checkpointy FP4 w przepisie „Low Latency” z cookbooka projektu dla MI355X. Mówiąc językiem samego projektu:

• Suite — nightly-amd-4-gpu-mi35x-muse-spark-open, zadanie nightly-4-gpu-mi35x-muse-spark-open na runnerze linux-mi35x-gpu-8 przy TP4, z limitem 21 600 sekund na plik.

• Dwa serwery, dwie klasy — po jednej na punkt kontrolny, ponieważ komórka NVFP4 ma inną ścieżkę wczytywania niż komórka MXFP4. MXFP4 wczytuje amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4; NVFP4 wczytuje z repozytorium Meta -NVFP4, punkt kontrolny przy użyciu --quantization quark_mxfp4, który przy wczytywaniu jest rekwantyzowany do MXFP4.

• Flagi przepisu — TP4/EP4, attention AITER przy rozmiarze strony 16, MUSE_MOE_BACKEND=flydsl, DFlash2 z backendem draft-attention opartym na Tritonie.

• Co jest mierzone — pełny split GSM8K przez sgl-eval z włączonym myśleniem, reasoning_effort=xhigh, 32 768 maks. tokenów, temperatura 1.0, top_p 0.95, plus 100 próbek MMMU dla ścieżki multimodalnej.

• Czas zegarowy — pojedynczy runner z 8 GPU obsługuje oba checkpointy jeden po drugim, około czterech godzin.

Uwzględnienie MMMU to szczegół, który sprawia, że warto przeczytać ten PR. Jak ujmuje to autor, w przypadku HIP model przechodzi do implementacji ROCm, a ścieżka obrazu przez tę implementację poza tym nie jest testowana — więc wieża wizyjna jest, w chwili pisania tego tekstu, najrzadziej testowaną częścią Muse Spark Open na krzemie AMD.

Dwie liczby w PR i skąd się wzięły

Nic tutaj nie jest pomiarem Muse Spark Open na sprzęcie AMD, i PR tak twierdzi.

• GSM8K 0.93 — przeniesione w całości z testu B300 Muse Spark w Day-0 PR. B300 to NVIDIA Blackwell Ultra. Próg, ustawienia próbkowania i konfiguracja oceniania zostały przeniesione z prac nad przejściem z klasy Hopper na Blackwell na całkowicie inny stos akceleratorów.

• MMMU 0,50 — opisany w PR jako „wartość zastępcza, za którą nie stoi żaden pomiar AMD”. To nietypowo szczere jak na plik CI i warto zrozumieć, dlaczego ma to większe znaczenie, niż się wydaje. Bramka z wymyślonym progiem minimalnym nie jest kontrolą poprawności; to pułapka. Wychwyci katastrofalną regresję, a łagodną przepuści po cichu. Jeśli prawdziwy wynik MMMU dla MI355X okaże się wynosić 0,68, bramka dopuszcza sześciopunktowy spadek, zanim zadziała.

• Długość akceptacji DFlash2 — raportowana w podsumowaniu kroku zadania, celowo nieobjęta bramkowaniem. Ścieżka dekodowania spekulatywnego jest więc obserwowalna, ale niechroniona: model szkicujący, który po cichu przestaje dobrze przewidywać, pojawi się w podsumowaniu, na które nikt nie ustawił alertów.

Ten ostatni punkt ma szersze zastosowanie niż ten jeden PR. Nocna bramka dokładności mierzy kod modelu dostarczany przez framework, a nie model, który udostępnia ci dostawca. Inna receptura kwantyzacji, inny rozmiar strony, inny backend uwagi, inny model roboczy — i jesteś poza obwiednią, dla której napisano tę bramkę.

Brama jest zablokowana, a powód jest prozaiczny.

PR pozostaje w wersji roboczej, dopóki nie zostanie scalony PR wsparcia na Dzień 0, co jest normalną zależnością. Ciekawszym blokerem jest zestaw łatek AMD AITER. Te łaty są zweryfikowane względem jednej wersji AITER (4ad9983), ale plik Dockerfile dla ROCm na gałęzi main przypina inną wersję (2bb5491). Względem przypiętej wersji 04-aiter-muse-moe-flydsl.patch nakłada się bez problemów; część AITER z 03-plan-b-aiter-unified-attention-3d.patch już nie, ponieważ aiter/ops/triton/attention/unified_attention.py zostało zrefaktoryzowane po utworzeniu łatek. Autor nie sprawdził trzeciej łaty, która dotyczy podmodułu composable_kernel. Dopóki druga z nich się nie nałoży, zadanie kończy się niepowodzeniem, zanim cokolwiek oceni.

Odczytaj to jako sygnał dojrzałości, a nie jako akt oskarżenia. Ścieżki serwowania AMD dla bardzo dużych modeli mieszaniny ekspertów są nieustannie przebudowywane po stronie upstream, a lockfile dostawcy jest dokładnie tym, co psuje zestaw łatek, który w ogóle uruchomił ten model.

Pierwszy dzień w AMD nie był właściwie pierwszym dniem

To, że bramka nie została uruchomiona, to nie to samo, co to, że ścieżka AMD jest nowa. Os czasu wokół tego opowiada pełniejszą historię niż wpis o premierze albo komunikat prasowy.

• Artefakty kwantyzacji AMD wyprzedzają premierę o około cztery tygodnie — Quark-MXFP4 i Quark-PTPC-FP8 checkpointy dla Muse Spark Open opublikowano na Hugging Face 18 września 2026 r., mniej więcej miesiąc przed tym, jak Meta ogłosiła wagi.

• Wsparcie frameworków otwarto w dniu premiery — PR SGLang [Day0] Wsparcie Muse Spark Open i PR vLLM [Model] Dodaj wsparcie Muse Spark Open oba zostały otwarte w ciągu dwunastu minut od siebie 15 października 2026, co pokazuje, jak wygląda prawdziwa koordynacja day-zero.

• Własny przewodnik budowania Meta zawiera receptury AMD — FP8 (Quark) dla Instinct MI355X udostępniany przez vLLM oraz MXFP4 (Quark) dla MI350X i MI355X, a także ścieżkę Intel MXFP4 przewidzianą dla czterech kart 160 GB i ścieżkę INT4 Xeon 6 do użytku offline.

• Meta opublikowała przepustowość konkretnie dla AMD — model szkicowy DFlash V2 zapewnia 3,7× przepustowości dla pojedynczego żądania na MI355X i 2,9× przy 16 równoczesnych żądaniach, przy 6,4 akceptowanych tokenach szkicowych na krok; niestandardowym jądrom Helion w SGLang przypisuje się przyspieszenia na poziomie jądra wynoszące 1,03–3,95× w przypadku NVIDIA i AMD oraz 3% zysku end-to-end na MI350.

Nie o to więc chodzi, że „wsparcie AMD nadchodzi późno”. Chodzi o to, że wsparcie AMD nadeszło jednocześnie przećwiczone i niezmierzone: artefakty, przepisy i przyspieszenia były gotowe, a liczby dotyczącej dokładności nie było — i dokładnie tę lukę nocna bramka ma za zadanie zamknąć.

Co tymczasem mówią niezależne liczby

Chociaż dokładność AMD pozostaje nierozstrzygnięta, ogólny obraz już nie. Artificial Analysis umieszcza Muse Spark Open na Intelligence Index na poziomie 39, na dziewiątym miejscu spośród 118 modeli w swoim zestawie porównawczym, z medianą 19 wśród porównywalnych modeli — to mocny wynik. Jego cena jest tym, co budzi ostrożność: 1,25 USD za milion tokenów wejściowych i 4,25 USD za milion wyjściowych, z 88% zniżką na pamięć podręczną, stawką mieszaną 0,78 USD i wydatkiem 0,84 USD na zadanie Intelligence Index, co plasuje go na 32. miejscu na 40 według tego wskaźnika efektywności. Szybkość generowania jest podana jako niedostępna, a wpis odnotowuje wejście tekstowe i obrazowe w zestawieniu z deklaracją dostawcy dotyczącą tekstu, obrazu, wideo i dźwięku — nierozstrzygnięta rozbieżność, którą warto zaznaczyć, a nie rozstrzygać. Te dane są niezależne i neutralne względem dostawcy; powyższe dane AMP należą do Meta.

Krótka wersja, jeśli decydujesz dzisiaj

Jeśli Twoja infrastruktura opiera się na AMD i planujesz samodzielnie hostować Muse Spark Open na MI355X, uczciwe stanowisko jest takie, że to Ty jesteś pomiarem. Istnieje pełna ścieżka serwowania od dnia zerowego, recepta kwantyzacji dla każdego akceleratora, opublikowane przyspieszenie dzięki dekodowaniu spekulatywnemu — i, na chwilę obecną, brak opublikowanego wyniku dokładności dla którejkolwiek z komórek FP4 na krzemie AMD. PR i tak daje Ci coś użytecznego: jego konfiguracja ewaluacji to kompletna, gotowa do przejęcia definicja tego, jak wygląda poważne sprawdzenie dokładności tego modelu, aż po reasoning effort i top_p. Uruchom ją na własnym checkpointcie, zanim postawisz przed nim klienta, i obserwuj obiecane uruchomienia autora, zrebazowane patche AITER oraz zastąpienie progu MMMU zmierzonym wynikiem.

Praktyczna uwaga o serwowaniu czterotygodniowego stosu kwantyzacji

Jeden mechanizm w tym PR zasługuje na uwagę. Komórka NVFP4 jest ładowana z --quantization quark_mxfp4, co oznacza, że źródłowy checkpoint to NVFP4, a środowisko uruchomieniowe przekwantyzuje go do MXFP4 przy ładowaniu. W ramach jednego zestawu porównywane są dwa numerycznie różne potoki i właśnie dlatego każdy z nich otrzymuje własny serwer, własną klasę i własny wiersz zaliczenia/niepowodzenia. Wskazówki samej Meta mówią, że kompilacja AMD FP8 (Quark) dorównuje dokładności BF16 na GSM8K, ale to twierdzenie dotyczy FP8, a nie którejkolwiek z komórek FP4, i jest to pomiar dostawcy. Jeśli wybierasz kwantyzację do produkcji, traktuj komórki FP4 jako niezweryfikowane, dopóki ktoś nie opublikuje wyniku.

To tutaj warstwa routingu zasługuje na swoje miejsce. Żadna z tych niepewności nie istnieje dla czytelnika wywołującego hostowany endpoint — ale jeśli to Ty podejmujesz decyzję o self-hostingu, sposobem na ograniczenie ryzyka związanego z nieprzetestowanym modelem jest skierowanie na niego niewielkiej części ruchu za czymś, co potrafi przenieść ten ruch z powrotem. OrcaRouter już dziś kieruje ruch do Muse Spark 1.2 i Muse Spark 1.1, a nie kieruje go do Muse Spark Open, więc nic tutaj nie jest twierdzeniem o hostowaniu nowego modelu; to to samo jedno API dla ponad 200 modeli, z automatycznym przełączaniem awaryjnym, gdy dostawca zaczyna działać gorzej oraz DSL routingu do rozdzielania ruchu między modelami i dostawcami za pomocą konfiguracji, a nie zmiany kodu. Przekazujemy cenę katalogową dostawcy bez marży (0%), co sprawia, że ostrożny równoległy test jest wystarczająco tani, by naprawdę go przeprowadzić.

Dla samego Muse Spark Open dostępność na dziś zapewniają własne API Meta oraz zestaw zewnętrznych platform inferencyjnych, a także pobieranie wag z Hugging Face i dwa katalogi modeli w chmurze, które Meta wymieniła. W przypadku AMD najszybszą drogą do wiarygodnej liczby jest bramka w tym PR — gdy ktoś ją uruchomi.

Co obejrzeć

• Scalenie PR-a Day-0 — bramka dokładności nie może zostać scalona, dopóki to nie nastąpi, a gdy to nastąpi, własny kod modelu staje się punktem odniesienia, a nie migawką.

• Rebase patcha AITER — konkretnie połowa AITER patcha unified-attention względem przypiętej rewizji. Dopóki się nie zastosuje, zestaw testów AMD jest czerwony z powodów, które nie mają nic wspólnego z modelem.

• Przesunięcie progu MMMU z 0,50 — w momencie, gdy prawdziwy wynik MI355X zastąpi wartość zastępczą, bramka multimodalna zaczyna działać.

• Pierwsze opublikowane raporty z uruchomień — autor zobowiązał się do opublikowania wyników uruchomień na wszystkich trzech obrazach przed oznaczeniem PR jako gotowego. To pierwszy odczyt dokładności AMD dla Muse Spark Open i będzie pochodzić z harnessu testowego, a nie ze slajdu dostawcy.

• Czy liczby dla NVIDIA i AMD się rozchodzą — jeśli GSM8K utrzymuje się blisko 0,93 na MI355X, a MMMU wypada istotnie niżej niż na jakiejkolwiek innej platformie, to ścieżka wizyjna na ROCm jest tu sednem sprawy, a PR frameworka, który dodał tę bramkę, będzie pierwszym miejscem, w którym stało się to widoczne.

Dla każdego, kto śledzi, jak flagowe modele open-weight faktycznie trafiają na sprzęt wtórny, to jest plik, który warto mieć otwarty. Wpis o premierze mówi, że model jest dostępny na AMD. Pull request mówi, że na dzień 15 października 2026 nikt jeszcze nie sprawdził, czy nadal sprawdza się tam dobrze.