合評測指南：兩階段學(xué)術(shù)能力評測實戰(zhàn))
人工智能大模型模型推理服務(wù)推理引擎本地部署模型量化【免費(fèi)下載鏈接】lmdeployLMDeploy is a toolkit for compressing, deploying, and serving LLMs.項目地址https://gitcode.com/gh_mirrors/lm/lmdeploy點(diǎn)擊查看免費(fèi)下載本指南以 LMDeploy 開源倉庫的 模型評測文檔 為骨架系統(tǒng)講解如何使用 LMDeploy 與 OpenCompass 對模型在學(xué)術(shù)數(shù)據(jù)集上的能力進(jìn)行評測。完整評測流程分為「推理階段」與「評判階段」兩個環(huán)節(jié)推理階段由 LMDeploy 將待評測模型部署為推理服務(wù)、OpenCompass 負(fù)責(zé)發(fā)請求與收結(jié)果評判階段則由評測模型opencompass/CompassVerifier-32B擔(dān)任 Judger對推理結(jié)果打分。讀完本文你將掌握端到端與逐步兩種評測模式的完整命令、eval/eval.py的底層原理、評測配置eval/config.py的每一項關(guān)鍵參數(shù)以及如何復(fù)用推理結(jié)果單獨(dú)執(zhí)行評判從而獨(dú)立完成一次可復(fù)現(xiàn)的學(xué)術(shù)評測實驗。評測流程總覽模型評測的核心問題是如何公平、可復(fù)現(xiàn)地衡量一個模型在數(shù)學(xué)、推理、代碼、知識、指令跟隨等學(xué)術(shù)能力上的表現(xiàn)LMDeploy 給出的答案是「兩階段解耦」推理階段Inference先通過lmdeploy serve api_server將待評測模型部署為 OpenAI 兼容的 RESTful 服務(wù)再由 OpenCompass 將數(shù)據(jù)集中的題目組織成請求發(fā)往該服務(wù)收集模型生成的回答。此階段只產(chǎn)出「模型回答」不產(chǎn)出分?jǐn)?shù)。評判階段Evaluation將 OpenCompass 官方提供的評測模型opencompass/CompassVerifier-32B同樣通過 LMDeploy 部署為服務(wù)作為 Judger裁判OpenCompass 將推理階段生成的回答提交給 Judger由 Judger 判斷正確與否最終產(chǎn)出評測分?jǐn)?shù)。兩個階段可一次跑完端到端也可拆開分步執(zhí)行逐步評測后者特別適合資源有限的場景——推理階段可以先保存結(jié)果之后隨時用-r復(fù)用并單獨(dú)執(zhí)行評判。這一設(shè)計在 eval/eval.py 中通過--mode參數(shù)的all / infer / eval / config四種取值直接體現(xiàn)。環(huán)境準(zhǔn)備評測前需要安裝兩個核心組件pip install lmdeploy pip install opencompass[full] # 下載 lmdeploy 源碼后續(xù)會用到 eval/* 目錄下的評測腳本與配置文件 git clone --depth1 https://github.com/InternLM/lmdeploy.git幾點(diǎn)說明opencompass[full]安裝了 OpenCompass 的完整依賴含評測相關(guān)后端若磁盤或網(wǎng)絡(luò)受限可查閱 OpenCompass 官方文檔按需裁剪安裝?？寺}庫是為了獲取 eval/eval.py 評測入口腳本與 eval/config.py 評測配置文件。強(qiáng)烈建議將 LMDeploy 與 OpenCompass 安裝在不同的 Python 虛擬環(huán)境中二者依賴矩陣差異較大混裝容易產(chǎn)生版本沖突。例如 LMDeploy 環(huán)境負(fù)責(zé)啟動服務(wù)OpenCompass 環(huán)境負(fù)責(zé)執(zhí)行python eval/eval.py。端到端評測若評測資源充足可以直接使用--mode all一次完成推理與評判共三步。1. 部署待評測模型lmdeploy serve api_server model_path --server-port 10000 --other-optionsmodel_path可以是 HuggingFace 模型名如Qwen/Qwen2.5-7B-Instruct或本地模型目錄。--server-port 10000指定推理服務(wù)端口后續(xù) OpenCompass 通過--api-server http://{ip}:10000訪問。--other-options按需補(bǔ)充例如--tp 2張量并行、--session-len 65536會話長度、--cache-max-entry-countKV cache 容量等。從 lmdeploy/cli/serve.py 的api_server實現(xiàn)可見該命令最終會構(gòu)建PytorchEngineConfig或TurbomindEngineConfig并啟動 OpenAI 兼容服務(wù)默認(rèn)端口 23333未指定--server-port時生效。2. 部署評測模型Judgerlmdeploy serve api_server opencompass/CompassVerifier-32B --server-port 20000 --tp 2 --session-len 65536Judger 是負(fù)責(zé)打分的模型端口建議與推理服務(wù)區(qū)分此處為20000。--tp 2CompassVerifier-32B 規(guī)模較大使用 2 張 GPU 做張量并行。--session-len 65536與 eval/config.py 中judge_cfg.max_seq_len 65536對齊確保長評測樣例如代碼生成、長輸出推理題不被截斷。3. 生成評測配置并執(zhí)行評測cd {the/root/path/of/lmdeploy/repo} ## 指定數(shù)據(jù)集緩存路徑若該路徑下沒有對應(yīng)數(shù)據(jù)集OpenCompass 會自動下載 export HF_DATASETS_CACHE/nvme4/huggingface_hub/datasets export COMPASS_DATA_CACHE/nvme1/shared/opencompass/.cache python eval/eval.py {task_name} \ --mode all \ --api-server http://{api-server-ip}:10000 \ --judger-server http://{judger-server-ip}:20000 \ -w {oc_output_dir}各參數(shù)含義參數(shù)含義說明{task_name}任務(wù)名位置參數(shù)會寫入配置中的TASK_TAG作為模型在 OpenCompass 中的abbr標(biāo)識--mode all評測模式all表示推理 評判全流程可選infer、eval、config--api-server推理服務(wù)地址必填指向步驟 1 部署的模型服務(wù)--judger-serverJudger 服務(wù)地址必填all/eval模式指向步驟 2 部署的服務(wù)-w輸出目錄OpenCompass 工作目錄結(jié)果按時間戳子目錄存放評測任務(wù)完成后結(jié)果保存在{oc_output_dir}/{yyyymmdd_hhmmss}目錄中其中{yyyymmdd_hhmmss}為任務(wù)執(zhí)行的時間戳。eval.py的更多用法如指定評測集可通過python eval/eval.py --help查看。逐步評測當(dāng)算力有限、無法同時啟動兩個大模型服務(wù)時推薦把流程拆成兩個階段依次執(zhí)行。推理階段生成模型回答第 1 步部署待評測模型命令與端到端模式完全一致lmdeploy serve api_server model_path --server-port 10000 --other-options第 2 步生成推理配置并執(zhí)行推理cd {the/root/path/of/lmdeploy/repo} ## 指定數(shù)據(jù)集路徑。如果在路徑下沒有找到評測數(shù)據(jù)集OC會自動下載 export HF_DATASETS_CACHE/nvme4/huggingface_hub/datasets export COMPASS_DATA_CACHE/nvme1/shared/opencompass/.cache # 執(zhí)行推理任務(wù) python eval/eval.py {task_name} \ --mode infer \ --api-server http://{api-server-ip}:10000 \ -w {oc_output_dir}與端到端模式相比此命令不傳--judger-server只產(chǎn)出推理結(jié)果。推理完成后結(jié)果同樣保存在{oc_output_dir}/{yyyymmdd_hhmmss}時間戳目錄中。評判階段Judger 打分第 1 步部署評測模型Judgerlmdeploy serve api_server opencompass/CompassVerifier-32B --server-port 20000 --tp 2第 2 步生成評判配置并執(zhí)行評判cd {the/root/path/of/lmdeploy/repo} ## 指定數(shù)據(jù)集路徑。如果在路徑下沒有找到評測數(shù)據(jù)集OC會自動下載 export HF_DATASETS_CACHE/nvme4/huggingface_hub/datasets export COMPASS_DATA_CACHE/nvme1/shared/opencompass/.cache # 執(zhí)行評測任務(wù) python eval/eval.py {task_name} \ --mode eval \ --judger-server http://{judger-server-ip}:20000 \ -w {oc_output_dir} -r {yyyymmdd_hhmmss}關(guān)鍵注意事項task_name必須與推理階段的任務(wù)名稱保持一致否則配置中的TASK_TAG不一致會導(dǎo)致評判階段找不到對應(yīng)模型的推理輸出-w指定的輸出目錄oc_output_dir需與推理階段一致這是 OpenCompass 定位歷史輸出的前提-r參數(shù)用于指定「之前的輸出與結(jié)果」應(yīng)填入推理階段生成的時間戳目錄名即{oc_output_dir}下的子目錄名稱格式如20260926_013000。-r的復(fù)用邏輯在 eval/eval.py 中實現(xiàn)腳本會用datetime.strptime(reuse, %Y%m%d_%H%M%S)校驗時間戳格式合法后拼入opencompass ... -r {timestamp}命令若-r后不帶值則復(fù)用工作目錄下最近一次的結(jié)果對應(yīng)-r的constlatest語義。eval.py 工作原理從參數(shù)到 OpenCompass 命令理解 eval/eval.py 的源碼有助于排障和自定義。它本質(zhì)上是一個「配置生成器 命令封裝器」執(zhí)行鏈路如下解析命令行參數(shù)main()支持-a/--api-server、-j/--judger-server、-d/--datasets、-w/--work-dir、-r/--reuse、-m/--mode六類參數(shù)。其中--datasets的合法取值包括aime2025、gpqa、ifeval、code、mmlu_pro、hle、all默認(rèn)all即使用配置中的全部數(shù)據(jù)集。讀取模板配置read_config()讀取腳本同目錄下的 eval/config.py 全文作為配置模板。動態(tài)注入變量用字符串替換完成四類注入——TASK_TAG → 任務(wù)名數(shù)據(jù)集段替換update_datasets()在配置的dataset_replace_tag與/dataset_replace_tag標(biāo)記之間重寫datasets ...行若傳all則保持原樣若傳code會追加LCBCodeGeneration_dataset其余數(shù)據(jù)集名以drlblxrh1_datasets拼接API_SERVER_ADDR/JUDGER_ADDR→ 服務(wù)地址未以http開頭時會自動補(bǔ)全前綴見 eval/eval.py自動探測服務(wù)端模型名通過get_model_name_from_server()eval/eval.py以 OpenAI 客戶端調(diào)用{server}/v1/models取第一個模型 id 回填SERVED_MODEL_PATH/JUDGER_MODEL_PATH保證配置中的path與真實部署模型一致。生成配置或直接執(zhí)行perform_evaluation()-w目錄下寫出更新后的config.py若--mode config則只生成配置不執(zhí)行否則拼裝并運(yùn)行opencompass {work_dir}/config.py -m {mode} -w {work_dir} [-r {timestamp}]。子進(jìn)程通過ProcessManager托管收到SIGINT/SIGTERM時會先優(yōu)雅終止再強(qiáng)殺避免殘留進(jìn)程。評測配置詳解eval/config.py 逐項拆解eval/config.py 是 OpenCompass 的 mmengine 風(fēng)格配置文件eval.py生成的所有配置都以此為基礎(chǔ)。理解它能幫你自定義數(shù)據(jù)集、調(diào)整并發(fā)或采樣參數(shù)。數(shù)據(jù)集與匯總組配置通過read_base()導(dǎo)入六類學(xué)術(shù)數(shù)據(jù)集aime2025_datasetsAIME 2025 數(shù)學(xué)競賽題LLM Judge 打分32 次重復(fù)取平均gpqa_datasetsGPQA 研究生級科學(xué)問答級聯(lián)評測4 次重復(fù)取平均hle_datasetsHLE 人類最后考試LLM Verify 打分ifeval_datasetsIFEval 指令跟隨Prompt-level strict accuracyLCBCodeGeneration_datasetLiveCodeBench 代碼生成pass16 次重復(fù)取平均mmlu_pro_datasetsMMLU-Pro 多學(xué)科知識naive_average。默認(rèn)的datasets行把所有*_datasets變量求和并追加LCBCodeGeneration_datasetdataset_replace_tag標(biāo)記段正是eval.py按--datasets參數(shù)重寫的錨點(diǎn)。core_summary_groups與summarizer定義了一個core_average匯總指標(biāo)把 IFEval、HLE、AIME2025、GPQA、MMLU-Pro、LCB 六項能力加權(quán)匯總為單一均值方便橫向?qū)Ρ炔煌Ｐ?。待評測模型配置modelsmodels [ dict(abbrTASK_TAG, keydummy, openai_api_basef{API_SERVER_ADDR}/v1, typeOpenAISDK, pathSERVED_MODEL_PATH, temperature0.6, meta_templatedict(round[ dict(roleHUMAN, api_roleHUMAN), dict(roleBOT, api_roleBOT, generateTrue), ], ), query_per_second10, max_out_len64000, max_seq_len65536, batch_size32, retry10, pred_postprocessordict(typeextract_non_reasoning_content), verboseFalse) ]關(guān)鍵參數(shù)解讀typeOpenAISDK以 OpenAI SDK 方式調(diào)用 LMDeploy 的/v1接口pathSERVED_MODEL_PATH由eval.py自動探測填充通常無需手工填寫meta_template把對話模板映射為HUMAN/BOT角色generateTrue表示 BOT 輪需要模型生成query_per_second10對推理服務(wù)的 QPS 限速避免打爆服務(wù)max_out_len64000/max_seq_len65536允許極長輸出適配 AIME、LCB 這類長推理鏈數(shù)據(jù)集文檔 llm_compressor.md 提到 aime2025 平均輸出約 17,635 tokens、LCB 約 14,157 tokens若輸出長度限制過小會嚴(yán)重拉低分?jǐn)?shù)pred_postprocessorextract_non_reasoning_contentOpenCompass 提供的后處理器從模型輸出中剝離思考過程reasoning content只保留最終答案用于判分。Judger 配置judge_cfgjudge_cfg dict( abbrCompassVerifier, typeOpenAISDK, pathJUDGER_MODEL_PATH, keyYOUR_API_KEY, openai_api_basef{JUDGER_ADDR}/v1, meta_templatedict(round[ dict(roleHUMAN, api_roleHUMAN), dict(roleBOT, api_roleBOT, generateTrue), ]), query_per_second8, batch_size32, temperature0.001, max_out_len8192, max_seq_len65536, modemid, )Judger 的關(guān)鍵差異點(diǎn)temperature0.001打分任務(wù)要求確定性溫度壓到接近 0減少隨機(jī)性modemid指定 Judger 的驗證模式配置末尾的循環(huán)eval/config.py會把judge_cfg注入到每個數(shù)據(jù)集的eval_cfg.evaluator含llm_evaluator中——這正是文檔中「推理階段生成的結(jié)果提交給 Judger 服務(wù)」的配置實現(xiàn)所有需要 LLM 打分的評測器統(tǒng)一指向同一個 Judger 服務(wù)。推理/評判執(zhí)行配置infer / eval runnerinfer dict( partitionerdict(typeNumWorkerPartitioner, num_worker8), runnerdict( typeLocalRunner, max_num_workers16, retry0, # 可按需修改 taskdict(typeOpenICLInferTask), ), ) eval dict( partitionerdict(typeNaivePartitioner, n10), runnerdict(typeLocalRunner, max_num_workers16, taskdict(typeOpenICLEvalTask)), )推理階段使用NumWorkerPartitioner按 worker 數(shù)切分?jǐn)?shù)據(jù)集num_worker8本地LocalRunner最多 16 個并發(fā) worker評判階段使用NaivePartitionern10同樣本地并發(fā)執(zhí)行若機(jī)器核數(shù)較少可下調(diào)max_num_workers若推理服務(wù)吞吐有限可同步調(diào)低models中的query_per_second與batch_size或提高retry容錯。倉庫 autotest/evaluate/ 目錄下的eval_config_base.py、eval_config_chat.py、eval_config_chat_longtext.py等文件展示了另一種面向自動化測試的 OpenCompass 配置范式TurboMindAPIModel直連、PPL 類評測集、dataset_size_path數(shù)據(jù)集規(guī)模緩存等適合需要批量回歸評測的場景可作為自定義評測配置的補(bǔ)充參考。結(jié)果目錄與復(fù)用機(jī)制無論端到端還是逐步評測OpenCompass 都會在-w指定的工作目錄下按{yyyymmdd_hhmmss}時間戳創(chuàng)建結(jié)果目錄內(nèi)含推理輸出predictions/、評測分?jǐn)?shù)summary/下的 CSV/JSON以及 OpenCompass 生成的完整配置快照。借助這一目錄結(jié)構(gòu)eval.py的-r參數(shù)實現(xiàn)了以下三類典型用法-r {timestamp}顯式復(fù)用指定時間戳的結(jié)果例如分步評測時把推理階段的結(jié)果喂給評判階段-r不帶值復(fù)用工作目錄下最新一次的結(jié)果不傳-r從頭執(zhí)行覆蓋式產(chǎn)出新結(jié)果。這也意味著只要推理階段產(chǎn)出的回答保持不變你可以隨時更換 Judger 模型或調(diào)整打分配置重新評判而不必重復(fù)昂貴的推理——這正是兩階段解耦設(shè)計的核心價值。注意事項與排障建議依賴隔離LMDeploy 與 OpenCompass 分裝兩個虛擬環(huán)境eval.py運(yùn)行在 OpenCompass 環(huán)境、服務(wù)運(yùn)行在 LMDeploy 環(huán)境二者通過 HTTP 解耦互不依賴進(jìn)程內(nèi)包版本。端口與地址可達(dá)性--api-server/--judger-server填寫的 IP 必須能被運(yùn)行eval.py的機(jī)器訪問eval.py會先調(diào)用/v1/models探測模型名若該請求失敗會直接報Failed to get model name ...此時應(yīng)先排查服務(wù)是否就緒、端口是否開放。數(shù)據(jù)集自動下載若HF_DATASETS_CACHE/COMPASS_DATA_CACHE路徑下沒有數(shù)據(jù)集OpenCompass 會自動從 HuggingFace 下載請保證網(wǎng)絡(luò)連通與磁盤空間評測前可先跑一次--mode config生成配置并檢查數(shù)據(jù)集導(dǎo)入是否成功。長輸出數(shù)據(jù)集與 max_out_lenAIME2025、LCB 等數(shù)據(jù)集輸出可達(dá)上萬 token不要調(diào)小max_out_len默認(rèn) 64000否則模型回答被截斷會顯著低估真實能力。Judger 顯存規(guī)劃CompassVerifier-32B建議按--tp 2及以上配置部署并確保--session-len與配置中max_seq_len65536匹配若顯存緊張可考慮分步評測先完成推理再啟動 Judger。任務(wù)名一致性分步評測時推理與評判階段的task_name、-w目錄必須完全一致-r填推理階段的時間戳目錄名否則 OpenCompass 無法找到待評判的預(yù)測結(jié)果。評測完成后結(jié)合 supported_models.md 確認(rèn)模型支持情況并可將 量化精度評測 等文檔中介紹的評測方法復(fù)用——同一套eval.py流程同樣適用于量化模型、長上下文模型的精度對比實驗。贊分享人工智能大模型模型推理服務(wù)推理引擎本地部署模型量化【免費(fèi)下載鏈接】lmdeployLMDeploy is a toolkit for compressing, deploying, and serving LLMs.項目地址https://gitcode.com/gh_mirrors/lm/lmdeploy點(diǎn)擊查看免費(fèi)下載相關(guān)推薦LMDeploy 集成 OpenCompass 模型評測實戰(zhàn)指南端到端學(xué)術(shù)評測流程與源碼級解析LMDeploy 集成 OpenCompass 模型評測實戰(zhàn)指南端到端學(xué)術(shù)評測流程與源碼級解析 本篇技術(shù)指南聚焦于 LMDeploy 與 OpenCompas人工智能大模型模型推理服務(wù)推理引擎本地部署模型量化AIMLInterviews 目標(biāo)檢測指南兩階段與單階段檢測器原理、架構(gòu)對比與 mAP 評估體系詳解AIMLInterviews 目標(biāo)檢測指南兩階段與單階段檢測器原理、架構(gòu)對比與 mAP 評估體系詳解 本指南是 AIMLInterviews 項目 ML 系統(tǒng)示例工程教程人工智能XTuner LLaVA 全流程實戰(zhàn)指南從兩階段訓(xùn)練到模型轉(zhuǎn)換、對話測試與多模態(tài)評測XTuner LLaVA 全流程實戰(zhàn)指南從兩階段訓(xùn)練到模型轉(zhuǎn)換、對話測試與多模態(tài)評測 本指南以 XTuner 倉庫中 LLaVA 全流程文檔 https://大模型模型微調(diào)上一篇終極防護(hù)如何用Fail2Ban抵御日志偽造攻擊下一篇LocalAI深度指南開源AI引擎的架構(gòu)解析與生產(chǎn)部署實踐創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 LMDeploy 與 OpenCompass 聯(lián)合評測指南：兩階段學(xué)術(shù)能力評測實戰(zhàn)
人工智能大模型模型推理服務(wù)推理引擎本地部署模型量化【免費(fèi)下載鏈接】lmdeployLMDeploy is a toolkit for compressing, deploying, and serving LLMs.項目地址https://gitcode.com/gh_mirrors/lm/lmdeploy點(diǎn)擊查看免費(fèi)下載本指南以 LMDeploy 開源倉庫的 模型評測文檔 為骨架系統(tǒng)講解如何使用 LMDeploy 與 OpenCompass 對模型在學(xué)術(shù)數(shù)據(jù)集上的能力進(jìn)行評測。完整評測流程分為「推理階段」與「評判階段」兩個環(huán)節(jié)推理階段由 LMDeploy 將待評測模型部署為推理服務(wù)、OpenCompass 負(fù)責(zé)發(fā)請求與收結(jié)果評判階段則由評測模型opencompass/CompassVerifier-32B擔(dān)任 Judger對推理結(jié)果打分。讀完本文你將掌握端到端與逐步兩種評測模式的完整命令、eval/eval.py的底層原理、評測配置eval/config.py的每一項關(guān)鍵參數(shù)以及如何復(fù)用推理結(jié)果單獨(dú)執(zhí)行評判從而獨(dú)立完成一次可復(fù)現(xiàn)的學(xué)術(shù)評測實驗。評測流程總覽模型評測的核心問題是如何公平、可復(fù)現(xiàn)地衡量一個模型在數(shù)學(xué)、推理、代碼、知識、指令跟隨等學(xué)術(shù)能力上的表現(xiàn)LMDeploy 給出的答案是「兩階段解耦」推理階段Inference先通過lmdeploy serve api_server將待評測模型部署為 OpenAI 兼容的 RESTful 服務(wù)再由 OpenCompass 將數(shù)據(jù)集中的題目組織成請求發(fā)往該服務(wù)收集模型生成的回答。此階段只產(chǎn)出「模型回答」不產(chǎn)出分?jǐn)?shù)。評判階段Evaluation將 OpenCompass 官方提供的評測模型opencompass/CompassVerifier-32B同樣通過 LMDeploy 部署為服務(wù)作為 Judger裁判OpenCompass 將推理階段生成的回答提交給 Judger由 Judger 判斷正確與否最終產(chǎn)出評測分?jǐn)?shù)。兩個階段可一次跑完端到端也可拆開分步執(zhí)行逐步評測后者特別適合資源有限的場景——推理階段可以先保存結(jié)果之后隨時用-r復(fù)用并單獨(dú)執(zhí)行評判。這一設(shè)計在 eval/eval.py 中通過--mode參數(shù)的all / infer / eval / config四種取值直接體現(xiàn)。環(huán)境準(zhǔn)備評測前需要安裝兩個核心組件pip install lmdeploy pip install opencompass[full] # 下載 lmdeploy 源碼后續(xù)會用到 eval/* 目錄下的評測腳本與配置文件 git clone --depth1 https://github.com/InternLM/lmdeploy.git幾點(diǎn)說明opencompass[full]安裝了 OpenCompass 的完整依賴含評測相關(guān)后端若磁盤或網(wǎng)絡(luò)受限可查閱 OpenCompass 官方文檔按需裁剪安裝?？寺}庫是為了獲取 eval/eval.py 評測入口腳本與 eval/config.py 評測配置文件。強(qiáng)烈建議將 LMDeploy 與 OpenCompass 安裝在不同的 Python 虛擬環(huán)境中二者依賴矩陣差異較大混裝容易產(chǎn)生版本沖突。例如 LMDeploy 環(huán)境負(fù)責(zé)啟動服務(wù)OpenCompass 環(huán)境負(fù)責(zé)執(zhí)行python eval/eval.py。端到端評測若評測資源充足可以直接使用--mode all一次完成推理與評判共三步。1. 部署待評測模型lmdeploy serve api_server model_path --server-port 10000 --other-optionsmodel_path可以是 HuggingFace 模型名如Qwen/Qwen2.5-7B-Instruct或本地模型目錄。--server-port 10000指定推理服務(wù)端口后續(xù) OpenCompass 通過--api-server http://{ip}:10000訪問。--other-options按需補(bǔ)充例如--tp 2張量并行、--session-len 65536會話長度、--cache-max-entry-countKV cache 容量等。從 lmdeploy/cli/serve.py 的api_server實現(xiàn)可見該命令最終會構(gòu)建PytorchEngineConfig或TurbomindEngineConfig并啟動 OpenAI 兼容服務(wù)默認(rèn)端口 23333未指定--server-port時生效。2. 部署評測模型Judgerlmdeploy serve api_server opencompass/CompassVerifier-32B --server-port 20000 --tp 2 --session-len 65536Judger 是負(fù)責(zé)打分的模型端口建議與推理服務(wù)區(qū)分此處為20000。--tp 2CompassVerifier-32B 規(guī)模較大使用 2 張 GPU 做張量并行。--session-len 65536與 eval/config.py 中judge_cfg.max_seq_len 65536對齊確保長評測樣例如代碼生成、長輸出推理題不被截斷。3. 生成評測配置并執(zhí)行評測cd {the/root/path/of/lmdeploy/repo} ## 指定數(shù)據(jù)集緩存路徑若該路徑下沒有對應(yīng)數(shù)據(jù)集OpenCompass 會自動下載 export HF_DATASETS_CACHE/nvme4/huggingface_hub/datasets export COMPASS_DATA_CACHE/nvme1/shared/opencompass/.cache python eval/eval.py {task_name} \ --mode all \ --api-server http://{api-server-ip}:10000 \ --judger-server http://{judger-server-ip}:20000 \ -w {oc_output_dir}各參數(shù)含義參數(shù)含義說明{task_name}任務(wù)名位置參數(shù)會寫入配置中的TASK_TAG作為模型在 OpenCompass 中的abbr標(biāo)識--mode all評測模式all表示推理 評判全流程可選infer、eval、config--api-server推理服務(wù)地址必填指向步驟 1 部署的模型服務(wù)--judger-serverJudger 服務(wù)地址必填all/eval模式指向步驟 2 部署的服務(wù)-w輸出目錄OpenCompass 工作目錄結(jié)果按時間戳子目錄存放評測任務(wù)完成后結(jié)果保存在{oc_output_dir}/{yyyymmdd_hhmmss}目錄中其中{yyyymmdd_hhmmss}為任務(wù)執(zhí)行的時間戳。eval.py的更多用法如指定評測集可通過python eval/eval.py --help查看。逐步評測當(dāng)算力有限、無法同時啟動兩個大模型服務(wù)時推薦把流程拆成兩個階段依次執(zhí)行。推理階段生成模型回答第 1 步部署待評測模型命令與端到端模式完全一致lmdeploy serve api_server model_path --server-port 10000 --other-options第 2 步生成推理配置并執(zhí)行推理cd {the/root/path/of/lmdeploy/repo} ## 指定數(shù)據(jù)集路徑。如果在路徑下沒有找到評測數(shù)據(jù)集OC會自動下載 export HF_DATASETS_CACHE/nvme4/huggingface_hub/datasets export COMPASS_DATA_CACHE/nvme1/shared/opencompass/.cache # 執(zhí)行推理任務(wù) python eval/eval.py {task_name} \ --mode infer \ --api-server http://{api-server-ip}:10000 \ -w {oc_output_dir}與端到端模式相比此命令不傳--judger-server只產(chǎn)出推理結(jié)果。推理完成后結(jié)果同樣保存在{oc_output_dir}/{yyyymmdd_hhmmss}時間戳目錄中。評判階段Judger 打分第 1 步部署評測模型Judgerlmdeploy serve api_server opencompass/CompassVerifier-32B --server-port 20000 --tp 2第 2 步生成評判配置并執(zhí)行評判cd {the/root/path/of/lmdeploy/repo} ## 指定數(shù)據(jù)集路徑。如果在路徑下沒有找到評測數(shù)據(jù)集OC會自動下載 export HF_DATASETS_CACHE/nvme4/huggingface_hub/datasets export COMPASS_DATA_CACHE/nvme1/shared/opencompass/.cache # 執(zhí)行評測任務(wù) python eval/eval.py {task_name} \ --mode eval \ --judger-server http://{judger-server-ip}:20000 \ -w {oc_output_dir} -r {yyyymmdd_hhmmss}關(guān)鍵注意事項task_name必須與推理階段的任務(wù)名稱保持一致否則配置中的TASK_TAG不一致會導(dǎo)致評判階段找不到對應(yīng)模型的推理輸出-w指定的輸出目錄oc_output_dir需與推理階段一致這是 OpenCompass 定位歷史輸出的前提-r參數(shù)用于指定「之前的輸出與結(jié)果」應(yīng)填入推理階段生成的時間戳目錄名即{oc_output_dir}下的子目錄名稱格式如20260926_013000。-r的復(fù)用邏輯在 eval/eval.py 中實現(xiàn)腳本會用datetime.strptime(reuse, %Y%m%d_%H%M%S)校驗時間戳格式合法后拼入opencompass ... -r {timestamp}命令若-r后不帶值則復(fù)用工作目錄下最近一次的結(jié)果對應(yīng)-r的constlatest語義。eval.py 工作原理從參數(shù)到 OpenCompass 命令理解 eval/eval.py 的源碼有助于排障和自定義。它本質(zhì)上是一個「配置生成器 命令封裝器」執(zhí)行鏈路如下解析命令行參數(shù)main()支持-a/--api-server、-j/--judger-server、-d/--datasets、-w/--work-dir、-r/--reuse、-m/--mode六類參數(shù)。其中--datasets的合法取值包括aime2025、gpqa、ifeval、code、mmlu_pro、hle、all默認(rèn)all即使用配置中的全部數(shù)據(jù)集。讀取模板配置read_config()讀取腳本同目錄下的 eval/config.py 全文作為配置模板。動態(tài)注入變量用字符串替換完成四類注入——TASK_TAG → 任務(wù)名數(shù)據(jù)集段替換update_datasets()在配置的dataset_replace_tag與/dataset_replace_tag標(biāo)記之間重寫datasets ...行若傳all則保持原樣若傳code會追加LCBCodeGeneration_dataset其余數(shù)據(jù)集名以drlblxrh1_datasets拼接API_SERVER_ADDR/JUDGER_ADDR→ 服務(wù)地址未以http開頭時會自動補(bǔ)全前綴見 eval/eval.py自動探測服務(wù)端模型名通過get_model_name_from_server()eval/eval.py以 OpenAI 客戶端調(diào)用{server}/v1/models取第一個模型 id 回填SERVED_MODEL_PATH/JUDGER_MODEL_PATH保證配置中的path與真實部署模型一致。生成配置或直接執(zhí)行perform_evaluation()-w目錄下寫出更新后的config.py若--mode config則只生成配置不執(zhí)行否則拼裝并運(yùn)行opencompass {work_dir}/config.py -m {mode} -w {work_dir} [-r {timestamp}]。子進(jìn)程通過ProcessManager托管收到SIGINT/SIGTERM時會先優(yōu)雅終止再強(qiáng)殺避免殘留進(jìn)程。評測配置詳解eval/config.py 逐項拆解eval/config.py 是 OpenCompass 的 mmengine 風(fēng)格配置文件eval.py生成的所有配置都以此為基礎(chǔ)。理解它能幫你自定義數(shù)據(jù)集、調(diào)整并發(fā)或采樣參數(shù)。數(shù)據(jù)集與匯總組配置通過read_base()導(dǎo)入六類學(xué)術(shù)數(shù)據(jù)集aime2025_datasetsAIME 2025 數(shù)學(xué)競賽題LLM Judge 打分32 次重復(fù)取平均gpqa_datasetsGPQA 研究生級科學(xué)問答級聯(lián)評測4 次重復(fù)取平均hle_datasetsHLE 人類最后考試LLM Verify 打分ifeval_datasetsIFEval 指令跟隨Prompt-level strict accuracyLCBCodeGeneration_datasetLiveCodeBench 代碼生成pass16 次重復(fù)取平均mmlu_pro_datasetsMMLU-Pro 多學(xué)科知識naive_average。默認(rèn)的datasets行把所有*_datasets變量求和并追加LCBCodeGeneration_datasetdataset_replace_tag標(biāo)記段正是eval.py按--datasets參數(shù)重寫的錨點(diǎn)。core_summary_groups與summarizer定義了一個core_average匯總指標(biāo)把 IFEval、HLE、AIME2025、GPQA、MMLU-Pro、LCB 六項能力加權(quán)匯總為單一均值方便橫向?qū)Ρ炔煌Ｐ?。待評測模型配置modelsmodels [ dict(abbrTASK_TAG, keydummy, openai_api_basef{API_SERVER_ADDR}/v1, typeOpenAISDK, pathSERVED_MODEL_PATH, temperature0.6, meta_templatedict(round[ dict(roleHUMAN, api_roleHUMAN), dict(roleBOT, api_roleBOT, generateTrue), ], ), query_per_second10, max_out_len64000, max_seq_len65536, batch_size32, retry10, pred_postprocessordict(typeextract_non_reasoning_content), verboseFalse) ]關(guān)鍵參數(shù)解讀typeOpenAISDK以 OpenAI SDK 方式調(diào)用 LMDeploy 的/v1接口pathSERVED_MODEL_PATH由eval.py自動探測填充通常無需手工填寫meta_template把對話模板映射為HUMAN/BOT角色generateTrue表示 BOT 輪需要模型生成query_per_second10對推理服務(wù)的 QPS 限速避免打爆服務(wù)max_out_len64000/max_seq_len65536允許極長輸出適配 AIME、LCB 這類長推理鏈數(shù)據(jù)集文檔 llm_compressor.md 提到 aime2025 平均輸出約 17,635 tokens、LCB 約 14,157 tokens若輸出長度限制過小會嚴(yán)重拉低分?jǐn)?shù)pred_postprocessorextract_non_reasoning_contentOpenCompass 提供的后處理器從模型輸出中剝離思考過程reasoning content只保留最終答案用于判分。Judger 配置judge_cfgjudge_cfg dict( abbrCompassVerifier, typeOpenAISDK, pathJUDGER_MODEL_PATH, keyYOUR_API_KEY, openai_api_basef{JUDGER_ADDR}/v1, meta_templatedict(round[ dict(roleHUMAN, api_roleHUMAN), dict(roleBOT, api_roleBOT, generateTrue), ]), query_per_second8, batch_size32, temperature0.001, max_out_len8192, max_seq_len65536, modemid, )Judger 的關(guān)鍵差異點(diǎn)temperature0.001打分任務(wù)要求確定性溫度壓到接近 0減少隨機(jī)性modemid指定 Judger 的驗證模式配置末尾的循環(huán)eval/config.py會把judge_cfg注入到每個數(shù)據(jù)集的eval_cfg.evaluator含llm_evaluator中——這正是文檔中「推理階段生成的結(jié)果提交給 Judger 服務(wù)」的配置實現(xiàn)所有需要 LLM 打分的評測器統(tǒng)一指向同一個 Judger 服務(wù)。推理/評判執(zhí)行配置infer / eval runnerinfer dict( partitionerdict(typeNumWorkerPartitioner, num_worker8), runnerdict( typeLocalRunner, max_num_workers16, retry0, # 可按需修改 taskdict(typeOpenICLInferTask), ), ) eval dict( partitionerdict(typeNaivePartitioner, n10), runnerdict(typeLocalRunner, max_num_workers16, taskdict(typeOpenICLEvalTask)), )推理階段使用NumWorkerPartitioner按 worker 數(shù)切分?jǐn)?shù)據(jù)集num_worker8本地LocalRunner最多 16 個并發(fā) worker評判階段使用NaivePartitionern10同樣本地并發(fā)執(zhí)行若機(jī)器核數(shù)較少可下調(diào)max_num_workers若推理服務(wù)吞吐有限可同步調(diào)低models中的query_per_second與batch_size或提高retry容錯。倉庫 autotest/evaluate/ 目錄下的eval_config_base.py、eval_config_chat.py、eval_config_chat_longtext.py等文件展示了另一種面向自動化測試的 OpenCompass 配置范式TurboMindAPIModel直連、PPL 類評測集、dataset_size_path數(shù)據(jù)集規(guī)模緩存等適合需要批量回歸評測的場景可作為自定義評測配置的補(bǔ)充參考。結(jié)果目錄與復(fù)用機(jī)制無論端到端還是逐步評測OpenCompass 都會在-w指定的工作目錄下按{yyyymmdd_hhmmss}時間戳創(chuàng)建結(jié)果目錄內(nèi)含推理輸出predictions/、評測分?jǐn)?shù)summary/下的 CSV/JSON以及 OpenCompass 生成的完整配置快照。借助這一目錄結(jié)構(gòu)eval.py的-r參數(shù)實現(xiàn)了以下三類典型用法-r {timestamp}顯式復(fù)用指定時間戳的結(jié)果例如分步評測時把推理階段的結(jié)果喂給評判階段-r不帶值復(fù)用工作目錄下最新一次的結(jié)果不傳-r從頭執(zhí)行覆蓋式產(chǎn)出新結(jié)果。這也意味著只要推理階段產(chǎn)出的回答保持不變你可以隨時更換 Judger 模型或調(diào)整打分配置重新評判而不必重復(fù)昂貴的推理——這正是兩階段解耦設(shè)計的核心價值。注意事項與排障建議依賴隔離LMDeploy 與 OpenCompass 分裝兩個虛擬環(huán)境eval.py運(yùn)行在 OpenCompass 環(huán)境、服務(wù)運(yùn)行在 LMDeploy 環(huán)境二者通過 HTTP 解耦互不依賴進(jìn)程內(nèi)包版本。端口與地址可達(dá)性--api-server/--judger-server填寫的 IP 必須能被運(yùn)行eval.py的機(jī)器訪問eval.py會先調(diào)用/v1/models探測模型名若該請求失敗會直接報Failed to get model name ...此時應(yīng)先排查服務(wù)是否就緒、端口是否開放。數(shù)據(jù)集自動下載若HF_DATASETS_CACHE/COMPASS_DATA_CACHE路徑下沒有數(shù)據(jù)集OpenCompass 會自動從 HuggingFace 下載請保證網(wǎng)絡(luò)連通與磁盤空間評測前可先跑一次--mode config生成配置并檢查數(shù)據(jù)集導(dǎo)入是否成功。長輸出數(shù)據(jù)集與 max_out_lenAIME2025、LCB 等數(shù)據(jù)集輸出可達(dá)上萬 token不要調(diào)小max_out_len默認(rèn) 64000否則模型回答被截斷會顯著低估真實能力。Judger 顯存規(guī)劃CompassVerifier-32B建議按--tp 2及以上配置部署并確保--session-len與配置中max_seq_len65536匹配若顯存緊張可考慮分步評測先完成推理再啟動 Judger。任務(wù)名一致性分步評測時推理與評判階段的task_name、-w目錄必須完全一致-r填推理階段的時間戳目錄名否則 OpenCompass 無法找到待評判的預(yù)測結(jié)果。評測完成后結(jié)合 supported_models.md 確認(rèn)模型支持情況并可將 量化精度評測 等文檔中介紹的評測方法復(fù)用——同一套eval.py流程同樣適用于量化模型、長上下文模型的精度對比實驗。贊分享人工智能大模型模型推理服務(wù)推理引擎本地部署模型量化【免費(fèi)下載鏈接】lmdeployLMDeploy is a toolkit for compressing, deploying, and serving LLMs.項目地址https://gitcode.com/gh_mirrors/lm/lmdeploy點(diǎn)擊查看免費(fèi)下載相關(guān)推薦LMDeploy 集成 OpenCompass 模型評測實戰(zhàn)指南端到端學(xué)術(shù)評測流程與源碼級解析LMDeploy 集成 OpenCompass 模型評測實戰(zhàn)指南端到端學(xué)術(shù)評測流程與源碼級解析 本篇技術(shù)指南聚焦于 LMDeploy 與 OpenCompas人工智能大模型模型推理服務(wù)推理引擎本地部署模型量化AIMLInterviews 目標(biāo)檢測指南兩階段與單階段檢測器原理、架構(gòu)對比與 mAP 評估體系詳解AIMLInterviews 目標(biāo)檢測指南兩階段與單階段檢測器原理、架構(gòu)對比與 mAP 評估體系詳解 本指南是 AIMLInterviews 項目 ML 系統(tǒng)示例工程教程人工智能XTuner LLaVA 全流程實戰(zhàn)指南從兩階段訓(xùn)練到模型轉(zhuǎn)換、對話測試與多模態(tài)評測XTuner LLaVA 全流程實戰(zhàn)指南從兩階段訓(xùn)練到模型轉(zhuǎn)換、對話測試與多模態(tài)評測 本指南以 XTuner 倉庫中 LLaVA 全流程文檔 https://大模型模型微調(diào)上一篇終極防護(hù)如何用Fail2Ban抵御日志偽造攻擊下一篇LocalAI深度指南開源AI引擎的架構(gòu)解析與生產(chǎn)部署實踐創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考