Open-R1项目中Qwen2.5模型SFT训练性能下降问题分析

在Open-R1项目中使用Qwen2.5-1.5B-Instruct模型进行监督微调(SFT)时，开发者遇到了一个典型问题：训练损失值正常下降，但最终模型在MATH-500评估集上的表现却显著低于预期。本文将深入分析这一现象背后的技术原因，并提供解决方案。

问题现象

开发者使用HuggingFaceH4/Bespoke-Stratos-17k数据集对Qwen2.5-1.5B-Instruct模型进行微调，训练过程中损失函数值正常下降，表明模型确实在学习。然而，在MATH-500评估集上的表现却出现了异常：

• 原始Qwen2.5-1.5B-Instruct模型的准确率为43.6%
• 微调后的模型准确率骤降至1.6%-36.6%不等
• 类似问题也出现在AIME24评估集上，准确率从43.6%降至3.33%

根本原因分析

经过技术排查，发现导致性能下降的主要原因包括：

1. 评估提示词问题：早期版本的评估提示词存在缺陷，导致评估结果不准确。项目组已通过#392合并修复了这一问题。

2. 训练配置不当：

   • 使用了不匹配的浮点精度（V100不支持bf16但配置中启用了bf16）
   • 批量大小过小（仅1），远低于推荐的128
   • 学习率设置可能不适合数学推理任务

3. 模型容量限制：1.5B参数规模的模型在数学推理任务上存在固有局限，相比之下7B模型表现明显更好。

4. 评估数据泄露：警告信息显示评估使用了测试数据构建few-shot示例，可能导致评估结果失真。

解决方案与实践建议

针对上述问题，我们建议采取以下改进措施：

1. 硬件配置优化：

   • 确保使用支持bf16的硬件（如A100）
   • 或明确配置为fp16训练
   • 增加批量大小至128（需要8张32GB显存的GPU）

2. 训练参数调整：

   • 采用分阶段学习率策略
   • 增加训练epoch数
   • 启用梯度检查点以节省显存

3. 评估流程规范化：

   • 使用最新修复的评估提示词
   • 确保评估数据独立，避免数据泄露
   • 监控上下文长度，防止自动截断

4. 模型选择策略：

   • 对于数学推理任务，优先考虑7B及以上规模的模型
   • 对小模型设置合理的性能预期

经验总结

这一案例揭示了LLM微调过程中的几个关键点：

1. 训练损失下降不一定代表实际任务性能提升
2. 评估流程的严谨性直接影响结果可信度
3. 硬件配置与训练参数需要精细调校
4. 模型规模与任务复杂度需要匹配

开发者应当建立完整的评估验证流程，在训练过程中监控多个指标，而不仅仅是训练损失。同时，理解模型容量与任务需求的关系，选择合适的模型规模进行微调。