Muse Spark Open: Meta's 816B Model on Two Macs

Muse Spark Open is Meta's first open-weights release in the Muse family. Meta calls it "the most capable US open-weight model to date" and says it is natively multimodal, with a focus on coding and agentic work: long-horizon tasks, complex software engineering and multi-step reasoning. The weights went public on the day of the announcement, 15 October 2026.

• Size: 816B total parameters, 42B active per token, a Mixture-of-Experts design, with a 1M token context window.
• Formats: native BF16 weights (over 1.6TB) plus an NVFP4 4-bit version of about 493GB.
• Apple Silicon: optimised for Mac Studio with M5 Ultra using MLX; two machines hold the whole model in roughly a terabyte of unified memory.
• Measured speed: 15.74, 24.99 and 36.73 tokens per second for two-node pipeline, two-node tensor and four-node tensor setups, according to Apple.
• Licence: the Muse Model License, with limited commercial terms rather than a standard open-source licence.
• Gap: the announcement's benchmark section carried no numeric scores in the text we could retrieve, and Meta says a full safety evaluation report is "available soon".

If you have followed the open-weights race through our coverage of NVIDIA Nemotron 3.5 Super VL and Qwen 3.8 27B, Muse Spark Open sits at the very top of the size range: far larger than either, and the first to be demonstrated on consumer-class desktop hardware at this scale.

Meta's Muse line began as a deliberately closed family. Our review of Meta Muse Spark 1.2 and Muse Code noted that the model and the terminal coding agent were entirely proprietary, with no downloadable weights, a striking reversal for the company that built Llama into one of the most downloaded open model families. Muse Spark Open reverses that reversal, at least in part.

Meta's announcement does not spell out the relationship between Muse Spark Open and earlier Muse releases. The artwork on the announcement page is filed under the name "muse-spark-1-2-open-weights", which hints at a link to the 1.2 generation, but Meta's text does not confirm it, so we treat it as a hint rather than a fact. What the text does say is that releasing open-weight models is "part of how we bring the benefits of personal superintelligence to everyone".

The wider Muse family now also includes Muse Wonder, covered separately, and a second Hugging Face collection called Muse Glimmer, which we have reviewed in our Muse Glimmer guide. For readers new to the line, the open model is the one to watch if you care about hosting your own weights.

Muse Spark Open is a Mixture-of-Experts model. In an MoE, the network contains many specialist sub-networks and a router that picks a small subset for every token. That is why the headline figures are two numbers: 816 billion parameters must be stored, but only 42 billion are used to produce each token. That is about 5% of the total. Memory capacity therefore sets the hardware floor, while memory bandwidth and the active parameter count set the speed.

BF16 versus NVFP4

The native precision is BF16, which stores each parameter in two bytes. Apple's research post puts the BF16 footprint at over 1.6TB, which is simply 816 billion multiplied by two bytes. That does not fit on any single Mac and does not fit on two. Apple's evaluation therefore uses NVFP4, a 4-bit floating-point format, which brings the weights down to roughly 493GB. Hugging Face lists both: a BF16 repository and an NVFP4 repository, the latter at roughly 484 on the site's size column against 822 for the full-precision one.

Quantisation always trades some quality for size. Neither Meta nor Apple, in the text we could retrieve, publishes a side-by-side quality comparison of the two formats. That matters: every speed figure below is for the 4-bit version, and the quality you get on your own prompts may differ from the full-precision model that Meta's own tests describe.

A million tokens of context

Meta lists a 1M token context window. Long context costs memory for the key-value cache on top of the weights, which is why Apple's tables show time to first token climbing sharply at long prompts. Apple's tests used 65,536 tokens at most, a long way short of the full million, so the headline window is a capability claim rather than something the Mac figures demonstrate.

