Cómo ejecutar Muse Spark Open localmente

TL;DR

Ejecutar Muse Spark Open localmente es posible, pero se trata de un despliegue a gran escala, no de una configuración típica de una sola GPU. Las configuraciones documentadas por Meta incluyen cuatro GPU NVIDIA B300 para NVFP4, ocho B300 para BF16 o una configuración MLX distribuida usando varios Mac Studio M5 Ultra.

Para la mayoría de desarrolladores, el primer paso es hacer coincidir el checkpoint con una combinación de hardware y runtime de inferencia compatibles. Empiece con una longitud de contexto conservadora, verifique que el servidor devuelve respuestas completas y mida el uso de memoria antes de aumentar el contexto o la concurrencia. Si no tiene acceso al hardware adecuado, una API de inferencia hospedada puede ser una opción más práctica, como Muse Spark de CometAPI Muse Spark.

Puntos clave

• Muse Spark Open tiene 816B parámetros totales y unos 42B activos por token; aun así, el banco completo de expertos requiere almacenamiento y memoria.
• Elija NVFP4 o BF16 en función del tamaño del checkpoint, la memoria del acelerador, el interconector y la sobrecarga de serving.
• El ejemplo de NVIDIA utiliza la configuración NVFP4 vLLM vigente con cuatro B300; verifique su hardware y runtime exactos antes de lanzar.
• La ruta Apple requiere varios Mac Studio M5 Ultra y RDMA sobre enlaces directos Thunderbolt 5.
• Verifique el endpoint del modelo, la integridad de la respuesta y el uso de memoria antes de aumentar el contexto o añadir usuarios.

¿Qué es Muse Spark Open?

Muse Spark Open es la versión con pesos descargables de la familia Muse Spark de Meta. A diferencia de un transformer denso convencional, su diseño MoE disperso enruta cada token a un subconjunto de expertos, ofreciendo capacidad de frontera con una huella de cómputo activo menor. El anuncio de lanzamiento de Meta lo describe como nativamente multimodal y optimizado para codificación multi-paso y flujos de trabajo agénticos.

El modelo acepta texto, imágenes, audio y video y produce texto; la disponibilidad de funciones aún depende del runtime de serving. Se distribuye bajo la Muse Model License con restricciones de uso. Revise los términos del repositorio antes del despliegue y las acciones irreversibles en flujos de trabajo agénticos.

¿Cómo rinde Muse Spark Open?

Los benchmarks de calidad ayudan a determinar si vale la pena evaluarlo; no indican qué tan rápido funcionará su servidor local. Las cifras siguientes son resultados de capacidad reportados por Meta, no mediciones de los comandos de despliegue de esta guía.

Meta documenta configuraciones del modelo, procedimientos específicos del benchmark y selección de puntuaciones en su metodología de evaluación. Muse Spark Open utiliza razonamiento xhigh en estos resultados. Compare una configuración local usando su propio conjunto de tareas, versión de software, contexto y concurrencia; un contexto servido menor o un harness diferente cambia lo que se evalúa.

¿Realmente puede ejecutar Muse Spark Open localmente?

Sí. Puede ejecutar Muse Spark Open localmente si su sistema cumple los requisitos del checkpoint, el acelerador y el runtime de inferencia. Las rutas documentadas incluyen servidores con GPU NVIDIA y sistemas Apple Silicon distribuidos; una conversión compatible a GGUF ofrece otra opción para máquinas con suficiente memoria direccionable. La tarjeta del modelo oficial de Muse Spark Open y la guía de despliegue en Hugging Face describen los pesos publicados y la configuración específica por runtime. Un portátil de consumo estándar no puede mantener el checkpoint nativo completo en memoria.

La capacidad de memoria es la primera restricción. Los parámetros activos describen el cómputo por token, no el conjunto completo de pesos de expertos. La guía de checkpoints de Meta indica aproximadamente 537 GB para NVFP4 y 1.65 TB para BF16, sin incluir la caché KV, activaciones ni la sobrecarga del runtime.

