vLLM 最新版來(lái)了，修復(fù) DeepSeek-V4 跑不穩(wěn)、跑不快的問(wèn)題

節(jié)前我連著寫(xiě)了三篇 vLLM × DeepSeek V4 的文章：

勞動(dòng)節(jié)假期還沒(méi)過(guò)完，vLLM 團(tuán)隊(duì)就給我加了道菜——0.20.1 緊急 patch 出爐了，主線就一句話：把 DSV4 跑不穩(wěn)、跑不快的問(wèn)題集中處理一遍

簡(jiǎn)介

先把版本性質(zhì)說(shuō)清楚：v0.20.1 是 v0.20.0 的補(bǔ)丁版本，不是新功能堆料，而是圍繞 DeepSeek V4 做穩(wěn)定化 + 性能調(diào)優(yōu)，外加一批通用 bug 修復(fù)

如果你正在本地跑 DSV4 / DSV4-Flash，強(qiáng)烈建議升級(jí)；如果你還在用 0.19.x 老老實(shí)實(shí)跑 V3，那這版意義不大，等 0.21 再說(shuō)

DeepSeek V4 這一塊改了啥

這是這個(gè) patch 的主線，我認(rèn)真研究了 release notes ：

1. 模型支持收口

• 把 DSV4 的 base model 正式接進(jìn)來(lái)（PR ）——之前 V4 是帶"實(shí)驗(yàn)"標(biāo)簽的，這一版算是把基礎(chǔ)打牢了

• Pure TP 模式下給 megamoe flag 上了保護(hù)（），避免錯(cuò)誤配置直接把進(jìn)程干崩

2. 性能優(yōu)化（這部分含金量很高）

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

• 配套加了一個(gè)調(diào)優(yōu)旋鈕 VLLM_MULTI_STREAM_GEMM_TOKEN_THRESHOLD （、），還順手把默認(rèn)值調(diào)到了一個(gè)比較合理的點(diǎn)上——這就是寫(xiě)過(guò)《為何如此困難》那篇里抱怨"參數(shù)全靠玄學(xué)"的直接回應(yīng)

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

• PTX cvt 指令加速 FP32→FP4 轉(zhuǎn)換 （）：直接下到指令級(jí)別壓榨硬件，F(xiàn)P4 推理路徑吞吐能再上一檔

• head_compute_mix_kernel tile kernel 集成（）：head 計(jì)算路徑專門做了 kernel 優(yōu)化

3. 一批要命的 Bug 修復(fù)

這部分尤其值得貼出來(lái)，因?yàn)椴簧俣际巧鐓^(qū)里反復(fù)哀嚎過(guò)的：

• TopK=1024 時(shí)持久化 topk 協(xié)作死鎖 （）——多并發(fā)跑久了進(jìn)程突然卡死，元兇就是這個(gè)

• RadixRowState 的 inter-CTA 初始化競(jìng)爭(zhēng) （）

• 臨時(shí)把 persistent topk 關(guān)掉作為 workaround（）——穩(wěn)定性優(yōu)先于性能的取舍

• AOT 編譯緩存導(dǎo)致 import error （）——升級(jí)后報(bào)"模塊導(dǎo)入失敗"，多半就是它

• torch inductor 報(bào)錯(cuò) （）

• RoPE cache 重復(fù)初始化 （）——表現(xiàn)是顯存被偷偷吃掉一塊

• DSV3.2 / V4 非流式 tool calls 類型轉(zhuǎn)換缺失 （）——做 Agent 調(diào)用的老板必須升

隨機(jī)卡死、顯存莫名爆漲、tool call 偶發(fā)不返回、OOM 之后再起進(jìn)程報(bào) import error——這次基本都被一鍋端了

通用 Bug 修復(fù)

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

• max_num_batched_token 沒(méi)被 CUDA graph 正確捕獲（）

• num_gpu_blocks_override 在 max_model_len 校驗(yàn)里沒(méi)被算進(jìn)去（）——手動(dòng)調(diào)顯存塊數(shù)的老板請(qǐng)?zhí)ь^

• 自動(dòng)禁用 cumem 內(nèi)存池附近的 expandable_segments （）

• BailingMoE linear layer（）和 V2.5 的 MLA RoPE 旋轉(zhuǎn)修復(fù)（）

• reasoning parser 的 kwargs 沒(méi)傳給 structured output（）——對(duì)結(jié)構(gòu)化輸出影響很大

• ROCm：Quark W4A8 GPT-OSS 的 input_ids 和 expert_map 參數(shù)修復(fù)（）

ROCm 用戶也別走，這版對(duì)你們也有禮物

安裝

升級(jí)方式?jīng)]變化，CUDA 13.0 + PyTorch 2.11 是 0.20.x 的標(biāo)配，0.20.1 也跟著這個(gè)組合：

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


 # 或者老老實(shí)實(shí) pip
pip install --upgrade vllm

如果你還在 CUDA 12.9 的環(huán)境上，官方推薦的寫(xiě)法是：

uv pip install vllm --torch-backend=cu129

Docker 鏡像：

docker pull vllm/vllm-openai:v0.20.1

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

我的建議

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

具體到幾類老板：

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

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

• 做 Agent / Function Calling 的 ：tool calls 類型轉(zhuǎn)換那個(gè) fix（）你必須升，不然偶發(fā)返回缺字段會(huì)讓上層應(yīng)用一頭霧水

• 還在 V3 / V3.2 陣營(yíng) ：升級(jí)風(fēng)險(xiǎn)低收益也不大，可以等 0.21 主線版本

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

這也側(cè)面印證了一件事：DeepSeek V4 這條路線，已經(jīng)成為開(kāi)源推理框架第一優(yōu)先級(jí)要支持好的目標(biāo)模型，沒(méi)有之一

至于 V4 部署本身那些"硬件門檻高、配置玄學(xué)多"的根本性難題，0.20.1 解決了一部分，但遠(yuǎn)遠(yuǎn)沒(méi)全解決。等我假期后摸到 H20 集群，再做一輪升級(jí)前后的對(duì)比實(shí)測(cè)，到時(shí)候再來(lái)跟老板們匯報(bào)

制作不易，如果這篇文章覺(jué)得對(duì)你有用，可否點(diǎn)個(gè)關(guān)注。給我個(gè)三連擊：點(diǎn)贊、轉(zhuǎn)發(fā)和在看。若可以再給我加個(gè)，謝謝你看我的文章，我們下篇再見(jiàn)！