dataset.shard()需在数据加载早期调用，num_shards设为总worker数，index设为当前worker编号（从0开始）；必须先shuffle再shard以避免类别偏差，且batch时建议drop_remainder=true保证每worker batch数一致。
Dataset.shard() 分片时 worker_id 和 num_shards 怎么设
分片的核心是 Dataset.shard()，它必须在数据加载早期调用，否则可能漏数据或重复。参数 num_shards 是总分片数（通常等于分布式训练的 worker 数），index 是当前 worker 的编号（从 0 开始）。常见错误是把 index 写成 1 或搞反顺序——比如 4 个 worker，worker 0 要传 shard(4, 0)，不是 shard(4, 1)。
实际部署中，index 一般来自环境变量或启动参数，例如：
import os
num_workers = int(os.environ.get("NUM_WORKERS", "1"))
worker_id = int(os.environ.get("WORKER_ID", "0"))
dataset = dataset.shard(num_shards=num_workers, index=worker_id)
注意：shard() 不会自动打乱数据，如果原始数据有顺序（如按标签排列），分片后每个 worker 可能只看到部分类别——得先 shuffle() 再 shard()。
多机训练下 shard() 和 tf.data.experimental.AutoShardPolicy 的关系
TF 2.6+ 默认启用自动分片（AutoShardPolicy.FILE），会尝试按输入文件切分；但如果你手动调用了 shard()，自动分片会被禁用。这时候必须确保 shard() 出现在所有数据变换之前（包括 map()、batch() 前），否则部分操作可能跨分片执行，引发形状不匹配或重复样本。
容易踩的坑：
- 在
shard()前用了cache()：缓存会把全部数据加载进内存，失去分片意义 - 在
shard()后才shuffle(buffer_size=1000)：每个 worker 只 shuffle 自己那块，全局无序 - 用了
interleave()且cycle_length > 1：若没在 interleave 内部做子分片，可能破坏分片边界
分片后 batch() 大小为什么变小了
这是最常被忽略的副作用：shard() 会按元素数量等比分，但最后一批常被截断。比如原始数据 1000 条、batch(32)，共 32 批（最后批 8 条）；分片为 3 份后，每份约 333 条，batch(32) 就只剩 10 批（最后批 13 条）——总数没错，但每 worker 的 batch 数不同，影响 epoch 对齐。
解决方法只有两个：
• 用 drop_remainder=True 在 batch() 中丢弃末尾不足 batch 的数据，保证每批严格 32 条
• 或在分片前用 repeat() + take() 预估总步数，但会引入额外复杂度
更稳妥的做法是：分片 → shuffle → batch(drop_remainder=True) → prefetch，这样每个 worker 每 epoch 的 batch 数一致，同步训练更稳。
本地调试时怎么模拟多 worker 分片
不用起多进程，直接用不同 index 多次运行即可。例如写个脚本循环跑：
for i in range(3):
ds = base_dataset.shard(num_shards=3, index=i)
print(f"Worker {i} gets first 5 labels:",
[x[1].numpy() for x in ds.take(5)])
关键点是：必须用同一个未 shuffle 的 base_dataset 实例反复分片，否则每次 shuffle() 种子不同，结果不可比。调试时建议固定 shuffle(seed=42) 并放在 shard() 之后——这样你能验证每个 worker 是否拿到互斥、无重叠的数据子集。
真实集群里，shard() 的行为依赖于 Dataset 的“确定性”（deterministic），如果用了非确定性 op（如某些随机 map），分片结果可能不一致——务必在 options().deterministic = True 下测试。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
