Meta Muse Spark Open Runs on Mac Studio: Apple’s Local AI Breakthrough

Meta Muse Spark Open Runs on Mac Studio: Apple’s Local AI Breakthrough

Mark Zuckerberg once criticized Apple for failing to invent anything remarkable since the iPhone. Now, Meta’s CEO is publicly thanking Apple and its new CEO, John Ternus, for helping bring one of Meta’s most capable open-weight AI models to Mac Studio.

The collaboration centers on Muse Spark Open, an 816-billion-parameter model that can run locally across multiple Apple Silicon systems. Using Apple’s MLX framework and high-speed Thunderbolt 5 interconnects, developers can run demanding AI workloads—including coding agents, long-context reasoning, and video analysis—without sending inference requests to a model provider’s cloud.

The announcement highlights a broader shift in AI infrastructure. As models become more capable and handle increasingly sensitive information, developers are looking beyond centralized cloud services toward systems they can deploy and control themselves.

Apple’s unified memory architecture, custom silicon, and developer tooling provide a foundation for this transition. Meanwhile, Meta’s release of model weights gives developers the freedom to choose where and how inference takes place.

The result is a new role for the desktop: not merely a client for cloud-based AI, but a potential local AI workstation capable of running frontier-scale models.

🤝 Meta Supplies the Model, Apple Supplies the Platform

#

Meta’s release of Muse Spark Open follows its earlier commitment to expand its open-weight model lineup. The new model contains 816 billion total parameters, with approximately 42 billion active during each inference pass, and supports a context window of up to one million tokens.

Meta describes it as the most capable US-developed open-weight model to date. Its intended applications include complex reasoning, software engineering, and multi-step agent workflows.

Developers can obtain the model weights through supported distribution platforms, deploy them on compatible hardware, and customize the model using tools such as PyTorch. The model is also available through hosted inference providers, giving teams a choice between self-managed infrastructure and cloud-based access.

The distinction between open weights and hosted APIs is important. A hosted API provides access to model capabilities, but the provider generally controls the inference environment. With downloadable weights, developers gain substantially more control over deployment, data handling, model customization, and operational policies, subject to the model’s license and applicable requirements.

Meta AI leadership has acknowledged that the open-weight model does not necessarily match the capabilities of every closed-source model in Meta’s broader portfolio. Its appeal lies in giving developers direct access to the model and greater freedom over their execution environment.

Zuckerberg and Ternus Publicly Acknowledge the Collaboration

#

Zuckerberg shared a photo of Meta AI agents running on a Mac, highlighting the collaboration with Ternus and Apple. Ternus responded by emphasizing how exciting it is to run a model of this scale efficiently on a desktop.

The public exchange is notable because Apple and Meta have historically competed in consumer technology and platform ecosystems. Yet local AI creates a shared technical interest: Apple can demonstrate the capabilities of its hardware, while Meta can expand the reach of its models beyond centralized infrastructure.

According to Meta AI chief Alexandr Wang, the companies had been working together for months. Daniel Gross, a former Apple employee who later joined Meta, reportedly played a role in the collaboration. Meta had also acquired hundreds of Macs earlier in the year for its superintelligence team to investigate local AI and agent-based applications.

The partnership therefore extends beyond a promotional demonstration. It reflects a practical effort to make very large models usable on commercially available desktop hardware.

Local Inference Changes the Data-Control Equation

#

When a model runs entirely on hardware controlled by its user or organization, inference requests do not need to be sent to the model developer’s servers.

That changes the data-governance model in several ways:

• Individuals: Personal documents, prompts, and private projects can remain on locally managed infrastructure.
• Developers: Source code and repository context can be processed without automatically transmitting them to an external inference provider.
• Enterprises: Teams can design deployments around internal access controls, security policies, and data-retention requirements.
• Researchers: Model behavior and inference workflows can be evaluated in environments they control.

