内存泄漏 & 多机性能问题

[nebuladream]

dataloader 存在内存泄漏问题，好像新版本也没fix 。 有什么建议么？

[zhengzangw]

这里绿线包括 cache 吗？我们实验中观察到的现象是：memory used 不会增加，cached memory 会增加。

[nebuladream]

是mem usage，1080P 8个worker的话基本上几千个step就oom了。把epoch变小，worker数量降低，每个epoch结束后做下gc清理能基本维持mem不爆掉。另外，这个代码的分布式有性能问题，scale up后迭代速度会随卡数增加而变差。

[nebuladream]

应该是多节点通信的性能问题，节点数double，单个step的时间也会增长一倍，scaleup基本上不可用。

[nebuladream]

实测8台机器是极限

[zhengzangw]

mem usage 我们正在查。但是分布式性能我们这边测下来是正常的，节点数从单节点到 12 节点速度单个时间 step 速度基本不变（16s -> 18s /it）。如果你的 scaleup 有问题的话，我觉得可能是：

1. 可以看一下你们多节点之间的通信带宽和拓扑。
2. 可以检查一下通信相关的配置（比如 NCCL 环境变量）
3. 结合你说的 8 台极限，可能你 8 台之外的机器连接带宽不同。

[nebuladream]

分布式这块的code你们有update过么？测试的是1.0版本的，360P 32帧视频 8台7sec，16台～14sec。 集群没问题的，megatron重新实现了下就好了。

[zhengzangw]

应该有，我记得 colossalai 版本更新后就更适配了。你们 batch size 是多大呀，8台 7s -> 16台 14s 感觉慢的太多了，我们目前没有观察到这样的现象。

[nebuladream]

colossalai你们推荐哪个版本啊，我们可以update下再测测

[nebuladream]

应该有，我记得 colossalai 版本更新后就更适配了。你们 batch size 是多大呀，8台 7s -> 16台 14s 感觉慢的太多了，我们目前没有观察到这样的现象。

单卡bs=1，8gpu/台

[zhengzangw]

机器是 H100 吗？我先继续修一下你上面提到的 memory leak 现象。之后我用你的 setting 测一下速度，大概明天反馈给你。

[nebuladream]

A800

[chehx]

mem usage 我们正在查。但是分布式性能我们这边测下来是正常的，节点数从单节点到 12 节点速度单个时间 step 速度基本不变（16s -> 18s /it）。如果你的 scaleup 有问题的话，我觉得可能是：

1. 可以看一下你们多节点之间的通信带宽和拓扑。
2. 可以检查一下通信相关的配置（比如 NCCL 环境变量）
3. 结合你说的 8 台极限，可能你 8 台之外的机器连接带宽不同。

NCCL的配置有什么推荐吗？我这边观察到现象是随着训练进行，一些速度会显著变慢。

Epoch 3: 54%|█████▍ | 806/1488 [3:11:51<2:38:10, 13.92s/it, loss=0.503, step=805, global_step=5269]Rank 0 | Epoch 3 | Step 806 | move data: 1.491s | encode: 4.004s | mask: 0.001s | diffusion: 2.296s | backward: 7.125s | update_ema: 0.043s | reduce_loss: 0.001s | Rank 1 | Epoch 3 | Step 806 | move data: 1.194s | encode: 4.302s | mask: 0.001s | diffusion: 2.296s | backward: 7.125s | update_ema: 0.043s | reduce_loss: 0.001s |

而在这之后不久

Epoch 3: 55%|█████▍ | 814/1488 [3:33:50<34:47:20, 185.82s/it, loss=0.503, step=805, global_step=5269]Rank 3 | Epoch 3 | Step 814 | move data: 2.161s | encode: 78.647s | mask: 0.105s | diffusion: 15.410s | backward: 133.027s | update_ema: 5.773s | reduce_loss: 0.103s | Rank 1 | Epoch 3 | Step 814 | move data: 6.429s | encode: 74.378s | mask: 0.091s | diffusion: 15.402s | backward: 133.082s | update_ema: 5.719s | reduce_loss: 0.101s | Rank 0 | Epoch 3 | Step 814 | move data: 59.557s | encode: 21.276s | mask: 0.042s | diffusion: 15.423s | backward: 133.040s | update_ema: 5.747s | reduce_loss: 0.113s | Rank 2 | Epoch 3 | Step 814 | move data: 3.107s | encode: 77.701s | mask: 0.111s | diffusion: 15.409s | backward: 133.077s | update_ema: 5.728s | reduce_loss: 0.101s |

