Running Muse Spark Open on Two Mac Studios: What 816B Parameters Demand

Meta says its new open-weight model can run on two Mac Studios. That claim is worth taking seriously enough to cost out, because the answer changes a real purchase decision: whether a data-sensitive team buys roughly a terabyte of desktop unified memory, rents GPU capacity, or walks away to a smaller model. The short version of the finding is this. The 816B total parameter count is a storage problem, not a speed problem. Per-token speed tracks the 42B active slice and the 1.2 TB/s of memory bandwidth Meta quotes for each M5 Ultra chip, while the 816B total is what your machines must physically hold. Two 512GB Mac Studios meet that holding requirement only for the weights themselves, and nothing in the evidence supports exercising the advertised 1M-token context on that hardware. Every Muse Spark Open number in this article is vendor-reported from Meta’s announcement, accessed 2026-10-15, and no independent replication appears in any source cited here.

The sizing variable: 42B active per token, 816B total in memory

Muse Spark Open is, per Meta’s announcement, “a natively multimodal model with 816B total parameters (42B active) and a 1M-token context window,” released as open weights. The mixture-of-experts architecture is the entire reason a desktop deployment is even a conversation. Each generated token routes through roughly 42B parameters of compute, so the bandwidth-bound work per token resembles serving a 42B dense model. But all 816B parameters have to sit in memory, because any expert can be selected on any token.

That split inverts the intuition most buyers bring from dense models. With a dense model, the parameter count tells you both the memory bill and the speed. With an MoE, you budget memory against the total and throughput against the active slice. Confuse the two and you either overbuy bandwidth you cannot use or underbuy memory and never load the model at all.

This is not a Meta-specific curiosity. The FORGE paper (arXiv:2610.16890) reports that MoE weight footprints across recent models “range from 31GB (Qwen3-30B (Qwen Team, 2025)) to 742GB (GLM-5 (GLM-5 Team, 2026))” and that “all but the smallest exceed the 80GB HBM of a single H100.” An 816B-parameter model sits at the far end of that distribution. Whatever you think of Meta’s desktop claim, the model needs either pooled unified memory, several GPUs, or aggressive quantization. There is no single-card path at full precision.

What two 512GB Mac Studios actually hold

Meta’s core hardware claim, quoted from the announcement:

“Apple’s unified memory architecture lets the M5 Ultra’s integrated GPU use up to 512 GB per Mac Studio, so two machines can hold an entire model. And the chip’s 1.2 TB/s of memory bandwidth is fast enough to read the small slice each token needs.”

The arithmetic, as inference from those vendor figures: two machines with up to 512GB each give about 1TB of combined unified memory. At FP8 precision, 816B parameters occupy roughly 816GB before overhead, so the weights fit with modest headroom. That headroom is where the caveats live. It must also absorb the KV cache for whatever context you actually run, plus framework overhead, and the per-machine 512GB figure is a ceiling on what the GPU can address, not a guarantee of what remains after the operating system and runtime take their share.

The larger gap is mechanical. Meta says the model “run[s] on your desktop using two Apple M5 Ultra Mac Studios with the latest MLX framework,” but the announcement does not say how the model is sharded across the two machines, what interconnect carries the cross-machine traffic, or what latency that adds per token. Expert routing in an MoE means tokens regularly need weights that live on the other machine. Whether the two-box setup performs like one pool of memory or like two machines passing messages over a desk cable is exactly the kind of detail that determines whether the claim survives contact with a real workload, and it is unstated. I would treat “two Mac Studios” as a floor for holding the weights, not as a verified serving configuration, until Meta or an independent party publishes the sharding and networking specifics.

Serving path A: MLX on Apple Silicon

The independent evidence on Apple Silicon serving comes from a comparative study of MLX, MLC-LLM, Ollama, llama.cpp and PyTorch MPS (arXiv:2511.05502). Two study-reported findings matter here. First, among local runtimes on Apple Silicon, MLX achieved the highest sustained generation throughput, while MLC-LLM delivered consistently lower time-to-first-token for moderate prompt sizes. That supports Meta’s choice of MLX as the reference stack: for long generation runs, which is what a large-model serving workload mostly is, MLX is the study’s throughput leader among the runtimes it compared.

The second finding is the counterweight, quoted directly:

