Deploy Muse Spark Open on GPU Cloud: Meta's 816B MoE Setup (2026)

This guide covers deploying Muse Spark Open on GPU cloud: the exact VRAM math Meta's documentation splits across three pages, which GPU configurations actually fit each checkpoint, and a cost-per-token estimate using the closest real fleet numbers available, since nobody has independently benchmarked this model yet.

TL;DR: How to Deploy Muse Spark Open on GPU Cloud

• Architecture: Muse Spark Open is Meta's 816B-parameter MoE with 42B active per token, 256 experts, top-8 routing, and a 1M-token context, released 15 Oct 2026.
• BF16 math: the BF16 checkpoint needs roughly 2TB of VRAM including working memory, which only clears comfortably across 4 InfiniBand-connected nodes of 8x H200 (32 GPUs) at tensor-parallel 32.
• NVFP4 math: the NVFP4 checkpoint needs roughly 700GB, fitting a single 8-GPU node (H200 or B200) or the 4x Blackwell Ultra setup Meta's own reference deployment uses.
• Local ceiling: a llama.cpp Q2_K build runs on one Mac Studio M3 Ultra at about 18 tok/s, fine for testing, not production serving.
• Spheron: H200 and B200 are on-demand today for the single-node NVFP4 path; Blackwell Ultra (B300) is spot-only as of 21 Oct 2026. Compare live GPU pricing.

What Muse Spark Open Actually Is: 816B Total, 42B Active, 1M Context

Muse Spark Open's model card on Hugging Face lists 816B total parameters with 42B active per forward pass, routed across 256 experts with top-8 selection, 62 transformer layers, grouped-query attention with 128 query heads and 16 key-value heads, a 202,048-token vocabulary, and a 1M-token context window. That ratio, about 5% of total weights firing per token, is why a model this large is viable to serve: compute cost tracks the 42B active figure, while memory cost tracks the full 816B.

On Meta's own benchmark suite, Muse Spark Open scores 89.0 on GPQA Diamond, 76.4 on Terminal-Bench 2.1, and 61.8 on JobBench. Those are self-reported numbers; independent reproductions hadn't surfaced as of this writing, six days after release.

"Open" here means what it says: Meta shipped actual downloadable weights, in both BF16 and NVFP4 checkpoints, under the terms posted on the model repository at the Hugging Face link above. Nothing about self-hosting it requires an API key or a Meta-run endpoint; the checkpoint is yours to run on whatever hardware clears the VRAM math below.

BF16 vs NVFP4 Checkpoints: VRAM Math at Both Precisions

Meta's own numbers, spread across the model card and the launch blog post, put the BF16 safetensors checkpoint at roughly 1.5TB and the full BF16 deployment footprint, including working memory, at about 2TB. The NVFP4 checkpoint lands much smaller: about 700GB deployed, with raw quantized weights closer to 530GB, because NVFP4 quantizes only the expert weights and leaves attention layers at higher precision.

KV cache is the piece that's easy to underweight. Muse Spark Open's grouped-query attention adds about 250KB of KV cache per token in BF16, roughly 266GB for one session at the full 1M-token context. That's additive on top of the weight footprint above, per concurrent long-context session, not a one-time cost.

Put the two together and the node math gets concrete. The 2TB BF16 footprint alone exceeds a single 8-GPU H200 node (141GB x 8 = 1,128GB) and crowds the ceiling of a 16-GPU, two-node setup (141GB x 16 = 2,256GB) before adding any KV cache. Add one full 1M-token session's 266GB and 16 GPUs are already over budget. That's the arithmetic behind running the BF16 checkpoint across 4 InfiniBand-connected 8-GPU nodes (32x H200, tensor-parallel 32): 32 x 141GB = 4,512GB holds the weights with room for several concurrent long-context sessions, not just the bare model.

NVFP4's 700GB footprint is a different story. Even with a full 1M-token KV session added on top (roughly a quarter of the BF16 figure, since NVFP4 compresses harder), the total stays well under a single 8-GPU H200 node (1,128GB) or B200 node (1,536GB at 192GB per GPU). That's the gap between needing a multi-node InfiniBand cluster and fitting on one box, for the same model.

Run Muse Spark Open Locally: Mac Studio and the Single-GPU Ceiling

Running Muse Spark Open on a single machine at home is possible, but only at a quantization level and speed that fit testing, not serving:

• It fits on one Mac Studio. A llama.cpp build using Q2_K quantization runs on a single Mac M3 Ultra with 512GB of unified memory, using about 304GB and producing roughly 18 tokens per second.
• It does not fit on one GPU, consumer or data center. No single accelerator shipping today, including NVIDIA's flagship Blackwell Ultra (B300), holds the ~530GB raw NVFP4 checkpoint alone, let alone the ~700GB deployed footprint.
• It does not fit on a gaming rig. Stacking consumer cards doesn't close the gap at this scale; you'd need a double-digit multiple of a single high-end GPU's VRAM before the math gets close.
• What you give up locally. Q2_K is a deep 2-bit-class quantization, well below the NVFP4 checkpoint Meta shipped for production, and 18 tok/s suits reading along as it types, not serving concurrent requests.
• The real ceiling. A Mac Studio keeps Muse Spark Open runnable for one developer testing locally. Real throughput, the full 1M-token context, or more than one concurrent user needs a GPU cloud node.

GPU Configurations That Fit: 4x Blackwell Ultra vs 8x H200 on Spheron

Here's the node-level breakdown for both checkpoints, matched against what Spheron's catalog actually offers:

