Muse Spark Open’s self-hosting recipes do not promise the same inputs everywhere. Superpower Daily’s bounded documentation review finds explicit text, image, audio and video support in specific NVIDIA configurations, while sampled AMD commands deliberately select text-only operation. Other routes leave media support unspecified—and NVIDIA’s Dynamo guide contains conflicting instructions for video.
The comparison asks which combinations of checkpoint, runtime software and hardware explicitly document each input. A checkpoint holds the saved model weights; a runtime loads them and handles requests. Our sample covers Meta’s hardware and inference guides, directly linked runtime evidence and the supplied Apple snapshot. It covers self-hosted inference, excluding hosted providers, cost, licensing and performance rankings. No inference requests were executed.
This October 17, 2026 review classifies inputs as documented, excluded by the configuration, or unspecified; conflicts remain unresolved. These are documentation findings, not hardware-wide capability judgments. The intended cutoff was 15:30 UTC, but snapshot retrieval at 15:32:10 UTC and later live checks do not establish an exact historical freeze. Pages and unpinned repository branches can change.
Four-input routes, with different requirements
The clearest positive findings concern specific NVIDIA deployments. Hugging Face’s SGLang reference uses Meta’s NVFP4 checkpoint on four GB300 GPUs and explicitly supports all four inputs. Its TP4/EP4 settings divide attention computation and the model’s expert components across four GPUs.
NVIDIA’s TensorRT-LLM guide also explicitly covers text, images, audio and video. It identifies an NVFP4 configuration validated on four GB300 NVL GPUs, with serving work kept together in an aggregated deployment. It requires the complete checkpoint and bundled tokenizer wrapper, which prepares text in the model’s expected format.
Native vLLM documents all four inputs on NVIDIA Blackwell, but its static recipe uses eight-way tensor parallelism with expert parallelism. Meta separately supplies a four-B300 command using four-way tensor parallelism. Those examples have different GPU counts and settings; they are not interchangeable instructions.
Transformers supplies another four-input route. Hugging Face identifies BF16 operation across 32 H200 GPUs and NVFP4 on one B200 node, alongside modality-specific examples. Meta requires Transformers 5.19 or later for the base integration and a separate branch for NVFP4. Software version and checkpoint format are part of the deployment definition.
AMD’s text-only result is explicit. Meta’s sampled commands all include --language-model-only, and vLLM’s recipe states that its AMD setup serves text only. The commands use eight MI350X or MI355X GPUs. They span BF16, BF16 with experts converted to MXFP4 at loading, preconverted Quark MXFP4 and Quark FP8 checkpoints. Throughput and latency variants retain the media exclusion.
Desktop and CPU paths leave different gaps
- Distributed MLX: The NVFP4 path uses mlx_lm.server across two M5 Ultra Mac Studios with 512GB each, or four with 256GB each. Text is documented; media remains unspecified. Setup requires macOS 26.2 or later, MLX 0.30.1 or later, and direct Thunderbolt links for remote memory access.
- llama.cpp: The ggml-org GGUF path explicitly documents text, image and audio requests, leaving video unspecified. Hugging Face reports Q2_K testing on an M3 Ultra with 512GB. That hardware example is not separate validation of successful requests for every modality or every backend.
- Intel and Unsloth: Intel’s INT4 SGLang example on Xeon 6 P-cores documents text, with media unspecified. Unsloth’s Dynamic-GGUF recipe makes multimodal input dependent on the backend and loaded assets; it does not establish a specific hardware configuration supporting all four inputs.
Video support does not automatically include sound
The native vLLM route samples video frames but does not automatically process the soundtrack. To include speech or other sound, users must extract the audio and submit it separately in the same request. Its four-input classification therefore does not mean a video file automatically delivers both visual and audio information.
Transformers takes a different route: loading a video’s audio requires load_audio_from_video=True. Direct audio input needs mono sound at 24kHz; the processor’s chat-template workflow can handle decoding, resampling and padding. These are request-preparation requirements, not differences in the model’s advertised input categories.
TensorRT-LLM adds resource constraints. Media tokens consume the serving token budget alongside text. Its validated serving window is 49,152 tokens, distinct from the model’s maximum context of 1,048,576. On GB300’s SM103 architecture, chunked prompt processing or cached-prefix reuse also requires an FP8 attention cache.
Dynamo’s video instructions remain in conflict
Dynamo’s GB200 and GB300 recipes show why a deployment wrapper cannot simply inherit its backend’s capabilities. NVIDIA’s guide directs video users to aggregated SGLang, yet also warns that video requests fail because the referenced container image lacks decord2, the package supplying SGLang’s video decoder. Together, those statements do not establish an unconditional working video route.
The disaggregated recipes, which separate prompt processing from generation, have another restriction: image and video frontend decoding is unsupported with DYN_SGL_FRONTEND_DECODING=true. Text has a smoke test—a basic request intended to check operation—while audio is unspecified.
Reader comments
Newest comments first. Replies stay oldest first.