OpenCompass 评测平台：跑通大模型评测的工程化路线
OpenCompass is an LLM evaluation platform, supporting a wide range of models (Llama3, Mistral, InternLM2,GPT-4,LLaMa2, Qwen,GLM, Claude, etc) over 100+ datasets.
秒懂
- 它是什么？
- OpenCompass 是一个面向大语言模型的评测平台，支持百余个数据集与多种模型接入方式。本文基于其公开文档与仓库结构，梳理它的工作机制、运行方式与适用边界。
- 适合谁用？
- 建议需要批量、可复现评测多组模型的研究团队或模型选型部门采用 OpenCompass。它适合你已经有明确的评测集清单，并且愿意投入时间学习其配置体系的情况。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
评测不是跑脚本，是工程问题
大模型评测看起来简单，把题目喂给模型，比对答案就行。实际做起来完全不是这样。不同数据集有各自的 prompt 模板，有的要选择题格式，有的要生成式回答，有的需要多轮对话。模型的接入方式也五花八门，本地权重、API 服务、不同厂商的 SDK 各有差异。OpenCompass 想解决的就是这一层混乱。它把数据集、模型、推理器、评测器拆成可组合的模块，用户通过配置文件声明要跑什么，平台负责调度和执行。这个定位决定了它的目标用户不是随便试试的爱好者，而是需要反复跑多组模型对比的工程师或研究者。从仓库结构看，它不是一个单一脚本，而是一套完整的评测流水线框架。
从配置到报告的流水线机制
OpenCompass 的核心思路是配置驱动。用户需要声明用哪个数据集、哪个模型、用什么样的推理方式和评测指标。根据 README 中的说明，0.4.0 版本做了一次大的结构调整，把原本分散在 configs/datasets、configs/models、configs/summarizers 下的 AMOTIC 配置文件统一收进了 opencompass 包内部。这意味着配置引用方式发生了破坏性变更，旧脚本需要更新路径。评测执行层面，平台引入了并发推理机制，可以同时跑多个推理任务，并配有 evaluation watcher 来监控已完成的任务，触发后续评测。对于重复内容问题，仓库里提供了 tools/analyze_repeat.py 这类分析工具，专门检测模型输出中的循环和重复文本。整个流程设计明显偏向大规模、多任务的场景，而不是单次快速验证。
模型接入的宽度与深度
从 README 的更新日志能看出，OpenCompass 在模型接入上投入很大。它支持 HuggingFace 生态的本地模型，也支持 GPT-4、Claude、Gemini 这类闭源 API。2026 年 7 月的更新显示，平台新增了 OpenAI Responses API 和 LiteLLM AI Gateway 的支持，同时把 Gemini 和 Anthropic 的集成更新到了最新 SDK。这意味着用户可以通过统一的配置接口使用不同厂商的模型，而不必为每家写单独的调用代码。此外，平台还集成了 VLMEvalKit，支持多模态数据集的加载和评测。对于需要对比多个闭源模型输出质量的团队来说，这种统一的接入层确实省事。但要注意，接入宽度大意味着每个模型的适配逻辑都需要维护，API 版本升级时平台必须跟着更新，这是持续的成本。
评测模板的细节控制
一个容易被忽视但实际很关键的能力是 RawPromptTemplate。根据文档说明，这个模板允许把原始 benchmark 的 prompt 和结构化对话直接传给模型，不做任何额外的格式转换。这解决了一个真实痛点：很多评测框架会在 prompt 外面套自己的格式模板，导致模型接收到的内容与 benchmark 原始设计不一致，评测结果因此失真。RawPromptTemplate 支持 API 模型和 ChatML 数据集，还可以在模型侧追加额外的 prompt 内容。对于追求评测结果严谨性的团队，这个功能值得仔细研究。它意味着你可以在最大程度上还原 benchmark 的原始评测条件，减少框架本身引入的偏差。反过来，这也要求使用者理解 benchmark 的原始格式，否则无法判断默认模板和 RawPromptTemplate 之间的差异是否影响结果。
上手路径与配置学习成本
OpenCompass 的安装和运行方式在官方文档中有详细说明，但 README 本身没有给出完整的快速开始命令。从仓库结构推断，典型用法是先通过 pip 或源码安装 opencompass，然后编写或选择现成的配置文件，最后通过命令行工具启动评测。仓库提供了大量示例，比如 examples/eval_mmbench_vlmevalkit.py 和 examples/eval_scireasoner.py，这些示例文件是理解配置格式的最佳入口。对于新用户，最大的门槛不是安装，而是理解数据集配置、模型配置和评测器配置三者之间的组合关系。0.4.0 的配置路径迁移说明这个体系还在演进，配置结构并未完全稳定。如果你只是偶尔评测一次，学习这套配置体系的成本可能高于直接用 HuggingFace 自带的 evaluate 库。
评测编排的进阶能力
OpenCompass 不只是单次评测工具。2025 年 4 月引入的 CascadeEvaluator 支持多个评测器按顺序执行，形成自定义的评测流水线。2026 年 3 月的更新加入了并发推理和评测监控机制，可以协调多个推理任务的执行节奏。这些功能指向一个明确的使用场景：大规模的模型迭代评测。当你有多个模型版本、多个数据集需要交叉评测时，手动逐个跑是不现实的。OpenCompass 试图把这种矩阵式的评测任务变成可声明的配置，然后由平台自动调度。这种设计思路与持续集成类似，把评测从一次性动作变成可重复执行的流程。但复杂度也随之上升，调试并发任务之间的依赖关系并不轻松，尤其是涉及到推理结果缓存和任务失败重试的时候。
与同类工具的差异和选型考量
大模型评测领域最常被拿来比较的工具是 EleutherAI 的 lm-evaluation-harness。两者的核心差异在于设计哲学。lm-evaluation-harness 更轻量，聚焦于把 HuggingFace 模型跑在标准 benchmark 上，结构简单，上手快，适合快速验证。OpenCompass 则走的是重平台路线，它提供的并发推理、评测编排、多模态支持、LLM-as-judge 等能力，在 lm-evaluation-harness 中要么没有，要么需要自己拼装。如果你只需要跑 MMLU 和 GSM8K 两个数据集，lm-evaluation-harness 可能半小时内就能跑通。但如果你需要定期评测几十个数据集、对比多个闭源模型、还要把评测流程固化到 CI 里，OpenCompass 的编排能力就体现出价值。选型的核心问题是你的评测需求有多复杂，复杂到需要平台，还是简单到只需要工具。
维护状态与许可证约束
从仓库状态看，OpenCompass 的维护相当活跃。最近一次推送在 2026 年 9 月，0.5.4 版本发布于 2026 年 8 月，版本迭代节奏大约是两到三个月一个 minor release。项目采用 Apache-2.0 许可证，这意味着你可以自由使用、修改和分发，包括商用场景，只要保留版权声明并注明修改内容。对于企业用户来说，这个许可证比 GPL 类许可证友好得多，不存在将内部修改开源回馈的义务。但需要注意，项目的活跃开发也意味着接口变动频繁，0.4.0 的配置路径迁移就是例子。如果你在内部深度定制了配置体系，每次大版本升级都需要评估迁移成本。建议在采用前查看 CHANGELOG，确认你依赖的配置项是否在近期版本中有破坏性变更。
编辑结论
建议需要批量、可复现评测多组模型的研究团队或模型选型部门采用 OpenCompass。它适合你已经有明确的评测集清单，并且愿意投入时间学习其配置体系的情况。不适合只需要快速跑一两个 benchmark 的临时用户，这类需求用 lm-evaluation-harness 或直接调用数据集官方脚本更省事。在正式采用前，先确认三件事：一是你需要的评测集是否在官方支持的百余个数据集内，二是你的模型能否通过 HuggingFace 或 OpenAI 兼容 API 接入，三是确认 0.4.0 版本之后配置路径迁移是否影响你已有的自动化脚本。OpenCompass 的工程化深度是它的护城河，但这份复杂度需要用户用配置时间买单。
社区笔记