人工智能大模型模型推理服务推理引擎本地部署模型量化【免费下载链接】lmdeployLMDeploy 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 --depth1 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-optionsmodel_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-countKV cache 容量等。从 lmdeploy/cli/serve.py 的api_server实现可见该命令最终会构建PytorchEngineConfig或TurbomindEngineConfig并启动 OpenAI 兼容服务默认端口 23333未指定--server-port时生效。2. 部署评测模型Judgerlmdeploy serve api_server opencompass/CompassVerifier-32B --server-port 20000 --tp 2 --session-len 65536Judger 是负责打分的模型端口建议与推理服务区分此处为20000。--tp 2CompassVerifier-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-serverJudger 服务地址必填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 步部署评测模型Judgerlmdeploy 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的constlatest语义。eval.py 工作原理从参数到 OpenCompass 命令理解 eval/eval.py 的源码有助于排障和自定义。它本质上是一个「配置生成器 命令封装器」执行链路如下解析命令行参数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即使用配置中的全部数据集。读取模板配置read_config()读取脚本同目录下的 eval/config.py 全文作为配置模板。动态注入变量用字符串替换完成四类注入——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与真实部署模型一致。生成配置或直接执行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_datasetsAIME 2025 数学竞赛题LLM Judge 打分32 次重复取平均gpqa_datasetsGPQA 研究生级科学问答级联评测4 次重复取平均hle_datasetsHLE 人类最后考试LLM Verify 打分ifeval_datasetsIFEval 指令跟随Prompt-level strict accuracyLCBCodeGeneration_datasetLiveCodeBench 代码生成pass16 次重复取平均mmlu_pro_datasetsMMLU-Pro 多学科知识naive_average。默认的datasets行把所有*_datasets变量求和并追加LCBCodeGeneration_datasetdataset_replace_tag标记段正是eval.py按--datasets参数重写的锚点。core_summary_groups与summarizer定义了一个core_average汇总指标把 IFEval、HLE、AIME2025、GPQA、MMLU-Pro、LCB 六项能力加权汇总为单一均值方便横向对比不同模型。待评测模型配置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) ]关键参数解读typeOpenAISDK以 OpenAI SDK 方式调用 LMDeploy 的/v1接口pathSERVED_MODEL_PATH由eval.py自动探测填充通常无需手工填写meta_template把对话模板映射为HUMAN/BOT角色generateTrue表示 BOT 轮需要模型生成query_per_second10对推理服务的 QPS 限速避免打爆服务max_out_len64000/max_seq_len65536允许极长输出适配 AIME、LCB 这类长推理链数据集文档 llm_compressor.md 提到 aime2025 平均输出约 17,635 tokens、LCB 约 14,157 tokens若输出长度限制过小会严重拉低分数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 的关键差异点temperature0.001打分任务要求确定性温度压到接近 0减少随机性modemid指定 Judger 的验证模式配置末尾的循环eval/config.py会把judge_cfg注入到每个数据集的eval_cfg.evaluator含llm_evaluator中——这正是文档中「推理阶段生成的结果提交给 Judger 服务」的配置实现所有需要 LLM 打分的评测器统一指向同一个 Judger 服务。推理/评判执行配置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 数切分数据集num_worker8本地LocalRunner最多 16 个并发 worker评判阶段使用NaivePartitionern10同样本地并发执行若机器核数较少可下调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 模型或调整打分配置重新评判而不必重复昂贵的推理——这正是两阶段解耦设计的核心价值。注意事项与排障建议依赖隔离LMDeploy 与 OpenCompass 分装两个虚拟环境eval.py运行在 OpenCompass 环境、服务运行在 LMDeploy 环境二者通过 HTTP 解耦互不依赖进程内包版本。端口与地址可达性--api-server/--judger-server填写的 IP 必须能被运行eval.py的机器访问eval.py会先调用/v1/models探测模型名若该请求失败会直接报Failed to get model name ...此时应先排查服务是否就绪、端口是否开放。数据集自动下载若HF_DATASETS_CACHE/COMPASS_DATA_CACHE路径下没有数据集OpenCompass 会自动从 HuggingFace 下载请保证网络连通与磁盘空间评测前可先跑一次--mode config生成配置并检查数据集导入是否成功。长输出数据集与 max_out_lenAIME2025、LCB 等数据集输出可达上万 token不要调小max_out_len默认 64000否则模型回答被截断会显著低估真实能力。Judger 显存规划CompassVerifier-32B建议按--tp 2及以上配置部署并确保--session-len与配置中max_seq_len65536匹配若显存紧张可考虑分步评测先完成推理再启动 Judger。任务名一致性分步评测时推理与评判阶段的task_name、-w目录必须完全一致-r填推理阶段的时间戳目录名否则 OpenCompass 无法找到待评判的预测结果。评测完成后结合 supported_models.md 确认模型支持情况并可将 量化精度评测 等文档中介绍的评测方法复用——同一套eval.py流程同样适用于量化模型、长上下文模型的精度对比实验。赞分享人工智能大模型模型推理服务推理引擎本地部署模型量化【免费下载链接】lmdeployLMDeploy 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引擎的架构解析与生产部署实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考