Meta releases Muse Spark Open with 816B parameters, 42B active parameters and a 1M-token context

Meta has released Muse Spark Open, an open-weight multimodal AI model with 816 billion total parameters, approximately 42 billion active parameters per token and a context window of 1,048,576 tokens. The release extends Meta's Muse family toward downloadable model weights, agentic coding, long-context reasoning and deployment beyond proprietary Meta services.

The model uses a sparse Mixture-of-Experts (MoE) architecture. Approximately 5.15% of its parameters are active per token, but deployment still requires access to the much larger collection of model weights.

Meta also reports optimizations for Apple Silicon using distributed MLX inference. The model accepts text, images, audio and video as inputs, while producing text outputs.

Architectural specifications are not equivalent to independently verified performance. Model quality, million-token retrieval, latency, inference cost and hardware practicality must be evaluated separately.

··········

MUSE SPARK OPEN AT A GLANCE: ARCHITECTURE, CONTEXT, HARDWARE AND AVAILABILITY.

Meta released Muse Spark Open on October 15, 2026, through Meta Superintelligence Labs. Its primary targets include coding, multi-step reasoning, tool use and multimodal analysis.

........

Specification	Muse Spark Open
Developer	Meta Superintelligence Labs
Release date	October 15, 2026
Total parameters	816 billion
Active parameters	Approximately 42 billion per token
Architecture	Sparse Mixture-of-Experts transformer
Active parameter ratio	Approximately 5.15%
Context window	1,048,576 tokens
Input modalities	Text, images, video, audio
Output modality	Text
Training languages	More than 100
Native checkpoint	BF16
Quantized checkpoint	NVFP4
BF16 weight size	Approximately 1.65 TB
NVFP4 weight size	Approximately 537 GB
License	Muse Model License
Model weights	Downloadable
Primary applications	Coding, agents and multimodal analysis

........

The 42-billion figure describes active computation rather than total model size. Even a sparsely activated model requires access to its complete set of experts, making memory capacity a critical deployment constraint.

··········

HOW THE 816B-PARAMETER MIXTURE-OF-EXPERTS ARCHITECTURE WORKS.

A Mixture-of-Experts model distributes parameters across specialized expert networks. A router selects the experts used to process each token.

Unlike a dense transformer, not every parameter is active in each forward pass.

42 ÷ 816 × 100 = approximately 5.15% active parameters.

This leaves roughly 94.85% inactive for a typical token, while retaining a much larger total model capacity.

The ratio does not imply that inference requires 94.85% less computation than an 816B dense model. Attention operations, routing, device communication and memory movement contribute to actual execution cost.

Expert parallelism can require substantial bandwidth between accelerators. Performance depends on how efficiently weights are stored and routed, and whether the hardware can keep computation supplied with data.

The central trade-off is therefore large model capacity with sparse arithmetic, but substantial storage and memory requirements.

··········

THE ONE-MILLION-TOKEN CONTEXT WINDOW SUPPORTS LARGE REPOSITORIES AND EXTENDED AGENT WORKFLOWS.

Muse Spark Open supports a maximum context of 1,048,576 tokens.

This allows applications to supply extensive code repositories, technical documents, tool histories and instructions within a single request.

For coding agents, a larger context can reduce repeated summarization and enable examination of relationships across distant files.

However, context capacity does not establish perfect long-context retrieval or reasoning.

Information buried in a million-token prompt may be harder to retrieve accurately than information in a shorter, carefully curated input.

Longer sequences also increase processing time and key-value cache requirements.

Developers should measure retrieval accuracy, consistency and latency at the context lengths they actually expect to use, rather than assuming that the maximum advertised capacity is optimal for every task.

··········

NATIVE MULTIMODALITY COMBINES TEXT, IMAGES, AUDIO AND VIDEO.

Muse Spark Open accepts text, images, audio and video, but its documented output modality is text.

A coding agent could examine screenshots and source files together. A document-analysis system could interpret charts alongside written explanations. Video and audio inputs may support workflows involving recorded media.

These capabilities describe multimodal understanding, not native image, audio or video generation.

Performance can vary across modalities and combinations of inputs. Developers should test their specific tasks, including resolution, frame sampling, audio quality and the handling of long multimodal sequences.

··········

MUSE SPARK OPEN IS OPTIMIZED FOR CODING AGENTS AND LONG-HORIZON TASK EXECUTION.

Meta positions the model for software engineering, tool use and multi-step agent workflows.

A coding agent might inspect files, propose changes, run tests, interpret failures and revise its implementation. Such work requires reliable tool selection and recovery from errors, not simply strong single-turn reasoning.

The model's training emphasizes reasoning and agentic execution. Potential applications also include synthetic data generation and evaluation of model outputs.

Successful deployment depends on the agent framework, tool permissions, verification processes and task-specific constraints.

