Muse Spark Open Requirements

Meta's open-weight model Muse Spark Open (816B total, 42B active MoE), released on October 15, 2026, officially needs about 2TB of VRAM at BF16 and at least 700GB at NVFP4 (4-bit). Meta calls it the most capable US open-weight model to date, and it is officially optimized to run on two Mac Studio machines with M5 Ultra (512GB unified memory each) through MLX. A 2-bit GGUF build is reported to fit in roughly 300GB of combined memory.

In other words, this is not a model for a personal PC or a single GPU. Realistic options are two Mac Studios, a server with around eight H200 or B200 GPUs, or a provider API. This article separates Meta's official information, reported figures, and our own estimates. Where no official number exists, such as FP8 and KV cache, we label it an estimate; anything missing from the model card is marked not disclosed.

Weight size is roughly 816B parameters times bytes per parameter. The official 700GB and 2TB figures appear to include headroom for KV cache and runtime overhead, so the table separates official, reported, and estimated values.

If you want to check quickly whether your own GPU or Mac can run it, the VRAM calculator (free, no sign-up) estimates required VRAM from a model, quantization, and context length. Muse Spark Open is available in its model list.

The pass/fail verdicts for these configurations are our judgment, comparing total memory against the official 700GB and the estimated FP8 size; they are not measured results. BF16 needs about 2TB, which even 8 B200s (1,536GB) cannot hold.

Muse Spark Open is the open-weight member of Meta's Muse family. It is a Mixture-of-Experts Transformer paired with a Perception Encoder, accepting text, image, video, and audio input and producing text output. It was trained on 100+ languages, though not all were evaluated. The Hugging Face repo is meta-models/Muse-Spark-Open-816B-A42B, and it is also offered on Amazon SageMaker AI, Google Cloud Model Garden, and Microsoft Foundry Models.

An MoE uses only 8 of 256 experts per token, but which ones depend on the input. All experts therefore generally have to stay resident, so required memory is set by the total parameter count (816B). The 42B active figure mainly affects speed: at 4-bit, each token reads about 21GB of weights (42B x 0.5 byte). The memory footprint is that of an ~800B model, while compute is closer to a ~40B model.

The official 4-bit format is NVFP4, described as a Meta and Apple format for MLX. Weights alone would be about 408GB (816B x 0.5 byte), but with scale metadata, KV cache, and runtime space, Meta states at least 700GB. A 2-bit Unsloth Dynamic GGUF is reported to fit in about 300GB combined, and quantized builds work in llama.cpp, Ollama, LM Studio, and Jan. Quality drops noticeably at 2-bit, so 4-bit or higher is safer for reasoning workloads.

The basics of quantization are also covered in our Mistral Large 4 requirements article. Muse Spark Open has an official 700GB-class figure for 4-bit, which makes sizing less guesswork than for a 1T-class model with no published number.

Meta officially optimizes for two Mac Studio machines with M5 Ultra (512GB unified memory each), about 1TB in total with 1.2TB/s memory bandwidth. Using NVFP4 through MLX (mlx-lm), generation speed across the two machines is reported at about 15.7 to 25 tokens per second (reported, varies by conditions). A single 512GB machine cannot hold the 4-bit build (at least 700GB), so distributed inference across two is the premise.

In the demo, Muse Code, Meta's AI coding terminal, ran agent work on-device: fixing bugs and adding features in Ice Cubes, an open-source iOS Mastodon client, and driving DaVinci Resolve to review and crop footage. The interconnect, required network bandwidth, and speed at long context are not disclosed in the sources we checked, so we treat them as not disclosed.

For GPU servers, 4-bit (NVFP4) points to 5 to 8 H200s or 4 to 8 B200s. FP8 (~816GB) fits in 8 H200s (1,128GB) but leaves only about 300GB, which is tight at the long contexts discussed below. BF16 does not fit even on 8 B200s. Depending on the parallelism method (tensor or expert parallel), GPU counts may need to be powers of two, so whether a 5-GPU H200 setup works depends on the framework.

Meta contributed custom Helion kernels to SGLang, reporting 1.03 to 3.95x kernel-level speedups on NVIDIA and AMD and a 3% end-to-end gain on AMD MI350. The end-to-end gain is modest, so treat it as a sign that AMD is a workable option rather than a deciding factor.

KV cache per token is 62 layers x 16 KV heads x 64 head dim x 2 (K and V) x 2 bytes (BF16), or about 254KB per token (our calculation, not an official figure).

Thanks to GQA (16 KV heads), 128K costs only about 33GB. Using the full 1M, however, adds about 260GB on top of the weights, bringing the 4-bit total to around 960GB. It scales with concurrent requests, so serious 1M use realistically calls for 8 H200s or 8 B200s. For the mechanism, see our KV cache and context length VRAM guide.