观察到显卡功耗占用也显著降低。config是默认的stage 3

[nebuladream]

机器是 H100 吗？我先继续修一下你上面提到的 memory leak 现象。之后我用你的 setting 测一下速度，大概明天反馈给你。

怎么样？

[zhengzangw]

机器是 H100 吗？我先继续修一下你上面提到的 memory leak 现象。之后我用你的 setting 测一下速度，大概明天反馈给你。

怎么样？

定位了问题在 pyav 这个库与 python list 交互时的内存泄露。比较复杂，目前能减轻一些，我还在看怎么处理能够更好。暂时还没测速度，我先把 memory leak 修完吧。

[zhengzangw]

是mem usage，1080P 8个worker的话基本上几千个step就oom了。把epoch变小，worker数量降低，每个epoch结束后做下gc清理能基本维持mem不爆掉。另外，这个代码的分布式有性能问题，scale up后迭代速度会随卡数增加而变差。

我优化了一下内存泄露的问题。你可以看 #526 中的具体分析。在我们的测试中，我们把 450G 内存占用降低到 300G 以下了，并且经过计算，与 dataloader=8 8 卡的情况下理论计算量相差不大，也没有内存泄露。

由于视频解压后本身很大，训练本身需要大量的内存。如果需要减小内存占用，可以尝试：

1. 减小 dataloader 数量
2. 减小 prefetch_factor 数量（pytorch 默认为 2）
3. 减小训练用的视频的大小

[zhengzangw]

mem usage 我们正在查。但是分布式性能我们这边测下来是正常的，节点数从单节点到 12 节点速度单个时间 step 速度基本不变（16s -> 18s /it）。如果你的 scaleup 有问题的话，我觉得可能是：

1. 可以看一下你们多节点之间的通信带宽和拓扑。
2. 可以检查一下通信相关的配置（比如 NCCL 环境变量）
3. 结合你说的 8 台极限，可能你 8 台之外的机器连接带宽不同。

NCCL的配置有什么推荐吗？我这边观察到现象是随着训练进行，一些速度会显著变慢。

Epoch 3: 54%|█████▍ | 806/1488 [3:11:51<2:38:10, 13.92s/it, loss=0.503, step=805, global_step=5269]Rank 0 | Epoch 3 | Step 806 | move data: 1.491s | encode: 4.004s | mask: 0.001s | diffusion: 2.296s | backward: 7.125s | update_ema: 0.043s | reduce_loss: 0.001s | Rank 1 | Epoch 3 | Step 806 | move data: 1.194s | encode: 4.302s | mask: 0.001s | diffusion: 2.296s | backward: 7.125s | update_ema: 0.043s | reduce_loss: 0.001s |

而在这之后不久

Epoch 3: 55%|█████▍ | 814/1488 [3:33:50<34:47:20, 185.82s/it, loss=0.503, step=805, global_step=5269]Rank 3 | Epoch 3 | Step 814 | move data: 2.161s | encode: 78.647s | mask: 0.105s | diffusion: 15.410s | backward: 133.027s | update_ema: 5.773s | reduce_loss: 0.103s | Rank 1 | Epoch 3 | Step 814 | move data: 6.429s | encode: 74.378s | mask: 0.091s | diffusion: 15.402s | backward: 133.082s | update_ema: 5.719s | reduce_loss: 0.101s | Rank 0 | Epoch 3 | Step 814 | move data: 59.557s | encode: 21.276s | mask: 0.042s | diffusion: 15.423s | backward: 133.040s | update_ema: 5.747s | reduce_loss: 0.113s | Rank 2 | Epoch 3 | Step 814 | move data: 3.107s | encode: 77.701s | mask: 0.111s | diffusion: 15.409s | backward: 133.077s | update_ema: 5.728s | reduce_loss: 0.101s |

观察到显卡功耗占用也显著降低。config是默认的stage 3

