Meta Opens Sources 816B-Param Muse Spark for Agents, Lags in Coding Benchmarks

Meta Open-Sources Muse Spark Open: An 816B-Parameter Sparse MoE Model with Million-Token Context and Multimodal Input, Designed for Long-Horizon Agentic Tasks (Requires Dual M5 Ultra Mac Studios for Local Deployment)

The model supports cross-modal understanding but lacks native generation capabilities; end-to-end tool calling and failure recovery are its core agentic strengths. However, it underperforms competitors like Zhipu and Kimi on coding benchmarks.

This article is intended for AI architects, agentic system engineers, and edge LLM deployment engineers.

Meta has brought large-scale agentic models to desktop devices, though this "desktop" setup requires two high-spec Mac Studios.

On October 15 local time, Meta announced the release of the Muse Spark Open model weights, targeting software engineering, long-horizon task execution, and multi-step reasoning as primary use cases. Alongside the model weights, attention has focused on its local runtime solution: developers can deploy this model on two Mac Studios equipped with M5 Ultra chips using the MLX framework.

Meta positions Muse Spark Open as the most capable US open-weight model to date.

Muse Spark Open utilizes a sparse Mixture-of-Experts (MoE) architecture with a total parameter count of 816 billion, activating approximately 42 billion parameters per token. It supports a context window of 1,048,576 tokens. The model accepts text, images, audio, and video inputs, while outputting only text. Consequently, while it can understand screenshots, videos, and recordings, this does not imply native image, audio, or video generation capabilities.

This capability set targets workflows requiring continuous operation. The model must not only understand user intent but also plan steps, invoke tools, check execution results, and adjust actions after tool failures.

Coding Benchmarks Trail Behind Zhipu and Kimi

Meta’s model card lists end-to-end agentic tasks, code writing and debugging, and long-horizon tool calling as primary uses, alongside synthetic data generation and model output evaluation.

In official demonstrations, Meta used Muse Code—powered by Muse Spark Open—to complete iOS development work for the open-source Mastodon client Ice Cubes locally, involving bug fixes, feature additions, and full builds.

Another demonstration showed the model operating DaVinci Resolve, inspecting footage frame-by-frame, selecting clips, and performing vertical cropping. These cases illustrate the model’s direction toward connecting with real-world software, but they remain official showcases and cannot be directly extrapolated to guarantee unattended completion of all similar tasks.

Regarding performance, Meta reported scores of 61.8 on JobBench, 89.2 on MCP-Atlas, and 80.4 on OSWorld Verified. In coding-related tests, Terminal-Bench 2.1 scored 76.4, and DeepSWE 1.1 scored 60.

Notably, in both Terminal-Bench 2.1 and DeepSWE 1.1 tests, Muse Spark Open scored lower than domestic open-source models GLM 5.3 max and Kimi K3 max.

Objectively speaking, these results do not demonstrate comprehensive leadership across all metrics.

Local Deployment Is the Model’s Biggest Highlight

Local deployment is a key highlight of this release. However, 42 billion active parameters do not mean memory requirements are limited to hosting a 42-billion-parameter model. While the sparse architecture reduces the number of parameters participating in computation per token, the full weights still need to be loaded. According to official documentation, BF16 version weights are approximately 1.65 TB, and NVFP4 versions are around 537 GB, with additional space required for KV Cache, activations, and runtime overhead.

Official GPU deployment examples indicate that the BF16 version uses 8 B300 GPUs, while the NVFP4 version uses 4 B300 GPUs. Specific configurations depend on accelerator memory, interconnect conditions, context length, and parallelism strategies.

It is worth noting that “can run locally” means developers gain control over deployment location choices; it does not imply that ordinary laptops can handle such models.

Related research published by Apple also demonstrated distributed inference results on four Mac Studios: Muse Spark Open achieved a generation speed exceeding 36 tokens per second.

For teams not prepared to build their own hardware, Muse Spark Open offers hosted access paths. Official ecosystem partners include Baseten, Fireworks AI, Groq, Modal, Nebius, Together AI, and OpenRouter; deployment tools cover SGLang, vLLM, TensorRT-LLM, llama.cpp, and MLX. Developers can first validate task effectiveness via API before assessing whether self-deployment is worthwhile.

Another point to note is that Muse Spark Open adopts the Muse Model License; open weights do not equate to unrestricted commercial use. The license permits usage, modification, fine-tuning, distillation, and distribution provided terms are met.

Where applicable, the license allows use under specific conditions.

After the model's release, it sparked heated discussion in international communities, with users across various platforms offering mixed reviews.

Some netizens expressed skepticism regarding the benchmark scores: "Their models are always heavily optimized for leaderboards; I don't know whether to trust these numbers."

Others appreciated Meta’s decision to open-source the model weights again but were dissatisfied with the terms of use: "The license is disappointing, but I’m glad Meta is finally paying attention to developers again."

Another group of users prioritized actual user experience. One netizen noted that while Muse Spark Open appears to be "the second-best open-weight model" based on evaluations, it may be even more competitive in practice: "The Muse Spark series performs exceptionally well in real-world usage and consistently surprises me."

Additionally, a user shared a comparison between other models in the Muse series and Gemini 4 Argon, aiming to verify which series is stronger. They stated that under identical prompts and each model's highest available reasoning settings, Muse took approximately 40 minutes and cost around $30, whereas Argon took about 30 minutes and cost roughly$10. Regarding the results of this 3D task, they commented: "Muse definitely surprised me... but I think Argon is slightly better."

How to Bring 816 Billion Parameters to the Desktop: The Technical Logic Behind Muse Spark Open

