Numpy在HPC节点多CPU环境下矩阵点积性能停滞原因咨询

我在单节点最多128核的HPC机器上测试Numpy的性能，当前执行的是两个N×N矩阵的点积运算，逐步增加请求的CPU核数。下方图表展示了不同N值（标签代表数组大小N²）对应CPU核数的性能情况，想知道为什么CPU核数达到约20个后性能就停滞了？

环境配置 #

>>> import numpy as np
>>> np.show_config()
blas_mkl_info:
  NOT AVAILABLE
blis_info:
  NOT AVAILABLE
openblas_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
blas_opt_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
lapack_mkl_info:
  NOT AVAILABLE
openblas_lapack_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]
lapack_opt_info:
    libraries = ['openblas', 'openblas']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None)]

性能图表 #

从环境配置和性能数据来看，导致性能在20核后停滞的核心原因有三点：

• OpenBLAS线程数限制：当前使用的OpenBLAS默认可能只绑定了单个NUMA域的核心（HPC机器的一个NUMA域通常包含20左右核心），它不会自动跨NUMA域调度线程，因此无法利用更多核心。另外，OpenBLAS的编译参数或运行时配置可能被限制了最大线程数。
• 内存带宽瓶颈：矩阵点积在核心数超过阈值后，会从计算密集型转为内存密集型。当20个核心已经占满了内存带宽，再多的核心也无法获取更多数据，性能自然无法提升。从图表能看到，小矩阵（如1024²）的性能停滞更早，这正是小矩阵内存访问开销占比更高的表现。
• 并行效率衰减：并行计算的效率不会随核心数线性增长，当核心数超过最优值后，线程同步、数据拆分合并的开销会急剧增加，抵消了多核心的收益。20核恰好是当前矩阵规模下OpenBLAS并行效率的最优阈值。

• 手动设置OpenBLAS线程数：通过环境变量export OPENBLAS_NUM_THREADS=128强制指定线程数，重新测试看性能是否能继续提升。
• 检查NUMA配置：用numactl --hardware查看机器的NUMA域分布，尝试用numactl --interleave=all优化内存跨域访问，或者绑定进程到多个NUMA域。
• 更换BLAS后端：如果OpenBLAS的并行优化不足，可以切换到MKL后端，它对多核心HPC机器的适配性更好，能更充分利用128核的资源。

内容的提问来源于stack exchange，提问作者Sketos