我看到你是 encode/backward time 增加，这个确实很有可能是网卡问题。鉴于这个问题下的讨论已经比较杂了，如果你想解决可以再开一个问题。同时请附上更多的信息。

[zhengzangw]

分布式这块的code你们有update过么？测试的是1.0版本的，360P 32帧视频 8台7sec，16台～14sec。 集群没问题的，megatron重新实现了下就好了。

我们测试了一下发现确实有通信问题，我会继续看能否修复。在我们的预训练中这个问题不明显的原因是，我们的 batch size 很大，所以每个 step 时间很长，掩盖了通信时间的增长。

使用 OpenSora 1.0 32x360p local bs=1 的速度如下：

1 GPU	8 GPUs	12x8 GPUs
1.1s/it	1.3s/it	2.4s/it

所以多机时确实有 2 倍的速度增长。我们会尝试优化这个问题。不过我们测下来的速度应该远低于 8s。此外，我们也测了 OpenSora 1.2 360p local bs=1:

1 GPU	8 GPUs	12x8 GPUs
2.7s/it	2.9s/it	5.9s/it

The problem still exists.

[chehx]

mem usage 我们正在查。但是分布式性能我们这边测下来是正常的，节点数从单节点到 12 节点速度单个时间 step 速度基本不变（16s -> 18s /it）。如果你的 scaleup 有问题的话，我觉得可能是：

1. 可以看一下你们多节点之间的通信带宽和拓扑。
2. 可以检查一下通信相关的配置（比如 NCCL 环境变量）
3. 结合你说的 8 台极限，可能你 8 台之外的机器连接带宽不同。

NCCL的配置有什么推荐吗？我这边观察到现象是随着训练进行，一些速度会显著变慢。 Epoch 3: 54%|█████▍ | 806/1488 [3:11:51<2:38:10, 13.92s/it, loss=0.503, step=805, global_step=5269]Rank 0 | Epoch 3 | Step 806 | move data: 1.491s | encode: 4.004s | mask: 0.001s | diffusion: 2.296s | backward: 7.125s | update_ema: 0.043s | reduce_loss: 0.001s | Rank 1 | Epoch 3 | Step 806 | move data: 1.194s | encode: 4.302s | mask: 0.001s | diffusion: 2.296s | backward: 7.125s | update_ema: 0.043s | reduce_loss: 0.001s | 而在这之后不久 Epoch 3: 55%|█████▍ | 814/1488 [3:33:50<34:47:20, 185.82s/it, loss=0.503, step=805, global_step=5269]Rank 3 | Epoch 3 | Step 814 | move data: 2.161s | encode: 78.647s | mask: 0.105s | diffusion: 15.410s | backward: 133.027s | update_ema: 5.773s | reduce_loss: 0.103s | Rank 1 | Epoch 3 | Step 814 | move data: 6.429s | encode: 74.378s | mask: 0.091s | diffusion: 15.402s | backward: 133.082s | update_ema: 5.719s | reduce_loss: 0.101s | Rank 0 | Epoch 3 | Step 814 | move data: 59.557s | encode: 21.276s | mask: 0.042s | diffusion: 15.423s | backward: 133.040s | update_ema: 5.747s | reduce_loss: 0.113s | Rank 2 | Epoch 3 | Step 814 | move data: 3.107s | encode: 77.701s | mask: 0.111s | diffusion: 15.409s | backward: 133.077s | update_ema: 5.728s | reduce_loss: 0.101s | 观察到显卡功耗占用也显著降低。config是默认的stage 3

我看到你是 encode/backward time 增加，这个确实很有可能是网卡问题。鉴于这个问题下的讨论已经比较杂了，如果你想解决可以再开一个问题。同时请附上更多的信息。

谢谢回复，我现在怀疑也是内存的问题。因为当我把num_worker开到2，这个问题就不存在了，训练一切正常。

[nebuladream]

it

那感觉差不多？我之前测试单机的话32帧也要3sec的，64卡大概6-7sec吧，感觉你这个测试速度更快一点，用的A800么？

[zhengzangw]

549 优化了我们的多机性能。使用 colossalai 0.4.0, 目前测试速度为：

1 GPU	8 GPUs	8x8 GPUs
2.65s/it	2.75s/it	3.50s/it