Meta Open-Sources 816B Behemoth Muse Spark: The Truth About Parameters and Licensing

Meta released the model weights for Muse Spark Open on October 15, and it shot up to about 800 points on Hacker News. The two dominant takes in the community—"Meta is back" and "this isn't open source at all"—are both too simplistic. What actually deserves attention is this: what do you actually get in your hands?

Spec Sheet: More Than Just Big

Muse Spark Open uses a mixture-of-experts (MoE) architecture with 816B total parameters, but only 42B activated per inference. This means VRAM usage is based on 816B, while compute cost is closer to a 42B model—theoretical throughput-per-dollar could be considerable.

Other key specs:

• 1 million token context window
• Native multimodal
• Built for coding and agentic tasks: long-horizon tasks, software engineering, multi-step reasoning
• Additional safety post-training to keep behavior controllable even when running bare without system guardrails
• Custom Helion GPU kernels integrated into SGLang, which Meta claims deliver 1.03–3.95x kernel-level speedups on NVIDIA and AMD, and a 3% end-to-end improvement on AMD MI350

Meta calls it "the strongest US open-weight model to date." Note that qualifier "US"—it says a lot on its own.

Mixture-of-experts (MoE) architecture is the key to understanding the cost structure of this class of models. A traditional dense model runs all parameters through computation on every inference, whereas MoE splits the feed-forward layers into many "expert" subnetworks, then uses a router network to select only a few experts to activate based on each token's content. Muse Spark Open's 816B total parameters are the sum of all experts, while the 42B activated parameters are the portion that actually participates in computation in a single forward pass. This leads to two direct consequences: VRAM must be able to hold all 816B weights (because any token might be routed to any expert), but compute cost is only comparable to 42B. So its price-performance advantage mainly comes down to the "VRAM-for-compute" trade-off—you need hardware with large memory, but on the same compute budget you get capability far beyond a dense model of comparable scale.

NVFP4, BF16, and GGUF quantization represent different numerical precision storage formats of the same model. BF16 is 16-bit floating point: highest precision, largest size. NVFP4 is NVIDIA's flagship 4-bit floating-point format, optimized specifically for the Blackwell architecture, capable of compressing weight size to roughly a quarter with almost no precision loss. GGUF is the quantization container format of the llama.cpp ecosystem, supporting multiple levels from 2-bit to 8-bit. 2-bit dynamic quantization is an aggressive approach that mitigates precision collapse through layer-wise adaptive scaling of the weight distribution, at the cost of potentially degraded inference quality. These three are not mutually exclusive model versions, but rather the same set of weights packaged for different hardware and deployment stacks.

Benchmarks: Vendor Data, Read With Caution

Benchmark	Muse Spark Open	Best Competitor
MCP-Atlas (tool calling)	89.2	GLM 5.3: 84.2
Terminal-Bench 2.1	76.4	Kimi K3: 85.0
DeepSWE 1.1	60	Kimi K3: 68
Intelligence Index	39	GLM 5.3: 45

An honest read: it leads on tool calling, but lags behind frontier Chinese open models on pure coding and general intelligence. If you're building an agent stack, tool-calling reliability carries a lot of weight; but if it's "write me a compiler," Kimi K3 is still more favored.

HN commenters also pointed out that Artificial Analysis scores are obtained at the highest reasoning setting, which almost nobody uses in high-concurrency production environments. Actual tokens/sec and completion time are more informative than headline indices. Be sure to run your own evaluations.

MCP-Atlas measures a model's tool-calling ability in Model Context Protocol scenarios—that is, whether the model can correctly select tools, fill in parameters, parse returned results, and advance the task accordingly. This type of benchmark is fundamentally different from traditional code generation or question-answering accuracy evaluations: it examines the reliability of "orchestrating external capabilities," not the model's own knowledge or reasoning depth. So a model can absolutely lead on MCP-Atlas while lagging on end-to-end command-line tasks like Terminal-Bench or software engineering benchmarks like DeepSWE—the former rewards stable scheduling, the latter rewards long-horizon planning and code correctness. Intelligence Index is a composite intelligence score introduced by Artificial Analysis, aggregating multiple categories of reasoning and knowledge tasks, where higher values indicate stronger general capability. Only by looking at these together can you judge whether a model is suited to agent orchestration or to independently completing complex programming.

License: Read It Carefully Before You Build

It uses the Muse Model License, not Apache or MIT. The actual terms:

