DeepSeek V4.1 Flash 工具呼叫功能登陸 vLLM：帶空格的標籤搞壞了什麼

DeepSeek V4.1 Flash自 2026 年 9 月 10 日起正式全面推出，而在它問世後的頭十二天裡，這款模型存在一個沒有人寫過的落差：它能推理、能看圖像、能容納一百萬個詞元的上下文，卻無法透過最廣泛使用的開放推論服務堆疊可靠地呼叫工具。如今這個落差已在 vLLM 中補上——不是靠設定旗標，而是靠解析器重寫。有兩份拉取請求承載了這項工作，而它們之所以必要的理由才是真正有趣的部分。

簡短版：DeepSeek V4.1 Flash 是以一種標籤格式發出工具呼叫，而現有的 DeepSeek V4 偵測器無法辨識這種格式，因此在標準的 vLLM 部署上，工具呼叫的標記會以一般文字送達，而不是結構化輸出。不會有任何錯誤。模型看起來就像是單純拒絕呼叫函式。如果你一直在用自架的 DeepSeek V4.1 Flash 測試 agent 迴圈，並得出這個模型不擅長工具使用的結論，這很可能就是你當時看到的狀況。

服務堆疊中實際上有什麼改變

vLLM 對 DeepSeek 模型的工具呼叫解析，已有一段時間存在於兩個地方：Python 前端與較新的 Rust 前端，而文法層級的工作則委由 XGrammar 專案處理。要讓 V4.1 Flash 支援涵蓋進來，意味著將 XGrammar 內部的 C++ deepseek_xml 轉換移植到 Rust 建構器中，然後把模型本身的編碼接入 vLLM 的分詞器目錄。

• Rust 前端的工作是 PR #56235，它將 XGrammar C++ deepseek_xml 轉換移植到 Rust builder 中。它為 V4.1 特別附上了 18 個新測試，而現有的完整測試套件——vllm-parser 中的 472 個測試，以及 vllm-chat 中的 326 個測試——依然全數通過。

• Python 前端的工作是 PR #56408，目前仍是草稿。它取決於上游 XGrammar 的變更（mlc-ai/xgrammar#885）先行落地，並在套用該相依項目後回報有 110 項測試通過。

• 新的編碼模組是 vllm/tokenizers/deepseek_v41_encoding.py——它是一個獨立檔案，而非 V4 編碼內部的分支，這說明其標籤語法是真正有所不同，而不只是單純擴充。

• 呼叫方式是明確指定的：--tool-parser deepseek_v41。並沒有會默默自動做對事情的自動偵測備援機制。

那些帶空格的標籤才是整件事的關鍵。

新解析器之所以存在，而不是把正規表達式放寬，原因在於空白。DeepSeek V4.1 Flash 撰寫其 DSML 工具標籤時，會在記號之間加入空格。V4 偵測器的模式預期的是無空格形式，因此比對失敗；而在工具呼叫解析器中，比對失敗在設計上就是靜默的——文字會直接作為內容傳遞，而不是拋出例外。

那個失敗模式值得深究，因為它是最昂貴的一種。會拋出例外的解析器，一個下午就能修好。一個傳回格式良好字串、其中卻含有呼叫端從未要求之標記的解析器，看起來就像模型品質問題，而團隊對它的反應，也會像面對模型品質問題那樣：他們嘗試不同的提示、加入範例、更換模型。十二天已經長到足以讓這類事情在私下發生很多次了。

這也意味著，這項修正並不是一個調校旋鈕。你無法靠提示詞擺脫一個與你模型輸出格式不符的偵測器，也無法在用戶端透過後處理來修正它，因為當文字抵達你的用戶端時，結構早已消失。這必須在服務堆疊中完成，而它現在正好就在那裡。

為什麼這件事對 V4.1 Flash 來說，比對 V4 更加重要？

工具呼叫對這個特定模型而言，並不是可有可無的附加功能。DeepSeek V4.1 Flash 是一個 5,520 億參數的混合專家模型，輸入時啟用 80 億參數，輸出時啟用 160 億參數，具備 100 萬 token 的上下文視窗，以及 38.4 萬 token 的最大輸出。從啟用參數的分配方式就能看出端倪：這個模型是為了接收大量輸入——一個程式碼儲存庫、一組文件、一段冗長的工具追蹤記錄——並輸出冗長且結構化的回應而打造。那是代理的形態，而非聊天機器人的形態。

