3 天前，大模型本地部署最强引擎，vLLM 大版本更新，v0.25 正式版发布
vLLM 昨天紧急发了 v0.25.1，只有 2 个 commit——但如果你在生产环境跑 vLLM，这两个修复可能直接决定你的服务是正常运行还是输出乱码
第一个 Bug：模型启动被 FFmpeg 卡死
问题现象：你用 vllm serve Qwen/Qwen3-VL-2B-Instruct 启动多模态模型，结果进程直接卡住不动，日志里报 RuntimeError 来自 import torchcodec
根本原因：TorchCodec 在 import 时会检查系统是否安装了 FFmpeg，没装就直接抛异常。问题是 vLLM 在启动阶段会 import 这个模块，哪怕你根本没用到视频处理功能，只是跑个文本/图片推理
修复方案（PR #47888）：把 FFmpeg 的检查从 import 时延迟到实际调用时。现在只有你真的需要用 TorchCodec 处理视频的时候才会报错，不影响正常启动
受影响场景：
-
所有多模态模型的部署（Qwen-VL、LLaVA 等） -
系统没装 FFmpeg 的 Docker 镜像 -
只用到文本/图片能力但被视频模块拖累的情况
第二个 Bug：NVFP4 模型输出全是乱码
这个才是真正的大坑
问题现象：用 NVFP4 量化的模型（比如 Gemma4、Qwen 系列的 NVFP4 版本），推理输出变成一串 !!!!! 或者完全无意义的乱码
根本原因：v0.25.0 里新加的 FlashInfer allreduce + RMSNorm + 静态量化融合有个隐藏 bug——当 activation 是 BF16 但 RMSNorm 的 weight 是 FP32 的时候（Gemma 和 Qwen 的 RMSNorm 就是这种混合精度设计），融合内核不会检查 dtype 是否匹配，直接把不兼容的数据塞进去算
结果就是 hidden state 被污染，后面的所有 token 生成全部跑偏，输出纯垃圾
修复方案（PR #48330）：加了一个 dtype 匹配检查的 guard。如果 activation 和 RMSNorm weight 的 dtype 不一样，就走安全路径（不融合）；dtype 相同的模型继续享受融合带来的性能提升
一张图看懂这个修复的逻辑：
受影响场景：
-
所有使用 NVFP4 量化的 Gemma 系列模型 -
所有使用 NVFP4 量化的 Qwen 系列模型 -
任何 RMSNorm weight 是 FP32 而 activation 是 BF16 的混合精度模型 -
跑在多卡（需要 allreduce）环境下时触发
升级建议
pip install vllm==0.25.1
如果你正在用 v0.25.0 并且满足以下任一条件，立即升级：
-
部署了多模态模型且环境没有 FFmpeg -
使用 NVFP4 量化模型（特别是 Gemma/Qwen 系列） -
多卡推理 + 使用了 allreduce RMSNorm 融合优化
总结
这种”2 个 commit 的紧急补丁”往往比大版本更值得关注——说明 v0.25.0 上线后有真实用户踩了坑，而且坑够深才值得紧急修
第一个 bug 是启动阻塞，容易发现；第二个 bug 是输出静默损坏，不容易发现但后果更严重——你的模型可能在默默输出垃圾而你以为是模型能力问题
如果你前几天刚升到 v0.25.0 然后发现 NVFP4 模型效果变差了，现在知道原因了