Local execution does not automatically guarantee complete privacy. Applications may still use external services, transmit telemetry, or connect to remote tools. Effective privacy therefore depends on the full application stack, network configuration, and deployment policies—not just the location of the model weights.

Nevertheless, open-weight models make self-managed inference a practical option for organizations that need more control over sensitive data.

🧠 How an 816-Billion-Parameter Model Runs Across Multiple Macs

#

Running a model of this size on desktop hardware presents two fundamental challenges: memory capacity and inference performance.

Muse Spark Open uses a Mixture-of-Experts (MoE) architecture. Although the model contains 816 billion parameters, approximately 42 billion are active during a given inference pass. A routing mechanism selects relevant experts for each input, reducing the computation required compared with activating every parameter for every token.

However, inactive parameters still need to be available when the model selects them. MoE reduces active computation, but it does not eliminate the memory needed to store the full model.

Quantization Reduces the Memory Footprint

#

According to Apple’s machine learning research, storing Muse Spark Open in its native BF16 precision requires more than 1.6 TB of memory for the parameters alone.

Apple’s demonstration instead uses an NVFP4 four-bit quantized version, reducing the model’s footprint to approximately 493 GB.

Quantization represents model parameters with fewer bits, substantially reducing storage and memory-bandwidth requirements. The trade-off is that lower numerical precision can affect model behavior, depending on the quantization method and workload.

Even at approximately 493 GB, the model leaves little room for other memory consumers on a Mac Studio configured with 512 GB of unified memory. The runtime, operating system, temporary computations, and key-value (KV) cache also require memory.

As a result, a single 512 GB Mac Studio is not a comfortable fit for this particular configuration. Distributing inference across multiple machines provides the capacity and bandwidth needed to run the model more effectively.

Pipeline Parallelism vs. Tensor Parallelism

#

Apple’s MLX framework supports distributed inference across multiple Macs. Two important strategies are pipeline parallelism and tensor parallelism.

Pipeline parallelism assigns different groups of model layers to different machines. One Mac processes the initial layers and passes intermediate results to the next machine, which continues the computation.

This approach distributes the model across available memory, but the sequential dependency between stages can limit how efficiently all machines work at the same time.

Tensor parallelism divides operations within a layer across multiple machines. Devices can perform parts of the same computation concurrently, then exchange and combine intermediate results.

Tensor parallelism can improve throughput, but it requires more frequent communication between machines. Network latency and bandwidth therefore become critical performance factors.

Apple’s approach combines MLX with RDMA communication over Thunderbolt 5, reducing communication overhead for distributed workloads. The demonstrated setup uses direct Thunderbolt connections, with dual cables between paired machines to increase available link bandwidth.

Benchmark Results: From Two Macs to Four

#

Apple’s published benchmark measures model generation after an 8,192-token prompt, followed by the generation of 128 tokens.

Switching from pipeline to tensor parallelism on two machines increases generation throughput by approximately 59%. Expanding the setup to four machines raises throughput further, reaching 36.73 tokens per second.

Apple also reports that the four-machine configuration reduces time to first token to approximately 4.8 seconds, compared with around 8.2 seconds for the two-machine tensor-parallel setup.

These results illustrate how distributed inference can turn several desktop workstations into a usable environment for a model that would otherwise exceed the memory capacity of a single machine.

The figures are vendor-published benchmarks rather than independent comparisons across every possible hardware and software configuration. Actual performance will vary with context length, quantization, runtime version, memory pressure, and workload.

Why Apple Silicon Is Well Suited to Local AI

#

The demonstrated system depends on several hardware and software capabilities working together.

• Unified memory: CPU and GPU components share a large memory pool, simplifying access to model weights and intermediate data.
• High memory bandwidth: The M5 Ultra provides up to 1.2 TB/s of unified-memory bandwidth, compared with 819 GB/s for the M3 Ultra.
• GPU Neural Accelerators: Dedicated matrix-multiplication capabilities improve performance for suitable AI workloads.
• MLX: Apple’s framework provides optimized machine-learning operations and support for distributed inference.
• Thunderbolt 5 with RDMA: High-speed, low-overhead communication allows multiple Macs to coordinate their computations.

