"Supercomputer on your desk" has been a stale exaggeration for years. On October 15, it arrived with actual numbers attached.

Meta released the weights of Muse Spark Open, an 816B-parameter model, and Apple published benchmarks of that model running on Mac Studios with MLX and Thunderbolt RDMA. The short version: it runs. Just not on your MacBook.

Two announcements, one day — October 15, 2026

Meta  — Muse Spark Open weights released (816B total / 42B active, 1M context)
Apple — MLX + Thunderbolt RDMA measurements on a Mac Studio cluster
        Up to 36.73 tokens/s on four machines (8,192-token context)

Let's walk through the distance between "it runs" and "it's usable," using today's numbers.

What was released: character before digits

Muse Spark Open is the open-weight version of Muse Spark from Meta Superintelligence Labs.

- 816B total parameters, sparse MoE activating ~42B per token
- Natively multimodal: text, image, video, and audio input
- 1M-token context window
- Built for agentic work: read a codebase, plan a change, call tools,
  check the result, and correct itself when a step fails
- License: Muse Model License (limited commercial terms)

The weights are on Hugging Face, with day-one support across SGLang, vLLM, TensorRT-LLM, Transformers, MLX, llama.cpp, and Unsloth. Hosted inference from Baseten, Fireworks, Groq, Modal, Nebius, OpenRouter, and Together gives you a path that starts with an API call and ends on your own hardware.

What "open weights" really means here is download, fine-tune, self-host. Meta's "most capable US open-weight model" framing is for evaluators to argue over; what matters is that this class of model is shipping open at all.

The Apple numbers: 36.73 tokens per second at 8,192-token context

From Apple's ML research post. Mac Studio with M5 Ultra, 512GB, at an 8,192-token context:

Measurement 2 machines, pipeline 2 machines, tensor 4 machines, tensor
Decode speed (tokens/s) 15.74 24.99 36.73
Time to first token (s) 8.4 8.2 4.8

Some context for those numbers:

- M5 Ultra: up to 512GB unified memory, 1.2TB/s memory bandwidth
  (the previous M3 Ultra: 819GB/s)
- Versus M3 Ultra, up to 4.6x faster time-to-first-token and 1.6x decode
- Peak power: around 200-300W at a 65,536-token context
  — less than a toaster, which is why "on the desk" is even a thing

Why four machines: the two ways to split a model

Muse Spark Open is about 493GB (Apple's figure) to 530GB (Meta's figure) in NVFP4 4-bit quantization. The BF16 original exceeds 1.6TB, so it cannot live on one machine. That leaves two shapes: two 512GB Mac Studios, or four 256GB machines.

There are two ways to split a model across machines.

Pipeline parallelization — split by depth
  [Mac 1] first half of layers -> [Mac 2] second half
  · Machines compute in sequence; only intermediate outputs travel
  · Simple to implement; decode speed stays close to one machine
  · Up to ~1.8x faster prefill at very long contexts (65,536 tokens)

Tensor parallelization — split by width
  [Mac 1] half of every layer | [Mac 2] half of every layer
  · Both machines compute on every token and exchange partial results
  · Talkative: needs low-latency links (Thunderbolt RDMA) to pay off
  · Scales decode best: 36.73 tokens/s on four machines

The communication layer that makes this possible is the RDMA-over-Thunderbolt 5 driver in macOS 26.2, with MLX's jaccl backend on top. Two Thunderbolt cables per link double the bandwidth, and launching a job is one command:

mlx.launch --hostfile hostfile.json --backend jaccl --env MLX_METAL_FAST_SYNCH=1 -- \
  mlx_lm.benchmark --model meta-models/Muse-Spark-Open-816B-A42B-NVFP4 -p 8192 -g 128 -b 1

One subtlety worth keeping: at a 65,536-token context, two-machine tensor parallelization can be slower than two-machine pipeline for prefill, because expert-output normalization adds communication. Adding machines flips the outcome. It is not "tensor always wins" — the answer depends on machine count and context length. As in our MoE serving kernel piece, the bottleneck is rarely arithmetic. It is the road the data travels.

When the model moves to your desk: the local-agent loop

Apple did not just benchmark inference. It showed how to wire a local model server into a coding agent: serve the model with mlx_lm.server, then point a tool like OpenCode at it.

{
  "$schema": "https://opencode.ai/config.json",
  "model": "meta-models/Muse-Spark-Open-816B-A42B-NVFP4",
  "provider": {
    "mlx": {
      "baseURL": "http://127.0.0.1:8080/v1"
    }
  }
}

(The full configuration is in Apple's post; this is the essential part.)

Meta's own on-device tests point the same direction. Muse Code shipped real iOS changes to Ice Cubes, an open-source Mastodon client — bug fixes, new features, a full build — entirely on-device. It also drove DaVinci Resolve end to end, reviewing footage frame by frame to find the strongest moments and crop them vertically. The point is not the demos; it is that local models are entering real work loops.

Reality check: the fine print the headlines skip

1. 36.73 tokens/s is decode speed at an 8,192-token context.
   It does not mean "it runs on one MacBook."
   The NVFP4 baseline is 2 machines (512GB each) or 4 machines (256GB each).
2. Time to first token is 4.8s (4 machines, 8k context). For interactive
   feel, this number matters more than decode speed.
3. Speed figures use NVFP4 quantization. Meta says only the expert layers
   are quantized; precision-sensitive work needs its own validation.
4. The 40.6s TTFT at 65k context on four machines assumes a two-cable
   mesh. With one cable, Apple measured about 50.5s.
5. Unsloth's ~2-bit GGUF fits a single 256GB workstation (~300GB total).
   That trades quality for reach — "it runs" is not "it runs well."
6. The speed helpers: speculative decoding drafts
   (SGLang's DFlash V2: 3.7x on a single MI355X request) and Helion
   kernels (1.03-3.95x at kernel level, 3% end-to-end on MI350).

CodeBridge mini lab: local vs cloud on the same questions

1. Build a fixed set of 10 questions (3 code understanding, 3 log
   summaries, 4 document lookups)
2. Run each on a local Muse Spark Open and on a cloud API
3. Record:
   [ ] time to first token / tokens per second
   [ ] answer quality (blind comparison, one rubric)
   [ ] cost per run (power and depreciation vs API pricing)
   [ ] did the data leave the machine? (compliance angle)
4. Decide by: does local pay for the work that cannot leave the building?

The question is not whether you should buy an 816B-class setup. For most of us, no. But once a list of "this work stays on my machine" tasks exists, what you need is not a hardware decision — it is a workload map. The math from our DGX Spark local-AI economics piece applies here unchanged.

Conclusion: the model moves, the design work stays

The real change today is not "you can buy 816B."
It is that "the model might live on your desk" became an option.

Wherever the model lives, agents only get work done when someone designs the execute-and-verify loop, the tool calls, and the handoffs. Hardware refreshes every few years; that structure lasts. You can start learning it today, 816B purchase optional.

Further reading

References

Go deeper with a course

However far down the model moves, agents only work when the execute-and-verify structure around them is designed. Practice building harnesses, loops, and graphs — deciding where to run and where to check.