Any gradient checkpointing operation?

[tb2-sy]

Nice work!I am using multi-gpu ddp to train, local_tensorfs = DDP(local_tensorfs, device_ids=[args.local_rank], output_device=args.local_rank, find_unused_parameters=True)

When set find_unused_parameters=True, an error is thrown. Is there any gradient checkpointing operation in the code? This may cause the error. "RuntimeError: Expected to mark a variable ready only once. This error is caused by one of the following reasons: 1) Use of a module parameter outside the forward function. Please make sure model parameters are not shared across multiple concurrent forward- Backward Passes. Or try to use_Set_Static_graph () as a workaround if this module graph does not change training loop.2) Reused Parameters In Multiple Re entyrt Backward Passes. For Example, if you used multiple Checkpoint Functions to wrap the Same Part of your model, it would result in the same set of parameters been used by different reentrant backward passes multiple times, and hence marking a variable ready multiple times. DDP does not support such use cases in default. You can try to use _set_static_graph() as a workaround if your module graph does not change over iterations. Parameter at index 8 with name t_c2w.0 has been marked as ready twice. This means that multiple autograd engine hooks have fired for this particular parameter during this iteration.”

What's even more excruciating is that when I set find_unused_parameters=False, it throws another error, which confuses me so much that I really need your help, thanks! “RuntimeError: Expected to have finished reduction in the prior iteration before starting a new one. This error indicates that your module has parameters that were not used in producing loss. You can enable unused parameter detection by passing the keyword argument find_unused_ parameters=True to torch.nn.parallel.DistributedDataParallel, and by making sure all forward function outputs participate in calculating loss. If you already have done the above, then the distributed data parallel module wasn't able to locate the output tensors in the return value of your module's forward function. Please include the loss function and the structure of the return value of forward of your module when reporting this issue (e.g. list, dict, iterable). Parameters which did not receive grad for rank 1: exposure.0, exposure.1, exposure.2, exposure.3, exposure.4 Parameter indices which did not receive grad for rank 1: 13 14 15 16 17 if torch.is_grad_enabled() and self.reducer._rebuild_buckets(): RuntimeError: Expected to have finished reduction in the prior iteration before starting a new one. This error indicates that your module has parameters that were not used in producing loss. You can enable unused parameter detection by passing the keyword argumentfindunused parameters=Truetotorch.nn.parallel.DistributedDataParallel, and by making sure allforwardfunction outputs participate in calculating loss. If you already have done the above, then the distributed data parallel module wasn't able to locate the output tensors in the return value of your module'sforwardfunction. Please include the loss function and the structure of the return value offorward of your module when reporting this issue (e.g. list, dict, iterable). Parameters which did not receive grad for rank 0: exposure.0, exposure.1, exposure.2, exposure.3, exposure.4 Parameter indices which did not receive grad for rank 0: 13 14 15 16 17"

[ameuleman]

Hi, I'm not sure what could be the issue. We have several optimizers running at each iteration and operations outside of the forward function (for regularisation losses). Do you anticipate multi-gpu to significantly speed up the optimisation? Since GPU load is quite low, I believe we have strong overhead from multiple optimizers and a slow dataloader that should be resolved first.

[tb2-sy]

Hi, I'm not sure what could be the issue. We have several optimizers running at each iteration and operations outside of the forward function (for regularisation losses). Do you anticipate multi-gpu to significantly speed up the optimisation? Since GPU load is quite low, I believe we have strong overhead from multiple optimizers and a slow dataloader that should be resolved first.

Yes, you're right, ddp seems to be a lot slower. . .