EvalScope：把模型評測、壓力測試與 Agent 軌跡收進同一條命令列
A streamlined and customizable framework for efficient large model (LLM, VLM, AIGC) evaluation and performance benchmarking.
秒懂
- 它是什麼？
- ModelScope 社群維護的 Apache-2.0 評測框架，主打一條命令跑完 GSM8K 這類基準，並把推論效能壓測、Agent 多輪軌跡與 Web Dashboard 併入同一套設定。本文聚焦它實際解決什麼問題、後端與適配層怎麼分工，以及哪些場景它並不適合。
- 適合誰用？
- EvalScope 適合已經有 OpenAI 相容端點、想在一天內拿到 GSM8K 或 MMLU 分數並同時量測 TTFT、TPOT 的團隊，也適合需要把 Agent 多輪軌跡留下來逐筆檢視的人。若你只需要跑單一學術基準、不想引入 ModelScope 生態的資料集下載路徑，lm-evaluation-harness 這類只做靜態基準的工具會更輕。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
一條 eval 命令背後要解決的重複勞動
跑一次模型評測的麻煩往往不在模型本身。資料集要下載、格式要對齊、提示模板要套、答案抽取要寫正則，換一個基準就重來一遍；如果還要看服務端的吞吐與延遲，通常得另外接一套壓測工具，兩邊的模型名稱與端點設定各寫一份。EvalScope 想收掉的就是這層重複勞動。README 給的起手式是一行安裝加一行執行：pip install evalscope，接著 evalscope eval --model your-model-name --api-url $OPENAI_API_BASE_URL --api-key $OPENAI_API_KEY --eval-type openai_api --datasets gsm8k --limit 5。--limit 5 的用意很直白，先確認整條鏈路通不通，再放大到完整資料集。它的目標讀者不是研究評測方法的人，而是要把「這個模型在我們場景值不值得上線」講清楚的工程團隊。
後端不是自己重寫，而是把既有評測器接起來
EvalScope 的架構選擇值得注意：它沒有把所有基準都自己實作一遍，而是把 OpenCompass、VLMEvalKit、RAGEval 當作可切換的評測後端。這代表同一條命令列介面之下，實際跑的是不同專案的評測邏輯。好處是基準覆蓋面能快速擴張，README 的更新紀錄顯示 2026 年 6 月到 8 月之間接連加入 AutomationBench、JobBench、MiniWoB、OmniDocBench-v1.6、ScreenSpot-Pro、PLawBench、PMC-VQA、LogicVista、CC-OCR-V2 等項目。代價是當某個基準的判定結果與上游後端不一致時，你得先判斷問題出在 EvalScope 的封裝層還是後端本身。RAG 這條線在 2026.06.02 重構過，升級到 MTEB 2.x 與 RAGAS 0.4.x，並改用統一的 Pydantic 設定物件，這種把設定集中成結構化 schema 的做法，正是為了讓多後端共存時參數不至於散落各處。
Agent 模式：多輪迴圈、工具與沙箱是三個獨立變數
Agent 評測是這個專案近期投入最多的方向。README 描述的做法，是把 GSM8K、AIME、SWE-bench Agentic 這類基準放進一個受控的 AgentLoop 中執行，策略與工具可插拔，並搭配 Docker 沙箱；每個樣本的 Agent Trace 都會被記錄下來，可在 Dashboard 檢視。2026.06.23 的更新提到重構了適配層，加入 AudioLanguageAdapter、統一的 FunctionCallAdapter，以及公開的 run_agent_loop API。這裡的設計取捨很明顯：沙箱帶來隔離與可重現性，但也意味著 Agent 類評測的成敗同時取決於模型、工具實作與容器環境三個變數。當某個 SWE-bench 樣本失敗時，你必須先分辨是模型判斷錯誤，還是工具在沙箱內執行超時。2026.05.27 加入的 Trie agentic trace replay，用 trie_agentic_coding、trie_code_qa、trie_office_work 三個資料集外掛重播真實多輪軌跡，並支援逐輪 token 上限與工具呼叫延遲模擬，這是把「重播」與「生成」分開處理的務實做法：要量測服務端在真實負載下的表現，重播比讓模型自由生成更可控。
效能壓測與評測共用同一組設定
多數評測框架只回答「答對幾題」，不回答「每秒能服務幾個請求」。EvalScope 把推論效能壓測放進同一套工具，README 點名支援 TTFT 與 TPOT 等指標。TTFT 是首個 token 的等待時間，TPOT 是後續每個 token 的平均產出時間，這兩個數字對串流式對話服務的體感影響，往往比總吞吐量更直接。2026.06.16 的更新提到效能模組支援統一的 --data-source，並把請求生成平行化，這解決的是壓測時請求產生速度跟不上發送速度、導致量到的延遲其實被客戶端拖慢的問題。2026.05.27 另外加入 --duration 這個以牆鐘時間為預算的參數，適用於所有基準模式。用時間而非固定請求數當終止條件，在延遲分布長尾明顯的服務上更貼近真實觀察，因為固定請求數會讓慢速端點的量測時間被拉得很長。
安裝門檻與版本相容的實際代價
README 的徽章標示 Python 需為 3.10 以上，這是硬性前提，不是建議值。第二個成本來自依賴鏈：專案同時整合 OpenCompass、VLMEvalKit、MTEB 2.x、RAGAS 0.4.x 等多個上游，這些套件各自的版本約束會互相牽動。RAG 模組從舊版升級到 MTEB 2.x 與 RAGAS 0.4.x，屬於帶有破壞性的變更，若你的環境還停在舊版 RAGAS，升級 EvalScope 時必須一併處理。第三個成本是評測結果的可比性。v1.11.0 引入「已發布評測版本」的概念，用來讓基準結果可重現，並改進報告語意與未完成執行的處理方式。這件事的意義在於：同一份報告若沒有標明評測版本，跨時間比較分數就沒有意義。團隊若要長期追蹤某個模型的表現，必須把評測版本號一起記錄下來，否則分數變化可能來自基準本身改版，而非模型改動。
當你要的只是單一靜態基準時
lm-evaluation-harness 是這個領域最常被拿來對比的工具，兩者的取向差異清楚。lm-evaluation-harness 聚焦在靜態基準的任務定義與計分，架構相對單薄，沒有內建 Web Dashboard、沒有多後端抽象層，也不處理推論效能壓測。EvalScope 則把評測、壓測、視覺化與 Agent 迴圈綁成一套。這個差別決定了適用場景：如果你的需求是「跑 MMLU 拿一個分數，寫進報告」，lm-evaluation-harness 的依賴面更小，出問題時要追的層次也更少。反過來說，如果你需要同時比較多個模型的雷達圖、需要 Arena 模式的成對對戰排名、或者需要把 Agent 的每一步軌跡攤開來看，EvalScope 的整合度省下的是自己串接這些環節的工作量。選型時值得問自己一個問題：我需要的是一個計分器，還是一條從執行到檢視的流水線。
授權條款與升級節奏
專案採用 Apache-2.0，允許商業使用與修改，並附帶專利授權條款，比 MIT 在專利層面多一層保障。實際使用時要注意的是它串接的上游：OpenCompass、VLMEvalKit、MTEB、RAGAS 各自有自己的授權，這些條件不會因為外層是 Apache-2.0 就一併適用，尤其是把評測流程包進商業產品時，建議逐一確認各後端的授權。維護節奏方面，從釋出紀錄看，v1.10.0 到 v1.11.1 集中在 2026 年 8 月，v1.11.0 與 v1.11.1 相隔一週，屬於修補跟得上的節奏。但基準數量持續增加、後端持續重構，意味著鎖定版本是必要的：在 CI 中固定 evalscope 的版本號，並把評測版本一併寫入報告，比每次拉最新版更能保證歷史分數可比。
編輯結論
EvalScope 適合已經有 OpenAI 相容端點、想在一天內拿到 GSM8K 或 MMLU 分數並同時量測 TTFT、TPOT 的團隊，也適合需要把 Agent 多輪軌跡留下來逐筆檢視的人。若你只需要跑單一學術基準、不想引入 ModelScope 生態的資料集下載路徑，lm-evaluation-harness 這類只做靜態基準的工具會更輕。動手前先確認三件事：你的 Python 是否達到 3.10、目標資料集在 v1.11.0 之後是否屬於已發布評測版本、以及 Agent 模式所需的 Docker 沙箱在你環境中能否啟動。這三項任一不成立，第一條 eval 命令就不會給出可比較的數字。
社群筆記