PyTorch DataLoader 核心机制与实战调优：从 Dataset 到多进程加载的完整指南

几个月前调一个图像分类项目，数据量从几万涨到几十万，训练脚本里还是老老实实一次性把所有图片 resize 好塞进内存，结果 32G 的机器直接 OOM，换成边读边训练又慢得离谱，GPU 利用率一直上不去。后来把整条数据管线切到 PyTorch 的 DataLoader 上，才发现自己之前对“批量加载数据”的理解有多粗糙。这篇就专门聊聊 DataLoader 怎么用、为什么这么设计，以及我实际踩过的坑。

DataLoader 核心解决三件事：把数据按 batch 切好、把读取和预处理放到后台多进程里提前跑、把每个样本聚合成训练所需的张量结构。它适合所有开始正经训练模型的读者，尤其是你发现训练流程里“加载数据”正在拖后腿，或者你还在用手工写循环一次取一个 batch、再自己 padding 拼装的阶段。读完你应该能搞明白 DataLoader 内部到底怎么协作，以及遇到速度上不去、内存爆炸、多进程诡异报错时怎么定位。

1. DataLoader 解决的核心痛点：完整的数据流全景

1.1 数据加载失控的典型场景

我先说几个我见过（也经历过）的典型场景：

第一种是“内存爆炸型”。数据集不大时，把图片全量读入内存做成 numpy 数组，训练确实飞快。但数据量一旦上来，或者图片分辨率提高，内存瞬间就不够用了。很多人以为这是硬件问题，其实根源是数据流设计问题——你把“存储”和“计算”绑在一起了。

第二种是“GPU 饥饿型”。训练循环里每次迭代都同步去磁盘读文件、做 resize、做归一化，一个 batch 的数据准备要花 200 毫秒，GPU 算完一个 batch 只需要 50 毫秒。这时候显存的利用率曲线就是锯齿状，一路一停，整体训练时间被数据加载拖慢好几倍。

第三种是“顺序错乱型”。训练集和验证集没有独立的数据流，或者忘了在每个 epoch 打乱数据，导致模型评估结果虚高或偏低，甚至出现过连续多个 epoch 看到同一批数据的问题，loss 曲线看着正常但验证集表现一直在波动。

这些场景背后其实是同一个问题：数据准备和模型训练没有解耦。DataLoader 存在的意义就是把“取样本、打乱、攒 batch、预处理、拼装张量”这套流程标准化，让你只关心“喂给模型的张量长什么样”，而不是每次从头写一个 while 循环去管这些脏活累活。

1.2 Dataset、Sampler、BatchSampler、collate_fn 的分工

很多人第一次接触 DataLoader，只知道往里塞一个 dataset 再设置 batch_size，完全没搞懂内部的组件是怎么协作的。理解这些组件的分工，对排查问题会非常有帮助。

完整的默认流程可以看成一条流水线：

Dataset负责“给一个索引，返回一个样本”。它像一个冰箱，每个格子放一种食材，你告诉它格子编号，它把食材递给你。Dataset 只管单条样本，不知道 batch 是什么。

Sampler负责“决定取哪些索引、按什么顺序取”。它决定这一个 epoch 里你按什么顺序访问冰箱里的格子。默认情况下，DataLoader 会在你设置shuffle=True时使用随机采样，False时按顺序采样。Sampler 输出的是一个个索引，不是数据本身。

BatchSampler负责把 Sampler 输出的索引攒成一组一组。比如batch_size=32，它就把 32 个索引装进一个小篮子。这批索引会被一次性送到 Dataset 那里，取出对应的 32 个样本。

collate_fn是最后一道工序，负责把“32 个独立样本”拼成“一个 batch 张量”。默认逻辑是把你返回的元组按位置对齐：如果每个样本是(image, label)，那它就拼出(images_batch, labels_batch)。这个函数能不能拼成功，取决于你所有样本的形状是否一致。很多新手在这里报错，就是因为不同样本的尺寸或长度不一致。

下面这个表格可以帮你快速记住各组件的职责边界：

为了更好理解，我给这套机制一个生活类比：Dataset 是食材仓库；Sampler 是你今天想按什么顺序拿食材；BatchSampler 是把食材每 32 份装成一箱；collate_fn 是后厨把每箱食材切好、摆盘，变成可以直接端上桌的一道菜。DataLoader 则是整个配送调度系统，它负责提前通知仓库备货、用几辆车运、什么时候送到后厨。

