AI news, with the context that matters.

Products & Services · ·

Muse Spark Open releases its weights: can you own a powerful AI at home?

An 816B model now runs across two Mac Studios. Its 42B active parameters, roughly 493GB of quantized weights, and distributed inference measurements show what changes for a local-LLM budget of one or two million yen.

If you want to run a powerful AI on your own hardware, the question is what work can actually move off the cloud. Our earlier local-LLM column examined budgets of one and two million yen. Meta’s October 15 release of Muse Spark Open adds a concrete candidate, including a way to distribute the large model across two Mac Studios.

The change is access to model weights that you can use for inference yourself. Memory capacity, time spent processing input, and the application that executes tools determine what you must buy and assemble to own an agent.

Key takeaways

  1. Muse Spark Open is an MoE model with 816B total and 42B active parameters. Activating a subset reduces computation, while memory is still needed to hold the full model.
  2. Apple measured 24.99 generated tokens per second using NVFP4 and tensor parallelism on two 512GB M5 Ultra Mac Studios. The test used 8,192 input tokens, 128 generated tokens and batch size one; it does not establish performance at a million-token context or whole-job completion time.
  3. Two base machines start at a combined ¥1,899,600, which is not the price of the tested 512GB configurations. The 512GB version is scheduled for late October. The weight release also excludes the full Muse service, so an agent application and integrations must be supplied separately.

A concrete system for owning the model

What you own: the model and its execution system

Weights → two Macs → a local API → an agent application

Store the model

Load the NVFP4 weights in partitions. Each Mac has 512GB of unified memory.

Run inference together

Exchange intermediate results using Thunderbolt 5 RDMA. MLX handles distributed computation and communication.

Let an application execute the work

An application queries the local API and executes the returned tool calls. It also handles file access and approvals.

Figure 1. System outline based on Apple’s distributed inference and local-agent examples. Downloading weights alone does not supply application integrations or approvals.

Apple: distributed inference and a local API with MLX

Muse Spark Open targets coding and multi-step work. Its model specification accepts text, images, video, and audio and produces text. Meta lists choosing tools and recovering from failures among its intended uses. One million tokens is its inference context limit.

Meta reports 89.2 on MCP-Atlas and 76.4 on Terminal-Bench 2.1. The latter uses the Terminus 2 agent, and Muse is evaluated at xhigh reasoning effort. These results help identify candidate workloads; they are not measurements reproducing the same scores or completion times on a home Mac setup.

Meta model card: specifications, use cases, and evaluation conditions

42B active still means storing 816B parameters

816B means 816 billion parameters, and 42B means 42 billion. An MoE model selects experts for each token. Muse Spark Open selects eight of 256 experts, computing with only part of the model. Different tokens can need different experts, so 42B active does not mean it can be stored in the memory of a 42B model.

Storage and per-token computation are different

MoE and quantization reduce different costs

Store 816B

Keep the full model weights available so that routing can select different experts.

Activate 42B

Compute with a subset for each token, reducing work relative to activating all 816B parameters.

Store more compactly with NVFP4

Represent weights with fewer bits. Smaller weights still leave additional memory needs for context and intermediate computations.

Figure 2. Quantization reduces weight storage; MoE reduces the active computation. The 42B figure cannot be converted directly into the required memory.

Model card: selecting eight of 256 experts

Apple puts the BF16 weights above 1.6TB and the NVFP4 model footprint at roughly 493GB. Intermediate computations push it beyond a single 512GB Mac. Meta’s inference requirements are also larger: 700GB of VRAM for NVFP4 and 2TB for BF16. The roughly 493GB weight footprint is distinct from the requirements of an inference system.

Apple: the NVFP4 footprint and why one machine is insufficient

How two Macs share the work changes speed

Unified memory lets a Mac’s GPU use the large shared memory pool rather than requiring a separate allocation of dedicated GPU memory. Two 512GB machines provide a combined terabyte. A cable alone does not make them one GPU: MLX partitions the model and exchanges intermediate results.

M5 Ultra has 1.2TB/s of memory bandwidth. Capacity determines how much of a model can be stored, while bandwidth affects how quickly weights can be read. This is bandwidth within each Mac, not the speed of the Thunderbolt link between them.

Apple: M5 Ultra unified-memory capacity and bandwidth

Two ways for the same two Macs to divide the work

Split the layers into stages, or split computation within each layer

Pipeline parallelism

Mac A evaluates the earlier layers → sends intermediate results → Mac B evaluates the later layers. This straightforwardly expands capacity.

Tensor parallelism

Macs A and B share computation within each layer → combine their results. More work runs concurrently, with more frequent communication.

Communication is part of inference

