lmms-eval
统一评测100+基准任务,覆盖图文音视频四大模态的LMM评测框架
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
统一评测100+基准任务,覆盖图文音视频四大模态的LMM评测框架
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象一下:医院里有一台神奇的体检机,只要把人放进去,它就能同时测视力(看图)、测听力(音频)、测理解力(文字),甚至能分析你的思维逻辑(视频理解)。而不同医院的体检报告单格式还完全统一,医生之间可以直接对比——这就是 LMMs-Eval 正在做的事。
多模态大模型(Large Multimodal Models,简称 LMM)正在席卷 AI 领域。这类模型不仅能读文字,还能"看"图片、"听"音频、"理解"视频。GPT-4V、Gemini、Qwen2-VL、LLaVA……每隔几个月就有新一代模型问世。
然而,当研究团队想要评估"谁更强"时,问题就来了。
同一个模型,同一个基准测试,两个团队跑出来的结果可能相差好几个百分点。Benchmark 太多太杂——MME、MMbench、Video-MMMU、MMBench……每个都有自己的数据格式、评分标准和代码实现。更令人头疼的是,音频、视频、图片三种模态的评估工具各玩各的,根本没法横向比较。
LMMs-Eval 就是在这种混乱中诞生的。2024年3月,EvolvingLMMs-Lab 发布了第一个版本,目标只有一个:打造一个统一、可靠、高效的多模态大模型评测框架。
图1:LMMs-Eval 统一评测框架示意图
打个比方你就明白了。
在没有 LMMs-Eval 之前,评估一个多模态模型就像让同一个病人去三家不同的医院体检。每家医院的体检项目、评分标准、甚至正常值范围都不一样——A 医院的血压计用 kPa,B 医院用 mmHg,C 医院干脆不测血压,只测心率。你拿到三份报告,根本没法比较哪个更健康。
LMMs-Eval 相当于建立了一个国家标准化体检中心:所有模型来这儿都得用同一套题目(100+ 标准化基准测试),所有打分标准统一(支持置信区间、聚类标准误差、配对比较),所有模态一站式测完(文本/图像/音频/视频),过程透明可复现(确定性流水线,同样的输入永远产出同样的结果)。
这就是为什么 LMMs-Eval 敢说"Trustworthy"——不是因为它测试更严格,而是因为它可复现。
LMMs-Eval 目前支持超过 100 个评测任务,横跨四大模态:
框架内置了 30+ 主流多模态模型的适配器,包括:
适配方式非常优雅——只需在命令行指定模型名称和预训练路径,框架自动处理模型加载、批处理和推理逻辑。
图2:LMMs-Eval TUI 交互界面,模型选择面板
上手门槛极低。一个最简单的评测只需要几行命令:
# 克隆 + 安装(推荐用 uv)
git clone https://github.com/EvolvingLMMs-Lab/lmms-eval.git
cd lmms-eval && uv pip install -e ".[all]"
# 运行评测(Qwen2.5-VL 在 MME 基准,8条样本快速验证)
python -m lmms_eval \
--model qwen2_5_vl \
--model_args pretrained=Qwen/Qwen2.5-VL-3B-Instruct \
--tasks mme \
--batch_size 1 \
--limit 8
如果正常输出指标分数,说明环境就绪。这比大多数 ML 工具的"Hello World"还要简洁。
评测大规模模型时,最大的瓶颈往往不是 GPU 计算,而是数据 I/O。一个 1 小时的视频,解码可能需要几分钟。LMMs-Eval 在 v0.7 版本做了重大优化:
传统评测的问题在于:给你一个准确率数字,你不知道这个数字有多可信。同样的模型多跑几次,分数可能波动 0.5-2%。
LMMs-Eval 内置了置信区间(CI)和配对 t 检验:不仅告诉你"分数是多少",还告诉你"这个分数的可信区间是多大"以及"和另一个模型比,差异是否统计显著"。
这个功能看似学术,但对团队决策至关重要——如果你花三个月改进了模型,准确率从 85.2% 提升到 85.4%,这个"提升"是真的还是随机波动?LMMs-Eval 能给你答案。
图3:TUI 模型选择界面,支持 30+ 主流多模态模型
从代码结构来看,LMMs-Eval 采用了经典的流水线架构,各模块职责清晰:
lmms_eval/models/:模型适配层。通过 registry_v2.py 统一注册,支持 chat 风格 API 和 simple 风格推理lmms_eval/tasks/:任务定义层。每个任务是一个独立目录,包含数据集配置、评测模板和后处理逻辑lmms_eval/evaluator.py:核心调度引擎。负责模型调用、结果收集和指标计算lmms_eval/loggers/:结果输出层。输出标准 JSONL 格式日志,方便后续分析lmms_eval/tui/:交互界面(基于 FastAPI + Uvicorn 的 TUI)lmms_eval/api/:HTTP Eval Server,支持远程调用(v0.6+)lmms_eval/filters/:结果后处理过滤器技术栈以 Python 为主,核心依赖包括:PyTorch、Transformers、Accelerate、PEFT(深度学习),timm(图像)、PyAV/TorchCodec(视频)、librosa(音频)的多模态处理,sacrebleu、scikit-learn、pycocoevalcap 的评测指标,以及 FastAPI、Uvicorn 的 HTTP 服务。
LMMs-Eval 不提供 Docker 镜像,也没有 docker-compose 支持,部署方式为纯源码安装。推荐使用 uv 包管理器(Astral 出品,比 pip 快 10-100 倍),因为项目在 pyproject.toml 中明确声明使用 uv 来保证一致的依赖版本。
安装方面,[all] 可选依赖组包含了所有功能(音视频/MCP/搜索等),但实际上只需要安装你需要的子集:lmms_eval[server] 启用 HTTP Eval Server,lmms_eval[audio] 启用音频评测,lmms_eval[video] 启用视频评测(需要 TorchCodec)。
硬件要求方面,小模型(3B)可在单卡 8GB 显存运行,但完整基准测试通常需要 16-24GB+ 显存。评测任务的数据集(尤其是视频)可能需要数十 GB 磁盘空间。
1. 依赖管理复杂:[all] 依赖组包含 30+ 个包,涵盖音视频处理、指标计算、Web 服务等多个领域。首次安装可能遇到依赖冲突(尤其是 torchcodec、decord 等视频库的版本约束)。
2. 数据集下载门槛:评测依赖 Hugging Face datasets,部分大型数据集(如视频基准)下载需要 hf_transfer 加速,且需要足够的磁盘空间。
3. GPU 资源要求高:虽然小模型可以在 8GB 显存运行,但完整评测(尤其是视频理解任务)通常需要 24GB+ 显存。对于研究团队而言,GPU 资源的可用性是主要瓶颈。
4. 评测基准的时效性:AI 领域变化快,新的多模态能力(如 agentic 规划)不断涌现,评测基准的更新速度能否跟上模型进化的节奏,是一个持续挑战。
Benchmarks 决定下一个时代的模型。
这不是夸张——回顾 AI 历史,从 ImageNet 催生 CNN 革命,到 GLUE/SuperGLUE 催生 BERT 时代,再到 MMLU 推动 LLM 推理能力,评测基准一直在塑造 AI 研究的方向。
LMMs-Eval 的价值,在于它让多模态模型的评测变得可信、透明、可比较。当所有团队都在同一个"体检中心"用同一套标准进行评测时:研究者能真正判断"我的改进是否有意义";工程师能准确选择"哪个模型最适合我的场景";投资人能清晰看到"这个团队的技术实力"。
从数据来看,LMMs-Eval 自 2024 年 3 月发布以来,已迭代到 v0.7 版本,获得了 4100+ Stars 和 596 个 Fork,被多个研究团队和高校课程采纳作为标准评测工具。GitHub Issues 的解决率很高(Closed 远超 Open),说明社区活跃且维护积极。
LMMs-Eval 是一个专注于大型多模态模型统一评测的 Python 框架。它解决了多模态 AI 评测领域的三个核心痛点:碎片化(100+ 任务、4 大模态、30+ 模型,一个框架搞定)、不可复现(确定性流水线 + 统计置信度,让结果可信)、效率低下(视频 I/O 优化 + 异步 Serving,让评测不再成为研发瓶颈)。
它不是那种"一键部署"的简单工具——需要 Python 3.10+、GPU、和一定的依赖管理经验。但对于真正需要做多模态模型评测的研究者和工程师而言,它几乎是目前最完善的选择。
如果你正在评估多模态大模型,或者需要为团队建立模型评测标准,LMMs-Eval 值得放进你的工具箱。