On Thursday, Meta released the weights of Muse Spark Open, an 816 billion parameter sparse mixture-of-experts model that activates roughly 42 billion parameters per token. It takes text, image, video and audio as input, holds a one million token context window, and ships with day-one support in SGLang, vLLM, TensorRT-LLM, Hugging Face Transformers, MLX, llama.cpp and Unsloth. Meta's AI chief Alexandr Wang called it "the most capable US open-weight model to date" on X, and The Guardian's report frames the launch as Meta's bid to catch Chinese open-weight leaders like Alibaba's Qwen, Moonshot's Kimi K3 and Z.ai's GLM.
Those are the press-release facts. The more interesting story is in the deployment details Meta published alongside them, because together they reveal exactly what kind of bet this is: a model engineered so that the compute per token looks like a 42B model, while the memory footprint stays stubbornly, unavoidably 816B.
Context: What Actually Shipped
Muse Spark Open is derived from the closed Muse Spark model Meta released in August, with additional safety post-training aimed at making it robust as a standalone model without system guardrails. That lineage matters: this is not a purpose-built distilled open model, it is a frontier-adjacent model opened up, which is the pattern Meta returned to after a stretch of closed releases (the same week its hosted pricing appeared on OpenRouter at $1.25 per million input tokens and $4.25 per million output tokens).
The launch surface is unusually wide for a first-day release:
| Layer | What shipped on day one |
|---|---|
| Checkpoints | BF16 and NVFP4 from Meta; FP8 and MXFP4 from AMD; INT4 and MXFP4 tuned for Intel Crescent Island; GGUF quants from Unsloth |
| Runtimes | SGLang, vLLM, TensorRT-LLM, Transformers, MLX, llama.cpp, Unsloth |
| Hardware verified | NVIDIA, AMD, Intel, Apple silicon |
| Speculative decoding | DFlash V2 draft model (SGLang), DSpark draft model (vLLM) |
| Post training | TorchTitan, SGLang plus Miles, NVIDIA NeMo AutoModel, Hugging Face TRL, managed fine-tuning at Fireworks AI and Together AI |
| Hosted access | Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter, Together AI |
| Model catalogs | Amazon SageMaker AI, Google Cloud Model Garden, Microsoft Foundry Models |
The demo everyone will remember is the Apple one: two Mac Studios with M5 Ultra chips and 512GB of unified memory each, or four machines with 256GB each, connected over Thunderbolt 5 with RDMA, running the NVFP4 checkpoint through MLX tensor parallelism. Meta's framing is "the most capable US open-weight model running on the desktop." Whether that phrasing survives contact with real workloads is a memory question, so let's do the memory math.
The Memory Math: Why 42B Active Still Needs a Terabyte
This is the part an 816B headline hides. A sparse MoE trades compute for capacity: you do less arithmetic per token, but every expert's weights must still sit somewhere addressable, because any token might route to any expert.
Here is the arithmetic, with each assumption labeled:
| Quantity | Estimate | Basis |
|---|---|---|
| BF16 weights | ~1.63 TB | 816B params x 2 bytes, arithmetic |
| BF16 requirement per Meta's model card | 2 TB | Meta's published figure, includes activation and KV headroom |
| NVFP4 weights | ~0.41 to 0.45 TB | 4 bits per weight plus block scale overhead, roughly 0.5 to 0.55 bytes per param (assumption) |
| NVFP4 requirement per Meta's model card | at least 700 GB | Meta's published figure, via Flavio Copes' model-card breakdown |
| Active density | 42B / 816B = 5.1% | Meta's stated A42B configuration |
| Forward FLOPs per token | ~84 GFLOPs | $2 \times 42 \times 10^9$, the standard linear-layer estimate, attention excluded |
| Same model if dense | ~1.63 TFLOPs per token | $2 \times 816 \times 10^9$, roughly 19x the sparse cost |
Two observations fall out. First, Meta's own 700GB floor for the NVFP4 checkpoint is well above the ~430GB the weights alone should occupy, which tells you the remaining several hundred gigabytes are budgeted for KV cache and activations. For an agentic model marketed with a 1M-token window, that budget is the whole game: at full context, cache, not weights, is what eats a machine. Second, the active-to-total ratio of 5.1% is aggressive. It means decode-time arithmetic is cheap in a way that batch-1 latency will not reflect, because single-token decoding is bandwidth-bound, not FLOP-bound.
Run the bandwidth number with one stated assumption. At batch size 1 in NVFP4, each generated token must stream roughly 21GB of active expert weights (42B params at about 0.5 bytes, assumption again). On memory bandwidth in the sub-1TB/s class, which is the right order of magnitude for Apple unified memory and mid-range datacenter GPUs (assumption, since Meta publishes no tokens-per-second figures), that caps raw generation in the dozens of tokens per second before KV-cache reads and multi-machine communication are even counted. This is precisely why Meta shipped two speculative decoding draft paths on day one: with DFlash or DSpark verifying several draft tokens per forward pass, effective throughput scales with the accept rate, not with the 21GB-per-token floor. The draft models are not an optimization nicety here, they are load-bearing.
The tensor-parallelism choice in the MLX path is also worth reading carefully. Meta splits every layer across both Mac Studios so each machine holds half the weights and does half the computation per token, exchanging only intermediate results over Thunderbolt 5 RDMA. That works for MoE because expert outputs are summed through small activations, but it makes the interconnect part of the critical path on every single token. Two machines "working as one" is true up to the point where a Thunderbolt hop becomes visible in per-token latency, and Meta publishes nothing that lets you locate that point.
Our Read: The License Clause Is the Product Strategy
The benchmark table on Meta's model page stacks Muse Spark Open against Inkling, Nemotron 3 Ultra, Mistral Large 4, Qwen3.8-2.4T-A95B, GLM 5.3 and Kimi K3 across agentic suites like JobBench, MCP-Atlas, Terminal-Bench 2.1 and DeepSWE 1.1. Two details on that table deserve more attention than the scores: the harness footnote says scores reflect the "best available" configuration per model, self-reported, and several competitor cells simply read "Not supported." A comparison where your own model is run at its best setting and rivals are marked unsupported wherever their tool interfaces differ is a marketing table, not an evaluation. We covered exactly this failure mode in Reading AI Benchmark Claims Like a Skeptic, and nothing here changes the prescription: wait for independent runs of the agentic suites before believing any "outperforms" claim in Thursday's coverage.
The genuinely novel artifact is the Muse Model License. As documented in Copes' reading of the release, it permits modification, fine-tuning and commercial use, with two strings attached. Products must display a "Built with Muse Spark Open" notice. And any licensee (with affiliates) that exceeds $20 million in aggregate gross revenue over any consecutive twelve-month period must notify Meta and sign a separate written agreement before offering Muse Spark Open, or its derivatives, as a Model-as-a-Service business. Internal use, research, and using the model to power features inside your own non-MaaS product are explicitly excluded from that clause.
Compare that to the Llama playbook, where the gating threshold was a usage-count cliff, and the strategy reads clearly. Meta is not selling Muse Spark Open to API resellers, it is selling it as the default substrate for enterprise internal deployment and fine-tuning, where the $20M carve-out means a bank running the model privately on its own chips never touches Meta's legal department, while a startup planning to become the next inference marketplace cannot do so on Meta's weights without a contract. The wide day-one runtime matrix, the AMD and Intel quantized checkpoints, the managed fine-tuning partners: all of it points at install base inside other companies' infrastructure, monetized through Meta Model API at the top of the funnel and through hardware goodwill everywhere else.
There is a second economic tell. Hosted pricing of $1.25 in and $4.25 out per million tokens puts Muse Spark Open in the value tier, and for a coding agent that re-reads large files at every step, input tokens dominate the bill. An agent loop that pulls a 200K-token codebase context per attempt pays $0.25 per attempt in input cost before generating a single character. Self-hosting on hardware you already own flips that from a metered cost to a fixed one, and for teams whose whole workload is long-context agentic coding, that is the actual buying argument, more than any benchmark row. Meta knows its infrastructure story well, it is the same cost-per-token logic we traced in Meta's MTIA 450 Arke bet.
Outlook
Three things to watch over the next month. First, independent agentic evaluations on Terminal-Bench 2.1 and DeepSWE 1.1 with identical harnesses for all competitors; only then does the "rivals Chinese models" framing from Meta and its coverage become testable. Second, real-world throughput on the two-Mac-Studio setup, because the architecture math says generation speed will live or die on speculative decoding accept rates and Thunderbolt latency, and Meta has published neither. Third, whether the $20M MaaS clause steers the ecosystem: if large fine-tuners and internal deployments adopt the weights quickly while no new API reseller surfaces, that confirms Meta aimed at the enterprise floor, not the open-source crown.
One honest caveat to close on, in the same spirit we applied to DeepSeek V4's open-weight release: the weights are free, the license is not permissive, and the 700GB floor is not a desktop. Muse Spark Open is a serious piece of engineering with a specific commercial shape. Read the license and do the memory math before treating it as an Llama successor.