原生依赖噩梦：Python 中的 BLAS、LAPACK 和 OpenMP

对于绝大多数 Python 开发人员来说，安装像 NumPy 或 scikit-learn 这样的库就像运行 pip install 一样简单。然而，在这些无缝安装的表面之下，隐藏着一个复杂且往往脆弱的原生依赖网络。PyData 技术栈的核心是 BLAS、LAPACK 和 OpenMP——这些库为线性代数和并行处理提供了原始的计算能力。

由于这些库是用低级语言（C、C++、Fortran 和汇编）编写的，并且针对特定硬件进行了高度优化，它们为 Python 的打包基础设施带来了独特的挑战。目前管理这些依赖项的挣扎揭示了特定语言的包管理器与系统级软件现实之间的深层结构性紧张关系。

理解核心组件

要理解打包冲突，首先必须了解这些库究竟在做什么：

  • BLAS (Basic Linear Algebra Subprograms): 这些是向量和矩阵运算的基础例程。
  • LAPACK (Linear Algebra PACKage): 构建在 BLAS 之上，LAPACK 为求解线性方程组、特征值问题和奇异值分解提供了更复杂的例程。
  • OpenMP (Open Multi-Processing): 一个允许共享内存并行编程的 API，使代码能够有效地利用多个 CPU 核心。

虽然存在参考实现（例如 Netlib 仓库中的实现），但这些库的实际应用依赖于高度优化的版本，如 Intel MKL、OpenBLAS、Apple Accelerate 和 AMD AOCL。这些优化版本提供的性能提升可达 10 倍到 100 倍，使其在科学计算和深度学习中不可或缺。

当前现状：Vendoring（内置化）与碎片化

由于 PyPI (the Python Package Index) 并非设计用于处理系统级原生依赖，许多主要项目不得不采取 "vendoring"（内置化）策略——即直接将依赖项的编译二进制文件包含在 Python wheel 中。

目前，NumPy 和 SciPy 都内置了 OpenBLAS。然而，它们通常使用不同的版本或不同的构建配置（例如，NumPy 使用 64 位 ILP64，而 SciPy 使用 32 位）。这导致了一个碎片化的环境，其中单个 Python 安装可能会包含多个相同库的副本。

其他库遵循不同的模式：

  • PyTorch 在大多数平台上静态链接 MKL，并内置了自己的 OpenMP 实现 (libiomp 或 libgomp)。
  • TensorFlow 使用 Eigen，这是一个仅头文件的 C++ 库，它简化了分发，但仍然依赖 OpenMP 进行并行化。
  • scikit-learn 内置了 libomp/libgomp，并依赖 SciPy 的 BLAS/LAPACK 接口。

"钻石依赖"与运行时错误

这种内置化方法导致了几个关键的技术问题：

1. 过度订阅与线程冲突

当多个库（例如 NumPy 和 PyTorch）各自携带自己的线程运行时（如不同的 OpenMP 实现）时，它们可能会争夺 CPU 资源。这会导致 "oversubscription"（过度订阅），即创建了过多的线程，从而导致严重的性能下降。

2. Fork-Safety（分叉安全性）死锁

PyTorch 中一个反复出现的问题是在使用 Python 的 multiprocessing 模块时发生的死锁。这通常是由于 GCC 实现的 OpenMP (libgomp) 不是 "fork-safe"（分叉安全）的。如果包管理器能够明确指定对分叉安全 OpenMP 实现（如 LLVM 的 libomp）的需求，这些错误就可以在安装层面得到避免。

3. ABI 不兼容性

不同的 BLAS/LAPACK 实现可能会使用不同的应用二进制接口 (ABIs)。例如，有些使用 32 位整数进行索引，而另一些使用 64 位。在单个环境中混合使用这些实现可能会导致段错误 (segmentation faults) 或极其错误的数值结果。

与系统包管理器的比较

系统级管理器（如 Debian 的 apt、Fedora 的 dnf 或 Conda）使用 "virtual dependencies"（虚拟依赖）或 "mutex metapackages"（互斥元包）来处理这个问题。

例如，在 Conda 中，一个互斥包 (mutex package) 可以确保一次只安装一个 BLAS 实现。这允许用户在全球范围内在所有已安装的包之间切换 OpenBLAS 和 MKL，而不会破坏环境。PyPI 缺乏类似的机制，使得每个 wheel 成为一个孤立的孤岛。

潜在的解决路径

解决 "原生依赖噩梦" 需要超越现状。目前已提出了几种潜在的缓解方案：

  • Standalone Native Wheels: 为 OpenBLAS 和 OpenMP 创建独立的 PyPI wheels。虽然这减少了 duplication，但它引发了关于谁来维护这些 wheels 以及如何管理破坏性变更的问题。
  • Demuxing Libraries: 利用像 FlexiBLAS 或 libblastrampoline 这样的包装库来提供统一的 API/ABI，从而允许在运行时交换底层实现。
  • Structural PyPI Changes: 实现构建农场 (build farm) 或虚拟包支持，使 PyPI 接近于系统包管理器的功能水平。

更广泛的视角："小岛问题"

与 BLAS 和 OpenMP 的挣扎是更大架构问题的一个症状。正如社区观察者所指出的，许多特定语言的包管理器被设计得仿佛它们存在于一个 "小隔离的岛屿"上，忽略了系统库和跨语言 ABIs 的复杂性。

"第一阶段 - 每个语言都试图重新实现自己的包管理器... 第二阶段 - 特定语言的包管理器被设计得仿佛它们生活在一个小隔离的岛屿上。它们既不尝试与其他语言集成，也不关心系统库... 第三阶段 - 生态系统成长起来，整个事情在生产环境中发生剧烈的爆炸。"

在 Python 的打包生态系统能够有效地弥合高层语言与它所依赖的低层系统库之间的鸿沟之前，PyData 技术栈将继续依赖脆弱的内置化权宜之计来维持其性能和稳定性。

Sources