發布規格的其餘部分也指向同一個方向。以 MIT 授權的權重、每個 token 890 位元組的 KV 快取、45 兆個預訓練 token、原生視覺。KV 快取這個數字才是 1M 上下文下營運上真正關鍵的一點：它讓冗長的代理對話紀錄得以用可負擔的成本常駐，也是為什麼這個模型可以在一個由更昂貴模型監督的迴圈中，合理地扮演低成本工作者的角色。

這使得十二天的工具呼叫空窗期成為實質成本，而非可有可無的註腳。一個模型的經濟價值若建立在成為代理流程中大量執行工作的執行者，那麼當流程無法從它取得結構化呼叫時，這個模型就幾乎毫無價值。

還有什麼仍然開放？

截至 2026 年 9 月 22 日，如實的現況是：

• Rust 前端路徑（PR #56235）是在新的 V4.1 案例與既有測試套件上都具備完整測試涵蓋的那一個。如果你使用的 vLLM 建置版本包含它，解析器今天就可以供你使用。

• Python 前端路徑（PR #56408）是草稿，且有外部相依性。若你目前鎖定的是早於 XGrammar 變更的建置版本，Python 前端還不會提供 V4.1 工具解析。

• 由於呼叫是明確的，一個升級了 vLLM 但未變更其啟動旗標的部署，仍會維持舊有行為。解析器存在，與解析器實際被使用，是兩件不同的事。

• 目前尚無公開證據顯示，已有獨立的工具呼叫基準測試在採用新解析器的 V4.1 Flash 上執行過。我們知道的是，底層機制運作正常，測試也通過了。模型的工具呼叫品質是否優良，則是另一個問題，這次合併並未給出答案。

最後那一點才是該牢牢記住的。修正解析器會讓模型從「無法評估」變成「可以評估」。這是做出裁決的前提，而不是裁決本身。

如果您不想自行執行服務堆疊

有更短的路徑。DeepSeek V4.1 Flash 可透過 OrcaRouter 為其提供的端點使用，這意味著工具呼叫行為會以一般 API 呼叫的形式出現，而不是變成建置問題——無需匹配 XGrammar 版本、無需挑選前端、無需記住啟動旗標。這在這裡特別重要的原因在於，該修正已在兩個成熟度不同的地方落地，而託管端點讓這項決策化為烏有。

同一組金鑰也會觸及其餘的模型，也就是你會拿來比較的那些模型——當問題不是「這個解析器正確嗎」，而是「這個模型夠不夠格用在我的迴圈裡」時，這正是有用的特性。你可以把 DeepSeek V4.1 Flash 放在路由規則後面，當作低成本的執行者，並在呼叫失敗時故障轉移到更強的模型，不需要第二份合約或第二個 SDK。嘗試一個工具呼叫支援才剛滿兩週的模型，正是自動故障轉移存在的意義。

接下來要看什麼

有三件事能讓這件事從技術細節變成明確結論：

• PR #56408 結束草稿狀態，這將讓 Python 前端路徑真正落實，並終結雙層級支援的現況。

• 在固定服務堆疊上針對 V4.1 Flash 執行的一項獨立代理或工具呼叫評估。該模型已推出十二天，而解析器可供使用的時間還不到那麼久，所以你现在看到任何引用它的工具呼叫分數都值得追問——設定和模型本身一樣重要。

• 其他服務堆疊是否跟進。vLLM 是唯一有公開 PR 的；空格標籤問題並非 vLLM 獨有，因此任何採用 V4 偵測器、卻未從 V4.1 輸出重新推導的堆疊，都潛藏著同樣的靜默失敗。

在那些事情的第一項落地之前，準確的總結雖然狹隘，卻值得直白說出：DeepSeek V4.1 Flash 是正式推出（GA）的模型，具備 MIT 授權權重、1M 上下文與 384K 輸出上限，而其工具呼叫現在可在 vLLM 的 Rust 路徑上運作，並搭配明確的 parser 旗標。這是實質的一步，但還不是一項結果。