live wire
▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸SECURITY · Red Hat Hardened Images fixes Moderate libpng denial-of-service flawRed Hat▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸SECURITY · Red Hat’s first Security Signals report shifts focus from CVE counts to risk paths (Oct. 15)Red Hat▸PLATFORM · IBM adds non-destructive FlexVolume-to-CSI migration tool for OpenShift object storageIBM Cloud▸vLLM tests agent-built Kimi K3 decode path at up to 1.9× speedup; PR remains openvLLM▸AI · LeaderWorkerSet 1.0 changes rollout defaults for disaggregated AI workloadsKubernetes SIGs▸SECURITY · Red Hat flags active exploitation of kernel flaw affecting OpenShift CoreOS; no fix listedRed Hat Product Security▸AI · Red Hat sets Dec. 9 showcase for AI 3.6 agent governance and model servicesRed Hat▸vLLM 0.32.0 drops Python 3.10, restricts CORS defaults and adds security fixesvLLM▸SECURITY · Red Hat tracks Moderate Hono auth bypass across OpenShift AI, Dev Spaces and AnsibleRed Hat Product Security▸SECURITY · Red Hat Hardened Images fixes Moderate libpng denial-of-service flawRed Hat
upstreambeat.ai
releaseAI

vLLM adds day-zero serving support for Meta's 816B-parameter Muse Spark Open

The initial integration spans NVIDIA and AMD deployments, a DSpark draft model and limited TPU access, while the main code change still awaits merge.

vLLM support spans NVIDIA, AMD, and TPU with throughput figures.
Chart: figures from the story
By The News Desk· Oct 16, 2026the quick take — two AI hosts go live when you do

vLLM has announced day-zero support for Meta's Muse Spark Open, an open-weight mixture-of-experts model aimed at long-horizon coding-agent workloads. The model has 816 billion total parameters, activates 42 billion per token and supports a one-million-token context window.

The vLLM engineering post describes deployment paths for NVIDIA and AMD accelerators, initial TPU work, and a DSpark speculative-decoding model intended to raise serving throughput. It also carries an important availability caveat: the main implementation is still under review in vLLM pull request 61879. A nightly PyPI wheel is expected only after that code merges, which the project says usually takes about a week.

What the first integration supports

Meta released BF16 and NVFP4 weights, while AMD released MXFP4 weights. vLLM provides prebuilt serving images for NVIDIA and AMD. Tensor and pipeline parallelism are available on both vendors; NVIDIA additionally gets expert parallelism, tensor-and-expert parallelism, decode expert parallelism and prefill/decode disaggregation. ROCm support currently covers tensor and pipeline parallelism on AMD Instinct MI355X, including FP8 and MXFP4 formats.

The model's architecture helps explain the deployment demands. All 62 decoder layers are MoE layers with 256 experts each. Layers alternate full attention with sliding-window attention in a four-layer cycle: three layers look at a 2,048-token window and the fourth sees the full context. vLLM says that structure cuts the one-million-token KV cache to slightly more than one quarter of an all-full-attention design.

Muse Spark Open also accepts images, video and audio. Images and video frames use the same roughly two-billion-parameter Perception Encoder as Muse Glimmer; audio runs through a separate 118-million-parameter encoder. Video audio is not processed automatically, so applications that need both must send the video and an extracted audio stream as separate inputs.

DSpark and the TPU boundary

The integration includes a DSpark draft model for CUDA and ROCm. DSpark uses block diffusion to propose as many as seven tokens in one pass, with confidence-based scheduling and adaptive verification. Operators must enable it explicitly in vLLM's speculative configuration.

Initial TPU support sits behind a narrower boundary. vLLM says it is built on TorchTPU and directs users to contact the project or Google for code access. The post reports more than 650 tokens per second on four TPU v7 chips and more than 960 on eight with DSpark at an acceptance length of six. Those figures are project-reported results, not a cross-platform comparison under the same deployment recipe.

What operators should do

Teams testing immediately can start with the vendor container images and the documented serve command, but should pin those images and treat the integration as pre-merge software. PyPI-based workflows need to wait for pull request 61879 to land and for the nightly wheel to include it.

The practical signal is breadth rather than maturity: vLLM has a path for an unusually large multimodal MoE model across the two major GPU stacks, a speculative decoder and early TPU work. Production readiness will depend on the pending merge, hardware-specific parallelism limits and workload testing at the context lengths an application will actually use.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk