tf.data管道优化需协同配置map、shuffle、prefetch和cache：map设num_parallel_calls=AUTOTUNE或略超物理核数；shuffle在repeat前、buffer_size取样本量1–3倍；prefetch放pipeline末尾；cache仅用于小数据集且置于shuffle前。
GPU 等着数据，不是模型等着收敛——tf.data 管道调不好，90% 的训练时间都花在空转上。
map() 不加 num_parallel_calls 就是单线程堵点
图像解码、随机裁剪、归一化这些操作默认在单个 CPU 核上串行执行，哪怕你有 32 核，map() 也只用 1 个。GPU 拿到 batch 后立刻干等，显存利用率掉到 30% 是常态。
-
num_parallel_calls=tf.data.AUTOTUNE是最稳妥的选择，TensorFlow 运行时会根据当前 CPU 负载和批大小动态分配线程数 - 若需手动控制（比如调试或固定环境），设为
num_parallel_calls=4或略高于物理核心数；超过 8 通常无收益，还可能因线程竞争拖慢 - 函数体内不能含
cv2.VideoCapture、全局变量、print()或其他不可序列化/带副作用的操作，多线程下行为不可预测 - 避免在
map()中嵌套tf.py_function：它会退回到 Python GIL，性能断崖式下跌
shuffle(buffer_size) 不是越大越好，也不是越小越省事
shuffle() 并不真正打乱整个数据集，而是维护一个滑动缓冲池：每次从中随机取一个样本，再用新样本补位。buffer_size 决定了“随机性深度”和内存开销。
- 训练集 5 万样本，
buffer_size=1000：前 1000 个样本高频出现，后期样本几乎不会进入前几个 epoch，loss 曲线抖动剧烈 -
buffer_size=len(dataset)：TFRecord 流式读取时根本不知道总长，强行估算易 OOM；即使能算准，也极易挤占显存外的系统内存 - 经验起点：
buffer_size=10000；已知总量时，设为样本数的 1–3 倍（如 8 万样本 →buffer_size=240000） - 必须在
repeat()之前调用shuffle()，否则每个 epoch 都从同一顺序开始，shuffle 形同虚设
prefetch(tf.data.AUTOTUNE) 必须放在 pipeline 最末端
prefetch() 的作用是让“数据预处理”和“GPU 训练 step”重叠执行。但它只对后续操作生效——放错位置等于没开。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
立即学习“Python免费学习笔记（深入）”；
- 错误写法：
dataset.prefetch(...).map(...).batch(...)→ 此时 prefetch 的是原始字节流，还没解码，毫无意义 - 正确顺序：
...shuffle().map().batch().prefetch(tf.data.AUTOTUNE) - 别写
prefetch(1)或prefetch(2)：硬编码值在不同 GPU 显存、batch_size、CPU 核心数下极易失配 - 即使用了
tf.distribute.MirroredStrategy，AUTOTUNE依然有效，无需额外修改
cache() 用错地方反而拖慢速度
cache() 把已处理的数据存进内存（或磁盘），适合预处理代价高 + 数据集能装下。但多数场景下它是个双刃剑。
- 图像尺寸大、增强操作复杂（如 mixup + autoaugment）且数据集 ≤ 20GB 时，
cache()放在map()之后、shuffle()之前效果最好 - TFRecord 文件本身已压缩，又做了 decode + resize，此时再
cache()可能比重新解码还慢——因为内存带宽成了瓶颈 - 绝对不要在
repeat()之后cache()：会把无限重复的数据全塞进内存，几轮就爆掉 - 不确定是否该缓存？先跑一轮 profile：对比开启前后
tf.data.experimental.StatsOptions统计的 “IteratorGetNext” 耗时
三个参数的位置和取值不是孤立的：改 map 的并发数，shuffle 缓冲区就得跟着调；开了 cache，prefetch 的深度也要重估。没有银弹，只有实测。
