Repository navigation
[PyTorch] Type the grouped wgrad from main_grad for distributed weights #3397
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
base: main
Are you sure you want to change the base?
Changes from all commits
5ec40f8
c73b296
f5d8e77
1b2a404
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -28,6 +28,7 @@ | |
| materialize_weight_for_forward, | ||
| materialize_weight_for_backward, | ||
| finalize_weight_grads, | ||
| weight_grad_dtype, | ||
| ) | ||
| from ...module.base import _2X_ACC_WGRAD | ||
| from ...quantization import Recipe, get_fp8_torch_dtype | ||
|
|
@@ -873,7 +874,7 @@ def _compute_grad_params( | |
| shapes=[weight_shape] * num_groups, | ||
| quantizer=None, | ||
| device=device, | ||
| dtype=dtype, | ||
| dtype=weight_grad_dtype(weights, dtype), | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I dont understand how this will help, since we will never enter this else condition of allocating using torch.empty, if main_grad is attached to the parameter.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually we will, if accumulate_into_main_grad is False, but why are we attaching main_grad to parameter in that case in Megatron?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi @vthumbe1503 , for you first question why this line's change is required: we need to follow Details:
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
for MLM:
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for the explaination @fanshiqing! Why is this problem not present for discrete weights? Is it because in case discrete weights, we always write directly into the main_grad buffer?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi @vthumbe1503 , Mostly yes — what matters is whether the reduction runs before or after the wgrad lands in main_grad:
|
||
| ) | ||
| wgrad_output = grouped_wgrad | ||
| w_list = [grouped_wgrad.rowwise_data.view(num_groups, *weight_shape)] | ||
|
|
@@ -889,7 +890,7 @@ def _compute_grad_params( | |
| wgrad_packed = torch.empty( | ||
| num_groups, | ||
| *weight_shape, | ||
| dtype=dtype, | ||
| dtype=weight_grad_dtype(weights, dtype), | ||
| device=device, | ||
| ) | ||
| w_list = [wgrad_packed[i] for i in range(num_groups)] | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can also get rid of this helper?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I'd keep this one. It's the actual fix, and without it the same condition gets copied into 8 places