大语言模型性能评测：MMLU-Pro基准测试解析

ONE实验室

1. 大语言模型性能评测：MMLU-Pro计算机科学基准测试深度解析

最近我在更新MMLU-Pro计算机科学基准测试结果时，加入了三个Phi-4变体（微软官方权重、Unsloth修复的HF和GGUF版本）、Qwen2 VL 72B Instruct和Aya Expanse 32B的新数据。作为一位长期从事AI模型评测的研究者，我想分享这次测试的详细过程和发现，希望能为同行提供有价值的参考。

MMLU-Pro是一个全面评估大语言模型能力的基准测试，覆盖计算机科学、数学、物理、化学等多个学科。与它的前身MMLU相比，MMLU-Pro将每道题的选择项从4个增加到10个，大幅降低了随机猜对的概率。同时，它更注重复杂推理能力而非单纯的事实记忆。在我的测试中，我专注于计算机科学类别的410道题目，因为这与我的日常工作环境密切相关，而且考虑到本地模型在消费级硬件上运行的时间限制——即使是较大模型的单次测试也需要数小时。

提示：所有测试都至少运行两次以确保结果一致性，这比通常只报告单次得分的基准测试更能反映模型的真实能力。

2. 新测试模型表现分析

2.1 Phi-4系列模型对比

Phi-4作为微软推出的14B参数模型，在这次测试中展示了几个有趣的特点：

不同实现版本的差异：Unsloth修复的Transformers实现与原版在基准测试中表现接近，GGUF版本略微领先（67.8% vs 66.1%）。虽然差异不大，但考虑到GGUF格式通常用于量化模型，这个结果值得关注。
温度参数的影响：当温度设为0时，模型输出稳定但重复；设为1时则变得不可预测。这提示我们在实际应用中需要谨慎调整这个参数。
德语能力提升：相比前代，Phi-4的德语翻译质量有明显进步，虽然偶尔会出现过于直译的问题，但已能满足大多数使用场景。
审查规避：通过基本的提示工程技巧就能完全规避内容过滤机制，这在使用时需要特别注意。

2.2 Qwen2 VL 72B Instruct的表现

这款72B参数的模型得分相对较低（62.2%），可能因为它基于较旧的Qwen2架构而非更先进的2.5版本。我期待未来能看到基于Qwen2.5架构的VL 72B模型，相信会有更好的表现。

2.3 Aya Expanse 32B的多语言优势

虽然它在本次测试中得分最低（51.46%），但需要说明的是我只收录了得分超过50%的模型。Aya Expanse的主要优势在于支持23种语言，当您需要多语言能力且没有更好选择时，它仍然是一个可靠的选项。

3. 测试方法与执行细节

3.1 基准测试设计原理

MMLU-Pro通过以下几个方面确保评估的全面性和准确性：

题目设计：每道题有10个选项，随机猜对的概率从MMLU的25%降至10%，大幅提高了测试的区分度。
评分标准：不仅看最终答案是否正确，还会记录模型在回答过程中的确定性程度。当模型无法明确选择答案时，系统会随机猜测并记录这种情况的发生频率和准确率。
测试范围：虽然完整测试包含多个学科，但我专注于计算机科学类别的410道题目，因为：
- 与我的专业领域高度相关
- 在有限的计算资源下更易管理
- 可以更快获得结果，避免因测试时间过长导致模型过时

3.2 测试环境配置

所有测试都在以下硬件环境下进行：

GPU：NVIDIA RTX 6000（24GB显存）
内存：128GB DDR4
存储：2TB NVMe SSD
软件栈：
- TabbyAPI v1.2.3（用于本地模型部署）
- Hugging Face Transformers v4.40.0
- llama.cpp v0.10.0（用于GGUF格式模型）

注意：对于超过24GB显存的大型模型，使用了双RTX 3090配置（共48GB显存），通过NVLink连接。

3.3 测试执行流程

