vLLM 0.19.1 正式版發(fā)布了，這次是一個補丁版本，11 個 cherry-pick，主題非常集中：把 Transformers v5 正式拉進來，然后把 Gemma 4 的一堆坑填上。

v0.19.0 對 Gemma 4 做到了"發(fā)布當(dāng)天可用"，但"可用"和"好用"之間差著不少 bug

這次 v0.19.1 就是來還債的，可以說這是一個 Gemma 4 專項修復(fù)版本

變更

類型

一句話

Transformers v5 正式升級

生態(tài)

從兼容升級到正式依賴

Gemma 4 流式工具調(diào)用 JSON 損壞

修復(fù)

流式輸出時部分分隔符導(dǎo)致無效 JSON

Gemma 4 流式 HTML 重復(fù)

修復(fù)

工具調(diào)用后 HTML 內(nèi)容被重復(fù)輸出

Gemma 4 流式布爾/數(shù)字值損壞

修復(fù)

跨 chunk 的布爾和數(shù)字值被截斷

Gemma 4 推理解析 + 多輪工具調(diào)用

修復(fù)

推理解析器支持 adjust_request，修復(fù)多輪對話

Gemma 4 量化 MoE 支持

? 新功能

FP8 和 NVFP4 量化的 MoE 模型可以跑了

Gemma 4 Eagle3 推測解碼

? 新功能

支持隱藏狀態(tài)提取，可訓(xùn)練專屬草稿模型

Gemma 4 LoRA 適配器加載

修復(fù)

LoRA 加載路徑修正

Gemma 4 null 值轉(zhuǎn)字符串

修復(fù)

裸 null 被錯誤轉(zhuǎn)為 "null" 字符串

Gemma 4 PT 模型 token 重復(fù)

修復(fù)

預(yù)訓(xùn)練模型缺失 BOS token 導(dǎo)致輸出重復(fù)

Kimi-K2.5 媒體占位符 token

修復(fù)

上游 config 和 tokenizer 的 ID 不一致

一、Transformers v5：從兼容到正式依賴

這個 PR（#30566）從 2025 年 12 月就開始做了，歷時四個多月終于合入。

HuggingFace Transformers v5 是一次大版本升級，改了不少底層 API。

vLLM 作為最依賴 Transformers 生態(tài)的推理引擎，這次升級涉及面很廣：

• 模型加載方式變了 ：配置注冊、tokenizer 獲取路徑都有調(diào)整

• 部分模型暫不兼容 ：比如 XVERSE 的 tokenizer 在 v5 下會報錯，暫時鎖定了 transformers<=4.57

• LoRA 加載路徑修復(fù) ：適配器目錄下沒有 config.json 時不再報錯

v0.19.0 已經(jīng)做了大面積適配，但還是"兼容"狀態(tài)

v0.19.1 把 Transformers v5.5.4 正式拉進依賴——如果你之前一直卡在 v4 不敢升，現(xiàn)在可以放心了

二、Gemma 4 工具調(diào)用：流式輸出的六連修

Gemma 4 的工具調(diào)用在 v0.19.0 發(fā)布時就能用，但流式場景下問題一大堆：

Bug 1：部分分隔符導(dǎo)致無效 JSON（#38992）

Gemma 4 的工具調(diào)用格式用特殊分隔符標(biāo)記參數(shù)

流式輸出時，一個分隔符可能被拆成兩個 chunk 發(fā)出去

前半截分隔符被當(dāng)成普通文本輸出，后半截又被正確識別，導(dǎo)致最終拼出來的 JSON 是壞的

修復(fù)方式：在流式輸出中檢測并剝離不完整的分隔符字符。

Bug 2：工具調(diào)用后 HTML 內(nèi)容重復(fù)（#38909）

Gemma 4 在執(zhí)行工具調(diào)用后繼續(xù)生成 HTML 內(nèi)容時，parser 內(nèi)部會從緩沖的 delta 重建 current_text，導(dǎo)致已經(jīng)發(fā)過的內(nèi)容被重復(fù)發(fā)送。

修復(fù)方式：停止從緩沖 delta 重建文本，直接使用原始流。

Bug 3：跨 chunk 的布爾/數(shù)字值被截斷（#39114）

工具調(diào)用參數(shù)如果是 true、false 或數(shù)字，這些值可能跨兩個 chunk 被拆開。比如 tru 在第一個 chunk，e 在第二個 chunk，parser 把 tru 當(dāng)成了字符串。

修復(fù)方式：在流式模式下扣留冒號和后續(xù)空白字符，等值完整后再發(fā)送。

Bug 4：裸 null 被轉(zhuǎn)成字符串 "null"（#39679）

