PyTorch DataLoader的num_worker与prefetch_factor无法线性扩展性能

你的推测完全成立：大尺寸numpy数组跨进程传输时的序列化/反序列化+内存拷贝开销，是多进程加速失效的核心瓶颈。

为什么加大num_workers也没法让队列始终填满 #

• PyTorch多进程DataLoader的数据流存在天然的串行节点：所有worker进程生成的batch，都必须先完成序列化，再通过跨进程管道传输到主进程，主进程完成反序列化后才能被训练逻辑使用。这一传输环节的总带宽是固定的，和worker数量无关，相当于整条数据供给链路的「窄口」。
• 按你测试用的大尺寸数组计算：单条样本为(1000,150)规格的float64 numpy数组，单样本大小约1.2MB，batch_size=128时单batch大小达153.6MB。你模拟的单步训练耗时为0.05s，对应需要的跨进程传输带宽约3GB/s，已经接近Python原生多进程队列（基于pickle+管道实现）的性能上限。
• 此时即使开再多worker，生成的batch都会堵在队列入口等待传输，worker无法持续往队列里塞数据，自然不可能把队列填满，数据传输的固定开销会直接暴露，拖慢整体处理速度。
• 小尺寸数组场景下，单batch大小仅1.5MB左右，传输开销可以忽略，因此加worker能线性降低处理耗时，和你的测试结果完全吻合。

prefetch_factor的实际作用与失效原因 #

prefetch_factor的真实作用是控制单个worker最多可预生成并塞入队列的batch数量，全队列总缓存容量为num_workers * prefetch_factor，设计目标是掩盖worker侧读数据、做预处理的IO/计算耗时波动，本身无法降低数据传输、计算的固定开销。

你测试时调整该参数无效果，对应两种场景的原因分别是：

• 小尺寸数组场景：当worker数量加到8时，单batch处理耗时已经降到0.05s，和你模拟的训练步耗时完全打平，此时队列本身已经处于持续填满的状态，再加大prefetch_factor只是增加队列缓存的batch数量，不会进一步降低耗时，瓶颈已经转移到训练步骤本身。
• 大尺寸数组场景：瓶颈是跨进程传输的固定带宽上限，此时worker根本塞不满prefetch_factor设定的队列容量——你把参数从2调到10，实际队列里可能最多只缓存1-2个batch，参数调整完全不会改变实际运行状态；就算真能把队列填满，主进程取每个batch时依然要花固定时间做反序列化，预存再多batch也没法减少这部分耗时。

可落地的优化方案 #

• 不要在worker中返回大尺寸numpy数组，尽量在worker侧直接将数组转为PyTorch Tensor：PyTorch为Tensor跨进程传输做了共享内存优化，不需要走完整的pickle序列化流程，传输开销可降低一个数量级。
• Linux环境下优先使用默认的fork多进程启动方式，相比你测试用的spawn模式，fork对numpy、PyTorch数据结构的序列化支持更好，额外开销更低。
• 尽量把数组拼接、格式转换等计算逻辑放到worker侧完成，减少主进程侧的计算负载，避免主进程成为新的瓶颈。
• 如果必须传输大尺寸numpy数组，可手动将数组挂载到共享内存段，worker仅向主进程传输共享内存句柄，避免直接拷贝数组本体。

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