Asigne hardware usando el tamaño completo del checkpoint más margen para serving. Prompts largos incrementan la presión de la caché KV, y el número de GPU soportadas depende del runtime y del acelerador. La configuración NVFP4 de cuatro GPU no garantiza que cualquier cuarteto de tarjetas Blackwell pueda servir cada longitud de contexto.

Un servidor privado con GPU es la ruta de pesos nativos. Varios Mac Studio de alta memoria constituyen una ruta distinta y soportada. Escritorios de consumo requieren una compilación cuantizada compatible y comprobaciones de capacidad cuidadosas; un SSD grande por sí solo no sustituye a la memoria rápida de inferencia.

¿Qué checkpoint debería elegir?

Elija un checkpoint antes de descargar. Meta publica checkpoints nativos BF16 y NVFP4, pero no son recomendaciones universales para toda plataforma. Las rutas documentadas en NVIDIA Blackwell usan BF16 o NVFP4; las rutas en AMD Instinct usan BF16 o formatos específicos de AMD como MXFP4/FP8; Intel Xeon 6 usa una configuración en INT4; y la ruta Apple Silicon distribuida usa el checkpoint NVFP4 con MLX. Seleccione el checkpoint que soporte su acelerador exacto y el runtime de inferencia, siguiendo la guía de checkpoints y las instrucciones de despliegue por plataforma de Meta. Los repositorios GGUF proveen una vía diferente de empaquetado y cuantización para llama.cpp. Debe verificarse la compatibilidad del runtime y el soporte de modalidades para los archivos exactos que seleccione.

Estas son huellas de pesos, no presupuestos completos de memoria para serving. Deje espacio para caché, activaciones, el sistema operativo y asignaciones del runtime. Una conversión de menos bits puede reducir el almacenamiento a la vez que cambia calidad o rendimiento; pruebe esas compensaciones con sus prompts reales.

Cómo descargar Muse Spark Open

Comience con Python 3.10 o posterior, almacenamiento persistente y el repositorio oficial NVFP4. Revise su licencia y cumpla cualquier requisito de acceso mostrado para su cuenta. El checkpoint BF16 es un repositorio separado. La descarga siguiente guarda una copia local; el ejemplo posterior con Docker usa una caché persistente de Hugging Face, por lo que puede descargar otra copia a menos que configure explícitamente la carga desde una ruta local.

Descargue el checkpoint NVFP4 a almacenamiento local persistente.

python -m pip install -U huggingface_hub
hf auth login
hf download meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  --local-dir ./Muse-Spark-Open-NVFP4

Planee cientos de gigabytes de transferencia y espacio adicional para archivos temporales. Si la descarga devuelve HTTP 401/403, confirme el acceso al repositorio y la autenticación antes de cambiar la pila de inferencia. Evite copiar un token en el historial del shell o capturas de pantalla publicadas.

Cómo desplegar Muse Spark Open con vLLM

Use vLLM cuando desee un endpoint compatible con OpenAI en un servidor de aceleración soportado. Meta documenta ahora una configuración inicial NVFP4 con cuatro B300. El ejemplo de lanzamiento a continuación sigue esa topología, reduce el contexto servido a 128K y deja deshabilitada la decodificación especulativa para la primera validación.

Verifique los prerrequisitos

Prepare un servidor Linux con cuatro GPU B300 compatibles, el controlador NVIDIA correspondiente, Docker, NVIDIA Container Toolkit y suficiente almacenamiento persistente para pesos y caché. Fije la visibilidad de GPU dentro de los contenedores antes de descargar el modelo. Ejecute los ejemplos de Bash en una shell Bash.

Compruebe el host, Docker y el acceso a GPU dentro de un contenedor CUDA.

nvidia-smi
docker --version
docker run --rm --gpus all nvidia/cuda:12.8.1-base-ubuntu22.04 nvidia-smi

Configure el token de Hugging Face

Si el acceso al repositorio requiere autenticación, pase su token a través del entorno. El siguiente prompt oculta el token mientras escribe; no pegue credenciales en comandos compartidos o registros publicados.

Lea un token de Hugging Face sin eco.

read -rsp "Hugging Face token: " HF_TOKEN
echo
export HF_TOKEN

Extraiga la imagen específica del modelo

Descargue la imagen vLLM de Muse Spark Open.

