大模型评测 Benchmark：关键指标与选型方法
大模型评测 Benchmark 是用数据集和评测维度量化模型能力的方法。本文梳理推理结果打分、吞吐量、延迟与 token 级指标，帮助研发和业务团队完成模型对比与选型。
什么是大模型评测 Benchmark？
大模型评测 Benchmark 是用评测数据、评测任务和评测维度，对大语言模型的能力或运行表现进行量化观察的方法。它通常会对模型推理结果进行打分和对比，帮助研发、算法和业务团队判断不同模型在同一类任务下的表现差异。
在实际使用中，Benchmark 不只是一个排行榜分数，更像一套可复用的参照条件：把不同模型放到相同或可比的数据集、任务和指标下，观察它们的输出质量、运行效率和适用边界。
常见关注点可以分为两类：
| 评测类型 | 主要关注点 | 典型用途 |
|---|---|---|
| 能力评测 | 模型推理结果的打分、对比和任务表现 | 模型选型、能力验证、业务适配 |
| 性能 Benchmark | 吞吐量、延迟、token 级指标等运行表现 | 上线前压测、容量规划、高并发服务评估 |
要点： 大模型评测 Benchmark 的核心不是“看一个分数”，而是在明确任务和数据条件后，用可对比的指标支持模型选择和迭代决策。
为什么评测不能只看单一分数？
模型评测的价值在于通过多个评测维度对推理结果进行打分和对比，而不是得到一个孤立的高低分。不同业务目标对模型能力和推理性能的权重不同，单一分数很难覆盖真实使用中的全部需求。
例如，一个模型在通用问答中表现较好，并不必然意味着它在业务知识问答、代码生成或高并发在线服务中同样合适。反过来，一个推理速度较快的模型，也需要结合输出质量判断是否能满足任务要求。
| 评测目标 | 应重点关注 | 适用决策 |
|---|---|---|
| 比较模型回答质量 | 推理结果打分、评测维度对比、结果摘要 | 判断哪个模型更适合具体任务 |
| 验证通用能力 | 公开数据集结果、统一任务条件下的对比 | 初步筛选候选模型 |
| 验证业务适配 | 自定义数据集结果、业务样本表现 | 判断是否满足内部场景需求 |
| 评估上线表现 | 吞吐量、延迟、token 级指标 | 估算服务容量和用户等待时间 |
| 辅助模型迭代 | 多轮评测记录、基线对比 | 判断新版本是否相对改进 |
因此，合理的评测结论通常应包含评测目标、数据集来源、评测方式、关键指标和适用范围，而不是只保留一个最终分数。
评测数据集主要来自哪里？
评测数据决定了 Benchmark 回答的是什么问题。常见数据来源包括公开数据集和自定义数据集，两者适合解决的问题不同。
公开数据集评测
公开数据集适合观察模型在通用任务上的能力表现。部分模型评测能力支持使用公开数据集评测大语言模型能力，常见示例包括 MMLU、C-Eval 等。
公开数据集的优势是更容易形成横向参照，适合在模型选型早期进行初筛。但公开数据集不一定覆盖特定行业、企业内部知识或私有业务流程，因此不宜直接替代业务场景验证。
自定义数据集评测
自定义数据集评测适合验证模型在业务语料、内部任务或特定应用场景中的实际效果。例如，团队可以围绕自己的问答样本、生成任务或流程型任务构建评测数据，用来观察模型是否符合真实使用要求。
自定义数据集的关键价值在于贴近实际问题。它更适合回答“这个模型能不能解决我的任务”，而不是只回答“这个模型在通用数据集上排名如何”。
| 数据集来源 | 适合回答的问题 | 使用建议 |
|---|---|---|
| 公开数据集 | 模型在通用任务上的相对表现如何 | 用于初筛、横向比较和建立参照 |
| 自定义数据集 | 模型是否适合具体业务场景 | 用于业务验收、上线前验证和持续复测 |
要点： 同一模型在不同数据集上的表现可能反映不同能力。做选型时，应记录数据集来源、任务范围和评测条件，避免把某一类结果泛化到所有场景。
能力评测应关注推理结果的打分与对比
能力评测主要围绕模型输出结果展开。平台型模型评测能力通常会通过评测维度对模型推理结果进行打分和对比，帮助用户选择更合适的模型。
基线评测
基线评测适合快速建立参照。它通常用于在相对固定的任务、数据或评测维度下观察模型表现，帮助团队形成初步比较。
基线评测的价值在于降低比较成本：当候选模型较多时，先用统一方式评测，可以快速筛出需要深入验证的模型。
自定义评测
自定义评测适合围绕实际任务验证模型表现。部分模型评测能力支持自定义评测方式，也支持使用自定义数据集评测大语言模型能力。
当团队已经明确业务目标时，自定义评测更能反映真实场景。例如，客服问答、企业知识库问答、摘要生成或流程辅助类任务，都可以通过贴近业务的数据和维度进行评估。
可以用下面的表格记录一次能力评测结果：
| 模型 | 数据集来源 | 评测方式 | 评测维度 | 结果摘要 | 适用结论 |
|---|---|---|---|---|---|
| 模型 A | 公开数据集 | 基线评测 | 通用任务表现 | 在统一任务下表现较好 | 可进入下一轮业务验证 |
| 模型 B | 自定义数据集 | 自定义评测 | 业务任务表现 | 对特定样本响应更符合预期 | 更适合当前业务场景 |
| 模型 C | 自定义数据集 | 自定义评测 | 业务任务表现 | 部分任务需要补充优化 | 暂不作为首选 |
表格中的“结果摘要”和“适用结论”应基于实际评测输出填写，不应脱离数据集和任务范围做泛化判断。
性能 Benchmark 应关注吞吐量、延迟和 token 级指标
性能类 Benchmark 主要衡量模型推理服务的实际运行表现，关注点不是回答内容本身好不好，而是服务在运行过程中是否足够高效、稳定和可承载。
在 LLM 性能基准测试中，吞吐量、延迟和 token 级指标是常见关注对象。这些指标有助于识别与模型效率相关的问题，尤其适合上线前压测、服务容量规划和高并发场景评估。
吞吐量
吞吐量用于观察单位时间内系统能够处理多少请求或生成多少内容。它适合回答“在一定资源条件下，服务能承载多大处理量”这类问题。
当应用面向大量用户、批量任务或高频调用时，吞吐量是容量规划中的重要观察指标。
延迟
延迟用于观察用户或调用方从发起请求到获得响应所需要等待的时间。它适合回答“用户体验是否足够流畅”这类问题。
对对话式应用、实时问答和交互式工具而言，延迟往往会直接影响使用体验。
token 级指标
token 级指标用于进一步观察生成过程中的效率表现。由于大语言模型的输入和输出通常以 token 为单位进行处理，token 级观察有助于更细粒度地分析推理过程。
| 性能指标 | 主要含义 | 更适合的场景 |
|---|---|---|
| 吞吐量 | 单位时间处理能力 | 高并发服务、批量处理、容量规划 |
| 延迟 | 单次请求等待时间 | 在线问答、对话交互、实时辅助 |
| token 级指标 | 生成过程中的细粒度效率表现 | 推理效率分析、性能调优、压测对比 |
要点： 能力评测回答“模型答得怎么样”，性能 Benchmark 回答“模型服务跑得怎么样”。上线选型通常需要同时看这两类结果。
常见评测工具和平台能力
大模型评测可以通过托管式平台能力完成，也可以使用评测工具在自有环境中组织测试。不同方式适合的团队阶段和控制粒度不同。
托管式模型评测能力
托管式模型评测能力通常用于评估模型能力，支持对模型推理结果进行打分和对比，并辅助选择更合适的模型。部分平台能力支持自定义评测和基线评测，也支持使用自定义数据集和公开数据集评测大语言模型能力。
这种方式适合希望降低评测工程成本、快速比较候选模型的团队。
EvalScope
EvalScope 是 ModelScope 的官方评测工具，可作为大模型评测工具使用。它支持添加自己的评测基准，并可与社区成员分享，适合需要扩展评测任务或沉淀自有 Benchmark 的场景。
性能测试工具
在大模型推理性能测试实践中，可涉及 EvalScope、LLMPerf 和 vLLM Benchmark 等工具。它们更适合围绕推理性能、服务效率和压测场景开展验证。
| 工具或能力类型 | 适合用途 | 选择思路 |
|---|---|---|
| 托管式模型评测 | 快速评估模型能力、打分和对比 | 适合快速选型和减少评测工程投入 |
| EvalScope | 组织评测任务、添加自有评测基准 | 适合需要扩展 Benchmark 的团队 |
| LLMPerf / vLLM Benchmark | 大模型推理性能测试 | 适合上线前压测和性能对比 |
如何从评测目标反推指标选择？
选择模型评测指标时，建议从目标倒推，而不是先套用固定指标清单。因为不同目标对应的数据集、评测方式和指标重点并不相同。
第一步：明确评测目标
先判断评测是为了模型选型、业务验收、上线压测，还是持续迭代。目标不同，指标重点也不同。
如果目标是模型选型，应关注不同模型在相同或可比条件下的打分和对比。如果目标是上线服务，应把吞吐量、延迟和 token 级指标纳入重点观察范围。
第二步：确定数据集来源
根据目标选择公开数据集、自定义数据集，或两者结合。公开数据集适合形成通用参照，自定义数据集适合验证业务适配。
第三步：选择能力维度或性能指标
能力评测应围绕推理结果打分和对比；性能 Benchmark 应围绕吞吐量、延迟和 token 级指标观察运行效率。
第四步：在可比条件下进行模型对比
模型对比应尽量保持数据集、任务范围和评测方式一致。只有评测条件可比，得出的结果才更适合用于选型决策。
| 目标 | 数据集建议 | 指标重点 | 输出结论 |
|---|---|---|---|
| 通用能力初筛 | 公开数据集 | 推理结果打分和模型对比 | 候选模型优先级 |
| 业务场景验证 | 自定义数据集 | 业务任务表现和结果摘要 | 是否适合当前场景 |
| 上线前压测 | 贴近线上请求的数据或任务 | 吞吐量、延迟、token 级指标 | 容量与性能风险判断 |
| 模型版本迭代 | 固定或可复用评测集 | 与基线结果对比 | 新版本是否值得替换 |
用评测结果辅助模型选型
模型选型应综合能力评测结果和性能 Benchmark 结果，避免只根据单项指标做结论。一个更稳妥的选型过程，通常需要同时回答两类问题：模型是否能完成任务，以及模型服务是否能满足运行要求。
建议在每次评测后保留以下信息：
- 评测目标：本次评测是为了初筛、业务验证、上线压测还是版本迭代。
- 数据集来源：使用公开数据集、自定义数据集，或两者结合。
- 评测方式：使用基线评测、自定义评测，还是性能 Benchmark。
- 关键指标：能力维度结果、吞吐量、延迟、token 级指标等。
- 对比结论：哪些模型进入下一轮验证，哪些模型暂不适合当前场景。
- 复测条件：后续模型版本变化、数据集变化或部署条件变化时，是否能够复用同一套评测方法。
选型前可以使用下面的检查清单：
- [ ] 是否明确了评测目标，而不是只追求一个总分？
- [ ] 数据集是否匹配当前任务或业务场景？
- [ ] 是否区分了公开数据集结果和自定义数据集结果？
- [ ] 是否有基线参照，便于判断模型间差异？
- [ ] 是否同时覆盖能力评测和性能 Benchmark？
- [ ] 是否记录了吞吐量、延迟和 token 级指标等上线相关信息？
- [ ] 评测结论是否说明了适用范围，而不是泛化为所有场景？
- [ ] 评测流程和结果是否可复用，便于后续模型迭代？
要点： 好的 Benchmark 不是一次性打分表，而是一套可复测、可对比、能支撑决策的评估流程。对模型选型而言，评测条件和结论边界与分数本身同样重要。
原文链接：https://www.qianwenai.com/discover/llm-benchmark-metrics