The most unusual part of this release is the hardware story. Meta's page says the model was optimised to run on Mac Studio with M5 Ultra using the latest MLX, and that "two machines can hold an entire model". The reasoning is straightforward. Apple's unified memory lets the integrated GPU address up to 512GB per Mac Studio, so two machines provide about a terabyte. The M5 Ultra has 1.2TB/s of memory bandwidth, which Meta describes as fast enough to read the small slice each token needs.

Apple's own write-up gives the plumbing. The machines talk over RDMA, remote direct memory access, running on Thunderbolt 5, which macOS 26.2 enables. Two machines are joined with two Thunderbolt cables for double the bandwidth; four machines are connected as a Thunderbolt mesh. Apple's post lists the MLX requirements as version 0.30.1 or later, which provides the jaccl communication backend, with jobs launched through mlx.launch from a hostfile and the MLX_METAL_FAST_SYNCH=1 environment variable set to reduce CPU-to-GPU synchronisation overhead.

For serving, mlx_lm.server can expose a local OpenAI-compatible endpoint, which means tools that speak the OpenAI API, including OpenCode, can use the cluster as a local coding backend. Apple also includes a prior-generation comparison: against the M3 Ultra, the M5 Ultra gives up to 4.6 times faster time to first token and 1.6 times faster decode, thanks mainly to its higher memory bandwidth (1.2TB/s versus 819GB/s).

The power draw is modest for the capability. Apple measured a peak of about 300W for an M5 Ultra running Qwen 3.8 at a 65,536-token context, against about 200W for an M3 Ultra. That figure is for the smaller Qwen model on one machine, not for the 816B cluster, so do not multiply it blindly, but it does give a sense of the scale: a desk-side box, not a data-centre rack.

Apple's post compares three models: Muse Spark Open (816B total, 42B active, evaluated at NVFP4), Mistral Medium 3.5 (128B dense, FP8) and Qwen 3.8 (27B dense, BF16). Here are the Muse Spark Open results as Apple reports them.

A few readings are worth drawing out. First, 25 tokens per second is a comfortable reading speed and quick enough for interactive coding assistance, but it is well below what a hosted API from Groq or Together AI will deliver. Second, adding machines helps: going from two to four nodes lifts decode by about 47% and cuts time to first token from 8.2 to 4.8 seconds. Third, the model fits an unusual niche. The smaller dense Qwen 3.8 decodes at 19.69 tokens per second on one M5 Ultra, so the 816B MoE on two machines at roughly 25 is not slower than a 27B dense model on one. That is the MoE advantage in practice: only 42 billion parameters are read per token.

Two caveats. Apple's figure caption cites "over 36 tokens per second" at an 8,192-token context for four machines, and the table's context sizes are not entirely clear from the page we retrieved, so do not assume the table holds at long contexts. And these are single-stream numbers; Apple's post does not claim concurrent multi-user throughput, which is the metric that matters if you want to serve a team.

The gap between 15.74 and 24.99 tokens per second on the same two machines comes down to how the model is split.

Pipeline parallelism: split by depth

