多模態資料處理¶

為了在 vLLM 中實現各種最佳化，例如分塊預填充和字首快取，我們使用BaseMultiModalProcessor來根據 HF 處理器的輸出，提供佔位符特徵 token（例如<image>）與多模態輸入（例如原始輸入影像）之間的對應關係。

以下是BaseMultiModalProcessor的主要功能

提示更新檢測¶

HF 處理器的一個主要職責是用佔位符 token 更新提示。例如

在字串開頭插入特徵佔位符 token（例如<image><image>...<image>，數量等於特徵大小）。
將現有輸入佔位符 token（例如用於單張影像的<image>）替換為特徵佔位符 token（例如<image><image>...<image>，數量等於特徵大小）。

關於哪些 token 已被更新的資訊是查詢佔位符特徵 token 與多模態輸入之間對應關係的關鍵。

在 vLLM 中，此資訊透過PromptUpdate在_get_prompt_updates中指定。我們可以透過檢查已更新 token 的存在性來自動檢測 HF 是否已更新提示。

分詞後的提示輸入¶

為了在單獨的程序中實現分詞，我們支援在多模態資料之外傳遞輸入 token ID。

問題¶

考慮 HF 處理器遵循以下主要步驟

對文字進行分詞
處理多模態輸入
執行提示更新

並且我們要求

對於文字 + 多模態輸入，應用所有步驟 1-3。
對於分詞 + 多模態輸入，僅應用步驟 2-3。

我們如何在不重寫 HF 處理器的情況下實現這一點？我們可以嘗試在不同的輸入上多次呼叫 HF 處理器

對於文字 + 多模態輸入，直接呼叫 HF 處理器即可。
對於分詞 + 多模態輸入，僅在多模態輸入上呼叫處理器。

雖然 HF 處理器原生支援文字 + 多模態輸入，但對分詞 + 多模態輸入則不然：如果輸入佔位符 token 的數量與多模態輸入的數量不對應，則會丟擲錯誤。

此外，由於分詞後的文字未透過 HF 處理器處理，我們必須自行應用步驟 3，以保持輸出 token 和多模態資料彼此一致。

佔位文字¶

我們透過要求每個模型透過get_dummy_text定義如何根據多模態輸入的數量生成佔位文字來解決第一個問題。這使我們能夠生成與多模態輸入對應的佔位文字，並將它們一起輸入以獲得處理後的多模態資料。

自動提示更新¶

我們透過在_apply_prompt_updates中實現與模型無關的程式碼來解決第二個問題，該程式碼根據_get_prompt_updates輸出的規範，自動使用特徵佔位符 token 更新提示。

總結¶

藉助佔位文字和自動提示更新，我們的多模態處理器最終可以接受帶有多模態資料的文字和 token 提示。詳細邏輯如_apply_hf_processor_main所示。

處理器輸出快取¶

一些 HF 處理器，例如 Qwen2-VL 的處理器，速度非常慢。為了緩解這個問題，我們快取了 HF 處理器對多模態輸出的處理結果，以避免再次處理相同的多模態輸入（例如影像）。

當傳入新資料時，我們首先檢查哪些項在快取中，哪些項缺失。缺失的項會以單個批次的形式傳遞給 HF 處理器並快取起來，然後與快取中已有的項合併。

由於我們只處理缺失的多模態資料項，輸入佔位符 token 的數量不再與多模態輸入的數量對應，因此它們不能與文字提示一起傳遞給 HF 處理器。因此，我們分別處理文字和多模態輸入，使用佔位文字來避免 HF 錯誤。由於這跳過了 HF 的提示更新程式碼，我們隨後會應用自動提示更新，以保持輸出 token 和多模態資料彼此一致。