SciPy优化器性能下降问题分析与解决方案

问题背景

在SciPy 1.15.0版本发布后，用户在使用scipy.optimize.minimize函数时遇到了显著的性能下降问题。特别是在使用L-BFGS-B优化器时，函数评估时间在某些环境下出现了4-10倍的性能退化。这一问题主要出现在GitHub Actions的4核Ubuntu运行器和Google Colab环境中，而在高核数CPU（如M1 Pro Macbook或32核Intel Xeon服务器）上则无法复现。

问题根源分析

经过深入调查，发现性能下降的根本原因在于SciPy 1.15.0中对L-BFGS-B优化器的重大重构：

1. 代码重构：从原始的Fortran 77实现迁移到了C语言实现，并采用了更规范的LAPACK调用方式
2. 线程管理：新版本开始使用OpenBLAS的多线程能力，而旧版本使用的是单线程实现
3. 环境差异：在低核数环境中，线程竞争和上下文切换的开销超过了并行计算带来的收益

技术细节

性能对比数据

在Google Colab环境中进行的基准测试显示：

• SciPy 1.15.1：

  • 在minimize中102次函数评估耗时13.593秒
  • 直接循环100次评估耗时9.061秒

• SciPy 1.14.1：

  • 在minimize中101次函数评估耗时8.923秒
  • 直接循环100次评估耗时8.911秒

影响因素

1. BLAS实现：使用MKL而非OpenBLAS时问题消失
2. 线程设置：设置环境变量OPENBLAS_NUM_THREADS=1可解决问题
3. 优化器类型：仅影响L-BFGS-B（使用梯度信息时），SLSQP不受影响

解决方案

推荐方案：使用threadpoolctl

对于需要在代码中局部控制BLAS线程数的场景，推荐使用threadpoolctl库：

from threadpoolctl import threadpool_limits

with threadpool_limits(limits=1, user_api='blas'):
    res = minimize(
        fun=f_and_grad,
        x0=x0,
        method="L-BFGS-B",
        jac=True,
        bounds=bounds,
        options={"maxfun": 100, "ftol": 0},
    )

这种方法不会影响PyTorch等使用OpenMP/MKL的库，具有较好的隔离性。

其他可选方案

1. 全局环境变量：设置OPENBLAS_NUM_THREADS=1，但会影响整个程序
2. 切换BLAS实现：使用conda安装MKL版本的SciPy
3. 降级版本：回退到SciPy 1.14.1版本

最佳实践建议

1. 在低核数环境中使用L-BFGS-B优化器时，应当考虑线程控制
2. 对于性能敏感的优化问题，建议进行基准测试比较不同BLAS实现的性能
3. 在CI/CD环境中，明确指定BLAS线程数可以保证测试结果的一致性
4. 对于混合使用多种数值计算库的应用，应当注意各库的线程管理策略

总结

SciPy 1.15.0对L-BFGS-B优化器的重构虽然带来了代码质量和数值稳定性的提升，但在某些环境下可能引发性能问题。通过理解底层BLAS库的线程管理机制，并采用适当的线程控制策略，开发者可以在享受新版本优势的同时避免性能下降问题。