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

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

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

變更

類型

一句話

Transformers v5 正式升級

生態(tài)

從兼容升級到正式依賴

Gemma 4 流式工具調用 JSON 損壞

修復

流式輸出時部分分隔符導致無效 JSON

Gemma 4 流式 HTML 重復

修復

工具調用后 HTML 內容被重復輸出

Gemma 4 流式布爾/數字值損壞

修復

跨 chunk 的布爾和數字值被截斷

Gemma 4 推理解析 + 多輪工具調用

修復

推理解析器支持 adjust_request，修復多輪對話

Gemma 4 量化 MoE 支持

? 新功能

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

Gemma 4 Eagle3 推測解碼

? 新功能

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

Gemma 4 LoRA 適配器加載

修復

LoRA 加載路徑修正

Gemma 4 null 值轉字符串

修復

裸 null 被錯誤轉為 "null" 字符串

Gemma 4 PT 模型 token 重復

修復

預訓練模型缺失 BOS token 導致輸出重復

Kimi-K2.5 媒體占位符 token

修復

上游 config 和 tokenizer 的 ID 不一致

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

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

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

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

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

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

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

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

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

二、Gemma 4 工具調用：流式輸出的六連修

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

Bug 1：部分分隔符導致無效 JSON（#38992）

Gemma 4 的工具調用格式用特殊分隔符標記參數

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

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

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

Bug 2：工具調用后 HTML 內容重復（#38909）

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

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

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

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

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

Bug 4：裸 null 被轉成字符串 "null"（#39679）

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

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

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

Bug 5：多輪工具調用 + 推理模式修復（#39027）

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

• 新增了 Gemma 4 專用 chat template，正確編碼工具結果，處理多輪對話中交替出現的工具調用和推理內容

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

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

• 清理了 Anthropic Messages API 轉換中產生的空 user 消息

Gemma4ForCausalLM 加載 LoRA 適配器時路徑有誤，現已修正。想在 Gemma 4 上微調+部署的同學，這個必須有。

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

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

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

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

對應的 llm-compressor 也同步更新了，支持 Gemma 4 MoE 的專家級校準和量化流程。

四、Gemma 4 Eagle3 推測解碼支持

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

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

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

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

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

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

五、Gemma 4 PT 模型的 token 重復問題

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

問題根源：預訓練模型沒有 chat template，走的是原始 completions 接口。但 Gemma 4 的 ProcessingInfo 默認設置了 add_special_tokens=False——這個設置對 IT（指令微調）模型是對的，因為 chat template 渲染時已經加了 BOS token。可 PT 模型沒有 template，BOS token 就丟了。

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

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

六、Kimi-K2.5 媒體占位符修復

這個跟 Gemma 4 無關，但也值得提一嘴

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

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

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

升級建議

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

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