“Although Apple Silicon inference frameworks still trail NVIDIA GPU-based systems such as vLLM in absolute performance, they are rapidly maturing into viable, production-grade solutions for private, on-device LLM inference.”

The study ran Qwen-2.5 models on an M2 Ultra with 192GB of unified memory, so it measures neither Muse Spark Open nor the M5 Ultra machines in Meta’s claim. What it establishes is directional: if you buy the two-Mac path, you are buying private, on-premises inference that keeps data off third-party infrastructure, and you are accepting lower absolute throughput than an NVIDIA-class serving stack would deliver. For a team whose constraint is data residency, that trade is the point of the exercise. For a team whose constraint is tokens per second, the study says the Mac path is not the winner, and the MoE architecture does not change that. The study measures no cost or pricing dimension, so any tokens-per-second-per-dollar verdict has to come from your own costing exercise rather than from it.

Serving path B: SGLang with Helion kernels on NVIDIA and AMD

Meta ships an alternative stack alongside the weights. From the announcement:

“The open-weight version of Muse Spark ships with custom, auto-tunable Helion GPU kernels in SGLang, delivering 1.03-3.95× kernel-level speedups on NVIDIA and AMD GPUs, and a 3% end-to-end speedup on AMD MI350.” (Meta’s announcement)

Read those two numbers together, because the distance between them is the story. Kernel-level speedups of 1.03-3.95× (vendor-reported) mean individual operations run faster in isolation. The measured end-to-end gain on AMD MI350 is 3%, also vendor-reported (Meta’s announcement). Serving throughput is dominated by memory movement, scheduling, and communication, not by any single kernel, so microbenchmarks of custom kernels mostly do not reach the user-visible number. A team evaluating the GPU path should budget for the end-to-end figure, not the 3.95× kernel figure, and treat even that as unverified until independent SGLang benchmarks appear.

On memory, the GPU path follows the arithmetic from the FORGE paper cited above: a single H100’s 80GB of HBM cannot hold an 816B-parameter model, so this deployment means a multi-GPU server, which in practice means renting. The comparison is then two owned Mac Studios with a combined ~1TB of unified memory against a rented multi-GPU node with comparable aggregate HBM but higher bandwidth and a mature serving stack. Owning wins on data control and predictable cost if utilization is steady; renting wins on throughput and on not committing capital to a configuration whose real-world performance is currently unverified.

The 1M-token context bill nobody quotes in the headline

The 1M-token context window is the spec most likely to be misread, because the memory cost of long context has nothing to do with the weight footprint. A study of attention mechanisms at million-token context (arXiv:2609.08574) models the cost of ordinary dense KV caching for a 1M-token window on a stack of comparable depth at more than 2.5 TiB: “more memory than any single machine has.” Two Mac Studios with a combined ~1TB of unified memory, most of it already occupied by ~816GB of weights, cannot come close to that.

This is a general result about dense attention caching rather than a measurement of Muse Spark Open specifically, and the model may use attention variants or cache compression that change the constant. Meta’s announcement does not say. But the study-reported figure sets the order of magnitude: unless the model’s caching is far leaner than ordinary dense attention, usable context on the two-Mac configuration will sit far below the advertised 1M tokens. If your workload genuinely needs million-token contexts, plan to verify the cache memory requirement per token before sizing hardware, and assume the answer constrains context long before it constrains weights. A realistic working context on this hardware is an open question, not a headline number.

The quantization escape hatch, with a transfer warning

If ~1TB of memory is out of budget, the published escape route is quantization. A quantitative analysis of DeepSeek model quantization (arXiv:2505.02390) reports that “4-bit quantization maintains little performance degradation versus FP8 while enabling single-machine deployment on standard Nvidia GPU devices.” At 4 bits, 816B parameters compress to roughly 400GB by simple arithmetic, which would fit in one 512GB Mac Studio or a single multi-GPU node with room for a working KV cache.

The warning is that the study measured DeepSeek models, not Muse Spark Open. Quantization tolerance varies across architectures, training regimes and modalities, and this model is natively multimodal, which adds components the DeepSeek study did not exercise. The study-reported result makes 4-bit worth testing; it does not make it safe to assume. A team considering this path should run its own quality evals on quantized weights before committing, and treat the single-machine option as a hypothesis with good precedent rather than a guarantee.

The license is part of the hardware decision

