Come eseguire Muse Spark Open in locale

TL;DR

Eseguire Muse Spark Open in locale è possibile, ma si tratta di una distribuzione su larga scala piuttosto che di una tipica configurazione a singola GPU. Le configurazioni documentate da Meta includono quattro GPU NVIDIA B300 per NVFP4, otto B300 per BF16 oppure un setup MLX distribuito che utilizza più M5 Ultra Mac Studio.

Per la maggior parte degli sviluppatori, il primo passo è abbinare il checkpoint a una combinazione supportata di hardware e runtime di inferenza. Iniziare con una lunghezza del contesto conservativa, verificare che il server restituisca risposte complete e misurare l’uso di memoria prima di aumentare il contesto o la concorrenza. Se non si dispone di hardware adeguato, un’API di inferenza ospitata può essere l’opzione più pratica, ad esempio Muse Spark di CometAPI.

Key Takeaways

• Muse Spark Open ha 816B parametri totali e circa 42B attivi per token; l’intera banca di esperti richiede comunque archiviazione e memoria.
• Scegliere NVFP4 o BF16 in base a dimensione del checkpoint, memoria dell’acceleratore, interconnessione e overhead di serving.
• L’esempio NVIDIA utilizza l’attuale configurazione vLLM NVFP4 con quattro B300; verificare l’hardware e il runtime esatti prima dell’avvio.
• Il percorso Apple richiede più M5 Ultra Mac Studio e RDMA su collegamenti Thunderbolt 5 diretti.
• Verificare endpoint del modello, completezza delle risposte e uso di memoria prima di aumentare il contesto o aggiungere utenti.

What Is Muse Spark Open?

Muse Spark Open è il rilascio con pesi scaricabili della famiglia Muse Spark di Meta. A differenza di un trasformatore denso convenzionale, il suo design MoE sparso instrada ogni token attraverso un sottoinsieme di esperti, supportando una capacità a livello di frontiera con un’impronta di calcolo attivo più piccola. L’annuncio di rilascio di Meta lo descrive come nativamente multimodale e ottimizzato per il coding multi-step e workflow agentici.

Il modello accetta testo, immagini, audio e video e produce testo; la disponibilità delle funzionalità dipende comunque dal runtime di serving. È distribuito sotto la Muse Model License con restrizioni d’uso. Controllare i termini del repository prima della distribuzione e rivedere le azioni irreversibili nei workflow agentici.

How Does Muse Spark Open Perform?

I benchmark di qualità aiutano a stabilire se il modello merita una valutazione; non indicano quanto velocemente funzionerà il vostro server locale. I dati riportati di seguito sono risultati di capacità dichiarati da Meta, non misurazioni derivate dai comandi di distribuzione in questa guida.

Meta documenta impostazioni del modello, procedure specifiche per benchmark e selezione dei punteggi nella sua metodologia di valutazione. Muse Spark Open utilizza ragionamento xhigh in questi risultati. Confrontare un setup locale utilizzando il proprio set di task, versione software, contesto e concorrenza; un contesto servito inferiore o un harness diverso cambia cosa viene testato.

Can You Actually Run Muse Spark Open Locally?

Sì. È possibile eseguire Muse Spark Open in locale se il sistema soddisfa i requisiti di checkpoint, acceleratore e runtime di inferenza. I percorsi documentati includono server GPU NVIDIA e sistemi Apple Silicon distribuiti; una conversione GGUF compatibile fornisce un’altra opzione per macchine con sufficiente memoria indirizzabile. La scheda modello ufficiale di Muse Spark Open e la guida alla distribuzione su Hugging Face descrivono i pesi rilasciati e la configurazione specifica per ciascun runtime. Un laptop consumer standard non può mantenere l’intero checkpoint nativo in memoria.

La capacità di memoria è il primo vincolo. I parametri attivi descrivono il calcolo per token, non l’intera impronta dei pesi degli esperti. La guida ai checkpoint di Meta riporta circa 537 GB per NVFP4 e 1,65 TB per BF16, escludendo KV cache, attivazioni e overhead del runtime.

Allocare l’hardware utilizzando la dimensione completa del checkpoint più il margine per il serving. Prompt lunghi aumentano la pressione sulla KV cache e il numero di GPU supportate dipende dal runtime e dall’acceleratore. La configurazione NVFP4 a quattro GPU non è una promessa che qualsiasi quattro schede Blackwell possano servire ogni lunghezza di contesto.

