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.
Short answer: yes—Hugging Face publishes a prevalidated Muse Spark Open endpoint recipe using eight NVIDIA H200 GPUs at 1,048,576-token context. NVIDIA specifies 141GB per H200, giving the eight-device pool 1,128GB: 428GB above Meta’s stated 700GB NVFP4 minimum and 594.989GB above the official repository’s 533.011GB of listed safetensors. That validates the named hosted recipe, not every arbitrary eight-H200 cluster.
The unusual part
Meta describes NVFP4 as targeting NVIDIA Blackwell GPUs, yet Hugging Face separately publishes this specific H200 hosted endpoint recipe. Preserve both facts: the named Hopper path is prevalidated, but that does not generalize to an unsupported self-managed runtime or arbitrary Hopper topology.
Eight H200 GPUs: the exact boundary
| Boundary | Value | Margin in the 8×141GB pool |
|---|---|---|
| Official listed NVFP4 safetensors | 533.011GB | 594.989GB above stored files |
| Meta’s stated NVFP4 minimum | 700GB VRAM | 428GB above the minimum |
| 8×H200 | 1,128GB nominal | 141GB per device |
| Published endpoint context | 1,048,576 tokens | Recipe-specific maximum-position target |
Why this is stronger evidence than H200 capacity alone
Five H200 GPUs already total 705GB, which clears Meta’s minimum by 5GB on paper. But the reviewed official material does not validate a five-H200 Muse Spark deployment. The eight-H200 recipe is materially different: a publishing platform has bound the named checkpoint, hardware count, runtime path and context configuration into a prevalidated endpoint definition.
Prevalidation still does not establish your own throughput, latency, power draw, reliability or maximum concurrency. Those must be measured on the exact endpoint or reproduction.
The one-million-token setting is not free memory
The published 1,048,576-token value is a configuration target, not proof that every request can use the full window under every batch and concurrency setting. KV cache grows with sequence length and serving load. Multimodal inputs, preprocessing, framework state, communication buffers, tensor/expert placement and temporary workspaces also consume memory.
The 428GB difference from Meta’s minimum averages 53.5GB per device only under even pressure. Operators still need per-device peak measurements because a run fails on the most constrained GPU, not on aggregate average memory.
H200 versus the other published paths
| Path | Nominal memory | Published evidence | Best interpretation |
|---|---|---|---|
| 8×RTX PRO 6000 96GB | 768GB | Prevalidated hosted endpoint at 131,072 context | Lower-capacity published endpoint path |
| 8×H200 141GB | 1,128GB | Prevalidated hosted endpoint at 1,048,576 context | Published long-context hosted path |
| 4×GB300/B300-class 288GB | 1,152GB nominal | Official SGLang TP4/EP4 self-managed reference | Published four-device Blackwell path |
| 8×B200 180GB node | 1,440GB | Official launch article’s single-node B200 path | Published node-scale Blackwell path |
Validate the exact H200 deployment
- Confirm H200 form factor, 141GB visible memory on every device and whether MIG is disabled.
- Record the host, interconnect, slot layout and complete peer topology.
- Pin the model revision, quantization, container, driver, CUDA and inference runtime.
- Record tensor-parallel and expert-parallel sizes plus the placement map.
- Disclose every form of CPU or storage offload.
- Fix context, modality, batch size and concurrency for each test.
- Capture idle, load and peak memory on every GPU.
- Check correctness, retries, errors and out-of-memory failures.
- Report latency, throughput, warmup, repetitions, throttling and wall power separately.
Decision
Choose the published eight-H200 endpoint route when the prevalidated one-million-token configuration is central to the workload. Choose the eight-RTX-PRO endpoint when its published 131,072-token target is sufficient and the smaller 768GB pool is preferable. Choose the four-GB300 SGLang reference when reproducing the official self-managed Blackwell path matters more. Do not infer that H200 is universally faster or that any eight-H200 cluster inherits the hosted recipe.
Continue the research
- See the exact Muse Spark Open VRAM requirements
- Compare every published and capacity-only hardware path
- Review H200 SXM and NVL specifications
- Compare the 8×RTX PRO 6000 recipe
- Stage a reproducible Muse Spark benchmark record
- Follow qualifying high-VRAM hardware listings
Primary sources
- Official Muse Spark Open launch and prevalidated endpoint recipes
- Official Muse Spark Open NVFP4 repository
- NVIDIA H200 specifications
- NVIDIA HGX platform specifications
Checked October 25, 2026. “Prevalidated” applies only to the named hosted recipe. Capacity and context support are not performance benchmarks or purchase guarantees.