Cost per successfully completed task is a more useful operational metric than token pricing alone when workflows involve multiple attempts and tool calls.

··········

META RELEASES BF16 AND NVFP4 CHECKPOINTS WITH VERY DIFFERENT MEMORY REQUIREMENTS.

Meta provides BF16 and NVFP4 model formats.

BF16 uses 16-bit floating-point representation. NVFP4 compresses most weights to approximately four-bit precision while retaining selected higher-precision components.

........

Characteristic	BF16	NVFP4
Representation	16-bit floating point	Predominantly 4-bit
Approximate weight size	1.65 TB	537 GB
Reference configuration	Eight B300-class GPUs	Four Blackwell GPUs
Primary advantage	Reference precision	Reduced memory footprint
Main constraint	Very high memory demand	Quantization trade-offs

........

The published weight sizes imply approximately 67.5% less storage for NVFP4.

That reduction does not automatically apply to total runtime memory, which also includes activations, buffers and key-value cache.

Quantization can influence accuracy, so developers should benchmark the precise checkpoint they intend to deploy.

··········

META AND APPLE ENABLE LOCAL INFERENCE ON TWO M5 ULTRA MAC STUDIOS.

Meta collaborated with Apple to optimize Muse Spark Open for Apple Silicon through MLX.

The described setup uses two Mac Studio computers with M5 Ultra chips, each offering up to 512 GB of unified memory.

Their combined memory capacity can accommodate the quantized weights with remaining space for inference, depending on workload configuration.

Unified memory allows integrated GPU computation to access a large shared memory pool, while distributed inference requires efficient communication between the two machines.

Apple describes remote direct memory access techniques intended to reduce that overhead.

This is not equivalent to running the model on a standard consumer laptop. Two high-end workstations still represent a substantial hardware investment.

Practical deployment depends on memory bandwidth, inter-device communication, context length, token throughput and energy consumption.

··········

APPLE'S MLX RESEARCH MEASURES LATENCY, THROUGHPUT AND POWER CONSUMPTION.

Apple's technical evaluations examine local and distributed inference using MLX.

The main operational metrics include time to first token, generation throughput and peak power consumption.

Time to first token measures how long users wait before receiving an answer. Throughput measures output tokens per second after generation begins. Power consumption helps assess energy and operating costs.

Evaluations at context lengths such as 8,192 and 65,536 tokens provide useful practical evidence, but do not establish equivalent performance at the model's full million-token context.

Comparisons should also account for numerical precision and hardware configuration.

Results obtained with NVFP4 cannot automatically be compared with BF16 results from other models without controlling for differences in setup.

··········

DEVELOPERS CAN DEPLOY MUSE SPARK OPEN THROUGH MULTIPLE INFERENCE FRAMEWORKS.

Meta lists support for SGLang, vLLM, TensorRT-LLM, Hugging Face Transformers, llama.cpp, MLX and Unsloth.

These frameworks target different deployment environments and optimization requirements.

........

Hardware ecosystem	Deployment approach
NVIDIA Blackwell	SGLang, vLLM, TensorRT-LLM
AMD Instinct	Compatible vLLM deployments
Intel Xeon	Optimized low-precision inference
Apple M5 Ultra	Distributed MLX
Cloud providers	Managed inference APIs

........

Self-hosting offers control over execution and data handling, but requires infrastructure management and sufficient accelerator memory.

Hosted APIs reduce the initial hardware burden while introducing usage charges, external processing and provider dependencies.

The right choice depends on utilization, latency requirements, data governance and total operating cost.

··········

MUSE SPARK OPEN IS AVAILABLE THROUGH HUGGING FACE AND MAJOR CLOUD PLATFORMS.

Model weights are available through Hugging Face, with distribution through enterprise model catalogs including Amazon SageMaker AI, Google Cloud Model Garden and Microsoft Foundry Models.

Meta also identifies hosting partners such as Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter and Together AI.

These channels support research, managed inference and enterprise integration without requiring every developer to operate dedicated hardware.

Downloading the weights, however, does not make deployment inexpensive: storage, memory and inference engineering remain significant constraints.

Hosted inference may be preferable for intermittent demand. Self-hosting can become attractive when sustained workload volume justifies the hardware and operational investment.

··········

THE MUSE MODEL LICENSE IS NOT EQUIVALENT TO AN UNRESTRICTED OPEN-SOURCE LICENSE.

Muse Spark Open is distributed under the custom Muse Model License.

Downloadable weights provide meaningful deployment flexibility, but they should not be confused with unrestricted software distributed under permissive licenses such as MIT or Apache 2.0.

Organizations should review commercial eligibility, redistribution terms and applicable usage restrictions before integration.

Two models may offer comparable capabilities but materially different legal rights.

