Open weights can still need a machine room
Muse Spark Open is a sparse mixture-of-experts model with 816 billion total parameters and about 42 billion active for each token. Meta publishes BF16 and NVFP4 checkpoints. The developer guide puts the BF16 weights at about 1.6 TB and the NVFP4 checkpoint at about 530 GB.
The model card gives a higher deployment floor because serving needs more than the weight file. It says NVFP4 requires at least 700 GB of VRAM and BF16 requires 2 TB. Those figures do not fit on an ordinary developer laptop. They define a workstation cluster, a large accelerator node, or a hosted endpoint.
"Desktop" is a location claim. Topology still decides the work.
The two-Mac route is tensor parallel
Meta's Apple recipe uses two M5 Ultra Mac Studios with 512 GB of unified memory each, or four with 256 GB each. The machines connect directly through Thunderbolt 5 with RDMA. MLX splits every model layer across the hosts. Each machine holds part of the weights and performs part of the computation for every token.
Meta says the weights stay put while intermediate results cross the link. That is the useful engineering detail. The cable, MLX version, host count, memory size, direct-link configuration, and process placement all belong in a reproducible run record. Removing any one of them changes the system.
Forty-two billion active does not mean forty-two billion resident
The router selects eight of 256 experts for each token, but the full expert set still has to live somewhere. Sparse activation can reduce compute per token. It does not shrink the stored model to the active parameter count.
The Hugging Face API confirms that the gated BF16 repository has 65 safetensor shards and about 1.64 TB of stored files. The same record identifies revision 0fb02478. That proves the published artifact exists. It does not prove that this garage downloaded, loaded, or ran it.
Test the seam, not only the answer
A two-host setup adds failure states that a one-process benchmark can miss. Pull the direct link during generation. Stop one worker. Restart one host with a different runtime build. Fill memory on one side. Send a long multimodal request. Record whether the request fails closed, hangs, retries, or returns a partial result.
Then run the coding workload. Measure cold load, first-token delay, steady generation, tool-call correctness, and recovery after a failed action. Meta's benchmark table and launch demonstrations are publisher evidence. They are not a substitute for your repository, tools, permissions, and stop rules.
Keep five records
- Pin the model revision, precision, and exact artifact.
- Record every host, its memory, operating system, runtime, and process role.
- Record the physical link and the distributed settings that split each layer.
- Test link loss, worker loss, version mismatch, memory pressure, and restart behavior.
- Replay the real workload and compare it with a hosted route and a smaller local model.