tf.data.Dataset.from_tensor_slices慢因一次性加载全部数据到内存，应改用TextLineDataset或TFRecordDataset配合延迟加载；map并行数宜设AUTOTUNE；shuffle须在repeat前、batch后；prefetch必须置于batch之后。
tf.data.Dataset.from_tensor_slices 为什么慢？别直接喂原始数组
直接用 tf.data.Dataset.from_tensor_slices 加载整个 NumPy 数组进内存，训练时反而卡在数据流水线上——尤其当数组是 GB 级图像路径或特征矩阵时，初始化就耗几秒，prefetch 也救不回来。根本原因是它把全部数据一次性转成 TensorFlow 张量，没留 IO 调度空间。
实操建议：
- 路径列表用
from_tensor_slices没问题（只存字符串），但后续必须接map延迟加载； - 图像/音频等大文件，改用
tf.data.TextLineDataset（读路径文件）或tf.data.TFRecordDataset（预序列化）； - 避免在
map函数里做 PIL/OpenCV 解码+增强——换成tf.io.decode_jpeg+tf.image.random_flip_left_right，否则会退化到 CPU 单线程。
map 的 num_parallel_calls 怎么设才不翻车
num_parallel_calls 不是越大越好。设成 tf.data.AUTOTUNE 多数情况最稳，手动指定容易触发资源争抢：CPU 核数超了，线程排队反拖慢；GPU 显存小，解码缓冲区溢出报 ResourceExhaustedError。
常见错误现象：
立即学习“Python免费学习笔记（深入）”；
- 训练刚开始就卡住 10 秒以上，
nvidia-smi显示 GPU 利用率 0% —— map 并行太多，CPU 解码堵死 pipeline； - batch size 调小后反而更快 —— 说明之前并行任务把内存带宽打满了；
实操建议：
- 先固定
num_parallel_calls=tf.data.AUTOTUNE； - 若需手动调优，从
num_parallel_calls=2开始试，每轮 +2 观察dataset.cardinality().numpy()和 step time； - 在
map里做归一化时，别写x / 255.0，改用tf.cast(x, tf.float32) * (1. / 255.)，避免隐式类型转换阻塞并行。
repeat、shuffle、batch 的顺序错了，数据分布就歪了
写成 dataset.repeat().shuffle(1000).batch(32) 是典型错误：repeat 在前会导致 shuffle 缓冲区反复灌入相同 epoch 数据，实际打乱效果极弱；更糟的是，如果 repeat 放最前且没设 count，shuffle 缓冲区永远填不满，首几个 batch 全是相似样本。
正确顺序必须是：
-
shuffle紧跟原始数据源后（如from_tensor_slices或TFRecordDataset）； -
repeat放shuffle后、batch前； -
batch必须在最后（或prefetch前）；
示例：
dataset = tf.data.TFRecordDataset('train.tfrecord')
dataset = dataset.shuffle(buffer_size=10000, reshuffle_each_iteration=True)
dataset = dataset.repeat(count=epochs)
dataset = dataset.batch(32)
dataset = dataset.prefetch(tf.data.AUTOTUNE)prefetch 放哪儿？放错位置等于没加
prefetch 必须放在流水线末端，也就是 batch 之后、模型 fit 之前。放在 map 前或 shuffle 前毫无意义——前者 prefetch 的是未解码的原始字节，后者 prefetch 的是打乱前的乱序片段，都不能缓解 GPU 等待。
性能影响很直接：
- 没
prefetch：GPU 利用率常低于 30%，step time波动大； - 加了
prefetch(tf.data.AUTOTUNE)：利用率拉到 85%+，time per step 方差缩小 50% 以上；
注意：prefetch 参数是「预取多少个 batch」，不是线程数。设太大（如 100）会吃光内存，尤其 batch 内含高分辨率图像时；设太小（如 1）起不到掩盖 IO 延迟的作用。默认用 tf.data.AUTOTUNE 最省心。
真正卡顿往往不出现在模型里，而出现在 map 函数的 Python 回调中——只要写了 lambda x: some_pil_func(x)，整条 pipeline 就掉回单线程。能用原生 TF ops 就别碰 NumPy/PIL，这个边界比想象中更硬。
