LMDeploy 与 OpenCompass 联合评测指南：两阶段学术能力评测实战

• 人工智能
• 大模型
• 模型推理服务
• 推理引擎
• 本地部署
• 模型量化

【免费下载链接】lmdeploy

LMDeploy is a toolkit for compressing, deploying, and serving LLMs.

项目地址：https://gitcode.com/gh_mirrors/lm/lmdeploy

点击查看免费下载

本指南以 LMDeploy 开源仓库的 模型评测文档 为骨架，系统讲解如何使用 LMDeploy 与 OpenCompass 对模型在学术数据集上的能力进行评测。完整评测流程分为「推理阶段」与「评判阶段」两个环节：推理阶段由 LMDeploy 将待评测模型部署为推理服务、OpenCompass 负责发请求与收结果；评判阶段则由评测模型opencompass/CompassVerifier-32B担任 Judger，对推理结果打分。读完本文，你将掌握端到端与逐步两种评测模式的完整命令、eval/eval.py的底层原理、评测配置（eval/config.py）的每一项关键参数，以及如何复用推理结果单独执行评判，从而独立完成一次可复现的学术评测实验。

评测流程总览

模型评测的核心问题是：如何公平、可复现地衡量一个模型在数学、推理、代码、知识、指令跟随等学术能力上的表现？LMDeploy 给出的答案是「两阶段解耦」：

• 推理阶段（Inference）：先通过lmdeploy serve api_server将待评测模型部署为 OpenAI 兼容的 RESTful 服务，再由 OpenCompass 将数据集中的题目组织成请求发往该服务，收集模型生成的回答。此阶段只产出「模型回答」，不产出分数。
• 评判阶段（Evaluation）：将 OpenCompass 官方提供的评测模型opencompass/CompassVerifier-32B同样通过 LMDeploy 部署为服务，作为 Judger（裁判），OpenCompass 将推理阶段生成的回答提交给 Judger，由 Judger 判断正确与否，最终产出评测分数。

两个阶段可一次跑完（端到端），也可拆开分步执行（逐步评测），后者特别适合资源有限的场景——推理阶段可以先保存结果，之后随时用-r复用并单独执行评判。这一设计在 eval/eval.py 中通过--mode参数的all / infer / eval / config四种取值直接体现。

环境准备

评测前需要安装两个核心组件：

pip install lmdeploy pip install "opencompass[full]" # 下载 lmdeploy 源码，后续会用到 eval/* 目录下的评测脚本与配置文件 git clone --depth=1 https://github.com/InternLM/lmdeploy.git

几点说明：

• opencompass[full]安装了 OpenCompass 的完整依赖（含评测相关后端）；若磁盘或网络受限，可查阅 OpenCompass 官方文档按需裁剪安装。
• 克隆仓库是为了获取 eval/eval.py 评测入口脚本与 eval/config.py 评测配置文件。
• 强烈建议将 LMDeploy 与 OpenCompass 安装在不同的 Python 虚拟环境中，二者依赖矩阵差异较大，混装容易产生版本冲突。例如 LMDeploy 环境负责启动服务，OpenCompass 环境负责执行python eval/eval.py。

端到端评测

若评测资源充足，可以直接使用--mode all一次完成推理与评判，共三步。

1. 部署待评测模型

lmdeploy serve api_server <model_path> --server-port 10000 <--other-options>

• <model_path>可以是 HuggingFace 模型名（如Qwen/Qwen2.5-7B-Instruct）或本地模型目录。
• --server-port 10000指定推理服务端口，后续 OpenCompass 通过--api-server http://{ip}:10000访问。
• <--other-options>按需补充，例如--tp 2（张量并行）、--session-len 65536（会话长度）、--cache-max-entry-count（KV cache 容量）等。从 lmdeploy/cli/serve.py 的api_server实现可见，该命令最终会构建PytorchEngineConfig或TurbomindEngineConfig并启动 OpenAI 兼容服务（默认端口 23333，未指定--server-port时生效）。

2. 部署评测模型（Judger）

lmdeploy serve api_server opencompass/CompassVerifier-32B --server-port 20000 --tp 2 --session-len 65536

• Judger 是负责打分的模型，端口建议与推理服务区分（此处为20000）。
• --tp 2：CompassVerifier-32B 规模较大，使用 2 张 GPU 做张量并行。
• --session-len 65536：与 eval/config.py 中judge_cfg.max_seq_len = 65536对齐，确保长评测样例（如代码生成、长输出推理题）不被截断。

3. 生成评测配置并执行评测

cd {the/root/path/of/lmdeploy/repo} ## 指定数据集缓存路径；若该路径下没有对应数据集，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}

