Meta Muse Spark Open on a Mac: 304GB 2-bit Build Needs a 512GB Mac Studio

Meta released the weights of Muse Spark Open on October 15, 2026, an 816B-parameter Mixture-of-Experts model with 42B active parameters and a 1M-token context window, and shipped it with an Apple story. The official path is two Mac Studio M5 Ultra machines with 512 GB of unified memory each, linked by RDMA over Thunderbolt 5 and served by MLX. That is the top of the ladder. The bottom of the ladder is simpler: the smallest build that loads at all is a 304 GB 2-bit GGUF on a single 512 GB Mac Studio, and no Mac with 16 to 128 GB of unified memory can load the model in any form. This article walks the whole range, from a 16 GB MacBook Air to a four-Mac Studio cluster, and answers the only question that matters to a reader: what do I actually need to run this thing.

What Muse Spark Open is, in specs

Muse Spark Open is a natively multimodal, sparse Mixture-of-Experts model from Meta Superintelligence Labs, released under the Muse Model License. A Mixture-of-Experts (MoE) model is a transformer where each layer replaces one dense feed-forward network with many parallel experts plus a router that picks a few per token. The headline numbers, taken from the Hugging Face release post:

• 816B total parameters, about 42B active per token
• 256 experts per MoE layer, 8 selected per token
• 62 layers, hidden dimension 8192, 128 query heads and 16 key-value heads (grouped-query attention)
• Context window up to 1M tokens, max_position_embeddings set to 1,048,576
• Input: text, image, video and audio. Output: text only

Every expert stays in memory even though only 8 of 256 run per token. That is the whole point of the architecture, and also the whole problem for a laptop. Deployment needs the memory footprint of an 816B-parameter model, but generation runs at the speed of a 42B one. The experts hold about 97% of the total parameters, according to the Hugging Face post.

Two more definitions matter before the sizes, because the whole article hinges on them. Unified memory is the single pool of RAM that Apple Silicon shares between the CPU and the GPU, so a model's weights and its KV cache compete for the same budget. KV cache is the key-value state a model keeps for every token it has already read, and for a long context it is a first-class memory cost, not an afterthought.

Meta published on its research blog that Muse Spark Open is the first model in its class to run on a desktop, specifically two Apple M5 Ultra Mac Studios with the latest MLX framework. That sentence is the reason this article exists.

Can it run on your Mac? The short answer

No, not below 512 GB of unified memory. Here is the compatibility table by RAM tier, built from the file sizes read on the official pages:

The line that matters is the one between 256 GB and 512 GB. Everything at 256 GB and below is a hard no, because the smallest quantised build is larger than the machine. If you want the underlying arithmetic, how much unified memory an LLM actually needs walks through the weights-plus-KV-cache calculation that produces every number in that table.

The three file families, with their real byte sizes

Muse Spark Open ships in three flavours, and only one of them is ungated. All byte figures below are decimal GB (1 GB = 1,000,000,000 bytes), read from the Hugging Face API blobs endpoint and from the model pages on publication day. They are not GiB.

First, the two Meta repositories, both gated with manual access on Hugging Face:

• BF16 checkpoint, meta-models/Muse-Spark-Open-816B-A42B: the API reports 1,644.366 GB summed across 65 shards. The Hugging Face post rounds the same checkpoint to about 1.5 TB in safetensors format, and Apple's writeup says the native BF16 precision needs more than 1.6TB for the parameters alone.
• NVFP4 checkpoint, meta-models/Muse-Spark-Open-816B-A42B-NVFP4: the API reports 533.043 GB summed across 127 shards, in 4-bit floating point. Apple puts the memory footprint for this format at about 493GB, and states plainly that with the memory needed for intermediate computations the model cannot fit on a single machine.

Both of those repositories are gated for manual access: the model page tells you to submit your full legal name, date of birth and organization, and access is granted after review. One click does not download the official weights.

Second, the ungated GGUF quantisations from ggml-org, published on 2026-10-14. This is the family a single Mac can actually use, and the sizes come straight from the ggml-org GGUF model page:

The split between the rounded page figures and the API sums is not a contradiction, it is rounding. The model page says 304 GB, the API blobs endpoint summed across the 22 Q2_K shards says 304.080 GB. Same file set, two levels of precision. If you are planning disk space, use the decimal figure: it is the sum of the actual shards.

One detail on Q2_K: it is not a uniform 2-bit squeeze. The ggml-org page documents that the routed expert gate and up projections go to Q2_K while the expert down projections go to Q3_K, and the per-layer latent projections and the attention output gate stay at Q8_0. The quant is calibrated with an imatrix computed from the Q8_0 build. It is a mixed-precision recipe, not a blunt truncation.

2-bit on a frontier model: what it costs

