Muse Spark abierto en AMD: soporte desde el primer día, un umbral provisional y una compuerta que nadie ha ejecutado

Meta lanzó Muse Spark Open el 15 de octubre de 2026, y esa misma noche un pull request en borrador llegó a SGLang cuyo título se lee menos como una característica que como una confesión: [AMD] Añadir un control de precisión nocturno de GSM8K + MMMU para Muse Spark Open MI35x. El motivo de su existencia se detalla en el cuerpo del PR. En HIP, el código del modelo se despacha a una implementación de ROCm separada — sglang.srt.rocm_muse_spark — y ningún trabajo de integración continua en el proyecto la cubre. Según el propio autor, el nuevo control no se ha ejecutado en hardware, uno de sus dos umbrales de aprobado/reprobado es un marcador de posición inventado porque no existía ninguna medición de AMD que usar, y el trabajo de CI fallaría hoy en su primer paso de todos modos. Esto no es una historia de lanzamiento. Es un rastro con forma de filtración de cómo se ve realmente desplegar un modelo de pesos abiertos de 816 mil millones de parámetros en hardware de AMD desde dentro de un framework de servicio.

Lo que realmente añade la pull request

El gate es un único trabajo nocturno que cubre ambos checkpoints FP4 en la receta de cookbook «Low Latency» de MI355X del proyecto. En los propios términos del proyecto:

• Suite — nightly-amd-4-gpu-mi35x-muse-spark-open, trabajo nightly-4-gpu-mi35x-muse-spark-open en el linux-mi35x-gpu-8 runner en TP4, con un límite de 21.600 segundos por archivo.

• Dos servidores, dos clases — una por checkpoint, porque la celda NVFP4 toma una ruta de carga distinta a la de MXFP4. MXFP4 carga amd/Muse-Spark-Open-816B-A42B-Quark-MXFP4; NVFP4 carga el checkpoint -NVFP4 del repositorio de Meta con --quantization quark_mxfp4, que recuantiza a MXFP4 en el momento de la carga.

• Indicadores de receta — TP4/EP4, atención de AITER con tamaño de página 16, MUSE_MOE_BACKEND=flydsl, DFlash2 con un backend de atención de borrador en Triton.

• Qué se mide — GSM8K de división completa a través de sgl-eval con el pensamiento activado, reasoning_effort=xhigh, 32.768 tokens máx., temperatura 1.0, top_p 0.95, más 100 muestras de MMMU para la ruta multimodal.

• Tiempo de reloj — un único runner de 8 GPU atiende ambos checkpoints uno tras otro, aproximadamente cuatro horas.

La inclusión de MMMU es el detalle que hace que el PR valga la pena leer. Como lo expresa el autor, en HIP el modelo se despacha hacia una implementación de ROCm y la ruta de imágenes a través de esa implementación no está probada por lo demás — así que la torre de visión es, en el momento en que se escribió esto, la parte menos ejercitada de Muse Spark Open sobre silicio AMD.

Los dos números en el PR, y de dónde provienen

Nada de lo que hay aquí es una medición de Muse Spark Open en hardware de AMD, y el PR lo dice.

• GSM8K 0.93 — extraído en su totalidad de la prueba B300 Muse Spark en el PR del Día 0. B300 es NVIDIA Blackwell Ultra. El umbral, la configuración de muestreo y la configuración de puntuación se trasladaron por completo del trabajo de clase Hopper a Blackwell a una pila de aceleradores completamente diferente.

• MMMU 0,50 — descrito en el PR como «un marcador de posición sin ninguna medición de AMD que lo respalde». Eso es inusualmente franco para un archivo de CI, y vale la pena entender por qué importa más de lo que parece. Una puerta con un mínimo inventado no es una comprobación de corrección; es un cable trampa. Detendrá una regresión catastrófica y dejará pasar silenciosamente una leve. Si la puntuación real de MMMU del MI355X resulta ser 0,68, la puerta permite una caída de seis puntos antes de activarse.

• DFlash2 longitud de aceptación — reportado en el resumen de pasos del trabajo, deliberadamente sin compuerta. Así, la ruta de decodificación especulativa es observable pero no está protegida: un modelo borrador que deja de predecir bien en silencio aparecerá en un resumen sobre el que nadie está alertando.

Ese último punto se generaliza más allá de este PR en concreto. Un control de precisión nocturno mide el código del modelo que distribuye el framework, no el modelo que te sirve un proveedor. Distinta receta de cuantización, distinto tamaño de página, distinto backend de atención, distinto modelo de borrador, y ya estás fuera del envelope para el que se escribió el control.