各参数含义：

参数	含义	说明
{task_name}	任务名（位置参数）	会写入配置中的TASK_TAG，作为模型在 OpenCompass 中的abbr标识
--mode all	评测模式	all表示推理 + 评判全流程；可选infer、eval、config
--api-server	推理服务地址	必填，指向步骤 1 部署的模型服务
--judger-server	Judger 服务地址	必填（all/eval模式），指向步骤 2 部署的服务
-w	输出目录	OpenCompass 工作目录，结果按时间戳子目录存放

评测任务完成后，结果保存在{oc_output_dir}/{yyyymmdd_hhmmss}目录中，其中{yyyymmdd_hhmmss}为任务执行的时间戳。eval.py的更多用法（如指定评测集）可通过python eval/eval.py --help查看。

逐步评测

当算力有限、无法同时启动两个大模型服务时，推荐把流程拆成两个阶段依次执行。

推理阶段：生成模型回答

第 1 步：部署待评测模型，命令与端到端模式完全一致：

lmdeploy serve api_server <model_path> --server-port 10000 <--other-options>

第 2 步：生成推理配置并执行推理：

cd {the/root/path/of/lmdeploy/repo} ## 指定数据集路径。如果在路径下没有找到评测数据集，OC会自动下载 export HF_DATASETS_CACHE=/nvme4/huggingface_hub/datasets export COMPASS_DATA_CACHE=/nvme1/shared/opencompass/.cache # 执行推理任务 python eval/eval.py {task_name} \ --mode infer \ --api-server http://{api-server-ip}:10000 \ -w {oc_output_dir}

与端到端模式相比，此命令不传--judger-server，只产出推理结果。推理完成后，结果同样保存在{oc_output_dir}/{yyyymmdd_hhmmss}时间戳目录中。

评判阶段：Judger 打分

第 1 步：部署评测模型（Judger）：

lmdeploy serve api_server opencompass/CompassVerifier-32B --server-port 20000 --tp 2

第 2 步：生成评判配置并执行评判：

cd {the/root/path/of/lmdeploy/repo} ## 指定数据集路径。如果在路径下没有找到评测数据集，OC会自动下载 export HF_DATASETS_CACHE=/nvme4/huggingface_hub/datasets export COMPASS_DATA_CACHE=/nvme1/shared/opencompass/.cache # 执行评测任务 python eval/eval.py {task_name} \ --mode eval \ --judger-server http://{judger-server-ip}:20000 \ -w {oc_output_dir} -r {yyyymmdd_hhmmss}

关键注意事项：

• task_name必须与推理阶段的任务名称保持一致，否则配置中的TASK_TAG不一致，会导致评判阶段找不到对应模型的推理输出；
• -w指定的输出目录oc_output_dir需与推理阶段一致，这是 OpenCompass 定位历史输出的前提；
• -r参数用于指定「之前的输出与结果」，应填入推理阶段生成的时间戳目录名，即{oc_output_dir}下的子目录名称（格式如20260926_013000）。

-r的复用逻辑在 eval/eval.py 中实现：脚本会用datetime.strptime(reuse, '%Y%m%d_%H%M%S')校验时间戳格式，合法后拼入opencompass ... -r {timestamp}命令；若-r后不带值，则复用工作目录下最近一次的结果（对应-r的const='latest'语义）。

eval.py 工作原理：从参数到 OpenCompass 命令

理解 eval/eval.py 的源码有助于排障和自定义。它本质上是一个「配置生成器 + 命令封装器」，执行链路如下：

1. 解析命令行参数（main()）：支持-a/--api-server、-j/--judger-server、-d/--datasets、-w/--work-dir、-r/--reuse、-m/--mode六类参数。其中--datasets的合法取值包括aime2025、gpqa、ifeval、code、mmlu_pro、hle、all，默认all（即使用配置中的全部数据集）。
2. 读取模板配置（read_config()）：读取脚本同目录下的 eval/config.py 全文作为配置模板。
3. 动态注入变量：用字符串替换完成四类注入——
   • TASK_TAG = ''→ 任务名；
   • 数据集段替换：update_datasets()在配置的<dataset_replace_tag>与</dataset_replace_tag>标记之间重写datasets = ...行（若传all则保持原样；若传code会追加LCBCodeGeneration_dataset，其余数据集名以{d}_datasets拼接）；
   • API_SERVER_ADDR/JUDGER_ADDR→ 服务地址（未以http开头时会自动补全前缀，见 eval/eval.py）；
   • 自动探测服务端模型名：通过get_model_name_from_server()（eval/eval.py）以 OpenAI 客户端调用{server}/v1/models，取第一个模型 id 回填SERVED_MODEL_PATH/JUDGER_MODEL_PATH，保证配置中的path与真实部署模型一致。
