VLMEvalKit：把 220 多個視覺語言模型的評測收斂成一條指令
Open-source evaluation toolkit of large multi-modality models (LMMs), support 220+ LMMs, 80+ benchmarks
秒懂
- 它是什麼？
- 這個由 OpenCompass 維護的 Python 工具包，用生成式評測統一了多模態模型的跑分流程。它真正解決的是資料準備與推論後處理的重複勞動，代價是你得接受它對模型輸出格式的預設假設。
- 適合誰用？
- 如果你要在一批開源或 API 視覺語言模型上跑同一組 benchmark，並且需要可重現的預測檔案，VLMEvalKit 值得先進沙箱試一輪；如果你的評測對象是閉源模型的內部版本、或 benchmark 需要自訂評分邏輯而非選擇題抽取，這套工具的預設路徑會綁手綁腳。動手前先確認三件事：你的模型是否已在 vlmeval/config.py 中登錄，你的輸出長度是否超過 32k 而必須開 PRED_FORMAT=tsv，以及你的模型是否帶 thinking 模式而必須開 SPLIT_THINK=True。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要取代的是評測流程裡最無聊的那一段
多模態模型的評測長期有一個尷尬處境：模型本身很容易換，但每個 benchmark 都自帶一份下載腳本、一套圖像解壓邏輯、一種答案格式。你要比較 LLaVA 和 Qwen2.5-VL，往往得在兩套互不相容的程式碼裡各跑一次，再手動對齊題號。VLMEvalKit 的定位就是把這一段收斂掉。README 的說明是它提供 one-command evaluation，讓使用者不必為了多個 repository 各自做一次資料準備。
目標讀者是誰，其實相當明確：要對多個視覺語言模型做橫向比較的研究者、要在內部模型與公開模型之間建立基準線的工程團隊，以及需要產出可下載預測記錄的人。它不適合只想跑單一模型單一資料集的臨時需求，那種情況下直接寫三十行推論腳本更快。工具包的價值來自規模，模型數量少於三、四個時，抽象層帶來的學習成本會超過它省下的時間。
生成式評測：所有模型都先寫答案，再談對錯
VLMEvalKit 對所有模型採用 generation-based evaluation。這個選擇決定了整條資料流：模型不是被要求輸出某個類別機率或 logit，而是被要求生成一段文字答案，之後才由評測端判斷這段文字對不對。判斷方式有兩層，一層是 exact matching，另一層是 LLM-based answer extraction。
第二層的存在理由很實際。視覺語言模型回答選擇題時，經常輸出「答案是 B，因為圖中……」這類帶解釋的句子，字串比對會直接判錯。所以工具包會嘗試把選項從生成文字中抽取出來。README 提到 2025-08-04 的 PR 1175 改寫了 can_infer_option 與 can_infer_text，讓更多情況被導向 LLM choice extractor，並且在選擇題 benchmark 上帶來輕微的效能提升。這裡要注意的是，這個改動同時意味著評測結果會受抽取器行為影響：同一份模型輸出，在不同版本的抽取邏輯下可能得到不同分數。做跨時間點比較時，版本必須一起記錄。
架構上，README 顯示模型設定集中放在 vlmeval/config.py，推論後端可以掛上 LMDeploy 或 VLLM。也就是說工具包本身不負責高效能推論，它把這件事外包給專門的推論引擎，自己專注在資料集載入、prompt 組裝與答案抽取。這個分工是合理的，但也代表推論引擎的版本會成為你環境裡另一個需要鎖定的變數。
跑起來：環境變數與 config.py 是兩個必經的開關
README 指向 docs/en/Quickstart.md 與 docs/zh-CN/Quickstart.md 作為入門文件，本文不重述其中的安裝步驟，只整理幾個從 release note 與 README 可直接確認的操作面。
模型設定寫在 vlmeval/config.py。要啟用多節點分散式推論，README 的說明是在自訂模型設定中加入 use_lmdeploy 或 use_vllm 旗標，前者支援 InternVL 系列、QwenVL 系列與 LLaMa4，後者支援 QwenVL 系列與 LLaMa4。這個支援範圍是硬邊界，不是所有模型都能走這條加速路徑。
環境變數方面，README 明確列出兩個。PRED_FORMAT=tsv 用於把預測結果改存成 TSV 格式，理由是 .xlsx 的單一儲存格上限為 32,767 個字元，長回覆會被截斷，官方建議輸出超過 16k 或 32k token 的模型啟用。SPLIT_THINK=True 用於處理帶 thinking 模式的模型，預設會解析 <think>...</think> 標籤並把內容存到輸出的 thinking 鍵，README 也說明可以自行為模型建立 split_think 函式，並以 InternVL 的實作作為範例。
還有一個下載來源的開關：VLMEVALKIT_USE_MODELSCOPE，設定後可從 modelscope 下載支援的影片 benchmark。這對中國大陸網路的團隊是實質差別，對其他地區則未必需要。
thinking 模式與長輸出：兩個會靜默出錯的地方
這個工具包最需要警覺的不是功能缺失，而是錯誤不會以中斷的形式出現。
第一個是 thinking 模式。README 在 2025-09-12 的更新裡用了相當強烈的措辭，建議帶 thinking 模式的模型務必使用新的 split_thinking 功能以確保評測準確性。反過來讀這句話：在啟用之前，這類模型的評測準確性是不被保證的。原因是顯而易見的，如果模型先輸出大段推理再給答案，而抽取邏輯沒有把推理段與答案段分開，選擇題抽取就可能抓到推理過程中提到的錯誤選項。這是靜默失敗，分數會偏低但不會報錯。
第二個是長輸出截斷。xlsx 的 32,767 字元上限是 Excel 格式本身的限制，不是這個專案的選擇。工具包的應對是提供 TSV 輸出。問題在於，如果你沿用預設格式而模型又話多，截斷發生在寫檔階段，你看到的是一份看起來完整、實際上尾巴被切掉的預測檔。要做長輸出的分析，例如統計推理長度或檢查被截斷的答案，就必須先切到 TSV。
這兩點合起來說明一件事：VLMEvalKit 的預設值是為一般長度回覆的模型設計的，遇到新一代的推理型視覺模型，預設值不再是安全值。
lmms-eval 的取捨：生成式統一對上任務原生評分
同類工具裡最常被拿來對照的是 lmms-eval。兩者的分歧不在支援數量，而在評測哲學。
VLMEvalKit 把所有 benchmark 壓進同一條生成式管線：模型生成文字，工具包抽取答案，再與標準答案比對。好處是新增一個模型只需要寫一份推論介面，不需要為每個 benchmark 分別適配輸出格式。代價是它假設所有任務都能被化約成「生成一段可抽取的文字」。遇到需要計算 IoU 的偵測任務、需要多輪互動的 agent 評測、或評分標準本身依賴模型輸出結構的 benchmark，這個抽象就會漏水。
lmms-eval 走的是另一條路，它更接近逐任務實作，讓每個 benchmark 保有自己的評分邏輯。這在處理非選擇題、需要精確數值比對或自訂指標的場景下更直接，但新增模型的成本較高，因為你要面對的是多套評分介面而不是一套。
選擇的判準因此很清楚：如果你評測的 benchmark 以選擇題與短答為主，且模型清單會持續變動，VLMEvalKit 的統一管線省下的工更多。如果你的評測集包含大量需要自訂指標的任務，逐任務實作反而更省事，因為你遲早要繞過統一抽取層。
維護成本與授權：Apache-2.0 之下你要自己扛的事
授權是 Apache-2.0，這是寬鬆授權，允許修改與再散布，包含商業用途。本文不提供法律意見，實際條款請以 repository 中的 LICENSE 檔案為準。需要留意的實務點在於，Apache-2.0 涵蓋的是這個工具包的程式碼，不涵蓋你透過它下載的 benchmark 資料集與模型權重，那些各自有獨立的授權條款，這是使用評測工具時常被忽略的一層。
維護成本主要來自版本敏感度。從 release 記錄看，v0.2rc1 在 2024-06-29，v0.2 在 2025-03-24，v0.3rc1 在 2025-06-21，節奏不算密集，但 README 的 Recent Codebase Changes 顯示抽取邏輯與輸出處理在持續調整。can_infer_option 與 can_infer_text 的改動會直接影響歷史分數的可比性，這意味著你如果要把分數放進長期追蹤的表格，必須把 VLMEvalKit 的版本與相關環境變數一起記錄下來，否則半年後沒人說得清某個數字是在什麼條件下產生的。
另一個成本是依賴鏈。當你掛上 use_vllm 或 use_lmdeploy，環境裡就多了兩個獨立演進的推論框架，它們與模型權重之間的相容性問題會變成你的問題，而不是 VLMEvalKit 的問題。
誰該採用，以及開跑前必須先驗的三件事
判斷標準可以回到一個問題：你需要的是可重現的橫向比較，還是一次性的單點數字。前者是這個工具包的強項，後者用它是殺雞用牛刀。
適合採用的情況包括：手上有一份十個以上的視覺語言模型清單要跑同一組 benchmark；需要把預測結果存檔供後續分析或公開；團隊裡有人願意維護 config.py 中的模型登錄與環境變數。不適合的情況包括：評測任務需要自訂評分指標而非選擇題抽取；只跑一兩個模型；或者你要評測的是無法透過公開 API 或本地權重存取的模型。
開跑前先驗三件事。第一，確認目標模型是否已在 vlmeval/config.py 中登錄，沒有的話你得自己寫推論介面，這是整個流程中最花時間的一步。第二，確認模型的輸出長度，若會超過 16k 就先把 PRED_FORMAT 設為 tsv，不要等到發現預測檔被截斷才回頭重跑。第三，確認模型是否帶 thinking 模式，若是就設 SPLIT_THINK=True，並考慮依照 InternVL 的範例自訂 split_think。這三項檢查做完，你得到的數字才有資格放進比較表。
編輯結論
如果你要在一批開源或 API 視覺語言模型上跑同一組 benchmark，並且需要可重現的預測檔案，VLMEvalKit 值得先進沙箱試一輪；如果你的評測對象是閉源模型的內部版本、或 benchmark 需要自訂評分邏輯而非選擇題抽取，這套工具的預設路徑會綁手綁腳。動手前先確認三件事：你的模型是否已在 vlmeval/config.py 中登錄，你的輸出長度是否超過 32k 而必須開 PRED_FORMAT=tsv，以及你的模型是否帶 thinking 模式而必須開 SPLIT_THINK=True。這三項沒確認就開跑，得到的數字很可能要重跑。
社群筆記