Meta Muse Spark Open ships 816B weights: memory is the catch

Meta's Muse Spark Open gives builders downloadable multimodal weights, but local deployment remains a high-memory undertaking. Hugging Face describes an approximately 816B-parameter model with 42B active per token. Its serving guide shows why sparse computation does not turn a frontier-size checkpoint into a small workstation model.

Key facts

• Hugging Face lists text, images, audio, and video as inputs, with text output, and a maximum context window of 1,048,576 tokens.
• The architecture description specifies 256 experts per MoE layer, with eight selected for each token.
• The guide describes the BF16 checkpoint as approximately 1.5 TB and documents an NVFP4 variant for Blackwell-oriented serving.
• Hugging Face reports 18 tokens per second with a calibrated 2-bit llama.cpp quantization on an M3 Ultra with 512 GB memory; it lists 304 GB used by that model configuration.

Downloadable weights change the access question

DeAI's October 16 feed captured the Muse Spark Open release material. It is a different access story from Muse Wonder's closed-weight launch, which DeAI covered earlier that week. The current Hugging Face guide links BF16 and NVFP4 checkpoints, quantizations, serving integrations, and fine-tuning examples.

The model is positioned for coding and agentic work. Multimodal input means the same system can take a screenshot, recording, or video as context while producing text or tool calls. Those capabilities expand the possible workflow, but the serving implementation has to preserve the input processing and parse the model's response correctly.

Weight access also does not settle every licensing question. Direct retrieval of the gated checkpoint README required authorization during this review. This report therefore does not characterize the underlying terms as unrestricted or Apache-licensed. Teams should inspect the terms attached to the checkpoint they actually obtain. The public integration guide is sufficient to report the deployment recipes, not to infer permissions hidden behind access controls.

Active parameters are not the memory budget

The public architecture explanation explicitly says that the full expert set remains in memory. Routing determines which experts compute on a token; it does not discard the rest of the weights. The active count is consequently useful for understanding sparse execution, but misleading as a hardware-sizing shortcut.

Quantization reduces the stored representation. It can also change output quality and which kernels or accelerators are usable. A result from a calibrated low-bit checkpoint is not interchangeable with the full-precision release. An application should preserve the exact quantization identifier in any test report and evaluate its own long tasks rather than treating every checkpoint under the model's name as equivalent.

The context window adds another budget. Hugging Face calculates about 266 GB of BF16 key-value cache at the full window. That figure is separate from the weights. A machine that loads a quantized model may still be unable to serve its maximum advertised context with useful concurrency.

Runtime support is uneven

The guide offers several paths, and they do not expose identical capabilities. Its reference vLLM integration supports text and image inputs, while the SGLang integration is described as supporting audio and video as well. The published vLLM launch command also caps its serving context below the architecture's maximum. Backend configuration determines what an endpoint can actually accept.

There is a further documentation mismatch worth testing before integration. The prose says reasoning cannot be disabled and recommends lowering reasoning effort for easier tasks. An endpoint example nevertheless includes an enable_thinking: false argument. That example is not evidence that disabling reasoning works. A client should check the actual response and supported settings on its chosen backend.

Hugging Face's local measurements offer possible starting configurations, not guarantees. Its MLX-oriented example uses a different quantization and reports memory and speed under a short prompt. Those conditions differ from a long agent session with multimodal inputs and repeated tools. Prefill time and retained context can dominate a workflow even when decode speed looks usable.

Background and deployment decisions

DeAI's model hub follows the practical availability of open weights. The open-weight versus open-source explainer covers the separate permissions question, and the self-hosting economics guide explains why utilization belongs beside hardware capacity in deployment comparisons.

For a team considering Muse Spark Open, a useful evaluation starts with the required modalities. If an application needs audio, selecting a text-and-image endpoint and assuming the model's advertised audio support will pass through is an integration error. If it needs long repository context, loading the weights is only the first capacity check.

The next evidence should be a run on the intended serving stack with realistic input lengths, the selected quantization, and actual tool schemas. Record peak memory and failure behavior as well as completed work. Downloadable multimodal weights give operators more control over where inference happens. The published recipes also make clear that exercising that control can require a much larger memory allocation than the active-parameter headline suggests.