## 一、一个反常识的账

书里有句话值得贴在显示器上：

> **调优不当的输入管道可能浪费 50% 的 GPU 时间，而算法优化通常只给几个百分点**

这个数字不是危言耸听。数据管道的活儿听起来不高级——读文件、解码、裁剪、分词、打包成 batch——但它卡在 GPU 和存储之间，是最后一道闸门。这道闸门卡了，前面 GPU、网络、存储的所有优化全白费。

![fig8-gpu-breakdown.png](https://developer.qcloudimg.com/http-save/yehe-11479707/1ca9c707fede0f3ad5ae4e38d3e88b9d.png)

这张图是示意。真实比例因人而异，但「等数据 30% → 5%」这个区间在行业里反复出现（PyTorch Profiler 社区案例）。核心逻辑是：GPU 利用率每提高 1%，对千卡集群都是真金白银的硬件成本下降。

## 二、DataLoader 的几个旋钮

PyTorch 的 DataLoader 是多数人的第一站。它有几个旋钮，默认值通常偏保守：

- **`num_workers`**：多少个进程并行取数、预处理。太少 GPU 饿着，太多 CPU 和 I/O 争抢。经验值是 CPU 核数的一半到四分之三，但最终要测。
- **`pin_memory=True`**：把数据锁在固定内存里，主机到 GPU 的 DMA 拷贝更快，还能真正异步。记得把 `ulimit -l` 调高，否则大块的固定内存分配会失败。
- **`prefetch_factor`**：每个 worker 提前加载几批。默认 2，I/O 有突发时调到 4 或 8。
- **`persistent_workers=True`**：worker 跨 epoch 存活，省掉每个 epoch 边界重建进程的开销，短 epoch 场景尤其明显。

这些参数没有银弹，但「默认值够用」在数据管道上是错的——绝大多数人的瓶颈就藏在这几个默认值里。

顺带提一句分布式场景：PyTorch 的 `DistributedSampler` 负责把全局数据集切片到各个 rank，每个 rank 读自己那一份。配合 DataLoader，能从几个 GPU 平滑扩到几百个而不打乱数据分布。

## 三、CPU 准备数据，GPU 算数据，得重叠

数据管道的理想状态是一条流水线：

![fig7-pipeline.png](https://developer.qcloudimg.com/http-save/yehe-11479707/d2b35b3db8108c8412ceadf7c2ba3cf9.png)
当 GPU 在处理第 N 批时，CPU 已经在加载、预处理第 N+1 批，并把第 N+2 批准备好。GPU 算完第 N 批，直接 DMA 拿走第 N+1 批，立刻开工，中间不停。

这条流水线的关键，就是第二章反复讲的「重叠」。多数框架在开了多个 worker 后会自动这么做，但你要**监控它真的发生了**——如果看到 GPU 每次迭代开头都空转一会儿等数据，流水线就是断的。

监控方法：

1. 用 `torch.cuda.Event` 包住 `next(data_iterator)` 计时，这就是 GPU 等下一批数据的总空闲时间。
2. 把 `num_workers=0` 再测一次，隔离纯 Python 开销。
3. 用 `torch.cuda.Event` 包住 `.to("cuda")` 计时，看主机到 GPU 拷贝的代价。

两个时间和总 GPU 空闲一比，瓶颈在 Python 还是 H2D，一目了然。

## 四、数据准备的两种姿势：离线 vs 在线

数据预处理有个根本选择：训练时现做，还是提前做好。

![fig7-offline-online.png](https://developer.qcloudimg.com/http-save/yehe-11479707/3324dc9f13cd52278f08fd0d77d7c498.png)

**在线加载**：训练循环里现读、现解码、现分词。灵活，但每一步都在和 GPU 抢时间。

**离线预处理**：训练开始前，把原始数据一次性处理成干净、定长、二进制化的数据文件，训练时只做轻量的「最后一公里」读取。代价是提前花时间、占额外存储，但换来的是训练时几乎不碰字符串处理、不现分词、读的都是大小均匀的块。

书第 5 章的结论很明确：**几乎永远不该拿原始文本直接训练**。离线预处理花的时间，会通过更快的训练、更快的迭代、更可预测的扩展，加倍赚回来。

一个省钱细节：如果你想训练 N 个 epoch 又不想每个 epoch 现洗牌，可以提前存 N 份不同洗牌顺序的数据副本。用磁盘换时间，在大规模训练里通常是划算的。

### 一个反共识判断

离线预处理常被当作"灵活性的敌人"，但大模型训练里恰恰相反。**把重预处理全部推到离线，训练时的管道越简单，你的迭代速度就越快。** 实时加载的灵活性，很多时候是算法工程师给自己找的借口。

## 五、DALI：把预处理搬到 GPU

如果预处理太重、CPU 扛不住，NVIDIA 的 DALI（Data Loading Library）能把它搬到 GPU 上。

DALI 用声明式的算子图定义数据管道，解码 JPEG、随机裁剪、缩放、归一化这些活，全在 GPU 上干。书第 5 章有一个直观例子：一个图像视频检测任务，纯 CPU 管道要吃满 8 个核（CPU 使用率 800%），GPU 还偶尔停顿；换成 DALI 后，CPU 降到 200%（两个核），只负责读文件，真正的解码交给 GPU，还能和计算并发。

DALI 有个常见坑：如果你只拿它解压 JPEG，解完立刻把原始像素交回 CPU 做增强和打包，那会多出几趟「主机→设备→主机」的拷贝，把收益全抵消。正确的用法是把 GPU 友好的预处理操作整体融合进 GPU 计算图，让数据尽量别在 CPU 和 GPU 之间来回倒。

## 六、NeMo Curator：LLM 数据集的离线工厂

对 LLM 来说，数据管道还有个上游问题：TB 级原始语料怎么清洗成能训练的数据集。

NVIDIA 的 NeMo Curator 就是干这个的。它把清洗、去重、分词、洗牌这些重活，分布式地铺到多个 GPU 或节点上离线做，最后打包成少量大文件，或者二进制格式。它还能去重、剔除问题内容、甚至生成合成数据来补充越来越稀缺的高质量人类数据（来源：NVIDIA NeMo Curator 文档）。

用 Curator 的意义在于：把重预处理全部推到训练之前，让训练时的数据管道退化成一个「读取准备好的数据」的简单动作。这样训练作业绝大部分时间都在做前向和反向传播，而不是处理文本、读几百万个大小不一的小文件。

## 七、踩坑现场：num_workers 设错，GPU 利用率从 80% 掉到 30%

下面是一个基于公开资料整理的典型踩坑模式，不是某一次特定事故，但在很多图像/视频训练里反复出现：

**症状**：模型配置没变，训练突然慢了一倍。`nvidia-smi` 显示 GPU 利用率在 30% 左右反复横跳，CPU 使用率也不高，好像两边都没干活。

**排查**：

1. 用 PyTorch Profiler 或 `torch.cuda.Event` 包住 `next(dataloader)`，发现每次取 batch 要等 40–60 ms。
2. 把 `num_workers=0` 再测，发现 Python 主进程单线程解码 JPEG，CPU 被占满。
3. 主机到 GPU 拷贝只有 2–3 ms，说明 H2D 不是瓶颈。

**修复**：

1. `num_workers` 从默认的 2 调到 CPU 核数的一半（例如 8）。
2. 开 `pin_memory=True` 和 `persistent_workers=True`。
3. 把 JPEG 解码和随机裁剪提前离线做，训练时只读二进制 tensor。

**结果**：GPU 利用率从 30% 回到 80%，整体吞吐提升了 2.5 倍左右。这个案例里，算法一点没变，但训练时间直接减半。

## 八、收尾：先盯数据，再调算法

回到开头那笔账。数据管道的优化，常常比任何算法调整都值钱。

![fig7-idle-improve.png](https://developer.qcloudimg.com/http-save/yehe-11479707/b956e951b0d57de3bc0e74e94215faa5.png)
这张图展示的是同一个意思：优化前 GPU 大量时间空转，优化后等待时间被压到很低。对千卡集群来说，这个差距就是能不能少租一半机器的区别。

下次训练慢的时候，先别急着换优化器、改学习率。先用 Profiler 看一眼 GPU 到底有多少时间在等数据——找准瓶颈再动手，往往比改算法划算得多。

到这里，存储层（上下两篇）就讲完了。加上前面的性能工程、网络层，goodput 三大元凶里的通信和存储/数据管道，都有了抓手。

---
## 参考资料

- Chris Fregly, *AI Systems Performance Engineering*, O'Reilly Media（第 5 章 5.10–5.13）
- NVIDIA DALI 官方文档
- NVIDIA NeMo Curator 官方文档
- PyTorch DataLoader / DistributedSampler 官方文档
- PyTorch Profiler 社区性能调优案例

> 说明：GPU 时间构成图（fig8-gpu-breakdown.png）为基于书第 5 章典型区间的示意值，非特定集群实测。文中 50% GPU 时间浪费等数字沿用《AI Systems Performance Engineering》第 5 章结论，并结合 PyTorch Profiler 常见案例区间说明。


调优不当的输入管道可能浪费 50% 的 GPU 时间，而算法优化通常只给几个百分点

AI Infra 系列 · 第三章 存储层（下）：训练慢别改学习率，先看 DataLoader

存储把数据送到节点了，但还要经过解码、预处理、打包，才能真正进训练循环。这一层藏着一个反常识的坑：一个没调好的数据管道，能吞掉你 50% 的 GPU 时间，而你在算法上抠的那几个百分点，可能连零头都算不上。

运维开发工程师

人工智能

编程语言

开发工具

调优输入管道可减少高达50%的GPU空闲时间，远胜算法优化。核心在于配置DataLoader参数（num_workers、pin_memory、prefetch_factor），实现CPU数据准备与GPU计算重叠，并优先采用离线预处理及DALI/NeMoCurator等工具，可显著提升训练吞吐与硬件利用率。

2026上云采购 | AI焕新·智启新局

tione

tiocr

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI Infra 系列 · 第三章 存储层（下）：训练慢别改学习率，先看 DataLoader-腾讯云开发者社区-腾讯云

AI Infra 系列 · 第三章存储层（下）：训练慢别改学习率，先看 DataLoader

AI Infra 系列 · 第三章存储层（下）：训练慢别改学习率，先看 DataLoader

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第三章 存储层（下）：训练慢别改学习率，先看 DataLoader

AI Infra 系列 · 第三章 存储层（下）：训练慢别改学习率，先看 DataLoader

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

AI Infra 系列 · 第三章存储层（下）：训练慢别改学习率，先看 DataLoader

AI Infra 系列 · 第三章存储层（下）：训练慢别改学习率，先看 DataLoader