docker pull vllm/vllm-openai:muse-spark-open

Use la configuración actual de vLLM de Meta con un build compatible con Muse. Una imagen genérica antigua puede no reconocer la arquitectura o el parser. Guarde el digest de la imagen tras una prueba exitosa para que despliegues posteriores usen el mismo build.

Inicie el servidor NVFP4

Lance un servidor vLLM de cuatro GPU con un límite de servicio de 128K.

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:8000:8000 \
  -e HF_TOKEN \
  -e VLLM_USE_RUST_FRONTEND=1 \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  vllm/vllm-openai:muse-spark-open \
  meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  --tensor-parallel-size 4 \
  --enable-expert-parallel \
  --max-model-len 131072 \
  --reasoning-parser muse \
  --tool-call-parser muse \
  --enable-auto-tool-choice

Esta es una configuración inicial para la topología especificada, no una garantía de que cualesquiera cuatro GPU puedan servir el checkpoint. Permita que finalicen la primera descarga, la carga del modelo y la compilación. Conserve la caché entre reinicios. Este comando obtiene desde el repositorio hacia la caché montada; no reutiliza automáticamente la descarga separada con --local-dir.

Pruebe el endpoint local

Liste el modelo servido y solicite una respuesta corta.

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model":"meta-models/Muse-Spark-Open-816B-A42B-NVFP4",
    "messages":[{"role":"user","content":"Explain tensor parallelism in two sentences."}],
    "reasoning_effort":"low",
    "max_tokens":2048
  }'

Use el identificador devuelto por /v1/models si difiere. Verifique tanto la respuesta final como finish_reason: alcanzar el límite de tokens puede cortar el razonamiento antes de una respuesta útil. Mantenga el binding a localhost para pruebas iniciales y añada control de acceso antes del uso remoto.

Conecte una aplicación en Python

Instale el cliente Python usado por el ejemplo.

python -m pip install -U openai

Llame al endpoint local de vLLM desde Python.

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
    timeout=3600,
)
model_id = client.models.list().data[0].id
response = client.chat.completions.create(
    model=model_id,
    messages=[{"role": "user", "content": "Write a small Python input validator."}],
    max_tokens=2048,
    extra_body={"reasoning_effort": "low"},
)
print(response.choices[0].message.content)
print("finish_reason:", response.choices[0].finish_reason)

EMPTY es solo un marcador de posición para un servidor local sin enforcement de API key. Use la credencial configurada si habilita autenticación. Registre el ID del modelo servido y la configuración de la solicitud al integrar agentes.

Cómo desplegar Muse Spark Open con SGLang

SGLang es otra opción soportada de serving con pesos nativos. Su cookbook de Muse Spark Open proporciona configuración y ajuste específicos de hardware. Seleccione la imagen de NVIDIA para B300; AMD e Intel usan imágenes y recetas diferentes.

Prepare la imagen específica del modelo

Descargue la imagen de SGLang para Muse Spark Open en NVIDIA.

docker pull lmsysorg/sglang:dev-muse-spark-open

Inicie el servidor NVFP4 con cuatro B300

El siguiente lanzamiento básico adapta la configuración NVFP4 nativa, omitiendo decodificación especulativa y caché jerárquica. Habilite esas funciones solo después de que el endpoint base funcione y mida el margen de memoria.

Inicie SGLang con paralelismo tensorial y de expertos en cuatro vías.

docker run --rm --gpus all --ipc=host \
  -p 127.0.0.1:30000:30000 \
  -e HF_TOKEN \
  -v "$HOME/.cache/huggingface:/root/.cache/huggingface" \
  --entrypoint sglang \
  lmsysorg/sglang:dev-muse-spark-open serve \
  --model-path meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
  --tp-size 4 --ep-size 4 \
  --quantization modelopt_fp4 \
  --moe-runner-backend flashinfer_trtllm \
  --mem-fraction-static 0.8 \
  --context-length 131072 \
  --enable-layernorm-sp \
  --enable-megamoe-for-layernorm-sp \
  --reasoning-parser muse \
  --tool-call-parser muse \
  --host 0.0.0.0 --port 30000

Verifique el endpoint de SGLang

