You can run Meta's new 816-billion-parameter Muse Spark Open on one Mac, if that Mac has 512GB of memory and you use heavily compressed weights. Hugging Face reports that a two-bit version occupied about 304GB on an M3 Ultra. That gives developers a different starting point from Meta's two-machine launch configuration.
Meta released the weights on October 15, positioning the model for coding and software agents. Its own desktop demonstration uses two M5 Ultra Mac Studios. The company says it tested local workflows that changed and built the open-source Mastodon client Ice Cubes, alongside video-editing work in DaVinci Resolve. Meta reports those results from its own tests.
The useful distinction is between fitting the weights and running the workload you need. Meta's model documentation lists 42 billion active parameters, but serving still requires the full set of 816 billion weights. Compression changes the memory calculation. Context and runtime overhead add to it.
Why 42 billion active parameters still need so much memory
Muse Spark Open uses a sparse mixture-of-experts architecture: each token activates a subset of the model's experts. That reduces computation per token while leaving the stored model much larger. According to Meta's architecture overview, the model accepts text, images, audio, and video, and generates text. Its maximum context window is 1,048,576 tokens. The active parameter count alone doesn't tell you whether your machine can serve it.
The two official checkpoint formats make the storage requirement concrete. Meta's download guide puts BF16 weights at about 1.65TB and NVFP4 at about 537GB. NVFP4 stores most weights at four-bit precision while retaining some layers in BF16. The published serving recipes use eight B300 GPUs for BF16 and four for NVFP4.
These are weight footprints. The same guide excludes the key-value cache, activations, and runtime overhead from those figures. If you're planning a deployment, a checkpoint download size is only the first line of the memory budget. The guide says GPU requirements also depend on the interconnect and parallelism strategy, so the recipe's GPU count shouldn't be read as a universal minimum.
What the single-Mac tests establish
Hugging Face's launch walkthrough reports 18 generated tokens per second for a calibrated two-bit version in llama.cpp on a 512GB M3 Ultra. It also reports an oQ3e version in oMLX using about 344GB, with roughly 225 tokens per second for prompt processing and 21 for generation. That measurement used a 1,024-token prompt and generated 128 tokens. Both results describe particular compressed versions and software configurations.
The qualification matters for developers choosing between them. Hugging Face's three-dimensional asset demo uses the two-bit model with a coding agent and says quantization requires more steering. Its short-prompt throughput figures don't establish how a long repository session performs, or how faithfully either compressed version preserves coding quality. They establish a working local route worth testing.
A million-token model can serve a shorter window
Meta's recommended settings explain why context needs its own budget. Of the model's 62 decoder layers, 46 use sliding-window attention over the most recent 2,048 tokens. Sixteen use full attention and retain a cache across the whole context. Memory grows with context length on those full-attention layers, while the sliding-window cache stays fixed.
That makes a smaller serving window a practical control. Meta advises setting the maximum context to the workload, using the appropriate server flag. For a developer, this means choosing a limit for the repository material and accumulated tool results you expect to send. The model's advertised ceiling doesn't oblige the runtime to reserve or expose that ceiling in every deployment.
Even Meta's TensorRT-LLM instructions distinguish the architectural maximum from a validated setup. They specify a 49,152-token serving window for the recommended configuration and say longer windows require more cache memory. That example is a useful check on the million-token headline: support in the model and validation on a particular server are separate claims.
The llama.cpp guide adds a detail for concurrent requests: its total context allocation is divided across slots. Check n_ctx_slot in the startup log to see the limit available to each generation.
Meta's two-Mac route has its own requirements
The official Apple configuration uses NVFP4 with two 512GB M5 Ultra Mac Studios, or four machines with 256GB each, according to Meta's hardware table. MLX distributes the model over RDMA on Thunderbolt 5. The guide requires macOS 26.2 or later and a direct connection between every pair of Macs. Four machines therefore need a different cable arrangement from a simple chain.
Meta's MLX deployment instructions add MLX 0.30.1 or later, enabled RDMA, and passwordless SSH from the primary machine to the others. Each Mac loads the checkpoint from its own disk and needs space for the complete NVFP4 download. Splitting inference across machines doesn't split that disk-space requirement in the documented setup.
Apple hardware is one supported option. The platform guide also lists NVIDIA Blackwell configurations, AMD MI355X or MI350X systems, and an INT4 path for Intel Xeon 6 processors. These are recipes for different hardware and runtimes. The table supplies no common benchmark that would let you rank them against the compressed single-Mac tests.
Reasoning settings change what a speed figure means
Muse Spark Open defaults to its highest reasoning effort, xhigh. Meta's settings guide says reducing that effort cuts reasoning tokens and latency. A useful local test should record the effort setting alongside prompt length. Otherwise, two runs can spend different amounts of computation before producing their visible answers.
The llama.cpp instructions say reasoning cannot be disabled: the chat template rejects none. Lower effort is available. For an interactive coding session, that leaves a concrete decision about how much time to allow the model to think on each request. A tokens-per-second figure by itself doesn't capture the wait for a completed answer.
Meta's evaluation methodology uses xhigh reasoning for Muse Spark Open, with temperature and top-p both set to 1.0. Its comparisons combine official benchmark results, internal runs, and other providers' reported scores. Meta also says its agent tools and system prompts weren't specifically tuned for rival models and may not reflect their best performance.
The coding comparisons have another variable. In the DeepSWE methodology, Muse Spark Open runs with Muse Code, while several competitors use other harnesses. DeepSWE includes functional verifiers and regression checks, which give the scores a defined basis. They still describe model-and-harness combinations. They don't establish that a compressed local checkpoint, connected to your preferred agent, will achieve the same result.
Control comes with a specific configuration
Meta offers the weights under the Muse Model License, with limited commercial terms. It also lists hosted inference partners for developers who don't want to provision the hardware. Downloadable weights create a choice about where inference runs, while the license remains part of the deployment decision.
For teams that choose local operation, Meta's download guide says inference can run offline after the weights arrive, without an API key. That is a concrete benefit for work you want to keep on your own infrastructure. A hosted endpoint is a different arrangement, even when it serves the same released model.
Watch for reproducible coding runs of these compressed checkpoints, with actual context length and reasoning effort reported. Meta's evaluation report documents different harnesses across coding comparisons, so a local test also needs to name its agent. Passing regression checks and measured time to completion would help you judge whether the single-Mac route can handle your work.