数据管道设计：确保加速器持续满载

数据流水线的设计依据应当是节点实际可持续的读取速率，而非数据集的规模。多数性能不达标的集群，问题出在这里，而不在模型。

从节点出发

首先确定：在计划采用的批大小与模型下，需要多高的读取速率才能让一个八 GPU 节点保持满负荷。该数值乘以节点数量，即为存储层必须满足的要求。按容量确定存储规格、并寄望吞吐自然达标，是常见的错误做法，其结果恰恰是本文库其他文章所描述的症状：GPU 报告利用率高、实际吞吐低，且任何位置都不报错。

预处理

在训练循环内部执行的预处理，会与训练争夺同一批资源。若变换过程是确定性的，那么一次性完成并存储结果几乎总是更划算的取舍，即便需要付出额外存储空间的代价。若变换必须按轮次随机进行，则应交由 CPU 工作进程承担，并按能够始终领先于加速器的规模进行配置，而不应置于关键路径之上。

缓存与预取

若工作集能够装入节点本地缓存，稳态运行中的大部分网络开销即被消除。预取深度应调整到：在当前批次处理完成之前，下一批次已驻留内存。合适的深度取决于单步耗时与读取延迟，值得实测而非估算。

当训练节点数量超过约八台后，制约因素将从带宽转为并发能力，此时同时分布元数据与数据的并行文件系统通常是正确答案。在此规模以下，一台配置得当的 NVMe-oF 存储柜更为简单且已经够用。

监测数据加载环节

应将数据加载等待时间与单步耗时并列，作为一级指标进行跟踪。这是区分模型本身慢与数据供给不足这两种情况最快的方法，而这两种情况在利用率图表上看起来完全相同。