_parse_gemma4_value 函數(shù)處理了 true/false 的裸值，但漏了 null。結(jié)果 param:null 被解析成 {"param": "null"} 而不是 {"param": null}。

這會導(dǎo)致 tool_choice="auto" 和 tool_choice=" " 產(chǎn)生不一致的輸出——后者走了 guided decoding 能正確處理 JSON schema，前者不行。

修復(fù)方式：在值解析中補上 null 的處理。

Bug 5：多輪工具調(diào)用 + 推理模式修復(fù)（#39027）

這是最大的一個修復(fù)，解決了多個問題：

• 新增了 Gemma 4 專用 chat template，正確編碼工具結(jié)果，處理多輪對話中交替出現(xiàn)的工具調(diào)用和推理內(nèi)容

• 給 ReasoningParser 基類添加了 adjust_request() 方法——Gemma 4 用它來強制設(shè)置 skip_special_tokens=False ，保留邊界 token

• 修復(fù)了流式推理中 thought\n 前綴的剝離邏輯

• 清理了 Anthropic Messages API 轉(zhuǎn)換中產(chǎn)生的空 user 消息

Gemma4ForCausalLM 加載 LoRA 適配器時路徑有誤，現(xiàn)已修正。想在 Gemma 4 上微調(diào)+部署的同學(xué)，這個必須有。

? 老章說：這六個 bug 放一起看，就能理解為什么 Gemma 4 的工具調(diào)用在 v0.19.0 發(fā)布時被那么多人吐槽。流式 + 工具調(diào)用 + 特殊分隔符，這三個東西疊在一起，邊界條件多到爆炸。如果你在用 Gemma 4 做 function calling，v0.19.1 是必升版本。

Gemma 4 的 26B MoE 模型（實際激活 4B）跑起來并不重，但完整加載仍然需要不少顯存。v0.19.1 正式支持了量化 MoE：

• FP8 動態(tài)量化 （W8A8）：RedHat 團隊已經(jīng)發(fā)布了現(xiàn)成的量化模型 gemma-4-26B-A4B-it-FP8-Dynamic

• NVFP4 量化 （W4A4）：更激進的壓縮，gemma-4-26B-A4B-it-NVFP4

對應(yīng)的 llm-compressor 也同步更新了，支持 Gemma 4 MoE 的專家級校準(zhǔn)和量化流程。

四、Gemma 4 Eagle3 推測解碼支持

上篇文章我詳細(xì)講了 vLLM v0.19.0 新增的隱藏狀態(tài)提取功能

v0.19.1 把這個能力擴展到了 Gemma 4：

• Gemma4Model 繼承了 EagleModelMixin ，支持輔助隱藏狀態(tài)的逐層收集

• Gemma4ForCausalLM 和 Gemma4ForConditionalGeneration （多模態(tài)包裝器）都實現(xiàn)了 SupportsEagle3 接口

• 在推測解碼配置驗證的模型白名單中加入了 gemma4

這意味著你現(xiàn)在可以用上篇介紹的那套流程，為 Gemma 4 訓(xùn)練專屬的 Eagle3 草稿模型，實現(xiàn)定制化的推測解碼加速。

五、Gemma 4 PT 模型的 token 重復(fù)問題

這個 bug 專門針對 Gemma 4 的預(yù)訓(xùn)練模型（不帶 -it 后綴的那些）

問題根源：預(yù)訓(xùn)練模型沒有 chat template，走的是原始 completions 接口。但 Gemma 4 的 ProcessingInfo 默認(rèn)設(shè)置了 add_special_tokens=False——這個設(shè)置對 IT（指令微調(diào)）模型是對的，因為 chat template 渲染時已經(jīng)加了 BOS token?？?PT 模型沒有 template，BOS token 就丟了。

缺少 BOS token 的后果：模型輸出開始瘋狂重復(fù)。

修復(fù)方式：動態(tài)檢測模型是否有 chat_template，沒有的話自動設(shè) add_special_tokens=True，確保 BOS token 被正確注入。

六、Kimi-K2.5 媒體占位符修復(fù)

這個跟 Gemma 4 無關(guān)，但也值得提一嘴

月之暗面的 Kimi-K2.5 模型的 config.json 里，media_placeholder_token_id 寫的是 163605，但 tokenizer 實際映射的 <|media_pad|> ID 是 163602

為什么不一致？因為 Kimi-K2.5 沒有附帶 tokenizer.json，Transformers 從 tiktoken 自動轉(zhuǎn)換時，特殊 token 的 ID 被悄悄壓縮了。

修復(fù)方式：在初始化時從 tokenizer 重新解析 token ID，如果和 config 不一致就自動修正。

升級建議

如果你不用 Gemma 4，v0.19.0 到 v0.19.1 的變化對你幾乎沒有影響，可以按需升級

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