Reproducing the official self-managed path? See whether four GB300 GPUs can run Muse Spark Open, including the published SGLang TP4/EP4 configuration and GB300/B300 naming boundary.
Following the published 768GB path? See whether eight RTX PRO 6000 Blackwell GPUs can run Muse Spark Open, including the prevalidated 131,072-context recipe, 96GB/98GB source discrepancy and validation limits.
Short answer: four NVIDIA B200 GPUs provide 720GB of nominal HBM3e, so they clear Meta’s stated 700GB minimum for Muse Spark Open NVFP4 by only 20GB. They also exceed the 533.011GB listed checkpoint files by 186.989GB. But no published source reviewed here validates a four-B200 Muse Spark Open deployment. The official launch article says NVFP4 runs on a single B200 node, and NVIDIA documents that HGX node as eight 180GB GPUs. Treat 4×B200 as an experiment to prove—not a confirmed configuration or buying recommendation.
The decisive distinction
Capacity test: 720GB is 20GB above the stated minimum. Deployment test: the runtime, quantization kernels, tensor/expert placement and topology must work across exactly four B200s. The arithmetic passes; the published deployment evidence does not establish the second test.
Four-B200 capacity arithmetic
| Boundary | Value | What it proves |
|---|---|---|
| Official listed NVFP4 files | 533.011GB | Stored checkpoint floor |
| Meta’s stated NVFP4 minimum | 700GB VRAM | Publisher’s minimum deployment boundary |
| 4×B200 nominal capacity | 720GB | Aggregate arithmetic only |
| Margin after listed files | 186.989GB | Space beyond stored artifacts before placement |
| Margin above stated minimum | 20GB | Only 5GB per device if distributed evenly |
The important margin is not just 720 − 533.011. Meta already converts the storage floor into a 700GB minimum deployment figure, a difference of 166.989GB. A four-B200 pool leaves only 20GB beyond that stated minimum—an average of 5GB per device if every component and runtime allocation were balanced perfectly.
Why aggregate VRAM can still fail
- Uneven components: attention, embeddings, multimodal towers and output layers may not partition like routed experts.
- Runtime allocations: CUDA state, kernels, workspaces and communication buffers consume per-device memory.
- KV cache: context, cache precision, batch and concurrency change the live requirement.
- Parallel plan: tensor and expert parallel sizes must match a supported placement strategy.
- Topology: four devices in an arbitrary host do not reproduce a qualified NVLink/NVSwitch node.
- Software support: the exact NVFP4 backend, framework version and kernels must support the four-way configuration.
What the official deployment evidence actually says
The official Muse Spark Open launch material provides two different Blackwell signals:
- The NVFP4 checkpoint runs on a single B200 node. NVIDIA’s HGX reference architecture describes that node as eight B200 GPUs with 180GB each, totaling 1.44TB.
- The published SGLang command uses four GB300 GPUs with tensor parallelism 4 and expert parallelism 4.
Neither statement validates four B200 GPUs. A four-device count appears in the GB300 reference, but that does not transfer automatically to B200: capacity, usable memory, platform topology and the tested software path differ.
Four B200s versus published alternatives
| Configuration | Aggregate memory | Above 700GB | Muse Spark evidence |
|---|---|---|---|
| 4×B200 180GB | 720GB | +20GB | Capacity-only experiment |
| 8×RTX PRO 6000 Blackwell 96GB | 768GB | +68GB | Prevalidated hosted recipe at 131,072 context |
| 4×GB300/B300-class 288GB | 1,152GB nominal | +452GB | Official SGLang TP4/EP4 reference |
| 8×H200 141GB | 1,128GB | +428GB | Prevalidated hosted recipe at 1,048,576 context |
| 8×B200 180GB node | 1,440GB | +740GB | Official article’s B200-node path |
The eight-RTX-PRO path is especially instructive: its 768GB nominal pool is only 48GB larger than four B200s, yet it has a named prevalidated hosted recipe and a defined 131K context boundary. Published support and workload definition matter as much as the raw capacity difference.
How to validate a four-B200 experiment
- Pin the exact
meta-models/Muse-Spark-Open-816B-A42B-NVFP4revision. - Use a framework build that explicitly supports Muse Spark Open and this NVFP4 checkpoint.
- Record the complete system, not just four GPU names: baseboard, NVLink/NVSwitch, host, firmware and exposed memory.
- Record tensor parallelism, expert parallelism and every unsharded or replicated component.
- Start with text-only, short context, batch size one and concurrency one.
- Measure peak memory on every B200, not only the aggregate sum.
- Record load failures, out-of-memory events and output correctness—not just a successful process start.
- Increase context, modality and concurrency one variable at a time.
- Publish the runtime version, launch command and measurements through the benchmark builder.
Decision
Can four B200s fit the stated capacity boundary? Yes: 720GB is 20GB above 700GB. Can HighVRAM confirm that four B200s run Muse Spark Open from current official evidence? No. The supported evidence points to an eight-B200 node, four GB300 GPUs, or the named eight-GPU hosted recipes. Unless you can reproduce a four-B200 configuration with per-device measurements, buy or rent against a published path rather than the smallest aggregate sum.
Continue planning
- Compare every published Muse Spark hardware path
- Review the 533.011GB files and 700GB minimum
- Understand B200 180GB platform requirements
- Understand multi-GPU placement and topology
- Stage a reproducible Muse Spark benchmark record
- Follow published-path hardware families
Primary sources
- Official Meta NVFP4 model card
- Official launch and deployment recipes
- NVIDIA HGX B200 and B300 specifications
Capacity analysis, not a measured performance result. Last checked October 25, 2026.