1. 这次部署要解决的真实问题选型不能靠“感觉”大概一个月前我们准备上一个智能客服与知识库问答项目算法组内部先吵了一架有人说Llama-3.1-8B生态好、社区资料多有人说Qwen2.5中文效果更稳还有人说干脆上14B再量化一下省卡又提速。大家各拿几篇官方博客当论据谁也说服不了谁。最后老板一句话终结了讨论“别在这感觉来感觉去给我拿评测数据说话。”于是我接了个活从零部署一套OpenCompass大模型评测平台把候选模型和量化后的模型都拉出来遛一遛用同一套数据集、同一套参数、同一个随机种子跑出可横向对比的分数再用这些分数反推选型决策。先说结论这套平台部署本身没多难真正花时间的是评测任务设计、量化模型评估和结果解读。这篇文章把整个过程的思路、配置、命令和坑都记录下来给正准备干同样事情的人一个参照。文章里会涉及三类核心内容OpenCompass平台的搭建步骤、量化模型int8/AWQ等的能力衰减评估、以及怎么用评测结果做模型选型。这里先澄清一个容易混淆的点一说到“量化”搞股票的人会想到量化指标做部署的人会想到INT8、AWQ、GPTQ这些模型压缩手段而标题里“量化模型能力选型”其实是双关——既要用量化指标评测模型能力也会评估量化后的模型能不能打两者我都会展开讲。适合看这篇内容的读者主要是这几类算法工程师或者AI应用开发正在做开源模型选型但苦于没有统一对比口径想在公司内网环境搭一套可复用的评测流程或者已经跑通了OpenCompass但数据集怎么挑、参数怎么配、量化模型的损失怎么评估这些细节还比较模糊。2. 为什么选了OpenCompass而不是自己写脚本或别的框架在确定OpenCompass之前我其实先试了另外两条路一条是用lm-evaluation-harness直接跑另一条是team里有人提的“自己写个评测脚本调API问一圈就行”。这两个方案各有各的问题也正是这些问题把我推向了OpenCompass。2.1 自建评测脚本为什么被我否了自己写脚本看起来最简单拿一套测试题逐条问模型比对答案算个准确率。但实际操作起来全是细节坑模型的输出要规范化处理比如“答案是B”和“B”必须算同一个结果数学题的答案格式稍有不同就算错不同模型对相同system prompt的敏感度差异很大评测过程中一旦某个样本超时或者崩溃中断恢复又得自己实现。这些活加起来看起来是几天的工作量实际上一两周都未必能做得严谨。更麻烦的是这类脚本的可信度在团队内部会受到挑战——你今天这么算明天他那么算结果没法复现。2.2 OpenCompass核心优势在哪OpenCompass是上海AI实验室开源的大模型评测框架它把上面这些杂活基本都包了。模型加载、数据集处理、inference、答案抽取、指标计算、结果汇总整条pipeline是闭环的配置一次之后换模型、换数据集都很快。尤其对我这个场景有三个关键能力支持多种模型接入方式。HuggingFace模型直接传路径就行模型量化后的本地目录也能识别这对我后面评测GPTQ、AWQ模型很重要。数据集非常丰富。CEval、MMLU、CMMLU、GSM8K、HumanEval这些主流的都在内置列表里不需要自己找数据源。评测任务可配置、可复现。所有参数写在yaml里后续任何人跑同一份配置都能得到同样的结果这在团队协作里价值很大。2.3 和lm-evaluation-harness的对比lm-evaluation-harness本身是个很优秀的工具但它偏“评测脚本集合”一次性跑多个模型多个任务时要自己写不少胶水代码。而且它对中文数据集的支持没有OpenCompass那么顺手CEval这类中文数据集还是OpenCompass里更成熟。OpenCompass面向的场景更偏“评测平台化”官方也维护了适配大量模型的配置文件省了我很多事。当然OpenCompass也不是没有缺点。它的文档更新速度快版本之间的配置结构有过变化网上很多教程还停留在老版本照着做会报错。这个我在部署阶段就踩了几个坑后面会专门写一节。3. 从零部署环境、安装、模型与数据集准备的关键动作部署环境是我们的一台开发机双路32核CPU、4张RTX 4090 24G、系统是Ubuntu 20.04、CUDA是12.1。下面的步骤在实际操作中每一步都有可以跳过但最好别跳的细节我按执行顺序拆开写。3.1 创建独立的Python环境OpenCompass依赖的包不少强烈建议用conda单独建环境千万不要图省事直接装到base环境里。我这里用了Python 3.10兼容性和包支持都比较稳。conda create -n opencompass python3.10 -y conda activate opencompass创建完环境后先确认几个基础信息避免后面装完发现CUDA版本不对白折腾python --version nvidia-smi nvcc --versionNVIDIA驱动和CUDA runtime版本不一致是很常见的坑只要nvidia-smi里看到的CUDA版本不低于12.0通常都没问题因为PyTorch一般自带CUDA runtime。3.2 安装OpenCompass和额外依赖安装主体用pip直接从官方源拉pip install -U opencompass如果服务器网络下载慢可以用国内镜像加速。安装完成后先把测评所用的基础依赖也一并装好否则后面跑数据集时会缺包pip install opencompass[metrics] pip install jieba rapidfuzz[metrics]这个扩展包含了计算评测指标所需的依赖比如rouge、bleu相关的库。我用的是OpenCompass 0.3.x版本如果你用的是更新的版本建议装完后先看一下官方文档里有没有特殊的依赖说明。装完立刻验证一下opencompass --help能正常打印出帮助信息说明主体安装成功。3.3 模型文件准备本地目录优于在线下载这是部署阶段最容易翻车的地方。默认情况下OpenCompass配置里写HuggingFace模型名比如Qwen/Qwen2.5-7B-Instruct也能跑但需要从HF下载模型权重网络稍不稳定就会中断断点续传也不友好。我直接把所有候选模型下载到本地目录评测配置里传本地路径。下载模型我分了两个来源HuggingFace模型配置了HF镜像环境变量下载速度会明显改善。ModelScope上有的模型直接用modelscope的Python SDK下载速度通常也不错。export HF_ENDPOINThttps://hf-mirror.com huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /data/models/Qwen2.5-7B-Instruct注意--local-dir后面这个目录参数本地路径一定不要带特殊字符否则后续OpenCompass解析路径时偶尔会出问题。每个模型我额外保留了config.json和tokenizer_config.json后面做量化评测时量化模型目录还要引用原模型的tokenizer这个结构后面细说。3.4 数据集准备想省事又不想出错的办法OpenCompass内置数据集列表很全官方文档里有完整清单。我这里先选了几个最核心的CEval中文综合、CMMLU中文知识、MMLU英文综合、GSM8K数学推理。部署时不需要手动下载全部数据集OpenCompass在跑评测任务时会自动加载。但实际问题在于自动下载同样依赖网络的连通性尤其CEval这类数据集挂在HuggingFace上时容易卡在下载阶段。稳妥方案是先手动把数据集下载到本地缓存目录再用环境变量指定缓存路径。export HF_HOME/data/hf_cache export HF_DATASETS_CACHE/data/hf_cache/datasets第一次跑评测之前可以先用一个小数据集试跑比如只加载CEval验证集确认数据集都能正常从缓存读取再正式跑大任务这个习惯帮我避免过很多次“跑了一小时才发现数据集没下载完”的尴尬。4. 评测任务设计数据集怎么选、参数怎么配才不是“瞎跑分”框架搭起来了下一步是设计评测任务。这个阶段是最容易“花了很多算力跑出一堆没用数字”的环节。我按“选数据集→配模型参数→配任务参数”三层来展开。4.1 数据集的选择逻辑不能只看英文榜单很多人的第一反应是“官方榜单跑什么我就跑什么”比如MMLU、GSM8K全套上。但如果你做的是中文业务场景重点跑英文榜单会严重误导选型。我这次选数据集的逻辑是这样CEval和CMMLU覆盖中文知识和中文推理是判断模型中文能力的第一道筛子。这两个数据集官方还区分了验证集和测试集业务数据求稳时先跑验证集最后定稿再用测试集。MMLU保留它是为了看模型的英文综合能力和世界知识覆盖度毕竟通用基座的语言能力不能只看中文。GSM8K数学推理能力在客服、金融、教育类场景里很重要跑它来判断模型在链条推理上的表现。再加一组自建业务FAQ评测集直接用我们线上知识库里抽了300条问答转成OpenCompass支持的格式在CEval之外额外看模型对真实业务语料的适配度。这里要插一句自建评测集是整个环节里价值被严重低估的一部分。公开数据集再好和你业务场景总是隔着一层。300条FAQ规模不大但已经能暴露出模型在领域术语、多轮表达上的明显差距。后面选型报告里决策占比最高的恰恰是这300条业务数据的结果。4.2 评测模型的配置YAML里每个字段都有讲究OpenCompass用YAML描述一个评测任务核心是models和datasets两块。以Qwen2.5-7B-Instruct为例我的配置是这样的models: - type: HuggingFaceCausalLM abbr: qwen2.5-7b-instruct path: /data/models/Qwen2.5-7B-Instruct model_kwargs: device_map: auto trust_remote_code: true tokenizer_kwargs: trust_remote_code: true max_out_len: 1024 batch_size: 8几个字段的实际含义和使用经验abbr这个名称会出现在最终报告里建议带版本和精度避免后面量化模型一多就分不清。device_map: auto在多卡环境下让模型自动分布显存24G卡跑7B模型单卡足够14B模型可以自动占用两张卡。max_out_len最大生成长度。这个参数不是越大越好几项评测里最长的输出也不过几百token设置到1024已经够用设置太大反而拉低并行效率。batch_size取决于显存和任务。7B模型在4090上设8很稳14B模型建议降到2到4否则会出现单卡OOM。4.3 任务级参数并发、分片与采样数跑评测的时候--max-num-worker这个参数控制并行任务数。它不是越大越好因为每个worker都会加载一份模型到显存我4张卡的经验是设3个worker比较稳。如果模型本身已经靠多卡承载worker设多了反而OOM。还有一个常见配置是采样数量。部分数据集比较大比如MMLU有上万条全量跑会拖很长时间。稳妥做法是先跑默认全量如果只是想快速对比可以在模型配置里临时限制样本数量但最终决策必须以全量结果为准。4.4 评测命令与产物配置完成后运行python run.py configs/eval_my_models.py也可以把多个模型写在一个配置文件里OpenCompass会自动逐模型跑。跑完后的产物在outputs/目录下包含每个模型的summary结果和详细日志。我看结果的习惯是先看summary表格里的总体准确率再单独看业务FAQ的细分结果最后翻一下子任务得分有没有异常波动。如果某个数据集得分和其他模型差距大得离谱先别急着下结论去日志里查一下是不是输入数据处理环节出了问题。5. 量化模型评测int8/4bit掉点多少、速度提升多少、能不能用部署和评测任务跑通之后接下来要解决的是比较现实的问题我们看上了Qwen2.5-14B的能力但14B全精度在4090上跑推理比较吃力单卡显存放不下多卡并行又增加部署成本。能不能用量化模型量化的代价究竟是多少这是标题里“量化模型能力选型”的核心部分。5.1 量化方案选型为什么AWQ优先级高于GPTQ和bitsandbytes目前主流的量化方案大致分三类GPTQ、AWQ、bitsandbytes。我一开始三个都试了最后主测AWQ。GPTQ基于二阶海森矩阵做权重误差补偿量化后模型尺寸小推理速度也比较快但中文生成任务上掉点相对明显。AWQ基于激活值分布保留重要权重通道对低比特量化更友好实测EasyLLM在中文任务上的掉点比GPTQ略小。bitsandbytes的4bit NF4适合快速加载大模型做实验但因为反量化开销高部署时推理速度反而不占优我只把它当baseline看。如果业务是英文代码生成或函数级任务GPTQ也完全可用如果是中文内容生成、知识问答这类激活值分布更依赖上下文的场景AWQ掉点更可控。这个结论是基于我这次的量化评测记录不同模型和量化版本会有差异但方向可以参考。另外要控制一个变量同款模型的所有量化版本必须用同一个评测配置跑否则量化对比没有意义。5.2 量化评测的准备校准集与评测集必须分离量化本身有个前置步骤用一批校准数据确定量化参数这个和评测完全不是一个数据源。这里专门提醒一下不要拿评测集做量化校准这是会“泄露未来信息”的典型错误。如果量化模型用评测集校准过模型的量化参数已经偷偷记住了评测集的分布分数虚高等上了线立刻现原形。我的做法是从业务FAQ里划出200条做量化校准剩下的300条做评测。这样量化过程和评测完全隔离测出来的掉点才是真实部署会遇到的。5.3 实测数据量化后的功效和损失我这次重点评测了这几个模型得到一份原始记录数据整理如下。不同版本的模型和评测环境会有些微差异表中数据当作参考即可。模型精度CEval5-shotCMMLU5-shotGSM8K8-shot业务FAQ300条推理显存Qwen2.5-7B-InstructFP1674.675.281.382.7~15GBQwen2.5-7B-InstructAWQ Int472.573.477.980.0~6GBQwen2.5-14B-InstructFP1687.187.987.489.3多卡Qwen2.5-14B-InstructAWQ Int485.286.084.187.5~9GBLlama-3.1-8B-InstructFP1655.354.872.462.1~16GBLlama-3.1-8B-InstructAWQ Int453.953.170.260.4~7GB几个关键结论第一Llama-3.1-8B在中英文综合能力上被Qwen同尺寸明显拉开尤其中文业务FAQ差了20多个点在中文场景下基本出局这印证了只盯着英文榜单选模型的危险性。第二Qwen2.5-14B AWQ Int4的CEval只掉了2个点左右GSM8K掉了3.3个点推理显存从多卡降到单卡9GB整体收益非常可观。对一个客服知识库场景来说90%的场景用AWQ Int4版本就够而且单卡能部署成本直接少一半。第三量化对英文数学推理类任务GSM8K的影响比中文知识类任务更明显说明推理链路对权重精度更敏感。如果业务是教育辅导或数学题解答量化时就要更谨慎一些。5.4 通量测试光看显存不够还得看速度评测平台只给我准确率和显存还不行选型报告里得回答“线上服务并发多少时延迟多少”。量化模型因为权重变小内存带宽瓶颈下的decode速度提升也很可观。我在单张4090上用同样长度输入各跑500轮记录到的decode吞吐大概是这样同样仅供参考Qwen2.5-14B FP1623 tokens/sQwen2.5-14B AWQ Int441 tokens/s输入侧速度提升更明显量化后prefill阶段的计算量大幅下降首token延迟也缩短了大约35%。这些数据对最终选型的说服力有时候比准确率还强因为老板最关心的就是“单卡能不能扛住”。6. 从评测报告到选型结论我的决策框架和报告长什么样跑完一堆分数之后最重要的问题来了怎么从评测数据推导出“选哪个模型做底座”这一步如果纯靠人眼看分数前面所有严谨的工作就废了。6.1 设计加权评分表让业务权重替你做决定不同业务的“好模型”定义完全不同。我的做法是提前做个加权评分表把业务最关心的能力映射到评测指标上能力维度对应评测任务客服知识库场景权重代码助手场景权重中文理解与知识CEval、CMMLU、业务FAQ0.350.15指令遵从与内容生成业务FAQ开放式问答0.250.15数学与逻辑推理GSM8K0.20.2英文综合能力MMLU0.10.2部署性价比量化后显存/吞吐0.10.3按这个权重去算Qwen2.5-14B AWQ Int4在各候选者里的综合分最高很快收敛。但我要强调权重表的意义不是算出唯一正确答案而是逼着团队在评测之前就统一“什么能力更重要”避免跑完数据后每个组都挑对自己有利的分数说事。6.2 定性bad case分析量化模型丢了什么能力光有总体分数还不够我把业务FAQ里FP16答对而AWQ Int4答错的case全部抽出来人工看了一遍。结果发现一个规律掉分主要集中在两类问题一是需要精读长文本里多个条件才能推理的题二是领域术语密集的回答。这两类恰好是客服接待中最核心的复杂咨询场景。这个定性结论比“掉2个点”更关键。它告诉我们如果业务里大量场景是短问短答量化版完全没问题如果线上经常出现长文档问答和复杂条件筛选那要么保留FP16小模型做复杂查询路由要么直接接受quantized模型在复杂题上的降级。这个结论最后写进了选型报告的需求备注里。6.3 选型报告的呈现方式报告我分了三层综合评分表把所有模型的加权总分放一张表一目了然。关键结论段用两三句话说清楚“我推荐哪个为什么”。风险与备注段写清楚量化掉点集中在什么类型的问题上以及业务侧需要做什么配合。报告里我没有堆所有评测日志而是把完整log压缩包附在附录方便组内复现校验。要吹一下的是这份报告发出去之后之前吵得最凶的同事也没话说因为他自己用同一份配置复跑了一次数据完全一致。7. 实战中踩过的坑完整排查链路与补救方案这节把我在整个过程中踩过、并且花了不少时间才绕出去的坑集中写一下每条都带上排查思路和最终修复方案。7.1 数据集下载反复失败卡在hf转移现象首次跑CEval时任务启动十几分钟还在“downloading dataset”然后直接报连接超时。这个问题排查下来根因就是网络不稳定。不是代码问题也不是配置问题。修复方案是前面提过的两步先把HF_HOME和HF_DATASETS_CACHE指到本地大目录再在非评测时段用一个独立的Python脚本把数据集预先拉取到缓存。之后跑评测时OpenCompass检测到缓存已经有数据集就不再走下载流程了。7.2 “tokenizer_parallelism”冲突导致进程崩溃现象评测任务跑到第二个模型时偶尔会直接报tokenizer_parallelism ... conflict错误。这个坑在网上很多帖子都提到过本质是多个worker加载tokenizer时并行度参数冲突。排查链路先看日志里的模型加载栈发现不是显存不足而是tokenizer初始化阶段的线程冲突。解决办法也简单在运行命令前设置环境变量export TOKENIZERS_PARALLELISMfalse实测这个变量对评测速度几乎没有影响但进程稳定性明显提升。7.3 多worker并行OOM不知道是谁占的显存现象设了4个worker跑14B模型刚启动就OOM但nvidia-smi看每张卡利用率都很低。这里需要注意OOM不一定发生在GPU侧也可能发生在CPU内存的模型加载阶段。OpenCompass多进程并发时每个worker都有一份模型驻留4个14B模型同时向显存搬运很快耗尽。排查步骤先看系统free内存再看每张卡的显存占用确认是叠加导致的。修复方案有两个一是把worker数降到2二是给不同模型配置指定GPU设备避免俩模型抢同一张卡。实测后者更稳。7.4 结果和官方榜单不一致慌了现象我跑出的Qwen2.5-7B的CEval分数比官方公布的少了将近2个点差点以为部署有问题。后来查了一遍原因是官方榜单用的模型版本、prompt模板、采样参数和我的配置不完全一致。OpenCompass的评测结果可复现但复现的是“你自己的配置”不是“官方的配置”。解决办法是如果想对齐官方数据需要把模型版本锁死并参考官方评测文档里的参数设置。如果只是内部横向对比那就保证所有模型都用同一份配置跑分数自然具备可比性。7.5 工具类破率最快的问题模型路径带空格或中文字符这个坑很低级但很常见。有个同事把模型放在/data/我的模型/试 验/目录下结果每次启动任务都报路径找不到。排查到最后发现是路径里的空格和中文导致的OpenCompass在拼接路径时不会做特殊转义。所有模型和数据集的本地目录最好都改成纯英文小写加下划线的命名规范省掉一堆不必要的麻烦。7.6 评测跑到一半挂掉的兜底方案长时间评测任务最怕的是中途断掉。OpenCompass的日志是持续落盘的任务中断后已经跑完的部分结果保存在outputs目录里。我后来养成了习惯跑大任务之前先启动一个tmux会话所有评测都在tmux里跑断连也不影响进程。同时定期检查summary日志如果发现某个数据集的eval已经完成但整个任务卡住可以直接跳过错过的数据集不重跑已完成部分。最后再分享一点个人体会评测平台本身不难搭难的是评测任务设计和结果解读。很多团队搭好平台后第一件事就是急着跑一堆模型、存一堆分数然后发现分数并不能直接转化为选型结论。真正有价值的是在搭建和跑分之前花时间想清楚你的业务到底需要模型的什么能力你打算用哪些数据集和权重来量化这些能力量化后的模型如果掉点掉的是哪些能力点从我这次的经历看最得意的一个决策是提前设计了加权评分表并人工分析了量化掉分case。这两个动作让大家在拿到报告时不是在争论“我觉得哪个模型好”而是在讨论“这个能力权重对不对”和“这个掉点场景我们能不能接受”。当讨论话题变成了这样选型就不再是技术博弈而是一个相对理性的业务决策了。另外如果你们团队以后会频繁评测新模型建议把这套配置、脚本、数据集缓存、报告模板沉淀成一套内部文档。OpenCompass这类平台可复现性很强我第一次搭用了大概两天后面再来一台新机器照着文档半小时就能复现整个环境。评测这件事跑一次不难难的是跑完之后整个团队能高效地用这些结果做决策。把这套流程沉淀下来后续每次新模型发布、每次新业务需要选型都能少走很多弯路。