Muse Spark Open no AMD: suporte desde o primeiro dia, um limiar provisório e um gate que ninguém executou

A Meta lançou Muse Spark Open em 15 de outubro de 2026, e naquela mesma noite um pull request em rascunho chegou ao SGLang cujo título soa menos como uma funcionalidade do que como uma admissão: [AMD] Adicionar um gate de precisão noturno GSM8K + MMMU do Muse Spark Open MI35x. O motivo de sua existência é explicado no corpo do PR. No HIP, o código do modelo encaminha para uma implementação ROCm separada — sglang.srt.rocm_muse_spark — e nenhum job de integração contínua no projeto o cobre. Segundo o próprio autor, o novo gate não foi executado em hardware, um de seus dois limiares de aprovação/reprovação é um placeholder inventado porque não existia nenhuma medição da AMD para usar, e o job de CI falharia em sua primeira etapa hoje de qualquer forma. Esta não é uma história de lançamento. É um traço em forma de vazamento daquilo que realmente parece ser colocar um modelo de pesos abertos de 816 bilhões de parâmetros em hardware AMD, visto de dentro de um framework de serving.

O que o pull request realmente adiciona

O gate é um job noturno que cobre ambos os checkpoints FP4 na receita do cookbook "Low Latency" do MI355X do projeto. Nos termos do próprio projeto:

• Suíte — nightly-amd-4-gpu-mi35x-muse-spark-open, tarefa nightly-4-gpu-mi35x-muse-spark-open no linux-mi35x-gpu-8 runner em TP4, com um limite de 21.600 segundos por arquivo.

• Dois servidores, duas classes — um por checkpoint, porque a célula NVFP4 segue um caminho de carregamento diferente da MXFP4. O MXFP4 carrega amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4; o NVFP4 carrega o checkpoint -NVFP4 do repositório da Meta com --quantization quark_mxfp4, que requantiza para MXFP4 no momento do carregamento.

• Flags de receita — TP4/EP4, atenção AITER com tamanho de página 16, MUSE_MOE_BACKEND=flydsl, DFlash2 com um backend de atenção de rascunho em Triton.

• O que é medido — GSM8K em split completo via sgl-eval com thinking ativado, reasoning_effort=xhigh, máximo de 32.768 tokens, temperatura 1,0, top_p 0.95, além de 100 amostras MMMU para o caminho multimodal.

• Tempo de relógio — um único executor de 8 GPUs atende os dois checkpoints um após o outro, cerca de quatro horas.

A inclusão do MMMU é o detalhe que faz valer a pena ler o PR. Como diz o autor, no HIP o modelo é encaminhado para uma implementação ROCm e o caminho da imagem por essa implementação não é testado de outra forma — portanto, no momento em que isto foi escrito, a torre de visão é a parte menos exercitada do Muse Spark Open em silício AMD.

Os dois números no PR, e de onde eles vieram

Nada aqui é uma medição do Muse Spark Open em hardware AMD, e o PR diz isso.

• GSM8K 0.93 — copiado integralmente do teste B300 Muse Spark no PR do Dia 0. B300 é NVIDIA Blackwell Ultra. O limiar, as configurações de amostragem e a configuração de pontuação foram todos transportados do trabalho Hopper-class-to-Blackwell para uma pilha de aceleradores completamente diferente.

• MMMU 0.50 — descrito no PR como "um placeholder sem nenhuma medição da AMD por trás". Isso é incomumente franco para um arquivo de CI, e vale a pena entender por que isso importa mais do que parece. Um gate com um piso inventado não é uma verificação de correção; é um fio-armadilha. Ele vai capturar uma regressão catastrófica e vai deixar passar silenciosamente uma regressão leve. Se a pontuação real do MMMU do MI355X for 0,68, o gate permite uma queda de seis pontos antes de disparar.

• Comprimento de aceitação do DFlash2 — reportado no resumo de etapas da tarefa, deliberadamente sem qualquer barreira. Assim, o caminho de descodificação especulativa é observável mas não protegido: um modelo de rascunho que silenciosamente deixa de prever bem vai aparecer num resumo sobre o qual ninguém está a alertar.

Esse último ponto vale para além deste único PR. Um gate de precisão noturno mede o código do modelo que o framework entrega, não o modelo que um provedor serve a você. Receita de quantização diferente, tamanho de página diferente, backend de atenção diferente, modelo de rascunho diferente — e você está fora do envelope para o qual o gate foi escrito.