Here is the verdict this site has to give, and it is the same one we give everywhere: a 2-bit quant is a quality compromise, and we never recommend 2-bit quants as a default. Meta's own Apple recipe does not use Q2_K. It uses NVFP4, which is 4-bit floating point, and the Hugging Face post describes it as storing parameters in 4-bit precision with negligible loss in accuracy. The 2-bit GGUF exists because someone wants to see an 816B model run on one Mac, not because it is the recommended deployment.

So read the 2-bit path as a capability demo, not a production configuration. If your workload can tolerate the degradation, a 304 GB build on a 512 GB Mac Studio is genuinely impressive: an 816B model on one desktop. If your workload cannot, you are looking at two Mac Studios and the NVFP4 checkpoint, and the 2-bit warning post explains why we draw that line.

Does 512 GB actually hold the full context?

This is the trap. The weights are not the only thing that lives in unified memory. The KV cache does too, and Muse Spark Open's cache is large at context.

The Hugging Face post does the arithmetic: each token adds 2 x 16 heads x 64 dimensions x 62 layers = 126,976 values to the cache. In BF16 that is about 250 KB per token, and about 266 GB for a full 1M-token context.

Now put the two numbers side by side on a single 512 GB Mac Studio. The Q2_K weights take 304 GB and the Hugging Face team reports 304 GB used by the model with plenty of room free for the KV cache on its test machine. That room is enough for a long conversation, but it is not 266 GB. A 304 GB build plus a full 1M-token BF16 cache is roughly 570 GB, more than a single 512 GB machine has. So the honest reading is this: the 304 GB build fits a 512 GB Mac, and the 266 GB full-context cache is what pushes past 512 GB. You can have the frontier model on one machine at 2-bit, or you can have the full 1M-token window, but not both at once on a single 512 GB Mac Studio. The cache is the reason.

If you want the full window in BF16, you are back to a cluster, which is exactly what Meta's recipe assumes.

What Meta's official Mac recipe actually requires

Meta publishes a Mac cookbook for Muse Spark Open, and it is not a one-machine story. From the Muse Spark Open on Mac cookbook, the prerequisites are:

• Two Mac Studio computers with M5 Ultra and 512 GB of unified memory each, or four with 256 GB each
• macOS 26.2 or later on every Mac, because that release adds the RDMA-over-Thunderbolt driver that jaccl uses
• MLX 0.30.1 or later
• A direct Thunderbolt 5 link between every pair of Macs, connected with two cables per pair to double the link bandwidth
• Disk space for the full NVFP4 checkpoint on each Mac, since each machine loads the model from its own disk

The harness is mlx-lm across Thunderbolt-linked Mac Studios, and mlx.launch starts the program over SSH on every machine from a hostfile. Tensor parallelism splits each layer across the cluster. Meta estimates about 4 hours to complete the recipe.

On versions, note the gap between the minimum and the current state. Meta's floor is MLX 0.30.1. The latest MLX tag published is v0.32.4, and mlx-lm shipped three releases (v0.32.0 to v0.32.2) within a day of the launch, each listing Muse support in its notes. If you follow the cookbook today, you will be well above the minimum. Check the mlx-lm tags before you build the cluster, since the Muse template landed recently.

The cluster is not exotic, and it is not only for Muse Spark Open

A pair of Mac Studios wired by Thunderbolt is a pattern this site has covered for a while, because it is the only way around the single-machine memory ceiling on Apple Silicon. If you are weighing a two-Mac setup for Muse Spark Open, the same hardware runs other large models and the NVIDIA pair versus a local Mac cluster comparison is worth reading before you buy. For the single-machine case, running large local LLMs on a Mac Studio M5 Ultra 512 GB and our best-LLM pick for that machine cover what actually fits today.

If you are deciding between serving stacks, the MLX versus Ollama comparison for Mac in 2026 explains why Meta's recipe uses MLX here rather than a single-machine runner. And since the ggml-org quants lean on recent llama.cpp work, the llama.cpp 0.4.0 writeup on lazy tensors, RDMA and sparse attention is the background for the 2-bit path.

How fast is it, and who measured what

Two speed figures circulate, and both need their hardware named, because neither is a modelfit measurement. ModelFit runs no benchmarks.

• 18 tokens per second: measured by the Hugging Face team on a Mac M3 Ultra with 512 GB, running an imatrix-calibrated 2-bit quant through llama.cpp. The post reports 304 GB used by the model with room left for the KV cache. Source: Hugging Face release post.
• Over 36 tokens per second: measured by Apple on a cluster of four Mac Studios with M5 Ultra, in NVFP4 with MLX, at a context size of 8,192 tokens. Source: Apple machine learning research.

Different engines, different quantization, different hardware counts. The Apple number is a four-machine tensor-parallel NVFP4 result at a modest context. The Hugging Face number is a single-machine 2-bit llama.cpp result. Treat them as two data points, not a comparison.