Compruebe la lista de modelos antes de reutilizar la solicitud de chat en el puerto 30000.

curl http://localhost:30000/v1/models

Envíe la misma prueba de chat corta usada para vLLM al puerto 30000, utilizando el ID de modelo devuelto aquí. Revise la finalización de la respuesta final y una llamada a herramienta inocua antes de ejecutar un agente de codificación.

Cómo ejecutar Muse Spark Open con llama.cpp

El repositorio GGUF de ggml-org proporciona una ruta de conversión separada. Revise los archivos elegidos, la RAM/VRAM disponible y el soporte actual del runtime antes de iniciar una descarga. La disponibilidad de GGUF no hace que un modelo de 816B quepa en un portátil común.

Instale una build actual de llama.cpp

Instale el binario de la aplicación Llama en un host macOS o Linux soportado.

curl -LsSf https://llama.app/install.sh | sh

Revise los scripts de instalación antes de ejecutarlos y use las instrucciones específicas por plataforma si su entorno bloquea instaladores de shell. Los comandos abajo usan la interfaz actual de la aplicación llama; binarios más antiguos llamados llama-server usan una CLI diferente.

Inicie el servidor GGUF

Sirva el GGUF Q4_K_S con un alias de API fijo y un contexto inicial de 32K.

llama serve \
  -hf ggml-org/Muse-Spark-Open-816B-A42B-GGUF:Q4_K_S \
  -a muse-spark-open \
  -c 32768 \
  -np 1 \
  --chat-template-kwargs '{"reasoning_effort":"low"}'

Confirme que el servidor GGUF es accesible en su endpoint local.

curl http://localhost:8080/v1/models

Use muse-spark-open como alias de modelo en la solicitud. Mantenga la máquina en una red de confianza durante las pruebas y configure binding y autenticación antes de compartir acceso. Confirme la visión, audio y comportamiento de herramientas para la conversión seleccionada en lugar de asumir paridad de funciones con los pesos nativos. Use Ollama solo con un paquete de modelo Muse Spark Open verificado y una versión compatible.

Cómo ejecutar Muse Spark Open en varios Mac Studio con MLX

Use dos Mac Studio M5 Ultra con 512 GB de memoria unificada cada uno, o cuatro con 256 GB cada uno. Es una configuración distribuida, no una instalación en un MacBook convencional.

Las instrucciones oficiales de despliegue con MLX requieren macOS 26.2 o posterior, MLX 0.30.1 o posterior, RDMA habilitado en cada Mac, enlaces directos Thunderbolt 5 entre cada par de Macs y SSH sin contraseña desde el host principal. Cada host necesita espacio en disco para el checkpoint NVFP4 completo.

Instale mlx-lm en cada host. Use mlx.distributed_config y la guía distribuida de MLX para generar hostfile.json con las direcciones IP de Thunderbolt y los dispositivos RDMA de cada máquina. Verifique el acceso por SSH y la configuración de RDMA antes de lanzar.

Inicie el servidor MLX compatible con OpenAI desde el Mac principal.

mlx.launch --hostfile hostfile.json --backend jaccl --env MLX_METAL_FAST_SYNCH=1 -- \
  mlx_lm.server --model meta-models/Muse-Spark-Open-816B-A42B-NVFP4 --port 8080

Verifique el endpoint desde el Mac principal con curl http://localhost:8080/v1/models. Reutilice el identificador de modelo devuelto para una solicitud de chat corta. Mantenga el servicio en una red de confianza y añada autenticación antes de compartir acceso.

¿Qué checkpoint de Muse Spark Open debería elegir?

Comience con NVFP4 en un servidor Blackwell soportado cuando su memoria e interconector coincidan con la receta nativa. Use BF16 cuando necesite la referencia de precisión y tenga capacidad. Elija una conversión GGUF específica para llama.cpp solo después de verificar su tamaño real de archivo y calidad de salida. Para la ruta multi-Mac documentada, use el checkpoint NVFP4 compatible con MLX.

Evite elegir únicamente por el tamaño de descarga menor. Compare el éxito de sus tareas, la integridad de las respuestas, la latencia y el uso de memoria. Mantenga la revisión exacta del repositorio y el build del runtime en el registro de despliegue para reproducir resultados.