1.3 三类 Dataset：Map 式、Iterable 式、TensorDataset

Dataset 有几种常见形态，它们的适用场景差别很大。

最常见的是Map 式 Dataset，也就是实现了__getitem__和__len__的类。这种形态支持随机访问，所以才能配合 shuffle、随机采样、多进程预取。绝大多数监督学习任务都该优先用它，因为你能拿到数据集长度，索引和标签一一对应。

第二种是Iterable 式 Dataset，只需要实现__iter__，不要求实现__len__。它适合流式数据场景——比如从数据库游标逐行读取、从日志文件流式解析、或者数据本身没法一口气列全的情况。它的代价是：你没法随机访问，也就没法真正 shuffle，多进程时每个 worker 拿到的是同一份迭代器副本，需要自己处理切分逻辑。

第三种是TensorDataset，它是最快的入门方式。如果你数据已经读进了内存，变成了若干个张量，比如(features, labels)，直接TensorDataset(features, labels)包一下，再交给 DataLoader，它就能按第一维对齐、批量取出。这种方式适合小规模数据快速验证模型结构，但不适合大数据集，因为它没法避免全量数据驻留内存的问题。

我个人的选型原则很简单：凡是数据能落盘、有明确索引的任务，一律用 Map 式 Dataset；凡是真正流式无限数据才用 Iterable 式；TensorDataset 只用来快速跑通小程序。有不少人把数据存在数据库、接口访问，也硬塞进 TensorDataset，这种属于没想清楚边界。

2. 手把手搭建一套可跑的批量加载流程

2.1 一个图像分类任务的 Dataset 写法

理论讲完，直接看代码。假设我有一个图片分类任务，图片路径在file_list里，标签在label_list里，我打算读图后用torchvision.transforms做预处理。

import torch from torch.utils.data import Dataset, DataLoader from PIL import Image import torchvision.transforms as T class MyImageDataset(Dataset): def __init__(self, file_list, label_list, transform=None): self.file_list = file_list self.label_list = label_list self.transform = transform def __len__(self): return len(self.file_list) def __getitem__(self, idx): img = Image.open(self.file_list[idx]).convert("RGB") if self.transform is not None: img = self.transform(img) label = self.label_list[idx] return img, label

这里有几个细节要留意：

• __init__里不要做重活。能延迟到__getitem__的就不在初始化时做，因为后面提到多进程 worker 时，__init__会被重复执行，很容易踩坑。
• 每条样本的标签和路径必须索引对齐。这是最基础也最容易出错的地方，尤其是你做了 train/val 划分后，标签列表的下标不要搞混。
• transform 放在 Dataset 外面传入比较好。这样同一个 Dataset 可以配不同的 transform 分别给训练集和验证集，复用代码。

然后这样实例化：

transform_train = T.Compose([ T.RandomResizedCrop(224), T.RandomHorizontalFlip(), T.ToTensor(), T.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]) ]) train_loader = DataLoader( MyImageDataset(train_files, train_labels, transform=transform_train), batch_size=32, shuffle=True, num_workers=4, drop_last=True, )

这样做后，每次迭代train_loader拿到的就是一个 shape 为(32, 3, 224, 224)的图像张量加一个(32,)的标签张量。

2.2 collate_fn 默认行为与自定义时机

默认的 collate_fn 对大多数人来说足够用：它会把样本逐字段拼成张量。但只要你的样本形状不一致，或者你有“样本之外”的元信息需要一起进 batch，就必须自己写 collate_fn。

一个最典型的场景是 NLP 里的变长序列。假设每条样本是(token_ids, label)，不同句子的token_ids长度可能不一样，默认 collate_fn 会直接报错说“无法把长度不一致的序列堆叠成张量”。这时候就需要自定义 collate_fn，在拼装时做 padding。

def collate_texts(batch): texts, labels = zip(*batch) lengths = [len(t) for t in texts] max_len = max(lengths) padded = torch.zeros(len(texts), max_len, dtype=torch.long) mask = torch.zeros(len(texts), max_len, dtype=torch.bool) for i, t in enumerate(texts): padded[i, :len(t)] = torch.tensor(t) mask[i, :len(t)] = True return padded, mask, torch.tensor(labels)

