{"article":{"slug":"day-0-support-for-muse-spark-open-on-vllm","title":"Day 0 support for Muse Spark Open on vLLM","subtitle":null,"summary":"The vLLM team explains its day-0 support for Meta's Muse Spark Open, an 816B-total, 42B-active MoE model with 1M context and multimodal inputs: usage, model architecture details, DSpark speculative decoding, NVIDIA, AMD and initial TPU serving, and reinforcement learning support in vLLM.","content_type":"announcement","language":"en","canonical_url":"https://vllm.ai/blog/2026-10-15-muse-spark-open","author":{"name":"vLLM Team","url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"vLLM","url":"https://vllm.ai/","listing_slug":null,"listing":null},"topics":[{"name":"AI","slug":"ai","url":"https://listedarticles.com/topics/ai"},{"name":"LLMs","slug":"llms","url":"https://listedarticles.com/topics/llms"},{"name":"Open Source","slug":"open-source","url":"https://listedarticles.com/topics/open-source"},{"name":"Infrastructure","slug":"infrastructure","url":"https://listedarticles.com/topics/infrastructure"}],"about_listings":[],"cover_image_url":null,"license":"all-rights-reserved","word_count":1561,"reading_minutes":7,"published_at":"2026-10-15T00:00:00.000Z","added_at":"2026-10-18T11:13:02.558Z","updated_at":"2026-10-18T11:13:02.558Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/day-0-support-for-muse-spark-open-on-vllm","markdown_url":"https://listedarticles.com/articles/day-0-support-for-muse-spark-open-on-vllm.md","example":false,"citation":"vLLM Team, vLLM. \"Day 0 support for Muse Spark Open on vLLM.\" 15 Oct 2026. https://vllm.ai/blog/2026-10-15-muse-spark-open (all-rights-reserved)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://vllm.ai/blog/2026-10-15-muse-spark-open"},"body_markdown":"We're excited to have worked with Meta Superintelligence Labs to bring Muse Spark Open to vLLM on day 0. Muse Spark Open is an open-weight sparse mixture-of-experts (MoE) model, built for long-horizon agentic coding workflows. It is the most capable US open-weights model to date and it is the model Muse Glimmer 30B was distilled from.\n\n## Highlights\n\n- Architecture: 816B total parameters, 42B active per token with a 1M context window.\n- Quantization: Meta released the model in both BF16 and NVFP4. MXFP4 weights were released by AMD.\n- Multimodal: Native image and video perception through the same Perception Encoder as Muse Glimmer, with additional audio support.\n- Parallelism: Tensor Parallelism and Pipeline Parallelism on both Nvidia and AMD. EP, TEP, DEP and PD disaggregation on Nvidia. Initial support on TPU is also available.\n- Speculative decoding: We have trained a DSpark draft model, supported on both CUDA and ROCm that accelerates the model performance, tested on the SPEED bench.\n\n## Usage\n\nPrebuilt images are available for both vendors:\n\n- Nvidia: vllm/vllm-openai:muse-spark-open\n- AMD: vllm/vllm-openai-rocm:muse-spark-open\n\nNote that the model will only be available at nightly PyPI wheel after the code ([PR #61879](https://github.com/vllm-project/vllm/pull/61879)) is reviewed and merged, which usually takes about a week.\n\n```\n# Rust frontend is recommended\nexport VLLM_USE_RUST_FRONTEND=1\n \nvllm serve meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \\\n --tensor-parallel-size 8 \\\n --enable-expert-parallel \\\n --max-model-len 1048576 \\\n --reasoning-parser muse \\\n --tool-call-parser muse \\\n --enable-auto-tool-choice \\\n --speculative-config '{\"method\":\"dspark\",\"model\": \"Inferact/Muse-Spark-Open-DSpark\",\"num_speculative_tokens\":7,\"draft_sample_method\":\"probabilistic\",\"rejection_sample_method\":\"block\",\"enable_adaptive_verification\":true}'\n```\n\nTo use this model with plain text:\n\n```\n curl http://localhost:8000/v1/chat/completions \\\n -H 'Content-Type: application/json' \\\n -d '{\n \"model\": \"meta-models/Muse-Spark-Open-816B-A42B-NVFP4\",\n \"messages\": [{\"role\": \"user\", \"content\": \"Refactor this module.\"}],\n \"reasoning_effort\": \"xhigh\"\n }'\n```\n\nFor multimodal perception:\n\n```\n curl http://localhost:8000/v1/chat/completions \\\n -H 'Content-Type: application/json' \\\n -d '{\n \"model\": \"meta-models/Muse-Spark-Open-816B-A42B\",\n \"messages\": [{\"role\": \"user\", \"content\": [\n {\"type\": \"image_url\", \"image_url\": {\"url\": \"https://example.com/screenshot.png\"}},\n {\"type\": \"video_url\", \"video_url\": {\"url\": \"https://example.com/demo.mp4\"}},\n {\"type\": \"audio_url\", \"audio_url\": {\"url\": \"https://example.com/clip.wav\"}},\n {\"type\": \"text\", \"text\": \"What is happening here, and when?\"}\n ]}]\n }'\n```\n\n## Implementation details\n\n### Model architecture\n\n*Figure 1: One of the 62 identical decoder layers. Every block is normalized before and after, `x + post_norm(F(norm(x)))`. [Open it full-screen](https://vllm.ai/blog-assets/interactive_pages/muse-spark-open-decoder-layer.html).*\n\nMuse Spark Open is a mixture-of-experts model with 816B total parameters including the text decoder, plus a 2B vision encoder and a small audio encoder alongside it. The decoder has 62 layers, and every one of them is a mixture-of-experts layer. Here is where the weights sit:\n\n| part | size |\n| --- | --- |\n| 256 experts per layer | 799 B |\n| attention | 13.5 B |\n| MoE latent projections | 4.2 B |\n| embedding and output layer | 3.3 B |\n| vision tower (separate) | 1.9 B |\n\nThe model architecture is similar to Muse Glimmer. For folks who haven't used Muse Glimmer. There are a few things in this model architecture worth a closer look.\n\n*Figure 2: Inside the attention block. Queries and keys are normalized before they meet, and each head's output is normalized before a learned gate scales it. [Open it full-screen](https://vllm.ai/blog-assets/interactive_pages/muse-spark-open-attention.html).*\n\n**Sandwich normalization.** Most decoders put one normalization layer before each block, giving x + F(norm(x)) Muse Spark Open, similar to Muse Glimmer, place one before and one after, like the two slices of a sandwich with the block sitting in between, giving x + post\\_norm(F(norm(x)))\n\n*Figure 3: The mixture-of-experts block. A shared squeeze halves each token from 8192 to 4096 before the experts and an expand restores 8192 after. [Open it full-screen](https://vllm.ai/blog-assets/interactive_pages/muse-spark-open-moe.html).*\n\n**Latent MoE**. Every mixture-of-experts (MoE) layer carries two extra matrices, shared by all 256 experts in that layer. The code calls them the pooler and unpooler, though neither is pooling in the usual sense, instead both are learned projections to squeeze and expand the dimensions. The pooler is an 8192 × 4096 matrix that halves each token's width before it reaches the experts; while the unpooler restores the full width afterwards. The experts therefore work entirely at 4096 rather than 8192, which effectively halved the number of parameters required in the two expert projection layers.\n\n*Figure 4: Which layers attend to what. 46 of the 62 layers keep a 2048-token window of KV and 16 keep every token, so the KV cache at 1M tokens is about a quarter of all-full attention. [Open it full-screen](https://vllm.ai/blog-assets/interactive_pages/muse-spark-open-attention-pattern.html).*\n\n**Hybrid attention.** Layers alternate between full attention and Sliding Window Attention (SWA) on a repeating cycle of 4 with three attending to a 2048-token window and the fourth looking at the whole context. The cycle is anchored to the end of the stack so the final layer is always a full attention layer. Across 62 layers, that gives 46 narrow layers and 16 wide ones where the narrow layers only hold recent KV. At 1M tokens, this brings the cache to just over ¼ of what all-full attention would need. This is what makes 1M context length affordable.\n\n**Vision Encoder.** Muse Spark Open uses the same Perception Encoder as Muse Glimmer, a 2B parameter tower that reads images at their native resolution, rather than resizing them to a square. Videos run through the same encoder: frames are sampled at load time as a series of sampled video frames with timestamp tokenized in the prompt.\n\n**Audio Encoder.** Audio is read as raw waveform at 24 kHz and Every 1920 samples, i.e. 80ms become one token through a series of transformations. The whole audio encoder is just 118M parameters. Note that the video's audio track is not processed. To give the model both the pictures and the sound of a clip, send the video and the extracted audio as two separate content parts in the same request.\n\n### DSpark\n\nTo accelerate Muse Spark Open inference on vLLM, we trained a speculator using DSpark, a speculative decoding algorithm that uses block diffusion to propose up to seven draft tokens in a single pass. Confidence-based scheduling helps sustain significant speedups even at large batch sizes, where speculative decoding traditionally offers diminishing returns, as shown in the results below.\n\n*Figure 5: Aggregate output throughput against per-user decode speed on 4 × NVIDIA GB300 (TP4), one point per concurrency level from c1 to c256. Hover a point for every series' values, or [open it full-screen](https://vllm.ai/blog-assets/interactive_pages/muse-spark-open-dspark-throughput.html).*\n\nOur speculator also uses the Muse Spark Open sliding-window attention to keep drafting lightweight, even with a 1M-token context. Together, these choices make it well suited to production workloads spanning a wide range of batch sizes and context lengths.\n\nTo enable it, add this when the server starts:\n\n```\n--speculative-config '{\"method\":\"dspark\",\"model\": \"Inferact/Muse-Spark-Open-DSpark\",\"num_speculative_tokens\":7,\"draft_sample_method\":\"probabilistic\",\"rejection_sample_method\":\"block\",\"enable_adaptive_verification\":true}'\n```\n\n### Nvidia\n\nNvidia team improved Muse Spark Open inference across FlashInfer and vLLM through fused normalization, gating, and residual kernels; fused MoE finalization with tensor-parallel communication and RMSNorm; a new low-latency BF16 GEMM implementation and reduced compilation overhead; TEP pooler/unpooler sharding with fused MNNVL collectives; TF32 router GEMM fed by the norm's FP32 output; and improvements to data movement, hardware support, and runtime reliability.\n\n### AMD\n\nThanks to the AMD team, we have also supported the model on AMD Instinct™ MI355X GPUs, in both FP8 and MXFP4 quantized formats, providing improved inference performance and deployment efficiency. Note that ROCm currently supports both Tensor-Parallel and Pipeline-Parallelism.\n\n### TPU\n\nWe have added support for Muse Spark Open on TPU on top of TorchTPU. Please contact us or Google for code access. We have also built [megakernels](https://github.com/Inferact/tpu-megakernels) for Muse Spark Open. With DSpark speculative decoding (acceptance length = 6), they reach over 650 tokens/sec on 4 TPU v7 chips and over 960 tokens/sec on 8 chips. Without speculative decoding, they still deliver over 270 and 350 tokens/sec, respectively.\n\n## Reinforcement learning in vLLM\n\nvLLM also supports LoRA RL on Muse Spark Open from day 0, serving as the rollout engine with Verl FSDP2 as the trainer. vLLM serves the original NVFP4 checkpoint with the LoRA adapter applied on top. The trainer runs on a BF16 dequantization of the same weights and updates only the adapter (rank 32, alpha 64), which covers attention, the MoE latent projections and all routed experts. It also replays the rollout’s MoE routing (R3), and only the adapter is synced back to vLLM after each step.\n\nWe trained with GRPO on DAPO-Math-17K for 150 steps on 16 GB300 GPUs, sampling 8 responses for each of 32 prompts per step with up to 4K tokens per response. The accuracy on AIME-2024 (mean@8) went from 0.56 before training to 0.85 by the end of the run. Throughout the run, the k3 KL between the trainer’s and vLLM’s log-probabilities held near 2×10⁻⁴. More details are available in . In the vLLM ecosystem, Titan RL also uses vLLM as its rollout engine to provide day-0 RL support.\n\n![Muse Spark Open LoRA RL results](https://vllm.ai/blog-assets/figures/2026-10-15-muse-spark-open/lora-rl-results.png)\n\nMuse Spark Open LoRA RL results\n\n## Acknowledgement\n\nWe extend our sincere gratitude to the teams at Meta Superintelligence Labs and the vLLM community for their close collaboration in delivering Day 0 support for Muse Spark Open on vLLM. We also thank Inferact for training the DSpark speculator and TPU integration, alongside NVIDIA and AMD for their vital hardware optimizations.\n\nContributors:\n\n- Inferact: Jie Li, Zifeng Mo, Zixi Qi, Jeff Ma, Ziqi Zhao, Dakai An, Ao Shen\n- Meta: Beto de Paola, Sidhartha Reddy Potu\n- Nvidia: Cyrus Chang, Duncan Moss, Marek Pikulski, Seong Hee Lee\n- AMD: Andy Luo, Hongxia Yang, Haichen Zhang\n\nShare:\n\n[View Markdown Source](https://github.com/vllm-project/vllm-project.github.io/blob/main/_posts/2026-10-15-muse-spark-open.md)\n","body_html":"

We're excited to have worked with Meta Superintelligence Labs to bring Muse Spark Open to vLLM on day 0. Muse Spark Open is an open-weight sparse mixture-of-experts (MoE) model, built for long-horizon agentic coding workflows. It is the most capable US open-weights model to date and it is the model Muse Glimmer 30B was distilled from.

\n

Highlights

\n\n

Usage

\n

Prebuilt images are available for both vendors:

\n\n

Note that the model will only be available at nightly PyPI wheel after the code (PR #61879) is reviewed and merged, which usually takes about a week.

\n
# Rust frontend is recommended\nexport VLLM_USE_RUST_FRONTEND=1\n \nvllm serve meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \\\n    --tensor-parallel-size 8 \\\n    --enable-expert-parallel \\\n    --max-model-len 1048576 \\\n    --reasoning-parser muse \\\n    --tool-call-parser muse \\\n    --enable-auto-tool-choice \\\n    --speculative-config '{"method":"dspark","model": "Inferact/Muse-Spark-Open-DSpark","num_speculative_tokens":7,"draft_sample_method":"probabilistic","rejection_sample_method":"block","enable_adaptive_verification":true}'
\n

To use this model with plain text:

\n
  curl http://localhost:8000/v1/chat/completions \\\n    -H 'Content-Type: application/json' \\\n    -d '{\n      "model": "meta-models/Muse-Spark-Open-816B-A42B-NVFP4",\n      "messages": [{"role": "user", "content": "Refactor this module."}],\n      "reasoning_effort": "xhigh"\n    }'
\n

For multimodal perception:

\n
 curl http://localhost:8000/v1/chat/completions \\\n   -H 'Content-Type: application/json' \\\n   -d '{\n     "model": "meta-models/Muse-Spark-Open-816B-A42B",\n     "messages": [{"role": "user", "content": [\n       {"type": "image_url", "image_url": {"url": "https://example.com/screenshot.png"}},\n       {"type": "video_url", "video_url": {"url": "https://example.com/demo.mp4"}},\n       {"type": "audio_url", "audio_url": {"url": "https://example.com/clip.wav"}},\n       {"type": "text",      "text": "What is happening here, and when?"}\n     ]}]\n   }'
\n

Implementation details

\n

Model architecture

\n

Figure 1: One of the 62 identical decoder layers. Every block is normalized before and after, x + post_norm(F(norm(x))). Open it full-screen.

\n

Muse Spark Open is a mixture-of-experts model with 816B total parameters including the text decoder, plus a 2B vision encoder and a small audio encoder alongside it. The decoder has 62 layers, and every one of them is a mixture-of-experts layer. Here is where the weights sit:

\n
partsize
256 experts per layer799 B
attention13.5 B
MoE latent projections4.2 B
embedding and output layer3.3 B
vision tower (separate)1.9 B
\n

The model architecture is similar to Muse Glimmer. For folks who haven't used Muse Glimmer. There are a few things in this model architecture worth a closer look.

\n

Figure 2: Inside the attention block. Queries and keys are normalized before they meet, and each head's output is normalized before a learned gate scales it. Open it full-screen.

\n

Sandwich normalization. Most decoders put one normalization layer before each block, giving x + F(norm(x)) Muse Spark Open, similar to Muse Glimmer, place one before and one after, like the two slices of a sandwich with the block sitting in between, giving x + post_norm(F(norm(x)))

\n

Figure 3: The mixture-of-experts block. A shared squeeze halves each token from 8192 to 4096 before the experts and an expand restores 8192 after. Open it full-screen.

\n

Latent MoE. Every mixture-of-experts (MoE) layer carries two extra matrices, shared by all 256 experts in that layer. The code calls them the pooler and unpooler, though neither is pooling in the usual sense, instead both are learned projections to squeeze and expand the dimensions. The pooler is an 8192 × 4096 matrix that halves each token's width before it reaches the experts; while the unpooler restores the full width afterwards. The experts therefore work entirely at 4096 rather than 8192, which effectively halved the number of parameters required in the two expert projection layers.

\n

Figure 4: Which layers attend to what. 46 of the 62 layers keep a 2048-token window of KV and 16 keep every token, so the KV cache at 1M tokens is about a quarter of all-full attention. Open it full-screen.

\n

Hybrid attention. Layers alternate between full attention and Sliding Window Attention (SWA) on a repeating cycle of 4 with three attending to a 2048-token window and the fourth looking at the whole context. The cycle is anchored to the end of the stack so the final layer is always a full attention layer. Across 62 layers, that gives 46 narrow layers and 16 wide ones where the narrow layers only hold recent KV. At 1M tokens, this brings the cache to just over ¼ of what all-full attention would need. This is what makes 1M context length affordable.

\n

Vision Encoder. Muse Spark Open uses the same Perception Encoder as Muse Glimmer, a 2B parameter tower that reads images at their native resolution, rather than resizing them to a square. Videos run through the same encoder: frames are sampled at load time as a series of sampled video frames with timestamp tokenized in the prompt.

\n

Audio Encoder. Audio is read as raw waveform at 24 kHz and Every 1920 samples, i.e. 80ms become one token through a series of transformations. The whole audio encoder is just 118M parameters. Note that the video's audio track is not processed. To give the model both the pictures and the sound of a clip, send the video and the extracted audio as two separate content parts in the same request.

\n

DSpark

\n

To accelerate Muse Spark Open inference on vLLM, we trained a speculator using DSpark, a speculative decoding algorithm that uses block diffusion to propose up to seven draft tokens in a single pass. Confidence-based scheduling helps sustain significant speedups even at large batch sizes, where speculative decoding traditionally offers diminishing returns, as shown in the results below.

\n

Figure 5: Aggregate output throughput against per-user decode speed on 4 × NVIDIA GB300 (TP4), one point per concurrency level from c1 to c256. Hover a point for every series' values, or open it full-screen.

\n

Our speculator also uses the Muse Spark Open sliding-window attention to keep drafting lightweight, even with a 1M-token context. Together, these choices make it well suited to production workloads spanning a wide range of batch sizes and context lengths.

\n

To enable it, add this when the server starts:

\n
--speculative-config '{"method":"dspark","model": "Inferact/Muse-Spark-Open-DSpark","num_speculative_tokens":7,"draft_sample_method":"probabilistic","rejection_sample_method":"block","enable_adaptive_verification":true}'
\n

Nvidia

\n

Nvidia team improved Muse Spark Open inference across FlashInfer and vLLM through fused normalization, gating, and residual kernels; fused MoE finalization with tensor-parallel communication and RMSNorm; a new low-latency BF16 GEMM implementation and reduced compilation overhead; TEP pooler/unpooler sharding with fused MNNVL collectives; TF32 router GEMM fed by the norm's FP32 output; and improvements to data movement, hardware support, and runtime reliability.

\n

AMD

\n

Thanks to the AMD team, we have also supported the model on AMD Instinct™ MI355X GPUs, in both FP8 and MXFP4 quantized formats, providing improved inference performance and deployment efficiency. Note that ROCm currently supports both Tensor-Parallel and Pipeline-Parallelism.

\n

TPU

\n

We have added support for Muse Spark Open on TPU on top of TorchTPU. Please contact us or Google for code access. We have also built megakernels for Muse Spark Open. With DSpark speculative decoding (acceptance length = 6), they reach over 650 tokens/sec on 4 TPU v7 chips and over 960 tokens/sec on 8 chips. Without speculative decoding, they still deliver over 270 and 350 tokens/sec, respectively.

\n

Reinforcement learning in vLLM

\n

vLLM also supports LoRA RL on Muse Spark Open from day 0, serving as the rollout engine with Verl FSDP2 as the trainer. vLLM serves the original NVFP4 checkpoint with the LoRA adapter applied on top. The trainer runs on a BF16 dequantization of the same weights and updates only the adapter (rank 32, alpha 64), which covers attention, the MoE latent projections and all routed experts. It also replays the rollout’s MoE routing (R3), and only the adapter is synced back to vLLM after each step.

\n

We trained with GRPO on DAPO-Math-17K for 150 steps on 16 GB300 GPUs, sampling 8 responses for each of 32 prompts per step with up to 4K tokens per response. The accuracy on AIME-2024 (mean@8) went from 0.56 before training to 0.85 by the end of the run. Throughout the run, the k3 KL between the trainer’s and vLLM’s log-probabilities held near 2×10⁻⁴. More details are available in https://github.com/verl-project/verl/pull/8257. In the vLLM ecosystem, Titan RL also uses vLLM as its rollout engine to provide day-0 RL support.

\n
\"Muse
\n

Muse Spark Open LoRA RL results

\n

Acknowledgement

\n

We extend our sincere gratitude to the teams at Meta Superintelligence Labs and the vLLM community for their close collaboration in delivering Day 0 support for Muse Spark Open on vLLM. We also thank Inferact for training the DSpark speculator and TPU integration, alongside NVIDIA and AMD for their vital hardware optimizations.

\n

Contributors:

\n\n

Share:

\n

View Markdown Source

","headings":[{"level":2,"text":"Highlights","id":"highlights"},{"level":2,"text":"Usage","id":"usage"},{"level":2,"text":"Implementation details","id":"implementation-details"},{"level":3,"text":"Model architecture","id":"model-architecture"},{"level":3,"text":"DSpark","id":"dspark"},{"level":3,"text":"Nvidia","id":"nvidia"},{"level":3,"text":"AMD","id":"amd"},{"level":3,"text":"TPU","id":"tpu"},{"level":2,"text":"Reinforcement learning in vLLM","id":"reinforcement-learning-in-vllm"},{"level":2,"text":"Acknowledgement","id":"acknowledgement"}]}}