先看nvidia-smi和htop比改代码更管用：若GPU-Util长期为0%但Memory-Usage占满，说明GPU在等数据；若GPU-Util持续95%+却无日志输出，可能是Python主线程在map中卡住；同步用htop观察CPU，单核100%锁死且GPU空闲则大概率是map内阻塞逻辑导致。
训练卡住时，90%的情况不是模型问题，而是资源被堵在数据加载或显存分配环节。先看 nvidia-smi 和 htop，比改代码更管用。
怎么快速判断是GPU空转还是真卡死？
打开终端，一边跑训练脚本，一边执行：
watch -n 1 nvidia-smi
重点盯三列：GPU-Util、Memory-Usage、Processes。如果 GPU-Util 长期为 0% 或个位数，但 Memory-Usage 已占满，说明 GPU 在等数据——大概率是 tf.data 管道没配好；如果 GPU-Util 持续 95%+ 却没日志输出，反而要怀疑 Python 主线程是否在某个 map 函数里卡住了（比如用了未向量化的 PIL 操作）。
同步开另一个终端：
立即学习“Python免费学习笔记（深入）”；
htop -u $(whoami)
观察 Python 进程的 CPU 占用：如果单核 100% 锁死，且 nvidia-smi 显示 GPU 空闲，基本可断定是 tf.data.Dataset.map 里混入了阻塞式逻辑（如 cv2.imread + time.sleep 类调用）。
为什么加了 prefetch 还卡？常见配置陷阱
prefetch 不是万能开关，它只对“数据供给”起作用，不能解决预处理函数本身慢的问题。容易踩的坑包括：
-
dataset.prefetch(buffer_size=1)：缓冲区太小，几乎无效；应设为tf.data.AUTOTUNE或至少2 -
map放在batch后面：图像解码、归一化这类操作必须在batch前做，否则会反复对单张图调用 N 次 - 没加
num_parallel_calls=tf.data.AUTOTUNE：CPU 核心闲置，预处理串行执行 -
cache()误用：对超大数据集（如百万级图像）直接cache()会爆内存，应只在内存可容纳时用，或改用cache("/path/to/cache")落盘缓存
训练中途突然卡住，CUDNN_STATUS_INTERNAL_ERROR 怎么办？
这个错误本质是 cuDNN 初始化失败，95% 由显存碎片或残留状态导致，和模型结构无关。不要急着重装 CUDA：
- 检查是否多个 Python 进程共用同一块 GPU：用
nvidia-smi看Processes列，杀掉残留的python进程 - 确认没在 notebook 里反复
import tensorflow并新建tf.config.list_physical_devices('GPU')：每次 import 都可能触发新上下文，积累显存句柄 - 加这两行到训练脚本最开头（不是模型定义后）：
import os os.environ['TF_FORCE_GPU_ALLOW_GROWTH'] = 'true'
再配合 tf.config.experimental.set_memory_growth，避免显存一次性占满后无法回收。
Python 层怎么监控 CPU/GPU 耗时？别靠 print
用 time.time() 打点只能定位粗粒度瓶颈。真正有用的是：
- 在
tf.data.Dataset.map的预处理函数里加tf.py_function包裹，并用time.perf_counter()测单次耗时，打印到stderr（避免被 tf logging 冲掉） - 用
tf.profiler抓取真实算子耗时（v2.9+ 推荐）：
tf.profiler.experimental.start('logdir')
# 训练一步
tf.profiler.experimental.stop()然后用 tensorboard --logdir=logdir 查看「Input Pipeline Analyzer」面板，它会明确标出哪步占了 80% 时间——通常是 IteratorGetNext 或某个 DecodeJpeg。
真正难调的从来不是模型收敛速度，而是数据流里那些看不见的等待：一个没关的文件句柄、一次多余的 numpy.array() 转换、甚至硬盘 I/O 调度策略。监控不是为了凑数字，是把模糊的“卡住”变成可定位的「第 372 步，map 函数里 PIL.Image.open 耗时 420ms」。