这个函数返回三个东西：padded是填充后的 token 矩阵，mask标记哪些位置是真实 token，labels是标签。模型在算 loss 时可以利用mask把 padding 部分排除掉，这一步很容易被新手漏掉，导致模型在无效位置上也学了一堆噪声。

什么时候需要自定义 collate_fn？我的经验是这几个场景：

• 变长序列（文本、语音、不同长度的视频片段）
• 样本不是简单元组，而是需要返回 dict 结构
• 同一条样本里有多个不同模态的输入，需要分别拼装
• 你希望把某条样本的全局信息（比如音频长度）单独拿出来，而不是直接拼进张量里

记住 collate_fn 处理的是“列表内样本之间的组织关系”，而不是“单个样本怎么生成”。单个样本的预处理请放到 Dataset 里。

2.3 跑训练前先验证数据流：调试 DataLoader 的土办法

我见过太多人写完全部代码直接开训练，跑了三个小时才发现标签顺序错了、图片维度不对、或者某个 batch 里混进了空数据。这个过程痛不痛？非常痛。所以我强烈建议，在写训练循环之前，先单独把 DataLoader 拉出来调试一遍。

调试方式很简单，写一个极小的循环，打印几个 batch 的 shape 和标签分布：

for i, (images, labels) in enumerate(train_loader): print(images.shape, labels.shape) print("label distribution:", labels.unique(return_counts=True)) if i >= 2: break

我会重点看三件事：

• shape 对不对：图像是不是(N, C, H, W)，序列是不是(N, L)，标签是不是(N,)。
• 标签分布是否符合预期：如果一共 10 类，某个 batch 里只有一个类，但你确实设置了shuffle=True，那在小数据集上可能只是概率问题，不用慌。
• 多跑几个 epoch 确认顺序真的变了：把每个 epoch 第一个 batch 的第一个样本打出来，如果完全相同，说明 shuffle 没有生效或者你的 Dataset 实现有问题。

这个阶段发现问题，修改成本是最低的。一旦开始训练，定位问题的成本会高一个数量级。

3. 参数调优：从“能用”跑到“跑快”的分水岭

3.1 每个参数到底是干什么的

DataLoader 的参数不少，但真正影响性能的就那么几个。我先列一个表，然后针对最重要的两个展开说。

这些参数没有一个能靠拍脑袋定死，都得结合你的数据存储、IO 带宽和模型复杂度来调。但有一些基本规律可以参考。

3.2 num_workers 和 prefetch_factor 的组合魔法

num_workers是影响数据加载速度最直接的因素。它决定启动几个子进程来并行执行 Dataset 的__getitem__和 collate 流程。num_workers=0表示所有数据在主进程同步获取，这种情况下你的训练循环每迭代一次都要等数据准备好，一旦读文件稍慢，GPU 就空转。

理论上num_workers越大，并行加载能力越强，但它受几个硬约束：

• 磁盘 IO 是瓶颈：如果数据在机械硬盘上，随机读取大量小文件时磁盘寻道时间很长，开 32 个 worker 无非是让所有进程一起等磁盘。
• 内存是瓶颈：每个 worker 会预取数据，prefetch_factor=2意味着每个 worker 在内存里多放 2 个 batch。num_workers=8时，内存里最多缓存 16 个 batch，如果你的 batch 很大（比如视频帧、高分辨率图），内存可能先爆。
• 进程通信是瓶颈：worker 数过多时，主进程收集数据、张量在进程间序列化/反序列化的开销会显著上升，性能不升反降。

我自己的调参习惯是：先从num_workers=4起步，然后观察 GPU 利用率。如果 GPU 利用率在 90% 以上，就不用加了。如果明显看到训练过程中 GPU 利用率周期性掉下去，说明数据供给跟不上，加num_workers或调大prefetch_factor。

prefetch_factor的作用是让每个 worker 提前准备多个 batch，而不是等上一个 batch 被取走再开始下一个。这个参数在数据加载时间波动比较大时特别有效——比如某些样本特别大、某些特别小，预取几个 batch 可以让慢样本被“藏”在流水线里。

有一点别忽略：prefetch_factor=2是默认值，但 PyTorch 要求它至少为 2。如果你想调大，按倍数来试，比如 4、8，同时留意内存占用。如果内存本身很紧张，优先加num_workers而不是prefetch_factor。

3.3 pin_memory 和 non_blocking 的配合

