Muse Spark Open hardware requirements: VRAM, GPUs and users for Meta's 816B model

Which servers run Muse Spark Open on premise

Muse Spark Open needs a server with eight GPUs. Its NVFP4 checkpoint of 533.0 GB fits eight NVIDIA RTX PRO 6000 Blackwell Server Edition cards with room for about 71 concurrent conversations of 32,768 tokens with a 16-bit cache, or 142 with an FP8 cache, by our users-per-card rule. Eight H200 NVL hold the same weights with nearly three times the spare memory, but only if the engine keeps the FP4 weights and computes in 16-bit, and the BF16 checkpoint of 1.64 TB needs a DGX B300 or two eight-card H200 NVL servers.

Meta's model card states that "the model requires a GPU with at least 700GB of VRAM for NVFP4 and 2TB for BF16". No single GPU has that much memory, so the figure describes the GPU memory of a whole server. Eight RTX PRO 6000 Server Edition cards have 768 GB; by our rule 664.3 GiB of it, 713 GB, holds weights and cache, which meets Meta's figure. Four-card servers do not: four H200 NVL miss the NVFP4 weights by 3.0 GiB, and four RTX PRO 6000 Server Edition by 164 GiB. Our eight-card RTX PRO 6000 Server Edition guide lists Muse Spark Open beside other models that need the whole server; this page sizes it in detail.

Muse Spark Open on Hugging Face: parameters, checkpoints and context

Meta publishes the model in a collection with two repositories, one in BF16 and one in NVFP4. We summed the safetensors files on both "Files" pages on 24 October 2026.

Model cards of meta-models/Muse-Spark-Open-816B-A42B and -NVFP4 and their file lists on Hugging Face, read on 24 October 2026; checkpoint sizes are our sums of the listed safetensors files (GB = 10⁹ bytes, GiB = 2³⁰ bytes). The vLLM recipe, updated 16 October 2026, gives "~533 GB" and "~1.64 TB".

The card names SGLang, vLLM, Hugging Face Transformers, TensorRT-LLM, Unsloth and llama.cpp as supported engines but pins no versions, and it names no GPU model. The card describes the model as a mixture-of-experts transformer with a Perception Encoder of 1.8B parameters; the file sums above cover every safetensors file in each repository, so they are what the server has to load. The vLLM recipe describes the NVFP4 build as "the primary NVIDIA Blackwell path" that "fits one 8-GPU node". Its header names vLLM 0.33.0, and it says to "Use Docker image for now until the code is in vLLM main repo", so the model may need a newer engine than the one your platform runs today.

KV cache: 46 sliding-window layers and 16 full layers

The cache decides how many people one server carries. The card gives 16 KV heads of dimension 64 per layer. The vLLM recipe adds the layer pattern: "Three layers in each cycle look back 2048 tokens; the other (layers 1, 5, …, 61) sees the whole context", which makes "46 narrow layers and 16 wide ones". The configuration file itself sits behind Meta's access form, so we count from these two published descriptions.

Each layer stores keys and values of 16 heads × 64 values, 4,096 bytes per token in 16-bit. The 16 full layers store every token, and the 46 narrow layers at most 2,048 tokens. By our count, one conversation therefore takes:

Our estimate from the attention figures on the model card and the layer pattern in vLLM's recipe, assuming the engine keeps only the last 2,048 tokens in the narrow layers. If an engine stored the full context in all 62 layers, a 32K conversation would take 7.75 GiB in 16-bit.

The recipe validates an FP8 cache ("either the default or --kv-cache-dtype fp8 KV cache") only for AMD's MXFP4 variant at the full 1M context; for the NVIDIA NVFP4 path it does not mention one. --kv-cache-dtype fp8 is a general vLLM option, so the FP8 column is our estimate for a layout that needs a test run on your hardware. With 16 KV heads, eight-way tensor parallelism gives each card two heads, and each card keeps one eighth of every conversation's cache. Unlike the latent caches of DeepSeek and Kimi models, nothing is copied to every card, and the cache memory of all eight cards adds up. Our guide to long-context LLM hardware compares these cache types.

Memory left and conversations per configuration

Our users-per-card rule takes 90 per cent of the memory the driver reports and subtracts 3 GiB per card: 83.0 GiB per RTX PRO 6000 Server Edition and 123.4 GiB per H200 NVL. What remains after the weights is cache.

Our estimates by the users-per-card rule for the NVFP4 checkpoint of 496.4 GiB, conversations at full length. H200 NVL rows assume the engine runs NVFP4 weight-only on Hopper. DGX B300: NVIDIA gives 2.1 TB of GPU memory for eight GPUs, about 270 GB each, read cautiously as 10⁹ bytes. The DSpark draft model of vLLM's recipe is not counted.

At 128K, eight RTX PRO 6000 Server Edition hold about 20 conversations with a 16-bit cache and 40 with an FP8 cache; eight H200 NVL about 58 and 117. At the full 1M context, our count gives about five conversations on eight RTX PRO 6000 Server Edition and 15 on eight H200 NVL, both with an FP8 cache. These are requests in flight at the same moment, far fewer than the number of staff who use the service, so measure the peak in your own logs before choosing between the two servers. We build eight-card servers with RTX PRO 6000 Server Edition or H200 NVL; send us your expected peak conversations and context length, and our team replies with the figures for each.

Eight RTX PRO 6000 Server Edition: NVFP4 on Blackwell

