vLLM 0.25.1 Fixes Two Critical Bugs That Can Crash Multimodal Deployments

Three days ago vLLM announced the official 0.25 release; the following day an urgent 0.25.1 patch was issued with only two commits, but those changes can determine whether a production service runs correctly or produces garbled output.

Bug 1: Model startup hangs due to FFmpeg check

Symptom: Running vllm serve Qwen/Qwen3-VL-2B-Instruct to launch a multimodal model causes the process to freeze and the logs show a RuntimeError originating from import torchcodec.

Root cause: torchcodec checks for a system FFmpeg installation at import time and throws an exception if FFmpeg is absent. vLLM imports this module during startup even when video processing is not used.

Fix (PR #47888): Delay the FFmpeg check until the code actually calls video‑processing functions. The error now only appears when TorchCodec is truly needed, allowing normal startup without FFmpeg.

Affected scenarios:

All multimodal model deployments (e.g., Qwen‑VL, LLaVA)

Docker images without FFmpeg installed

Deployments that only use text or image capabilities but are slowed by the video module

Bug 2: NVFP4 models output garbled tokens

This issue is more insidious.

Symptom: Models quantized with NVFP4 (e.g., Gemma‑4, Qwen series NVFP4) generate streams of exclamation marks ( !!!!!) or completely meaningless characters.

Root cause: In v0.25.0 a new FlashInfer all‑reduce + RMSNorm + static‑quantization fusion introduced a hidden bug. When the activation tensor is BF16 but the RMSNorm weight is FP32 (a mixed‑precision design used by Gemma and Qwen), the fused kernel does not verify dtype compatibility and feeds mismatched data into the computation.

The hidden state becomes polluted, causing every subsequent token to be corrupted.

Fix (PR #48330): Add a dtype‑matching guard. If activation and RMSNorm weight dtypes differ, the code follows a safe path that skips the fusion; models with matching dtypes continue to benefit from the performance boost.

Affected scenarios:

All Gemma series models quantized with NVFP4

All Qwen series models quantized with NVFP4

Any mixed‑precision model where RMSNorm weight is FP32 and activation is BF16

Multi‑GPU inference that uses all‑reduce RMSNorm fusion

Upgrade Recommendation

pip install vllm==0.25.1

If you are running v0.25.0 and any of the following apply, upgrade immediately:

Deploying multimodal models on systems without FFmpeg

Using NVFP4‑quantized models (especially Gemma or Qwen series)

Multi‑GPU inference with all‑reduce RMSNorm fusion enabled

Conclusion

These two‑commit emergency patches are more critical than a typical minor version bump, indicating real‑world user pain after v0.25.0 launch. The first bug is easy to detect (startup block), while the second silently corrupts output, potentially misleading users about model capability.

Understanding the root causes and applying the fixes ensures stable multimodal deployments and correct NVFP4 model behavior.