多GPU训练时如何设置Hugging Face dataloader_num_workers参数？

这个参数的取值是单训练进程绑定的DataLoader worker子进程数量，不是全局总worker数，配置逻辑确实会随分布式训练模式变化，核心差异来自不同模式下的训练进程架构：

• 针对DistributedDataParallel（DDP）模式：
  用torch.distributed.launch、accelerate launch等标准方式启动DDP时，每一块GPU对应1个独立的训练进程，每个进程都会独立创建自己的DataLoader实例，每个实例都会拉起参数设定数量的worker进程。这种场景下全局总worker数的计算公式为：全局worker数 = dataloader_num_workers * 训练进程数（即GPU卡数）。
• 针对DataParallel（DP）模式：
  DP是单进程多线程架构，整个训练任务只有1个主进程管控所有GPU的计算流程，全局仅存在1个DataLoader实例，你设置的dataloader_num_workers就是全局的总worker进程数，不会随GPU数量倍增。

你对两种模式的配置思路基本是对的，但是要留系统和训练本身的CPU开销冗余：

1. DDP模式下不建议单卡worker设到12以上：如果单卡设12，全局总worker数就是4*12=48，刚好占满所有CPU物理核心，此时主进程的训练调度、GPU通信、系统后台进程没有CPU资源可用，会出现争抢调度的问题，反而拖慢整体速度。实际最优值一般是单卡设10_{11，总worker数控制在40}44，留少量核心给非数据加载的逻辑，设超过12不会带来任何加载收益，只会因为上下文切换开销增加掉速。
2. DP模式下可以把参数设到40_{45左右，不用卡到47：同样要留3}8个核心给主进程的多卡调度、前向反向传播计算、GPU通信逻辑，设满47反而容易出现主进程资源不足导致的GPU空等。

• 不要硬套核心数公式算worker值：如果你的数据集加载逻辑很轻（比如已经做了内存映射、二进制序列化），worker数过高反而会因为多进程启动、进程间通信的开销大于数据加载收益，实际最优值建议通过3_{5分钟的吞吐基准测试确定，大部分场景下单卡worker在4}12之间就能跑满GPU利用率。
• 目前DP模式本身已经不推荐用于多卡训练：单进程多线程的架构受Python GIL锁限制，存在多卡负载不均、通信开销高的问题，同硬件配置下比DDP慢20%左右是常态，多卡训练优先选择DDP架构。

内容的提问来源于stack exchange，提问作者dingus