pytorch cpu运算默认不自动启用多核并行，而是依赖底层blas库（如mkl、openblas）的线程配置；若未设置omp_num_threads等环境变量，通常仅用单线程。
PyTorch 本身不默认启用 CPU 多核并行计算，不是 bug，而是设计选择；它把底层并行留给 BLAS 库（如 OpenBLAS、Intel MKL）控制，而这些库的线程数默认常为 1 或受限于环境变量。
PyTorch 的 CPU 运算到底用不用多核？
用，但不自动开满。PyTorch 的张量运算（如 torch.mm、torch.relu、torch.softmax）在底层调用的是链接的 BLAS/LAPACK 库，这些库支持多线程，但 PyTorch 不负责启动或管理它们——线程数由系统级配置决定：
-
OMP_NUM_THREADS：控制 OpenMP 线程数（影响部分 BLAS 实现） -
OPENBLAS_NUM_THREADS：专用于 OpenBLAS -
MKL_NUM_THREADS：专用于 Intel MKL（PyTorch 官方 Linux/macOS 预编译包默认链接 MKL） - 若全未设置，多数情况下只用 1 个线程，导致 CPU 利用率长期低于 100% 且仅跑满单核
为什么 torch.set_num_threads() 有时没效果？
这个函数只对 PyTorch 自己调度的内部线程生效（比如 torch.nn.DataParallel 的数据预处理线程），但它不传递给底层 BLAS。常见误操作：
- 只调用
torch.set_num_threads(8)，但没设MKL_NUM_THREADS=8→ 矩阵乘依然单线程 - 在 Jupyter 中设置环境变量晚于 PyTorch 导入 → 变量被忽略（必须在
import torch前生效） - Linux 下用 conda 安装的 PyTorch 默认链接 MKL，但 macOS 上可能用 Accelerate 框架（不响应
MKL_NUM_THREADS）
验证是否生效：运行一次大矩阵乘后，用 psutil.cpu_percent(percpu=True) 观察是否多个核心同时跃升。
PyTorch + multiprocessing 会和 BLAS 多线程冲突吗？
会，而且很常见。当你用 ProcessPoolExecutor 启动 4 个子进程，每个又默认用 4 核 MKL —— 实际会并发 16 个线程，造成严重争抢和缓存抖动，总耗时反而比单进程更长。
- 解决方法：子进程中显式限制 BLAS 线程数，例如在 worker 函数开头加
torch.set_num_threads(1)和os.environ["MKL_NUM_THREADS"] = "1" - 更稳妥的做法：用
mp.set_start_method('spawn')+ 全局禁用子进程的 MKL 并行（避免继承父进程环境） - 注意：Windows/macOS 必须加
if __name__ == "__main__":，否则子进程重复导入时可能意外触发多线程初始化
真正需要 CPU 多核并行时，该选 PyTorch 还是别的？
取决于任务性质：
- 纯数值密集型（如批量矩阵求逆、SVD、自定义 kernel 计算）→ 优先调 BLAS 参数，而不是写 multiprocessing
- 逻辑复杂、非张量主导（如解析大量 JSON + 特征工程 + 小张量计算）→ 用
concurrent.futures.ProcessPoolExecutor，但务必关闭子进程的 BLAS 多线程 - 混合 I/O 与计算（如边读文件边做归一化）→
ThreadPoolExecutor可能更合适（GIL 在 I/O 时释放），但需确认计算部分是否真被阻塞
最容易被忽略的一点：PyTorch 的 CPU 模式下，.to(device) 对 tensor 是拷贝操作，频繁在进程间传大张量会触发序列化+内存复制，比直接用共享内存（torch.multiprocessing.shared_memory）慢一个数量级。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
