TensorFlow模型训练卡住怎么办_Python监控显存与CPU利用率

先看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 图像操作。

这时候，同步打开另一个终端：

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 怎么办？

遇到这个错误先别慌，更别急着重装 CUDA。它的本质通常是 cuDNN 初始化失败，95% 的原因出在显存碎片或残留的 GPU 状态上，跟模型结构本身关系不大。可以按这个顺序排查：

• 首先，检查是否有多个 Python 进程在共用同一块 GPU。用 nvidia-smi 查看 Processes 列，把那些残留的 python 进程清理掉。
• 其次，确认你没有在 notebook 环境里反复执行 import tensorflow 并新建 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（这样可以避免被 TensorFlow 自己的日志冲刷掉）。
• 更系统的方法是使用 tf.profiler（v2.9+ 版本推荐）：

tf.profiler.experimental.start('logdir')
# 这里执行一步训练
tf.profiler.experimental.stop()

之后，通过 tensorboard --logdir=logdir 打开「Input Pipeline Analyzer」面板。它会清晰地告诉你，时间到底被哪一步吃掉了——八成是 IteratorGetNext 或者某个 DecodeJpeg 操作。

说到底，训练过程中真正难调的，往往不是模型本身的收敛速度，而是数据流里那些“看不见的等待”。可能是一个没关闭的文件句柄，一次多余的 numpy.array() 类型转换，甚至是硬盘的 I/O 调度策略。监控的意义就在于此：把那种模糊的“感觉卡住了”，变成可以精准定位的「第 372 步，map 函数里的 PIL.Image.open 调用耗时 420ms」。这才是解决问题的开始。