The 4x Blackwell Ultra configuration mirrors the reference deployment NVIDIA and explainx describe for the NVFP4 checkpoint, running SGLang with modelopt_fp4 quantization and the FlashInfer MoE runner. On Spheron that GPU is listed spot only as of 21 Oct 2026, fine for development but with no guaranteed-uptime contract.

An 8x H200 SXM5 node covers the same NVFP4 footprint on-demand and spot, useful if you need the deployment to stay up without competing for reclaimable capacity. An 8x B200 SXM6 node fits the same checkpoint with more KV cache headroom at longer context, also on-demand.

For the full BF16 checkpoint, a single node isn't an option on any current hardware; you need the 4-node, 32-GPU InfiniBand cluster, which Spheron provisions on request rather than as a click-to-deploy launch. If your workload can live with NVFP4's quality tradeoff, the single-node path is faster to stand up and cheaper to run.

NVIDIA's own benchmark on a full GB300 NVL72 rack (72 Blackwell Ultra GPUs on a 130TB/s NVLink domain) reports up to 50,000 tokens per second per GPU and up to 600 per user on agentic coding workloads, using SGLang, vLLM, TensorRT-LLM, and NVIDIA Dynamo's disaggregated prefill/decode. That's a rack-scale ceiling the smaller setups above are working toward, not what they deliver on their own.

Step-by-Step vLLM Deployment on Spheron GPU Cloud

This walks through the single-node NVFP4 path, the practical starting point for most teams.

1. Provision the node. Log into Spheron's dashboard, select an 8x H200 SXM5 or 8x B200 SXM6 offer, set storage to at least 900GB, and choose Ubuntu 24.04.

2. Install the serving stack. Meta's reference path uses SGLang with the FlashInfer MoE runner for modelopt_fp4:

pip install --upgrade "sglang[all]"
pip install flashinfer-python

If you'd rather use vLLM, confirm your build supports modelopt_fp4 quantization first; given the 15 October 2026 release, stable support may still be landing in nightly builds.

3. Launch the server.

python -m sglang.launch_server \
    --model-path meta-models/Muse-Spark-Open-816B-A42B \
    --quantization modelopt_fp4 \
    --tp 8 \
    --trust-remote-code \
    --context-length 262144 \
    --port 30000

Keep --context-length below the full 1M-token ceiling unless you've sized KV cache headroom for it; the full window across more than a handful of concurrent sessions runs into the VRAM math above.

4. Verify. curl http://localhost:30000/v1/models, confirm the model ID appears, then send a short completion request and watch throughput before routing production traffic.

5. Plan for spot capacity. On spot GPUs, run two copies split across two separate nodes, so a reclaim on one doesn't take the whole deployment down, the layout we use for other large MoE models on spot fleets.

How Muse Spark Open Compares to DeepSeek V4 Flash on Cost Per Token

Muse Spark Open is six days old as of this writing. Nobody, including us, has independently benchmarked its throughput on real hardware yet, so a cost-per-token figure quoted for it directly is a placeholder. The closest proxy is a comparably-sized open MoE model we've actually run and measured.

We measured DeepSeek V4 Flash (0731) on an 8xB200 node running vLLM with FP8 and FP4 at a 1M-token context, with four 2-GPU copies per node. A single copy hit 272 tok/s for one user, dropping to 170 at 8 concurrent users, 140 at 16, and 116 at 32, with a 0.64s time-to-first-token and zero errors across the run.

We also measured DeepSeek V4.1 Flash on the same node type, running vLLM with FP8, FP4, and speculative decoding at 1M context, using two 4-GPU copies instead of four 2-GPU copies. That configuration hit 500 tok/s for one user, 260 at 8 users, 202 at 16, and 170 at 32, with a 0.45s time-to-first-token. Under 32 sessions, one copy read 218,578 prompt tokens per second and wrote 2,555 output tokens per second at an 86% KV cache hit rate.

Neither model is Muse Spark Open, but they're the closest real data point for a dense-enough 1M-context MoE on 8xB200 hardware until Muse Spark Open gets its own numbers. One more pattern worth carrying forward: splitting a B300 node into two 4-GPU copies instead of one 8-GPU copy traded lower per-user speed for double the concurrent sessions on GLM-5.3, 254 tok/s versus 324 tok/s for a single user, but 64 sessions versus 32. Expect a similar tradeoff here: fewer, larger copies for latency-sensitive single-user work, more smaller copies for concurrency-bound serving.

Budget conservatively until independent numbers land. An 8x H200 node on Spheron runs $38.40/hr on-demand as of 21 Oct 2026; an 8x B200 node runs $80.40/hr. Divide either by whatever throughput your own testing produces, not a figure carried over from a different model.

Pricing fluctuates based on GPU availability. Spheron rates above are live as of 21 Oct 2026; other providers' rates reflect their most recently published figures and may have changed. Check current GPU pricing → for live rates.

Weighing Muse Spark Open against other recent open-weight MoE releases: the Kimi K2.7 Code guide covers a 1T/32B-active coding model on the same 8-GPU NVLink-node pattern, the GLM-5.1 guide walks through a 754B MoE at FP8 on 8x H200, and the Mistral Large 3 guide covers expert-parallel vLLM serving on a 675B MoE. For long-context KV cache math specifically, the DeepSeek R2 deployment guide covers a problem that compounds the same way Muse Spark Open's 1M-token context does.

Muse Spark Open's NVFP4 checkpoint fits a single 8-GPU node today; its BF16 checkpoint needs a 4-node InfiniBand cluster. Spheron has H200 and B200 available on-demand for the single-node path right now.

H200 SXM5 on Spheron → | B200 SXM6 on Spheron → | View all GPU pricing →