The licensing distinction matters especially for commercial AI services, customized deployments and products built on third-party weights.

··········

MUSE SPARK OPEN AND MUSE WONDER SERVE DIFFERENT DISTRIBUTION STRATEGIES.

Muse Wonder and Muse Wonder Full were announced earlier in October 2026. Muse Spark Open is a separate offering built around downloadable model weights.

........

Dimension	Muse Spark Open	Muse Wonder / Wonder Full
Distribution	Downloadable weights	Proprietary offering
Self-hosting	Supported	Service-dependent
Customization	Available through tooling	Depends on service terms
Primary emphasis	Coding and agentic workloads	Frontier model capabilities
License	Muse Model License	Proprietary terms

........

The open-weight release does not establish that Muse Spark Open matches Muse Wonder Full on every task.

Meaningful comparisons require common benchmarks, consistent reasoning settings, equivalent tools and normalized cost measurements.

The two approaches offer different trade-offs between model control, operational burden and managed-service convenience.

··········

BENCHMARK RESULTS REQUIRE COMPARABLE REASONING SETTINGS AND EVALUATION CONDITIONS.

Meta reports benchmark comparisons with competing open-weight models and uses an xhigh reasoning-effort configuration for principal evaluations.

Reasoning effort influences both task performance and compute consumption.

A model allowed to generate more reasoning tokens may score better while taking longer and costing more.

Coding benchmarks additionally depend on agent scaffolding, tool access, retry budgets and time limits.

Multimodal results depend on input formatting, resolution and evaluation methodology.

Meta's published results provide evidence of intended capabilities, but independent tests remain necessary before drawing conclusions about overall superiority.

The relevant question for developers is whether Muse Spark Open improves accuracy, reliability or cost on their own workloads.

··········

SELF-HOSTING ECONOMICS DEPEND ON MEMORY CAPACITY AND UTILIZATION.

Muse Spark Open illustrates the distinction between active computation and total weight memory.

Although only around 42 billion parameters participate per token, the deployment still needs access to the complete 816-billion-parameter model.

A company running a few agent tasks each day may find hosted inference cheaper than maintaining dedicated hardware.

A high-volume service may benefit from self-hosting if utilization is consistently high.

The comparison should include hardware rental or acquisition, electricity, cooling, engineering, memory, latency, throughput and maintenance.

Agentic workloads can involve retries and extensive contexts, so total cost per verified task is more informative than cost per output token alone.

··········

SAFETY EVALUATIONS AND MODEL GOVERNANCE REMAIN RELEVANT FOR OPEN-WEIGHT DEPLOYMENTS.

Meta describes safety evaluations under its Superintelligence Scaling Framework and additional safety post-training.

Open-weight distribution changes the operational responsibility: independent developers control the inference environment, tools and permissions.

An agent with terminal or repository access can cause unintended changes if authorization boundaries are too broad.

Deployers should use least-privilege permissions, sandboxing, monitoring, test environments and approval requirements appropriate to the task.

Model-level safety evaluation does not guarantee the safety of every application built around it.

··········

WHAT DEVELOPERS SHOULD VERIFY BEFORE ADOPTING MUSE SPARK OPEN.

The adoption decision should be based on workload-specific measurements rather than parameter count alone.

........

Evaluation dimension	Practical question
Model quality	Does it outperform alternatives on the intended task?
Long context	Can it retrieve and combine distant information?
Coding agents	How often does it complete tasks without intervention?
Tool use	Can it recover from failed tool executions?
Multimodality	Which input combinations perform reliably?
Latency	How quickly does it respond at realistic context lengths?
Throughput	How many concurrent requests are sustainable?
Memory	Can the hardware hold weights and runtime cache?
Quantization	Does NVFP4 materially affect accuracy?
Licensing	Are intended commercial uses permitted?
Security	Are tools and permissions adequately restricted?
Economics	What is the cost per successfully completed task?

........

The model's scale makes careful infrastructure planning essential, even when sparse computation and quantization reduce parts of the execution burden.

··········

META'S RELEASE EXPANDS OPEN-WEIGHT ACCESS TO FRONTIER-SCALE AGENTIC AI.

Muse Spark Open combines 816 billion total parameters, 42 billion active parameters and a one-million-token context window in an open-weight model designed for coding, multimodal understanding and agentic workflows.

Its distribution through downloadable checkpoints and hosted providers expands developer choice.

The collaboration with Apple also demonstrates how large unified-memory systems can support distributed inference for models previously associated primarily with accelerator clusters.

However, memory requirements remain substantial, the custom license warrants review and performance claims require workload-specific verification.

The model's practical significance lies in combining frontier-scale capacity with sparse computation and deployable weights—not in guaranteeing inexpensive local inference or universal benchmark superiority.

··········

FOLLOW US FOR MORE.

DATA STUDIOS

datastudios.org