OpenCompass API模型评测中的batch size问题解析与解决方案

问题背景

在使用OpenCompass评测框架对API模型进行评测时，用户发现batch size参数未能生效，系统始终以单条请求的方式进行推理。这一问题直接影响了评测效率，特别是在处理大规模数据集时尤为明显。

技术分析

问题根源

通过代码分析发现，在调用API模型的generate函数时，输入的inputs列表长度始终为1。这表明系统没有按照预期的batch size进行批量处理，而是逐个处理请求。尽管代码中使用了ThreadPoolExecutor来实现多线程并发，但由于输入数据未被正确分批次，导致并发机制未能充分发挥作用。

关键发现

1. 在OpenAI API的generate函数中，打印inputs长度始终显示为1
2. 多线程执行器ThreadPoolExecutor虽然存在，但实际并发量受限
3. 评测过程中的GPU报错与API模型的预期行为不符

解决方案

调整max_num_workers参数

通过增加runner配置中的max_num_workers参数值，可以提升并发处理能力。这个参数控制着工作线程的数量，适当增大该值能够提高API请求的并发度。

评测阶段的GPU需求

值得注意的是，即使用API模型进行推理，在评测阶段仍需要GPU资源。这是因为：

1. 结果比对阶段需要加载transformers模型来比较预测结果与标准答案
2. 评估过程涉及复杂的计算任务，GPU可显著提升效率
3. 当前架构不支持完全使用API模型完成整个评测流程

对于确实无法使用GPU的环境，可以通过修改评测配置中的相关参数来强制使用CPU，但需要注意这将显著降低评测速度。

最佳实践建议

1. 合理设置batch size和max_num_workers参数，平衡资源使用和评测效率
2. 确保评测环境具备足够的GPU资源，即使使用API模型进行推理
3. 对于大规模评测任务，建议分阶段进行并监控资源使用情况
4. 关注OpenCompass的版本更新，及时获取性能优化和功能改进

总结

OpenCompass框架在API模型评测中的batch size问题主要源于配置参数和资源分配。通过正确配置并发参数和确保必要的硬件资源，可以显著提升评测效率。理解框架在不同阶段对资源的需求特点，有助于用户更合理地规划评测任务和资源配置。