4. 生成配置或直接执行（perform_evaluation()）：-w目录下写出更新后的config.py；若--mode config则只生成配置不执行；否则拼装并运行opencompass {work_dir}/config.py -m {mode} -w {work_dir} [-r {timestamp}]。子进程通过ProcessManager托管，收到SIGINT/SIGTERM时会先优雅终止再强杀，避免残留进程。

评测配置详解：eval/config.py 逐项拆解

eval/config.py 是 OpenCompass 的 mmengine 风格配置文件，eval.py生成的所有配置都以此为基础。理解它能帮你自定义数据集、调整并发或采样参数。

数据集与汇总组

配置通过read_base()导入六类学术数据集：

• aime2025_datasets：AIME 2025 数学竞赛题（LLM Judge 打分，32 次重复取平均）；
• gpqa_datasets：GPQA 研究生级科学问答（级联评测，4 次重复取平均）；
• hle_datasets：HLE 人类最后考试（LLM Verify 打分）；
• ifeval_datasets：IFEval 指令跟随（Prompt-level strict accuracy）；
• LCBCodeGeneration_dataset：LiveCodeBench 代码生成（pass@1，6 次重复取平均）；
• mmlu_pro_datasets：MMLU-Pro 多学科知识（naive_average）。

默认的datasets行把所有*_datasets变量求和并追加LCBCodeGeneration_dataset；<dataset_replace_tag>标记段正是eval.py按--datasets参数重写的锚点。core_summary_groups与summarizer定义了一个core_average汇总指标，把 IFEval、HLE、AIME2025、GPQA、MMLU-Pro、LCB 六项能力加权汇总为单一均值，方便横向对比不同模型。

待评测模型配置（models）

models = [ dict(abbr=TASK_TAG, key='dummy', openai_api_base=f'{API_SERVER_ADDR}/v1', type=OpenAISDK, path=SERVED_MODEL_PATH, temperature=0.6, meta_template=dict(round=[ dict(role='HUMAN', api_role='HUMAN'), dict(role='BOT', api_role='BOT', generate=True), ], ), query_per_second=10, max_out_len=64000, max_seq_len=65536, batch_size=32, retry=10, pred_postprocessor=dict(type=extract_non_reasoning_content), verbose=False) ]

关键参数解读：

• type=OpenAISDK：以 OpenAI SDK 方式调用 LMDeploy 的/v1接口；
• path=SERVED_MODEL_PATH：由eval.py自动探测填充，通常无需手工填写；
• meta_template：把对话模板映射为HUMAN/BOT角色，generate=True表示 BOT 轮需要模型生成；
• query_per_second=10：对推理服务的 QPS 限速，避免打爆服务；
• max_out_len=64000/max_seq_len=65536：允许极长输出，适配 AIME、LCB 这类长推理链数据集（文档 llm_compressor.md 提到 aime2025 平均输出约 17,635 tokens、LCB 约 14,157 tokens，若输出长度限制过小会严重拉低分数）；
• pred_postprocessor=extract_non_reasoning_content：OpenCompass 提供的后处理器，从模型输出中剥离思考过程（reasoning content），只保留最终答案用于判分。

Judger 配置（judge_cfg）

judge_cfg = dict( abbr='CompassVerifier', type=OpenAISDK, path=JUDGER_MODEL_PATH, key='YOUR_API_KEY', openai_api_base=f'{JUDGER_ADDR}/v1', meta_template=dict(round=[ dict(role='HUMAN', api_role='HUMAN'), dict(role='BOT', api_role='BOT', generate=True), ]), query_per_second=8, batch_size=32, temperature=0.001, max_out_len=8192, max_seq_len=65536, mode='mid', )

Judger 的关键差异点：

• temperature=0.001：打分任务要求确定性，温度压到接近 0，减少随机性；
• mode='mid'：指定 Judger 的验证模式；
• 配置末尾的循环（eval/config.py）会把judge_cfg注入到每个数据集的eval_cfg.evaluator（含llm_evaluator）中——这正是文档中「推理阶段生成的结果提交给 Judger 服务」的配置实现：所有需要 LLM 打分的评测器统一指向同一个 Judger 服务。

推理/评判执行配置（infer / eval runner）

