HighVRAM Hardware Watch

Best Hardware for Muse Spark Open: B200, GB300, H200 or RTX PRO?

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.

Short answer: for Meta’s official Muse Spark Open NVFP4 checkpoint, choose a documented deployment path rather than the smallest aggregate VRAM sum above 700GB. The strongest published options are an eight-GPU B200 node, the official four-GB300 SGLang reference, or Hugging Face’s prevalidated hosted recipes using eight RTX PRO 6000 Blackwell GPUs for 131,072-token context or eight H200 141GB GPUs for the one-million-token context tier. Four B200s total 720GB and three B300s total 864GB, but those are capacity-only candidates—not published Muse Spark Open reference configurations.

Decision rule

Start with the exact runtime recipe and context target. Then verify that the complete qualified system exposes enough memory on every device. Do not buy a mathematically sufficient collection of GPUs and assume the framework can place Muse Spark Open across it.

Published and capacity-only hardware paths

Hardware pathNominal aggregate memoryAbove 700GB minimumEvidence status
4×B200 180GB720GB+20GBCapacity-only candidate; not the published B200-node reference
8×RTX PRO 6000 Blackwell 96GB768GB+68GBPrevalidated Hugging Face endpoint recipe for 131,072 context; verify exposed memory
3×B300 288GB864GB+164GBCapacity-only candidate; not the published four-GB300 reference
8×H200 141GB1,128GB+428GBPrevalidated Hugging Face endpoint recipe for 1,048,576 context
4×B300/GB300-class 288GB1,152GB+452GBOfficial SGLang reference uses four GB300 GPUs; confirm actual exposed memory
8×B200 180GB node1,440GB+740GBOfficial article says NVFP4 runs on a single B200 node
Nominal decimal capacities. NVIDIA documentation lists 96GB for RTX PRO 6000 Blackwell Server Edition, 141GB for H200, 180GB for B200 and 288GB for the current B300 product tier. Runtime-visible memory can differ; record it.

Why the smallest arithmetic fit is not automatically best

The official NVFP4 repository contains 533.011GB of listed safetensors, while Meta states that a self-hosted deployment needs at least 700GB of VRAM. Four B200 GPUs total 720GB, leaving only 20GB above that stated minimum. But the official publication describes NVFP4 running on a single B200 node, and NVIDIA documents an HGX B200 node as eight 180GB GPUs with 1.44TB total HBM3e. A four-GPU sum is therefore an experiment to validate, not a reason to assume support.

The same rule applies to three B300 GPUs. Their 864GB nominal sum clears 700GB, but Meta’s published SGLang reference uses four GB300 GPUs with tensor parallelism and expert parallelism both set to four. Device count, topology and the runtime’s supported parallel plan are part of the requirement.

Eight RTX PRO 6000 Blackwell: the lower-capacity published path

Hugging Face publishes a prevalidated Inference Endpoints recipe using eight RTX PRO 6000 Blackwell GPUs for a 131,072-token context setting. NVIDIA’s current documentation lists 96GB for the Server Edition, giving 768GB nominal aggregate memory and 68GB above Meta’s 700GB minimum.

The Hugging Face launch article currently labels those devices as “98 GB,” while NVIDIA’s product documentation lists 96GB. HighVRAM uses the manufacturer’s 96GB specification for capacity arithmetic and requires the operator to record runtime-visible memory. This source discrepancy is another reason not to budget the pool to its final gigabyte.

This route has the smallest published aggregate capacity in the current evidence, but it also uses a much shorter context ceiling than the H200 endpoint recipe. It is not evidence that every self-managed eight-card workstation or server will reproduce the hosted configuration.

Eight H200: the published one-million-context endpoint path

Eight H200 GPUs at 141GB each provide 1,128GB nominal aggregate memory—428GB above the stated minimum and 594.989GB beyond the listed NVFP4 files. Hugging Face identifies this as its prevalidated endpoint recipe for the 1,048,576-token context tier.

This is a particularly important distinction: Meta describes NVFP4 as Blackwell-oriented, yet Hugging Face separately publishes a prevalidated H200 hosted path. Treat that recipe as evidence for the named endpoint configuration, not permission to generalize to arbitrary Hopper runtimes, driver stacks or topology.

Four GB300: the official SGLang reference

The official deployment article shows SGLang with --tp-size 4 and --ep-size 4 across four GB300 GPUs. NVIDIA’s current HGX AI Factory table lists the B300 tier at 288GB per GPU and 2.30TB for an eight-GPU node; four devices are therefore a 1,152GB nominal product-tier calculation. Some NVIDIA surfaces expose lower usable-memory figures for specific systems or profiles, so record what the runtime actually sees rather than substituting the headline number.

Eight B200: the official node-scale Blackwell path

NVIDIA documents an HGX B200 node as eight 180GB GPUs, totaling 1,440GB HBM3e. The official Muse Spark Open article says the NVFP4 checkpoint runs on a single B200 node. This is the clearest on-premises Blackwell path in the published evidence, but it is a complete server platform decision—not eight independent cards treated as a generic memory pool.

Context changes the hardware decision

Use casePublished path to investigate firstWhat still must be measured
131K hosted endpoint8×RTX PRO 6000 BlackwellExposed memory, exact endpoint/runtime build, modality, batch and concurrency
1M hosted endpoint8×H200Peak per-device memory, cache configuration, modality, batch and concurrency
Self-managed SGLang reference4×GB300Exact GPU identity, usable memory, TP/EP placement and software versions
Self-managed Blackwell node8×B200 HGX/DGX-class nodeQualified platform, runtime recipe, per-device peak, power and cooling
Lower-count experiment4×B200 or 3×B300 capacity candidateFramework support, placement, topology, correctness and failure behavior

Buying and validation checklist

  1. Choose the exact checkpoint: official NVFP4, BF16, or a separately supported derived quant.
  2. Choose the runtime recipe: preserve the named framework, version, quantization backend and launch arguments.
  3. Fix the context target: 131K and one million tokens are materially different memory workloads.
  4. Verify exact hardware identity: product, form factor, device count, exposed memory, MIG state and firmware.
  5. Record topology and placement: NVLink/NVSwitch, tensor parallelism, expert parallelism and any offload.
  6. Start small: text-only, short context, batch one and concurrency one.
  7. Measure every device: report peak memory per accelerator, failures, correctness, latency and throughput.
  8. Price the complete system: server, networking, storage, host memory, cooling, rack power, service and delivery.

Recommendation

For the lowest-capacity published route, investigate the prevalidated eight-RTX-PRO-6000 endpoint configuration and accept its 131K context boundary. For a published million-token hosted path, investigate eight H200 GPUs. For self-managed reference work, begin with the official four-GB300 SGLang recipe or a complete eight-B200 node. Treat four B200s and three B300s as experiments whose aggregate memory clears 700GB—not as validated buying recommendations.

Chosen the hardware? The Muse Spark Open deployment guide maps each checkpoint and platform to its current official runtime path, starter command and validation sequence.

Continue planning

Primary sources

Capacity math uses manufacturer nominal decimal GB. “Published” and “prevalidated” refer only to the named source configuration; they are not HighVRAM performance measurements or guarantees. Last checked October 25, 2026.