使用pytorch时，训练集数据太多达到上千万张，Dataloader加载很慢怎么办?
数据量达到上千万张，PyTorch DataLoader 加载慢确实是个棘手的问题，直接影响训练效率。这背后有很多潜在的瓶颈，需要我们逐一排查和优化。我将从多个层面详细阐述，希望能帮你找到症结所在，并提供切实可行的解决方案。
一、 理解 DataLoader 的工作流程与潜在瓶颈
在深入优化之前，先回顾一下 DataLoader 的基本工作方式，才能更精准地定位问题：
1. Worker Processes: `DataLoader` 默认会启动多个子进程（workers）来并行加载数据。这些子进程负责从磁盘读取数据，进行预处理（如解码、变换），并将处理好的数据批量（batch）地放入一个队列（queue）中。
2. Main Process: 主进程（即你的训练脚本）则从这个队列中拉取（fetch）数据批次，然后送入 GPU 进行训练。
3. Potential Bottlenecks:
数据读取速度: 磁盘 I/O 是最常见的瓶颈。如果你的存储设备（HDD, SATA SSD, NVMe SSD）速度跟不上数据加载需求，或者文件系统本身有性能问题，就会很慢。
数据预处理: 图像解码（JPEG, PNG）、数据增强（随机裁剪、翻转、颜色抖动等）这些操作如果计算量很大，并且在 CPU 上执行，也会拖慢速度。
Worker 进程之间的通信: 即使子进程加载得很快，主进程从队列中拉取数据也需要时间。队列的大小、数据传输的效率也会有影响。
多进程同步开销: 尽管多进程是提速的关键，但进程间的通信和同步本身也需要一定的开销。
GPU 闲置: 如果 CPU 加载数据的速度慢于 GPU 的计算速度，GPU 就会出现饥饿（starvation），得不到及时喂养，这正是我们极力避免的。
二、 详细的优化策略与实践
有了以上理解，我们就可以开始逐个击破了。
1. 优化数据存储与读取
这是最基础也是最重要的一步。
使用更快的存储设备:
NVMe SSD: 如果你还在使用 HDD 或 SATA SSD，升级到 NVMe SSD 会带来质的飞跃。DataLoader 加载速度的提升往往是数量级的。
SSD RAID: 如果你的数据量极大，可以将多块 SSD 组成 RAID 阵列，进一步提升并行 I/O 能力。
优化文件组织:
避免大量小文件: 大量分散的小文件会增加文件系统的查找开销和 I/O 寻址时间。如果你的数据都是图片，可以考虑将它们打包成TFRecord (TensorFlow Record)、LMDB (Lightning MemoryMapped Database)、WebDataset 等更适合批量读取的格式。
LMDB: 这是一个非常流行的选择。它将所有数据存储在一个文件（或一组文件）中，提供了高效的内存映射访问，避免了大量小文件的开销。PyTorch 社区也有很多基于 LMDB 的数据加载库。
WebDataset: 专门为 PyTorch 设计，适合存储在对象存储（如 S3）上，也可以用于本地存储。它将数据打包成tar文件，支持流式读取，非常灵活。
TFRecord: 虽然是 TensorFlow 的格式，但 PyTorch 也可以通过 `tfrecord` 库进行读取，它将数据序列化成二进制格式，便于批量读取。
数据局部性: 尽量将相关数据放在一起，虽然对于随机采样的数据集来说效果有限，但对于顺序读取或局部读取的场景会有帮助。
使用内存映射（Memory Mapping）:
如果你的数据集可以完全加载到内存（RAM），这是最理想的情况。但上千万张图片通常内存不足。
对于无法完全加载的情况，LMDB 等格式本身就提供了内存映射的机制，允许操作系统高效地管理数据在内存和磁盘之间的映射，减少不必要的复制。
2. 优化数据预处理
预处理是 CPU 的主要工作，也是一个常见的瓶颈。
调整 `num_workers`:
`DataLoader(..., num_workers=N)` 中的 `N` 是最重要的参数之一。它决定了有多少个子进程并行加载数据。
如何选择 `N`？
经验法则: 通常设置为 CPU 核心数的 24 倍。但不是越多越好，过多的进程会增加进程间通信的开销和内存占用。
性能测试: 最好的方法是实际测试。从 `N=0` (单进程) 开始，逐步增加 `N`，观察 GPU 利用率和训练速度。当 GPU 利用率不再显著提升，甚至开始下降时，就找到了一个合适的 `N`。
注意: 你的 GPU 数量也需要考虑。如果你有多个 GPU，每个 GPU 应该有其独立的 DataLoader 实例，并且 `num_workers` 的选择也需要根据总 CPU 资源来平衡。
CPU 预处理提速:
优化数据增强:
使用 OpenCV (cv2) 或 PIL 的高效操作: 确保你使用的图像处理库是高效的。OpenCV 通常比 PIL 更快，尤其是在执行批量操作时。
GPU 数据增强 (DALI, TorchVision transform on GPU): 对于非常耗时的增强操作（如复杂的几何变换、颜色空间转换），可以考虑将这些操作放到 GPU 上执行。NVIDIA DALI (Deep Learning Accelerator) 是一个非常强大的库，可以实现 GPU 加速的数据加载和预处理。TorchVision 也在逐步支持 GPU 上的 transforms。
预先计算/缓存: 如果你的数据集是固定的，并且某些复杂的预处理操作可以提前完成，可以考虑将预处理后的数据保存下来，下次直接加载。但这会增加存储空间。
选择合适的 Transforms: 某些 transforms 计算量非常大，例如复杂的风格迁移或特征提取。审视你的数据增强策略，是否所有操作都是必需的。
多进程下的预处理: `num_workers` 已经实现了预处理的并行化，但确保你的预处理函数本身是线程安全的（虽然在多进程下，每个进程有自己的内存空间，但如果预处理函数依赖于共享资源，就需要注意）。
使用 `pin_memory=True`:
`DataLoader(..., pin_memory=True)` 会将加载到 CPU 内存的数据预先“锁定”在页内存（pagelocked memory）中。
好处: 当数据从 CPU 传输到 GPU 时，可以使用更快的异步 DMA (Direct Memory Access) 传输，避免 CPU 参与数据复制，减少 CPU 占用，提升传输速度。
前提: 需要你的系统有足够的页内存。通常情况下，设置为 `True` 是有益的。
`prefetch_factor`:
`DataLoader(..., prefetch_factor=N)` (PyTorch 1.7+)。它控制着每个 worker 进程在将数据放入队列之前，会预先加载多少个 batch。
作用: 增加 `prefetch_factor` 可以让 worker 进程更积极地预加载数据，从而可能填充DataLoader队列，减少主进程等待数据的时间。
如何选择: 结合 `num_workers` 和你的 GPU 计算速度来调整。一个合理的起点可以是 `prefetch_factor=2` 或 `3`。
3. 优化 DataLoader 本身和数据流水线
`persistent_workers=True`:
`DataLoader(..., persistent_workers=True)` (PyTorch 1.7+)。它会保持 worker 进程的存活，而不是在每个 epoch 结束后关闭它们。
好处: 避免了频繁启动和关闭子进程的开销，尤其是当你的预处理非常耗时时，这种开销会很显著。
注意: 只有当你的 `num_workers > 0` 时才有意义。如果你的数据集很大，并且预处理相对较快，`persistent_workers=True` 会很有帮助。
`collate_fn` 的效率:
`collate_fn` 是将一个 batch 中的多个样本合并成一个 tensor 的函数。默认的 `collate_fn` 对于大多数情况是高效的。
自定义 `collate_fn`: 如果你的数据样本结构复杂（例如，变长的序列、具有不同形状的标注），你可能需要自定义 `collate_fn`。确保你自定义的 `collate_fn` 是高效的，避免不必要的复制或复杂的逻辑。
示例: 如果你的数据是成对的 (image, label)，默认会帮你堆叠起来。如果你有更复杂的元数据，需要考虑如何高效地合并。
数据采样器 (Sampler):
`RandomSampler`: 默认用于训练。
`SequentialSampler`: 用于验证和测试。
`WeightedRandomSampler`: 如果类别不平衡，可以使用它来按照权重采样。
重要性: Sampler 的效率通常不是瓶颈，但如果你的数据集非常大，并且有特定的采样需求（例如，某些样本出现频率要高），一个高效的 Sampler 也很关键。
4. 监控与诊断
GPU 利用率: 使用 `nvidiasmi` 或 `nvtop` 监控 GPU 利用率。如果 GPU 利用率长期低于 8090%，说明数据加载或 CPU 预处理是瓶颈。
CPU 使用率: 监控每个 CPU 核心的使用率。如果某个核心或所有核心都持续满载，而 GPU 利用率不高，那说明 CPU 预处理是瓶颈。
内存占用: 监控系统内存和 GPU 显存。
PyTorch Profiler: PyTorch 提供了强大的 Profiler 工具，可以帮助你精确地分析代码的执行时间。你可以用它来查看 `DataLoader` 中各个部分的耗时，例如 `get_item`、`collate_fn`、`worker` 进程的耗时等。
```python
import torch
from torch.profiler import profile, record_function, ProfilerActivity
... your DataLoader setup ...
with profile(activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA], record_shapes=True) as prof:
with record_function("data_loading"):
for batch in dataloader:
... your training step ...
break Just for profiling one batch
print(prof.key_averages().table(sort_by="cpu_time_total", row_limit=10))
或者 prof.export_chrome_trace("trace.json") 在 Chrome 中打开 trace.json 查看
```
这个工具可以帮助你 pinpoint 到底是在数据读取、解码、增强，还是数据传输上花费了时间。
5. 实际操作建议总结
1. 优先级最高:
优化存储: 确保你的数据存储在速度够快的 SSD 上，最好是 NVMe SSD。
打包数据格式: 考虑使用 LMDB, WebDataset, TFRecord 等格式。
调整 `num_workers`: 通过实验找到最佳值，通常是 CPU 核心数的 24 倍。
启用 `pin_memory=True`: 几乎总是推荐开启。
2. 次优先级，但也很重要:
`persistent_workers=True`: 尤其当你使用较大的 `num_workers` 时。
GPU 加速预处理: 如果预处理非常耗时，研究 DALI 或 TorchVision GPU transforms。
`prefetch_factor`: 尝试调整以进一步平滑数据加载。
3. 深入诊断:
使用 Profiler: 当上述措施效果不明显时，用 Profiler 精确找出瓶颈。
举个具体案例的思考路径:
假设你的数据是上千万张 JPEG 图片，存储在 SATA SSD 上，每次训练时，DataLoader 加载特别慢，GPU 利用率只有 30%。
第一步诊断:
`nvidiasmi` 显示 GPU 空闲很多。
`htop` 或任务管理器显示 CPU 核心使用率不高，或者某个核心偶尔飙升。
初步判断: 很可能是 I/O 瓶颈或 CPU 预处理效率不高。
优化方案:
1. 存储: 将数据迁移到 NVMe SSD。
2. 格式: 将 JPEG 图片打包成 LMDB 文件。
3. Worker: 尝试增加 `num_workers`，比如你的 CPU 有 16 核，可以尝试 `num_workers=32`。
4. 内存: 确保 `pin_memory=True`。
5. 持久化: 启用 `persistent_workers=True`。
后续调整:
如果 GPU 利用率仍然不高，且 CPU 核心开始饱和，那么需要检查你的数据增强操作是否过重。
考虑使用 GPU 加速的图像解码库，或者将部分数据增强移至 GPU。
如果 CPU 核心使用率仍然不高，但 DataLoader 速度上不去，可能需要使用 PyTorch Profiler 来精确定位问题，看看是 `getitem` 里的哪个操作慢，还是 `collate_fn` 有问题。
最后的总结:
处理上千万级数据集的 DataLoader 加载问题，是一个系统工程，需要耐心和细致的排查。没有一蹴而就的万能药，但通过上述从数据存储、格式、预处理、Worker 配置到性能监控的全面优化，你一定能显著提升数据加载速度，充分释放 GPU 的计算能力，加速你的模型训练进程。记住，监控和实验是找到最佳解决方案的关键。
一、 理解 DataLoader 的工作流程与潜在瓶颈
在深入优化之前，先回顾一下 DataLoader 的基本工作方式，才能更精准地定位问题：
1. Worker Processes: `DataLoader` 默认会启动多个子进程（workers）来并行加载数据。这些子进程负责从磁盘读取数据，进行预处理（如解码、变换），并将处理好的数据批量（batch）地放入一个队列（queue）中。
2. Main Process: 主进程（即你的训练脚本）则从这个队列中拉取（fetch）数据批次，然后送入 GPU 进行训练。
3. Potential Bottlenecks:
数据读取速度: 磁盘 I/O 是最常见的瓶颈。如果你的存储设备（HDD, SATA SSD, NVMe SSD）速度跟不上数据加载需求，或者文件系统本身有性能问题，就会很慢。
数据预处理: 图像解码（JPEG, PNG）、数据增强（随机裁剪、翻转、颜色抖动等）这些操作如果计算量很大，并且在 CPU 上执行，也会拖慢速度。
Worker 进程之间的通信: 即使子进程加载得很快，主进程从队列中拉取数据也需要时间。队列的大小、数据传输的效率也会有影响。
多进程同步开销: 尽管多进程是提速的关键，但进程间的通信和同步本身也需要一定的开销。
GPU 闲置: 如果 CPU 加载数据的速度慢于 GPU 的计算速度，GPU 就会出现饥饿（starvation），得不到及时喂养，这正是我们极力避免的。
二、 详细的优化策略与实践
有了以上理解，我们就可以开始逐个击破了。
1. 优化数据存储与读取
这是最基础也是最重要的一步。
使用更快的存储设备:
NVMe SSD: 如果你还在使用 HDD 或 SATA SSD，升级到 NVMe SSD 会带来质的飞跃。DataLoader 加载速度的提升往往是数量级的。
SSD RAID: 如果你的数据量极大，可以将多块 SSD 组成 RAID 阵列，进一步提升并行 I/O 能力。
优化文件组织:
避免大量小文件: 大量分散的小文件会增加文件系统的查找开销和 I/O 寻址时间。如果你的数据都是图片，可以考虑将它们打包成TFRecord (TensorFlow Record)、LMDB (Lightning MemoryMapped Database)、WebDataset 等更适合批量读取的格式。
LMDB: 这是一个非常流行的选择。它将所有数据存储在一个文件（或一组文件）中，提供了高效的内存映射访问，避免了大量小文件的开销。PyTorch 社区也有很多基于 LMDB 的数据加载库。
WebDataset: 专门为 PyTorch 设计，适合存储在对象存储（如 S3）上，也可以用于本地存储。它将数据打包成tar文件，支持流式读取，非常灵活。
TFRecord: 虽然是 TensorFlow 的格式，但 PyTorch 也可以通过 `tfrecord` 库进行读取，它将数据序列化成二进制格式，便于批量读取。
数据局部性: 尽量将相关数据放在一起，虽然对于随机采样的数据集来说效果有限，但对于顺序读取或局部读取的场景会有帮助。
使用内存映射（Memory Mapping）:
如果你的数据集可以完全加载到内存（RAM），这是最理想的情况。但上千万张图片通常内存不足。
对于无法完全加载的情况，LMDB 等格式本身就提供了内存映射的机制，允许操作系统高效地管理数据在内存和磁盘之间的映射，减少不必要的复制。
2. 优化数据预处理
预处理是 CPU 的主要工作，也是一个常见的瓶颈。
调整 `num_workers`:
`DataLoader(..., num_workers=N)` 中的 `N` 是最重要的参数之一。它决定了有多少个子进程并行加载数据。
如何选择 `N`？
经验法则: 通常设置为 CPU 核心数的 24 倍。但不是越多越好，过多的进程会增加进程间通信的开销和内存占用。
性能测试: 最好的方法是实际测试。从 `N=0` (单进程) 开始，逐步增加 `N`，观察 GPU 利用率和训练速度。当 GPU 利用率不再显著提升，甚至开始下降时，就找到了一个合适的 `N`。
注意: 你的 GPU 数量也需要考虑。如果你有多个 GPU，每个 GPU 应该有其独立的 DataLoader 实例，并且 `num_workers` 的选择也需要根据总 CPU 资源来平衡。
CPU 预处理提速:
优化数据增强:
使用 OpenCV (cv2) 或 PIL 的高效操作: 确保你使用的图像处理库是高效的。OpenCV 通常比 PIL 更快，尤其是在执行批量操作时。
GPU 数据增强 (DALI, TorchVision transform on GPU): 对于非常耗时的增强操作（如复杂的几何变换、颜色空间转换），可以考虑将这些操作放到 GPU 上执行。NVIDIA DALI (Deep Learning Accelerator) 是一个非常强大的库，可以实现 GPU 加速的数据加载和预处理。TorchVision 也在逐步支持 GPU 上的 transforms。
预先计算/缓存: 如果你的数据集是固定的，并且某些复杂的预处理操作可以提前完成，可以考虑将预处理后的数据保存下来，下次直接加载。但这会增加存储空间。
选择合适的 Transforms: 某些 transforms 计算量非常大，例如复杂的风格迁移或特征提取。审视你的数据增强策略，是否所有操作都是必需的。
多进程下的预处理: `num_workers` 已经实现了预处理的并行化，但确保你的预处理函数本身是线程安全的（虽然在多进程下，每个进程有自己的内存空间，但如果预处理函数依赖于共享资源，就需要注意）。
使用 `pin_memory=True`:
`DataLoader(..., pin_memory=True)` 会将加载到 CPU 内存的数据预先“锁定”在页内存（pagelocked memory）中。
好处: 当数据从 CPU 传输到 GPU 时，可以使用更快的异步 DMA (Direct Memory Access) 传输，避免 CPU 参与数据复制，减少 CPU 占用，提升传输速度。
前提: 需要你的系统有足够的页内存。通常情况下，设置为 `True` 是有益的。
`prefetch_factor`:
`DataLoader(..., prefetch_factor=N)` (PyTorch 1.7+)。它控制着每个 worker 进程在将数据放入队列之前，会预先加载多少个 batch。
作用: 增加 `prefetch_factor` 可以让 worker 进程更积极地预加载数据，从而可能填充DataLoader队列，减少主进程等待数据的时间。
如何选择: 结合 `num_workers` 和你的 GPU 计算速度来调整。一个合理的起点可以是 `prefetch_factor=2` 或 `3`。
3. 优化 DataLoader 本身和数据流水线
`persistent_workers=True`:
`DataLoader(..., persistent_workers=True)` (PyTorch 1.7+)。它会保持 worker 进程的存活，而不是在每个 epoch 结束后关闭它们。
好处: 避免了频繁启动和关闭子进程的开销，尤其是当你的预处理非常耗时时，这种开销会很显著。
注意: 只有当你的 `num_workers > 0` 时才有意义。如果你的数据集很大，并且预处理相对较快，`persistent_workers=True` 会很有帮助。
`collate_fn` 的效率:
`collate_fn` 是将一个 batch 中的多个样本合并成一个 tensor 的函数。默认的 `collate_fn` 对于大多数情况是高效的。
自定义 `collate_fn`: 如果你的数据样本结构复杂（例如，变长的序列、具有不同形状的标注），你可能需要自定义 `collate_fn`。确保你自定义的 `collate_fn` 是高效的，避免不必要的复制或复杂的逻辑。
示例: 如果你的数据是成对的 (image, label)，默认会帮你堆叠起来。如果你有更复杂的元数据，需要考虑如何高效地合并。
数据采样器 (Sampler):
`RandomSampler`: 默认用于训练。
`SequentialSampler`: 用于验证和测试。
`WeightedRandomSampler`: 如果类别不平衡，可以使用它来按照权重采样。
重要性: Sampler 的效率通常不是瓶颈，但如果你的数据集非常大，并且有特定的采样需求（例如，某些样本出现频率要高），一个高效的 Sampler 也很关键。
4. 监控与诊断
GPU 利用率: 使用 `nvidiasmi` 或 `nvtop` 监控 GPU 利用率。如果 GPU 利用率长期低于 8090%，说明数据加载或 CPU 预处理是瓶颈。
CPU 使用率: 监控每个 CPU 核心的使用率。如果某个核心或所有核心都持续满载，而 GPU 利用率不高，那说明 CPU 预处理是瓶颈。
内存占用: 监控系统内存和 GPU 显存。
PyTorch Profiler: PyTorch 提供了强大的 Profiler 工具，可以帮助你精确地分析代码的执行时间。你可以用它来查看 `DataLoader` 中各个部分的耗时，例如 `get_item`、`collate_fn`、`worker` 进程的耗时等。
```python
import torch
from torch.profiler import profile, record_function, ProfilerActivity
... your DataLoader setup ...
with profile(activities=[ProfilerActivity.CPU, ProfilerActivity.CUDA], record_shapes=True) as prof:
with record_function("data_loading"):
for batch in dataloader:
... your training step ...
break Just for profiling one batch
print(prof.key_averages().table(sort_by="cpu_time_total", row_limit=10))
或者 prof.export_chrome_trace("trace.json") 在 Chrome 中打开 trace.json 查看
```
这个工具可以帮助你 pinpoint 到底是在数据读取、解码、增强，还是数据传输上花费了时间。
5. 实际操作建议总结
1. 优先级最高:
优化存储: 确保你的数据存储在速度够快的 SSD 上，最好是 NVMe SSD。
打包数据格式: 考虑使用 LMDB, WebDataset, TFRecord 等格式。
调整 `num_workers`: 通过实验找到最佳值，通常是 CPU 核心数的 24 倍。
启用 `pin_memory=True`: 几乎总是推荐开启。
2. 次优先级，但也很重要:
`persistent_workers=True`: 尤其当你使用较大的 `num_workers` 时。
GPU 加速预处理: 如果预处理非常耗时，研究 DALI 或 TorchVision GPU transforms。
`prefetch_factor`: 尝试调整以进一步平滑数据加载。
3. 深入诊断:
使用 Profiler: 当上述措施效果不明显时，用 Profiler 精确找出瓶颈。
举个具体案例的思考路径:
假设你的数据是上千万张 JPEG 图片，存储在 SATA SSD 上，每次训练时，DataLoader 加载特别慢，GPU 利用率只有 30%。
第一步诊断:
`nvidiasmi` 显示 GPU 空闲很多。
`htop` 或任务管理器显示 CPU 核心使用率不高，或者某个核心偶尔飙升。
初步判断: 很可能是 I/O 瓶颈或 CPU 预处理效率不高。
优化方案:
1. 存储: 将数据迁移到 NVMe SSD。
2. 格式: 将 JPEG 图片打包成 LMDB 文件。
3. Worker: 尝试增加 `num_workers`，比如你的 CPU 有 16 核，可以尝试 `num_workers=32`。
4. 内存: 确保 `pin_memory=True`。
5. 持久化: 启用 `persistent_workers=True`。
后续调整:
如果 GPU 利用率仍然不高，且 CPU 核心开始饱和，那么需要检查你的数据增强操作是否过重。
考虑使用 GPU 加速的图像解码库，或者将部分数据增强移至 GPU。
如果 CPU 核心使用率仍然不高，但 DataLoader 速度上不去，可能需要使用 PyTorch Profiler 来精确定位问题，看看是 `getitem` 里的哪个操作慢，还是 `collate_fn` 有问题。
最后的总结:
处理上千万级数据集的 DataLoader 加载问题，是一个系统工程，需要耐心和细致的排查。没有一蹴而就的万能药，但通过上述从数据存储、格式、预处理、Worker 配置到性能监控的全面优化，你一定能显著提升数据加载速度，充分释放 GPU 的计算能力，加速你的模型训练进程。记住，监控和实验是找到最佳解决方案的关键。
网友意见
下面是我见到过的写得最优雅的,预加载的dataloader迭代方式可以参考下:
使用方法就和普通dataloder一样 for xxx in trainloader .
主要思想就两点 , 第一重载 _iter 和 next_ ,第二点多线程异步Queue加载
import numbers import os import queue as Queue import threading import mxnet as mx import numpy as np import torch from torch.utils.data import DataLoader, Dataset from torchvision import transforms class BackgroundGenerator(threading.Thread): def __init__(self, generator, local_rank, max_prefetch=6): super(BackgroundGenerator, self).__init__() self.queue = Queue.Queue(max_prefetch) self.generator = generator self.local_rank = local_rank self.daemon = True self.start() def run(self): torch.cuda.set_device(self.local_rank) for item in self.generator: self.queue.put(item) self.queue.put(None) def next(self): next_item = self.queue.get() if next_item is None: raise StopIteration return next_item def __next__(self): return self.next() def __iter__(self): return self class DataLoaderX(DataLoader): def __init__(self, local_rank, **kwargs): super(DataLoaderX, self).__init__(**kwargs) self.stream = torch.cuda.Stream(local_rank) self.local_rank = local_rank def __iter__(self): self.iter = super(DataLoaderX, self).__iter__() self.iter = BackgroundGenerator(self.iter, self.local_rank) self.preload() return self def preload(self): self.batch = next(self.iter, None) if self.batch is None: return None with torch.cuda.stream(self.stream): for k in range(len(self.batch)): self.batch[k] = self.batch[k].to(device=self.local_rank, non_blocking=True) def __next__(self): torch.cuda.current_stream().wait_stream(self.stream) batch = self.batch if batch is None: raise StopIteration self.preload() return batch class MXFaceDataset(Dataset): def __init__(self, root_dir, local_rank): super(MXFaceDataset, self).__init__() self.transform = transforms.Compose( [transforms.ToPILImage(), transforms.RandomHorizontalFlip(), transforms.ToTensor(), transforms.Normalize(mean=[0.5, 0.5, 0.5], std=[0.5, 0.5, 0.5]), ]) self.root_dir = root_dir self.local_rank = local_rank path_imgrec = os.path.join(root_dir, 'train.rec') path_imgidx = os.path.join(root_dir, 'train.idx') self.imgrec = mx.recordio.MXIndexedRecordIO(path_imgidx, path_imgrec, 'r') s = self.imgrec.read_idx(0) header, _ = mx.recordio.unpack(s) if header.flag > 0: self.header0 = (int(header.label[0]), int(header.label[1])) self.imgidx = np.array(range(1, int(header.label[0]))) else: self.imgidx = np.array(list(self.imgrec.keys)) def __getitem__(self, index): idx = self.imgidx[index] s = self.imgrec.read_idx(idx) header, img = mx.recordio.unpack(s) label = header.label if not isinstance(label, numbers.Number): label = label[0] label = torch.tensor(label, dtype=torch.long) sample = mx.image.imdecode(img).asnumpy() if self.transform is not None: sample = self.transform(sample) return sample, label def __len__(self): return len(self.imgidx) 类似的话题
-
数据量达到上千万张，PyTorch DataLoader 加载慢确实是个棘手的问题，直接影响训练效率。这背后有很多潜在的瓶颈，需要我们逐一排查和优化。我将从多个层面详细阐述，希望能帮你找到症结所在，并提供切实可行的解决方案。一、 理解 DataLoader 的工作流程与潜在瓶颈在深入优化之前，先回顾............. -
使用GPL（GNU General Public License）软件开发产品时，要“避免GPL感染”，其实更准确的说法是如何遵守GPL的条款，同时在你的产品中最大限度地保留你对源代码的控制权，并避免你的专有部分也被强制要求以GPL开源。GPL的本质是“Copyleft”，它的核心目的是确保GNU软.............
-
这个问题很有趣，因为通常情况下，Unix Domain Socket（UDS）被认为在本地进程间通信时比 TCP/IP 回环（`127.0.0.1`）具有更低的延迟和更高的性能。但是，在 Go 中测试 MySQL 查询时，你可能观察到它们之间的差异不大，甚至差不多。这背后可能有多种原因，我们可以从多.............
-
使用 Python 是否会降低程序员的编程能力，这个问题需要从多个角度进行深入分析。Python 作为一种语法简洁、开发效率高的语言，确实可能在某些方面影响程序员的技能发展，但同时也可能带来其他优势。以下是详细的分析： 一、Python 的优势与可能带来的能力提升1. 降低学习门槛，促进快速上手 .............
-
关于“使用料理包成外卖普遍现象，部分成本低至 3 元，保质期长达一年半”的说法，这确实是一个非常普遍也引起广泛关注的现象。那么，对于这样的外卖，我是否能接受，需要从多个角度来详细分析：1. 接受与否的核心考量：食品安全与健康这是我最首要也最关心的方面。一个3元成本、保质期长达一年半的料理包外卖，让我.............
-
这个问题很有意思，它触及了我们对未来交通方式的想象，也牵扯到很多实际的技术难题。 简单地说， 用5G技术坐在家里用方向盘远程开卡车，理论上是有可能实现的，但要做到像玩模拟驾驶游戏那样流畅、安全，并且真正投入商业运营，还有非常多的挑战需要克服。咱们一点点来聊聊这个“在家开卡车”的设想，看看需要哪些条.............
-
这绝对是个非常有趣且富有想象力的问题，让人忍不住去思考这种极端情况下的物理极限。从科学的角度来说，要回答这个问题，我们需要深入探讨几个关键因素：线的材质、强度，以及切割所需的力。首先，我们来谈谈“1纳米细”。纳米是长度单位，1纳米是十亿分之一米。这是一个极其微小的尺度，比我们肉眼所见的任何东西都要小.............
-
在我看来，普遍的认知和观察倾向于认为，历史上以及目前，“搭讪艺术家”（PUA）这个概念和实践，是以男性为主导的。当然，我们不能完全排除女性也可能在某些层面运用类似“搭讪艺术家”的技巧，但从这个术语的起源、发展以及其核心关注点来看，男性角色更为突出。让我来详细解释一下为什么会有这种感觉，以及其中的一些.............
-
用米诺地尔的现在情况，以及对这个东西的了解，我能说得详细点。首先，要明确一点，米诺地尔不是万能药，也不是一劳永逸的解决方案。它是一个治疗雄激素性脱发（也就是我们常说的脂溢性脱发、遗传性脱发）的药物。对其他类型的脱发，比如斑秃、休止期脱发等，效果可能就没那么明显，甚至无效。用了米诺地尔，现在情况怎么样.............
-
既然要讨论超能力飞行的高度安全问题，那咱们就得好好捋一捋，不能只图个痛快。毕竟，这超能力也不是摆设，用得好，那叫神威；用不好，嘿，那可就成地面上的笑话了。首先，得明确一点，咱们说的“安全”是什么意思。不是说我飞到月亮上就能躲开所有危险，也不是说贴着地面就能万事大吉。这里的安全，得考虑多种因素，包括但.............
-
使用 CarPlay 是一种非常现代且集成的体验，它将你的 iPhone 的核心功能无缝地带入你的汽车中，让你可以在驾驶时更安全、更便捷地访问常用应用。以下我将从多个维度为你详细描述这种体验：1. 界面与操作的直观性： 简化和优化： CarPlay 的界面是为驾驶环境量身定制的。图标更大，按钮更.............
-
使用降噪耳机，尤其是主动降噪耳机（Active Noise Cancellation, ANC），是一种相当独特且常常令人惊喜的体验。它与普通入耳式耳机（Passive Noise Isolation, PNI）之间存在着本质的区别，这种区别体现在音频体验、佩戴感受以及适用的场景上。下面我将详细阐述.............
-
安德玛（Under Armour）这牌子吧，用起来什么感觉？嗯，怎么说呢，就像你一个平时不太爱说话的朋友，但一旦开始行动，就特别有力量，而且总是能让你出乎意料。我第一次接触安德玛，是那时候还在上大学，开始跟着几个哥们儿一起去健身房。那时候大家穿的都挺随意，但总有那么几个穿着特别显眼的，我注意到其中有.............
-
椭圆机用完之后小臂会痛，这确实是个不少见的情况。很多人觉得椭圆机主要是练腿部和臀部的，但实际上它是个全身运动器械，小臂的参与度比你想象的要高不少。之所以会痛，原因可能有很多，我们一样一样来拆解看看。首先，最直接的原因，也是最容易被忽略的，就是你对手柄的握持方式不对。很多人在使用椭圆机的时候，习惯性地.............
-
我手上这个用了一段时间的苹果官方皮革手机壳，怎么说呢，就是一种很“皮实”又很“舒服”的矛盾结合体吧。刚拿到的时候，那个触感就挺让人惊喜的。它不像市面上那些硬邦邦的塑料壳，拿在手里就是一种温润的、细腻的触感，滑滑的但又不会觉得粘腻。那种皮革特有的淡淡的香味，刚打开包装的时候尤其明显，虽然现在已经淡了很.............
-
关于使用护照乘坐列车是否存在“漏洞”，这实在是一个很有趣的问题，因为它触及了我们日常生活中的一些看似理所当然但细究起来又充满值得探讨之处的环节。在我看来，如果一定要从“漏洞”这个角度去理解，那更多的是一种“对规则的特定解读”或者说“在现有体系下利用了某些信息不对称或流程上的细微之处”，而不是法律上的.............
-
用防护能力相近的APC（装甲人员输送车）取代IFV（步兵战车），并将节省下来的资金用于装备更多的坦克，这个想法听起来似乎很有经济效益，能够提升整体的装甲力量数量。然而，仔细推敲起来，这种做法存在着不少实际操作和战略层面的问题，而且这些问题一旦显现，可能会让这种看似精打细算的决策付出沉重的代价。首先，.............
-
使用 G1 垃圾收集器（GarbageFirst Garbage Collector）并不能直接等同于不再需要进行虚拟机性能调优。G1 是 JVM 中一个非常优秀的垃圾收集器，它在很多场景下能提供出色的吞吐量和可预测的暂停时间，但“优秀”并不等于“万能”或“自动优化到极致”。我们来深入聊聊为什么即使.............
-
在知乎“好物推荐”里淘金，这几点你得门儿清！知乎，这个知识分享的平台，现在也多了个“好物推荐”的入口，这对于咱们这些爱琢磨、爱折腾、总想买点“值”东西的人来说，简直是打开了新世界的大门。但说实话，刚开始接触的时候，也确实有点摸不着头脑，不知道怎么才能在这里真正找到自己想要的好东西，而不是被一堆“套路.............
-
家里楼上邻居制造噪音，确实是个让人头疼的难题。很多人在忍无可忍的情况下，可能会想到一些“非常规”的解决办法，比如使用震楼器。那么，使用震楼器对付楼上住户，到底违法吗？以及，我们应该怎样更妥善地处理楼上制造噪音的问题呢？咱们今天就来好好聊聊这个话题。关于震楼器：是不是违法，以及潜在的风险首先，直接回答.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有