Muse Spark Open: what it takes to run Meta's 816B open-weight model, what the licence allows, and where it trails

Meta released the weights of Muse Spark Open on 15 October: an 816-billion-parameter mixture-of-experts model with 42B parameters active per token, a 1M-token context window, and text, image, video and audio input (Meta, Hugging Face). Meta calls it "the most capable US open-weight model to date" and pitches it at coding and agent work. Seven API providers had it on day one, and Meta showed it running on two Mac Studios (TechCrunch).

"Open weights" and "816B" raise the same three questions for any team thinking of using it: what hardware it really needs, how you call it, and what the licence lets you do. This article answers each with the numbers from Meta's model card, gives you the serve and client code, and shows where Meta's own benchmarks say it falls behind the Chinese open models it is up against.

What Meta released

A closed Muse Spark model launched in April; this is the open-weight release of that line (The New Stack). The weights are on Hugging Face, Amazon SageMaker AI, Google Cloud Model Garden and Microsoft Foundry, and Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter and Together AI serve it as an API (Meta).

How 816B parameters become 42B per token

Each of the 62 layers has 256 expert feed-forward blocks. A router picks 8 of them for every token, so only a small slice of the expert weights does any arithmetic for that token (Hugging Face). Images, video and audio go through the Perception Encoder first and enter the language model as embeddings. That is why the model computes like a 42B model but has to be stored like an 816B one.

Memory: the active count does not shrink the bill

Any expert can be chosen for the next token, so all of them have to be resident. At two bytes per parameter, the BF16 weights are about 1.6 TB; the NVFP4 checkpoint, which quantises only the experts, is about 530 GB (MarkTechPost). The model card recommends at least 700 GB of accelerator memory for NVFP4 and 2 TB for BF16 (Hugging Face).

The Mac option is real but narrow. The New Stack points out that Apple does not currently sell the 512 GB Mac Studio to general buyers, and that two of them cost roughly as much as a small car (The New Stack). For most teams the choice is a four- or eight-GPU node, or an API.

The context window adds its own cost. From the model card's attention config, the KV cache per token is 2 (keys and values) × 16 KV heads × 64 dimensions × 62 layers × 2 bytes = 253,952 bytes, about 248 KiB. A single sequence filled to 1,048,576 tokens therefore needs about 266 GB of KV cache in BF16, on top of the weights. That is our arithmetic, not a Meta figure.

Serving it with vLLM or SGLang

Meta's developer blog gives day-one commands for vLLM, SGLang, TensorRT-LLM, llama.cpp and Unsloth. Both GPU recipes use the NVFP4 checkpoint across four GPUs with expert parallelism, and both enable the muse reasoning and tool-call parsers, which is how the server hands back reasoning and tool calls as separate fields rather than as raw text. The commands below are Meta's, without the speculative-decoding options; add those from the blog once the base setup works.

VLLM_USE_RUST_FRONTEND=1 vllm serve meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \  --tensor-parallel-size 4 \  --enable-expert-parallel \  --max-model-len 1048576 \  --reasoning-parser muse \  --tool-call-parser muse \  --enable-auto-tool-choice

Meta reports a 3.7× single-request throughput gain from the DFlash V2 draft model on AMD MI355X (MarkTechPost) and kernel-level speed-ups of 1.03–3.95× from SGLang's Helion kernels, but only 3% end to end on AMD MI350 (Meta). Those are vendor numbers on vendor hardware; the end-to-end figure is the one to plan around until you have measured your own.

Calling it: reasoning_effort and sampling

Both servers expose an OpenAI-compatible endpoint, so any OpenAI client works. Two settings matter. First, reasoning_effort defaults to xhigh, the slowest and most expensive level, and any value other than low, medium, high or xhigh is an error. Meta suggests high or xhigh for coding and agent work and low or medium for short answers. Second, the recommended sampling is temperature 1.0 and top_p 1.0 with top_k off; Meta's benchmarks were run that way (Hugging Face).

import jsonfrom openai import OpenAI # vLLM serves on :8000 by default; SGLang on the --port you gave it.client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed") tools = [{    "type": "function",    "function": {        "name": "ci_status",        "description": "Return the latest CI result for a branch.",        "parameters": {            "type": "object",            "properties": {"branch": {"type": "string"}},            "required": ["branch"],        },    },}] resp = client.chat.completions.create(    model="meta-models/Muse-Spark-Open-816B-A42B-NVFP4",    messages=[{"role": "user", "content": "Is main green? If not, say which job failed."}],    tools=tools,    reasoning_effort="medium",  # the default is xhigh; set it on purpose    temperature=1.0,    top_p=1.0,) msg = resp.choices[0].messagefor call in msg.tool_calls or []:    print("tool call:", call.function.name, json.loads(call.function.arguments))print(msg.content)print(resp.usage)

If you would rather not host it, OpenRouter, Baseten and Nebius list it at 1.25 per million input tokens and 4.25 per million output tokens with the full 1M context (MarkTechPost). Reasoning tokens are output, so reasoning_effort is also your cost control.

Benchmarks: ahead on tool use, behind on coding

Meta's comparison is with the leading Chinese open-weight models, and its own table shows a split. Muse Spark Open leads on agent and tool-use benchmarks such as MCP-Atlas and JobBench, and trails on coding: 76.4 on Terminal-Bench 2.1 against 85.0 for Kimi K3, and 60 on DeepSWE 1.1 against 68 (Hugging Face). The New Stack notes the DeepSWE gap is about the same one Meta acknowledged at the April launch (The New Stack).

Size matters when you read this. Kimi K3 is 2.8T parameters with 104B active and Qwen3.8 is 2.4T with 95B active, while GLM 5.3, at 753B total and about 40B active, is the closest match to Muse's 816B and 42B (MarkTechPost). On Artificial Analysis's Intelligence Index, Muse scores 39 against 45 for GLM 5.3, 44 for Kimi K3 and 40 for Qwen3.8 (Hugging Face). Every number here is vendor-reported, and Meta's harness for DeepSWE is its own. Run your own tasks before choosing.

One result stands out for a different reason. On StrongREJECT v2, where lower means the model gave less help with harmful jailbreak prompts, Muse scores 0.5 against 62.9 to 66.6 for the others (Hugging Face). Meta says the open version had extra safety post-training (Meta). If you build security tooling, test for refusals on legitimate requests early.

What the Muse Model License asks of you

The weights are downloadable; the licence is not an open-source licence. From the model card and The New Stack:

• Derivatives are allowed, including fine-tuning, distillation and merging. Meta claims no ownership of outputs.
• Attribution is mandatory: a product using the model or a derivative must prominently display "Built with Muse Spark Open" in its UI, documentation, website or settings.
• The revenue clause is aimed at hosts: a model-as-a-service provider with more than $20 million in gross revenue over any 12 months must notify Meta and sign a separate agreement before offering it. Internal use and features in your own product are not covered by that clause (MarkTechPost).
• The usage policy restricts uses, including military and critical-infrastructure deployments, malware and impersonation, and says the model is not intended for people under 18.

For most internal tools and product features, the licence costs you a line of attribution. If you resell inference, or your product touches defence or critical infrastructure, get a lawyer to read the full text before you build on it.