Following the release of Muse Spark Open, YouTubers analyzed the technical logic behind its desktop deployment.

Running a model with 816 billion parameters locally first faces physical constraints: where to store the model weights, how compute units read these weights, and how data is exchanged between multiple machines. Desktop deployment of Muse Spark Open requires coordinated efforts among model architecture, numerical precision, memory systems, and inference frameworks.

Two easily confused metrics are total parameter count and active parameter count. Muse Spark Open has 816 billion total parameters, but only about 42 billion parameters are activated per token. The former largely determines weight storage requirements, while the latter impacts the computational load per token. These correspond to "whether it fits" and "whether it can compute," respectively, and cannot substitute for one another.

The model employs a Sparse Mixture-of-Experts (MoE) architecture. In typical MoE layers, the routing network calculates routing scores for different experts based on the current hidden representation of the token, assigns computation to the selected minority of experts, and finally aggregates the results. This allows the model to avoid invoking all experts when processing every token.

In the video, the blogger compared this mechanism to a librarian: when answering a question, one doesn’t need to search through the entire library, just retrieve the relevant books. The sparse architecture reduces the number of parameters involved in computation but does not eliminate the storage requirement for all weights. Since different tokens may invoke different experts, the system must still ensure these expert weights are accessible. Therefore, one cannot estimate memory requirements based on a dense 42-billion-parameter model simply because the model only activates ~42 billion parameters. Official documentation clearly distinguishes between these two concepts.

While the blogger attributed the feasibility of desktop deployment primarily to MoE, quantization is also an indispensable factor.

Roughly calculating at two bytes per parameter, 816 billion parameters require approximately 1.63TB just for BF16 weights, excluding additional memory needed during inference. Two devices equipped with 512GB of RAM each cannot directly accommodate the full model and its operational overhead at this precision level.

Apple’s published tests for Muse Spark Open utilized NVFP4 precision rather than BF16. Reducing weight precision shrinks the model’s memory footprint, while multi-machine parallelism further distributes weight and computational loads, making such desktop deployment possible.

Thus, a more complete technical explanation is: MoE reduces active computation per token, quantization lowers weight storage overhead, multiple machines provide the necessary total memory capacity, and the inference framework coordinates distributed execution. No single factor alone explains the entire result.

The video highlighted Apple Silicon’s unified memory architecture. Its key feature is that CPUs and GPUs can access the same physical memory pool, reducing the need to copy data between system memory and dedicated VRAM in certain workflows, while allowing integrated GPUs to leverage larger memory capacities.

However, unified memory does not mean memory bottlenecks disappear. Compute units still need to read weights and intermediate data, and actual speed remains influenced by memory bandwidth, access patterns, cache hits, and computational efficiency. Apple announced that the M5 Ultra’s unified memory bandwidth is 1.2TB/s, but this is a metric for a single machine’s memory system and cannot be viewed as communication bandwidth between two Macs.

Similarly, two Macs with 512GB of RAM each do not become a single computer with ~1TB of uniformly fast-accessible memory merely by being connected. Distributed execution requires partitioning the model or computation across different devices and exchanging necessary data via communication mechanisms. Apple’s solution uses RDMA over Thunderbolt, with MLX providing corresponding collective communication support.

This means local large model deployment involves both capacity issues and communication issues. As the number of machines increases, even if the model fits, cross-device synchronization and data exchange may limit scalability benefits.

Operator Acceleration Approaching 4x Does Not Mean End-to-End Inference Approaches 4x

The latter half of the video introduced another noteworthy technical point: after weights are opened up, the inference implementation still determines whether developers can efficiently use the model.

Meta introduced custom Helion GPU operators integrated into SGLang during the release, claiming they achieved 1.03–3.95x operator-level acceleration on NVIDIA and AMD GPUs, and approximately 3% end-to-end acceleration on AMD MI350. It is crucial to distinguish between "operator-level" and "end-to-end" metrics here.

GPU operators execute specific types of computations, with performance related to data tiling, thread organization, memory access, and hardware resource utilization. Auto-tuning selects more suitable implementations for target devices and inputs by testing different configurations. This does not imply re-exploring optimal configurations for every generated token; Helion supports caching tuning results and offers pre-tuning workflows.

Even if a local operator is significantly accelerated, its impact on overall performance depends on how much runtime it originally consumed. If other operators, memory access, and cross-device communication do not improve synchronously, the overall gains will be limited. Therefore, these figures truly demonstrate that low-level optimizations can yield tangible benefits, rather than implying that the model achieves nearly 4x inference speed across all hardware.

The video concludes by discussing security issues related to open-weight models. The core assessment remains valid: providers of hosted APIs can deploy input/output checks, access controls, and monitoring mechanisms; once model weights are handed over to developers, these external safeguards do not automatically travel with the model.

Meta states that Muse Spark Open underwent additional safety post-training specifically for open-weight release and passed evaluations required by their release framework. However, this should not be interpreted as meaning that safety mechanisms are permanently embedded in the model and immutable, or that local deployment is inherently secure.

For agents capable of reading files, executing commands, and invoking software, actual risk still depends on tool permissions, the runtime environment, and the scope of operations. Keeping data local reduces the need to transmit information to external inference services; however, if a local model is granted excessive operational privileges, it can equally cause erroneous modifications or data loss.

References:

https://huggingface.co/meta-models/Muse-Spark-Open-816B-A42B

https://www.youtube.com/watch?v=-eG-hbmqcZg

https://research.meta.ai/static/muse-spark-open-evaluation-methodology

https://x.com/alexandr_wang/status/2110778736434184611