vLLM 最新版來了，修復 DeepSeek-V4 跑不穩、跑不快的問題

節前我連著寫了三篇 vLLM × DeepSeek V4 的文章：

勞動節假期還沒過完，vLLM 團隊就給我加了道菜——0.20.1 緊急 patch 出爐了，主線就一句話：把 DSV4 跑不穩、跑不快的問題集中處理一遍

簡介

先把版本性質說清楚：v0.20.1 是 v0.20.0 的補丁版本，不是新功能堆料，而是圍繞 DeepSeek V4 做穩定化 + 性能調優，外加一批通用 bug 修復

如果你正在本地跑 DSV4 / DSV4-Flash，強烈建議升級；如果你還在用 0.19.x 老老實實跑 V3，那這版意義不大，等 0.21 再說

DeepSeek V4 這一塊改了啥

這是這個 patch 的主線，我認真研究了 release notes ：

1. 模型支持收口

• 把 DSV4 的 base model 正式接進來（PR ）——之前 V4 是帶"實驗"標簽的，這一版算是把基礎打牢了

• Pure TP 模式下給 megamoe flag 上了保護（），避免錯誤配置直接把進程干崩

2. 性能優化（這部分含金量很高）

• Multi-stream pre-attention GEMM （）：把 attention 之前的矩陣乘法拆到多個 CUDA stream 上并發跑，解決了 GEMM 等 attention 卡 GPU 利用率的老問題

• 配套加了一個調優旋鈕 VLLM_MULTI_STREAM_GEMM_TOKEN_THRESHOLD （、），還順手把默認值調到了一個比較合理的點上——這就是寫過《為何如此困難》那篇里抱怨"參數全靠玄學"的直接回應

• FlashInfer one-sided 通信支持 BF16 + MXFP8 all-to-all （）：MoE 跨 GPU 調度的核心通信路徑，BF16/MXFP8 雙精度都打通，多卡部署 V4 這下順了

• PTX cvt 指令加速 FP32→FP4 轉換 （）：直接下到指令級別壓榨硬件，FP4 推理路徑吞吐能再上一檔

• head_compute_mix_kernel tile kernel 集成（）：head 計算路徑專門做了 kernel 優化

3. 一批要命的 Bug 修復

這部分尤其值得貼出來，因為不少都是社區里反復哀嚎過的：

• TopK=1024 時持久化 topk 協作死鎖 （）——多并發跑久了進程突然卡死，元兇就是這個

• RadixRowState 的 inter-CTA 初始化競爭 （）

• 臨時把 persistent topk 關掉作為 workaround（）——穩定性優先于性能的取舍

• AOT 編譯緩存導致 import error （）——升級后報"模塊導入失敗"，多半就是它

• torch inductor 報錯 （）

• RoPE cache 重復初始化 （）——表現是顯存被偷偷吃掉一塊

• DSV3.2 / V4 非流式 tool calls 類型轉換缺失 （）——做 Agent 調用的老板必須升

隨機卡死、顯存莫名爆漲、tool call 偶發不返回、OOM 之后再起進程報 import error——這次基本都被一鍋端了

通用 Bug 修復

不只是 V4，0.20.1 還順手把幾個影響所有用戶的 bug 修了：

• max_num_batched_token 沒被 CUDA graph 正確捕獲（）

• num_gpu_blocks_override 在 max_model_len 校驗里沒被算進去（）——手動調顯存塊數的老板請抬頭

• 自動禁用 cumem 內存池附近的 expandable_segments （）

• BailingMoE linear layer（）和 V2.5 的 MLA RoPE 旋轉修復（）

• reasoning parser 的 kwargs 沒傳給 structured output（）——對結構化輸出影響很大

• ROCm：Quark W4A8 GPT-OSS 的 input_ids 和 expert_map 參數修復（）

ROCm 用戶也別走，這版對你們也有禮物

安裝

升級方式沒變化，CUDA 13.0 + PyTorch 2.11 是 0.20.x 的標配，0.20.1 也跟著這個組合：

# 推薦用 uv
uv pip install --upgrade vllm


 # 或者老老實實 pip
pip install --upgrade vllm

如果你還在 CUDA 12.9 的環境上，官方推薦的寫法是：

uv pip install vllm --torch-backend=cu129

Docker 鏡像：

docker pull vllm/vllm-openai:v0.20.1

升級前如果你跑過 0.20.0，記得清一下 ~/.cache/vllm 下面的 AOT 編譯緩存，否則可能命中 那個 import error

我的建議

? 一句話：正在跑 V4 的，立刻升；其他用戶，按部就班升

具體到幾類老板：

• 跑 DSV4-Flash 的小機型用戶 （比如我前面那篇 2×H20 96GB 的配置）：直接升，多 stream GEMM + FP4 轉換加速對你們這種"卡顯存又卡算力"的場景收益最大

• 多卡集群跑滿血 V4 ：FlashInfer all-to-all 的 BF16/MXFP8 支持是核心收益，all-reduce 階段的瓶頸被進一步打開

• 做 Agent / Function Calling 的 ：tool calls 類型轉換那個 fix（）你必須升，不然偶發返回缺字段會讓上層應用一頭霧水

• 還在 V3 / V3.2 陣營 ：升級風險低收益也不大，可以等 0.21 主線版本

看完這次 release notes 我有一個挺直接的感受：vLLM 團隊對 DSV4 的投入是真的舍得給資源——從 0.20.0 的"基礎支持"到 0.20.1 的"性能 + 穩定性雙升"，前后才隔了不到兩周

這也側面印證了一件事：DeepSeek V4 這條路線，已經成為開源推理框架第一優先級要支持好的目標模型，沒有之一

至于 V4 部署本身那些"硬件門檻高、配置玄學多"的根本性難題，0.20.1 解決了一部分，但遠遠沒全解決。等我假期后摸到 H20 集群，再做一輪升級前后的對比實測，到時候再來跟老板們匯報

制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！