pin_memory=True会把 DataLoader 产出的 batch 张量放在页锁定内存里。页锁定内存是一种特殊的内存区域，GPU 从这种内存拷贝数据到显存时可以使用更快的 DMA 传输，而且这个传输是异步的，不会阻塞 CPU 计算。

但这有一个前提：你在把数据搬到 GPU 时要配合non_blocking=True：

images = images.to(device, non_blocking=True) labels = labels.to(device, non_blocking=True)

如果你pin_memory=True但.to()没有设置non_blocking=True，虽然拷贝仍然走 pin 内存路径，但同步等待会让一部分加速效果打折扣。反过来，如果你pin_memory=False却设置了non_blocking=True，PyTorch 会忽略这个标志，不会出错，但也拿不到性能收益。

pin_memory也不是没有代价。页锁定内存不能参与系统内存的常规换页，大量使用会减少可用于其他用途的内存。如果你的机器内存本来就很紧张，或者训练数据很大需要缓存，那pin_memory=True可能让系统开始频繁 swap，反而变慢。我一般只在显存训练开，CPU 推理或者内存吃紧时关掉。

3.4 不同硬件场景的参考配置

结合我自己的实测经验，给一个起点参数配置表，你可以按这个去试，再继续往两个方向调：

这套配置不是最优解，只是起步值。真正最优必须结合数据大小、存储类型、图像尺寸来实测，没有银弹。

4. 实测中躲不掉的坑与排查链路

4.1 推理阶段必须关掉的三个开关

很多人在训练时调好的 DataLoader，直接拿去跑推理，结果出了问题。

第一个是shuffle。推理阶段你把shuffle=True留着，预测结果的顺序就和原始样本顺序对不上，后面做评估或者导出预测文件时很容易错位。推理时设shuffle=False。

第二个是drop_last。如果你在推理时还开着drop_last=True，最后一批不足 batch_size 的样本会被直接丢弃，导致你永远漏掉末尾几个样本。如果业务要求必须逐条预测，推理时干脆batch_size=1，或者drop_last=False。

第三个是num_workers。推理时数据加载一般不是瓶颈，反而多进程的启动开销会拖慢冷启动。我更建议推理时num_workers=0，如果确实吞吐上不去再加 worker。还有，pin_memory在纯 CPU 推理时不会带来好处，反而多做了内存锁定，关掉它。

核心原则是：训练时的 DataLoader 配置是为了压榨吞吐，推理时的配置是为了确定性和低延迟，两者目标不同，不要直接复用。

4.2 可变长样本的 collate_fn 到底怎么写才合理

变长序列的 padding 方向有讲究。刚才给的示例是最基础的版本，但实际项目中还有不少细节要补：

pad 的方向。如果序列是时间维度，一般是在尾部补pad_token_id；但如果是音频特征或某些卷积模型，也可能希望左 padding 保持对齐。你需要在 collate_fn 里显式控制，而不是依赖默认行为。

pad 值的选择。NLP 里通常用 0 或 tokenizer 的pad_token_id。如果你的模型有位置编码，padding 位置也必须参与位置编码计算，只是 loss 里被 mask 掉。很多人只在输入里 pad，却忘了返回 mask，这是导致训练指标和实际不符的常见原因。

多字段 padding。如果一条样本里既有input_ids又有attention_mask还有token_type_ids，这几个字段的 padding 必须同步，不能各自为政。我习惯把一条样本组织成 dict：

def collate_dict_batch(batch): input_ids = [item["input_ids"] for item in batch] labels = [item["labels"] for item in batch] # 根据 input_ids 的长度做同步 padding ... return {"input_ids": padded_ids, "attention_mask": mask, "labels": labels}

这样返回一个 dict，模型前向时直接model(**batch)，代码会清爽很多。

4.3 多进程 worker 的“重新实例化”陷阱

这个坑我猜很多人踩过。当你设置num_workers>0，DataLoader 会用多进程来跑Dataset.__getitem__。关键问题在于：每个 worker 子进程在启动时都会重新执行一遍 Dataset 的__init__。

如果你的__init__里有昂贵的操作，比如全量扫描文件列表、读入全部数据到内存、建立复杂的索引结构，那这些操作会被重复执行num_workers次。在 Linux 上默认 fork 方式启动子进程时，子进程会继承父进程的内存，所以如果你的 Dataset 实例在初始化时已经把数据读进了内存，子进程可以“看到”同一份数据，不算太糟。但在 Windows 或使用 spawn 方式时，子进程会重新导入模块、重新执行__init__，开销就完全暴露出来了。