Distributed computation adds time spent exchanging results. More machines do not guarantee a proportional reduction in the time for an entire job.

Figure 3. Comparison of parallelization strategies. Frequent communication makes latency particularly important for tensor parallelism, which is why Apple uses Thunderbolt 5 RDMA.

MLX documentation: distributed execution and JACCL setup

RDMA enables data transfers between the memories of separate machines. Apple’s test links each pair with two Thunderbolt cables and uses MLX’s JACCL backend. Official setup includes compatible macOS 26.2-or-later systems, enabling RDMA in Recovery, SSH access, and a host configuration. The owner must prepare the distributed environment.

Separate generation speed from job completion

The following Apple measurements use NVFP4, an 8,192-token context, 128 generated tokens, and batch size one. They distinguish the time until the first token from the subsequent generation rate.

M5 Ultra setup Time to first token Generation rate
Two Macs, pipeline 8.4 seconds 15.74 tokens/s
Two Macs, tensor 8.2 seconds 24.99 tokens/s
Four Macs, tensor 4.8 seconds 36.73 tokens/s

Apple Tables 2 and 3: first-token latency and generation at 8,192 tokens

Generation speed changes even with the same machine count. Dividing 24.99 by 15.74 gives about 1.59 times the rate for tensor parallelism. This calculation from the published values does not show that a coding or video-editing job finished 1.59 times faster.

An agent reads input, reasons, invokes tools, and reads the results. A whole job also depends on how many tokens it generates, tool delays, and retries. A one-million-token limit does not establish 24.99 tokens per second at that length. LATENT has not benchmarked this hardware configuration.

The measured system is not yet a ¥2 million purchase plan

Apple’s Japanese announcement lists the M5 Ultra Mac Studio from ¥949,800 including tax. Two base machines therefore total ¥1,899,600. That is not a quote for two of the tested 512GB configurations.

Apple schedules the 512GB configuration for late October. The official sources checked as of October 16 did not establish its final price. They do not support a purchase plan promising the same environment immediately for two million yen.

Apple Japan: starting price and planned availability of the 512GB configuration

Our earlier local-LLM column on one- and two-million-yen budgets weighed the capacity of a single GPU or Mac against the work assigned to it. Muse Spark Open adds a multi-machine route to an approximately 800B-class model. That choice also brings networking setup and responsibility for operating two computers.

Owning the system removes the need to pay a model provider per inference, but hardware, electricity, storage, and maintenance remain. A break-even comparison with an API requires actual usage and the price of the chosen hardware.

An agent needs software around the weights

Apple demonstrates running an MLX local server as the endpoint for OpenCode. In this arrangement, the model produces tool calls and the application executes actions such as file edits. Approvals, work records, and authentication for connected services are surrounding components.

The distinction between a model, an execution tool, and an ongoing service in our Muse Wonder, Muse Code, and Muse app comparison still applies. Spark Open’s weight release does not mean that Wonder or the Muse service’s memory, integrations, and managed execution environment have all been distributed.

Meta’s release covers Muse Spark Open weights

Input support also depends on implementation. The model card includes audio, while the checked Muse implementation in MLX LM marks the audio tower as unsupported and excludes its weights during loading. Model specifications and features available in a particular runtime must be checked separately.

MLX LM implementation: vision, distributed execution, and the unsupported audio tower

Use and redistribution have Muse-specific terms

The weights use the Muse Model License. It permits use, modification, redistribution, and commercial use subject to conditions, including retaining the notices, license, and Usage Policy and displaying “Built with Muse Spark Open” for products using it. Public weights do not imply unconditional permission.

For a Model as a Service business providing models to third parties through APIs or similar interfaces, aggregate gross revenue above US$20 million over any consecutive twelve months, including affiliates, requires notice to Meta and a separate written agreement. This clause excludes internal use, research, and use as a feature in a product that is not Model as a Service. Local use and offering a model API to others therefore need to be distinguished.

Muse Model License, sections 1–3, on the distribution page

Test the work and waiting time before buying

Muse Spark Open makes hosting a very large model at home a concrete system with specified capacity, communication, and measured performance. It matters to people who want to test coding or multi-step work that smaller models cannot handle without sending inference to an external service.

The available hosted APIs offer a way to try representative tasks before buying hardware. That tests answer and task quality; Mac performance is a separate test. Local evaluation should cover required input types, normal context lengths, and time to complete a job with the chosen application.

Meta announcement: weights and hosted API providers

The same day’s Nemotron 3.5 Bolt takes the approach of compressing a model toward a 24GB budget. Muse Spark Open retains a large model across multiple computers. Reusing existing hardware and acquiring a new high-capacity system are now two concrete directions to add to the earlier budget comparison.