These capabilities affect different parts of inference performance. Time to first token measures the initial wait while a model processes the prompt, whereas token-generation throughput measures how quickly output continues after generation begins.

Apple reports that, in its tests of Qwen 3.8 and Mistral Medium 3.5, the M5 Ultra achieves up to a 4.6× improvement in time to first token and approximately 1.6× faster generation compared with the M3 Ultra. Those results apply to the tested models and configurations rather than every AI workload.

The broader point is that local AI performance depends on more than peak compute figures. Memory capacity, memory bandwidth, interconnects, quantization, and runtime optimization all influence which models a desktop can run and how responsive they feel.

Local Coding Agents and Video Workflows

#

Apple and Meta also demonstrated agent-based workflows using Muse Spark Open locally on Mac Studio.

For software engineering, a coding agent can inspect project context, generate changes, and work through multi-step development tasks while using a local inference server. Apple’s examples include making changes to an open-source iOS application and building the resulting project.

Video workflows provide another example. An agent can examine footage frame by frame, identify promising segments, and assist with editing tasks in applications such as DaVinci Resolve.

These demonstrations show that local AI is not limited to conversational interfaces. When connected to appropriate tools, a model can support longer-running workflows involving code, files, and creative applications.

Developers can also connect a local MLX model server to compatible agent frameworks, including OpenCode, allowing the user-facing tool to remain familiar while inference takes place on the local cluster.

For more background on Apple hardware and local inference, see M4 Max Mac Studio Beats GB10 and Strix Halo in Local AI.

Cost and Accessibility Remain Major Constraints

#

The ability to run a model locally does not mean that every user can do so economically.

High-memory Mac Studio configurations are expensive, and the 512 GB model configuration required for the demonstration represents a substantial investment. Running Muse Spark Open also requires multiple machines, appropriate Thunderbolt connections, compatible software, and sufficient storage for the model files.

This makes the setup most relevant to professional developers, AI researchers, and engineering teams that value local control and can justify the hardware expense.

For smaller models, a single computer may provide a more practical balance of cost, performance, and privacy. Large distributed setups are most compelling when a workload genuinely benefits from their memory capacity or computational throughput.

🖥️ Apple’s Minions Project Turns Idle Macs into Shared Compute

#

While multi-Mac inference addresses the challenge of running a single massive model, Apple researchers are exploring another way to use Apple Silicon: pooling the idle GPU capacity of computers already deployed across an organization.

Their research system, Minions, aims to create a dynamic distributed inference pool from existing Mac devices. Rather than requiring every participating machine to host the same large model, the system distributes independent tasks across available computers.

The underlying observation is straightforward. Engineering teams may face long queues for centralized GPUs while colleagues’ Macs spend much of the day performing relatively lightweight tasks, such as email, document editing, and routine development work.

Minions attempts to make that unused capacity available for workloads that can be divided into independent pieces.

Distributed Tasks Instead of One Shared Model

#

When a user submits a workload, Minions breaks it into smaller tasks. Participating Macs retrieve assigned work, execute it using their local GPUs, and return results to shared storage.

This approach differs from the tightly coordinated cluster used to run Muse Spark Open.

A distributed model cluster divides the execution of one model across machines, often requiring frequent exchanges of intermediate data. Minions instead targets workloads that can be decomposed into largely independent tasks.

Current examples include:

• Text embeddings: Generating vector representations for semantic search, indexing, and retrieval pipelines.
• Local LLM generation: Processing batches of independent prompts through supported local inference engines such as Ollama.
• Batch inference: Distributing large collections of tasks across available devices without requiring every task to run on the same machine.

Because the tasks are largely independent, the system can make productive use of heterogeneous devices without coordinating every computation at the same fine-grained level.