更隐蔽的问题是：如果你在__init__里创建了文件句柄、数据库游标、随机数生成器等对象，这些对象被 fork 到子进程后可能处于不正确的状态。我遇到过在 Dataset 初始化时打开一个文件句柄，在__getitem__里读取，结果多进程下每个 worker 都持有同一个偏移位置，导致读出来的数据错乱。

我的建议是两句话：

• 把重的、一次性的资源尽量放到__getitem__或第一次调用时再懒加载，避免在__init__里持有跨进程共享的可变状态。
• 把需要全局唯一的东西（比如 epoch 计数、随机种子）放在 worker 外面管理，不要依赖 Dataset 内部状态。

如果你的__init__确实必须加载大对象，那么优先考虑用 Linux 的 fork 方式，并确认你不需要修改这些对象；否则就把大对象的加载挪出去，在外部先加载好，作为全局变量供 Dataset 读取。

4.4 分布式训练时 Sampler 的隐蔽问题

单卡训练时shuffle=True没什么问题，但多卡训练时如果每个进程都独立用shuffle=True，就会出现一个严重问题：不同进程拿到的 batch 样本不完全对齐，每个进程自己“随机”打乱，全局看来数据分布不均匀，甚至某些样本被多个进程重复看到，另一些样本从未出现。

正确做法是使用DistributedSampler：

from torch.utils.data.distributed import DistributedSampler sampler = DistributedSampler( dataset, num_replicas=world_size, rank=rank, shuffle=True, ) loader = DataLoader( dataset, batch_size=32, sampler=sampler, num_workers=4, )

分布式场景，DataLoader的shuffle参数应该保持False，由Sampler来控制打乱。还有一个必须注意的细节：DistributedSampler要求训练循环里每个 epoch 调用sampler.set_epoch(epoch)，否则每个 epoch 的划分和打乱顺序会完全一样，模型相当于每轮看到同样的数据排列，对 BN 和收敛都有影响。

for epoch in range(epochs): sampler.set_epoch(epoch) for batch in loader: ...

这个错误写进代码里不会有任何报错，但模型收敛质量和最终精度可能莫名其妙地比别人差一截，排查起来很费劲。

4.5 一次数据加载变慢的完整排查链路

分享一次实际排查经历。某次在 SSD 上训练视频分类模型，GPU 利用率始终在 40% 到 70% 之间大幅跳动，显存占用稳定但利用率不饱和。我当时按这个链条做了排查：

第一步，先排除是不是模型计算慢。把 DataLoader 的num_workers调到 0，让数据加载变成同步，观察单步耗时。结果发现单步总耗时 1.2 秒，模型前向反向只需要 0.4 秒，数据加载占了接近 0.8 秒，问题基本锁在数据侧。

第二步，缩小范围。分别测试：只读文件不做 transform、只做 transform 不读文件。发现读文件这部分很慢，因为数据是大量小视频帧，每帧单独一个文件，随机读取海量小文件恰恰是 SSD 最不擅长的工作。这里一定不要忽略存储介质的特性。

第三步，调整参数。提高num_workers从 4 到 8，变化不明显；把prefetch_factor从 2 提到 8，GPU 利用率终于稳定在 85% 以上。原因是每个样本的读取时间差异很大，预取多个 batch 能有效抹平波动，单纯加 worker 反而加剧了磁盘 IO 争抢。

这里可以做一个简单的排查对照表，方便你以后快速定位：

这套排查方法的关键是：先定性，再定量。很多人在数据加载慢时直接盲目调num_workers，其实可能问题根本在读写模式或预取配置上。

5. 进阶思考：哪些场景不该用 DataLoader

5.1 对比学习和自定义负采样

DataLoader 的设计目标是“从数据集中均匀采样并组成 batch”。但对比学习这类任务，需要在一个 batch 内构造正负样本对，或者保证负样本来自特定分布，这时候默认的采样策略就失效了。

