# Would I Buy Two Mac Studios for Muse Spark Open?

**Summary:** Meta describes running Muse Spark Open across two 512 GB M5 Ultra Mac Studios. I would test the model on useful work and measure local performance before buying hardware to replace an API bill.

- Canonical: https://markhuang.ai/news/muse-spark-open-two-mac-decision
- Language: en
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-15
- Section: News
- Tags: Muse Spark Open, Open Weights, Local Inference, Mac Studio, AI Deployment
- Source: [Meta AI Research](https://research.meta.ai/blog/muse-spark-open)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![Two linked aluminum desktop computers support a single intricate glass lattice with a small amber path glowing inside](https://cdn.markhuang.ai/news/muse-spark-open-two-mac-decision/hero.webp)

*A conceptual view of one large model spread across two desktops. Fitting the weights is the beginning of the deployment decision.*

[Meta released Muse Spark Open on October 15, 2026](https://research.meta.ai/blog/muse-spark-open), with 816 billion total parameters, 42 billion active parameters, and a million-token context window. Its desktop pitch is unusually specific: run the model with MLX across two M5 Ultra Mac Studios, each with 512 GB of unified memory.

I would want a successful workload evaluation and a measured local run before buying those machines. The release gives developers a way to control where the model executes. It does not establish how much useful work that desktop setup can deliver for the money.

I could justify local execution for control even if it costs more. To justify replacing an API bill on savings alone, I would need a cost per completed task.

## 42B active does not make this a small model

Meta's [developer guide](https://dev.meta.ai/resources/blog/build-with-muse-spark-open) describes a sparse mixture-of-experts model and puts its NVFP4 checkpoint at about 530 GB. The smaller active-parameter count describes what participates in each token's computation. The rest of the weights still need somewhere to live.

The guide explains how the Mac configuration handles that: MLX splits each layer across the two machines, which hold their shares of the weights and exchange intermediate results. Meta specifies direct Thunderbolt 5 connections with RDMA. This is a distributed inference setup that fits on a desk, with a runtime and interconnect to configure.

I would keep the million-token context claim separate from the memory claim, too. A published context limit does not tell me the latency or usable concurrency at that length on these machines. Before budgeting around a large repository, I would want measurements with its actual context and tool history loaded, using the exact quantization I planned to deploy.

Meta says it demonstrated entirely on-device agent workflows, including iOS changes to the Ice Cubes Mastodon client and editing footage in DaVinci Resolve. Those examples help explain the intended use. They do not give me a repeatable task-cost comparison for my workload.

## Local control can justify spending more

The strongest reason I see to run this locally is deciding where inference happens and keeping that part of a workflow inside a boundary I control. A team may reasonably pay more for that. [Engadget's coverage emphasizes the hardware investment](https://www.engadget.com/2287833/meta-built-a-huge-open-weight-ai-model-for-macs-but-youll-need-1tb-of-ram-to-run-it/), which helps temper the announcement's inviting desktop language.

My review would still cover the whole agent. If its tools send a search query or call another hosted service, local model execution alone cannot keep that traffic on the machine. Tool permissions and outbound connections belong in the deployment decision alongside the inference endpoint.

This extends the distinction I made about [Muse Spark 1.3's discounted Contributor tier](https://markhuang.ai/news/muse-spark-1-3-20-cent-output-data-clause): deployment choices carry data-policy consequences. Open weights add another option. An explicit need for control would be a good reason to choose it, provided I could accept the operational cost.

## The license deserves its own decision

The [Muse Model License](https://huggingface.co/meta-models/Muse-Spark-Open-816B-A42B/blob/main/LICENSE.md) allows use and modification subject to conditions, including displaying "Built with Muse Spark Open" in a product interface or specified accompanying materials. It also sets a separate-agreement requirement for qualifying Model as a Service businesses whose aggregate gross revenue, including affiliates, exceeds $20 million during any consecutive 12-month period. The clause expressly exempts internal use, research, and specified other uses, including features in a product that is not Model as a Service.

In the [Hacker News discussion](https://news.ycombinator.com/item?id=50107379), one commenter welcomed the range of supported runtimes, while another objected to separate licensing for large inference providers. Both points deserve attention. Broad runtime support helps deployment; the license determines which business arrangements need another agreement. I would check that before making the checkpoint a dependency in a service.

## I would qualify the model before buying its home

Meta lists hosted options including Baseten, Fireworks AI, and Together AI. That gives me a practical first step: evaluate a hosted version on representative work before committing to hardware. The record needs to include which checkpoint and settings the provider serves. A hosted result would help establish capability; local performance needs a separate test.

For that test, I would count tasks that pass review and record elapsed time and human intervention. The budget would include operating the machines and the hours they sit unused. A fast response matters less if I spend the saving correcting the result, and idle capacity still costs money.

If local execution is a requirement and Spark Open handles the work well, this release gives me a concrete configuration to investigate. If saving money is the goal, I would keep paying for evaluation calls until a measured local workload supports the purchase. I like having the option to own the inference setup. The announcement has earned an evaluation, and the hardware order can wait for its results.