Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Locking image tower fails when locking image tower in a distributed context #288

Open
rsomani95 opened this issue Dec 13, 2022 · 0 comments

Comments

@rsomani95
Copy link
Contributor

I run into a DDP error when trying to freeze part of the image encoder. This is how I'm launching my training run:

torchrun --nproc_per_node 3 -m training.main \
    --train-data $PATH_TO_DATASET \
    --csv-separator , \
    --csv-img-key filepath_mistake_not \
    --epochs 3 \
    --local-loss \
    --use-bn-sync \
    --gather-with-grad \
    --grad-clip-norm 1.0 \
    --pretrained openai \
    --model ViT-L-14 \
    --precision amp_bf16 \
    --lr=1e-4 \
    --warmup 500 \
    --grad-checkpointing \
    --batch-size=336 \
    --lock-image \
    --lock-image-unlocked-groups 5

The error I ran into is:

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).
Parameter indices which did not receive grad for rank 2: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

I tried adding ddp_args['find_unused_parameters'] = True to the script to try and combat this, but that yielded a different 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
during training loop.2) Reused parameters in multiple reentrant backward passes. For example, if you use 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 196 has been marked as ready twice. This means that multiple autograd engine  hooks have fired for this
particular parameter during this iteration. You can set the environment variable TORCH_DISTRIBUTED_DEBUG to either INFO or
DETAIL to print parameter names for further debugging.

The error message above made me think that the issue was perhaps due to gradient checkpointing. My hunch was right, and turning it off (both with and without ddp_args['find_unused_parameters'] = True now works with the above settings.

Thought I'd report anyways because it's unclear to me if this is a bug or those two settings are incompatible.
I'm yet to measure speed, but the only drawback for turning off checkpointing is smaller batch sizes, which I'm able to work around with the accum-freq arg.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant