Muse Spark Open on Two Macs: Local vs Hosted Cost

By Lazar Milicevic · Published October 28, 2026 · 10 min read

You're a founder or ops lead looking at an open-weights model and wondering whether "run it yourself" is finally realistic, or still a trap for people with GPU clusters. Meta's Muse Spark Open changes the hardware math: an 816B-parameter model that fits on two paired Mac desktops instead of a rack. Before you spend five figures, here is what the model is, what the setup demands, where the license bites, and how to decide between local and hosted.

What Muse Spark Open is (and what Meta's claims actually mean)

Muse Spark Open is an open-weights model from Meta Superintelligence Labs with 816B total parameters, 42B active per token, and a 1M-token context window (Hugging Face model card). Meta released it on 15 October 2026, and the weights are on Hugging Face under the Muse Model License (PyTorch blog).

The architecture is why the Mac story works at all. It's a mixture-of-experts design: 256 experts per MoE layer, with each token routed to 8 of them. All experts stay in memory, so you need the memory footprint of an 816B model, but you get roughly the generation speed of a 42B model (Hugging Face blog). That's the trade: memory is the constraint, compute is not.

Now the caveat you should hold onto. "Most capable US open-weights model" is Meta's own claim. It is not "the best open model." On Meta's own benchmark table, it leads on MCP-Atlas, a tool-use benchmark, at 89.2 versus 84.2 for GLM 5.3, 82.3 for Kimi K3 and 84.5 for Qwen3.8. It trails Kimi K3 and GLM 5.3 on Terminal-Bench 2.1, a coding benchmark, at 76.4 versus 85.0 and 83.9 (VentureBeat). Chinese models also score higher on several tests and on the aggregate index Meta cites. That index figure in the model card comes from Meta itself, so look for independent third-party evaluations before you lean on it.

What that means for an SMB: this is a strong candidate for tool-calling agent workflows, a weaker pick if your main use case is autonomous coding, and in neither case a model to adopt on a press release. Run your own eval.

The hardware reality: what "two Macs" actually means

The headline setup is two M5 Ultra Mac Studios with up to 512GB of unified memory each, about 1TB combined (VentureBeat). Meta documents two NVFP4 configurations with MLX: two machines at 512GB each, or four at 256GB each. Every machine needs macOS 26.2 or later and MLX 0.30.1 or later, with direct Thunderbolt 5 links between each pair (AppleMagazine).

Compare that with the datacenter path. Meta's model card says self-hosting on GPUs needs at least 700GB of VRAM for the NVFP4 checkpoint and 2TB for BF16, with SGLang, vLLM, TensorRT-LLM, Unsloth and llama.cpp among the supported frameworks (model card). Unified memory is what lets a desktop box compete on capacity.

How the two machines split the work matters for speed. With MLX tensor parallelism, every layer is split across both machines: each holds half the weights and does half the computation per token, and only small intermediate results cross the link (Meta AI developer blog). That's why the direct Thunderbolt 5 connection is a requirement, not a suggestion.

A rough shape of the cluster setup (check Meta's developer guide for the exact, current commands, since this is a sketch of the workflow and not a copy-paste recipe):

# On BOTH Macs: confirm the OS and MLX versions Meta requires
sw_vers -productVersion        # needs 26.2 or later
pip install -U mlx             # needs 0.30.1 or later
python -c "import mlx.core as mx; print(mx.__version__)"

# Machines must be directly linked over Thunderbolt 5.
# Then launch with MLX's distributed tooling, using tensor
# parallelism (not pipeline parallelism). Follow Meta's guide for
# the model path, hostfile and launch flags:
# https://dev.meta.ai/resources/blog/build-with-muse-spark-open

Can you actually buy it today?

This is where I'd slow down. The Mac Studio launched on September 22, 2026, starting at $2,499 with M5 Max and $5,499 with M5 Ultra; the 512GB RAM option came later (MacRumors roundup). The 512GB M5 Ultra was announced for "late October" availability, with US pricing expected to start well above $10,000 (MacRumors). As of today, 28 October 2026, I can't confirm it's orderable or shipping, so check Apple's store before you plan around it. I'm also not going to give you a total hardware cost, because no verified price exists for the 512GB configuration.

Speed: what you can realistically expect

Treat any speed number as a range, not a spec. iClarified, citing Apple-published benchmarks, reports about 24.99 tokens/sec on two M5 Ultra Mac Studios with tensor parallelism, versus 15.74 tokens/sec with pipeline parallelism (iClarified). I haven't seen that figure independently reproduced, so measure it on your own prompts.

Whatever the exact number, here's what it means in practice:

• Single-user, interactive use works. Tokens/sec in the low tens is readable in a chat window and fine for an agent working through a task queue overnight.
• Concurrency is the unknown. A desktop pair serving one person is a different thing from serving a team of ten. No verified source gives concurrent-user throughput for this setup, so measure it yourself before putting a team on it.
• Agent loops multiply latency. An agent that makes 15 model calls per task at 25 tokens/sec feels very different from one that makes 2. Measure end-to-end task time, not tokens/sec.

If you build this, benchmark your own prompts. A small harness is enough:

import time
from openai import OpenAI  # works against any OpenAI-compatible local/hosted endpoint

client = OpenAI(base_url="localhost api_key="local")

def run(prompt: str, max_tokens: int = 400):
    t0 = time.time()
    resp = client.chat.completions.create(
        model="muse-spark-open",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=max_tokens,
    )
    dt = time.time() - t0
    out = resp.usage.completion_tokens
    return {"seconds": round(dt, 1), "out_tokens": out, "tok_per_s": round(out / dt, 1)}

# Use YOUR real prompts: an invoice extraction, a lead-reply draft, a triage call.
print(run("Summarize this support thread and propose a reply: ..."))

Run the identical script against a hosted endpoint and your local pair. Same prompts, same harness, then compare.

The hosted alternative: what it costs

You don't have to buy hardware to use this model. Seven inference providers offered hosted access at launch, including Groq and Fireworks AI, and the weights are also in the model catalogs of AWS, Google and Microsoft (SiliconANGLE).

One published price point: Together AI serverless lists $1.25 per 1M input tokens and $4.25 per 1M output tokens ($5.50 combined) (VentureBeat). Prices vary by provider and change, so verify on the provider's current pricing page before budgeting.

Here's a clearly labelled illustrative example with round numbers, not a benchmark: say an agent workflow processes 2M input tokens and 500K output tokens a day.

# ILLUSTRATIVE ONLY - round numbers, Together AI list prices from above.
in_tokens_m, out_tokens_m = 2.0, 0.5       # millions per day
price_in, price_out = 1.25, 4.25           # $ per 1M tokens (verify current)
daily = in_tokens_m * price_in + out_tokens_m * price_out
print(f"${daily:.2f}/day  ->  ${daily*30:,.0f}/month")
# $4.62/day -> ~$139/month

At that volume, hosted costs a rounding error next to a five-figure hardware purchase. The break-even only moves if your token volume is orders of magnitude higher, and I can't give you a verified break-even because none exists: no source publishes total cost of ownership covering power, maintenance, engineering time and concurrency. Anyone telling you local is cheaper without your actual token counts is guessing.

Where local genuinely wins: privacy, control, and the license

Cost is the weakest argument for local at SMB scale. Privacy and control are the strongest.

Privacy. Because the model runs on your machines, Meta doesn't see your prompts (as reported by Axios and relayed by TNW) (The Next Web). For client contracts, medical-adjacent notes, financial records or anything under an NDA, "the data never leaves the building" is a simpler story to tell a client than "we use a vendor with a DPA." Note that hosted open-weights still means a third-party provider sees your prompts; only self-hosting removes that party.

Reliability and control. A pinned local model doesn't get deprecated, repriced or silently updated under you. That matters for workflows you've tuned and tested.

The license, which you must read yourself. I couldn't read the license text directly, so what follows comes from secondary sources that quote or summarize it. Treat it as a checklist for your own reading, not legal advice:

• The Muse Model License is custom and not OSI-approved. It requires a prominent "Built with Muse Spark Open" notice in the UI, docs, website or settings of any product using the model or a Derivative (Digital Applied).
• A $20M revenue threshold applies only to Model-as-a-Service businesses: a licensee and its affiliates over $20M aggregate gross revenue in any consecutive 12 months must sign a separate agreement with Meta before offering the model as a service. Internal use, research and features inside your own product are exempt (Import Static). Check the license text itself to see how "affiliates" is defined, since that determines whether the threshold applies to you.
• The attached Usage Policy bars military and critical-infrastructure uses. Per one reading, it also bans "unlicensed professional practice" in financial, legal and medical work, and says the model isn't intended for anyone under 18 (SiliconANGLE).

That third bullet is the one to read carefully if you serve accountants, law firms or clinics. If your agent drafts something that edges toward professional advice, get the actual text in front of a lawyer.

A decision framework: local, hosted, or neither

Don't pick by hype. Walk these in order:

A sensible staged path for a small team:

1. Prototype on a hosted endpoint. Use any of the launch providers with the same OpenAI-compatible client code you'll later point at local hardware.
2. Build an eval set of 30-50 real tasks from your own workflows, with expected outputs. Include the failures you've seen.
3. Compare against alternatives. Qwen3.8, GLM 5.3 and Kimi K3 are all in the competitive picture on Meta's own table. Run them on the same set.
4. Measure end-to-end task time and cost per completed task, not tokens/sec in isolation.
5. Only then price hardware. If privacy genuinely requires local, and the eval says Muse Spark Open is the right model, order the machines.

Keep your application code endpoint-agnostic from day one so this migration is a config change:

# llm.yaml - swap providers without touching workflow code
default:
  base_url: api.your-hosted-provider.example
  model: muse-spark-open
local:
  base_url: mac-studio-a.local
  model: muse-spark-open
routing:
  sensitive_workflows: local
  everything_else: default

Routing by data sensitivity, with sensitive workflows local and the rest hosted, is often the pragmatic answer, and it avoids buying hardware for traffic that doesn't need it.

What I'd watch before committing

• Availability and price of the 512GB Mac Studio. Verify on Apple's store, not in a roundup.
• Independent benchmarks. Meta's table is Meta's table. Wait for third-party evals, especially on tool use, which is where this model claims its lead.
• License clarity. Read how "affiliates" is defined in the license text, and read the professional-practice language, before building a product on top.
• Reproduced throughput. The two-Mac speed figure I cited comes from one source. Reproduce it on your prompts or don't count on it.

How BizFlowAI approaches this

I'm Lazar Milićević, a senior engineer who builds AI automations for solopreneurs and small teams, and the local-versus-hosted question is one I weigh when choosing an architecture. My default is boring on purpose: prototype on a hosted API, build an eval from your actual tasks, keep the code endpoint-agnostic, and route only genuinely sensitive workflows to local hardware. For most small teams, the numbers point toward hosted. Where privacy or contractual constraints are strict, local becomes worth considering, and then the work is sizing the hardware to the concurrency you actually have.

If you want to work through your own numbers, meaning your token volumes, your data sensitivity, your license exposure and a measured comparison across candidate models, get in touch and we can go through them together. The answer may well be "don't buy anything yet."

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Request a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.