El portón está bloqueado, y la razón es trivial.

El PR permanece en borrador hasta que aterrice el PR de soporte del Día 0, lo cual es una dependencia normal. El bloqueador más interesante es el conjunto de parches de AMD AITER. Esos parches están validados contra una revisión de AITER (4ad9983), pero el Dockerfile de ROCm en main fija una distinta (2bb5491). Contra la revisión fijada, 04-aiter-muse-moe-flydsl.patch se aplica sin problemas; la mitad de AITER de 03-plan-b-aiter-unified-attention-3d.patch no, porque aiter/ops/triton/attention/unified_attention.py se refactorizó después de que se crearan los parches. El autor no ha comprobado el tercer parche, que apunta al submódulo composable_kernel. Hasta que se aplique el segundo, el job falla antes de evaluar nada.

Interpreta eso como una señal de madurez y no como una acusación. Las rutas de servicio de AMD para modelos de mezcla de expertos muy grandes se están reconstruyendo continuamente en upstream, y un archivo de bloqueo del proveedor es exactamente lo que rompe el conjunto de parches que hizo que el modelo funcionara en primer lugar.

El primer día en AMD no fue en realidad el primer día

Que el gate no se haya ejecutado no es lo mismo que la ruta de AMD sea nueva. La cronología que lo rodea cuenta una historia más completa que la que cuentan la publicación de lanzamiento o el comunicado de prensa.

• Los artefactos de cuantización de AMD preceden al lanzamiento en unas cuatro semanas — Quark-MXFP4 y Quark-PTPC-FP8, los checkpoints de Muse Spark Open, se publicaron en Hugging Face el 2026-09-18, aproximadamente un mes antes de que Meta anunciara los pesos.

• El soporte para el framework se abrió el mismo día del lanzamiento — el PR [Day0] Support Muse Spark Open de SGLang y el PR [Model] Add Muse Spark Open support de vLLM se abrieron con apenas doce minutos de diferencia entre sí el 2026-10-15, y eso es exactamente cómo se ve una coordinación genuina de día cero.

• La propia guía de compilación de Meta incluye recetas para AMD — FP8 (Quark) para Instinct MI355X servido a través de vLLM, y MXFP4 (Quark) para MI350X y MI355X, junto con una ruta MXFP4 de Intel dimensionada para cuatro tarjetas de 160 GB y una ruta INT4 para Xeon 6 destinada a uso sin conexión.

• Meta publicó el rendimiento específicamente para AMD — el modelo de borrador DFlash V2 ofrece un rendimiento de 3,7× para una única solicitud en MI355X y de 2,9× con 16 solicitudes concurrentes, con 6,4 tokens de borrador aceptados por paso; a los kernels Helion personalizados en SGLang se les atribuyen aceleraciones a nivel de kernel de 1,03–3,95× en NVIDIA y AMD y una ganancia de extremo a extremo del 3 % en MI350.

Así que la historia no es «el soporte para AMD llega tarde». Es que el soporte para AMD llegó ensayado y sin medir al mismo tiempo: los artefactos, las recetas y las aceleraciones estaban todos listos, y la cifra de precisión no lo estaba, que es precisamente la brecha que una compuerta nocturna existe para cerrar.

Lo que dicen mientras tanto los números independientes

Aunque la precisión de AMD no está resuelta, el panorama agregado sí lo está. Artificial Analysis sitúa a Muse Spark Open en un Índice de Inteligencia de 39, noveno de 118 modelos en su conjunto de comparación, con una mediana de 19 entre los modelos comparables, un resultado sólido. Es en su precio donde reside la cautela: $1.25 por millón de tokens de entrada y $4.25 por millón de salida, con un descuento de caché del 88%, una tarifa combinada de $0.78 y $0.84 de gasto por tarea del Índice de Inteligencia, lo que lo sitúa en el puesto 32 de 40 en esa medida de eficiencia. La velocidad de salida figura como no disponible, y el listado registra entrada de texto e imagen frente a la afirmación del propio proveedor sobre texto, imagen, video y audio: una discrepancia no resuelta que vale la pena señalar en lugar de dirimir. Esas cifras son independientes y neutras respecto del proveedor; las cifras de AMP mencionadas arriba son de Meta.

La versión corta, si decides hoy

