tf.data.map() 默认单线程执行，需设 num_parallel_calls=tf.data.AUTOTUNE 以充分利用 CPU；shuffle() 应在 repeat() 前、buffer_size 取样本量 1–3 倍；prefetch() 必须置于 pipeline 末端且用 AUTOTUNE；cache() 仅适用于小数据集且位置关键。
tf.data.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() 必须放在 pipeline 最末端
prefetch() 的作用是让“数据预处理”和“GPU 训练 step”重叠执行。但它只对后续操作生效——放错位置等于没开。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 错误写法：
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() 只对小数据集有效，且必须放在 shuffle() 前、map() 后；否则要么吃光内存，要么起不到加速作用。
立即学习“Python免费学习笔记（深入）”；
- 小数据集（如 cache() 到内存
- 中大型数据集建议用磁盘缓存：
cache('/path/to/cache')，避免内存溢出 -
cache()放在shuffle()后：会导致每次 shuffle 都重新读取原始数据，失去缓存意义 - TFRecord 流式读取时慎用
cache()，尤其当parse_fn含随机增强逻辑，缓存会固化增强结果
prefetch 就行，而是 map 并行没开、shuffle 缓冲太小、prefetch 放错位置，任何一个点没对齐，GPU 就还在空转。 
