大模型本地部署最強引擎，vLLM 大版本更新，v0.24.0

vLLM 是咱們公眾號的老熟人了，老章隔三差五就要來拆一遍它的版本更新

昨天0.24來了，我把整份更新日志翻了個底朝天，挑幾個我覺得值得說道的點跟大家聊聊

簡介

先給不太熟的朋友補一句：vLLM 是一個專門做大模型推理和部署的引擎，核心賣點就是快和省顯存

它最出名的技術是 PagedAttention，把操作系統里虛擬內存分頁那套思路搬到了 KV Cache 上，同樣的顯卡能塞下更多并發請求，吞吐量比 HuggingFace Transformers 原生方案高出一大截

現在國內外幾乎所有搞大模型私有化部署的團隊，繞不開它

先上一張圖，把這版最值得關注的一次看全：
省流版：

• MiniMax-M3 成為新主角 ：新增 MiniMax-M3 支持，同時跟進 BF16/FP8 indexer、MXFP4、FP8 sparse GQA 和 ROCm 調優

• DeepSeek-V4 繼續成熟 ：2-4% TTFT 優化、4% 端到端吞吐優化、低延遲 topK、連續 KV 分配、SM120、XPU、ROCm 支持都在推進

• Model Runner V2 繼續鋪開 ：量化模型默認支持、GraniteMoE 默認啟用，Qwen 和 DeepSeek-V2 MoE 遷移，DFlash 投機解碼也跟上

• Streaming Parser Engine 上線 ：把工具調用和 reasoning 解析統一起來，Qwen3、MiniMax-M2、GLM、Nemotron V3 都有對應 parser

• Diffusion LLM 進入 vLLM 主線 ：DiffusionGemma 加入，CPU 路徑和結構化輸出保護也有了

• Rust frontend 更像生產服務了 ：API key、CORS、tokenize、pause、resume、abort、thinking token budget 都在補齊

• 多卡設備選擇邏輯有變化 ：vLLM 不再內部設置 CUDA_VISIBLE_DEVICES ，新加 device_ids 參數

這次最搶眼的是把 MiniMax-M3 給接上了

而且是一整套組合拳：BF16/FP8 indexer 走 MSA、MXFP4 量化支持、FP8 稀疏 GQA，連 AMD 顯卡上的適配都安排得明明白白（gfx950 上的 mxfp8 MoE 調優、MI300X 上 bf16 權重跑 fp8 逐通道量化）

我一直覺得，一個模型能不能第一時間被 vLLM 支持，某種程度上是它江湖地位的體現，國產模型能吃上這種待遇，挺好

順帶還修了 MiniMax-M2 之前的一個性能回退問題，用 M2 的朋友記得升一下

二、DeepSeek-V4 持續被喂飽

DeepSeek-V4 上個版本剛首發，這次直接來了一波大規模優化，我數了數至少六七個 PR 是專門伺候它的：

• FlashInfer 稀疏索引緩存，TTFT（首 token 延遲）改善 2%~4%

• prefill 分塊規劃優化，端到端吞吐提升 4%

• 給低延遲場景加了 cluster-cooperative topK kernel

• KV cache 改成按塊連續分配

• 修了個 OOM（顯存溢出）的坑

更關鍵的是覆蓋面：現在 DeepSeek-V4 在 SM120 上能跑了（和 GLM-5.1 一起），Intel XPU、AMD ROCm 的注意力和 MoE 路徑也都補齊了

• FlashInfer sparse index cache，TTFT 提升 2-4%

• prefill chunk planning 優化，端到端吞吐提升 4%

• 低延遲場景的 cluster-cooperative topK kernel

• DeepSeek-V4 的 KV cache 做連續 per-block 分配

• 支持 block-FP8 shared expert 的 TEP=16

• SM100 上的 native DSA indexer decode

• DeepSeek-V4 和 GLM-5.1 已啟用 SM120

• XPU 和 ROCm 路徑繼續補齊

這些數字看起來都不夸張，2%、4% 這種優化，在外行眼里可能沒啥感覺

但做推理服務的人都知道，這種改動才是真金白銀

當模型已經大到 1T 級別，單點 4% 吞吐提升意味著同樣機器多扛一部分流量，也意味著在長上下文、多請求、MoE 調度下少一點崩潰邊緣

大模型推理引擎拼到后面，很多時候拼的就是這種細碎到有點枯燥的工程活

