Exploring the 512GB Apple-silicon path? See whether a 512GB Mac Studio can run Muse Spark Open, including the published 304GB Q2_K and 344GB oQ3e tests and why they do not replace the official 700GB NVFP4 requirement.
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.
Evaluating the published long-context path? See whether eight H200 GPUs can run Muse Spark Open, including the prevalidated 1,048,576-token endpoint recipe and its Hopper-specific evidence limits.
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.
Evaluating the 720GB boundary? See whether four B200 GPUs can run Muse Spark Open and why passing the 700GB arithmetic does not reproduce the published eight-B200 node path.
Choosing Muse Spark Open hardware? The Muse Spark Open hardware guide separates published eight-B200, four-GB300, eight-H200 and eight-RTX-PRO paths from smaller capacity-only experiments.
Short answer: Meta’s official Muse-Spark-Open-816B-A42B-NVFP4 repository lists 127 safetensors files totaling 533,011,023,472 bytes—533.011GB in decimal units. That is the storage floor, not the deployment target. Meta says the NVFP4 model requires a GPU system with at least 700GB of VRAM. Therefore, 8×80GB = 640GB is below the official runtime guidance; 5×H200 141GB = 705GB only barely clears it; and 4×B200 180GB = 720GB is the first reference-style Blackwell tier with a little more breathing room.
The number to remember
533.011GB = listed checkpoint files. 700GB = Meta’s minimum VRAM guidance for the NVFP4 model. Do not size a deployment from the smaller number alone.
Official Muse Spark Open facts
- Official NVFP4 repository: meta-models/Muse-Spark-Open-816B-A42B-NVFP4
- Repository revision checked:
4239e4db19376904f2e82c167e78f70abb5455fe - Listed checkpoint size: 127
.safetensorsfiles, 533,011,023,472 bytes (533.011GB decimal / 496.405GiB) - Architecture: 816B total parameters, about 42B active per token, 256 experts with 8 selected per token
- Modalities: text, image, video and audio input; text output
- Context: up to 1M tokens, subject to serving configuration and memory
- Official deployment statement: at least 700GB VRAM for NVFP4 and 2TB for BF16
VRAM capacity table
| Aggregate VRAM | Margin after 533.011GB files | Against Meta’s 700GB minimum | Planning verdict |
|---|---|---|---|
| 512GB | −21.011GB | −188GB | No: files alone do not fit |
| 640GB (8×80GB) | +106.989GB | −60GB | Files fit; below official runtime guidance |
| 700GB | +166.989GB | Meets stated minimum | Boundary, not a guarantee |
| 705GB (5×141GB) | +171.989GB | +5GB | Barely clears the stated minimum |
| 720GB (4×180GB) | +186.989GB | +20GB | Reference-style B200 capacity tier; validate workload |
| 768GB (8×96GB) | +234.989GB | +68GB | More aggregate headroom; runtime support still matters |
| 810GB (3×270GB) | +276.989GB | +110GB | Higher-capacity Blackwell tier |
| 864GB (3×288GB) | +330.989GB | +164GB | Comfortable capacity tier on paper |
Why 533GB of files can require 700GB of VRAM
The checkpoint files are a lower bound: they measure stored artifacts. A live server also needs memory for runtime allocations, dequantization or execution-specific representations, CUDA state, kernels, workspaces, communication buffers, KV cache, multimodal encoders, and uneven per-device placement. Meta’s 700GB figure is therefore the more relevant starting point for a supported NVFP4 deployment.
The difference is 166.989GB between the listed files and the stated minimum—about 31.3% of the file total. That does not mean every workload consumes exactly that overhead. It means a 533GB subtraction exercise is not enough to validate a production configuration.
How many GPUs does Muse Spark Open need?
There is no single count without naming the GPU and deployment recipe. For the official NVFP4 path, Meta’s floor is at least 700GB of aggregate GPU memory, but the published examples bind that capacity to a device family, count, runtime and context target.
| Published path | Device count | Aggregate memory | Evidence status |
|---|---|---|---|
| RTX PRO 6000 Server Edition | 8 GPUs | 768GB (8×96GB) | Published/prevalidated endpoint at 131,072 context |
| H200 | 8 GPUs | 1,128GB (8×141GB) | Published/prevalidated hosted endpoint at 1,048,576 context; a specific Hopper exception, not universal self-managed support |
| GB300/B300-class | 4 GPUs | 1,152GB (4×288GB) | Official self-managed SGLang reference using TP4 + EP4 |
| B200 | 8 GPUs | 1,440GB (8×180GB) | Official launch-article single-node path |
Do not treat capacity arithmetic as validation. Five H200s (705GB) and four B200s (720GB) cross 700GB only arithmetically; the reviewed sources do not validate those device counts as deployment paths. Eight 80GB H100s total 640GB and remain below the official minimum. GPU count alone does not establish speed, supported context, topology or availability.
Can eight H100 80GB GPUs run Muse Spark Open?
Do not plan on 8×H100 80GB from the official guidance. The 640GB aggregate pool is large enough to hold the 533.011GB files, but it is 60GB below Meta’s stated 700GB minimum for NVFP4. It also leaves an average of only 13.374GB per device after a perfectly even file split—before live-serving memory and placement imbalance.
Capacity aside, Meta describes NVFP4 as a Blackwell-targeted checkpoint. Hardware generation, runtime version, quantization kernels and communication topology must all support the exact format. A larger aggregate pool on unsupported hardware is not a valid deployment path.
What about five H200s or four B200s?
Five H200 141GB GPUs total 705GB, just 5GB above the stated minimum. That is a useful arithmetic boundary, not proof that the NVFP4 execution path supports Hopper or that component placement works. Treat it as a question for the exact framework and checkpoint—not a purchase recommendation.
Four B200 180GB GPUs total 720GB, 20GB above the stated minimum and 186.989GB above the stored file total. Meta’s official model card says the NVFP4 version is designed for NVIDIA Blackwell, and its published SGLang reference uses four GB300 GPUs. A B200 plan still needs verified framework support, per-device peak memory, context, batch and concurrency testing.
One-million-token context is not free
The model supports up to a one-million-token context, but the maximum is not a promise that every 700GB deployment can serve that context at useful batch or concurrency. KV cache and temporary state grow with context, precision, batch size, concurrent requests and engine design. Start with a short context and one request, record peak memory on every device, then increase one variable at a time.
Deployment checklist
- Pin the exact repository revision and confirm that all 127 weight shards are present.
- Use a runtime version that explicitly supports Muse Spark Open and its NVFP4 path.
- Record device model, exposed memory, interconnect, tensor/expert parallel settings and placement.
- Begin with text-only, short context, batch size 1 and concurrency 1.
- Measure peak memory per device rather than relying on aggregate totals.
- Test images, audio and video separately; multimodal success has different memory demands.
- Increase context and concurrency gradually, preserving observed headroom.
Practical recommendation
Use 533.011GB as the exact listed NVFP4 checkpoint size and 700GB as the official minimum deployment boundary. Reject 640GB plans unless a different supported artifact and reproducible measurement justify them. Treat 705GB as a razor-thin boundary, 720GB as the first relevant reference-style tier, and larger 768GB–864GB pools as capacity candidates that still require format, topology and workload validation.
Ready to deploy? Use the Muse Spark Open runtime-path guide to choose between the official SGLang, vLLM, TensorRT-LLM and distributed-MLX routes or the separate llama.cpp and Unsloth quantized paths.
Continue planning
- Compare NVIDIA H100, H200, B200 and B300
- Understand multi-GPU VRAM and placement
- Browse the high-VRAM hardware guide
- Submit a reproducible local-AI benchmark
- Follow high-VRAM hardware listings
Primary sources and method
- Official Meta NVFP4 model card
- Official Meta BF16 model card
- Official repository API with blob sizes
- Hugging Face Transformers documentation
Method: summed the byte sizes of every .safetensors entry returned by the official NVFP4 repository API at revision 4239e4db19376904f2e82c167e78f70abb5455fe, converted bytes using decimal GB, and subtracted that total from nominal aggregate VRAM. Official runtime boundaries come from Meta’s model card. This is capacity analysis, not a speed benchmark. Last checked October 25, 2026.