• Derivative works must be labeled "Built with Muse Spark Open"
• If you provide model output as a service and annual revenue exceeds $20 million, you need a separate written agreement with Meta
• Internal use and powering your own proprietary products are unrestricted

For startups, it's fine. For hyperscale cloud providers or large API resellers, this clause is exactly the crux. Call it "open-weight," not "open source." The HN community is right on the labeling, though the scope of the restriction is narrower than the outrage suggests.

What It Takes to Run It

This is not a model that runs on a laptop.

• NVFP4 checkpoint: minimum approximately 700 GB VRAM, equivalent to four Blackwell Ultras or eight H200s
• BF16: approximately 2 TB VRAM
• 2-bit GGUF (Unsloth dynamic quantization): roughly 300 GB combined memory/VRAM
• Meta's own recommendation: two M5 Ultra Mac Studios, each with 512 GB unified memory

Deploy with vLLM on 4 GPUs:

vllm serve meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
    --tensor-parallel-size 4 --enable-expert-parallel

Or llama.cpp:

llama serve -hf ggml-org/Muse-Spark-Open-816B-A42B-GGUF:Q4_K_S

SGLang, TensorRT-LLM, MLX, and Transformers are also supported.

Don't want to buy hardware yourself? Together AI, Fireworks, Baseten, Modal, Groq, Nebius, and OpenRouter all host it. Weights are available on Hugging Face, SageMaker, Google Cloud Model Garden, and Microsoft Foundry. None of the sources I checked published pricing, so check each endpoint directly.

Tensor parallelism and expert parallelism are the two main partitioning paths for deploying hundred-billion-scale MoE models. Tensor parallelism splits individual weight matrices by row or column across multiple GPUs, and each layer's computation requires inter-GPU communication to aggregate results—suitable for dense parts. Expert parallelism, by contrast, assigns different experts to different GPUs; after routing, each token only accesses the card holding its target expert during the forward pass, so communication volume grows with the number of activated experts rather than total parameter count, making it especially efficient for MoE. The --tensor-parallel-size 4 in the vLLM command means the dense layers use 4-card tensor parallelism, while --enable-expert-parallel additionally enables expert-dimension partitioning. The two can be stacked, spreading 816B weights across 4 GPUs while keeping communication pressure within an acceptable range. Which combination to choose depends on cluster interconnect bandwidth and the VRAM/compute ratio.

My Take

1. This is first and foremost an agent model. The MCP-Atlas lead is the main point. If you're building tool-call-heavy agents and want a non-Chinese open-weight option, this is now the one most worth evaluating.
2. 42B activated parameters is the lever. You pay VRAM costs for 816B but only compute costs for 42B. On a suitably sized cluster, throughput per dollar could be good. Test it, don't assume.
3. The "US" framing says it all. Meta is no longer claiming global leadership, but leadership among US open models. That's a genuine concession about where frontier open-weight work is happening.
4. Don't trust the tables, including mine. All the numbers above are vendor-reported or secondhand. Before migrating anything, build an evaluation from your own 50 tasks and run Muse Spark Open, GLM 5.3, and Kimi K3 through it.

Should You Care?

• Building tool-call-heavy agents with GPUs or a hosted endpoint: Yes, evaluate this week.
• Hobbyist with only one consumer GPU: No. Even 2-bit quantization needs about 300 GB.
• Selling model output services at scale: Talk to a lawyer first.

Sources: Meta Research Blog, Hacker News discussion, Developers Digest analysis, PyTorch Blog.

One-line Summary

Meta releases Muse Spark Open, an 816B open-weight model with 42B activated parameters, leading on tool calling but lagging on coding, with an extremely high deployment barrier.

Paragraph Summary

Meta released the Muse Spark Open model weights on October 15: 816B total parameters, 42B activated, MoE architecture, 1 million token context, and native multimodality, targeting coding and agentic tasks. It leads tool-calling benchmark MCP-Atlas at 89.2, but trails Chinese open models like Kimi K3 and GLM 5.3 on Terminal-Bench, DeepSWE, and the Intelligence Index. The license is the Muse Model License; model output services earning over $20 million annually require a separate agreement with Meta, so this is open-weight rather than open source. The deployment barrier is extremely high: NVFP4 needs about 700GB VRAM, and 2-bit quantization still needs about 300GB. Meta calls it "the strongest US open-weight model," and that qualifier reflects a shift in where the open-weight frontier lies. The author recommends evaluating with your own task set before migrating.