Supported frameworks are SGLang, vLLM, Transformers (AutoModelForMultimodalLM), TensorRT-LLM, MLX (mlx-lm), llama.cpp, and Unsloth. Fine-tuning works with PyTorch and TorchTitan. These are the commands Meta shows. First, vLLM.

Next, SGLang, which starts an OpenAI-compatible server on port 30000.

With Docker, Docker Model Runner starts it in one line.

For the two-Mac MLX setup, use mlx-lm's distributed features. Check Meta's model card and the mlx-lm documentation for the exact connection commands; we have not verified this on real hardware. Recommended sampling is temperature 1.0, top_p 1.0, top_k disabled, and reasoning effort can be low, medium, high, or xhigh (default xhigh).

API providers include Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter, and Together AI. Per-token prices are not confirmed, so compare input and output rates on each provider's pricing page. The hardware above costs millions of yen even for two Mac Studios, and an 8-GPU H200 server is an order of magnitude more, so for most small and mid-sized businesses, evaluating quality through an API first is the safer investment. Self-hosting makes sense when data cannot leave your premises or daily volume is large.

For Meta's closed API model, see Muse Spark 1.3 pricing and benchmarks; for a smaller model you can run locally, see Muse Glimmer 30B requirements.

It uses Meta's custom Muse Model License, which is not OSI-approved open source. Use, modification, fine-tuning, distillation, distribution, and sale are permitted. The main conditions are:

- You must display "Built with Muse Spark Open"
- If aggregate gross revenue exceeds $20M USD in any 12 months AND you offer the model via API to third parties (Model-as-a-Service), you must notify Meta and sign a separate agreement
- Internal use, research, and embedding in your own product are excluded from that clause
- Meta claims no ownership of outputs
- The usage policy bans weapons, malware, critical infrastructure operation, and fraud, disinformation, and impersonation; not for users under 18

It is reportedly similar to the Kimi K3 license. A small business embedding the model in its own service normally falls outside the $20M clause, but interpretation depends on the contract structure, so read the full license text before commercial use.

The figures below come from Meta's model card at xhigh and are vendor-reported. We have not seen independent replication, and the full evaluation report is listed as coming soon.

The pattern: it is strong at agent tool use (MCP-Atlas) and refusing harmful requests (StrongREJECT), but behind Kimi K3 and GLM 5.3 on coding benchmarks. Its AA Intelligence Index of 39 is close to Qwen3.8-2.4T (40) and slightly above Mistral Large 4 (38). Kimi K3 for coding agents and Muse Spark Open for tool integration and safety is one plausible split, but verify on your own data.

Reflection Beam (501B) is much lighter on memory. Muse Spark Open carries about 1.6x the weights but is lighter than the 1T-class Mistral Large 4. On license freedom, Apache 2.0 Beam is ahead, while Muse Spark Open adds an attribution requirement and a revenue condition.

- Just want to try it: a provider API (OpenRouter, Together AI, Fireworks AI, etc.); check each price
- Self-host on Mac: two Mac Studio M5 Ultra 512GB machines (MLX, NVFP4, officially supported)
- Serious GPU server: 8 H200s or 4 to 8 B200s; 8 H200s or more for 1M context
- Fit over quality: 2-bit GGUF in about 300GB combined (expect quality loss)
- Managed cloud: Amazon SageMaker AI, Google Cloud Model Garden, Microsoft Foundry Models

- OOM at startup: the weights do not fit. Drop a precision step (FP8 to 4-bit) or add machines or GPUs
- OOM mid-run: likely KV cache. Lower the context cap, reduce concurrent requests, or try FP8 KV
- Crash on image, video, or audio input: the Perception Encoder (1.8B) and input tokens add memory. Reduce resolution or concurrent inputs
- Slow or unstable on Mac: the link between machines is a common bottleneck. Close other apps and check for memory compression
- Garbled output: reset sampling to temperature 1.0, top_p 1.0, top_k disabled; 2-bit loses much quality, so try 4-bit
- Framework says unsupported: update vLLM or SGLang to the latest version

Muse Spark Open is an 816B-total, 42B-active MoE with official figures of about 2TB at BF16 and at least 700GB at NVFP4. Two Mac Studio M5 Ultra 512GB machines are officially optimized via MLX, and a 2-bit GGUF is reported at about 300GB. The license is custom, and a separate agreement is needed only when revenue exceeds $20M and you also offer it through an API. Benchmarks show strong tool use but weaker coding than Kimi K3. For most users, evaluating via API first and considering self-hosting later is the sensible order.