Fault Tolerance for a Changing Fleet of Devices

#

Office computers are not stable, dedicated servers. A laptop may go to sleep, a network connection may fail, or a user may need local GPU resources for an interactive application.

Minions is designed to account for these changes by monitoring participating devices and reclaiming unfinished work when a node becomes unavailable. Uncompleted tasks can then be reassigned to other available machines.

This dynamic scheduling model makes a fleet of ordinary computers more practical as a shared compute resource.

Organizations can also configure which teams, projects, or tasks are permitted to use particular devices. The goal is to align resource sharing with internal access controls and data-governance requirements rather than creating an unrestricted pool of corporate hardware.

Shorter Queues Without Buying More GPUs

#

According to the paper’s reported experience, tasks that previously waited more than ten hours for centralized GPU resources could often begin within minutes under Minions.

The improvement comes from making existing compute capacity available on demand, rather than relying exclusively on additional centralized accelerators.

That does not mean idle Macs can replace a GPU cluster for every workload. Their usefulness depends on task size, device availability, network conditions, and the capabilities of the local GPU and software stack.

Minions is best understood as a complementary infrastructure layer: it can help teams process suitable inference workloads using hardware they already own, while reserving centralized GPUs for work that needs them most.

The researchers identify distributed model training as a possible future direction, but the current emphasis is on inference and task execution.

For a related look at why AI developers are acquiring large numbers of Apple computers, see Why Mac Mini Supply Is Tight: OpenAI, Anthropic and AI Agents.

🔐 Open Weights and Local Hardware Strengthen AI Sovereignty

#

Muse Spark Open and Minions address different dimensions of the same infrastructure challenge.

Muse Spark Open demonstrates how high-memory machines and fast interconnects can run a very large model locally. Minions explores how existing computers can collectively process workloads by contributing otherwise unused GPU capacity.

Together, they illustrate three emerging patterns for desktop and edge AI:

1. Single-device inference: A computer processes private or specialized workloads locally when the model fits within its available resources.
2. Distributed model inference: Multiple connected machines cooperate to host and execute a model that exceeds the practical limits of one device.
3. Distributed batch processing: A fleet of existing computers independently executes tasks to improve overall resource utilization.

These patterns are complementary rather than interchangeable. A large model may need tightly coordinated memory and communication across machines, while a collection of embedding jobs may be distributed with far less coordination.

The privacy implications also deserve careful consideration. Self-hosting can reduce reliance on external inference services, but organizations still need to manage access permissions, application integrations, logging, network traffic, and the security of the devices themselves.

Open weights provide control over deployment; they do not automatically provide a secure deployment.

🚀 The Mac’s Emerging Role in the AI Era

#

The collaboration between Apple and Meta signals a convergence of model development and personal computing infrastructure.

Meta gains another route for distributing its models and demonstrating their capabilities. Apple, meanwhile, can showcase the value of its investments in unified memory, high-bandwidth silicon, machine-learning frameworks, and fast device interconnects.

The technical achievement is not simply that a model with 816 billion parameters can be loaded across several Macs. It is that the combined system can generate responses at interactive speeds while supporting real development and agent workflows.

Minions adds a complementary idea: even computers that are not powerful enough to host a massive model independently may still contribute valuable compute to suitable distributed workloads.

Significant constraints remain. High-memory hardware is expensive, distributed inference introduces communication overhead, and local execution requires deliberate security and operational management. The economics will differ substantially between individual developers and organizations with existing Mac fleets.

Nevertheless, the direction is clear. AI infrastructure is expanding beyond centralized data centers into workstations, desktops, and distributed pools of edge devices.

As models become more capable and interact with increasingly sensitive information, the ability to control where inference happens is becoming an important architectural choice. Open-weight models provide the flexibility, while local hardware and distributed software turn that flexibility into a working system.

For Apple, the opportunity is to make the Mac more than a destination for AI applications: it can also become the infrastructure on which those applications run.