DiffusionGemma 進主線了

DiffusionGemma 這次也正式進 v0.24.0

前面我單獨寫過 DiffusionGemma，它最大的特點是生成方式和傳統自回歸模型不同，低并發場景下速度非常夸張

這次 release notes 里提到：

• 新增 DiffusionGemma 支持

• 包含 CPU 路徑

• 對 diffusion decoder 的結構化輸出加了保護

這說明 vLLM 對新型生成范式的支持在繼續往主線合并

這件事很有意思

過去推理框架基本圍繞自回歸模型設計，后面如果擴散式語言模型、多 token 并行生成、投機解碼、MTP 都繼續發展，推理引擎的抽象會越來越復雜

vLLM 這次把 DiffusionGemma 往主線里收，是一個很清晰的信號

Model Runner V2 越來越能打

這次它新增了量化模型默認支持、GraniteMoE 默認啟用，還繼續遷移 Qwen 和 DeepSeek-V2 MoE 模型，同時加了 DFlash 投機解碼和更準確的 FP32 Gumbel sampling

我的理解是，vLLM 現在已經進入“核心路徑換代”的階段

過去大家更關心某個模型能不能跑起來，現在更要關心它跑在哪條 engine path 上

因為同一個模型，走老路徑和走新路徑，吞吐、顯存、調度、兼容性都會不一樣

這次 MRv2 繼續擴張，說明 vLLM 的重心還在往新架構遷移

對用戶來說，好處是以后大量新優化會優先沉淀到 MRv2 里

壞處也很現實：升級版本時更要跑自己的回歸測試，尤其是量化、LoRA、投機解碼、多模態這種組合場景

全新的 Streaming Parser Engine 是給 Agent 時代補課

這次新增的 Streaming Parser Engine，我覺得很值得單獨拎出來

它要解決的是一個越來越常見的問題：模型輸出不只是普通文本，還有工具調用、reasoning、結構化片段、流式增量

不同模型的格式又不一樣，Qwen3 一套，MiniMax-M2 一套，GLM 一套，Nemotron 又一套

如果每個模型都寫一份零散 parser，后面會越來越難維護

v0.24.0 做的事情，是把這些解析邏輯往統一引擎里收

這對 Agent 開發很重要

因為 Agent 真正上線后，很多失敗都卡在細節里：流式輸出里的工具調用有沒有被正確識別，reasoning 有沒有被誤吞，JSON 有沒有被強行修壞

這些東西很臟，很工程，但很真實

一個容易踩坑的破壞性改動

vLLM 不再在內部自己設置 CUDA_VISIBLE_DEVICES 了，改成提供一個 device_ids 參數讓你顯式指定

如果你的部署腳本以前依賴 vLLM 在內部處理設備可見性，這次要認真檢查多卡啟動方式

尤其是這些場景：

• 一臺機器上多個服務共用 GPU

• Kubernetes 里靠環境變量控制 GPU 分配

• Ray 或多進程啟動時每個 worker 看到的設備不同

• ROCm 環境里還在沿用 CUDA 風格的設備變量

如果你只是想新建環境試一下，官方 quickstart 推薦用 uv 建 Python 3.12 環境，再安裝 vLLM：

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

如果你要明確鎖到這次的版本，可以這樣做：

uv pip install "vllm==0.24.0" --torch-backend=auto

生產環境升級，我建議別直接原地替換

更穩的方式是新建環境、固定版本、用自己的真實請求集跑一遍，再看多模態、工具調用、reasoning、量化模型、LoRA、長上下文這些場景有沒有變化

總結

vLLM v0.24.0 這一版，我給的評價是該升，但要看菜下飯

• 如果你要跑 MiniMax-M3、DeepSeek-V4、DiffusionGemma、Qwen 多模態，這版值得第一時間測試

• 如果你在用 Rust frontend 或 OpenAI 兼容服務做網關，這版的服務能力補齊很有價值

• 如果你的業務很依賴穩定輸出格式，重點測 Streaming Parser Engine 相關模型

• 如果你是多卡部署，先看 CUDA_VISIBLE_DEVICES 和 device_ids 的影響

• 如果你只是單機跑普通模型，沒必要著急，等一周看 issue 反饋也可以

一個開源項目能保持這種更新密度和質量，還愿意持續做減法保持整潔，這本身就很了不起