比如 SimCLR 这类对比学习方法，一个 batch 里的样本经过两种不同的数据增强得到两个视图，它们天然构成正样本对，剩下 batch 内其他样本都是负样本。这个逻辑本身不复杂，复杂的是“两个视图的数据增强必须针对同一条原始样本”。如果你在 Dataset 的__getitem__里做两次增强，再靠默认 collate_fn 拼装，也能实现，但很容易在并行 worker 上造成麻烦——因为同一个 idx 可能被不同的 worker 取到，或者在 batch 内随机顺序打乱了视图对。

更稳妥的做法是：用 DataLoader 只负责采样原始样本，数据增强和视图拼接放在训练循环外部或者自定义 BatchSampler 里做。这种场景下，DataLoader 只是“食材配送”，真正做组合菜的是你后厨的手艺。

同样道理，负采样任务如果你想控制“每个 batch 里谁的负样本是谁”，Default BatchSampler 给不了你这么精细的控制。需要自定义BatchSampler，自己定义索引组合规则，再传给 DataLoader。

5.2 蒸馏、多模态对齐等复杂标签结构的场景

知识蒸馏里，student 的输入和 teacher 的输入往往不完全一样，比如 teacher 输入更大尺寸的图，student 输入小尺寸；或者 teacher 需要额外的时序信息。如果硬塞进同一个 Dataset 和 collate_fn，代码会迅速变得难以维护。

我的建议是：当数据流目标不一致时，拆成多个 DataLoader，而不是硬塞进一个 Dataset。比如 teacher 的输入单独一个 loader，student 的输入单独一个 loader，训练循环里用同一个随机种子或索引对齐来维持两个 batch 的对应关系。这样做代码结构清晰，调试定位也方便。

多模态对齐任务也有类似问题——文本、图像、音频各自由独立的处理流程生成，输入长度和特征类型完全不一致。强行在一个__getitem__里让它们同步返回，不仅难写，而且一旦某一模态的数据有缺失，整个 batch 都要遭殃。

5.3 全局统计类预处理要在离线阶段完成

常见的数据归一化需要用到整个训练集的 mean 和 std，比如 CV 里常用的Normalize(mean, std)。不少人图省事，在 Dataset 或 collate_fn 里动态计算统计量，这是不对的。

如果每个 batch 单独算 mean/std 做归一化，你相当于对每个 batch 做了“独立标准化”，这等于把输入分布强行拉齐到一个固定均值 0 方差 1，原始数据的相对分布信息全被破坏了。正确的做法是：先用离线脚本扫一遍训练集，算好全局 mean 和 std，再写死在 transform 里。DataLoader 只负责调度，不负责统计全局信息。

同样的道理还适用一些数据清洗逻辑：比如你想对整个数据集的标签分布做重采样、做类别均衡，这属于全局采样策略，应该通过WeightedRandomSampler这类组件解决，而不是在 Dataset 内部偷偷改概率。

5.4 把 Dataset 保持“薄”一点，复杂逻辑放外面

写了几年数据管线后，我最大的一个感悟是：Dataset 和 DataLoader 最好的状态是“薄而稳定”。它们只负责“通过索引拿到训练所需的张量”，而不是把所有业务逻辑都塞进来。

我见过一种把数据清洗、增强、动态负采样、云端上传日志都写在__getitem__里的设计，结果训练一跑起来，worker 进程里各种网络请求、磁盘写入，GPU 利用率一塌糊涂，而且出了错极难定位。

正确的分层是：

• 离线阶段：数据清洗、统计、去重、预切分、计算归一化参数
• Dataset 内：读取原始数据、轻量 transform、返回样本
• DataLoader 层：采样策略、batch 拼装、多进程调度
• 训练循环外：复杂增强、视图构造、负采样组合、loss 组织

遵循这个分层，绝大多数数据加载问题都能快速定位到底是哪一层出的问题。改起来也自信得多——动了 Dataset 不会影响采样逻辑，动了 collate_fn 不会影响数据读取。

数据加载看起来是入门知识，但真正把它用得顺手，需要你对底层协作机制有清晰的认识。我自己的体会是，几乎所有训练异常，要么是数据流没打通，要么是配置参数跟硬件不匹配。先跑通一个小 batch 验证数据正确性，再逐个调性能参数，最后把分布式和特殊采样策略控制在合理的边界内，DataLoader 就会像一个训练脚本里的原动力一样，安静又高效地供给你每一个 batch。碰到问题别慌，拆成“取数、打乱、拼装、调度”四件事，一件一件检查，大多数坑都能在半小时内定位出来。