Two more figures from the Hugging Face post are worth knowing if you plan to train on top: full fine-tuning of the 816B checkpoint was done on 8 nodes of 8 H100 GPUs, and the reference NVFP4 deployment in vLLM needs Blackwell-series GPUs. Neither is a Mac workload, and neither is something a Mac Studio can do.

Is there a local ollama run command?

No. The Ollama library page for muse-spark-open lists exactly one tag, muse-spark-open:cloud, and it is a cloud model. The page shows ollama run muse-spark-open:cloud, which calls Ollama's hosted endpoint, not your Mac. There was no local tag at the time of this check. If you want Muse Spark Open on local hardware, the routes are llama.cpp with the ggml-org GGUFs, or MLX with the NVFP4 checkpoint across a Mac Studio cluster. Ollama is not one of them right now.

ModelFit take: the memory ladder just moved

Labeled as our own reading, not a vendor claim. Until now, the largest open models a single Mac could hold were in the low hundreds of billions of parameters at 4-bit, and a 512 GB Mac Studio was headroom, not a requirement. Muse Spark Open changes the shape of the ladder in one specific way: the entry rung is now 512 GB, and it is filled by a 2-bit build, while the recommended configuration is a two-machine cluster. That is a new pattern for desktop local AI. It also means the practical question for a buyer is no longer "how big a Mac do I need" but "do I want one 512 GB Mac at 2-bit, or two 512 GB Macs at 4-bit".

Our synthesis of the three published sources, since no single page states it: Meta, Hugging Face and Apple agree on the two-machine NVFP4 path and disagree only on rounding, 533.043 GB of files versus about 493GB of footprint versus more than 1.6TB for BF16. The gap between those numbers is quantization plus the difference between files on disk and bytes resident in memory. Read together, they say the same thing: this model was designed for a cluster, and the single-Mac 2-bit build is a bonus that the ggml-org team published a day before Meta's own release date.

FAQ

Can Muse Spark Open run on a Mac with 64 GB of unified memory?

No. The smallest build is the Q2_K GGUF at 304 GB, which is several times larger than 64 GB. Nothing in the model family, not even the vision and audio encoders alone, brings a 64 GB Mac into range. The floor for loading the model at all is a 512 GB machine.

What is the smallest Mac that can run Muse Spark Open?

A single Mac Studio M5 Ultra with 512 GB of unified memory, using the Q2_K GGUF at 304 GB. This is a 2-bit build, and 2-bit is a quality compromise for a frontier model, so treat it as a way to run the model rather than the way to run it well.

Does the official checkpoint fit on one 512 GB Mac Studio?

No. The NVFP4 checkpoint totals 533.043 GB across 127 shards, already past 512 GB before any KV cache, and Apple states the model cannot fit on a single machine once intermediate inference memory is counted. Meta's recipe splits it across two or four Mac Studios over Thunderbolt 5.

Why does 266 GB come up if the model is only 304 GB?

266 GB is the KV cache for a full 1M-token context in BF16, at about 250 KB per token. On a single 512 GB Mac, a 304 GB build plus a full-context cache is more than the machine has, so you choose between the 2-bit weights and the full window, or you add machines.

Where can I download the weights?

The GGUF quantisations from ggml-org are ungated and downloadable now. The BF16 and NVFP4 checkpoints from meta-models are gated with manual access and require an approved request.

Sources

• Hugging Face: Welcome Muse Spark Open: architecture, 816B/42B, 256 experts, 62 layers, 250 KB per token, 266 GB full context, 304 GB used, 18 tokens/s on M3 Ultra 512 GB, Q2_K/Q4_K_S/Q8_0 test note, 1.5 TB BF16 rounding
• ggml-org GGUF model page: Q2_K 304 GB, Q4_K_S 470 GB, Q8_0 872 GB, BF16 1.64 TB, mmproj 4.1 / 4.1 / 2.2 GB
• Hugging Face API, ggml-org GGUF blobs: decimal GB summed per quant
• Hugging Face API, meta NVFP4 blobs: 533.043 GB across 127 shards
• Hugging Face API, meta BF16 blobs: 1,644.366 GB across 65 shards
• Meta model card, BF16 repository: Date of Release October 15th, 2026, Muse Model License, 816B total / 42B active, gated download
• Meta cookbook: Muse Spark Open on Mac: two or four Mac Studios, macOS 26.2 or later, MLX 0.30.1 or later, Thunderbolt 5 link, NVFP4 checkpoint on each disk
• Apple machine learning research: MLX distributed inference: over 36 tokens per second on four Mac Studios at 8,192-token context, more than 1.6TB BF16, about 493GB NVFP4
• Meta AI research blog: October 15, 2026 release, desktop claim, two M5 Ultra Mac Studios
• Ollama library: muse-spark-open: cloud tag only, Muse Model License
• mlx-lm tags: v0.32.0 to v0.32.2 released October 15 and 16, 2026