Un server GPU privato è il percorso per pesi nativi. Più Mac Studio ad alta memoria rappresentano un percorso supportato separato. I desktop consumer richiedono una build quantizzata compatibile e attenti controlli di capacità; un grande SSD da solo non può sostituire la memoria veloce per l’inferenza.

Which Checkpoint Should You Choose?

Scegliere un checkpoint prima del download. Meta pubblica checkpoint nativi BF16 e NVFP4, ma non sono raccomandazioni universali per ogni piattaforma. I percorsi documentati per NVIDIA Blackwell utilizzano BF16 o NVFP4; i percorsi su AMD Instinct utilizzano BF16 o checkpoint specifici AMD MXFP4/FP8; Intel Xeon 6 utilizza una configurazione INT4; e il percorso Apple Silicon distribuito utilizza il checkpoint NVFP4 con MLX. Selezionare il checkpoint supportato dall’acceleratore e dal runtime di inferenza esatti, seguendo la guida ai checkpoint di Meta e le istruzioni di distribuzione specifiche per piattaforma. I repository GGUF forniscono un diverso packaging e percorso di quantizzazione per llama.cpp. Compatibilità del runtime e supporto delle modalità devono essere verificati per i file esatti selezionati.

Queste sono impronte dei pesi, non budget di memoria completi per il serving. Lasciare spazio per cache, attivazioni, sistema operativo e allocazioni del runtime. Una conversione a bit inferiori può ridurre l’archiviazione modificando qualità o throughput; testare tali compromessi sui propri prompt effettivi.

How to Download Muse Spark Open

Iniziare con Python 3.10 o successivo, archiviazione persistente e il repository NVFP4 ufficiale. Rivedere la licenza e completare eventuali requisiti di accesso associati al proprio account. Il checkpoint BF16 è un repository separato. Il download seguente salva una copia locale; l’esempio Docker successivo utilizza una cache Hugging Face persistente, quindi potrebbe scaricare un’altra copia a meno che non si configuri esplicitamente il caricamento da un percorso locale.

Scaricare il checkpoint NVFP4 su archiviazione locale 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

Pianificare centinaia di gigabyte di trasferimento e spazio aggiuntivo per file temporanei. Se il download restituisce HTTP 401/403, confermare l’accesso al repository e l’autenticazione prima di modificare lo stack di inferenza. Evitare di copiare un token nella cronologia della shell pubblicata o in screenshot.

How to Deploy Muse Spark Open with vLLM

Usare vLLM quando si desidera un endpoint compatibile OpenAI su un server con acceleratore supportato. Meta documenta ora una configurazione iniziale NVFP4 con quattro B300. L’esempio di lancio seguente segue tale topologia, abbassa il contesto servito a 128K e lascia la decodifica speculativa facoltativa disabilitata per il primo run di convalida.

Check the prerequisites

Preparare un server Linux con quattro GPU B300 compatibili, il driver NVIDIA corrispondente, Docker, NVIDIA Container Toolkit e sufficiente archiviazione persistente per pesi e cache. Correggere la visibilità delle GPU all’interno dei container prima di scaricare il modello. Eseguire gli esempi Bash in una shell Bash.

Verificare l’host, Docker e l’accesso GPU dentro un container CUDA.

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

Set the Hugging Face token

Se l’accesso al repository richiede autenticazione, passare il token tramite l’ambiente. Il prompt seguente nasconde il token mentre si digita; non incollare credenziali in comandi condivisi o log pubblicati.

Leggere un token Hugging Face senza eco.

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

Pull the model-specific container

Scaricare l’immagine vLLM di Muse Spark Open.

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

Usare la configurazione Meta vLLM corrente con una build compatibile con Muse. Un’immagine generica più vecchia potrebbe non riconoscere l’architettura o il parser. Salvare il digest dell’immagine dopo un test riuscito in modo che le distribuzioni successive utilizzino la stessa build.

Launch the NVFP4 server

Avviare un server vLLM a quattro GPU con limite di serving a 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