Si tu capacidad es AMD y planeabas autoalojar Muse Spark Open en MI355X, la postura honesta es que tú eres la medición. Hay una ruta de servicio completa desde el día cero, una receta de cuantización por acelerador, una aceleración de decodificación especulativa publicada —y, a la fecha de este escrito, ninguna puntuación de precisión publicada para ninguna de las dos celdas FP4 en silicio AMD. El PR te entrega algo útil de todas formas: su configuración de evaluación es una definición completa y lista para tomar de cómo se ve una verificación seria de precisión en este modelo, hasta el esfuerzo de razonamiento y el top_p. Ejecútala contra tu propio checkpoint antes de poner a un cliente frente a él, y mantente atento a las ejecuciones prometidas por el autor, a los parches de AITER rebasados y a que el umbral de MMMU se reemplace con una puntuación medida.

La nota práctica sobre servir una pila de cuantización de cuatro semanas de antigüedad

Un mecanismo en el PR merece atención. La celda NVFP4 se carga con --quantization quark_mxfp4, lo que significa que el checkpoint de origen es NVFP4 y el runtime lo recuantiza a MXFP4 al cargarlo. Se están comparando dos pipelines numéricamente diferentes dentro de una misma suite, que es exactamente por lo que cada pipeline obtiene su propio servidor, su propia clase y su propia línea de aprobado/reprobado. La propia guía de Meta indica que la compilación AMD FP8 (Quark) iguala la precisión de BF16 en GSM8K, pero esa afirmación se refiere a FP8, no a ninguna de las dos celdas FP4, y es una medición de proveedor. Si estás eligiendo una cuantización para producción, trata las celdas FP4 como no verificadas hasta que alguien publique el número.

Aquí es donde la capa de enrutamiento se gana su sitio. Nada de esta incertidumbre existe para un lector que llama a un endpoint alojado, pero si eres quien toma la decisión de autoalojar, la forma de reducir el riesgo de un modelo no probado es poner una pequeña parte del tráfico en él detrás de algo que pueda redirigir el tráfico de vuelta. OrcaRouter enruta hoy Muse Spark 1.2 y Muse Spark 1.1 y no enruta Muse Spark Open, así que nada de esto es una afirmación sobre alojar el nuevo modelo; es la misma API para más de 200 modelos, con conmutación automática por error cuando un proveedor se degrada y un DSL de enrutamiento para dividir el tráfico entre modelos y proveedores por configuración en lugar de por cambios de código. Repercutimos el precio de lista del proveedor con un 0 % de margen, que es lo que hace que una ejecución en paralelo prudente sea lo bastante barata como para llevarla a cabo de verdad.

En cuanto a Muse Spark Open en sí, la disponibilidad hoy pasa por la propia API de Meta y un conjunto de plataformas de inferencia de terceros, además de las descargas de pesos en Hugging Face y los dos catálogos de modelos en la nube que Meta mencionó. En AMD, la forma más rápida de obtener una cifra fiable es el gate de este PR — una vez que alguien lo ejecute.

Qué ver

• La llegada del PR del Día 0 — la puerta de precisión no puede fusionarse antes de que eso ocurra, y su llegada marca el momento en que el propio código del modelo se convierte en la línea base en lugar de una instantánea.

• El rebase del parche de AITER — en concreto, la mitad de AITER del parche de atención unificada frente a la revisión fijada. Hasta que eso se aplique, la suite de AMD está en rojo por razones que no tienen nada que ver con el modelo.

• El umbral de MMMU que deja atrás el 0,50 — en el momento en que una puntuación real de MI355X sustituya el valor provisional, la puerta multimodal empieza a hacer su trabajo.

• Los primeros informes de ejecución publicados — el autor se ha comprometido a publicar ejecuciones en las tres imágenes antes de marcar el PR como listo. Esa es la primera lectura de precisión de AMD para Muse Spark Open, y provendrá de un arnés de pruebas en lugar de una diapositiva de un proveedor.

• Si los números de NVIDIA y AMD divergen — si GSM8K se mantiene cerca de 0.93 en MI355X mientras que MMMU queda sustancialmente por debajo de cualquier otra plataforma, la ruta de visión en ROCm es la cuestión, y el PR del framework que añadió la puerta habrá sido el primer lugar donde fue visible.

Para cualquiera que siga cómo llegan realmente los modelos insignia de pesos abiertos al hardware secundario, este es el archivo que conviene tener abierto. La publicación de lanzamiento te dice que el modelo está disponible en AMD. La solicitud de extracción te dice que, a partir del 15 de octubre de 2026, nadie ha comprobado todavía si sigue funcionando bien ahí.