开源大模型怎么测、怎么选：可复现的选型流程

一、评测目标与场景

公开榜单的分数来自统一数据集和理想条件。团队部署时面对的是自己的业务数据、硬件、并发模式和合规要求。两者不一致时，榜单分数不能直接用于选型。榜单适合用来筛选候选模型，最终判断要靠自己的测试。

评测开始前，先确定使用场景。不同场景对各维度的权重差别很大：

• 私有化问答：重点看知识准确性、首Token延迟、显存占用，以及数据是否留在内网。
• 安全敏感场景（如内容审核、风控客服）：重点看拒答一致性、对提示注入的抵抗表现，以及日志能否完整审计。
• 通用业务（如文档摘要、信息抽取）：重点看结构化输出的有效率、长文本稳定性和单位请求成本。

每个场景写一句目标，并选出三到四个权重最高的维度。没有权重的维度不进入评分表，避免为了面面俱到而稀释结论。

二、把四类问题改写为可判定的结论

评测要回答四类问题。每一类都要对应一个通过或不通过的结论，写不出判定标准的问题应当删除或改写。

1. 能力边界：在自有测试集上，任务准确率不低于当前方案的基线，下降幅度不超过2个百分点。结构化输出有效率不低于98%。
2. 工程可行性：在目标并发下，P95首Token延迟和P95单Token耗时满足服务等级目标（SLO）。显存峰值不超过显存总量的85%，单位请求成本低于预算。
3. 安全可控性：红队测试在隔离环境中完成，高风险类别的不通过数为零，或者有安全团队审批的例外记录。全部交互日志可以追溯到模型版本和操作时间。
4. 生态可持续性：许可证允许目标用途和分发方式。近十二个月内有版本更新或安全修复记录。问题反馈有公开渠道，响应情况可以查证。

上面的阈值只是起点。业务的SLO、风险偏好和预算不同，阈值也应随之调整，并在评测报告中写明依据。

三、理解架构差异对评测的影响

开源大语言模型通常指权重可公开下载、允许自行部署和微调的模型。按架构划分，常见的有稠密模型和混合专家（MoE）模型。稠密模型在每次推理时激活全部参数。MoE模型在前馈层放置多组专家网络，由路由器为每个token选择少数专家参与计算。

MoE模型带来三类需要单独观测的代价：

• 专家负载不均：统计每层每个专家接收的token数，计算最大值与均值之比。该比值持续偏高时，少数专家成为瓶颈，P99延迟会先于平均延迟恶化。
• 权重常驻显存：所有专家的权重都要留在显存中，显存需求随总参数量增长，而不是随激活参数量增长。测量时要分别记录小批量和大批量下的峰值显存，不能只按激活参数估算。
• 通信开销：多卡部署时，专家并行需要分发token并汇聚结果。用性能分析工具记录通信时间占单步耗时的比例，并发上升时单独报告这一比例。

跨架构比较时，应把稠密模型与MoE模型按相近的单次计算量（激活参数量）或相近的显存预算分组。只比较参数规模，会得出误导性的结论。

四、统一的指标口径

下表给出六个维度的核心指标、口径和参考阈值。阈值需按业务SLO调整。

维度	核心指标	口径定义	样本量建议	参考阈值（需按SLO调整）
功能完整性	功能覆盖率	通过的功能用例数除以总用例数。用例覆盖对话、函数调用、JSON输出和长上下文	每类功能不少于50条	核心功能覆盖率不低于95%
准确性	任务准确率及95%置信区间	与标准答案一致的样本占比。客观题用规则判分，开放题用经校准的评审模型或人工双评	误差约±3个百分点时约700条	不低于基线，下降不超过2个百分点
性能	P95首Token延迟（TTFT）、P95单Token耗时（TPOT）、吞吐	固定输入输出长度分布，预热后统计各并发档位的分位数	每个并发档位P95不少于2000次有效请求，P99不少于10000次	交互场景TTFT P95不超过2秒，TPOT P95不超过80毫秒
稳定性	失败率、超时率、重复运行的结果波动	失败包括HTTP错误、超时和输出截断。统计连续运行期间的占比	连续运行不少于24小时，合计不少于10000次请求	失败率不超过0.5%
安全性	拒答一致性、注入抵抗通过率、敏感信息泄露次数	在隔离环境中，用安全团队批准的用例集统计各高风险类别的通过率	每个高风险类别不少于200条	高风险类别不通过数为零，或有审批记录的例外
生态可持续性	许可证条款核对结果、近十二个月发布次数、安全公告响应时长	逐项核对许可证条款，统计公开发布记录和问题响应记录	不适用	许可证条款全部经法务确认

样本量依据如下。比例类指标按 n ≈ z²·p(1−p)/