根本原因是num_parallel_calls默认为none导致map()串行阻塞；应设为tf.data.autotune，配合cache()→shuffle()→batch()→prefetch()正确顺序，并用profiler定位iteratorgetnext耗时。
不是fit()本身慢，而是数据供给不上、GPU空转、或计算图没编译——90% 的“极慢”都卡在这三处。
tf.data流水线卡在map()里，CPU 100%但GPU利用率个位数
典型现象：训练前几轮还行，越往后map()耗时越长，prefetch()像没起作用。根本原因是默认num_parallel_calls=None，所有预处理（比如tf.io.read_file、tf.image.decode_jpeg）全串行执行。
- 必须显式写
num_parallel_calls=tf.data.AUTOTUNE，别用硬编码数字（不同机器核数不同） - 如果用了
tf.py_function，不加num_parallel_calls就自动退化为单线程 -
cache()要放在map()之后、shuffle()之前；小数据集可内存缓存，大数据集改用cache('/path/to/disk') - 顺序必须是：
map() → cache() → shuffle() → batch() → prefetch()；写成prefetch().batch()会让GPU等CPU拼batch
fit()没用@tf.function，全程Eager Execution拖垮性能
TensorFlow 2.x默认启用Eager模式，调试方便，但每步都走Python解释器，开销巨大。尤其在fit()内部循环中，反复调用model()、loss()、GradientTape，会把GPU算力全浪费在调度上。
- 确保模型训练逻辑被
@tf.function包裹（Keras默认已做，但自定义训练循环必须手动加） - 避免在
@tf.function内做Python原生操作（如print()、list.append()），否则会退出图模式 - 如果用了
tf.keras.metrics，确认它们没在@tf.function外频繁调用.result()——这会强制同步并打断图执行
GPU显存占满但算力闲置，nvidia-smi显示GPU-Util长期低于30%
这不是显卡不行，而是TensorFlow没把硬件资源调度起来。RTX/A100的Tensor Core在FP32训练下基本闲置，同时显存带宽也被低效数据格式拖累。
- 开启混合精度：
policy = tf.keras.mixed_precision.Policy('mixed_float16')+mixed_precision.set_global_policy(policy) - 检查是否误启用了
tf.config.experimental.set_memory_growth却没配allow_growth=True，导致显存分配失败后fallback到CPU - 禁用不必要的
tf.debugging断言或tf.print，它们会在每个step插入同步点 - 确认
batch_size足够大——太小会导致kernel launch开销占比过高，尤其对小模型
最容易被忽略的一点：fit()慢往往不是模型或数据的问题，而是你没打开tf.data的并行开关、没让@tf.function真正生效、也没告诉TensorFlow去用FP16。三个开关一开，速度常能翻倍；缺一个，GPU就一直在摸鱼。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