O portão está bloqueado, e o motivo é banal.

O PR permanece em rascunho até que o PR de suporte do Day-0 seja integrado, o que é uma dependência normal. O bloqueador mais interessante é o conjunto de patches do AMD AITER. Esses patches são validados contra uma revisão do AITER (4ad9983), mas o Dockerfile do ROCm em main fixa uma diferente (2bb5491). Contra a revisão fixada, 04-aiter-muse-moe-flydsl.patch aplica-se de forma limpa; a metade AITER de 03-plan-b-aiter-unified-attention-3d.patch não, porque aiter/ops/triton/attention/unified_attention.py foi refatorado depois que os patches foram criados. O autor não verificou o terceiro patch, que tem como alvo o submódulo composable_kernel. Até que o segundo seja aplicado, o job falha antes de avaliar qualquer coisa.

Leia isso como um sinal de maturidade, e não como uma acusação. Os caminhos de serving da AMD para modelos mixture-of-experts muito grandes estão sendo reconstruídos continuamente no upstream, e um lockfile de fornecedor é exatamente o que quebra o conjunto de patches que fez o modelo funcionar em primeiro lugar.

O primeiro dia na AMD não foi realmente o primeiro dia.

O fato de o gate não ter sido executado não é o mesmo que o caminho da AMD ser novo. A linha do tempo em volta conta uma história mais completa do que o post de lançamento ou o PR.

• Os artefatos de quantização da AMD antecedem o lançamento em cerca de quatro semanas — os Quark-MXFP4 e Quark-PTPC-FP8 checkpoints para o Muse Spark Open foram publicados no Hugging Face em 2026-09-18, aproximadamente um mês antes de a Meta anunciar os pesos.

• O suporte do framework foi aberto no dia do lançamento — o [Day0] Support Muse Spark Open PR da SGLang e o [Model] Add Muse Spark Open support PR da vLLM foram ambos abertos com doze minutos de diferença um do outro em 2026-10-15, que é exatamente como uma coordenação genuína de day-zero se parece.

• O próprio guia de compilação da Meta inclui receitas AMD — FP8 (Quark) para o Instinct MI355X servido via vLLM, e MXFP4 (Quark) para MI350X e MI355X, além de um caminho MXFP4 da Intel dimensionado para quatro placas de 160 GB e um caminho INT4 Xeon 6 para uso offline.

• A Meta publicou a vazão especificamente para a AMD — o modelo de rascunho DFlash V2 proporciona 3,7× de vazão para uma única requisição no MI355X e 2,9× com 16 requisições simultâneas, com 6,4 tokens de rascunho aceitos por passo; os kernels Helion personalizados no SGLang são creditados por ganhos de velocidade de 1,03–3,95× em nível de kernel em NVIDIA e AMD e um ganho ponta a ponta de 3% no MI350.

Então a história não é "o suporte para AMD chega tarde." É que o suporte para AMD chegou ensaiado e não medido ao mesmo tempo: os artefatos, as receitas e os ganhos de velocidade estavam todos prontos, e o número de acurácia não estava, que é exatamente a lacuna que um gate noturno existe para fechar.

O que dizem, entretanto, os números independentes

Embora a precisão da AMD não esteja resolvida, o panorama geral não é. A Artificial Analysis lista o Muse Spark Open com um Intelligence Index de 39, nono de 118 modelos em seu conjunto de comparação, com uma mediana de 19 entre modelos comparáveis — um resultado forte. O seu preço é onde reside a cautela: $1,25 por milhão de tokens de entrada e $4,25 por milhão de saída, com um desconto de cache de 88%, uma taxa combinada de $0,78 e $0,84 de gasto por tarefa do Intelligence Index, o que classifica em 32º de 40 nessa medida de eficiência. A velocidade de saída está listada como não disponível, e a listagem registra entrada de texto e imagem contra a própria reivindicação do fornecedor de texto, imagem, vídeo e áudio — uma discrepância não resolvida que vale a pena sinalizar em vez de julgar. Esses números são independentes e agnósticos em relação ao fornecedor; os números do AMP acima são da Meta.

A versão curta se você estiver decidindo hoje

