Meta launches Muse Spark Open, billed as the US’s top open-source model, but falls short in programming benchmarks.
Meta launches Muse Spark Open, claiming to be the strongest open-source model in the US, but the programming benchmark is lacking.
Summary
Author | Dongmei Meta has brought large-scale agent models to desktop devices, but this “desktop” requires two high‑spec Mac Studios. On October 15 local time, Meta announced the launch
Meta has brought large-scale agent models to desktop devices, but this “desktop” requires two high‑spec Mac Studios.
On October 15 local time, Meta announced the release of Muse Spark Open model weights, focusing on software engineering, long‑range task execution, and multi‑step reasoning as primary application areas. Alongside the model weights, attention is also on its local deployment solution: using the MLX framework, developers can run the model on two Mac Studios equipped with M5 Ultra chips.
Meta positions it as the most capable open‑weight model from the United States to date.
Muse Spark Open adopts a sparse mixture-of-experts architecture, with a total parameter count of 8.16 trillion, activating about 4.2 billion parameters per token, and supports a context of 1,048,576 tokens. The model can accept text, images, audio, and video, and outputs text. Therefore, it can understand screenshots, videos, and recordings, but this does not imply native image, audio, or video generation capabilities.
This combination of capabilities points to workflows that require continuous operation. The model must not only understand user intent, but also plan steps, invoke tools, check execution results, and adjust actions when tools fail.
Meta’s model cards list end‑to‑end agent tasks, code writing and debugging, and long‑range tool invocation as primary use cases, while also covering synthetic data generation and model output evaluation.
In the official demo, Meta used Muse Code powered by Muse Spark Open to complete the iOS development of the open‑source Mastodon client Ice Cubes locally, involving bug fixes, feature additions, and a full build.
Another demo had the model operate DaVinci Resolve, inspecting footage frame by frame, selecting clips, and performing vertical cropping. These examples showcase the model’s ability to interface with real software, but they remain official demonstrations and cannot be directly inferred to mean all similar tasks can be performed unattended.
In terms of performance, Meta’s published results show Muse Spark Open scoring 61.8 on JobBench, MCP‑Atlas 89.2, and OSWorld Verified 80.4; for programming‑related tests, Terminal‑Bench 2.1 achieved 76.4 and DeepSWE 1.1 reached 60.
It is worth noting that in the Terminal‑Bench 2.1 and DeepSWE 1.1 tests, Muse Spark Open scored lower than the domestic open‑source models GLM 5.3 max and Kimi K3 max.
Objectively speaking, these results do not demonstrate a universally leading position across all projects.
Local deployment is an important highlight of this release, but the 42 billion activation parameters do not mean that only memory for a 42 billion‑parameter model is needed. The sparse architecture reduces the number of parameters involved in computation for each token, but the full weights still need to be loaded. According to the official documentation, the BF16 version weights are about 1.65 TB, the NVFP4 version about 537 GB, and additional space must be reserved for the KV cache, activations, and runtime overhead.
In the GPU deployment example provided by the official documentation, the BF16 version uses 8 B300 GPUs, and the NVFP4 version uses 4 B300 GPUs. The exact configuration also depends on accelerator memory, interconnect conditions, context length, and parallelization strategy.
It must be noted that “can run locally” means developers have the option to choose the deployment location, but it does not imply that an ordinary laptop can already handle such models.
Apple’s published research also showed distributed inference results from four Mac Studios: Muse Spark Open generates at a speed of over 36 tokens per second.
For teams that are not ready to build their own hardware, Muse Spark Open also offers a hosted access path. The official ecosystem partners listed include Baseten, Fireworks AI, Groq, Modal, Nebius, Together AI, and OpenRouter; deployment tools cover SGLang, vLLM, TensorRT‑LLM, llama.cpp, and MLX, among others. Developers can first verify task performance via the API and then assess whether it is worthwhile to deploy on their own.
Another point to note is that Muse Spark Open uses the Muse Model License, and open weights do not mean there are no commercial usage conditions. The license permits use, modification, fine‑tuning, distillation, and distribution of the model under the terms, and requires the designated attribution mark to be displayed in related products or documentation.
Specifically, for companies that provide the model as a service via APIs or similar methods, if the licensee and its affiliates have total revenue exceeding $20 million in any consecutive 12‑month period, the terms require them to notify Meta before using the model or derivative models for that business and to sign a separate written agreement.
This provision also lists exceptions, including internal use, research, non‑model‑as‑a‑service commercial activities, and using the model to support features of proprietary non‑model‑as‑a‑service products, so it cannot be simply summarized as “any company with annual revenue over $20 million must pay.”
From this release, we can see that competition among large open-weight models is extending to the actual deployment stage: whether the model can perform continuous software operations, integrate with existing tools, and how much hardware and operational cost developers need to bear are becoming as important as parameters and leaderboard scores.
Muse Spark Open increases the possibility of running large agent models locally, but moving from “downloadable” to “stably affordable” still requires validation under real-world workloads.
After the model’s release, it sparked heated discussion in overseas communities, and users on various platforms gave mixed reviews of this launch.
One netizen expressed reservations about the benchmark results: “Their models are always hyper‑optimized for the leaderboard; I don’t know whether to trust these numbers.”
Some also approve of Meta reopening model weights, but are dissatisfied with the terms of use: “The license is disappointing, but I’m glad Meta is once again paying attention to developers.”
Other users place more emphasis on the actual experience. One netizen believes that, based on reviews, Muse Spark Open “seems to be the second best open-weight model currently,” but it may be more competitive in real use: “The Muse Spark series performs exceptionally well in practice and always surprises me.”
Another user shared a comparison between other Muse series models and Gemini 4 Argon to see which series is stronger. He said that with the same prompts and each model’s highest available inference settings, Muse took about 40 minutes and cost roughly $30, while Argon took about 30 minutes and cost roughly $10. Regarding the results of this 3D task, he commented: “Muse truly surprised me… but I think Argon is slightly better.”
After Muse Spark Open was released, a YouTube creator analyzed the technical logic behind its desktop deployment.
Running a model with 816 billion parameters locally first confronts physical constraints: where to store the model weights, how compute units read those weights, and how multiple machines exchange data. Muse Spark Open’s desktop deployment requires the model architecture, numerical precision, memory system, and inference framework to work together.
The two numbers that are most easily confused are total parameters and activation parameters. Muse Spark Open has 816 billion total parameters, but about 42 billion parameters are activated per token. The former largely determines weight storage requirements, while the latter affects the computational load per token. They correspond to “can it fit” and “can it compute,” and cannot replace each other.
The model uses a sparse mixture‑of‑experts architecture. In a typical MoE layer, the routing network computes routing scores for different experts based on a token’s current hidden representation, assigns computation to a selected few experts, and then merges the results. This allows the model to avoid invoking all experts for every token.
In the video, the blogger likens this mechanism to a librarian: when answering a question, you don’t have to search the entire library, just retrieve the relevant books. Sparse architecture reduces the number of parameters involved in computation, but it does not eliminate the need to store all weights. Different tokens may invoke different experts, and the system still needs to make those expert weights accessible. Therefore, you cannot estimate memory requirements based on a dense model with 4.2 billion parameters just because the model activates roughly 4.2 billion parameters. The official documentation also clearly distinguishes these two concepts.
The blogger attributes the main reason for desktop deployment to MoE, but in fact, quantization is also an indispensable factor.
Estimating roughly two bytes per parameter, 816 billion parameters in BF16 alone would require about 1.63 TB, not including additional memory needed during inference. Two machines each equipped with 512 GB of RAM cannot directly accommodate the full model at this precision along with its runtime overhead.
Apple announced that the Muse Spark Open test uses NVFP4 precision instead of BF16. Reducing weight precision shrinks the model’s memory footprint, and multi‑machine parallelism further shares the weight and compute load, making this desktop deployment possible.
Therefore, a more complete technical explanation on this basis is: MoE reduces the active computation per token, quantization lowers weight storage overhead, multiple machines provide the required total memory capacity, and the inference framework coordinates distributed execution. No single factor can fully explain the results.
The video focuses on Apple Silicon’s unified memory architecture. Its key feature is that the CPU and GPU can access the same physical memory pool, reducing the need to copy data between system memory and discrete video memory in certain workflows, while allowing the integrated GPU to leverage a larger memory capacity.
But unified memory does not mean the memory bottleneck disappears. Compute units still need to read weights and intermediate data, and actual speed is still affected by memory bandwidth, access patterns, cache hits, and computational efficiency. Apple announced that the M5 Ultra’s unified memory bandwidth is 1.2 TB/s, but this is a metric for a single-machine memory system and cannot be treated as the communication bandwidth between two Macs.
Likewise, two Macs each with 512 GB of memory do not become a single machine with roughly 1 TB of memory that can be accessed at the same speed just because they are connected. Distributed execution requires partitioning the model or computation across different devices and then exchanging the necessary data via a communication mechanism. Apple’s solution uses RDMA over Thunderbolt and is supported by MLX’s collective communication library.
This means that local large‑model deployment faces both capacity and communication challenges. As the number of machines increases, even if the model fits, cross‑device synchronization and data exchange can still limit scaling benefits.
The latter part of the video introduces another noteworthy technical point: after the weights are released, the inference implementation still determines whether developers can use the model efficiently.
Meta introduced a custom Helion GPU operator integrated into SGLang in its release, stating that it achieves 1.03–3.95× operator‑level acceleration on NVIDIA and AMD GPUs, and about a 3% end‑to‑end acceleration on AMD MI350. The distinction between “operator‑level” and “end‑to‑end” must be preserved here.
A GPU operator is responsible for executing a specific class of computation, and its performance depends on data tiling, thread organization, memory access, and hardware resource utilization. Auto‑tuning tests different configurations to select a more suitable implementation for the target device and inputs. This does not mean that the optimal configuration is re‑explored for every token generation; Helion supports caching tuning results and also provides a workflow for pre‑tuning.
Even if a local operator is noticeably accelerated, its impact on overall performance still depends on how much runtime it originally consumed. Other operators, memory accesses, and cross‑device communication do not improve synchronously, so the overall gain is limited. Therefore, these numbers truly demonstrate that low‑level optimizations can yield tangible benefits, rather than implying that the model can achieve nearly four‑fold inference speed on all hardware.
The video concluded with a discussion of the security issues surrounding open weights. Its core judgment can be retained: the provider hosting the API can deploy input‑output checks, access controls, and monitoring mechanisms; once the model weights are handed to developers, these external measures will not automatically take effect with the model.
Meta stated that Muse Spark Open underwent additional safety fine‑tuning for the open‑weight release and passed the evaluations required by its release framework. However, this should not be interpreted as the safety mechanisms being permanently embedded in the model, immutable, or that local deployment is inherently safe.
For agents that can read files, execute commands, and invoke software, the actual risk still depends on tool permissions, runtime environment, and scope of operation. Keeping data locally can reduce the need to transmit it to external inference services; but if a local model gains excessive operational privileges, it can likewise cause erroneous modifications or data loss.
Reference links:
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
Disclaimer: This article is original to InfoQ, does not represent the platform’s views, does not constitute investment advice, and may not be reproduced without permission.
The QCon Global Software Development Conference 2026 (Shanghai edition) will be held from October 22–24. This year’s conference focuses on engineering practices in the Harness AI era, ranging from “building AI” to “harnessing AI”, covering hot technology areas such as AI‑Native architecture, Agent Runtime, AI Infra, Agent security and observability, Loop Engineering, embodied intelligence and world models. We invite the global tech community and frontline industry practitioners to share the most valuable engineering experiences of the AI‑Native era. For more details, scan the QR code or contact ticket manager 18514549229.
Get MirrorSpeed