关于训练的利用率

[hyskylord]

我使用的硬件：16 Cores CPU、64G RAM 、RTX 4090、三星PM983 SSD
Mortal参数：cudnn.benchmark = true, enable_amp = true, enable_compile = true, num_worker = 12, file_batch_size = 15, conv_channel = 256, num_block = 80.
观察到的现象：CPU和GPU的利用率都可以达到峰值（8.5batch/s），但是不能持续跑满（平均6.8batch/s），平均训练速度只有峰值的80%，如图所示

下图为GPU利用率

下图为CPU利用率

目前为止的猜想与尝试，但都没有明显的提升：

猜想1：DataLoader并行度不够
验证：增加num_worker和prefetch_factor，微调file_batch_size，利用率没有明显提升，似乎答案为否。

猜想2：encoding占用太多资源
验证：限制dataloader的CPU占用，使用如下设置

def worker_init_fn(*args, **kwargs):
    worker_info = torch.utils.data.get_worker_info()
    torch.set_num_threads(1)
    os.environ["OMP_NUM_THREADS"] = '1'
    os.environ["MKL_NUM_THREADS"] = '1'
    os.sched_setaffinity(os.getpid(),{worker_info.id})

结果利用率下降，否定了此猜想

猜想3：CPU to GPU瓶颈
验证：提前加载数据到GPU，如下所示

def collate(batch):
    obs, actions,masks, steps_to_done, kyoku_rewards, player_ranks = torch.utils.data.default_collate(batch)
    return (obs.to(dtype=torch.float32, device=torch.device('cuda:0')),
            actions.to(dtype=torch.int64, device=torch.device('cuda:0')),
            masks.to(dtype=torch.bool, device=torch.device('cuda:0')),
            steps_to_done.to(dtype=torch.int64, device=torch.device('cuda:0')),
            kyoku_rewards.to(dtype=torch.float64, device=torch.device('cuda:0')),
            player_ranks.to(dtype=torch.int64, device=torch.device('cuda:0'))
            )

结果：有微弱的提升（约1%~2%），似乎也并不是主要瓶颈

猜想4：IO瓶颈
目前没有验证，但是通过iostat观察到的读写均为15MB/s，低于SSD benchmark结果（4KQD1Read 44MB/s，4KQD1Write 140MB/s），似乎也不会造成瓶颈。

[Koyonomi]

如果你正在使用AutoDL训练 (你提供的利用率截图与AutoPanel的有关界面相同），要注意AutoDL服务器的硬盘是所有机上用户共享的，完全相同的程序在不同时段，利用率曲线也会有明显区别。
但我不确定这个问题是否会发生在Mortal上。

[hyskylord]

上述SSD benchmark数据是我在端上实机运行得到的：

fio --loops=10 --size=1000m --filename=/root/autudl-tmp/fiotest.tmp --stonewall --ioengine=libaio --direct=1 --name=4kQD1read --bs=4k --iodepth=1 --rw=randread   --name=4kQD1write --bs=4k --iodepth=1 --rw=randwrite

应该能够反应实际的读写速度

[Koyonomi]

1 * A100 GPU在93%~100%的利用率（曲线无明显波动)，我这边利用iostat查看的实际读取4MB/S，写入16MB/S(因为我的file_batch_size很小)

[hyskylord]

设置了file_batch_size = 1，确实大幅度提高了利用率。

[2659494286]

你好，可以分享下数据和训练的方法么，有偿

[Equim-chan]

我个人认为问题最可能是出在 dataloader 上。dataloader 的生产是被动触发的，即在 buffer 用完的时候才会去继续生产，而这就不可避免地会造成消费者的等待。增加 num_workers 只是增加了总吞吐，降低 file_batch_size 会减少等待时间但也会缩短生产触发的间隔，无论哪个都没有解决等待的问题。

不过，我确实有尝试过重写 dataloader，相当于自己实现了一个多进程 Queue，来实现完全异步的生产，即从「平时不生产，buffer 用完才开始」改成了「平时一直生产，buffer 满了才停止」，但是最后似乎也没有提升的样子。

[hyskylord]

我之前的理解是每个worker都有独立的的dataset和buffer，所以增加num_worker会减少所有buffer都在生产的可能性，但是实际上pytorch的dataloader似乎是采取的顺序遍历每个worker的方式（see），所以buffer其实是同时用完的。

[Equim-chan]

各个 worker 的 buffer 大小是不一样的，因为每个文件的样本数量不固定。

[hyskylord]

参考了 Equim-chan和Koyonomi的意见，最后将file_batch_size设置为1基本上解决了这个问题（达到了峰值的95%性能）。个人理解是通过最小的buffer_size让buffer一直处于耗尽状态，从而让dataloader持续工作。

不过个人认为未来通过实现异步的读取应该还有一定的性能提升的空间。

[2659494286]

你好，可以分享下数据和训练的方法么，有偿

[KimamanaNeko]

是否设置了过高的batch_size，在我的测试中过高的batch_size带来的并不一定是正向的提升

[2659494286]

你好，可以分享下数据和训练的方法么，有偿

[2659494286]

你好，可以分享下数据和训练的方法么，有偿

[dylanhdy]

设置dataloader中的in_order参数为False，并增大prefetch_factor能够有效缓解dataloader worker等待问题。不过2.6.0版本pytorch的in_order参数相关代码存在性能问题，已在2.7.0进行修复PR。