Muse Spark Open: vLLM vs SGLang vs llama.cpp vs MLX

Elija un runtime en función de su hardware existente y la receta específica del modelo. vLLM se ajusta a servidores con aceleradores soportados; MLX cubre la configuración multi-Mac documentada. Meta también documenta llama.cpp con checkpoints GGUF. Valide el checkpoint y backend elegidos antes de estimar throughput o cambiar de runtime.

¿Cómo optimizar un despliegue local de Muse Spark Open?

Aumente el contexto gradualmente

Use un contexto acotado en el primer lanzamiento y súbalo solo cuando la carga lo requiera. Supervise el tiempo de prefill y la memoria a medida que crece la longitud de entrada. Que un modelo soporte una ventana de 1M tokens no garantiza que toda configuración de hardware pueda reservar esa capacidad con una concurrencia útil.

Ajuste una función a la vez

Mida el servidor base antes de habilitar caché de prefijo, decodificación especulativa o disposiciones distribuidas avanzadas. Repita los mismos prompts y patrón de tráfico tras cada cambio. Conserve los cambios que mejoren la latencia o el throughput de tareas completadas sin perjudicar la calidad de salida.

Mantenga predecibles las versiones de almacenamiento y runtime

Coloque pesos y caché en almacenamiento persistente rápido, separe el arranque en frío de solicitudes en caliente y fije digests de imagen validados. Registre tipo de acelerador, revisión del checkpoint, build del runtime, ajustes del parser, límite de contexto y concurrencia con las mediciones.

Supervise el trabajo completado

Anteponga la corrección a la velocidad. Empiece con una solicitud corta de texto y confirme que el servidor devuelve una respuesta completa. Luego pruebe una llamada a herramienta inocua y una solicitud de imagen si el runtime elegido la soporta. Registre versiones de software, cantidad de GPU, checkpoint, longitud de entrada, presupuesto de salida y concurrencia para cada medición local.

Aumente gradualmente la longitud del prompt y la concurrencia, observando la latencia al primer token, las respuestas completas y el pico de memoria. Estas son mediciones de validación local; esta guía no afirma throughput medido ni cifras de rentabilidad del hardware.

Cómo usar la API Muse Wonder en CometAPI en lugar de autoalojar

Si un servidor multi-GPU o una configuración Mac distribuida no es práctica, puede usar la API Muse Wonder en CometAPI como alternativa hospedada del modelo de Meta. No es un endpoint para el checkpoint Muse Spark Open: el ID de modelo del gateway es muse-wonder, mientras que Muse Spark Open se refiere a pesos descargables publicados por separado. No transfiera resultados de benchmark de Muse Spark Open ni afirmaciones exactas de funciones del modelo a Muse Wonder.

Endpoint, identidad del modelo y autenticación

Use la URL base HTTPS https://api.cometapi.com/v1, POST /chat/completions, autenticación Bearer y el identificador de modelo muse-wonder. Consulte la documentación de integración de CometAPI para detalles de autenticación.

export COMETAPI_KEY="your_cometapi_api_key"
 
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
  -H "Authorization: Bearer $COMETAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "muse-wonder",
    "messages": [{"role":"user","content":"Explain expert parallelism briefly."}],
    "stream": false
  }'

Una respuesta exitosa debería incluir una respuesta en choices[0].message.content. La solicitud ilustra la ruta documentada de CometAPI; no es evidencia de que Wonder y Spark Open sean el mismo modelo.

Ejemplo de cliente en Python

import os
from openai import OpenAI
 
client = OpenAI(
    api_key=os.environ["COMETAPI_KEY"],
    base_url="https://api.cometapi.com/v1",
    timeout=120.0,
)
result = client.chat.completions.create(
    model="muse-wonder",
    messages=[{"role": "user", "content": "Summarize the deployment tradeoffs."}],
)
print(result.choices[0].message.content)

¿Qué entradas y precios soporta la alternativa?