模型准备：
- 下载官方模型权重或社区优化版本
- 根据模型格式（HF/EXL2/GGUF）进行相应配置
- 加载到GPU并预热
测试执行：
- 每个模型至少运行两次完整测试
- 记录每次运行的准确率、响应时间和资源使用情况
- 对结果差异较大的模型增加第三次测试
数据收集：
- 记录每道题的模型回答
- 统计随机猜测的发生率和准确率
- 测量token处理速度（prompt tokens/s和completion tokens/s）
结果分析：
- 计算平均准确率和标准差
- 分析模型在不同类型题目上的表现
- 比较不同参数配置下的性能差异

4. 详细测试结果与排名

4.1 顶级模型表现

以下是表现最好的几个模型及其关键指标：

模型名称	参数规模	格式	平均准确率	最佳单次得分	Token处理速度(prompt)	Token处理速度(completion)
Claude 3.5 Sonnet	-	API	82.52%	82.93%	362.78 tk/s	50.90 tk/s
Gemini 1.5 Pro	-	API	80.90%	81.71%	346.82 tk/s	41.87 tk/s
QwQ-32B-Preview	32B	EXL2	79.15%	79.27%	88.58 tk/s	44.22 tk/s
Athene-V2-Chat	72B	EXL2	77.64%	79.51%	82.11 tk/s	17.81 tk/s

4.2 中端模型对比

中端梯队中有几个值得关注的模型：

Qwen2.5-72B-Instruct：平均77.93%的准确率，表现稳定但资源消耗较大（需要双GPU）
DeepSeek-V3：虽然参数高达671B，但准确率(78.05%)与更小的模型相当，API延迟较低
GPT-4o：最新版本表现优异(78.05%)，但存在明显的版本间波动

4.3 量化模型的影响

测试了多种量化配置的模型，发现：

EXL2格式：4.65bpw量化对72B模型的影响较小（性能下降约2-3%），但显存占用减少40%
GGUF格式：在Phi-4上表现优于原版HF格式，可能是由于优化的推理实现
混合精度：FP8对Llama-3.1-405B效果良好，保持75.85%准确率的同时减少内存需求

5. 实用建议与经验分享

5.1 模型选择策略

根据测试结果，我建议：

追求最高准确率：选择Claude 3.5 Sonnet或Gemini 1.5 Pro的API服务
本地部署需求：
- 高端硬件：QwQ-32B-Preview或Athene-V2-Chat
- 中等硬件：Phi-4 GGUF版本（平衡性能与资源需求）
多语言支持：虽然Aya Expanse得分较低，但在非英语任务中仍可能是最佳选择

5.2 性能优化技巧

温度参数：大多数模型在0.3-0.7范围内表现最佳，过高会导致输出不稳定
批处理：使用TabbyAPI时，适当增加batch size可以提高吞吐量（但要注意显存限制）
量化策略：
- 对话应用：4.65bpw EXL2提供良好的精度/性能平衡
- 开发测试：8.0bpw EXL2保留更多原始性能
缓存利用：启用KV缓存可减少重复计算，特别适合长对话场景

5.3 常见问题排查

准确率波动：
- 原因：温度设置过高、提示词不一致
- 解决：固定随机种子、明确输出格式要求
显存不足：
- 尝试更低bit的量化版本
- 启用gradient checkpointing
- 使用CPU卸载部分计算
响应速度慢：
- 检查token生成速度（应>20tk/s）
- 确认没有其他进程占用GPU
- 考虑使用推测解码加速

6. 测试中的意外发现

模型大小与性能的非线性关系：670B参数的DeepSeek-V3表现与70B级别的模型相当，说明参数数量不是决定性能的唯一因素。
量化惊喜：某些模型在适度量化后表现反而略有提升，可能与优化后的推理实现有关。
API稳定性：商业API在不同时间的表现存在显著差异（如GPT-4o的版本波动），而本地部署的模型更加稳定。
语言能力差异：虽然测试聚焦英文，但观察到多语言模型在非英语任务上的表现往往与其英文得分不直接相关。

这次全面的基准测试耗时超过103小时，涵盖了当前最受关注的多种大语言模型。结果显示，模型选择需要综合考虑任务需求、硬件条件和性能期望，没有放之四海而皆准的最佳选项。对于我的日常工作场景，QwQ-32B-Preview和Phi-4 GGUF版本成为了新的常用选择，它们在性能与资源消耗间取得了良好平衡。