The first Mac runs the first half of the layers and hands its output to the second Mac, which runs the rest. Each token still travels through every layer in sequence, so decode speed stays close to that of one machine. Where pipelining helps is prefill: context can be processed in chunks (8,192 tokens in Apple's benchmark) so both machines work at once. Apple reports roughly 1.8 times faster prefill than a single node at 65,536 tokens.

Tensor parallelism: split by width

Here every machine holds a slice of every layer, so both work on every token. The cost is communication: many small exchanges per token and per layer, which is why low-latency RDMA over Thunderbolt 5 is essential. Apple says tensor parallelism scales better for dense models, and that decode for Muse Spark Open is not hurt at large contexts. For interactive use, tensor parallelism is the choice; the cables and the macOS 26.2 requirement are the price.

Apple also tested the cable count. On four M5 Ultras at 65,536 tokens, using two cables per link instead of one cut time to first token from about 50.5 seconds to 40.6. That is a sobering reminder that long prompts are slow on this hardware: even in the best configuration, a 65,000-token prompt takes tens of seconds to start answering.

Meta tested "a range of agentic workflows running entirely on-device" using Muse Code powered by Muse Spark Open. Two examples are named. First, shipping real iOS changes to Ice Cubes, an open-source Mastodon client, covering bug fixes, new features and a full build. Second, driving DaVinci Resolve end to end, with the model reviewing footage frame by frame to find the strongest moments and crop them vertically for short-form video.

Both are good demonstrations of why multimodality and long context matter together. The iOS task is a long-horizon engineering job with a compiler in the loop; the video task needs the model to look at frames, not read text. Equally, both are demonstrations rather than measurements. Meta does not give success rates, how many attempts were needed, or how long the runs took, so they show what is possible and not what is typical. For the coding agent itself, our Muse Code review covers its terminal-benchmark results and pricing model.

If your interest is agent frameworks, note that the local OpenAI-compatible endpoint means any harness that can target a custom base URL can drive the cluster. Our guide to OpenMuse, an open-source personal agent, is one place to start.

Meta lists a broad rollout on day one:

• Weights: Hugging Face (collection "meta-models/muse-spark-open", with BF16 and NVFP4 repositories), Amazon SageMaker AI, Google Cloud Model Garden and Microsoft Foundry Models.
• Hosted APIs: Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter and Together AI.
• Inference engines: SGLang, vLLM, TensorRT-LLM, Hugging Face Transformers, Apple MLX, llama.cpp and Unsloth, with optimisations for AMD, Apple, Intel and NVIDIA hardware.
• Fine-tuning: PyTorch, with TorchTitan suggested.

One engineering detail stands out: the open-weight release ships with custom, auto-tunable Helion GPU kernels in SGLang, which Meta says deliver 1.03 to 3.95 times kernel-level speedups on NVIDIA and AMD GPUs and a 3% end-to-end speedup on AMD's MI350. The kernel-level range is wide and the end-to-end gain small, so read it as a sign of effort on non-NVIDIA hardware, not a headline performance claim.

Practically, most teams will never touch a Mac cluster. The hosted route through OpenRouter, Together AI or Fireworks lets you try the model at per-token prices without buying hardware, and we recommend doing that first to find out whether the model suits your workload before you consider self-hosting.

Open weights change the safety calculus, because once weights are public the developer cannot revoke access or patch behaviour. Meta says Muse Spark Open received additional safety post-training for that reason, and that it was evaluated under the Meta Superintelligence Scaling Framework, which covers the most severe risks. According to Meta, the model met the framework's release thresholds. Detailed results are said to be in the Hugging Face model card, and a full evaluation report is "available soon".

That is a statement, not yet evidence. We could not retrieve numeric cyber, biological or autonomy results from the pages we reviewed, and the full report had not been published when this article was written. Compare that with closed frontier releases from Anthropic, which publish system cards with specific evaluation numbers; our reviews of Claude Opus 5.5 show what that disclosure looks like. Until Meta's report lands, the responsible position is to take the claim as stated and verify what you can.

For anyone deploying an agent on a local cluster, the usual agent risks still apply. A model that can run a build, edit files and drive desktop applications can be steered by hostile content in the files or web pages it reads. Run local agents in a sandbox or a separate user account, give them the narrowest file access they need and review what they do before it ships.

Meta's announcement has a "Key Benchmarks" section and links to an evaluation methodology report. In the text of the page that we could retrieve, the section contained no numeric scores, and the Hugging Face collection page we reviewed gave no benchmark results, licence or context length either. Rather than quote figures from social media posts or video descriptions, we are not publishing any benchmark numbers for the model in this article.

That matters for how you read the headline claim. "The most capable US open-weight model to date" is Meta's own description, and "US" is an important qualifier: it implicitly excludes Chinese open-weights models such as those in Alibaba's Qwen line and Zhipu's GLM 5.3, which compete directly with it. Whether Muse Spark Open leads the global open-weights field is a question for independent evaluations, which will take days or weeks to arrive.

We will update this page when Meta's methodology report and independent results are available. In the meantime, a sensible test plan is to run 20 to 30 of your own real tasks through a hosted endpoint, score them blind against whichever model you use now, and only then decide whether local hosting is worth the hardware.

The weights are released under the Muse Model License, which Meta describes as having limited commercial terms that allow many developers to use the model free of charge. The wording "limited" and "many" suggests thresholds or restrictions, as with earlier Llama licences, which for example required large companies to seek separate permission. We have not been able to read the full licence text, so check it before shipping a commercial product, and do not assume it behaves like Apache 2.0 or MIT. It is open weights, not open source in the OSI sense.

On hardware cost: Apple does not publish prices in the research post, and we are not going to guess at M5 Ultra Mac Studio pricing. What the post does establish is the shape of the bill. You need machines with 512GB of unified memory each for the two-node setup, plus Thunderbolt 5 cables, and the capital cost is a one-off rather than a per-token charge. For occasional use, hosted APIs will almost certainly be cheaper; for heavy, private, always-on agent workloads, local hardware can win. Work out your own break-even using the per-million-token price of whichever hosted provider you would otherwise use.

• No verifiable benchmarks yet: Meta's numeric results and methodology report were not retrievable for this review.
• Safety report pending: the full evaluation is "available soon", so the safety claim is currently unchecked.
• Quantised results only: Apple's speeds are for 4-bit NVFP4, and quality versus BF16 is unpublished.
• Slow long prompts: a 65,536-token prompt on four M5 Ultras still takes about 40 seconds to first token with two cables per link.
• Heavy kit: two machines with 512GB each, Thunderbolt 5 and macOS 26.2 are prerequisites for the local route.
• Custom licence: not a standard open-source licence; read it first.
• Demos, not metrics: the Ice Cubes and DaVinci Resolve runs have no published success rates.

Within open weights, Muse Spark Open is a size outlier. Nemotron 3.5 Super VL has 120B total and 12B active parameters and needs four H100s or two GB200s; Qwen 3.8 27B runs on a single high-memory machine. Muse Spark Open is roughly seven times the total size of Nemotron and 30 times that of Qwen, with 42B active parameters, about 3.5 times Nemotron's active count. More parameters should buy more capability, but only independent tests will say how much.

Against closed frontier models such as Claude Opus 5.5, the trade is the familiar one: privacy, cost control and customisation against capability and managed safety. Our guide to the best AI models tracks where each sits. Against Apple's smaller dense options on the same Macs, Muse Spark Open's selling point is that the MoE design makes an 816B model no slower, in tokens per second, than a 27B dense one.

For the wider local-AI picture, including smaller Apple hardware, see our piece on the M6 Mac mini and local AI.

Worth trying if you handle sensitive code or data that cannot leave your premises; if you run heavy agent workloads where per-token pricing would be painful; if you already own or can budget for high-memory Macs; or if you are a researcher who wants to inspect, fine-tune or probe a very large open model.

Wait if you need published benchmark and safety numbers before adopting a model, if your prompts are long and latency-sensitive, if you need concurrent multi-user serving on the Mac route, or if your company's size may trigger limits in the Muse Model License. In every case, start with a hosted endpoint, which costs nothing in hardware and tells you quickly whether the model earns its place.

Muse Spark Open matters for what it demonstrates more than for what it scores. An 816B-parameter model, with 42B active, a million-token window, broad day-one distribution and a credible desktop-class local route is a genuine step: Apple's measured 25 to 37 tokens per second turns "possible in principle" into "possible this week" for anyone with the budget.

What is missing is the evidence that normally accompanies a frontier-class claim: numeric benchmarks in text, a published safety report, and quantised-versus-full-precision quality. Treat the release as promising, test it on your own work through a hosted API, and revisit this guide as the independent results arrive.