Meta documenta entrada de texto, imagen, video, audio y PDF para el Muse Wonder nativo, con salida de texto. El soporte del gateway para cada formato multimedia y esquema de mensajes debe validarse por separado; los ejemplos anteriores empiezan deliberadamente con texto. La guía de la API Muse Wonder de CometAPI proporciona la siguiente instantánea de tarifas publicadas: 3.20 USD por millón de tokens de entrada no cacheados y 16.00 USD por millón de tokens de salida. No establece una tarifa de entrada cacheada de CometAPI. Verifique la tarifa aplicada a su cuenta antes del uso en producción.

A esas tarifas citadas, 100,000 tokens de entrada no cacheados más 50,000 tokens de salida costarían aproximadamente 1.12 USD en cargos por tokens del modelo (0.1 × 3.20 USD + 0.05 × 16.00 USD), excluyendo otras posibles tasas. En cambio, los costos del hosting local dependen de la adquisición o alquiler de GPU, energía, utilización, almacenamiento, ingeniería y mantenimiento. Este es un ejemplo de precios, no un benchmark de costo por tarea medido.

El autoalojamiento ofrece control sobre residencia de datos, configuración de runtime y potencialmente una alta utilización predecible. Las APIs hospedadas evitan comprar aceleradores, mantener clusters con paralelismo de expertos y diseñar tolerancia a fallos. El punto de equilibrio depende de la carga: un asistente interno con uso ligero suele tener una economía distinta a la de una flota de agentes de codificación muy utilizada.

Problemas comunes en despliegues locales de Muse Spark Open

Separe fallos de arranque de fallos en solicitudes

Para fallos al arrancar, compruebe acceso al repositorio, visibilidad de GPU, soporte de arquitectura y asignación de memoria en ese orden. Si el servidor está listo pero fallan las solicitudes, inspeccione el ID de modelo, formato de solicitud, parser y presupuesto de salida. Guarde la versión del runtime y el primer error relevante en lugar de reintentar con varios cambios de flags no relacionados.

Conclusión

Si cuenta con un servidor Blackwell soportado, comience con NVFP4 y una receta de despliegue oficial de vLLM, valide un contexto de servicio modesto y escale el paralelismo tras recopilar sus propias mediciones de latencia y éxito de tareas. Si trabaja totalmente en el ecosistema Apple, la opción de escritorio soportada es un despliegue MLX con múltiples Mac Studio M5 Ultra, no una instalación convencional en portátil. Para equipos sin esa infraestructura, use un proveedor de inferencia hospedada manteniendo explícitos la identidad del modelo y los supuestos de precio.

Preguntas frecuentes

¿Cómo reinicio una descarga de Muse Spark Open tras una interrupción?

Ejecute de nuevo hf download con el mismo repositorio y directorio local. Conserve los archivos descargados y la caché para que el cliente pueda reutilizar el contenido completado. Confirme que la autenticación sigue funcionando y que queda suficiente espacio en disco antes de reintentar; borrar todo el directorio puede forzar otra transferencia grande.

¿Qué ocurre con las conversaciones de Muse Spark Open tras reiniciar el servidor?

Considere el endpoint HTTP de inferencia como sin estado a menos que su aplicación persista explícitamente el historial de conversación. Guarde los mensajes y resultados de herramientas necesarios para reconstruir la conversación y envíelos de nuevo tras el reinicio. Una caché persistente de descarga del modelo preserva los archivos de pesos, no las conversaciones de su aplicación.

¿Cómo mantengo consistentes los ajustes de razonamiento de Muse Spark Open?

Establezca explícitamente el esfuerzo de razonamiento soportado en la solicitud del cliente en lugar de confiar en valores por defecto. Registre ese valor junto con la revisión del modelo, la plantilla de chat y la versión del runtime al comparar respuestas. Si el comportamiento cambia después de una actualización, verifique esos ajustes antes de atribuir la diferencia al checkpoint.

¿Cómo pueden varias aplicaciones compartir un endpoint local de Muse Spark Open?

Dirija cada cliente a la misma URL base compatible con OpenAI y al identificador de modelo devuelto por /v1/models. Añada autenticación, límites de solicitud y monitorización antes de compartirlo con más usuarios. Pruebe solicitudes simultáneas y defina el comportamiento de cola o timeout antes de considerar una solicitud única exitosa como una garantía de capacidad.