Se a sua capacidade for AMD e você estava planejando auto-hospedar o Muse Spark Open no MI355X, a posição honesta é que você é a medição. Existe um caminho completo de serving para o day zero, uma receita de quantização por acelerador, um ganho de velocidade de decodificação especulativa publicado — e, até o momento em que isto foi escrito, nenhuma pontuação de acurácia publicada para qualquer uma das duas células FP4 em silício AMD. O PR lhe entrega algo útil de qualquer forma: sua configuração de avaliação é uma definição completa e pronta para ser aproveitada de como é uma verificação séria de acurácia neste modelo, até o esforço de raciocínio e o top_p. Rode-a contra o seu próprio checkpoint antes de colocar um cliente diante dele, e fique atento às execuções prometidas pelo autor, aos patches rebaseados do AITER e à substituição do limiar do MMMU por uma pontuação medida.

A nota prática sobre a implementação de uma stack de quantização com quatro semanas de idade

Um mecanismo no PR merece atenção. A célula NVFP4 é carregada com --quantization quark_mxfp4, o que significa que o checkpoint de origem é NVFP4 e o runtime o requantiza para MXFP4 no carregamento. Dois pipelines numericamente diferentes estão sendo comparados em uma única suíte, e é exatamente por isso que cada um recebe seu próprio servidor, sua própria classe e sua própria linha de aprovação/reprovação. A orientação da própria Meta é que a build AMD FP8 (Quark) corresponde à acurácia do BF16 no GSM8K, mas essa afirmação é sobre FP8, não sobre nenhuma das células FP4, e é uma medição do fornecedor. Se você está escolhendo uma quantização para produção, trate as células FP4 como não verificadas até que alguém publique o número.

É aqui que a camada de roteamento justifica seu lugar. Nada dessa incerteza existe para um leitor que chama um endpoint hospedado — mas se você é quem toma a decisão de auto-hospedar, a forma de reduzir o risco de um modelo não comprovado é colocar uma pequena parcela do tráfego nele por trás de algo que consiga mover o tráfego de volta. O OrcaRouter roteia o Muse Spark 1.2 e o Muse Spark 1.1 hoje e não roteia o Muse Spark Open, então nada aqui é uma alegação sobre hospedar o novo modelo; é a mesma API única para mais de 200 modelos, com failover automático quando um provedor se degrada e uma DSL de roteamento para dividir o tráfego entre modelos e provedores por configuração, em vez de por alteração de código. Repassamos o preço de tabela do provedor com 0% de markup, o que torna uma execução paralela cautelosa barata o suficiente para realmente ser feita.

Para o próprio Muse Spark Open, a disponibilidade hoje passa pela API da própria Meta e por um conjunto de plataformas de inferência de terceiros, além dos downloads de pesos no Hugging Face e dos dois catálogos de modelos em nuvem que a Meta citou. Na AMD, o caminho mais rápido para se chegar a um número confiável é o gate deste PR — assim que alguém o executar.

O que assistir

• A chegada do PR do Dia 0 — o portão de precisão não pode ser mesclado antes que isso aconteça, e sua chegada é quando o próprio código do modelo se torna a linha de base, em vez de um snapshot.

• O rebase do patch AITER — mais especificamente, a metade AITER do patch de atenção unificada em relação à revisão fixada. Enquanto ele não for aplicado, a suíte AMD fica vermelha por motivos que nada têm a ver com o modelo.

• O limiar do MMMU saindo de 0,50 — no momento em que uma pontuação real do MI355X substitui o valor provisório, o portão multimodal começa a fazer o seu trabalho.

• Os primeiros relatórios de execução publicados — o autor comprometeu-se a publicar execuções em todas as três imagens antes de marcar o PR como pronto. Essa é a primeira leitura de precisão da AMD para o Muse Spark Open, e virá de um ambiente de testes, e não de um slide de fornecedor.

• Se os números da NVIDIA e da AMD divergem — se o GSM8K se mantiver perto de 0,93 no MI355X enquanto o MMMU ficar materialmente abaixo de qualquer outra plataforma, o caminho de visão no ROCm é o ponto central, e o PR do framework que adicionou o gate terá sido o primeiro lugar onde isso foi visível.

Para quem acompanha como os principais modelos de pesos abertos realmente chegam ao hardware secundário, este é o arquivo que vale manter aberto. O post de lançamento informa que o modelo está disponível na AMD. O pull request informa que, em 15 de outubro de 2026, ninguém ainda verificou se ele continua bom por lá.