Questa è una configurazione iniziale per la topologia specificata, non una promessa che qualsiasi quattro GPU possano servire il checkpoint. Lasciare completare il primo download, il caricamento del modello e la compilazione. Conservare la cache tra i riavvii. Questo comando recupera dal repository nella cache montata; non riutilizza automaticamente il download separato con --local-dir di cui sopra.

Test the local endpoint

Elencare il modello servito e richiedere una breve risposta.

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
  }'

Usare l’identificatore restituito da /v1/models se differisce. Controllare sia la risposta finale sia finish_reason: raggiungere il limite di token può troncare il ragionamento prima che appaia una risposta utile. Mantenere il binding su localhost per i test iniziali e aggiungere controllo degli accessi prima dell’uso remoto.

Connect a Python application

Installare il client Python usato nell’esempio.

python -m pip install -U openai

Chiamare l’endpoint vLLM locale da 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 è solo un segnaposto per un server locale senza enforcement di API key. Usare la credenziale configurata se si abilita l’autenticazione. Registrare l’ID del modello servito e le impostazioni della richiesta quando si integrano agenti.

How to Deploy Muse Spark Open with SGLang

SGLang è un’altra opzione supportata per il serving con pesi nativi. Il suo cookbook per Muse Spark Open fornisce configurazione e tuning specifici per hardware. Selezionare l’immagine NVIDIA per B300; AMD e Intel utilizzano immagini e ricette diverse.

Prepare the model-specific image

Scaricare l’immagine SGLang NVIDIA per Muse Spark Open.

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

Start the four-B300 NVFP4 server

Il seguente avvio di base adatta le impostazioni NVFP4 native, con decodifica speculativa e caching gerarchico omessi. Abilitare tali funzionalità solo dopo che l’endpoint base funziona e si è misurato il margine di memoria.

Avviare SGLang con parallelismo tensoriale ed esperto a quattro vie.

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

Verify the SGLang endpoint

Controllare l’elenco dei modelli prima di riutilizzare la richiesta di chat sulla porta 30000.

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

Inviare lo stesso breve test di chat usato per vLLM alla porta 30000, utilizzando l’ID modello restituito qui. Ricontrollare la completezza della risposta finale e una chiamata tool innocua prima di eseguire un agente di coding.

How to Run Muse Spark Open with llama.cpp

Il repository GGUF di ggml-org fornisce un percorso di conversione separato. Rivedere i file scelti, la RAM/VRAM disponibile e il supporto del runtime corrente prima di avviare un download. La disponibilità di GGUF non significa che un modello da 816B rientri in un laptop ordinario.

Install a current llama.cpp build

Installare il binario dell’app Llama su un host macOS o Linux supportato.

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

Rivedere gli script di installazione prima di eseguirli e usare le istruzioni specifiche per la piattaforma se l’ambiente blocca installer shell. I comandi seguenti utilizzano l’attuale interfaccia dell’app llama; binari più vecchi denominati llama-server usano una CLI diversa.

Start the GGUF server

Servire il GGUF Q4_K_S con un alias API fisso e un contesto iniziale a 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"}'

Confermare che il server GGUF sia raggiungibile sul suo endpoint locale.

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

Usare muse-spark-open come alias modello nella richiesta. Tenere la macchina su una rete fidata durante i test e configurare binding e autenticazione prima di condividere l’accesso. Confermare comportamento per visione, audio e tool per la conversione selezionata invece di assumere parità di funzionalità con i pesi nativi. Usare Ollama solo con un pacchetto modello Muse Spark Open verificato e una versione compatibile.

How to Run Muse Spark Open on Multiple Mac Studios with MLX

Usare due M5 Ultra Mac Studio con 512 GB di memoria unificata ciascuno, oppure quattro con 256 GB ciascuno. Si tratta di un setup distribuito, non di un’installazione su un MacBook ordinario.

Le istruzioni ufficiali di distribuzione MLX richiedono macOS 26.2 o successivo, MLX 0.30.1 o successivo, RDMA abilitato su ogni Mac, collegamenti Thunderbolt 5 diretti tra ogni coppia di Mac e SSH senza password dall’host primario. Ogni host necessita di spazio su disco per l’intero checkpoint NVFP4.

Installare mlx-lm su ogni host. Usare mlx.distributed_config e la guida MLX distribuita per generare hostfile.json con gli indirizzi IP Thunderbolt e i dispositivi RDMA di ogni macchina. Verificare accesso SSH e configurazione RDMA prima dell’avvio.