The RTX PRO 6000 computes FP4 on its Blackwell Tensor Cores, so it runs the NVFP4 checkpoint as published. vLLM's command for the NVIDIA NVFP4 path starts the model with --tensor-parallel-size 8, --enable-expert-parallel and --max-model-len 1048576, plus Meta's reasoning and tool parsers and a DSpark draft model for speculative decoding. The recipe states that NVIDIA "supports every parallelism this recipe offers: TP, TP + PP, TP + expert parallel, data + expert parallel".

The recipe does not name the RTX PRO 6000 or its compute capability 12.0, the SM120 generation. Kernels written for data-centre Blackwell are not always built for SM120, as our article on Blackwell RTX SM120 software support explains, so test the image on this card before you plan a service on it. The cards connect over PCIe only. Tensor parallelism over eight cards sends each layer's all-reduce across PCIe, and expert parallelism sends tokens to the cards that hold their experts. Our article on tensor parallelism without NVLink on the RTX PRO 6000 covers the settings that matter for this traffic.

Eight cards at 600 W draw 4.8 kW; with two processors and the rest of the server we estimate about 6.3 kW at the wall, a figure that a measurement on the delivered system confirms or corrects. That is more than a 230 V 32 A single-phase feed carries at 80 per cent, 5.89 kW, so the server needs a three-phase position, as our guide to GPU server power on 16 A, 32 A and three-phase shows. The configuration and ordering steps are on our page to buy an 8× RTX PRO 6000 Server Edition server.

Eight H200 NVL: more memory, weight-only FP4

Eight H200 NVL have 1,128 GB of HBM3e and 986.9 GiB by our rule, which leaves 490.5 GiB of cache after the NVFP4 weights. Hopper has no FP4 arithmetic. As our guide to FP4 models on the H200 NVL and Ada GPUs explains, vLLM runs NVFP4 checkpoints on Hopper only weight-only: the weights keep their 4-bit size in memory and the arithmetic runs in 16-bit. Neither Meta's card nor vLLM's recipe names Hopper for this model, so the H200 NVL rows are a memory fit that needs a test run.

The BF16 checkpoint, which Hopper runs natively, is 1,531.4 GiB and does not fit eight H200 NVL. Meta publishes no FP8 version. On an eight-card H200 NVL server the cards also form two NVLink domains of four, joined over PCIe, so the layout of choice is TP=4 × PP=2, one pipeline stage per domain, which the recipe's "TP + PP" covers. Our guide to the 8× H200 NVL server explains the domains and the commands.

BF16 and the next step: DGX B300 or two servers

The BF16 weights take 1,531.4 GiB before any cache. Two options hold them. A DGX B300 has eight B300 GPUs with about 270 GB each in one NVLink domain. Read cautiously as 10⁹ bytes, that is about 1,786 GiB by our rule, which leaves about 255 GiB, room for about 108 conversations of 32K with a 16-bit cache or 216 with an FP8 cache. In NVFP4, which the B300 computes natively, the same system keeps about 1,290 GiB free. We supply the DGX B300 per project; before we can quote, the distribution asks for the company, the project and the intended use, as our guide to buying a DGX B300 in the EU describes.

The second option is two servers with eight H200 NVL each, 1,973.8 GiB by our rule, joined over the network with pipeline parallelism between the servers. After the BF16 weights, about 442 GiB remain, roughly 187 conversations of 32K with a 16-bit cache. Our comparison of 1T models for 100 users on a DGX B300 or two H200 NVL servers works through that layout for several large models. For most companies the NVFP4 checkpoint on Blackwell is the practical choice; BF16 matters where a fine-tuning pipeline or an evaluation must start from the original weights.

Muse Model License: attribution, Model-as-a-Service and access

Muse Spark Open is published under the Muse Model License, which Meta dated 15 October 2026. It grants the right "to deal in the Software without restriction", including modification, fine-tuning, distillation and sale, provided that "The above copyright notice and this license and the Usage Policy shall be included in all copies". Licensees must "prominently display "Built with Muse Spark Open"" in the user interface of each product or service, or in its documentation, website or settings.

The commercial condition sits in Section 3. A licensee that offers Model as a Service, defined as providing "a third party with access to artificial intelligence models as a product or service, via API or a similar interface", must notify Meta and "enter into a separate written agreement with Meta" once "the aggregate gross revenue of the Licensee and its affiliates exceeds twenty (20) million US dollars" in a 12-month period. The section does not apply to "internal use, research, or any commercial activity that is not Model as a Service", nor to using the model "as a component to power features of the Licensee's own product or service". For European licensees, "Meta" means Meta Platforms Ireland Limited. We found no clause that excludes the EU or restricts use there. The Usage Policy states that the model is not intended for people under 18 and lists prohibited uses.

The repositories are gated: Meta's form asks for full legal name, date of birth and organisation name and cannot be edited after submission, so have the person who signs for your company fill it in. Whether the licence and policy fit your use is for your legal department to decide. A model run from downloaded weights on your own servers sends no prompts or outputs to Meta.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. For Muse Spark Open we build eight-card servers with RTX PRO 6000 Server Edition or H200 NVL, two AMD EPYC processors, DDR5 ECC memory of at least twice the GPU memory and NVMe storage for the 533 GB checkpoint, assembled and tested before delivery, on one EU contract and invoice with manufacturer warranty on every component. The DGX B300 we quote per project. Setting up the model, retrieval and the serving platform is part of our Private AI/ML service. Tell us whether you need images, video or audio as input, and we include the encoder load in the sizing.

FAQ