Run Muse Spark Open Locally: The Real Hardware Bill

The headline on Meta's open-weight release last week was that you can run Muse Spark Open locally, on a Mac. That is true in the same way it is true that you can run a datacentre in your garage. The official checkpoint does not fit on one machine, and Meta's own deployment page says so.

Here is what the hardware actually costs, what the hosted API costs instead, and which of those two numbers is relevant to you.

What Meta shipped on 15 October

Meta released the weights for Muse Spark Open on 15 October 2026, describing it in its research announcement as the most capable US open-weight model to date. It is the opened version of Muse Spark, the closed flagship Meta shipped in April, with additional safety post-training applied before release.

The specification, per the model card on Hugging Face:

• 816 billion total parameters, with roughly 42 billion active per token.
• A sparse mixture-of-experts transformer — 256 experts per MoE layer, 8 routed per token.
• 62 layers, hidden dimension 8192, 128 query heads and 16 key-value heads.
• A context window of 1,048,576 tokens.
• Text, image, video and audio in; text out only.
• Built for coding and agentic work — long-horizon tasks and multi-step reasoning.

That 42B active figure is the one people misread. Sparse activation keeps the compute per token near a 42B dense model, but every expert still has to be resident in memory, because routing decides which eight you need only once the token arrives. You pay for 816B of weights and get 42B of arithmetic.

What it takes to run Muse Spark Open locally

This is where the headline and the documentation part company.

Meta's own guidance

Meta's deployment documentation puts the NVFP4 checkpoint at about 530GB — roughly a third the size of the BF16 weights, with only the experts quantized. It serves on four Blackwell Ultra GPUs or eight H200s.

The Mac configuration

For Apple silicon, Meta is explicit that the model does not fit in one Mac's memory. The supported arrangements are two M5 Ultra Mac Studios with 512GB of unified memory each, or four with 256GB each. CNBC reports that this came out of a collaboration between Apple and Meta, and that customers will be able to pair between two and four Mac Studios to run it. Representatives from both companies declined to say whether it is the start of a broader relationship.

The memory floor

TechCrunch, citing Engadget, reports a requirement of at least 1TB of RAM. That figure is best read as the combined memory of the cluster rather than a single machine's spec, and it is the honest number: 530GB of weights is the floor before the KV cache, and a million-token context window is not free.

What that costs

Per CNBC, a Mac Studio with the M5 Ultra chip and 256GB of memory starts at $10,799, and the 512GB configuration ships later this month. So the cheapest supported Apple-silicon arrangement — two machines — starts somewhere north of $21,000, before the larger memory tier that the two-machine setup actually requires.

Community quantizations

Smaller 2-, 3- and 4-bit builds are already appearing on Hugging Face from the usual quantization community, targeting a single large-memory machine instead of a cluster. They are a legitimate way in, and they are also an accuracy trade the uploaders are upfront about — a 2-bit quantization of a frontier model is not the model Meta benchmarked. Treat the memory figures on those cards as the uploaders' own estimates, usually measured on previous-generation hardware, not as Meta's supported configuration.

The hosted API is the answer for almost everyone

Weights are on Hugging Face, Amazon SageMaker AI, Google Cloud Model Garden and Microsoft Foundry. If you want tokens rather than a server, the model is served by Baseten, Fireworks, Together, Nebius, Modal and OpenRouter.

The striking thing is how tightly the price has converged. Fireworks, Together, Baseten, OpenRouter and Meta's own Model API all list the same rate:

• $1.25 per million input tokens
• $4.25 per million output tokens
• $0.15 per million cached input tokens

For context, that puts it in roughly the same bracket as the mid-tier closed models, well above a small model like Claude Haiku 5.5 at $0.10 per million input, and the output price is where it bites. A 3.4x input-to-output ratio punishes exactly the long-horizon agentic work the model is built for.

Contributor mode and what it costs you instead

Meta's first-party API also offers a contributor tier at $0.10 input and $0.20 output per million — about a twelfth the standard input price and a twentieth the output. The trade is stated plainly in the pricing docs: prompts and outputs may be used to improve Meta's products. That is a fine deal for a side project and an obvious non-starter for anything carrying customer data or unreleased code.

"Open" here means weights, not open source

Meta is careful with the wording and it is worth repeating, because a lot of the coverage was not. The weights ship under the Muse Model License, which permits limited commercial use. It does not mean the training data or development details are public, it does not mean every service running the model is operated by Meta, and it is not interchangeable with an OSI-approved open-source license.

Practically: read the license before you build a product on it, the same way you would read any other dependency's terms. "Open-weight" buys you the right to self-host, inspect activations, fine-tune and run without a vendor in the request path. It does not buy you the freedoms the phrase "open source" implies.

The benchmark claim nobody has checked

Meta calls this the most capable US open-weight model to date. As of writing, that claim has not been independently verified, and Meta has said a fuller evaluation report is still to come. The model card does not carry the kind of head-to-head table that would settle it.

That is not an accusation — it is the normal state of a release week, and it is the reason we try not to write the scoreboard post on day three. We did the same thing when we compared Gemini 4 Argon against GPT-6.1 Sol: the interesting question was what each lab was betting on, not whose bar chart was taller. Wait for third-party evals before you move a workload.

What we would use it for at Taqari

We run a platform where candidates write code and talk to an AI interviewer, so a long-context, agentic, open-weight model is genuinely interesting to us — and we would still not self-host this one.

The reason is shape of load, not capability. Interview traffic is spiky and latency-sensitive: nothing for an hour, then forty concurrent sessions, each one with a person sitting there waiting for a response. A $21,000 cluster is the worst possible fit for that curve. It is idle most of the day and saturated exactly when you need it to scale, and scaling it means buying another one.

What open weights do change for us is the part of the stack where data residency is the constraint rather than cost. If an enterprise customer requires that transcripts never leave their infrastructure, having a capable model that can be deployed inside their boundary is the difference between a deal and no deal. That is the real argument for open weights, and it has very little to do with saving money on tokens.

The scoring path stays where it is. We wrote about keeping LLM-as-judge scores reproducible, and score stability depends on a model whose behaviour you can pin across months. A self-hosted checkpoint is actually good at that — it does not change under you — but only once there are third-party evals worth pinning to.

What this changes if you are preparing for interviews

Two things, and neither is "learn to fine-tune".

The first is that deployment economics has quietly become an interview topic. "Should we self-host an open-weight model?" is now a real architecture question with a real answer, and the answer is usually no for reasons that have nothing to do with the model — utilisation, spiky traffic, who carries the pager. Being able to walk through that trade, out loud, with numbers, is a differentiator.

The second is licensing literacy. An engineer who reads "open" and assumes MIT is an engineer who creates a legal problem. Knowing the difference between open-weight and open-source, and being willing to say "I'd need to read the license first", reads as senior.

Both of these are judgement questions rather than recall questions, which means they are hard to prepare for by reading. If you want to practise reasoning through tradeoffs like these under time pressure, that is what Taqari's free AI mock interviews are built for.