根本原因是CPU预处理瓶颈而非GPU未识别：tf.data流水线未优化导致CPU打满、GPU空闲，需合理配置prefetch、cache、map并行数，限制TF及OpenCV/NumPy线程数，避免多库线程冲突。
根本原因不是GPU没识别，而是CPU在数据准备阶段失控——线程开太多、预处理库抢核、内存拷贝阻塞，GPU只能干等。
tf.data管道卡在CPU预处理上
GPU空闲但CPU打满，90%以上情况是tf.data流水线没调好：shuffle、map、batch这些操作默认在CPU上串行执行，尤其当用了from_generator或自定义preprocessing函数时，容易变成单点瓶颈。
-
.prefetch(buffer_size=tf.data.AUTOTUNE)必须加，它让CPU准备下一批数据的同时GPU算当前批——不加就等于“做完一批再做下一批” -
.cache()对固定数据集（如本地文件）非常有效，避免每轮重复解码；但对动态生成数据（如实时增强）反而拖慢 -
.map(..., num_parallel_calls=tf.data.AUTOTUNE)要显式启用，并确保map里函数本身不带OpenCV多线程（否则会和TF线程打架）
TensorFlow后台线程数失控
TF 2.x默认把intra_op和inter_op线程数都设成物理核心数，两个相乘可能生成上百线程，调度开销反超收益。更糟的是，一旦执行过任意TF操作（比如tf.constant(1)），再调tf.config.threading.set_intra_op_parallelism_threads()就完全失效。
- 必须放在
import tensorflow as tf之后、第一行张量创建之前 - 设为
1最稳；设为2~4适合混部环境；别信“按CPU核数配”的经验公式 - 环境变量优先级更高：
TF_NUM_INTRAOP_THREADS=2和TF_NUM_INTEROP_THREADS=2启动前就export，比代码设置更可靠
OpenCV/NumPy底层偷偷吃满CPU
很多人调了TF线程数没用，最后发现是cv2.imread、albumentations.Compose或scipy.ndimage内部启用了OpenMP，默认占满所有逻辑核——它们根本不听TF的线程配置。
立即学习“Python免费学习笔记（深入）”；
- 在脚本最开头加：
os.environ["OMP_NUM_THREADS"] = "1"、os.environ["OPENBLAS_NUM_THREADS"] = "1" - 如果用了OpenCV，还要加：
cv2.setNumThreads(0)（设0表示禁用内部多线程） -
torch.set_num_threads(1)对TF无效，别混用；TF只认自己的环境变量和tf.config
GPU没真正接管计算任务
即使tf.config.list_physical_devices("GPU")返回非空，也不代表模型在GPU上跑。TF会根据op注册情况自动 placement，但某些op（如自定义Python函数、部分稀疏操作）强制回退到CPU。
- 用
tf.debugging.set_log_device_placement(True)打开设备日志，看关键op（如MatMul、Conv2D）是否落在/GPU:0 - 显存被占满但GPU-Util≈0？大概率是
tf.data把数据全load进GPU memory却没触发计算——检查model.fit()输入是否直接用了tf.data.Dataset，而不是numpy array - 确认没手动指定
with tf.device("/CPU:0"):这种硬绑定，也别在Keras层里写device="cpu"
真正卡点往往不在表面参数，而在多个库的线程策略叠加：TF开8个、OpenCV开16个、NumPy BLAS再开8个，三套调度器互相抢核。先htop -H看线程名归属，再针对性关，比盲目调num_parallel_calls管用得多。