infer = dict( partitioner=dict(type=NumWorkerPartitioner, num_worker=8), runner=dict( type=LocalRunner, max_num_workers=16, retry=0, # 可按需修改 task=dict(type=OpenICLInferTask), ), ) eval = dict( partitioner=dict(type=NaivePartitioner, n=10), runner=dict(type=LocalRunner, max_num_workers=16, task=dict(type=OpenICLEvalTask)), )

• 推理阶段使用NumWorkerPartitioner（按 worker 数切分数据集，num_worker=8），本地LocalRunner最多 16 个并发 worker；
• 评判阶段使用NaivePartitioner（n=10），同样本地并发执行；
• 若机器核数较少，可下调max_num_workers；若推理服务吞吐有限，可同步调低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数据集规模缓存等），适合需要批量回归评测的场景，可作为自定义评测配置的补充参考。

结果目录与复用机制

无论端到端还是逐步评测，OpenCompass 都会在-w指定的工作目录下按{yyyymmdd_hhmmss}时间戳创建结果目录，内含推理输出（predictions/）、评测分数（summary/下的 CSV/JSON）以及 OpenCompass 生成的完整配置快照。借助这一目录结构，eval.py的-r参数实现了以下三类典型用法：

• -r {timestamp}：显式复用指定时间戳的结果，例如分步评测时把推理阶段的结果喂给评判阶段；
• -r（不带值）：复用工作目录下最新一次的结果；
• 不传-r：从头执行，覆盖式产出新结果。

这也意味着：只要推理阶段产出的回答保持不变，你可以随时更换 Judger 模型或调整打分配置重新评判，而不必重复昂贵的推理——这正是两阶段解耦设计的核心价值。

注意事项与排障建议

1. 依赖隔离：LMDeploy 与 OpenCompass 分装两个虚拟环境，eval.py运行在 OpenCompass 环境、服务运行在 LMDeploy 环境，二者通过 HTTP 解耦，互不依赖进程内包版本。
2. 端口与地址可达性：--api-server/--judger-server填写的 IP 必须能被运行eval.py的机器访问；eval.py会先调用/v1/models探测模型名，若该请求失败会直接报Failed to get model name ...，此时应先排查服务是否就绪、端口是否开放。
3. 数据集自动下载：若HF_DATASETS_CACHE/COMPASS_DATA_CACHE路径下没有数据集，OpenCompass 会自动从 HuggingFace 下载，请保证网络连通与磁盘空间；评测前可先跑一次--mode config生成配置并检查数据集导入是否成功。
4. 长输出数据集与 max_out_len：AIME2025、LCB 等数据集输出可达上万 token，不要调小max_out_len（默认 64000），否则模型回答被截断会显著低估真实能力。
5. Judger 显存规划：CompassVerifier-32B建议按--tp 2及以上配置部署，并确保--session-len与配置中max_seq_len=65536匹配；若显存紧张，可考虑分步评测，先完成推理再启动 Judger。
6. 任务名一致性：分步评测时，推理与评判阶段的task_name、-w目录必须完全一致，-r填推理阶段的时间戳目录名，否则 OpenCompass 无法找到待评判的预测结果。

评测完成后，结合 supported_models.md 确认模型支持情况，并可将 量化精度评测 等文档中介绍的评测方法复用——同一套eval.py流程同样适用于量化模型、长上下文模型的精度对比实验。

赞分享

• 人工智能
• 大模型
• 模型推理服务
• 推理引擎
• 本地部署
• 模型量化

【免费下载链接】lmdeploy

LMDeploy is a toolkit for compressing, deploying, and serving LLMs.

项目地址：https://gitcode.com/gh_mirrors/lm/lmdeploy

点击查看免费下载

相关推荐

• LMDeploy 集成 OpenCompass 模型评测实战指南：端到端学术评测流程与源码级解析

  LMDeploy 集成 OpenCompass 模型评测实战指南：端到端学术评测流程与源码级解析 本篇技术指南聚焦于 LMDeploy 与 OpenCompas

  人工智能大模型模型推理服务推理引擎本地部署模型量化

• AIMLInterviews 目标检测指南：两阶段与单阶段检测器原理、架构对比与 mAP 评估体系详解

  AIMLInterviews 目标检测指南：两阶段与单阶段检测器原理、架构对比与 mAP 评估体系详解 本指南是 AIMLInterviews 项目 ML 系统

  示例工程教程人工智能

• XTuner LLaVA 全流程实战指南：从两阶段训练到模型转换、对话测试与多模态评测

  XTuner LLaVA 全流程实战指南：从两阶段训练到模型转换、对话测试与多模态评测 本指南以 XTuner 仓库中 LLaVA 全流程文档 https://

  大模型模型微调

上一篇：终极防护：如何用Fail2Ban抵御日志伪造攻击

下一篇：LocalAI深度指南：开源AI引擎的架构解析与生产部署实践