输入管线瓶颈（DataLoader Bottleneck）指的是：模型训练时 GPU 明明还没跑满，却一直在等数据，真正拖慢整体速度的不是计算，而是从磁盘到显存这条"喂数据"的流水线。
打个饭馆的比方。后厨（GPU）是顶配的，一道菜下锅几秒钟就好；但传菜口只有一个人，还先要洗菜、切菜、摆盘（解码图片、数据增强、拼成 batch），一道菜从下单到进锅要等半分钟。结果大厨大部分时间在灶台边刷手机——这就是 GPU 空转。你嫌出菜慢去骂厨师，方向就错了。
拆开这条管线，大致这么几段：存储读取（本地磁盘或网络存储）→ 解码（比如把 JPEG 还原成像素）→ 预处理增强（裁剪、翻转、归一化）→ 组装成批次（batch）→ 从内存拷进显存（Host to Device，H2D）。任何一段慢了，GPU 就得干等。而这几段的执行者主要是 CPU 和存储系统，它们这些年提速的幅度远不如 GPU，落差越拉越大。尤其图片、视频、点云这类原始数据，解码和增强往往比模型前向还贵。Python 的多进程还会被 GIL（全局解释器锁）和进程间拷贝拖累，让情况更糟。
怎么确认是它？几个通用信号：
- 看 GPU 利用率，长期在低区间来回跳，而不是稳定跑高；
- 用随机生成的假数据（fake data）跑同样的训练循环，如果吞吐一下子翻上去，基本就锁定输入管线；
- 做性能剖析（profiling）时，看到大量等待同步、等待下一个批次的时间。
和几个容易混淆的邻居区分一下：
| 瓶颈类型 | 典型现象 | 大致方向 |
|---|---|---|
| 输入管线 | GPU 利用率低且抖动，假数据一换就快 | 加 worker、预取、加快解码、缓存 |
| 计算瓶颈 | GPU 利用率高但吞吐上不去 | 换算子、混合精度、模型结构 |
| 显存不足（OOM） | 直接报错或反复换入换出 | 减小 batch、梯度累积、重算 |
| 通信瓶颈 | 多卡训练时同步梯度耗时明显 | 通信与计算重叠、调整并行策略 |
请注意第一条和第四条常被误认成"模型太慢"，其实模型是无辜的。
对从业者来说，实际意义很直接：在调模型超参之前，先把喂数据的管线修通。常见做法包括调大 DataLoader 的 worker 数、开启预取（prefetch）、把耗时的增强挪到 GPU 或离线预先算好、用更快的解码方式、把数据缓存到更快的存储上。判断标准也很朴素——让 GPU 忙起来，比让模型更聪明，往往更快见效。至于具体框架里这些参数叫什么、默认值是多少，以官方文档页面为准。
对普通职场人的类比价值在于：任何流水线系统，产出慢时先别质问最贵的那一环，去看看上游的供给节奏。最贵的那台机器空转，损失的从来不只是它自己的时间。