应设为 min(4, os.cpu_count()) 起手，小模型用2–4、大模型试8–16，需与 inter_op 协同调整；仅对 CPU 生效，且必须在 tf.function 追踪前设置，环境变量优先级更高。
tf.config.threading.set_intra_op_parallelism_threads 该设多少
这个函数控制单个算子内部的并行线程数，比如矩阵乘法、卷积等底层计算能用几个线程跑。设太高反而拖慢——尤其在 CPU 核心少或模型小的时候，线程调度开销会盖过并行收益。
实操建议：
- 默认值通常是 CPU 逻辑核心数，但实际推荐设为
min(4, os.cpu_count())起手，再根据top或htop观察 CPU 利用率和 wall time 调整 - 训练小模型（如 MLP on MNIST）设 2–4 即可；大模型（ResNet50+ImageNet）可试 8–16，但务必搭配
set_inter_op_parallelism_threads一起调 - 注意：它只对 CPU 后端生效，GPU 上该参数被忽略
tf.config.threading.set_inter_op_parallelism_threads 影响什么
这个参数决定不同算子之间（比如前一层输出 → 下一层输入）能并发执行多少个独立计算图节点。它本质是控制 graph execution scheduler 的并发度，不是“每个 op 开几个线程”，而是“最多同时跑几个 op”。
常见错误现象：
- 设成 1：图里所有 op 强制串行，哪怕有大量独立分支（如多个 loss 分别计算），吞吐暴跌
- 设得远大于 CPU 核心数（比如 32 在 8 核机器上）：线程争抢严重，
pthread_mutex_lock耗时上升，tf.function编译后实际性能反而下降 - 与
intra_op不匹配：比如intra_op=16+inter_op=1，等于把所有计算压在一个线程里喂 16 个子线程，极易触发锁竞争
set_inter_op_parallelism_threads(8)。
为什么 tf.config.threading 设置在 tf.function 外无效
TensorFlow 2.x 的 eager mode 下，这些配置必须在任何 tf.function 被追踪（tracing）之前完成，否则 runtime 已按旧配置生成了执行计划，后续修改不生效。
使用场景：
- 你在 Jupyter 里先跑了
@tf.function定义模型，再调set_intra_op_parallelism_threads—— 毫无作用 - 多进程训练中，每个 worker 进程需各自调用设置，不能只在主进程设
- 常见错误写法：
model = MyModel(); tf.config.threading.set_...(); model(x)—— 如果model(x)是首次调用触发 tracing，此时设置已晚
@tf.function 定义之前，最好紧贴 import tensorflow as tf 下一行。
Linux 环境下 TF_NUM_INTEROP_THREADS 和 TF_NUM_INTRAOP_THREADS 优先级
这两个环境变量会覆盖 Python API 的设置，且在进程启动时读取，属于更底层的硬约束。
参数差异：
-
TF_NUM_INTEROP_THREADS对应set_inter_op_parallelism_threads -
TF_NUM_INTRAOP_THREADS对应set_intra_op_parallelism_threads - 如果同时设置了环境变量和 Python API，以环境变量为准；若只设其一，另一仍走 Python API 设置
--cpus=2），却没设环境变量，默认可能拉满宿主机核心数，导致容器内频繁被 throttled。此时应显式导出：export TF_NUM_INTEROP_THREADS=2 TF_NUM_INTRAOP_THREADS=2。
事情说清了就结束。最常被忽略的是：这些设置对 tf.data.Dataset 的 prefetch、map(num_parallel_calls=...) 完全无关——那是另一套线程池，得单独调。 