“Open-weight” describes artifact availability, not usage rights. Meta’s announcement states: “We’re releasing the weights under the Muse Model License with limited commercial terms, which allow many developers to use the model for free.” The announcement’s License section is one sentence, so what “limited” and “many” exclude is unknown: revenue thresholds, user-count caps, prohibited use categories, or redistribution rules could all sit behind that phrase.

The risk is not hypothetical in pattern. An audit of license drift across the open-source AI ecosystem found that “Non-Commercial licenses, which impose significant use restrictions, have a retention rate of only 20.7%,” (arXiv:2509.09873) meaning restrictive terms frequently fail to propagate into downstream components built on the model. That statistic is study-reported, and the paper’s own page flags a newer superseding study, so treat the number as indicative rather than final. The practical point stands: if your product depends on Muse Spark Open and the license’s commercial limits turn out to exclude you, the hardware you bought to serve it becomes a stranded asset. Read the actual license text, not the blog summary, before any purchase.

How the paths compare

The decision axes, with the evidence status for each:

Before you buy: a verification checklist

Every open item below follows from a gap in the current evidence, not from generic caution:

1. License text. Obtain the Muse Model License itself and check the commercial limits against your revenue, user count and intended downstream distribution. The announcement’s summary, quoted above, is all that describes the terms.
2. MLX build. The hosting side is settled: the announcement lists the weights on Amazon SageMaker AI, Google Cloud Model Garden, Hugging Face and Microsoft Foundry Models, gives a Hugging Face collection URL, and links an MLX adapter for running the model on Mac Studio. The open gap is the build itself: the two-Mac claim is stated for “the latest version of MLX” with no version number or configuration detail, so pin the exact release before assuming reproducibility.
3. Sharding and interconnect. Ask how the model spans two Mac Studios: which layers or experts live where, what link connects the machines, and what it costs per token. This is the least documented part of the headline claim.
4. KV cache at your context length. Measure or compute cache memory per token for your real context needs, using the 2.5 TiB dense-caching figure (arXiv:2609.08574) as the upper-bound intuition until model-specific numbers exist.
5. Independent benchmarks. No independent benchmark of Muse Spark Open appears in any source cited here. Revisit the throughput story when third-party MLX and SGLang numbers land.

Verdict

If your constraint is keeping data off external APIs and you can tolerate modest throughput, two 512GB M5 Ultra Mac Studios are the vendor-supported floor for holding Muse Spark Open’s unquantized weights, and MLX is the evidence-backed runtime choice on that hardware. Size your speed expectations to the 42B active slice, cap your context planning far below 1M tokens, and accept that the configuration’s real performance is unverified until the sharding details and independent benchmarks exist. If your constraint is throughput or your context requirements are genuinely long, rent multi-GPU capacity and serve through SGLang, budgeting for the vendor-reported 3% end-to-end gain (Meta’s announcement) rather than the kernel-level numbers. If ~1TB of memory or the license terms do not work, 4-bit quantization is a promising but unproven route for this specific model, and a smaller open-weight model under a clearly open license remains the lowest-risk option. In every branch, the license check comes first: it is the one factor that can invalidate the purchase entirely, and it is also the cheapest one to resolve.

Frequently Asked Questions

How much memory do the unquantized Muse Spark Open weights require?

At FP8 precision, 816B parameters occupy roughly 816GB before overhead, so the weights fit with modest headroom. That headroom is where the caveats live. It must also absorb the KV cache for whatever context you actually run, plus framework overhead, and the per-machine 512GB figure is a ceiling on what the GPU can address, not a guarantee of what remains after the operating system and runtime take their share.

Can the two Mac Studio setup support the full 1M-token context window?

A study of attention mechanisms at million-token context (arXiv:2609.08574) models the cost of ordinary dense KV caching for a 1M-token window on a stack of comparable depth at more than 2.5 TiB: “more memory than any single machine has.” Two Mac Studios with a combined ~1TB of unified memory, most of it already occupied by ~816GB of weights, cannot come close to that.

What are the commercial usage restrictions for Muse Spark Open?

Meta’s announcement states: “We’re releasing the weights under the Muse Model License with limited commercial terms, which allow many developers to use the model for free.” The announcement’s License section is one sentence, so what “limited” and “many” exclude is unknown: revenue thresholds, user-count caps, prohibited use categories, or redistribution rules could all sit behind that phrase.