北京
3 天前，
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 ）：把 FFmpeg 的檢查從 import 時延遲到實際調用時?，F在只有你真的需要用 TorchCodec 處理視頻的時候才會報錯，不影響正常啟動
受影響場景：
所有多模態模型的部署（Qwen-VL、LLaVA 等）
系統沒裝 FFmpeg 的 Docker 鏡像
只用到文本/圖片能力但被視頻模塊拖累的情況
這個才是真正的大坑
問題現象：用 NVFP4 量化的模型（比如 Gemma4、Qwen 系列的 NVFP4 版本），推理輸出變成一串 !!!!! 或者完全無意義的亂碼
根本原因：v0.25.0 里新加的 FlashInfer allreduce + RMSNorm + 靜態量化融合有個隱藏 bug——當 activation 是 BF16 但 RMSNorm 的 weight 是 FP32 的時候（Gemma 和 Qwen 的 RMSNorm 就是這種混合精度設計），融合內核不會檢查 dtype 是否匹配，直接把不兼容的數據塞進去算
結果就是 hidden state 被污染，后面的所有 token 生成全部跑偏，輸出純垃圾
修復方案（PR ）：加了一個 dtype 匹配檢查的 guard。如果 activation 和 RMSNorm weight 的 dtype 不一樣，就走安全路徑（不融合）；dtype 相同的模型繼續享受融合帶來的性能提升
一張圖看懂這個修復的邏輯：
vLLM 0.25.1 dtype guard 修復流程
受影響場景：
所有使用 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 模型效果變差了，現在知道原因了
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