Avviare il server MLX compatibile OpenAI distribuito dal Mac primario.

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

Verificare l’endpoint dal Mac primario con curl http://localhost:8080/v1/models. Riutilizzare l’identificatore di modello restituito per una breve richiesta di chat. Mantenere il servizio su una rete fidata e aggiungere autenticazione prima di condividere l’accesso.

Which Muse Spark Open Checkpoint Should You Choose?

Iniziare con NVFP4 su un server Blackwell supportato quando memoria e interconnessione corrispondono alla ricetta nativa. Usare BF16 quando è richiesto il riferimento a piena precisione e si dispone della capacità. Scegliere una specifica conversione GGUF per llama.cpp solo dopo aver verificato dimensione effettiva del file e qualità dell’output. Per il percorso multi-Mac documentato, usare il checkpoint NVFP4 compatibile con MLX.

Evitare di scegliere solo in base al download più piccolo. Confrontare successo sulle proprie attività, completezza delle risposte, latenza e uso di memoria. Conservare la revisione del repository esatta e la build del runtime nel record di distribuzione in modo che i risultati siano riproducibili.

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

Scegliere un runtime utilizzando l’hardware esistente e la ricetta specifica del modello. vLLM si adatta a server con acceleratori supportati; MLX copre il setup multi-Mac documentato. Meta documenta anche llama.cpp con checkpoint GGUF. Convalidare il checkpoint e il backend scelti prima di stimare il throughput o cambiare runtime.

How Do You Optimize a Local Muse Spark Open Deployment?

Increase context gradually

Usare un contesto limitato per il primo avvio e aumentarlo solo quando il carico di lavoro necessita di più storico. Monitorare tempo di prefill e memoria man mano che la lunghezza dell’input cresce. Un modello che supporta una finestra da 1M di token non garantisce che ogni configurazione hardware possa riservare tale capacità con una concorrenza utile.

Tune one feature at a time

Misurare il server base prima di abilitare caching dei prefissi, decodifica speculativa o layout distribuiti avanzati. Ripetere gli stessi prompt e pattern di traffico dopo ogni modifica. Conservare le modifiche che migliorano la latenza o il throughput per task completati senza compromettere la qualità dell’output.

Keep storage and runtime versions predictable

Posizionare pesi e cache su storage persistente e veloce, separare l’avvio a freddo dalle richieste a caldo e fissare i digest delle immagini convalidate. Registrare tipo di acceleratore, revisione del checkpoint, build del runtime, impostazioni del parser, limite di contesto e concorrenza insieme alle misurazioni.

Monitor completed work

Verificare la correttezza prima della velocità. Iniziare con una breve richiesta testuale e confermare che il server restituisca una risposta completa. Quindi testare una chiamata tool innocua e una richiesta di immagine se il runtime scelto la supporta. Registrare versioni software, numero di GPU, checkpoint, lunghezza input, budget output e concorrenza per ogni misurazione locale.

Aumentare gradualmente lunghezza del prompt e concorrenza, osservando latenza del primo token, risposte completate e memoria di picco. Queste sono misurazioni di convalida locale; questa guida non rivendica throughput misurato o punti di pareggio hardware.

How Can You Use Muse Wonder API in CometAPI Instead of Self-Hosting?

Se un server multi-GPU o un setup Mac distribuito non è praticabile, è possibile usare la Muse Wonder API in CometAPI come alternativa ospitata dei modelli Meta. Questa non è un’endpoint API per il checkpoint Muse Spark Open: l’ID modello del gateway è muse-wonder, mentre Muse Spark Open si riferisce a pesi scaricabili rilasciati separatamente. Non trasferire i risultati di benchmark di Muse Spark Open o affermazioni esatte sulle funzionalità del modello a Muse Wonder.

Endpoint, model identity, and authentication

Usare l’URL base HTTPS https://api.cometapi.com/v1, POST /chat/completions, autenticazione Bearer e l’identificatore di modello muse-wonder. Consultare la documentazione di integrazione CometAPI per i dettagli di autenticazione.

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 risposta corretta dovrebbe includere una risposta in choices[0].message.content. La richiesta illustra il percorso CometAPI documentato; non è prova che Wonder e Spark Open siano lo stesso modello.

Python client example

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)

What inputs and pricing does the alternative support?

Meta documenta input di testo, immagine, video, audio e PDF per Muse Wonder nativo, con output testuale. Il supporto del gateway per ciascun formato media e schema dei messaggi deve essere validato separatamente; gli esempi sopra iniziano deliberatamente con testo. La guida alla Muse Wonder API di CometAPI fornisce la seguente istantanea tariffaria pubblicata: $3,20 per milione di token di input non in cache e $16,00 per milione di token di output. Non stabilisce una tariffa CometAPI per input in cache. Verificare la tariffa applicata al proprio account prima dell’uso in produzione.

A tali tariffe, 100.000 token di input non in cache più 50.000 token di output costerebbero approssimativamente $1,12 in addebiti per token modello (0,1 × $3,20 + 0,05 × $16,00), escludendo altre possibili commissioni. Per contro, i costi di hosting locale dipendono da acquisizione o noleggio GPU, energia, utilizzo, archiviazione, engineering e manutenzione. Questo è un esempio di pricing, non un benchmark misurato del costo per task.

Il self-hosting offre controllo su residenza dei dati, configurazione del runtime e potenzialmente un’alta utilizzazione prevedibile. Le API ospitate evitano l’acquisto di acceleratori, la manutenzione di cluster con parallelismo degli esperti e l’ingegnerizzazione della tolleranza ai guasti. Il punto di pareggio dipende dal carico: un assistente interno poco utilizzato di solito ha un’economia diversa da una flotta di agenti di coding molto utilizzata.

Common Muse Spark Open Local Deployment Problems

Separate startup failures from request failures

Per i failure all’avvio, controllare in quest’ordine: accesso al repository, visibilità delle GPU, supporto dell’architettura e allocazione della memoria. Se il server è pronto ma le richieste falliscono, ispezionare ID del modello, formato della richiesta, parser e budget di output. Salvare la versione del runtime e il primo errore rilevante invece di ritentare con diverse flag non correlate.

Conclusion

Se si dispone di un server Blackwell supportato, iniziare con NVFP4 e una ricetta di distribuzione vLLM ufficiale, convalidare un contesto di serving modesto e scalare il parallelismo dopo aver raccolto le proprie misurazioni di latenza e successo dei task. Se si lavora interamente nell’ecosistema Apple, la storia desktop supportata è una distribuzione MLX su più Mac Studio M5 Ultra, non un’installazione su un laptop convenzionale. Per i team senza questa infrastruttura, usare un provider di inferenza ospitato mantenendo esplicite identità del modello e ipotesi di prezzo.

FAQ

How can I restart a Muse Spark Open download after an interruption?

Rieseguire hf download con lo stesso repository e directory locale. Conservare i file scaricati e la cache così che il client possa riutilizzare i contenuti completati. Confermare che l’autenticazione funzioni ancora e che rimanga spazio su disco sufficiente prima di riprovare; eliminare l’intera directory può forzare un altro grande trasferimento.

What happens to Muse Spark Open conversations after a server restart?

Trattare l’endpoint HTTP di inferenza come stateless a meno che la vostra applicazione non persista esplicitamente la cronologia delle conversazioni. Salvare i messaggi e i risultati degli strumenti necessari per ricostruire la conversazione e inviarli di nuovo dopo il riavvio. Una cache di download persistente del modello conserva i file dei pesi, non le conversazioni della vostra applicazione.

How do I keep Muse Spark Open reasoning settings consistent?

Impostare esplicitamente lo sforzo di ragionamento supportato nella richiesta del client anziché fare affidamento sui default. Registrare tale valore con la revisione del modello, il template di chat e la versione del runtime quando si confrontano le risposte. Se il comportamento cambia dopo un aggiornamento, verificare tali impostazioni prima di attribuire la differenza al checkpoint.

How can several applications share a local Muse Spark Open endpoint?

Puntare ciascun client allo stesso URL base compatibile OpenAI e all’identificatore di modello restituito da /v1/models. Aggiungere autenticazione, limiti di richiesta e monitoraggio prima di condividerlo con più utenti. Testare richieste simultanee e definire comportamento di queueing o timeout prima di considerare una singola richiesta riuscita come garanzia di capacità.